[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Fwd: saw your comments on hacker news]
From: |
Daniel J Sebald |
Subject: |
Re: [Fwd: saw your comments on hacker news] |
Date: |
Sat, 19 Nov 2016 14:38:02 -0600 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 |
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