1. Speed
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 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? I have no idea what it would be
like to hack, is it a realistic possibility ? It might go down better than
encryption, which by the way could be done by distributing the bound .ex
randomly inside ex.exe - if you can hack that.
Daniel
2. Re: Speed
I had a rude shock when I wrote my eBasic converter. After reading the
benchmarks included with Euphoria, I was under the impression that Euphoria
ran signifigantly faster than interpreted QBasic. As a result, I thought
that a program that converting QBasic programs to Euphroia would result in
great speed-up in the code.
Imagine my suprise when I converted the QBasic benchmarks to discover that
the Euphoria version of the code ran about the *same* speed, or often much
slower!
You can look in the eBasic documentation for more details, but most of the
benchmarks gained their speed increase because they called specialize
Euphoria routines, so the comparisons were essentially apples vs. oranges -
stacked in Euphoria's favor. For example:
- Array initialization using a FOR...NEXT loop was replaced with repeat().
- Adding two arrays using a FOR...NEXT loop was replaced with adding two
sequences.
- String concatonation using MID$ and LEN used an optimized append() call.
- Name lookup using a FOR...NEXT loop was replaces with a find().
So the benchmarks demonstrated that using Euphoria's specialized routines
were faster than coding them by hand. No suprise there.
What I found perhaps most misleading was the string concatonation. For
example, the code that eBasic generated for:
S$ = S$ + "*"
was:
gStr[1] = gStr[1] & "*"
A fairly innocuous bit of code, yielding a score of 4089 operations, three
times SLOWER than QBasic's 13,880 operations. After scratching my head for
a while, I found that changing the code to:
gStr = gStr & "*"
bounced Euphoria's score to an stellar 778,333! Clearly, an optimized
operation - and an atypical.
Euphoria's IS a fast language - but I'm not sure that, in a comparable
test, that it is faster than integer-based QBasic, or PowerBasic.
-- David Cuny
3. Re: Speed
It has been said that there are 3 levels of mis-truth in this
world.
1. Lies
2. Damn Lies
3. Benchmarks!
David Cuny writes:
> Imagine my suprise when I converted the QBasic benchmarks to
> discover that the Euphoria version of the code ran about the
> *same* speed, or often much slower!
You are comparing unoptimized machine-generated
Euphoria code against human-written QBasic code.
> So the benchmarks demonstrated that using Euphoria's
> specialized routines were faster than coding them by hand.
> No suprise there.
What are you supposed to do when one language has
fast operations on large amounts of data and the other
language doesn't. Disallow any benchmarks that would
play into that strength?
> What I found perhaps most misleading was the string
> concatonation. For
> example, the code that eBasic generated for:
> S$ = S$ + "*"
> was:
> gStr[1] = gStr[1] & "*"
> A fairly innocuous bit of code, yielding a score of 4089 operations,
> three times SLOWER than QBasic's 13,880 operations. After
> scratching my head for
> a while, I found that changing the code to:
> gStr = gStr & "*"
> bounced Euphoria's score to an stellar 778,333! Clearly,
> an optimized operation - and an atypical.
It's strange to compare concatenation onto a variable
with concatenation onto a subscripted variable. This
is just an artifact of your translator. There are more
cases in real life where you will concatenate something
onto a simple variable than there are cases where you
will concatenate onto a subscripted variable.
The simple variable case has been well optimized, so that
it's tremendously faster than QBasic while handling
any kind of *general data*, not just 8-bit characters.
> Euphoria's IS a fast language - but I'm not sure that,
> in a comparable test, that it is faster than integer-based
> QBasic, or PowerBasic.
The bread and butter operations such as adding
two integers, subscripting etc. are an order of magnitude
faster in Euphoria than they are in QBasic. If you write
a program in QBasic it will almost certainly be much slower
than if you write it in Euphoria.
Obviously there is no such thing as a totally "fair"
benchmark.
The sieve benchmark was chosen because it is
fairly small, and was published in Byte magazine.
shell sort was chosen because it's small,
does a well-defined and useful task,
and is different from sieve.
I do not consider either
of these to be "cheats". sieve makes a call to repeat()
but that is a fairly small percentage of the benchmark.
You can replace repeat() by flags[1..SIZE] = ON and
it's just as fast - Oh... but that's cheating too I guess.
I later added database.ex because there was nothing
to show Euphoria's dynamic storage allocation.
The sequence.ex benchmark was created because
I wanted to show Euphoria's powerful operations
on entire sequences.
Obviously you should view it with great suspicion when
one of the participants in a benchmark comparison
gets to choose all the tests.
I recently discovered that Brian Kernighan (co-creator of
C, Awk and most recently "Limbo") has
created a set of benchmarks for interpreted languages.
He coauthored a paper that's on the Web:
He compares C, Java, Visual Basic, Perl, Awk, TcL, Limbo
and Scheme (Lisp). 7 interpreters and one compiler (C).
I converted his benchmark programs to Euphoria
and downloaded his input data (The Bible as 4.5Mb text file!)
Many of his benchmarks are extremely I/O intensive, involving
reading the entire Bible into memory and doing things
with it. I do not consider these to be good benchmarks
in the sense of being representative of typical applications.
Nor do they help you compare interpreter speed very well
when most of the time is spent on I/O.
I suspect he chose them because one of his languages (Awk)
was designed to be extremely fast at pattern matching
in large text files.
Anyway, the bottom line: Euphoria beat each of the other 7
interpreted languages more times than it lost on the 8
benchmark programs. It even beat C once. Some of the other
languages crashed or took "forever" on some of
his benchmarks. Euphoria handled them all easily.
His machine was 100MHz 32Mb
and mine is 150 MHz 32Mb so I scaled my times accordingly.
I'll post his benchmarks, as written in Euphoria, tomorrow.
You can get the (large) input data from Kernighan's site. I sent
him a copy of the Euphoria results and benchmark
programs. He thanked me but I haven't heard anything more
from him.
Regards,
Rob Craig
Rapid Deployment Software
4. Re: Speed
At 03:57 PM 1/26/98 -0800, you wrote:
>Imagine my suprise when I converted the QBasic benchmarks to discover that
>the Euphoria version of the code ran about the *same* speed, or often much
>slower!
>
Gee... I don't know what to say here.
I was under the impression that *all* computer languages were designed to
do something in a better/faster way than their predecessor(s).
Otherwise why write them?
I know of no law that says we must always do a task in the same way,
otherwise why would we need, for example, string handling routines, when
we could just declare an array of char. and print them using a for_loop?
The BASIC benchmarks are doing the best they can, using the features
built into BASIC. If they had a better method available, wouldn't they
also use it?
I think Euphoria is faster. Try this:
create an array of 1 million integers
set each member of the array to , say 3 (or whatever you like)
time the process.
Euphoria takes about 1 sec.
I'm still waiting for QBASIC to decide how to create an array that
size. (Might be a long wait, eh?)
Irv
----------------------------------------------------------------------------
------
visit my Euphoria archives: http://www.mindspring.com/~mountains
----------------------------------------------------------------------------
------
5. Re: Speed
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
