OpenEuphoria

Re: Dramatic slowdown -ping Rob

• Posted by Robert Craig <rds at RapidEuphoria.com> Nov 30, 2004
• 554 views

Mario Steele wrote:
> 
> 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.
> 
> }}}
<eucode>
> 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
> </eucode>
{{{

> 
> 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

I tried a few more experiments, and yes, it seems
you can flip ex from fast to slow, by making other 
seemingly unrelated changes, besides just changing 
the sequence lengths. exw seems to always be fast.

This is not a 2.5-specific issue.
Pete originally reported it using 2.4,
a few days before 2.5 came out. I have also
confirmed it using 2.4, as have some other people.

Watcom's allocator is complex, as are most allocators 
that try to achieve high performance. I don't think
corruption is taking place, because the same, correct
result is produced whether it's running fast or slow.
Also, when it runs slow, it actually starts off fast and gradually
slows down, suggesting that maybe it is searching through 
an increasing number of memory blocks, looking for a free block of
the right size. I believe Watcom may be using a system where
blocks are marked with a bit that indicates whether they are free
or not. In some cases I suspect Watcom searches
through all blocks, free or in use, looking for a free block
of the right size. This would slow it down as more blocks are 
allocated, but I think they also use other algorithms in some cases.
Most allocators search a linked list containing only free blocks.

Thanks,
   Rob Craig
   Rapid Deployment Software
   http://www.RapidEuphoria.com