Mérések a Gentoo optimalizálásokról

Gentoo

A linux-mag.com-ról: "A Gentoo egy forrás-alapú disztribúció, amely lehetővé teszi a felhasználó számára, hogy az eldönthesse, hogy hogyan optimalizálja a rendszerét különböző szempontokból. A Linux Magazine a három leggyakoribb GCC optimalizációt - -Os, -O2 és -O3 - mérte le, és összehasonlításképpen bedobta az Ubuntu-t."

Az eredmények itt.

( Replaced | 2009. 10. 31., szo – 12:12 )

haha, semmi kulonbseg nincs :p
amugy soha nem ertettem ezt az -O666 maniat, mikor az alkalmazasok 99%-nal a GUI a szuk keresztmetszet, ami meg baromi lassu ugyis X11 alatt :>

--
NetBSD - Simplicity is prerequisite for reliability

Azert egy -O2 eleg stabilnak tunik, ez a defult Gentoo-ban es nekem meg sose volt bajom vele (7 ev alatt). Plusz nem neveznem tuloptimalizacionak. Persze lehet itt ilyen O3, O4-ekkel jatszani, de mint a teszt is mutatja nem eri meg tulsagosan, es azzal mar a Gentoo bugzillaban is elhajtanak.

En azt sokkal jobban utalom, amikor a disztro felrak neked egy szar csomagot, es egyszeruen nem tudsz vele mit csinalni, csak varsz, hogy jojjon uj verzio. Gentoo alatt ujrafordithatom, leszedhetek egy uj ebuild-ot a bugzillabol ami javitja.

Jo de azt a fejlesztokon kivul senki nem hasznalja. Nemtom milyen dokumentaltsaga van. Plusz nemtom mit szolnak hozzad bugzillaban ha forras csomagra jelentesz bug-ot (hasznald a binarist, az jo).

Szoval ha mar ugyis forditani akarsz akkor sokkal jobban jarsz Gentoo-val. Mivel ott mindenki azt teszi. Sokkal egyszerubb, jobban ki van tesztelve, tamogatva van.

Arch alatt szerintem nem bonyolultabb, mint gentoo alatt. Portage helyett van abs + makepkg. Unsupported csomagokhoz meg van az AUR és hozzá a yaourt, ami tök automatán leszedi a pkgbuild-et, rántja a függőségeket, build-el, csomagol, installál, de menet közben minden lépésnél lehetőséget is hagy rá, hogy kézzel beleeditálj, ha valami nem tetszik.

RPMbuild valóban lényegesen macerásabb, bár tény, hogy kevesebbet is foglalkoztam vele.
---
Internet Memetikai Tanszék

En nem nagyon ertek a dologhoz, de pont tegnap neztem meg egy eloadast a szabad szoftver konferencian, ami kb 30 perc volt. Nem azt mondom, hogy ezek utan tudnek profin mindent csinalni, de ugy erzem, hogy egy bugot megtalalni, kijavitani lenyegesen nagyobb feladat, mint megtanulni azt a par parancsot, ami rpm-et csinal az egeszbol.

USE flagek helyett viszont nincs semmi az Archban. az egyik fő előnye a Gentoonak, hogy fordíthatsz rá pl XChat csomagot gtk támogatás nélkül, és ezt globálisan be is állíthatod minden érintett csomagra. ugyanakkor egyedileg egyes csomagoknál felül is bírálhatod a saját global USE flag beállításaidat.

Sose használtam éles rendszeren gentoo-t, ugyanakkor szerintem ez inkább feature. Ha egyszer szükségem lesz egy olyan gépre, amin fontos, hogy az OS pontosan az adott vasra legyen belőve, hogy pontosan azok a dolgok menjenek amik nekem kellenek, és még a teljesítmény is nagyon számítana, akkor gentoo jó eséllyel indulna oprendszernek. Szóval a szememben ez egy nagy plusz pont a gentoonak.
Csaba

Aztán ha frissíteni kell, vagy ha valami gáz van, és mélylélektani :) debugolásra van szükség, akkor jöhet a vakarózás. Pont önmagad ellen beszélsz egyébként azzal, hogy "pontosan azok a dolgok menjenek amik nekem kellenek" -- egy szerveren nagyjából semmi keresnivalója egy komplett toolchain-nek/build környezetnek, kivéve, ha nem az az egyik vagy a fő feladata, hogy binárisokat csináljanak rajta. Legalábbis szerintem...

Konkrétan a szomszéd szobában ketyegő clusterünkre (százvalahány node) gondoltam. Most fedora megy rajta, a fontos dolgok újraforgatva. Csak elgondolkoztam, hogy esetleg még nagyobb teljesítményt ki lehetne belőle hozni egy customizált (mármint a jelenleginél is jobban customizált) rendszerrel, és ekkor jöhetett szóba a gentoo. Természetesen arról szó sincs, hogy minden node saját maga alá forgassa a szoftvert. Szóval nem szerver, a cluster csak belső hálóról elérhető, végül, de nem utolsó sorban nem én adminolom, szóval nekem csak kívánságaim lehetnek, hogy milyen OS fut rajta. :-)
Csaba

