Komputer Z 72 Procesorami Pobiera 200 Watów Energii

[Gość Kaaban]

Firma SiCortex wprowadza na rynek swoje najnowsze dziecko o nazwie SC072 Catapult. Jest to klaster superkomputerowy wyposażony w 72 procesory i niewyobrażalną ilość pamięci operacyjnej, a przy tym wygląda jak zwykły PeCet i pobiera zaledwie 200 watów energii.

 

SC072 Catapult, określany jako HPC (High Performance Computer), działa na systemie Linux. Wspomniane 72 procesory to tak naprawdę 12 sześciordzeniowych chipów CPU połączonych na jednej płycie głównej. Urządzenie korzysta z pamięci RAM o gigantycznej pojemności 48 gigabajtów i opcjonalnie może zostać wyposażone w 3 gniazda PCI Express. W obudowie znalazło się także miejsce dla sześciu standardowych dysków twardych.

 

Co chyba najciekawsze, zgodnie z mottem firmy SiCortex, które brzmi "W komputerach najwyższej wydajności diabeł tkwi w miliwatach", SC072 pobiera jedynie 200 watów energii! Nie wspominając już o tym, że mieści się w obudowie typu little tower i bez problemu wejdzie na biurko obok monitora.

 

Ciężko wymyślić sposób na pełne wykorzystanie w domowym zaciszu mocy tej bestii. Może warto mieć taki sprzęt pod ręką na wypadek nagłej potrzeby sporządzenia modelu przemieszczania się huraganów w nadchodzącym sezonie. Jeśli ktoś musi się na taką okoliczność zabezpieczyć, wystarczy jedyne 15 tysięcy dolarów i domowy superkomputer będzie jego.

źródło: http://www.gram.pl/news_9QneGu6_Komputer_z...ow_energii.html

 

Niezły hardkor, ciekawe jak w środku wygląda :rolleyes:

[kszonek]

Dobre do wprimea ;)

[Komixx]

chciałbym zobaczyć fotkę tego kompa w środku xD

Edytowane 20 Listopada 2007 przez Komixx

[Sens]

Jak wygram w totka to se kupie :D:D

 

Ciekawe jak by sie gralo na takim sprzecie :D

[Komixx]

hm... i pewnie fajna zabawa by byla przy podkrecaniu XD hehehe

[Gość Pussik]

Ani slowa o wydajności.

 

 

Niedawno było głośno o 1W procku z zegarem 500MHz.

 

Tutaj też pewnie będzie góra 1GHz. :)

Ale przy 72 rdzeniach to wcale nie mało. :D

 

 

Dobre do renderingu.

[Gość <account_deleted>]

Ani slowa o wydajności.

... bo po pierwsze procesor to nie to, co się większości wydaje (np typowy kalkulator intela xD). Poza tym system ten jest pewnie tak bardzo mocno "dedykowany", że do tej pory jeszcze nikt nie zadedykował mu żadnego softu ;)

[Sens]

Powini umieścić na płycie cztery pci-e 16x do sli i zrobic stery pod windowsy i mozna sie bawić :D

Wtedy napewno bym kupił xD

[MacOSek]

Powini umieścić na płycie cztery pci-e 16x do sli i zrobic stery pod windowsy i mozna sie bawić :D

Wtedy napewno bym kupił xD

to raczej nie są procesory x86

[hary]

raczej na pewno ;]

[costi]

Powini umieścić na płycie cztery pci-e 16x do sli i zrobic stery pod windowsy i mozna sie bawić :D

Wtedy napewno bym kupił xD

Czym sie bawic? 70 rdzeni bedzie lezalo odlogiem, bo malo ktora gra wykorzystuje dwa jak trzeba, a co dopiero mowic o 72 :lol2:

[bryken]

moze 3d mark 2006 by sobie poradzil :D

[krzat]

Czym sie bawic? 70 rdzeni bedzie lezalo odlogiem, bo malo ktora gra wykorzystuje dwa jak trzeba, a co dopiero mowic o 72 :lol2:

Myślę, że to kwestia sterowników.

[Gość <account_deleted>]

