Ať žije multicore!

26.10.2007 23:50 | Přečteno: 2330× | Novinky | poslední úprava: 13.1.2008 17:42

Zhruba před týdnem jsem si koupil nový procesor, čímž jsem dokončil menší inovaci mé sestavy, kterou jsem kupoval o prázdninách 2005.

Jen tak abych to shrnul, takhle to šlo postupně:

• 05.01. - nová deska ASUS A8N-SLI Premium; nahrazuje Biostar NF4ST-A9.
• 11.04. - dalších 2×512 MiB RAM, takže celkem 2 GiB
• 23.07. - nová grafika Gainward 8484-Bliss 8600 GT Golden Sample; nahrazuje starou MSI GeForce PCX-5750
• 19.10. - nový procesor AMD Athlon 64 X2 4200+; nahrazuje 3000+

Novej procesor je fakt kotel. Hned snad druhej den jsem zvedl FSB na 250 MHz (takže bráškové jedou na 2.75 GHz a RAM s děličkou 1.666) a jede to už tejden stabilně (a že tady probíhaly psí kusy). Všechny hry najednou jedou bez sekání na maximum (úplně nejvíc Postal 2: A Week in Paradise, dále GTA San Andreas a FlatOut 2 ve Wine to hodně pomohlo, o ET:QW a Quake IV ani nemluvím, jelikož využívaji multicore). Kompilace... jádro mám zkompilovaný pod 3 minuty.

A dneska jedna úžasná věc... kompiluju si takhle nový Wine s -O3 v C[XX]FLAGS a -j4 v MAKEOPTS (s nice 0) a najednou píše kámoš ať jdu hrát RTCW:ET. Nechtělo se mi čekat, ani přerušovat kompilaci (už to bylo asi v polovině), tak jsem to drze (jak jsem si myslel) zkusil spustit a ono to šlo úplně bez problémů! Za pár minut se to dokompilovalo a FPS rate vyletěla zase do nebeských výšin. Těžko říct, jestli je to tím, ale vidím to na ten novej CFQ plánovač - je fakt dobrej.

Nepotěšil mě ale oom-killer, kterej nechal kompilaci rb_libtorrent vytuhnout systém. Nechal jsem ho šrotit 20 minut, kurzor se sem tam pohnul, ale nedalo se nic dělat. Vím, že 5 dní uptime není žádnej zázrak, ale stejně. Zakompiloval jsem do jádra zpátky podporu pro swap a odkomentoval ve fstabu 1 GiB swapovací oddíl a je dobře...

No, jenom jsem chtěl říct, že jestli teprve uvažujete o přechodu na multicore, tak hurá do toho, je to nářez. Ironie je, že jisté operace jsou sice rychleji hotové, ale ve výsledku se na kompu během tý doby nedá nic dělat, což nemá na svědomí nikdo jiný, než pomalý disk... Achjo, už aby se dělaly nějaký fakt pořádně rychlý (a za rozumnou cenu, že jo).        

Komentáře

[Michal Fecko]

2 pary 512M RAM modulov, 2 jadrovy procak... hadam by sa uz len ziadalo 2x160G v RAID0 a 320G na zalohy

[pasmen]

Jo nářez, zvlášť Core Duo... O to bych si neopřel ani koloběžku. Čemu říkám nářez je až Xeon Quad Core.

[deda.jabko]

ja mam v notasku core duo... a nemuzu si stezovat jediny problem je tam s ovladanim spotreby, ktera ma tendenci procesor zpomalovat v ten nejblbejsi okamzik... treba pri testech rychlosti vypoctu....

ale pokud ma nekdo zalibu v kompilovani doporucuji vyzkouset niagaru... "make -j32" je teprve narez ;-]

[Käyttäjä 11133]

No jo, ale na niagaře asi zase nerozjedeš chuťovky typu mplayer s wmv nebo se pletu?

[deda.jabko]

ja tam mam problemy rozjet i svoje programy... zase na druhou stranu jsou velice rychle zkompilovane... ;-]

