Hacker News Reader

Comment by Thaxll | Hacker News Reader

"beating Go by an order of magnitude."

This is not what happend, Go was faster until batch size was > 16 then C# took over, but still C# latency was 2-3x higher than Go in every benchmarks.

Also C# / Java had to use C code where the Go driver was pure Go.

https://github.com/ixy-languages/ixy-languages/raw/master/im...

At 20Mpp/sec the C# latency was no longer on the graph:

https://github.com/ixy-languages/ixy-languages/raw/master/im...

View on HN

I think it's fascinating that someone could look at those graphs and come away with the conclusion that c# is an order of magnitude faster than go.

On the repo page, there’s a latency graph, and on it there are two green lines. One is for Javascript and has poor latencies. The other is Go and has some of the best latencies. Because the Go one is clustered with other overlapping lines, I think people often misinterpret the Javascript line as the Go line.

https://github.com/ixy-languages/ixy-languages

Well, in my defense, I wasn't looking at the graph when I wrote that, I was trying to remember a graph that I saw a week ago.

It's also fascinating that someone could look at those graphs and say that "Go was faster until batch size was > 16 then C# took over," when Go was barely faster but C# was significantly faster.

C# had to use C code due to lack of .NET knowledge of the authors as discussed on the other thread.

Yes, interop and Span<> should be fine...

Would be interesting to get a PR then and see the difference.

There would be 20 fewer lines of C?

If you go to the other thread someone posted a GitHub gist showing how to use mlock() from C#, which apparently was impossible to do.

As if you have a choice to not use pure Go code, it doesn't play nice with C.

Cgo is a very well supported paradigm and many projects use cgo copiously.

Reply on news.ycombinator.com