[LAD] vectorization

[Jens M Andreasen]

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
> 
> 
--