Debian vs Gentoo / Test

Dwokfur:
"(vedd észre: -c3 és nem -c1)"
dunno, hdparm manpage: "and 3 to enable 32-bit data transfers with a special sync sequence required by many chipsets."
jo lenne tudni, mi tartozik a "many chipset" ala; elkepzelheto, hogy a man nem teljesen friss, legalabbis a 2.0.x kernelekre van benne csak hivatkozas;

"ahol yy="
szinten man: "Apart from that, use of this flag is seldom necessary since most/all modern IDE drives default to their fastest PIO transfer mode at power-on."
mennyire biztonsagos ezt piszkalni?

hoznak ezek vmi sebessegjavulast?
mer pld a '-m' optimalizalasa nalam semmit;

[quote:a1743157ca="snq-"][quote:a1743157ca="thuglife"]...mindekinek ajanlom a figyelmebe a http://www.funroll-loops.org/ oldalt...

a http://greenfly.org/mes.html Q&A resze is jo

hogy a legtobb gentoos mandrakerol valtott? en eddig egyel sem talalkoztam, de ugytunik nem ismerek eleg gentoo usert.

imho a legtöbb genroos debről váltott vagy slackról :wink:

[quote:f0266026fa="MSD"]hogy a legtobb gentoos mandrakerol valtott?

aaazt nem tudom, de a cikkben valszeg azert szerepel, mert a mandrake csomagjai voltak/vannak 586-ra porgetve (nem is sima gccvel, erdekes flagekkel), es ez valszeg ugyanannak a kozonsegnek tetszik, aki harminc-haromszazezer szazalekos gyorsulast el meg gentoo alatt is

Hogy sikerült megoldani az optimalizációt mplayernél Gentoon? ;)

a gentoo fordítósdis játékában nem az optimalizáció a nagyon jó, hanem a use flagek :wink:

Atyaúristen te úgy vagy "fear of performance", h nem ismered a hdparmot? Lehet, h az egesz gentoo így fejlődött ki?
Ezek szerint ezzel nem ismertet meg a nagy Gentoo?????
Érdeklődéssel vártam a nagy eredményeket, de ez nagy csalódás...
Ha küldesz egy hdparm -I /dev/... eredményt, akkor a sok lassú debiannal rendelkező ember ki tud segíteni, mert ismerik a linuxot...

[quote:789f4ef89b="wwrreecckk"]Atyaúristen te úgy vagy "fear of performance", h nem ismered a hdparmot? Lehet, h az egesz gentoo így fejlődött ki?
Ezek szerint ezzel nem ismertet meg a nagy Gentoo?????
Érdeklődéssel vártam a nagy eredményeket, de ez nagy csalódás...
Ha küldesz egy hdparm -I /dev/... eredményt, akkor a sok lassú debiannal rendelkező ember ki tud segíteni, mert ismerik a linuxot...

Azt hiszem ennek itt semmi helye. Menj at a flamebe.

[quote:992d2345a5="snq-"][quote:992d2345a5="MSD"]hogy a legtobb gentoos mandrakerol valtott?

aaazt nem tudom, de a cikkben valszeg azert szerepel, mert a mandrake csomagjai voltak/vannak 586-ra porgetve (nem is sima gccvel, erdekes flagekkel), es ez valszeg ugyanannak a kozonsegnek tetszik, aki harminc-haromszazezer szazalekos gyorsulast el meg gentoo alatt is

Hat en pl. Mandrakerol valtottam Gentoora, de egyiket sem az altalad emlitett okbol kifolyolag valasztottam. Szerintem egyiknek sem a sebessegben vagy az optimalizacioban keresendo a hasznalati erteke.

A teljesitmenyteszteket egyebkent erdeklodesbol meg szoktam nezegetni, de legkevesbe sem hatnak meg az ott kiadodo eredmenyek. Ugyanis ez nem disztribuciofuggo (mar amennyiben eltekintunk az esetleges disztribucio-specifikus patchekrol az egyes programok vonatkozasaban), hanem fordito, fordito-parameterezes, es hardware fuggo. Raadasul a forditot kulonbozo csomagok eseten kulonfelekeppen kellene parameterezni a legjobb teljesitmeny eleresehez. Na most ezzel meg en nem vagyok hajlando az idomet tolteni.

Ahol tenyleg lehet nyerni az nem a forditasi optimalizacio, hanem a fordito maga, na meg persze a hardware.

Én win alatt sem nézegettem a gépem teljesítményét, hogy jobb lett-e hangyányit :-).

A gentoo egyszerűen magával ragad, ahogy percről pecre felfedezed. Menet közben mikor tanulod, olyan érzésed van, hogy ezt tudtad eddig is, de nem volt sikerélményed, itt pedig van.

Nem leírható, nem mérhető. Ezt érzed. A mért értékek pedig akkor sem zavarnak, ha nem a javamra (gentoo javára) igazolnak, hanem ellene. Minden annyit ér amennyit adsz érte. A gentoo-ért az időddel fizetsz. Cserébe a gentoo megtanít linuxul és gentoo-ul (ez szépen hangzik ha kimondom :-D). Nem jobb, nem rosszabb. Egyszerűen más, a jó értelemben véve. Mire kitapasztalod a flageket, egészen belejössz abba amitől esetleg féltél. Szvsz gentoo alatt megjöhet a kedved a programozáshoz is, ha esetleg előtte nem tudtál. (mint pl én :-D ) UHU alatt kernelt fordítani sem volt kedvem, mert pl az 1.0-ás alatt nem tudtam a 2.6.x szériából egy darabot sem lefordítani. Gentoo alatt meg mint a karikacsapás. Ezt érezned kell. Ha érzed más rendszer alatt, akkor azt ne add fel! Használd és légy rá büszke, hogy megtaláltad, igen Ő az! Mindegy melyik az a rendszer.

dzsolt

[quote:e068a6c895="dzsolt"]UHU alatt kernelt fordítani sem volt kedvem, mert pl az 1.0-ás alatt nem tudtam a 2.6.x szériából egy darabot sem lefordítani. Gentoo alatt meg mint a karikacsapás. Ezt érezned kell. Ha érzed más rendszer alatt, akkor azt ne add fel! Használd és légy rá büszke, hogy megtaláltad, igen Ő az! Mindegy melyik az a rendszer.

dzsolt

Ezert maradok en a Debiannal. :D

A Gentoo-t kiprobaltam tetszett (tetszik), de nincs idom a forditgatasok kivarasara.

Ennek ellenere, ha valaki megkerdezi... Ja-ja valaszd a Gentoo-t, ha gondolod. Jo kis rendszer az. De ezt elmondom a Debianrol is. :wink:

[quote:a70745c8b4="vmiklos"]a gentoo fordítósdis játékában nem az optimalizáció a nagyon jó, hanem a use flagek :wink:

[quote:a70745c8b4="fdavid"]Szerintem egyiknek sem a sebessegben vagy az optimalizacioban keresendo a hasznalati erteke.

a fenti kifogas-patternek akkor jonnek elo, ha kiderul, hogy megsem 30-300ezer literrel lesz gyorsabb az 'ls', ha 686-ra porgeted

[quote:a70745c8b4="dzsolt"]A gentoo egyszerűen magával ragad, ahogy percről pecre felfedezed. Menet közben mikor tanulod, olyan érzésed van, hogy ezt tudtad eddig is, de nem volt sikerélményed, itt pedig van. ... Nem leírható, nem mérhető. Ezt érzed. ... Cserébe a gentoo megtanít linuxul és gentoo-ul... Szvsz gentoo alatt megjöhet a kedved a programozáshoz is...

http://www.funroll-loops.org/ --teach-me-unix ala ezt elpostolhatnad, ne csak mi rohogjunk :)

[quote:f8d5886974="snq-"]

http://www.funroll-loops.org/ --teach-me-unix ala ezt elpostolhatnad, ne csak mi rohogjunk :)

Köszönöm, hogy megtiszteltél eme megnyilvánulással. Az amit feljebb írtam, az én vok, ez meg Te!

dzsolt

Erdekes. Ha az eddig elert eredmenyek szazalekos kulonbsegenek atlagat vesszuk, az optimalizalt csomagok 1%-al lassabbak.. Ezt azert mondjuk nem ertem.

[quote:bd93fd11da="snq-"][quote:bd93fd11da="vmiklos"]a gentoo fordítósdis játékában nem az optimalizáció a nagyon jó, hanem a use flagek :wink:

[quote:bd93fd11da="fdavid"]Szerintem egyiknek sem a sebessegben vagy az optimalizacioban keresendo a hasznalati erteke.

a fenti kifogas-patternek akkor jonnek elo, ha kiderul, hogy megsem 30-300ezer literrel lesz gyorsabb az 'ls', ha 686-ra porgeted

Nehezen tudok rajonni, hogy mi okozhat vkinel ilyen merhetetlen frusztraciot.

Tudod, masok szavainak kiforgatasa nem visz kozelebb az igazsaghoz, ezert megkerlek, hogy ne ertelmezd masok hozzaszolasait. Ha vmit nem ertesz, inkabb kerdezz.