Miért kell hozzá saját build környezet? A Gentoo is fel tud tenni bináris csomagokat. Egy gépen szépen lefordítod aztán az összes node azt teszi fel, ezt Gentoon nagyon egyszerű megcsinálni. Saját build rendszernek nincs semmi előnye, Gentoo-ban mindent testre lehet szabni. A telepítés is egyszerű klónozod őket, ha egy egyszerű script csinálja pár perc alatt megvan, mérettől függően.

Ha egy darab gépe van, akkor helyben build. Ha szerver meg egy rakat desktop (kkv), akkor a desktop esélyes, hogy Windows, ergo buildelés a szerveren. Más disztrón is simán meg lehet csinálni a saját fordítású csomagokat, azt azonban nem szabad elfelejteni, hogy egy bináris disztrib esetén azonos szoftverkörnyezetet n+1 helyen használnak, tesztelnek, míg a saját custom build-et meg nem. Éles rendszerbe teszteletlen csomagot feltolni nem igazán helyes irányvonal... (Ergo build rendszer és tesztkörnyezet kialakítás nélkül nem igazán tetszetős a dolog)

Pedig de. Nekem pl. Ubuntu alatt kellett frissebb Dia (Cairo pdf-fel). Kb. tíz perc alatt a buildhez szükséges cuccok lejöttek, lefordultak és a kész csomagok felmentek a disztribben lévő régi helyett. (Annak, hogy mindent a saját CPU izzad ki, annak mi a tényleges előnye? (Hogy a források letöltésének, tárolásának az erőforrás-igényét (sávszélesség, diszk) már ne is említsem...)

A szó valóban értelmetlen, de amit mögötte értenek az a jelenség létezik, mert a túl sok optimalizácós paraméter esetén (így már szerintem nem paradox), előfordul, hogy lassabb binárist eredményez. Ugyanis az optimalizáció fokával növekszik a bináris mérete, ami fix cache/memória mérete miatt bőven lassabb is lehet. Pl. annó nekem egy p4-celeron-om volt amin az Os-el fordított kódok sokkal gyorsabban (a sok itt értendő 10%-os nagygságrend) voltak többnyire mint az O3-al. Ezek a műszavak szerintem olyanok mint a gulyásleves, vagy a tűzcsap szavak. Gulyásleves főzésért sem született még kannibalizmus miatt elítélő ítélet, és a tűzcsapok esetén sem hallottam olyan esetet, hogy lakástüzet okoztak volna. :D, pedig szó szerint értelmezve logikus lenne. Engem nem zavar ez a fajta megfogalmazás. Vam annyira kifejező a Magyar nyelv, (ellentétben más nyelvekkel) hogy ezek a kifelyezések simán érthetőek.
------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

6 óra!?

T8300 @ 2.40GHz / 4GB RAM
laptopról van szó!


gaia balage # genlop -t openoffice
* app-office/openoffice

Wed Sep 9 15:25:43 2009 >>> app-office/openoffice-3.1.1
merge time: 2 hours, 18 minutes and 52 seconds.

Fri Sep 18 08:56:50 2009 >>> app-office/openoffice-3.1.1
merge time: 45 minutes and 22 seconds.

Sun Oct 11 13:28:12 2009 >>> app-office/openoffice-3.1.1
merge time: 48 minutes and 31 seconds.

Mon Oct 19 17:25:21 2009 >>> app-office/openoffice-3.1.1
merge time: 2 hours, 21 minutes and 35 seconds.

Thu Oct 29 11:31:11 2009 >>> app-office/openoffice-3.1.1
merge time: 1 hour, 1 minute and 7 seconds.

kdelibs-4.x a második "leglassabb"


gaia balage # genlop -t kdelibs
* kde-base/kdelibs

Sat Aug 29 13:04:09 2009 >>> kde-base/kdelibs-4.3.0
merge time: 34 minutes and 28 seconds.

Sat Sep 5 09:53:14 2009 >>> kde-base/kdelibs-4.3.1
merge time: 24 minutes and 36 seconds.

Mon Sep 28 21:15:18 2009 >>> kde-base/kdelibs-4.3.1
merge time: 12 minutes and 27 seconds.

Tue Oct 13 09:40:26 2009 >>> kde-base/kdelibs-4.3.2-r1
merge time: 26 minutes and 23 seconds.

Thu Oct 15 16:38:22 2009 >>> kde-base/kdelibs-4.3.2-r2
merge time: 37 minutes and 44 seconds.

Wed Oct 21 15:09:33 2009 >>> kde-base/kdelibs-4.3.2-r3
merge time: 27 minutes and 22 seconds.

igen használok ccache-t, /dev/shm-et, és a portage --jobs funkcióját ja és a makeopts="-j4" :D

--
\\-- blog --//

Nagyon érdekes, hogy az emberek miért könyvelték el, hogy a Gentoo mostanában rossz. Az is érdekes, hogy miért tartják az emberek rossznak a Vistát és jónak a Windows 7-et. Szerintem mindkét hiedelem légbőlkapott, és egyiket sem támaszja alá semmi racionális magyarázat. Nekem nem szokott olyan problémám lenni aminek a Gentoo az oka.
Kérem mellőzni a hasonló hozzászólásokat, igazán a problémákról csak az tud aki aktívan használja legalább egy számítógépen, és ez igaz tetszőleges XY disztribúcióra.

Pedig nagyon egyszerű a magyarázat, válasz első mondatodra.

Pár éve kikerült a valós életbe, érts felnőtt, az a nemzedék, ami tömegesen istenítette és használta anno a Gentoot.
Kikerült és rádöbbent, hogy bár alapokat tanulni nagyon jó egy source base disztró, de éveket rápazarolni bizony drága hanyagság.
Ezután gondolom legtöbbjük úgy viselkedett, viselkedik mint a dohányzásról éppen leszokottak, akikben gyakran több intolerancia támad fel régi szenvedélyük iránt mint eleve nemdohányzókban.
Ennek a viselkedésnek az utóhangjait magába itta az őket következő generáció, és ennek hatását tapasztalja a Gentoo.
--
http://opensolaris.org/os/project/indiana/
http://www.opera.com/browser/

Ez szerintem csak részben igaz, de van egy kis realitás alapja annyiban, hogy a frissítés sok idő (az meg pénz tudjuk) az egy dolog, mert egy este alatt lefut egy komplett emerge -e word (egy izmosabb gép esetén), de az hogy a 6. csomag után leakad egy telepítés azért mert pl rossz sorrendben kezd telepíteni, vagy reszelj egyet az ebuilden és tedd hozzá a hiányzó dolgait. Na az már gond. Tény hogy a portage sokkal sokkal bonyolultabb, mint bármelyik más csomagkezelő rendszer, de ez nem mentség arra hogy hibás legyen. Na ezért hagyják ott sokan a Gentoo-t. Ha megbízható lenne a portage, és nem lenne ilyen banális hibákkal dugig, ráadásul, ha lefutott hibátlanul a telepítés, egyéb hibák is felléptek. Pl nekem nem volt hajlandó leállni a gép, eljutott egy üzenetik, hogy mindennel kész és leállás, de semmi nem történt (pedig USE flagok rendben voltak garantáltan, minden a telepítve volt ami kel....). Ezen kívül még sok-sok apró hibája volt. Ez szerintem pedig azok hibája akik készítik a distrot. Arch linux lett telepítve a gentoo helyére, és ott minden remekül megy.
------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

Használj portage-2.2-t. emerge után még revdep-rebuild sem kell (csak emerge @preserved-rebuild). Sőt ha közben leállítod akkor sincs nagy baj.

"leakad egy telepítés azért mert pl rossz sorrendben kezd telepíteni"

Ez tényleg k*rva nagy gáz! Bár azért valószínűleg az ebuild-ből hiányzott valami (ez azért stable csomagnál nagyon ritka). Ugye rögtön jelentetted a bugzillában?

gentoon tanácsos előbb emerge -u system kezdeni, majd csak utána world. bár és mindig elkerültem a world használatát. csak system, és utána a főbb csomagok, amik függőségként forgatták a többit is. így kontrolláltabb volt az upgrade.

az arch jó disztrib, de azért mégsem gentoo.

Attól függ ki mit tekint hardened-nek. Hardened Gentooval valóban nem találkoztam idáig. RHEL-ben ha jól látom csak a PAX/grsec nincs gyárilag benne, a többi, amit a Hardened Gentoo-nál írnak (SELinux, Execshield) azt tudja ez is. Cserébe viszont ott van, hogy a RHEL-nél többnyire a széles körben publikált security advisory előtt kapod a lyukas csomagokra az updatet. A Gentoo-nál nem hiszem, hogy lenne ilyenre lehetőségük, lévén, hogy ennek azért van némi anyagi vonzata is. Ráadásul nem látom, hogy nagyon backportolnák a fixeket, tehát a csomagok alap verziófrissítéseivel együtt kell haladnod, ami nem biztos, hogy éles környezetben elfogadható. Alapvetően ez utóbbi miatt horkantam fel a "gentoo, mint szerver" felvetésre.
---
Internet Memetikai Tanszék

selinux, rsbac, grsecurity, propolice.

már régóta dilemma volt Debianon belül, hogy mi a biztonságosabb? nem stabilabb, csak biztonságosabb. a többség a Debian stable mellett volt, de voltak sokan, akik a Sidre esküdtek. az érv a Sid mellett az volt, hogy gyorsan cserélődnek a csomagok, mindig a legfrissebbre. lehet, hogy van benne biztonsági lyuk, de mire exploit születne rá, már régen 5x frissítve lett a csomag a Sid ágban. és ismeretségi körömben nem is tudnék most mondani felnyomott Sid szervert. persze több munka.
a nevezetes Debian SSL bug után imho a Sid logika biztonságosabb választás.
a Gentoo kicsit más történet. azokat a forráskódokat használják, amiket az írója eléggé stabilnak talált releasere. mivel alapból nem patchelgetik össze vissza a Gentoo maintainerek, jó eséllyel nem rontják el az alapcsomagot. persze a server admin rosszul megválasztott USE flagekkel elcseszheti, de egy rendszergazda figyeljen a részletekre:)
annak kicsi az esélye, hogy egy biztonsági hibát előbb foltozzon be egy csomagkarbantartó, mint az eredeti kód írója. így egy frissen tartott Gentoo biztonságos is. természetesen a Gentooban nincsenek annyira régi forráskódok, amikkel a fejlesztője már nem foglalkozik, csak egy egy disztrib maintainere. a RedHatnak egyébként sok eredeti programozója van, ennek meg is vannak az előnyei biztonságban. a gentoo használja is a rendesen a Red6 forráskódjait. a gentoonak további előnye, hogy szinte nincs két egyforma Gentoo rendszer, ezért egy külső támadónak igen nehéz dolga van, ha gyenge pontot akar keresni. a kiadásokra épülő binary disztribek esetében jóval pontosabban behatárolható milyen kód fut rajta.
belső unix shell userek esetében pedig a hardened megoldások széleskörű alkalmazása jelenti a legnagyobb védelmet. hiperaktív egyetemi haxorpalánták hordáinak kordában tartására, remek választás egy hardened gentoo szerver;)
természetesen egy szokásos lamp szervere esetén én is binary párti vagyok, kényelmi okok miatt.

