AMD Athlon 64 3000+ ra optimalizált kernelfordítás megéri-e?

[quote:71b95da815="8192Joco"]UHU alatt ki lehet bányászni a meglévő kernel többi be állitásátés és csak ezt az egyet megváltoztatni?

igen, a /boot -ban van a config file... bemasolod az aktualis kernel soru-jaban .config neven, es felulirod a cuccot, majd forgatod...

[quote:e48b5b2dd9="Andrei"]Nekem a "magamnak optimalizalok es forditok" hozzaallassal mas az igazi problemam. A Gentoo userek 100%-ig meg vannak rola gyozodve, hogy az ovek optimalizalt rendszer, csak azert mert egy csomo optimization flag be van kapcsolva (es hogy ez igy jobb, mint a Debian v. a Slackware). Abszolut nem veletlen, hogy ezek nem kerulnek mindig alkalmazasra a forditokban.

hidd el, ezekre azert ok is odafigyelnek. ergo ha -ffooval akarod forgatni es az nem lesz jo, akkor azt alapbol ignore-oljak

[quote:6339e65475="trey"]
Processor type and features --->
(X) Opteron/Athlon64/Hammer/K8

ettol meg nem lesz optimalizalt

-O -pipe es hasonlo flagek a makenak

[quote:ffff40cef3="drastik"][quote:ffff40cef3="trey"]
Processor type and features --->
(X) Opteron/Athlon64/Hammer/K8

ettol meg nem lesz optimalizalt

-O -pipe es hasonlo flagek a makenak

``Intel, és egyéb proceszorokat találtam a menuconfig alat az amd64-et nem.''

en csak erre valaszoltam, mivel szemmel lathatolag nem talalta az opciot.

a optimalizaciorol meg az a velemenyem, hogy faszsag.

[quote:1ef5edf61a="trey"][quote:1ef5edf61a="drastik"][quote:1ef5edf61a="trey"]
Processor type and features --->
(X) Opteron/Athlon64/Hammer/K8

ettol meg nem lesz optimalizalt

-O -pipe es hasonlo flagek a makenak

``Intel, és egyéb proceszorokat találtam a menuconfig alat az amd64-et nem.''

en csak erre valaszoltam, mivel szemmel lathatolag nem talalta az opciot.

a optimalizaciorol meg az a velemenyem, hogy ***.

hja.
hat lehet hogy szted sz_a_r de akkor ezt mondd el a pl. gentoosoknak is.
en fbsdn a make.conf-ban hasznalom ezeket a flageket.

[quote:002e5079ee="drastik"][quote:002e5079ee="trey"][quote:002e5079ee="drastik"][quote:002e5079ee="trey"]
Processor type and features --->
(X) Opteron/Athlon64/Hammer/K8

ettol meg nem lesz optimalizalt

-O -pipe es hasonlo flagek a makenak

``Intel, és egyéb proceszorokat találtam a menuconfig alat az amd64-et nem.''

en csak erre valaszoltam, mivel szemmel lathatolag nem talalta az opciot.

a optimalizaciorol meg az a velemenyem, hogy ***.

hja.
hat lehet hogy szted sz_a_r de akkor ezt mondd el a pl. gentoosoknak is.
en fbsdn a make.conf-ban hasznalom ezeket a flageket.

Gentoos-ok, az optimalizacio szart se er, amit esetleg nyertek a megkerdojelezheto optimalizacion, azt bebukjatok a stabilitason.

Drastik:
- lattal-e mar fuben nyuszit?
- lattal-e mar Mandrake-t?
- jartal-e mar torok borotonben?
- miert mondja az OpenBSD, hogy hasznalj binaris csomagokat? Mert az optimakolas parasztvakitas? Miert mondja, hogy a GENERIC kernel jo, nem kell forditani?
- Miert coredump-ol allandoan az apache, ha FreeBSD optimalizalva van, es miert nem ha nincs?
- meselje, mit nyertel az optimalizalassal? (szamok)

Gyozz meg.

Egy-ket helyen van ertelme az optimalizacionak. Pl. MPlayer. De ha nekem valaki bemeseli, hogy az optimakolt ls kurva jo, azt szemberohogom.

[quote:f5cd0f076c="trey"]- lattal-e mar Mandrake-t?

Na most a Mandrake-kel mi a baj már megint? :D

[quote:f875e2845a="drojid"][quote:f875e2845a="trey"]- lattal-e mar Mandrake-t?

Na most a Mandrake-kel mi a baj már megint? :D

Az agyonoptimalizalt Mandrake-n eleg ha nyomok egy jobb klick-et az asztalon, es a jutalmam egy kis bomba ikon. Tudod mit jelent az... (core dump).

Inkabb legyen valami stabil, mint megkerdojelezhetoen 1-2%-kal gyorsabb. Es nem arrol beszelek, hogy i386-ra, vagy i686-ra van forditva. Hanem csak arrol, hogy kell-e az -O2 vagy -O3 meg az egyeb VPS

[quote:53df813a8a="trey"]
Gentoos-ok, az optimalizacio szart se er, amit esetleg nyertek a megkerdojelezheto optimalizacion, azt bebukjatok a stabilitason.

really? nem panaszkodik a gentoos haverem hogy fagyna a gentoo

[quote:53df813a8a="trey"]
Drastik:
- lattal-e mar fuben nyuszit?

igen lattam aranyos pici orra van meg nagy fule es ugrall

[quote:53df813a8a="trey"]
- lattal-e mar Mandrake-t?

