Propose your solution
Attachments
Duplicates
Comments
|
twright
wrote on the 29 Feb 08 at 17:08
|
|
|
|
maybe customized builds as well as a generic one as not to confuse newbies
|
|
aitikin
wrote on the 29 Feb 08 at 17:17
|
|
|
Problem with that is there really isn't that much of a performance difference. I use Gentoo for a long time and changing from the simpler options to the amd64 with sse3 didn't do a whole ton of a difference. It made one, for sure, but supporting older hardware has always been one of the major benefits of Linux.
Sure, most computers these days are more powerful than the minimal requirements. That being said, who doesn't like trying to get stuff to run on weaker hardware.
|
|
squizzz
wrote on the 29 Feb 08 at 17:49
|
|
|
@aitkin - hmmm I'm not sure about difference under Gentoo... I guess Gentoo is optimized by default. :)
Anyway... It always kept me wonder what does SuSE do, that on my 2 old machines (Pentium II 450MHz, 128MB RAM / Celeron 533, 256 MB RAM) they are light year ahead of Ubuntu - SuSE being responsive with full-blown KDE, while Ubuntu being usable only with Xfce/Enlightment. On the latter config SuSE was even snappier than Windows 2000. (plus: Ubuntu had accelerated graphics enabled and working, while SuSE had just 'nv'...)
|
|
Hawke
wrote on the 29 Feb 08 at 17:53
|
|
|
|
aitikin: of course, Desktop Ubuntu doesn't run on that weaker hardware anyway...and the desktop is Ubuntu's target, I believe. All in all, anything less than i686 optimization makes no sense.
|
|
qaaq
wrote on the 29 Feb 08 at 18:43
|
|
|
|
Go back to Gentoo! :P
|
|
squizzz
wrote on the 29 Feb 08 at 19:12
|
|
|
@qaaq: I never used Gentoo. I'm way too scared to even start using one. :P
I just wish Ubuntu was a little bit snappier.
|
|
probono
wrote on the 1 Mar 08 at 18:24
|
|
|
|
This would lead to binary incompatibilities of all sorts and to an increased complexity, which we don't want.
|
|
|
|
The difference is not usually that large, there are only couple key components that are worth really optimizing. Kernel being one, compiling it for instance with Intel's compiler really can make the difference but it's a lot of work especially from QA perspective. In overall extra optimizations are not really viable. Bumping to i686 would be though.
|
|
ethana2
wrote on the 2 Mar 08 at 08:39
|
|
|
i386 to i686 is huge, and it needs to be done. Don't tell me xine and gstreamer don't use MMX... please don't.
If I needed i586- support, I'd be using DSL or some such thing.
|
|
|
Yes, make i686.
Nobody uses Ubuntu on a i386, its too slow.
There is Slackware and OpenBSD for that.
Don't think anyone would use Ubuntu on a i486 either.
And probably not a i586 either.
|
|
miki
wrote on the 2 Mar 08 at 16:41
|
|
|
I686 architecture is a about 8 years old, and practically everybody is running on it.
On the other hand ubuntu linux is 4 years old, I would like to see, for it fourth birthday, if not a major packeges compiled for i686 architecture, then at least a some sort of a base ubuntu i686 cd with tools so everyone can make is one ubuntu i686 instalation.
This will solve a all sorts of speed problems (like boot speed, opening application like Ooo), and made it the most
desirable distro in linux world.
|
|
hspaans
wrote on the 2 Mar 08 at 19:15
|
|
|
Current glibc versions requires a i486 process at least so that leaves all the i386 processors dead in the water for any mainstream linux distro any how. And viewing at http://counter.li.org/reports/machines.php for example (and Ubuntu has may some figures as well) that i686 may be a issue for some people, but i586 may be a target to work on.
Also OpenSuSE has been shipping i586 binaries for years now and sometimes even i686 as well. But is it worth the trouble, now more and more people are switching to amd64?
But then again, for Ubuntu i686 may be a good level for the years to come. Also when keeping in mind that Sun Solaris x86 requires a Intel Pentium 4 at least. And do we need to keep all the legacy running? People who have anything lower then a P3/P4 are mostly already dead in the water when it comes to hardware support.
|
|
nvivo
wrote on the 4 Mar 08 at 18:08
|
|
|
Agreed that i686 should be the default. Maybe doing that in Hardy, so we don't have incompatibilities doing it just for half of the repository.
Now, just a question... don't x64 standard have a minimum instruction set so that this is not a problem anymore? If so, going to x64 should be the way to go if you want to get most of your pc.
I know that x64 is A LOT faster on my PC than x86.
|
|
|
> I know that x64 is A LOT faster on my PC than x86.
You're right, but much more people have i686 compatible hardware than x64.
|
|
|
|
This has to be done for SURE. The difference between Arch Linux and Ubuntu in terms of snapiness is huge. Arch runs so much quicker!
|
|
Götz
wrote on the 29 Mar 08 at 01:12
|
|
|
In Gutsy when a do "uname -m" there comes: i686
What does this mean? I think there is some 686 compilation in kernel, but in the rest of the software?
|
|
|
|
Ubuntu is compiled to work on i386 but optimized for i686.
|
|
|
its just silly for i686 to not be selected. i386 compatibility is not needed. i586 is over 15 years old and was discontinued over 10 years ago. In fact, even the highest end i586 machine doesn't support enough ram to run Ubuntu. 256mb, 512mb ram, on a pentium I processor, running ubuntu with 1MB video ram? Guess what, it won't run. You won't get it to boot in under 5 minutes. Half those machines don't even have CDROM drives, much less ethernet ports and broadband connections. Ubuntu is not for these systems.
Anybody running a system that old needs to find another linux distro because ubuntu just doesn't support it properly. And if thats the case, then why compile for the baseline processor i386?
i686 should be the baseline march with optimization for core or athlon processors. Just look at all the other distros out there with similar basline CPU requirements: about twice as fast at just about everything.
|
|
Hawke
wrote on the 16 May 08 at 19:48
|
|
|
|
On the other hand, some Via processors (at least the C3) can't handle some i686 instructions.
|
|
|
pentium 1 (i386) show me the guy who has it?
i486, pentium2, is past too.
i586, pentium 2, I am ukrainian, our univercity is very poor, but even it has found money to make upgrade (the lowest machine is p3(i686)) highest is Duron 1,6, p4 2,4.
I think i586 is pust too.
i686(p3 600Mhz) i can buy for 10$ in my country, it's going without saying.
Mandriva has i586 as minimum far time ago, and i don't thinks that they are have problem with coomplain.
I think i686 must be as default and minimum, about VIA C3, it's bad, but at least i586 as minimum that's what needed to be done. Make a vote, or some thing else, i'm sure a lot of people who is familiar with x86 archi says i586 is low level, and we might be need to think into i686 archi ;)
|
|
|
i586 as minimum
i686 as a way to thinking
+1
|
|
steve196
wrote on the 18 May 08 at 19:44
|
|
|
You are confusing the terms: i686 are 64 bit Pentium/Athlon.
Pentium3, Pentium4 and Socket A Athlons are all i586.
There is a million possible reasons, why Arch is snappier. Wouldn't it be smart, to find out, what actually makes the big difference, before copying them?
|
|
Hawke
wrote on the 20 May 08 at 17:49
|
|
|
Wow. There's a lot of confusion here from both amdlintuxos and steve196.
i386: the Intel 386 processor, and AMD clones of same.
i486: the Intel 486 processor, and AMD clones of same.
i586: Pentium; AMD K5 and K6, K6-II, K6-III, Via C3
i686: Pentium Pro, Pentium II, Pentium III, Pentium 4, Via C7, AMD Athlon (and variants). All 64-bit processors when in 32-bit mode.
See also http://en.wikipedia.org/wiki/I686 -- according to which, some C3 processor are i686 as well. I know for a fact there are i686-incompatible C3 processors though.
|
|
mp3phish
wrote on the 21 May 08 at 02:13
|
|
|
@ Hawke et al
i386: the Intel 386 processor, and AMD clones of same.
i486: the Intel 486 processor, and AMD clones of same.
i586: Pentium; AMD K5 and K6, K6-II, K6-III, Via C3
i686: Pentium Pro, Pentium II, Pentium III, Pentium 4, Via C7, AMD Athlon (and variants). All 64-bit processors when in 32-bit mode.
This is exactly true. Now lets put a date on these architectures
1986: i386 processor released. Fast page mode RAM. Typical RAM size less than 4MB. Typical hard drive size less than 500MB.
1989: i486 processor released. Fast page mode RAM, some with EDO. Typical RAM size between 4MB and 32MB. Typical hard drive size less than 1GB.
1993: i586 processor released(Pentium I). EDO ram, and newer systems with SDRAM. Typical RAM size below 32MB. Later systems had up to 128MB ram.
1995: i686 PentiumPro released. The first i686, typically installed in workstations and servers. Features an extended instruction set and on die cache. The very low yield made the chip expensive and for home systems, the gen2 Pentium (mmx version) was the processor of choice.
1996: i586 (gen2) Pentium MMX released. SDRAM. Typical RAM size below 128MB. hard drive sizes still in the single digit GB ranges. This was an interim release until the Pentium Pro architecture (i686) could be refined for higher yield and speed.
1997: i686 Pentium II released. First mainstream i686 processor produced. Windows 98 and NT4 are still the mainstream microsoft OS's on the market. typical RAM sizes between 64MB and 256MB.
1998: i686 Celeron (with no cache, later with on die cache) released. Typical ram size for these systems between 64MB and 128MB.
1998: Last Pentium I (i586) processor discontinued by intel. All x86 processors manufactured in 1999 and later for desktop, laptop, and servers were i686 processors. Typical systems shipped with Pentium I (mmx) processors shipped with less than 128MB system memory and ran windows 98 first edition.
1999: Pentium III released. Pentium II discontinued in favor of Pentium III (on die cache version of the PII, with some pipeline tweaks) Pentium III desktop systems typically shipped with 256MB and 512MB of system memory in this year. 1GB ram was unheard of in consumer systems until several years later.
In summary, it has been nearly 14 years since the i686 processor was introduced. It has been 11 years since i686 was in the majority of systems shipped to consumers. It has been 10 years since the last i586 processor was ever manufactured. It has been nearly 10 years since the first system shipping with 512MB of system ram was sold, which is generally considered the minimum system RAM size for a standard install of Ubuntu Linux.
|
|
Hawke
wrote on the 6 Jun 08 at 18:35
|
|
|
@mp3phish:
"It has been 10 years since the last i586 processor was ever manufactured."
With the exception of the Via C3, that's true (the last i586 "Ezra" version was launched in Jun 2002). I have no idea when exactly manufacturing ceased, but the successor ("Nehemiah") was released in July 2003. I doubt all production of "Ezra" was immediately halted, but I could be wrong.
For this single processor model, I think it would be worth keeping i586 compatibility.
i386 and i486 compatibility should go ASAP, in my opinion.
|
|
jdhore
wrote on the 8 Jun 08 at 19:46
|
|
|
1st: @Gotz - There IS a i686-optimized kernel, libc6 and other intensive apps (such as mencoder, ardour, etc), but all in all, that's it (unless you compile some of your apps yourself).
2nd: It will never happen because Ubuntu pulls from Debian Unstable at the start of a development cycle and Debian is still and will prolly always be i386 and Ubuntu currently doesn't rebuild all the Debian packages on import so i doubt they'd change their entire development system just to get a slight performance increase.
3rd: Doing this begins the long, hard cycle of crap as i call it. When i386, i486 and i586 go out the window, what's next? Optimizations for SSE (Which is only on P3's and Athlon XP's and high)? 64-bit only (if you have newer than a 4-year old system, it's 64-bit capable)? SSE2 or above? This kind of thing will never stop really until the lowest CPU Ubuntu will work on becomes a Athlon X2 or a Core 2.
|
|
|
|
I would generally idea, but the problem that would arise with trying to do this, is that there are a number of derivatives of Ubuntu that DO need to target machines whose processors are not i686 compatible. Although these derivatives may not be officially supported by Canonical, they are still seen as very prominent. The key example would be Xubuntu.
|
|
|
I would generally idea, but the problem that would arise with trying to do this, is that there are a number of derivatives of Ubuntu that DO need to target machines whose processors are not i686 compatible. Although these derivatives may not be officially supported by Canonical, they are still seen as very prominent. The key example would be Xubuntu.
The solution could be this. At the moment most packages are complied for i386, amd64 and (often) ppc. Well the solution would be to compile packages for i686 as well as i386. But this would cost a lot of time, storage space, and may be confusing to less technically inclined users.
|
|
mariuz
wrote on the 9 Jun 08 at 09:14
|
|
|
Hardy compiled for i686 but works on i586 it runs just fine
on an amd k6-2 @350Mhz with 256M of ram , firefox is snappy enough to read write gmail and also work with google docs
So there are still good old machines outhere and i can't afford yet to replace it for the moment . This is my secondary pc .
Sure sooner or later i will have to replace with an new i686 or amd64 based one.
ps: for the speed freaks we should provide some ppa alternatives where binaries are optimized , or they can recompile themselves (rebuild and replace their own binaries)
|
|
HiRez_l
wrote on the 9 Jun 08 at 13:08
|
|
|
|
I agree an i686 optimized build would be good, but I disagree that we need to discontinue support for older architectures, many of us are still running some machines with older architecture, successfully, with ubuntu.
|
|
Auzy
wrote on the 9 Jun 08 at 15:04
|
|
|
Great job guys, 31 posts and not one of you guys have actually run a proper test.
Before I see another reply added, I want one of you people arguing for this idea, to forget about the history of the intel processor which is totally irrelevent, and actually run a benchmark.
Because, so far, there is maybe 1 response of someone who ran tests, but not a comparison to test it.
So before any of you guys continue arguing this, actually test what you are preaching..
And this is why they would never let me mod. I would actually close all discussion until someone ran proper tests and submitted it.
|
|
Hawke
wrote on the 9 Jun 08 at 15:52
|
|
|
|
Auzy, how would someone submit "proper" tests with the discussion closed? :-p
|
|
Auzy
wrote on the 9 Jun 08 at 16:20
|
|
|
I dont think it would make any difference either way.
Everyone always ignores my requests for evidence anyway, so even if it was left open, it would be just useless discussions. I think I have already asked this in other dupes. Nobody bothered...
Everyone is happy to argue about how great this is, and how it will add an enormous speed increase, but nobody seems to be bothered enough to actually prove to themselves there is one. I think its because they are scared it may not be as big as they think..
|
|
jdhore
wrote on the 9 Jun 08 at 18:14
|
|
|
ARCHLINUX:
real 2m2.733s
user 1m45.433s
sys 0m7.460s
DEBIAN UNSTABLE I386:
real 1m54.753s
user 1m47.231s
sys 0m6.080s
Both running same kernel (2.6.25) same version of Tar (1.20) and GNOME (2.22.2) and extracting via CLI.
System Specs: 2.4GhZ P4 Northwood (533MhZ FSB), 1GB RAM, 5400RPM HDD
Archive info: 315MB .tar.bz2 archive
There's some benchmark happiness for you
|
|
jdhore
wrote on the 9 Jun 08 at 18:29
|
|
|
OK, i just re-ran the un-tar test with a cleanly rebooted Arch:
real 1m59.056s
user 1m42.187s
sys 0m7.083s
so...doing the math (using the real figures), a i686-optimized distro (Arch...and Arch even has other optimizations) is only about 4% faster at CPU intensive stuff (during un-tarring, CPU usage was pegged at 100% on all 3 tests) than a i386 distro with i686 kernel and libc6 (Which is the same way Ubuntu does it)
|
|
jdhore
wrote on the 9 Jun 08 at 18:49
|
|
|
MAKE TESTS:
ARCHLINUX:
real 0m53.916s
user 0m44.610s
sys 0m5.393s
DEBIAN I386:
real 0m54.321s
user 0m44.271s
sys 0m5.036s
This was same system as before, doing a clean make of XChat with all the same options on both. both distros are/were at the same versions of libs (glib, gtk, gcc, etc).
Again, using math and the figure in real, Arch was about 1% faster at compiling XChat than Debian.
I should mention, this is a bit more/less comparative because Debian is A LOT faster and A LOT less bloated than Ubuntu so it would prolly differ more, but Ubuntu couldn't do all the optimizations Arch does or even close.
|
|
marnold
wrote on the 9 Jun 08 at 18:51
|
|
|
|
If it ain't broke don't fix it IMHO
|
|
salseeg
wrote on the 20 Aug 08 at 08:24
|
|
|
it would be too complex to have packages built for every CPU
AFAIK apt-build allows you to rebuild your software for your CPU, why not to use this? ... may be create some fronted to detect best options for current CPU
|
|
r0g
wrote on the 12 Sep 08 at 01:23
|
|
|
i586 +1
i686 -1
Hey my old Thinkpad's i586 and it runs kubuntu very nicely thank you! Let's not do a Vista and make a massive contribution to the worlds landfills for no good reason.
|
|
6205
wrote on the 13 Sep 08 at 17:42
|
|
|
f0g ->
i doubt that your Thinkpad is i586, because first i686 CPU was Pentium Pro in 1995
Ubuntu should be i686 optimized asap
|
|
|
Nobody's saying to totally discontinue making an 1386 version. The idea is, you can keep making the i386 edition if necessary, but also provide a version for all of us with i686 processors.
(If I could, I'd be using the 64-bit one, as I do intensive computational work that would speed up enormously and make it worthwhile. It's the lack of a decent flash player for 64-bit that's holding me back - don't say swfdec or Gnash, they just aren't ready yet, though Adobe's got a 64-bit alpha out now, so hopefully not much longer to wait...)
So many other distros are provided as i686 it's ridiculous that we don't. In fact, because we insist on i386, Ubuntu has a bit of a reputation for being one of the slower distros. For example Arch (which is i686) is frequently faster than Ubuntu. Naturally it depends on your setup but I've found Fedora to run faster too, and guess what, it's i686 too. Run around Google for a bit and check the benchmarks that have been done.
Providing multiple builds doesn't have to confuse newbies. The ubuntu website could host some kind of script that detects what processor the computer has, and suggests which build to use. (Naturally, accompanied with a message saying exactly what the script does, that it isn't malicious code etc etc). Besides, newbies don't have a problem with choosing between i386 vs x86-64 on the website today.
And for the rest of us who are more technically inclined, just host a bunch of links to i386, i686 and perhaps i586 as well as the 64-bit, SPARC and whatever. We can already sort through the plethora of builds - one or two more won't cause much trouble.
+1
|
|
|
I have picked one example (not very scientific, I know, but quick and dirty). There is a c program at
http://www.network-theory.co.uk/docs/gccintro/gccintro_80.html
Which uses integer arithmetic, bit shifting etc and takes long enough to run to give some sort of result. I have compiled and run it using different compiler flags. Using GCC 4.3.3-5ubuntu4
I then run the resultant binary on my Intel E2220 processor (Core 2) using the command
time ./a.out
I have stated the actual CPU time used in each case to run the resultant binary:
Command Time to execute a.out
gcc collatz.c 0.584s
gcc -march=i686 collatz.c 0.580s
gcc -march=i386 collatz.c 0.572s
gcc -O2 -march=i686 collatz.c 0.428s
gcc -O2 -march=i386 collatz.c 0.408s
gcc -O3 -march=i386 -mtune=i686 collatz.c 0.264s
gcc -O3 -march=i386 collatz.c 0.216s
gcc -O3 -march=i686 collatz.c 0.148s
From these results, Putting optimisation up to -O3 makes a bigger difference than march alone. Combining higher optimisation -O3 with -march=i686 makes the biggest difference.
Don't use -march=i686 unless you use higher optimisation as well.
-march=i686 is equivalent to -march=pentium2
Using -march=i686 gives a 31.5% speed improvement when combined with -O3. If not combined with -O3, -march=i686 makes execution slower.
|
|
|
According to GCC developers, optimisations which almost always give faster code go into -O2. Also, those optimisations which improve stability.
-O3 has optimisations which don't necessarily make faster code. Eg the code may be bigger, and may not fit into the execution cache where O2 would.
According to the developers, march=pentium should (almost) always make an improvement in speed.
So perhaps we should be using -O2 and march=pentium2 and help GCC developers get the optimisation mix right. One way might be to make a test suite for an operating system build which GCC developers can use.
Or perhaps build a test CD using -O3 and march=pentium2 and give GCC developers feedback whether those optimisations included in -O3 generally do a good job for an OS build.
|
|
|
on the 26 Aug 09 at 18:09 I posted results of a test using collatz.c as an example. On further examination, much of the time, the code is calling a function. the -O3 optimisation enables -finline-functions. This optimisation eliminates that function call overhead, making the object code much faster.
It appears that with -O2, GCC relies upon the programmer to decide when a function is to be inlined by using the inline function keyword in the C source code. Apparently, inlining functions can sometimes make object code larger, sometimes smaller.
I modified collatz.c to include the inline keyword on the step and nseq functions. using gcc -O2 collatz.c, the execution time was down to 0.172s. With -march=pentium2, execution time was 0.179s.
Without inlining, execution time about 0.43s.
With -O3, or with the -finline-functions switch, GCC tries to make good decisions where to in-line functions.
In general, I think the issue of compiler optimisation needs to be visited, but with the background of a series of distribution-wide tests. We should re-compile the next release of Ubuntu CD with several releases using different optimisation features. Keep them amongst developement CD downloads. After the trials, using the help of GCC developers, make a sensible decision which flags work for us and should be enabled by default.
Inline functions may be a unique case, as programmers have the option of enabling that in the code, but many programmers may feel this sort of optimisation of the code is the role of the compiler (i.e. GCC), not them. At the same time, GCC authors may consider inlining the responsibility of the code writer, as there is the possibility of enabling it in the code. So decide this optimisation should remain optional. Consequently, we may find that much code which would benefit from inlining remains as discrete function calls, which are clearly much slower. This could be a good area for Ubuntu to adopt a policy. We need tests to back this up.
|
|
|
To summarise my previous post, Compiling Ubuntu for the Pemtium2 or better might not make much performance difference for most code. (For audio or video codecs, it might make a big difference).
Carefully using compiler optimisations which are not currently used by default might make a big difference for that ubuntu code which takes most CPU cycles.
See:
http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
|
Post your comment
|
Ubuntuforums.org thread #437285
