Given that most/all of the recent boxes (ie the ones doing the real work) are P4s and Athlons it is time RedHat stopped compiling with -mcpu=i686 and started optimizing for the P4: -mcpu=p4
Another point is that there is no such thing like low-level glibc functions for the P4 and the Athlon. The highest targetted processor is the PIII. However documents in AMD's web site show that moving data (ie memcpy and friends) can be made several times faster if using 3DNow instructions and data prefetching, I gave only a cursory glance to the assembler parts of glibc but it didn't look like those parts (targetting the PIII) would be even remotely ideal for the Athlon. Same thing about the P4.
Would it be possible for RedHat to contact those with an interest ie AMD/Intel in order to get high-pedrformance assembly versions of those low level routines? Or failing that to have them written by an employee?
The point of the i686 instructions, is that certain key instructions became available, not that the scheduling is perfect. Have you timed the benefit of using -mcpu=p4 over -mcpu=i686? Is it really worthwhile? Or are you just guessing?
I wouldn't mind if a PIII version came with RedHat - but then again, it is very easy to recompile the kernel for PIII, deselect all the crap that I don't want, and have an optimal system. I don't need RedHat to change their distribution to satisfy my whim.
As for GLIBC optimized support for P4 or the latest AMD chips, RedHat is probably the wrong organization to ask. What is the business case? I'm sure people on the GLIBC mailing lists would be glad to receive patches from you that implement proven optimizations...
Just some perspective... :-) mark
On Wed, Aug 13, 2003 at 10:23:01PM +0200, Jean Francois Martinez wrote:
Given that most/all of the recent boxes (ie the ones doing the real work) are P4s and Athlons it is time RedHat stopped compiling with -mcpu=i686 and started optimizing for the P4: -mcpu=p4
Another point is that there is no such thing like low-level glibc functions for the P4 and the Athlon. The highest targetted processor is the PIII. However documents in AMD's web site show that moving data (ie memcpy and friends) can be made several times faster if using 3DNow instructions and data prefetching, I gave only a cursory glance to the assembler parts of glibc but it didn't look like those parts (targetting the PIII) would be even remotely ideal for the Athlon. Same thing about the P4.
Would it be possible for RedHat to contact those with an interest ie AMD/Intel in order to get high-pedrformance assembly versions of those low level routines? Or failing that to have them written by an employee?
On Wed, Aug 13, 2003 at 10:23:01PM +0200, Jean Francois Martinez wrote:
Given that most/all of the recent boxes (ie the ones doing the real work) are P4s and Athlons it is time RedHat stopped compiling with -mcpu=i686 and started optimizing for the P4: -mcpu=p4
RHL glibc is compiled with -march=i686 actually, and there are not many instructions other than those enabled by -mfpmath=sse which would the compiler generate for normal code with -march=pentiumiii and not -march=i686 (the only difference is scheduling and to my knowledge the difference is not very big between i686 and PIII). -mfpmath=sse is not usable for libm, because glibc on IA-32 relies on extended precision in several places. Scheduling difference between P4 and i686 is bigger, but I don't think that code runs that well on Athlons.
Another point is that there is no such thing like low-level glibc functions for the P4 and the Athlon. The highest targetted processor is the PIII. However documents in AMD's web site show that moving data (ie memcpy and friends) can be made several times faster if using 3DNow instructions and data prefetching, I gave only a cursory glance to the assembler parts of glibc but it didn't look like those parts (targetting the PIII) would be even remotely ideal for the Athlon. Same thing about the P4.
Where have you seen PIII optimized assembly in glibc? AFAIK there is none. P4/Athlon/PIII optimized stringops are certainly welcome (patches to libc-alpha@sources.redhat.com), but bear in mind that any use of floating point regs (SSE/SSE2/whatever) has quite a big price in lazy FPU saving environment. Another thing to keep in mind is what are typical arguments to these functions.
Jakub
processor is the PIII. However documents in AMD's web site show that moving data (ie memcpy and friends) can be made several times faster if using 3DNow instructions and data prefetching, I gave only
Sometimes and for some situations. Most string ops are on short strings so actually don't benefit from fancy stuff like mmx because of the overheads (in the kernel we dont even try and do fancies until we are copying 1K or so)
Alan
On Wed, 2003-08-13 at 22:23, Jean Francois Martinez wrote:
Given that most/all of the recent boxes (ie the ones doing the real work) are P4s and Athlons it is time RedHat stopped compiling with -mcpu=i686 and started optimizing for the P4: -mcpu=p4
I still have a 486 DX2/50, an original Pentium 100 and a Pentium II 300. Well, in fact, only the Pentium II runs Red Hat Linux 9 but who knows ;-)
I agree it's time to compile with -mcpu=pentium3 for i686 kernels, and I would propose creating a "pentium4" arch for P4. But I would still keep i396 kernels compiled as -mcpu=i386.
On Wed, 2003-08-13 at 22:35, Mark Mielke wrote:
The point of the i686 instructions, is that certain key instructions became available, not that the scheduling is perfect. Have you timed the benefit of using -mcpu=p4 over -mcpu=i686? Is it really worthwhile? Or are you just guessing?
In fact I was the guy who timed the gains for gcc 2.9.x for processors based on the PPro core (ie P2, P3, Ppro, Celeron). I don't have a P4. so I cannot evaluate how big would be the gain on -mcpu=p4 versus -mcpu=i686
I wouldn't mind if a PIII version came with RedHat - but then again, it is very easy to recompile the kernel for PIII, deselect all the crap that I don't want, and have an optimal system. I don't need RedHat to change their distribution to satisfy my whim.
The -mcpu=p4 means that the compiler will only generate 386 instrructions but will use the P4 time table for optimization. For use of P4 instructions you need -march=p4 and that is not what I advocate
If we assume that most boxes in use are P4s or Athlons or at least that P4s and Athlons are the majority when speed matters (ie not for ere firewalls and similar tasks who often handled by obsolete boxes) then RedHat should be optimized for P4 (notice that does NOT mean "will run only on the P4"
As for GLIBC optimized support for P4 or the latest AMD chips, RedHat is probably the wrong organization to ask. What is the business case? I'm sure people on the GLIBC mailing lists would be glad to receive patches from you that implement proven optimizations...
There is a business case: if, for instance, Linux is left in the dust at web serving because Apache uses memcpy significantly and Linux's memcpy is three or four times slower on a P4 than the version used by W2K.
Just some perspective... :-) mark
On Wed, Aug 13, 2003 at 10:23:01PM +0200, Jean Francois Martinez wrote:
Given that most/all of the recent boxes (ie the ones doing the real work) are P4s and Athlons it is time RedHat stopped compiling with -mcpu=i686 and started optimizing for the P4: -mcpu=p4
Another point is that there is no such thing like low-level glibc functions for the P4 and the Athlon. The highest targetted processor is the PIII. However documents in AMD's web site show that moving data (ie memcpy and friends) can be made several times faster if using 3DNow instructions and data prefetching, I gave only a cursory glance to the assembler parts of glibc but it didn't look like those parts (targetting the PIII) would be even remotely ideal for the Athlon. Same thing about the P4.
Would it be possible for RedHat to contact those with an interest ie AMD/Intel in order to get high-pedrformance assembly versions of those low level routines? Or failing that to have them written by an employee?
On Wed, 2003-08-13 at 22:50, Jakub Jelinek wrote:
On Wed, Aug 13, 2003 at 10:23:01PM +0200, Jean Francois Martinez wrote:
Given that most/all of the recent boxes (ie the ones doing the real work) are P4s and Athlons it is time RedHat stopped compiling with -mcpu=i686 and started optimizing for the P4: -mcpu=p4
RHL glibc is compiled with -march=i686 actually, and there are not many instructions other than those enabled by -mfpmath=sse which would the compiler generate for normal code with -march=pentiumiii and not -march=i686 (the only difference is scheduling and to my knowledge the difference is not very big between i686 and PIII). -mfpmath=sse is not usable for libm, because glibc on IA-32 relies on extended precision in several places. Scheduling difference between P4 and i686 is bigger, but I don't think that code runs that well on Athlons.
I think I was unclear: for normal packages I advocate the use of -mcpu=p4 given that the PII/PIII boxes are being phased out and still more when we consider boxes where user requires high performance
I will do some benchamrk on athlon to see which code runs better on the Athlon but given that P4s outnumber athlons I would tend to say to "hell with athlons" despite having one.
Another point is that there is no such thing like low-level glibc functions for the P4 and the Athlon. The highest targetted processor is the PIII. However documents in AMD's web site show that moving data (ie memcpy and friends) can be made several times faster if using 3DNow instructions and data prefetching, I gave only a cursory glance to the assembler parts of glibc but it didn't look like those parts (targetting the PIII) would be even remotely ideal for the Athlon. Same thing about the P4.
Where have you seen PIII optimized assembly in glibc? AFAIK there is none. P4/Athlon/PIII optimized stringops are certainly welcome (patches to libc-alpha@sources.redhat.com), but bear in mind that any use of floating point regs (SSE/SSE2/whatever) has quite a big price in lazy FPU saving environment. Another thing to keep in mind is what are typical arguments to these functions.
I should have told i686 instead of PIII. There are 686-specific stringops in glibc but from distant memories they target the "minimal" processor in the family ie PPro and therefore don't use MMX or SSE.
There are stringops specific for the PPro family, aka i686, in glibc.
For thh argument to functions: strcpy and friends tend to act on small volumes but I am not so sure this is also true about the memcpy family.
The following is from distant memories so I can be incorrect: 1) AMD doc says that shifthing between 3DNow and FP instructions bears near zero penalty on the Athlon (ciontrarly to the K6 where it was very slow). I suppose the same is true for P4 versus PII/PIII (penalty much smaller on the newer family) 2) There is a nice performance bonus reaped by use of an Athlon instruction who prefetchs data in cache.
Now, Redhat has more than one way to get P4-optimized stringops in the glibc. One of them is have the idea suggested by one of the RedHat people who are involved in glibc maintenance. Another one is go to AMD, tell them how bad that the Athlon64 performance being hampered by a few, relatively small, but critically important, functions. When you get them, go to Intel and tell them how bad is that the Athlon64 is running circles around the P4 due to lack of optimized versions of these functions. :-)
There is a business case: if, for instance, Linux is left in the dust at web serving because Apache uses memcpy significantly and Linux's memcpy is three or four times slower on a P4 than the version used by W2K.
If apache is block copying 32K chunks around then there is a much better cure - fixing apache. It isnt "lets do big memory copies fast" first of all but "why am I doing big memory copies".
In the case of the PIV I've also seen little evidence to suggest any meaningful different between rep movs and fancy stuff even on big blocks unless you have innate knowledge of cache handling and local use (which glibc doesn't). Intel seem to have nice silicon fast paths for this stuff
Given that most/all of the recent boxes (ie the ones doing the real work) are P4s and Athlons it is time RedHat stopped compiling with -mcpu=i686 and started optimizing for the P4: -mcpu=p4
Got any actual evidence to back this up? I didn't think so.
I do plenty of real work with my dual P-III system.
On Wed, 2003-08-13 at 15:43, Jean Francois Martinez wrote:
If we assume that most boxes in use are P4s or Athlons or at least that P4s and Athlons are the majority when speed matters (ie not for ere firewalls and similar tasks who often handled by obsolete boxes) then RedHat should be optimized for P4 (notice that does NOT mean "will run only on the P4"
There are still lots of PIIIs in use, especially Xeons. Hardware doesn't get obsolete that fast.