search for: flatbuff

...I take it you mean (as detailed later) to have a separate format > (could be a portable binary format, but currently discussing it as > JSON/YAML/etc) that things are converted from that makes them portable? > >> > > One thing worth mentioning on this regard is maybe we can use Flatbuffers ( > https://google.github.io/flatbuffers/) for the XRay log. > For the secondary form (instead of YAML/JSON) or the primary form (the thing compiler-rt writes out)? Or as a form that would cover both use cases without the need to convert from one format to another? > > Flatbuffers...

...e: - Abbrev are lazily emitted in the stream and can be interleaved with record. You have to scan the whole block to get the context for a record. - Because records have variable size, you need to parse then in sequence to find the “interesting” one. I just finished a quick prototype using Google Flatbuffers ( http://google.github.io/flatbuffers/ ). This is a solution that provide “zero-copy” serialization/deserialization, by avoiding the use of variable length integer and aligning appropriately every field. The structure of the serialization is described using a DSL, and the serialization/deseriali...

...e lazily emitted in the stream and can be interleaved with record. You have to scan the whole block to get the context for a record. > - Because records have variable size, you need to parse then in sequence to find the “interesting” one. > > I just finished a quick prototype using Google Flatbuffers ( http://google.github.io/flatbuffers/ <http://google.github.io/flatbuffers/> ). This is a solution that provide “zero-copy” serialization/deserialization, by avoiding the use of variable length integer and aligning appropriately every field. The structure of the serialization is described...

> On 7 Sep 2016, at 01:21, David Blaikie <dblaikie at gmail.com> wrote: > > (sorry for the delay) > All good, thanks Dave! > On Tue, Aug 23, 2016 at 1:05 AM Dean Michael Berris <dean.berris at gmail.com <mailto:dean.berris at gmail.com>> wrote: > Hi llvm-dev, > > I've been implementing a tool for analysing XRay traces. A recap of XRay's

...> If this is an application that you've developed in-house, you should be using htonl() to convert your 32-bit values to network byte order ?or its superset, XDR [1] ?or use a text format (XML, JSON, YAML, SQL, CSV?) ?or use a binary serialization of same (BSON, CBOR, Binary XML?) ?or use FlatBuffers [2] ?or use ASN.1 [3] or, or or. This problem is *solved*. The only difficult part is choosing which of the many available solutions to use. [1]: https://en.wikipedia.org/wiki/External_Data_Representation [2]: https://en.wikipedia.org/wiki/FlatBuffers [3]: https://en.wikipedia.org/wiki/A...

We have been fortunate to hang onto one of our summer interns for part time work on weekends during the current school year. One of the intern's jobs is to load documents and data which are then processed.? The documents are .txt, .docx, and .pdf files. The data files are raw sensor outputs usually captured using ADCs mostly with eight bit precision.? All files are loaded or moved from one

Hi Vikram, It is a bit more that just “efficient (de)serialization” as there is some amount of tradeoff to make between “size” vs “speed” vs “flexibility” (which are all some sort of “efficient”). For instance what if we get a faster deserialization but got larger size? That might be an issue for some people who’d like to ship bitcode. Another thing is that we may get better speed/size by

Hi Mehdi, Yes, we did see your earlier post. Efficient (de)serialization is definitely important for both exporting (a la LTO and ThinLTO) and for shipping code as IR. I expect most use cases of the latter would benefit. -—Vikram // Vikram S. Adve // Professor, Department of Computer Science // University of Illinois at Urbana-Champaign // vadve at illinois.edu<mailto:vadve at