6 ms·

> no intrinsic value to your stronger definition of zero-copy. Whoa, that's a very strong statement. But then the rest of the paragraph gets a lot weaker. > t

> no intrinsic value to your stronger definition of zero-copy. Whoa, that's a very strong statement. But then the rest of the paragraph gets a lot weaker. > there are high-performance computation packages that compress data structures in L1-cached-sized blocks This seems like a non sequitur. Of course hand-tuned data structures can achieve higher performance than any serialization framework, but what does that have to do with zero-copy vs. protobuf? Are you suggesting that protobuf encoding would be a good choice for these people? > So, you've used the word "achieve" to decorate an outcome that might not be optimal. I'm not sure why "achieve" would imply "optimal". Of course whether this is an advantage depends on the use case. There are many cases where zero-copy doesn't provide any real advantages. If you're just sending messages over a standard network socket, then yeah, zero-copy probably isn't going to make things faster. There are already several copies inherent in network communication. But if you have a huge protobuf file on disk and you want to read one field in the middle of it, that's just not something you can do in any sort of efficient way. With zero-copy, you can do this trivially with mmap(). Or if you're communicating over shared memory between processes on the same machine, then the entire serialize/parse round trip required with protobuf is 100% waste. Zero-copy would let you build and consume the structure from the same memory pages. These seem "intrinsically valuable"? > we could never get flatbuffers to go any faster. What use case were you testing? Did you test any zero-copy serializations other than flatbuffers? I've heard from lots of people that say Cap'n Proto beat Protobuf in their tests... but it definitely depends on the use case.

jeffbee 6y ago
> Or if you're communicating over shared memory between processes on the same machine, then the entire serialize/parse round trip required with protobuf is 100% waste. This is the part I don’t agree with. What I’m saying there is value in using encoded structures not only between servers and not only over shared memory but even within a single process. Yes, you discard the ability to just jump to any random field, but that is not always important. Often it can be better to spend some compute cycles and L1 accesses to save main memory accesses. If you are having to make full access to some kind of data anyway, then packing it makes a ton of sense. Consider any kind of delta-encoded column of values ... you can’t seek within it, but if the deltas are smaller than the absolutes, this can save massive amounts of main memory bandwidth. This is why I argue that representing something as a C struct in main memory is not obviously advantageous, outside some given workloads. As for flatbuf at google I’m sure you’re aware that the only way to get the kind of mindshare you’d need to ship it would be to make websearch measurably faster.
- fluffything 6y ago
  > Yes, you discard the ability to just jump to any random field, but that is not always important. I don't think this is the criticism being raised. The main criticism being raised against non-zero-copy serialization is that this often requires maintaining different memory representations for the same value - the copies are the consequence of transforming from one representation to another one.
  - jeffbee 6y ago
    We do that all the time in high-performance computing. You keep a packed representation in memory and unpack it in small pieces to operate on it. Sparse matrices, compressed columns, etc. This is not evil, it’s an adaptation to the way the machine works. Saying that Kenton’s definition of zero-copy is unconditionally better is an aesthetic argument and I don’t buy it.
    - fluffything 6y ago
      You are still not getting it. They are not talking about "unpacking on the fly for processing", but rather about "unpacking on memory to be able to call an opaque API outside your control that expects the unpacked representation". That requires copying in-memory to interface with that API. Your approach only works if you are willing to "re-implement the world" to interface with whatever packed format suits your application. With zero-copy serialization you don't have to do that.
      - jeffbee 6y ago
        We can both advocate for different perspectives on this issue without either of us “not getting it”.
    - Dylan16807 6y ago
      > Saying that Kenton’s definition of zero-copy is unconditionally better It feels like you're conflating things here. It's not always a better algorithm, but it's a better definition.

jeffbee 6y ago

> Or if you're communicating over shared memory between processes on the same machine, then the entire serialize/parse round trip required with protobuf is 100% waste. This is the part I don’t agree with. What I’m saying there is value in using encoded structures not only between servers and not only over shared memory but even within a single process. Yes, you discard the ability to just jump to any random field, but that is not always important. Often it can be better to spend some compute cycles and L1 accesses to save main memory accesses. If you are having to make full access to some kind of data anyway, then packing it makes a ton of sense. Consider any kind of delta-encoded column of values ... you can’t seek within it, but if the deltas are smaller than the absolutes, this can save massive amounts of main memory bandwidth. This is why I argue that representing something as a C struct in main memory is not obviously advantageous, outside some given workloads. As for flatbuf at google I’m sure you’re aware that the only way to get the kind of mindshare you’d need to ship it would be to make websearch measurably faster.

fluffything 6y ago
> Yes, you discard the ability to just jump to any random field, but that is not always important. I don't think this is the criticism being raised. The main criticism being raised against non-zero-copy serialization is that this often requires maintaining different memory representations for the same value - the copies are the consequence of transforming from one representation to another one.
- jeffbee 6y ago
  We do that all the time in high-performance computing. You keep a packed representation in memory and unpack it in small pieces to operate on it. Sparse matrices, compressed columns, etc. This is not evil, it’s an adaptation to the way the machine works. Saying that Kenton’s definition of zero-copy is unconditionally better is an aesthetic argument and I don’t buy it.
  - fluffything 6y ago
    You are still not getting it. They are not talking about "unpacking on the fly for processing", but rather about "unpacking on memory to be able to call an opaque API outside your control that expects the unpacked representation". That requires copying in-memory to interface with that API. Your approach only works if you are willing to "re-implement the world" to interface with whatever packed format suits your application. With zero-copy serialization you don't have to do that.
    - jeffbee 6y ago
      We can both advocate for different perspectives on this issue without either of us “not getting it”.
  - Dylan16807 6y ago
    > Saying that Kenton’s definition of zero-copy is unconditionally better It feels like you're conflating things here. It's not always a better algorithm, but it's a better definition.