Earlier quoted context omitted.
and afaik, .net has record types unlike the jvm (yet) which means java is even worse
Java recently added record types.
did it land in a release ? i thought it was still at review proposal
Golang vs. C# (.NET 5.0) at Benchmarks Game
81–90 of 114 posts
Re: Golang vs. C# (.NET 5.0) at Benchmarks Game
#82I've never understood why folks treat the Benchmarks Game results as indicative nor representative of anything useful. The code specimens they use are often unpolished nor idiomatic, without even commenting on whether they could be made to perform better through Byzantine, careful by-hand optimization. Why does their web site have no contact nor link to where the source code for the project can be checked out, contri…
> I've never understood why… Perhaps they don't read the website text? > … no contact nor link… Search works.
I ran multiple search queries. I wouldn't be so dumb to post a comment like this here without having done my homework. The best I found after trying numerous keyword permutations was https://salsa.debian.org/benchmarksgame-team/benchmarksgame, but this did not appear to contain all of the benchmarks' source, just the source embedded in HTML, which is specious at best. This repository looks mostly like frontend HTML and chrome, not a SUT, executor, nor even the sub-test code.
At the very least, I couldn't realistically re-run some of the example benchmarks from the source embedded in the HTML, because they did not include vendoring/version information for external packages they depend on. That made me doubt the provenance of https://salsa.debian.org/benchmarksgame-team/benchmarksgame.
Re: Golang vs. C# (.NET 5.0) at Benchmarks Game
#83Earlier quoted context omitted.
> The point of the btree example is to test how good programming languages are at allocating tree-like structures that can't be preplanned. Forcing allocations for every node isn't justified by a desire to demonstrate dynamically sized binary trees. A naive dynamically-sized tree would just keep a list of node buffers and allocate a new node buffer every time the previous one fills up (perhaps with subsequent buffers…
> … a desire to demonstrate dynamically sized binary trees… Cart before horse — the binary trees are justified by a desire to demonstrate memory allocation. http://hboehm.info/gc/gc_bench/
1. That’s plainly not the case here since other languages are allowed to use custom allocators
2. Why use a binary tree benchmark in the first place if you’re going to limit the implementation to certain naive implementations (and again, only for one language)? Why not just measure allocations outright or at least call the benchmark “allocator performance”?
3. Showing allocation performance doesn’t help anyone understand the actual performance of the language, which is transparently what everyone uses these benchmarks for. If they wanted a general idea for language performance they would allow trivial, idiomatic optimizations. A benchmark that shows allocation performance is worthless, and a suite of benchmarks that includes a benchmark for allocation performance but not GC latency is worse than worthless: it’s misleading because latency is the more important concern and it’s what these bump allocators trade in order to get their fast allocation performance.
Re: Golang vs. C# (.NET 5.0) at Benchmarks Game
#84I can't imagine a better setup for a language flame war :). I really like debating languages, so I hope it doesn't go that direction. One of the standard caveats with this particular benchmark game with respect to Go is idiomatic optimizations are prohibited. To use the btree example, Go's memory management is low latency and non-moving, so allocations are expensive--any Go programmer writing a performance-sensitive…
That is one reason I don't consider the language benchmark to be really relevant: a lot of benchmarks are taited by the exact rules of the competition.
And these rules are particularly bizarre. Rust, C, and C++ are all allowed to use custom allocators while Java and C# have GCs which are optimized for this particular micro benchmark but not for real world applications (although I hear Java’s GCs are making good headway on latency lately, and clearly all of the GCs are suitable for general application development). So it’s really just Go which is forbidden from an idiomatic optimization as far as I can tell.
Re: Golang vs. C# (.NET 5.0) at Benchmarks Game
#85Earlier quoted context omitted.
> Which is not accepted for the C# programs either. Because C# doesn't benefit from this kind of optimization. Its GC is generational, which means that it has very fast allocations at the expense of high latency. In most applications, lower latency is more important than slower allocations (not least of all because these batch-allocating optimizations are nearly trivial), but these benchmarks don't reflect that at al…
> Because C# doesn't benefit… C# does provide a memory pool implementation.
So what about C, Rust, and C++? They’re all allowed to use bespoke pools and custom allocators. The fastest Rust implementation imports an allocator crate. No doubt you can lawyer the rules to make sure Go still appears slow, but in reality this benchmark doesn’t tell you anything about the language’s general performance because while Go’s allocator is slower, idiomatic Go allocates much less frequently than other languages, but this benchmark prohibits idiomatic optimizations. Moreover, there isn’t a benchmark that shows gc latency, which is the flip side of the allocator coin. So if you really want to die on the hill of “worthless but well-lawyered benchmark rules” be my guest.
Re: Golang vs. C# (.NET 5.0) at Benchmarks Game
#86Earlier quoted context omitted.
My guess is that golang's GC is optimized for latency at the expense of throughput, limiting the max memory size.
nah he just compares two different things. basically his golang hello world probably had basically nothing while his dotnet version used the "Microsoft.NET.Sdk.Web" which basically pulls the shared framework which will load a ton of stuff. BUT even after that the memory usage might be bigger. however does it really matter? I mean dotnet is not a big memory hog. it's pretty lightweight for what it is. compare it to ja…
I tried to do the most minimal, idiomatic design for both. I didn't save the C# code (I think it probably was just asp.net core and newtonsoft.json), but here is the go version [1].
It basically just loads a JSON file into memory then allows you to query the data with 2 API endpoints.
Re: Golang vs. C# (.NET 5.0) at Benchmarks Game
#87Earlier quoted context omitted.
I definitely have run into this, even when using 'server mode' in asp.net core. I never was able to figure out why the C# version of my POC was using so much memory, but rewriting to golang ended up using a very predictable, minimal amount of memory in comparison.
Server mode is much less likely to incur GC. Were you causing enough memory usage to force your app to actually free memory? It will intentionally use more memory for the sake of throughput, hence why this post has all .NET program flag for it, as it's a _speed_ benchmark primarily.
I cant say for certain, but I'm pretty sure I manually GC'ed as a test and it didn't seem to help. Its been a while and the C# ended up being a temporary approach until I saw how much less memory the golang version used.
They performed almost equivalently for RPS I believe.
Re: Golang vs. C# (.NET 5.0) at Benchmarks Game
#88Earlier quoted context omitted.
> … a desire to demonstrate dynamically sized binary trees… Cart before horse — the binary trees are justified by a desire to demonstrate memory allocation. http://hboehm.info/gc/gc_bench/
1. That’s plainly not the case here since other languages are allowed to use custom allocators 2. Why use a binary tree benchmark in the first place if you’re going to limit the implementation to certain naive implementations (and again, only for one language)? Why not just measure allocations outright or at least call the benchmark “allocator performance”? 3. Showing allocation performance doesn’t help anyone unders…
Looking at the fastest Java, Haskell, Racket, OCaml, JavasScript, C#... they're all doing per-node allocation using the standard allocator, and all beating Go. The limit is not just for Go. I don't know why you think that Go is the only one being disadvantaged here.
Re: Golang vs. C# (.NET 5.0) at Benchmarks Game
#89Earlier quoted context omitted.
> I've never understood why… Perhaps they don't read the website text? > … no contact nor link… Search works.
I ran multiple search queries. I wouldn't be so dumb to post a comment like this here without having done my homework. The best I found after trying numerous keyword permutations was https://salsa.debian.org/benchmarksgame-team/benchmarksgame , but this did not appear to contain all of the benchmarks' source, just the source embedded in HTML, which is specious at best. This repository looks mostly like frontend HTML…
> … just the source embedded in HTML…
"Where can I get the program source code? — zip'd program source code"
line 11 ? in the README
> … vendoring/version information for external packages they depend on…
If the programs don't build/run with the latest GA external packages, they will be shown as "Make Error" "Bad Output" "Failed" until someone updates them.
Re: Golang vs. C# (.NET 5.0) at Benchmarks Game
#90Earlier quoted context omitted.
> … a desire to demonstrate dynamically sized binary trees… Cart before horse — the binary trees are justified by a desire to demonstrate memory allocation. http://hboehm.info/gc/gc_bench/
1. That’s plainly not the case here since other languages are allowed to use custom allocators 2. Why use a binary tree benchmark in the first place if you’re going to limit the implementation to certain naive implementations (and again, only for one language)? Why not just measure allocations outright or at least call the benchmark “allocator performance”? 3. Showing allocation performance doesn’t help anyone unders…
1. Please be specific.
2. Again, not limited to only one language.
3. You are allowed an opinion.