Nie, to nie jest kwestia sterowników. Jeśli program nie przewiduje możliwości wykorzystania równoległej pracy procesorów, to i 500 rdzeni nic nie pomoże - będzie wręcz wolniej niż na 1 rdzeniu. Dlatego, jak już wcześniej napisałem, takie systemy buduje się pod konkretne zastosowanie, czasami nawet dla jednej konkretnej aplikacji.

W dzisiejszych czasach w najmocniejsze modele układów PLD można bez problemu wcisnąć kilka rdzeni, a ponieważ są to procesory opracowywane "od zera", czyli nie są obciążone koniecznością zachowania kompatybilności, to projektanci mogą "rozwinąć skrzydła". W efekcie porównywanie np. zegarów takich chipów z PC jest absurdalne - 400MHz może kłaść na łopatki 4GHz x86 intela, który tak na prawdę ma chyba najgorszą z istniejących na świecie architektur.

[PelzaK]

komputery z dużą ilością procesorów są raczej przeznaczone do typowej pracy równoległej i równoległego przetwarzania danych. Zwykłe procesory pod kontrolą np systemu windows przetwarzaja dane szeregowo, w szczególnych przypadkach mogą pracować prawie równolegle gdy mają więcej jąder. Ale nadal jest to w pewnym sensie praca szeregowa ino z podziałem zadań.

 

tomazzi, najgorszą to może nie :). Gdyby byłą najgorsza nie rządziła by rynkiem:)

[Gość <account_deleted>]

komputery z dużą ilością procesorów są raczej przeznaczone do typowej pracy równoległej i równoległego przetwarzania danych. Zwykłe procesory pod kontrolą np systemu windows przetwarzaja dane szeregowo, w szczególnych przypadkach mogą pracować prawie równolegle gdy mają więcej jąder. Ale nadal jest to w pewnym sensie praca szeregowa ino z podziałem zadań.

Każdy program jest wykonywany "szeregowo" czyli instrukcja po instrukcji (+ skoki). Praca równoległa to praca 2 lub więcej programów, które dzielą się danymi do przetworzenia lub zadaniami do wykonania.

 

tomazzi, najgorszą to może nie :). Gdyby byłą najgorsza nie rządziła by rynkiem:)

Napisałem "chyba najgorszą", co należy rozumieć: "najgorszą, jaką znam" (a znam dość dobrze kilka różnych procków)

Dlaczego zdobyli rynek? To już inna historia, Chińczycy też zdobywają stopniowo...

[jurek911]

Jak wygram w totka to se kupie :D:D

 

Ciekawe jak by sie gralo na takim sprzecie :D

e,chyba karta graf. byłaby tu wąskim gardłem :wink:

[Gość Pussik]

Sami pseudoznawcy architektury CPU.

A jak sama zalożyłam topic nieco bardziej zaawansownay a pytaniami o architekture GPU to ani jednej odpowiedzi przez miesiące nie ujrzałam.

 

A przecież budowa GPU jest imo dużo bardziej atrkacyjna od CPU.

[PelzaK]

Każdy program jest wykonywany "szeregowo" czyli instrukcja po instrukcji (+ skoki). Praca równoległa to praca 2 lub więcej programów, które dzielą się danymi do przetworzenia lub zadaniami do wykonania.

Nie musisz mnie uczyć jak jest wykonywany program w procesorze :). Mówię natomiast jaka jest różnica między komputerami szeregowymi i równoległymi i ten 72 procesorowy nie nadaje się dla przeciętnego zjadacza gier... Niektórzy się napalają jak na 500GHz'owy nieistniejący procesor IBMa :) Edytowane 22 Listopada 2007 przez PelzaK

[p3dzi0r]

od kiedy to program jest wykonywany zawsze szeregowo, z punktu widzenia architektury np itanium, ale w naszych zwyklych prockach tez to jest to przetwarzanie potokowe samo w sobie jest zaprzeczeniem przetwarzania szeregowego. To ze dane opuszczaja jednostke w szeregu nie znaczy ze sa przetwarzane szeregowo, po to wlasnie jest duzo jednostek wykonujacych i nasze kochane potoki xD. Niektore architektury przeciez sa budowane tak aby nawet poszczegolne procki mogly podmieniac sobie info z cache miedzy soba. Takze w grupie razniej ;]

