Perfomance of 2.6 and 4.2

[mycoding]

 Good day.

I checked perfomance of old versions and new versions and was upset.

In version 2.6 code was made for 4 seconds

And in version 4.2 for 14 seconds.

I test it on my vps where ubuntu.

Here is code

var a = 5;

var b = 6;

for(var i=0;i<1000000000;i++){

if(i%2==0){

var c = a;

a = b;

b = c;

}

else{

var c = b;

b = a;

a = c;

}

}

console.log('END');

[Dominic Tarr]

wow, I'm getting similar results!

is this node, or v8?

i'm getting similar results:

v0.2.6: 7.655

v0.4.2: 59.276

also on ubuntu, old computer.

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

[Laurie Harper]

A micro benchmark like that isn't a reliable indication of real-world performance. You shouldn't draw any conclusions until you've measured and compared with code that's doing real work to satisfy a real-world use case.

If you want more insight into the performance characteristics of Node and the underlying V8 virtual machine, there was a lengthy discussion on this list just recently. Check the archives to learn more than you probably wanted to know :-)

L.

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

--
Laurie Harper
http://laurie.holoweb.net/

[Dean Mao]

If you want to see node 0.4 run as fast as 0.2.6, you can mess with Bert's fork:

https://github.com/piscisaureus/node

(this info was extracted from the last giant 0.4/0.2.6 discussion on performance)

Running your code yields these results:  (doing "time node test.js")

Bert's 0.4.1:

real 0m0.371s

0.4.2:

real 0m1.729s

0.4.2 --crankshaft:

real 0m1.123s

0.2.6:

real 0m0.389s

[Vyacheslav Egorov]

On Thu, Mar 10, 2011 at 7:58 AM, mycoding <mycod...@gmail.com> wrote:
> I checked perfomance of old versions and new versions and was upset.

There are several factors in play here. New optimizing backend does not _yet_:

1) support global variables with accessors --- so when it sees
'console' (which is global with accessors) it bails out, so your
testcase runs only as non-optimized code.

2) do strength reduction, so i % 2 will be compiled into idiv
instruction, while classic backend did strength reduction for modulo
with power-of-2 divisors and compiled it into an and instruction (with
a slow case for negative dividend).

Does this kind of loop dominate running time of your node.js application?

On Thu, Mar 10, 2011 at 11:29 AM, Dean Mao <dea...@gmail.com> wrote:
> If you want to see node 0.4 run as fast as 0.2.6, you can mess with Bert's
> fork:

Bert's fixes affect only node.js performance on Cygwin on Windows.

--
Vyacheslav Egorov

[Dean Mao]

hm, so why does Bert's 0.4.1 performance differ so greatly on my non-windows platform?  My 0.4.2 micro benchmark runs in 1.7s, but bert's version runs in 0.3

[Vyacheslav Egorov]

Can you run both builds with --trace-opt --trace-osr --trace-bailout
--trace-deopt and post output?

--
Vyacheslav Egorov

[Egor Egorov]

On Thursday, March 10, 2011 12:49:11 PM UTC+2, veg...@chromium.org wrote:

On Thu, Mar 10, 2011 at 7:58 AM, mycoding <mycod...@gmail.com> wrote:
> I checked perfomance of old versions and new versions and was upset.

There are several factors in play here. New optimizing backend does not _yet_:

1) support global variables with accessors --- so when it sees
'console' (which is global with accessors) it bails out, so your
testcase runs only as non-optimized code.

Not reproductible. This code runs on my Mac OS X 10.6.6: with console.log: 26 seconds, without console.log: 25.6 seconds.  

[Vyacheslav Egorov]

Can you please run with --trace-opt --trace-osr --trace-bailout
--trace-deopt with and without console.log?

// I also hope you are running ia32 version of node 0.4.2 or more recent.

--
Vyacheslav Egorov

[Egor Egorov]

Sure but, uh, where do I find the results to send 'em to you? I ran that and no log files found. 

[Vyacheslav Egorov]

All data is printed to stdout.

If you don't see anything that means that Crankshaft is not active for
some reason (e.g. you are running x64 build of node with V8 prior to
3.2.0 which enabled crankshaft for x64).

Also make sure to specify flags like this:

node --trace-opt --trace-osr --trace-bailout --trace-deopt test.js

not like this

node test.js --trace-opt --trace-osr --trace-bailout --trace-deopt

--
Vyacheslav Egorov

On Thu, Mar 10, 2011 at 1:24 PM, Egor Egorov <egor....@gmail.com> wrote:
> Sure but, uh, where do I find the results to send 'em to you? I ran that and
> no log files found.
>

[Egor Egorov]

On Thursday, March 10, 2011 2:41:55 PM UTC+2, veg...@chromium.org wrote:

All data is printed to stdout.

If you don't see anything that means that Crankshaft is not active for
some reason (e.g. you are running x64 build of node with V8 prior to

Oops. Does it mean that x64 never had crankshaft enabled until 3.2? I have node running on all my servers which are x64...:) 

