4 ms·

> BTW, the author claims Go is faster than Java. Is this true, because it didn't used to be? I think for certain use cases C# or Java will be faster. THere was

by LandR 7y ago

> BTW, the author claims Go is faster than Java. Is this true, because it didn't used to be? I think for certain use cases C# or Java will be faster. THere was a post here the other day about a network driver written in C, Rust, C#, Go, Java and a few others and The C# one was faster then Go. Can't remember if Java was faster or not.

coder543 7y ago
> The C# one was faster then Go As pointed out over here (https://news.ycombinator.com/item?id=20984503 https://news.ycombinator.com/item?id=20984503), Compared to C#, Go was faster (higher throughput) for smaller batch sizes, and it always had significantly lower latency. .NET Core is particularly good these days, so I'm sure there are times when C# is definitely faster than Go, but the network driver isn't a great example to support that.
- joelfolksy 7y ago
  Are we looking at the same charts? Go and C# are practically on top of each other for smaller batch sizes, then C# pulls ahead significantly.
  - coder543 7y ago
    If you’re looking at the latency chart, higher is worse. The right hand side of the C# graph is not a good thing. The throughput graph doesn’t show C# pulling ahead significantly. Significant is how far behind Java is from Go and C# in that benchmark. Also be sure you’re not looking at JavaScript on the throughout graph, since it is colored very similarly to Go.
specialist 7y ago
[Another] keen observation on that network driver thread is performance is bound by memory copying. For which Java, C#, etc. can all be about the same. FWIW: Back in ~1998, I wrote a VRML browser that was faster (FPS and event loop) than Sony's. Benchmarks showed Sony's was then the fastest (publicly available). They used 'C'. I used Java (JDK 1.2). We both used same OpenGL stack. Same kind of deal as a network stack. Most of FPS was due the graphics card and use of OpenGL. Java's JNI added a minor performance penalty. As for the all the other stuff, like reading files, parsing, user interface, I just figured Sony's VRML team sucked (worse than me). Update: Others made the point about latencies.

by LandR 7y ago

coder543 7y ago

> The C# one was faster then Go As pointed out over here (https://news.ycombinator.com/item?id=20984503 https://news.ycombinator.com/item?id=20984503), Compared to C#, Go was faster (higher throughput) for smaller batch sizes, and it always had significantly lower latency. .NET Core is particularly good these days, so I'm sure there are times when C# is definitely faster than Go, but the network driver isn't a great example to support that.

joelfolksy 7y ago
Are we looking at the same charts? Go and C# are practically on top of each other for smaller batch sizes, then C# pulls ahead significantly.
- coder543 7y ago
  If you’re looking at the latency chart, higher is worse. The right hand side of the C# graph is not a good thing. The throughput graph doesn’t show C# pulling ahead significantly. Significant is how far behind Java is from Go and C# in that benchmark. Also be sure you’re not looking at JavaScript on the throughout graph, since it is colored very similarly to Go.

specialist 7y ago

[Another] keen observation on that network driver thread is performance is bound by memory copying. For which Java, C#, etc. can all be about the same. FWIW: Back in ~1998, I wrote a VRML browser that was faster (FPS and event loop) than Sony's. Benchmarks showed Sony's was then the fastest (publicly available). They used 'C'. I used Java (JDK 1.2). We both used same OpenGL stack. Same kind of deal as a network stack. Most of FPS was due the graphics card and use of OpenGL. Java's JNI added a minor performance penalty. As for the all the other stuff, like reading files, parsing, user interface, I just figured Sony's VRML team sucked (worse than me). Update: Others made the point about latencies.