On 4 apr 2006, at 13:46, Пётр Косаревский wrote:
No, it's a very common cases on all cpus which have a reasonable
amount of available registers.
With 3-4 dynamical arrays and several parameters?
It all depends on how many parameters, how many other variables and
how they are used. But a PPC has on average about 27 or so registers
available for register variables (19 if the procedure makes any
calls), and
What can I do to speed up dynamical arrays?
What can I do to speed up static arrays?
I mean: what is the shortest way to estimate speed?
The only way is profiling your complete program and looking where the
bottlenecks are. Performance estimation is very complex and depends
on a lot of factors. In most cases it is impossible to say in advance
"X will will always be faster than Y".
I don't know, why with "a[j]:=a[999999-j]"
(yes, entering something other than 1000000 is likely to generate
one exception or another, I did so to avoid processing array size
as constant)
static is faster and with "a[j]:=1" and "a[j]:=a[0] xor a[j]"
dynamic is faster (this one is about 7719 vs 4405, dynamic wins!).
I don't know either. Have a look at the generated assembler. Maybe in
one case the optimizer misses something which it catches in the other
case.
Passages in answer to "braindead architecture":
All your explanations do not change anything about the fact that it
is a braindead architecture which is very hard to work with from a
compiler point of view, and that we often only have 5 or so registers
to work with (with only 3 available for regvars if there are any
calls during the lifetime of the variable).
We are not on purpose generating suboptimal code for the x86. In
fact, the x86 is the only target cpu for which we have a fairly
complicated optimizer and for which the code generator uses a lot of
tricks to get as much performance as possible. It is also the only
one that really needs that, most others already get close to fairly
optimal performance by just enabling register variables.
Jonas_______________________________________________
fpc-devel maillist - [email protected]
http://lists.freepascal.org/mailman/listinfo/fpc-devel