3.2.0 which enabled crankshaft for x64).

 

OMG!

Without console.log: 

  stock node 0.4.2 on x64: 26 seconds;

  node 0.4.2 with v8 bleeding edge: 6.2 seconds

With console.log:

  stock node 0.4.2 on x64: 26 seconds;

  node 0.4.2 with v8 bleeding edge: 26 seconds.

Trace with console.log: 

[deoptimize context: 1009a2021]

[marking (lazily)  for recompilation]

[patching stack checks in  for on-stack replacement]

[replacing on-stack at AST id 32 in ]

Bailout in HGraphBuilder: @"": global variable has accessors

[disabled optimization for:  / 100f2c419]

[restoring original stack checks in ]

[marking (lazily) Module._compile for recompilation]

[marking (lazily) NativeModule.compile for recompilation]

[optimizing: NativeModule.compile / 100e28b99 - took 0.581 ms]

This line "Bailout in HGraphBuilder: @"": global variable has accessors" is useful, but how do I know the name of the variable so I can optimize my own code? In this test snippet I know it's console, but for my own code that would be tricky...

[Arnout Kazemier]

I don't think that v8 3.2.0 has landed inside node yet.
The latest stable version is 0.4.2 is using V8 3.1.8 and the
latest trunk build Node v0.5.0pre is still using V8 3.1.6

[Vyacheslav Egorov]

> Oops. Does it mean that x64 never had crankshaft enabled until 3.2?

Yes. When Crankshaft was initially released it supported only ia32.
3.2.0 enables it on x64 and ARM. But I would not recommend immediately
pulling it into production. There are some known bugs in x64
Crankshaft so we had to revert 3.2.0 from Chrome tree and are actively
working on fixing them.

> This line "Bailout in HGraphBuilder: @"": global variable has accessors" is useful, but how do I know the name of the variable so I can optimize my own code?

Unfortunately only by setting breakpoint in hydrogen's guts. This
output was never intended to be widely used externally. Eventually all
or almost all constructs will be supported by hydrogen.

--
Vyacheslav Egorov

[Egor Egorov]

On Thursday, March 10, 2011 3:00:10 PM UTC+2, veg...@chromium.org wrote:

[]

 

Thanks! I will build for ia32 then. 

 

> This line "Bailout in HGraphBuilder: @"": global variable has accessors" is useful, but how do I know the name of the variable so I can optimize my own code?

Unfortunately only by setting breakpoint in hydrogen's guts.

Is there a way to put a debugger output in the code somewhere?  

 

>> > nodejs...@googlegroups.com.

[Vyacheslav Egorov]

> Is there a way to put a debugger output in the code somewhere?

For this particular bailout you can put it into
HGraphBuilder::LookupGlobalPropertyCell. Something like:

if (lookup->type() != NORMAL) {
if (FLAG_trace_bailout) PrintF("global var with accessor %s\n",
*var->name()->ToCString()); // add this line to see name of the
variable
BAILOUT("global variable has accessors");
}

But there are a lot of other bailouts and they do not print any
detailed information.

--
Vyacheslav Egorov

[Dean Mao]

Not sure how useful this is, but here are running times for a few different node/v8 version combinations running the micro-benchmark.  All of these tests were running on my macbook 2.4ghz - i5

Seems like the fastest versions are all on v8-3.1.6

----

0.2.6-stable on v8-2.3.8:

time node --trace-opt --trace-osr --trace-bailout --trace-deopt /tmp/blah.js 

Error: unrecognized flag --trace-opt

Try --help for options

real 0m3.349s

user 0m3.297s

sys 0m0.017s

----

0.2.6-stable on v8-3.1.6:

time ./node --trace-opt --trace-osr --trace-bailout --trace-deopt /tmp/blah.js 

real 0m3.305s

user 0m3.281s

sys 0m0.017s

----

0.2.6-stable on v8-3.2.1:

time ./node --trace-opt --trace-osr --trace-bailout --trace-deopt /tmp/blah.js 

[marking (lazily)  for recompilation]

[patching stack checks in  for on-stack replacement]

[replacing on-stack at AST id 32 in ]

[optimizing:  / 100e4da29 - took 0.704 ms]

[on-stack replacement offset 53 in optimized code]

[restoring original stack checks in ]

**** OSR:  at ast id #32, address 0x105852bad, frame size 32

[on-stack replacement: begin 0x100e4da29  => node=32, frame=112->160]

    [sp + 72] <- 0x1020c0a91 ; [sp + 104]

    [sp + 64] <- 0x1020c0a91 ; [sp + 96]

    [sp + 56] <- 0x1020f1ea1 ; [sp + 88]

    [sp + 48] <- 0x1020c09f1 ; [sp + 80]

    [sp + 40] <- 0x102020309 ; [sp + 72]

    [sp + 32] <- 0x1020f1fb9 ; [sp + 64]

    [esp + 104] <- 0x1058154fc ; [esp + 56] (fixed part)

    [esp + 96] <- 0x7fff5fbfd578 ; [esp + 48] (fixed part)

    [esp + 88] <- 0x100a4c021 ; [esp + 40] (fixed part)

    [esp + 80] <- 0x100e4da29 ; [esp + 32] (fixed part)

    [sp + 24] <- 0x500000000 ; [sp + 24]

    [sp + 16] <- 0x20af2e00000000 ; [sp + 16]

    [sp + 8] <- 0x500000000 ; [sp + 8]

    [sp + 0] <- 0x600000000 ; [sp + 0]

