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

61–70 of 120 posts

Re: What I Learned Making My Own JIT Language

#61

Post by batmansmk »

arghwhat wrote: post #18
amelius wrote: post #13

Earlier quoted context omitted.

Isn't there some kind of static analysis possible for such cases?

JavaScript is too dynamic for such analysis. JavaScript at its core is not a very well designed language, and it's a bloody miracle that a JIT can make it usable. If you're designing a new language, don't make everything (even arrays!) a hashmap.

Hmm, looking at the source code, you are partially correct. https://github.com/v8/v8/tree/master/src/objects

I can see at least 10 types which are not hash maps. Including all the flavors of Typed Arrays.

Re: What I Learned Making My Own JIT Language

#62

Post by jamestimmins »

sigjuice wrote: post #35

Title should say 'JIT compiler'.

Is it not fair to say that this is the same thing? My impression was that in designing a compiler you're explicitly determining the rules for language, which is the same as designing the language itself? Or do you mean that technically the compiler, not the language, is JIT?

This is a new area for me so apologies if I'm just misunderstanding the mechanics here!

Re: What I Learned Making My Own JIT Language

#63

Post by ummonk »

Sawamara wrote: post #55
arghwhat wrote: post #41

Earlier quoted context omitted.

I would certainly say "no" to having your basic array type be a hashmap as a hashmap is several orders of magnitude slower than an array for all operations on small arrays and for access for all sizes, although there is nothing wrong with also having hashmap and linked list collections if you need O(1) inserts. However, what I was referring to is much worse than that: JavaScript arrays are defined as a normal hashmap…

You say all this as if JS's jit engines (V8, chakra, spidermokey, etc) did not destroy "better designed" languages when it comes to speed and efficiency. The only dynamic language that does not pale beyond what is achieved with V8 is LuaJIT.

How many "better designed" dynamic languages are there even out there? Julia is one such language and is substantially faster than V8, at least for idiomatic code.

The problem is that most dynamic languages (like JS) are never designed with speed and efficiency in mind. JS just happens to be the fastest of that bunch (other than Lua) because browser makers have invested substantial effort into making it fast - far more than anyone has put into other dynamic languages.

Re: What I Learned Making My Own JIT Language

#64

Post by jtolmar »

arghwhat wrote: post #37
white-flame wrote: post #34

Earlier quoted context omitted.

I say screw deoptimization checks, and put the burden in the redefinition processing. When you redefine something, you stop the world at safepoints and update prior baked assumptions that are registered on the old definition. These redefinitions usually happen during development and initialization, not during performance-sensitive runtime. It would add more to the memory footprint, but that information is not accesse…

Then you either need to have "redefinition" checks, or an actual, full stop the world, which is also a performance nightmare and also affects unrelated code. The proper solution is to not have unnecessary dynamics. There is no need for the ability to redefine methods on an object. If you have functions as first-class objects, you can just let users store functions and call them at the cost of indirection if they wish…

How about a language that loses the ability to redefine structures and methods after a certain point?

I've been thinking of making a scripting language where you can freely redefine things until you return the main function to the script's caller. At that point main gets compiled / JITed / otherwise locked and any redefinitions done by calling it are errors.

Re: What I Learned Making My Own JIT Language

#65

Post by taeric »

Sawamara wrote: post #55
arghwhat wrote: post #41

Earlier quoted context omitted.

I would certainly say "no" to having your basic array type be a hashmap as a hashmap is several orders of magnitude slower than an array for all operations on small arrays and for access for all sizes, although there is nothing wrong with also having hashmap and linked list collections if you need O(1) inserts. However, what I was referring to is much worse than that: JavaScript arrays are defined as a normal hashmap…

You say all this as if JS's jit engines (V8, chakra, spidermokey, etc) did not destroy "better designed" languages when it comes to speed and efficiency. The only dynamic language that does not pale beyond what is achieved with V8 is LuaJIT.

I'm curious what your claim is. The evidence here is primarily that engineering effort can provide massive benefits to runtime speed. This is not that controversial, I believe. It can feel disappointing, but there is no reason for it to. The people working on those engines are putting a ton of solid effort into it. They deserve the recognition they have gotten.

This in no way argues against some other languages being better designed for performance. Indeed, many other languages are better designed for performance. The designers should get recognition for the contributions they have made, as well.

