It might be worth trying the newest version of gcc and using -march=native. You're tuning for pentium4 which may not be very good. Are you using the same compiler version on the CentOS machine? If so, then likely Tim is right and it's one of the many schedulers that is wreaking your havoc (could be the processor or IO scheduling). If it's processor, you might be able to use CPU affinity to partially solve the problem. If it's IO then it will depend on what kind of IO you are doing. I second the recommendation for oprofiling your code. Brian On 6/12/09, Brian McGrew <brian@xxxxxxxxxxxxx> wrote: > Top of the morning to y¹all! > > I¹m a bit curious as to what optimization flags are in the newest compilers > and how they¹d work with the newest CPU¹s versus the last generation of > CPU¹s. > > Our older systems we Dell Precision T5400 workstations with dual Intel Xeon > 5420 CPU¹s at 2.33GHz with 6MB of cache per core. The cache breaks out to > be 32k of L1 cache and 6MB of L2 cache. > > Now, we¹re getting Dell Precision T5500 workstations with dual Intel Xeon > 5506 CPU¹s at 2.21GHz with 4MB of cache per core. But, the cache breaks > down as 32k L1 cache, 256k L2 cache and 4096k L3 cache. > > Out application is very processor and disk I/O intensive and it runs about > 6x slower on the newer hardware versus the old. We¹re currently compiling > with gcc-4.1.1 using the following optimization flags on Fedora Core 5 using > a 2.6.16.16 kernel. As it happens, the code runs seemlessly on CentOS 5.2 > with a 2.6.18 kernel as well. Upgrading compilers, if there is a compelling > reason is an option for us. Upgrading kernels, at this time is not an > option because of 3rd party hardware support. > > Our compiler flags are: > > -g O2 funroll-loops finline-limit=2750 pipe ansi pedantic Wimplicit > Wconversion Wsign-compare Wno-long-long Wreorder Woverloaded-virtual > Wsign-promo march=pentium4 mfpmath=sse malign-double > > (Not necessarily in this order... But, is order important???) > > Thanks, > > -b > -- > > >
