8-rdzeniowy i 16-wątkowy Xeon E5-2687W przetestowany
Autor: Wedelek | źródło: WCCFTech | 07:43
(15)
Oprócz desktopowych Sandy Bridge-E, które miały już swoją premierę, na początku 2012 roku pojawią się również serwerowe odmiany CPU Intela z tą architekturą. Wejdą one w skład procesorów Xeon E5 i będą wyposażone w rdzenie Sandy Bridge-EP (specjalnie zoptymalizowany Sandy Bridge-E). Jeden z takich procesorów, oznaczony symbolem E5-2687W trafił w ręce znanego entuzjastom i wzbudzającego kontrowersje użytkownika OBR, który rzecz jasna wykonał testy jego wydajności w programach CineBench R11.5 oraz 3D Mark 11 (Physics).
Testowany układ był wyposażony w 20MB pamięci podręcznej trzeciego poziomu oraz 8 rdzeni i 16 wątków, które oryginalnie są taktowane zegarem 3.1 Ghz. TDP tego modelu to 150W, a jego cena w chwili debiutu będzie wynosić 1885 dolarów.
Nowy Xeon jest kompatybilny z podstawką LGA 2011 i chipsetem X79 (Patsburg-D), a niektóre procesory serwerowe Intela będą mogły pracować w konfiguracji dwuprocesorowej.
Ale przejdźmy do najważniejszego, czyli wyników, które kształtowały się następująco dla tego modelu:
CineBench R11.5 (wiele rdzeni) – 13.07 punktów
3D Mark 11 (test Physics) – 14141 punktów
Uzyskane wyniki nie zachwycają na tle 6-rdzeniowego Core i7 3960X, który w teście CineBench osiągnął rezultat wyższy o 1 punkt do czego zapewne przyczyniła się funkcja Turbo Core, która w Xeonie nie była aktywna.
"Bact to the Future" ? (autor: koski | data: 28/11/11 | godz.: 08:42) "Oprócz desktopowych Sandy Bridge-E, które miały już swoją premierę na początku 2012 roku"...
ciekawe (autor: Markizy | data: 28/11/11 | godz.: 09:43) 8 rdzeni gorsze od 6 w i7 3360x, a zegary z zbliżone, wygląda to na fake, wystarczy spojrzeć na test cinebench.
@Markizy (autor: VP11 | data: 28/11/11 | godz.: 11:03) Ja dawno zauwazylem taka tendencje, ze jak program zle napisan dla wielowatkowosci, to przy uzyciu kolejnych watkow wydajnosc rosnie, ale spada effektywnosc. Czyli jak uruchomilem obliczenia na 1 watku czas byl X. Przy odpaleniu 2-x obliczen czas wyniosl X+dX1, czyli zamiast 2*X dla kazdego (gdzyby odpalic na 1 rdzeniu) mamy X+dX1, przy czym dX1<<X.
Jak odpalimy cztery obliczenia czas juz wynosi X+dX2. Przy czym dX2>dX1. I wyszlo mi ze spadek wydajnosci dla czterordzeniowca przy obciazeniu 4-x rdzeni wyniosl 50%. Czyli dX3 = X/2. A wiec obliczenia licza 1.5X zamiast 4X. Niestety niby musialo byc nadal X.
Jak mamy dwuprocesorowy komp po 4 rdzeni, pelne obciazenie wydluza jeden watek o 80%. Czyli dX8=0.8X Czyli zamiast 8X (na jednordzeniowym jednoprocesorowym kompie) mamy prawie 2X dla 8 obliczen.
Prawdopodobnie za to wydzluzenie odpowiada zapchana jest komunikacja pamiec-procesor.
W przypadku rozdzielenia watkow w samym pojedynczym obliczeniu moze byc troche mniejszym (przy dobrej optymalizacji. przyklad karty graficzne), ale prawdopodobnie nadal zle zoptymalizowany. Moze dojsc ze wylaczenie HT na osmiordzeniowcu poprawi wynik.
VP11 (autor: Markizy | data: 28/11/11 | godz.: 15:01) może faktycznie kontroler pamięci intela jest coś nie teges http://pclab.pl/art47592-19.html
bo miedzy 2-3-4 kanałami są różnice minimalne, a już przy 6 rdzeniach powinno robić to różnice.
@up (autor: Plackator | data: 28/11/11 | godz.: 15:08) Po prostu nie jest potrzebna taka przepustowość, stad te małe różnice.
Jedne programy się dobrze skalują przy wielu watkach, inne nie, proste.
@Plackator (autor: VP11 | data: 28/11/11 | godz.: 15:34) Wedlug mnie to zalezy od rozwiazania.
W moim przypadku program pisali kiedy x64 jeszcze nie bylo. I przy takim rozwiazaniu 2GB przekroczyc nie bylo problemu. Chcesz nawet i 8GB, tylko by ilość procesorow byla wystarczajaca (5x2GB=10GB na uzycie pamieci).
Teraz patrzac na to ze klastry potrochu moga byc zastepowane wieleprocesorowymi maszynami i prawie nieograniczona iloscia pamieci (48GB to naprawde juz duzo), to zastosowane rozwiazanie zaczyna szwankowac. Natomiast w przypadku klasterow dalej bedzie dawalo przyzwoite rozwiazanie.
Musze powiedziec ze mowimy o programach ktore maja od 100MB i wiecej na jeden rdzen. I stad problem kontrolera pamieci. Musi dla kazdego watku dostarczyc duza ilosc pamieci w krotkim czasie.
Rozwiazanie kiedy to w trakcie pojedynczego programu idzie rozdzielenie na watki, strata moze byc znaczaco mniejsza.
Czyli dzieki temu ze obliczenie wywolywane jest dla malej przestrzeni, i prawdopodobnie pamiec sie miesci w keshu albo nie miesz kilkoma set MB na raz, skalowanie odbywa sie nie mal idealnie. dla 12 watkow skalowalnosc jest 11.76. Uwazam ze to calkiem dobry wynik.
Czyli glowne to czy program dobrze zoptymalizowany dla wielowatkowosci.
Zobaczcie najpierw testy Core i7 3960X na innych portalach (autor: Karak | data: 28/11/11 | godz.: 16:25) A później porównujcie - wynik? 10.xx dla 6 rdzeniowca bez OC.
@07 (autor: Plackator | data: 28/11/11 | godz.: 17:25) Tylko ze jak rozumiesz 100MB na rdzeń?
Niezależnie jaka objętość by miał program, program jest wczytywany i zapisywany w cachu, zanim zakończy się obliczanie tamtej części programu, nigdy program nie jest wczytywany bezpośrednio z RAM, nigdy, przenigdy.
@Wedelek (autor: Conan Barbarian | data: 29/11/11 | godz.: 08:10) Nie razi Cię pierwsze zdanie?
Nie widzisz, że po "miały już swoją premierę" konieczny jest przecinek? Dalej nawet nie czytam.
Zrozum w końcu, że to co napiszesz jest czytane przez wiele osób, które już wielokrotnie olewałeś, wystawiając sobie przy okazji odpowiedni certyfikat.
@Plackator (autor: VP11 | data: 29/11/11 | godz.: 08:17) Masz do wyliczenia czesc danych, ktore zajmuja po 100MB na jeden rdzen (4 rdzeni 400MB, 12 rdzeni 1.2GB). To mialem na uwadze.
To prawda ze procesor korzysta z cachu, ale te 100MB musi byc dostarczone do ceshu. Mozna zrobic tak, ze program do rdzenia pakuja bloki po 1MB jak struktura obliczen pozwala, i liczysz malutkie kawalki. W tym przypadku ilosc ramu zajmujacego nie ma znaczenia. Wazne ze da sie obliczac male kawalki programu osobno na innym rdzeniu i nie prosic w tym czasie z pamieci inne dane.
Ale jak kod powiedzmy ma kilka GB i pakuje na rdzen 300-800MB, i non stop pobiera albo zapisuje do roznych czesci pamieci, to jest duza szansa ze w pewnym momencie kontroler nie wyrobi, i procesor nie dostanie kawalku kodu, wykona pusty cykl.
Struktura obliczen w programie ma ogromna role na wydajnosc.
@Wedelek (autor: Conan Barbarian | data: 29/11/11 | godz.: 10:47) Dzięki za poprawkę.
@12 (autor: Plackator | data: 29/11/11 | godz.: 17:01) Nadal cie nie rozumiem, i przeliczanie instrukcji na MB, jeżeli w prostsze są liczone instrukcje, a sam cache nie może się
przeładować.
@Plackator (autor: VP11 | data: 30/11/11 | godz.: 08:53) Masz w pamieci macierz powiedzmy 10 000 wierszow. Program liczy korzystajac z calej macierzy. Najpierw wypelnia ja danymi z innej czeesci pamieci, nastepnie iteracyjnie poszukuje rozwiazania.
Chodzi o to jak jest uruchomionych kilka podobnych obliczen, ktore wymagaja intensywnej wymiany pomiedzy cechem a pamiecia. Przy zwiekszeniu ilosci takich programow, nastepuje wyczerpanie mozliwosci przesylu danych z pamieci do cechu i z powrotem.
Przynajmniej tak traktuje to. Bo inaczej niby czemu obliczenie ktore trwalo 40min, nagle zaczyna liczyc 60min albo i 70min. Dla sprawdzenia obliczenia uruchomiano kilka razy. Czyli blad jest powtarzalny.
Dla pojedynczego obliczenia (nic w tle nie chodzi) program liczy np. 40min. Jak uruchomimy dwa takie same obliczenia to liczy juz powiedzmy okolo 44-45min. Jak uruchomie 4 obliczenia to pojedynczy program liczy 60min.
Wiec prosze wytlumaczyc mi dlaczego zwalnia, jezeli ilosc pamieci nie ma na to wplywu bo ceche wszystko zalatwia ??
D O D A J K O M E N T A R Z
Aby dodawać komentarze, należy się wpierw zarejestrować, ewentualnie jeśli posiadasz już swoje konto, należy się zalogować.
