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

NodeJs Smi-Array vs Pure V8 Smi-Array Performance #48524

Closed
demimurych opened this issue Jun 22, 2023 · 5 comments
Closed

NodeJs Smi-Array vs Pure V8 Smi-Array Performance #48524

demimurych opened this issue Jun 22, 2023 · 5 comments

Comments

@demimurych
Copy link

demimurych commented Jun 22, 2023

Version

v20.3.0

Platform

Linux murych-hive 5.4.0-148-lowlatency #165-Ubuntu SMP PREEMPT Tue Apr 18 09:36:22 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Subsystem

noop

What steps will reproduce the bug?

file.js

"use strict";
var arr = [];
var size = 10000000;
var test_times = 50;

for ( var i = 0; i < size; i++ ) {
	arr.push( i )
}

for ( var i = 0; i < test_times; i++ ) {
	var test = arr.indexOf( 9999999 )
}

/usr/bin/time -f "Time: %e" /usr/bin/node ./file.js

Time: 1.32

this code will be much slower than in pure v8.
/usr/bin/time -f "Time: %e" /usr/bin/d8 ./file.js

Time: 0.36

How often does it reproduce? Is there a required condition?

no

What is the expected behavior? Why is that the expected behavior?

There should be no discrepancy between v8 and node with such a large gap.

What do you see instead?

The first example slower than the second

Additional information

that's not all.
file2.js

"use strict";
var arr = [];
var size = 10000000;
var test_times = 50;



for ( var i = 0; i < size; i++ ) {
	arr.push( i + 0.1 )
}

for ( var i = 0; i < test_times; i++ ) {
	var test = arr.indexOf( 9999999.1 )
}

Runs faster than the first example.
/usr/bin/time -f "Time: %e" /usr/bin/node ./file.js

Time: 1.32

/usr/bin/time -f "Time: %e" /usr/bin/node ./file2.js

Time: 0.90

The first example operates on SMI in array
The second example operates on Double in array

How in Node double which is located in heap is faster than smi which located directly in array ?

In pure v8 everything works as expected.
/usr/bin/time -f "Time: %e" /usr/bin/d8 ./file.js

Time: 0.36

/usr/bin/time -f "Time: %e" /usr/bin/d8 ./file2.js

Time: 0.59

That is, double is slower than smi

@mscdex
Copy link
Contributor

mscdex commented Jun 22, 2023

You shouldn't be comparing time like that since it's including a lot of extra machinery (startup and otherwise) that node has but d8 does not. Instead, use something like performance.now() in the code itself to measure the difference to avoid including irrelevant code.

@mscdex
Copy link
Contributor

mscdex commented Jun 22, 2023

Additionally, make sure that the d8 executable was compiled with the same V8 configuration as node for a fair comparison (in fact, this could very well be the cause of any discrepencies).

@demimurych
Copy link
Author

demimurych commented Jun 23, 2023

You shouldn't be comparing time like that since it's including a lot of extra machinery (startup and otherwise) that node has but d8 does not. Instead, use something like performance.now() in the code itself to measure the difference to avoid including irrelevant code.

The most important thing to pay attention to is not the numbers but the fact that Float Array in Node.js turns out to be 1.5 times faster than NodeJS SMI Array. And this contradicts how Arrays are structured in V8.
Please focus not on the comparison numbers between Node.js and V8, but on the numbers for Node.js with SMi and Float Array.
There seems to be an obvious degradation in your code somewhere.

Just compare the numbers between File.js and File2.js using any method specifically for Node.js. And after that, please explain how FloatArray in Node.js became faster than SMI Array in Node.js.

In d8 all work like expected. In browser Google Chrome All work like expected. In node NOT.

@bnoordhuis
Copy link
Member

I can explain why you see a difference (your intuition re: ints vs. floats is too naive) but honestly, such microbenchmarks are uninteresting and not worth the time. You're really just benchmarking different versions of V8 against each other.

@bnoordhuis
Copy link
Member

I'll go ahead and close this but let me know if there is reason to reopen.

@bnoordhuis bnoordhuis closed this as not planned Won't fix, can't repro, duplicate, stale Jun 27, 2023
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