3:23 p.m.
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?
--
Jean Francois Martinez <jfm512(a)free.fr>
3:35 p.m.
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?
--
mark@mielke.cc/markm@ncf.ca/markm(a)nortelnetworks.com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...
http://mark.mielke.cc/
5:43 p.m.
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?
--
Jean Francois Martinez <jfm512(a)free.fr>
7:26 p.m.
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.
--
========================================================================
Ian Pilcher i.pilcher(a)comcast.net
========================================================================
4:48 p.m.
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
2:47 p.m.
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.
--
Florin Andrei
http://florin.myip.org/
5:54 p.m.
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
5:43 p.m.
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(a)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. :-)
--
Jean Francois Martinez <jfm512(a)free.fr>
5:25 p.m.
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.
3:50 p.m.
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(a)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
7570
days inactive
7571
days old
9 comments
7 participants
participants (7)
-
Alan Cox -
Felipe Alfaro Solana -
Florin Andrei -
Ian Pilcher -
Jakub Jelinek -
Jean Francois Martinez -
Mark Mielke