Gentoo Linux

[jurastublic]

Kolika je na kraju razlika u postocima u brzini izvođenja uobičajenih aplikacija koje su kompilirane s O2 i O3? (ne u brzini učitavanja). Znam da je Os najsporiji jer kad optimizira na manju veličinu, to ide na štetu brzine izvođenja ali ni to nije više od par posto. Toga se sjećam jer sam prije 10-tak godina kompilirao neki svoj programčić za ARM da stane u što manji ROM pa sam eksperimentirao s raznim optimizacijama ali nikad za velike aplikacije poput firefox i sl.

[shrike]

Koliko će se brže izvoditi ovisi i o samom programu. Ja sam jednom napisao niz programčića baš sa tim smislom i -O2 je bio najbrži. U usporedi bez korištenja optimizacija, -O2 je davao oko 100-200x bolje performanse. -Os s obzirom da optimizacijju radi za veličinu može ovo još zeznuti.

[posjeko_sam_drva]

Kolika je na kraju razlika u postocima u brzini izvođenja uobičajenih aplikacija koje su kompilirane s O2 i O3? (ne u brzini učitavanja). Znam da je Os najsporiji jer kad optimizira na manju veličinu, to ide na štetu brzine izvođenja ali ni to nije više od par posto. Toga se sjećam jer sam prije 10-tak godina kompilirao neki svoj programčić za ARM da stane u što manji ROM pa sam eksperimentirao s raznim optimizacijama ali nikad za velike aplikacije poput firefox i sl.

-Os ne optimizara za manju veličinu ništa više nego -O2, on samo isključuje optimizacije koje utječu na veličinu
jer -O2 je isto što i -Os samo uz dodatak nekih optimizacijskih opcija koje uvečavaju kod. (i O2 i O3 u sebi sadrze sve sto ima Os)
Tako da ovisi o programu, koliko on koristi i kako memoriju kad je jednom pokrenut.
Što u principu znači da je za svaku veču aplikaciju poput firefox uvijek bolje koristiti -Os pa manualno mu dodati neke optimizacije iz -O2 kolekcije, ovisi koje mu trebaju tj kakav je program.
I LDFLAGOVI mogu jako puno pomoći

http://forums.gentoo.org/viewtopic-t-79 ... art-0.html

autor je zaboravio na custom-cflags useflag bez kojeg mu to ništa ne vrijedi pa uzmite u obzir ako optimizirate sa portage

[jurastublic]

-Os ne optimizara za manju veličinu ništa više nego -O2, on samo isključuje optimizacije koje utječu na veličinu jer -O2 je isto što i -Os samo uz dodatak nekih optimizacijskih opcija koje uvečavaju kod.

Ova izjava je kontradiktorna.

Tako da ovisi o programu, koliko on koristi i kako memoriju kad je jednom pokrenut.

Svakako.

[posjeko_sam_drva]

Želio sam reči da ti je isto koristio Os + x, jer x je razlika između O2 i Os, ili O2
Tj kad koristiš O2 zapravo koristiš Os + dodatke koji čine O2 od kojih ti nisu svi potrebni, tako da je Os + x uvijek bolje riješenje ako dobro odabereš što češ staviti pod x

[shrike]

Ovakoc, ne širiti dezinformacije. Ako pogledamo recimo http://www.phoronix.com/scan.php?page=a ... ions&num=1 testove optimizacija, uočit ćemo kako je -Os konzistentno sporiji od ostalih (osim O1), te da je najbrži Ofast. Sa time da je razlika između Os i O2 zapravo ta da se iz O2 maknu stvari koje povećavaju kod i dodaju one koje ga smanjuju. Drugim rječima, općenito govoreći O2, O3 i Ofast daju bolje rezultate u skoro svim slučajevima od Os. Phoronix testovi se slažu i sa mojim osobnim testovima, što znači da je svaka daljnja diskusija bez testova koji bi ju poduprli čisto trolanje.

[posjeko_sam_drva]

