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

Gonum – Numerical Computing for Go

gonum.org

Post reply on HN
Print view View original

31–40 of 47 posts

Re: Gonum – Numerical Computing for Go

#31

Post by howeman »

howeman wrote: post #30
jerf wrote: post #25

Earlier quoted context omitted.

If Go was to become big in the scientific programming community, it would need generics eventually. One interesting thing that NumPy demonstrates is that such things are capable of becoming popular enough that they essentially become their own sub-language. One option in that case, if GoNum collected enough of a community, is to fork Go and add generics. There are some complicated generics options that would be diffi…

I can see the argument for operator overloading being necessary, but I don't understand the argument for generics. There's basically no time I've wanted generics coding Go, except a couple times with float64 vs []float64. I also see the need for float32 vs. float64, but that's a very small use case for generics in terms of scope (we can and do autogenerate float32 code). There's a couple of cases with float64 vs. com…

Sorry, just saw your thing below. I see your point about [2]float64 vs. [3]float64, but that still feels like mostly an operator overloading thing (I realize it isn't exclusivly). Most of the time I've dealt with that (say, [3][3]float64 vs. [2][2]float64) the contexts were different enough that generics would not have been useful because there would still have to be type switching.

Re: Gonum – Numerical Computing for Go

#32

Post by catnaroek »

nerdponx wrote: post #27
paulsutter wrote: post #10

Earlier quoted context omitted.

As of reading your comment, I'm 100% convinced that Go needs generics. I'm a longtime Go advocate, love coding in Go, but until now thought the lack of generics is just fine. Lately I do a lot of numpy/tensorflow, and have begun to really dislike the slowness of python. It would be great to do that work in Go specifically.

One of the big perks of Julia comes from its built-in multiple dispatch. Overloading is one thing, but full-blown multiple dispatch is really powerful in a math context, where the concept of "multiplication" is entirely dependent on the types of things you are multiplying. In Python (despite there being an excellent `multipledispatch` module) this is mostly just handled by aggressive duck typing ("if it has a .foo me…

For numerical computing, rather than dynamic multiple dispatch, what is actually desirable is a type system that can figure out statically the kinds of result produced by multiplying different kinds of arguments.

Re: Gonum – Numerical Computing for Go

#33

Post by catnaroek »

jerf wrote: post #28
nerdponx wrote: post #27

Earlier quoted context omitted.

One of the big perks of Julia comes from its built-in multiple dispatch. Overloading is one thing, but full-blown multiple dispatch is really powerful in a math context, where the concept of "multiplication" is entirely dependent on the types of things you are multiplying. In Python (despite there being an excellent `multipledispatch` module) this is mostly just handled by aggressive duck typing ("if it has a .foo me…

"So I guess my question is: why do you need generics when you have interfaces? These other (admittedly dynamically typed) languages make do without." Going backwards, as you allude to, dynamic languages fulfill the use cases for generics, as long as you don't care about type safety, which is a thing that is true for the whole language anyhow so it's not much to give up. For Go, the main problem is that when you're tr…

> and you want it to be strongly-typed because that's also how you get good performance

What you get performance from is the absence of dynamic checks, not the presence of static ones. Of course, in the absence of dynamic checks, you want static ones for your sanity's sake - but not for performance's sake!

Re: Gonum – Numerical Computing for Go

#34

Post by brian-armstrong »

Honestly, I don't think that Go is the right language for this. I've used Go quite a lot and it feels like it mostly just gets in your way. You can't really do memory management, which will likely impede performance for numerical work. There's no operator overloading either.

C++, for all its flaws, seems to just generally be a more well-conceived language and more generalist than Go. The only place I really feel like Go works is specifically in the context of moving bytes from one socket to another.

Re: Gonum – Numerical Computing for Go

#35

Post by d4l3k »

brian-armstrong wrote: post #34

Honestly, I don't think that Go is the right language for this. I've used Go quite a lot and it feels like it mostly just gets in your way. You can't really do memory management, which will likely impede performance for numerical work. There's no operator overloading either. C++, for all its flaws, seems to just generally be a more well-conceived language and more generalist than Go. The only place I really feel like…

What kind of memory management do you need that Go doesn't provide?

It's not too hard to write Go to minimize allocations (and most short lived allocations end up on the stack anyways unlike other languages [1]). If you really need a lot of allocations you can always use https://golang.org/pkg/sync/#Pool to avoid GC overhead.

[1] https://groups.google.com/d/msg/golang-nuts/KJiyv2mV2pU/wdBU...

Re: Gonum – Numerical Computing for Go

#36

Post by sbinet »

howeman wrote: post #15
openasocket wrote: post #13

How does this play with Go's scheduler? My understanding is that the Go scheduler is not preemptive, and goroutines are switched out at yield point, like the start of a function body. So tight loops that don't call other functions can effectively hog the OS thread until it leaves that loop body (No idea what happens when doing FFI, maybe that's done in a separate thread pool?). For most cases where you would use Go y…

I don't use Gonum with a webserver + large calculations so I can't definitively answer. No one has reported problems, but that could be a lack of usage. One thing though is that matrix multiplication (which is a kernel for higher-level operations) is written in a blocked format, and the code can be pre-empted on any of those blocks, so I wouldn't suspect it's a problem.

also, there's been work to make for-loops preemptible:

- https://github.com/golang/go/issues/10958

- https://go-review.googlesource.com/c/go/+/33910

- https://go-review.googlesource.com/c/go/+/36206

- https://go-review.googlesource.com/c/go/+/46410

- https://go-review.googlesource.com/c/go/+/43050

Re: Gonum – Numerical Computing for Go

#37

Post by sbinet »

I have been using Gonum for some time now (also contributed, mostly in the plotting area).

Last summer, I tried an experiment: have a student migrate a little python-based analysis to a Go-based one. The analysis was fitting some cosmological constants out of the so called Hubble diagram.

I was pleased to see that, in the span of 2-3 months, the student who had limited knowledge in programming (a bit of python), managed to pull off the minimization of a 740 supernovae dataset with a 2220x2220 nuisance parameters matrix.

and the run time was 2x faster than the python one (with scipy/minuit for the minimization, so everything in C/C++, really).

success. :)

(and this motivated us to completely switch to Go as a teaching language for our master in particle physics / cosmology.)

Re: Gonum – Numerical Computing for Go

#38

Post by jerf »

catnaroek wrote: post #33
jerf wrote: post #28

Earlier quoted context omitted.

"So I guess my question is: why do you need generics when you have interfaces? These other (admittedly dynamically typed) languages make do without." Going backwards, as you allude to, dynamic languages fulfill the use cases for generics, as long as you don't care about type safety, which is a thing that is true for the whole language anyhow so it's not much to give up. For Go, the main problem is that when you're tr…

> and you want it to be strongly-typed because that's also how you get good performance What you get performance from is the absence of dynamic checks, not the presence of static ones. Of course, in the absence of dynamic checks, you want static ones for your sanity's sake - but not for performance's sake!

I was speaking in the context of Go. In general, this is the sort of code that JITs are so good at handling that they tend to fool people into thinking they are miracle workers everywhere else where the JIT expense isn't being amortized across million-row matrix multiplications. But Go doesn't have a JIT, and its performance is good enough that I don't expect one to emerge any time soon. (Languages running 50x slower than C have a lot more pressure to try to solve that problem with a JIT than languages that are only 2-3x slower than C.)

Re: Gonum – Numerical Computing for Go

#39

Post by sbinet »

jerf wrote: post #38
catnaroek wrote: post #33

Earlier quoted context omitted.

> and you want it to be strongly-typed because that's also how you get good performance What you get performance from is the absence of dynamic checks, not the presence of static ones. Of course, in the absence of dynamic checks, you want static ones for your sanity's sake - but not for performance's sake!

I was speaking in the context of Go. In general, this is the sort of code that JITs are so good at handling that they tend to fool people into thinking they are miracle workers everywhere else where the JIT expense isn't being amortized across million-row matrix multiplications. But Go doesn't have a JIT, and its performance is good enough that I don't expect one to emerge any time soon. (Languages running 50x slower…

> But Go doesn't have a JIT, and its performance is good enough that I don't expect one to emerge any time soon.

that's true. that is... until a (real) Go interpreter shows up. something that's bound to happen when Go will be used for (data) exploratory work.

Re: Gonum – Numerical Computing for Go

#40

Post by jerf »

sbinet wrote: post #39
jerf wrote: post #38

Earlier quoted context omitted.

I was speaking in the context of Go. In general, this is the sort of code that JITs are so good at handling that they tend to fool people into thinking they are miracle workers everywhere else where the JIT expense isn't being amortized across million-row matrix multiplications. But Go doesn't have a JIT, and its performance is good enough that I don't expect one to emerge any time soon. (Languages running 50x slower…

> But Go doesn't have a JIT, and its performance is good enough that I don't expect one to emerge any time soon. that's true. that is... until a (real) Go interpreter shows up. something that's bound to happen when Go will be used for (data) exploratory work.

I poked around with writing a Go interpreter a while back. There are a number of issues that make it practically infeasible. You can get some hacked-up stuff off of GitHub, but those hacked up things are pretty much the best you can do right now.

But as per my other thread in this thread, if the scientific community becomes big enough I wouldn't be surprised they fork Go entirely, at which point that opens up a lot more options.

Post reply on HN