Yes, but when you write in a high-level language like javascript without taking advantage of all of the high-level features like webgl (which are provided by the implementation and assumed to be fast), performance suffers.
In this case, Notch is writing code that doesn't necessitate the overhead of using JS. It could easily be rewritten as C and probably run faster that way. Not that it isn't interesting, of course.
It's JIT compiled and WebGL shaders are compiled as well. It is a native code executable on CPU, read how Crankshaft in V8 works.
It's true that JS is at the moment N times slower than C++ (N in range 1 to 10). It's not true that you need to use JS that much to have great graphics. Everything you pointed out is done on GPU afaik.
And if you wait a year or so, JIT + type inference will make JS basically as fast as C++.
WebGL runs at basically full speed on the GPU. And JS can run at about half the speed of native code, when compiling a C++ codebase like we are talking about here.
So this would be far faster than typical 2006 perf.
> and access to all source code.
Look at optimized+minified compilation output in JS, it is just as unreadable as a native binary.
BUT maybe it does not matter that much for some projects and a lot of people can write some logic in js a lot faster than in C (or C++ or Rust or..).
Also, there are a lot of people who know only js and would like to "play" with some LED, fetching room temperatures, opening closing doors etc - this is a nice way to start.
C is always going to be faster than almost anything you compare it to, of course. But the V8 interpreter is also not 5000% slower; for computationally intensive tasks it's not actually significantly slower. The problem in OP's case is that JS lacks an interface to interact with the display and render that is as "close to the metal" as their "native" counter parts. You are drawing sprites on a html canvas which is then rendered by a web view, which just not that great no matter what language you use to get there.
What I'm getting at is that it's easy to blame Javascript, but really that's not the whole picture, and if Google and Apple chose to support Javascript natively it wouldn't have these dramatic performance issues.
I am still a little skeptical about this new language. It is not so hard to to write optimizable JS. And when you need a real performance boost, most of such tasks are parallelizable, so you can use low-level WebGL or WebCL.
I've had a lot of conversations with javascript engineers over the years who've argued to me that well tuned JS will be nearly as fast as the equivalent C code. I've written plenty of little toy benchmarks over the years, and in my experience they're partly right. Well written JS code in V8 can certainly run fast - sometimes around half the speed of C code. But a massive performance gap opens up when you use nontrivial data structures. Nested fields, non-uniform arrays, trees, and so on will all cripple javascript's performance when compared to C's equivalent of simple embedded nested structs. If you couple clean C data structures with allocation-free hot paths from arenas, the performance of C will easily hit 10-20x the performance of the equivalent JS code.
From memory my plain text based operational transform code does ~800k transforms / second in javascript. The equivalent C code does 20M/second. The C implementation is about twice as many lines of code as the JS version though.
Well-optimized C is likely to always be faster than well-optimized JavaScript.
It is also possible that circuitlab is not well-optimized JavaScript.
I will say that it also depends on the problem domain. You can make a fast 3D game in JavaScript because WebGL does hardware acceleration of the graphics. You can also make a fast todo list in JavaScript because, well, it's a todo list :)
The alternatives like ASM.js and PNACL are far from usable. ASM.js has no support for threads and PNACL is unlikely to be supported outside of Chrome. They also have no debugging support.
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 be rendered on the web in 20+ FPS, at least until WebGL2/WASM/WebGPU get better support.
But JavaScript is fast enough. Because the vast majority of programs, especially websites, don’t need really fast code like C. They don’t need to redraw every frame, don’t need 3D capabilities, don’t need to perform expensive computations, etc.. If you need a fast program that does those things 99.9% of the time you can just make it a real app, or you can write the fast parts in WebAssembly.
At the end of the day computers are very fast, so a program could be written in any language as long as it isn’t doing anything super performance-needing and the compiler/interpreter has has half-decent optimization.
> It's an example of the truly extraordinary performance of JavaScript. It really does get very close to C/C++ performance
Yes I can attest to that. In my day job I write JS code that processes images in 2D. Processing images, even of a high resolution through simple algorithm is perfectly doable at 60 fps in JS. You just have a to be careful to what you do but that's pretty much true for any language.
Recently, I implemented a bilinear interpolation in JS, C (wasm) and WebGL. The C version was only marginally faster than the JS version even though the whole set of optimization was on. Sure native C would probably be significantly faster but then you wouldn't compare languages but runtimes.
Now we are getting somewhere ;) Graphics are not an issue, physics may be. Still, you would be surprised how fast compiled JS can be. It requires some discipline but if your code is good, performance is not that bad. And some data structures are actually waaay easier and smaller in JS (e.g. graphs). These are pros and cons of high level language.
By the way, there are also typed arrays which are translated directly to native code and were designed with WebGL in mind. I'd say that garbage collector is now the biggest issue of JS games. But it's improving, don't be skeptic.
EDIT:
Actually, I did a small lecture a week ago, about performance tips. It's probably far from perfect as I don't work on browser engines, but it may give you some hints about making JS performance C++-like.
http://www.smashinglabs.pl/lectures/js-performance/
JS is really fast assuming you don’t do anything in JS is not a convincing argument for this.
My point is that if you are using JS as a wrapper for a big black box of gpu computations that are close to the metal then you are not really using JS in any meaningful sense and can wrap anything else that has a much better library ecosystem and performance qualities for anything that you’re not just getting the gpu to crank out in a server context (which is implied by nodejs).
There’s the speed of generating inputs, the speed of transforming and passing data at the input/output boundaries, and the ability to conveniently and performantly work with data in memory natively (i.e. while not outsourcing the computations elsewhere) that matters here. Is JS a great choice for any of these things? Most importantly, the last thing? This library isn’t using ArrayBuffers for setting up all data or working on the data in JS so even if they work great for performance it seems totally irrelevant and let’s be honest, if it were working with ArrayBuffers directly you would be so far away from usual JS and any convenience JS offers, you might as well not be writing JS.
This isn't JavaScript being as fast as C++, it's writing critical sections in a low-level language being as good as writing the whole app in a low-level language.
Well, first, even assuming JITing JavaScript is expensive and produces expensive code, shouldn't WebGL demos mostly stress the GPU and not the CPU?
Second, web sites are not allowed to execute native code, but all the modern JavaScript engines compile down to native code. My intuition tells me to expect the performance of compiled JavaScript to be low, however I have seen endless benchmarks that say that's not the case and JITed JavaScript should be plenty fast.
However I feel this disconnect between those benchmarks and reality. The benchmarks say it's fast, while in fact I perceive it to be pretty slow and a resource hog.
> Well, I could agree if I saw any computational-heavy JS application (and not a microbenchmark) doing well compared to native counterpart, especially on multicore.
For example, BananaBread compiles 120,000 lines of code of a C++ 3D game engine, including AI and physics and so forth. It also uses 3 cores during startup processing
The difference between JavaScript and C++ is less than one order of magnitude, and note that this is a hard case to optimize for JS engines since LLVM inlining creates huge functions that JS engines just give up on optimizing currently. So that the game ends up still running as fast as it does in JS is a nice surprise.
There are also lots of other compiled examples of real-world code, like Box2D and Bullet. Typically the speed of JS compared to C is 5X-10X slower, again, much of it because of large functions not being fully optimized.
In this case, Notch is writing code that doesn't necessitate the overhead of using JS. It could easily be rewritten as C and probably run faster that way. Not that it isn't interesting, of course.
reply