Sve to stoji ali ignoriraš x koji dolazi nakon Os
tj Os + x
jer O2 sadrži optimizacije koje su namjenjene globalnu i niti jedan program nije optimiziran sa O2 kako bi mogao biti
najbolji rezultati se uvijek postižu kad staviš Os + samo neke dodatke (optimizacije iz O2 ili čak one iz O3) koje programu mogu pomoći u radu.
Prouči man GCC i online dokumentaciju
To nisu dezinformacije, tako se optimizira za najbolja riješenja, ove informacije koje ti daješ su defaulti i ne nose nikad najbolju optimizaciju
O2 i O3 nisu optimizacijske opcije u pravom smislu riječi, to su opcije za ljude kojima se ne da optimizirati da dobe na gotovo što bolja riješenja
Sve su to kao i Os kolekcije optimizacijskih opcija, optimizacijaka opcija je npr: -findirect-inlining i spada u O2 kolekciju
(Zasto bi ja koristio cijeli O2 ako programu treba samo ta i jos neke opcije, zato cu koristiti:
-Os -findirect-inlining -.... ili -fno- ako neku iz Os kolekcije ne želim)

Uglavnom "Optimizacija" i "Fine-tunning optimizacija" su dvije razlicite stvari, jedno je default sa zlatnom sredinom između stabilnosti i optimizacija, zato se koriste gotove kolekcije optimizacija.

[shrike]

U redu, daj neke konkretne primjere realističnog koda koji će se izvršavati sporije od -Ofast, a koji su optimizirani sa -Os + x. Ako to nisi u stanju napraviti, po defaultu smatrma da nisi u pravu.

[posjeko_sam_drva]

Jesi li ti svijestan uopče šta me tražiš ?
Idi isto pitanje postavi na gcc irc pa če te banirati i reči da proučiš man gcc
nema primjera jer ne postoji default, ne ovisi samo o samom programu več i količini dostupne memorije, instrukcijama procesora, kernelu i OSu, o svemu...
Šta misliš da su developeri firefoxa koristili neki O2 za svoj binary ? Čak i oni nisu znali konkretne primjere optimizacije pa su rekompajlirali iz nova sto puta i testirali aplikaciju dok nisu postigli najbolje performanse
I da ti dam neki primjer, to je primjer samo za mene i za tebe i tvoj slučaj neče biti najoptimiziraniji, naprotiv može ti uništiti aplikaciju

Odustanimo od ove rasprave, nema veze ko je u krivu nek sam i ja
ako neko bude kompajlirao sam če si odličiti što mu je najbolje neče sigurno slušati mene i tebe jer defualti ne postoje kad ovisi doslovno o svemu

[max360se]

Moze li netko molim vas pobrisati dezinformacije koje je drvosjeca sirio?


Samo jedna objest koja je ocito stara tjedan dana pa ako u medjuvremenu niste radili update dobro je znati.

2013-11-07-python-exec-package-move
Title python-exec package move
Author MichaŠGórny <mgorny@gentoo.org>
Posted 2013-11-07
Revision 1

Due to the recent issues which caused dev-python/python-exec:0 to be
removed prematurely [1], we had to perform an urgent package move.
Since we could not use the automatic updates support in portage, users
will notice two python-exec packages and possibly blockers.

Currently, dev-lang/python-exec is the real package that contains
python-exec and that will be used in the future. dev-python/python-exec
is a virtual package that is kept for compatibility with dependencies
in already-installed packages.

In the most favorable scenario, the package will be upgraded correctly
on your next world update if you use the '--deep' (-D) and '--update'
(-u) options. If you don't want to perform a complete world update
or if it fails for you, you may as well manually upgrade
dev-python/python-exec:

emerge -1 dev-python/python-exec

This will cause portage to update both python-exec packages and resolve
the blockers properly.

Please note that if you have applied any kind of package-specific
modifications to dev-python/python-exec (such as applying keywords
through 'package.accept_keywords'), you will need to copy them to
dev-lang/python-exec as well.

If you have applied keywords to dev-python/python-exec in order
to unmask Python 3.3 on a stable system, please consider removing
the keywords and reading our wiki page that explains how to properly
unmask USE flags [2].

We apologize for all the inconveniences. If you have any more issues
with python-exec, please do not hesitate to contact as at #gentoo-python
IRC channel (@freenode) or the gentoo-python@lists.gentoo.org mailing
list.

[1]:https://bugs.gentoo.org/show_bug.cgi?id=489440
[2]:https://wiki.gentoo.org/wiki/Unmasking_ ... mentations