egyszer mar majdnem felraktam egy linuxot de aztan lebeszeltem magam rola de biztos nagyon aranyos a linux network security setup wizard

[quote:53df813a8a="trey"]
- jartal-e mar torok borotnben?

meg nem. rossz emlekeid vannak? van egy jo pszichologus ismerosom...:)

[quote:53df813a8a="trey"]
- miert mondja az OpenBSD, hogy hasznalj binaris csomagokat? Mert az optimakolas parasztvakitas?

mert az openbsd egy ilyen allat, megertem oket. az openbsd jo ugyis ahogy ok ferditik

[quote:53df813a8a="trey"]
- Miert coredump-ol allandoan az apache, ha FreeBSD optimalizalva van, es miert nem ha nincs?

nekem nem koredumpol...

[quote:53df813a8a="trey"]
- meselje, mit nyertel az optimalizalassal? (szamok)

kettes kaptam C forditas oran :))

[quote:53df813a8a="trey"]
Gyozz meg.

kuldom az ukranokat, nagyon meggyozoek :))))

[quote:53df813a8a="trey"]
Egyket helyen van ertelme az optimalizacionak. Pl. MPlayer. De ha nekem valaki bemeseli, hogy az optimakol ls ****** jo, azt szemberohogom.

ls != apache != mplayer
de mint a topicindito srac kerdese szolt o az optimalizaciorol kerdezett hogy mikent lehet, nem az volt a kerdes hogy erdemes-e

amugy mint mondottam nekem a make.conf-ban van mukodik minden f_a_s_zan akkor miert na hasznalnam? neked rosszak a tapasztalataid ne hasznald. ennyi

beke!

se apacs se mas nem coredump-ol optimalizalva(bsd-n portsbol, jobban mint portsbol optimalizacio nelkul, lehetnek egyedi esetek de azert nem lehet altalanosagban kijelenteni hogy fos lesz) igaz eszrevehetoen nem is gyorsabb uhu-nal/munkaallomasnal/olcsoszervernel szerintem sokkal inkabb az a hatranya hogy ha hirtelen vasat akar csereleni alatta az ember akkor korulmenyesebb.

[quote:3a493bef10="vmiklos"][quote:3a493bef10="Andrei"]Nekem a "magamnak optimalizalok es forditok" hozzaallassal mas az igazi problemam. A Gentoo userek 100%-ig meg vannak rola gyozodve, hogy az ovek optimalizalt rendszer, csak azert mert egy csomo optimization flag be van kapcsolva (es hogy ez igy jobb, mint a Debian v. a Slackware). Abszolut nem veletlen, hogy ezek nem kerulnek mindig alkalmazasra a forditokban.

hidd el, ezekre azert ok is odafigyelnek. ergo ha -ffooval akarod forgatni es az nem lesz jo, akkor azt alapbol ignore-oljak

Tartok tole, hogy nem minden esetet probalnak ki.

Szoval a sefer choice megiscsak a sokezer felhasznalo altal "tesztelt" alapbeallitas.

[quote:f855419895="polya"]se apacs se mas nem coredump-ol optimalizalva(bsd-n portsbol, jobban mint portsbol optimalizacio nelkul, lehetnek egyedi esetek de azert nem lehet altalanosagban kijelenteni hogy fos lesz)

Erdekes, a nepi megfigyelesek mast mutatnak.

igaz eszrevehetoen nem is gyorsabb uhu-nal/munkaallomasnal/olcsoszervernel szerintem sokkal inkabb az a hatranya hogy ha hirtelen vasat akar csereleni alatta az ember akkor korulmenyesebb.

Tehat nem lesz gyorsabb, csak korulmenyesebb. Mar megeri :-D

[quote:1db6f0aac7="trey"]Gentoos-ok, az optimalizacio szart se er, amit esetleg nyertek a megkerdojelezheto optimalizacion, azt bebukjatok a stabilitason.

erdekes, nem gond nelkul futnak a gentoo (nem pistike-kategorias) szervereim emberes, folyamatos terheles alatt is. (erzem, megint gentoo flame lesz az egeszbol, pedig nagyon nem kene, mert unalmas mar kicsit es teljesen folosleges)

[quote:1db6f0aac7="trey"]
- Miert coredump-ol allandoan az apache, ha FreeBSD optimalizalva van, es miert nem ha nincs?

miert coredumpolt peldaul az ian murdock altal megaldott es haromszor korbepisalt binarisbol telepitett apacs a hihetetlen S:T:A:B:I:L debianon? (es miert nem dumpolt semmi mas?)

En egy kicsit nem ertem ezt a optimalizalasi dolgot. Volt munkatarsaim irtak egy viszonylag nagy programot C++-ban, tobb 10000 sor sok evi munka egyebek, szep TCP/IP-s multithreades program volt sok libbel egyebekkel szepen felepitve, megkrtek, hogy nezzek mar utanna ezeknek az optimalizacioknak, meg is tettem. Igy lett aztan -o6 meg minden ami kell, szep hosszu flegek. A lenyeg az, optimalizacio miatt sose fordult elo, hogy a program nem mukodott, kiprobaltunk jo par optimalizaciot persze csak ertelmes dolgokat, de mindegyikkel mukodott.
Akkor hogy van ez hogy valami nem megy xyz optimalizacioval, szamomra ebbol az szurodik le:
-1 : hiba van a gcc-ben ami elkepzelheto, de idovel kijavitjak
-2: hiba van a programban, amire gondolom a lusta fejlesztok azt fogjak mondani ne hasznalj optimalizalast
-3: az egyes es a kettes pont kevereke

