5 ms·

That's a really interesting observation on so many levels! Firefox (or rather SpiderMonkey) seems to really be focusing on WebASM performance, and it's easy to

That's a really interesting observation on so many levels! Firefox (or rather SpiderMonkey) seems to really be focusing on WebASM performance, and it's easy to forget just how goddamn fast V8 has made JavaScript...

jsheard 9y ago
It's worth noting that this isn't idiomatic Javascript though, the author is jumping through hoops to avoid ever triggering the garbage collector. Javascript can be very fast if you go down that route but the code gets extremely ugly.
- Klathmon 9y ago
  Isn't most "fast path" code in a GCd language written like this? I've jumped through similar hoops in Go, and even C++ to avoid allocation or GC. The fact that a dynamic language like JavaScript can compile and execute as fast as it does is nothing short of incredible! Even if it's not idiomatic, it's still far from "unreadable".
  - pjmlp 9y ago
    Not if the language supports a mix of value types, off heap allocations or untraced references. There are a few like that.
    - imtringued 9y ago
      Can you name them?
      - pjmlp 9y ago
        Yes, surely. - Eiffel - Oberon family (Oberon, Oberon-2, Active Oberon, Component Pascal, Oberon-07) - Mesa/Cedar - Modula-3 - D - Nim - C# (specially now with 7.2 improvements) - Go - Swift (RC is also a form of GC algorithm) These are just the most well known ones, there are others if you feel like having a dive into SIGPLAN papers. I can also provide examples, how to do it in any of them, if you wish.
- rcfox 9y ago
  What do you consider jumping through hoops? The code looked pretty normal to me.
- bartread 9y ago
  It really depends what you mean by "very fast". For most event driven UI applications JavaScript can certainly be more than fast enough, even on relatively underpowered devices (say, iPhone 5S). With that being said, I recently ported a bunch of data heavy JS calculation code that had previously been running in the browser (and downloading about 100MB of data to the browser to do so - ouch) to run on a .NET back-end. (Ignore the fact that doing this on the client will sound crazy to a professional software engineer but I would argue is totally legitimate in the context of a smart person who is not a software engineer building a prototype with tools they understand, which is what happened.) Now, in doing the port I did improve and optimise the way the calculations were performed: basically I eliminated some redundant operations and structured the data up-front in a way that made it easier to work with. This in itself only sped things up by a factor of 2 or 3. What really gave me the performance boost was taking advantage of the strong typing that languages such as C# offer. Just switching over to using strongly typed dictionaries via generics, and strongly typed arrays, having initially used IDictionary<string, object> (this, because I just wanted to get it working to start off with, and wasn't sure I'd always be working with the same type of data), gave me an extra 75 to 100 times performance boost. In the end the C# version outperformed the JS version by a factor of around 200, mostly due to being able to take advantage of strong typing. And here I'm comparing the classic .NET 4.6 CLR to the latest version of Google Chrome, both running on the same machine. I'm not JavaScript bashing - I use it all the time, and it's good for what it's good for - and V8 is a fantastic runtime, but due to the constraints of the language it simply does not approach the performance of strongly typed languages. I believe I would be able to do even better than the above with C++. Due to the parallelizable nature of the calculations we are considering a switch to CUDA to boost performance further. If you are running performance-critical CPU-intensive code, unless you have to run that in the browser, JavaScript is generally not going to be the right choice. Based on the figures I see for this renderer, neither is WebAssembly. If you do need to run that sort of code in the browser, and you want consistent performance across browsers, then WebAssembly might be[1]. [1] As long as you don't need to support IE11. If you do need to support it I'd suggest you find a way to avoid running large amounts of JS since, whilst its performance is definitely the best of any version of Internet Explorer, it's still not what you'd call fast and doesn't do a great job of memory management.
  - 9y ago
- sniklaus 9y ago
  I initially wrote the raytracer in more idiomatic way. However, I wanted to show my students a side-by-side comparison, demonstrating that the program logic is pretty much the same. Take it as you will, I understand your critique though.
  - djellybeans 9y ago
    Idiomatic will probably entail a lot of objects for the pixel data, I'm assuming? I've seen some raytracers written with arrays of simple "bags" of numbers, which would increase performance. I wrote a real-time 3D polygonal rasterizer in JS that supports texture mapping. After switching from regular arrays to Float32array to store coordinates, it got a huge (~50%) jump in performance.

