# [Sys-Devel] GCC 4.0.0

## Dawid159

Witam  :Smile: 

Hmm co o tym sądzicie, warto przekomipolwać tym system  :Wink:  Może ktoś korzystał z wersji testowych i wie jak to się sprawuje  :Wink: 

Pozdrawiam

Dawid

----------

## nelchael

Nie radze tego robic - zobacz https://forums.gentoo.org/viewtopic-t-176085.html

----------

## OBenY

Nelchael: wez po krotce powiedz czemu, tego watku sie nie da przeczytac, zdeczka za dlugi jest ...

----------

## Crenshaw

Tak z innej beczki... gcc ma w koncu wektoryzacje  :Smile:  NIICE  :Smile:  Jak bedzie mi sie chcialo to pomierze jak wypada wydajnosc w stosunku do np. pgcc

----------

## wojtek

 *Crenshaw wrote:*   

> Tak z innej beczki... gcc ma w koncu wektoryzacje  NIICE  Jak bedzie mi sie chcialo to pomierze jak wypada wydajnosc w stosunku do np. pgcc

 

To ten projekt jeszcze sie rozwija?? Mam wrazenie, ze to juz jest dawno i nieprawda...

A propos gcc 4.0, nie mam sensu, na dzien dzisiejszy, przekompilowywanie calego systemu za jego pomoca chocby z jednej prostej przyczyny - nie wszytsko sie skompiluje (z mojej praktyki wynika raczej, ze wiele sie nie skompiluje). Ma natomist sens zainstalowanie go obok dotychczasowego kompilatora i testowanie oraz wysylanie bugreportow co dziala a co nie - to pomoze przyspieszyc jego pojawienie sie w testowej/stabilnej wersji.

----------

## Crenshaw

 *wojtek wrote:*   

>  *Crenshaw wrote:*   Tak z innej beczki... gcc ma w koncu wektoryzacje  NIICE  Jak bedzie mi sie chcialo to pomierze jak wypada wydajnosc w stosunku do np. pgcc 
> 
> To ten projekt jeszcze sie rozwija?? Mam wrazenie, ze to juz jest dawno i nieprawda...
> 
> 

 

Nie wiem czy mowimy o tym samym, mi chodzi o to http://www.pgroup.com/

 *wojtek wrote:*   

> 
> 
> A propos gcc 4.0, nie mam sensu, na dzien dzisiejszy, przekompilowywanie calego systemu za jego pomoca chocby z jednej prostej przyczyny - nie wszytsko sie skompiluje (z mojej praktyki wynika raczej, ze wiele sie nie skompiluje). Ma natomist sens zainstalowanie go obok dotychczasowego kompilatora i testowanie oraz wysylanie bugreportow co dziala a co nie - to pomoze przyspieszyc jego pojawienie sie w testowej/stabilnej wersji.

 

Zgadzam sie ze systemu nie. Ale programow do number crunching tak.

L

----------

## arsen

To przypomina sytuację kiedy wychodziło gcc 3.4.0, połowa rzeczy się nie kompilowała, masa patchy w samych ebuildach, następnie wiele poprawek robione już przez osoby rozwijające dany program, trwało to kawał czasu zanim gcc z seri 3.4.x zaczeło być używalne, i czas w którym można było cały system na nim zbudować,  tu sprawa może wyglądać podobnie, ja bym radził studzić puki co zapały, te gcc nawet nie jest suportowane przez gentoo, w portage jest bo jest, nie zawiera nawet ssp i pie.

----------

## Dawid159

Czyli zrobie sobie backup systemu i będe się bawić i sprawdzać co da się skompilować  :Wink:  gcc już się kompiluje  :Wink:  Zobaczymy co z tego będzie.

----------

## wojtek

 *Crenshaw wrote:*   

> Nie wiem czy mowimy o tym samym, mi chodzi o to http://www.pgroup.com/

 

Myslalem, ze chodzi Ci o http://www.goof.com/pcg/  :Smile: .

