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

Performance of ES6 features relative to ES5

kpdecker.github.io

Post reply on HN
Print view View original

31–40 of 71 posts

Re: Performance of ES6 features relative to ES5

#31

Post by baddox »

aschampion wrote: post #28
venning wrote: post #9

Note, when it says "1.6x faster" what is really means is "1.6 as fast" or "60% faster", or really "operates at 1.6x the speed of the baseline", not "1.6x increase in speed". For example, when looking at the data for Chrome 48's "arrow" tests [1], the baseline number is 57,858,016 and the traceur number is 91,556,806, which is 158.2% of the baseline , but is reported as "1.6x faster". I know this seems like semantics,…

This is the convention when talking about speedup in software. 1x speedup means identical time. [1] https://en.wikipedia.org/wiki/Speedup

I agree based on my experience reading these types of comparisons. I've never thought there was any ambiguity to saying "1.6 times faster." It means performance_1 = performance_0 * 1.6.

Re: Performance of ES6 features relative to ES5

#32

Post by dcwca »

coldtea wrote: post #30
venning wrote: post #9

Note, when it says "1.6x faster" what is really means is "1.6 as fast" or "60% faster", or really "operates at 1.6x the speed of the baseline", not "1.6x increase in speed". For example, when looking at the data for Chrome 48's "arrow" tests [1], the baseline number is 57,858,016 and the traceur number is 91,556,806, which is 158.2% of the baseline , but is reported as "1.6x faster". I know this seems like semantics,…

> Note, when it says "1.6x faster" what is really means is "1.6 as fast" or "60% faster", or really "operates at 1.6x the speed of the baseline", not "1.6x increase in speed". Isn't this always the case with such comparisons? One is meant to multiple initialValue by e.g. 1.6 (hence the "x", for multiple), not calculate initialValue + 1.6*initialValue.

No, the word faster means an increase by that amount. 100% faster means twice as fast. 1x faster means twice as fast. 100% as fast means no change. 1x as fast means no change.

English, you subtle trickster!

Re: Performance of ES6 features relative to ES5

#33

Post by acdha »

dragonwriter wrote: post #29
acdha wrote: post #27

Earlier quoted context omitted.

The main difference is that you the developer can test with a known compiler and know what the performance characteristics are before you release your code: when Microsoft releases VisualStudio 2018, your existing application doesn't change until you rebuild it. In contrast, for code running in a web browser or something like the JVM, your existing code may run faster or slower without you even knowing about the new…

> The main difference is that you the developer can test with a known compiler and know what the performance characteristics are before you release your code: when Microsoft releases VisualStudio 2018, your existing application doesn't change until you rebuild it. In contrast, for code running in a web browser or something like the JVM, your existing code may run faster or slower without you even knowing about the ne…

Right – that's why I didn't say “known compiler and standard library”. That said, it's a difficult comparison because OS updates tend to be more conservative and are definitely less frequent than browser updates, AOT apps in lower-level languages like C/C++ are going to manage a higher percentage of their core data structures because they're pinning something like Boost whereas a JavaScript developer just gets whatever version of Object/Array/etc. is available, and there's not really a concept of a pinned release: if you install Windows apps, you'll pull in major versions of things like .NET or the JVM but there's no analogous practice of pinning a particular browser version. The closest we've come was Internet Explorer's compatibility modes which they've deprecated and which never changed the core JavaScript engine's performance – e.g. IE8-running-as-IE7 still applied the IE8 JavaScript engine's validation and optimizations.

Re: Performance of ES6 features relative to ES5

#35

Post by nostrademons »

acdha wrote: post #27
paulddraper wrote: post #20

Earlier quoted context omitted.

> The thing about JIT languages is that there's no such thing as overall speed of a particular operation; you can only sample current speed on current implementations. How in the world is that specific to JIT? Have you never heard of a Sufficiently Smart Compiler?

The main difference is that you the developer can test with a known compiler and know what the performance characteristics are before you release your code: when Microsoft releases VisualStudio 2018, your existing application doesn't change until you rebuild it. In contrast, for code running in a web browser or something like the JVM, your existing code may run faster or slower without you even knowing about the new…

I'm not sure this is true anymore even in this case - with multicore processors, cache dependency, and pervasive virtualization, the speed of your program can be significantly affected by what else is running on the box. Remember that the x86 itself has a JIT on the chip, converting x86 machine code to whatever microcode the processor uses. When I was at Google, they provided special dedicated machines for benchmarking, with custom run-times that disabled a lot of the containerization/virtualization features, and there was still a lot of noise in benchmark times.

Re: Performance of ES6 features relative to ES5

#36

Post by mrcarrot »

dcwca wrote: post #32
coldtea wrote: post #30

Earlier quoted context omitted.

