4 ms·

I believe what he's referring to is also called AoS(Arrays of Structures) vs SoA(Structure of Arrays). If you're iterating over one or two values in a struct v

I believe what he's referring to is also called AoS(Arrays of Structures) vs SoA(Structure of Arrays). If you're iterating over one or two values in a struct via AoS it's very painful from a memory caching standpoint since you're only getting sizeof(member) / sizeof(struct) efficiency. In a SoA situation all your data for members is tightly packed so you usually get better cache coherency. That said the best approach is actually looking at your data access patterns and packing your data appropriately. Unfortunately some languages don't have value types(most managed languages except C#). This is why C/C++ is usually faster than managed languages, they can get close on generated code but can be off by a factor of 50x in memory access performance.

pron 11y ago
> This is why C/C++ is usually faster than managed languages, they can get close on generated code but can be off by a factor of 50x in memory access performance. This is a common misconception that is a result of Java's current state. Control over memory layout and garbage collection are two completely orthogonal issues. At the moment, Java just happens to be both GCed and to afford little control over memory layout. Currently, the HotSpot team (HotSpot is the name of OpenJDK's JVM) is working on project Valhalla and project Panama, two efforts scheduled for Java 10 and intended to give the JVM all the memory layout control you need.
- vvanders 11y ago
  Not completely. Most GCs want to be able to compact the heap, that means they lean in favor of reference based models by default. It's not exclusive like you mention but to my knowledge C# is the only language with explicit guarantees. I was aware of the effort around Java's value types, however how long till we can reasonably see this in production? You can do this in Java today but it involves lots of nasty ByteBuffer manipulation(in which FlatBuffers is fantastic for). You'll still pay for the conversions from bytes to the actual types you want. If you're dealing with these types of performance problems it's best to treat them with a language that's well suited to deal with them. There's nothing wrong with using Java for higher level business logic and delegating the heavy lifting to a stack that's designed to deal with them.
  - pron 11y ago
    > Most GCs want to be able to compact the heap, that means they lean in favor of reference based models by default. I don't see how this follows. Copying GCs do compact the heap, but when you use values you're basically saying "these two things go together". You're only making life easier for the GC (well, you're also creating larger objects, but that might just require a small adjustment of the GC strategy). > how long till we can reasonably see this in production? Four years probably... Still, that doesn't change the fact that layout and GCs are orthogonal.
  - vvanders 11y ago
    Expanding on my point a bit, I'm not arguing that in theory GC and memory layout are orthogonal. Just that in practice you don't see memory layout in languages that are managed. Since I'm usually not in a habit of building a new languages to solve problems it's something worth understanding when making a technical selection on a language.
  - pjmlp 11y ago
    D, Modula-3 and the Oberon family are two examples of value types by default with a GC enabled heap. Eiffel also offers value types (aka expanded), but it is reference by default.
pjmlp 11y ago
> This is why C/C++ is usually faster than managed languages, they can get close on generated code but can be off by a factor of 50x in memory access performance. This only happens because the Pascal branch of languages with GC, sadly failed in the mainstream (for several reasons). Modula-3, Eiffel, Oberon, Oberon-2, Component Pascal all offer the same data access patterns and packing available to C and C++.

pron 11y ago

> This is why C/C++ is usually faster than managed languages, they can get close on generated code but can be off by a factor of 50x in memory access performance. This is a common misconception that is a result of Java's current state. Control over memory layout and garbage collection are two completely orthogonal issues. At the moment, Java just happens to be both GCed and to afford little control over memory layout. Currently, the HotSpot team (HotSpot is the name of OpenJDK's JVM) is working on project Valhalla and project Panama, two efforts scheduled for Java 10 and intended to give the JVM all the memory layout control you need.

vvanders 11y ago
Not completely. Most GCs want to be able to compact the heap, that means they lean in favor of reference based models by default. It's not exclusive like you mention but to my knowledge C# is the only language with explicit guarantees. I was aware of the effort around Java's value types, however how long till we can reasonably see this in production? You can do this in Java today but it involves lots of nasty ByteBuffer manipulation(in which FlatBuffers is fantastic for). You'll still pay for the conversions from bytes to the actual types you want. If you're dealing with these types of performance problems it's best to treat them with a language that's well suited to deal with them. There's nothing wrong with using Java for higher level business logic and delegating the heavy lifting to a stack that's designed to deal with them.
- pron 11y ago
  > Most GCs want to be able to compact the heap, that means they lean in favor of reference based models by default. I don't see how this follows. Copying GCs do compact the heap, but when you use values you're basically saying "these two things go together". You're only making life easier for the GC (well, you're also creating larger objects, but that might just require a small adjustment of the GC strategy). > how long till we can reasonably see this in production? Four years probably... Still, that doesn't change the fact that layout and GCs are orthogonal.
- vvanders 11y ago
  Expanding on my point a bit, I'm not arguing that in theory GC and memory layout are orthogonal. Just that in practice you don't see memory layout in languages that are managed. Since I'm usually not in a habit of building a new languages to solve problems it's something worth understanding when making a technical selection on a language.
- pjmlp 11y ago
  D, Modula-3 and the Oberon family are two examples of value types by default with a GC enabled heap. Eiffel also offers value types (aka expanded), but it is reference by default.

pjmlp 11y ago

> This is why C/C++ is usually faster than managed languages, they can get close on generated code but can be off by a factor of 50x in memory access performance. This only happens because the Pascal branch of languages with GC, sadly failed in the mainstream (for several reasons). Modula-3, Eiffel, Oberon, Oberon-2, Component Pascal all offer the same data access patterns and packing available to C and C++.