Comment by jasode | Hacker News Reader

Comment by jasode | Hacker News Reader

Parent Full thread

>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_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.

> 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.

Apparently linear search now beats hashmap if you have less than TWO HUNDRED elements. Crazy!

But when you compare native integers, not something more complicated, right?

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.

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.

Not in Java, because a linear search map in Java means traversing over 100 (on average) pointers.

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?

For which key types, hashmap implementation, and hasher? Depending on these factors hashmaps performance can vary a lot.

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.

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.)

Reply on news.ycombinator.com