8 ms·

>What changed, why suddenly they adopt C++ features they explicitly excluded? Project Valhalla, which includes the effort to add value types was announced in 2

by jasode 24d ago

>What changed, why suddenly they adopt C++ features they explicitly excluded? Project Valhalla, which includes the effort to add value types was announced in 2014. They've been working on it for a while. As for "what changed" ... Back in 1990s when Java was conceived, there was an idea that CPUs in desktops had plenty of extra cycles that were being wasted and could therefore be used to reduce mental load on developers. It was the same "cpus are cheaper than developers" idea that is repeated today with "tokens/cpu are cheaper than developers". With that philosophy, James Gosling talked about Java's "everything-is-an-object" as a mental simplification for developers. All the extra indirections of pointer-chasing to box unbox primitives and/or iterate through arrays of objects wasn't seen as a penalty (again, "CPUs are cheap; devs are expensive"). However, the later evolution in 2000s of CPU hardware vs RAM hardware changed that performance tradeoff thesis: https://en.wikipedia.org/wiki/Random-access_memory#Memory_wall https://en.wikipedia.org/wiki/Random-access_memory#Memory_wa... Now having value types that are contiguous in RAM is a big deal for performance. Avoid a bunch of pointer chasing. Even C++ best practices were affected. E.g. the traditional tradeoffs you learned from from classroom textbooks of linked-lists being faster than arrays for middle-of-list insertions was no longer always correct in the new world where CPUs are caching adjacent RAM areas to try to reduce the memory wall issue. So O(n) could be faster than O(log n) depending on the size of the data structure and interactions with RAM pre-fetch, etc.

SkiFire13 24d ago
> So O(n) could be faster than O(log n) depending on the size of the data structure and interactions with RAM pre-fetch, etc. This has always been the case. The RAM effects only changed at which point the O(n) stops being faster than the O(log n) solution.
- inigyou 24d ago
  Apparently linear search now beats hashmap if you have less than TWO HUNDRED elements. Crazy!
  - afdbcreid 24d ago
    But when you compare native integers, not something more complicated, right?
    - zbentley 23d ago
      Depends. Are you searching for the complicated thing by identity, or in a system that caches identities and/or interns objects of the type you’re handling? All Of those can result in searches being word-based and thus vectorizable/cache-sympathetic more often.
  - spockz 24d ago
    So now the result of `new HashMap<>()` should be backed by an array for the first 200 elements or so? Potentially the size depending on the L1 size etc.
    - inigyou 24d ago
      Not in Java, because a linear search map in Java means traversing over 100 (on average) pointers.
      - spockz 23d ago
        Right, but not once these records/structs/value types arrive anymore I gather. Does this also mean we need to worry about word aligning our fields?? What about strings?
  - SkiFire13 23d ago
    For which key types, hashmap implementation, and hasher? Depending on these factors hashmaps performance can vary a lot.
stuaxo 24d ago
https://openjdk.org/projects/valhalla/design-notes/state-of-valhalla/01-background https://openjdk.org/projects/valhalla/design-notes/state-of-... > Project Valhalla got its start in 2014, with the goal of bringing more flexible flattened data types to JVM-based languages, in order to restore alignment between the programming model and the performance characteristics of modern hardware. (In some ways, it got started much earlier; the designers of Java wanted to include value types in the initial version of the language.)
PaulHoule 24d ago
The 1990s were the peak of "you will be able to buy a better computer in a year and a half" and "the cost of computing power is going down rapidly" and, for me, the 2010s were the decade where you couldn't sell specialist VCs on any non-columnar query engine because they were all impressed by mechanical sympathy, more so than the mainstream programmer. Today we're in the age where we can't count on your next computer being faster than your current computer or being more affordable, so the trade-offs look quite different -- it is feeling more like the 1980s where the Apple ][ line lasted almost a decade longer than Apple expected with (mainly) minor improvements in performance.

by jasode 24d ago

SkiFire13 24d ago

> So O(n) could be faster than O(log n) depending on the size of the data structure and interactions with RAM pre-fetch, etc. This has always been the case. The RAM effects only changed at which point the O(n) stops being faster than the O(log n) solution.

inigyou 24d ago
Apparently linear search now beats hashmap if you have less than TWO HUNDRED elements. Crazy!
- afdbcreid 24d ago
  But when you compare native integers, not something more complicated, right?
  - zbentley 23d ago
    Depends. Are you searching for the complicated thing by identity, or in a system that caches identities and/or interns objects of the type you’re handling? All Of those can result in searches being word-based and thus vectorizable/cache-sympathetic more often.
- spockz 24d ago
  So now the result of `new HashMap<>()` should be backed by an array for the first 200 elements or so? Potentially the size depending on the L1 size etc.
  - inigyou 24d ago
    Not in Java, because a linear search map in Java means traversing over 100 (on average) pointers.
    - spockz 23d ago
      Right, but not once these records/structs/value types arrive anymore I gather. Does this also mean we need to worry about word aligning our fields?? What about strings?
- SkiFire13 23d ago
  For which key types, hashmap implementation, and hasher? Depending on these factors hashmaps performance can vary a lot.

stuaxo 24d ago

https://openjdk.org/projects/valhalla/design-notes/state-of-valhalla/01-background https://openjdk.org/projects/valhalla/design-notes/state-of-... > Project Valhalla got its start in 2014, with the goal of bringing more flexible flattened data types to JVM-based languages, in order to restore alignment between the programming model and the performance characteristics of modern hardware. (In some ways, it got started much earlier; the designers of Java wanted to include value types in the initial version of the language.)

PaulHoule 24d ago

The 1990s were the peak of "you will be able to buy a better computer in a year and a half" and "the cost of computing power is going down rapidly" and, for me, the 2010s were the decade where you couldn't sell specialist VCs on any non-columnar query engine because they were all impressed by mechanical sympathy, more so than the mainstream programmer. Today we're in the age where we can't count on your next computer being faster than your current computer or being more affordable, so the trade-offs look quite different -- it is feeling more like the 1980s where the Apple ][ line lasted almost a decade longer than Apple expected with (mainly) minor improvements in performance.