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

a jsPerf benchmark of your eval example #5

Open
Myaushka opened this issue Feb 7, 2014 · 9 comments
Open

a jsPerf benchmark of your eval example #5

Myaushka opened this issue Feb 7, 2014 · 9 comments

Comments

@Myaushka
Copy link

Myaushka commented Feb 7, 2014

I thought it would be interesting to actually test your eval claim. So, I created a jsPerf test (based on the Benchmark.js library, which happens to be named the same as one of the files in your repo):

http://jsperf.com/mesdfleifi

It's way more impressive than I expected! Check out the graph at the end!

It could be an interesting addition to your article.

@Myaushka
Copy link
Author

Myaushka commented Feb 7, 2014

I thought it might be about http://en.wikipedia.org/wiki/Loop_unwinding, but then I found this: http://jsperf.com/unrolled-loops

It's not exactly the same thing, so maybe "further research is needed."

@felixge
Copy link
Owner

felixge commented Feb 7, 2014

Thanks for putting this together, the numbers are impressive indeed. I'm not maintaing this repo, I just put it together once for a talk, but if you want to make changes I'd be happy to merge them in.

Anyway, I'm not sure what the technique should be called. Yes, it's loop unwinding, but it's neither done by the compiler, nor the programmer. I almost want to call it a userland JIT, but since it's not compiling to a lower level representation that seems inappropriate. I guess "runtime code generation for loop unwinding" is the best way to describe it.

@Myaushka
Copy link
Author

Myaushka commented Feb 7, 2014

Actually, I updated the test to be more fair, and it's a lot more reasonable. I originally didn't include the loop unwinding code in the test, but it should be included, unless it's reused (is it?)

@Myaushka
Copy link
Author

Myaushka commented Feb 7, 2014

It's still faster, though, although not astronomically so.

@felixge
Copy link
Owner

felixge commented Feb 7, 2014

So the details on how the benchmark runs become very important. This technique will yield very high results when parsing a huge number of rows from the same table. It's not so useful when doing lots of queries with smaller result sets where the parser needs to be re-generated every time (which is what I suspect ends up happening with your change to the setup).

@Myaushka
Copy link
Author

Myaushka commented Feb 7, 2014

Yes, exactly. I think I'll add a 3rd case and rename the cases appropriately!

@felixge
Copy link
Owner

felixge commented Feb 7, 2014

Cool! Thanks for making these standalone test cases!

@Myaushka
Copy link
Author

Myaushka commented Feb 7, 2014

This exactly proves your point about specific techniques being applicable to specific problems!

@agauniyal
Copy link

Anyway, I'm not sure what the technique should be called. Yes, it's loop unwinding, but it's neither done by the compiler, nor the programmer. I almost want to call it a userland JIT, but since it's not compiling to a lower level representation that seems inappropriate. I guess "runtime code generation for loop unwinding" is the best way to describe it.

Loop unwinding might be new to javascript language but is quite popular in other c-family languages from much, much-older times. But I must say, impressive work 👍

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

3 participants