Wojtek

----------

## Poe

Mam od jakiegos czasu juz gcc400 skompilowane (z miesiąc, półtora), ale jakos nie mam czasu na zabawe z nim  :Wink:  ale widze, ze chba trzeba bedzie sie zabrac za to  :Smile: 

----------

## rzezioo

hmmm... zalezy do czego ty masz ten swoj system:) desktopu bym tym raczej nie kompilowal bo ci sie moze cos posypac. jesli masz cos nim kompilowac to raczej system na x86 postawiony TYLKO w celu sprawdzenia kompilatora ktory na razie jest w wersjii beta

----------

## Poe

eeee... czy mi sie wydaje, czy gcc400 stable jest  :Neutral: 

```
root@failed> emerge -puD world                                     /usr/portage

These are the packages that I would merge, in order:

Calculating world dependencies ...done!

[ebuild     U ] sys-devel/gcc-4.0.0 [4.0.0_beta20050416] 

[ebuild     U ] sys-libs/glibc-2.3.5 [2.3.4.20050125-r1] 

[ebuild     U ] media-libs/xine-lib-1.0-r3 [1.0-r1] 

[ebuild     U ] sys-devel/gdb-6.3-r1 [6.3] 

[ebuild     U ] app-text/ghostscript-7.07.1-r9 [7.07.1-r8] 

[ebuild     U ] media-video/ffmpeg-0.4.9_p20050226-r4 [0.4.9_p20050226-r3] 

```

----------

## Dawid159

Kompilator sam po sobie jest stable dlatego założyłem temat  :Smile:  Myślałem, że wiecie o tym hehe  :Smile:  Pisali o tym np. tutaj Poe widzę, że masz bete zaintalowaną, jak się sprawuje  :Question:  Kompilowałeś coś poważnego nią  :Question: 

----------

## Poe

Heh, nie wiecie  :Wink: 

nie, nie mialem kiedy sie bawic gcc400 ijedyne co kompilowalem tą betą to bylo kadu (nie dokladnie tą wersją, jakies 3-4 wersje w tyl) ale skoro jest juz stable, zobaczymy, moze skompiluje firefoksa, zobacze jak mi czas pozwoli.. egzaminu we wtorek i srode do liceum :'\

----------

## rasheed

Czy takie "stable stable" to ja nie wiem  :Wink:  Wiele progsów się nie kompiluje, zaczyna się "wielkie łatanie".

Zresztą samo gcc 4.0.0 jest *-

----------

## Thindil

Z tego co wiem, na gcc 4.0 nie da się skompilować ponoć KDE - błąd jest już zgłoszony do odpowiedzialnych  :Wink:  ale według ich słów, odpowiednia poprawka pojawi sie dopiero w wersji 4.0.1 czy jakoś tak. Są już wprawdzie patche, ale trzeba je poszukać samodzielnie - dlatego na dzień dzisiejszy gcc 4.0 nadaje się jedynie na generator błędów do bugtracka a nie do normalnego użycia  :Wink: 

----------

## rasheed

 *Thindil wrote:*   

> Z tego co wiem, na gcc 4.0 nie da się skompilować ponoć KDE - błąd jest już zgłoszony do odpowiedzialnych  ale według ich słów, odpowiednia poprawka pojawi sie dopiero w wersji 4.0.1 czy jakoś tak. Są już wprawdzie patche, ale trzeba je poszukać samodzielnie - dlatego na dzień dzisiejszy gcc 4.0 nadaje się jedynie na generator błędów do bugtracka a nie do normalnego użycia 

 

Kdelibs jak i samo qt (a i nawet xorg) się kompilują, gorzej z kdebase. U mnie siadło przy kwirte.

----------

## Rumil

 *rasheed wrote:*   

> 
> 
> Kdelibs jak i samo qt (a i nawet xorg) się kompilują, gorzej z kdebase. U mnie siadło przy kwirte.

 

