3 ms·
I'd be interested to understand the design choices behind using protobuf as an interface with LLVM: in my reasoning, it may be more performant, but that seriali
by pyrale 2y ago
I'd be interested to understand the design choices behind using protobuf as an interface with LLVM: in my reasoning, it may be more performant, but that serialization step is a very small part of compute, and the serialization format is unusable by humans. For debug purposes, it'd have been nice to have a more human-friendly format. Did the project have other constraints?
- kubb 2y agoSerialized protocol buffers can be converted to the human friendly text format: https://protobuf.dev/reference/protobuf/textformat-spec/ https://protobuf.dev/reference/protobuf/textformat-spec/ He most likely wants to have the type structure generated by protocol buffer as opposed to parsing JSON The latter requires asserting in a million places that this key exists in this map with this type, which will require a million lines of crap code. Not to mention packing and unpacking the serialized data and maintaining two separate sets of corresponding structures/records that have to be kept in sync.
- rurban 2y agoProtobuf also needs to deserialized. Cap'n proto would have been the better option.
- etyp 2y agoI've actually tried serializing languages into protobufs. The main reason was it made communication from X random programming language to Java in a consistent, structured way. Seems like it's just how they sent the IR from OCaml to C++. On either side you'll get the Bolt IR so I don't think debugging suffers too much. But the extra step for serializing and deserializing is a bit of a bummer