191
votes
|
|
261
0
70
|
|
|
|
|
Propose your solution
Attachments
Duplicates
Comments
|
|
I think nearly nobody would try to install ubuntu on less than a Pentium II today..
By default, I think it would be good to propose a i686 version, but still keep a i386 version available for those who would like to install ubuntu on a very old machine.
|
|
theosib
wrote on the 4 Mar 08 at 20:16
|
|
|
You must be a former Gentoo user. We have to keep in mind that optimization is only necessary in a few very limited areas that actually become compute bottlenecks. The rule of thumb is that if your CPU load won't go to 100% for more than a few seconds, then more optimized code translates only into more idle time. That buys you nothing except MAYBE a tiny (unnoticeably small) bit more power efficiency.
This rule of thumb rules out a good 99% of the programs stored on your hard drive. In those cases, you might benefit a bit more from optimizing them for SIZE. Compiling for i686 probably won't help you much in that department.
There are, however, a number of high-profile that could benefit from being compiled not just for i686 but several architectural variants as well, and the system can automatically install the right one. Applications like this include compression tools (bzip2 can shave several minutes off of a many-GB compression task by being optimized), Firefox (because of its renderer and Javascript), OpenOffice, interpreters (bash, ruby, etc.), etc. Anything that would actually benefit from more efficiency.
In other words, don't waste time and space optimizing something that will only speed up from 1 second of run time to 0.9999 seconds of run time.
An exception could be made for heavily-loaded servers. For a desktop, the CPU overhead of your bittorrent program won't matter. But for a server, even the little tools add up. If your CPU runs at 100% all of the time, then every little thing adds up.
|
|
|
|
Would this really make that much of a difference in performance?
|
|
|
Should Definetly Shift to i686
There are no reasons not to do so.
|
|
|
|
Modern processors reorder instructions inside the processor. So reordering the instructions in the compiler will have little to no benefit in speed.
|
|
|
If I remember right:
Ubuntu is i386 compatible but optimized for i686.
|
|
|
|
Are there any benchmarks that show enough increase in speed to potentially alienate users on older hardware?
|
|
jarlath
wrote on the 4 Mar 08 at 21:38
|
|
|
I see as many disadvantages as advantages here. A lot of third world countries are using this in education on old computers. Also, the current method gives greater compatability allowing Ubuntu and linux reach a wider audience.
Let's acknowledge that with the releases as we currently do and leave optimization to the hobbyists.
|
|
|
+1
@theosib:
There can be improvements even if you don't hit 100%. If I can view a movie on i386 software which takes 15% CPU, or i686 one that takes 10% CPU - it's not big change - I won't see movie faster, but when I'm using laptop that means:
1. cpu speed can be lowered and switched less often
2. it will stay cooler and keep the fan running slowly / turned off
3. it won't heat up rest of hardware (disk...)
Another thing is that software never works on 10% cpu - that's just statistics (lies, damned lies, and ...) - it either runs, or waits. More - it either runs to respond to you, runs other code, or sleeps - so if some part of code can complete faster (because it was optimized), get back to waiting and return control to your "main" process without needing to run in another context switch - you'll get more responsive desktop. You can just recompile bigger part of the system and check if you see the difference. I did feel it. (and yes - that was gentoo with different flags - easiest to test this)
|
|
|
well I didn't vote up or down, cause I don't know if it would make any difference... I like the idea of installing on a Pentium Pro or II, but can you find one with 512MB, or even 256MB???
Ubuntu with 256MB is horrible, with 128MB I don't think the GUI would run... (console only)
|
|
|
One problem I see is for the people running Xubuntu, since its part of the Ubuntu family, would upgrading Ubuntu to i686 make Xubuntu i686 too?
They could seperate the two, and keep Xubuntu at i386, but that would make support too difficult.
|
|
|
I'm not going to vote this up unless there are some statistics to back up the benefits.
Bring us the data!
|
|
Ansible
wrote on the 4 Mar 08 at 23:26
|
|
|
|
Ditto on the benchmarks. let's see some demonstration of additional performance!
|
|
|
@zoubidoo, Ansible:
Data for you - generated just now:
faac from today's hardy (1.26-0.1ubuntu1)
running three times:
viraptor@hedgehog:~/rip$ faac track01.cdda.wav
Freeware Advanced Audio Coder
FAAC 1.26.1 (Mar 5 2008) UNSTABLE
Quantization quality: 100
Bandwidth: 16000 Hz
Object type: Low Complexity(MPEG-2) + M/S
Container format: Transport Stream (ADTS)
Encoding track01.cdda.wav to track01.cdda.aac
original:
frame | bitrate | elapsed/estim | play/CPU | ETA
8815/8815 (100%)| 114.1 | 15.5/15.5 | 13.24x | 0.0
8815/8815 (100%)| 114.1 | 15.6/15.6 | 13.08x | 0.0
8815/8815 (100%)| 114.1 | 15.6/15.6 | 13.09x | 0.0
modified -march=i686 -ffast-math:
frame | bitrate | elapsed/estim | play/CPU | ETA
8815/8815 (100%)| 114.1 | 14.1/14.1 | 14.50x | 0.0
8815/8815 (100%)| 114.1 | 14.0/14.0 | 14.62x | 0.0
8815/8815 (100%)| 114.1 | 14.0/14.0 | 14.59x | 0.0
original speed avg. - 13.13666
optimized speed avg. - 14.57000
improvement (14.57-13.13)/13.13 = 0.10967
10.9% improvement on encoding aac with default settings
There's no need to put i686 and ffast-math on every single thing (no point in bash for example), but it's sure useful for some others...
|
|
arzajac
wrote on the 5 Mar 08 at 00:52
|
|
|
A lot of modern processors are not 686. The ViaC3 for example. I don't think the Via C5 is, either. That processor powers the Everex gOS computers sold at Walmart.
Bad idea.
|
|
fros1y
wrote on the 5 Mar 08 at 00:57
|
|
|
You've got to be very careful with this kind of benchmark. Clock timing may be totally unreliable, depending on what else is going on with the system. Running a command a second time may result in better times because of cache or random chance. If nothing else, this kind of testing requires repeated runs to calculate both any average improvement and to calculate confidence values for the average improvement.
Also, don't compare apples and oranges.. fast-math is an option that triggers non-IEEE 745, i.e. wrong, floating point.
|
|
|
> Running a command a second time may result in better times because of cache or random chance.
These 3 lines are 3 separate runs on the same file - they don't differ by more than 0.1 sec, so I'm not doing more.
-march=i686 then, without fast-math
frame | bitrate | elapsed/estim | play/CPU | ETA
8815/8815 (100%)| 114.1 | 15.2/15.2 | 13.48x | 0.0
8815/8815 (100%)| 114.1 | 15.1/15.1 | 13.52x | 0.0
8815/8815 (100%)| 114.1 | 15.1/15.1 | 13.51x | 0.0
I'm actually doing longer-running encoding and many tracks, so gain is much bigger for me than just 0.4s, or 1.5s - also that was only optimizing faac, not any other library that it uses - everything else is i386. I did it just to show, that yes - there is gain when you optimize for i686.
|
|
|
|
Unfortunately I believe asking the devs to maintain even the bigger packages in i386/i686 and 64 bit would be a bit much. Much more sensible to keep things going as is with 64 bit being the next optimization.
|
|
|
Audio and video encoding / decoding is one of the areas where CPU specific optimizations can be done successfully, but relatively difficult to do with a compiler. FAAC doesn't have any explicit vector ops that I've been able to find.
Do everyone a favor and investigate how much worse that encode is when you set march=i486 and mtune=i686 versus march=i686 mtune=i686.
Personally, I think that rebuilding the whole archive is unlikely to find massive improvements. Better to hunt down a few specific instances like the kernel, libc, and maybe some media encoding libraries that can use the vector ops boost.
|
|
johno
wrote on the 5 Mar 08 at 06:36
|
|
|
|
IIRC there used to be 686 kernel packages, but not anymore. Was the reasoning that the performance gains weren't there - even in the kernel?
|
|
sin
wrote on the 5 Mar 08 at 07:09
|
|
|
|
If you need performance, you can recompile your kernel and/or other software. Apt-build can help you a lot with the second one.
|
|
6205
wrote on the 5 Mar 08 at 07:25
|
|
|
|
I don't care if i get only 1% performance boost. First 686 CPU was Pentium Pro 150 Mhz back in 1995 and i think is time to move forward and to forget at stupid i386 compatibility.
|
|
|
Hm. on the other hand: If you guys want to have performance, why don't you set up the Ubuntu64 system on your Dual Core 2 CPU? Why bother with that "lame old" i686?
I think its right, if the performance boost is that small, better leave it at i386 to support guys with older hardware. And those who want performance, use 64bit systems...
|
|
vabue
wrote on the 5 Mar 08 at 08:56
|
|
|
I can't imagine guys who use latest desktop ubuntu on i486, i586. Have you seen a lot of pentiums with 256MB RAM, or 128?
OK, let's try to use Server version. I took JeOS in vmware, and made clean install + vmware tools + opensshd.
user@lampada:~$ free
total used free shared buffers cached
Mem: 255992 51440 204552 0 3492 33568
-/+ buffers/cache: 14380 241612
Swap: 409616 0 409616
So, the real minimum is 64MB. But we have to put there some services!
The same brainstorm idea: http://brainstorm.ubuntu.com/idea/1573/
|
|
tenshu
wrote on the 5 Mar 08 at 09:21
|
|
|
Ubuntu kernel il already 686 AND 386 that is why it is named "generic".
This issue has been already debate à year or 2 ago.
Please close this
|
|
|
> This issue has been already debate à year or 2 ago.
1. Please provide reference link.
2. 2 years (4 releases!) later it may be nice time to revisit the issue.
> If you guys want to have performance, why don't you set up the Ubuntu64 system on your Dual Core 2 CPU? Why bother with that "lame old" i686?
I haven't heard from one person that uses pentium I yet - so I say i686. Dual core and x64 is relatively new - upgrade is not an option for laptop users, that are still running fast 32b single cores - and those are the ones that could really use some optimizations.
Why would I prefer to run 32b on x64 arch is completely story...
|
|
|
Ubuntu 9.10 runs pathetically on a pentium II anyway on version 9.10. it runs horribly slow on my P4 too!
Actually, I have a dual motive for the migration to 686 to happen: Faster for many many processors, and my computer needs a 686 kernel or it won't see the hard drives. Ubuntu has been irritating due to the fact that only 64 bit fixes it, but I want full 32-bit compatibility! Many 64 bit libraries either don't exist or are buggy!
|
Post your comment
|
Ubuntuforums.org thread #437285
