I'm currently loading some new servers with CentOS6 on which perl5.10 is
the standard version of perl provided. However, I've also loaded perl5.18
and I don't think the version of perl is significant in the results I'm
seeing. Basically, I'm seeing perl performance significantly slower on my
new systems than on my 6 year old systems.

Here's some of the relevant details:

+ 6 year old server, 32 bit architecture, CentOS5 perl5.8
perl, and in particular regexp operations, perform reasonably fast.

+ Very new server, 64 bit architecture, CentOS6, perl5.10 (and have tried
perl5.18)
perl, and in particular regexp operations, perform significantly slower
than on the 6 year old server. That struck me as odd right off. I though
surely, perl running on a modern high-end cpu is going to beat out my code
running on 6 year old hardware.

I've compared CPU models at various CPU benchmarking sites and the new
CPUs, as you would expect, are ranked significantly higher in performance
than the old.

I've also installed perl5.8 on the new 64bit servers and the performance is
similar to that of perl5.10 and perl5.18 on the same 64bit servers. Given
that, I don't think perl version plays a significant factor is the
performance diffs.

Is it an accepted fact that perl performance takes a hit on 64 bit
architecture?

I've tried comparing some of the perl -V and Config.pm results looking for
significant differences. That output is pretty verbose and the most
significant difference is the architecture.

I could provide some of my benchmarking code if that would be of help. The
differences are significant. The only reason I'm looking at this is because
I could see right off that some of my code is taking 30-40% longer to run
in the new environment. Once I started putting in some timing
with Time::HiRes I could see the delay involved large amounts of regexp
processing.

Right now, I'm just looking for any opinions on what I'm seeing so that I
know the architecture is the significant factor in the performance
degradation and then consider any recommendations for improvements. I'm
happy to provide further relevant details.

Thanks,
Phil

Reply via email to