Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Asm.js performance boost on V8 #16

Open
5nyper opened this issue Nov 22, 2014 · 23 comments
Open

Asm.js performance boost on V8 #16

5nyper opened this issue Nov 22, 2014 · 23 comments

Comments

@5nyper
Copy link

5nyper commented Nov 22, 2014

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
Copy link

indutny commented Nov 22, 2014

@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
Copy link

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
Copy link
Member

rlidwka commented Nov 22, 2014

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
Copy link

indutny commented Nov 22, 2014

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
Copy link
Member

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

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

@timkuijsten
Copy link

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
Copy link

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

@YurySolovyov
Copy link

@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
Copy link

indutny commented Dec 4, 2014

@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
Copy link

@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
Copy link

indutny commented Dec 4, 2014

@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
Copy link

@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
Copy link

indutny commented Dec 4, 2014

@YuriSolovyov sounds like a good plan :)

@indutny
Copy link

indutny commented Dec 4, 2014

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

@YurySolovyov
Copy link

@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
Copy link

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

@YurySolovyov
Copy link

@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
Copy link

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

@LaurentVB
Copy link

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
Copy link
Member

rlidwka commented Dec 5, 2014

@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
Copy link

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
Copy link
Member

rlidwka commented Dec 5, 2014

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
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants