Re: Eu vs perl
- Posted by Raude Riwal <RAUDER at THMULTI.COM> Dec 06, 1999
- 550 views
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...> > 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