van egy talpon maradt binary hardened linux disztrib az EnGarde Secure Linux. de el kell telnie még egy is időnek és pár kiadásnak ahhoz, hogy lássam a biztos jövőjét. túl sok hardened linux tűnt el az utóbbi években sajnos. a Gentoo jövője a körülötte levő viszontagságos viszonyok ellenére legalább biztosnak látszik.

a sok zoldseget kihagyom, de ezt nem:

> Cserébe viszont ott van, hogy a RHEL-nél többnyire a széles körben publikált security advisory előtt kapod a lyukas csomagokra az updatet.

ezt ugye nem gondoltad at? mert ebbol egyenesen kovetkezik, hogy egy tamadonak eleg a RHEL frissiteseket figyelnie, es az olebe hull minden 0-day hiba, amit mas meg nem tudott javitani. eleg rossz fenyt vetne a RH kozossegi megitelesere, ha ilyen akarcsak egyszer is elofordult volna. esetleg ajanlom meg a vendor-sec meg embargo fogalmak tanulmanyozasat.

annak sincs sok értelme, ha a szerver cpuja a gépidő 99%ában 95%felett idle. a Gentoon a fordítás megoldható úgy simán, hogy a szerverfeladatok ellátásán ez észrevehetetlen legyen.
sok bajom van a Gentoo mai állapotával, fent leírtam. de a fordítás sosem volt a probléma része.

