[lmm]

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

[kjeetgill]

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.

[shub]

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

[samatman]

I made this case in 2013.

Tlon didn't want to hear it.