[Michal Kubeček]

Ale segfaultují výrazně rychleji. :-)

[pasmen]

Myslel jsem bugy Core Duo, nikoliv výkon.

[kkaarreell]

To me zajima, muzes je prosim specifikovat?

[pasmen]

napr. tady

[pic]

prosím rozvést

[srigi]

Heh neviete o najzavaznejsej chybe C2D? Checknite C2D ERRATA, cislo A20. Pise sa tam nieco v tom zmysle, ze ak za sebou nasleduje niekolko inst. delenia a vysledok tohoto delenia moze pri float operandoch viest k nepresnemu vysledku, CPU nenastavi FP Inexact-Result Exception flag, cize vysledny program nie je informovany o tom, ze vysledok vypoctu bol nepresny.

[srigi]

Cislo chyby je AH20, nie A20. Sry.

[Michal Kubeček]

Něco na zchlazení: mám prográmek, který při stejných parametrech na starém (jednojádrovém) A64 3500+ (2.2 GHz) běží 3.5 sekundy a na dvoujádrovém X2 4400+ (2.2 GHz) asi 15 sekund… :-)

[Käyttäjä 11133]

Zbytek parametrů je naprosto shodný?

[David Watzke]

Jde o to, co je to za prográmek, vždyť to vůbec nemusí být CPU, kdo to brzdí A jestli jo, tak proč?

[deda.jabko]

a co je to za program? tady toto delaji s oblibou vicevlaknove aplikace, kdyz se perou o zdroje (treba i alokace pameti)... na tom jednom jadru je ta synchronizace precejen min narocna ;-]

[Michal Kubeček]

Přesně tak. Je to ukázka na demonstraci kolizí při přístupu ke globálním datům. Ty hodnoty, které jsem uváděl výše, jsou pro 'mutex 100 1000000'.

[David Watzke]

real    0m6.527s
user    0m7.506s
sys     0m4.180s

[Michal Kubeček]

Asi to bude dost záležet na verzi překladače a knihoven. Také se to dá urychlit tak, že se současně spustí něco, co vytíží druhé jádro (čistší je samozřejmě použít sched_setaffinity()).

[David Watzke]

GCC 4.2.2, glibc 2.6.1. Když jsem vedle spustil bzip2 -9 na velkej soubor a zkusil to znova, bylo to jen o trošku rychlejší (6.1s).

[Michal Kubeček]

A co tohle?

  taskset -c 0 ./mutex 100 1000000

[David Watzke]

real    0m2.396s
user    0m2.390s
sys     0m0.000s

[deda.jabko]

tento priklad je opravdu extremni... v praxi mam dobre zkusenosti, ze se program muze zrychlit/stabilizovat vymenou alokatoru... nebo prepsanim nekterych mutexu na atomicke operace (mozna by pomohl i tomu vyse zminenemu prikladu)

[Michal Kubeček]

Ten příklad je samozřejmě naprosto umělý, je to jen demonstrační kód, který ukazuje, že mutexy opravdu fungují a řeší problém, který se projeví u create. Ale jednou jsem na podobný efekt narazil i u trochu realističtějšího kódu: když jsem zkoušel měřit roundtrip při komunikaci mezi dvěma procesy přes rouru a (anonymní) UNIX domain socket. Tam to při posazení obou procesů na totéž jádro vycházelo asi 60 procent hodnoty naměřené v případě, že seděl každý na jiném.

[David Heidelberg]

S tou FSB není problém u 64bitovejch AMDéček vytahnout i 300. Já mám třeba Semprona 64 2500+ na 275FSB a běhá nádherně stabilně. Ono i 310FSB jde, ale potom už nestíhá chladič dodávaný s procesorem. Na rychlost kompilace jádra to podle mně nemá moc vliv, jelikož kernel mám taky kolem 3minut zkompilovaný(a to je Sempron celkem šunka).

Kdybych teď měl ale možnost koupit novej procesors deskou), tak bych asi vybral Core Duo, díky poměru spotřeba_procesoru/cena.