A CPU-s dolog rendben, azt vigye, ha épp nem csinálna semmit, de mi van a memóriával meg a diszk I/O-val? Ok. persze, kisvállalati picipécé, mint szerver, néhány user esetén ezek is bőven túl vannak méretezve, de nagyobb igények esetén elég cinkes azért új vasat venni, hogy a build ne zavarja a napi ügymenetet. (Ok. lehet munkaidőn kívülre is ütemezni, este elindít, aztán reggel megnéz, mit csinált, bár éjjel pl. a mentéseknek kéne az erőforrás...)

Az a normális, hogy van egy tesztkörnyezet, és arra megy fel az új csomag. Ha custom build, akkor sokkal szigorúbban, részletesebben kéne tesztelni, mintha a bináris disztribből jönne, hiszen ez utóbbit mások is tesztelik (azonos sw-környezetben), ergo a hibák is hamarabb kijönnek, míg egy custom build esetén nem lehetsz biztos abban, hogy a sw alapvetően hibás, vagy a customizált build hoz ki valami problémát.

az én problémám úgy 1.5éve amikor váltottam a következők voltak:
#1 lassan jelentek meg a friss .ebuildek, főleg stabilként.
#2 KDE akkori helyzete a Gentooban. még kevésbé voltak friss csomagok. akkoriban menetszették a KDE teamet belső ellentétek miatt.
#3 hosszú ígéretek ellenére, több év után sem volt még jól használható security update rendszer. ennek megvalósítása valóban nem egyszerű egy Gentoo típusú source metadisztribúciónál, és nem is ez volt a döntő érv. mivel a fordítások mindenképp több időt vesznek igénybe, mint egy binary disztribnél, szükség lenne automatizálható security update rendszerre, legalább azoknál a csomagoknál, ahol ez triviálisan elvégezhető. GLSA akkor messze volt ettől sajnos.
#4 a hivatalos web package search rendszer sebezhetőség miatt le lett állítva. hetekig semmi sem volt helyette, majd search funkció nélkül állították csak vissza. a kereső funkciót a mai napig nem sikerült pótolni.
#5 teljes fejetlenség, amit a háttérszervezetet adó Gentoo Foundation környékén uralkodott. nem vagyok az a disztribúció turista, aki havonta új disztribet próbál ki. a 11+ éves Debianom is él és virul egy notebookon, up2date karbantartva természetesen:) ha nincs stabil, jól működő szervezet egy disztribúció mögött, az bizonytalan jövőt jelent, és esetleg kényszerű disztribváltást. ennek mentem elébe.

