Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Spis by me zajimalo jestli pokud to pujde pouzit jako primarni procesor to budeme moct vyuzit doma na PC :D :D
Mohlo by to bejt pekny vedle GK mit neco takovedleho s 90+ jadry, myslim ze vykonove by to mohlo i i7 vytrit zrak :)
I kdyz v realite, kdyz pocitam vsechny instrukcni sady i7 a podobnych, turbo mody, hyperthreading, nevim nevim, ale prece jen vykonnejsi to bejt musi, ted jen jestli nejaka deska to zezere jako primarni CPU (pro domaci pc) a nejaky OS, linux asi jo, ale windows tezko ...
kazdopadne, muzeme se tesit do budoucna az s tim nekdo prijde :)
Rychlejší v čem? Ty máš na PC při normálním využití nějakou vysoce paralelizovanou úlohu? Proč si lidi pořád myslí že čím víc proužků tím víc adidas?
Já ano.
A co počítáš?
SHA-256.
hej, cinebench tam zbehne fakt rychlo, bezne aplikacie budu radovo pomalsie, kedze su vacsinou singlethreaded
a preco by s tym windows mal mat problem? win7 podporuje 256 cpu jadier, windows 8 podporuje 640 jadier, takze daky stojadrovy procesor nebude problem...
Rekl bych zePhi neni SMP jadro... ale sada procesoru s radicem ke spolecne zbernici, takze by to chtelo silne upravy jadra OS, aby to bezelo tak jak to kluci ocekavate :)
Mno, Intel Phi presentuje jako Coprocessor, takže nevím zda by byla dostačující úprava OS. Není to tak, že na tyto přídavné karty musí být napsané využití přímo v aplikaci?
Na zrychlení CB, jak by bylo zbožné přání, by to tedy nejspíš nebylo. Ale kdysi putovala internetem zmínka o předobjednávce na Larabee od Pixaru .
prave preto ziadnu upravu jadra OS netreba (narozdiel od NUMA architektury) navonok sa to moze tvarit ako velajadrovy procesor s jednym pamatovym radicom, rovnako ako nebolo treba upravu pre pentiumD, co boli dva procesory pripojene na jednu FSB
V 2014 pride Haswell-E (tento rok este len pride Ivy Bridge-E). Haswell-E vsak vyjde aj 8-jadrovy 16-vlaknovy. Konecne riadny posun od prvucickych 6-jadrovych 12-vlaknovych Nehalem snob-endov do sc. 1366 spred 4 rokov! T.j. narast vykonu o 33% (uz len vyssim poctom jadier) oproti dnesnym snob-endovym Intel CPU za tisic €. S vyssimi frekvenciami moze byt narast vykonu este vyssi. Uz aj tie dnesne snob-endove hovada za tisic € su neskutočné delá, ktoré nechávajú FX-8350 daleko za sebou.
Ovela radsej mat 8-jadrove 16-vlaknove neskutocne vykonne hovado za tisic € ako 60 jadrovu Phi kartu za 5 tisic €, ktorej vykon v single thread je hnusne maly ... Vykon v single thread je stale dolezity.
Neříkejme tomu výkon v single. Ale výkon na thread a taky IPC. Výkon na thread je nejdůležitější, z něj odvodíme i single, a když je třeba jader se tam prostě nahází víc, o vyspělosti archiektury rozhoduje ten výkon na thread a provozní vlastnosti při danném výkonu.
Mam tu čet tu mít jeden 24 jádrovej stroj (2x 12 jádrovej opteron) a musim poznamenat, že drtivá většina aplikací na tom neběhá dobře, resp ne tak jak by někdo doufal. Spusta aplikací je mutithreadovejch, ale složenejch z jednotlivejch na sebe nezávislejch threadů, tzn když je výkon na thread moc slow, je i apliakce slow protože multithread má pouze některé části.
A z těch aplikací co OK škálujou v multi jich opět jen malé procento škáluje hezky pokud se jde nad +- 8 jader. Tam většinou začíná průser.
Co škáluje ideálně je real-time encryption, hashing, x264 enkóding (pokud se použije dobrej SW) a to je asi tak vše co jsem našel. Zbytek programů má občas i lepší výkon když se polovina "jader" vyřadí.
tipoval by som to na problemy s NUMA architekturou, prakticky ziaden software ju automaticky nevie vyuzit optimalne a OS s tym tiez velmi zazraky nerobi, najlepsie je priradovat afinitu procesom a vlaknam manualne. ked totizto proces bezi na jednom procesore, ale pouziva ramku na druhom procesore, tak vykon ide velmi rychlo dole
Ne, tohle konkrétně nemá s numou co dělat. To jsem zkoušel. Třeba takovejch cinebench R10 se snaží renderovanou scénu rozsekat aby každej thread dostal svůj díl, ale při 24 threadech ten program stráví více času rozělováním scény než počítáním, je to děsně neefektivní. R11.5 už je na tom mnohem lépe díky těm krychlím kde si každej thread bere novou a nestará se o to co dělaj ty ostatní, tak to škáluje OK (numu nezná ani jeden cinebench, ta s tim nemá co dělat, ta limituje jen SW kterej padá na držku díky paměťové propustnosti). Ale opravdu toho SW co škáluje fajn nad 8 threadů je máááálo.
U her je to největší krize protože i ty co si říkaj optimalizované pro multithread jdou vždy jen tak rychle jak rychlej je zrovan ten 1 thread co bottleneckuje geometrii a animace eghm...
Stroj slouží k real-time enkódování x264 ze zachytávací karty, což je díky bohu to co mu zrovna jde a vužívá to oba CPU naplno. I tak to ale suxxovalo jako celek, bomba se z toho stala až když jsem to přetaktoval, protože 24 jader na 2,2 - 2,5 Ghz vs 24 na 3,8Ghz je drobátko rozdíl, ale to už je offtopic. A ano psal jsem 2,2 - 2,5 protože FX architektura i v serverech throtluje aby se vešla do TDP, bez ohledu na teplotu.
ako sa daju pretaktovat opterony?
Opatrne.
No, ono to neni tak jednoduchy mit to jako hlavni CPU. Nezapomente, ze v aktualni implementaci je kazde jadro ekvivalentni in-order Pentiu s pridanou vektorovou jednotkou, ktera neni kompatibilni s SSE. Takze zadne SSE, AVX, zadna virtualizace, zadny AESNI. Tim nevylucuju, ze se to v druhe generaci nezmeni. Jen pro zajimavost, to se asi moc nevi, ale kazde to in-order jadro ma 4-nasobny hyperthreading.
Jinak pustit tam OS neni zas takovej problem, protoze uz ted tam primo na karte bezi Linux, a to jako porad :) Takze kdyz tam offloadujete nejakej vypocet, tak se to jen preda po sbernicich tomu Linuxu a ten uz si to tam sam spousti. Zrovna tak tam je Linux proto, aby kazde to jadro rovnou slo vyuzit jako MPI node. A ten Linux neni zas tak moc opatchovanej, je tam jen par komunikacnich driveru.
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.