4 ms·

The author also measures .net core, which has the best performance of them all. I believe that is also running non native. Moreover, the core assumption that n

by memset 11y ago

The author also measures .net core, which has the best performance of them all. I believe that is also running non native. Moreover, the core assumption that native == faster is not true. One advantage of the jvm is that as a program runs, the runtime can internally profile and adjust the byte code on the fly in order to increase performance.

travjones 11y ago
Hey! Yeah, I just noticed the author added .Net core (this wasn't apart of the benchmarks when it was first posted to HN). I agree that the assumption is violated. On the topic of native code though, check out the numbers for .Net core on Win 8.1 vs. Mac OS X (almost 3x faster on Windows, which is expected).
- wizzard0 11y ago
  (dotnetcore version author here) Please note that Windows and OS X is benchmarked on different CPUs! You're welcome to re-test at dual-boot MacBook together so we can meaningfully compare OS X/Windows
  - deleted 11y ago
    [deleted]
radicalbyte 11y ago
If anything is unfair it's that they're using long ints. Java (and I assume other JVM languages) have the overhead of allocation for most of the longs. Testing with allocation in all languages will give a better idea of performance (and I won't be surprised if .Net core fares very well).
- dtech 11y ago
  JVM has primitives for longs
benashford 11y ago
Is the .NET version actually spawning any threads at all? It uses Tasks to collect the results, but all the work is done in the main thread by the looks of it.
- wizzard0 11y ago
  .NET version has 2 variants for exactly this reason :) Single-thread version is fastest of course.
  - Matthias247 11y ago
    The async version also doesn't spawn as much Actors/Threads/whatever than all other implementations. It only runs the Task.WhenAll continuation in the ThreadPool - and probably even that not because it can recognize that all child tasks are ready and execute the continuation synchronously. The leaf tasks, whose amount is the biggest, are only synchronous function calls that return a fulfilled task instead of spawning anything. A fair comparison should use at least use something like `Task.Run()`, which would make it a lot slower. And then you can make it a lot faster again by using a custom TaskScheduler. I think there are by far too many knobs to turn to make this comparison meaningful.
    - wizzard0 11y ago
      Updated to use Task.Run, got only 15% perf decrease, which can be due to the delegate creation too...
      - Matthias247 11y ago
        That was a quick update! Looks better now. I would have expected the difference to be much bigger. I made some similar comparison about a year ago (with normal .NET), and it performed slower than Go. However with a custom Actor implementation (similar to the Scalaz implementation) I was a lot faster. F# with the Hopac library also performed very good.
bboreham 11y ago
.Net is compiled to native code, either jit or at deployment time.

by memset 11y ago

travjones 11y ago

Hey! Yeah, I just noticed the author added .Net core (this wasn't apart of the benchmarks when it was first posted to HN). I agree that the assumption is violated. On the topic of native code though, check out the numbers for .Net core on Win 8.1 vs. Mac OS X (almost 3x faster on Windows, which is expected).

wizzard0 11y ago
(dotnetcore version author here) Please note that Windows and OS X is benchmarked on different CPUs! You're welcome to re-test at dual-boot MacBook together so we can meaningfully compare OS X/Windows
- deleted 11y ago
  [deleted]

radicalbyte 11y ago

If anything is unfair it's that they're using long ints. Java (and I assume other JVM languages) have the overhead of allocation for most of the longs. Testing with allocation in all languages will give a better idea of performance (and I won't be surprised if .Net core fares very well).

dtech 11y ago
JVM has primitives for longs

benashford 11y ago

Is the .NET version actually spawning any threads at all? It uses Tasks to collect the results, but all the work is done in the main thread by the looks of it.

wizzard0 11y ago
.NET version has 2 variants for exactly this reason :) Single-thread version is fastest of course.
- Matthias247 11y ago
  The async version also doesn't spawn as much Actors/Threads/whatever than all other implementations. It only runs the Task.WhenAll continuation in the ThreadPool - and probably even that not because it can recognize that all child tasks are ready and execute the continuation synchronously. The leaf tasks, whose amount is the biggest, are only synchronous function calls that return a fulfilled task instead of spawning anything. A fair comparison should use at least use something like `Task.Run()`, which would make it a lot slower. And then you can make it a lot faster again by using a custom TaskScheduler. I think there are by far too many knobs to turn to make this comparison meaningful.
  - wizzard0 11y ago
    Updated to use Task.Run, got only 15% perf decrease, which can be due to the delegate creation too...
    - Matthias247 11y ago
      That was a quick update! Looks better now. I would have expected the difference to be much bigger. I made some similar comparison about a year ago (with normal .NET), and it performed slower than Go. However with a custom Actor implementation (similar to the Scalaz implementation) I was a lot faster. F# with the Hopac library also performed very good.

bboreham 11y ago

.Net is compiled to native code, either jit or at deployment time.