It might be nice to include JRuby, since we appear to be faster than all recent CRuby versions.

On my system (using OpenJDK 11):

[] ~/projects/raytracer/ruby $ rvm ruby-2.7.0 do ruby RayTracer.rb 
Completed in 20886.185999999998 ms

[] ~/projects/raytracer/ruby $ rvm ruby-3.0.2 do ruby RayTracer.rb 
Completed in 16813.604000000003 ms

[] ~/projects/raytracer/ruby $ rvm jruby-9.3.0.0 do ruby RayTracer.rb 
Ignoring executable-hooks-1.6.1 because its extensions are not built. Try: gem pristine executable-hooks --version 1.6.1
Ignoring gem-wrappers-1.4.0 because its extensions are not built. Try: gem pristine gem-wrappers --version 1.4.0
Completed in 13248.208 ms

[] ~/projects/raytracer/ruby $ rvm jruby-9.3.0.0 do ruby -Xcompile.invokedynamic RayTracer.rb 
Ignoring executable-hooks-1.6.1 because its extensions are not built. Try: gem pristine executable-hooks --version 1.6.1
Ignoring gem-wrappers-1.4.0 because its extensions are not built. Try: gem pristine gem-wrappers --version 1.4.0
Completed in 7894.947999999999 ms

If this scales the same way on your end it would put the JRuby results somewhere between HHVM and PHP, which I'd like to see. 😀

I can't seem to find anything about License: https://github.com/edin/raytracer/search?q=License

I would like to incorporate some of the code here but I don't know if I can.

There are 14 forks, but I don't know if they are allowed.

Hi! Interesting benchmarks 👍

But I see you are using some deprecated switches for D.

For example "noboundscheck" should be "boundscheck=off".

You're also using a lot of classes instead of structs (compared to the C++ version). If you don't want (don't have time) to change it to structs, consider adding the final keyword before class to make the comparison a bit fairer (vtable) :)

Thanks!

Both Kotlin/JVM and Kotlin/Native would be nice :)

These languages don't have results:
Zig
V
Swift
Haskel
Ada

I'm interested in the Ada version. It's easy to test in Ubuntu/Debian. Install packages gprbuild and gnat-12 and run gprbuild -p raytracer.gpr.

In going over the revised Rust version from a couple of days ago, the compiler says test_ray function not used, though the image does not appear affected because of it.

    fn test_ray(&self, ray: &Ray) -> Option<f32>
    {
        let intersect = self.intersections(ray);
        return match intersect {
            Some(result) => Some(result.dist),
            None => None
        }
    }

In the Ruby, Crystal, et al version it was used in

  def addLight(col, light, pos, norm, scene, thing, rd)
    ldis  = Vector.minus(light.pos, pos)
    livec = Vector.norm(ldis)
    neatIsect = self.testRay(Ray.new(pos, livec), scene)
   ...
 end

In Nim as

func getNaturalColor(scene: Scene, sp: SurfaceProperties,
  pos, rd, norm: Vector): Color =
  var rdNorm = rd.norm()
  for light in scene.lights:
    let
      ldis = light.pos - pos
      ldisLen = ldis.len()
      livec = ldis.norm()
      neatIsect = scene.testRay(pos, livec)
      ...

When I ran the C code version, it produces a bad *.bmp file of 1,000,102 bytes, which doesn't show an image.
Also, while the Rust code produces a viewable image, the image has different shading from all the others.

Here are comparisons with other *.bmp files that produce correct viewable images.

➜  raytracer ls -al *bmp
-rw-rw-r-- 1 jzakiya jzakiya 1000054 Apr 10 01:28 cpp-raytracer.bmp
-rw-rw-r-- 1 jzakiya jzakiya 1000102 Apr 10 01:28 c-raytracer.bmp
-rw-rw-r-- 1 jzakiya jzakiya 1000054 Apr 10 01:27 d-raytracer.bmp
-rw-rw-r-- 1 jzakiya jzakiya 1000054 Mar 25 11:59 julia-ray.bmp
-rw-rw-r-- 1 jzakiya jzakiya 1000054 Mar 24 17:04 nim-raytracer.bmp
-rw-rw-r-- 1 jzakiya jzakiya 1000054 Apr 10 01:28 nim-RayTracer.bmp
-rw-rw-r-- 1 jzakiya jzakiya  750054 Mar 15 12:43 ruby-raytracer-266.bmp
-rw-rw-r-- 1 jzakiya jzakiya  750054 Mar 15 12:35 ruby-raytracer-272.bmp
-rw-rw-r-- 1 jzakiya jzakiya  750054 Mar 15 12:51 ruby-raytracer-jruby9.2.16.0.bmp
-rw-rw-r-- 1 jzakiya jzakiya  750054 Mar 24 16:54 rust-raytracer.bmp

The original (corrected) parallel Rust version created correct images when run either sequential|parallel.

The modified version, which changed the Vector math implementation, no longer creates correct images.

I'm trying to build the Fortran version and have run into some problems.

raytracer> gfortran --version
GNU Fortran (PCLinuxOS 10.3.0-1pclos2021) 10.3.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

When I use the build instructions I get this error.

raytracer> gfortran.exe main.f95 -O3 -o FRay.exe
zsh: command not found: gfortran.exe

When I ran it without the .exe it gives a missing library error.

raytracer> gfortran main.f95 -O3 -o FRay.exe 
/usr/bin/ld: cannot find -lquadmath
collect2: error: ld returned 1 exit status

For Crystal, please add the --release compiler option to optimize speed.

crystal build RayTracer.cr --release

Thank you for updating some of the timings.

When you have time, can you also update the LOCs too.

After #4 was merged, Nim version should not take 1500ms anymore to run

Python appears to be the only language to use external library PIL to write the bitmap out. This makes it significantly shorter then other languages.

I think to be fair to other languages in the lines of code benchmark Python should not use PIL and write the .bmp like the other languages.

Nim's implantation has double empty lines and comments other languages do not have. If Python is forced to write out the bitmap and Nim's code is cleaned up I think Nim might be able to take the top spot in both speed and shortness.

I see a number of the language versions have been upgraded.
I've done an optimized version of the original Ruby implementation that mimics Crystal.
How should I submit the new Ruby code to you?