1. perl vs. Euphoria

On Thu, 31 Aug 2000 22:13:28 -0400, Robert Craig <rds at ATTCANADA.NET> wrote:


>If Euphoria were 40-60 times slower, such as Python or Perl,
>then I would understand people wanting to jam lots of stuff into
>the interpreter where it can be handled by C code.
>
>Regards,
>   Rob Craig
>   Rapid Deployment Software
>   http://www.RapidEuphoria.com

I'm sorry, Rob.  I can understand complaints about Python speed, I've seen
that elsewhere.  However, it is my understanding that Perl does compile to a
highly optimized set of opcodes which are then executed.  It executes from a
script without a compilation step that produces a separate executeable, but
it does run quite fast.  Are there any benchmarks comparing execution speeds
between perl and Euphoria?  I would be happy to do some comparisons.  I have
both perl and Euphoria on both Linux and Windows.  I don't usually play
around with benchmarks much.  Is there a particular operation which you
believe will prove euphoria significantly faster?

It wouldn't be fair to compare features which simply show up the differences
of the languages.  For instance, since Euphoria doesn't support regular
expressions, a benchmark which checks for performance of regular expression
processing would by definition be slanted in favor of perl.  Similarly,
while perl can support arbitrarily complex structures, it doesn't have
sequences as a data type so benchmarks of routines which create random
sequences and then measure access times would be slanted towards Euphoria
(not to mention that it would be a lot of work to make a perl program which
could routinely handle arbitrarily nested arrays of references to arrays and
other data).

However, in areas such as file i/o, numeric calculation, perhaps direct
substring access of text strings, others? it should be possible to have some
reasonable comparisons.  If you could supply some Euphoria routines which
you believe will perform better than equivilent perl code, I'd be glad to
try to write the equivilent perl code.  I don't have the expertise with perl
that some people I've met have, but I do use it professionally and I think I
could put together a reasonable set of benchmark code.

I'm not trying to slam Euphoria here.  I've registered for it and have been
having a lot of fun putting together some code at home using it, but I have
a hard time believing that it is 40 to 60 times faster than perl.

        -J. Kenneth Riviere

new topic     » topic index » view message » categorize

2. Re: perl vs. Euphoria

J. Kenneth Riviere writes:
> I have a hard time believing that it is 40 to
> 60 times faster than perl.

I based that figure on the sieve benchmark
running on DOS. The Euphoria, Perl and Python
sieve programs are included with the Linux version of Euphoria
in demo/bench. On Linux, Euphoria (interpreted)
beats the other two by a factor of about 35x.
Translated/compiled Euphoria is considerably faster
(as you'll see when the translator to C is released in a few days).

I'd be pleased to see any benchmark results that you can
come up with. Just post the code, and any input data
that you used.

No single benchmark gives the whole story.
Proponents of slow languages will favor
benchmarks that are diluted by things like I/O,
calls to library routines written in C, or unique features
built-in to the language. What's fair really depends
on what your application is.

Regards,
   Rob Craig
   Rapid Deployment Software
   http://www.RapidEuphoria.com

new topic     » goto parent     » topic index » view message » categorize

3. Re: perl vs. Euphoria

On Fri, 1 Sep 2000 10:39:57 -0400, Robert Craig <rds at ATTCANADA.NET> wrote:

>J. Kenneth Riviere writes:
>> I have a hard time believing that it is 40 to
>> 60 times faster than perl.
>
>I based that figure on the sieve benchmark
>running on DOS. The Euphoria, Perl and Python
>sieve programs are included with the Linux version of Euphoria
>in demo/bench. On Linux, Euphoria (interpreted)
>beats the other two by a factor of about 35x.
>Translated/compiled Euphoria is considerably faster
>(as you'll see when the translator to C is released in a few days).
>

I pulled up the benchmark programs and ran them.  I hadn't really paid much
attention to them when I got the package.  I was astonished to find that
Euphoria did indeed run the code 30+ times faster than perl.  I reviewed the
code and thought I'd found a gotcha when I saw that the time was being
checked on each iteration of the loop.  Perhaps this is some kind of problem
with perl's time-checking, system access routines (though I'd not seen such
problems mentioned elsewhere).  I changed the loops to run a set number of
iterations instead of running for a set period of time.  I then had to up
the number of iterations for the Euphoria version so that it would run for
more than a second.  The relative performance stayed the same.  I was able
to coax about a 20% improvement in perl's performance by initializing the
@flags array from a pre-initialized array instead of using a for loop, but
that improvement is dwarfed by the dramatic difference between the
performance overall of Euphoria and perl.

I've used perl for several years now and have always heard a lot of hype
about how perl's "compile at run-time" approach optimized performance to the
extent that it was not necessary to have a true compiler generating
stand-alone executeables.  I thought that the only real advantage of the
perl compiler project was that it would make it possible to generate
stand-alone executables without requiring complete perl installations on
each machine where the application was used.  My initial usage for perl was
simply to make simple filters to reformat data for specialized needs.  It
has served me very well in this regard.  I've recently started working at a
company which has been doing more extensive applications in perl, and I'm
going to have to suggest that we re-assess our options in that regard, as it
seems clear that we are not getting the optimized performance from perl that
I had been led to believe it was giving us.  Perhaps the perl compiler will
be sufficient (I understand a lot of progress has been made on this
project), but I'll need to examine this in greater detail.

So when are you going to have full ODBC drivers for Euphoria so that I can
suggest we rewrite our Oracle applications using Euphoria instead of perl
with its DBI/DBD modules?  smile

         -J. Kenneth Riviere

new topic     » goto parent     » topic index » view message » categorize

4. Re: perl vs. Euphoria

On Fri, 1 Sep 2000 14:28:52 -0400, J. Kenneth Riviere
<kriviere at MINDSPRING.COM> wrote:

>So when are you going to have full ODBC drivers for Euphoria so that I can
>suggest we rewrite our Oracle applications using Euphoria instead of perl
>with its DBI/DBD modules?  smile

   Kenneth:

   Maybe you could use a odbc socket-server like this and
   write a Euphoria client to access it.

   http://odbc.linuxave.net/faq.html#T1

   Bernie

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu