Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Value Classes Still Need Compiler Sympathy

johan-sjolen.github.io

Post reply on HN
Print view View original

41–50 of 51 posts

Re: Value Classes Still Need Compiler Sympathy

#41

Post by bjoli »

marginalia_nu wrote: post #17
dist-epoch wrote: post #2

Since being created, the Java pitch was "don't worry about low-level stuff like value/reference classes, a Sufficiently Smart Compiler will automatically pick the best option given your code and runtime profiling". What changed, why suddenly they adopt C++ features they explicitly excluded? https://wiki.c2.com/?SufficientlySmartCompiler

This was pretty much always wrong. Nobody writing performance critical code in Java trusts the compiler to magically figure things out, and the sort of code you arrive at if you want Java to go fast is generally unidiomatic.

that of course depends on what you mean by fast. Fast can mean "know how to make the job of the JIT easy" (which it does in many cases), but it can also mean "write C in Java" which is, arguably, worse than writing C in C.

Re: Value Classes Still Need Compiler Sympathy

#43

Post by dullcrisp »

I’m not sure I fully understand why the compiler can’t derive the specialized apply method in this case.

I guess I follow the technical reason that the interface doesn’t override the method so there can’t be a specialized version of it. But that’s only visible through reflection right? Not in the direct language semantics?

Re: Value Classes Still Need Compiler Sympathy

#44

Post by zbentley »

afdbcreid wrote: post #32
inigyou wrote: post #24

Earlier quoted context omitted.

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.

Re: Value Classes Still Need Compiler Sympathy

#45

Post by spockz »

inigyou wrote: post #37
spockz wrote: post #35

Earlier quoted context omitted.

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?

Re: Value Classes Still Need Compiler Sympathy

#46

Post by SkiFire13 »

inigyou wrote: post #24
SkiFire13 wrote: post #14

Earlier quoted context omitted.

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

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

Re: Value Classes Still Need Compiler Sympathy

#47

Post by DarkNova6 »

tsimionescu wrote: post #30
DarkNova6 wrote: post #9

Earlier quoted context omitted.

Yes, this was the idiom in the 90s, but Escape Analysis has not proven to be powerful enough to optimize away identity. And looking at all the edge-cases and possible data-races via tearing, declaring something as a value must be an explicit design decision that cannot be inferred by a compiler or optimizer alone.

Note that tearing is NOT a risk for value classes in Java - the JIT compiler is not allowed to optimize the layout of any value class that can tear on the current architecture (so, for any value class larger than 64 bits on x86-64).

The tradeoff being that tearing is what enables flattening. So if you truly want the best performance (cache lines etc.) you must enable it.

But whether your data’s integrity can be broken by such must be decided by the class author.

Re: Value Classes Still Need Compiler Sympathy

#48

Post by iam-da-author »

dullcrisp wrote: post #43

I’m not sure I fully understand why the compiler can’t derive the specialized apply method in this case. I guess I follow the technical reason that the interface doesn’t override the method so there can’t be a specialized version of it. But that’s only visible through reflection right? Not in the direct language semantics?

Hi, the author of the blog post here.

I think that your misunderstanding comes from the fact that you base your understanding in Java semantics, but we really need to deal with the JVM's semantics. Your suggestion only makes sense when:

a) All of the typing information is preserved across a whole build b) The build is entirely static, no new classes can be loaded

Both of these are at odds with how the JVM functions. First: We lose type parameters on compilation, so we only see that Frobber extends Fun, the type parameters are lost and its usages are converted to Object.

Second: The JVM loads code by lazily loading classfiles. All classfiles are independent, and more can be added to a system.

Re: Value Classes Still Need Compiler Sympathy

#49

Post by tsimionescu »

DarkNova6 wrote: post #47
tsimionescu wrote: post #30

Earlier quoted context omitted.

Note that tearing is NOT a risk for value classes in Java - the JIT compiler is not allowed to optimize the layout of any value class that can tear on the current architecture (so, for any value class larger than 64 bits on x86-64).

The tradeoff being that tearing is what enables flattening. So if you truly want the best performance (cache lines etc.) you must enable it. But whether your data’s integrity can be broken by such must be decided by the class author.

> The tradeoff being that tearing is what enables flattening.

Yes, exactly.

> So if you truly want the best performance (cache lines etc.) you must enable it.

Someone was saying that this is planned as an option in some future version of Java. As it stands, this is just not possible, and to me this suggests that the performance gains from Project Valhalla in this Java will be minimal.

Re: Value Classes Still Need Compiler Sympathy

#50

Post by dullcrisp »

iam-da-author wrote: post #48
dullcrisp wrote: post #43

I’m not sure I fully understand why the compiler can’t derive the specialized apply method in this case. I guess I follow the technical reason that the interface doesn’t override the method so there can’t be a specialized version of it. But that’s only visible through reflection right? Not in the direct language semantics?

Hi, the author of the blog post here. I think that your misunderstanding comes from the fact that you base your understanding in Java semantics, but we really need to deal with the JVM's semantics. Your suggestion only makes sense when: a) All of the typing information is preserved across a whole build b) The build is entirely static, no new classes can be loaded Both of these are at odds with how the JVM functions.…

Thanks for responding. I think that makes sense. I’m definitely thinking of it from a language semantics perspective and this is a case where type erasure feels particularly counterintuitive to me.

Would including the specialized method in the derived interface bytecode preemptively take us all the way to C++ templates and ruin everything that’s good about Java? Or is it a matter of type erasure being consistently applied and if it were ignored selectively it would make everything more confusing?

Like if we had final class Foo implements Func then we’d presumably need to supply a typed implementation of apply, so the fact that we can get away with the generic one in a specialized interface feels surprising, even though I can see why it’s technically correct.

Post reply on HN