Hacker News Reader

Comment by kjeetgill | Hacker News Reader

This is already a standard piece of how JITs work today. See the discussion of Java intrinsics and Array.fill() here [0].

> An intrinsic function is applied as a method substitution [...] and the compiler will replace it's apparent source-level implementation with a pre-cooked implementation. In some cases intrinsics are sort of compilation cheats [...]

> The intrinsics are all set up in vmSymbols.hpp and if you look, you'll see Arrays.fill is NOT on the list. [...] Because it is something like an intrinsic... [...] What is it then? Arrays.fill is a code pattern substitution kind of compiler shortcut, basically looking for this kind of loop:

``` for (int i = 0; i < arrayB.length; i++) { arrayB[i] = b; } ```

And replacing it with a call into the JVM memset implementation.

[0]: http://psy-lob-saw.blogspot.com/2015/04/on-arraysfill-intrin...

View on HN

That has bugged me since the first time I read about Nock. JITs use intrinsics to work around inefficiency of generated code when the maintenance burden of the intrinsic is worth the performance boost, and the grand plan is to make a VM so terrible that you need a shitload of intrinsics for programs to terminate before the heat death of the universe? Years later I still haven't gotten past that initial bafflement. It just makes no sense at all.

Have you taken a math course at any point in your life?

> JITs use intrinsics to work around inefficiency of generated code when the maintenance burden of the intrinsic is worth the performance boost, and the grand plan is to make a VM so terrible that you need a shitload of intrinsics for programs to terminate before the heat death of the universe?

Put it this way: the JVM is perhaps the most sophisticated JIT on the planet, maybe a million lines of code, the product of decades of programming research and billions of programmer-hours, and it still needs intrinsics to improve performance. So how about we skip the billions of programmer hours and just use lots of intrinsics?

I don't know if it's going to work, but it's interesting enough to be worth a try.

I'm baffled by your conclusion and that of your parent post.

> So how about we skip the billions of programmer hours and just use lots of intrinsics?

This is very nearly the equivalent of: Why don't we skip writing a compiler and just USE glibc?

My post was about the opportunity to forgo the use of an intrinsic and instead do pattern recognition as part of compilation. The point being that the "jet-like" pattern matching phase that exists in many compilers today, my example being from the hotspot JVM's JIT compiler, but GCC will match the for loop and INTRODUCE a call to memset too.

I was using "intrinsic" inappropriately, I think, to mean both substitution of method calls and substitution of bytecode patterns. Yeah, the JVM already does the second thing. It's not roses for them, either[0]. The thing that I've been looking for in all this discussion is acknowledgement that the JVM team has been doing this, has encountered engineering challenges to the point that they're willing to change javac to simplify a jet, and an explanation of how these weird VMs are so different that none of that matters and using a shitload of jets is perfectly fine.

[0] http://openjdk.java.net/jeps/280

I made this case in 2013.

Tlon didn't want to hear it.

I wanted a reminder of Nock, and looked for an example, but the first hit is the enourmous pile of hoops to jump through to make "decrement" work! https://urbit.org/docs/nock/example/

Reminds me of nothing so much as INTERCAL.

Reply on news.ycombinator.com