4 ms·

Java and C# lag behind Golang on most performance metrics. Combine it with the awesome deployment story (single binary) and you'd be hard pressed to choose the

Java and C# lag behind Golang on most performance metrics. Combine it with the awesome deployment story (single binary) and you'd be hard pressed to choose the former

MrBuddyCasino 7y ago
The opposite is true. Golang is on average 2-3 times slower than Java. On the plus side, it uses less memory.
- LOLOLOLO1 7y ago
  No of course. It may loses at some benchmarks made by Java or Python/Ruby coders. Two areas where it is actually slower are 1) Memory allocation 2) Regular expression performance. But you must understand your Java app won’t have performance advantage because of faster alloc speed IRL: GC will take lots of CPU, because Go’s one is much easier at memory release. You can only see allocation advantage in micro benchmarks where the app stops before the GC will start.
  - barrkel 7y ago
    How much CPU GC takes for any given GC implementation is largely down to the design of the application, its data structures and allocation graph. Request / response servers which keep caches and other allocations prone to middle age death out of the GC heap are consistent with the generational hypothesis and ought to spend no more than a few (low single digit) percent in GC with a generational collector.
  - apta 7y ago
    > You can only see allocation advantage in micro benchmarks where the app stops before the GC will start. The golang gc is tuned for latency at the expense of throughput, meaning if you look at the duration of time spent in GC over the course of the code execution, it would actually be longer compared to a GC tuned for throughput. If you have a use case that requires high throughput, then you cannot change the GC behavior. Unlike on the JVM, where you have several GCs to choose from. The JVM is also getting two new low latency GCs for use cases that require low latency. And it's not just microbenchmarks where Java does better than golang, it's especially longer running processes where the JVM's runtime optimizations really kick in. Not to mention that the JVM is getting value types as well to ease the load on the GC when required (it does an excellent job as it is even without value types). I did a dummy port of the C# version of the Havlak code here[1] to Java, preserving the same behavior and not making any data structure changes. On the machine I tested on, the C# version took over 70 seconds to run, while the Java version took ~17 seconds. In comparison, the C++ version took ~24 seconds, and the golang version took ~30 seconds. Yes, you could most likely spend much more time tuning the C++ version, avoiding allocations, and so on, but at the expense of readability. This is what the JVM gives you, you write straight-forward, readable code, and it does a lot of optimizations for you. The brainfuck2 benchmark is especially interesting. Kotlin tops the list, but I was able to get Java to the same performance since Kotlin by writing it in a similar manner as the Kotlin code. Again, Java/Kotlin beat out even C++ when I tested them, and by quite a margin. [1] https://github.com/kostya/benchmarks https://github.com/kostya/benchmarks
- ryuukk_ 7y ago
  People also have other requierements that both Java and C# fails to offer Java/C#(.net) don't understand what people need, they are closed minded, therefore won't survive web assembly revolution
Xelbair 7y ago
I'll just leave this here https://www.ageofascent.com/2019/02/04/asp-net-core-saturating-10gbe-at-7-million-requests-per-second/ https://www.ageofascent.com/2019/02/04/asp-net-core-saturati...
- ryuukk_ 7y ago
  Exactly, Go ranks better than C#, look at the Fortune section > Exercises the ORM, database connectivity, dynamic-size collections, sorting, server-side templates, XSS countermeasures, and character encoding. Wich looks like a better way to benchmark something, more talkative than raw data And when you addition the deployement story (single binary, small package, etc) Go is way way way way ahead, not to mention the web assembly revolution, again thanks to these positive points, Go is again way ahead of C# Now please comunicate this to your C# team at Microsoft, hury up before it is too late, i heard your solution to single binary distribution was to zip/unzip 200 files at runtime, lol
- dcu 7y ago
  these microbenchmarks doesn't say anything about real world use cases... but anyway, here are the latest results: https://www.techempower.com/benchmarks/#section=data-r17&hw=ph&test=plaintext https://www.techempower.com/benchmarks/#section=data-r17&hw=... c#, rust, go, c++, java, c, nim.. all tied at 7M. again, this doesn't mean anything useful.
  - apta 7y ago
    This benchmark isn't really useful as you pointed out. Microbenchmarks are always tricky, but check out the other two posts I just wrote here (about Martin Thompson and the benchmarks on GitHub) for hopefully more realistic benchmarks.
apta 7y ago
I'd like to see those performance metrics. Other than that, this is not true to the slightest, not just from what I observed, but from established performance people like Martin Thompson[1]. If you watch that talk, he mentions towards the end that they ported Aeron (originally Java) to C#, golang, and C++. The Java version was the fastest out of the box, but with some work, they were able to get the C# version to be faster. I suspect this mainly has to do with value types, which is being developed for the JVM as well. What you're probably referring to is GC pauses. The golang GC is tuned for latency, at the expense of throughput. The JVM has several GCs, and is gaining several more like Shenandoah and ZGC, which allows you to select the GC that best fits your use case. You can tune for latency or throughput. A lot of Java deployments these days are in the form of uber/shaded jars, which is basically one jar file that contains the entire app, and run with a single command, not much different than running a binary. [1] https://www.youtube.com/watch?v=Pz-4co8IaI8 https://www.youtube.com/watch?v=Pz-4co8IaI8