Again, though, it can sound like disappointment that we can't get both teams working together. I contend that is short sighted. Yes, we can imagine a world where they worked together to make even better things. However, don't let that imagined world stop any communication on the front lines that we have today. (That make sense?)

Re: What I Learned Making My Own JIT Language

#66

Post by Sawamara »

ummonk wrote: post #63
Sawamara wrote: post #55

Earlier quoted context omitted.

You say all this as if JS's jit engines (V8, chakra, spidermokey, etc) did not destroy "better designed" languages when it comes to speed and efficiency. The only dynamic language that does not pale beyond what is achieved with V8 is LuaJIT.

How many "better designed" dynamic languages are there even out there? Julia is one such language and is substantially faster than V8, at least for idiomatic code. The problem is that most dynamic languages (like JS) are never designed with speed and efficiency in mind. JS just happens to be the fastest of that bunch (other than Lua) because browser makers have invested substantial effort into making it fast - far mo…

Usual suspects that many people who hate JS seem to champion are are python, lua, ruby.

I love Lua personally, but it has its own traps too. Never could get into Python too much, the indentation syntax is killing me :P

Re: What I Learned Making My Own JIT Language

#67

Post by stcredzero »

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…

what if you could do something like the "pledge()" call that says "OK, this is it, I'm all set up, the dynamism is all done

Someone did a study of their Python servers, and found that after an initial phase, almost no dynamic facilities were used at all!

it seems to me that it would also be feasible to go the other way, and allow users to define things as structs, and if you want to offer hash-like access it would be easy to lay down hash-like access to the struct members

I like that. Smalltalk kind of did this, but much less. Objects were just arrays of object references, but certain object references were adorned smallint values. People also wrote hash-like accessor implementations for objects. "Shape changes" to objects of a certain class would require a stop the world re-allocation of all such objects, however.

Re: What I Learned Making My Own JIT Language

#68

Post by white-flame »

jtolmar wrote: post #64
arghwhat wrote: post #37

Earlier quoted context omitted.

Then you either need to have "redefinition" checks, or an actual, full stop the world, which is also a performance nightmare and also affects unrelated code. The proper solution is to not have unnecessary dynamics. There is no need for the ability to redefine methods on an object. If you have functions as first-class objects, you can just let users store functions and call them at the cost of indirection if they wish…

How about a language that loses the ability to redefine structures and methods after a certain point? I've been thinking of making a scripting language where you can freely redefine things until you return the main function to the script's caller. At that point main gets compiled / JITed / otherwise locked and any redefinitions done by calling it are errors.

Or even just a manual bake() call, with an expensive unbake() to use during development (or maybe even deployed if it's that reconfigurable). But I do agree that a tool like this should affect the global environment and not try to be fine grained. Leave any fine-grained decisions up to the VM itself.

Re: What I Learned Making My Own JIT Language

#69

Post by qznc »

PeCaN wrote: post #30
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.

How does it compare to PyPy?

Re: What I Learned Making My Own JIT Language

#70

Post by bjoli »

gameswithgo wrote: post #36
TomMarius wrote: post #3

Earlier quoted context omitted.

Is there a list of common language poison pills? I'd like to learn more.

a JIT is one! time is wasted doing compiling while running, the compiler has strict time constraints so can't do as many optimizations, claims about theoretical benefits from runtime data collection and-recompilation for optimization are rarely reazlied in the actual world and profile guided optimizations can achieve similar things for AOT compiled programs. soooooooooooo AOT master race

As someone who has ported racket's for loops to guile scheme (or at least, re-implemented them without looking at the source of the original racket macros), a JIT has several benefits. There are some things that you just can't know at compile time, and hot paths/inline caches solve a lot of those things.

for example (for/list ([a (in-range a b c)]) (+ a 100)). Since in-range has to check when to end the loop, it has to know whether the loop goes in negative or positive direction (ie: to check the loop using ). If the values of a b c isn't known at compile time, the comparator has to be checked for each loop. This can potentially be very expensive, especially in an inner loop.

There are loads of optimizations that can be done much more efficiently/easily by a JIT. Store sinking, store/load forwarding, array bounds check elimination, value-range propagation and hyperblock scheduling to name a few.

LuaJIT is still the fastest dynamic language out there, but the complexity of the codebase surely makes you wish that wasn't the case.

Post reply on HN