0K!AS

[David Watzke]

S tou FSB není problém u 64bitovejch AMDéček vytahnout i 300. Já mám třeba Semprona 64 2500+ na 275FSB a běhá nádherně stabilně. Ono i 310FSB jde, ale potom už nestíhá chladič dodávaný s procesorem.

Já vim, s 3000+ mi to jelo na 294 MHz, dokud jsem měl jen 2×512 MB RAM. Chladič dodávaný s procesorem je výsměch, vyhodil jsem ho hned ten den co jsem koupil 3000+ a ten velkej CoolerMaster, co jsem koupil místo něj, mám doteď, k novýmu žádnej ani nebyl.

Na rychlost kompilace jádra to podle mně nemá moc vliv

LOL? Na single-core to trvalo dýl... o dost.

[David Heidelberg]

Pokuď vezmeš v úvahu, že mně kompilace na SEMPRONU 2500+ jede kolem 3minut, tak si musel mít ten Athl3000+ podtaktovanej ... a nebo máš v jádře moc ovladačů, který nepotřebuješ.

0K!AS

[David Watzke]

Mám snad jitrnice na čele?

[David Heidelberg]

No to nevím, ale zkusil bych nejbližší zrcadlo . To by Ti mohlo poskytnout velmi cenný údaj o tom, jestli je tam máš či ne

0K!AS

[David Watzke]

Tak to vidíš, děláš chytrýho a nakonec jsi můj kernel kompiloval téměř 7 minut.

[David Heidelberg]

TVŮJ KERNEL. Já jsem říkal, že MŮJ kernel mám za 3 minuty. Svůj jsem kompiloval hned potom... jako obvykle 3 minuty

0K!AS (c) (r)

[David Watzke]

Ne, ty jsi říkal

Na rychlost kompilace jádra to podle mně nemá moc vliv

a já tě tady vyvádím z omylu.

[David Heidelberg]

Tak ono u toho kernelu je to stejně jedno... člověk nekompiluje kernel každej den

0K!AS

PS: tvrzení, že to podle mně nemá moc vliv vzniklo z toho, že si psal

jádro mám zkompilovaný pod 3 minuty

z čehož jsem usoudil, že když moje jádro kompiluju 3minuty.. tak to asi velký rozdíl nebude

0K!AS

[Heron]

0K!AS

...

0K!AS

To už je trochu přeháňka, ne?

[David Heidelberg]

omyl... většinou se podepisuju jen jednou...

0K!AS (r)

[Michal Kubeček]

člověk nekompiluje kernel každej den

Řekněme většina… :-)

[tom112233]

Já nákup dvoujádra zvažuji už hodně dlouho, teď jsem se ale rozhodl, že je koupím. Teď mám také Athlon 3000+, přetaktovaný z 1,8GHz na 2,6GHz. Jen se při vývěru nemůžu rozhodnout mezi dvěma:

AMD Athlon 64 X2 5200+ EE

AMD Athlon X2 BE-2400 EE

U prvního mě láká 2MB L2 cache, u druhého zase 65nm technologie a malý příkon.

Oba by snad měly jít přetaktovat někam na 2,8GHz. Co myslíte, jak moc poznám na výkonu větší L2 cache?

[Mandarinka]

Moc ne. 1-5% V světlých a vzácných výjimkách 10%. A když to chcete přesně, najděte si benchmarky - tyhle věci se testují - někdy mezi Semprony/Athlony, jindy opterony/athlony, dneska už i různými athlony s různou L2.

[Heron]

Přeju ti to a užívej si to. Za chvíli si budeš kupovat pamět. A pak další stroj.

Možná bys mohl dát někam do /etc/rc.d/ startovací skript na nice -19 boinc, ať ten výkon slouží dobré věci. Výkon (pocit výkonu) to nijak neovlivňuje a těch pár mega paměti už teď nepoznáš.

[trekker.dk]

