» »

Opteron in Seti@Home

Opteron in Seti@Home

Amdmb.com - Medtem ko smo danes stopili med prvih 200 pri iskanju vesoljčkov (več boste izvedeli kmalu), bo za še boljši rezultat potrebno pognati še kak sistem. Tak s štrimi Opteroni bi bil kar v redu. Amdmb so pognali Setija na taki mašini in zapisali ugotovitve. Le en 1,8 gigaherčni Opteron se lahko po hitrosti računanja meri s 500 MHz hitrejšim Athlonom XP (2,3 GHz) s Thoroughbred jedrom.

Mislili pa so, da bodo ob vklopu še preostalih treh procesorjev precej zmanjšali končni rezultat posameznega procesorja, a izkazalo se je, da temu ni tako. Čas računanja štirih paketkov pri obremenjenih vseh štirih procesorjevso je bil zelo enak času, ki ga je potreboval en procesor za en paketek. Kaj nam to pove? Tudi če v sistemu tečejo vsi štirje procesorji hkrati, to ne vpliva bistveno na porabo drugih sistemskih virov, kar je velika prednost Opteron sistemov.

33 komentarjev

Brane2 ::

Ravno zato so mi Opteroni všeč. Hypertransport at its best :D

gabl136 ::

Opteron je zakon!! Sam se mal pocakamo, de se cena mal spusti:)

PS: Žaba nima las!! Znanstveno dokazano!!

Thomas ::

Kako slabo je napisan software za SETI@home?!

8-O
Man muss immer generalisieren - Carl Jacobi

Dr_M ::

seveda...usak bo kupu usaj 2.

AMD OPTERON 244 (1.8GHz)BX 250.440
The reason why most of society hates conservatives and
loves liberals is because conservatives hurt you with
the truth and liberals comfort you with lies.

Tarzan ::

kaj bi 1.8GHz, pomoje je tale čist zadost dober, pa še cena je bolj ugodna

AMD Opteron DP Server Processor 242 ( AMDOSA242BOX ) 64-bit, 1600MHz Dual Processor Server - Retail with Heatsink and Fan**Free Shipping** .........Cena...sitnica 155.600 SIT>:D

minmax ::

ne neumnosti spuščat.

.... seti je aplikacija pri kateri interprocess comunication ni potreben (vsak paket je svoj data set) in hkrati data seti niso tako zelo veliki da ne bi mogli iti v večje cache. linearna skalabilnost bo tako povsod kjer imajo procesorji dovolj cachea.

to ni neka posebnost opterona

Thomas ::

Kaj zdej?

SETI obdeluje en data string. Da ne zna narediti tako, da bil vsak procesor obdelal svoj substring - je huda pomanjkljivost PROGRAMA.

A komu ni kaj jasno?

:\
Man muss immer generalisieren - Carl Jacobi

krneki ::

Jest mam pač na večprocesorskih mašinah več seti clientov, vsak na svojem procesorju.

Brane2 ::


to ni neka posebnost opterona


Je pa posebnost Opterona, da si CPUji med seboj načeloma ne kradejo ciklov, saj imajo svoj RAM. Tako posamezni threadi ne bremzajo threadov na sosednjih CPUjih zaradi dostopa do RAM-a, tudi če glavne zanke ne bi šle v CPU $$$...

minmax ::

brane2 ne bluzi, mešaš memory kontroler z memorijo

vsak procesor ima svoj ram, reče se mu cache, če lahko fitaš dataset v cache potem na nobeni multiprocesorski arihtekturi ne bo nobene kraje ciklov ali kakorkoli že temu praviš

če pa misliš na to, da lahko vsak procesor dostopa do svoje banke vzporedno ... to pri večini distribuiranih računanj sploh ni relevantno, ker gre cel dataset v cache.

Brane2 ::


brane2 ne bluzi, mešaš memory kontroler z memorijo


Ne bi reku. Po čem to sklepaš ?


vsak procesor ima svoj ram, reče se mu cache, če lahko fitaš dataset v cache potem na nobeni multiprocesorski arihtekturi ne bo nobene kraje ciklov ali kakorkoli že temu praviš


Deloma res. Procesorji pa še zmeraj lahko delajo data snooping med sabo. Če se ne motim, to P3ke in Xeoni znajo in tudi počnejo. Ko torej en CPU spremeni podatek v svojem lokalnem kešu, katerega kopija se pa nahaja tudi v drugih procesorjih, je očitno potrebna sinhronizacija podatkov. A to je le en detajl. Pa tudi če to zanemarimo, velja kar si rekel le, dokler glavne zanke programa padejo v cache CPUja. To pa je fajn ko gre, še zdaleč ne gre vedno pri vseh programih.


če pa misliš na to, da lahko vsak procesor dostopa do svoje banke vzporedno ... to pri večini distribuiranih računanj sploh ni relevantno, ker gre cel dataset v cache.


