Optimisation: Remove PC param from opcode implementations

plasma-umass / doppio

Breaks the browser language barrier (includes a plugin-free JVM).

http://plasma-umass.github.io/doppio-demo

MIT License

2.16k stars 175 forks source link

Optimisation: Remove PC param from opcode implementations #437

Closed hrj closed 8 years ago

hrj commented 8 years ago

The PC param is required only by a few opcode implementations, and when required it can be easily retrieved from the frame parameter. This change gives a modest speed boost (1% to 2% reduction in compilation using javac).
There are couple of stacks in doppio. I renamed the operand stack to opStack for clarity.

jvilk commented 8 years ago

While 1% to 2% is within the noise of normal JavaScript engine execution, this change makes the bytecode a bit cleaner, so I'm OK with it.

jvilk commented 8 years ago

thanks!

hrj commented 8 years ago

While 1% to 2% is within the noise of normal JavaScript engine execution,

Indeed, there is a lot of noise, though I believe I have been getting better at benchmarking these days. I follow this process:

Set the linux CPU governor to performance. Other governors dynamically change the frequency of the CPU / move the thread to a different core based on load and temperature. Whereas the performance governor keeps all cores running at maximum frequency. This reduces the benchmark noise significantly.
Close all applications that have background threads in them, such as secondary browsers, email clients, etc. The only applications I run are Vim and a clean-profile browser with just one incognito tab open, in which I run the benchmark.

emeryberger commented 8 years ago

These are all fine suggestions for experimental evaluation when you are trying to distinguish signal from noise. However, in real settings, where users will be multitasking, etc., 1-2% is absolutely noise. You want any gains to be visible to users in real settings; otherwise, they literally do not matter. As a policy matter, @jvilk is 100% correct: it doesn't make sense to chase after minor gains if they come at the cost of increased code complexity / maintenance costs. Luckily, in this case, it's the opposite. Thanks!