Jo, taky jsem boincoval - Einstein. Pak jsem si ale koupil 64bit a u Einsteinů na 64bit architekturu kašlou, takže mi server neustále vracel, že pro mě nemá úlohy.

Psal jsem do fóra (mj. už asi tři roky starého) a žádná odpověď - tak jsem se na ně vybodnul, asi mají výkonu dost.

[trekker.dk]

Hele - po několika letech se konečně probudili a už to funguje - 64bit klient má stahovat 32bit binárky.

[Heron]

Einsteina jsem na 64b ani nezkoušel. Někde je psáno, že na Intelu jede lépe Seti tak počítám je. I když taky jak blbec 32 bit binárka. Klient, který nic nedělá, je 64b. Podivné.

[David Watzke]

Paměť už asi kupovat nebudu, protože bych musel koupit jedině 4×1 GiB (nebo 2×, ale to je na prd ) a to už se nevyplatí, jelikož až pak dám dohromady novou sestavu, budu je moct tak akorát vyhodit.

[Heron]

Vyhodit ne. Až budeš kupovat novou sestavu, tak tuhle budeš mít jako server. Ono je fakt znát, když ti na kompu neběží spousta služeb, ale jsou k dispozici na GLanu. Mě teď čeká nelehký úkol vybrat desku a case (se zdroji už mám snad jasno) pro file server.

[kavol]

jj, oom-killer stojí za starou belu ... klash a některé verze ktorrentu mají leaky jak prase, ale vraždění obvykle začíná u takových věcí jako syslog nebo sshd, a to teprve v době, kdy už je počítač dávno absolutně nepoužitelný neb nedělá nic jiného než swapuje

[outsider]

Vzdycky kdyz ctu o tech gigahertzech a gigabytech, tak premyslim o tom, jak mi muze stacit uz tolik let (realese date biosu je kveten 2002, takze jsem to kupoval jeste predtim) porad stejny pocitac... Hmmmmmm uz vim! Nehraju hry!

[Limoto]

Já už jsem si myslel, že se nepochlubíš

[Ondrej 'SanTiago' Zajicek]

> Nepotěšil mě ale oom-killer, kterej nechal kompilaci rb_libtorrent vytuhnout systém

No problem nejspis nebyl ani tak v oom-killerovi, ale v tom, ze se oom-killer nespustil.

Pokud totiz nemas swap a zacne ti dochazet volna pamet, tak jadro uvolnuje stranky z cache. Casto v takove situaci dochazi k prudkemu thrashingu, kdy procesy maji v pameti jen par stranek sveho kodu a pro jejich beh se zurive nacitaji stranky z disku a strare zapominaji.

Pokud ma clovek swap, tak je nastup swapovani mnohem poklidnejsi a uzivatel si toho spis vsimne, nez dojde situace do extremu.

[Luk]

Někdy ani swap nepomůže. Jednou jsem spustil Click'n'Run (hlavní správce softwarových balíčků na Linspire a Freespire) na počítači s 256 MB paměti. Výsledkem bylo totální zabetovonání systému. A to přestože swapovací oddíl byl využit jen z 50 %. Problém byl totiž v tom, že ten program alokoval hodně paměti (cca 400 MB) a tuto paměť velmi vydatně používal. Takže stránky putovaly stále na disk a vzápětí zpět do paměti. O zmíněném programu si myslím své, ale každopádně je to situace, která je řešitelná pouze přidáním fyzické paměti.

[Murry]

Jeden, dva,tri, ctyri, ....milion
A vseci pretaktovany nebo 'neco' nestandartniho u ADM Athon3000+ .... To jsem jediny, ktery to ma tak jak to koupil?
PS: pridal bych se k ostatku, ale nevim jak se to dela.....a nevim na kolik je to riskantni...

[Michal Kubeček]

Nebojte, nejste. Nikdy jsem procesor (ani nic jiného) nepřetaktovával a ani nevidím důvod, proč to dělat.

[David Watzke]

Např. protože 2.2 GHz a 2.8 GHz je docela rozdíl...

[Michal Kubeček]

