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



--
View this message in context: 
http://octave.1599824.n4.nabble.com/Question-tp4678311p4678327.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.