-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Proposal] Add some timings #1
Comments
Thanks, I was testing on macos, maybe that's why it's slower |
What exactly is the test-dotnet running, NativeAOT ? I.e. are you uncommenting fable-raytracer/fable-raytracer.fsproj Line 19 in 014db00
|
@yowl That should be enough, but if not, follow the MS instructions for NativeAOT. There is also a NativeAOT-LLVM branch but I haven't tried it. Overall, I got more or less the same performance from NativeAOT as normal (jitted) .NET 6.0 (for this specific demo, which is numeric-heavy). The native binaries it produces are quite large, so I didn't bother trying to make a cross-platform script to build/run it. I haven't tried it with .NET 7 either, so YMMV. |
Some more results with an M1 Mac (aarch64):
|
@alfonsogarciacaro |
Thanks for letting me know @ncave. This is a good thing to remember to avoid the mantra that GC destroys performance and we forget that passing by value also has a cost :) Even if Rust is not much faster that .NET I think it's still very valuable to be able to compile F# to native/wasm through Rust and generate small binaries without the full .NET runtime. And of course, having the potential to get better performance by improving the generated Rust from the same F# code is a big plus 👍 |
Btw, chatting with .net JIT developer Egor some time ago, he mentioned that optimal struct size is 64b (4 fields), anymore than that and you typically lose more than you gain. |
In the generated Rust code we're passing in everything by reference, so size normally should not matter for function parameters. But this particular type is a function return type (returned by value), so size does matter. But, it was already a reference type in the Rust code, so Rust times didn't change, only .NET times were improved. Usually it's a bit more nuanced than this, with speculative execution, data locality, caches and GC pressure all interacting to complicate things. |
I added the original Raytracer sample from the Typescript playground (it seems to be deleted now). These are the results in my machine, I get the best timing out of 4 runs. The code always renders the same 1024x1024 scene in all cases. Browser (Chrome)
CLI (Ubuntu on Windows WSL2)
|
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):
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
The text was updated successfully, but these errors were encountered: