Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Node.js applications will benefit from replacing V8 in JXcore

oguzbastemur.blogspot.com

Post reply on HN
Print view View original

21–24 of 24 posts

Re: How Node.js applications will benefit from replacing V8 in JXcore

#21

Post by eshyong »

bbllee wrote: post #16
modeless wrote: post #10

Earlier quoted context omitted.

It doesn't. The benchmark clearly shows that V8 is faster than JXCore, because lower scores are worse .

Looking at the linked benchmark file appears to bear out this claim: https://github.com/Nubisa/jxdocs/blob/master/benchmarks/core... It appears that the reported numbers for benchmark X are _the # of times that X can be run before one second elapses_, so parent comment is correct and the premise of the blogpost (that the new node.js version with V8 has worse performance than the earlier version / the private fork has…

Wait, I'm confused. From the following line:

https://github.com/Nubisa/jxdocs/blob/master/benchmarks/core...

Doesn't this line calculate the amount of time it takes to compute a single task? (elapsed time / number of runs = time per run) Doesn't this mean that JXcore is actually faster, since the number would be smaller with more runs?

Re: How Node.js applications will benefit from replacing V8 in JXcore

#22

Post by azakai »

tantalor wrote: post #15

Nothing to see here. Author uses Octane benchmark where bigger is better, so v8 ~26 beats the "experimental engine". Q: What do the scores mean? A: In a nutshell: bigger is better. Octane measures the time a test takes to complete and then assigns a score that is inversely proportional to the run time (historically, Firefox 2 produced a score of 100 on an old benchmark rig the V8 team used). https://developers.google…

Also, they report run times for the process - it's unclear if they are looking at the total score or the run times. If score, then it seems they are looking at it in the wrong direction, as you said. If run times, then those are meaningless in the Octane benchmark, as it estimates how many executions are possible in a fixed time frame, not how long a fixed workload takes to run.

Re: How Node.js applications will benefit from replacing V8 in JXcore

#23

Post by moisy »

eshyong wrote: post #21
bbllee wrote: post #16

Earlier quoted context omitted.

Looking at the linked benchmark file appears to bear out this claim: https://github.com/Nubisa/jxdocs/blob/master/benchmarks/core... It appears that the reported numbers for benchmark X are _the # of times that X can be run before one second elapses_, so parent comment is correct and the premise of the blogpost (that the new node.js version with V8 has worse performance than the earlier version / the private fork has…

Wait, I'm confused. From the following line: https://github.com/Nubisa/jxdocs/blob/master/benchmarks/core... Doesn't this line calculate the amount of time it takes to compute a single task? (elapsed time / number of runs = time per run) Doesn't this mean that JXcore is actually faster, since the number would be smaller with more runs?

numbers seem less important considering the run times.

Re: How Node.js applications will benefit from replacing V8 in JXcore

#24

Post by bbllee »

eshyong wrote: post #21
bbllee wrote: post #16

Earlier quoted context omitted.

Looking at the linked benchmark file appears to bear out this claim: https://github.com/Nubisa/jxdocs/blob/master/benchmarks/core... It appears that the reported numbers for benchmark X are _the # of times that X can be run before one second elapses_, so parent comment is correct and the premise of the blogpost (that the new node.js version with V8 has worse performance than the earlier version / the private fork has…

Wait, I'm confused. From the following line: https://github.com/Nubisa/jxdocs/blob/master/benchmarks/core... Doesn't this line calculate the amount of time it takes to compute a single task? (elapsed time / number of runs = time per run) Doesn't this mean that JXcore is actually faster, since the number would be smaller with more runs?

    // Suites of benchmarks consist of a name and the set of benchmarks in
    // addition to the reference timing that the final score will be based
    // on.  This way, all scores are relative to a reference run and higher
    // scores implies better performance.
https://github.com/Nubisa/jxdocs/blob/master/benchmarks/core...

For complete clarity, see also the lines

https://github.com/Nubisa/jxdocs/blob/master/benchmarks/core...

The score is (arbitrary reference constant) / (geometric mean of runtime). Bad performance ==> longer runtime ==> lower scores.

Post reply on HN