QT i KDElibs przed chwila sie skonczylo kompilowac - wyglada ze dziala ok.

Firefox z latka od Fedory dziala jak najbardziej ok, nie zauwazylem zeby dzialal szybciej.

Zaraz wezme sie za xorga.  :Smile: 

A co do kwrite to mi sie nie kompilowalo nawet na gcc-3.4.3  :Neutral: 

Jak juz ktos chce kompilowac kde gcc-4.0.0 to radze nalozyc wczesniej tego patcha: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20973 .

Poza tym Fedora jest teraz cala kompilowana gcc4, wiec jakby cos sie nei chcialo skompilowc to mozna skorzystac z ich patchy.

EDIT:

Jednak mam problem z libkhtml.so, konqueror (ale nie menadzer plikow, tlyko przegladarka internetowa) nie dziala. Sprobuje jeszcze raz spaczowac gcc (moze cos zle zrobilem ostatnio  :Wink:  ) i jeszcze raz przekompilowac kdelibs.

----------

## keman

Skoro mówisz, że nie zauważyłes wzrostu wydajności, a masz czasami problemy z kompilacją czegoś tam, to ja jeszcze niebęde się w nowe gcc pchał...

Zaczekam aż uzyska status bardziej stabilnego :] ...

BTW rekompilacja systemu może troche potrwac, i tu nasuwa się pytanie, czy wogle warto...

Czasowo to tak samo, jakby zainstalowac nowy system (tym bardziej, że ostatnio wyrzuciłem swoje distfiles :/ )...

Pozdrawiam, waluigi

----------

## Poe

firefox sie nie skompilowal, wywalil sie po dluzszym czasie kompilacji (juz chyba po 2h), utelnetd od razu sie wywalil. coz, gcc400 nie nadaje sie do powszechnoego uzytku

----------

## rasheed

 *Poe wrote:*   

> firefox sie nie skompilowal, wywalil sie po dluzszym czasie kompilacji (juz chyba po 2h)

 

Na b.g.o masz patche, z nimi działa (u mnie ZDECYDOWANIE szybciej).

----------

## Poe

 *rasheed wrote:*   

>  *Poe wrote:*   firefox sie nie skompilowal, wywalil sie po dluzszym czasie kompilacji (juz chyba po 2h) 
> 
> Na b.g.o masz patche, z nimi działa (u mnie ZDECYDOWANIE szybciej).

 

mozliwe, ja chcialem zobaczyc jak dziala 'stable' gcc400 z portage bez zadnych patchow dodatkowych, i std gcc400 jeszcze nie jest do uzytku.

----------

## wojtek

Wszystkim eksperymentujacym z GCC 4.0 polecam pod rozwage ten post.

----------

## OBenY

Wlasnie robie male testy wydajnosciowe, zaraz opublikuje wyniki  :Smile: 

EDIT: wyniki testow, wrazenia i interpretacje zostawiam Wam, ja sie zawiodlem  :Sad: 

