Live data from Hacker News

Programming language ray tracing benchmarks project

github.com

11–20 of 90 posts

Re: Programming language ray tracing benchmarks project

#12
post #2

Interesting that Nim is slightly faster than C it considering that it compiles down to C.

That's possibly because of the "Code must follow best practices" restriction.

Oftentimes compile to C is "It's C Jim, but not as we know it"

You can write C as if it is a SSA VM or similar intermediate representation that leaves very little work for the first stages of the compiler.

Re: Programming language ray tracing benchmarks project

#14
Ordered by realtime, fastest to slowest for those like me who got annoyed by the scrolling up and down trying to compare:

  Rust (1.13.0-nightly)         1m32.392s
  Nim (0.14.2)                  1m53.320s
  C                             1m59.116s
  Julia (0.4.6)                 2m01.166s
  Crystal (0.18.7)              2m01.735s
  C Double Precision            2m26.546s
  Java (1.7.0_111)              2m36.949s
  Nim Double Precision (0.14.2) 3m19.547s
  OCaml                         3m59.597s
  Go 1.6                        6m44.151s
  node.js (6.2.1)               7m59.041s
  node.js (5.7.1)               8m49.170s
  C#                           12m18.463s
  PyPy                         14m02.406s
  Lisp                         24m43.216s
  Haskell                      26m34.955s
  Elixir                      123m59.025s
  Elixir MP                   138m48.241s
  Luajit                      225m58.621s
  Python                      348m35.965s
  Lua                         611m38.925s

Re: Programming language ray tracing benchmarks project

#15
post #13

> rustc 1.13.0-nightly what's an ancient version of rust. Interesting it is faster than C, though.

To be fair, The README.md seems to be three years old.

It would actually be quite interesting to see a comparison with all of the languages using more recent builds to see which ones are developing their performance.

Re: Programming language ray tracing benchmarks project

#16

The most impressive result here is Lua -- not far behind C! LuaJIT is amazing. Good to see a few languages like Nim and Rust actually beating C for raw performance, too.

Am I reading it wrong or did LuaJIT take 113x as long as C?

Re: Programming language ray tracing benchmarks project

#17
post #4

I don't think the C# time is representative. I suspect Mono is really slow here. I just ran it with VS 2015 in 1 min 24 sec.

If I'm not mistaken, Miguel himself said that Mono was meant for portability (can run on Linux) and not performance. Would be a far better test to use .NET Core as you could still run this test on Linux or any other place where Core runs.

Re: Programming language ray tracing benchmarks project

#18

The most impressive result here is Lua -- not far behind C! LuaJIT is amazing. Good to see a few languages like Nim and Rust actually beating C for raw performance, too.

Am I reading it wrong or did LuaJIT take 113x as long as C?

It sure looks that slow to me.

Re: Programming language ray tracing benchmarks project

#19
post #7

I am surprised PyPy has such a huge lead over Python. $ time python pyrb.py real 348m35.965s user 345m51.776s sys 0m22.880s $ time pypy pyrb.py real 14m2.406s user 13m55.292s sys 0m1.416s

Raytracing is a pretty great place to apply pypy, you have a very heavy loop that will hit the JIT.

I've certainly seen speedups like that on stuff like project euler code.

Re: Programming language ray tracing benchmarks project

#20
post #17
post #4

I don't think the C# time is representative. I suspect Mono is really slow here. I just ran it with VS 2015 in 1 min 24 sec.

If I'm not mistaken, Miguel himself said that Mono was meant for portability (can run on Linux) and not performance. Would be a far better test to use .NET Core as you could still run this test on Linux or any other place where Core runs.

The one exception to what I initially wrote is if Mono was used to compile to native binary (which is what Xamarin apps for iOS do: compile to ARM binary). You'll get very different results if you go that route but that's going to require different compiler options.
Post reply on HN