4 ms·

Looks like a fun project. One thing i'd be interested in, is if it's slower than using javac, given that the JIT can optimize common idioms that the compiler sp

by mbfg 4y ago

Looks like a fun project. One thing i'd be interested in, is if it's slower than using javac, given that the JIT can optimize common idioms that the compiler spits out. For instance, for some JITs, in the past anyway, This code int myNumber = getANumber(); String s = "" + myNumber; was faster to run than int myNumber = getANumber(); String s= String.valueOf(myNumber); even though the bytecode for the second bit of code is a proper subset of the first. (Meaning the first section had all the byte code of the second, plus some extra stuff.) And yet the first ran faster than the second. So unless you've got some spectacularly tricky algorithm that you can naturally express in java, and can in jasm, i'm betting the javac output will be as fast or faster. Again tho, i'm not criticizing the author for doing this project at all. Kudos!

pvg 4y ago
The purpose of this thing isn't really performance but fun and exploration, if I'm reading the author's comments right. For examples like yours though, between the static analysis done by the compiler, whatever the JIT does and intrinsics, you can't readily predict what's going to run faster by looking at the Java code or the bytecode. These days, a much broader range of things that are equivalent-looking end up performing the same once the JIT gets involved, including stuff that seems to be naively doing allocations in inner loops. There's a whole genre of SO questions and answers that boil down to throwing a micro-example like yours into JMH and finding out they have identical performance profiles.
noone_youknow 4y ago
Oh yeah, totally. As another reply mentions, this isn't about performance - by this point Javac is most likely doing the best thing possible (especially given the knowledge of hotspot and intrinsics that are built in to it). I kind of hint at this in the readme :) That said, this doesn't _have_ to be any slower than Javac - in fact I recommend looking at the disassembly of classes compiled with Javac to see how things work under the hood :)

by mbfg 4y ago

pvg 4y ago

The purpose of this thing isn't really performance but fun and exploration, if I'm reading the author's comments right. For examples like yours though, between the static analysis done by the compiler, whatever the JIT does and intrinsics, you can't readily predict what's going to run faster by looking at the Java code or the bytecode. These days, a much broader range of things that are equivalent-looking end up performing the same once the JIT gets involved, including stuff that seems to be naively doing allocations in inner loops. There's a whole genre of SO questions and answers that boil down to throwing a micro-example like yours into JMH and finding out they have identical performance profiles.

noone_youknow 4y ago

Oh yeah, totally. As another reply mentions, this isn't about performance - by this point Javac is most likely doing the best thing possible (especially given the knowledge of hotspot and intrinsics that are built in to it). I kind of hint at this in the readme :) That said, this doesn't _have_ to be any slower than Javac - in fact I recommend looking at the disassembly of classes compiled with Javac to see how things work under the hood :)