To sploh ni res. Če bi blo to res, se večje mašine z veliko procesorji sploh ne bi prodajale. Vsi bi kupovali samo 1-CPU stroje in mrežne kartice...

Thomas ::

Ma jasno. Sploh je SETI obdelava taka, da bi lahko ZLAHKA tekli neodvisni procesi po substringih. Če le ne bi bilo "čudno" narejeno. Kar smo ob tem videli, da je.

:)
Man muss immer generalisieren - Carl Jacobi

minmax ::

distribuiranih računanj as in SETI, folding, DES cracking... torej teh o katerih govori novica.

mogoče nisem bil specifičen, skratka te programi se namerno lotevajo problemov pri katerih lahko vse skupaj dosežejo brez interpocess komunikacije in z ločenimi dataseti, ker drugače bi bili preveč neučinkoviti

point je v temu, da stvar gre v cache in torej opteronov memory controler on die nima nobene veze z hitrostjo setija pri večjem številu procesorjev

ker vsak dela na svojem data setu in ker vsak ta dataset gre v cache nimaš potrebe po nobeni sinhronizaciji pomnilnika med procesorji. še več... načeloma bi lahko ob ideanih pogojih vsak od procesorjev se odlopil od vodila za čas ko izračunava...

Thomas ::

Ja, vendar SETI program (očitno) ni tako napisan. Kar je podn.

Zdej mi je jasno, da SETI ne bi našel nič, pa če leteči krožnik pristane v polju repe zraven glavnega radioteleskopa! :D

;)
Man muss immer generalisieren - Carl Jacobi

BlazP ::

SETI@Home je bil napisan za distribuirano racunanje, ki poteka na navadnih domacih racunalnikih. Zarad mogoce 3% ljudi, ko laufa zadevo na vecprocesorskih sistemih je pa res brezveze pisat program, ko bo izvaju paralelno procesiranje. (to je sam moje mnenje)

Jux ::

@Thomas:

Če nisi dobro razumel, vsaj procesor obdeluje svoj paket in na koncu v količini časa ki ga potrebuje en pocesor za en paket obdela 4 pakete. Razumeš? SETI je že dobro napisan za več procesorske računalnike, grozno bi bilo če nebi bil, ker konec koncev je cel seti projekt večprocesorski računalnik.
web&blog&etc: http://lukabirsa.com

dr.J ::

Jasno, da je SETI napisan samo za en procesor; tudi hyperthreading mu pri tem ne more pomagati. Če bi bilo na voljo veliko neizkoriščenih večprocesorskih računalnikov naokoli, bi zagotovo napisali ustrezno aplikacijo in postavili en supercluster in bi že našli marsovce.

Sploh pa je od same aplikacije odvisno, kako dobro se jo da paralelizirati. Pri setiju itak ni po tem nobene potrebe; vsak pač dobi en substring.

Speedup je samo v teoriji enak številu procesorjev, v praksi je vedno manjši zaradi potrebne medsebojne komunikacije, kjer pa utegne biti hypertransport sila zanimiva zadeva.

Thomas ::

Jux,

> Mislili pa so, da bodo ob vklopu še preostalih treh procesorjev precej zmanjšali končni rezultat posameznega procesorja, a izkazalo se je, da temu ni tako.

Kaj to pomeni? Da si ne znajo razdeliti taska?


> Čas računanja štirih paketkov pri obremenjenih vseh štirih procesorjevso je bil zelo enak času, ki ga je potreboval en procesor za en paketek.

Kaj pa to pomeni? Da si ga le znajo?

Odvisno, kako razumemo. Da en procesor vseeno dela samo en paketek?

Če bi si jih razdelili (vsi vsakega), bi IMO moralo pisati: Vsota časov računanja 4 paketov.

IMO.

A nej grem zdej brat originalni članek?
Man muss immer generalisieren - Carl Jacobi

Jux ::

Jux,

>> Mislili pa so, da bodo ob vklopu še preostalih treh procesorjev precej zmanjšali končni rezultat posameznega procesorja, a izkazalo se je, da temu ni tako.
>Kaj to pomeni? Da si ne znajo razdeliti taska?
Ne, to pomeni, da se rezultat navkljub temu da se 4 paketi računajo na enkrat ni spremenil dosti (kar bi se po mnenju članka avtorja moral). To pomeni, da so se 4 procesorji res obnasali kot 4 procesorji.


>> Čas računanja štirih paketkov pri obremenjenih vseh štirih procesorjevso je bil zelo enak času, ki ga je potreboval en procesor za en paketek.
>Kaj pa to pomeni? Da si ga le znajo?
>Odvisno, kako razumemo. Da en procesor vseeno dela samo en paketek?