szerencsétlennek tartom, hogy a Gentoo core team és az alapítvány, nem tiszteli és támogatja azt a munkát, amit Gentoo körül folytatnak userei, félhivatalos fejlesztői. a nagyszerű Gentoo wiki odalett egyik napról a másikra. korábban az internet talán legjobb gnu/linuxos howto gyűjteménye volt. még Ubuntuhoz is gyakran azt használtam. miért nem tudott biztosítani a Gentoo Foundation egy szervert, ennek a nagyszerű projektnek?!

végül egy winchesterhiba miatt hibás lett pár fontos fájl a /usr/ könyvtáraiban. lementettem amit az ép részeket. bár meg lehetett volna javítani a rendszert sok munka árán, vagy újra reinstall sok sok fordítással. a fentiek miatt inkább Ubuntut tettem fel.

imho Daniel Robbins távozásával kezdődtek a gondok. sajnos túl korán távozott a projektje éléről, és nem mentek tovább gördülékenyen úgy a dolgok, mint a Debiannal az alapító Ian Murdock távozása után.

hardened szerver esetében ma is jó választás a Gentoo, talán a legjobb arra a célra. de hardened szerverre szükség igazán csak akkor van, ha shellel be kell engedni sok usert a szerverre futtatási joggal.

( DirtY_iCE | 2009. 10. 31., szo – 12:29 )

ok, ok. azért memóriahasználatot is mérhettek volna, egy kicsit konkrétabban h ez többet eszik, mint az.. mert azért már láttam olyat h ugyan az a program egyik gépen kb. 2x annyi memóriát evett mint a másikon (én -O2-es gentoo gépem vs valami random ubuntu, mondjuk az lehet h 32 bites volt, de akkoris), s az ugye azért már nem jelentéktelen.. ha ezt is figyelembe vesszük, -Os sokszor jobb, mint akár az -O2..

I hate myself, because I'm not open-source.

( LGee | 2009. 10. 31., szo – 14:14 )

A -On -nek kozel sincs akkora jelentosege, mint a multithreading-nek, dobbenet, hogy manapsag milyen keves alkalmazas tamogatja.

( Coornail | 2009. 10. 31., szo – 14:26 )

Abszolult baromsag.

Hint: -march=native

( turul16 v | 2009. 10. 31., szo – 16:54 )

Ami nekem furcsa a forditas idok.
Elvileg a dinamikus linkeles nem lesz gyorsabb -Os -nel, es ha jol emlekszem gentoo profilingozik egyett gcc-n amikor forgatja.
Pusztan a binarisok merete miatt lenne gyorsabb -Os -el?

-funroll-loops -ot hianyolom.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

( simca | 2009. 10. 31., szo – 17:12 )

Az, hogy legtöbbször nagyobb a különbség az ubuntu és bármelyik gentoo között, arra utal, hogy a kernelverziók közti különbség sokkal többet nyom a latba, mint az optimalizálási szintek.

--
"I tried to get into business school, but on the qualifying exams, I passed the ethics test."

( Bodri v | 2009. 10. 31., szo – 19:18 )

