Scala.js Ray Tracer | Hacker News Reader

Scala.js Ray Tracer

lihaoyi.github.io

42 pointslihaoyi16 comments

Here's a high resolution pre-computed verison, in case anyone wants to see it but doesn't want to wait for it to render

https://www.dropbox.com/s/pmg84wj0eufb3ur/Screenshot%202014-...

you might like to add your benchmark to this: https://github.com/kidoman/rays

I find it interesting to compare this compiled JS to the tiny recursive Ray Tracer previously posted here on HN [0]. This Scala->JS compilation is 214k characters while the tiny Ray Tracer is at <1k characters. It should be noted that the tiny Ray Tracer is heavily optimized and minified.

[0] http://www.gabrielgambetta.com/tiny_raytracer.html

ScalaJS is still in its infancy, I wouldn't expect miracles at this point, particularly in terms of generated JS file size. Note the _experimental_ disclaimer in ScalaJS' home page: http://www.scala-js.org

Assume optimizations will come with time, for now it's pretty cool that one can work in a more or less completely type safe environment on both client and server with Scala.

p.s. muddling along with Coffeescript + GruntJS for the time being, but look forward to working in pure Scala once the library stabilizes.

Yeah this is a great effort that will have a really big upside for developers like me using Play! framework. It means I can define my transfer types in Scala and share them between client and server in a typesafe way. Currently that takes lots of testing to keep the javascript side honest in what it's sending.

The source-code linked is only 279 lines of Scala code, including blanks and comments and the code is very readable [1]. However, it is using Scala's standard library, which is somewhere at 16.5 MB - 18.5 MB, depending on version. That the minified code is 209 KB (50 KB gzipped), I find that awesome, as it means that the compression / tree shaking done is pretty aggressive, much better than what people can do by hand. Under the hood Scala.js does optimizations of its own, before passing the result to Google's Closure compiler in advanced mode.

https://github.com/lihaoyi/workbench-example-app/blob/ray-tr...

I ran this in Chrome, Safari 7 and Firefox. Firefox was the slowest of them all by quite some margin. I guess asm.js specific code enables some drastic speedups with less effort from the JIT's point of view. Too bad this code did not utilize asm.js.

> Too bad this code did not utilize asm.js.

The goal of asm.js is to efficiently compile C/C++ into JavaScript using Enscriptem,it's not meant to be written by hand.

I doubt the Scala to JavaScript transpiling is done by hand.

Compiling a high-level level like Scala to asm.js does not make sense, as asm.js is meant for lower level languages (e.g. C++), not managed languages, although it might be in the future ... http://asmjs.org/faq.html

I totally transcribed it by hand. The transcribed sources (http://lihaoyi.github.io/workbench-example-app/raytracer-opt...) are completely readable

Scala is a garbage collected language like Java, not really a good target for asm.js.

I fail to see why. It is only a matter how good the GC would be.

I think it would be rather inefficient, that is, not very useful. What would be the gain? Languages like Java have shown that AOT compilation doesn't really benefit them very much over runtime JIT. C->asm.js makes a lot of sense, but I'm not sure it would be very much of a win for Java or Scala, especially non-math heavy apps.

It is just that I think it is mostly a matter of how much performance one would be able to get from it. Just thinking out loud.

On the other hand, implementing a GC system on top of another one is probably not the best way to spend time.

You can make use of LLJS.

Reply on news.ycombinator.com