[Fli4l_dev] [fli4l-3.9.0-rev28716] -Os vs. -O2

[Christoph Schulz]

Hallo!

Bernd Kuhls schrieb:

> Hallo,
> 
> im aktuellen tarball wird, statt wie bisher -Os, nun -O2 als gcc-Option
> genutzt:

So ist es. Siehe Commit-Kommentar zu r28565:

buildroot changes:
- EXPERIMENTAL: using optimization level -O2 (optimize for speed) instead of 
-Os (optimize for size)
[...]

> [...]
> Dadurch werden die erstellten binaries größer, das base-Paket z.B. wuchs
> von 24,9MB auf 27,8MB, /usr/lib/xbmc/xbmc.bin von 12,2MB auf 17MB.

Das wäre eine Erhöhung um knapp 12% im base-Paket. Wenn es 30% oder mehr 
wären, könnte man darüber meckern, aber 12%? Dass xbmc um einiges fetter 
wird, ist bedauerlich, aber siehe auch unten.

> Beim Kompilieren des src-Pakets habe ich testweise wieder BR2_OPTIMIZE_S=y
> aktiviert, dabei bin ich auf einen gcc-Fehler gestoßen, der mit -Os
> auftritt: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58864
> 
> Ist das der Grund, warum -O2 im fbr aktiviert wurde und soll das dauerhaft
> so bleiben, auch wenn bug 58864 behoben wurde?

Das ist nicht der Grund, und bei mir ist der Fehler auch nicht aufgetreten. 
Allerdings habe ich die Umstellung durchgeführt, bevor wir auf 2013.11-rc1 
umgestiegen und somit noch gcc 4.8.1 (und nicht gcc 4.8.2) genutzt haben. 
Vielleicht macht das den entscheidenden Unterschied aus. (2013.11-rc1/2 ist 
noch nicht in den testing-Tarballs, bitte dazu FFL-658 verfolgen.)

Warum ist es ein Problem, wenn die Binarys etwas größer werden? Die 
Umstellung ist zwar experimentell, aber sollte sich auf dem Typ Maschine, 
der heute für fli4l eingesetzt wird, i.d.R. positiv auf die Geschwindigkeit 
auswirken. Bislang sind jedenfalls keine fühlbaren Verschlechterungen auf 
langsamen Rechnern mit kleinem Cache vom Typ WRAP, Soekris etc. aufgetreten. 
Das Bootmedium Floppy-Disk ist ohnehin tot, und USB-Sticks kümmert es nicht, 
ob 5 MiB mehr oder weniger verwendet werden. Klar, der Speicherverbrauch 
steigt an, aber fli4l-Router mit 16 MiB RAM o.ä. werden ohnehin nicht mehr 
unterstützt -- wir fordern inzwischen mindestens 64 MiB. Und eine Anwendung 
wie dein xbmc läuft sicherlich auch mit -Os nicht gut auf einem 64 MiB-
System.

Das soll natürlich nicht heißen, dass wir bei entsprechendem Feedback die 
Einstellung nicht zurückdrehen könnten. Aber dafür müssen erst einmal 
handfeste Argumente auf den Tisch. Und zwar welche, die sich an der 
aktuellen Hardware-Situation orientieren und nicht an Uralt-fli4ls (i486, 16 
MiB RAM).


Viele Grüße,
-- 
Christoph Schulz
[fli4l-Team]