[Gość <account_deleted>]

od kiedy to program jest wykonywany zawsze szeregowo, z punktu widzenia architektury np itanium, ale w naszych zwyklych prockach tez to jest to przetwarzanie potokowe samo w sobie jest zaprzeczeniem przetwarzania szeregowego.

Potoki operują na mikrokodzie i pełnią funkcję zaawansowanego prefetch-u. Nie zmieniają kolejności wykonywania instrukcji, nie operują na rejestrach (jawnych) procesora. Istnienie wielu potoków nie ma nic wspólnego z równoległym przetwarzaniem danych (użytkowych). Potoki są niewidoczne z poziomu asemblera, ich działanie można obejrzeć tylko w niskopoziomowym trybie diagnostycznym procesora, tj przez interfejs JTAG. To po prostu "inna bajka" ;)

Tak więc każdy program jest wykonywany szeregowo, a wielozadaniowość na jednym rdzeniu to poprostu softwareowa emulacja.

 

Niektore architektury przeciez sa budowane tak aby nawet poszczegolne procki mogly podmieniac sobie info z cache miedzy soba. Takze w grupie razniej ;]

To akurat jest sprawa oczywista - systemy, które tego nie potrafią są "dalekie od doskonałości" ;)

 

edit:

ps. najnowsze konstrukcje rdzeni wogóle nie posiadają "potoków", bo nowe rozwiązania pozwalają na wykonanie 1 a nawet 2 instrukcji w 1 cyklu zegara + jump prefetch ;)

Edytowane 22 Listopada 2007 przez tomazzi

[Uzurpator]

Tak więc każdy program jest wykonywany szeregowo, a wielozadaniowość na jednym rdzeniu to poprostu softwareowa emulacja.

Niekoniecznie - procesor moze miec dwa dekodery i potoki "bijące" się o jedno alu. Ie: hyperthreading.

 

ps. najnowsze konstrukcje rdzeni wogóle nie posiadają "potoków", bo nowe rozwiązania pozwalają na wykonanie 1 a nawet 2 instrukcji w 1 cyklu zegara + jump prefetch ;)

Mają potoki jak najbardziej, dla swojego wewnetrzengo risc'a. Prefetcher i dekoder mogą pozamieniać kolejność wykonywania operacji, tudzież alu, których może być i 10 ;) może wykonywać kilka rozkazów na takt. Nie wspominajac o spekulatywnym wykonywaniu kodu czy zmianie kolejności wykonywania operacji. Jednakże same alu ma na wejsciu potok.

 

Nie ma już chyba procka który pracowałby na natywnym kodzie x86 :P

[p3dzi0r]

2 instrukcje w cyklu to rozwiazanie superpotokowe ktore w zyciu okazuje sie mniej wydajne od standartowej koncepcji superskalarnej. Ale wiele potokow to zbytnia komplikacja ukladow zgadywania co warto a co nie wrzucic do potoku ;] dlatego np intel chcial sprobowac sztuczki z itanium ghdzie kompilator odwala zabawe w przewidywanie. (sorki ze non stop odnosze sie do tego itanium ale przetrzepali mnei z tego na uczelni ;], a to akurat dobry przyklad)

[Gość <account_deleted>]

Niekoniecznie - procesor moze miec dwa dekodery i potoki "bijące" się o jedno alu. Ie: hyperthreading.

Racja, ale chyba nie do końca zrozumiałeś co napisałeś: Procesor oddaje ALU na przemian dla jednego lub drugiego potoku, co nie zmienia faktu, że każdy z realizowanych programów jest wykonywany "szeregowo", tyle że na przemian: parę instrukcji z jednego, parę z drugiego. Nie jest to więc przetwarzanie równoległe, korzyść z tego żadna, lub co najwyżej śladowa ... życie zresztą samo pokazało :rolleyes:

 

Mają potoki jak najbardziej, dla swojego wewnetrzengo risc'a. Prefetcher i dekoder mogą pozamieniać kolejność wykonywania operacji, tudzież alu, których może być i 10 ;) może wykonywać kilka rozkazów na takt. Nie wspominajac o spekulatywnym wykonywaniu kodu czy zmianie kolejności wykonywania operacji. Jednakże same alu ma na wejsciu potok.