```
   4.0 test.c (gcc 7508 ; g++ 7612) size

bzip2   (86728) size

   bzip2 -d binutils-2.15.92.0.2.tar.bz2  6,30s user 0,19s system 82% cpu 7,853 total

   bzip2 -d binutils-2.15.92.0.2.tar.bz2  6,34s user 0,21s system 99% cpu 6,555 total

   bzip2 -d binutils-2.15.92.0.2.tar.bz2  6,33s user 0,23s system 99% cpu 6,556 total

   bzip2 -d binutils-2.15.92.0.2.tar.bz2  6,29s user 0,18s system 99% cpu 6,475 total

   bzip2 --best binutils-2.15.92.0.2.tar  26,19s user 0,12s system 99% cpu 26,315 total

   bzip2 --best binutils-2.15.92.0.2.tar  26,28s user 0,13s system 99% cpu 26,413 total

   bzip2 --best binutils-2.15.92.0.2.tar  26,44s user 0,18s system 99% cpu 26,627 total

   bzip2 --best binutils-2.15.92.0.2.tar  26,36s user 0,20s system 100% cpu 26,560 total

gzip   (52012) size

   gzip -d VMware-workstation-5.0.0-13124.tar.gz  1,78s user 0,37s system 100% cpu 2,152 total

   gzip -d VMware-workstation-5.0.0-13124.tar.gz  1,76s user 0,42s system 99% cpu 2,179 total

   gzip -d VMware-workstation-5.0.0-13124.tar.gz  1,77s user 0,41s system 99% cpu 2,178 total

   gzip -d VMware-workstation-5.0.0-13124.tar.gz  1,78s user 0,39s system 99% cpu 2,177 total

   gzip --best VMware-workstation-5.0.0-13124.tar  37,37s user 0,43s system 99% cpu 37,825 total

   gzip --best VMware-workstation-5.0.0-13124.tar  37,35s user 0,43s system 94% cpu 40,014 total

   gzip --best VMware-workstation-5.0.0-13124.tar  37,22s user 0,38s system 97% cpu 38,558 total

   gzip --best VMware-workstation-5.0.0-13124.tar  37,35s user 0,39s system 99% cpu 37,776 total

tar   (190444) size

   tar xf binutils-2.15.92.0.2.tar  0,05s user 0,98s system 76% cpu 1,354 total

   tar xf binutils-2.15.92.0.2.tar  0,05s user 0,99s system 99% cpu 1,044 total

   tar xf binutils-2.15.92.0.2.tar  0,04s user 0,97s system 98% cpu 1,028 total

   tar xf binutils-2.15.92.0.2.tar  0,05s user 1,00s system 99% cpu 1,054 total

oggenc   (9864 oggdec ; 47960 oggenc) size

   oggdec 02-Hours\ Passed\ In\ Exile.ogg  3,82s user 0,25s system 99% cpu 4,070 total

   oggdec 02-Hours\ Passed\ In\ Exile.ogg  3,77s user 0,29s system 99% cpu 4,064 total

   oggdec 02-Hours\ Passed\ In\ Exile.ogg  3,80s user 0,23s system 99% cpu 4,040 total

   oggdec 02-Hours\ Passed\ In\ Exile.ogg  3,79s user 0,26s system 99% cpu 4,055 total

   

   oggenc 02-Hours\ Passed\ In\ Exile.wav  23,16s user 0,09s system 99% cpu 23,309 total

   oggenc 02-Hours\ Passed\ In\ Exile.wav  23,21s user 0,10s system 99% cpu 23,313 total

   oggenc 02-Hours\ Passed\ In\ Exile.wav  23,19s user 0,09s system 99% cpu 23,290 total

   oggenc 02-Hours\ Passed\ In\ Exile.wav  23,02s user 0,05s system 99% cpu 23,073 total

kadu   (1504064) size

   7,28 1,47

   7,02 1,64

   6,84 1,51

xmms   (996504)

   2,03 0,86

   2,10 0,72

   2,83 0,98

   -====================================================-

   3.4.3 test.c (gcc 7662 ; g++ 7766) size

bzip2   (86728) size

   bzip2 -d binutils-2.15.92.0.2.tar.bz2  6,82s user 0,21s system 99% cpu 7,071 total

   bzip2 -d binutils-2.15.92.0.2.tar.bz2  6,91s user 0,23s system 100% cpu 7,144 total

   bzip2 -d binutils-2.15.92.0.2.tar.bz2  6,80s user 0,19s system 100% cpu 6,991 total

   bzip2 -d binutils-2.15.92.0.2.tar.bz2  6,84s user 0,20s system 99% cpu 7,042 total

   bzip2 --best binutils-2.15.92.0.2.tar  27,35s user 0,18s system 100% cpu 27,527 total

   bzip2 --best binutils-2.15.92.0.2.tar  27,04s user 0,19s system 100% cpu 27,229 total

   bzip2 --best binutils-2.15.92.0.2.tar  26,60s user 0,12s system 100% cpu 26,722 total

   bzip2 --best binutils-2.15.92.0.2.tar  26,79s user 0,19s system 100% cpu 26,981 total

gzip   (50188) size

   gzip -d VMware-workstation-5.0.0-13124.tar.gz  1,68s user 0,37s system 99% cpu 2,050 total

   gzip -d VMware-workstation-5.0.0-13124.tar.gz  1,68s user 0,38s system 99% cpu 2,062 total

   gzip -d VMware-workstation-5.0.0-13124.tar.gz  1,66s user 0,42s system 99% cpu 2,079 total

   gzip -d VMware-workstation-5.0.0-13124.tar.gz  1,66s user 0,41s system 100% cpu 2,078 total

   gzip --best VMware-workstation-5.0.0-13124.tar  35,98s user 0,42s system 99% cpu 36,437 total

   gzip --best VMware-workstation-5.0.0-13124.tar  36,05s user 0,39s system 99% cpu 36,475 total

   gzip --best VMware-workstation-5.0.0-13124.tar  36,04s user 0,41s system 99% cpu 36,619 total

   gzip --best VMware-workstation-5.0.0-13124.tar  36,01s user 0,42s system 99% cpu 36,469 total

tar   (190528) size

   tar xf binutils-2.15.92.0.2.tar  0,05s user 0,98s system 47% cpu 2,176 total

   tar xf binutils-2.15.92.0.2.tar  0,04s user 1,01s system 99% cpu 1,052 total

   tar xf binutils-2.15.92.0.2.tar  0,06s user 1,01s system 99% cpu 1,076 total

   tar xf binutils-2.15.92.0.2.tar  0,04s user 1,01s system 99% cpu 1,060 total

oggenc   (9864 oggdec ; 47360 oggenc) size

   oggdec 02-Hours\ Passed\ In\ Exile.ogg  3,81s user 0,23s system 98% cpu 4,084 total

   oggdec 02-Hours\ Passed\ In\ Exile.ogg  3,83s user 0,23s system 99% cpu 4,066 total

   oggdec 02-Hours\ Passed\ In\ Exile.ogg  3,80s user 0,22s system 99% cpu 4,032 total

   oggdec 02-Hours\ Passed\ In\ Exile.ogg  3,79s user 0,25s system 99% cpu 4,041 total

   oggenc 02-Hours\ Passed\ In\ Exile.wav  23,10s user 0,06s system 100% cpu 23,166 total

   oggenc 02-Hours\ Passed\ In\ Exile.wav  23,20s user 0,10s system 100% cpu 23,301 total

   oggenc 02-Hours\ Passed\ In\ Exile.wav  23,20s user 0,09s system 100% cpu 23,289 total

   oggenc 02-Hours\ Passed\ In\ Exile.wav  23,21s user 0,09s system 100% cpu 23,293 total

kadu   (1482048) size

   7,69 1,44

   7,57 1,65

   7,77 1,47

xmms   (996952) size

   2,32 0,94

   2,24 1,11

   2,66 1,00

```

