Kevan Hashemi wrote:
Most things take two or three times as long with GPC. I expect code running on MacOS X (UNIX) to be slower than code on MacOS 9 because MacOS X is re-entrant, is subject to pre-emptive multitasking, and provides protected memory.
Provided the hardware supports these features (I suppose it does, though I don't have a Mac myself) and there's no heavy concurrent load (which would cause context switches etc.), this should hardly matter.
I am more interested in the fact that the GPC round() function takes four times as long as the GPC implementation of a:=a*a/a, while the CW round() function takes about the same time as the CW implementation of a:=a*a/a.
As you know, rounding a number with platform-independent mathematical functions is slow. The CW round() probably uses the Power PC real number format to abbreviate the rounding process. Perhaps GPC uses a platform- independent implementation.
It does -- and in addition it's harmed by the fact that Pascal's rounding does not match either of the 4 IEEE rounding modes, so it's implemented as "Trunc (if x >= 0.0 then x + 0.5 else x - 0.5)", according to the standard's description:
: From the expression x that shall be of realÂtype, this function : shall return a result of integer type. If x is positive or zero, : round(x) shall be equivalent to trunc(x+0.5); otherwise, round(x) : shall be equivalent to trunc(x-0.5) It shall be an error if such a : value does not exist.
I.e., round to nearest and half-integers towards +/-infinity. It does appear strange, maybe an unintentional feature, and I don't know which other Pascal compilers actually implement this ...
I have always used round() with sinusoidal look-up tables in my fourier transforms. The above results suggest that I gained very little by doing so.
Maybe using `Trunc' (and adjusting the tables accordingly, or using `Trunc (x + 0.5)' if you know the argument will always be non-negative) is an option.
Frank