The Black Cat of Microbenchmarks | Hacker News Reader

The Black Cat of Microbenchmarks

mrale.ph

52 pointsluu5 comments

This was written in 2014, when Crankshaft was still the JIT in V8. Turbofan was shipped in late 2016 and made primary in 2017. It's a much better JIT - it is tolerant to many more code patterns, including ES6 features - but IRHydra2 no longer works with Turbofan, so this type of introspection is more difficult to do.

A few years ago I hand-tuned some kdb+/q interop code on Crankshaft using IRHydra2 and d8. The results were impressive: about 10x by just shuffling code around to be friendlier to the JIT. It was fun, but more than a little mysterious.

Tuning on Crankshaft was all about avoiding bailout (https://github.com/vhf/v8-bailout-reasons/blob/master/README...). Tuning for Turbofan is less about "gotchas" and more about making sure your functions don't go megamorphic. Using TypeScript or Flow helps you do this just to get your code to typecheck anyway so it's a good habit.

As mentioned in this comment (https://news.ycombinator.com/item?id=15067462) there is still some minor analysis of the IR possible in IRHydra2 on TurboFan.

Was about to post this. In addition dead-code elimination is (still) disabled in V8 as far as I know and it's not that big of a deal anymore.

TurboFan IR (and Turbofan in general) is way simpler and more readable than Crankshaft. Figuring out what's optimized and how is easy with the CodeStubAssembler. I remember nights of head-scratching with CrankShaft :D

> dead-code elimination is (still) disabled in V8

How can you disable dead-code elimination in a graphical IR? I would have thought it was implicit?

I just checked the code - it is explicit (there is literally a file called dead-code-elimination.cc that shows the reductions) and it's turned on and it's added in pipeline.cc :)

So apparently it's been turned on for a while now which is good (it was off for a while before that).

Are their alternatives to IRHydra2 that work now (or indeed on different JS engines)?

I generally code with an attitude of "a sufficiently-smart-optimizer should understand this", but it's clear that in a lot of cases writing ugly code can be more performant.

I would actually be more interested in highlighting opportunities for engine improvement over just making a particular piece of my code faster.

Reply on news.ycombinator.com