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

41–47 of 47 posts

Re: Gonum – Numerical Computing for Go

#41

Post by brian-armstrong »

d4l3k wrote: post #35
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...

But if you're doing that, you might as well just use a language with RAII, good scoping and unique pointers. A language like... C++

Re: Gonum – Numerical Computing for Go

#42

Post by Khanthulhu »

jbochi wrote: post #9
Khanthulhu wrote: post #3

What's the use case for this? Machine learning? But data? General math use?

Here at The New York Times we are using it to power some of our recommendation algorithms. We are actually training the models with Python and serving them with Go using gonum. Our library was just open sourced (and still in my personal account, until we add more documentation): https://github.com/jbochi/facts

Beautiful. Thanks for the reply

Re: Gonum – Numerical Computing for Go

#43

Post by catnaroek »

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…

Relying on a JIT to get good performance is arguably a bad thing anyway, since JIT compilation makes performance harder to predict. Of course, in the end you need to measure what you have, but you should also be able to make educated guesses about performance when you don't have something to measure, e.g., when you need to select between several alternative designs, and implementing all of them would be prohibitively expensive.

Re: Gonum – Numerical Computing for Go

#44

Post by Recurecur »

microtonal wrote: post #8
paultopia wrote: post #5

A solid, featureful & performant numerics library seems like a really good match for Go---if it can match numpy but also provide benefits like the safety of types, binary compilation, and better performance in non-numeric code, that's a really exciting case for sliding away from python?

I have done some numeric programming in Go and compared to Python it's really hampered by the lack of operator overloading. Of course, it just provides convenience, but it's what makes writing stuff in numpy, Tensorflow, Eigen, etc elegant.

I think Julia is a far better candidate for high performance numerics than Go. It's just a better designed language in general, it is already higher performance, and it's far more expressive than Go.

When the Julia AOT compilation story is complete, and it's well along now, Julia should dominate a whole lot of Go use cases...

Re: Gonum – Numerical Computing for Go

#45

Post by Recurecur »

sbinet wrote: post #37

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), mana…

I suggest you take a look at Julia. I think it's a much better fit for that type of work...

Re: Gonum – Numerical Computing for Go

#46

Post by dm319 »

howeman wrote: post #7
optimuspaul wrote: post #6

wonder how this compares to numpy/scipy in terms of features and performance. Looks pretty comprehensive.

We aren't at full feature parity, but we're pretty close. There are some big things we are missing (ODE, FFT), and we have a bunch of things they don't have (statistical distance measures being one example). We are trying to be pure-go, so it's not at simple as providing a wrapper API. Working on it though!

statistical distance measures? is that like tSNE and similar?

Re: Gonum – Numerical Computing for Go

#47

Post by sbinet »

jerf wrote: post #40
sbinet wrote: post #39

Earlier quoted context omitted.

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

as I am working on https://github.com/go-interpreter/wagon, I'd be very interested in these issues you're talking about.
Post reply on HN