4 ms·
> Assuming little-endian CPU arch. It's followed by a byte reorder on big-endian architectures. Basically all common CPUs are LE. (And basically all BE CPUs h
by kentonv 9y ago
> Assuming little-endian CPU arch. It's followed by a byte reorder on big-endian architectures.
Basically all common CPUs are LE.
(And basically all BE CPUs have dedicated instructions for reading LE data. It's true I haven't yet added the inline assembly to use those instructions in Cap'n Proto's reference implementation, but that's only because no one actually cares about these architectures.)
So in basically all real use, there's no machine-instruction-level difference between accessing a field of a capnp struct and accessing a field of a C struct. If the instructions are identical, then how can you say one is "deferred parsing" and the other isn't? What meaning does any such distinction have?
> There's a performance cost, but hopefully you're only doing serialization/deserialization when you intend to hit the disk or wire to read/write into/out of your struct.
Disk is usually cached, meaning it's already in physical memory and you're wasting time making a copy rather than using the data in-place.
Over the network, within a datacenter, bandwidth is basically infinite (in that your CPU probably can't process bytes as fast as your network interface can). Time spent serializing and parsing is very real and wasteful. I've seen servers spending 30% or more of their CPU time parsing protobufs.
Over the long-haul internet, perhaps the CPU time spent parsing/serializing is not as relevant compared to the time spent transmitting. Still, I'd rather spend my CPU cycles elsewhere -- like in a dedicated compression algorithm -- rather than twiddling bytes needlessly in a parser.
> handling arbitrary binary formats
Yes, we all agree that some binary formats can't be handled any other way. But if you're in control of the format you use, then you can design it in a way that doesn't require a "bag of bytes" model, and your code can be much simpler and more adaptable as a result.
- zerokernel 9y ago> but that's only because no one actually cares about these architectures. This. Optimizing performance on BE is a waste of everyone's time and resources.
- classichasclass 9y agoExcept, of course, for those small number of us who primarily do run on a BE platform. I don't mind doing this work, just let us do it.
- kentonv 9y agoFWIW I'd be very happy to accept patches adding the appropriate platform-specific inline assembly around here: https://github.com/capnproto/capnproto/blob/master/c++/src/capnp/endian.h#L139-L175 https://github.com/capnproto/capnproto/blob/master/c++/src/c... (But the status quo on BE is that it does a load followed by a byte swap, which is probably pretty cheap anyway. The compiler might even already know how to optimize that into the appropriate LE-load instruction.)