[quote:ef6a6f48d3="zsirfeka"][quote:ef6a6f48d3="trey"]Gentoos-ok, az optimalizacio szart se er, amit esetleg nyertek a megkerdojelezheto optimalizacion, azt bebukjatok a stabilitason.

erdekes, nem gond nelkul futnak a gentoo (nem pistike-kategorias) szervereim emberes, folyamatos terheles alatt is. (erzem, megint gentoo flame lesz az egeszbol, pedig nagyon nem kene, mert unalmas mar kicsit es teljesen folosleges)

[quote:ef6a6f48d3="trey"]
- Miert coredump-ol allandoan az apache, ha FreeBSD optimalizalva van, es miert nem ha nincs?

miert coredumpolt peldaul az ian murdock altal megaldott es haromszor korbepisalt binarisbol telepitett apacs a hihetetlen S:T:A:B:I:L debianon? (es miert nem dumpolt semmi mas?)

Szamokat ember. Mitol jobb a -OX, mint a semmi.

[quote:bab57710a5="szipka"]
-1 : hiba van a gcc-ben ami elkepzelheto, de idovel kijavitjak
-2: hiba van a programban, amire gondolom a lusta fejlesztok azt fogjak mondani ne hasznalj optimalizalast
-3: az egyes es a kettes pont kevereke

Senki nem vitatta ezeket. A vegeredmeny: valami nem mukodik ugy, ahogy kell. Hogy ez a csillagok allasatol van, vagy csak azert mert a hiba van a programban az egy production szerver eseten nem szamit. A lenyeg: nekem nem hozott semmi pluszt a -Ocsilliobillio, ellenben voltak vele gondok. A kovetkeztetesem: nem erdemes vele foglalkozni annyit, amennyit az ember elbasz azzal hogy leforditja.

[quote:18b4f32d63="zsirfeka"]miert coredumpolt peldaul az ian murdock altal megaldott es haromszor korbepisalt binarisbol telepitett apacs a hihetetlen S:T:A:B:I:L debianon? (es miert nem dumpolt semmi mas?)

Nalad ez a Debian tema fixa idea? Hogy a faszba jott most ez ide? LOL

[quote:40415a70b4="Andrei"][quote:40415a70b4="vmiklos"][quote:40415a70b4="Andrei"]Nekem a "magamnak optimalizalok es forditok" hozzaallassal mas az igazi problemam. A Gentoo userek 100%-ig meg vannak rola gyozodve, hogy az ovek optimalizalt rendszer, csak azert mert egy csomo optimization flag be van kapcsolva (es hogy ez igy jobb, mint a Debian v. a Slackware). Abszolut nem veletlen, hogy ezek nem kerulnek mindig alkalmazasra a forditokban.

hidd el, ezekre azert ok is odafigyelnek. ergo ha -ffooval akarod forgatni es az nem lesz jo, akkor azt alapbol ignore-oljak

Tartok tole, hogy nem minden esetet probalnak ki.

Szoval a sefer choice megiscsak a sokezer felhasznalo altal "tesztelt" alapbeallitas.

Lehet, hogy pici tulzas, de eleg sok gentoo-s siramra emlexem a kozelmultbol itt a HUP-on, amirol aztan kiderult, hogy hasonlo okok miatt volt, mert az orig csomaggal meg ment ua.

[quote:164e5e2684="trey"][quote:164e5e2684="szipka"]
-1 : hiba van a gcc-ben ami elkepzelheto, de idovel kijavitjak
-2: hiba van a programban, amire gondolom a lusta fejlesztok azt fogjak mondani ne hasznalj optimalizalast
-3: az egyes es a kettes pont kevereke

Senki nem vitatta ezeket. A vegeredmeny: valami nem mukodik ugy, ahogy kell. Hogy ez a csillagok allasatol van, vagy csak azert mert a hiba van a programban az egy production szerver eseten nem szamit. A lenyeg: nekem nem hozott semmi pluszt a -Ocsilliobillio, ellenben voltak vele gondok. A kovetkeztetesem: nem erdemes vele foglalkozni annyit, amennyit az ember **** azzal hogy leforditja.

Igen, de akkor a fejlesztoknek kellene ezeket a problemakat kezelni, es nem a rendszeradminisztratoroknak kikiserletezni, hogy melyik program mivel mukodik jol. Persze a legtobb programnal azt mondjak -o2 es kesz, mert azzal megy. Pedig talan egy kis odafigyelessel menne -o3-4 el stb. Kb. ugy ahogy a mplayer csinalja, detektal es optimalizaltan fordit.

[quote:ddba04b73b="trey"]Nalad ez a Debian tema fixa idea? Hogy a *** jott most ez ide? LOL

nem fixa idea, csupan arra probaltam celozni, hogy ott a ("gyari") csomagok nincsenek szenne optimalizalva, megis voltak gondok. ennyi. egyebkent a legtobben a debiant allitjak szembe a gentooval stabilitas kerdeskoreben (is).

[quote:f2d1219ad8="trey"]Szamokat ember. Mitol jobb a -OX, mint a semmi.