T_računanja(4)/St_Proc(4)=T_računanja(1)/St_Proc(1)
to pomeni točno to en procesor dela samo en paketek, vendar ker so štirje to počnejo štirje hkrati. Zanimivo je to, da so penali za tako izvajanje zelo majhni.
web&blog&etc: http://lukabirsa.com

Thomas ::

Ni čisto jasno - vsaj iz teksta ne - če vsak procesor zagrabi svoj paketek ali pa si razdelijo najprej prvi, potem drugi, tretji, potem pa vsi še četrti paketek.

Jest mislim, da Opteroni so očitno dobri. Če je tako ali če je tako.

Samo SETI sam pa multiprocesiranja večih procesorjev na enem paketku (bolj zgleda) - le ne podpira.

:)
Man muss immer generalisieren - Carl Jacobi

BlazP ::

SETI@Home ne podpira paralelnega procesiranja enega paketka. Vsak paket deluje kot nedeljiv proces. Pri vec procesorjih pac vsak izvaja svoj proces(ki nima nobene veze z ostalimi procesi) in ne potrebujejo medsebojne sinhronizacije in izmenjave podatkov. Stirje procesorji izracunajo stiri pakete v enakem casu kot en procesor en paket, pa ni vazno ali so na isti maticni plosci ali na stirih razlicnih:D

Brane2 ::


> Mislili pa so, da bodo ob vklopu še preostalih treh procesorjev precej zmanjšali končni rezultat posameznega procesorja, a izkazalo se je, da temu ni tako.

Kaj to pomeni? Da si ne znajo razdeliti taska?


Kot sem jaz dojel, ni tako. Tip je hotel reči, da na SMP Opteron plati en CPU obdeluje paket tiste dve uri in dvajset minut, pa če to dela sam ali če ostali bratci med tem časom premetavajo svoje pakete, kar je res lepo- linearen porast hitrosti obdelave. En CPU v času T obdela en paket, štirje pa štiri pakete.

NA SMP Intel Xeon ali AMD Athlon plati (verjetno) ne bi bilo tako, saj bi vsak CPU ostalim kradel cikle za dostop do pomnilnika...


BTW. Članek ni prikaz optimalnosti Setijevega programa, ampak so hoteli pokazati Opteronove posebnosti.
Za sam program verjetno ni tako pomembno ali si deli obdelavo enega paketa med drugimi programi ali je najmanjša enota obdelave paket in pač vsaka inkarnacija obdeluje svoj paket...

Zoidberg ::

Za zaključek lahko rečemo da je opteron res dober procesor.
Just keep on trying, keep on flying. I will be the light.

Thomas ::

Ja, na vsak način lahko rečemo tako!

O (ne)deljivosti SETI obdelav je bilo pa škoda zgubljati besed. Mea culpa!

:)
Man muss immer generalisieren - Carl Jacobi

Dr_M ::

NA SMP Intel Xeon ali AMD Athlon plati (verjetno) ne bi bilo tako, saj bi vsak CPU ostalim kradel cikle za dostop do pomnilnika...

kolikor jaz vem je bilo tako samo pri intelu, pri amdju pa ne. naj me kdo popravi ce se motim.

:)
The reason why most of society hates conservatives and
loves liberals is because conservatives hurt you with
the truth and liberals comfort you with lies.

Tarzan ::

Takole to gre. En paketek ne gre cel v L2 cache, čeprav je tako majhen. Od tu tudi razlika tiste minute, kot je znašala pri 4ih procesorjih. Ampak ta minuta je zanemarljiva v primerjavi s starimi dvoprocesorskimi sistemi. Naprimer Dual 2400+ @ 2600+ je Seti paketke obdeloval z komaj za odtenek večjo hitrostjo kot 1800+ @ 2100+; zakaj? Zato, ker je bil šibkejši procesor bolj navit (višji FSB), kar je več doprineslo k hitrosti, saj je pri hitrejših procesorjih memory bandwith zeloooo ozko grlo (že za en procesor, kaj šele za dva, ki si ga delita).

Torej Opteron zdaj nima več tega problema, ker si vsak procesor vzame svoj memory bandwith, poleg tega hypertransport hudičevo dobro opravlja svoj posel.

Hyperthreading & Seti = dva paketka v 30% daljšem času kot en sam paketek brez hyperthreadinga. Rezultat je precej več paketkov, ampak brez hitrostnih rekordov.

Intel: AMD & Seti = Intelovi P4 procesorji so zelo hitri pri računanju Setija in to predvsem na račun enormne hitrosti pomnilnika. Athlon je absolutni zmagovalec, kar se tiče Price/performance. Athlonu se, ko mu navijemo FSB prav tako močno povečajo performanse Setija.

Večprocesorski Intel sistemi prav tako občutijo padec hitrosti, kot stari dual Athlon MP sistemi.
...

Loki ::

