search

node-forward / discussions

Soliciting ideas and feedback for community driven collaborative projects that help Node.
149 stars 1 forks source link

Asm.js performance boost on V8 #16

Open 5nyper opened 9 years ago

5nyper commented 9 years ago

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 commented 9 years ago

@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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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

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

timkuijsten commented 9 years ago

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 https://github.com/node-forward/discussions/issues/16#issuecomment-64082961.

yosuke-furukawa commented 9 years ago

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

YurySolovyov commented 9 years ago

@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 commented 9 years ago

@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 commented 9 years ago

@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 commented 9 years ago

@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 commented 9 years ago

@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 commented 9 years ago

@YuriSolovyov sounds like a good plan :)

indutny commented 9 years ago

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

YurySolovyov commented 9 years ago

@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.

LaurentVB commented 9 years ago

@YuriSolovyov Thanks for these experiments. Do you know how it compares to https://github.com/creationix/http-parser-js ?

YurySolovyov commented 9 years ago

@LaurentVB https://github.com/creationix/http-parser-js will probably be faster, because it does not have all that asm.js machinery, but I'm not 100% sure.

YurySolovyov commented 9 years ago

also, here is archive with transpiled http parser. .html and .js for firefox and node respectively

LaurentVB commented 9 years ago

For the sake of curiosity, I tried the same benchmark (js port here) on https://github.com/creationix/http-parser-js. On my windows 7 machine, node.0.10, it's approx 13x slower that the asm.js version you provided:

$ node ./bench.js
Benchmark result:
Took 73.280000 seconds to run
68231.441049 req/sec

$ node bench2.js
Benchmark result:
Took 100.011021152 seconds to run
4999.449003126203 req/sec

Not there yet...

rlidwka commented 9 years ago

@LaurentVB , so which one is slower? emscripten(http-parser) or creationix/http-parser-js? Your message isn't very clear.

Is creationix/http-parser-js 100 times slower than http-parser node.js uses?

YurySolovyov commented 9 years ago

Just curious if it is possible to port C parser to js just by hand, using plain js. 2.3k lines with lots of whitespace and static data seems approachable...

rlidwka commented 9 years ago

Just curious if it is possible to port C parser to js just by hand, using plain js.

I think so. Those defines scare me a bit, but it should be pretty doable.

LaurentVB commented 9 years ago

@rlidwka Yes, on my machine and under node 0.10, the js version of creationix/http-parser-js is 10 to 15 times slower than emscripten(joyent/http-parser)