[HN Gopher] Speculation in JavaScriptCore
___________________________________________________________________
Speculation in JavaScriptCore
Author : pizlonator
Score : 98 points
Date : 2020-07-29 17:04 UTC (5 hours ago)
(HTM) web link (webkit.org)
(TXT) w3m dump (webkit.org)
| om2 wrote:
| If you were ever curious how modern JavaScript VMs (or VMs for
| other dynamic languages) achieve high performance, this is an
| awesome resource. It explains tiers, the goals and design of
| different tiers, on stack replacement, profiling, speculation and
| more!
|
| JavaScript engines are the most advanced at this (only LuaJIT is
| even comparable), it would be awesome if Python, Perl, Ruby, PHP
| or the like aimed for the same level of performance tech.
| goatlover wrote:
| There is also Julia, which JITs very performant code.
| slaymaker1907 wrote:
| I think that Julia uses the LLVM JIT. When I used it last,
| Julia was somewhat prone to long startup delays since it
| would fully compile functions on first execution.
|
| That can work great for long running applications such as its
| main niche of scientific computing but would be terrible for
| JS since you want the page to be interactive ASAP.
|
| This is why talking about JIT performance is so complicated.
| Not only do you need to worry about compilation speed and
| speed of the generated code, you also have to worry about a
| lot about impact on memory and impact on concurrently running
| code. Plus most JITs also need to have some sort of profiling
| system running all the time as part of those constraints to
| only spend compilation resources on hot paths.
| pizlonator wrote:
| The difference between Julia and speculative compilers is
| that Julia is much more likely to have to compile things to
| run them. JSC compiles only a fraction of what it runs, the
| rest gets interpreted.
| om2 wrote:
| Modern JS engines have a multi-tier structure and profiling
| info that lets them choose what to JIT and which point on
| compile speed vs runtime speed tradeoff space to take for
| any given chunk of code. The post covers a lot of this.
| tyingq wrote:
| PHP has a JIT coming in 8.0, using the same underlying tech
| that LuaJit does. Unfortunately, most of what people do with
| PHP isn't CPU bound, so it doesn't help much.
| pizlonator wrote:
| And let's not forget HHVM. That was (is?) quite the beast.
| pastrami_panda wrote:
| > most of what people do with PHP isn't CPU bound
|
| ... cause it's I/O bound? Just curious.
| tyingq wrote:
| Yes, or just waiting on MySQL, for example.
|
| The JIT does dramatically speed up microbenchmarks like
| Mandlebrot, etc. 5x.
| pizlonator wrote:
| I feel like I can almost visualize the killshot slides that
| the HipHop and HHVM folks used to show the extent to which
| PHP can be CPU bound and the extent to which server idle
| time can be increased by using speculative compilation
| tricks on PHP.
|
| So, I think it is cpu bound for at least some people.
| tyingq wrote:
| Versus PHP5.x that's true. Mostly because the PHP
| internals were inefficient. The performance differences
| vs HHVM vanished with PHP 7.x.
| tambourine_man wrote:
| This could be a chicken and egg thing. As soon as JavaScript
| started to get faster, we started using it for more CPU
| intensive tasks, which in turn led to more investment in
| optimizations, and so on, in a virtuous circle.
| qaq wrote:
| Large entities are competing on browser performance "which
| in turn led to more investment in optimizations" part does
| not really ring true. We are just benefiting from browser
| market dynamics.
| 1337shadow wrote:
| Actually that's available for the Python language as well with
| PyPy.
| pizlonator wrote:
| The post gives PyPy a shout out. But it's subtle. PyPy is
| similar but not the same. I think that JSC's exact technique
| could be tried for Python and I don't believe it has.
| 1337shadow wrote:
| Maybe, I wish I had the occasion to deploy PyPy in
| production, but as a daily Python user since 2008: I never
| had to switch to PyPy to fix any performance problem that
| mattered for my users or me, but I keep an eye on PyPy and
| admire it as well as the developers behind it.
| om2 wrote:
| PyPy is faster than vanilla Python but it's not really
| built the same way as modern JavaScript engines and
| likely can't hit the same perf level.
| war1025 wrote:
| What is the current development status of Pypy? I haven't
| heard much about it in the past couple years.
| monocasa wrote:
| I'd say that the JVMs (particularly Azul's) are more advanced
| at this. Even with types, they sill speculate in order to
| inline across virtual method calls.
|
| But agreed that the amount of perf JS engines can achieve is
| truly impressive.
| pizlonator wrote:
| JSC speculates in order to inline across virtual method calls
| while also inferring types.
|
| Also inlining across virtual method calls is just old hat.
| See the post's related work section to learn some of the
| history. Most of the post is about techniques that are more
| involved that inlining and devirtualization.
| monocasa wrote:
| HotSpot is a fork of strongtalk, which did the same thing
| and in fact invented the techniques you're talking about
| (ie. creating fake backing types for untyped code and
| optimistically inlining those with bounces out to the
| interpreter on failures, perhaps keeeping several copies
| around and swapping out the entry in the inline cache).
|
| Additionally that functionality has been added to over time
| with the invokedynamic byte code and it's optimizations.
| pizlonator wrote:
| Invented some of the techniques in the post. Most of the
| post is about what's new. I cite the work that led up to
| strongtalk throughout the post.
| monocasa wrote:
| I read the article and don't see any examples of what
| hotspot doesn't do? What am I missing?
| pizlonator wrote:
| HotSpot has four tiers huh?
|
| That's just one snarky example. There are lots of others.
| I'm sure you could identify them easily, if you are
| familiar with HotSpot and you read the post.
| monocasa wrote:
| Last time I checked it had five tiers.
|
| Like, really one non snarky example is all I'm looking
| for. As someone who does know the internals of hotspot
| fairly well and read the post.
| pizlonator wrote:
| JSC has four in the sense that hot enough functions go
| through LLInt, then Baseline, then DFG, and then FTL.
| They go through three lower optimization levels before
| the max one.
|
| HotSpot has three in the sense that you get interpreter,
| client, then server.
|
| Both VMs have additional execution engines available
| behind flags. JSC has a different interpreter (CLoop,
| based on LLInt but different) for some systems, so it's
| like a "fifth tier" if you think of "tier" as just an
| available execution engine. I think of tier as a stage of
| optimization that you get adaptively, without having to
| specifically configure for it. I get that HotSpot can
| alternatively AOT or Graal, but those aren't tiered with
| the rest to my knowledge (like there is no
| interpreter->client->server->graal config but if there
| was then that would be four tiers).
| monocasa wrote:
| HotSpot definitely uses five tiers (including the
| interpreter, so same as JSC).
|
| https://github.com/openjdk/jdk/blob/0aefe6f20ae719c9793c7
| 90d...
|
| I'll give you that levels 1-3 use the same IR, but that
| says more about the generality of the C1 IR than JSC
| being more advanced for using different IRs IMO.
| chrisseaton wrote:
| I don't think it's reasonable to describe those as five
| independent tiers. Two of them just add (slower) code to
| collect profiling information.
| pizlonator wrote:
| Anyway, this is silly. The post cites HotSpot and it's
| predecessors. It's just not the case that we repeat their
| technique, and number of tiers is a snarky difference and
| not the real one. I'm not going to give you a TL;DR that
| enumerates the meaningful differences just because you
| claimed that there aren't any.
| pizlonator wrote:
| According to that, it skips level 1 and goes all the way
| to 3 in some cases.
|
| Again, not the same as what JSC does, and not nearly as
| aggressive. Most notably, there is no baseline jit. Also,
| C1 in any config compiles slower than DFG.
| hugomg wrote:
| I always love reading more about JavaScriptCore internals
| although I have to confess that much of the time one of the main
| lessons I get from it is that life would be much easier if we had
| types and didn't need to speculate so much in the first place.
| pizlonator wrote:
| Not having types is a virtue for the web, where interfaces can
| change in weird ways. Dynamism leads the engine and the JS code
| to be less tightly coupled. So, there's more wiggle room for
| evolution in the engine and more wiggle room for portability
| defenses in JS.
|
| So, it just depends on how important the benefits of dynamic
| types are versus the benefits of static types. I don't think
| static types of dynamic types are better; they are just good at
| different things.
| jolux wrote:
| There are still ways to program to unstable interfaces in
| static languages though, and they tend to be safer overall
| because they are isolated from the rest of the language.
| hugomg wrote:
| It wouldn't be the JS we know and love if it had been
| burdened with a type system designed by a committee sometime
| in the 90s. That said, one thing we can say for sure is that
| the dynamic typing doesn't make your job any easier :)
| chrisseaton wrote:
| You may want to speculate even when you have precise
| concrete types.
|
| For example your type system may tell you have you have an
| int32, but you can speculate that only the lowest bit is
| ever set, with a kind of synthetic type you could call
| int32&0x1 which isn't expressable in the type system the
| user uses.
|
| > dynamic typing doesn't make your job any easier
|
| Yeah, it makes millions of application programmers' jobs
| easier at the expense of a small group of experts - sounds
| like the right tradeoff?
___________________________________________________________________
(page generated 2020-07-29 23:01 UTC)