1. Eu Interpreted
On Monday 13 August 2001 15:46, Kat wrote:
> Speaking of Lua, has anyone compared the Eu interpreters coded in Eu to
> the Lua ability to exec commands stored in strings? Are they as fast? Less
> able? What about nested procedures and functions, and lengths of the
> strings? If Eu has a line length limit, is a string that exceeds this limit
> non- executeable in the interpreters? So i cannot pass a 1/2 megabyte file
> to the doubley interpreted Eu, right? I accept that the interpreted
> languages are slower than compiled languages, but is the doubly-interpreted
> Eu still as fast as the Lua in a dostring()?
Kat:
Reading a 10,500 line text file and sorting it100 times in Euphoria takes
9.38 seconds, the same task in Lua takes 9.61 seconds. Making the sort call
via "dostring" instead of direct takes 9.62 seconds. I don't think Euphoria
interpreting Eu code is going to be able to beat that. Or even come close.
Regards,
Irv
2. Re: Eu Interpreted
At 09:57 13/08/01 -0400, you wrote:
>
>On Monday 13 August 2001 15:46, Kat wrote:
>
>> Speaking of Lua, has anyone compared the Eu interpreters coded in Eu to
>> the Lua ability to exec commands stored in strings? Are they as fast? Less
>> able? What about nested procedures and functions, and lengths of the
>> strings? If Eu has a line length limit, is a string that exceeds this limit
>> non- executeable in the interpreters? So i cannot pass a 1/2 megabyte file
>> to the doubley interpreted Eu, right? I accept that the interpreted
>> languages are slower than compiled languages, but is the doubly-interpreted
>> Eu still as fast as the Lua in a dostring()?
>
>Kat:
>
>Reading a 10,500 line text file and sorting it100 times in Euphoria takes
>9.38 seconds, the same task in Lua takes 9.61 seconds. Making the sort call
>via "dostring" instead of direct takes 9.62 seconds. I don't think Euphoria
>interpreting Eu code is going to be able to beat that. Or even come close.
>
>Regards,
>Irv
If you did some preprocessing to produce an include file containing an
indexed table
of routine_id's from all routines used you could do it without much
overhead, apart from
the cost of the table itself. You would need a routine to recognize and call
builtins,
but that would just be a simple switch.
in the example above the dostring("file=sort(file)") or whatever
could be only 2 lookups and a call_func. So speeds might be comparable.
routines declared within strings would be another matter, but I imagine
most calls would be to pre-defined stuff.....
Graeme
3. Re: Eu Interpreted
I'm considering including an interface routine for executing the p-code that
the EU script would generate. Along with a routine for converting a native
script to a p-code script. This would eliminate the parser pass, reducing
load times, and it would also allow for custom optimizations that couldn't
be easily done in the script engine.
What do you think? Would it be worthwhile?
Chris
> Kat:
>
> Reading a 10,500 line text file and sorting it100 times in Euphoria takes
> 9.38 seconds, the same task in Lua takes 9.61 seconds. Making the sort
call
> via "dostring" instead of direct takes 9.62 seconds. I don't think
Euphoria
> interpreting Eu code is going to be able to beat that. Or even come close.
>
> Regards,
> Irv
4. Re: Eu Interpreted
Why would you want to use a script in an interpreted program?
The only way to utilize an include for the script engine would be if the
application was intepreted. In which case, you would just implement the
script as the include itself.
If you wanted to execute it in a compiled program, you could just call a new
instance of the interpeter.
The only use of scripts in an app as I see it, is for dynamic execution. IE
custom expansions to an application, variable execution,etc.
Chris
----- Original Message -----
From: "Graeme" <graemeburke at hotmail.com>
To: "EUforum" <EUforum at topica.com>
Sent: Monday, August 13, 2001 9:35 PM
Subject: Re: Eu Interpreted
>
> At 09:57 13/08/01 -0400, you wrote:
> >
> >On Monday 13 August 2001 15:46, Kat wrote:
> >
> >> Speaking of Lua, has anyone compared the Eu interpreters coded in Eu to
> >> the Lua ability to exec commands stored in strings? Are they as fast?
Less
> >> able? What about nested procedures and functions, and lengths of the
> >> strings? If Eu has a line length limit, is a string that exceeds this
limit
> >> non- executeable in the interpreters? So i cannot pass a 1/2 megabyte
file
> >> to the doubley interpreted Eu, right? I accept that the interpreted
> >> languages are slower than compiled languages, but is the
doubly-interpreted
> >> Eu still as fast as the Lua in a dostring()?
> >
> >Kat:
> >
> >Reading a 10,500 line text file and sorting it100 times in Euphoria takes
> >9.38 seconds, the same task in Lua takes 9.61 seconds. Making the sort
call
> >via "dostring" instead of direct takes 9.62 seconds. I don't think
Euphoria
> >interpreting Eu code is going to be able to beat that. Or even come
close.
> >
> >Regards,
> >Irv
>
>
> If you did some preprocessing to produce an include file containing an
> indexed table
> of routine_id's from all routines used you could do it without much
> overhead, apart from
> the cost of the table itself. You would need a routine to recognize and
call
> builtins,
> but that would just be a simple switch.
>
> in the example above the dostring("file=sort(file)") or whatever
> could be only 2 lookups and a call_func. So speeds might be comparable.
> routines declared within strings would be another matter, but I imagine
> most calls would be to pre-defined stuff.....
>
>
>
>
> Graeme
>
>
>
>
>
>
5. Re: Eu Interpreted
Irv Mullins writes:
> Reading a 10,500 line text file and sorting it100 times in Euphoria takes
> 9.38 seconds, the same task in Lua takes 9.61 seconds. Making the sort call
> via "dostring" instead of direct takes 9.62 seconds.
Correct me if I'm wrong but this benchmark
seems to consist of:
1. doing a bunch of I/O, where a large chunk of the time
will be spent inside the O/S, and also waiting for possible
mechanical motion of the disk. Interpreter speed is largely
irrelevant. The I/O time just dilutes the overall speed comparison.
2. sorting, where you compare a generic and *interpreted* shell-sort
written in Euphoria, against a quick-sort routine *written in compiled C*,
i.e. the Lua *built-in function* for "sort".
In any case, for 10,500 items, the quick sort *algorithm* should be
somewhat faster than shell sort.
The fact that Euphoria wins the benchmark is remarkable.
> I don't think Euphoria interpreting Eu code is going to be
> able to beat that. Or even come close.
The overhead of converting a short string into a
call to a built-in function should be insignificant when
compared to the time spent inside that function,
sorting 10,500 items. I'm sure a "double-interpreted"
Euphoria could do as well.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
6. Re: Eu Interpreted
On 14 Aug 2001, at 6:35, Chris Bensler wrote:
>
> I'm considering including an interface routine for executing the p-code that
> the
> EU script would generate. Along with a routine for converting a native script
> to
> a p-code script. This would eliminate the parser pass, reducing load times,
> and
> it would also allow for custom optimizations that couldn't be easily done in
> the
> script engine.
>
> What do you think? Would it be worthwhile?
I don't see how you could ask that, when you apparently said me wanting to
exec strings without including them wasn't worthwhile.
Kat
> Chris
>
> > Kat:
> >
> > Reading a 10,500 line text file and sorting it100 times in Euphoria takes
> > 9.38
> > seconds, the same task in Lua takes 9.61 seconds. Making the sort
> call
> > via "dostring" instead of direct takes 9.62 seconds. I don't think
> Euphoria
> > interpreting Eu code is going to be able to beat that. Or even come close.
> >
> > Regards,
> > Irv
>
>
>
>
>
>
7. Re: Eu Interpreted
On Tuesday 14 August 2001 12:50, Robert Craig wrote:
>
> Irv Mullins writes:
> > Reading a 10,500 line text file and sorting it100 times in Euphoria takes
> > 9.38 seconds, the same task in Lua takes 9.61 seconds. Making the sort
> > call via "dostring" instead of direct takes 9.62 seconds.
>
> Correct me if I'm wrong but this benchmark
> seems to consist of:
>
> 1. doing a bunch of I/O, where a large chunk of the time
> will be spent inside the O/S, and also waiting for possible
> mechanical motion of the disk. Interpreter speed is largely
> irrelevant. The I/O time just dilutes the overall speed comparison.
>
> 2. sorting, where you compare a generic and *interpreted* shell-sort
> written in Euphoria, against a quick-sort routine *written in
> compiled C*, i.e. the Lua *built-in function* for "sort".
> In any case, for 10,500 items, the quick sort *algorithm* should be
> somewhat faster than shell sort.
>
> The fact that Euphoria wins the benchmark is remarkable.
It certainly is. But, as you say, the disk access masks the differences.
Once you take the disk access time away, the story is different.
Look at this one:
Convert 10,564 lines of text (from listserver archive) to uppercase:
(Timing starts after text is loaded)
Euphoria : 0.24 seconds
Lua: 0.02 seconds
-------------------
-- Filesort.lua
-------------------
lines = {}
readfrom("lua.txt")
lines = read("*all")
readfrom()
start = clock()
lines = strupper(lines)
fini = clock()
print(lines) -- to verify all is upper case
print(format("%2.4f",fini-start))
--------------------
-- Filesort.exu
--------------------
include wildcard.e
atom fn, start, fini
sequence text
object line
fn = open("lua.txt","r")
text = {}
while 1 do
line = gets(fn)
if atom(line) then exit
else text = append(text,line)
end if
end while
start = time()
text = upper(text)
fini = time()
printf(1,"Time required: %2.4f",fini-start)
Regards,
Irv
8. Re: Eu Interpreted
Irv,
just an idea, but why don't you see what difference this makes ...
Use ...
else text &= line
instead of ...
else text = append(text,line)
My guess is it should be a lot faster because fewer sequences are involved.
----- Original Message -----
From: "Irv Mullins" <irvm at ellijay.com>
To: "EUforum" <EUforum at topica.com>
Sent: Wednesday, August 15, 2001 5:30 AM
Subject: Re: Eu Interpreted
>
> On Tuesday 14 August 2001 12:50, Robert Craig wrote:
> >
> > Irv Mullins writes:
> > > Reading a 10,500 line text file and sorting it100 times in Euphoria
takes
> > > 9.38 seconds, the same task in Lua takes 9.61 seconds. Making the sort
> > > call via "dostring" instead of direct takes 9.62 seconds.
> >
> > Correct me if I'm wrong but this benchmark
> > seems to consist of:
> >
> > 1. doing a bunch of I/O, where a large chunk of the time
> > will be spent inside the O/S, and also waiting for possible
> > mechanical motion of the disk. Interpreter speed is largely
> > irrelevant. The I/O time just dilutes the overall speed
comparison.
> >
> > 2. sorting, where you compare a generic and *interpreted* shell-sort
> > written in Euphoria, against a quick-sort routine *written in
> > compiled C*, i.e. the Lua *built-in function* for "sort".
> > In any case, for 10,500 items, the quick sort *algorithm* should
be
> > somewhat faster than shell sort.
> >
> > The fact that Euphoria wins the benchmark is remarkable.
>
> It certainly is. But, as you say, the disk access masks the differences.
> Once you take the disk access time away, the story is different.
> Look at this one:
>
> Convert 10,564 lines of text (from listserver archive) to uppercase:
> (Timing starts after text is loaded)
>
> Euphoria : 0.24 seconds
> Lua: 0.02 seconds
>
> -------------------
> -- Filesort.lua
> -------------------
>
> lines = {}
>
> readfrom("lua.txt")
> lines = read("*all")
> readfrom()
>
> start = clock()
> lines = strupper(lines)
> fini = clock()
>
> print(lines) -- to verify all is upper case
> print(format("%2.4f",fini-start))
>
> --------------------
> -- Filesort.exu
> --------------------
> include wildcard.e
>
> atom fn, start, fini
> sequence text
> object line
>
> fn = open("lua.txt","r")
> text = {}
> while 1 do
> line = gets(fn)
> if atom(line) then exit
> else text = append(text,line)
> end if
> end while
>
> start = time()
> text = upper(text)
> fini = time()
>
> printf(1,"Time required: %2.4f",fini-start)
>
> Regards,
> Irv
>
>
>
>
>
9. Re: Eu Interpreted
On 14 Aug 2001, at 15:30, Irv Mullins wrote:
>
> On Tuesday 14 August 2001 12:50, Robert Craig wrote:
> >
> > Irv Mullins writes:
> > > Reading a 10,500 line text file and sorting it100 times in Euphoria takes
> > > 9.38 seconds, the same task in Lua takes 9.61 seconds. Making the sort
> > > call
> > > via "dostring" instead of direct takes 9.62 seconds.
> >
> > Correct me if I'm wrong but this benchmark
> > seems to consist of:
> >
> > 1. doing a bunch of I/O, where a large chunk of the time
> > will be spent inside the O/S, and also waiting for possible
> > mechanical motion of the disk. Interpreter speed is largely
> > irrelevant. The I/O time just dilutes the overall speed comparison.
> >
> > 2. sorting, where you compare a generic and *interpreted* shell-sort
> > written in Euphoria, against a quick-sort routine *written in
> > compiled C*, i.e. the Lua *built-in function* for "sort".
> > In any case, for 10,500 items, the quick sort *algorithm* should be
> > somewhat faster than shell sort.
> >
> > The fact that Euphoria wins the benchmark is remarkable.
>
> It certainly is. But, as you say, the disk access masks the differences.
> Once you take the disk access time away, the story is different.
> Look at this one:
>
> Convert 10,564 lines of text (from listserver archive) to uppercase:
> (Timing starts after text is loaded)
>
> Euphoria : 0.24 seconds
> Lua: 0.02 seconds
To be fair, Irv, in your code below, the Lua time included the time to print the
results, the Eu code didn't print the results.
Kat
> -------------------
> -- Filesort.lua
> -------------------
>
> lines = {}
>
> readfrom("lua.txt")
> lines = read("*all")
> readfrom()
>
> start = clock()
> lines = strupper(lines)
> fini = clock()
>
> print(lines) -- to verify all is upper case
> print(format("%2.4f",fini-start))
>
> --------------------
> -- Filesort.exu
> --------------------
> include wildcard.e
>
> atom fn, start, fini
> sequence text
> object line
>
> fn = open("lua.txt","r")
> text = {}
> while 1 do
> line = gets(fn)
> if atom(line) then exit
> else text = append(text,line)
> end if
> end while
>
> start = time()
> text = upper(text)
> fini = time()
>
> printf(1,"Time required: %2.4f",fini-start)
>
> Regards,
> Irv
>
>
>
>
>
>
10. Re: Eu Interpreted
- Posted by rossboyd at ihug.com.au
Aug 14, 2001
Derek,
Hi, I'm new to this forum.
I ran your suggestion thinking you'd be right....
But not so, "text = append(text,line) " is significantly faster than
"text &= line".
Thinking about the reasons why....
It would be due to the memory overhead of string concatenation as the
string grows.
Large string concatenation is highly memory intensive.
Whereas, using append() , its just a straight malloc() for the new
sequence.
Also, I read somewhere append() has been highly optimised to avoid
allocating memory on every pass.
Regards,
Ross
----- Original Message -----
From: "Derek Parnell" <ddparnell at bigpond.com>
To: "EUforum" <EUforum at topica.com>
Sent: Wednesday, August 15, 2001 5:52 AM
Subject: Re: Eu Interpreted
>
> Irv,
> just an idea, but why don't you see what difference this makes ...
>
> Use ...
> else text &= line
>
> instead of ...
> else text = append(text,line)
>
> My guess is it should be a lot faster because fewer sequences are
involved.
>
> ----- Original Message -----
> From: "Irv Mullins" <irvm at ellijay.com>
> To: "EUforum" <EUforum at topica.com>
> Sent: Wednesday, August 15, 2001 5:30 AM
> Subject: Re: Eu Interpreted
>
>
> >
> > On Tuesday 14 August 2001 12:50, Robert Craig wrote:
> > >
> > > Irv Mullins writes:
> > > > Reading a 10,500 line text file and sorting it100 times in
Euphoria
> takes
> > > > 9.38 seconds, the same task in Lua takes 9.61 seconds. Making
the sort
> > > > call via "dostring" instead of direct takes 9.62 seconds.
> > >
> > > Correct me if I'm wrong but this benchmark
> > > seems to consist of:
> > >
> > > 1. doing a bunch of I/O, where a large chunk of the time
> > > will be spent inside the O/S, and also waiting for possible
> > > mechanical motion of the disk. Interpreter speed is largely
> > > irrelevant. The I/O time just dilutes the overall speed
> comparison.
> > >
> > > 2. sorting, where you compare a generic and *interpreted*
shell-sort
> > > written in Euphoria, against a quick-sort routine *written
in
> > > compiled C*, i.e. the Lua *built-in function* for "sort".
> > > In any case, for 10,500 items, the quick sort *algorithm*
should
> be
> > > somewhat faster than shell sort.
> > >
> > > The fact that Euphoria wins the benchmark is remarkable.
> >
> > It certainly is. But, as you say, the disk access masks the
differences.
> > Once you take the disk access time away, the story is different.
> > Look at this one:
> >
> > Convert 10,564 lines of text (from listserver archive) to uppercase:
> > (Timing starts after text is loaded)
> >
> > Euphoria : 0.24 seconds
> > Lua: 0.02 seconds
> >
> > -------------------
> > -- Filesort.lua
> > -------------------
> >
> > lines = {}
> >
> > readfrom("lua.txt")
> > lines = read("*all")
> > readfrom()
> >
> > start = clock()
> > lines = strupper(lines)
> > fini = clock()
> >
> > print(lines) -- to verify all is upper case
> > print(format("%2.4f",fini-start))
> >
> > --------------------
> > -- Filesort.exu
> > --------------------
> > include wildcard.e
> >
> > atom fn, start, fini
> > sequence text
> > object line
> >
> > fn = open("lua.txt","r")
> > text = {}
> > while 1 do
> > line = gets(fn)
> > if atom(line) then exit
> > else text = append(text,line)
> > end if
> > end while
> >
> > start = time()
> > text = upper(text)
> > fini = time()
> >
> > printf(1,"Time required: %2.4f",fini-start)
> >
> > Regards,
> > Irv
> >
> >
> >
> >
> >
>
>
>
>
>
>
11. Re: Eu Interpreted
Come on, Derek, the string concatenation is not even timed. The same
for your comment, Kat, the print statement is also outside the timed
block.
Have a nice day too. jiri
12. Re: Eu Interpreted
On 15 Aug 2001, at 5:52, Derek Parnell wrote:
>
> Irv,
> just an idea, but why don't you see what difference this makes ...
>
> Use ...
> else text &= line
>
> instead of ...
> else text = append(text,line)
>
> My guess is it should be a lot faster because fewer sequences are involved.
This is another case where the interpreter should be smart enough to choose
the fastest method of attaching two strings together.
Kat
> ----- Original Message -----
> From: "Irv Mullins" <irvm at ellijay.com>
> To: "EUforum" <EUforum at topica.com>
> Sent: Wednesday, August 15, 2001 5:30 AM
> Subject: Re: Eu Interpreted
>
>
> >
> > On Tuesday 14 August 2001 12:50, Robert Craig wrote:
> > >
> > > Irv Mullins writes:
> > > > Reading a 10,500 line text file and sorting it100 times in Euphoria
> takes
> > > > 9.38 seconds, the same task in Lua takes 9.61 seconds. Making the sort
> > > > call via "dostring" instead of direct takes 9.62 seconds.
> > >
> > > Correct me if I'm wrong but this benchmark
> > > seems to consist of:
> > >
> > > 1. doing a bunch of I/O, where a large chunk of the time
> > > will be spent inside the O/S, and also waiting for possible
> > > mechanical motion of the disk. Interpreter speed is largely
> > > irrelevant. The I/O time just dilutes the overall speed
> comparison.
> > >
> > > 2. sorting, where you compare a generic and *interpreted* shell-sort
> > > written in Euphoria, against a quick-sort routine *written in
> > > compiled C*, i.e. the Lua *built-in function* for "sort".
> > > In any case, for 10,500 items, the quick sort *algorithm* should
> be
> > > somewhat faster than shell sort.
> > >
> > > The fact that Euphoria wins the benchmark is remarkable.
> >
> > It certainly is. But, as you say, the disk access masks the differences.
> > Once you take the disk access time away, the story is different.
> > Look at this one:
> >
> > Convert 10,564 lines of text (from listserver archive) to uppercase:
> > (Timing starts after text is loaded)
> >
> > Euphoria : 0.24 seconds
> > Lua: 0.02 seconds
> >
> > -------------------
> > -- Filesort.lua
> > -------------------
> >
> > lines = {}
> >
> > readfrom("lua.txt")
> > lines = read("*all")
> > readfrom()
> >
> > start = clock()
> > lines = strupper(lines)
> > fini = clock()
> >
> > print(lines) -- to verify all is upper case
> > print(format("%2.4f",fini-start))
> >
> > --------------------
> > -- Filesort.exu
> > --------------------
> > include wildcard.e
> >
> > atom fn, start, fini
> > sequence text
> > object line
> >
> > fn = open("lua.txt","r")
> > text = {}
> > while 1 do
> > line = gets(fn)
> > if atom(line) then exit
> > else text = append(text,line)
> > end if
> > end while
> >
> > start = time()
> > text = upper(text)
> > fini = time()
> >
> > printf(1,"Time required: %2.4f",fini-start)
> >
> > Regards,
> > Irv
> >
> >
> >
> >
> >
>
>
>
>
>
>
13. Re: Eu Interpreted
I agree with you, Mike, Irv's test is a mere comparison of upper()
functions. But on the other hand it highlights the fact that
important, widely used functions like lower() and upper() should be
optimised built-in routines, not just high level euphoria stuff -
that's simply crazy no matter how 'elegant' the code is.
jiri
----- Original Message -----
From: "Mike" <vulcan at win.co.nz>
To: "EUforum" <EUforum at topica.com>
Subject: RE: Eu Interpreted
>
> Hi Irv,
>
> -- It seems to me that this latest test merely reduces to a
comparison
> of upper().
> -- Does lua act directly on the sequence like C? If so then a more
> suitable comparison
> -- would be to inline the upper() function in the EU code. Try using
> this one noted below
> -- instead of Rob's "elegant" routine in wildcard.e
> -- It should speed up the Eu code by a factor of 2
>
> -- In any case, whatever criticsms may be made when comparing:
>
> " a generic and *interpreted* shell-sort written in Euphoria,
> against a quick-sort routine *written in compiled C* "
>
> -- surely also apply in the case of strupper vs upper, do they not?
>
> Your truly
> Mike
>
> vulcan at win.co.nz
>
> function faster_upper(sequence d)
> integer c, disp
> disp='a'-'A'
> for j=1 to length(d) do
> c=d[j]
> if c>='a' then
> if c<='z' then
> d[j] -= disp
> end if
> end if
> end for
> return d
> end function
>
> Irv Mullins wrote:
> > On Tuesday 14 August 2001 12:50, Robert Craig wrote:
> > >
> > > Irv Mullins writes:
> > > > Reading a 10,500 line text file and sorting it100 times in
Euphoria
> > > > takes
> > > > 9.38 seconds, the same task in Lua takes 9.61 seconds. Making
the sort
> > > > call via "dostring" instead of direct takes 9.62 seconds.
> > >
> > > Correct me if I'm wrong but this benchmark
> > > seems to consist of:
> > >
> > > 1. doing a bunch of I/O, where a large chunk of the time
> > > will be spent inside the O/S, and also waiting for
possible
> > > mechanical motion of the disk. Interpreter speed is
largely
> > > irrelevant. The I/O time just dilutes the overall speed
comparison.
> > >
> > > 2. sorting, where you compare a generic and *interpreted*
shell-sort
> > > written in Euphoria, against a quick-sort routine *written
in
> > > compiled C*, i.e. the Lua *built-in function* for "sort".
> > > In any case, for 10,500 items, the quick sort *algorithm*
should be
> > > somewhat faster than shell sort.
> > >
> > > The fact that Euphoria wins the benchmark is remarkable.
> >
> > It certainly is. But, as you say, the disk access masks the
differences.
> > Once you take the disk access time away, the story is different.
> > Look at this one:
> >
> > Convert 10,564 lines of text (from listserver archive) to
uppercase:
> > (Timing starts after text is loaded)
> >
> > Euphoria : 0.24 seconds
> > Lua: 0.02 seconds
> >
> > -------------------
> > -- Filesort.lua
> > -------------------
> >
> > lines = {}
> >
> > readfrom("lua.txt")
> > lines = read("*all")
> > readfrom()
> >
> > start = clock()
> > lines = strupper(lines)
> > fini = clock()
> >
> > print(lines) -- to verify all is upper case
> > print(format("%2.4f",fini-start))
> >
> > --------------------
> > -- Filesort.exu
> > --------------------
> > include wildcard.e
> >
> > atom fn, start, fini
> > sequence text
> > object line
> >
> > fn = open("lua.txt","r")
> > text = {}
> > while 1 do
> > line = gets(fn)
> > if atom(line) then exit
> > else text = append(text,line)
> > end if
> > end while
> >
> > start = time()
> > text = upper(text)
> > fini = time()
> >
> > printf(1,"Time required: %2.4f",fini-start)
> >
> > Regards,
> > Irv
> >
> >
> >
>
>
>
>
>
>
14. Re: Eu Interpreted
On Tuesday 14 August 2001 15:52, Derek Parnell wrote:
>
> Irv,
> just an idea, but why don't you see what difference this makes ...
>
> Use ...
> else text &= line
>
> instead of ...
> else text = append(text,line)
If is, indeed faster: 0.17 seconds, compared to Lua's 0.02.
I picked this comparison just at random, because it seemed
simple to code. Some other benchmarks I have tried give Euphoria
the edge. For example:
Factorial:1,000 repetitions of integers from 1 to 100:
Euphoria: 1.49 seconds
Lua: 4.10 seconds
However, all this proves is that Lua seems to be much more suited
to text manipulation, while Euphoria is better at math.
Another trial:
To read a 10,500 line text file (390,780 bytes) and write it to 5 new files,
repeated 10 times, takes:
Euphoria: 49.20 seconds
Lua: 0.53 seconds !
(yes, I tested it several times. The files are there)
Looks like Lua is a better deal if you're heavily into file processing.
These tests were performed on Linux, DOS mileage may vary.
Lua, by the way, supposedly runs on DOS, Windows, Linux, OSX, Mac,
OS-9, OS/2, BeOS, PalmOS, and - ahem... Playstation II.
Regards,
Irv
15. Re: Eu Interpreted
- Posted by euman at bellsouth.net
Aug 14, 2001
I said yrs ago that I thought Euphoria file i/o was pretty
slow but I hear Robert keep saying that's just not so..
Lua beat up on Eu didnt it...
Robert, what are your plans for this, if any?
Maybe unleashing some more speed in this area would
be a great selling point....
Euman
euman at bellsouth.net
> However, all this proves is that Lua seems to be much more suited
> to text manipulation, while Euphoria is better at math.
>
> Another trial:
> To read a 10,500 line text file (390,780 bytes) and write it to 5 new files,
> repeated 10 times, takes:
> Euphoria: 49.20 seconds
> Lua: 0.53 seconds !
> (yes, I tested it several times. The files are there)
>
> Looks like Lua is a better deal if you're heavily into file processing.
> These tests were performed on Linux, DOS mileage may vary.
> Lua, by the way, supposedly runs on DOS, Windows, Linux, OSX, Mac,
> OS-9, OS/2, BeOS, PalmOS, and - ahem... Playstation II.
>
> Regards,
> Irv
16. Re: Eu Interpreted
> On 14 Aug 2001, at 6:35, Chris Bensler wrote:
>
> >
> > I'm considering including an interface routine for executing the p-code
that the
> > EU script would generate. Along with a routine for converting a native
script to
> > a p-code script. This would eliminate the parser pass, reducing load
times, and
> > it would also allow for custom optimizations that couldn't be easily
done in the
> > script engine.
> >
> > What do you think? Would it be worthwhile?
>
> I don't see how you could ask that, when you apparently said me wanting to
> exec strings without including them wasn't worthwhile.
>
> Kat
I didn't say that. I basically said I don't see why you couldn't.
May be I confused you because I made a mistake. it should've said: EU
*doesn't* have a line limit
you mean this?...
<SNIP>
Why couldn't you? You can load an entire file into a single sequence.
EU has a line limit anyways. In my preprocessor I wrote, there is an option
to compact the output file (strips comments, and all unnesseccary
whitespace). The output file is only one line(excluding top level
statements), no line feeds, it executes fine. I've tried it with a file that
was over 100kb, so that's not a problem.
<SNIP>
Chris
17. Re: Eu Interpreted
Hi Jiri and Ross,
I'm sorry. I must have misunderstood Irv's purpose. I thought the code was
trying to time the upper() function, not the whole exercise of reading and
processing the data as well. If that were the case, I'd not have used
append() nor concatenation, but rather I'd have used get_bytes() to read in
the entire file in one go.
-----------
cheers,
Derek Parnell
Senior Design Engineer
Global Technology Australasia Ltd
dparnell at glotec.com.au
---------------------
--------------------------------------------------------------------
Global Technology Australasia Limited is the industry leader in next
generation financial software solutions: www.glotec.com.au
Delivering the Future of Banking Today
CAUTION - This email and any files attached may contain privileged and
confidential information intended solely for the use of the individual or
entity to whom they are addressed. If you are not the intended recipient of
this message you are hereby notified that any use, dissemination,
distribution or reproduction of this message is prohibited. If you have
received this message in error please notify the sender immediately. Any
views expressed in this message are those of the individual sender and may
not necessarily reflect the views of Global Technology Australasia Limited.
--------------------------------------------------------------------
18. Re: Eu Interpreted
Hi Irv,
please note that contrary to some people's interpretations, by attempting to
offer alternate speed test using Eu I am not trying to suggest that Euphoria
is a fast language. I would be foolish to do so with so much evidence to the
contrary. However, I do believe that it is not a slow language either. It is
certainly better at some things rather than others, as you and other have
noted.
I agree with Jiri too that some commonly used routines, currently
distributed as Euphoria coded libraries would be better suited to being
built-in. This might conflict with RDS's goal of having a simple language
though.
I coded up a file speed test similar to the one you described. Here is my
code and findings....
---------------------
include file.e
include get.e
atom start, stop, chkpt
integer fh
sequence textdata
sequence dirinfo
constant FileOutNames = {"test1.txt", "test2.txt", "test3.txt",
"test4.txt", "test5.txt"}
constant FileName = "bigfile.txt"
start = time()
dirinfo = dir(FileName)
fh = open(FileName, "rb")
textdata = get_bytes(fh, dirinfo[1][D_SIZE])
close(fh)
chkpt = time()
for i = 1 to 5 do
fh = open(FileOutNames[i], "wb")
puts(fh, textdata)
close(fh)
end for
stop = time()
printf(1, "Filesize=%d Seconds=%f in=%f out=%f\n", {dirinfo[1][D_SIZE],
stop - start,
chkpt - start,
(stop - chkpt)/5})
---------------------
H:\EUPHORIA\V055>ex speed1
Filesize=724875 Seconds=4.720000 in=0.880000 out=0.768000
This was run on a Windows 2000 machine, Dell OPTIPLEX GX115, x86 Family 6
Model 8 Stepping 6, 128Meg RAM.
I don't have Lua installed so I can't compare the two. Maybe you can use
this code to provide some comparisons.
-----------
cheers,
Derek Parnell
Senior Design Engineer
Global Technology Australasia Ltd
dparnell at glotec.com.au
--------------------------------------------------------------------
Global Technology Australasia Limited is the industry leader in next
generation financial software solutions: www.glotec.com.au
Delivering the Future of Banking Today
CAUTION - This email and any files attached may contain privileged and
confidential information intended solely for the use of the individual or
entity to whom they are addressed. If you are not the intended recipient of
this message you are hereby notified that any use, dissemination,
distribution or reproduction of this message is prohibited. If you have
received this message in error please notify the sender immediately. Any
views expressed in this message are those of the individual sender and may
not necessarily reflect the views of Global Technology Australasia Limited.
--------------------------------------------------------------------
19. Re: Eu Interpreted
From: Kat <gertie at PELL.NET>
> To: EUforum <EUforum at topica.com>
> Reply-To: EUforum at topica.com
> Subject: Re: Eu Interpreted
> Date: 15/08/2001 6:54:03 AM
>
> >
> > Irv,
> > just an idea, but why don't you see what
> difference this makes ...
> >
> > Use ...
> > else text &= line
> >
> > instead of ...
> > else text = append(text,line)
> >
> > My guess is it should be a lot faster
> because fewer sequences are involved.
>
> This is another case where the interpreter
> should be smart enough to choose
> the fastest method of attaching two
> strings together.
Hi Kat,
I'm not so sure about that. The append() version results in a sequence of
sequences, and the '&' version results in a sequence of atoms. How would the
Euphoria interpreter know which result the programmer desired, as both are
valid and useful results.
If, on the other hand, Euphoria had a built-in string data type and the
programmer was appending/concatenating two strings, then I could agree with
you.
----
Derek.
--------------------------------------------------------------------
Global Technology Australasia Limited is the industry leader in next
generation financial software solutions: www.glotec.com.au
Delivering the Future of Banking Today
CAUTION - This email and any files attached may contain privileged and
confidential information intended solely for the use of the individual or
entity to whom they are addressed. If you are not the intended recipient of
this message you are hereby notified that any use, dissemination,
distribution or reproduction of this message is prohibited. If you have
received this message in error please notify the sender immediately. Any
views expressed in this message are those of the individual sender and may
not necessarily reflect the views of Global Technology Australasia Limited.
--------------------------------------------------------------------
20. Re: Eu Interpreted
Irv Mullins writes:
> Convert 10,564 lines of text (from listserver archive) to uppercase:
> (Timing starts after text is loaded)
>
> Euphoria : 0.24 seconds
> Lua: 0.02 seconds
Again, you are comparing a single compiled C routine
built into Lua against a generic, interpreted Euphoria routine.
The world's slowest interpreter can win a benchmark that is
based on a single built-in compiled C function that it happens to have.
By the way, in search.ex I have a much faster routine,
that is not generic.
> Factorial:1,000 repetitions of integers from 1 to 100:
> Euphoria: 1.49 seconds
> Lua: 4.10 seconds
OK, finally you give us a benchmark where Lua
has to actually interpret some Lua statements, rather than
relying on a single built-in compiled C routine to do all the work.
> Another trial:
> To read a 10,500 line text file (390,780 bytes) and
> write it to 5 new files, repeated 10 times, takes:
> Euphoria: 49.20 seconds
> Lua: 0.53 seconds !
Two points:
1. We've already seen that Lua has a built-in C routine
that reads in an entire file in one gulp.
> readfrom("lua.txt")
> lines = read("*all")
2. Even so, the 49.2 seconds probably has very
little to do with I/O time, and a whole lot to do with
what you did with the characters after you
read them in. I assume you used a (n-squared time)
algorithm to concatenate the characters onto
a large and growing sequence. You could have preallocated
a large sequence and stuffed it with characters, more like what
Lua's read() does internally in C.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
21. Re: Eu Interpreted
On Tuesday 14 August 2001 20:57, Derek Parnell wrote:
>
> Hi Jiri and Ross,
> I'm sorry. I must have misunderstood Irv's purpose. I thought the code was
> trying to time the upper() function, not the whole exercise of reading and
> processing the data as well. If that were the case, I'd not have used
> append() nor concatenation, but rather I'd have used get_bytes() to read in
> the entire file in one go.
Hi Derek:
I moved the start time after the dir() command in your program, so as
not to include that in the total. I didn't need to do a dir() in Lua, in
order to read the entire file, and I haven't found Lua's equivalent yet,
anyway.
Euphoria: Filesize=390768 Seconds=0.220000 in=0.110000 out=0.022000
Lua: Seconds=0.050000 in=0.010000 out=0.008000
Subsequent runs of Lua are about 20% faster.
Subsequent runs of Eu are the same.
Regards,
Irv
-------------------------------------
-- Lua version
-------------------------------------
FileOutNames = {"test1.txt", "test2.txt", "test3.txt",
"test4.txt", "test5.txt"}
FileName = "lua.txt"
start = clock()
readfrom(FileName)
textdata = read("*all")
readfrom()
chkpt = clock()
for i = 1, 5 do
writeto(FileOutNames[i])
write(textdata)
writeto()
end
stop = clock()
print(format("Seconds=%f in=%f out=%f\n",
stop - start, chkpt - start, (stop - chkpt)/5) )
22. Re: Eu Interpreted
Hi Irv,
thanks for that.
So it looks like Lua's file operations are 4-5 times faster than Euphoria's.
Did you note that Euphoria's 'read' was 5 times longer than the 'write',
whereas Lua is about the same.
-----------
cheers,
Derek Parnell
--------------------------------------------------------------------
Global Technology Australasia Limited is the industry leader in next
generation financial software solutions: www.glotec.com.au
Delivering the Future of Banking Today
CAUTION - This email and any files attached may contain privileged and
confidential information intended solely for the use of the individual or
entity to whom they are addressed. If you are not the intended recipient of
this message you are hereby notified that any use, dissemination,
distribution or reproduction of this message is prohibited. If you have
received this message in error please notify the sender immediately. Any
views expressed in this message are those of the individual sender and may
not necessarily reflect the views of Global Technology Australasia Limited.
--------------------------------------------------------------------
23. Re: Eu Interpreted
Derek Parnell writes:
> So it looks like Lua's file operations are 4-5 times faster than Euphoria's.
Thanks Irv and Derek.
I think your latest I/O benchmark is much more reasonable
than Irv's previous one.
> Did you note that Euphoria's 'read' was 5 times longer than the 'write',
> whereas Lua is about the same.
Both Euphoria and Lua write out the file with one
call to a built-in function. Lua uses a call to a
C routine to read in a whole file,
whereas get_bytes() executes 2 interpreted
Euphoria statements *per byte* that's read in.
This explains why Euphoria's read is slower than
its write and helps to explain why Euphoria was slower overall.
Once again we see that Lua can only win
on simple benchmarks where 99% of the time is
spent inside one or two of its built-in C routines.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
