OpenEuphoria

Re: Speed

• Posted by Robert Craig <rds at EMAIL.MSN.COM> Jan 27, 1998
• 724 views

Daniel writes:
> The actual speed of the Euphoria interpreter seems
> heavily dependent on the type of code used.
> The boasts do seemed to be based on the efficient data
> structure (do not hold me to this one) and clever
> built in functions. When conventional structures are used
> speed gains over languages such as QBasic become
> much less significant (again, do not hold me to this one).

I'm not exactly sure what you mean by "conventional structures".
Maybe you could be more specific or give an example.

> I was wondering if anybody has done any comparisons
> between Eu and JIT-compiled
> Java, because the 7x speed gain may be
> annulled by this new development.
> Rob, have you ever considered going the
> next stage after tokenising and byte-
> coding and JIT-compiling things such as for loops,
> so that loops with a large
> number of repetitions can go a lot faster?

JIT (Just in time)-compiled Java is certainly faster than
interpreted Java, but the speed-up is rarely as great as the extreme
claims that I've seen from the vendors of JIT Java compilers.
See Kernighan's paper for some idea of the difference.

I have spent a lot of time researching JIT for Euphoria.
Compiling Euphoria would be harder than compiling Java,
because Java requires you to declare the type of all
of your variables at compile-time, and the type can never change.
Java also has less-flexible data structures and does less in
the area of dynamic storage allocation.

Euphoria currently compiles into a kind of
machine-independent code, that is then interpreted
using a fast, lean "thread-code" approach.
If you cross the line into producing actual Intel machine
code, you open up a whole new realm of complexity,
bugs, and lack of portability to other machines.

I'd like to get more into compiling someday, (I worked as
a compiler developer for several years) but you guys
are keeping me pinned down under heavy fire with
demands for new features.  

(By the way, Euphoria does a bit of JIT for for-loops
already. It adjusts the for-loop control code *dynamically* at the
start of a for-loop, so that the increment and test will
be as fast as possible, given the known range of values
that the loop variable will take on. This range isn't always
known at compile-time.)

Regards,
     Rob Craig
     Rapid Deployment Software