Erzelmeket vinni muszaki kerdesekbe, hat legkevesebb sajnalatra melto.

[quote:1e4e8fb095="wwrreecckk"]Atyaúristen te úgy vagy "fear of performance", h nem ismered a hdparmot? Lehet, h az egesz gentoo így fejlődött ki?
Ezek szerint ezzel nem ismertet meg a nagy Gentoo?????
Érdeklődéssel vártam a nagy eredményeket, de ez nagy csalódás...
Ha küldesz egy hdparm -I /dev/... eredményt, akkor a sok lassú debiannal rendelkező ember ki tud segíteni, mert ismerik a linuxot...

leborulok nagyságod előtt, de megtisztelnél vele ha nem nyilvánítanád ki véleményedet :wink:

[quote:bde507a79c="FeriX"]
Gentoora vannak optimalizált csomagok. Nem kell fordítani. Ez egy kicsi de bosszantó tévhit.

Hogyan lehet ezeket az optimalizat csomagokat halozaton keresztul telepiteni? Ok, van package cd, de net-rol?

[quote:bde507a79c="FeriX"]
Én csak azért fordítom, és tesztelem a Gentoot hogy megéri-e a Debianomat pentium4-re optimalizálva lefordítani, és ha igen meg is osztom a csomagokat mindenkivel.

Tenyleg csinalsz esetleg pentium4-re optimalizalt deb csomagokat??? 8O
Valoban nem lenne rossz, ha ezeket megosztanad majd. :)

Totya

"sima" libc6 es libc6-i686 ( http://packages.debian.org/testing/libs/libc6-i686 ) osszehasonlitasara csinalt mar vki teszteket?

[quote:108854adec="FeriX"]Befejeztem a tesztelések első fázisát. Kérésre %-ao arány is ott van.
Teszt 1 és Teszt 2 lefutott. Az eredmények itt:

http://www.hup.hu/modules.php?name=Forums&file=viewtopic&t=2437

Amire jutottam, az kicsit megdöbbentett. A hdparm a lelke mindennek. A Debian telepítő erről nem szól, ezért szerintem sokan nem is használják. Vagy ha hallottak is róla, nem használják. Az első tesztben használtam, ezért elenyésző a különbség a két rendszer között. A másodikban elfelejtettem.
Ez lehet hogy megérne itt egy szavazást.

A többi tesztet is elkezdem hétvégén.

Várom a visszajelzéseket és ötleteket.

Ez a 3 MB/sec biztos hogy nem jó végeredmény. valami nagyon extrém terhelés közben futhatott le, másra nem tudok gondolni.
Az én 20 gigás seagatem udma66-al

DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 *udma4 udma5

is HUP böngészés mellett KDE konzol alól ad ki 15-20 MB/sec értékeket. "üresjáratban" ez
akár 32 MB/secig is felmegy. (kernel az a jó kis agyonpacsált 2.4.18-as), sz'al ezt a hdparm-ot debian alól sz'Tem mégegszer futtasd le, mert ez a 3 MB/sec ez itt sehogy sem jövi ki magát.
hdparm -i mit fut?

Ezt nehezen tudom elhinni, hogy ennyi mármint 3 MB/sec. :?
(hogy fordítottad a kernelt?).

mos látom, hogy kernel-image-t használtál (2.6.7-686-smp):
ebben nincs minden IDE motyó modulban véletlenül?
bár dma support mintha lenne a configban, de ezt így txt nézve a .config-ot kicsit nehéz eldöntetni.

Ötlet: esetleg mi lenne, ha a gentoo-n használt kernel configfájlját(de csak azt!) áttennéd a debianra, és
CONFIG_M686-ra módosítanál benne...?

[quote:7b000d5ef4="fdavid"][quote:7b000d5ef4="snq-"][quote:7b000d5ef4="vmiklos"]a gentoo fordítósdis játékában nem az optimalizáció a nagyon jó, hanem a use flagek :wink:

[quote:7b000d5ef4="fdavid"]Szerintem egyiknek sem a sebessegben vagy az optimalizacioban keresendo a hasznalati erteke.

a fenti kifogas-patternek akkor jonnek elo, ha kiderul, hogy megsem 30-300ezer literrel lesz gyorsabb az 'ls', ha 686-ra porgeted

Nehezen tudok rajonni, hogy mi okozhat vkinel ilyen merhetetlen frusztraciot.

Tudod, masok szavainak kiforgatasa nem visz kozelebb az igazsaghoz, ezert megkerlek, hogy ne ertelmezd masok hozzaszolasait. Ha vmit nem ertesz, inkabb kerdezz.

Erzelmeket vinni muszaki kerdesekbe, hat legkevesebb sajnalatra melto.

Mindig vannak aktuális hype-ok. Az emberek egy része hype-ol. Ezek egy része fikázza azokat, akik nem tartanak velük, a többi nem kötöszködik. A hype-ot elkerülőkből is többféle van. Az egyik fikázza a hype-olókat, és van olyan, amelyik nem kötöszködik. Egy részük annyira fikáz, hogy egy anti-hype-ot formál. Ezek egy része a sznobok közé tartozik, aki más akar lenni, csak hogy beszólhasson a többségnek. Nagy különc. És van még egy fajta: az űber. Ő mindenek felett áll, mindenkinél okosabb, tudja a frankót. Osztja is az észt, és próbál úgy tenni, mintha nem venne a hype-harcban részt, miközben nyakig belemerül.

Régen maga a Linux hype volt. Lehetett szakeszolni a windows-os haverokat. De mit tehet a sznob, ha már senkinek sem új a linux? Átvált *bsd-re, hogy szakeszolhassa mind a linux-osokat, mind a windows-osokat. Így lett egy idő után a BSD is hype. Ekkor vagy lehet keresni egy bizonyos BSD-t, vagy egy Linux distro-t. Ne legyen elterjedt. Szóval a FreeBSD, vagy a Debian nem jó. OpenBSD, Gentoo: az igen. Közben az űber fentről folytathatja az összes leszólását (kivéve, amit ő használ).

És mi van akkor, ha egyik-másik hype-olt OS/disztró tényleg hordoz értékeket? Mi van, ha valaki kicsit mélyebb betekintést nyer a Linux-ba a Gentoo-n keresztül? Tán baj?

Van amit ha a seggünket a földhöz verjük, akkor sem lehet a másikkal megcsinálni. Az egyik támogatja a CARP-ot, de többproceszsoros rendszerek támogatásában lemaradásban van. És van amelyik olyat kínál (USE, rc-update), amit az űber kedvence nem. Ez az űbernek rohattul nem teccik.

De ez vanik, jól. Ha melenazik, akkor is.

Dw.

Gentooban vannak csomagok amik nem viselnek el különbő "agresszívebb" CFLAGeket. Az ebuildben ezek le vannak tiltva. Ilyen például az OpenOffice.

[quote:fa6ea326c8="Dwokfur"]És van még egy fajta: az űber. Ő mindenek felett áll, mindenkinél okosabb, tudja a frankót. Osztja is az észt, és próbál úgy tenni, mintha nem venne a hype-harcban részt, miközben nyakig belemerül.

es van +1 fajta, aki megiteli, hogy ki uber, es ki nem, tudja a frankot, osztja is az eszt, es probal ugy tenni, mintha nem venne a hype-harcban reszt, mikozben nyakig belemerul

[quote:fa6ea326c8="Dwokfur"]Mi van, ha valaki kicsit mélyebb betekintést nyer a Linux-ba a Gentoo-n keresztül?

errol a funkcionalitasrol bovebbnen is irhatnal

[quote:fa6ea326c8="Dwokfur"]És van amelyik olyat kínál (USE, rc-update), amit az űber kedvence nem. Ez az űbernek rohattul nem teccik.

az rc-update dologgal kapcsolatban nem tudom pontosan milyen egyedi megoldasra gondolsz; a USE tema viszont erdekesebb, mert ha uber kedvenc linux-terjeszteseben letezne, akkor uber kedvenc linux-terjesztesenek egyetlen kiadasara sem irhatnak ra, hogy stable

[quote:f701300650="Dwokfur"] És van még egy fajta: az űber. Ő mindenek felett áll, mindenkinél okosabb, tudja a frankót.

És van aki bele sem szól, mégis ő a legűberebb. Ez volnék én :D

[quote:4ebfb4258e="fdavid"]Nehezen tudok rajonni, hogy mi okozhat vkinel ilyen merhetetlen frusztraciot.

Um, jo kerdes. Tobb altalam a temaban sokra tartott ember hasznal Gentoot mindenfele celra. A gentoo.org-os ismertetoket/leirasokat olvasgatva (tehat a kiprobalas elott) en is lattam benne fantaziat. Tehat nem ezzel van a baj. Valahol ott telt be a pohar, amikor "stable" Gentoo-rol kezdtek egyesek irni (Woody-val hasonlitgatva), meg testreszabhatosagrol.

[quote:4ebfb4258e="fdavid"]Erzelmeket vinni muszaki kerdesekbe, hat legkevesebb sajnalatra melto.

Egyetertenek, ha valoban muszaki kerdesekrol lenne szo.

[quote:9362e8f61c="FeriX"]Teljesen mind1 mit állítok be a CFLAGS-be, de ha nem állítok be semmit akkor is detektálja a legoptimálisabb konfigurációt:
(...)
És azt, hogy ezt, miként lehet felülbírálni, nem tudom, de az én esetemben ez így jó.

ha a CFLAGS környezeti változó be van állítva, akkor azt használja, és warningol 1et, h lehet, h gondjaid lesznek :wink:

Tehát eme rész már a flame kategória. Lehet én indítottam :-) Bocs. Folytassuk ott, ha vkinek van kedve hozzá. Itt meg szerepeljen a deb-gentoo tovább.

