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

What I Learned Making My Own JIT Language

mikedrivendevelopment.com

Post reply on HN
Print view View original

21–30 of 120 posts

Re: What I Learned Making My Own JIT Language

#21

Post by jerf »

pjmlp wrote: post #11
jerf wrote: post #4

Earlier quoted context omitted.

I would be intrigued to see a modern attempt at a dynamic language like Python or Ruby, but with attention paid from day one to ensure that only very JIT-able constructs were used, and with an eye towards the language helping the user stick to those and be aware of when they deviate, rather than designing a language, setting "runs fast" somewhere around the third or fourth priority, then trying to JIT it after 10-15…

I guess you mean Julia, or to pick three from the past Common Lisp, Dylan and Strongtalk.

Is Julia really a Python competitor, I mean, for the same sort of niches? I had the impression that it was more specialized than that. (Bearing in mind of course that once you're Turing Complete and have a C binding you can technically do anything. Not that either of those two is necessary, but they are sufficient.) But as my phrasing implies, it was just an impression, and two people have mentioned it now.

Common Lisp, well, I suppose I'll leave that up to the reader. Personally, I observe that in a context where dynamic languages are being discussed in a positive manner, Common Lisp is a dynamic language, but when static languages are being discussed in a positive manner, suddenly Common Lisp is a static language. (In fact, that pattern may hold in general; for any given programming individual language characteristic being positively discussed, Common Lisp will have it, no matter how contradictory the whole set may be.) Under the hood, it must resemble one or the other more strongly, but after years of consuming advocacy, heck if I know which.

Can't speak to the other two.

Re: What I Learned Making My Own JIT Language

#22

Post by kodablah »

jerf wrote: post #4
stcredzero wrote: post #2

Sure, there are things that can be "poison pills" for performance, even in JITs. For example, another reason why my fib benchmark beats V8 is that V8 has to continually check if the fib function was redefined as a deoptimization check. I don't allow that in Vaiven, so I can produce faster code. Dart was designed to have fewer of these poison pills, for instance. Note to language designers: Reduce your language's pois…

I would be intrigued to see a modern attempt at a dynamic language like Python or Ruby, but with attention paid from day one to ensure that only very JIT-able constructs were used, and with an eye towards the language helping the user stick to those and be aware of when they deviate, rather than designing a language, setting "runs fast" somewhere around the third or fourth priority, then trying to JIT it after 10-15…

> I would be intrigued to see a modern attempt at a dynamic language like Python or Ruby, but with attention paid from day one to ensure that only very JIT-able constructs were used

I think "unknown type at compile time" and "JIT-able constructs" are opposites. You'd end up with a tracing JIT that compiles the same set of code in different, specialized ways based on runtime determination of the the input types as though the lang was static. Which is basically what we have today. You can have optionally typed languages, but you still have to write your runtime and compiler to the lowest common denominator, so you probably want to go more strict if you care about your (runtime or compile-time) compiler and runtime performance (as the Dart devs learned IIRC).

I would assume "JIT-ability" is proportional to the immutable input and output knowledge of the code to be compiled.

Re: What I Learned Making My Own JIT Language

#23

Post by naasking »

jerf wrote: post #4
stcredzero wrote: post #2

Sure, there are things that can be "poison pills" for performance, even in JITs. For example, another reason why my fib benchmark beats V8 is that V8 has to continually check if the fib function was redefined as a deoptimization check. I don't allow that in Vaiven, so I can produce faster code. Dart was designed to have fewer of these poison pills, for instance. Note to language designers: Reduce your language's pois…

I would be intrigued to see a modern attempt at a dynamic language like Python or Ruby, but with attention paid from day one to ensure that only very JIT-able constructs were used, and with an eye towards the language helping the user stick to those and be aware of when they deviate, rather than designing a language, setting "runs fast" somewhere around the third or fourth priority, then trying to JIT it after 10-15…

Wren is kind of along these lines: http://wren.io/

Re: What I Learned Making My Own JIT Language

#25

Post by naasking »

kodablah wrote: post #22
jerf wrote: post #4

Earlier quoted context omitted.

I would be intrigued to see a modern attempt at a dynamic language like Python or Ruby, but with attention paid from day one to ensure that only very JIT-able constructs were used, and with an eye towards the language helping the user stick to those and be aware of when they deviate, rather than designing a language, setting "runs fast" somewhere around the third or fourth priority, then trying to JIT it after 10-15…

> I would be intrigued to see a modern attempt at a dynamic language like Python or Ruby, but with attention paid from day one to ensure that only very JIT-able constructs were used I think "unknown type at compile time" and "JIT-able constructs" are opposites. You'd end up with a tracing JIT that compiles the same set of code in different, specialized ways based on runtime determination of the the input types as tho…

> I think "unknown type at compile time" and "JIT-able constructs" are opposites.

Not opposites exactly. Types enforce a phase separation between compile time and runtime, but there's no reason you can't have a compilation phase at runtime too. This leads to staged programming, like MetaOCaml.

Re: What I Learned Making My Own JIT Language

#26

Post by tomcam »

filereaper wrote: post #5

PSA: If there are folks writing their own JIT languages (and are highly encouraged to do so) please also checkout out the Eclipse OMR project. OMR is a bunch pluggable runtime components (GC, JIT etc...) intended to ease building of runtimes from scratch. https://github.com/eclipse/omr

What an incredible resource. Thank you.

Re: What I Learned Making My Own JIT Language

#27

Post by kodablah »

naasking wrote: post #25
kodablah wrote: post #22

Earlier quoted context omitted.

> I would be intrigued to see a modern attempt at a dynamic language like Python or Ruby, but with attention paid from day one to ensure that only very JIT-able constructs were used I think "unknown type at compile time" and "JIT-able constructs" are opposites. You'd end up with a tracing JIT that compiles the same set of code in different, specialized ways based on runtime determination of the the input types as tho…

> I think "unknown type at compile time" and "JIT-able constructs" are opposites. Not opposites exactly. Types enforce a phase separation between compile time and runtime, but there's no reason you can't have a compilation phase at runtime too. This leads to staged programming, like MetaOCaml.

Well, to phrase it simply, in my mind a dynamic type is not a very JIT-able construct. I suppose it comes down to what people consider "very JIT-able", but I don't consider the same code possibly JIT'ing in separate ways in the same execution as very JIT-able.

Re: What I Learned Making My Own JIT Language

#28

Post by liveoneggs »

jerf wrote: post #4
stcredzero wrote: post #2

Sure, there are things that can be "poison pills" for performance, even in JITs. For example, another reason why my fib benchmark beats V8 is that V8 has to continually check if the fib function was redefined as a deoptimization check. I don't allow that in Vaiven, so I can produce faster code. Dart was designed to have fewer of these poison pills, for instance. Note to language designers: Reduce your language's pois…

I would be intrigued to see a modern attempt at a dynamic language like Python or Ruby, but with attention paid from day one to ensure that only very JIT-able constructs were used, and with an eye towards the language helping the user stick to those and be aware of when they deviate, rather than designing a language, setting "runs fast" somewhere around the third or fourth priority, then trying to JIT it after 10-15…

perl6 on MoarVM is starting to grow a JIT

Re: What I Learned Making My Own JIT Language

#29

Post by jcdavis »

mncharity wrote: post #7

A while back, it looked like v8 deopt type guards, for at least monomorphic call sites, were consistently ending up off of the processor speculative execution mainline. They were "free"-ish. Then speculative execution attacks and mitigations hit. Does anyone know the current state of play? I've wanted fast multiple dispatch in js for many years. V8's handling of inlining budgets improved, and guards seemed off mainli…

Not really familiar with v8 internals, aren't there ways to do deopts without relying on guards? The JVM deopts methods by hotpatching the start of them to be a jump to runtime handlers.

Re: What I Learned Making My Own JIT Language

#30

Post by PeCaN »

filereaper wrote: post #5

PSA: If there are folks writing their own JIT languages (and are highly encouraged to do so) please also checkout out the Eclipse OMR project. OMR is a bunch pluggable runtime components (GC, JIT etc...) intended to ease building of runtimes from scratch. https://github.com/eclipse/omr

OMR is amazing. It's essentially IBM's J9 virtual machine, with all the man-decades of effort that went into that.

However, if you're writing your own JIT language and you've never written one before, you probably want to learn something and write your own GC, JIT, etc. It's really not that hard. Then once you get an idea of how everything works you can use OMR and make it fast.

Post reply on HN