3 ms·

That JavaScript and Swift have essentially the same performance here is extremely telling: there are essentially four performance regimes (five if you count Pyt

by saurik 7y ago

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.

bsder 7y ago
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.
Gibbon1 7y ago
> 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.
masklinn 7y ago
> 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. I expect Haskell and OCaml have similar issues.
quietbritishjim 7y ago
> JavaScript and Swift have essentially the same performance here Only for throughput. The latency difference is enormous.
emmericp 7y ago
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. There's some more evlauation for Swift here: https://github.com/ixy-languages/ixy.swift/tree/master/performance https://github.com/ixy-languages/ixy.swift/tree/master/perfo... 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.
- skohan 7y ago
  This is also a clear optimization target. It is very possible to write Swift code which requires very little reference-counting overhead.
  - dep_b 7y ago
    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.
skohan 7y ago
> 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.
gameswithgo 7y ago
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.

by saurik 7y ago

bsder 7y ago

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.

Gibbon1 7y ago

> 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.

masklinn 7y ago

> 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. I expect Haskell and OCaml have similar issues.

quietbritishjim 7y ago

> JavaScript and Swift have essentially the same performance here Only for throughput. The latency difference is enormous.

emmericp 7y ago

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. There's some more evlauation for Swift here: https://github.com/ixy-languages/ixy.swift/tree/master/performance https://github.com/ixy-languages/ixy.swift/tree/master/perfo... 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.

skohan 7y ago
This is also a clear optimization target. It is very possible to write Swift code which requires very little reference-counting overhead.
- dep_b 7y ago
  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.

skohan 7y ago

> 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.

gameswithgo 7y ago

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.