dma nelkul szokott ennyi lenni.
Legalabbis most en a laptopommal szenvedtem egy ideig amig sikerult a kernelbe dma tamogatast forditani es a hdparm-al mukodesre is birni, addig 2-3MB/s korul mozgott, mosmar 32 :)

es van +1 fajta, aki megiteli, hogy ki uber, es ki nem, tudja a frankot, osztja is az eszt, es probal ugy tenni, mintha nem venne a hype-harcban reszt, mikozben nyakig belemerul

Van olyan is, akinek az arcán el kezd rángatózni egy kis izom, amikor nagyokosokat lát, de nem próbálja távol tartani magát a hype-harc-tól.

errol a funkcionalitasrol bovebbnen is irhatnal

Ha egyeseknek jobb az, hogy az illető, aki a Gentoo-tól lenyűgözve áttért Linux-ra inkább marad a Windows-nál, akkor annak a pcforum.hu-t ajállom. Sting-gel, a magyar Rob Enderlével lehet, hogy megtalálja a közös hangot.
Nem tom miért baj az, ha dzsolt-nak megtetszett? Mi fekáliáért baj az?

az rc-update dologgal kapcsolatban nem tudom pontosan milyen egyedi megoldasra gondolsz; a USE tema viszont erdekesebb, mert ha uber kedvenc linux-terjeszteseben letezne, akkor uber kedvenc linux-terjesztesenek egyetlen kiadasara sem irhatnak ra, hogy stable

Rc-update: az egész init rendszert kellett volna írnom.
USE téma: VÁ! Eszt jól megaszontad! Sajnos mára már nincs több időm erre.

Üdv,
Dw.

Asztali gépen is volt ilyen nekem, hogy a demian kernelével nem akart menni a dma-s vinyóelérés. 2.4.25-ös vanilla fordítása megoldotta a problémát.
A 3 Mbyte/sec tényleg nagyon kevésnek tűnik. Most nálam (Mandrake 9.2, 2.4.22-36mdk kernellel):
/dev/hda:
Timing buffer-cache reads: 492 MB in 1.99 seconds = 247.24 MB/sec
Timing buffered disk reads: 140 MB in 3.03 seconds = 46.20 MB/sec
(Kde alatt, konsole-ból...)
Lehet, hogy a többi debianos teszt (tar, kernelfordítás) is sokat javulna, ha menne a dma...

Üdv,
L. Á.

Hozzászólok, de csak azért, hogy bosszantsalak! :wink:

Nos, úgy gondolom, hogy én mindaddig nem mérnék össze két dolgot, amíg nem ismerem őket valamennyire.
Pl.
Nem versenyeztetnék két motorcsónakot (úgy, h én vezetem), ha nem tudom, hogy lehet az egyiken sebességet váltani (tényleg, van rajtuk sebességváltó? :))

Ezek a tesztek így tényleg csak arra jók, hogy megtudjuk, hogy egy ember, aki kap két frissen telepített rendszert, milyen teljesítménykülönbségeket kaphat.
Meg arra, hogy flamewar-t gerjesszenek, amibe én is belekezdtem, amiért bocs :roll: .

[quote:1c8a10007e="FeriX"][quote:1c8a10007e="Aewyn"][quote:1c8a10007e="Dwokfur"] És van még egy fajta: az űber. Ő mindenek felett áll, mindenkinél okosabb, tudja a frankót.

És van aki bele sem szól, mégis ő a legűberebb. Ez volnék én :D

És utánna meg az Űberek Űbere és így tovább. Azt nem értem, hogy aki nem űber és itt szívja a másik vérét, az meg visszaszív, miért nem nyit magának egy topikot és szívja ott a sajátját. :twisted:

Igazad van FeriX, bocs. Az a baj, hogy volt egy kis szabadidőm. Azért várjuk, hogy mi lesz a teszt v2.0 eredménye.
Sqn-: igazából nincs veled bajom, remélem nem haragudtál meg rám nagyon.

Üdv,
Dw.

Dwokfur: senkivel sincs bajom:) Igazabol mi egy nagy csalad vagyunk, 95%-unknak ott az XP az otthoni desktopjanak a legelso particiojan; az meg hogy mi van meg a vinyon, igazan ne legyen vita targya:)

[quote:05c8a2e36e="snq-"]...harminc-haromszazezer szazalekos gyorsulast el meg gentoo alatt is...

"Ígymagyaráz Taki Árpi"
az egyszerű gentoo-s
Szerintem a gentoo akkor is a középhaladó linuxosok kedvelt rendszere, mert ők azok akik:
- sokat lehet belőle tanulni [kíváncsiak]
- sokat lehet vele szenvedni (hozzáértés nélkül) [mazohisták]
- igazán hozzáértőnek érzik magukat a telepítés közben [egoisták]

A gentoo filozófia "www.gentoo.hu" szerint azért jó mert gyors, hanem mert nem erőlteti rád a választásokat, (pl. a debian az eximet :x ) nem erőlteti veled az interakciót.

Ez mind igaz, de épp ezért, csak a nagyon profiknak ajánlott belőle komoly szervert alkotni.
Középhaladóknak viszont tanulásra kíválló! És nem szabad őket utálni azért, mert istenítik!

amugy sztem tobbet mutatnanak a benchmark osszehasonlitasok, ha a szazalekos kulonbseg is ott lenne.
2% -3% 0.3% -2.3% .....

FeriX:
"Amire jutottam, az kicsit megdöbbentett. A hdparm a lelke mindennek. A Debian telepítő erről nem szól, ezért szerintem sokan nem is használják. Vagy ha hallottak is róla, nem használják."
megintcsak a debian_desktopomra kell hivatkoznom:
egyreszt bf24 -gyel inditva a telepitot eleve 2.4 kernelt rak fel, ahol ritkabban jon elo ez a problema; masreszt:

(...)
dma:
az alapkernel nem mindíg kapcsolja be a merevlemezek dma támogatását kompatibilitási okokból;
telepíteni: hdparm - alcsonyszintű merevlemez beállítások;
ellenőrizd, hogy minden merevlemezre ('fdisk -l') be van kapcsolva a dma ('hdparm -i /dev/hdx', ha vmelyik dma sornál van a *, akkor oké);
ha nem kézzel bekapcsolni: 'hdparm -u1 -c1 /dev/hdx'
a boot loadert beállítva ez automatizálható, a "kernel(...)" sor végére szúrj be egy "idex=dma" részt;
(...)

snq-:
""sima" libc6 es libc6-i686 ( http://packages.debian.org/testing/libs/libc6-i686 ) osszehasonlitasara csinalt mar vki teszteket?"
emreg probaltam ki ezt a csomagot, mivel eddig a pax megakadalyozott a hasznalataban (minden sig11 volt), de a 2.3.2.ds1-14 libc6 alatt vegre megszunt ez a problema (meg a "disable vsyscall" vedelm is mukodik);
tesztet nme vegeztem (egyebkent is -grsec es -ck mix kernelem van, ergo mas tuning is szerepet jatszik), de oszinten nem vettem eszre semmi kulonbseget; igaz anyira konnyu desktopot hasznalok, hogy tenyleg az io a legszukebb resz; (mondjuk egy vim -en mar nincs "mit" gyorsitani);

A Gentoo-s CFLAG, amit használsz, közel sem aknázza ki a P4 processzorokban rejlő plussz tudást. Az a terület, ahol a legnagyobb sebességkülönbség van az i386 és a P4 bővített utasításkészlet között, az sse/sse2 használata az i387 helyett, illetve a plussz mmx utasítások is jól jönnek néha. Egy meglehetősen konzervatív CFLAGS:

[code:1:2f8d30d263]CFLAGS="-march=pentium4 -O2 -mfpmath=sse -mmmx -msse2 -fomit-frame-pointer -fforce-addr"[/code:1:2f8d30d263]

[quote:3f07177b06="snq-"]Dwokfur: senkivel sincs bajom:) Igazabol mi egy nagy csalad vagyunk, 95%-unknak ott az XP az otthoni desktopjanak a legelso particiojan; az meg hogy mi van meg a vinyon, igazan ne legyen vita targya:)

Ez teccett!
Nekem speciel Win2000, Win2003, Gentoo, És Debian Sarge van fent. XP soha nem volt rajt :lol:
Természetesen a debian a legelső. Bár a winyó végén lévő oprendszerek rendelkeznek egy kis sebességtöblettel, mégis a debian hasít a legjobban. Az igazán objektív tesztek ezzel is számolnak !!!