----------

## wojtek

Jak porównac wyniki to bzip2 delikatnie przyśpieszył po kompilacji gcc 4, w przeciwieństwie do gzipa. Testy oggenc i tar-a raczej nie wskazay żadnego faworyta - wzystko w granicach błędu pomiaru. 

Nie rozumiem kadu i xmms - czy to też pakowanie/rozpakowuwanie? Jeśli tak to gcc 4 też raczej jest faworytem - choc błąd pomiaru jest tu dość znaczny.

Ja tu nie widzę powodu do rozczarowania.

----------

## fallow

 *wojtek wrote:*   

> Jak porównac wyniki to bzip2 delikatnie przyśpieszył po kompilacji gcc 4, w przeciwieństwie do gzipa. Testy oggenc i tar-a raczej nie wskazay żadnego faworyta - wzystko w granicach błędu pomiaru. 
> 
> Nie rozumiem kadu i xmms - czy to też pakowanie/rozpakowuwanie? Jeśli tak to gcc 4 też raczej jest faworytem - choc błąd pomiaru jest tu dość znaczny.
> 
> Ja tu nie widzę powodu do rozczarowania.

 

w 100% zgadzam sie z wojtkiem.

ps . chyba nit nie myslal , ze ( tak znowu to powiem ) , ze jak uzyje gcc4.0.0 to jego destkop zamieni sie w ferrari modena albo odleci z predkoscia warp7 ? . 

