Re: Eu vs perl

new topic     » goto parent     » topic index » view thread      » older message » newer message

I can answer one SHORT thing on this thread:
Take a lambda user.
give him Half an hour the euphoria documentation.
give him Half an hour to read the perl documentation.
ask him to write a program.
with euphoria he does the job.
with perl he gets out to drink a guinness.

Yes, I understood the meaning of "Rapid Deployment" when I really wrote a
test program.
Just half an hour.
Thats why I'd like to have euphoria on sparcstation/Solaris...

Riwal Raude
rauder at thmulti.com
> -----Original Message-----
> From: Robert Craig [SMTP:rds at ATTCANADA.NET]
> Sent: Monday, December 06, 1999 5:14 AM
> To:   EUPHORIA at LISTSERV.MUOHIO.EDU
> Subject:      Re: Eu vs perl
>
> > : ./lines bigwords  1.03s user 0.05s system 100%
> > cpu 1.075 total
> > : perl lines.pl bigwords  2.27s user 0.03s system 99%
> > cpu 2.307 total
>
> lines.ex took 1.075 total CPU time. The original
> lines.pl took 2.307. That makes lines.ex 2.307/1.075=2.15
> times faster, i.e. 115% faster.
>
> > it now runs 60% faster than your version, which means
> > it should now outrun the Euphoria example.
>
> Huh? He speeded up the original by only 60%.
> That's far short of the *115%* that he needs.
>
> > On the other hand, the Euphoria program has to pull
> > in another 489 lines of include files to do what it does,
> > so it's really a 598 line program.
>
> It's very reasonable to code some standard library
> routines in Euphoria itself, because Euphoria code
> is fast enough to do the job, and the Euphoria compiler
> is fast enough to compile the code in a fraction of a second.
> If Euphoria ran at the speed of Perl, people would demand
> that I write all routines in C, and bury them in a large
> monolithic executable file like Perl.
>
> bin/lines.ex is probably the most "Perlish" of all the programs
> in the Euphoria distribution. Perl was *specifically designed*
> to scan text files, match patterns, and report results.
> Euphoria is more general purpose, but can still beat
> Perl on it's own turf.
> I'm still waiting to see an action game in Perl.
>
> > It's quicker on that problem for several reasons.
> > One, it has integer declarations.
>
> Wrong. You could remove all the integer declarations,
> declare everything as atom or even object, and get
> the same speed within 1%.
>
> > Two, it doesn't really have any strings to speak of,
> > just numeric arrays that it pretends are strings.
>
> I consider that to be a important "feature" of Euphoria.
> "Strings" are easily manipulated in Euphoria, and
> the core language definition of Euphoria is about 10%
> of the size of Perl. By the way, if strings are handled just like
> *general* sequences, how would that make them any
> faster in Euphoria?
>
> > Three, it cheats--it looks to me like it steals a bit from
> > each integer cell for something else, perhaps to tell
> > whether it's an object pointer instead.
>
> I guess one man's clever optimization is another man's "cheat".
> Euphoria does not limit you to 31-bit integer values, unless
> you ask it to. You can always use "atom".
>
> > P.P.S. I suppose we could make Perl run even faster
> > if we do like Euphoria and only distribute binaries
> > for Intel CPUs.  Then we could write it all in 386
> > assembly...  blink
>
> Euphoria is written in C, just like Perl.
> Assembly is only used in a few very isolated areas
> having litte to do with performance.
> Euphoria would be much faster than Perl on any CPU.
> Euphoria is 34x faster on sieve, which is a pure
> CPU burner. People with slow interpreters prefer
> to look at benchmarks that:
>
>     a) are heavily I/O intensive. Even Euphoria can't make
>          the operating system run faster, or the disk drive
>          spin faster. Euphoria's time profiling shows
>          that (on DOS) 70% of this benchmark's time is
>          spent on I/O. (I didn't realize it would become a
>          benchmark when I wrote it.)
>
>     b) depend heavily on special features that are built-in to the
>          interpreter so as to avoid having to execute many
>          statements in the interpreted language itself.
>
> Regards,
>      Rob Craig
>      Rapid Deployment Software
>      http://www.RapidEuphoria.com

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu