OpenEuphoria

Re: Dramatic slowdown -ping Rob

• Posted by Mario Steele <eumario at trilake.net> Nov 30, 2004
• 585 views

I have actually found something of much intrest....

I do not have a copy of 2.4 readily at my disposal,
but this test has come up with some.... shall we say,
interesting points.  This problem at hand, may be due
to Heap Corruption as Pete suggested, but it may be
not what your expecting.

I'm running a AMD Athlon XP 2.16 GHz Proccessor with
192 Megs of ram, and for the original source code as
given by Pete, the results are as follows:

ex.exe (27): 0.110000
ex.exe (28): 0.110000

However, I was going to test this with exw.exe, and
needed to throw in a pause before exiting execution,
so I use my normal, while get_key() = -1 do end while
to the end of the code, so I could see the results.

However, I forgot I put this in, when I went to re-test
the code on ex.exe, and found a surprising result.

constant START = time()
constant INNER=27
sequence table
		table=repeat(repeat(0,INNER),1024)
integer used
		used=1

for i=1 to 45000 do
	used+=1
	if used>length(table) then table&=repeat(repeat(0,INNER),1024) end
if
	table[used][5]=used
end for

printf(1, "Elapsed time: %f\n", time() - START)
while get_key() = -1 do end while

One would belive this would return the same result as before,
however, these are the results I got:

ex.exe (27): 2.030000
ex.exe (28): 2.090000

Now, taking from Rob's own admitance, it seems to me, that
it's not the actual execution that's resulting in these
times, but instead, the backend may be corrupting the
heap when it releases the memory before executing the
IL code generated by the frontend.

There's definatly something going on, for the interpreter
to be generating this much of a diffrence between the
original code, to 1 loop inheritance added, with absolutely
no code inside actually executed, except for get_key().

Just letting ya know,
EuMario


Pete Lomax wrote:
> 
> On Sun, 28 Nov 2004 20:29:12 -0800, Robert Craig
> <guest at RapidEuphoria.com> wrote:
> 
> >As promised, I looked into the performance issue raised
> >by Pete Lomax a while back. I don't think there is any
> >bug in Euphoria itself (ref counts etc.). 
> >I rather think WATCOM's storage 
> >allocator for DOS has some very quirky behavior. In exw.exe
> >I don't use the WATCOM allocator, I use Microsoft's.
> Thanks for looking into this. Now I know it's a problem in ex rather
> than exw, I'm no longer overly concerned about it.
> >I earlier reported no problem with ex.exe for 2.5,
> >but I think I must have been using exw.exe for 2.5.
> >exw runs the code below very fast regardless of the 
> >size of the sequences. People noticed a big slowdown
> >with ex.exe when moving from 27 to 28. I believe that's because 
> >I allocate 50% more space when the size becomes 28. 
> >For speed in handling small sequences, I map to a set of 
> >standard memory block sizes:
> >16, 24, 32, 48, 64, 96, 128 bytes, 192 bytes, 256 etc.
> >I think 27 would need 128, while 28 would need 192.
> >
> >However, strangely enough, when the size is increased from 28 to 
> >100, it runs really fast, even though more processing is being
> >done by Euphoria.
> Sounds to me like Watcom has a problem with 192, which is not all that
> surprising since few C programs are likely to allocate tens of
> thousands of blocks of (just) that size. You've probably thought of
> this already, but you might want to consider avoiding the problem in
> ex by removing the 192 size (ie just in ex, leave it in exw and exu)?
> As I said, it does not really bother me personally, but I know that
> "speed is something of an obsession for you".
> 
> Regards,
> Pete