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

HolyJit: A New Hope

blog.mozilla.org

Post reply on HN
Print view View original

171–180 of 219 posts

Re: HolyJit: A New Hope

#171

Post by kannanvijayan »

DannyBee wrote: post #165
kannanvijayan wrote: post #140

Earlier quoted context omitted.

The state of the art in jit compilation has advanced quite a bit since then, and another difference between the days of old and new is that this is being targeted at runtime code generation, which naturally trades off throughput of generated code for speed-of-generation. Especially for web pages, speed-of-generation, and the stability of the resulting code under polymorphism (so that jitcode with type assumptions doe…

"The state of the art in jit compilation has advanced quite a bit since then" Since when? Since the 70's? Sure. But since the 90's, not really in terms of techniques, only in terms of engineering and feasibility of advanced techniques. It's not that there is no research, mind you, but it's definitely more engineering than research. That also doesn't make it any less cool, exciting, etc. "another difference between th…

> This actually was true then too, FWIW.

Ah, you were referring to a era before my time, and it seems I made some false assumptions about motivations back then. Thanks for the correction.

> But since the 90's, not really in terms of techniques, only in terms of engineering and feasibility of advanced techniques. It's not that there is no research, mind you, but it's definitely more engineering than research. That also doesn't make it any less cool, exciting, etc.

Are you referring to meta-compilation techniques here, or the techniques for runtime type modeling developed to drive type-specialization of dynamic code?

If you are referring to the latter, I agree completely. If the former, I'd argue that the runtime type modeling work brings something new to the table which changes the dynamic. But in general I agree with your point - the main difference between now and then is the sheer level of engineering effort by multiple parties, cross-pollination of ideas, and other prosaic matters.

In terms of research, my exposure has been to two main pedigrees of thought in runtime type modeling serving to drive type-specialization of dynamic code: the Self work by Ungar and friends, and Type-Inference by Hackett and Guo (both of whom I have the pleasure of working closely with).

> While i'm not sure how much it matters, i guess i'd just point out these are not different concerns than history had

It always helps to understand the motivations and efforts of what came before, so thanks for the clarification. Any more insight or information or references would be welcome.

> I certainly hope you succeed, FWIW.

This is nbp's baby, but yeah, I hope it succeeds as well. I will never get bored of working in this space :)

Re: HolyJit: A New Hope

#172

Post by steveklabnik »

tbodt wrote: post #169
steveklabnik wrote: post #80

Earlier quoted context omitted.

Rustc does, but it doesn't appear to me that holyjit does, that is https://github.com/nbp/holyjit/blob/master/lib/src/compile.r... and https://github.com/nbp/holyjit/blob/master/lib/src/lib.rs#L1... Basically, it seems (and I haven't fully digested the code yet) that it uses https://crates.io/crates/dynasmrt for codegen.

Looks like dynasmrt was written for use in holyjit.

Quite possibly! It's the first I'm hearing of it. It's very interesting...

Re: HolyJit: A New Hope

#173

Post by DamonHD »

smitherfield wrote: post #170
DamonHD wrote: post #72

Earlier quoted context omitted.

What about just avoiding needless offence to people who happen to regard the 'holy' morpheme as indicative of ... well ... something holy and not to be trifled with. I don't have religion, but given an essentially infinite number of alternatives to this not-very-funny one, why do this? People also have a right to be idiots in other ways, such as poking hornets' nests because it's funny.

