I've decided to try & run those on my machine (mbp, 16" 2019, 2,4 GHz 8-Core Intel Core i9, 32gb), and I've got the following times (couple runs each):

# test-js
Raytracer running...
Ray tracing:
 - rendered image size: (1024x1024)
 - elapsed: 1805.3647939562798 ms
 
 
# test-wasm
 Raytracer running...
Ray tracing done:
 - rendered image size: (1024x1024)
 - elapsed: 970.5676089525223 ms

# test-web
Ray tracing done:
 - image rendered at 2x for super-sampled anti-aliasing
 - rendered image size: (1024x1024)
 - elapsed: 1067 ms
 
 # test-rust (lto = false)
 Raytracer running...
Ray tracing:
 - rendered image size: (1024x1024)
 - elapsed: 2143.8712720000003 ms
 
 # test-dotnet
 Raytracer running...
Ray tracing:
 - rendered image size: (1024x1024)
 - elapsed: 915.9425 ms

# test-native (had to change vars to osx-x64)
Raytracer running...
Ray tracing:
 - rendered image size: (1024x1024)
 - elapsed: 949.2975 ms

Seems kinda interesting that dotnet is on par with nodejs, and rust is kinda the slowest. I guess JIT does it work quite well

P.S. the license file is dated 2017 lol

This is a really interesting project! Really nice work :)

I have some small suggestions to improve the Rust performance, and am willing to contribute by creating a PR if you like. I thought it better to post an issue for discussion before opening an unsolicited PR :)

Essentially, it's the following things:

• LTO is not being applied to the release build that we're measuring in the mini benchmark. We have thin LTO enabled, but it's quite a bit faster with full fat LTO and codegen-units=1, possibly due to the code residing in two different modules. This bumps the performance of the WASM build a little too.
• For the test-rust native target, there's a significant performance improvement if we allow LLVM to target more recent hardware; by default it's just doing the "generic" baseline x64 instruction set, i.e. SSE, but no AVX / AVX2 etc.
  • This may need some discussion -- it's debatable whether we should just set the target-cpu flag to native and compile for the exact machine, or whether it's more representative to target something more generic (but supporting AVX2) like the x86-64-v3 target.
  • The same applied to the ARM builds, although I don't know offhand what a good representative target would be there.
• Benchmarks for the normal (JIT) dotnet are more representative if we run the benchmark a few times in a loop.

On the main branch, I'm getting results that look like this currently:

• test-rust: 775 ms
• test-wasm: 1060 ms
• test-dotnet: 900 ms

With the above applied, and after a 10 iterations or so for the dotnet JIT to settle:

• test-rust: 542 ms
• test-wasm: 925 ms
• test-dotnet: 720 ms

If this looks like a useful contribution, let me know and I'll open a little PR to add the required configs.

This produce EXE of 2.5Mb after strip executable from debug symbols. Without strip it's 9Mb size, still notably smaller then with reflection. Execution speed about same as .NET, but on Linux perception that startup time is faster even if I add --no-build.

Slap <IlcOptimizationPreference>Size</IlcOptimizationPreference> and you get NativeAOT version run faster by ~10%. It will shave 150ms from 1312ms to 1168ms (-10%) (I do have very old laptop)

This is just to make sure that NativeAOT is compiling in your repo without much friction.

A lot of people tend to like visual demostration, so that's that (before merging will need to adjust url - change the repo name & branch name) You can view it working t https://github.com/delneg/fable-raytracer/tree/feat/readme-img

This downloads Fable as a dotnet tool instead of using a local build to make it easier for users.

@ncave It seems that the npm run test-rust target can only be run after npm run test-web (or test-wasm). Apparently it need the files from fable-library-rust in fable_modules in the repo root, but the other files must be in out dir to avoid file name conflicts. Wasn't sure how to fix that.

This small constribution adds a new run script: npm run test-rust-target-cpu. It does the same as npm run test-rust, but allows Rust to target the current host machine's CPU. I've updated README.md too. This relates to #6.

It was a bit of a fiddle to get it working on Windows too, since the usual approach of setting an environment variable for RUSTFLAGS isn't quite as easy. Luckily Cargo has a --config argument we can use to achieve the same objective.

Hello again, I've ported it to iOS just for fun: https://github.com/delneg/fable-raytracer-ios-net6

So now it's F# -> Rust -> static library -> F# DLL Import -> iOS Most interesting bits are in https://github.com/delneg/fable-raytracer-ios-net6/blob/master/FableRustRaytracerNet6iOS/AppDelegate.fs

• Yes, it's slow. But added for completeness (and to show that Python can be awfully slow for tight loops like this).

PS: Needs a new Fable release to compile correctly, i.e 4.0.0-theta-019

❯ python main.py
Raytracer running...
Ray tracing done:
 - rendered image size: (1024x1024)
 - elapsed: 94554.139777 ms