szamokat nem fogok neked mondani, mert sosem benchmarkoltam (boldog lennek, ha lenne annyi szabad idom, hogy megtehetnem). te azt allitod, hogy az optimalizacio instabilitast okoz, en ezt vitattam (vitatom is). egyebkent peldaul VIA C3 eseten javasolt a -Os (compile for size) opcio hasznalata szemben a -O2 vagy -O3-al (compile for speed), mert nagyon kicsi a cache, es igy a kisebb kod elmeletileg jobb teljesitmenyt eredmenyez. amugy ha magadnak forditasz dolgokat, a legtobb esetben -O2 flag ott figyel default Makefile-okban; kiszeded kezzel, mert folosleges? tudtommal -On nelkul a gcc a forditasi idot igyekszik csokkenteni, mig -O2 es -O3 eseten a vegleges kod teljesitmenyenek javitasa a cel (a forditasi ido es a targykod meretenek novekedese az ar).

The compiler does not perform loop unrolling or function inlining when
you specify `-O2'. As compared to `-O', this option increases
both compilation time and the performance of the generated code.

biztos ostoba vagyok, de en hiszem, hogy peldaul a loop unrolling es loop array prefetching teljesitmenynovekedest eredmenyezhet sok esetben (ezek nem reszei a -On csaladnak tudtommal, hanem kulon flagek), ahogy a function inlining is, de sok mas opciorol lehetne meg vitatkozni.

[quote:7013e34185="zsirfeka"][quote:7013e34185="trey"]Szamokat ember. Mitol jobb a -OX, mint a semmi.

szamokat nem fogok neked mondani, mert sosem benchmarkoltam (boldog lennek, ha lenne annyi szabad idom, hogy megtehetnem). te azt allitod, hogy az optimalizacio instabilitast okoz, en ezt vitattam (vitatom is). egyebkent peldaul VIA C3 eseten javasolt a -Os (compile for size) opcio hasznalata szemben a -O2 vagy -O3-al (compile for speed), mert nagyon kicsi a cache, es igy a kisebb kod elmeletileg jobb teljesitmenyt eredmenyez. amugy ha magadnak forditasz dolgokat, a legtobb esetben -O2 flag ott figyel default Makefile-okban; kiszeded kezzel, mert folosleges? tudtommal -On nelkul a gcc a forditasi idot igyekszik csokkenteni, mig -O2 es -O3 eseten a vegleges kod teljesitmenyenek javitasa a cel (a forditasi ido es a targykod meretenek novekedese az ar).

The compiler does not perform loop unrolling or function inlining when
you specify `-O2'. As compared to `-O', this option increases
both compilation time and the performance of the generated code.

biztos ostoba vagyok, de en hiszem, hogy peldaul a loop unrolling es loop array prefetching teljesitmenynovekedest eredmenyezhet sok esetben (ezek nem reszei a -On csaladnak tudtommal, hanem kulon flagek), ahogy a function inlining is, de sok mas opciorol lehetne meg vitatkozni.

Engem az erdekel, hogy mit nyerek vele. Mivel nem forditok, hanem binaris csomagokat hasznalok a gepemen, nem is igen buzeralok semmilyen makefile-t. Vannak kiveteles esetek, de nem eletem az -O dolgok allando buzeralasa. Azt mondod nincs idod a szamokra, erre bezzeg van :-D

Fordits sokat, csak meg ne artson a kondenzatoroknak :-)
En maradok a binarisoknal.

Nem is t'om engem ez az egesz gentoos + optimalizacios orulet a regi daciak optikai tuningjara emlekeztet... :twisted:

[quote:6a88cbc26c="trey"]
Engem az erdekel, hogy mit nyerek vele. Mivel nem forditok, hanem binaris csomagokat hasznalok a gepemen, nem is igen buzeralok semmilyen makefile-t. Vannak kiveteles esetek, de nem eletem az -O dolgok allando buzeralasa. Azt mondod nincs idod a szamokra, erre bezzeg van :-D

Fordits sokat, csak meg ne artson a kondenzatoroknak :-)
En maradok a binarisoknal.

Trey, ez egy kicsit szűklátókörű magatartásra vall. Gentooban sem feltétlenül azért fordít az ember, mert agyonoptimalizál, hanem azért, mert bizonyos funkciók csak így érhetők el. Marha szép, és jó, hogy te bináris csomagokat használsz, de ha szeretnél stack smashing protectort, pie-os binárisokat, selinux támogatást a binárisaidba, vagy egszerűen egy smartcard támogatású ssh-t, akkor egy laza mozdulattal a hajadra kenheted a bináris csomagjaidat (legalábbis pl. debian alatt biztosan). Ha meg úgyis fordítani kell, egy -O2 vagy -O3 egyáltalán nem baj, hogy ott van (ennél nagyobb ugye felelsleges, mert jelenleg -O3 == -O99). Ettől nem lesz instabilabb a rendszered, ez urban legend. A gentoo buildelő rendszere minden csomagnál kiszűri az adott csomagra veszélyes gcc flageket, és a -O -t is visszaveszi annyira, aminél a csomag stabil. Elég gáz, hogy azért, mert neked Mandrake-kel rossz tapasztalatod volt, a Gentoo-t szidod.

[quote:7355fc494e="Toma_"]Nem is t'om engem ez az egesz gentoos + optimalizacios orulet a regi daciak optikai tuningjara emlekeztet... :twisted:

Hat most eppen a kornyezetemben ketten is hasznalnak Gentoo-t, de egyik sem az elso helyen emliti a forrasbol porgetest, mint a Gentoo legelonyosebb tulajdonsagait. Szerintum sok mas fontosabb dolog van a Gentoo-ban amiert szeretni lehet. Plane h a Gentoo-hoz is vannak binaris csomagok. Nem veletlenul. Nem akar mindenkinek az elete a forgatas a kozhiedelemmel ellentetben :-)

