I can count the total number of people in the world who still use a 386 on the fingers of both of my hands. Why are we still catering to this small group of people?
With the exception of the kernel and glibc, all RPM's are optimized for 386 architecture. This is a waste of system resources. Study after study shows that you can achieve a 10% - 40% performance improvement my optimizing code for a specific architecture. Windows XP may only be optimized for a Pentium, but by golly, at least the whole thing is optimized, not just the kernel and the C library.
Just look at X. Is anyone seriously trying to get X to run on a 386? I can understand compiling the text-based programs, like bash, for 386. You can run a text-only box on a 386 just fine. Why do that for X? Why do that for GNOME, KDE, or any graphical program for that matter?
I know that I can recompile of these program from the source code to achieve those optimizations. However, why should everyone who wants to optimize their systems have to go through that, just so a handful of people with 386 machines can run X out-of-the-box? Then, we have recompile all over again with the next RPM release.
Why can't the few people who have a 386 be made to recompile X from sources to get it to run on there machines, so the rest of us can enjoy the performance boost from running optimized binaries?
I think we seriously need to rethink the distribution strategy. At the very least, all graphical programs should be optimized for i686.
Joseph D. Wagner
On Wed, Jan 19, 2005 at 10:08:22AM -0600, Joseph D. Wagner wrote:
With the exception of the kernel and glibc, all RPM's are optimized for 386 architecture. This is a waste of system resources. Study after study
Read the archives -- this comes up a lot. They're optimized for pentium4, but use the i386 instruction set.
They're optimized for pentium4, but use the i386 instruction set.
There are instructions which have come out since the 386, like MMX, that could improve the performance of programs. In this case, graphics programs. Why should my graphics programs suffer because some fool is running a 20 year old computer?
this comes up a lot.
If that many people are crying for it, maybe it should be done.
Joseph D. Wagner
On Wed, 2005-01-19 at 10:26 -0600, Joseph D. Wagner wrote:
They're optimized for pentium4, but use the i386 instruction set.
There are instructions which have come out since the 386, like MMX, that could improve the performance of programs. In this case, graphics programs. Why should my graphics programs suffer because some fool is running a 20 year old computer?
File bugs for the apps that you *know* could use the optimization. Make sure the code actually can use those newer instructions and that the compiler actually does any auto-vectorization for the code in question. Provide benchmarks proving that performance increases instead of simply blind and likely incorrect assumptions.
this comes up a lot.
If that many people are crying for it, maybe it should be done.
Or maybe that many people are clueless. Thankfully most of them are as rude and obnoxious as certain others.
Joseph D. Wagner
Sean Middleditch wrote:
On Wed, 2005-01-19 at 10:26 -0600, Joseph D. Wagner wrote:
They're optimized for pentium4, but use the i386 instruction set.
There are instructions which have come out since the 386, like MMX, that could improve the performance of programs. In this case, graphics programs. Why should my graphics programs suffer because some fool is running a 20 year old computer?
File bugs for the apps that you *know* could use the optimization. Make sure the code actually can use those newer instructions and that the compiler actually does any auto-vectorization for the code in question. Provide benchmarks proving that performance increases instead of simply blind and likely incorrect assumptions.
Benchmarking is important in this case. Use of the new instructions is only going to help in very specific cases where the code is CPU bound and the operations fit the style of parallel processing supported by the new instructions. In some cases the performance could be hurt due to the overheads of packing and unpacking the data for the MMX/SSE/3DNOW! register, besides on P4 processors the SSE hardware works at only half the speed as the integer units, so the gains are not going to be as big on P4.
OProfile could be used to identify areas of code that are cpu bound. Some analsysis could be done to determine whether those sections of code could benefit from using the the special operations. However, these types of improvements by changing instructions are not going to give the order of magnitude improvements due to algorithm changes/improvements in code. These instruction changes are also very processor specific, while improvements in the algorithms will work on virtually everything.
Blindly compiling all the rpms to use the latest instruction set isn't going to magically improve the performance of the code. There are other lots of other things besides processor instructions affecting performance like the memory hierarchy, interprocessor communciation, and algorithms.
-Will
On Wed, Jan 19, 2005 at 10:26:51AM -0600, Joseph D. Wagner wrote:
They're optimized for pentium4, but use the i386 instruction set.
There are instructions which have come out since the 386, like MMX, that could improve the performance of programs. In this case, graphics programs.
Many graphics programs test for features such as mmx/3dnow/sse at runtime and run alternative hand-written assembly routines when present. This way the program runs on any x86 platform regardless of featureset without needing to be compiled for a specific variant.
Why should my graphics programs suffer because some fool is running a 20 year old computer?
You forgot to attach the benchmarks showing the improvements.
For a large percentage of the packages shipped in Fedora, RPMs 'optimised' for >386 just won't be noticable.
Dave
On Wed, Jan 19, 2005 at 10:26:51AM -0600, Joseph D. Wagner wrote:
They're optimized for pentium4, but use the i386 instruction set.
There are instructions which have come out since the 386, like MMX, that could improve the performance of programs. In this case, graphics programs. Why should my graphics programs suffer because some fool is running a 20 year old computer?
MMX using apps all check for MMX v 3Dnow v SSE already and have too. The instructions in question are not compiler generated as they are specialist
If that many people are crying for it, maybe it should be done.
Lots of people thought the earth was flat and cried for the death of those who disagred too
This is not true. The default optimization is for Pentium 4 class processors.
This is not accurate. gcc has two separate sets of optimizations. The first (mtune) tunes everything except the ABI. This is the part that is optimized for the Pentium 4. The second (march) actually tunes the ABI. The second is optimized for 386. In other words, it won't take advantage of any instruction that didn't exist on the original 386.
I would like my ABI, especially for the graphics programs, to be optimized for more modern architecture, like i686.
Joseph D. Wagner
On Wed, 19 Jan 2005, Joseph D. Wagner wrote:
This is not accurate. gcc has two separate sets of optimizations. The first (mtune) tunes everything except the ABI. This is the part that is optimized for the Pentium 4. The second (march) actually tunes the ABI. The second is optimized for 386. In other words, it won't take advantage of any instruction that didn't exist on the original 386.
We know this, but the present compile settings still are just fine. Please go read the archives! :)
Best, -- Elliot
On Wed, 2005-01-19 at 16:35, Joseph D. Wagner wrote:
This is not true. The default optimization is for Pentium 4 class processors.
This is not accurate. gcc has two separate sets of optimizations. The first (mtune) tunes everything except the ABI. This is the part that is optimized for the Pentium 4. The second (march) actually tunes the ABI. The second is optimized for 386. In other words, it won't take advantage of any instruction that didn't exist on the original 386.
I would like my ABI, especially for the graphics programs, to be optimized for more modern architecture, like i686.
Joseph D. Wagner
Pointing out the obvious why doesn't somebody test core 3 against a fully source built distro like Gentoo and see if the performance gains are real - thats not just benchmark, but perceived responsiveness. If the gains are that huge then users will cry ever louder and it will happen.... thats the open source way.
Or alternately some people can "fork off" and build their own Fedora based distro - Redhat lawyers permitting.......
Jon
On Wed, Jan 19, 2005 at 04:52:15PM +0000, Jonathan Andrews wrote:
Pointing out the obvious why doesn't somebody test core 3 against a fully source built distro like Gentoo and see if the performance gains are real - thats not just benchmark, but perceived responsiveness. If
Even better, test un unoptimized Gentoo against an optimized one. That way, you'll have identical versions of tested software.
Emmanuel
On Wed, 19 Jan 2005 18:00:01 +0100, Emmanuel Seyman seyman@wanadoo.fr wrote:
On Wed, Jan 19, 2005 at 04:52:15PM +0000, Jonathan Andrews wrote:
Pointing out the obvious why doesn't somebody test core 3 against a fully source built distro like Gentoo and see if the performance gains are real - thats not just benchmark, but perceived responsiveness. If
Even better, test un unoptimized Gentoo against an optimized one. That way, you'll have identical versions of tested software.
That's the best suggestion. In theory, I think optimized/unoptimized builds of gentoo leading to a comparison would support the main argument here. I for one have built KDE from qt on up optimized versus unoptimized with no noticeable gain in anything.
Emmanuel
-- fedora-devel-list mailing list fedora-devel-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-devel-list
On Wed, 2005-01-19 at 17:05, Nick Bargnesi wrote:
On Wed, 19 Jan 2005 18:00:01 +0100, Emmanuel Seyman seyman@wanadoo.fr wrote:
On Wed, Jan 19, 2005 at 04:52:15PM +0000, Jonathan Andrews wrote:
Pointing out the obvious why doesn't somebody test core 3 against a fully source built distro like Gentoo and see if the performance gains are real - thats not just benchmark, but perceived responsiveness. If
Even better, test un unoptimized Gentoo against an optimized one. That way, you'll have identical versions of tested software.
That's the best suggestion. In theory, I think optimized/unoptimized builds of gentoo leading to a comparison would support the main argument here. I for one have built KDE from qt on up optimized versus unoptimized with no noticeable gain in anything.
True, my 1.3Ghz athlon doesnt even break a sweat in the CPU stakes doing most jobs.
A request for core 4
If more people has the fantastic 'kcpuload' tool available it would give them a better idea whats going on. Its in the kde archive, can it go back into core 4 as a default applet. Gnome has a good cpu monitor, but the best one kde has is missing from core ?
Jon
On Wed, Jan 19, 2005 at 04:52:15PM +0000, Jonathan Andrews wrote:
Pointing out the obvious why doesn't somebody test core 3 against a fully source built distro like Gentoo and see if the performance gains are real - thats not just benchmark, but perceived responsiveness. If the gains are that huge then users will cry ever louder and it will happen.... thats the open source way.
Because its an apples/oranges comparison. Unless you have the exact same versions of software, with exactly the same patches, with exactly the same configuration options, on exactly the same kernel/glibc, and only different compiler flags for the application, you're comparing N different things at the same time, resulting in a cumulative effect rather than a direct 1:1 comparison.
Or alternately some people can "fork off" and build their own Fedora based distro - Redhat lawyers permitting.......
We didn't send lawyers after the folks rebuilding RHEL packages into binary distros, so I can't see why we'd do so for Fedora, as long as any trademark's were respected etc.
Dave
On Wed, Jan 19, 2005 at 10:35:43AM -0600, Joseph D. Wagner wrote:
This is not true. The default optimization is for Pentium 4 class processors.
This is not accurate. gcc has two separate sets of optimizations. The first (mtune) tunes everything except the ABI. This is the part that is optimized for the Pentium 4. The second (march) actually tunes the ABI. The second is optimized for 386. In other words, it won't take advantage of any instruction that didn't exist on the original 386.
I would like my ABI, especially for the graphics programs, to be optimized for more modern architecture, like i686.
Please read the archives, all this has been answered several times already.
Yes, we know very well about -march and -mtune difference. The current CFLAGS (for *.i386.rpm -march=i386 -mtune=pentium4) are just fine for the whole distro.
But please tell us what instructions could be useful and would overweight the negatives (making FC impossible to run on certain hardware).
The ISA changes between i386 and i586 are uninteresting for the vast majority of programs (the main differences are atomic and specialized instructions, atomic instructions are used mostly by the kernel, C library and thread library, all of them come in i686 variants).
The i686 ISA adds conditional moves (some argue that this is optional i686 feature, but GCC's definition of i686 is i686 with cmov). Now, cmov* speeds things up on certain architectures, but: 1) using it everywhere would mean that FC doesn't support various not so old VIA CPUs, etc. 2) on P4, cmov* instructions aren't any win over using branches
Later CPUs add MMX, 3dNOW!, SSE, SSE2, SSE3 instructions. But 1) only GCC 4.0+ supports autovectorization, and only for SSE/SSE2 2) programs/libraries that have MMX/3dNOW!/SSE/SSE2/SSE3 assembly or use {,p,e,x}mmintrin.h usually choose between several implementations at runtime depending on what the CPU supports (e.g. various graphics/multimedia programs do this), or like e.g. gmp are packaged, so that the dynamic linker uses optimized libraries on SSE2+ capable CPUs 3) with SSE2+, -mfpmath=sse can speed up FPU intensive programs or libraries quite a bit. But SSE2+ is very high bar for the lowest supported CPU by FCx/ix86 ATM, that would mean not supporting even 2 years old CPUs. So, if a particular library is seen that has measurable improvements with -mfpmath=sse, it is far better to ship it as /usr/lib/sse2/ library instead of shipping everything in .pentium4.rpm's.
Note that the vast majority of packages in the distro aren't CPU bound, so it is just about selecting those where there are measurable improvements that justify alternate rpms resp. second set of libraries in .i386.rpm packages etc.
Jakub
Has anyone been testing -Os (optimize for size) instead of -O2 on any greater scale? Fitting as much as possible in L1-cache is a great way to obtain high performance.
/Peter Backlund
On Wed, 2005-01-19 at 18:24 +0100, Peter Backlund wrote:
Has anyone been testing -Os (optimize for size) instead of -O2 on any greater scale? Fitting as much as possible in L1-cache is a great way to obtain high performance.
-Os versus -O2 for OpenOffice.org (on RHEL3, with gcc 3.3.2) produced no real benefit, besides a small reduction in library size (7-8 MB total through the whole set of libraries). It also made OOo hit optimization bugs (either gcc bugs or OOo code bugs) that had stuff as simple as file opening crashing. Most likely, its OOo's aggressive use of inline functions and complex templates that causes there to be only a minor benefit.
For other programs though, -Os may well produce better-running, small- therefore-better-for-cache binaries.
Dan
Peter Backlund wrote:
Has anyone been testing -Os (optimize for size) instead of -O2 on any greater scale? Fitting as much as possible in L1-cache is a great way to obtain high performance.
/Peter Backlund
The kernels in FC are currently compiled with -Os.
I worked with some North Carolina State University studenst testing something like this out this fall on Mozilla. They found some improvement in performance (reduction in L1 cache and instruction TLB misses). I have put the pdf report at:
http://people.redhat.com/wcohen/ncsu2004/Space%20Optimizations.pdf
-Will
On Wed, Jan 19, 2005 at 06:24:16PM +0100, Peter Backlund wrote:
Has anyone been testing -Os (optimize for size) instead of -O2 on any greater scale? Fitting as much as possible in L1-cache is a great way to obtain high performance.
I run with almost all of gnome -Os and its faster where I can do tests - but its hard to be scientific
On Wed, 2005-01-19 at 19:16 -0500, Alan Cox wrote:
On Wed, Jan 19, 2005 at 06:24:16PM +0100, Peter Backlund wrote:
Has anyone been testing -Os (optimize for size) instead of -O2 on any greater scale? Fitting as much as possible in L1-cache is a great way to obtain high performance.
I run with almost all of gnome -Os and its faster where I can do tests - but its hard to be scientific
On the OOo front, the compile flags for 2.0 will be/should be "-Os -fno-strict-aliasing" the strict aliasing is apparently why 1.1.X becomes unstable when compiled just with -Os.
C.
On Thu, 2005-01-20 at 08:51 +0000, Caolan McNamara wrote:
On Wed, 2005-01-19 at 19:16 -0500, Alan Cox wrote:
On Wed, Jan 19, 2005 at 06:24:16PM +0100, Peter Backlund wrote:
Has anyone been testing -Os (optimize for size) instead of -O2 on any greater scale? Fitting as much as possible in L1-cache is a great way to obtain high performance.
I run with almost all of gnome -Os and its faster where I can do tests - but its hard to be scientific
On the OOo front, the compile flags for 2.0 will be/should be "-Os -fno-strict-aliasing" the strict aliasing is apparently why 1.1.X becomes unstable when compiled just with -Os.
Good to know, maybe we should do some tests on that again with 1.1.x and see what we get...
Dan
Dnia 01/19/2005 06:02 PM, Użytkownik Jakub Jelinek napisał:
Yes, we know very well about -march and -mtune difference. The current CFLAGS (for *.i386.rpm -march=i386 -mtune=pentium4) are just fine for the whole distro.
And what about LDFLAGS? Has anyone been experimenting with this variable? I've read those two pages: http://forums.gentoo.org/viewtopic.php?t=226909 http://bugs.gentoo.org/show_bug.cgi?id=65002 and it sounds promising - some optimizations for free :D Does it have any drawbacks?
Caolan McNamara wrote:
On Thu, 2005-01-20 at 14:36 +0100, Dawid Gajownik wrote:
And what about LDFLAGS? Has anyone been experimenting with this variable? I've read those two pages:
FWIW OOo (2 at least) links with -Wl,-01
With no objective measurement of any performance win through optimizing LDFLAGS, as always.
And with hints of build breakage and incompatibilities.
73 de Jeff
On Thu, 2005-01-20 at 06:25, Jeff Johnson wrote:
And what about LDFLAGS? Has anyone been experimenting with this variable? I've read those two pages:
FWIW OOo (2 at least) links with -Wl,-01
With no objective measurement of any performance win through optimizing LDFLAGS, as always.
http://www.coyotegulch.com/reviews/intel_comp/intel_gcc_bench2.html I remember that coyote gulch did some benchmarks of gcc compilers with different flags. His site seems to be down though. The url I gave is not the study I'm really thinking of. I think that he tried a genetic algorithm type approach to try and find the "perfect" set of optimization flags to use.
I'm sure of someone wants to use up a lot of cycles then someone could use a lot of benchmarks with different combinations of flags to find the perfect match for some programs. You could use simulated annealing or genetic algorithms if you didn't want to exercise each and every combination.
I remember that coyote gulch did some benchmarks of gcc compilers with different flags. He tried a genetic algorithm type approach to try and find the "perfect" set of optimization flags to use.
His site is probably permanently down. I found some people had it cached and mirrored. http://geckies.user.cis.ksu.edu/tiki-view_cache.php?url=http://www.coyotegul... Acovea: Analysis of Compiler Options via Evolutionary Algorithm by Scott Robert Ladd .
On Thu, Jan 20, 2005 at 02:36:24PM +0100, Dawid Gajownik wrote:
Dnia 01/19/2005 06:02 PM, U??ytkownik Jakub Jelinek napisa??:
Yes, we know very well about -march and -mtune difference. The current CFLAGS (for *.i386.rpm -march=i386 -mtune=pentium4) are just fine for the whole distro.
And what about LDFLAGS? Has anyone been experimenting with this variable? I've read those two pages: http://forums.gentoo.org/viewtopic.php?t=226909 http://bugs.gentoo.org/show_bug.cgi?id=65002 and it sounds promising - some optimizations for free :D Does it have any drawbacks?
First of all, I guess for many packages it isn't trivial to propagate LDFLAGS down.
-Wl,-O1 does only one thing in all binutils I know, particularly use an O(nsyms^2) algorithm to optimize .hash section for minimal chain lengths. It is very expensive for really large shared libraries, for the largest ones I've seen it takes an hour or more to link with this option. Plus when the library is prelinked and used (at least mostly) as direct dependency of prelinked programs, then -Wl,-O1 actually hurts (as it means .hash section is bigger than necessary) instead of helping.
Jakub
Dnia 01/20/2005 03:45 PM, Użytkownik Jakub Jelinek napisał:
Plus when the library is prelinked and used (at least mostly) as direct dependency of prelinked programs, then -Wl,-O1 actually hurts (as it means .hash section is bigger than necessary) instead of helping.
Really helpful answer - thanks for claryfing it :)
On Wed, 19 Jan 2005, Joseph D. Wagner wrote:
I would like my ABI, especially for the graphics programs, to be optimized for more modern architecture, like i686.
Why ?
How much benefit does this provide in your tests ?
On Wed, 19 Jan 2005 10:08:22 -0600, Joseph D. Wagner technojoecoolusa@charter.net wrote:
I can count the total number of people in the world who still use a 386 on the fingers of both of my hands. Why are we still catering to this small group of people?
You could have spend some time searching through the archives
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Joseph D. Wagner wrote: |>You could have spend some time searching through the archives | | | You could have spent some time counting the huge numbers of people who are asking for the same thing I am asking for, and perhaps a little time working towards those ends.
I think we could all spend a little more time being a little more tolerant of each other. Everyone has the same goals here. Let's be civil towards one another.
- -- Michael Favia michael.favia@insitesinc.com Insites Incorporated http://michael.insitesinc.com
On Wed, 2005-01-19 at 10:51 -0600, Michael Favia wrote:
I think we could all spend a little more time being a little more tolerant of each other. Everyone has the same goals here. Let's be civil towards one another.
Okay, but could Joseph Wagner answer this question: Have you gone and read the archives regarding your 10%-40% claim? This has been discussed ad-nauseum on this list at a level of detail that I can only hope to ever understand, but I will defer to the glibc/gcc/kernel experts. For Mr. Wagner, I would also point out that to change compile options, change directory names, change the architecture portion of the rpm names (not all of which are required, but most certainly desirable to lessen confusion) is a HUGE undertaking. Not to mention the additional testing. To expect Fedora Core developers to embark on this journey without hard facts (i.e.: benchmarks) is dreaming.
On Wed, 2005-01-19 at 10:27 -0600, Joseph D. Wagner wrote:
You could have spend some time searching through the archives
You could have spent some time counting the huge numbers of people who are asking for the same thing I am asking for, and perhaps a little time working towards those ends.
I think the reason many people are asking about it is many people do not understand performance tuning. I'm one of them; several times I've guessed at what is making my program slow, and have been completely wrong. The right approach is to use tools to identify specific bottlenecks in specific programs or libraries.
As for the specific case of extended CPU instructions, many packages do already use them at runtime. For example, GStreamer does that.
Hi
You could have spent some time counting the huge numbers of people who are asking for the same thing I am asking for, and perhaps a little time working towards those ends.
unfortunately a large number of ignorant people exist. we already know that. Fedora is slow for a good number of people. they are looking for ways to improve that but compiler optimisations arent one of them according to knowledgable developers
On Wed, 19 Jan 2005 10:08:22 -0600, Joseph D. Wagner technojoecoolusa@charter.net wrote:
I can count the total number of people in the world who still use a 386 on the fingers of both of my hands. Why are we still catering to this small group of people?
With the exception of the kernel and glibc, all RPM's are optimized for 386 architecture.
Acckk! All RPM's are optimized for i386? But I'm running x86_64! Who let 3 out of the cage with this showstopper? Where's the errata? :)
This is a waste of system resources. Study after study shows that you can achieve a 10% - 40% performance improvement my optimizing code for a specific architecture. Windows XP may only be optimized for a Pentium, but by golly, at least the whole thing is optimized, not just the kernel and the C library.
Just look at X. Is anyone seriously trying to get X to run on a 386? I can understand compiling the text-based programs, like bash, for 386. You can run a text-only box on a 386 just fine. Why do that for X? Why do that for GNOME, KDE, or any graphical program for that matter?
I know that I can recompile of these program from the source code to achieve those optimizations. However, why should everyone who wants to optimize their systems have to go through that, just so a handful of people with 386 machines can run X out-of-the-box? Then, we have recompile all over again with the next RPM release.
Why can't the few people who have a 386 be made to recompile X from sources to get it to run on there machines, so the rest of us can enjoy the performance boost from running optimized binaries?
I think we seriously need to rethink the distribution strategy. At the very least, all graphical programs should be optimized for i686.
Joseph D. Wagner
-- fedora-devel-list mailing list fedora-devel-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-devel-list
Once upon a time, Joseph D. Wagner technojoecoolusa@charter.net said:
OK, let me make clarify what I said.
AMENDED: All IA32 RPM's are optimized for 386 architecture.
And that is still wrong. All FC i386 arch RPMs are optimized for either i686 (up through FC2) or P4 (starting with FC3).
Some important RPMs (kernel, glibc, openssl) where the difference has been proven come with i686 arch RPMs as well as i386 arch RPMs. Some other RPMs have code that detects i386 vs. i686 vs. Athlon (really "regular" vs. MMX/SSE/etc.) at runtime and uses the best available.
Whenever this comes up, people make some claims of improvement if the instruction set used is i686 instead of i386, but the challenge is to prove it. The only valid way to prove it is to do some type of repeatable benchmark of real applications with Fedora Core installed as distributed. Then rebuild the packages from the same source with the only change being i686 arch instead of i386 arch and retest. Anything else is not a valid test of the gain Fedora could see in switching from i386 arch to i686 arch.
If someone takes the time to prove the point (and it is proven that the pain is worth the gain), you will get results; people will listen. Until it is proven, you'll just get told to RTFA. The burden of proof is on those asking for the change.
Chris Adams wrote:
Some other RPMs have code that detects i386 vs. i686 vs. Athlon (really "regular" vs. MMX/SSE/etc.) at runtime and uses the best available.
Just curious -- which packages are those? (Besides X and kernel.)
Once upon a time, Jamie Zawinski jwz@jwz.org said:
Chris Adams wrote:
Some other RPMs have code that detects i386 vs. i686 vs. Athlon (really "regular" vs. MMX/SSE/etc.) at runtime and uses the best available.
Just curious -- which packages are those? (Besides X and kernel.)
I think some of the video related libraries do, but I don't know which right off. A quick check on my system (FC2 still) looks like:
/usr/X11R6/lib/libOSMesa.so.4 checks for MMX, 3DNow!, SSE /usr/bin/gimp checks for MMX, 3DNow!, SSE /usr/bin/xmms may use MMX, 3DNow! /usr/lib/libFLAC.so.4 may use cmov, MMX, SSE, SSE2, 3DNow! /usr/lib/libSDL-1.2.so.0 may use MMX, SSE /usr/lib/libgstreamer-0.8.so may use MMX, 3DNow!, SSE /usr/lib/libasound.so.2 may use MMX
Looking at libraries on my system, I also see special versions of some libraries:
/lib/tls/libdb-4.2.so /usr/lib/tls/libdb_cxx-4.2.so /usr/lib/sse2/libgmp.so.3 /usr/lib/sse2/libgmpxx.so.3 /usr/lib/sse2/libmp.so.3
The tls libraries are different because of threading, but that is i686 related.
I also see other things (from freshrpms and such) that are i386 arch but the library/binary has MMX/SSE/etc. detection code.
On Wed, 19 Jan 2005, Chris Adams wrote:
Once upon a time, Jamie Zawinski jwz@jwz.org said:
Chris Adams wrote:
Some other RPMs have code that detects i386 vs. i686 vs. Athlon (really "regular" vs. MMX/SSE/etc.) at runtime and uses the best available.
Just curious -- which packages are those? (Besides X and kernel.)
I think some of the video related libraries do, but I don't know which right off. A quick check on my system (FC2 still) looks like:
/usr/X11R6/lib/libOSMesa.so.4 checks for MMX, 3DNow!, SSE /usr/bin/gimp checks for MMX, 3DNow!, SSE /usr/bin/xmms may use MMX, 3DNow! /usr/lib/libFLAC.so.4 may use cmov, MMX, SSE, SSE2, 3DNow! /usr/lib/libSDL-1.2.so.0 may use MMX, SSE /usr/lib/libgstreamer-0.8.so may use MMX, 3DNow!, SSE /usr/lib/libasound.so.2 may use MMX
I'm wondering, did you run a command to get such a list ?
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
Once upon a time, Dag Wieers dag@wieers.com said:
On Wed, 19 Jan 2005, Chris Adams wrote:
/usr/X11R6/lib/libOSMesa.so.4 checks for MMX, 3DNow!, SSE /usr/bin/gimp checks for MMX, 3DNow!, SSE /usr/bin/xmms may use MMX, 3DNow! /usr/lib/libFLAC.so.4 may use cmov, MMX, SSE, SSE2, 3DNow! /usr/lib/libSDL-1.2.so.0 may use MMX, SSE /usr/lib/libgstreamer-0.8.so may use MMX, 3DNow!, SSE /usr/lib/libasound.so.2 may use MMX
I'm wondering, did you run a command to get such a list ?
find, grep, and strings
On Wed, Jan 19, 2005 at 01:42:13PM -0800, Jamie Zawinski wrote:
Chris Adams wrote:
Some other RPMs have code that detects i386 vs. i686 vs. Athlon (really "regular" vs. MMX/SSE/etc.) at runtime and uses the best available.
Just curious -- which packages are those? (Besides X and kernel.)
Most of the video and audio apps do this, Mesa does this for 3D and can make good use of 3DNow!
ons 2005-01-19 klockan 10:08 -0600 skrev Joseph D. Wagner:
I can count the total number of people in the world who still use a 386 on the fingers of both of my hands. Why are we still catering to this small group of people?
I'm not going to read the archives for you, but I think it has been pointed out that there are relevant CPU:s that only implement the i386 instructions. For example the VIA CPU:s.
/abo
ons, 19.01.2005 kl. 17.08 skrev Joseph D. Wagner:
I can count the total number of people in the world who still use a 386 on the fingers of both of my hands. Why are we still catering to this small group of people?
With the exception of the kernel and glibc, all RPM's are optimized for 386 architecture. This is a waste of system resources. Study after study shows that you can achieve a 10% - 40% performance improvement my optimizing code for a specific architecture. Windows XP may only be optimized for a Pentium, but by golly, at least the whole thing is optimized, not just the kernel and the C library.
Just look at X. Is anyone seriously trying to get X to run on a 386? I can understand compiling the text-based programs, like bash, for 386. You can run a text-only box on a 386 just fine. Why do that for X? Why do that for GNOME, KDE, or any graphical program for that matter?
I know that I can recompile of these program from the source code to achieve those optimizations. However, why should everyone who wants to optimize their systems have to go through that, just so a handful of people with 386 machines can run X out-of-the-box? Then, we have recompile all over again with the next RPM release.
Why can't the few people who have a 386 be made to recompile X from sources to get it to run on there machines, so the rest of us can enjoy the performance boost from running optimized binaries?
I think we seriously need to rethink the distribution strategy. At the very least, all graphical programs should be optimized for i686.
Joseph D. Wagner
Actually, i don't think the CPU is the biggest slowdown for fedora. From my personal experience - memory (RAM) is a bigger issue. I have a 200 mhz pentium 2 running fedora 3, full GUI and everything, and while i ain't claiming that it is hyperfast, its certainly usable. It has 384 MB of RAM.
OTOH, i have seen much "stronger" pc's (counting on CPU - from 600 mhz to a bit over 1 GHz) with less memory (256 MB or 180 MB) be slow/barely usable. Especially when starting up the big memory-eater - OpenOffice.
Which sometimes takes as long as 1-2 minutes to load. BAD.
So maybe this is more of a problem - RAM usage and *startup times of apps*?
When it comes to startup times - how difficult would it be to (given enough RAM - autodetection+manual config) preload OpenOffice and Firefox on OS start, so it would just "be there" (like both of them are when first started) when the user clicks the nice, little icon?
Something that could be done to ease up OO memory usage, is make it stop loading a ton of dictionaryes. Well, it has certain upsides. Now i know that many mispelled norwegian words are correct in Hungarian... I have heard this is a goal for FC4 (splitting up OOi18n) - am i correct?
Kyrre
On Wed, Jan 19, 2005 at 11:16:06PM +0100, Kyrre Ness Sjobak wrote:
Actually, i don't think the CPU is the biggest slowdown for fedora. From my personal experience - memory (RAM) is a bigger issue. I have a 200
Same here, really.
I have heard this is a goal for FC4 (splitting up OOi18n) - am i correct?
Yes, it's bugzilla-ed but I can't remember the bug_id off the top of my head.
Emmanuel
On Wed, 2005-01-19 at 23:16 +0100, Kyrre Ness Sjobak wrote:
ons, 19.01.2005 kl. 17.08 skrev Joseph D. Wagner:
I can count the total number of people in the world who still use a 386 on the fingers of both of my hands. Why are we still catering to this small group of people?
With the exception of the kernel and glibc, all RPM's are optimized for 386 architecture. This is a waste of system resources. Study after study shows that you can achieve a 10% - 40% performance improvement my optimizing code for a specific architecture. Windows XP may only be optimized for a Pentium, but by golly, at least the whole thing is optimized, not just the kernel and the C library.
Just look at X. Is anyone seriously trying to get X to run on a 386? I can understand compiling the text-based programs, like bash, for 386. You can run a text-only box on a 386 just fine. Why do that for X? Why do that for GNOME, KDE, or any graphical program for that matter?
I know that I can recompile of these program from the source code to achieve those optimizations. However, why should everyone who wants to optimize their systems have to go through that, just so a handful of people with 386 machines can run X out-of-the-box? Then, we have recompile all over again with the next RPM release.
Why can't the few people who have a 386 be made to recompile X from sources to get it to run on there machines, so the rest of us can enjoy the performance boost from running optimized binaries?
I think we seriously need to rethink the distribution strategy. At the very least, all graphical programs should be optimized for i686.
Joseph D. Wagner
Actually, i don't think the CPU is the biggest slowdown for fedora. From my personal experience - memory (RAM) is a bigger issue. I have a 200 mhz pentium 2 running fedora 3, full GUI and everything, and while i ain't claiming that it is hyperfast, its certainly usable. It has 384 MB of RAM.
Disk access is also pretty important. I've started some "simple" apps using strace and watched as screen after screen after screen after screen of open/stat/etc calls were made. GUI apps with all their icons and external resource files and image plugins and so on are the worst. The GTK+ folks are working on solutions in some cases (like icon loading), but there's a lot that could be done by just slimming down what apps need and how they go about getting those needs. (Take a JAR file - load the whole thing in RAM and get your code and data with only loading one file off the disk. I wonder how well that could work for normal executables?)
When it comes to startup times - how difficult would it be to (given enough RAM - autodetection+manual config) preload OpenOffice and Firefox on OS start, so it would just "be there" (like both of them are when first started) when the user clicks the nice, little icon?
I don't really believe much in preloading. If you're a company CEO that doesn't do anything other than make presentations and fire off a memo here and there, maybe preloading works. In general, though, spending startup time preloading OOo just to have Mozilla kick it back out again if you start Mozilla first, just isn't going to help - the preloading only helps once and only if its the first large app you run.
Better to just slim down memory usage. Or go buy more RAM, it's cheap. Seriously, I've got a 512MB chip as a keychain ornament. ~_^
Something that could be done to ease up OO memory usage, is make it stop loading a ton of dictionaryes. Well, it has certain upsides. Now i know that many mispelled norwegian words are correct in Hungarian... I have heard this is a goal for FC4 (splitting up OOi18n) - am i correct?
Kyrre
tor, 20.01.2005 kl. 01.07 skrev Sean Middleditch:
On Wed, 2005-01-19 at 23:16 +0100, Kyrre Ness Sjobak wrote:
ons, 19.01.2005 kl. 17.08 skrev Joseph D. Wagner:
I can count the total number of people in the world who still use a 386 on the fingers of both of my hands. Why are we still catering to this small group of people?
With the exception of the kernel and glibc, all RPM's are optimized for 386 architecture. This is a waste of system resources. Study after study shows that you can achieve a 10% - 40% performance improvement my optimizing code for a specific architecture. Windows XP may only be optimized for a Pentium, but by golly, at least the whole thing is optimized, not just the kernel and the C library.
Just look at X. Is anyone seriously trying to get X to run on a 386? I can understand compiling the text-based programs, like bash, for 386. You can run a text-only box on a 386 just fine. Why do that for X? Why do that for GNOME, KDE, or any graphical program for that matter?
I know that I can recompile of these program from the source code to achieve those optimizations. However, why should everyone who wants to optimize their systems have to go through that, just so a handful of people with 386 machines can run X out-of-the-box? Then, we have recompile all over again with the next RPM release.
Why can't the few people who have a 386 be made to recompile X from sources to get it to run on there machines, so the rest of us can enjoy the performance boost from running optimized binaries?
I think we seriously need to rethink the distribution strategy. At the very least, all graphical programs should be optimized for i686.
Joseph D. Wagner
Actually, i don't think the CPU is the biggest slowdown for fedora. From my personal experience - memory (RAM) is a bigger issue. I have a 200 mhz pentium 2 running fedora 3, full GUI and everything, and while i ain't claiming that it is hyperfast, its certainly usable. It has 384 MB of RAM.
Disk access is also pretty important. I've started some "simple" apps using strace and watched as screen after screen after screen after screen of open/stat/etc calls were made. GUI apps with all their icons and external resource files and image plugins and so on are the worst. The GTK+ folks are working on solutions in some cases (like icon loading), but there's a lot that could be done by just slimming down what apps need and how they go about getting those needs. (Take a JAR file - load the whole thing in RAM and get your code and data with only loading one file off the disk. I wonder how well that could work for normal executables?)
When it comes to startup times - how difficult would it be to (given enough RAM - autodetection+manual config) preload OpenOffice and Firefox on OS start, so it would just "be there" (like both of them are when first started) when the user clicks the nice, little icon?
I don't really believe much in preloading. If you're a company CEO that doesn't do anything other than make presentations and fire off a memo here and there, maybe preloading works. In general, though, spending startup time preloading OOo just to have Mozilla kick it back out again if you start Mozilla first, just isn't going to help - the preloading only helps once and only if its the first large app you run.
At least most of the (non-technical) users i know use typically just a few apps. And thats a web browser (usually the one that goes with the OS), and an Office suite. Often they use the two in paralell - i.e. clicking on a link to a .doc just to read it. (i know .doc's are a damn stupid format for document exange etc. but... its used. Can't change the whole world at once!) They expect the office program to be there in the matter of secounds.
Then they log on to/borrow mine/ask me nicely to check something. Just some plan, standard form ETC. I open the page in the webbrowser (no problem, quick. The firefox start-up delay is at least tolerable, if not optimal), and click the link. Do i want to open it in /home/kyrre/.redhat-openoffice(etc)? Yes.
*wait*
*wait*
*spash screen*
*wait*
*wait*
*gray document area, main window visible*
*wait*
and there the document is.
Now, print it. (this is from my laptop. its a 850 mhz with about (:P)300 MB of RAM (the number is odd, nonstandard, strange, so i cant remember it). Overall, an OK laptop.
As i am lucky there actually is a shared cups printer on the net. BUT the damn stupid windows DNS which i get from DHCP isn't configured to allow me to lookup the printer server, so i can't print without changing my DNS. (even if cups has the IP adress. Why not let cups use this as a fallback when DNS fails?)
*control-alt-f1*
*black, scary looking terminal*
*type root and password hellishly fast*
*vim /etc/resolv.conf*
*whacka-whack!*
And the person looking over my shoulder finds out that this is an OS only for über-geeks which do little other than "hack" the computer (and ofcource he believes a hacker is someone who breaks into governement computers, and generally use the term "1337" about them). He ain't far off asking me to change the saldo of his bank account now, as this looks about as cryptic (especially done in fast-foreward... It isn't like this is the first time i am doing this).
*logout*
*print*
He happily wanders off to collect the papers, only a little confused. While i am sitting pussled about why the little printer icon doesn't dissapear. Did i do anything wrong? Will he come back again, telling "there was no print!".
He didn't. But he didn't complain about the print using 1 page and 2 lines instead of exactly one page (due to font diffs).
All of this should be a simple fast forward as "click "web", open page, hit "open", wait one-five secounds, hit print, select printer. Here, get you paper.
Better to just slim down memory usage. Or go buy more RAM, it's cheap. Seriously, I've got a 512MB chip as a keychain ornament. ~_^
*rant* You tell that to a public shool which IT budget is to bogged down by mandantory Windows/office licenses, while the governement demands more licenses and less money to schools (while they claim they are pro-education. Oh, you mean all those new private schools popping up like mushrooms? I guess they meant that, especially their shareholders.). Luckily, it looks that not i am not the only one tired of having the coutry being ran of a coalition of right-wing party's, who get little rigth exept figthing between each other and internally, never listening to the public (such as when 90% of the people was opposed to the war on Iraq and had declared hate on Bush, they managed to send them a bunch of weapons (they shure need it!), strongly supporting Bushis'm (and being the honor guest of some republican meeting). Then they declared tax cutbacks their most important thing - while most of the people rather wanted the public sector to be rescued.
And that was when they did not privatize everything they could as fast as possible, claiming that theocraties are evil (their prime minister is a priest. But you know, he's christian, so its okay)
And noooobody eeever mentioned doublespeak?
Well, you know - we are extremely good at sending people to get people to make peace to eachother - just look at Israel/Palestina and Sri Lanka! */rant*
On Thu, 2005-01-20 at 19:05 +0100, Kyrre Ness Sjobak wrote:
[snip]
*rant*
[bunch of political crap snipped]
*/rant*
Please realize that fedora-devel list members are likely of wide and varied political opinion (as well as wide and varied country of residence and/or citizenship) and keep this kind of crap off this list.
tor, 20.01.2005 kl. 19.37 skrev Paul Iadonisi:
On Thu, 2005-01-20 at 19:05 +0100, Kyrre Ness Sjobak wrote:
[snip]
*rant*
[bunch of political crap snipped]
*/rant*
Please realize that fedora-devel list members are likely of wide and varied political opinion (as well as wide and varied country of residence and/or citizenship) and keep this kind of crap off this list.
Just got a bit provoked. I had a long argument about if we could afford upgrading one computer from 128 to 256 MB of RAM. Turned out we could only afford a 64 MB chip scavenged from a defunct older box (which was also scavenged for PSU, CPU-fan, HDD, floppy, cdrom etc.
pretty enviromentaly friendly, tough.
Then they log on to/borrow mine/ask me nicely to check something. Just some plan, standard form ETC. I open the page in the webbrowser (no problem, quick. The firefox start-up delay is at least tolerable, if not optimal), and click the link. Do i want to open it in /home/kyrre/.redhat-openoffice(etc)? Yes.
One thing I always wished for x-mas but never got it this:
First the bad case (how it today afaik): 1. I click the .doc and select "open with BLAH_PROG" 2. There is some waiting while it's downloaded into doh.tmp 3. The browser executes "BLAH_PROG doh.tmp" 4. There is some waiting for the app. 5. My doc is done.
Here is how I always wanted it to be instead: 1. I click the .doc and select "open with BLAH_PROG" 2. The browser tells program BLAH_PROG to launch and wait for a doc 3. I want for the .doc to download and parallely BLAH_PROG launches 5. My doc is done.
See how this would save a lof of time, especially when viewing docs from servers with highload (low bandwidth) and on a client with little RAM (long launch time)? This is something not even Windows has yet.
PS. This is of course very similar to the idea of parallelizing the boot process (such a discussion for seen on this list not too long ago) and I'm sure there are TONS if other places where such parallellization would speed up things conderiably! DS.
regards, martin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Martin Olsson wrote:
Here is how I always wanted it to be instead:
- I click the .doc and select "open with BLAH_PROG"
- The browser tells program BLAH_PROG to launch and wait for a doc
- I want for the .doc to download and parallely BLAH_PROG launches
- My doc is done.
Simple but very good idea i think. It requires a little more "situational awareness" i think. The filemanager will need to have someway to evoke a load document event of some type right?
Unless you can count on launching the app (empty) and then launching the app again (with document title appended and some unique switch) Which would revert to the current running instance. But you can't depend on that type of behavior for most apps for some time.
Or is there an easier implementation?
- -- Michael Favia michael.favia@insitesinc.com Insites Incorporated http://michael.insitesinc.com
On Wed, 2005-01-19 at 23:16 +0100, Kyrre Ness Sjobak wrote:
When it comes to startup times - how difficult would it be to (given enough RAM - autodetection+manual config) preload OpenOffice and Firefox on OS start, so it would just "be there" (like both of them are when first started) when the user clicks the nice, little icon?
Actually take a look at /usr/lib/ooo-1.1/soffice and its use of its own "pagein" program to prime the diskcache with the OOo libs. You could play around with calling pagein from your desktop login or other places.
C.
On Wed, 2005-01-19 at 23:16, Kyrre Ness Sjobak wrote:
Actually, i don't think the CPU is the biggest slowdown for fedora. From my personal experience - memory (RAM) is a bigger issue. I have a 200 mhz pentium 2 running fedora 3, full GUI and everything, and while i ain't claiming that it is hyperfast, its certainly usable. It has 384 MB of RAM.
OTOH, i have seen much "stronger" pc's (counting on CPU - from 600 mhz to a bit over 1 GHz) with less memory (256 MB or 180 MB) be slow/barely usable. Especially when starting up the big memory-eater - OpenOffice.
I've had FC3 running on a p233 with 64 Mb and Gnome, and it was usable if you avoided to open a huge bunch of X apps at the same time.
Of course I didn't used OO in this box - abiword eats less resources - and no daemon was runing in the background.
The system was capable of normal desktop use: surfing the net, using mail apps, writing docs and such.
I Also tried xfce in this box and it's a bit faster, seems less memory hungry that Gnome, and better suited for low end machines.
Right now this machine is running RHEL4 beta and Gnome with success.
May be the stop point is not FC3 resources consuming but OO's :)
Best regards.
On Wed, Jan 19, 2005 at 10:08:22AM -0600, Joseph D. Wagner wrote:
With the exception of the kernel and glibc, all RPM's are optimized for 386 architecture. This is a waste of system resources. Study after study shows that you can achieve a 10% - 40% performance improvement my optimizing code for a specific architecture. Windows XP may only be optimized for a Pentium, but by golly, at least the whole thing is optimized, not just the kernel and the C library.
The number of people who don't check the archives first is regrettably not a handful ;)
The files are currently mostly PIV optimised