Eh, de én nem azért használom, hanem mert szeretem a pl. USE flag-ekkel beállítani, hogy mire van szükségem (többek között) és mire nincs. Pl. jó, ha az XFCE által használt gnome-theme nem húzza magával az egész GNOME-ot, amit más disztrónál szeretne megtenni. Csak az kerüljön bele a Seamonkey-ba amit használok is, stb. Persze mindenhol lehet egyénileg fordítgatni, csak akkor már így kényelmesebb. Amúgy meg a fapadosság miatt sok jó howto volt, amíg meg nem semmisült. ;) Amúgy meg úgy látszik IT sem más mint a többi, itt is kell valamire köpködni. Eddig a SuSE volt a fekete ló, most a Gentoo, csak a köpködők ugyanazok. :(

GCC optimalizációs Gentoo bűnöző ez ugyanolyan sztereotip baromság mint a többi. Agyilag és lelkileg deformált egyedek kreálmánya, akik csak valamihez képest tudják magukat meghatározni.

pl. USE flag-ekkel beállítani, hogy mire van szükségem (többek között) és mire nincs. Pl. jó, ha az XFCE által használt gnome-theme nem húzza magával az egész GNOME-ot, amit más disztrónál szeretne megtenni.
Ennek fő ellenszere az opcionális függőség, amihez sajnos gyakran nem veszik a fáradtságot a csomagkészítők, mert nem minden alkalmazást könnyű megfelelően szétszedni.
---
Internet Memetikai Tanszék

( mzperx | 2009. 10. 31., szo – 21:32 )

Nekem végtelen lehetőség a Gentoo, másoknak végtelen szívás!

Az az igazság, hogy a Gentoo az egyik legjobb op. rendszer ami ma létezik, és amiben az ereje rejlik az egyben a gyengesége is. És itt nem csak arra gondolok, hogy minden forrásból fordul, hanem arra az eszközkészletre is ami az egész op. rendszert beállítja, karbantartja, működteti és annak testre szabhatóságára is. Ezért amikor nem fontos annyira a teljesítmény ill. az pótolható anyagi ráfordítással, akkor a Debian-t használóm. Szeretném minden informatikus látókörét tágítani azzal, hogy elárulom a számítógépeket a web kiszolgáláson kívül bonyolultabb műveletek elvégzésére is használják pl. kvantumkémiai számításokra is ahol az atomok számával a számítási igény és a memória a 6. hatvánnyal nő ill. legjobb esetben is a 3.-onal. Szívesen megnézném annak az arcát - aki itt hangoztatja, hogy mi az a pár fps vagy ms.-um amivel gyorsabb - amikor az ő gépe még 1 napig számolja az egyik molekulát. Egy konkrét kutatási pr. pedig 200-500 számításból áll. (egyszerűsített adatokat tartalmazó hozzászólás)
Akkor ki szív mivel és hány évet?

Egyszer beszélgettem valakivel, aki azt mondta, hogy mindegy hogy pár ms-al gyorsabb, mert holnap vesz egy sokkal jobb gépet, ami 1 s-el lesz gyorsabb. És igaza van. Csakhogy az Én gépem még annál is mindig gyorsabb lesz 1 ms-al! :)

(~6 éve használok Gentoo-t, ~amd64 -O3 stb.. és x86 -O2 rendszereken)

+1
Ha 1000 node teker 1 éven keresztül egy szimuláción, akkor igen kellemetlen tud lenni, ha végén kiderül, hogy "jaj, a -O3-mal fordítva néha hibázik", vagy "jaj, a libnek ebben a bleeding edge változatában vagy egy apró kis bug".

EDIT: egyel feljebb akart menni a reply.
---
Internet Memetikai Tanszék

Ez esetben LFS-t mindenhova :))))

Bár azért mondjuk megnézem, hogy egy gentoo-t mondjuk hogy optimizálsz Mainframe-re ( főleg, hogy a Mainframe erejét adó utasítás készlet nagy részéhez a gcc hozzá se tud szólni.. ). Ha már a komoly számítású feladatoknál tartunk.. :)
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Én úgy tudom, hogy a mainframe a rendelkezésre állásra van tervezve, szóval mikor bekapcsolod kb addig megy míg ki nem selejtezik, szóval amolyan non-stop rendszer. Ha valami meghibásodik benne akkor ki lehet kapcsolni a teljes leállítás nélkül, így a rajta lévő alkalmazások futhatnak tovább gond nélkül.

Core2Duo T7100, 4G, Ubuntu 9.10, 2.6.31

Ez is benne van a körben.. Alapvetően tényleg a nagy rendelkezésre állás a cél emlékeim szerint is, de ha valaki azt mondja nekem, hogy a nagy számításkapacitást igénylő folyamatokra nem alkalmas, akkor azt tényleg szembe fogom röhögni ( pont a magas rendelkezésreállás, és az iszonyat nagy számítási kapacitás miatt használják ezeket a banki rendszereken ). Az tény, hogy nem egy szuperszámítógépnek lett kitalálva ( főként nem az ára miatt ), de nem hinném, hogy ha egy ilyen rendszert összefürtöznénk akkor ne lehetne egy nagyon erős számításkapacitásra kiélezett clustert kapni belőle ( arról ne is beszéljek, hogy ha tényleg olyan kódot ír valaki ami kihasználja az adott gép teljes utasítás készletét, akkor kb 2x-3x akkora teljesítményt is el lehet érni vele )..
Az más tészta, hogy hasonló teljesítményű szuperszámítógépet kb tized annyiért lehet összehozni..
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