[quote:ef0da1858b="johans"]Elég gáz, hogy azért, mert neked Mandrake-kel rossz tapasztalatod volt, a Gentoo-t szidod.

Ki szidta a Gentoot ember. Amig zsirfeka meg nem jelent Linux disztibucio szoba se kerult. Hagyjatok mar ezt ``csoportosan raszallok barkire, aki nem forgat forrasbol'' mert nem all jol. Azt mondtam, hogy az optimalizacio nem er annyit mint amennyi huhot csapnak korulotte. Ez lehet tolem Gentoo, vagy akarmi. Azert lett Gentoo, mert drastik azt hozta fel.

Egesz vegig optimalizaciorol volt szo, itt meg jossz tok mas dolgokkal, mint a stack protection.

Egyebkent Linux kernel FAQ:

http://www.tux.org/lkml/#ss8

What about optimizations? How do I get to use -O99, etc.?

If you want to play with the optimization options, you need to hack the Makefile in arch/i386/Makefile (assuming you have an x86 processor), but if it breaks... well, you should know the answer by now. Also keep in mind that some demented optimizations (such as -O99) may even produce slower and bigger kernels, due to gratuitous loop unrolling and function inlining.

Jo optimalizalast!

(Tudom, regi a FAQ, ha ez esetleg valtozott, akkor visszaszivok mindent, hamut szorok a fejemre, es mindenkinek ajanlani fogom az -O buzeralast :-)

[quote:aa2e4e3a2f="johans"]
Gentooban sem feltétlenül azért fordít az ember, mert agyonoptimalizál, hanem azért, mert bizonyos funkciók csak így érhetők el.

Nem akarok negativan lecsengeni gentoo ugyben, de szvsz kilencvenvalahany szazalekra saccolom azoknak az aranyat, akik csak trendi modon, a fentiek tudta nelkul hasznaljak...

[quote:b243360aee="trey"]Egyebkent Linux kernel FAQ:

http://www.tux.org/lkml/#ss8

What about optimizations? How do I get to use -O99, etc.?

If you want to play with the optimization options, you need to hack the Makefile in arch/i386/Makefile (assuming you have an x86 processor), but if it breaks... well, you should know the answer by now. Also keep in mind that some demented optimizations (such as -O99) may even produce slower and bigger kernels, due to gratuitous loop unrolling and function inlining.

Jo optimalizalast!

(Tudom, regi a FAQ, ha ez esetleg valtozott, akkor visszaszivok mindent, hamut szorok a fejemre, es mindenkinek ajanlani fogom az -O buzeralast :-)

Akkor idéznék a linux kernel Makefile-jából:

HOSTCFLAGS = -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer

A linux kernel optimalizálás nélkül tudtommal hibásan fordul.
Jó optimalizálást!

ps: az előző levelemet egy kicsit félreértetted. Ha már úgyis fordítasz, és nem lesz tőle instabil a rendszer, nem kellemesebb, ha az ésszerű optimalizáció be van kapcsolva?

Én csak szerényen, kérdezném meg, hogy a Debianban hol van a make.conf, mert én nem találom, az etc-ben meg végképp nem.

[quote:657c6ec05e="Andrei"]Tartok tole, hogy nem minden esetet probalnak ki.

persze. elore definialva van az a nehany ami megengedett a tobbit alapbol ignore-aljak. egyebkent erdemes a temaban googlezni egy kicsit, vagy majd vmi gentoo user ad bovebb felvilagositast :)

[quote:b61cb73fc1="johans"]
A linux kernel optimalizálás nélkül tudtommal hibásan fordul.
Jó optimalizálást!

ps: az előző levelemet egy kicsit félreértetted. Ha már úgyis fordítasz, és nem lesz tőle instabil a rendszer, nem kellemesebb, ha az ésszerű optimalizáció be van kapcsolva?

Arrol beszeltunk, hogy az alapokon tul kell-e. Ha neked nem ez jott le, akkor keson kapcsolodtal bele a beszelgetesbe... Sot azt is megbeszeltuk, hogy i386 es i686 se kerdeses. Tehat nyilvan ezt erdemes.

A legyeg: kell-e az alap beallitott dolgokon tul meg valamit ganyolni. Egyebkent megbeszeltuk ezt egy gentoo hasznaloval most, nezzuk o mit mond:

gentoo user: lehet h van olyan kombinacio amivel tenyleg jobb 0.01%-al
gentoo user: engem ez kurvara nem erdekel
gentoo user: sztem is baromsag, de miert ne szivjon vele aki akar? forditsa kernel -O99-el aztan oruljon neki ha mukodik
gentoo user: ha nem mukodik, akkor meg tudja hogy o a huje, es kussoljon
gentoo user: trey: biztos van olyan akinek megeri
gentoo user: olyanok is vannak akik neon foszforeszkalo kabeleket raknak a gepbe
gentoo user: en spec mindent -O2 -march athlon-xp -vel forgatok, nem azert mert azt hiszem h olyan kurva gyors lesz tole, hanem azert, mert ha mar ugyis forgatom akkor miert ne allitanam be neki
gentoo user: O3-at is hasznaltam egy darabig amig ra nem jottem h szar
valaki mas: -O3mal hetente 1x fagysz ;)
gentoo user: pl flac enkodolast 10%-al lehet gyorsitani
gentoo user: csak ugyanazzal a flaggel mas stuff meg elszall
gentoo user: es mivel nem flac enkodolasbol all az eletem, ezert jo nekem az O2