[on-stack replacement translation finished: 0x100e4da29  => pc=0x105853375]

[marking (lazily) module.Module._compile for recompilation]

real 0m5.770s

user 0m5.752s

sys 0m0.048s

----

0.4.2-stable on v8-2.3.8:

time ./node --trace-opt --trace-osr --trace-bailout --trace-deopt /tmp/blah.js 

Error: unrecognized flag --trace-opt

Try --help for options

real 0m17.997s

user 0m17.920s

sys 0m0.044s

----

0.4.2-stable on v8-3.1.6:

time ./0.4.2-v8_3.1.6/node --trace-opt --trace-osr --trace-bailout --trace-deopt /tmp/blah.js 

[deoptimize context: 100a4c021]

real 0m3.275s

user 0m3.253s

sys 0m0.016s

----

0.4.2-stable on v8-3.2.1:

time ./0.4.2-v8_3.2.1/node --trace-opt --trace-osr --trace-bailout --trace-deopt /tmp/blah.js 

[deoptimize context: 100a74021]

[marking (lazily)  for recompilation]

[patching stack checks in  for on-stack replacement]

[replacing on-stack at AST id 32 in ]

[optimizing:  / 126a283a1 - took 0.826 ms]

[on-stack replacement offset 53 in optimized code]

[restoring original stack checks in ]

**** OSR:  at ast id #32, address 0x10588736f, frame size 32

[on-stack replacement: begin 0x126a283a1  => node=32, frame=112->160]

    [sp + 72] <- 0x1030827e9 ; [sp + 104]

    [sp + 64] <- 0x1030827e9 ; [sp + 96]

    [sp + 56] <- 0x103085511 ; [sp + 88]

    [sp + 48] <- 0x1030826b1 ; [sp + 80]

    [sp + 40] <- 0x103081201 ; [sp + 72]

    [sp + 32] <- 0x1030864e1 ; [sp + 64]

    [esp + 104] <- 0x1058154fc ; [esp + 56] (fixed part)

    [esp + 96] <- 0x7fff5fbfe278 ; [esp + 48] (fixed part)

    [esp + 88] <- 0x100a74021 ; [esp + 40] (fixed part)

    [esp + 80] <- 0x126a283a1 ; [esp + 32] (fixed part)

    [sp + 24] <- 0x600000000 ; [sp + 24]

    [sp + 16] <- 0x104a0500000000 ; [sp + 16]

    [sp + 8] <- 0x500000000 ; [sp + 8]

    [sp + 0] <- 0x500000000 ; [sp + 0]

[on-stack replacement translation finished: 0x126a283a1  => pc=0x105887bb5]

[marking (lazily) Module._compile for recompilation]

real 0m5.769s

user 0m5.750s

sys 0m0.050s

[Vyacheslav Egorov]

Thank you.

> Seems like the fastest versions are all on v8-3.1.6

Judging by addresses you are running x64 bit version of node.

The difference between V8 3.2.x and V8 3.1.x is that Cranskshaft was
not enabled for x64 prior to V8 3.2.0.

Why Crankshaft is slower on this particular micro-benchmark than
classical backend was explained in my first message in the thread ---
strength reduction is missing.

--
Vyacheslav Egorov

[Ryan Dahl]

On Thu, Mar 10, 2011 at 2:49 AM, Vyacheslav Egorov <veg...@chromium.org> wrote:
> On Thu, Mar 10, 2011 at 7:58 AM, mycoding <mycod...@gmail.com> wrote:
>> I checked perfomance of old versions and new versions and was upset.
>
> There are several factors in play here. New optimizing backend does not _yet_:
>
> 1) support global variables with accessors --- so when it sees
> 'console' (which is global with accessors) it bails out, so your
> testcase runs only as non-optimized code.

Just a note to say that as of 2a05fe784d1c7ced3cee11e0d9e066b3bb0f361e
this is no longer the case.

[mycoding]

 Ryan Dahl, I am very glad to you for nodeJS.

But please tell everything is okey?

So it is normal.

Maybe the matter is in so that on 2.3 More CPU is used and in 

4.2 much less CPU.

As far as I understand it was made very much to fix some bugs and to 

do NodeJS more stable.

If so it is okey.

The matter is I first of all in my project need perfomance.

I want to change php on nodeJS.

And in future do not use php at all.

Still I am very pleased to you for your work.

I want to wish you to do some kind of online couse or video.

Advanced matirials and so on.

I watch video with you from Sencha Conference and other it is very 

good.

Very thanks for your work.