mainframe != supercomputer. de látom nem nagyon sikerült megérteni a mondandóm lényegét..
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

úgy tudom számítási kapacitásról van szó. "Ha már a komoly számítású feladatoknál tartunk.." mint írtad azt korábban.
természetesen lehet mondani, hogy egy 200 dolláros netbook helyett vegyél 2000 dolláros "normális" PCt Opteronokkal vagy Xeonnal.
de az már kicsit húzósabb kijelentés lenne, hogy a 125millió dolláros IBM Roadrunner szuperszámítógépet Opteron és PowerXCell helyett inkább System Z mainframekből álló nodeokkal kérnénk. nem baj ha 1milliárd és 250millió dollárba fog kerülni!:D

"Az más tészta, hogy hasonló teljesítményű szuperszámítógépet kb tized annyiért lehet összehozni.."
fizessünk dollármilliárdokat százmilliók helyett, mi?:) ezzel a szöveggel maximum egy részeg dúsgazdag olajsejket lehetne megetetni:) csak az a baj, hogy az iszlám vallás tiltja az alhol fogyasztását, LOL:D

Megbocsáss, de ez itt most hitvita??? Mert akkor nem szóltam egy szót sem inkább és felejtsük el az egészet..

Ha viszont hajlandó lennél reagálni arra is amit mondtam: Pont az áruk miatt nem terjedtek el ebben a közegben.. Viszont a teljesítményüket ezzel még nem lehet nem figyelembe venni..
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Klasszikus példája a hibás érvelésnek.
Egy poénba próbálsz belekötni, majd felszólítod a másik felet: reagáljon a mondandódra. Pedig reagált és meg is cáfolt rendesen. A mainframe-ek hírhedtek a magas ár/teljesítmény arányukról. A megbízhatóságuk miatt vásárolják még ezeket a gépeket, főleg pénzintézetek. Továbbá azok, akiknek fontos a régi céges üzleti programok stabil működtetése. 30 vagy akár 40 éves programok is elfutkároznak egy mai mainframe-en. Sok programnak már nem is él az eredeti írója, de a kód ma is stabilan működik egy mainframe-en. Ez valóban nagyszerű képesség. Üzleti világban ma is megvan az értéke. De ha hatalmas teljesítményre van szükség, akkor a mainframe egy pénznyelő szörnyeteg.

Esetleg ha nem beszélnél el az melett amit mondtam, akkor lehet rájnnél, hogy mi a fészkest is próbálok előadni, és hogy egyáltalán nem arra reagáltál ( pláne nem cáfoltál ) amit eddig mondtam.

"De ha hatalmas teljesítményre van szükség, akkor a mainframe egy pénznyelő szörnyeteg."

Sosem állítottam az ellenkezőjét.. Azt se mondtam, hogy a mainframe olcsó.. Csak annyi mondtam, hogy az az utasítás készlet ami a mainfrem benne van jóvalta nagyobb sebességet lenne képes nyújtani, ha azt valóban használnák is.. Jelenleg a kutya se használja azt, helyette a linux alkalmazások 2 módszer közül választhatnak:
- veszel a gépbe külön Linux card-ot és akkor az majd neked szépen leemulálja a teljes 8086os utasításkészletet és átfordítja a mainframe-esre
- A mainframe-es utasításkészletre próbál hagyatkozni, ám ebben az esetben ott szívod majd erőteljesen meg, hogy a gcc jó ha 30 utasítást használ ( 20on akárhányat emlékeim szerint ) a 100ból. na most pont a maradék utasításkészletben vannak olyan elemek, amelyek kb képesek lennének kiváltani 2-3 linux által használtat ( tehát amit a linux 2-3 vagy több utasításból old meg, azt a mainframe alatt meg lehetne oldani 1el is ).

Tudomásom szerint jelenleg az utóbbi az amit a zSeries-re fordított linuxok előszeretettel használnak..
Ha ezek után se vagy képes felfogni amiről beszélek, akkor részemről a vita lezárva..
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Ezt is félreértetted. :-) Nem szuperszámítógép elé kellene leülnöd egy benchmark-kal, hanem egy mainframe elé. Egy AMD Opteron-okból álló szuperszámítógépnek épp eléggé jól kihasználják az AMD-64 utasításkészletét. :-) Végig azzal érveltél: a mainframe hatalmas számítási kapacitásra képes ha kihasználja a programozó a széles utasításkészletét. Hát utasításból valóban jó sok van egy mainfame-en. De ennek teljes kihasználásával sem lehet 2x-3x teljesítményt elérni. Különben is mihez képest 2x-3x?
Szóval mainframe előtt kellene demóznod egy benchmark-al a hatalmas növekedést. :-))