[small_OT]

dla tych ktorzy mysleli : po prostu jesli ktos tak mysli o zmianie gcc na nowsze , badz wyborze genetycznego cpu schedulera , badz ricera4 , niech po prostu zmieni lekko zalozenia a nie bedzie rozczarowania  :Wink: 

dla tych ktorzy tak nie mysleli : i bardzo dobrze ze nie mysleli , bo to ze cos jest experymentalne oznacza tylko tyle ze jest nie dostatecznie przetestowana a to czy zrealizuje zakladane wytyczne dopiero okaze sie w trakcie testow  :Smile: 

a i pamietajcie o wszechobecnym "efekcie placebo ktoremu ulegaja miliony"  :Smile: 

[/small_OT]

cheers.

----------

## OBenY

Wojtek, Fallow: ow test kadu oraz xmms to czas uruchamiania owych programow, startuja one na tyle dlugo, ze mozna bylo sie pokusic o liczenie ze stoperem w reku, co jest moze troche dziwnym pomyslem, ale coz, innego nie mialem  :Razz: 

Dlaczego sie rozczarowalem? Bo mialem nadzieje, ze przyspieszenie bedzie JAKO-TAKO widoczne, liczylem, ze gcc dogoni chocby czesciowo ICC, ktore jednak potrafi generowac na prawde szybki kod i przy tym nie ma efektow ubocznych takich, ze np jakas flaga psuje binarke, ze potem zle ona dziala albo nie dziala w ogole.

Doskonale sobie zdaje sprawe z tego, ze gcc pomimo numeru 4.0.0 - teoretycznie stabilnego, jest to pierwszy release nowej linii i czeka koderow jeszcze wiele pracy nad nim, by wszystko dzialalo na prawde tak jak tego wszyscy oczekujemy. Jednakze kazda nowa wersja budzi nadzieje, mamy nadzieje, ze bedzie rewolucyjna, tym bardziej ze owe gcc wprowadza dzereg usprawnien w systemie optymalizacyjnym. Byc moze nie dalem sie wykazac kompilatorowi na nowych flagach jakie oferuje, bo testy lecialy na "-O2 -march=prescott -foimt-frame-pointer -s -Wl,-O1,--sort-common,--enable-new-dtags".

Coz, pozostaje czekac, mase fiksow dla nowego gccka juz mozna znalzec, jak wejda do oficjalnego to pewnie sytuacja sie zmieni. Ja poki co wstrzymuje sie z dalszymi walkami z gcc z linii 4.0 do czasu az ktos sie ponownie pokusi o jakis  test wydajnosciowy kodu przezen generowanego  :Smile: 

uff out of wywod  :Smile: 

----------

## Poe

btw ICC. nigdy nie mialem jakos mozliwosc go przetestowac (ot, zapominalem, czas itp) mimo iz mam Intela (celeron 2.0). I teraz drobne pytanko. jak uzytkowanie icc ima sie do gcc jezeli chodzi o kompatybilnosc, bo aktualnie nie mam czasu na przekompilwanie calego systemu z icc, tymbarzdiej, jak patrze na rozmiar zrodel (65,820 kB) wiec i sama kompilaca icc potrwa chwile.

pozdrawiam

----------

## quat

 *Poe wrote:*   