[quote:9f6c97e2f5="johans"]A Gentoo-s CFLAG, amit használsz, közel sem aknázza ki a P4 processzorokban rejlő plussz tudást.

es a fordito sem

[quote:063179d60e="FeriX"]Hatalmas Gentoo-s istenek,

Egy nagyon fontos kérdés.

Ha megállt a "emerge -ev world" hogy tudom folytatni a fordítást onnan ahol megállt?

Nem vagyok "Gentoo-s isten", sőt még programozni sem tudok igazán, de válaszolok.
Valahol azt olvastam, sőt tapasztaltam is, hogy Ctrl+c után is ott folytatja az emerge, ahol abbahagyta.
Nem esküszöm meg rá, hogy a -ev -re is megteszi. De megéri a próbát, ha ujra elindítod ugyanazt a parancsot.

Felix hajlanó lennél kirakni a make.confodat ide?

[quote:fe11eabe01="fellow"]
"(vedd észre: -c3 és nem -c1)"
dunno, hdparm manpage: "and 3 to enable 32-bit data transfers with a special sync sequence required by many chipsets."
jo lenne tudni, mi tartozik a "many chipset" ala; elkepzelheto, hogy a man nem teljesen friss, legalabbis a 2.0.x kernelekre van benne csak hivatkozas;

Neked van igazad. Valszeg a legtöbbeknek a -c1 a jobb, mert nincs egy kis "overhead".

[quote:fe11eabe01="fellow"]
"ahol yy="
szinten man: "Apart from that, use of this flag is seldom necessary since most/all modern IDE drives default to their fastest PIO transfer mode at power-on."
mennyire biztonsagos ezt piszkalni?

A PIO mód elmarad a DMA-tól (azonos sebességnél prociterhelés szempontjából),
Azt kell beállítani, amit tud a chipset is, meg a vinyó (hdparm -i) is. A tunning kisérlet adatvesztéssel járhat.

[quote:fe11eabe01="fellow"]
hoznak ezek vmi sebessegjavulast?
mer pld a '-m' optimalizalasa nalam semmit;

A -c1 biztos hoz javulást, az -X bekapcsolása pedig nagyon sokat hozhat, ha eddig a vinyó nem volt UDMA módban.

Üdv,
Dw.

ha jol tudom csak akkor folytatja ha egy csomagot allitottal le. ha ujra beirod az emerge -ev world-ot akkor elorol elkezdi ujraforgatni azokat is amiket mar leforgatott.
es kikerem magamnak nincs semmilyen windows a vinyomon! :)

Szerintem ez a teszt NEM az i386 és pentium4 re fordított programok közti külömbséget vizsgálja, hanem a ix86 és a pentium4 közöttit. Debian sid csomagjai nem i386-osak, hanem ix86 ak, aminek i386 a minimumja.

Ha jól tudom i786 platform nem létezik,
A K7-s processzorok, és a pentium4 -ek melett szerintem nem véletlenül nincs feltüntetve az i786 arhitektúra, mivel igazából i686 - osak csupán, extra bővítésekkel.
Az amd x86-64 processzorcsalád, pedig már 8-dik generációnak nevezi magát, a hetes kimaradt, de létezik.
Azaz a debian sid i686-os, mint a gentoo, csak egy picit másképp.

Ezek tudatában egyátalán nem meglepőek a közel azonos eredmények!

Gentoo alatt, ha nem a program írója adja meg, a flag-eket, akkor az akár ronthat is a teljesítményen. Szerintem.

Nem hiszem, hogy a lelkes debian fejlesztők lemondanának az progijuk ujabb procikhoz való illesztéséről, ha nincs megkötve a kezük:

[
Imhol egy idézet, amiben szerintem nics megkötés i386 -ra !!!

Debian Policy Manual
------------------------
...
10. Files
---------

10.1. Binaries
--------------

Two different packages must not install programs with different
functionality but with the same filenames. (The case of two programs
having the same functionality but different implementations is handled
via "alternatives" or the "Conflicts" mechanism. See Section 3.10,
`Maintainer Scripts' and Section 7.3, `Conflicting binary packages -
`Conflicts'' respectively.) If this case happens, one of the programs
must be renamed. The maintainers should report this to the
`debian-devel' mailing list and try to find a consensus about which
program will have to be renamed. If a consensus cannot be reached,
_both_ programs must be renamed.

By default, when a package is being built, any binaries created should
include debugging information, as well as being compiled with
optimization. You should also turn on as many reasonable compilation
warnings as possible; this makes life easier for porters, who can then
look at build logs for possible problems. For the C programming
language, this means the following compilation parameters should be
used:
CC = gcc
CFLAGS = -O2 -g -Wall # sane warning options vary between programs
LDFLAGS = # none
install -s # (or use strip on the files in debian/tmp)

Note that by default all installed binaries should be stripped, either
by using the `-s' flag to `install', or by calling `strip' on the
binaries after they have been copied into `debian/tmp' but before the
tree is made into a package.

Although binaries in the build tree should be compiled with debugging
information by default, it can often be difficult to debug programs if
they are also subjected to compiler optimization. For this reason, it
is recommended to support the standardized environment variable
`DEB_BUILD_OPTIONS'. This variable can contain several flags to
change how a package is compiled and built.

noopt
The presence of this string means that the package should be
compiled with a minimum of optimization. For C programs, it is
best to add `-O0' to `CFLAGS' (although this is usually the
default). Some programs might fail to build or run at this level
of optimization; it may be necessary to use `-O1', for example.

nostrip
This string means that the debugging symbols should not be
stripped from the binary during installation, so that debugging
information may be included in the package.

The following makefile snippet is an example of how one may implement
the build options; you will probably have to massage this example in
order to make it work for your package.
CFLAGS = -Wall -g
INSTALL = install
INSTALL_FILE = $(INSTALL) -p -o root -g root -m 644
INSTALL_PROGRAM = $(INSTALL) -p -o root -g root -m 755
INSTALL_SCRIPT = $(INSTALL) -p -o root -g root -m 755
INSTALL_DIR = $(INSTALL) -p -d -o root -g root -m 755

ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
CFLAGS += -O0
else
CFLAGS += -O2
endif
ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
INSTALL_PROGRAM += -s
endif

It is up to the package maintainer to decide what compilation options
are best for the package. Certain binaries (such as
computationally-intensive programs) will function better with certain
flags (`-O3', for example); feel free to use them. Please use good
judgment here. Don't use flags for the sake of it; only use them if
there is good reason to do so. Feel free to override the upstream
author's ideas about which compilation options are best: they are
often inappropriate for our environment.
10.2. Libraries ....]

Ezt nem értem tisztán:
http://www.nl.debian.org/doc/manuals/maint-guide/maint-guide.en.txt
de idevág a fórm témájába.
A debian maintrénerek gentoo állásfoglalása!

[quote:05549bb9b7="snq-"][quote:05549bb9b7="johans"]A Gentoo-s CFLAG, amit használsz, közel sem aknázza ki a P4 processzorokban rejlő plussz tudást.

es a fordito sem

http://gcc.gnu.org/ml/gcc/2004-05/msg00120.html

Az ICC még jobb. De azért közel sem annyival, amennyivel kezdetben. Az ICC-nél nem nagyon tudok jobban P4-re optimalizált fordítót (lévén az Intel saját fordítója)

[quote:9a2f1a4e6a="MSD"]ha jol tudom csak akkor folytatja ha egy csomagot allitottal le. ha ujra beirod az emerge -ev world-ot akkor elorol elkezdi ujraforgatni azokat is amiket mar leforgatott.
es kikerem magamnak nincs semmilyen windows a vinyomon! :)

MSD = MS Death

[quote:7f7b243182="global77"]Ezt nem értem tisztán:
http://www.nl.debian.org/doc/manuals/maint-guide/maint-guide.en.txt
de idevág a fórm témájába.
A debian maintrénerek gentoo állásfoglalása!

:) hat nem egeszen :)

A gentoo egy csomag (file manager), ezen keresztul mutatja be a csomagolast.

[quote:7912551066="snq-"]
A gentoo egy csomag (file manager), ezen keresztul mutatja be a csomagolast.

Ez is egy vélemény, nem? :lol:

[quote:fefb48964a="fellow"]

ha nem kézzel bekapcsolni: 'hdparm -u1 -c1 /dev/hdx'

DMA bekapcs miert nem "$hdparm -d1 /dev/hdx" ?

[quote:ce1968a2be="global77"][quote:ce1968a2be="snq-"]
A gentoo egy csomag (file manager), ezen keresztul mutatja be a csomagolast.

Ez is egy vélemény, nem? :lol:

:?: :?: :?:

[code:1:ce1968a2be]
name
gentoo

a fully GUI-configurable, two-pane X file manager gentoo is a two-pane file manager for the X Window System. gentoo lets the user do (almost) all of the configuration and customizing from within the program itself....

maintainer
Josip Rodin <joy-packages@debian.org>
filename
pool/main/g/gentoo/ gentoo_0.11.46-1_i386.deb
[/code:1:ce1968a2be]

Micsoda remek szovicc :roll:

