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

We've been lied to: JavaScript is fast

jyelewis.com

Post reply on HN
Print view View original

71–80 of 86 posts

Re: We've been lied to: JavaScript is fast

#71

Post by mohanmcgeek »

mc13 wrote: post #44
mohanmcgeek wrote: post #2

I've never heard anyone tell me that JavaScript is slow. I remember node.js benchmarks in the front page of hn showing it to be as fast as hotspot jvm. And this was pre 2012. And since node is single threaded, you had to run n.cores instances of your app. For the longest time as a kid what I was lied to was that Java was much slower than Ruby/Python and my perception was painted by the startup times.

Java is probably 10 times faster than JS and Pyrhon.

> Java is probably 10 times faster than JS

I don't wish to start a language flame war here. We're beyond that.

But by what measure? Doesn't this depend on what you're doing?

Re: We've been lied to: JavaScript is fast

#72

Post by genewitch »

pyentropy wrote: post #25
armchairhacker wrote: post #12

JavaScript is still really slow compared to compiled languages - C, C++, even Java. That super-simple benchmark even after JIT is still 2-3x as slow as the C version, and more complex code can’t be optimized nearly as well. I can confidently say that games and apps in the browser and Electron are noticeably slower than other apps. You don’t see many web games because the graphics required for games today can’t really…

Electron apps are memory heavy and slow at interaction because Chromium loads a ton of rendering and Web API code into memory, and interactions triggered by keyboard/mouse/touch input go through layers of non native handlers so that event listeners behave uniformly across devices. It's all part of a complex rendering loop, and whether an element has a fixed position during scroll can affect memory and performance by…

All that stuff in your last point is for telemetry, isn't it? That is, fingerprinting.

Re: We've been lied to: JavaScript is fast

#74

Post by pbadenski »

pizlonator wrote: post #23

Those are some really bad benchmarks. JavaScript is probably like 10x or 100x slower than C or similar languages when you write something bigger and any of the following happens: - the ratio of code size to run time is too big. Then the jit can’t keep up. - you use a lot of value types. Them be structs in C, no need for allocation. In JS them be objects. The JS VM will try to escape analyze them, and it will succeed…

To what extent writing your code in WebAssembly (eg Rust) can help with those points (eg structs in C argument). It would still run in a JS VM so I'm guessing a bit, but not to the full extent?

Re: We've been lied to: JavaScript is fast

#75

Post by pizlonator »

pbadenski wrote: post #74
pizlonator wrote: post #23

Those are some really bad benchmarks. JavaScript is probably like 10x or 100x slower than C or similar languages when you write something bigger and any of the following happens: - the ratio of code size to run time is too big. Then the jit can’t keep up. - you use a lot of value types. Them be structs in C, no need for allocation. In JS them be objects. The JS VM will try to escape analyze them, and it will succeed…

To what extent writing your code in WebAssembly (eg Rust) can help with those points (eg structs in C argument). It would still run in a JS VM so I'm guessing a bit, but not to the full extent?

WebAssembly helps a lot, but doesn’t solve the jit issue.

WebAssembly also introduces its own issues since it’s a BYORT system (bring your own runtime). So, there’s more to JIT (your language’s whole runtime) and more to hold in memory (your language’s whole runtime). You might say, “but pizlonator, every language has a runtime”, to which I’d say: yes but usually that shit gets shared by every running instance somehow. In WebAssembly every instance pays for its runtime’s memory footprint and it’s quite likely that every instance has a different runtime so the code isn’t shared either. Basically, WebAssembly is knee-capped on memory footprint by design. JS isn’t.

Re: We've been lied to: JavaScript is fast

#76

Post by pizlonator »

titzer wrote: post #38
pizlonator wrote: post #23

Those are some really bad benchmarks. JavaScript is probably like 10x or 100x slower than C or similar languages when you write something bigger and any of the following happens: - the ratio of code size to run time is too big. Then the jit can’t keep up. - you use a lot of value types. Them be structs in C, no need for allocation. In JS them be objects. The JS VM will try to escape analyze them, and it will succeed…

I've been thinking a lot about this over the years. Having been a dyed-in-the-wool Java VM person for years, and then also working on JS, I started to see the marketing speak I blabbed for years just kind of disappear in the face of huge applications. JavaScript, Java, C#, generally all JITed languages will eventually end up exhausting the size of their JIT code caches. You just gotta hope that your hot paths are con…

What do you mean by exhausting jit caches? Do other VMs limit their size somehow? JSC basically doesn’t.

