Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Golang vs. C# (.NET 5.0) at Benchmarks Game

benchmarksgame-team.pages.debian.net

Post reply on HN
Print view View original

91–100 of 114 posts

Re: Golang vs. C# (.NET 5.0) at Benchmarks Game

#91

Post by igouy »

throwaway894345 wrote: post #85
igouy wrote: post #74

Earlier quoted context omitted.

> 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 la…

What-about-ism.

https://golang.org/doc/faq#garbage_collection

> They’re all allowed to use bespoke pools and custom allocators.

No. They are allowed a library memory pool.

As-it-says: 'Please don't implement your own custom "arena" or "memory pool" or "free list" - they will not be accepted.'

> … while Go’s allocator is slower…

So that tiny tiny program shows it's slower because it's slower.

Re: Golang vs. C# (.NET 5.0) at Benchmarks Game

#92

Post by igouy »

kaba0 wrote: post #55
igouy wrote: post #36

Earlier quoted context omitted.

Many years ago — but from version-to-version too many of the Scala programs suffered bad bitrot, failed and were not updated.

Scala code is backwards compatible, only the class files are not - so at most dependencies could have become stale. With a recompile, the programs should work just fine.

Requirements changed; and neither the original program contributors or anyone else on the scala mailing list wished to update the programs.

(The scala mailing list archive doesn't seem to go back that far.)

Re: Golang vs. C# (.NET 5.0) at Benchmarks Game

#93

Post by matttproud »

igouy wrote: post #89
matttproud wrote: post #82

Earlier quoted context omitted.

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.

It would do the project’s web site a big service to actually link prominently to this repository, if this site is in fact canonical.

A zipped source code archive inside a Git repository is very surprising (violation of principle of least astonishment). No wonder I couldn’t find the benchmark programs’ source; they aren’t even indexed for code search due to residing in a zip file.

Re: Golang vs. C# (.NET 5.0) at Benchmarks Game

#94

Post by igouy »

matttproud wrote: post #93
igouy wrote: post #89

Earlier quoted context omitted.

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

It would do the project’s web site a big service to actually link prominently to this repository, if this site is in fact canonical. A zipped source code archive inside a Git repository is very surprising (violation of principle of least astonishment). No wonder I couldn’t find the benchmark programs’ source; they aren’t even indexed for code search due to residing in a zip file.

And, of course, there was a time when the website did "link prominently to this repository" — back before July 2020, when "new source-code was usually measured and shown on the website within a few days."

Re: Golang vs. C# (.NET 5.0) at Benchmarks Game

#95

Post by throwaway894345 »

igouy wrote: post #90
throwaway894345 wrote: post #83

Earlier quoted context omitted.

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.

1. Rust, C++, C

2. It is in practice, but regardless of the size of the cohort there’s no compelling reason for these limitations.

3. And you’re entitled to ignore reason. It cuts both ways.

Re: Golang vs. C# (.NET 5.0) at Benchmarks Game

#96

Post by throwaway894345 »

lalaithion wrote: post #88
throwaway894345 wrote: post #83

Earlier quoted context omitted.

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.

I believe this is all addressed in my original post: https://news.ycombinator.com/item?id=28293381. If you have specific questions/concerns, I'm happy to address them, but I don't see the point in repeating myself.

Re: Golang vs. C# (.NET 5.0) at Benchmarks Game

#97

Post by igouy »

throwaway894345 wrote: post #95
igouy wrote: post #90

Earlier quoted context omitted.

1. Please be specific. 2. Again, not limited to only one language. 3. You are allowed an opinion.

1. Rust, C++, C 2. It is in practice, but regardless of the size of the cohort there’s no compelling reason for these limitations. 3. And you’re entitled to ignore reason. It cuts both ways.

1. Which program?

2. Again, not limited to only one language. You are allowed an opinion about what is or is not compelling.

3. As before.

Re: Golang vs. C# (.NET 5.0) at Benchmarks Game

#98

Post by throwaway894345 »

igouy wrote: post #91
throwaway894345 wrote: post #85

Earlier quoted context omitted.

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 la…

What-about-ism. https://golang.org/doc/faq#garbage_collection > They’re all allowed to use bespoke pools and custom allocators. No. They are allowed a library memory pool. As-it-says: 'Please don't implement your own custom "arena" or "memory pool" or "free list" - they will not be accepted.' > … while Go’s allocator is slower… So that tiny tiny program shows it's slower because it's slower.

> What-about-ism.

Not sure what you're referring to here.

> No. They are allowed a library memory pool.

Yes, this is a contrived rule. In reality, a Go developer would write the extra ~dozen lines (all of the heavy lifting done by the builtin slice implementation) and call it a day.

> So that tiny tiny program shows it's slower because it's slower.

Tautology. It's slower because the contrived rules preclude idiomatic optimizations.

My point is that these contrived benchmarks don't indicate anything about the relative performance of these languages, but you keep responding with some variation of "but Go is slower in these benchmarks!" which everyone already agrees with. So unless you're going to actually address the point, I don't see the point in continuing on. It feels like you're hell-bent on using this thread for your personal programming language holy war, which is disinteresting to me (see again my first post) and against the site rules.

Re: Golang vs. C# (.NET 5.0) at Benchmarks Game

#99

Post by igouy »

throwaway894345 wrote: post #84
_ph_ wrote: post #59

Earlier quoted context omitted.

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 id…

> … allowed to use custom allocators…

No. They are allowed a library memory pool.

As-it-says: 'Please don't implement your own custom "arena" or "memory pool" or "free list" - they will not be accepted.'

Re: Golang vs. C# (.NET 5.0) at Benchmarks Game

#100

Post by throwaway894345 »

igouy wrote: post #97
throwaway894345 wrote: post #95

Earlier quoted context omitted.

1. Rust, C++, C 2. It is in practice, but regardless of the size of the cohort there’s no compelling reason for these limitations. 3. And you’re entitled to ignore reason. It cuts both ways.

1. Which program? 2. Again, not limited to only one language. You are allowed an opinion about what is or is not compelling. 3. As before.

1. btree; see the Rust version which uses a bump allocator for example

2. Doesn't matter whether it's exactly one language.

> You are allowed an opinion about what is or is not compelling.

It's not a matter of opinion. The definitional purpose of benchmarks is to indicate something about reality; if you contrive rules that cause the benchmarks to deviate from reality, they lose their utility as benchmarks. I've demonstrated that the rules are contrived (i.e., they prohibit real-world, idiomatic optimizations), so I think we can say as a matter of fact that these benchmarks aren't useful.

Of course, no one can force anyone else to see reason (but I don't have any interest in talking with unreasonable people).

Post reply on HN