Crankshaft

[Debacker]

Wow, the future looks bright !

The new version of V8 (3.0) with Crankshaft is up to twice as fast in some benchmarks.

You can see it on Chromium's blog: http://blog.chromium.org/2010/12/new-crankshaft-for-v8.html

They released the code today.

Laurent

[Joshua Kehn]

I just saw this on TechCrunch (http://techcrunch.com/2010/12/07/chrome-browser-120-million/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Techcrunch+%28TechCrunch%29). 

I'm very excited to see JavaScript moving forward this quickly! 

Regards,

-Josh

____________________________________

Joshua Kehn | Josh...@gmail.com

http://joshuakehn.com

--
You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com.
To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.

[Felix Geisendörfer]

Can't wait to benchmark node-mysql once this has landed in HEAD.

Thanks for the link!

--fg

On Dec 7, 8:17 pm, Joshua Kehn <josh.k...@gmail.com> wrote:
> I just saw this on TechCrunch (http://techcrunch.com/2010/12/07/chrome-browser-120-million/?utm_sour...).

>
> I'm very excited to see JavaScript moving forward this quickly!
>
> Regards,
>
> -Josh
> ____________________________________

> Joshua Kehn | Josh.K...@gmail.comhttp://joshuakehn.com

[Arnout Kazemier]

I couldn't wait until it landed in HEAD so I already compiled it, and ran a make bench against the latest trunk build and latest trunk build with crankshaft enabled.

If you care about the benchmark results, if have uploaded the zip's to my dropbox; 

http://dl.dropbox.com/u/1381492/nodejs/v8/benchmark_reports.zip <-- regular benchmarks  http://dl.dropbox.com/u/1381492/nodejs/crankshaft/benchmark_reports_crankshaft.zip <-- crankshaft benchmarks

~ Arnout

[Alex Brown]

I couldn't fill a thimble with what I know about optimization but It would be interesting if they could use the runtime profiler to continuously optimize the code as system resources change. I would think your optimization strategy would change if there was less memory to work with.

2010/12/7 Felix Geisendörfer <fe...@debuggable.com>

[Dean Landolt]

On Tue, Dec 7, 2010 at 4:52 PM, Arnout Kazemier <in...@3rd-eden.com> wrote:

I couldn't wait until it landed in HEAD so I already compiled it, and ran a make bench against the latest trunk build and latest trunk build with crankshaft enabled.

If you care about the benchmark results, if have uploaded the zip's to my dropbox; 

http://dl.dropbox.com/u/1381492/nodejs/v8/benchmark_reports.zip <-- regular benchmarks  http://dl.dropbox.com/u/1381492/nodejs/crankshaft/benchmark_reports_crankshaft.zip <-- crankshaft benchmarks

And what were your findings? From a cursory glance it looks like crankshaft is (very nominally) faster for your string tests and actually slower for your buffer tests. I didn't notice anything remotely close to a 50% bump.

[Jos Hirth]

Well, there aren't many calculations going on in that benchmark. A
better JIT won't help much. A better GC might help quite a bit, I
guess. But of course that would be only true if the response is
generated anew for every request. I'm not really sure if the benchmark
actually does that. (It probably doesn't, since it looks like it's all
about raw throughput.)

However, if there is actually some logic going on, you should see some
improvement. But you probably won't see much of that in a typical use
case.

Personally I'm very excited about the latest V8 improvements though.
It adds some extra fuel to the seemingly never ending engine wars and
of course it will also allow me to do a bit more in my client-side
games. :)