On Thu, 12 May 2011 20:54:16 +0200 cobines <cobi...@gmail.com> wrote
> I have written the following program:
> ...
> max := 100000000;
> for i := 0 to max do
> vd := i / max;
A really smart compiler would notice that this in this loop the value of
vd is never examined, the loop being equivalent to
vd := 1 ;
and would code it appropriately. This sort of thing caused all kinds of
trouble some 20 (30?) years ago with benchmarks involving small
timing loops of this kind. One has to be very, very careful before
believing such timing results!
I have recently been "modernizing" my old benchmark programs, with
many bizarre results. Funny things like replacing fixed size arrays by
dynamic ones making things slower ... until I put the code inside
a subroutine: the optimizer did a super job optimizing access to the local
variables inside the subroutine!
One should really use a large, complex program to test how well
optimization works. Results with short loops are, as you found, likely
to give inconsistent and misleading results.
By the way, I gave up writing Assembler programs for number crunching
when optimized Free Pascal got within 10% of the best I could do. That
was some years ago and there have been several improvements in
Free Pascal since: the compiled code is now, I think, faster than anything
I could do in Assembler. And, yes: I have the odd program that goes
faster with optimization off! Most like optimization on.
For comparison, my Assembler was over 4 times faster than Turbo
Pascal 3.01A for a similar number crunching application.
Andrew Bennett
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
