Question

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Question

Dominic O'Kane
Hi All
I have a very basic question I would like to ask. Forgive me if it appears dumb.
I like Octave and the idea of contributing to this community but the speed of computation is an issue for me and keeps pushing me back to matlab and alternatives.
I realise that it is a lot of work to be done to get a fast JIT compiler.
I was wondering if it might be easier to have a built in parser that can convert octave code to C which can then be compiled to machine code by the local compiler to produce fast object files and an executable that would run at close to the maximum possible speed. The compilation may take a short time - say a minute or so.
The work flow for users would be to do all initial development and debugging and testing in octave but click on a "compile" button when they are ready in order to obtain the fast executable.
I appreciate that this would require some clever makefile to be generated. And every user would need to have a c compiler on their machine.
But compared to writing a full working JIT, would this be easier ?
Regards
D


Sent from my iPad
Reply | Threaded
Open this post in threaded view
|

Re: Question

Carlo de Falco-3

On 7 Jul 2016, at 10:27, Dominic O'Kane <[hidden email]> wrote:

> Hi All
> I have a very basic question I would like to ask. Forgive me if it appears dumb.
> I like Octave and the idea of contributing to this community but the speed of computation is an issue for me and keeps pushing me back to matlab and alternatives.
> I realise that it is a lot of work to be done to get a fast JIT compiler.
> I was wondering if it might be easier to have a built in parser that can convert octave code to C which can then be compiled to machine code by the local compiler to produce fast object files and an executable that would run at close to the maximum possible speed. The compilation may take a short time - say a minute or so.
> The work flow for users would be to do all initial development and debugging and testing in octave but click on a "compile" button when they are ready in order to obtain the fast executable.
> I appreciate that this would require some clever makefile to be generated. And every user would need to have a c compiler on their machine.
> But compared to writing a full working JIT, would this be easier ?
> Regards
> D

I think this has been attempted several times.
If you search the mailing list archives you should
find a relatively recent thread where someone was
announcing work on a similar project.

c.




Reply | Threaded
Open this post in threaded view
|

Re: Question

Jordi Gutiérrez Hermoso-2
In reply to this post by Dominic O'Kane
On Thu, 2016-07-07 at 11:27 +0300, Dominic O'Kane wrote:
   
> I was wondering if it might be easier to have a built in parser that
> can convert octave code to C

No, it's not easier. It's more or less exactly the same problem as a
JIT compiler. The only big difference between ahead-of-time compiling
or just-in-time compiling is when the compiling happens, but both have
to solve the same problem of type inference and so forth.

- Jordi G. H.



Reply | Threaded
Open this post in threaded view
|

Re: Question

John W. Eaton
Administrator
On 07/07/2016 08:07 PM, Jordi Gutiérrez Hermoso wrote:
> On Thu, 2016-07-07 at 11:27 +0300, Dominic O'Kane wrote:
>
>> I was wondering if it might be easier to have a built in parser that
>> can convert octave code to C
>
> No, it's not easier. It's more or less exactly the same problem as a
> JIT compiler. The only big difference between ahead-of-time compiling
> or just-in-time compiling is when the compiling happens, but both have
> to solve the same problem of type inference and so forth.

And you can actually have more information available with JIT compiling
because you can use the types of the actual arguments that are passed to
a function and compile a version of the function for those types and
reuse it if you encounter the same types and number of arguments in a
future call.  You can't have that information if you are attempting a
general Octave to C++ translator that generates code to compile just
once for the entire program in advance of running it.

jwe


Reply | Threaded
Open this post in threaded view
|

Re: Question

LachlanA
John W. Eaton wrote
On 07/07/2016 08:07 PM, Jordi Gutiérrez Hermoso wrote:
> On Thu, 2016-07-07 at 11:27 +0300, Dominic O'Kane wrote:
>
>> I was wondering if it might be easier to have a built in parser that
>> can convert octave code to C
>
> No, it's not easier.