Nakerem. Ez az egesz egy hitvita. Az en velemenyem, hogy nem erdemes szivni ezzel. A tietek meg hogy igen. Szerintem fejezzuk be. :-D

khm

most itt ugye arrol volt szo trey hogy egyataln kell-e optimalizalni aztan szepen lassan elment abba az iranyba a velemenyed hogy jo hat -O2 meg jo de a folott mar nem.

mondjuk en az elejetol -O -t irtam

nohde sebaj

tehat nem kell optimalizalni de pl. a linux kernel makefileben -O2 van ....

[quote:6d723645e8="trey"]Ki szidta a Gentoot ember. Amig zsirfeka meg nem jelent Linux disztibucio szoba se kerult. Hagyjatok mar ezt ``csoportosan raszallok barkire, aki nem forgat forrasbol'' mert nem all jol. Azt mondtam, hogy az optimalizacio nem er annyit mint amennyi huhot csapnak korulotte. Ez lehet tolem Gentoo, vagy akarmi. Azert lett Gentoo, mert drastik azt hozta fel.

en kerek elnezest, de en nem hoztam fel semmifele disztribuciot (miutan megjelentem), hanem drastik emlitette a gentoot. egyebkent azt is mondtad, hogy instabil lesz a rendszered az optimalizaciotol, es en erre batorkodtam megjegyezni, hogy en is nyomorult forrasbolforgato vagyok (vagy verziob_u_z_i, vagy akarmi, amit akarsz), es meg nem voltak gondjaim gentoo szervereken az optimalizacio miatt. en nem uzemeltetek semmilyen szakmai portalt, igy nyilvan nem erthetek ezekhez a dolgokhoz, igy most bocsanatot kerek, hogy vitaba mereszeltem szallni az optimalizaciot illeto allaspontoddal. a kondenzatorok allapota engem is aggaszt, ezert csak es kizarolag gentoo-certified (optimalizalt) alkatreszeket vagyok hajlando hasznalni :lol:

[quote:0183e7174e="zsirfeka"][quote:0183e7174e="trey"]Ki szidta a Gentoot ember. Amig zsirfeka meg nem jelent Linux disztibucio szoba se kerult. Hagyjatok mar ezt ``csoportosan raszallok barkire, aki nem forgat forrasbol'' mert nem all jol. Azt mondtam, hogy az optimalizacio nem er annyit mint amennyi huhot csapnak korulotte. Ez lehet tolem Gentoo, vagy akarmi. Azert lett Gentoo, mert drastik azt hozta fel.

en kerek elnezest, de en nem hoztam fel semmifele disztribuciot (miutan megjelentem), hanem drastik emlitette a gentoot. egyebkent azt is mondtad, hogy instabil lesz a rendszered az optimalizaciotol, es en erre batorkodtam megjegyezni, hogy en is nyomorult forrasbolforgato vagyok (vagy verziob_u_z_i, vagy akarmi, amit akarsz), es meg nem voltak gondjaim gentoo szervereken az optimalizacio miatt. en nem uzemeltetek semmilyen szakmai portalt, igy nyilvan nem erthetek ezekhez a dolgokhoz, igy most bocsanatot kerek, hogy vitaba mereszeltem szallni az optimalizaciot illeto allaspontoddal. a kondenzatorok allapota engem is aggaszt, ezert csak es kizarolag gentoo-certified (optimalizalt) alkatreszeket vagyok hajlando hasznalni :lol:

:))))

ense uzemeltetek semmien szakmai portalt ellenben az osszes serveremen freebsd van es ugye ott lehetoseg van a ____teljes____ rendszer ujraforgatasara es ezt is -O -pipe flegekkel teszem es en sem tapasztaltam meg fagyast

de biztos ilyen nagyon gonosz dolog es csak nekem volt makom

[quote:ee9646c49a="drastik"]khm

most itt ugye arrol volt szo trey hogy egyataln kell-e optimalizalni aztan szepen lassan elment abba az iranyba a velemenyed hogy jo hat -O2 meg jo de a folott mar nem.

mondjuk en az elejetol -O -t irtam

nohde sebaj

tehat nem kell optimalizalni de pl. a linux kernel makefileben -O2 van ....

Nem a velemenyem ment el, hanem en default beallitasok mellett kardoskodok, itt a polgarok nagy resze meg -O3-akat emleget. Az en velemenyem az, hogy nem kell piszkalni a default (ezek szerint -O2-t), es ezt fenn is tartom. Mivel a kerdezonek is a default az -O2, nyilvan ot a tovabbi optimalizaciok erdeklik. Ha nem igy van, akkor en ertettem felre.

[quote:0983df65d8="8192Joco"]Akkor aki nem értette volna az eredeti kérdést.
A 32biten mocorgó AMD athlont mi módon lehet 64 biten mocorgóra tenni, mit kell át állítani?
Erre már az elején választ is kaptam.
Azért neveztem át a topicot mert elkezdetek az optimalizálásról vitatkozni. Kb az után ,hogy megkaptam a kérdésekre a választ.

Magyarul az elso valaszom kielegito volt, drastik meg szokas szerint a szar csepelte... :-D De ezt mar megszoktam tole. :-D

[quote:53b8d00dc0="drastik"]az osszes serveremen freebsd van es ugye ott lehetoseg van a ____teljes____ rendszer ujraforgatasara es ezt is -O -pipe flegekkel teszem es en sem tapasztaltam meg fagyast