[quote:b61bdc8a2c="Aewyn"][quote:b61bdc8a2c="global77"][quote:b61bdc8a2c="snq-"]
A gentoo egy csomag (file manager), ezen keresztul mutatja be a csomagolast.

Ez is egy vélemény, nem? :lol:

:?: :?: :?:

[code:1:b61bdc8a2c]
name
gentoo

a fully GUI-configurable, two-pane X file manager gentoo is a two-pane file manager for the X Window System. gentoo lets the user do (almost) all of the configuration and customizing from within the program itself....

maintainer
Josip Rodin <joy-packages@debian.org>
filename
pool/main/g/gentoo/ gentoo_0.11.46-1_i386.deb
[/code:1:b61bdc8a2c]

Ez mind igaz, de miért pont ezt a csomagot hozták fel példaként, miért nem valamit mást a sok ezerből :?: :?: :?:

Szorgalmasan olvasgattam a topicot, és most jutottam el oda, hogy leírom amit gondolok ezzel kapcsolatban. Csinos flame kerekedett ebből a debian-gentoo teszt dologból, szerintem kissé feleslegesen.
Nekem volt szerencsém a nagy disztribek többségéhez, volt Suse-m, RH-m, Mandrakem, Debian-om, Uhu-m, most pedig egy Gentoo ücsörög a gépemen. Én úgy jellemezném a különböző linuxokat, ahogy a zenében szokás mondani: variációk egy témára. Az alap közös, a felépítés filozófiája más. Mindenki aszerint választja ki a rendszerét, hogy melyik filozófia áll hozzá a legközelebb, mi az amit szívesen használ. Van akinek az apt-get-nél soha nem kellene jobb, más a fordítás erejében hisz.
Szerintem kár flamelni ezen, a linuxnak az ereje ebben a sokszínűségben is van, hogy "ugyanazt" hány féle módon el lehet vele érni. Ez a választás szabadsága, mindenki azt használ, amit szeretne, és ez éppen így jó. Nincs über meg überebb rendszer, egyszerűen mindegyiket másra hegyezték ki és máshogy építették fel.
Ami pedig az optimalizálást illeti, szerintem ez is felfogás beli kérdés valahol. Annyit nem lehet vele nyerni, hogy egyértelmű legyen az előnye, de van akinek ez mégis megér pár órát... De lényeg ott van, hogy linux. Szerintem... :wink:

[quote:0f4dacdbba="FeriX"]Fordít a Gentoom: 114 of 224

http://www.itsystems.hu/gentoo/gentoo.png

ezt a jobboldali cuccot hogyan varázsoltad oda?
teccik nagyon :wink:

igen, de az icc sokkal kevésbé tesztelt, mint a gcc
hja, és ha a 2.95ös gcct meg az icct összehasonlítanánk, imho eléggé megizzadva nyerne az icc :wink:

[quote:4845f9268e="vmiklos"][quote:4845f9268e="FeriX"]Fordít a Gentoom: 114 of 224

http://www.itsystems.hu/gentoo/gentoo.png

ezt a jobboldali cuccot hogyan varázsoltad oda?
teccik nagyon :wink:

Valszeg (super)karamba. Van mind2. Nekem csak egy időjós (liquid weather) téma figyel az asztalon. Egyébként van jónéhány ilyen progi.

Nem akarsz majd a végén egy szép kerek cikket írni ebből az egészből? Mármint nemcsak az eredményekről, hanem az odavezető útról, szerzett tapasztalatokról is? Szerintem nagyon érdekes, tanulságos lenne és jól is mutatna a "Központban" szekcióban. 8) Talán még máshonnan is linkelnék... :)

mplayer:
nem lennek meglepodve, ha a ket teszt kb azonos eredmenyt hozna.. leven az mplayer (nem a gmplayer) nemigazan grafikus (marmint felesleges GUI nincs benne), es igy a prociideje nagy reszet valoszinu a codec viszi el.. abbol meg DLL-eket (!nem eliras!) hasznal.. azt meg nem hinnem, hogy a gentoo kepes lenne ujraforditani, es optimalizalni.. :)
(en legalabbis eleg sok DLL-t tettem fel.. persze lehet, hogy a tesztelt konverziohoz nem hasznal semmi ilyet..)

FeriX:
azt is kitesztelhetned, hogy hany szalon forditasz..
make alapbol 1-et hasznal (bar gondolom a gentoo atirja, leven, hogy neki igencsak letfontossagu)
make -j2 2 szalat, -j4 4-et, stb..

gondolom nem veletlenul tettel fel SMP kernelt.. (az en procim is HT-es)
amikor forditottam, akkor annak ellenere, hogy 2 proci van, ha sok kis file-t fordit, 2 file kozott nem utemez be semmit.. igy en inkabb 4 szalon szoktam.. persze ha kozben masra is hasznalom a gepet, akkor maradok 1 szalnal, es tudom mellette hasznalni..

hmm.. lehet, hogy eloszedek vmi szep nagy forrast, es elkezdek forditani..

Egyéb körülmények azonosak voltak? (Pl. compiler verzió, filerendszer, iyesmi)

Ferix!

[code:1:86487f664a]
emerge --resume
[/code:1:86487f664a]

Ennyi az egész. A /var/tmp/portage-ban levő könyvtárak alapján tudja, hogy hol volt, és mit csinált éppen. Tehát semmi -ev, csak a resume, és folytatni fogja azt a műveletet, amibe belekezdtél. Természetesen az a csomag, aminek a fordítása közben megszakadt a művelet, újra lesz fordítva.

Ha még egyszer beírnád az emerge -e -t, akkor az újrakezdené az egészet, mivel az 'e' jelentése : clean portage tree.

ÜDv: Warper

[quote:70a518b2d3="popacsek"]Egyéb körülmények azonosak voltak? (Pl. compiler verzió, filerendszer, iyesmi)

mert?

Ez engem is erdekelne!

Masreszt meg kar megprobalni meggyozni a Gentoo-sokat, mert szakadár megrögzött geek-ek. :) Lehetetlen.:) Masreszt sztem a Gentoo nem azért jó, mert 30% gyorsabb :) hanem azért mert Terád szabja a rendszert és nincs felesleg, csak amiről Te is tudsz (persze ha akarsz :wink: )!

Majd meglátom mennyire "lassú" a csomagok fordítása.

gondolom ezert nem ajanlott gentoo egy ocskabb gepen ami ojan 300 MHz
koruli? vagy ottan jonni ki jobban a teljesitmeny kulonbseg?
nem akarja valaki megcsinalni a tesztet mondjuk atlagos gepen :>
merthat oszinten megvallva, egy 3GH es gepen akarmi mar gyorsan fut
ezert kene "ocskabb" gepen megnezni szerintem
talan az realisabb

ha valakinek van ilyen eredmenye varjuk :>

ventura

[quote:70bd79694f="nyos"]mplayer:
nem lennek meglepodve, ha a ket teszt kb azonos eredmenyt hozna.. leven az mplayer (nem a gmplayer) nemigazan grafikus (marmint felesleges GUI nincs benne), es igy a prociideje nagy reszet valoszinu a codec viszi el.. abbol meg DLL-eket (!nem eliras!) hasznal.. azt meg nem hinnem, hogy a gentoo kepes lenne ujraforditani, es optimalizalni.. :)

huh. ekkora hülyeséget is régen olvastam ;-)
attólmég, h az mplayer a wineből átvett loaderrel be tud tölteni win32 codeceket, a videók nagyrészét ffmpeggel, liba52vel, stb, tehát natív (forrásból fordított) codecekkel oldja meg. tehát igenis van különbség...
[quote:70bd79694f="nyos"]
(en legalabbis eleg sok DLL-t tettem fel.. persze lehet, hogy a tesztelt konverziohoz nem hasznal semmi ilyet..)

igen, ez ahhoz kell általában, h a legújabb wmvket, stb le tudjad játtszani

[quote:dcc13fb00f="snq-"][quote:dcc13fb00f="popacsek"]Egyéb körülmények azonosak voltak? (Pl. compiler verzió, filerendszer, iyesmi)

mert?

Minden teszteredményt csak akkor van értelme összehasonlítani, ha azonos körülmények között születtek. Mi értelme van összehasonlítani két disztribet, ha az egyiket gcc 3.3.4-el, míg a másikat 3.3.3-al fordították? Vagy mi értelme van összehasonlítani két vinyóigényes teszt eredményét, ha pl. az egyik ext3 filerendszeren futott, míg a másik reiserfs alatt? Na ezért kérdeztem.
Az gcc optimalizációja sajnos nem tökéletes, anno én is végeztem néhány tesztet, és néha előfordult, hogy az O2 gyorsabb volt az O3-nál. Nem is beszélve egyéb opciókról, amiken a rencer stabilitása is múlhat.
Az O3-al fordított kód binárisai rendszerint jóval nagyobbak lettek, így aztán én lemondtam az O3-ról. Én valóban nem azért használok gentoo-t, mert bármilyen sebességkülönbséget vártam tőle más disztribekkel összehasonlítva, hanem mert tetszik a portage rendszere.

