Hi,
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 seconds
You 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.
|