8 ms·
The jump from change #5 to #6 (inline caches + hidden-class object model) doing the bulk of the work here really tracks with how V8/JSC got fast historically —
by jiusanzhou 5mo ago
The jump from change #5 to #6 (inline caches + hidden-class object model) doing the bulk of the work here really tracks with how V8/JSC got fast historically — dynamic dispatch on property access is where naive interpreters die, and everything else is kind of rounding error by comparison. Nice that it's laid out so you can see the contribution of each step in isolation; most perf writeups just show the final number.
- Someone 5mo agoI agree, but there’s a tiny caveat that this is for one specific benchmark that, I think, doesn’t reflect most real-world code. I’m basing that on the 1.6% improvement they got on speeding up sqrt. That surprised me, because, to get such an improvement, the benchmark must spend over 1.6% of its time in there, to start with. Looking in the git repo, it seems that did happen in the nbody simulation (https://github.com/pizlonator/zef/blob/master/ScriptBench/nbody.zef https://github.com/pizlonator/zef/blob/master/ScriptBench/nb...).
- pizlonator 5mo agoBefore that specialization, sqrt calls were hilariously slow - so even calling it sparingly could significantly impact performance. Basically the flow was: - check if we’re calling a method of an object - nope, ok, so cascade through 10+ symbol comparisons - sqrt was towards the bottom of the cascade
- jimmypk 5mo ago[flagged]