Prefetcher może zmienić kolejność dostępu do RAMu/Cache, ale nie może zmienić kolejności wykonywania instrukcji asm - to chyba jest oczywiste. Poza tym jak widzę masz na myśli klony x86, a to nie są jedyne procki na świecie ;]

 

Nie ma już chyba procka który pracowałby na natywnym kodzie x86 :P

100% racji, wszystkie obecne klony x86 to emulatory ;]

 

@p3dzi0r i nie tylko:

Intel jest zmuszony do zachowania kompatybilności "w dół". Architektóra x86 była do doopy w momencie powstania, a kolejne MHz, wielopotokość, prefetching, a nawet cache L1, L2 i L3 to po prostu szminkowanie trupa. Procesory oparte o 1 akumulator były hitem w latach 70 ;] Wszystkie normalne konstrukcje opierają się na zastosowaniu wielu uniwersalnych rejestrów, które są kilka razy szybsze od Cache, umożliwiają skrócenie kodu asm z powodu mniejszej ilości operacji na stosie i odwołań do RAMu. EM64T jest próbą naprawy tej sytuacji, ale do normalności jeszcze daleko.

A tymczasem świat idzie naprzód i kto wie, może w końcu pozbędziemy się z domów tego szmelcu... :rolleyes:

Edytowane 22 Listopada 2007 przez tomazzi

[Uzurpator]

Racja, ale chyba nie do końca zrozumiałeś co napisałeś: Procesor oddaje ALU na przemian dla jednego lub drugiego potoku, co nie zmienia faktu, że każdy z realizowanych programów jest wykonywany "szeregowo", tyle że na przemian: parę instrukcji z jednego, parę z drugiego.

Widzisz, i tutaj mamy problem. 1 instrukcja sse może rozbic sie na kilka instrukcji wewnetrznego mikrokodu. Ba, zwykledo ADDa można potraktowac jako kilkadziesiat operacji na pojedynczych bitach. Kolejnosc ich wykonywania jest dowolna.

Albo inaczej - jak to jest, że jednowątkowy jakby nie patrzeć athlon XP ma 3 alu?

 

Nie jest to więc przetwarzanie równoległe, korzyść z tego żadna, lub co najwyżej śladowa ... życie zresztą samo pokazało :rolleyes:

To jest przetwarzanie równoległe na wyższym nieco poziomie :> a jego skuteczność zależy głownie od stosunku ilosci alu do dekoderów oraz efektywnosci dekodera w kolejkowaniu wewnetrzenego risca.

 

Prefetcher może zmienić kolejność dostępu do RAMu/Cache, ale nie może zmienić kolejności wykonywania instrukcji asm - to chyba jest oczywiste. Poza tym jak widzę masz na myśli klony x86, a to nie są jedyne procki na świecie ;]

Prefetcher/Dekoder może w dowolny sposób mieszać kolejnością wykonywania uOpów, tak długo jak wynik będzie się zgadzać z asmem którgo zjada. Przykładowo (dość naiwnie zreszta) seria:

 

:et

mov adres1, ax

mov adres2, bx

add ax,bx

move bx, adres3

add 1, dx

je et 4, dx

 

(dawno w asmie nie pisalem, wybacz bledy w skladni)

 

może zostać rozbita na 4 jednoczesne dodawania, kiedy to dekoder sobie poprzemianowuje nazwy rejestrów, przy okazji movy do ax mogą być wykonane en-masse, potem mov do bx itd. Połowa logiki w współczesnych prockach jest za to odpowiedzialna. EDIT: oczywiscie w normalenj architekturze takie rzeczy robi kompilator :P

 

O VILWach i innej egzotyce/embedach tutaj nie mówimy :D

Edytowane 22 Listopada 2007 przez Uzurpator

[p3dzi0r]

duzo rejestrow czyli po prostu koncepcja risc (chyba xD , juz nie pamietam) , ot tyle ;] ktora przeciez jest obecnie stosowana (jakbym sie mylil to sprawdze dokladniej ;])

[Gość <account_deleted>]

...