kako slabo je napisana seti@home koda?
program je napisan tako, da imajo posamezni klienti (glede na OS/ arhikteturo) CIMBOLJ isto kodo, da je pri portanju iz ene platforme na drugo cim manj popravkov same izvorne kode, poleg tega tudi ni nobene optimizacije za razlicne procesorje (recimo tisti console window klient za wintel sisteme lavfa od procesorja 386 naprej :)) ); edine razlike nastanejo zaradi uporabe razlicnih kompajlerjev - recimo pri wintel verziji je bil uporabljen Intelov (en izmed najboljsih trenutno), pri wintel screensaverju Visual Studio (zato take razlike v casu, tudi ce je sama grafika v screensaverju izklopljena), linuxov (x86) pa je bil kompajlan z GCC.

hitrostni testi kazejo, da je absolutno najhitrejsi (med zgoraj nastetimi) wintel cmdline, ravno zaradi uporabljenega kompajlerja; lahko se ga pa lavfa tudi v WINE.

seti@home ne podpira vecih procesorjev in razlicnih optimizacij za procesorje (ceprav je neki kreker razbil kodo, jo optimiziral za P4 - SSE2 - in pohitritev je bila ogromna).


pa se za primerjavo med opteron multi in hyperthreadingom:
na dual sistemih (ali vecjih - pri tem sta misljena recimo athlon in P3) se cas racunanja enega paketka (ce lavfata dva simultano) poveca za pribl. 20-30%.

Tarzan ::

Kje si pa dobil informacijo o SSE2? To me pa res zanima. Sicer se tega ne sme uporabljat, oziroma te Berkly kaznuje za tako početje, ker so v preteklosti nekateri že patchali Seti kliente ;)

Loki ::

news://alt.sci.seti ze zelo dolgo casa nazaj (min. eno leto). vem, da je bil neki nemec to, sam ne vem vec uporabniskega imena. uporabi google groups iskanje.

glede na to, da je tip moral crackat klienta, je tako pocetje seveda nelegalno, ker je v nasprotju z direktivami seti@home team:

-enaka izvorna koda - posledicno popolnoma enaki rezultati na vseh platformah (nobene razlike pro xyz procesorju, ker zxy nabor ukazov predvideva zaokrozevanje na npr. 30 dec. namesto 31, kot je pri xxx procu. - fiktivni primer;
izjema so samo zgodnji P1 200 MMX (in starejsi), ki so imeli tkim. FDIV bug, ko ti je po dolgem racunanju prisla napacna vrednost ali preoverclockani procesorji (ponavadi so sicer simptomi pri njih taki, da ti naredijo izredno veliko kolicino paketkov v izredno kratkem casu - npr. 3 min, ker z napacnim izracunom predvidijo napacen nadaljni potek racunanja).
obojni rezultati se seveda zavrzejo, ker s@h dela 2x do 3x checking podatkov (kolikor je pac presezka glede na sprejemnik v arecibu).

-ne smes disasemblat klienta in ga uporabljati za izracune.

Thomas ::

> kako slabo je napisana seti@home koda?

Takole:

> seti@home ne podpira vecih procesorjev in razlicnih optimizacij za procesorje (ceprav je neki kreker razbil kodo, jo optimiziral za P4 - SSE2 - in pohitritev je bila ogromna).

Če se jim gre res za najhitrejše možno izračunavanje, bodo v tolikih letih vendarle napisali tudi večprocesorsko varianto, saj večprocesorski sistemi so zunaj že dolgo. Da o SSE2 ne govorimo. Ane?

;)
Man muss immer generalisieren - Carl Jacobi

Brane2 ::

To je vse posledica pritiskov ameriške filmske industrije, da ŠE ne najdejo znakov zunajzemeljske inteligence.
Prodat nam morajo še vsaj 10.000 nadaljevanj Star Tracka... >:D >:D

Just a thought ...

CaqKa ::

bwahahahah

frenk ::

a sm se jest zgubu mau:\...al niso tole kao komentarji:\...zgleda je tole že forum:D


Vredno ogleda ...

TemaSporočilaOglediZadnje sporočilo
TemaSporočilaOglediZadnje sporočilo
»

Athlon 64 3400+: testi, testi, testi ...

Oddelek: Novice / Procesorji
173018 (3018) Pyr0Beast
»

Razlika med DDR266 in DDR400 ramom

Oddelek: Kaj kupiti
361798 (1367) boštjan
»

Regulatorji ventilatorjev - kateri je najboljsi po vasem mnenju?

Oddelek: Hlajenje in modifikacije
211582 (1374) smilyxx
»

LAN party

Oddelek: Novice / --Nerazporejeno--
62007 (2007) Ziga Dolhar
»

AMD predstavil Athlona 64

Oddelek: Novice / Procesorji
52075 (2075) Matri[X]

Več podobnih tem