1. Euphoria bug
--I've been getting a lot of misleading results during benchmarking
--of various large structures which prompted an investigation.
--The following example shows an anomaly I found.
--Run the programme with and without releasing the commented loop(s)
--and note the speed of the loops. 1D structures are fast and behave normally.
sequence s
atom t
object data
constant repeats = 1000000, len = 1000
s = repeat(repeat({}, len), len)
-- --this loop always appears to be fast and speeds up all following loops
-- t = time()
-- for n = 1 to repeats do
-- s[length(s)][length(s)] = {3333, 7777}
-- data = s[length(s)][length(s)]
-- end for
-- ?time()-t
-- t = time()
-- for n = 1 to repeats do
-- s[999][999] = {3333, 7777}
-- data = s[999][999]
-- end for
-- ?time()-t
t = time()--identical to the second loop
for n = 1 to repeats do
s[999][999] = {3333, 7777}
data = s[999][999]
end for
?time()-t
machine_proc(26,0)
2. Re: Euphoria bug
- Posted by Vincent <darkvincentdude at yahoo.com>
Sep 13, 2005
-
Last edited Sep 14, 2005
Bob Thompson wrote:
>
> --I've been getting a lot of misleading results during benchmarking
> --of various large structures which prompted an investigation.
> --The following example shows an anomaly I found.
> --Run the programme with and without releasing the commented loop(s)
> --and note the speed of the loops. 1D structures are fast and behave normally.
>
> sequence s
> atom t
> object data
> constant repeats = 1000000, len = 1000
>
> s = repeat(repeat({}, len), len)
>
> -- --this loop always appears to be fast and speeds up all following loops
> -- t = time()
> -- for n = 1 to repeats do
> -- s[length(s)][length(s)] = {3333, 7777}
> -- data = s[length(s)][length(s)]
> -- end for
> -- ?time()-t
>
> -- t = time()
> -- for n = 1 to repeats do
> -- s[999][999] = {3333, 7777}
> -- data = s[999][999]
> -- end for
> -- ?time()-t
>
> t = time()--identical to the second loop
> for n = 1 to repeats do
> s[999][999] = {3333, 7777}
> data = s[999][999]
> end for
> ?time()-t
>
> machine_proc(26,0)
>
Excellent find! The bug is in Euphoria v2.4 as well. It took 1 second to execute
the first 2 blocks, but when I commented them out, it took 10 seconds to execute
the last block.
Regards,
Vincent
3. Re: Euphoria bug
- Posted by Matt Lewis <matthewwalkerlewis at gmail.com>
Sep 13, 2005
-
Last edited Sep 14, 2005
Bob Thompson wrote:
>
> --I've been getting a lot of misleading results during benchmarking
> --of various large structures which prompted an investigation.
> --The following example shows an anomaly I found.
> --Run the programme with and without releasing the commented loop(s)
> --and note the speed of the loops. 1D structures are fast and behave normally.
>
What I find interesting is that you only have to assign something to a
sub-sequence:
s[1][1] = 0
...before the loop, and it runs quickly.
Matt Lewis
4. Re: Euphoria bug
- Posted by Al Getz <Xaxo at aol.com>
Sep 13, 2005
-
Last edited Sep 14, 2005
Hello,
I find that if you assign
s[999][999]={1,1} --same structure as loop's assignments
the loop runs fast anyway, without using the first loop.
This of course means it's not actually the loop itself causing
the speedup...it's what gets put into the sequence initially.
The time difference (20 seconds on mine) is absolutely astonishing,
however. 1/2 second compared to 20 seconds....WOW.
This makes me think that when we run into long time delays
perhaps we should check to see how we are initializing our
sequences...a simple assignment might speed things up 40 times!
Rob should probably look at this...
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
5. Re: Euphoria bug
Don't forget about the code parseing and other delays that the interpretor
may incure on code execution. for true code timing results the code should
be bound as an executable.
6. Re: Euphoria bug
Bob Thompson wrote:
> --I've been getting a lot of misleading results during benchmarking
> --of various large structures which prompted an investigation.
> --The following example shows an anomaly I found.
> --Run the programme with and without releasing the commented loop(s)
> --and note the speed of the loops. 1D structures are fast and behave normally.
>
> sequence s
> atom t
> object data
> constant repeats = 1000000, len = 1000
>
> s = repeat(repeat({}, len), len)
>
> -- --this loop always appears to be fast and speeds up all following loops
> -- t = time()
> -- for n = 1 to repeats do
> -- s[length(s)][length(s)] = {3333, 7777}
> -- data = s[length(s)][length(s)]
> -- end for
> -- ?time()-t
>
> -- t = time()
> -- for n = 1 to repeats do
> -- s[999][999] = {3333, 7777}
> -- data = s[999][999]
> -- end for
> -- ?time()-t
>
> t = time()--identical to the second loop
> for n = 1 to repeats do
> s[999][999] = {3333, 7777}
> data = s[999][999]
> end for
> ?time()-t
>
> machine_proc(26,0)
Thanks for reporting it.
I've duplicated the problem on my machine.
It seems that almost any change you make can cause
it to run fast. I haven't had time to track it down,
but working with a stripped down version suggested by
Matt Lewis, I found that simply changing:
data = s[999][999]
to:
data = s[998][999]
Makes it fast.
sequence s
atom t
object data
constant repeats = 1000000, len = 1000
s = repeat(repeat({}, len), len)
-- s[1][1] = 0 -- makes it fast - Matt Lewis
t = time()--identical to the second loop
for n = 1 to repeats do
s[999][999] = {1, 1}
data = s[999][999]
-- data = s[998][999] -- makes it fast
end for
?time()-t
This makes me think there might be a
quirky situation here to do with reference counts,
that causes a sequence to be copied on overwrite (slow case)
or not copied (fast case).
It's getting late.
I'll investigate it tomorrow.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
7. Re: Euphoria bug
Robert Craig wrote:
>
> This makes me think there might be a
> quirky situation here to do with reference counts,
> that causes a sequence to be copied on overwrite (slow case)
> or not copied (fast case).
>
Interestingly, I couldn't get it to duplicate after translating and
compiling.
Matt Lewis
8. Re: Euphoria bug
Matt Lewis wrote:
>
> Robert Craig wrote:
> >
> > This makes me think there might be a
> > quirky situation here to do with reference counts,
> > that causes a sequence to be copied on overwrite (slow case)
> > or not copied (fast case).
> >
>
> Interestingly, I couldn't get it to duplicate after translating and
> compiling.
>
> Matt Lewis
>
It seems the bug effects bound programs too, so it probably narrows it down to
the C coded backend. It's also effects the PD-source either interpreted,
translated/compiled or bound, so it may be a bug in the Euphoria coded backend as
well.
But when I translate & compiled the program itself (Open Watcom v1.4 beta), the
bug seems to disapear like you say; Or maybe the 3-5x speedup just makes it seem
like the bug has disapeared?
Regards,
Vincent
9. Re: Euphoria bug
Vincent wrote:
>
>
> It seems the bug effects bound programs too, so it probably narrows it down to
> the
> C coded backend. It's also effects the PD-source either interpreted,
> translated/compiled
> or bound, so it may be a bug in the Euphoria coded backend as well.
>
> But when I translate & compiled the program itself (Open Watcom v1.4 beta),
> the bug
> seems to disapear like you say; Or maybe the 3-5x speedup just makes it seem
> like the bug
> has disapeared?
>
No. Interpreted, I was getting about 7 seconds (~ 0.1 sec under the
'modified' source that made it run fast). The 'slow' source version, once
translated, was down under 0.1 sec, so I think it must be somewhere in the
backend.
Matt Lewis
10. Re: Euphoria bug
>Bob Thompson wrote:
<snip>
Yeah! Finally I have a program which runs faster on Posetf that RDS!
<scnr>
>Matt Lewis wrote:
>What I find interesting is that you only have to assign something to a
>sub-sequence:
>}}}
<eucode>
> s[1][1] = 0
></eucode>
{{{
>...before the loop, and it runs quickly.
That does not seem to make a difference here.
>Robert Craig wrote:
>Matt Lewis, I found that simply changing:
> data = s[999][999]
>to:
> data = s[998][999]
>Makes it fast.
Thinking that this is some kind of reference count problem, I tried:
data = s[999][999]
data = 0
and to my astonishment, it made no difference. What is doubly odd is
data = s[999][999]
data = s[998][999]
/DOES/ make it better. Odd, indeed!
Regards,
Pete
11. Re: Euphoria bug
On Thu, 15 Sep 2005 00:39:12 +0100, Pete Lomax
<petelomax at blueyonder.co.uk> wrote:
>and to my astonishment, it made no difference. What is doubly odd is
>
> data = s[999][999]
> data = s[998][999]
>
>/DOES/ make it better. Odd, indeed!
The other obvious thing to try is:
data = s[999][999]
data = s[999][998]
which still runs dog-slow, so I now think it is a problem in the ref
count of s[999], not s[999][999], iyswim.
I also just tried len=2, and think I still saw a 50% hit (bicbw),
though not (fairly obviously) as bad as (5000%?) reported.
Regards,
Pete
12. Re: Euphoria bug
> >Matt Lewis wrote:
> >What I find interesting is that you only have to assign something to a
> >sub-sequence:
> >}}}
<eucode>
> > s[1][1] = 0
> <font color="#330033">></eucode>
{{{
</font>
> >...before the loop, and it runs quickly.
> That does not seem to make a difference here.
Are you sure Pete? I thought a variation on Matt's code would be a neat
temporary fix.
sequence s
atom t
object data
constant repeats = 100000, len = 1000
s = repeat(repeat({}, len), len)
s[1][1] = {}--doesn't change initial structure and makes it fast
t = time()
for n = 1 to repeats do
s[999][999] = 1
data = s[999][999]
end for
?time()-t
machine_proc(26,0)
13. Re: Euphoria bug
On Thu, 15 Sep 2005 11:20:08 -0700, Bob Thompson
<guest at RapidEuphoria.com> wrote:
>Are you sure Pete?
It still runs slow on 2.4, but yes, I see it does speed it up on 2.5.
However, it is obviously only working by luck. I now think that the
problem is with ref counts on temp (hidden) vars. Consider this:
for n = 1 to repeats do
s[999][999] = n
tmp = s[999]
data = tmp[999]
end for
This runs like a dog, and I would expect it to.
The problem is that s[999] gets a refcount of 2, so storing in the
999'th element of s[999] must clone it, every iteration bar 1.
IE s[999][999] = n must set s[999] to {.....,n} but leave tmp set to
{......,n-1}, [see PS]
If you insert tmp=0 just before the end for, it runs 100 times faster.
It runs 100 times faster because the refcount on s[999] is put back
down to 1 so it does not need to be cloned, ever.
In fact, the interpreter uses a temp var in much the same way as
above, only it really ought to remove any ref count side effects once
it has done with using the temp var. Unrolling the data = s[999][999]
statement in this case is only doing what the interpreter would do
internally, so it will be just (or at least almost) as fast as can be.
Hope that makes sense,
Pete
PS I can tell my desc of s[999] is not quite right; maybe it needs two
clones every iteration, but I'm tired and I'm late already, and you
get the idea, I'm sure.
PPS I might have a look at eu.ex tomorrow.
14. Re: Euphoria bug
Look at this modified version of Bob's code snippet.
Now, if you set speed_loop to 0, it still speeds up the
loops that follow as long as the assignment is not commented
out. It is not necessary for the interpreter to execute the
assignment!
-- copyright Bob Thomson
-- modified by Shawn Pringle
--I've been getting a lot of misleading results during benchmarking
--of various large structures which prompted an investigation.
--The following example shows an anomaly I found.
--Run the programme with and without releasing the commented loop(s)
--and note the speed of the loops. 1D structures are fast and behave normally.
include msgbox.e
constant speed_loop = 0
sequence s
atom t
object data
constant repeats = 10000, len = 1000
sequence output
output = ""
s = repeat(repeat({}, len), len)
if speed_loop then
-- this speeds up all following loops
-- even if it is not executed!
s[len][len] = s[len][len]
end if
t = time()
for n = 1 to repeats do
s[999][999] = {3333, 7777}
data = s[999][999]
end for
output &= sprint(time()-t) & 10
t = time()--identical to the second loop
for n = 1 to repeats do
s[999][999] = {3333, 7777}
data = s[999][999]
end for
output &= sprint(time()-t) & 10
if message_box( output, "Information", MB_OK ) then
abort(0)
end if
