octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Possible (summer of code) projects for Octave


From: Daniel Kraft
Subject: Re: Possible (summer of code) projects for Octave
Date: Mon, 03 Jan 2011 21:49:05 +0100
User-agent: Thunderbird 2.0.0.0 (X11/20070425)

Hi Søren,

thanks a lot for the very quick reply!

Søren Hauberg wrote:
man, 03 01 2011 kl. 20:10 +0100, skrev Daniel Kraft:
Of course, what came first to my mind when thinking about this, was JIT or a byte-code VM approach to speed up interpretation of loops and other stuff -- but from what I read on the mailing list archives, this is already a somewhat "well known" project and I understand that there are a lot of difficulties in particular because of the dynamic typing. Still, maybe there are currently some ideas or motivation to try something into that direction?

When I talk to the compiler experts at university they tell me that it
is not an all-that-impossible task to implement something simple here.
Personally, I don't know the first thing in this field so I can't
comment much further except to say that few (if any at all) people on
this list are experts on JIT technology, so anybody working on this
would either need to be an expert or have a working relationship with an
expert.

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.

My impression is also, that maybe one could find some simple heuristics for infering types in "easy cases" (whatever that means) that still give good performance improvements for real-world codes. Sounds like a possibility -- at least if I have some ideas for what to propose there. But this means that currently there are no projects in planning or development to tackle something like that?

Otherwise, I also read something about attempts to make use of multiple cores -- this sounds interesting, too, are the ongoing projects towards (or interest in) that?

Some functionality exists in various packages for this, but having
something easier to use could be quite nice. I've seen work (can't find
the reference right now; ask if you're interested and I'll do my best at
digging it out) for NumPy where several functions got extended for an
extra argument for controlling parallisation of the function. E.g. you
could do something like (syntax is off-the-top-of-my-head)

  b = solve (A, x, num_nodes=10)

which would then distribute the program to 10 nodes in a cluster. I
would find something similar to be quite nice in Octave.

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.

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?

Some other things that would be useful for Octave and the user community?

First things that come to mind:

* Improve the OpenGL graphics system.
* Implement support for object oriented programming using 'classdef'.

Thanks for the suggestions here! I have to admit that so far I did not yet use the OpenGL graphics (but have used OpenGL a bit from C++ if that is related or could help) and am also using Octave usually in a "simple" way (i.e., no OOP) -- but I am and have been somewhat involved in the (ongoing) implementation of OOP features in gfortran. Of course, OOP in Octave is probably much different from OOP in Fortran (as this is very different in certain areas from OOP in C++/Java), but this also sounds interesting.

Yours,
Daniel

--
http://www.pro-vegan.info/
--
Done:  Arc-Bar-Cav-Kni-Ran-Rog-Sam-Tou-Val-Wiz
To go: Hea-Mon-Pri


reply via email to

[Prev in Thread] Current Thread [Next in Thread]