That JavaScript and Swift have essentially the same performance here is extremely telling: there are essentially four performance regimes (five if you count Python, but clearly from the graphs you should not ;P), and what would really be interesting--and which this page isn't bothering to even examine?! :(--is what is causing each of these four regimes. I want to know what is so similar about C# and Go that is causing them to have about the same performance, and yet much more performance (at higher batch sizes) than the regime of Java/OCaml/Haskell (a group which can't be explained by their garbage collectors as one of the garbage collectors tested for Java was "don't collect garbage" and it had the same performance). It frankly makes me expect there to be some algorithmic difference between those two regimes that is causing the difference, and it has nothing to do with language/runtime/fundamental performance.
Swift spends 76% of the time incrementing/decrementing reference counts; ARC is just very bad at pushing tens of millions of objects through it every second.
It's just a coincidence that JavaScript and Swift end up with almost the same performance; there is nothing similar between these two runtimes and implementations.
The problem is that 99% of all Swift developers use the language to create front-ends for powerful devices and you never need to squeeze the last drop of performance out of them.
> I want to know what is so similar about C# and Go that is causing them to have about the same performance, and yet much more performance (at higher batch sizes) than the regime of Java/OCaml/Haskell […] and it has nothing to do with language/runtime/fundamental performance.
The authors specifically call out the issue of avoiding heap allocations when asked about Java v C# (as they're pretty similar languages), noting that they couldn't get under ~20 bytes allocated per forwarded packet in Java. C# (and Go) would have much better facilities to work entirely out of the stack, avoid memory copies and reuse allocations in the main loop.
> want to know what is so similar about C# and Go that is causing them to have about the same performance.
I looked at the C# thesis. I think with care the programmer was able to reduce the amount of heap allocations and memory copying enough that it's similar to the mix in the go driver. I think also the modern processors ability to execute multiple instructions/code paths in parallel tend to negate the advantage efficiently compiled languages like C and go. So cache misses, heap allocation, and garbage collection tend to dominate over raw numbers of instructions executed.
> JavaScript and Swift have essentially the same performance here
One thing that I notice about the Swift version is that he's making heavy use of classes, and in the performance section it mentions that there is quite a lot of time spent on retain-release. There's probably a lot of room for performance optimization in this implementation.
For Java it could be binary wrangling. You have to do some weird things to unpack binary blobs in Java due to the lack of unsigned types. So, for performance you have to wrangle things through native ByteBuffers correctly or you will get killed.
c# and go both have value typea and reference types, java only has reference types. c# also has a variety of tools for controlling how memory isbused and accessed bs java. avoiding the heap may he the first order difference.