> Note, when it says "1.6x faster" what is really means is "1.6 as fast" or "60% faster", or really "operates at 1.6x the speed of the baseline", not "1.6x increase in speed". Isn't this always the case with such comparisons? One is meant to multiple initialValue by e.g. 1.6 (hence the "x", for multiple), not calculate initialValue + 1.6*initialValue.

No, the word faster means an increase by that amount. 100% faster means twice as fast. 1x faster means twice as fast. 100% as fast means no change. 1x as fast means no change. English, you subtle trickster!

I'm not sure I've ever seen anything described as being '1x' faster, without any fractional part. It's such an uncommon usage, I really don't think you can categorically declare that '1x faster means twice as fast'.

Re: Performance of ES6 features relative to ES5

#37

Post by venning »

aschampion wrote: post #28
venning wrote: post #9

Note, when it says "1.6x faster" what is really means is "1.6 as fast" or "60% faster", or really "operates at 1.6x the speed of the baseline", not "1.6x increase in speed". For example, when looking at the data for Chrome 48's "arrow" tests [1], the baseline number is 57,858,016 and the traceur number is 91,556,806, which is 158.2% of the baseline , but is reported as "1.6x faster". I know this seems like semantics,…

This is the convention when talking about speedup in software. 1x speedup means identical time. [1] https://en.wikipedia.org/wiki/Speedup

If the phrase was "1.6x speedup" then I would agree and not have commented. But the phrase is "1.6x faster", which is a bit ambiguous.

That there is disagreement among the commentariat both ways is indicative of ambiguity. (Though, I am assuming no trolling here.)

While not exactly analogous, try replacing it with a percentage and re-evaluate: What does "60% faster" mean and what does "160% faster" mean?

Re: Performance of ES6 features relative to ES5

#38

Post by erydo »

aschampion wrote: post #28
venning wrote: post #9

Note, when it says "1.6x faster" what is really means is "1.6 as fast" or "60% faster", or really "operates at 1.6x the speed of the baseline", not "1.6x increase in speed". For example, when looking at the data for Chrome 48's "arrow" tests [1], the baseline number is 57,858,016 and the traceur number is 91,556,806, which is 158.2% of the baseline , but is reported as "1.6x faster". I know this seems like semantics,…

This is the convention when talking about speedup in software. 1x speedup means identical time. [1] https://en.wikipedia.org/wiki/Speedup

They did say "1.6x faster", not using the term "speedup" (which is terrible nomenclature too, but that's not the point).

To say that something that's no faster is identical to something that's "1x faster" is a terrible confusion of thought.

It's reasonable to expect that, for example, "1x faster" would mean "for a baseline of 1 operation per second, it's faster by 1 operation per second, i.e. a total of 2 operations per second."

EDIT: Oh god, that's even before I saw the "1.2x slower" entries…

Re: Performance of ES6 features relative to ES5

#39

Post by acdha »

nostrademons wrote: post #35
acdha wrote: post #27

Earlier quoted context omitted.

The main difference is that you the developer can test with a known compiler and know what the performance characteristics are before you release your code: when Microsoft releases VisualStudio 2018, your existing application doesn't change until you rebuild it. In contrast, for code running in a web browser or something like the JVM, your existing code may run faster or slower without you even knowing about the new…

I'm not sure this is true anymore even in this case - with multicore processors, cache dependency, and pervasive virtualization, the speed of your program can be significantly affected by what else is running on the box. Remember that the x86 itself has a JIT on the chip, converting x86 machine code to whatever microcode the processor uses. When I was at Google, they provided special dedicated machines for benchmarki…

That's certainly true and I hope I didn't give the impression that I thought this was a binary situation. It's just that code which runs in a JITed environment, particularly one like the browser JavaScript runtimes which aren't even versioned, has an even wider exposure to skew. Everything running on a multiprocess/user operating system is exposed to resource contention but e.g. your JavaScript code also has to worry about things like Chrome disabling optimizations anywhere you use try/catch.

Re: Performance of ES6 features relative to ES5

#40

Post by goldbrick »

rgrove wrote: post #25
spankalee wrote: post #15

Earlier quoted context omitted.

Chrome doesn't have an interpreter, it has baseline and optimizing compiler. Also, I think try/catch preventing optimization was fixed. Still your point could stand, or additionally there could be many optimizations that interfere with such simple micro benchmarks, turning all or parts of them into no-ops. If this is happening in ES5 and not ES6, the results could be drastic. I suspect this is what's happening with s…

> Also, I think try/catch preventing optimization was fixed. Do you have a source for this? Try/catch deopts still bubble up in my Chrome profiling, so it seems like they're still a problem.

Yes, my understanding is the problem is essentially undefined behavior as exceptions can be caught at any point in the call stack which makes it basically impossible to optimize.
Post reply on HN