[quote:345e460be9="popacsek"]Az gcc optimalizációja sajnos nem tökéletes, anno én is végeztem néhány tesztet, és néha előfordult, hogy az O2 gyorsabb volt az O3-nál. Nem is beszélve egyéb opciókról, amiken a rencer stabilitása is múlhat.
Az O3-al fordított kód binárisai rendszerint jóval nagyobbak lettek, így aztán én lemondtam az O3-ról.

nem véletlen, h minden normális disztró -O2t használ :wink:

[quote:f519b090fa="vmiklos"][quote:f519b090fa="popacsek"]Az gcc optimalizációja sajnos nem tökéletes, anno én is végeztem néhány tesztet, és néha előfordult, hogy az O2 gyorsabb volt az O3-nál. Nem is beszélve egyéb opciókról, amiken a rencer stabilitása is múlhat.
Az O3-al fordított kód binárisai rendszerint jóval nagyobbak lettek, így aztán én lemondtam az O3-ról.

nem véletlen, h minden normális disztró -O2t használ :wink:

O2 = oxigén, O3 = ozon.

Egyéb alternativák?

[quote:c5f8381ced="8192Joco"]
O2 = oxigén, O3 = ozon.
Egyéb alternativák?

LOL

[quote:9de8e258a3="FeriX"]Lehet ide html táblázatot berakni :?:
...

OS1: Debian Sid,
OS2: Gentoo, -O3, -march=pentium4, -mcpu=pentium4

...

Egyenlőre ennyi.

Szia FeriX,

Igazán köszönjük, hogy akadt olyan lelkes ember, aki az idejét áldozza ilyen tesztekre.

Sajnos egy HUP-os forumban linkeltek egy levlistat, amiben egy fószer arról számolt be, hogy XY program lassabban futott az agyonoptimalizált Gentoo-ján, mint a Debian-ján. A végén kisütötte, hogy a fő bűnös a az -O3. Miután -O2-vel újrafordította a Gentoo-ját, akkor rendeződött a "paradox jelenség". Ezért megkérnélek, hogy ha van rá elegendő energiád, akkor ismételj meg néhány mérést, amelyben a Gentoo rosszabbul szerepelt, miután újrafordítottad -O2-vel.
És a make.conf-ból lehetőleg maradjanak ki a
[code:1:9de8e258a3]
LDFLAGS="-W,-z,norelro"
[/code:1:9de8e258a3]
szintő hackek.

Egyébként én mindkét féle rendszert használok, és mindkettőt szeretem.
Debian-nal kezdtem, és enneél egyszerűbbet nem tudok elképzelni.
Biztonsági megközelítésből, Adamantixon át lyukadtam ki a Gentoo-hoz. 1-2 dolog végzetesen megfogott a Gentoo-ban. Init rendszer, make system. USE="-X" és semmi nem húz be magával X-es dependenciát...

Dw.

[code:1:9de8e258a3]----------------------------------------------
::::::::_Hardened._Gentoo_Hardened._::::::::::
:::_once_you_go_hardened,_you_cant_go_back :::
----------------------------------------------[/code:1:9de8e258a3]

[quote:997f695c6c="8192Joco"][quote:997f695c6c="vmiklos"][quote:997f695c6c="popacsek"]Az gcc optimalizációja sajnos nem tökéletes, anno én is végeztem néhány tesztet, és néha előfordult, hogy az O2 gyorsabb volt az O3-nál. Nem is beszélve egyéb opciókról, amiken a rencer stabilitása is múlhat.
Az O3-al fordított kód binárisai rendszerint jóval nagyobbak lettek, így aztán én lemondtam az O3-ról.

nem véletlen, h minden normális disztró -O2t használ :wink:

O2 = oxigén, O3 = ozon.

Egyéb alternativák?

ehh, ez nem a linux-kezdő topic :twisted:
btw optimalizáló flagek, _elvileg_ minél nagyobb, annál jobban optimalizál :wink:

btw kösz ferix, nekem sose lenne energiám ilyen teszteket csinálni :lol:

[quote:875162800a="FeriX"][quote:875162800a="Dwokfur"][quote:875162800a="FeriX"]Lehet ide html táblázatot berakni :?:
...

OS1: Debian Sid,
OS2: Gentoo, -O3, -march=pentium4, -mcpu=pentium4

...

Egyenlőre ennyi.

A végén kisütötte, hogy a fő bűnös a az -O3. Miután -O2-vel újrafordította a Gentoo-ját, akkor rendeződött a "paradox jelenség". Ezért megkérnélek, hogy ha van rá elegendő energiád, akkor ismételj meg néhány mérést, amelyben a Gentoo rosszabbul szerepelt, miután újrafordítottad -O2-vel.
És a make.conf-ból lehetőleg maradjanak ki a
[code:1:875162800a]
LDFLAGS="-W,-z,norelro"
[/code:1:875162800a]

Akkó, mostan ugye megvan minden lefordítva az említett opciókkal. LDFLAGS nincs.
Hogy tudom újrafordíttatni a rendszert, -O2-vel, (természetesen a /etc/make.conf-ban módosítom) hogy ne kelljen újra beállítgatnom mindent?

Miután átállítottad a make.conf-ot, utána:
[code:1:875162800a]
env-update && source /etc/profile
[/code:1:875162800a]

Majd:
[code:1:875162800a]
emerge -ev world
[/code:1:875162800a]

Have phun.

Üdv,
Dw.

[quote:b281e1107c="popacsek"]Mi értelme van összehasonlítani két disztribet, ha az egyiket gcc 3.3.4-el, míg a másikat 3.3.3-al fordították?

a szemeben ez teljesen valid osszahasonlitas lenne

[quote:b281e1107c="popacsek"]Az gcc optimalizációja sajnos nem tökéletes

a gccvel ez a legkisebb gond, a gcc sajnos 2004-ben mar egy felvallalhatatlan dolog

Udv!

Ha leurul a masodlagos vinyom, megnezem AMD64-re a Gentoot.
Bar az X-es programok tuti nem futnak, mert az flgrx driver nem megy, csak 32 biten :(

Ja, egyebkent -O3 helyett inkabb -Os -t kene hasznalni a nagy programoknal (KDE, mozilla, OOo). Lenyegesen csokkenhet a betoltesi ido...

Kubi

[quote:3e7af163cd="FeriX"]Annyit elárulok az új tesztel kapcsolatban ami éjjel fog elkészülni, hogy nem a programok optimalizálásában rejlik a titok nyitja. És a helyzet elkeserítő. :?

A többi valamikor éjszaka..... :idea:

na most mi van? en nem is tudtam aludni az ejjel, ugy izgultam! ne kinozz tovabb bennunket :)

[quote:d9c162773e="FeriX"] De ha minden OS i386-ra van optimalizálva, minek kellettek az új utasításkészletek az új procikba? Majd csak a 64bites OS-ek hoznak ezek szerint áttörést?

Nem vagyok benn biztos, de a deb csomagok 686-ra is optimalizálva lehetnek,
[nem vagyok programozó, de a 686-os utasításkok helyett, csak a 386 utasítások indulnak, ha olyan a gép - lehet ilyet tenni egy 386-os csomagba?]
A p4, meg a K7 pedig alig több, mint a 686.
Javítsatok ki, ha tévedek!

Az mplayered viszont valszeg 686, mert a benchmark verte a gentoo-n lévőt

"Kernel: 2.6.7 mm7 patch."
Debian alá magad forgattad (peccselted) a kernelt és 386-ra?
Én előre forgatott K7-es kernel-csomagot használok most sarge-emen és nem látszik lasabbnak a gentoo-m sajátkezűleg összetoldott kernelénél.

[flame]
Idézet innét:
http://doc.gentoo.hu/html/hu-gentoo-filozofia.html
"Ha valami tökéletesen ellátja a munkáját, akkor észre sem veszed a jelenlétét, mert nem zavar és nem tudatja veled a jelenlétét valamint nem is erőlteti az interakciót veled, ha nem akarod"
A debian pillanatok alatt fent van, de egy picit a Billdowst idézi amikor a low(sok kérdés) szinten telepíted: "Next, OK, Next, Next, OK" (mert hát úgyis tudom majd módosítani, ha fent van) De, ha a gyorsaságról van szó verhetetlen a debian a ritkán használatos progik esetén, mert az apt-get install-al jóval gyorsabb, mint az emerge.
[/flame]

> Clevo D870P
UI: Mennyi pénz, egy ilyen gép?

Érdekes fórum, megint oda kerül a hangsúly, h a gentoosok állatok. A funoll-loops elég kiforgatott. Az az ember aki csinálta egy kicsit beteg is lehet. Talán francia hazafi és védi a Mendraket, és gentoo fóbiája van. ;D A --teach-me-unix az talán arra vonatkozik, legalábbis akik igazából erre gondoltak, hogy jobban rá vannak utalva a konzolra mint mondjuk UHU alatt, és talán kicsit közelebb kerülnek a rendszer felépítéséhez. Miből is áll..(Hiszen nem mindenki sysadmin és ssh felügyel szervereket nap mint nap.) Mert ugyebár UHUnál csak a szerencse segít. A tesztben a march és az mcpu use flagek együttes használatát nem igazán értem. A gentooban elvileg a mplayer forgatásához nem a make.confban megadott CFLAGeket használja hanem amelyek "gyáriak" a mplayer forráshoz, hogy supportálják az mplayeresek, vagy mi a fene.