Rozdíl to možná je, ale za jakou cenu? O snížení životnosti ani spolehlivosti procesoru nestojím.

[David Watzke]

Snížený životnosti jsem si nevšiml, např. starej procák pořád funguje. A kdyby to nebylo spolehlivý a stabilní, tak to takhle samozřejmě neprovozuju.

[Michal Kubeček]

V poradně už jsem tu viděl pár dotazů, kde měl tazatel problémy spočívající v občasných záhadných pádech systému a kde se nakonec ukázalo, že jakmile vrátil taktování na nominální hodnoty, problémy ustaly.

[msk]

O snížení životnosti ani spolehlivosti procesoru nestojím

K6-2 233@300 so zvysenym napatim o .2V (tusim) mi sluzil cca 8 rokov a sluzi dodnes ( +2 = cca 10 ).

[Heron]

Na druhou stranu, pokud máš stejný procesor, který se prodává jednou papírově snížen na nějakou nízkou frekvenci a několikrát dražší model na nominální frekvenci, tak proč nekoupit ten levný a neudělat z něj ten nominální. Tohle v podstatě není ani přetaktování, protože to ten CPU už od výroby bezpečně zvládá.

Můj CPU papírově: 1860MHz, jede na 2982MHz, což je zvýšení o 62% a to stále není na svém maximu.

Totéž starý Athlon 1800+ XP, který byl tentýž jako model 2400+ XP.

[Michal Kubeček]

Protože výrobce obvykle tu oficiální frekvenci určuje právě podle toho, kolik který kus vydržel při stress-testech, než začal dělat chyby. Takže přetaktuji-li o jeden nebo dva stupně, nestojí to za to, a přetaktuji-li víc, dostanu se do oblasti, kde už to výrobci začalo zlobit.

[Heron]

Jasně, tohle je pravda, ale pokud se podaří vyrobit více kvalitních kusů, tak se některé prostě musí označkovat níž. Zkrátka záleží kus od kusu (resp. šarže).

[Michal Kubeček]

Jen je smůla, že se to pohledem na pouzdro nepozná… :-)

[Heron]

Občas se to rozkřikne. Čísla kvalitních a nekvalitních sérií lze také najít na správných stránkách na internetu. A nebo to prostě zkusit.

[David Watzke]

Riskantní to je málo, v drtivý většině případů to prostě nenaběhne, když to přeženeš. V takovym případě stačí resetnout CMOS pomocí jumperu poblíž baterky na desce. Stačí jen zvyšovat frekvenci FSB a podle potřeby měnit násobič CPU, HT a děličku/časování RAM. Výsledná frekvence procesoru je FSB*násobič CPU, RAM má frekvenci FSB*dělička (333 MHz = 1.666, u DDR se to odvíjí od 200 MHz) a HT potom FSB*násobič HT. Když z toho chceš drtit úplný maximum, pak je třeba mít kvalitní desku, RAM a zvyšovat voltáž, čímž se krátí životnost procesoru. Pozor taky na chlazení...

[Murry]

mam: GA-K8N51 GMF-9
CPU: AMD Athlon 64 3000+, Venice
Otazka je - co je to 'kvalitni' deska?
No, zkusim se na to podivat nekde na netu - jestli teda mi to 'neco' da, tak bych do toho mozna i sel.
Nastesti nebudu (predpokladam) prekompilovavat cely system (gentoo), takze je to OK

[David Watzke]

Otazka je - co je to 'kvalitni' deska?

To poznáš... např. můj tehdější Biostar stál za prd

Nastesti nebudu (predpokladam) prekompilovavat cely system (gentoo), takze je to OK

To opravdu nebudeš muset Můj systém přežil výměnu základní desky + všeho co jsem vyjmenoval v blogu a musel jsem zasahovat jen v případě CPU - zkompilovat SMP kernel, aby využíval obě jádra.

[Murry]

No, tedka zkusim neco udelat do skoly, pak je LinuxALT a nasledne se vrhnu na to
PS: kdyztak te s tim budu otravovat