Java and C# lag behind Golang on most performance metrics. Combine it with the awesome deployment story (single binary) and you'd be hard pressed to choose the former

MrBuddyCasino 7y ago

The opposite is true. Golang is on average 2-3 times slower than Java. On the plus side, it uses less memory.

LOLOLOLO1 7y ago
No of course. It may loses at some benchmarks made by Java or Python/Ruby coders. Two areas where it is actually slower are 1) Memory allocation 2) Regular expression performance. But you must understand your Java app won’t have performance advantage because of faster alloc speed IRL: GC will take lots of CPU, because Go’s one is much easier at memory release. You can only see allocation advantage in micro benchmarks where the app stops before the GC will start.
- barrkel 7y ago
  How much CPU GC takes for any given GC implementation is largely down to the design of the application, its data structures and allocation graph. Request / response servers which keep caches and other allocations prone to middle age death out of the GC heap are consistent with the generational hypothesis and ought to spend no more than a few (low single digit) percent in GC with a generational collector.
- apta 7y ago
  > You can only see allocation advantage in micro benchmarks where the app stops before the GC will start. The golang gc is tuned for latency at the expense of throughput, meaning if you look at the duration of time spent in GC over the course of the code execution, it would actually be longer compared to a GC tuned for throughput. If you have a use case that requires high throughput, then you cannot change the GC behavior. Unlike on the JVM, where you have several GCs to choose from. The JVM is also getting two new low latency GCs for use cases that require low latency. And it's not just microbenchmarks where Java does better than golang, it's especially longer running processes where the JVM's runtime optimizations really kick in. Not to mention that the JVM is getting value types as well to ease the load on the GC when required (it does an excellent job as it is even without value types). I did a dummy port of the C# version of the Havlak code here[1] to Java, preserving the same behavior and not making any data structure changes. On the machine I tested on, the C# version took over 70 seconds to run, while the Java version took ~17 seconds. In comparison, the C++ version took ~24 seconds, and the golang version took ~30 seconds. Yes, you could most likely spend much more time tuning the C++ version, avoiding allocations, and so on, but at the expense of readability. This is what the JVM gives you, you write straight-forward, readable code, and it does a lot of optimizations for you. The brainfuck2 benchmark is especially interesting. Kotlin tops the list, but I was able to get Java to the same performance since Kotlin by writing it in a similar manner as the Kotlin code. Again, Java/Kotlin beat out even C++ when I tested them, and by quite a margin. [1] https://github.com/kostya/benchmarks https://github.com/kostya/benchmarks
ryuukk_ 7y ago
People also have other requierements that both Java and C# fails to offer Java/C#(.net) don't understand what people need, they are closed minded, therefore won't survive web assembly revolution

Xelbair 7y ago

I'll just leave this here https://www.ageofascent.com/2019/02/04/asp-net-core-saturating-10gbe-at-7-million-requests-per-second/ https://www.ageofascent.com/2019/02/04/asp-net-core-saturati...

ryuukk_ 7y ago
Exactly, Go ranks better than C#, look at the Fortune section > Exercises the ORM, database connectivity, dynamic-size collections, sorting, server-side templates, XSS countermeasures, and character encoding. Wich looks like a better way to benchmark something, more talkative than raw data And when you addition the deployement story (single binary, small package, etc) Go is way way way way ahead, not to mention the web assembly revolution, again thanks to these positive points, Go is again way ahead of C# Now please comunicate this to your C# team at Microsoft, hury up before it is too late, i heard your solution to single binary distribution was to zip/unzip 200 files at runtime, lol
dcu 7y ago
these microbenchmarks doesn't say anything about real world use cases... but anyway, here are the latest results: https://www.techempower.com/benchmarks/#section=data-r17&hw=ph&test=plaintext https://www.techempower.com/benchmarks/#section=data-r17&hw=... c#, rust, go, c++, java, c, nim.. all tied at 7M. again, this doesn't mean anything useful.
- apta 7y ago
  This benchmark isn't really useful as you pointed out. Microbenchmarks are always tricky, but check out the other two posts I just wrote here (about Martin Thompson and the benchmarks on GitHub) for hopefully more realistic benchmarks.

apta 7y ago

I'd like to see those performance metrics. Other than that, this is not true to the slightest, not just from what I observed, but from established performance people like Martin Thompson[1]. If you watch that talk, he mentions towards the end that they ported Aeron (originally Java) to C#, golang, and C++. The Java version was the fastest out of the box, but with some work, they were able to get the C# version to be faster. I suspect this mainly has to do with value types, which is being developed for the JVM as well. What you're probably referring to is GC pauses. The golang GC is tuned for latency, at the expense of throughput. The JVM has several GCs, and is gaining several more like Shenandoah and ZGC, which allows you to select the GC that best fits your use case. You can tune for latency or throughput. A lot of Java deployments these days are in the form of uber/shaded jars, which is basically one jar file that contains the entire app, and run with a single command, not much different than running a binary. [1] https://www.youtube.com/watch?v=Pz-4co8IaI8 https://www.youtube.com/watch?v=Pz-4co8IaI8