Hacker News Reader

Comment by throwawaymath | Hacker News Reader

Note that this comes out of a group at EPFL, a university known for cryptography research.

Can anyone explain how they're achieving comparable performance to C++ using Go, for someone who has never programmed in Go?

View on HN

That's surprising to me, because I don't see any SIMD use in this library. I guess the C++ libraries they're comparing against aren't using SIMD either and aren't effectively using autovectorization. I don't believe that the Go compiler autovectorizes.

Yes, you are correct, the C++ libraries in this field have decent performance, but generally haven't been tuned to hell yet (though they do tend to use all the algorithmic tricks people know about). Which is good news for those of us writing non-C++ versions of these algorithms because it means state of the art performance isn't all that hard to achieve.

Go goes pretty fast, especially if you program it like C (avoiding memory allocations).

You have less control in Go, it being garbage collected and omitting pointer arithmetic. It also ships with a runtime and is statically compiled so the binary you get is 'large'. 'goroutines' (similar to green-threads) are very lightweight and be integrated with high-level CSP constructs (channels & select) or lower level concurrency primitives from the std lib.

From what I've seen benchmark wise Go performs well. It is in the ballpark of fast, statically compiled, garbage collected languages, comparable to fast C#, Java etc. roughly speaking but surpasses them on certain tasks. If I remember correctly there are several web/http/json related tasks where Go is a top performer.

Go supports pointer arithmetic as unsafe code (which is what it is in practice).

Go is fast. No interpreter, no JIT, plain machine code combined with the ability to lay out your data like you can in C.

But the availability numerical libraries have been lackluster in my limited exploration.

Reply on news.ycombinator.com