And...
OK, so JIT is the way to go.  Once 4.2.0 is out, should we have a big push for better performance?  The benchmark times at [http://julialang.org] are truly embarrassing:

                         Julia     Octave
                  0.4.0      4.0.0
-----------------------------------------
fib 2.11     9324.35
parse_int 1.45     9581.44
quicksort 1.15      1866.01
mandel 0.79      451.81
pi_sum 1.00      299.31
rand_mat_stat 1.66 30.93
rand_mat_mul 1.02 1.12

The similarities between the Julia language and the Octave language are sufficient that they must have overcome many of the difficulties we face with JIT.  Their code is MIT licenced, so we can use whatever would help us.

Comparing out plotting performance to Matlab is probably also a factor of 100 or so.  (This seems to have got worse just recently; I'll try to track it down.)

Cheers,
Lachlan
Reply | Threaded
Open this post in threaded view
|

Re: Question

Jordi Gutiérrez Hermoso-2
On Thu, 2016-07-07 at 19:22 -0700, LachlanA wrote:
> OK, so JIT is the way to go. Once 4.2.0 is out, should we have a big
> push for better performance?

The problem is that the kind of people that are naturally attracted to
Octave usually know mathematics or engineering, but for JIT compiling
we need computer scientists who care about programming language
design. I'm not sure what kind of push we can do to get JIT compiling.

- Jordi G. H.




Reply | Threaded
Open this post in threaded view
|

Re: Question

LachlanA
Jordi Gutiérrez Hermoso-2 wrote
On Thu, 2016-07-07 at 19:22 -0700, LachlanA wrote:
> OK, so JIT is the way to go. Once 4.2.0 is out, should we have a big
> push for better performance?

The problem is that the kind of people that are naturally attracted to
Octave usually know mathematics or engineering, but for JIT compiling
we need computer scientists who care about programming language
design. I'm not sure what kind of push we can do to get JIT compiling.
Jordi,

That is a good point about the community.  For JIT, the options seem to be either to revive the current attempt or build on that of Julia or FreeMat or some such.  The "push" could involve someone deciding which of those to go with.  Someone (Mike?) said that it is unlikely that a future JIT compiler will use the current framework, which has made me reluctant to spend time on it.

However, I said a push for "performance", which can be aided by things other than JIT.

* Even the C++ components of the graphics subsystem are slow.  My pet conjecture is that each low-level object is carrying around too much option data.

* Figure out how to profile the executable.  This may be by figuring out what settings oprofile needs, by forming a cut-down version of Octave that gprof can work with, or if necessary putting explicit timing code in frequently-called functions.

* Reduce memory allocations/frees (IIRC, a previous post said this was a substantial fraction of time).

* Reduce the number of implicit temporary objects.  I recently put some output in a constructor, and it was called about 10 times as often as I would have expected by looking at the code.  Fortunately it was a light-weight constructor, but I expect similar things happen for more expensive objects.

Cheers,
Lachlan
Reply | Threaded
Open this post in threaded view
|

Getting gprof or oprof to work on recent versions of Octave (was Re: Question)

jbect
Le 08/07/2016 à 07:49, LachlanA a écrit :
> * Figure out how to profile the executable.  This may be by figuring out
> what settings oprofile needs, by forming a cut-down version of Octave that
> gprof can work with, or if necessary putting explicit timing code in
> frequently-called functions.

Yes, figuring out how to profile Octave would be a first step towards
trying to reduce the runtime on simple examples such as those used in
the Julia benchmark.

This has been discussed a few times on the mailing list, and it didn't
seem easy back then.  Here are a few relevant nabble threads:

-----

June 2014 : me asking for help to build static version of Octave
instrumented with gprof ; no one answered
http://octave.1599824.n4.nabble.com/For-loop-benchmarks-between-Octave-versions-tp4664522p4665042.html
(I am giving a link to the end of the discussion where gprof is
mentioned, but the whole thread is about performance and the Julia
benchmark)

May 2013 : Daniel Kraft asked for advice about using gprof ; Jordi said
that he had never managed to get gprof to work with Octave ; suggests
oprof instead
http://octave.1599824.n4.nabble.com/Profiling-C-code-in-oct-files-tp4652745.html

March 2013 : Júlio Hoffimann managed to get OProfile working (but not
gprof) ; nobody answered on the mailing list
http://octave.1599824.n4.nabble.com/Profiling-GNU-Octave-tp4650637.html

February 2009 : apparently, building a static version of Octave was
necessary at the time to get gprof to work
http://octave.1599824.n4.nabble.com/profiling-Octave-td1634535.html

-----

These discussions are rather old.  And I could find anything more on the
wiki.

Did I miss something ?  Does anyone have working recipes to use gprof or
oprof on recent versions of Octave ?

@++
Julien

Reply | Threaded
Open this post in threaded view
|

Re: Getting gprof or oprof to work on recent versions of Octave (was Re: Question)

jbect
Le 11/07/2016 à 13:22, Julien Bect a écrit :
> These discussions are rather old.  And I could find anything more on
> the wiki.


I meant : "I couldn't find".


Reply | Threaded
Open this post in threaded view
|

Re: Getting gprof or oprof to work on recent versions of Octave (was Re: Question)

Andreas Weber-6
In reply to this post by jbect
Am 11.07.2016 um 13:22 schrieb Julien Bect:

> Le 08/07/2016 à 07:49, LachlanA a écrit :
>> * Figure out how to profile the executable.  This may be by figuring out
>> what settings oprofile needs, by forming a cut-down version of Octave
>> that
>> gprof can work with, or if necessary putting explicit timing code in
>> frequently-called functions.
>
> Yes, figuring out how to profile Octave would be a first step towards
> trying to reduce the runtime on simple examples such as those used in
> the Julia benchmark.
>
> This has been discussed a few times on the mailing list, and it didn't
> seem easy back then.  Here are a few relevant nabble threads:
>
> -----
>
> June 2014 : me asking for help to build static version of Octave
> instrumented with gprof ; no one answered
> http://octave.1599824.n4.nabble.com/For-loop-benchmarks-between-Octave-versions-tp4664522p4665042.html
>
> (I am giving a link to the end of the discussion where gprof is
> mentioned, but the whole thread is about performance and the Julia
> benchmark)
>
> May 2013 : Daniel Kraft asked for advice about using gprof ; Jordi said
> that he had never managed to get gprof to work with Octave ; suggests
> oprof instead
> http://octave.1599824.n4.nabble.com/Profiling-C-code-in-oct-files-tp4652745.html
>
>
> March 2013 : Júlio Hoffimann managed to get OProfile working (but not
> gprof) ; nobody answered on the mailing list
> http://octave.1599824.n4.nabble.com/Profiling-GNU-Octave-tp4650637.html
>
> February 2009 : apparently, building a static version of Octave was
> necessary at the time to get gprof to work
> http://octave.1599824.n4.nabble.com/profiling-Octave-td1634535.html
>
> -----
>
> These discussions are rather old.  And I could find anything more on the
> wiki.
>
> Did I miss something ?  Does anyone have working recipes to use gprof or
> oprof on recent versions of Octave ?

I was able to compile current default, 4.2.1 and 4.0.3 with

../octave-src/configure CFLAGS=-pg -no-pie -O2 CXXFLAGS=-pg -no-pie -O2
--disable-java --disable-docs --without-qt --without-fftw3
--without-fltk --enable-static --disable-dl --disable-shared --no-create
--no-recursion

You can see output here:

https://josoansi.de/files/octave-4.3.0.gprof
https://josoansi.de/files/octave-4.2.1.gprof