This is a good point, despite the downvotes. (Although, on the subject of avoiding offensive terminology, I'd perhaps have avoided the "people also have a right to be idiots" part). I've recently been reading Ogilvy on Advertising [1] by David Ogilvy, one of the most successful 20th-century figures in the industry, and while it's a bit dated (it was written 30 years ago) and, obviously, the subject matter is advertis…

Some good points, thank you.

I hear what you say about my use of "idiots", but someone stirring the sh*t (yes, I can use (light-to-full) industrial language too, in its place) without any need, casually and semi-deliberately offending (or worse) many many others, is I think behaving idiotically.

BTW on your point [2]: I am enraged when I observe people slandering two groups at once, casually: a direct target (A), by noting them as obviously as bad/gross/etc as assumed obvious horrible out-group (B). Gahhh!

Re: HolyJit: A New Hope

#174

Post by sctb »

bitL wrote: post #66

So Mozilla continues the tradition of terrible names in software engineering - HolySh*t is just wonderful. At least if they were as autistic as Terry and were inspired by HolyC...

This is not a civil comment by Hacker News' standards. Please don't post like this.

https://news.ycombinator.com/newsguidelines.html

Re: HolyJit: A New Hope

#175

Post by kibwen »

steveklabnik wrote: post #167
wyager wrote: post #164

Earlier quoted context omitted.

Are they using the generated IR, or using the AST of the interpreter code? The latter would probably be more amenable to JITification.

Rust has several layers of IR: AST -> HIR -> MIR -> LLVM IR This operates at the MIR layer. You can sort of think of MIR as "core Rust", in that it's the final, desugared form of everything. This is why the non-lexical lifetime stuff has taken a while; the precursor to that is "port the borrow checker to MIR". MIR/HIR are also fairly new; using MIR is only a year old.

> You can sort of think of MIR as "core Rust", in that it's the final, desugared form of everything.

Though I don't want anyone to get the impression that MIR is a source-compatible subset of Rust; it's a pretty different thing in its own right. (Worth clarifying because one could imagine a "fully-desugared" maximally-explicit subset of Rust, where e.g. all method calls are maximally disambiguated via UFCS, all types are explicitly annotated, no lifetimes are elided, all macros are expanded, etc.)

Re: HolyJit: A New Hope

#176

Post by bjt »

stefano wrote: post #128
DannyBee wrote: post #126

For those wondering, it's a specializer, applied to an interpreter, to specialize the interpreter into a jit. This is a pretty well explored technique, it's rarely done these days because historically, people could not get good enough performance. (I am not trying to knock them, just put it in context) For more context on how you'd do something like this, read this: https://en.wikipedia.org/wiki/Partial_evaluation#Fu…

Isn't this what pypy does? pypy does the specialization at runtime, maybe this does it at (interpreter) compile time?

It sounds very similar to what RPython and Pypy do. You can even use RPython to create a VM for a language besides Python. I read a good blog post from an author who had done that 5 years ago.

http://tratt.net/laurie/blog/entries/fast_enough_vms_in_fast...

Re: HolyJit: A New Hope

#177

Post by evincarofautumn »

ccozan wrote: post #96
glandium wrote: post #63

Earlier quoted context omitted.

FWIW, it's the current spelling in some languages (e.g. French).

Actually it is speculated that the the origin ist "Sang(re) Real" ( royal blood ) which metamorphosed into San Graal. Looking for it meant to search for the ( possible) lost blood line of Jesus, I think.

“According to the Catholic Encyclopedia this is a false etymology.” — https://en.wikipedia.org/wiki/Holy_Grail#Etymology

It’s been around for a while but was most recently popularised by Dan Brown in The Da Vinci Code.

Re: HolyJit: A New Hope

#179

Post by kibwen »

pjmlp wrote: post #151
hajile wrote: post #150

Earlier quoted context omitted.

Shipping an entire Java/ruby/python/whatever VM with your code doesn't make much sense (not to mention, wasm doesn't have a good GC story). Then there's the DOM API issue. If you aren't making games or crunching big numbers, wasm isn't for you yet. Even so, let's assume wasm added all those features today. History shows it would still be a decade before you could ship to all your users. That may not matter for fancy…

I don't remeber ARM, MIPS, x86 or x64 having a good GC history either. If WebAssembly is good enough as C and C++ target, it is good enough as any of those processors. As for the potencial of WebAssembly, there are already ongoing efforts to port .NET and Java runtimes to it, and I am looking forward to Adobe porting Flash to it as well. So it will come, WebAssembly + Canvas + WebGL is already quite usable.

> I don't remeber ARM, MIPS, x86 or x64 having a good GC history either.

Typical client programs intended to run on nascent versions of those architectures were not intended to be delivered and installed very often. In contrast, web pages might get changes deployed to production multiple times a day. Needing to deliver a compiled runtime solely in order to run your client side code is going to be a nonstarter for the overwhelming majority of developers.

Now, at best, we can hope that many developers will collaborate to make caching easier by agreeing to only use one specific version of each runtime, delivered from a single well-known source (though experience with e.g. jQuery means that we shouldn't hold our breath). In the meantime, extending WASM to obviate the need for delivered runtimes will even the field between Javascript and every other managed language.

Post reply on HN