> btw ICC. nigdy nie mialem jakos mozliwosc go przetestowac (ot, zapominalem, czas itp) mimo iz mam Intela (celeron 2.0). I teraz drobne pytanko. jak uzytkowanie icc ima sie do gcc jezeli chodzi o kompatybilnosc, bo aktualnie nie mam czasu na przekompilwanie calego systemu z icc, tymbarzdiej, jak patrze na rozmiar zrodel (65,820 kB) wiec i sama kompilaca icc potrwa chwile.
> 
> pozdrawiam

 na forum pojawilo sie kilka watkow zwiaznych z przekomilowaniem systemu na icc. o ile pamietam bylo duuuzo problemow nie liczac tego ktory uniemozliwial powrot do gcc. mozna zacza stad, a potem tutaj no i prolemy z powrotem do gcc tutaj.

generalnie jest sporo watkow na temat icc na forum ale zaden mnie nie przekonal do przekompilowania systemu. programow numerycznych - tak, ale nie nic poza tym.

a wracajac do 4.0 to ja sie podpisuje obiema rekami ze swietna sprawa, ale jak ktokolwiek sie spodziewa przyrostu mocy w ok 30% to niech wrzuci ck-sources z kilkoma dodatkowymi paczsetami, konieczie z root partycja na r4 bo wtedy mu przyspieszy o ponad 30.2%  :Wink: 

eech, poczekamy i zobaczymy czy bedzie lepszy ten 4.0. wektoryzacja jest chyba jedynym elementem ktorym w 4.0 jestem zainteresowany. no ale mam nadzieje sie mile rozczarowac.  :Very Happy:  (tak tak, a garbate aniolki tez sa)

pozdrawiam

----------

## OBenY

Tez licze na to, ze owa wektoryzacja da czadu, czekalem na to jakis czas:)

A co do problemow z Gentoo na ICC to nie wiem, bo kiedys budowalem wlasne distro na ICC wiec stad wiem jaka roznica  :Smile: 

Pozatym polecam sobie kernela skompilowac przy uzyciu ICC, to jest czad  :Smile: 

Poe: ICC sie nie kompiluje, to jest komercyjny kompilator Intela, co za tym idzie wykorzystuje wszelkie moce drzemiace w prockach Intela. To co udostpeniaja to juz jest binarka, a nie sourcy, bo kto normalny by dawal zrodla takiego czegos  :Smile: 

----------

## wojtek

Wszytskim zawiedzionym polecam czołowy wątek Gentoo Chat  :Smile: .

A tak na poważnie:

1. Błąd w myśleniu pierwszy: można optymalizować w nieskończoność.

To jest nieprawa. Kto się interesował tym zagadnieniem, wie, że występuje tzw. efekt bąbelkowy, czyli usunięcie jednego wąskiego gardła powoduje pojawienie się natychmist innego w innym miejscu. Zawsze będzie istnieał taki kod, który będzie wyznaczał prędkość danej aplikacji. Jeśli ten kod jest napisany nieefektywnie to można go porawić i osiągnąć zauważalny przyrost prędkości wykonywanej aplikacji, jeśli natomiast jest już poprawnie i efektywnie zaimplementowany to jedyne co może Ci pomóc to wymiana sprzętu... Gdyby tak nie było, nie było by tez kryptografii, bo całe jej bezpieczeństwo opiera się na gigantycznej złożoności obliczeniowej pewnych zagadnień matematycznych.

W powyższym stwierdzeniu kryje się nie tylko przepis na to gdzie optymalizować, ale także gdzie nie optymalizować - tzn. jeśli nawet nowy kompilator zauważy kilaka nowych miejsc potencjalnej optymalizacji, które bedą się znajdowały poza wąskim gardłem i je poprawi, to i tak nie zauważymy wzrostu wydajności, mimo iż nowa binarka jest obiektywnie bardziej zoptymalizowana.

Jest to tzw. problem opłacalności optymalizacji i jednocześnie ostrzeżenie dla tych, którzy badają efektywność produkowanego kodu na zasadzie testowania prędkości ostecznych programów bez wnikania w ich budowę. Te testy, właśanie z tego powodu, w większości przypadków nie są obiektywne.

