What I Learned Making My Own JIT Language • Hacker News Board

Re: What I Learned Making My Own JIT Language

#71

Post by corysama » Wed, Jun 27, 2018, 9:35 PM UTC

iTokio wrote: post #56

corysama wrote: post #24

I wish http://terralang.org got more attention. It’s a great way to write a jitting library. Add in LuaPEG and it’s a great way to write a jitting language.

Doesn’t it rely on llvm internally? That means that the jit path is slow to start and that your have a huge dependency.

terra.dll is 53 megs. Terra is really oriented around high performance computing, so if you want a quick little script, it's a bad fit. For small apps, it can still be useful as an ahead-of-time compiler to either a stand-alone executable or a C-linkable library.

Re: What I Learned Making My Own JIT Language

#72

Post by tigershark » Wed, Jun 27, 2018, 9:56 PM UTC

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…

It seems like an horribly expensive shenanigan to me. F# can do all the work that you described at compile time using type providers with no runtime cost and no need for a call to pledge()... What will happen if someone forgets to call pledge? Or, even worse, if someone calls pledge and then he does some other dynamic operation? Or if he calls pledge at the right time but one thread has been rescheduled and when it is executed again it will continue to issue dynamic instructions?

Re: What I Learned Making My Own JIT Language

#73

Post by s2g » Wed, Jun 27, 2018, 9:59 PM UTC

This is cool, I used to really like this sort of thing.

At some point I transformed into a bitter sad man who can't stand reading articles like this because I feel like such a worthless piece of crap.

Re: What I Learned Making My Own JIT Language

#74

Post by squeaky-clean » Wed, Jun 27, 2018, 10:03 PM UTC

batmansmk wrote: post #61

arghwhat wrote: post #18

Earlier quoted context omitted.

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.

That's just how it optimizes their usage under-the-hood, but as far as JS is concerned they are all hash maps.

For example, try this:

    var foo = [1,2,3];  // or `foo = new Array(1,2,3)` also works
    foo['bar'] = 'test';
    console.log(foo);

and you get:

    0:1
    1:2
    2:3
    bar:"test"

Re: What I Learned Making My Own JIT Language

#75

Post by arghwhat » Wed, Jun 27, 2018, 10:06 PM UTC

vanderZwan wrote: post #60

arghwhat wrote: post #32

Earlier quoted context omitted.

I'd like to add: Don't define your array as nothing but a hashmap with strings as array indexes , with two assignment hooks: One that on assignment updates that sets length = max(length, ToUint32(assigned key)), and one on "length" assignment that iterates over all keys in the hashmap, and for those that can be parsed as uint32's, delete those that have a numerical value larger than the value assigned to length. That…

> That is how JavaScript "Array" objects work. Array indexes are coerced to a strings, as they are for all objects. Well, according to the spec . All modern VMs make optimisations for small integers, which is allowed as long as the behaviour is in accordance to the spec.

Of course, but the language spec severely limit what optimizations can be done.

For example, V8 will happily give you a proper array if certain criteria is met, but it must always be ready for you trying to index it with a string, which means that it must attempt to parse the string as a numeric value. This means deoptimization checks, or in the worst case, a non-optimized array.

Re: What I Learned Making My Own JIT Language

#76

Post by arghwhat » Wed, Jun 27, 2018, 10:16 PM UTC

batmansmk wrote: post #61

arghwhat wrote: post #18

Earlier quoted context omitted.

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.

Ah yes, I had forgotten about Typed Arrays, which is a terrible name for what is in fact a buffer view. The entire arraybuffer/typedarray system was a later (≥IE10 if I am not mistaken?) hack added to make up for the fact that Array and Number are super inefficient for data processing.

But regardless of them being a bandaid, you are correct that it is an exception. ArrayBuffer and all its views count 10 types in total, so were they the only exception? If so, I believe my point still stands.

Re: What I Learned Making My Own JIT Language

#77

Post by barrkel » Wed, Jun 27, 2018, 10:16 PM UTC

It is so pleasant to read an article with Intel asm syntax rather than AT&T, my eyes thank you.

Re: What I Learned Making My Own JIT Language

#78

Post by arghwhat » Wed, Jun 27, 2018, 10:22 PM UTC

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.

The performance of JS is purely down to absolute compiler genius, which would have given better results and been better applied to a language that was not designed on the back of a napkin. JS does everything in its power to make life hard for the compiler.

Outside JS, most compiler work goes into static languages (which I strongly prefer), but once WebAssembly DOM support comes through, better languages will run on V8, stripping JS of everything it has.

Re: What I Learned Making My Own JIT Language

#79

Post by j-pb » Wed, Jun 27, 2018, 10:23 PM UTC

arghwhat wrote: post #41

j-pb wrote: post #40

Earlier quoted context omitted.

[1]In clojure the array type is basically a hashmap to enable high perf/low memory immutability. So I would say "Yes[1]" ^^

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…

I think you kinda missed the point, tbh.

You don't need in place memory operations with ridiculous performance in most(tm) applications. On the contrary there are many applications where security is far more important than speed and something that basically embodies remote code execution (browser) is one of those.

The fact that JS has made this implementation choice while at the same time being mutable is the true peril, not the specific implementation per se.

Re: What I Learned Making My Own JIT Language

#80

Post by arghwhat » Wed, Jun 27, 2018, 10:27 PM UTC

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…

I don't understand interest in dynamic languages. I have worked with them extensively, but I find them to be handicapped without benefit.

However, JS specifically was not designed at all to begin with, but just thrown together, and core concepts have stayed since this first iteration. These core concepts are its primary handicap.