Asm.js performance boost on V8

[5nyper]

Will asm.js be used in V8 to optimize its performance? If asm.js is used, that will be a HUGE performance boost for V8 and essentially node.js.

[indutny]

@Ap0ph1s the thing is that we do not control v8. The V8 is developed by Google corporation and they define the way it goes.

[andrewlow]

V8 already does a very good job with code written to asm.js without having specific asm.js hacks. I'd argue that the HUGE performance boost for V8 is overly optimistic.

[rlidwka]

As far as I understand it, asm.js just adds static typing. Instead of doing that, v8 and seamonkey guess the type and insert cheap runtime checks to ensure that.

Thus, asm.js doesn't give any measurable performance benefits if you repeatedly run the same code (provided that the code in question is written with care about performance).

Anyway, node.js core doesn't do any heavy computations, so it doesn't matter here. You could ask people who write native crc32 modules for example, they could say something meaningful about it.

[indutny]

As an author of some native crypto stuff, I'd say that asm.js is less needed than some Math.* extensions: 32bit x 32bit multiplication, and stuff like that.

[Fishrock123]

afaik Spidermonkey / FF does better optimizations on asm.js code sometimes.

I also think using non-native-js libraries is silly.

[timkuijsten]

Just fyi, some speed comparisons of bcrypt implemented in C, js and
asm.js optimized js: https://www.npmjs.org/package/bcrypt-speed

-Tim

Fedor Indutny schreef op 22-11-14 om 16:05:

As an author of some native crypto stuff, I'd say that asm.js is less
needed than some |Math.*| extensions: 32bit x 32bit multiplication, and
stuff like that.

—
Reply to this email directly or view it on GitHub
#16 (comment).

[yosuke-furukawa]

Just FYI, next chrome will enable turbofan-asm. https://codereview.chromium.org/770203003/

[YurySolovyov]

@indutny is it worth to re-implement/transpile to asm.js anything that currently is c/c++ ?
I mean mainly any "hot spots" that doing needless C++ <-> Js switching.

[indutny]

@YuriSolovyov what exactly do you want to transpile? There is only two IO-independent C++ism here: cryptography and http parser. Cryptography in JS is possible and might be fast, but still it'll be slower and less secure (at least because it'll need to be reimplemented in JS).

HTTP parser is completely different story. Ideally, we could rewrite it in javascript or transpile it to JS, but I have never seen an implementation that is capable of same-speed parsing and provides same strictness as joyent/http-parser.

[YurySolovyov]

@indutny for http parser, if you just transpile it to asm.js from existing C/C++ code, how can you loose any strictness? I think it should be the same parser, but without going to C++ land.

For crypto, I agree. asm.js is not that good for now, nor V8 asm.js compiler.

In general, this is what google trying to do with chrome: they had problems with DOM bindings being in C++ and they trying to cross C++/JS boundaries less often by staying in JS as much as possible, so I thought it may be applicable to this case as well.

[indutny]

@YuriSolovyov it would be interesting to see how well it'll perform after transpiling. Sounds like an interesting experiment ;) Do you want to help us with this?

[YurySolovyov]

@indutny the only plan I have is

1. transpile parser to asm.js
2. try to plug it instead of C++ one
3. pass some tests

If I fail at any step, I have no idea where to dig, as I not familiar with both node core and C++.
(though I'm not sure C++ knowledge is needed, as I planed to plug it instead of bindings)
Sorry if I'm too distracting, just thinking out loud.

[indutny]

@YuriSolovyov sounds like a good plan :)

[indutny]

@YuriSolovyov and please don't forget to share results ;)

[YurySolovyov]

@indutny 2 news: Good and Bad.
Good: you CAN transpile http parser and it passes tests
Bad: it is too slow for now.
there is actually one more Good thing: v8 progress is really good and visible.
results (just parser. no node stuff):

0.10
user@y:~/httpparser/http-parser$ node bench.js
Benchmark result:
Took 65.347000 seconds to run
76514.606636 req/sec

0.12
user@y:~/httpparser/http-parser$ ~/node-0.12/out/Release/node bench.js
Benchmark result:
Took 31.232000 seconds to run
160092.213118 req/sec

native
user@y:~/httpparser/http-parser$ ./bench
Benchmark result:
Took 5.034185 seconds to run
993209.437500 req/sec

Latest stable Firefox

Benchmark result:
Took 13.304000 seconds to run
375826.819023 req/sec

This all can possibly be optimized better, but a I don't have good enough knowledge to do better. This is all done by following tutorials. ( still pretty cool though :) )
I can re-evaluate this once/if you get node/io build based on v8 3.31.38+ which is asm.js-enabled.
One more point: the actual benefit of having http parser in js, is not having to do context switch.
So if asm.js will work on more-or-less same speed as native, you should already get benefits.

I'm glad if it is interesting to anyone.