FeriX, nem tudom tudsz-e rola, hogy van egy ccbench nevu tool (a RockLinux-hoz fejlesztettek meg anno) amivel meg lehet hatarozni azokat a gcc kapcsolokat, ami a te prockod esetere (atlagban) a leggyorsabb kodot generalja. (Nem ujabb melot, csak egy tippet akarok adni :)
Reszemrol az altala kibokott kapcsolokkal forgattam le a Rock-ot, es vegul is mukodott. (Igaz, ellen tesztet nem csinaltam.)
Esetleg csinalhatnal egy forditast a ccbench altal adott parameterekkel is, hatha mond valami okosat. (Foleg ha mar minden %-nyi teljesitmeny szamit. =8-)

global77:
"Javítsatok ki, ha tévedek!"
roger that;

"Nem vagyok benn biztos, de a deb csomagok 686-ra is optimalizálva lehetnek, "
nem, 386 (kompatibilitas mindenek felett); pontosabban unstable/testingbe mar 486, mert a gcc 3.2tol kezdve (?) nincs 386 support;
de van libc6-i686, ami nptl (2.6 kernel) es 686 optimalizalt, de nem tudom mennyit gyorsit, mert pax nem kompatibilis vele; atlasnak vannak kulonbozo cpura optimalizalt valtozatai; afaik ennyi, a tobbi 386/486;

"[nem vagyok programozó, de a 686-os utasításkok helyett, csak a 386 utasítások indulnak, ha olyan a gép - lehet ilyet tenni egy 386-os csomagba?]"
az -march valoban ilyen, de az -mcpu mar minimum adott procit igenyel;

persze javitsatok, ha tevedek;

FeriX:
egy 'ps aux'ot meg mellekelj, hatha vmi visszafoghatja a rendszert (pld 'updatedb' neha "meglepi az embert");

Már féltem, hogy őrültségeket írtam, de most megnyugtattál.
"roger that;" ?

[quote:32fe30dd4e="global77"]Már féltem, hogy őrültségeket írtam, de most megnyugtattál.
"roger that;" ?

Fokepp amerikai katonak altal hasznalatos kifejezes; valami olyasmit jelent, hogy 'vettem', 'ertettem' stb.

BandiG:
"DMA bekapcs miert nem "$hdparm -d1 /dev/hdx" ?"
oke, igy teljes a lista:
u = unmakirq
c = io32bit
d = dma

a tobbi imho nem hozz teljesitmeny-novekedest;

[quote:91365dc9e2="BandiG"][quote:91365dc9e2="fellow"]

ha nem kézzel bekapcsolni: 'hdparm -u1 -c1 /dev/hdx'

DMA bekapcs miert nem "$hdparm -d1 /dev/hdx" ?

Üdv,

Egy kis update, hogy gyorsuljatok:

hdparm -d1 -c3 -u1 -Xyy /dev/hd?,
ahol yy=
- multiword dma mode bekapcsolásához: yy={32 + a kivánt multiword DMA mód száma} (pl.: mword dma mode2-höz: -X34)
- ultradma mode bekapcsolásához: yy={64 + a kívánt UDMA mode száma} (pl.: UDMA mode 4-hez (UDMA66): -X68)

(vedd észre: -c3 és nem -c1)

További gyorsabb winyókezelést és alacsonyabb prociterhelést kíván:
Dw.

[quote:7da21c67e2="snq-"]
a gccvel ez a legkisebb gond, a gcc sajnos 2004-ben mar egy felvallalhatatlan dolog

A teljesen clueless arcok kedveert errol azert par szot szolhatnal...

Az ilyesmi optimalizalas teljesen ertelmetlen. Sokszor a "tuloptimizalt" binárisok nemhogy gyorsabban, de lassabban futnak, emelett nem annyira megbizhatoak. Sok olyan bug van a softwarekben amelyek csak magas optimizacio utan jonnek elo. Erre FreeBSD ben tomerdeknyi pelda van. Gentoorol nem tudok nyilatkozni. vmiklos: attol, hogy minel magasabbra allitod az optimizacios szintet (-O) semmit nem fogsz elerni mivel -O20 == -O3 mivel 3 a maximum. Annyiban egyetertek vmiklossal, hogy minden normalis project -O2 -t hasznal. x86 an eseten i386 ra optimizal. Ezen kivul mindekinek ajanlom a figyelmebe a http://www.funroll-loops.org/ oldalt. Nagyon jol bemutatja a gentoo userek (és néhány fejleszto!) butaságait.

A CFLAGekhez igazából nem értek, viszont amit a gcc manualban olvastam azok alapján a march mindent tud amit az mcpu + jobban optimalizál az adott processzor típusra így lelőfordulhat, hogy más processzoron nem fog működni. http://gcc.gnu.org/onlinedocs/gcc-3.3.3/gcc/i386-and-x86-64-Options.html#i386%20and%20x86-64%20Options Azt nem tudom, bár próbáltam utánajárni, hogy ezek a CFLAGEK ütik-e egymást, mert ha igen, akkor tudtommal a gcc az utolót veszi figyelembe. Amiből az következik, hogy ha ilyen sorrendben írod be (ahogy fent), akkor az mcpu lesz figyelembe véve. Ha nem is ütik egymást, akkor is fölösleges mind2, mert a march magában foglalja az mcpu-t.

Az mplayerre vonatkozóan: keresd meg a /var/log/portage/ ban az mplayer logjait. 2 minimum lesz. Az egyikben le lesz írva. Ha felrakod és figyeled akkor is kiírja, hogy mi a helyzet. Azt, hogy hol változtatod meg nem tudom, én nem akartam, pontosan az adott okok miatt. Bár segítséget így se talál az ember nagyon.

A felhomályosítást nem merném állítani teljesen, mert nem tartom magamat nagyra linux téren. Nem vagyok rég óta dologban. Hogy miért Gentoo és miért nem mondjuk Debian arról tudnék mesélni, de jelen esetben mind1.

[quote:01646b628a="ruczati"][quote:01646b628a="snq-"]
a gccvel ez a legkisebb gond, a gcc sajnos 2004-ben mar egy felvallalhatatlan dolog

A teljesen clueless arcok kedveert errol azert par szot szolhatnal...

erre en is kivancsi lennek

arra gondoltam, hogy a mukodo precompiled-header-support tokeletes hianya miatt nagyobb lelegzetvetelu projektek (vagy osszetevoinek) forditasa iszonyatos idokbe telik, 200%-os CPU kihasznaltsag mellett, hogy kozben meg mast se tudjak csinalni

ha már mplayer, nekem a gentoo volt az első olyan disztró, ahol igazán fájdalommentes volt az mplayert föltenni, minden extrával együtt, és egyből beleszerettem a use flagekbe. az init-kezelése is kúl, az /etc kicsit "túlbonyolítot" egy slackwar-hez képest, de fölüdülés egy mandrake után.

off
dzsolt, jó volt olvasni a soraidat, olyan higgadt volt meg emberi
/off

UHU /etcet még biztos nem láttál. ;))

[quote:9a4132c79b="thuglife"]...mindekinek ajanlom a figyelmebe a http://www.funroll-loops.org/ oldalt...

a http://greenfly.org/mes.html Q&A resze is jo

Felix a make.confot ide be tudnád másolni? Csak az érdeklődőknek. Thx.

[quote:959b409f79="whitehawk"]UHU /etcet még biztos nem láttál. ;))

Húú bazz ne is mondd!
Inkább reinstalltam az illető gépét egy debian-ra minthogy kiismerjem.

(nem aztmondom, desktopnak lehet hogy jó, de ez "elvileg" szerver/router volt)

majd nyitok egy fórumot, ki miért váltott UHUról, és miért.

[quote:2a88179999="fellow"]az -march valoban ilyen, de az -mcpu mar minimum adott procit igenyel;

persze javitsatok, ha tevedek;

gcc 3.4.xnél már s/-mcpu/-mtune/ :wink:

[quote:3a9f584b82="thuglife"]vmiklos: attol, hogy minel magasabbra allitod az optimizacios szintet (-O) semmit nem fogsz elerni mivel -O20 == -O3 mivel 3 a maximum.

igen, tudom. de pl a kernel ha jól emléxem -O9szel fordul, hha esetleg bevezetnének a gccben 1 új optimalizációs szintet, akkor 1ből ki legyen használva
[quote:3a9f584b82="thuglife"]
Annyiban egyetertek vmiklossal, hogy minden normalis project -O2 -t hasznal. x86 an eseten i386 ra optimizal.

hm. sztem pl a '-O2 -mcpu/-mtune i686' elég jó, ez bármilyen x86an elfut, mégis a leginkább használt i686on lesz a leggyorsabb

