Re: Possible (summer of code) projects for Octave

[Søren Hauberg]

man, 03 01 2011 kl. 21:49 +0100, skrev Daniel Kraft:
> I'm also not really an expert or experienced with JIT technology of 
> related stuff, unfortunately.  What I do for gfortran/GCC is basically 
> front-end stuff (like implementation of Fortran 2003 OOP features) and I 
> did not yet touch any optimization or code-generation in GCC.  But on 
> the other hand, I guess that using existing frameworks like LLVM the 
> main concern is not compilation technology and code generation but more 
> about how to translate Octave into a more static form.

The simplest thing (according to the compiler people I hang out with
from time to time) would most likely be to output C++ code. Then the
missing part is essentially "just" type estimation. I don't think this
is particularly easy, but I'm really no expert here...

>   But this means that currently there are no projects in planning or 
> development to tackle something like that?

Not anything I know of.

> My first thought was more about using simple parallel algorithms (and 
> probably mostly shared-memory with few cores rather than cluster 
> computing) for stuff like matrix/vector element-wise operations, 
> dot-products or BLAS in general.  Although, I think that it is not 
> always easy to come up with code that performs well on different 
> architectures or for different problem sizes -- and AFAIK, Octave uses 
> BLAS/LAPACK routines for (some of) those operations, right?  I don't 
> really know, but I could imagine that there are already projects out 
> there to develop (free and portable) parallel BLAS routines.  So maybe 
> one could "simply" try integrating them into Octave and implementing 
> some framework to control parallelization depending on the problem size 
> and user preferences or the like.

I would tend to agree. Having mechanisms for switching BLAS/LAPACK
implementation at run-time could potentially be quite nice. I'm not sure
it's particularly easy, though.

> But of course also extension of selected existing Octave functions in a 
> way you mention it above seems like an interesting idea.  Do you know 
> what the opinions of "the community" are with respect to this ansatz in 
> general?  Would it be considered useful, and for which functions / 
> functionality?

I would consider it useful. My guess would be that others would feel the
same way if the code was simple enough to maintain. Such features would
never stand a chance if they where too hard to maintain.

Cheers
Søren