Ubuntu i686 idea

[ekerazha]

And if you notice, there is no difference (or, actually from the figures given, a regression) between Ubuntu-386 kernel & Ubuntu-686 kernel. So the difference between Arch & Ubuntu speed must be more complicated than just -march=686.

Just for the record, Ubuntu pakcages (those which aren't specifically processor-tuned) are build without -march=386 and with -mtune=pentium4, for what it's worth.

Yeah... the difference is that Arch is all i686 compiled, not only the kernel and -mtune=pentium4 (if what you say is true) doesn't optimize much for amd CPUs.

[suoko]

One easy question:

if apt-build worked, would it be difficult to do an "apt-build world" on a PIV pc to create ubuntu packages optimized for 686 and then do the same on an Athlon pc to create ubuntu packages optimized for k7 (after having set apt-build accordingly)?

One difficult question:

is there a chance to create a bittorrent-based repository for the above mentioned 686 and k7 packages so that I don't need super fast ftp servers to share them?

Gabriele

[RAOF]

Yeah... the difference is that Arch is all i686 compiled, not only the kernel and -mtune=pentium4 (if what you say is true) doesn't optimize much for amd CPUs.

Don't take my word for it - try apt-get source. The debian/rules file will have the compile options.

As for arch: The Ubuntu kernel gets slower (in that test) going from standard to -686. So compiling everything for 686 makes things somehow magically faster? Given how many variables there are changing between Arch & Ubuntu, you really can't make any statement that "-march=686" would speed things up.

Of course, you could make that statement, with a bit of effort: apt-build world to build your very own Ubuntu, with the only difference being the compile options. Run the same benchmark. Then we can say "-march=686 provides foo% performance benefit".

[vivekR]

Like most benchmarks, (and statistical data) there are more than 1 way to read the results

1) We acknowledge that ArchLinux is FASTER than ubuntu for some of the very basic tasks.
2) We say that there is NO major difference between the averge of the benchmarks tests on ubuntu386, and ubuntu686, so we shut our eyes, continue to build 386 packages, and ignore the fact that new and small distributions such as ArchLinux are getting ahead of our much hyped, agressively promoted, financially backed and much beloved Ubuntu.

I dont understand the problem in having a 686 optimized repository, looks like most of us would like to use it, if such a thing existed. See http://ubuntuforums.org/showthread.p...&highlight=386 - 82% people supported the idea of having 686 optimized packages.

Those convinced that this doesnt bring any benefits may continue to use 386 packages like before. (but why oppose having 686 packages?)

Any Ideas/pointers on how to actually build 686 optimized packages for Ubuntu/Debian? I tried apt-build, but it didnt work for me. (no -mcpu=i686 was passed to gcc)

[23meg]

I dont understand the problem in having a 686 optimized repository, looks like most of us would like to use it, if such a thing existed. See http://ubuntuforums.org/showthread.p...&highlight=386 - 82% people supported the idea of having 686 optimized packages.

This may very well mean that 82% of the people who voted weren't well informed about this matter and just swallowed the "I want to get the most out of my computer" bait presented tastily in the poll options.

(but why oppose having 686 packages?)

Because of the weight of extra bugspotting and support it would put on the shoulders of the testers and developers which would slow down Ubuntu development and which doesn't justify the insignificiant benefits.

You want to do this as an unofficial project, setting up repos and preparing step by step guides? Or as an Ubuntu derivative? You have your own crew and resources? Go ahead and do it. Just don't ask for it to be official.

[vivekR]

This may very well mean that 82% of the people who voted weren't well informed about this matter and just swallowed the "I want to get the most out of my computer" bait presented tastily in the poll options.

Yes, it may.

Maybe, 99 of the 121 people who cared to vote for the 686 and K7 optimzed packages were the uninformed ones, and the 17 who did not need optimized packages were indeed the enlightened ones.

Or, maybe some of them have played around with some other distributions and have experienced some good things (speed, for example) that they would also like to see in Ubuntu, and the 17 others have not had an obejective and unbiased look at some of the non-debian distributions lately.

Maybe we should conduct a much better worded poll on this matter? (perhaps you would like it to say, "I would like to use 386 optimized code even on my latest processor, as 686 and other such optimizations do not bring any benefits?")

Because of the weight of extra bugspotting and support it would put on the shoulders of the testers and developers which would slow down Ubuntu development and which doesn't justify the insignificiant benefits.

As far as I know, we are NOT talking about having different source trees for 386 and 686 here. We are talking about having a new repository of packages with the SAME SOURCES built and optimized for 686.

I can understand that there would be overhead involved in having new set of build scripts, and repositories. (I was told debian has build servers on which packages are created by the scripts when new sources are submitted by the maintainers?) But, I dont see why software which is functionally the same would need extra support and bugspotting.

And I also fail to see how does this slow down ubuntu? if anything, such a step would attract some of ArchLinux and Gentoo users towards Ubuntu. You get some very keen and "performance-minded" testers.

