Hacker News Reader

Comment by gautamcgoel | Hacker News Reader

The optimization I care about most is vectorization. A lot of ML and data science basically boils down to numerical linear algebra and optimization; vectorization is the key optimization for these kinds of problems. I bet if Go got a better autovectorizer it would compare more favorably against languages like Rust and C++ for numerical tasks. The trade-off, of course, is longer compile times, which I suspect will be unacceptable to the core Go team.

View on HN

I like Go. I use it a lot. I've been called a Go shill on HN.

And I seriously do not understand the appeal of trying to use Go for heavily-vectorized code. The ASM support is sufficient for encryption kernels and some lightweight additions like bigints, but if you're writing the kind of code where you want the compiler to autovectorize a lot of math operations, why would you want to write that in Go at all? Why start from scratch in a language with designers that may not actively hate your use case, but certainly don't care much about it, when you can work in a language+runtime+library environment that deeply cares about that use case?

If I for some reason had a task like this handed to me at work, I'd drop Go in a heartbeat and go get something reasonable for the task.

Go will never be good for numeric or mathematical tasks. Those things involve richer type systems than Go has, or weaker type systems (dynamic types); Go's type system is arguably pessimal for this use case, being both too strong and too weak at the same time. Even if Go grows generics, they are very likely to still not be what a numeric system is looking for. Rich numeric types put a lot of strain on type systems (rather than being the easiest case which I think some people's intuitions might suggest, they are the worst case), and Go's type system is simply never going to be complexified enough for what you'd want in a numeric/mathematical system because it would be directly at odds with their stated use cases.

It isn't even that Go is kind of weak on this one point, but if you fixed it, you'd have a great numerical language... the whole language is shot through with little things here and there that work against numeric code, the explicitly-stated desire for a fast compiler that doesn't do much optimization probably being the most notable other problem. Making Go an even decent numerical language would pretty much involve a full fork of it.

Even Java and .NET do better on auto vectorization.

Intel has recently published an article on using Go, their advice?

Manually use cgo or Go Assembly for the AVX.

Apples to orange comparison. Java and .NET have different goals, around 2 decades of optimization and a lot more money thrown at them.

Also, hi again pjmlp! Another Go thread, another nonconstructive Go bashing coming from you. From your other comments here I see you got pretty combative this time.

Stating facts is hardly bashing.

Vague statements without sources are not facts.

And even without sources comparing Go to Java and .NET doesn't even make sense in the context.

Since it is so hard for you to use Google, here you go:

https://cr.openjdk.java.net/~vlivanov/talks/2017_Vectorizati...

https://www.codeproject.com/Articles/1223361/Benchmarking-NE...

https://clearlinux.org/blogs-news/performant-containerized-g...

Now go play with your facts.

Intel doesn't directly advice for neither of the 3 methods. It simply states that handcrafting assembly code is faster which is always the case anyway.

So everybody can see how dishonest pjmlp is towards Go, here is their interpretation of Intel's conclusion:

> Intel has recently published an article on using Go, their advice? Manually use cgo or Go Assembly for the AVX.

And here is the actual Intel conclusion from the link:

> The examples show how to use Intel AVX-512 with Go to improve application performance using three different methods: direct access with Go assembly, using the Go cgo interface with intrinsics for Intel AVX-512, and via indirect access with 3rd party libraries such as Gonum.

> Each method showed that using Intel AVX-512 improved Go application performance, with shorter execution times and improved date throughput overall. Using Go assembly with direct access to the CPU instruction set was faster than indirect access using cgo or Gonum.

> Clear Linus OS makes it easy to use Intel AVX-512 in Go because Clear Linux OS provides a deeply optimized software stack, including Intel AVX-512 enabled software.

To say pjmlp's interpretation was uncharitable is an understatement.

Please enlighten us where does Intel describe how to do auto-vectorization with Go, because writing Go Assembly, using cgo writing C intrinsics by hand, or link to a third party library hand optimized doesn't look very automatic to me.

Like I said, play with facts if that makes you feel good.

Who said it needs to support vectorization natively? It's not what Go was created for so it's fine to exist as a library or assembly code.

Go has stricter goals than Java or .NET. So comparing them favorably is like saying a Corolla sucks because it lacks features present in a heavy duty truck.

Again, Intel's article doesn't advocate for any method. It just presents results. Anyone can read the article and conclude for themselves that you're extrapolating to the worse interpretation possible as usual.

That's understandable. There's a large cost to doing cgo calls. Not to mention you get into a weird situation where the cgo calls take too long to execute and the Go scheduler/pacer can make things even worse by suspending execution.

True. These are valid concerns one should keep in mind when using cgo.

Wait until a webasm thread comes around again and you'll see a real rabbit hole of extreme conflation, false claims, bad faith arguments and willful ignoring of facts and evidence.

Glad not to disappoint the accolades of WebAssembly knighthood.

Please don't do any more flamewars like this on HN ever again. What a train wreck.

https://news.ycombinator.com/newsguidelines.html

Please don't ever start or feed flamewars like this on HN again. We ban accounts that do that, and what you did here was egregious.

https://news.ycombinator.com/newsguidelines.html

I assume full responsibility. I started it.

Regardless of pjmlp's behavior in Go threads it doesn't justify me lowering the bar like this.

You wont see this kind of content coming from me in the future.

Well it sucks for now, but Gorgonia and Gonum has a bunch of vectorized libraries for deep learning related use cases - they are "hand written" kernels (in actual fact generated by gcc -O3)

This kernels method of doing things makes it easy to upgrade code. Check it out: https://github.com/gorgonia/vecf64

Given how brittle autovectorizers can be (small changes to the code preventing the heuristic from firing), that is pretty much the only reliably fast way to write such a library currently, and perhaps indefinitely.

Reply on news.ycombinator.com