Mellesleg a >Gentoo működik IBM mainframe-ken. :-))) Ugyanazt a gcc-t használja, mint a Suse, vagy a Vörös Kalap. Ezekkel a mainframe linux-okkal szép summát keres az IBM. :-) Már a kiinduló felvetésed is téves logikán alapult, ezt próbáltad nem túl szerencsésen védelmezni. Jobb lett volna hallgatni. :-D

Szerintem akkor se jobb HPC-re annó olvastam hogy pl a z10 egy műveletet egyszerre több procin is elvégez és ha eltérés van akkor biza kiabál. Nahh már most ez nem éppen HPC teljesítmény dobó feature, viszont banki tranzakcióknál baromira nem mind1, hogy ja valamit elszámolnak, mert utána már nehéz visszacsinálni ;>
Szóval gyorsak a mainframe is, de a HPC től messze vannak azért, viszont adatbiztonság rendelkezésre állás miatt pont alkalmas banki szektorokban, tranzakciószámításokra, vezérlésekre stbstb.

Core2Duo T7100, 4G, Ubuntu 9.10, 2.6.31

A prociban két műveletvégző egység dolgozik azonos bemeneti adatokkal, a kimenet megy komparátorra. Ha azonos, akkor jó. Ha nem, akkor újrajátszik, ha akkor jó -- akkor jó. Ha nem, akkor másik procival csinálja végig, az aktuális procit meg kiiktatja. Legalábbis én ilyesmire emlékszem...

1 fokkal jobb, de a célnak még mindig nem felel meg, tekintve, hogy a nagyja a gcc-ből van átemelve.. A fő probléma az, hogy a mainframe belső utasítás készlete jóvalta több, és használhatóbb utasítást ismer, mint amit a PC-k. Ennek pont az az előnye, hogy bizonyos folyamatokat jóvalta gyorsabban le tudsz futtatni ezen utasításokat használva, mint a normál PC-s hívásokkal. Sajnálatos módon pont ezek az utasítás hívások hiányoznak a gcc alól, ami azzal jár, hogy azt amit meg lehetne csinálni 1 utasítással, azt a gcc 6 másikkal oldja inkább meg.. Ez pedig nálam erős optimalizálatlanságot jelent..
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

( janoszen v | 2009. 11. 01., v – 11:36 )

Istenem, de jó volna már, ha elfelejtenék azt, hogy a Gentoo gyorsabb. Gyakorlatban semmivel nem gyorsabb, mert nem az a 0.1% CPU számít. A Gentoonak a optimalizáláson kívül kismillió fícsöre van, amik sokkal de sokkal többet érnek az optimalizálásnál.

Csak hogy példát mondjak: nem kell saját csomagot építeni azért, hogy mondjuk a PHP egyszerre bírjon LDAP és GeoIP támogatással (ld. Debian). Bekapcsolom a flaget, 90 másodperc alatt újraforgatom és boldog vagyok. Vagy nem kell új csomagot építenem azért, hogy egy patchet, fícsört adjak hozzá, egyszerűen lemásolom az Ebuildet, berakom azt az 1 sort (epatch my.patch) és boldog vagyok.

A Gentoo a világ legjobb Linux buildrendszere.

( uid_16313 | 2009. 11. 01., v – 13:53 )

Akárki akármit mond, szerintem semmi sem indokolja a forrásból telepítést, ha a végeredmény optimalizáltságát és a ráfordított idő arányát nézzük. A teszt tanulsága is ez. Döntse el mindenki, hogy megéri-e neki.
Nekem nem éri meg. Pedig én fordítottam már FreeBSD desktop-ot is forrásból, stb...
Abszolút nem éri meg. Bizonyos esetekben valóban lehet teljesítménynövekedés, de ez nem akkora, mint az az idő, amit pluszban elvisz a sok make ( persze, vannak akik grid-ben forgatnak op.rendszert :) 2 mp alatt, lelkük rajta ). Az áramfelhasználásról, és a vasigénybevételről nem is beszélve.
Minek táplálja a procim 100%-on órákig az áramszolgáltatót azért, hogy saját fordítású szoftvert rakjak fel, amikor a bináris 10%-os CPU terhelés mellett 5 mp alatt feltelepül.

Akinek meg ez a hobbija, az úgyis örül neki, azért csinálja. Van kedve hozzá, ideje is, meg erős vasa.

--
robyboy

Szerintem a Windows nem felhasználóbarát.
Ha az lenne, nem utálnám.

( Galadh Ereb | 2009. 11. 01., v – 15:09 )

szerk.: bocs, veletlenul jott a gyokerbe a hozzaszolasom.

( axt v | 2009. 11. 01., v – 19:34 )

Tegye fel a kezét aki a "sebessége" miatt használ gentoo-t ...
(bár gondolom már írták előbb is ezt)