Erdekes, hogy pont a FreeBSD 5.3-RELEASE nem akart az istennek elindulni ha a HUP-on ha a buildworld / buildkernel CPU-ra volt optimalizalva. Most eppen ugy megy a FreeBSD 5.3-STABLE a HUP-on, hogy a /etc/make.conf-bol ki van szedve a CPUTYPE?=p3 mert kulonben el se indul. Jee, van ilyen?

[quote:12b4c332d1="trey"][quote:12b4c332d1="drastik"]az osszes serveremen freebsd van es ugye ott lehetoseg van a ____teljes____ rendszer ujraforgatasara es ezt is -O -pipe flegekkel teszem es en sem tapasztaltam meg fagyast

Erdekes, hogy pont a FreeBSD 5.3-RELEASE nem akart az istennek elindulni ha a HUP-on ha a buildworld / buildkernel CPU-ra volt optimalizalva. Most eppen ugy megy a FreeBSD 5.3-STABLE a HUP-on, hogy a /etc/make.conf-bol ki van szedve a CPUTYPE=p3 mert kulonben el se indul. Jee, van ilyen?

kellemetlen

hasznald a CPUTYPE=!p3 -t ha jol emlekszem ami lehetove teszi a make szamara az eltero bellaitasokat ha megse lenne valami f_a_s_z_a.

[quote:b3539da839="drastik"][quote:b3539da839="trey"][quote:b3539da839="drastik"]az osszes serveremen freebsd van es ugye ott lehetoseg van a ____teljes____ rendszer ujraforgatasara es ezt is -O -pipe flegekkel teszem es en sem tapasztaltam meg fagyast

Erdekes, hogy pont a FreeBSD 5.3-RELEASE nem akart az istennek elindulni ha a HUP-on ha a buildworld / buildkernel CPU-ra volt optimalizalva. Most eppen ugy megy a FreeBSD 5.3-STABLE a HUP-on, hogy a /etc/make.conf-bol ki van szedve a CPUTYPE=p3 mert kulonben el se indul. Jee, van ilyen?

kellemetlen

hasznald a CPUTYPE=!p3 -t ha jol emlekszem ami lehetove teszi a make szamara az eltero bellaitasokat ha megse lenne valami f_a_s_z_a.

tevedtem

CPUTYPE?=p3

igy kell

[quote:51bc7660bc="drastik"]
tevedtem

CPUTYPE?=p3

igy kell

[quote:51bc7660bc="trey"]
hogy a /etc/make.conf-bol ki van szedve a CPUTYPE?=p3 mert kulonben el se indul.

Ugy volt benne. Nem mukodott.

[quote:c25e9fc886="8192Joco"]Akkor aki nem értette volna az eredeti kérdést.
A 32biten mocorgó AMD athlont mi módon lehet 64 biten mocorgóra tenni, mit kell át állítani?
Erre már az elején választ is kaptam.
Azért neveztem át a topicot mert elkezdetek az optimalizálásról vitatkozni. Kb az után ,hogy megkaptam a kérdésekre a választ.

Na varj csak, ha k8-ra forditod egy 32 bites linux-on, 32 bites gcc-vel, akkor szerintem nem lesz 64 bites a vegeredmeny.
Amikor 64 bites debian sarge alatt forditottam le (ugyanazt) a kernelt, akkor teljesen mas volt a processzorvalaszto menupont, es a /proc/cpuinfo is sokkal tobbet mutat. (es a postgres is gyorsabb lett :-) )

[quote:996a8bbf01="8192Joco"]Már fel raktam egy fél Getoot egy másik partícióra. AMD 64 optimalizált csomagos telepítést. Ott akarom megcsinálni a fordítást és azt akarom be hegeszteni az UHU -ba.

off

mihez kell neked az UHU amihez nem jo pl. a gentoo?

/off

[quote:9546f3eba2="trey"][quote:9546f3eba2="drastik"]
tevedtem

CPUTYPE?=p3

igy kell

[quote:9546f3eba2="trey"]
hogy a /etc/make.conf-bol ki van szedve a CPUTYPE?=p3 mert kulonben el se indul.

Ugy volt benne. Nem mukodott.

memoria jo?

minden mas esetben mas oprendszerrel jo?

passzolom a temat. en duronon, p4en, p2n, es p3an hasznaltam eddig es mindenhol jol mukodott.

[quote:24239d03aa="drastik"][quote:24239d03aa="trey"][quote:24239d03aa="drastik"]
tevedtem

CPUTYPE?=p3

igy kell

[quote:24239d03aa="trey"]
hogy a /etc/make.conf-bol ki van szedve a CPUTYPE?=p3 mert kulonben el se indul.

Ugy volt benne. Nem mukodott.

memoria jo?

minden mas esetben mas oprendszerrel jo?

passzolom a temat. en duronon, p4en, p2n, es p3an hasznaltam eddig es mindenhol jol mukodott.

A HUP 709 napot ment egyfolytaban FreeBSD 4.7-tel p3-ra forditva. Merevlemezhiba miatt lett ujratelepitve, es akkor mar 5.x kerult ra. Most igy megy mar 33 napja gond nelkul, nem p3-ra forditva, ugyhogy HW hiba kizarva. Egyebkent minosegi alkatreszekbol van osszerakva, pl. Kingston ECC memoriakkal. Kizart, hogy HW hiba lenne, ugyanis akkor nem menne ennyi ideig (709 nap akarhogy is nezem majdnem ket ev).