ezt próbáltam:
[code:1:6729f880e5]
root@nest /var/log/portage # cat 2836-mplayer-1.0_pre5-r2.log | head -n 5
Please note that we do not use C[XX]FLAGS from /etc/make.conf
or the environment, as the MPlayer guys then do not give support
in case of bug reports!.
[/code:1:6729f880e5]
Nem fogom lefordítani.[/code]

Én nem várok az optimalizációtól semmi sebességnövekedést. Nem is azérthasználom a gentoo-t. Egyszerűen tetszik a felállás, amit a gentoo telepítése folyamán látok, érzek. Használok UHU-t is, mert az általam összerakott gépekre mindig azt teszem. Nincsenek céges gépek közöttük még, de az uhu bármelyik magyar irodába megfelelhet. Gentooval nem adnék egy gépet sem. De az ismerőseim UHU után mind gentoot rakosgatnak a gépeikre. Pl epia lapra sokkal egyszerűbb minden hw-t kihasználva gentoot tenni, mint bármi mást. Az is fontos, hogy bár fejlesztői, de mégis a rendszer által támogatott buildekből lehet feltenni, így később egyszerűbb karban tartani, mint ha forrásból rakosgatnék fel mindent.

dzsolt

[quote:0c1baa1912="FeriX"][quote:0c1baa1912="whitehawk"]A CFLAGekhez igazából nem értek, viszont amit a gcc manualban olvastam azok alapján a march mindent tud amit az mcpu + jobban optimalizál az adott processzor típusra így lelőfordulhat, hogy más processzoron nem fog működni. http://gcc.gnu.org/onlinedocs/gcc-3.3.3/gcc/i386-and-x86-64-Options.html#i386%20and%20x86-64%20Options Azt nem tudom, bár próbáltam utánajárni, hogy ezek a CFLAGEK ütik-e egymást, mert ha igen, akkor tudtommal a gcc az utolót veszi figyelembe. Amiből az következik, hogy ha ilyen sorrendben írod be (ahogy fent), akkor az mcpu lesz figyelembe véve. Ha nem is ütik egymást, akkor is fölösleges mind2, mert a march magában foglalja az mcpu-t.

Az mplayerre vonatkozóan: keresd meg a /var/log/portage/ ban az mplayer logjait. 2 minimum lesz. Az egyikben le lesz írva. Ha felrakod és figyeled akkor is kiírja, hogy mi a helyzet. Azt, hogy hol változtatod meg nem tudom, én nem akartam, pontosan az adott okok miatt. Bár segítséget így se talál az ember nagyon.

A felhomályosítást nem merném állítani teljesen, mert nem tartom magamat nagyra linux téren. Nem vagyok rég óta dologban. Hogy miért Gentoo és miért nem mondjuk Debian arról tudnék mesélni, de jelen esetben mind1.

A CFLAGS úgy tökéletes ahogy használtam
Az mplayer meg kiírja hogy ne use C[XX]FLAGS vagy environment mert az MPlyar fijúk így nem bugrport fogadnak, és lecserélik erre fordításkor:
-O4 -march=pentium4 -mcpu=pentium4

Moreover, specifying -march=cpu-type implies -mcpu=cpu-type.

[code:1:0c1baa1912]to imply - beleért, magába foglal, értelmileg tartalmaz[/code:1:0c1baa1912]

Nem lehet, hogy elég az -march?

Dw.

[quote:6e15f81b25="dzsolt"]...Nincsenek céges gépek közöttük még, de a(z) <tetszoleges-linux-terjesztes> bármelyik magyar irodába megfelelhet...

mint micsoda?

[quote:d271e8f3f7="FeriX"][quote:d271e8f3f7="whitehawk"]A CFLAGekhez igazából nem értek, viszont amit a gcc manualban olvastam azok alapján a march mindent tud amit az mcpu + jobban optimalizál az adott processzor típusra így lelőfordulhat, hogy más processzoron nem fog működni. http://gcc.gnu.org/onlinedocs/gcc-3.3.3/gcc/i386-and-x86-64-Options.html#i386%20and%20x86-64%20Options Azt nem tudom, bár próbáltam utánajárni, hogy ezek a CFLAGEK ütik-e egymást, mert ha igen, akkor tudtommal a gcc az utolót veszi figyelembe. Amiből az következik, hogy ha ilyen sorrendben írod be (ahogy fent), akkor az mcpu lesz figyelembe véve. Ha nem is ütik egymást, akkor is fölösleges mind2, mert a march magában foglalja az mcpu-t.

Az mplayerre vonatkozóan: keresd meg a /var/log/portage/ ban az mplayer logjait. 2 minimum lesz. Az egyikben le lesz írva. Ha felrakod és figyeled akkor is kiírja, hogy mi a helyzet. Azt, hogy hol változtatod meg nem tudom, én nem akartam, pontosan az adott okok miatt. Bár segítséget így se talál az ember nagyon.

A felhomályosítást nem merném állítani teljesen, mert nem tartom magamat nagyra linux téren. Nem vagyok rég óta dologban. Hogy miért Gentoo és miért nem mondjuk Debian arról tudnék mesélni, de jelen esetben mind1.

A CFLAGS úgy tökéletes ahogy használtam
Az mplayer meg kiírja hogy ne use C[XX]FLAGS vagy environment mert az MPlyar fijúk így nem bugrport fogadnak, és lecserélik erre fordításkor:
-O4 -march=pentium4 -mcpu=pentium4

Még két megjegyzést szeretnék hozzáfűzni a tesztedhez:

A cpu optimalizálás hatását szerintem tisztábban lehet megmérni, ha fordítassz egy Gentoo-t march=i386-al és utána egy march=pentium4-gyel és a kettőt összehasonlítod. A két disztrib (Debian vs. Gentoo) közötti különbség egy más tészta. Persze teoretikusan azzal is számolni kell, hogy Debian alatt más hatással jár a cpu optimalizálás, mint Gentoo alatt. Ez utóbbi lehetőséget figyelmen kívül hagyhatjuk.

Az sem mindegy hogy a diszk melyik részén van a disztrib. A legjobb lenne, ha ugyanazt a swap-ot használná a két disztrib a teszt alatt - amit nem nagy ügy megoldani.

Üdv,
Dw.

[quote:182cdc81cc="snq-"][quote:182cdc81cc="dzsolt"]...Nincsenek céges gépek közöttük még, de a(z) <tetszoleges-linux-terjesztes> bármelyik magyar irodába megfelelhet...

mint micsoda?

Mint szövegszerkesztő, táblázatkezelő, raktárnyilvántartó. Bár ez utóbbi a Lafisoftos (vagy vmi ilyes) progival nem jött össze, rendszerint adatvesztéses hibákkal szált el. Kapcsolattartásra az ügyfelekkel megfelel. Árajánlatot pl a cég ahol dolgozom xls-ből ad, arra is megfelel. Van jogtár. Van könyvelő progi. Nem kell külsős munkákat beletenni, benne van. Természetesen igaz, minden dist megfelel mindenre, de nem ajánlok olyat senkinek amiben nem tudok segíteni. Erre példa volt 2 hete egy mrake 9.1 amiben azt se tudtam, hogy mit hol keressek, ha nem ott volt ahol én megszoktam. Pedig csak a /etc alatt bolyongtam ssh-n keresztül :-) . Volt egy gyenge kisérlet céges alkalmazásra, de a VisualWindow vállalat irányítási rendszer kizárólag m@sik rendszer alatt fut, így nem erőltettem. Sajna ott fontos a termelési tervezés, van baj elég a VW-vel is, nem akartam még több bajt a nyakamba.

Az UHU nem a kedvencem, de már ismerem. Most is UHU-ból írok. De ha vhova ráérős linux kell, amit meg is akar vki ismerni, oda azt mondom Gentoo. Használtam debet is, de nekem fontos volt az egyszerűség. Egy időben nem volt egyszerű a deb :-) És nem a Po-ra gondolok, még csak nem is a woodyra. leginkább a fejlesztői telepítőlemezek nem tetszettek. Gprs netem volt, nem volt mindegy, hogy hányszor kell lehúznom. Ebből lett az UHU. Aztán jött az adsl. Ráérősen elkezdtem a gentooval foglalkozni. Sokmindent nem tudok még róla, de megtetszett szeretem. Nekem a rendszer a gentoo. Az uhu-t pedig sokmindenhol kiismertem, tudok segíteni azoknak akik igényt tartanak a tudásomra. Szoktam is segíteni. Sőt ! Térítek is linuxra. Van akit UHU-val, van akit gentooval, van akit BDI-vel. Igaz ez utóbbi érdekes realtime rendszer, de nem arra való, hogy mindenkinek jó legyen. Ezt nem is erőltetem és csak live-ról használom egyenlőre én is.

Ezek a személyes véleményeim megnyilvánulásai. Nem kell követni, nem kell flamelni sem.
A gentoo mint koncepció, az amiért igazán érdemes megismerni. Sebességnövekedést nem tapasztaltam alkalmazásonként, bár a fullos UHU-nál minden gyorsabb :-) Debian a kényelmetlenségeivel, a szigorával győzött meg anno (95 környéke). Akkor volt miért tisztelni. Mára túzottan konzervatívvá vált a szememben, de ez is magán vélemény.

dzsolt