jsheard 9y ago

It's worth noting that this isn't idiomatic Javascript though, the author is jumping through hoops to avoid ever triggering the garbage collector. Javascript can be very fast if you go down that route but the code gets extremely ugly.

Klathmon 9y ago
Isn't most "fast path" code in a GCd language written like this? I've jumped through similar hoops in Go, and even C++ to avoid allocation or GC. The fact that a dynamic language like JavaScript can compile and execute as fast as it does is nothing short of incredible! Even if it's not idiomatic, it's still far from "unreadable".
- pjmlp 9y ago
  Not if the language supports a mix of value types, off heap allocations or untraced references. There are a few like that.
  - imtringued 9y ago
    Can you name them?
    - pjmlp 9y ago
      Yes, surely. - Eiffel - Oberon family (Oberon, Oberon-2, Active Oberon, Component Pascal, Oberon-07) - Mesa/Cedar - Modula-3 - D - Nim - C# (specially now with 7.2 improvements) - Go - Swift (RC is also a form of GC algorithm) These are just the most well known ones, there are others if you feel like having a dive into SIGPLAN papers. I can also provide examples, how to do it in any of them, if you wish.
rcfox 9y ago
What do you consider jumping through hoops? The code looked pretty normal to me.
bartread 9y ago
It really depends what you mean by "very fast". For most event driven UI applications JavaScript can certainly be more than fast enough, even on relatively underpowered devices (say, iPhone 5S). With that being said, I recently ported a bunch of data heavy JS calculation code that had previously been running in the browser (and downloading about 100MB of data to the browser to do so - ouch) to run on a .NET back-end. (Ignore the fact that doing this on the client will sound crazy to a professional software engineer but I would argue is totally legitimate in the context of a smart person who is not a software engineer building a prototype with tools they understand, which is what happened.) Now, in doing the port I did improve and optimise the way the calculations were performed: basically I eliminated some redundant operations and structured the data up-front in a way that made it easier to work with. This in itself only sped things up by a factor of 2 or 3. What really gave me the performance boost was taking advantage of the strong typing that languages such as C# offer. Just switching over to using strongly typed dictionaries via generics, and strongly typed arrays, having initially used IDictionary<string, object> (this, because I just wanted to get it working to start off with, and wasn't sure I'd always be working with the same type of data), gave me an extra 75 to 100 times performance boost. In the end the C# version outperformed the JS version by a factor of around 200, mostly due to being able to take advantage of strong typing. And here I'm comparing the classic .NET 4.6 CLR to the latest version of Google Chrome, both running on the same machine. I'm not JavaScript bashing - I use it all the time, and it's good for what it's good for - and V8 is a fantastic runtime, but due to the constraints of the language it simply does not approach the performance of strongly typed languages. I believe I would be able to do even better than the above with C++. Due to the parallelizable nature of the calculations we are considering a switch to CUDA to boost performance further. If you are running performance-critical CPU-intensive code, unless you have to run that in the browser, JavaScript is generally not going to be the right choice. Based on the figures I see for this renderer, neither is WebAssembly. If you do need to run that sort of code in the browser, and you want consistent performance across browsers, then WebAssembly might be[1]. [1] As long as you don't need to support IE11. If you do need to support it I'd suggest you find a way to avoid running large amounts of JS since, whilst its performance is definitely the best of any version of Internet Explorer, it's still not what you'd call fast and doesn't do a great job of memory management.
- 9y ago
sniklaus 9y ago
I initially wrote the raytracer in more idiomatic way. However, I wanted to show my students a side-by-side comparison, demonstrating that the program logic is pretty much the same. Take it as you will, I understand your critique though.
- djellybeans 9y ago
  Idiomatic will probably entail a lot of objects for the pixel data, I'm assuming? I've seen some raytracers written with arrays of simple "bags" of numbers, which would increase performance. I wrote a real-time 3D polygonal rasterizer in JS that supports texture mapping. After switching from regular arrays to Float32array to store coordinates, it got a huge (~50%) jump in performance.