Hacker News new | ask | show | jobs
by kevingadd 4627 days ago
That's correct, nan boxing doesn't help for 64-bit integers.

On the other hand, Dart doesn't have required type annotations either and it has 64-bit ints, doesn't it? So it should be possible to introduce in JS.

Runtime overhead is likely, but then when you're in the JIT sweet spot the types are all known so you get JITcode that doesn't check types.

1 comments

I think that part of the value people see in things like NaCL is not having to rely on JIT magic to figure out when to optimize 64 bit math. You get direct control over what is going on. It may be true that in certain edge cases the JIT can actually out-perform clean native code, but people are willing to sacrifice that for direct control over what the machine does.

GC is a related example of a place where VM designers told us not to worry ourselves, but it turns out that GC is inherently hard and you are going to pay for that convenience - either in performance or in memory. See: http://sealedabstract.com/rants/why-mobile-web-apps-are-slow....

> I think that part of the value people see in things like NaCL is not having to rely on JIT magic to figure out when to optimize 64 bit math. You get direct control over what is going on. It may be true that in certain edge cases the JIT can actually out-perform clean native code, but people are willing to sacrifice that for direct control over what the machine does.

This is precisely what "use asm" is for. It gives you direct control: each allowable operation in the subset has a direct analogue to the appropriate machine instruction(s). If you fall off the happy path and stray into "JIT magic" territory, you get a message in the developer console telling you to fix your code.

Unfortunately V8 is opposed to "use asm" in favor of the "JIT magic".

That post you linked to is actually full of some fundamental misunderstandings about GC and JS VMs :) But yes, it is the case that GC isn't a free lunch - it comes with costs and you have to design your applications to avoid the weaknesses of a given GC. It's rough.

I agree that not having to rely on the JIT to figure out how to optimize your code with 'magic' is preferable. I tend to lean towards that where possible in most of the JIT/GC-based environments I use (C#, JavaScript, etc), and it tends to pay off.