On Friday, March 28, 2014 10:31:54 PM UTC+1, egon wrote:
I've been thinking how to properly approach scientific computing with Go.
It seems that there are many cases which can be improved at the level of
compiler i.e. multi-dimensional arrays, matrices, sets. There are also
SIMD, GPGPUs, OpenCL, OpenMP, FPUs etc. basically hardware features and
libraries that can improve the speed of calculations. So the question is
how to properly target all of that?
Adding support for each of those special cases would make the compiler
slower, more complex and make it harder to maintain. So adding all of that
wouldn't probably be a good idea.
Please let's not mix hardware facilities or especial libraries, which are
indeed special cases, with multi-dimensional slices (we already have
multidimensional arrays) which are a natural way to represent matrices,
which, in turn, are not quite an "special case" but pretty much the main
thing you use for any code that deals with mathematics in some way (which
is a lot of code, not only scientific). Multidimensional slices are not
linked to a particular library, hardware or even algorithm. The proposal
currently being discussed in another thread here is a natural extension of
what exists, and is careful to keep complexity to a minimun.
I very much agree with you about GPUGPU, OpenCL, etc. Those things should
not be in the language. Also, noone in the scientific community has asked
for sets, as far as I know (sorry if I am wrong here), and 2-dimensional
slices are the same as matrices for our purposes. This means that while in
your mail it appears that a long list of language additions is needed/asked
for in order for Go to succeed in scientific programming, the community
is actually asking for only one thing,
Also, saying "multi-dimensional slices, matrices" gives a misleading
impression of several issues, when both things are actually the same for
our purposes. Since I have not seen anyone from the numerical community
asking for sets, the whole list you present as language changes wanted by
the scientific computing people is reduced to one item.
So what would be the alternative? One approach that would be viable is
runtime code generation, it's complex in it's internals, but idea is
simple. Take a string and convert it to a Go function at runtime. So
convert a string to an AST, run tons of optimizations and convert it to
specialized byte-code and finally run it.
When we are talking about scientific computing, this means we should do
aggressive inlining, optimizations that may take a lot of time... e.g. if
an optimization strategy takes 4min and it improves the computation by 20%
then with calculations running longer than 20min it's worthwhile to run
that optimization... but it may not be a good idea for general programming.
I do not like that separation between "scientific" and "general"
computing. We both want our code clean, and have to deal with large
programs. Still, I agree that if you want to use special hardware and the
like, or want the even the *last bit* of performance, no matter what, it is
reasonable that you pay the price. I suspect the current approach of
delegating those things to C is good enough, but I do not have a strong
opinion (well, my strong opinion, like yours, is "leave them out of the
So, maybe, the better approach for scientific computation is to provide
the packages for DSLs, AST conversions, transformations, optimizations,
targets and nice runtime code generation support. I know the details will
get complicated, but maybe it's a better than adding every single thing to
the compiler. With Go compiler eventually being written in Go, it would
mean that we can use the same code in runtime code generation.
What are your thoughts on this?
I will not speak for them, but I don't see that the numerical/scientific Go
comunity (mostly, the gonum people) has proposed or even thinks that we
should add every single thing to the compiler, but are actually against
that. That part sounds bit like a straw man to me. We want a natural way
to represent a very common data structure. We do not want fotran-like
matrix multiplication in the language, and we most certainly have not asked
for language support for the other things you mention. For several of them,
we can probably just work them out at library level, for some, like the GPU
thing, we probably will always need to delegate to C (or, actually, CUDA or
I am not particularly against your proposal, but I don't like that it is
presented as an alternative to what the scientific/numerical Go community
are asking for.
(PS. I'm probably not the best person for implementing it, but maybe
someone else gets inspired and runs with the idea :) )
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firstname.lastname@example.org.
For more options, visit https://groups.google.com/d/optout.