Re: [Fwd: saw your comments on hacker news]

[Daniel J Sebald]

On 11/19/2016 11:47 AM, John Swensen wrote:
> > On Nov 19, 2016, at 9:13 AM, Jordi Gutiérrez Hermoso
> > <address@hidden <mailto:address@hidden>> wrote:
> >
> > I posted the new website design on HN. It was nice to receive some fan
> > mail in response. :-)
> >
> > - Jordi G. H.
> >
> > -------- Forwarded Message --------
> > From: Chris Holliday <address@hidden <mailto:address@hidden>>
> > To: address@hidden <mailto:address@hidden>
> > Subject: saw your comments on hacker news
> > Date: Sat, 19 Nov 2016 10:52:39 -0500
> >
> > I'm chollida1 on hacker news.
> >
> > I was reading this thread
> >
> > https://news.ycombinator.com/item?id=12993521
> >
> > Just wanted to say that we used Ocatve for this course
> > https://www.coursera.org/learn/neural-networks
> >
> > and I appreciate the effort that you and your fellow contributors put into
> > Octave.
> >
> >
> > Cheers
> > Chris
> >
> >
> > <attachment.html>
>
> If wishes were horses….
>
> I wish we could find some language/interpreter expert with lots of time
> to spend on JIT for Octave. Most discussions I have with students and
> other researchers who have used Octave in the past (and reiterated in
> the ycombinator discussion), their complaint has always been the speed
> of for loops and lack of JIT. The problem is that it really requires
> pretty much a domain expert on JIT to keep a robust solution always up
> to date with a language.
>
> See
> c.
> I have so little experience with JIT that I don’t even know if it is
> possible, but even if we could just make sure the for loop portion of
> execution was somehow JIT’able, I think the apparent speed difference
> would be much less pronounced.
>
>
> John S.

Let me say some general things, having just skimmed through the looping 
code, and then come back to the specific example you cite.

In the code, there appears to be a "simple loop" variant and a "complex 
loop" variant.  Within those two functions are further sub-cases based 
upon the complexity of the RHS of the "for i=A:B:C" construct (i.e., the 
C limit).  That is, I presume that if the RHS C is a complex expression 
for which it is possible that its value or evaluation can change during 
the loop, things get more complex.  The point is that Octave is trying 
to speed things up when it can, as far as the looping mechanism.

There is this test "quit_loop_now()" that is called every time through a 
loop, but I'm guessing it isn't a critical CPU consumption.  It does 
call this octave_quit() which is in the cruft subdirectory.  I think it 
is for checking if the user has typed Cntr-C.  My feeling on that is 
rather than poll for a signal having occurred, it might be better to 
have some setup in which a signal is handled immediately by unwinding 
the stack and jumping back to the command line.  That's a hindsight sort 
of thing, probably slightly tricky but not too bad, but again this sort 
of C++ test of a simple variable isn't real CPU consuming.

The JIT code appears to only be present in the "simple loop" variant. 
Is there evidence of a major efficiency boost with the JIT code?

Let's take a look at the example in that link, and perhaps you or 
someone else at that link could explore things just a little more and 
give insight.

A smart interpreter would realize that the expression

for i=1:100 for j=1:100 k=x(i,j); end; end;

could be evaluated as

k=x(100,100)

and done.  (And maybe Octave should be that perceptive.)  My point is 
that the above loop isn't of much intrinsic value, so it really isn't 
worth it being a point of comparison.  Instead, I'd think comparing 
something like the following is more meaningful:

octave:38> x=rand(300);
octave:39> k=ones(300);
octave:40> tic; for i=1:300 for j=1:300 k(j,i)=x(i,j); end; end; toc;
Elapsed time is 1.69623 seconds.

That is, a loop interpreter couldn't reduce the loop to something 
independent of i and j and quickly get the final result.  (A person can 
recognize that this is simply k = x', sure, but not a general looping 
mechanism.)

So, I'd say make that comparison between the two programs.  It will tell 
us whether something inherent in Octave looping is really time consuming 
or whether Octave just needs to be a little smarter in recognizing 
certain conditions.

Dan