[quote:ada2dd4630="trey"]A HUP 709 napot ment egyfolytaban FreeBSD 4.7-tel p3-ra forditva. Merevlemezhiba miatt lett ujratelepitve, es akkor mar 5.x kerult ra. Most igy megy mar 33 napja gond nelkul, nem p3-ra forditva, ugyhogy HW hiba kizarva. Egyebkent minosegi alkatreszekbol van osszerakva, pl. Kingston ECC memoriakkal. Kizart, hogy HW hiba lenne, ugyanis akkor nem menne ennyi ideig (709 nap akarhogy is nezem majdnem ket ev).

hat akkor telleg csak az 5.xel lehet gond.
en 5.3at hasznalok a legtobb helyen mert eddig nagyon stabilnak tunik.
aztan ki tudja.

[quote:23056e8e4d="8192Joco"]Már fel raktam egy fél Getoot egy másik partícióra. AMD 64 optimalizált csomagos telepítést. Ott akarom megcsinálni a fordítást és azt akarom be hegeszteni az UHU -ba.

Ennek túl sok értelme nincs. Ha 64 bites kernelhez 32 bites userspace-t használsz, akkor biztosan nem fogsz gyorsulást tapasztalni, mert a userspace programok nem fogják kihasználni a +32 bit regiszter területet.

Valahogy nekem is az a velemenyem, hogy a procira optimalizalt kernel es libc parasztvakitas. Ezek nagyon sokszor ugyis olyan kodot tartalmaznak, hogy mar nem tud vele mit kezdeni a fordito.

Persze elkezdhet inline-ozni meg loop unroll-t csinalni, de az mindig keteselyes, mert sok eseteben a program runtime viselkedesekor dol el, hogy gyorsabb lehet-e a program (mennyire cseszi szet a felpumpalt kod a cache-t).

Az mplayer-t sem igazan eri meg optimalizalva forditani, mert a kritikus reszek ugyis assembly-ben vannak, azt meg nem erinti az optimalizacios flag. Ha most ugy nezzuk, hogy az mplayer futasa kozben 90%-ot tolt kritikus asm reszekben, a maradek 10%-ot pedig optimalizalhatod -O1000 flaggel, akkor mar latszik, hogy miert maceras a dolog (tizedszazalekokert szivatod magad). Viszont, ha barmi gaz van a cuccossal, akkor a kutya sem fog segiteni a problema megoldasaban.

Nekem a "magamnak optimalizalok es forditok" hozzaallassal mas az igazi problemam. A Gentoo userek 100%-ig meg vannak rola gyozodve, hogy az ovek optimalizalt rendszer, csak azert mert egy csomo optimization flag be van kapcsolva (es hogy ez igy jobb, mint a Debian v. a Slackware). Abszolut nem veletlen, hogy ezek nem kerulnek mindig alkalmazasra a forditokban. Az agresszivebb optimalizacios eljarasok nagyon kellemetlen mellekhatasokkal jarhatnak (a fent emlitett kod felfujas csak egy a sok kozul). Nem veletlen, hogy az inline es a loop unroll a jobb forditokban #pragma segitsegevel megadhato, mert elkepzelheto, hogy a forrasban levo 10 ciklusbol csak 2-3 kepes belole profitalni, a tobbi meg atvagja a forditot es csak felpumpalt kod lesz belole.

Szoval a flagek bekapcsolasanal sokkal tobbet kellene tenni azert, hogy valoban optimalizalt kodot kapj az egesz vegen. Ha automatice jo eredmeny jonne beloluk, akkor betettek volna alapbol.

Erdemes lehet 64 bitre forditani, tekintve hogy egy kicsit tobb regisztert hasznalhat a forditoprogram...

ezt valoszinu az uhusok megcsinalnak, ha lenne igeny ra, annyi, hogy ujra kellene forditani az uhu csomagokat

[quote:a9840e4165="8192Joco"]Ha a Blendert akarom 64 bitesre forditani (2.38 tól támogatni fogja adig cvs) akor azt hogyan kell csinálni?

Egy módszer, ami minden C/C++ program fordítására jó:
1, Lefuttatod a configure scriptet, amennyiben van, így kapsz egy stock Makefile-t, amiben a "gyári" beállítások vannak.
2, Kedvenc editoroddal megnyitod, és megkeresed a CFLAGS sort, vagy amit használ a flagek elnevezésére. Láttam olyat is, ahol egy CFLAGS-ban van az alap és van egy CEXTFLAGS vagy valami ilyesmi, és mindkettőt átadja paraméterként. Néha előfordul, hoyg amit keresel az a Makefile.am vagy Makefile.inc fájlok valamelyikében van. Nézd végig mindet.
Na, szóval keresd meg a megfelelő helyet, és szúrd be, vagy módosítsd ami neked kell. Ha 64 bitre akarsz fordítani, akkor: -march=athlon64
Ha emellé még akarsz optimizációt, akkor -O3 vagy -O2, esetleg -Os, kinek mi tetszik. (Nekem -Os)
3, make install

[quote:48ded8b2ef="8192Joco"]A fent nevezet processzora szeretnék kernelt fordítani.
Intel, és egyéb proceszorokat találtam a menuconfig alat az amd64-et nem. Mit rontottam el?

Vanillia 2.6.9.10

Most melyik? 9 vagy 10?

Egyebkent:

Processor type and features --->
(X) Opteron/Athlon64/Hammer/K8