Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

V8: Firing Up the Ignition Interpreter

v8project.blogspot.com

Post reply on HN
Print view View original

11–19 of 19 posts

Re: V8: Firing Up the Ignition Interpreter

#11

Post by beagle3 »

So, V8 follows in the footsteps of LuaJIT:

LuaJIT2/newV8 optimized interpreter is as fast as LuaJIT1/oldV8 compiler. And to make it cross platform, it uses the LuaJIT/V8 macro assembler, rather than standard platform tools. (Although, LuaJIT2's macro assembler is architecture dependent and does much less than TurboFan's bytecode/macro assembler).

I suspect they'll realize at some point that the 20% or so interpretation speedup that you get from writing crucial parts of the interpreter in pure assembly is easier than specializing TurboFan to generate good interpreter code - see Mike Pall's explanations[0]

[0] - https://news.ycombinator.com/item?id=2588696 ; unfortunately, gmane appears to be gone, and I can't find another copy of the pointed to article.

Re: V8: Firing Up the Ignition Interpreter

#12

Post by natorion »

Klathmon wrote: post #3

I really recommend the video in the article for anyone that wants to learn about some V8 internals, how they got to this point, and where it is headed. They are replacing 3 JITs with an interpreter and a JIT which should improve speed, memory usage, and allow them to add new features faster, but the climb to that point really looks like a tough one. Watching that talk it really sounds like they painted themselves int…

That sums it up quite well.

Re: V8: Firing Up the Ignition Interpreter

#13

Post by natorion »

bodyfour wrote: post #4

What would be the killer feature for me would be if I could select an interpreter-only mode... ideally at either compile-time or run-time. The products I work on sometimes need to be deployed in environments where JIT code is disallowed due to security constraints. Now, I don't mind if my code runs dog-slow there, but it does still need to run. Some projects that use JIT techniques work well in this scenario. For exa…

V8 recently introduced the flag --minimal which only uses Ignition. The intention behind the flag is to bootstrap porting though.

Re: V8: Firing Up the Ignition Interpreter

#14

Post by mike_hearn »

Waterluvian wrote: post #10
bodyfour wrote: post #4

What would be the killer feature for me would be if I could select an interpreter-only mode... ideally at either compile-time or run-time. The products I work on sometimes need to be deployed in environments where JIT code is disallowed due to security constraints. Now, I don't mind if my code runs dog-slow there, but it does still need to run. Some projects that use JIT techniques work well in this scenario. For exa…

Disallowing JIT due to security. That's something I'd like to understand. What might I Google?

iOS devices do that.

Re: V8: Firing Up the Ignition Interpreter

#15

Post by mike_hearn »

beagle3 wrote: post #11

So, V8 follows in the footsteps of LuaJIT: LuaJIT2/newV8 optimized interpreter is as fast as LuaJIT1/oldV8 compiler. And to make it cross platform, it uses the LuaJIT/V8 macro assembler, rather than standard platform tools. (Although, LuaJIT2's macro assembler is architecture dependent and does much less than TurboFan's bytecode/macro assembler). I suspect they'll realize at some point that the 20% or so interpretati…

Not just LuaJIT but most heavily worked on VMs seem to converge to this point: it's basically the HotSpot architecture but with the source code compiler included and a register based bytecode instead of a stack based one. Oh, and two heavily optimising compilers instead of one. I guess they'll want to fix that. It was disappointing to hear that CrankShaft and Turbofan are both still in existence, I remember TurboFan being announced quite some time ago.

Re: V8: Firing Up the Ignition Interpreter

#16

Post by mike_hearn »

Klathmon wrote: post #3

I really recommend the video in the article for anyone that wants to learn about some V8 internals, how they got to this point, and where it is headed. They are replacing 3 JITs with an interpreter and a JIT which should improve speed, memory usage, and allow them to add new features faster, but the climb to that point really looks like a tough one. Watching that talk it really sounds like they painted themselves int…

Hm, well, as they say - they've actually now got two compilers even in the ideal case where they get rid of Crankshaft. Source to bytecode and then bytecode to machine code.

It does sound like there's a bit of a story behind V8's evolution here. I wonder when they'll try to standardise the bytecode they invented and introduce an extra protocol on top of HTTP to download it instead of source code. Seems like an obvious optimisation if compressed bytecode is more compact than compressed source (unclear if it would be), or maybe even if it's a bit larger if network speeds continue to improve and all the compile steps become the dominant factor in page load times.

Especially with WebAssembly it seems the whole web architecture is slowly winding its way back to the basic design of Java applets.

Re: V8: Firing Up the Ignition Interpreter

#17

Post by Klathmon »

bodyfour wrote: post #7
Klathmon wrote: post #5

Earlier quoted context omitted.

IIRC when they first announced Ignition, running in non-JIT environments was an explicit "non-goal". I don't think that they are against it, but i'm assuming nobody is really trying to get that to work, and I think some code is still JIT-ed during ignitions normal operating, so getting a "pure" interpreter might be much more work. Things might have changed since then, so someone with more up-to-date information will…

> so getting a "pure" interpreter might be much more work. If that's the case I'd have to take their word for it.. it's their code so they know the pitfalls. It still surprises me though: if I was developing a feature like that it would be the first thing I'd want to get working so I could try all of my test cases on interpeter-only mode. Maybe there are some types of code that the interpreter just can't handle and a…

I'm pretty sure they have a way to run in "Ignition only" mode, but Ignition still uses executable memory for some things, so an "Ignition only" mode is not a "JIT-free" mode.

Re: V8: Firing Up the Ignition Interpreter

#18

Post by fsfod »

beagle3 wrote: post #11

So, V8 follows in the footsteps of LuaJIT: LuaJIT2/newV8 optimized interpreter is as fast as LuaJIT1/oldV8 compiler. And to make it cross platform, it uses the LuaJIT/V8 macro assembler, rather than standard platform tools. (Although, LuaJIT2's macro assembler is architecture dependent and does much less than TurboFan's bytecode/macro assembler). I suspect they'll realize at some point that the 20% or so interpretati…

This seems to be the post it was referring to http://lua-users.org/lists/lua-l/2011-02/msg00742.html

Re: V8: Firing Up the Ignition Interpreter

#19

Post by bodyfour »

cpeterso wrote: post #9
bodyfour wrote: post #4

What would be the killer feature for me would be if I could select an interpreter-only mode... ideally at either compile-time or run-time. The products I work on sometimes need to be deployed in environments where JIT code is disallowed due to security constraints. Now, I don't mind if my code runs dog-slow there, but it does still need to run. Some projects that use JIT techniques work well in this scenario. For exa…

You can enable or disable SpiderMonkey's various JITs in Firefox's about:config prefs. Try disabling all the JIT prefs and running some JS benchmarks to measure interpreter-only mode. :) Each JIT level is roughly 10x faster on my machine. javascript.options.baselinejit controls the first-pass JIT. javascript.options.ion controls the IonMonkey optimizing JIT. javascript.options.asmjs controls the OdinMonkey asm.js JIT…

Yes last I checked you could still build firefox on platforms they didn't have a JIT for, so it certainly must be possible. Sadly, SpiderMoney isn't as commonly used for embedding compared to V8. Maybe Spidernode will take off in the node community and make it a more popular option... we'll see.

From watching the video it seems that Ignition is ~2x slower than JIT which sounds like great performance for a non-JIT'ed implementation.

Post reply on HN