Please fix your line wrapping. dm said on Wed, May 21, 2003 at 12:46:39AM -0500: > On Mon, 19 May 2003 13:33:41 -0700 Mark Ferlatte <ferlatte@cryptio.net> wrote: > > Yes. This comes up constantly. If you can demonstrate a repeatable > > improvement in end-user experienced speed by recompiling libc, then we'll be > > able to have a conversation. > Did you see that Debian Weekly News a while ago, about how libstdc++ now > compiles (by defualt, there are patches) to 486 and up? In addition, the > conversation that resulted showed that it was unclear and difficult at best > whether Debian could compile libstdc++ to 386 and remain compatable with > other distributions. Plus, it stated that there were significant benifits to > moving to 486. People really need to open up and move forward on this issue. Yes, I saw the discussion on -devel. There are significant benefits to moving to i486+, but they are more compatibility related than performance related. (ie, if every other distro requires the i486 locking instructions for C++ ABI, Debian better do it also). Sure, allowing the improved locking stuff helps too, but not that much, as far as I know. > I know some will say that recompiling only matters for performance critical > applications, and those are recompiled anyway, but almost everything depends > on libstdc++ and libc. And if these applications are mainly making library > calls, thier library calls will be unoptimized. Additionally, just becuase Just a guess, but I bet that most of the library calls are to str*, mem*, and malloc/free. All of those are heavily optimized, and probably won't gain anything from new CPU instructions. > someone is not running a statistical workstation that does not mean that > optimization will be lost on them. Even though I run a P3 800 mhz laptop > with 256mb of ram, gtk2 apps display kind of slow sometimes. I thought this > was becuase of my machine, but now I am starting to suspect that this could > be the optimization level too. I'd suspect that you're swapping... gtk2 apps tend to consume a lot of memory. > Are you running a 386? Nope. Pentium 1 and PowerPC here, P3 and P4 at work. > That Debian devel discussion also shows that very few, if anyone, uses a 386; > it also mentions that there were some 486 computers in wide spread use. I > feel Debian should compile to 586 and let the 386 and 486 users have a The i586 is pretty broken; compiling for it destroys performance for i686 and i486 CPUs. I'd expect that making a break at i486, and calling i386 a port would be best, but it's not up to me, since I'm not part of the project; I just use Debian, and submit patches. ;) > sub-project. It would not surprise me if most 486 computers could not run a > large percentage of Debian applications in any resonalble time frame. Why > should everyone else suffer becuase they cannot? Debian can still have a > smaller distro for them, while everyone else benifits from greater > optimization. You're not suffering because of them. At least, so far, nobody's proved that they are suffering because of them. You just _think_ you're suffering because the distro's built using the i386 instruction set, and optimizations. > One of the things that I like best about Debian is that the developers take > great care in maintaining compatability in areas that people would not care > or even know to think about. Yet, I feel that 386 (and most likely 486 as > well) definitely should and can go (or atlest move out of the way). And you're not a developer. > I see no reason why this conversation should not be had again, in fact it may > come up so often because something should be done here. So, here's a list of reasons why this is not as obvious appears (I'm sure there are more): * Compiler support: gcc has bugs. gcc CPU optimizers have bugs, and they are often subtle, and not well known, since most people don't use the CPU specific options. The i386 optimizer has been pretty well hashed out. Has the i686? The i586? The i486? * Where should the split be made? i686 eliminates a lot of useful hardware, i586 hurts i686 and i486 more than i386 does, i486 is probably okay, but doesn't gain as much as i686, but probably is necessary in order to maintain compatibilty with other Linuxes. * What about archive/mirror load? If you want to make the split, every package needs to be rebuilt. That's a lot of mirror traffic and disk usage. * What about upgrade path? * What about QA? And most importantly: * Who's going to do it? M
Attachment:
pgprfcx89cVkR.pgp
Description: PGP signature