News for hackers. Stuff that matters.
Re:JEP Draft: Deprecate memory-access methods in sun.misc.un... by kaba0 on Wednesday January 17, 2024 @01:43AM (#39024083)
Do we know why is that? I would assume the branch predictor is mostly happy with it, is it just the code cache increase?
Re:JEP Draft: Deprecate memory-access methods in sun.misc.un... by iscoelho on Wednesday January 17, 2024 @03:38AM (#39024982)
Perf impact due to bounds checks can be experienced in statically compiled languages as well (like Go/Rust). Although branch predictor improvements likely narrow the gap, they do not eliminate it.

Code cache is not completely relevant afaik - you can easily replicate in micro-benchmarks.

Re:JEP Draft: Deprecate memory-access methods in sun.misc.un... by kaba0 on Wednesday January 17, 2024 @03:56AM (#39025152)
> statically compiled languages

I don’t think it’s relevant here, the JIT compiler can do the same optimizations here.

If the branch predictor can basically 100% guess correctly (which will be the case in any correct program), it should not have any additional cost, besides taking up place in i$, so I would assume that that is responsible for the difference.

Re:JEP Draft: Deprecate memory-access methods in sun.misc.un... by iscoelho on Wednesday January 17, 2024 @04:09AM (#39025263)
> I don’t think it’s relevant here, the JIT compiler can do the same optimizations here.

Correct. I was clarifying that the issue can be replicated in a "simpler" statically compiled benchmark.

> If the branch predictor can basically 100% guess correctly (which will be the case in any correct program), it should not have any additional cost

That isn't true. The CPU branch predictor has a cost no-matter what. Of course, it's a complicated story: https://blog.cloudflare.com/branch-predictor

Re:JEP Draft: Deprecate memory-access methods in sun.misc.un... by kaba0 on Wednesday January 17, 2024 @04:48AM (#39025603)
Thanks! I definitely have to do some readup on that!