Re: modified reverse
Derek Parnell writes:
> Strange but I found rforno's version slightly slower (96%) than the
> standard.
Yes, I searched the mailing list archives, and found a comparison
I did between the current reverse() and a version identical to
rforno's 3 years ago. I was using my old Pentium-150 machine,
and found the current reverse() was faster. That's why I chose it.
Now I have a Pentium II with a different cache size etc.
> One way to get the standard one going slightly faster is to force
> an integer conversion of the floor() function.
> Because the floor() function is in the for..loop, Euphoria assumes
> that it is possible to generate a really big result and does
> tests for atom-ness and integer overflow on every
> comparison of the 'upper' variable. It even does extra
> work when adding one to it for the next iteration,
> just in case it overflows the integer bounds.
Good idea. I'll assign to an integer before the loop.
Note that this helps the translated code quite a bit,
but helps the interpreter very little because the interpreter
decides each time at the start of a for-loop (after
evaluating the expressions) whether
the loop variable can only have integer values or not
during the loop. It then self-modifies some of
the code for the loop. The translator has to decide once
and for all at compile-time when it generates the C code.
If there is any doubt (as in this case), it can't assume integer-only.
The only alternative for the translator would be to
to generate multiple copies of the entire loop and choose
one of them at the start, at run-time.
This would typically be a lot of C code to generate.
(Of course if the translator were *really* smart, it would realize that
floor(x/2)+1 must always be an integer, if x is an integer).
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
|
Not Categorized, Please Help
|
|
