From octave-maintainers-request at bevo dot che dot wisc dot edu Sun Dec  8 08:10:35 2002
Subject: Re: Possible starting point for Octave Compiler?
From: Paul Kienzle <pkienzle at jazz dot ncnr dot nist dot gov>
To: JD Cole <jdcole at san dot rr dot com>
Cc: Randy Gober <GoberR at Bellsouth dot net>, octave-maintainers@bevo.che.wisc.edu
Date: Sun, 8 Dec 2002 09:10:07 -0500

You will want to look at tree_walker in the octave/src directory, which
allows you to walk the parse tree.  It is used in pt-check, pt-pr-code
and pt-bp.  It walks the parse tree for a function, visiting each node
in turn.  You need to write the action you want for each node type.

As a first step I would like Octave to spit out a byte code for the likes
of Parrot or some other virtual machine.  Parrot in particular because
it is intended to be used by scripting languages, but Java byte code or
.NET CLR would also be interesting.

All of these machines have JITs available for compiling the byte code.

A couple of years ago I did an experiment in which I translated the
an m-file version of cumsum to C++ by hand:

	y = zeros(size(x));
	total = 0;
	for i=1:length(x)
	   total = total + x(i);
	   y(i) = total;
	endfor

IIRC, I got a 6x speedup from a direct translation using octave_value
for x,y,i and total.  As optimized C, this loop was about 5000x faster.
In Python, this loop was 100x faster.

Paul Kienzle
pkienzle at users dot sf dot net

On Sat, Dec 07, 2002 at 04:38:22PM -0800, JD Cole wrote:
> Randy Gober wrote:
> 
> >I am not sure if this is the right place, but will surfing the net I came
> >across this. 
> >
> >A MATLAB Compiler for Parallel Computers
> >Michael J. Quinn, Oregon State University
> >
> >http://cs.oregonstate.edu/~quinn/matlab.html
> >
> >My excitement waned a little when I saw the abstracts dated 1998, but I
> >decided to post it any way.
> >
> >
> >--Randy
> >
> >
> >  
> >
> 
> I've been thinking been toying around with an Octave compiler lately 
> also. The nice part about developing such a tool for Octave is that we 
> don't have to do steps 1 and two described in the above link, (here's 
> one for GPL) because we have access to Octave source. We also don't need 
> to develop a run-time library, for the same reason. Actually it would 
> seem that right now we could have octave build simple, un-optimized, 
> scripts if each octave value was given a print_c_code type function. (Of 
> course its not that straight forward, but a substantial amount of the 
> groundwork already exists.)
> 
> -JD
>