Changes to lunar optimize

[Auke Kok]

On 09/26/2010 04:19 PM, Zbigniew Luszpinski wrote:
> Hello,
>
> here are my proposed changes to lunar optimize:
> -O3 Fastest
> *Move it to "Specialized optimizations" because it is not safe or fastest:
> *It is not true it is the fastest it _may_ _be_ faster or slower than -O2
> depending on code. So rename it to may be "slower/faster than -O2".
> Setting it distribution wide is dangerous. Firefox, Seamonkey, Thunderbird
> will compile well but crash on start with segmentation fault because -O3
> will enable -ftree-vectorize - silent runtime killer for C++ applications.
> -ftree-vectorize is silent and dangerous killer because:
> *it does not kill an application compiled with it but libraries on which
> it depends kill it. In case of mozilla apps you can build them with ftree-
> vectorize and they will work. Build zlib, jpeg, cairo and other libs
> mozilla use with -ftree-vectorize and they will cause mozilla apps crash
> on start.
> *You can rebuild lunar with it and it will compile and work but some C++
> applications will be crashing on start and you will have really hard task
> to find why they crash.
> * -O3 can cause the code to grow up insanely and eat memory and disk space
> like a crazy. This is one of the reasons making -O3 actually slower than -
> O2.
>
> Newbies will always choose -O3 because the fastest is better than faster -
> O2 and will end up with broken system.  Next they will leave Lunar with
> opinion too buggy to use.

why not just hide the option when "only show safe optimizations" is set? 
This is far more simple to implement and keeps the option in a logical 
location.

> cpu selection in safe mode should be limited to:
> -i686
> -native
> only. The first one is paranoid safe and slow, the second one is really
> safe and the fastest.

well, I'd argue that -i586 would be even safer than i686, but in reality 
the only safe optimization is -march=native or nothing else, and that's 
certainly acceptable. So lets (in safe mode) only show:

    ( ) none
    (x) native

> On Lunar general ML I presented a proof that shows native target is better
> than manually selecting CPU. If newbie will choose bad cpu broken system
> will be compiled.

a script will always know best :)

Also, in your POC your compiler isn't enabling -fpmath=... I wonder why, 
perhaps that's different per CPU whether it's worth it or not.

> linker:
> I would like to add these optional flags to speed up app loading:
> -Wl,--hash-style-gnu=both
> -Wl,--sort-common
> I have successfuly rebuilt lunar 1.6.5 32bit with KDE and mozilla using
> these flags so they are safe.

that's not sufficient proof that these flags are indeed safe...

However, I'd have no problems adding these to the non-safe list.


Auke