Subject: [go-nuts] Re: Runtime code generation for scientific computing?
From: Raul Mera <rmeraa@gmail.com>
To: golang-nuts@googlegroups.com
Date: Fri, 28 Mar 2014 16:14:50 -0700 (PDT)



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 
language").

 

> 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 
similar).

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. 



+ egon
>
> (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 golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
