Given the loud feedback, I've updated the proposal at: https://fedoraproject.org/wiki/Features/F12X86Support
The revised proposal:
- Build all packages for i686 (this requires cmov) - Optimize for Atom
Why?
- We don't really support i586 in any meaningful matter - OLPC still works with base i686 - We are likely doing a mass rebuild for F-12 anyways, might as well switch while we're doing it - Atom is the only currently produced 32-bit x86 chip of note; optimize for what's currently available
If you want numbers, I did some benchmarking of code [1] with various build options on a variety of processors, with the F-11 gcc code. All of these results are relative to a F-11 baseline of "-march=i586 -mtune=generic".
P4 2.4Ghz Athlon 3400+ Core2Duo E6850 Atom N270 march=i686/ -1.1% +2.0% +0.9% +0.6% mtune=generic march=i586/ +0.3% -0.3% -0.2% +1.3% mtune=atom march=i686/ -1.5% +1.2% +0.5% +1.7% mtune=atom
Bill
[1] gzip, bzip2, math simulation, mp3 encode/decode, ogg encode/decode
On Wed, Jun 17, 2009 at 1:52 PM, Bill Nottinghamnotting@redhat.com wrote:
Given the loud feedback, I've updated the proposal at: https://fedoraproject.org/wiki/Features/F12X86Support
The revised proposal:
- Build all packages for i686 (this requires cmov)
- Optimize for Atom
Why?
- We don't really support i586 in any meaningful matter
- OLPC still works with base i686
- We are likely doing a mass rebuild for F-12 anyways, might as well switch
while we're doing it
- Atom is the only currently produced 32-bit x86 chip of note; optimize
for what's currently available
If you want numbers, I did some benchmarking of code [1] with various build options on a variety of processors, with the F-11 gcc code. All of these results are relative to a F-11 baseline of "-march=i586 -mtune=generic".
P4 2.4Ghz Athlon 3400+ Core2Duo E6850 Atom N270 march=i686/ -1.1% +2.0% +0.9% +0.6% mtune=generic march=i586/ +0.3% -0.3% -0.2% +1.3% mtune=atom march=i686/ -1.5% +1.2% +0.5% +1.7% mtune=atom
If there is a mass rebuild…
Consider:
-Os on the x86 build? -O3 on x86_64?
(Back in 2007 I would have screamed loudly that the auto-vectorizer produces broken code; but today it appears to work fine.)
On Wed, Jun 17, 2009 at 02:41:54PM -0400, Bill Nottingham wrote:
Gregory Maxwell (gmaxwell@gmail.com) said:
Consider:
-Os on the x86 build?
Back when I tested before, -Os unilaterally made things worse across Athlon64/C2D/Atom.
Note that GCC 4.4 switches -Os on for unlikely executed basic blocks and/or unlikely executed functions (of course profile feedback helps here a lot, but even without it the heuristics gets it right in many cases), so forcing -Os for all code, even hot, is not a good idea. On the other side, compiling everything with -O3 is going to bloat code a lot, just compile with -O3 the hot compilation units or even better just hot functions.
Jakub
On Wed, Jun 17, 2009 at 8:46 PM, Jakub Jelinekjakub@redhat.com wrote:
On Wed, Jun 17, 2009 at 02:41:54PM -0400, Bill Nottingham wrote:
Gregory Maxwell (gmaxwell@gmail.com) said:
Consider:
-Os on the x86 build?
Back when I tested before, -Os unilaterally made things worse across Athlon64/C2D/Atom.
Note that GCC 4.4 switches -Os on for unlikely executed basic blocks and/or unlikely executed functions (of course profile feedback helps here a lot, but even without it the heuristics gets it right in many cases), so forcing -Os for all code, even hot, is not a good idea. On the other side, compiling everything with -O3 is going to bloat code a lot, just compile with -O3 the hot compilation units or even better just hot functions.
Is this (bloated code) really a problem if the code runs faster?
Once upon a time, drago01 drago01@gmail.com said:
Is this (bloated code) really a problem if the code runs faster?
Bloated code: == more disk space (not too critical except for LiveCD type setup) == more RAM usage (most have lots of RAM so not too bad) == more cache misses (slows down code because of waiting on RAM)
On Wed, Jun 17, 2009 at 08:56:58PM +0200, drago01 wrote:
Note that GCC 4.4 switches -Os on for unlikely executed basic blocks and/or unlikely executed functions (of course profile feedback helps here a lot, but even without it the heuristics gets it right in many cases), so forcing -Os for all code, even hot, is not a good idea. On the other side, compiling everything with -O3 is going to bloat code a lot, just compile with -O3 the hot compilation units or even better just hot functions.
Is this (bloated code) really a problem if the code runs faster?
Of course it is. You trash caches by rarely used functions. You don't want to optimize rarely used code at the expense of code size, only the often used.
Jakub
On Wed, Jun 17, 2009 at 9:01 PM, Jakub Jelinekjakub@redhat.com wrote:
On Wed, Jun 17, 2009 at 08:56:58PM +0200, drago01 wrote:
Note that GCC 4.4 switches -Os on for unlikely executed basic blocks and/or unlikely executed functions (of course profile feedback helps here a lot, but even without it the heuristics gets it right in many cases), so forcing -Os for all code, even hot, is not a good idea. On the other side, compiling everything with -O3 is going to bloat code a lot, just compile with -O3 the hot compilation units or even better just hot functions.
Is this (bloated code) really a problem if the code runs faster?
Of course it is. You trash caches by rarely used functions. You don't want to optimize rarely used code at the expense of code size, only the often used.
OK, fair enough.
On 06/17/2009 07:52 PM, Bill Nottingham wrote:
Given the loud feedback, I've updated the proposal at: https://fedoraproject.org/wiki/Features/F12X86Support
The revised proposal:
- Build all packages for i686 (this requires cmov)
- Optimize for Atom
Why?
- We don't really support i586 in any meaningful matter
- OLPC still works with base i686
- We are likely doing a mass rebuild for F-12 anyways, might as well switch while we're doing it
- Atom is the only currently produced 32-bit x86 chip of note; optimize for what's currently available
If you want numbers, I did some benchmarking of code [1] with various build options on a variety of processors, with the F-11 gcc code. All of these results are relative to a F-11 baseline of "-march=i586 -mtune=generic".
P4 2.4Ghz Athlon 3400+ Core2Duo E6850 Atom N270
march=i686/ -1.1% +2.0% +0.9% +0.6% mtune=generic march=i586/ +0.3% -0.3% -0.2% +1.3% mtune=atom march=i686/ -1.5% +1.2% +0.5% +1.7% mtune=atom
Bill
[1] gzip, bzip2, math simulation, mp3 encode/decode, ogg encode/decode
This sounds a perfectly fine and sensible solution to me, thanks for taking the feedback into account :)
Steven
Once upon a time, Bill Nottingham notting@redhat.com said:
Why?
- We don't really support i586 in any meaningful matter
What does this mean? Does Fedora not run on i586? Why was there a mass-rebuild for i586 if it doesn't work?
- We are likely doing a mass rebuild for F-12 anyways, might as well switch while we're doing it
That's a pretty poor justification.
- Atom is the only currently produced 32-bit x86 chip of note; optimize for what's currently available
There are also lots of other chips that people run 32 bit x86 code on. I don't think Atom is a majority percentage of 32 bix x86 Fedora users either.
If you want numbers, I did some benchmarking of code [1] with various build options on a variety of processors, with the F-11 gcc code. All of these results are relative to a F-11 baseline of "-march=i586 -mtune=generic".
P4 2.4Ghz Athlon 3400+ Core2Duo E6850 Atom N270
march=i686/ -1.1% +2.0% +0.9% +0.6% mtune=generic march=i586/ +0.3% -0.3% -0.2% +1.3% mtune=atom march=i686/ -1.5% +1.2% +0.5% +1.7% mtune=atom
Bill
[1] gzip, bzip2, math simulation, mp3 encode/decode, ogg encode/decode
Okay, before I thought you said this was a "1-2% improvement across the board", but now it is a 1% improvement on some CPU-intensive operations on some CPUs (and a 1% performance hit on other CPUs).
How does this affect multilib on x86_64?
The justification for the i586 rebuild was that there hasn't been a Fedora i386 kernel for years (so i586 was already required anyway). This is the first time Fedora is proposing to throw out CPU support in a long long time, and I find a minimal improvement on some targeted benchmarks a poor justification.
It would seem to me that adding a few targeted Atom packages would be a better use of resources (e.g. similar to openssl.i686).
Chris Adams (cmadams@hiwaay.net) said:
- We don't really support i586 in any meaningful matter
What does this mean? Does Fedora not run on i586? Why was there a mass-rebuild for i586 if it doesn't work?
I know of *no one* in the community who tests on i586 to ensure that it works. (If this drags them out of silence, so be it!) It is certainly not part of the QA matrix for testing RCs. On the kernel side, I doubt the kernel team even has hardware around that they could test fixes on.
On the userspace side, we don't do a lot, if any, of optimization (or testing) of yum or the installer for working in small memory environments. I believe the minimum memory actually used for any of the qualification tests in the installer for F11 was 512MB.
At a certain level, I suspect many, if not all, bugs of a "Fedora does not install/takes three days to do anything/does not run well" on a i586-class box are going to be CLOSED/WONTFIX-UNLESS-YOU-ARE-SENDING-A-PATCH, at best.
*That's* what I mean by "we don't really support i586 in any meaningful manner". As for why it was done that way in F-11, paranoia mostly (about the XO not being fully vetted, among other things.)
- We are likely doing a mass rebuild for F-12 anyways, might as well switch while we're doing it
That's a pretty poor justification.
The common complaint leveled about doing it was "why go to the extra effort". If we're doing a mass rebuild, it's essentailly zero extra effort.
- Atom is the only currently produced 32-bit x86 chip of note; optimize for what's currently available
There are also lots of other chips that people run 32 bit x86 code on. I don't think Atom is a majority percentage of 32 bix x86 Fedora users either.
See the Fedora Foundations [1] and Objectives [2] page. If we're truly about being on the leading edge, being innovative, etc., the main target of Fedora should be current hardware, even if older hardware is still supported. The only *current* 32-bit x86 hardware is Atom. (And Nano, I suppose.)
If you want numbers, I did some benchmarking of code [1] with various build options on a variety of processors, with the F-11 gcc code. All of these results are relative to a F-11 baseline of "-march=i586 -mtune=generic".
P4 2.4Ghz Athlon 3400+ Core2Duo E6850 Atom N270
march=i686/ -1.1% +2.0% +0.9% +0.6% mtune=generic march=i586/ +0.3% -0.3% -0.2% +1.3% mtune=atom march=i686/ -1.5% +1.2% +0.5% +1.7% mtune=atom
Bill
[1] gzip, bzip2, math simulation, mp3 encode/decode, ogg encode/decode
Okay, before I thought you said this was a "1-2% improvement across the board", but now it is a 1% improvement on some CPU-intensive operations on some CPUs (and a 1% performance hit on other CPUs).
Well, if you're using a P4, you may have already lost, as it's not really a good CPU for optimization, period. The fact that -march=i686 is a lose on P4 makes it unique among everything I have access to, and the thing that really dragged the benchmark down on P4 was software we don't even ship (MP3 decode).
How does this affect multilib on x86_64?
It doesn't.
Bill
[1] http://fedoraproject.org/wiki/Foundations [2] http://fedoraproject.org/wiki/Objectives
Once upon a time, Bill Nottingham notting@redhat.com said:
Chris Adams (cmadams@hiwaay.net) said:
How does this affect multilib on x86_64?
It doesn't.
What I meant was what was the impact on running 32 bit binaries on the 64 bit OS (e.g. run your benchmarks there as well).
Chris Adams (cmadams@hiwaay.net) said:
How does this affect multilib on x86_64?
It doesn't.
What I meant was what was the impact on running 32 bit binaries on the 64 bit OS (e.g. run your benchmarks there as well).
Unless I've completely missed something (always a possiblity), 32-bit code runs *exactly* the same when the CPU is in 64-bit mode. In the benchmarks posted, the Athlon64 (and possibly the P4; I'd have to check later) was actually running in 64-bit mode at the time, even though the binaries were 32-bit.
Bill
Bill Nottingham wrote:
Chris Adams (cmadams@hiwaay.net) said:
- We don't really support i586 in any meaningful matter
What does this mean? Does Fedora not run on i586? Why was there a mass-rebuild for i586 if it doesn't work?
I know of *no one* in the community who tests on i586 to ensure that it works.
Well, I used to do, ... but you are right insofar, as that Fedora has grown too fat and bloated to be of much actual use on i586's, anymore.
At a certain level, I suspect many, if not all, bugs of a "Fedora does not install/takes three days to do anything/does not run well" on a i586-class box are going to be CLOSED/WONTFIX-UNLESS-YOU-ARE-SENDING-A-PATCH, at best.
That's not the point of keeping i586's around
On the user side, it's primarily "reusing recycled HW" without having to quit the distro you are using elsewhere.
On the developers' side it's "using i586s as testing platforms" to e.g. detect pieces of code which lack generality/suffer from portability issues and inefficiency.
(Now combine this with my remark on "Fedora is fat" ... )
*That's* what I mean by "we don't really support i586 in any meaningful manner".
You seem to be speaking in terms of "You == RH".
Ralf
Ralf Corsepius (rc040203@freenet.de) said:
*That's* what I mean by "we don't really support i586 in any meaningful manner".
You seem to be speaking in terms of "You == RH".
No, period - I haven't seen anyone in the community say that they're testing it on i586-class hardware.
Bill
Bill Nottingham wrote:
Ralf Corsepius (rc040203@freenet.de) said:
*That's* what I mean by "we don't really support i586 in any meaningful manner".
You seem to be speaking in terms of "You == RH".
No, period - I haven't seen anyone in the community say that they're testing it on i586-class hardware.
Then you likely haven't paid attention.
I repeatedly filed BZ'd i586 specific issues and mentioned i586 issues on several fedora lists (e.g. SELinux causing kernel OOMs on i586's).
Ralf
On 19/06/09 00:19, Bill Nottingham wrote:
No, period - I haven't seen anyone in the community say that they're testing it on i586-class hardware.
Hi Bill,
Your wiki page has some jargon ("i586") which I'm trying to reduce to manufacturer products, as you have already done for the AMD products.
F12 x86 will not work on i586 (or i686 without CMOV) ---------------------------------------------------- Intel Pentium Intel Pentium Pro
VIA Cyrix III VIA C3 and C3-M ("Samuel 2") VIA C3 and C3-M ("Ezra") VIA C3 and C3-M ("Ezra-T") VIA Eden ESP ("Samuel 2")
Note that the VIA Eden ESP ("Samuel 2") appears to be a shipping product [based on vendor's website, not personal experience], and that this will not run Fedora 12 under the current proposal. It ships in the VIA EPIA MII/ML/PE motherboards with CPUs rated at 667MHz (all other clock speeds will run F12). Probably worth a mention in the F12 Release Notes.
F12 x86 will work on these 32b processors -----------------------------------------
Intel Pentium II Intel Celeron (any) Intel Pentium III Intel Pentium 4 Intel Pentium M
VIA C3 and C3-D ("Nehemiah") VIA Eden ESP ("Nehemiah") VIA Eden-N VIA Eden ("Esther") VIA C7 and C7-M and C7-D ("Esther") VIA Nano
Any Intel x86-64, AMD64 or compatible
Although this is the best I could do, the VIA situation is complex and errors in the above would not shock me.
Cheers, Glen
On Sun, Jun 21, 2009 at 11:24:35PM +0930, Glen Turner wrote:
F12 x86 will not work on i586 (or i686 without CMOV)
Intel Pentium Intel Pentium Pro
VIA Cyrix III VIA C3 and C3-M ("Samuel 2") VIA C3 and C3-M ("Ezra") VIA C3 and C3-M ("Ezra-T") VIA Eden ESP ("Samuel 2")
.. Although this is the best I could do, the VIA situation is complex and errors in the above would not shock me.
The original "Samuel" won't work either. Other than this omission, your table looks correct to me.
There's also the AMD K5, K6, K6-2, K6-3 that won't work. And all the older Cyrix 6x86/MX/MII/MediaGX CPUs. (Though those things sucked even in 1990's, and I doubt they've improved with age)
Dave
On Sun, Jun 21, 2009 at 3:54 PM, Glen Turnergdt@gdt.id.au wrote:
On 19/06/09 00:19, Bill Nottingham wrote:
No, period - I haven't seen anyone in the community say that they're testing it on i586-class hardware.
Hi Bill,
Your wiki page has some jargon ("i586") which I'm trying to reduce to manufacturer products, as you have already done for the AMD products.
F12 x86 will not work on i586 (or i686 without CMOV)
Intel Pentium Intel Pentium Pro
VIA Cyrix III VIA C3 and C3-M ("Samuel 2") VIA C3 and C3-M ("Ezra") VIA C3 and C3-M ("Ezra-T") VIA Eden ESP ("Samuel 2")
Note that the VIA Eden ESP ("Samuel 2") appears to be a shipping product [based on vendor's website, not personal experience], and that this will not run Fedora 12 under the current proposal. It ships in the VIA EPIA MII/ML/PE motherboards with CPUs rated at 667MHz (all other clock speeds will run F12). Probably worth a mention in the F12 Release Notes.
F12 x86 will work on these 32b processors
Intel Pentium II Intel Celeron (any) Intel Pentium III Intel Pentium 4 Intel Pentium M
VIA C3 and C3-D ("Nehemiah") VIA Eden ESP ("Nehemiah") VIA Eden-N VIA Eden ("Esther") VIA C7 and C7-M and C7-D ("Esther") VIA Nano
Any Intel x86-64, AMD64 or compatible
+ AMD K7
Glen Turner (gdt@gdt.id.au) said:
On 19/06/09 00:19, Bill Nottingham wrote:
No, period - I haven't seen anyone in the community say that they're testing it on i586-class hardware.
Hi Bill,
Your wiki page has some jargon ("i586") which I'm trying to reduce to manufacturer products, as you have already done for the AMD products.
F12 x86 will not work on i586 (or i686 without CMOV)
Intel Pentium Intel Pentium Pro
PPro has cmov, AFAIK.
Bill
No, period - I haven't seen anyone in the community say that they're testing it on i586-class hardware.
Hi Bill,
Your wiki page has some jargon ("i586") which I'm trying to reduce to manufacturer products, as you have already done for the AMD products.
F12 x86 will not work on i586 (or i686 without CMOV)
Intel Pentium Intel Pentium Pro
PPro has cmov, AFAIK.
Yes, its i686.
Peter
On 06/17/2009 08:10 PM, Bill Nottingham wrote:
See the Fedora Foundations [1] and Objectives [2] page. If we're truly about being on the leading edge, being innovative, etc., the main target of Fedora should be current hardware, even if older hardware is still supported. The only *current* 32-bit x86 hardware is Atom. (And Nano, I suppose.)
I agree with your analysis leading to the "we don't really support i586 in any meaningful manner" statement but not this one. Being innovative in software and operating system design may be meaningful despite running on old hardware or even precisely because it runs on old hardware.
-Toshio
On 06/17/2009 11:10 PM, Bill Nottingham wrote:
- We are likely doing a mass rebuild for F-12 anyways, might as well switch while we're doing it
That's a pretty poor justification.
The common complaint leveled about doing it was "why go to the extra effort". If we're doing a mass rebuild, it's essentailly zero extra effort.
"extra effort" referred to a secondary arch probably more so than mass rebuild.
- Atom is the only currently produced 32-bit x86 chip of note; optimize for what's currently available
There are also lots of other chips that people run 32 bit x86 code on. I don't think Atom is a majority percentage of 32 bix x86 Fedora users either.
See the Fedora Foundations [1] and Objectives [2] page. If we're truly about being on the leading edge, being innovative, etc., the main target of Fedora should be current hardware, even if older hardware is still supported. The only *current* 32-bit x86 hardware is Atom. (And Nano, I suppose.)
Nano is 64bit with virt.
BTW, anyone tested these yet with Fedora?
Warren Togami wtogami@redhat.com
- We don't really support i586 in any meaningful matter
What does this mean? Does Fedora not run on i586? Why was there a mass-rebuild for i586 if it doesn't work?
I know of *no one* in the community who tests on i586 to ensure that it works. (If this drags them out of silence, so be it!) It is certainly not part of the QA matrix for testing RCs. On the kernel side, I doubt the kernel team even has hardware around that they could test fixes on.
Well geode is technically i586 even though it has cmov. I use two of them on a pretty regular basis. There are quite a few of the community who have XOs as part of the testing program that handed them out in the F10 devel period and I know a number of RedHat engineers have them as well so there is a least some hardware around for testing.
Peter
Peter Robinson (pbrobinson@gmail.com) said:
I know of *no one* in the community who tests on i586 to ensure that it works. (If this drags them out of silence, so be it!) It is certainly not part of the QA matrix for testing RCs. On the kernel side, I doubt the kernel team even has hardware around that they could test fixes on.
Well geode is technically i586 even though it has cmov. I use two of them on a pretty regular basis. There are quite a few of the community who have XOs as part of the testing program that handed them out in the F10 devel period and I know a number of RedHat engineers have them as well so there is a least some hardware around for testing.
Geode (at least the variant in the XO, and later models) isn't intended to be dropped here. There are earlier Geodes (the original version was 486-ish) that wouldn't be supported.
Bill
On Thu, Jun 18, 2009 at 4:48 PM, Bill Nottinghamnotting@redhat.com wrote:
Peter Robinson (pbrobinson@gmail.com) said:
I know of *no one* in the community who tests on i586 to ensure that it works. (If this drags them out of silence, so be it!) It is certainly not part of the QA matrix for testing RCs. On the kernel side, I doubt the kernel team even has hardware around that they could test fixes on.
Well geode is technically i586 even though it has cmov. I use two of them on a pretty regular basis. There are quite a few of the community who have XOs as part of the testing program that handed them out in the F10 devel period and I know a number of RedHat engineers have them as well so there is a least some hardware around for testing.
Geode (at least the variant in the XO, and later models) isn't intended to be dropped here. There are earlier Geodes (the original version was 486-ish) that wouldn't be supported.
I don't know how much of a 686 the Geode ("586+cmov") we use is, in the sense that I hope people (Chris, Deepak) have looked at this and ensured there are no other dragons lurking.
To note: it _is_ reported as a 586, so at least ancillary work in yum/anaconda/rpm will be needed so that installing F12 on these "supported but not quite 686 CPUs" is possible, avoiding the hackery of installing it on a true 686 and then transferring the image to the XO.
Do we have a good and reliable way to spot the properly supported CPUs?
cheers,
m
Martin Langhoff (martin.langhoff@gmail.com) said:
To note: it _is_ reported as a 586, so at least ancillary work in yum/anaconda/rpm will be needed so that installing F12 on these "supported but not quite 686 CPUs" is possible, avoiding the hackery of installing it on a true 686 and then transferring the image to the XO.
diff --git a/rpmrc.in b/rpmrc.in index 4a6cca9..d62ddaf 100644 --- a/rpmrc.in +++ b/rpmrc.in @@ -281,7 +281,7 @@ arch_compat: alphaev5: alpha arch_compat: alpha: axp noarch
arch_compat: athlon: i686 -arch_compat: geode: i586 +arch_compat: geode: i686 arch_compat: pentium4: pentium3 arch_compat: pentium3: i686 arch_compat: i686: i586
That should do the trick. :)
Bill
On Thu, Jun 18, 2009 at 5:22 PM, Bill Nottinghamnotting@redhat.com wrote:
+arch_compat: geode: i686
...
That should do the trick. :)
Cool. Didn't know we had that compat mechanism available.
Back to my humid cave then...
m
On Thu, Jun 18, 2009 at 4:22 PM, Bill Nottinghamnotting@redhat.com wrote:
Martin Langhoff (martin.langhoff@gmail.com) said:
To note: it _is_ reported as a 586, so at least ancillary work in yum/anaconda/rpm will be needed so that installing F12 on these "supported but not quite 686 CPUs" is possible, avoiding the hackery of installing it on a true 686 and then transferring the image to the XO.
diff --git a/rpmrc.in b/rpmrc.in index 4a6cca9..d62ddaf 100644 --- a/rpmrc.in +++ b/rpmrc.in @@ -281,7 +281,7 @@ arch_compat: alphaev5: alpha arch_compat: alpha: axp noarch
arch_compat: athlon: i686 -arch_compat: geode: i586 +arch_compat: geode: i686 arch_compat: pentium4: pentium3 arch_compat: pentium3: i686 arch_compat: i686: i586
That should do the trick. :)
I've just been testing this with my Fit-PC geode box and it hasn't made it into rawhide and hence doesn't work. I've filed a bug [1] and added it to the alpha blocker as its a pretty large miss for the x86 recompile feature.
Peter
Den 2009-06-18 05:10, Bill Nottingham skrev:
See the Fedora Foundations [1] and Objectives [2] page. If we're truly about being on the leading edge, being innovative, etc., the main target of Fedora should be current hardware, even if older hardware is still supported.
Yeah, but frankly, there's a difference between producing cutting edge software and requiring newer hardware... Sometimes they go hand in hand.
Though I guess updating the compiler flags means using other/newer/better code in the compiler, which is a form of software improvement.
/abo
On Wed, Jun 17, 2009 at 7:52 PM, Bill Nottinghamnotting@redhat.com wrote:
Given the loud feedback, I've updated the proposal at: https://fedoraproject.org/wiki/Features/F12X86Support
The revised proposal:
- Build all packages for i686 (this requires cmov)
- Optimize for Atom
Sounds much better than your last proposal.
On Wed, Jun 17, 2009 at 9:52 AM, Bill Nottinghamnotting@redhat.com wrote:
- Atom is the only currently produced 32-bit x86 chip of note; optimize
for what's currently available
Just as an aside, can we do anything to help people identify whether their hardware is 64bit capable?
I'm thinking specifically with people with "Centrino" stickered laptops of unclear vintage who may not realize that they have a 64bit capable machine even when they do. The Centrino branding doesn't exactly make it obvious as Intel pushed 64bit capability into the brand at some point (2006 ?).
How many people are running 32bit Fedora on 64bit capable hardware without realizing its 64bit capable laptop hardware?
-jef
On Wed, Jun 17, 2009 at 3:17 PM, Jeff Spaletajspaleta@gmail.com wrote:
Just as an aside, can we do anything to help people identify whether their hardware is 64bit capable?
grep lm /proc/cpuinfo
Fedora doesn't even indicate what video card that they're using why should it provide a way to discover the 64bit capability.
I'm thinking specifically with people with "Centrino" stickered laptops of unclear vintage who may not realize that they have a 64bit capable machine even when they do. The Centrino branding doesn't exactly make it obvious as Intel pushed 64bit capability into the brand at some point (2006 ?).
How many people are running 32bit Fedora on 64bit capable hardware without realizing its 64bit capable laptop hardware?
I think that those that care probably know and are running x86_64. If they're like me, they stick the x86_64 cd into their wife's computer and discover that it's got one of older processors when it gives the error message.
Trying to berate people into using x86_64 as I've seen in this and other threads has gotten annoying. People that run i386 on x86_64 capable hardware usually have a reason. On my work laptop, I run i386 simply because it makes my life easier. I have to work with proprietary software that is mostly 32bit. I don't want to deal with having to make sure that I've got the various 32bit libraries installed.
On Wed, Jun 17, 2009 at 2:28 PM, James Hubbardjameshubbard@gmail.com wrote:
grep lm /proc/cpuinfo
Specifically what information can you rely on in that info will be a reliably indication that your particular Centrino branded cpu is 64bit capable? is there a particular flag that marks it as 64bit capable or do you have to know something about the specific cpuid?
Trying to berate people into using x86_64 as I've seen in this and other threads has gotten annoying.
Berate? I'm not trying to berate anyone. What I am trying to do is get a handle on how to potentially mitigate as much as possible avoidable impact associated with an architecture policy change if and when it happens. If running 32bit Fedora on 64bit hardware is widespread, any substantial change in policy with regard to 32bit maybe more disruptive than we originally realize. Hmm, I wonder does smolt give any relevant info as to my question. Can smolt tell give me an indication of the percentage of 64bit capable systems which are running 32bit Fedora? Hmm.
-jef
Once upon a time, Jeff Spaleta jspaleta@gmail.com said:
On Wed, Jun 17, 2009 at 2:28 PM, James Hubbardjameshubbard@gmail.com wrote:
grep lm /proc/cpuinfo
Specifically what information can you rely on in that info will be a reliably indication that your particular Centrino branded cpu is 64bit capable? is there a particular flag that marks it as 64bit capable or do you have to know something about the specific cpuid?
"lm" is the flag; if it is there, your CPU supports "long mode" aka 64 bit mode.
I guess you could be more specific (in case somebody made a flag or another cpuinfo line with "lm" in it) with a:
grep '^<flags>.*<lm>' /proc/cpuinfo
On Wed, 2009-06-17 at 14:58 -0800, Jeff Spaleta wrote:
Can smolt tell give me an indication of the percentage of 64bit capable systems which are running 32bit Fedora? Hmm.
Question is, how reliable would smolt be, if you don't know how many more are *not* reporting to smolt anyway, via not on internet but on just a local network?
On Wed, 17 Jun 2009, Mike Chambers wrote:
On Wed, 2009-06-17 at 14:58 -0800, Jeff Spaleta wrote:
Can smolt tell give me an indication of the percentage of 64bit capable systems which are running 32bit Fedora? Hmm.
Question is, how reliable would smolt be, if you don't know how many more are *not* reporting to smolt anyway, via not on internet but on just a local network?
The only verification we've done to see how accurate the smolt stats are is to compare the i386 vs x86_64 in smolt to the mirror list requests, and they are consistently within a couple of percentage points of each other.
-Mike
Mike McGrath (mmcgrath@redhat.com) said:
Can smolt tell give me an indication of the percentage of 64bit capable systems which are running 32bit Fedora? Hmm.
Question is, how reliable would smolt be, if you don't know how many more are *not* reporting to smolt anyway, via not on internet but on just a local network?
The only verification we've done to see how accurate the smolt stats are is to compare the i386 vs x86_64 in smolt to the mirror list requests, and they are consistently within a couple of percentage points of each other.
That doesn't help with "I have a 32-bit install on my 64-bit box", of course.
Bill
On Wed, Jun 17, 2009 at 3:55 PM, Mike Chambersmike@miketc.net wrote:
Question is, how reliable would smolt be, if you don't know how many more are *not* reporting to smolt anyway, via not on internet but on just a local network?
I'll take it with a grain of salt...but I've no a priori reason to think that the number of 32bit installs on 64bit hardware would be unrepresentative....if we exclude virtualized installs completely. I'm not trying to compare the existence of 32bit to 64bit hardware.... just 32bit OS installs on 64bit hardware as a subset of all registered 64bit hardware. Just looking at 64bit hardware doesn't have the same sort of legacy or geographic distribution caveats that 32bit does with regard to re-purposed equipment. 64bit stuff just hasn't been around long enough.
If 32bit installs on 64bit hardware is a tiny percentage of the registered smolt installs i doubt seriously its going to a majority situation for 64bit hardware in the wild. If its 20% or more as a function registered 64bit hardware..its a big enough population to try to account for in how we communicate a change in policy with regard to 32bit. I'm not suggesting that policy decision be based on this numbers..I'm saying that how we communicate a change in policy should have these numbers in mind when generating Release specific talking points for the release where the change impacts potential install scenarios..
-jef
On Wed, Jun 17, 2009 at 6:58 PM, Jeff Spaletajspaleta@gmail.com wrote:
On Wed, Jun 17, 2009 at 2:28 PM, James Hubbardjameshubbard@gmail.com wrote:
Trying to berate people into using x86_64 as I've seen in this and other threads has gotten annoying.
Berate? I'm not trying to berate anyone. What I am trying to do is get a handle on how to potentially mitigate as much as possible avoidable impact associated with an architecture policy change if and when it happens. If running 32bit Fedora on 64bit hardware is widespread, any substantial change in policy with regard to 32bit maybe more disruptive than we originally realize. Hmm, I wonder does smolt give any relevant info as to my question. Can smolt tell give me an indication of the percentage of 64bit capable systems which are running 32bit Fedora? Hmm.
Sorry, I'm not saying you specifically. There have a been a far number of messages in which tone has seemed to be that you have to use x86_64 if you have hardware.
My apologies.
On Thu, Jun 18, 2009 at 2:31 PM, James Hubbardjameshubbard@gmail.com wrote:
On Wed, Jun 17, 2009 at 6:58 PM, Jeff Spaletajspaleta@gmail.com wrote:
On Wed, Jun 17, 2009 at 2:28 PM, James Hubbardjameshubbard@gmail.com wrote:
Trying to berate people into using x86_64 as I've seen in this and other threads has gotten annoying.
Berate? I'm not trying to berate anyone. What I am trying to do is get a handle on how to potentially mitigate as much as possible avoidable impact associated with an architecture policy change if and when it happens. If running 32bit Fedora on 64bit hardware is widespread, any substantial change in policy with regard to 32bit maybe more disruptive than we originally realize. Hmm, I wonder does smolt give any relevant info as to my question. Can smolt tell give me an indication of the percentage of 64bit capable systems which are running 32bit Fedora? Hmm.
Sorry, I'm not saying you specifically. There have a been a far number of messages in which tone has seemed to be that you have to use x86_64 if you have hardware.
My apologies.
s/have to/should/
Unless you have a specific reason not do so.
Jeff Spaleta wrote:
Just as an aside, can we do anything to help people identify whether their hardware is 64bit capable?
Well, we need to start by actually telling people a 64-bit version exists in the first place! The crappy download page needs to be fixed! We should go back to something like get-fedora-all, the current get-fedora is a disaster.
Kevin Kofler
On Wed, Jun 17, 2009 at 4:55 PM, Kevin Koflerkevin.kofler@chello.at wrote:
Jeff Spaleta wrote: Well, we need to start by actually telling people a 64-bit version exists in the first place! The crappy download page needs to be fixed! We should go back to something like get-fedora-all, the current get-fedora is a disaster.
Its all a matter of how you look at it. If it turns out that a lot of 64bit hardware owners are running 32bit Fedora 11, then we can probably assume the function of such a page is a high impact tool acting as a guide a significant portion of our userbase towards install media. If that's so then it probably deserves a lot of attention and scrutiny for first impression impact.
If on the other hand people with 64bit systems are predominately installing the 64bit version, even though its not exposed on that page then we can probably say that our current userbase demographics are very technically saavy, and that the details of the contents of that sort of on-ramp page doesn't particularly matter to them.
-jef"A firm believer that all great culinary inventions were in fact thought to be cooking disasters at first glance... until someone dared a 12 year old boy to eat it. Half the time the kid would die, 10% of the time it was actually tasty."spaleta
On 18/06/09 11:03, Jeff Spaleta wrote:
Its all a matter of how you look at it. If it turns out that a lot of 64bit hardware owners are running 32bit Fedora 11...
It would be useful if anaconda displayed a info box telling people when they were considering installing 32b Linux on systems with 32/64b CPUs and more than about 800MB of RAM. [1]
In disk and networking the win from 64b is considerable due to much reduced low memory fragmentation and in general there's a lot less stuffing about with DMA. It is well worthwhile for people to install 64b Linux when that is reasonable, but as this thread has pointed out determining 64b capabilities prior to installation is a big ask of people unfamiliar with the intricacies of their CPU vendor's products.
Thus the requirement to let installers of 32b Linux know when a better choice is available (but of course, not to insist upon that better choice -- the info box should only be informational).
[1] More technically, when /proc/meminfo's LowTotal < MemTotal.
On Sat, Jun 20, 2009 at 11:01 PM, Glen Turner gdt@gdt.id.au wrote:
On 18/06/09 11:03, Jeff Spaleta wrote:
Its all a matter of how you look at it. If it turns out that a lot of
64bit hardware owners are running 32bit Fedora 11...
It would be useful if anaconda displayed a info box telling people when they were considering installing 32b Linux on systems with 32/64b CPUs and more than about 800MB of RAM. [1]
In disk and networking the win from 64b is considerable due to much reduced low memory fragmentation and in general there's a lot less stuffing about with DMA. It is well worthwhile for people to install 64b Linux when that is reasonable, but as this thread has pointed out determining 64b capabilities prior to installation is a big ask of people unfamiliar with the intricacies of their CPU vendor's products.
Thus the requirement to let installers of 32b Linux know when a better choice is available (but of course, not to insist upon that better choice -- the info box should only be informational).
[1] More technically, when /proc/meminfo's LowTotal < MemTotal.
-- Glen Turner
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
I really don't see a great value in changing the arch yet again, this time to i686. The logic for switching to i586 was sound, and we didn't really lose any people using Fedora on both new and old hardware.
However, I do like the idea of an infobox that would show up if 32-bit Fedora is being installed on a 64-bit capable machine with sufficient RAM available.
On 06/17/2009 12:17 PM, Jeff Spaleta wrote:
On Wed, Jun 17, 2009 at 9:52 AM, Bill Nottinghamnotting@redhat.com wrote:
I'm thinking specifically with people with "Centrino" stickered laptops of unclear vintage who may not realize that they have a 64bit capable machine even when they do. The Centrino branding doesn't exactly make it obvious as Intel pushed 64bit capability into the brand at some point (2006 ?).
I am one of users with "Centrino" stickered notebook. It does not support x86_64 being a 2005 model.
cat /proc/cpuinfo
processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 13 model name : Intel(R) Pentium(R) M processor 1.50GHz stepping : 6 cpu MHz : 600.000 cache size : 2048 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr mce cx8 mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe up bts est tm2 bogomips : 1196.26 clflush size : 64 power management:
Luya
On 06/17/09 21:17, Jeff Spaleta wrote:
On Wed, Jun 17, 2009 at 9:52 AM, Bill Nottinghamnotting@redhat.com wrote:
- Atom is the only currently produced 32-bit x86 chip of note; optimize for what's currently available
Just as an aside, can we do anything to help people identify whether their hardware is 64bit capable?
Not sure it is still that way, but at least a while back suse had such a check in the install iso boot loader, poping up a window saying somehing along the lines "cool (64bit) computer, do you really want to cripple it with 32bit software?". That was the box with a two-sided dvd though (one side 32 other 64bit). In *that* case it makes alot of sense, you just have to flip the dvd and it also avoids installing 32bit by accident.
For fedora you probably want to know *before* downloading stuff ...
Idea #1: Can preupgrade handle a i386->x86_64 switch? If so a check could be added and offer going from F10/32bit to F11/64bit.
Idea #2: netinst iso for both 32 and 64bit, then have the bootloader check cpuid and offer either 32bit (32bit hardware) or 64bit+32bit with 64bit being default (64bit hardware).
cheers, Gerd
Hi,
The revised proposal:
- Build all packages for i686 (this requires cmov)
- Optimize for Atom
This sounds good to me/OLPC. Thanks!
- Chris.
On 06/17/2009 10:52 AM, Bill Nottingham wrote:
Given the loud feedback, I've updated the proposal at: https://fedoraproject.org/wiki/Features/F12X86Support
The revised proposal:
- Build all packages for i686 (this requires cmov)
- Optimize for Atom
Why?
- We don't really support i586 in any meaningful matter
- OLPC still works with base i686
- We are likely doing a mass rebuild for F-12 anyways, might as well switch while we're doing it
- Atom is the only currently produced 32-bit x86 chip of note; optimize for what's currently available
What about Pentium M family aka Centrino?
Luya
On 06/17/2009 11:39 PM, Luya Tshimbalanga wrote:
On 06/17/2009 10:52 AM, Bill Nottingham wrote:
Given the loud feedback, I've updated the proposal at: https://fedoraproject.org/wiki/Features/F12X86Support
The revised proposal:
- Build all packages for i686 (this requires cmov)
- Optimize for Atom
Why?
- We don't really support i586 in any meaningful matter
- OLPC still works with base i686
- We are likely doing a mass rebuild for F-12 anyways, might as well
switch while we're doing it
- Atom is the only currently produced 32-bit x86 chip of note; optimize
for what's currently available
What about Pentium M family aka Centrino?
The Pentium M chips are powerful enough not to care too much about 1-2% optimizations IMO, Atom is another story.
Steven
On Wed, Jun 17, 2009 at 01:52:26PM -0400, Bill Nottingham wrote:
- Build all packages for i686 (this requires cmov)
This cuts out AMD Geode ...
and for what ...
P4 2.4Ghz Athlon 3400+ Core2Duo E6850 Atom N270
march=i686/ -1.1% +2.0% +0.9% +0.6% mtune=generic march=i586/ +0.3% -0.3% -0.2% +1.3% mtune=atom march=i686/ -1.5% +1.2% +0.5% +1.7% mtune=atom
This just doesn't look worthwhile at all.
My proposal is that we actually start to 'downgrade' x86, start compiling for baseline i386, and try to support people running Fedora on really old hardware, through projects like the Minimal Platform feature.
Rich.
Hi,
On Wed, Jun 17, 2009 at 01:52:26PM -0400, Bill Nottingham wrote:
- Build all packages for i686 (this requires cmov)
This cuts out AMD Geode ...
That's not true; Geode has cmov, and should be compatible with gcc's i686.
- Chris.
Hi,
> On Wed, Jun 17, 2009 at 01:52:26PM -0400, Bill Nottingham wrote: >> - Build all packages for i686 (this requires cmov)
> This cuts out AMD Geode ...
That's not true; Geode has cmov, and should be compatible with gcc's i686.
Agreed, I've run i686 kernel/openssl on a geode based Fit-PC for 18 months (until F11 when it went to i586) and it supported it without massive issues. RPM/yum support is a different issue and will need to be addressed, but I'm sure that's probably a basic patch to identify a i586 that has cmov as being i686 capable.
Peter
On Wed, Jun 17, 2009 at 06:14:33PM -0400, Chris Ball wrote:
Hi,
On Wed, Jun 17, 2009 at 01:52:26PM -0400, Bill Nottingham wrote:
- Build all packages for i686 (this requires cmov)
This cuts out AMD Geode ...
That's not true; Geode has cmov, and should be compatible with gcc's i686.
It does work - I have CentOS 5.3 installed currently on my Geode.
But, it's very hard to install because it appears as a i586 machine. CentOS doesn't support i586, so I had to install it on the hard drive using another machine.
http://bugs.centos.org/view.php?id=2552
I guess it's possible there are subtle incompatibilities too, but I haven't found them yet. OpenSSL appears to work OK.
Rich.
Hi,
> On Wed, Jun 17, 2009 at 01:52:26PM -0400, Bill Nottingham wrote: >> - Build all packages for i686 (this requires cmov)
> This cuts out AMD Geode ...
That's not true; Geode has cmov, and should be compatible with gcc's i686.
It does work - I have CentOS 5.3 installed currently on my Geode.
But, it's very hard to install because it appears as a i586 machine. CentOS doesn't support i586, so I had to install it on the hard drive using another machine.
http://bugs.centos.org/view.php?id=2552
I guess it's possible there are subtle incompatibilities too, but I haven't found them yet. OpenSSL appears to work OK.
I believe one of the issues is with liboil and the optimisations it uses. I'm not 100% on the details but I think olpc has seen it,
Peter
On Wed, Jun 17, 2009 at 2:00 PM, Richard W.M. Jonesrjones@redhat.com wrote:
This just doesn't look worthwhile at all.
My proposal is that we actually start to 'downgrade' x86, start compiling for baseline i386, and try to support people running Fedora on really old hardware, through projects like the Minimal Platform feature.
Hmm. In the scheme of the numbers you references. What does that look like in terms of a performance penalty? Or was your proposal specifically covered by Bill's numbers? is the downgrade you are talking about within the jitter of Bill's posted performance numbers as well?
-jef
"Richard W.M. Jones" rjones@redhat.com writes:
- Build all packages for i686 (this requires cmov)
This cuts out AMD Geode ...
No, though it cuts out VIA C3 (used mostly(?) on EPIA (mini-ITX) boards). I have one but it had never run Fedora (only PXE ramdisk-based small LFS).
Hmm... Just checked and it seems they still list EPIA-M and others as "available". I'm not sure what to think about that:
- The CPU in question is C3 Eden / Samuel 2 / Ezra (not sure about the difference but C3-2(?) aka Nehemiah seems to be CMOV-capable).
- I think the clock range is 400 - 1000 MHz, though I've only seen 600+ MHz versions.
- it seems they've started selling mini-ITX EPIAs in 2002
- low-power fanless boards, the old EPIA-M was capable of hardware decoding MPEG2 and I'm told newer boards can do MPEG4 in hardware as well - they are/were popular as DVD/digital TV/DVR boxes.
- Eden CPU datasheet dated Jan 18, 2006 states that "CMOV and FCMOV instructions available" and "Notes On CPUID Feature Flags: The CMPXCHG8B instruction is provided and always enabled, however, it can be disabled in the corresponding CPUID function bit 8 to avoid a bug in an early version of Windows NT. However, this default can be changed via bit 1 in the FCR MSR."
- Maybe Samuel 2 and Ezra are non-cmov and Eden is cmov-able?
I don't say if those CPUs have to be supported by Fedora, I'm just posting this for completeness.
On Wed, Jun 17, 2009 at 23:00:38 +0100, "Richard W.M. Jones" rjones@redhat.com wrote:
My proposal is that we actually start to 'downgrade' x86, start compiling for baseline i386, and try to support people running Fedora on really old hardware, through projects like the Minimal Platform feature.
If you succeed let me know. I have a couple of P90 laptops with 24MB of memory that won't boot from CDs that I currently have RH 6.2 on and would upgrade to something more recent if I could.
I only use them once a year so I am not willing to invest a lot of time in helping. RH 6.2 works well enough for what I use them for.
On 06/17/2009 03:00 PM, Richard W.M. Jones wrote:
On Wed, Jun 17, 2009 at 01:52:26PM -0400, Bill Nottingham wrote:
- Build all packages for i686 (this requires cmov)
This cuts out AMD Geode ...
and for what ...
P4 2.4Ghz Athlon 3400+ Core2Duo E6850 Atom N270
march=i686/ -1.1% +2.0% +0.9% +0.6% mtune=generic march=i586/ +0.3% -0.3% -0.2% +1.3% mtune=atom march=i686/ -1.5% +1.2% +0.5% +1.7% mtune=atom
This just doesn't look worthwhile at all.
My proposal is that we actually start to 'downgrade' x86, start compiling for baseline i386, and try to support people running Fedora on really old hardware, through projects like the Minimal Platform feature.
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
Agreeing with Rich, what does this buy us? Being generous, 1.7% means you shaved 1 second off a 1 minute mp3 encode. Perhaps measurement accuracy is on the order of 0.5%? And the P4 performance degrades; Why further cripple the slower chip?
This slight benefit doesn't seem worth the effort of re-doing the build infrastructure and dropping/alienating older chip architectures.
-Bob Arendt
On Wednesday 17 June 2009 05:00:38 pm Richard W.M. Jones wrote:
On Wed, Jun 17, 2009 at 01:52:26PM -0400, Bill Nottingham wrote:
- Build all packages for i686 (this requires cmov)
This cuts out AMD Geode ...
and for what ...
P4 2.4Ghz Athlon 3400+ Core2Duo E6850 Atom N270
march=i686/ -1.1% +2.0% +0.9% +0.6% mtune=generic march=i586/ +0.3% -0.3% -0.2% +1.3% mtune=atom march=i686/ -1.5% +1.2% +0.5% +1.7% mtune=atom
This just doesn't look worthwhile at all.
My proposal is that we actually start to 'downgrade' x86, start compiling for baseline i386, and try to support people running Fedora on really old hardware, through projects like the Minimal Platform feature.
Sounds like a perfect target as a secondary arch. there is no reason why we cant support the older hardware as a community based effort of those interested in it. the primary arches are never going to satisfy everyone's itch but we leave the door open to do it through initiatives like secondary arches. The hardest part and the thing thats slowed things down so far is bootstrapping a new arch. its much much simpler for a x86 based arch as there is a baseline already bootstrapped.
Dennis
On 06/17/09 19:52, Bill Nottingham wrote:
P4 2.4Ghz Athlon 3400+ Core2Duo E6850 Atom N270
march=i686/ -1.1% +2.0% +0.9% +0.6% mtune=generic march=i586/ +0.3% -0.3% -0.2% +1.3% mtune=atom march=i686/ -1.5% +1.2% +0.5% +1.7% mtune=atom
2% difference max. You'll hardly notice that. Is that really worth the effort? IMHO not. People who care about performance that much certainly don't run 32bit any more.
cheers, Gerd
Gerd Hoffmann (kraxel@redhat.com) said:
On 06/17/09 19:52, Bill Nottingham wrote:
P4 2.4Ghz Athlon 3400+ Core2Duo E6850 Atom N270
march=i686/ -1.1% +2.0% +0.9% +0.6% mtune=generic march=i586/ +0.3% -0.3% -0.2% +1.3% mtune=atom march=i686/ -1.5% +1.2% +0.5% +1.7% mtune=atom
2% difference max. You'll hardly notice that. Is that really worth the effort?
As *already said*, if you're already doing a mass rebuild, it's near zero effort. (Also, if you think 5-10% is the threshold for any compiler performance improvements, the GCC team could use your help.)
Bill
Why can't you just leave it as-is? I mean is 1% improvement (for cpu intensive workload) really worth changing anything?
Instead of messing arround with stuff like that, I guess a lot of code would benefit of beeing build with profile driven optimizations, which often yields a 5-15% improvement without sacrifycing anything. On amd64 it would even enable the auto-vectorizer (if enabled) to vectorize only parts which count, without bloating code unescessary.
However that would be _real_ work, instead of just changing switches and discussing it forth and back ;)
- Clemens
Clemens Eisserer linuxhippy@gmail.com writes:
I mean is 1% improvement (for cpu intensive workload) really worth changing anything?
No, especially if it screws somebody (not me though).
- Optimize for Atom
I also don't get this one. Why not optimize for the cpu architectur in use by most fedora-x86 users, like p4 or c2d? It seems crazy to optimize for a cpu with maybe 5% market share, just because its the "only" x86 cpu left. (by the way, the via C7 is still sold too).
- Clemens
Clemens Eisserer (linuxhippy@gmail.com) said:
- Optimize for Atom
I also don't get this one. Why not optimize for the cpu architectur in use by most fedora-x86 users, like p4 or c2d? It seems crazy to optimize for a cpu with maybe 5% market share, just because its the "only" x86 cpu left. (by the way, the via C7 is still sold too).
1) Optimizing for P4 is ... messy 2) If you're using C2D, etc., you can already use the 64-bit distro.
Bill
- Optimizing for P4 is ... messy
- If you're using C2D, etc., you can already use the 64-bit distro.
So why not stay with generic, where most users would benefit.
Sure I could use 64-bit, as could all the others using 32-bit on 64-bit capable CPUs (I guess 50% of all fedora-x86 users).
- Clemens
On Tue, Jun 23, 2009 at 4:19 PM, Clemens Eissererlinuxhippy@gmail.com wrote:
- Optimizing for P4 is ... messy
- If you're using C2D, etc., you can already use the 64-bit distro.
So why not stay with generic, where most users would benefit.
Sure I could use 64-bit, as could all the others using 32-bit on 64-bit capable CPUs (I guess 50% of all fedora-x86 users).
Fedora x86_64 is the solution for good performance for those systems. The difference between 32bit mode and 64bit mode dwarfs all the little compiler tweaks we could discuss.
Optimizing for atom makes sense because it's the most modern hardware which doesn't have a higher performing alternative than the 32bit build.
Moreover, as an in-order core it atom should gain more from optimization than most cpus and generally optimizations for atom are harmless or even beneficial for other CPUs, while optimization for highly out of order CPUs can be devastating for in-order cores. As you can see in Bill's post upthread optimizing for atom is mildly beneficial even to P4.
Amusingly, on my own code at least -mtune=atom produces significantly faster code than -mtune=geode on my geode LX.
P4 is pretty much a lost cause. The move to i686 from i586 itself will make P4 slower, while helping most everything else by about the same margin that it hurt p4. Optimizing for P4 will probably hurt everything, certainly atom.
Atom systems are frequently battery powered, so improvements there can also to increased battery life. P4, OTOH, already requires a locally installed atomic power plant so energy isn't an issue there.
...
On Wed, 2009-06-24 at 00:48 -0400, Gregory Maxwell wrote:
Atom systems are frequently battery powered, so improvements there can also to increased battery life. P4, OTOH, already requires a locally installed atomic power plant so energy isn't an issue there.
There were actually some P4 laptops. They tended to be very large (to contain the required power and cooling) and have a battery life measured in minutes. They probably should also have come with heavy-duty lap heat protectors...
I doubt anyone who ever bought such a beast expected any kind of usable lengthy battery-powered operation out of it, though.
There were actually some P4 laptops. They tended to be very large (to contain the required power and cooling) and have a battery life measured in minutes. They probably should also have come with heavy-duty lap heat protectors...
I had a HP xe4500, with a P4M-1.6ghz, and its battery lasted 3 hours. (was 4000mA/h, 14,8V) Thats longer than my Core2Duo based thosiba laptop, which is a "buissness-class" machine.
Even found a review: http://reviews.cnet.com/laptops/hp-omnibook-xe4500-pentium/4505-3121_7-20001...
So yes the P4 was a horrible CPU, however when it came to heat/battery I didn't miss a thing with this laptop.
- Clemens
2009/6/25 Adam Williamson awilliam@redhat.com:
There were actually some P4 laptops. They tended to be very large (to contain the required power and cooling) and have a battery life measured in minutes. They probably should also have come with heavy-duty lap heat protectors...
I doubt anyone who ever bought such a beast expected any kind of usable lengthy battery-powered operation out of it, though.
Oh my God, I had one of those a few years ago -- it was a BEAST and sounded like a jet engine taking off. Then it committed motherboard suicide just before I was going to use it to present slides for a medium-important talk. Don't miss it at all. :)
MEF
Adam Williamson wrote:
On Wed, 2009-06-24 at 00:48 -0400, Gregory Maxwell wrote:
Atom systems are frequently battery powered, so improvements there can also to increased battery life. P4, OTOH, already requires a locally installed atomic power plant so energy isn't an issue there.
There were actually some P4 laptops.
One of these is sitting on my desk for several years.
They tended to be very large (to contain the required power and cooling) .. and have a battery life measured in minutes. They probably should also have come with heavy-duty lap heat protectors...
I doubt anyone who ever bought such a beast expected any kind of usable lengthy battery-powered operation out of it, though.
Hyperbole!
These beasts were their time's "desktop replacement" laptops, for which primarily display and keyboard sizes dictated the overall size. Mine actually is much smaller than many of today's DTRs.
At their time, these P4 laptops had been comparatively computationally powerful, comparatively cheep (desktop chipset), nevertheless sufficiently "compact" for occasional "mobile use".
Actually, pretty nice machines, ... at their time. Of cause, today, any mediocre netbook can easily outperform them wrt. many aspects.
Ralf