2. Błąd w myśleniu drugi: każdą aplikację da się przyspieszyć.

To też jest nieprawda, z tego samego powodu, który był wyjaśniany powyżej. To na ile można poprawić wydajność zależy ściśle od tego jak jest napisana sama aplikacja i (to jest bardzo ważne z punku widzenia kompilatora) na ile jesteśmy w stanie jednoznacznie określić przepływ sterowania w danym fragmencie kodu - np. wskaźniki w C/C++ potrafią bardzo istotnie zagmatwać, i często udaremnić wszelkie próby optymalizacji z tego prostego względu, że kompilator zwyczajnie nie może być pewien czy wygenerowany w ten sposób kod będzię równoważny (przecież chcemy optymalizować a nie pisać nowe aplikacje).

3. Błąd w myśleniu trzeci: można zbudować kompilator, który WSZYSTKO zoptymalizuje.

I to też, jak można się z poprzedniego punku domyślić jest nieprawda. Kompilator może sobie pozwolić tylko na takie optymalizacje, co do których jest pewien, że będą w efekcie dawać ten sam wynik, nie jest jednak ani alfą i omegą ani elektroniczym wróżbitą, ani nawet nie zdaje sobie sprawy z cudów jakich dokonuje David Coperfild, i nie będzie pisał od nowa całej aplikacji za programistę "bo tak powinno to być zrobione". Z czegoś (na szczęście) programiści mogą ciągle jeszcze żyć, pisząc coraz lepsze programy i często ucząc się na własnych będach.

To tyle ogólników dla zapalonych ricerów - pamiętajcie - najszybszy program to taki który ma długość zero - bo każdy inny jest już od niego wolniejszy... To wzór do naśladowania i cel naszych dążeń  :Wink: Last edited by wojtek on Tue Apr 26, 2005 12:34 pm; edited 2 times in total

----------

## Crenshaw

 *OBenY wrote:*   

> Tez licze na to, ze owa wektoryzacja da czadu, czekalem na to jakis czas:)

 

Tylko nie wstrzymuj oddechu  :Smile:  Do aplikacji desktopowych to nic nie da. To dotyczy tylko wiekszosci tego 

co uzywa number crunching. Poza tym kompilator sam z siebie nie wszystko umie zwektoryzowac i nawet

kompilatorom ktore umieja o wiele wiecej niz gcc na tym polu, trzeba recznie pomagac.

----------

## OBenY

Crenshaw: Spokojnie, to ja wiem  :Smile: 

----------

## joi_

OBenY: przetestuj Kadu z tą łatą

----------

## OBenY

Zrobi sie Joi  :Smile:  Zaraz aplikuje i zaczynam testy. Rozumiem, ze mam do flag dorzucic -fvisibility=hidden, tak ?

----------

## OBenY

EEE o kurde, chyba nic z tego, wszystko wywalilo komunikat z serii "unresolved symbol"... jutro potestuje na bardziej "normalnym buildzie"

----------

## joi_

 *OBenY wrote:*   

> Zrobi sie Joi  Zaraz aplikuje i zaczynam testy. Rozumiem, ze mam do flag dorzucic -fvisibility=hidden, tak ?

 

NIE

----------

## OBenY

Spokojnie Wasc, nie krzycz  :Smile:  Dziala i to piknie  :Smile: 

----------

## joi_

nie krzyczę  :Wink:  jest jakaś różnica w starcie?

----------

## OBenY

Szczerze ? Chyba niezauwazylem ...  :Sad:  (mimo usilnych prob)

----------

## wojtek

Testy GCC 4.0.0 vs GCC 3.4.3 na Gentoo:

http://www.coyotegulch.com/reviews/gcc4/index.html

----------

## joi_

 *OBenY wrote:*   

> Szczerze ? Chyba niezauwazylem ...  (mimo usilnych prob)

 

no cóż, zawsze to jakiś wynik...

----------

