[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
- Possible (summer of code) projects for Octave, Daniel Kraft, 2011/01/03
- Re: Possible (summer of code) projects for Octave, Søren Hauberg, 2011/01/03
- Re: Possible (summer of code) projects for Octave,
Daniel Kraft <=
- Re: Possible (summer of code) projects for Octave, Søren Hauberg, 2011/01/03
- Re: Possible (summer of code) projects for Octave, Jaroslav Hajek, 2011/01/04
- Re: Possible (summer of code) projects for Octave, Daniel Kraft, 2011/01/04
- Re: Possible (summer of code) projects for Octave, Søren Hauberg, 2011/01/04
- Re: Possible (summer of code) projects for Octave, Daniel Kraft, 2011/01/05
- Re: Possible (summer of code) projects for Octave, Søren Hauberg, 2011/01/05
Re: Possible (summer of code) projects for Octave, Jaroslav Hajek, 2011/01/04