That doesn’t solve the problem of course. I have this metric that I use to philosophize about this: SIPS, or static instructions per second. If your program has low SIPS (I.e. it’s the benchmark of HotSpot’s wet dreams or OP’s post) it means that the total code is small and it runs a long time - so the JIT will go on a rampage early on and then you’re good. If the program has high SIPS, then the JIT will still be catching up when the program terminates. Most real things that aren’t web servers have low SIPS.

Re: We've been lied to: JavaScript is fast

#77

Post by brundolf »

josephg wrote: post #58
brundolf wrote: post #27

Earlier quoted context omitted.

> I can confidently say that games and apps in the browser and Electron are noticeably slower than other apps In my experience the great majority of perceptible slowness in browser apps comes from DOM reflows, not JavaScript

I’ve also seen plenty of web apps which load slowly because they load too much javascript. Most of it unused. I was asked to help out with one project my coworkers were working on where the bundler was pulling in multiple copies of momentjs, each complete with its own copy of the global time zone database. The page loaded way faster once we cleared that out. A few years ago I noticed most websites just seemed slower…

Loading assets != running JavaScript, which is what we're talking about here. It's also a difference between startup slowness and long-running slowness. And Electron, for example, would (normally) only ever be "loading" JavaScript from disk, like any other local app would.

Re: We've been lied to: JavaScript is fast

#78

Post by tored »

jeroenhd wrote: post #59
rileymat2 wrote: post #8

In the past when I have written basic benchmarking code like the first example, the compiler will typically optimize all the code away. I am curious why this did not happen or what optimization flags were passed in. If it was prevented optimization through flags, is this a fair test?

I've run the C example code through Godbolt with -O2 and... it removed all the loops because the result wasn't used. Then I added a printf statement and the algorithm came out without too many strangeness. When I reduce the amount of iterations, the compiler inserts a constant where the calculation would've taken place. The amount of iterations in the benchmark seems to be too high for the compiler to evaluate and op…

PHP

    $numbers = [];
    for ($i = -10000000; $i  0 && $i
1.08 seconds

PHP Optimized

    $lowest = PHP_INT_MAX;
    foreach (range(-10000000, 10000000) as $i) {
        if ($i > 0 && $i
0.56 seconds

Make sure to enable JIT (tracing)

Node for loop version for me took 1.25 seconds (I have a very old rig)

php --version

    PHP 8.0.11 (cli) (built: Sep 21 2021 18:25:57) ( NTS Visual C++ 2019 x64 )
    Copyright (c) The PHP Group
    Zend Engine v4.0.11, Copyright (c) Zend Technologies
        with Zend OPcache v8.0.11, Copyright (c), by Zend Technologies
node --version

    v16.1.0
Note: I measured time within the script and not outside to avoid any bootup time.

Re: We've been lied to: JavaScript is fast

#79

Post by recursive »

JoeBot3000 wrote: post #16
recursive wrote: post #15

The second code comparison is supposed to point out that the second version. Unfortunately, still not easy enough to read to avoid bugs caused by javascript's "unique" approach. `findSmallestPositiveValue([2,11])` gives the wrong value for the supposedly better function. > Even if the second function takes twice as long as the first, we are in the realm of nanoseconds. How can you possibly know this? You can make eit…

> You can make either function take arbitrarily long by increasing the size of the input. The second one scales worse. I think this is the point, the second one scales worse - absolutely (ignoring the bug you mentioned) however it really is more readable, and because V8 is so fast, why not use the second version? Block comments and function names are important, but if someone needs to modify the code to add or change…

You can use .reduce((acc, curr) => curr > 0 && curr In some cases, there are persuasive arguments to favor readability over performance, but I don't find this particular example very convincing.

Re: We've been lied to: JavaScript is fast

#80

Post by jeroenhd »

tored wrote: post #78
jeroenhd wrote: post #59

Earlier quoted context omitted.

I've run the C example code through Godbolt with -O2 and... it removed all the loops because the result wasn't used. Then I added a printf statement and the algorithm came out without too many strangeness. When I reduce the amount of iterations, the compiler inserts a constant where the calculation would've taken place. The amount of iterations in the benchmark seems to be too high for the compiler to evaluate and op…

PHP $numbers = []; for ($i = -10000000; $i 0 && $i 1.08 seconds PHP Optimized $lowest = PHP_INT_MAX; foreach (range(-10000000, 10000000) as $i) { if ($i > 0 && $i 0.56 seconds Make sure to enable JIT (tracing) Node for loop version for me took 1.25 seconds (I have a very old rig) php --version PHP 8.0.11 (cli) (built: Sep 21 2021 18:25:57) ( NTS Visual C++ 2019 x64 ) Copyright (c) The PHP Group Zend Engine v4.0.11, C…

All of my measurements included bootup time but PHP took way longer. I guess I don't have JIT enabled, then, because the code is near identical.
Post reply on HN