Hallo Fred,
after I wrote the last message, I became curious myself about the
performance of the various fpc compilers for "standard" operations
also. So I wrote a VERY limited test program, doing an exhaustive set
of permutations of the characters of a string. It's hideously simple
minded, this is the source code:
PROGRAM permuter;
PROCEDURE Permutation (InString: string; level: integer);
VAR
p: integer;
c: char;
BEGIN
FOR p:= succ (level) TO Length (InString) DO BEGIN
c:= InString [p];
InString [p]:= InString [level];
InString [level]:= c;
// WriteLn (level, ';', p, ': ', InString);
Permutation (InString, succ (level));
END;
END;
VAR
permutated: string;
BEGIN
IF ParamCount < 1 THEN BEGIN
WriteLn ('No String to permute!'); Halt (1);
END;
permutated:= ParamStr (1);
Permutation (permutated, 1);
END.
The sequence of successive permutations is performed by recursion, the
permutations themselves use a for loop. I did exclude any output to
not affect execution performance by use of system functions.
These are the results for the 12 character long parameter string
"abcdefghijklm" (processing times depend STRONGlY on size!):
permuter_322: permuter_331: permuter_llvm:
real 0m22,605s real 0m21,743s real 0m23,238s
user 0m22,595s user 0m21,732s user 0m23,224s
sys 0m0,002s sys 0m0,001s sys 0m0,003s
permuter_322_O2: permuter_331_O2: permuter_llvm_O2:
real 0m16,926s real 0m17,010s real 0m17,819s
user 0m16,915s user 0m17,003s user 0m17,807s
sys 0m0,004s sys 0m0,000s sys 0m0,004s
permuter_322_O3: permuter_331_O3: permuter_llvm_O3:
real 0m16,997s real 0m17,013s real 0m17,649s
user 0m16,988s user 0m17,003s user 0m17,640s
sys 0m0,001s sys 0m0,002s sys 0m0,002s
permuter_322_O4: permuter_331_O4: permuter_llvm_O4:
real 0m16,985s real 0m17,025s real 0m17,685s
user 0m16,976s user 0m17,015s user 0m17,674s
sys 0m0,001s sys 0m0,002s sys 0m0,003s
executable sizes:
191056 permuter_322 198192 permuter_331 302144 permuter_llvm
191056 permuter_322_O2 198192 permuter_331_O2 302144 permuter_llvm_O2
191056 permuter_322_O3 198192 permuter_331_O3 302144 permuter_llvm_O3
191056 permuter_322_O4 198192 permuter_331_O4 302144 permuter_llvm_O4
Interestingly, the executable sizes do NOT depend on the optimization
level, that was the case for the previous tests as well.
The timing values show a saturation of performance at optimization
level O3, going beyond that doesn't make a measurable difference any
more. Here, fpc 3.3.1 even outperforms fpc 3.2.2 (slightly) with no
optimization, and the plain fpc 3.2.2. does similar with the llvm-based
version on all levels.
BTW, as I saw you mentioning crashes with fpc-llvm compiled programs
when optimization was used, I checked cursorily this with "MSEclock"
also. Using no optimization, I had already made sure it works with all
three complier variants I have now. Now, I also tried fpc-llvm with O3,
and it did work correctly. But I DO use the already modified library
files from (one of) your last commit(s) correcting the "longword vs.
pointer" issue mentioned somewhere. And I have to concur with Jonas
Maebe that it was (and maybe, at some places still IS) a very serious
error to use a longword parameter for a return value thats (probabely,
I didn't check thoroughly) specified as a pointer, even if its value is
not used. The issue even had come up quite a while ago, during the
transition from 32- to 64-bit CPUs, when someone wanted to use the
integer typed field (I cannot remember its name) left unspecified for
the programmer, to store a pointer to some component within, and the
compiler warned of "loss of precision" or some such. Then, Martin
(himself, still) extended that field or did he introduce another one?)
to a newly created "pointerint" of sufficient size to also accomodate
a 64-bit pointer.
BTW too, during compilation I'm always struck by a good number of
compiler messages like "variable ... not used" or "Case statement does
not handle all possible cases" or so. Though these usually will not
have any noticable effect, they're distracting and probabely should be
avoided. I was about to locate their causes and amend them already, but
always got distracted by something more important (or, at least,
interesting), so I haven't done this yet. I hope to get at it "soon".
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------
_______________________________________________
mseide-msegui-talk mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