Albo inaczej - jak to jest, że jednowątkowy jakby nie patrzeć athlon XP ma 3 alu?

To jest przetwarzanie równoległe na wyższym nieco poziomie :> a jego skuteczność zależy głownie od stosunku ilosci alu do dekoderów oraz efektywnosci dekodera w kolejkowaniu wewnetrzenego risca.

Prefetcher/Dekoder może w dowolny sposób mieszać kolejnością wykonywania uOpów, ...

No właśnie uOps to nie instrukcje asm wyplute przez kompilator, tylko ich zdekodowane fragmenty, widzę że jakby trochę się niezrozumieliśmy... każdy procesor na świecie dzieli instrukcje na fragmenty potrzebne dla różnych części rdzenia (dekoder adresów, alu, prefetcher, itd)

 

Przykładowo (dość naiwnie zreszta) seria:

...

może zostać rozbita na 4 jednoczesne dodawania, kiedy to dekoder sobie poprzemianowuje nazwy rejestrów, przy okazji movy do ax mogą być wykonane en-masse, potem mov do bx itd. Połowa logiki w współczesnych prockach jest za to odpowiedzialna. EDIT: oczywiscie w normalenj architekturze takie rzeczy robi kompilator :P

he, he, no dobra ale co Ty napisałeś? emulator DMA? xD Chodzi o to, że w normalnych programach obliczeniowych najczęściej nie da się tak łatwo pozamiatać (o prawdopodobieństwo się nie kłóćmy). Poza tym każda instrukcja każdego asm da się rozbić na różne fragmenty, które można różnie interpretować, przetwarzać i uzyskać dzięki temu różną wydajność - na tym właśnie polega różnica w wydajnościach procków AMD i Intela, czyli na prawdopodobieństwie ( ;) ) i optymalizacji.

 

@p3dzi0r: afain MC68000 był pierwszym cpu w jednej kości, który nie był RISCiem, a miał (ma) 8x32bit rej. danych i 8x32bit rej. adresowych. Lata 75 jak pamiętam... :lol2:

[p3dzi0r]

nie napisalem jaki nie byl risciem a tylko ze to jest taka koncepcja , nie nowa zreszta ;], ale faktyczie masz racje ze jezeli chodzi o koncepcje zwiekszania wydajnosci to producenci nie chca sie pakowac w wieksza ilosc jednostek wykonujacych i potokow bo to starasznie komplikuje logike, rozwiazaniem z prostsza logika i kompilatorem jest wlasnie itanium (na studiach gosciu chwali go pod niebiosa ) tymczasem wiki mowi ze byl to niewypal jezeli chodzi o rzeczywista wydajnosc ;], ponoc itanium2 byl lepszy, mniejsza o to. Faktem jest ze zadnej specjalnie innowacyjnej wydajnosciowo architektury niema (przynajmniej z takiego ogolnego rozeznania), bo moze i dysponujemy technologia pozwalajaca upchnac niewidomo ile tranzystorow ale nie wiadomo co z nimi zrobic ;] bo sie zwykle wiekszosc rzeczy po prostu nie oplaca ;].

[costi]

Alescie pofruneli :)

[Gość <account_deleted>]

Faktem jest ze zadnej specjalnie innowacyjnej wydajnosciowo architektury niema (przynajmniej z takiego ogolnego rozeznania), bo moze i dysponujemy technologia pozwalajaca upchnac niewidomo ile tranzystorow ale nie wiadomo co z nimi zrobic ;] bo sie zwykle wiekszosc rzeczy po prostu nie oplaca ;].

Wydajność jest często mylona z ilością MIPS i FLOPS, tymczasem nie jest ważne ile instrukcji procesor może wykonać w ciągu sekundy (czyli ile ma GHz ;] ), tylko ile instrukcji jest potrzebnych do zrealizowania konktretnego zadania. W tym kierunku są idą prace projektowe. Jako ciekawy przykład może posłużyć rdzeń ARM, który można programować zarówno w asm jak i w uops (thumbs) - daje to niesamowitego kopa wydajnościowego + drastycznie skraca kod wynikowy ;)

 

Alescie pofruneli :)

:D Latać każdy może... Edytowane 23 Listopada 2007 przez tomazzi