the two different kernels don't matter in this case, as they only indicate on what kernel the perl was compiled on. Actually both interpreters run on the same kernel (2.4.26) now.
Also I don't see any issue in comparing various perls compiled with various compilers. Basically we tried to be as pragmatic as possible: Given Perl X (where X is the parameter space): What can we do to make it faster?
It was mentioned here, that disabling threads helps a lot (which I can confirm), but that also some e.g. linux distributions ship perl with threads enabled by default.
I've recompiled Perl once again, this time also for the specific P4 architecture and fpmath=sse. The result: Binary is about 200k shorter, and the following execution times:
Normalization of a Swedish Lexicon in our Language Processing Suite: own 5.8.0-threaded (old): 241 seconds system 5.8.0+threads: 196 seconds "fast baby" from above: 178 seconds "new fast baby" (P4): 161 secondsYou know - from a practical point of view it is not important how the speed gain was achieved, it's just important THAT it can be achieved, and that compilation of perl can matter.
And one poster was right: The GCC we've used still didn't use autovectorization. I'm very interested what this will bring.
perlcc is not an issue as it cannot compile even the simpler modules... Not even the -o option.
Bye
PetaMem All Perl: MT, NLP, NLU
In reply to Re^2: How to make your Perl 30% faster
by PetaMem
in thread How to make your Perl 30% faster
by PetaMem
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |