On Thu, 2008-04-17 at 16:14 +0200, Fernando Lopez-Lezcano wrote: > You mean _complete_ binaries? All of the executable replicated several > times with different optimizations inside the package? So your intention > is not to optimize selected portions of the program, but _all_ of it??
No, plase be reasonable :-) One of the original source files holds the inner, hopefully vectorizable loops that eats cpu and may or may not contain ugly kludges to get around the denormals problem unavoidable in cpu's before sse2. > > And place the decision logic for which to use in pre and post install > scripts?? Yes please! (pretty please?) I would naively think that the package consists of object files with say engine.o in several versions. main.o userinterface.o networking.o ... engine.o.586 # plain C, runs everywhere but probably pretty terrible engine.o.sse # vectorized but has some kludges engine.o.sse2 # vectorized and no kludges, works for AMD, recomended! The pre-install script then looks in /proc/cpuinfo and decides which engine to rename to engine.o, links the objects in a jiffy, strips the binary and continues installation. > A downgrade would not affect a current linux system, the kernel > would just load the proper modules for the new hardware and run without > problems. All programs I know of would adjust themselves if necessary. > This might be because you have the least desireable versions of the programs? My all-singing-all-dancing kernel is at least three times bigger than older kernels. This without counting any modules. And it takes forever to figure out that nothing new has happened since last reboot :-| Distributions like Linux-from-Scratch do things differently. Which brings us back to the gunzip/configure/compile/install way of doing things Christian suggested from the start ... I must admit that I hate 'configure' myself. It is darned slow and checks for a lot of stuff that is senseless when you already know the target, and then it most likely just arrives at a decision that some obscure library is missing. Rinse, repeat ... A partially rpm based distribution could at least tell us to install KDE first and automagically do that before continuing to install stuff that depends on that environment. > Why do you think I, as a packager, will have access to all the possible > hardware? Nobody does. I don't. Good question. Who has the hardware and is willing to spend time on compiling and testing other peoples projects? Who would gain anything from this except for the end user? I suppose he/she then is the one to do the lifting, except that he/she probably won't have the guts to up the optimiser to insane levels, nor the experience to verify that the application did not break ... Also it is a lot of wasted time. Some kind of 'man in the middle' would be nice to have around, which is why people are looking at you :-) > > [why did you take the thread off the list?] I did not intend to, it was send TO: me, so the reply-to-list option (ctrl-L) was disabled. It is first now that you mention it that I realize that you also CC'ed the list. Putting it back now :-) > -- Fernando > > -- _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