You want to do this as an unofficial project, setting up repos and preparing step by step guides? Or as an Ubuntu derivative? You have your own crew and resources? Go ahead and do it.

Err.. I, like many people, would like to have 686 optimized packages. There is also a launchpad project for this idea: https://wiki.ubuntu.com/ubuntu-i686

Best option for us - we have Official Ubuntu repositories for this.

2nd best option - (If Ubuntu developers are totally opposed to having such repositories).. Some of us get together, and we can create such scripts, and build + share such packages with others. We can start with a small subset of packages.

3rd best option: Say goodbye to Ubuntu, move to Arch Linux or some such distro.

I was trying to at least build some packages using apt-build, but have been struggling so far. (does not build with the expected compiler flags)

Just don't ask for it to be official.

OK sorry. My fault. I must have missed reading those sections of forum rules which forbid this.

[23meg]

Yes, it may.

Maybe, 99 of the 121 people who cared to vote for the 686 and K7 optimzed packages were the uninformed ones, and the 17 who did not need optimized packages were indeed the enlightened ones.

Right, based on what I know and the discussion at hand, that's more or less what I'm saying, though I'd rather avoid the terms "uninformed" and "enlightened".

Maybe we should conduct a much better worded poll on this matter? (perhaps you would like it to say, "I would like to use 386 optimized code even on my latest processor, as 686 and other such optimizations do not bring any benefits?")

You're right, that would be nice, especially with an opening post that has a benchmark comparison and some basic dumbed down computer science theory on the matter.

As far as I know, we are NOT talking about having different source trees for 386 and 686 here. We are talking about having a new repository of packages with the SAME SOURCES built and optimized for 686.

I can understand that there would be overhead involved in having new set of build scripts, and repositories. (I was told debian has build servers on which packages are created by the scripts when new sources are submitted by the maintainers?) But, I dont see why software which is functionally the same would need extra support and bugspotting.

Did you actually read the poll thread? Please read again if you only scanned through it; there are some very informative posts that explain why the overhead won't justify the benefits there, as well as elsewhere on the forums where the same matter was discussed many times.

And I also fail to see how does this slow down ubuntu? if anything, such a step would attract some of ArchLinux and Gentoo users towards Ubuntu. You get some very keen and "performance-minded" testers.

What do you think slows down distros that support lots of architechtures such as Debian? Same goes here; more archs, more support load. Again refer to the poll thread for specifics which have already been covered. Agreed about testers but I don't see it as a big benefit.

2nd best option - (If Ubuntu developers are totally opposed to having such repositories).. Some of us get together, and we can create such scripts, and build + share such packages with others. We can start with a small subset of packages.

I see this as your best option. Projects such as Kubuntu that are official today actually began as community efforts, and then matured to a point where they got enough interest from the official folks and became official. I say go ahead and experiment with this and report your findings in solid, measured benchmarks; if all goes as you expect, you'll get official attention.

OK sorry. My fault. I must have missed reading those sections of forum rules which forbid this.

No need for drama; I'm barely stating my stance here. I feel people who want changes with possible impacts as big as this should step out and have a go at making those changes themselves to prove their point first rather than asking for top-down official development and support. You have all you need; what's holding you? Make a 686 Ubuntu derivative and distribute it, get it tested, see the reactions. Or set up some repos with 686 optimized packages that replace the 386 ones and see where you can get with that.

[LordHunter317]

Anyone who thinks the page vivekR posted is useful is crazy. Bad math abounds on that page (because the benchmark does it), and the data presented is inconsistent enough in behavior to be questionable. One must question the data before drawing inferences from it, and the data presented simply does not make any sense.

[ekerazha]

As for arch: The Ubuntu kernel gets slower (in that test) going from standard to -686. So compiling everything for 686 makes things somehow magically faster? Given how many variables there are changing between Arch & Ubuntu, you really can't make any statement that "-march=686" would speed things up.

Maybe a 686 kernel doesn't offer much when every other thing is 386 compiled.
Maybe Ubuntu kernel isn't very optimized.

[matt_hargett]

There are definitely some apps that this can help on, including the kernel -- but it takes more than mtune/mcpu to get the maximum benefit.

First, newer instructions can help reduce the size of the binary if -Os is used instead of -O2. (Newer kernels have an option that uses -Os instead of -O2 during compile, also.) Extra registers enabled via -mmmx and -msse can also help increase performance by avoiding pointer dereference operations.

The biggest help (even on i386 pkgs) would be to generate a runtime profile via -fprofile-generate, enabling usage of -freorder-blocks and -freorder-functions options.

<slightly offtopic>
None of these would make support any more difficult than it already is since the existing binary packages mostly produce useless stack traces as-is. If another repo were to be made, I would greatly prefer once that packaged more debuggable libraries. I'm not sure how they were planning to support this distro long term without this being the case.