aktualności

AMD Ryzen Threadripper 3000 - poznaliśmy możliwe nazewnictwo nowej serii

13
16 października 2019, 13:20 Adrian Kotowski

Premiera Threadripperów 3000 nadchodzi wielkimi krokami, ale do tej pory nie wiedzieliśmy, jak oznaczone będą nowe chipy. Na szczęście właśnie się to zmieniło za sprawą wpisów w bazie danych SATA-IO, która zawiera zgłoszenia dotyczące najnowszych jednostek HEDT AMD. Jeśli ciekawi Was, jak nazywać się będą nadchodzące chipy, to zapraszamy do lektury dalszej części newsa.

Zgłoszenie w SATA-IO zostało złożone przez AMD 10 października tego roku, więc raczej mało prawdopodobne, by cokolwiek miało się zmienić do premiery. Jak widać na załączonej grafice, przy opisie modelu widzimy oznaczenie AMD Ryzen Threadripper 39x0X, co oczywiście mówi nam sporo o spodziewanym nazewnictwie. Środkowy "x" w numerze chipu zamieniony zostanie na cyfrę, która najpewniej będzie wyższa niż 5. Wynika to z faktu, że razem z Threadripperami do sprzedaży trafi też Ryzen 9 3950X, czyli najwyższy w hierarchii przedstawiciel zwykłych Ryzenów 3. generacji.

Możemy domyślać się, że wśród nowych Threadripperów zobaczymy wersje 3960X, 3970X, 3980X i 3990X. Ten pierwszy mógłby zostać przypisany do 24-rdzeniowego modelu, który został już oficjalnie zapowiedziany przez czerwonych. Niewykluczone też, że część ze wspomnianych układów otrzyma przyrostek "WX", tak jak to miało miejsce choćby w Threadripperze 2990WX. Jest to o tyle prawdopodobne, że AMD ma podobno szykować dwie różne platformy TRX40 i TRX80, przeznaczone do różnych zastosowań.

Przypominamy raz jeszcze, że Threadrippery 3. generacji pojawią się na rynku w listopadzie tego roku. Według niepotwierdzonych jeszcze informacji, nowe chipy nie będą kompatybilne z obecnie dostępnymi płytami głównymi X399. Klienci myślący o nabyciu jednostek z nowej serii muszą też nastawiać się na kupno nowej płyty.

Źródło: SATA-IO
likoZobacz profil
Poziom ostrzeżenia: 0%
liko2019.10.16, 13:44
Przydałoby się więcej softu wykorzystującego możliwości tych bestii.
KenjiroZobacz profil
Poziom ostrzeżenia: 0%
Kenjiro2019.10.16, 14:03
@liko: Niestety, przygotowanie takiego softu nie jest łatwe, a przepisanie starego, aby wykorzystywał wiele rdzeni jeszcze trudniejsze.
Do tego dochodzą inne ograniczenia, np. UI w Windowsie jest jednowątkowe i nie da się zaktualizować kilku list/pól/whatever równocześnie, i trzeba się babrać w mieszanie kodu wielowątkowego z jednym wątkiem UI.
Rybaczek KoziołkaZobacz profil
Poziom ostrzeżenia: 33%
Rybaczek Koziołka2019.10.16, 14:24
-2#3
W tych potworach jako cache L3 mogliby pakować duże kości HBM :) byłby niezły kop.
AssassinZobacz profil
Poziom ostrzeżenia: 0%
Assassin2019.10.16, 14:36
Lepiej jako L4 podpięte pod cIOD.
GandalfGZobacz profil
Poziom ostrzeżenia: 0%
GandalfG2019.10.16, 16:46
64 rdzenie w 'domowym' kompie Wooo
Swoją drogą AMD zrobiło kawał niezłej roboty z pierwszą edycją ZEN/EPYC bo na drugą zamówienia na superkomputery sypią się jak z rękawa.
Teraz po Włochach, Niemcach i USA angole zamówili sobie bestię na nowych EPYCAch i GPU AMD
https://insidehpc.com/2019/10/amd-to-power...uter-in-the-uk/
jar3czekZobacz profil
Poziom ostrzeżenia: 0%
jar3czek2019.10.16, 17:14
Kenjiro @ 2019.10.16 14:03  Post: 1220173
@liko: Niestety, przygotowanie takiego softu nie jest łatwe, a przepisanie starego, aby wykorzystywał wiele rdzeni jeszcze trudniejsze.
Do tego dochodzą inne ograniczenia, np. UI w Windowsie jest jednowątkowe i nie da się zaktualizować kilku list/pól/whatever równocześnie, i trzeba się babrać w mieszanie kodu wielowątkowego z jednym wątkiem UI.

Większość frameworków od GUI(czy to Windows, QT, Android czy inne) działa na zasadzie jednego głównego wątku służącego do wyświetlania aktualizacji UI i powoływaniu długich/blokujących operacji w dodatkowych wątkach, które następnie komunikują się z wątkiem UI za pomocą np. callbacków (typowy case -> pobranie danych w request http i wywołanie callbacku do wątku UI w celu wyświetlenia danych). I to akurat nie jest żaden bottleneck.
supervisorZobacz profil
Poziom ostrzeżenia: 0%
supervisor2019.10.16, 17:21
GandalfG @ 2019.10.16 16:46  Post: 1220188
64 rdzenie w 'domowym' kompie Wooo
Swoją drogą AMD zrobiło kawał niezłej roboty z pierwszą edycją ZEN/EPYC bo na drugą zamówienia na superkomputery sypią się jak z rękawa.
Teraz po Włochach, Niemcach i USA angole zamówili sobie bestię na nowych EPYCAch i GPU AMD
https://insidehpc.com/2019/10/amd-to-power...uter-in-the-uk/

HEDT nie jest bardzo 'domowym' rozwiązaniem. Na myśl najpierw przychodzą stacje badawcze, szpitale i studia obróbki graficznej/video, miejsca gdzie potrzeba dużo rdzeni ale nie serwera. Poprzednie Threadrippery mogły jeszcze być domowe w wersjach 12, lub najwyżej 16 rdzeni. Teraz te miejsce zajmuje Ryzen 3900X i 3950X.
Edytowane przez autora (2019.10.16, 17:24)
blubajuZobacz profil
Poziom ostrzeżenia: 0%
blubaju2019.10.16, 18:21
-5#8
supervisor @ 2019.10.16 17:21  Post: 1220198
Poprzednie Threadrippery mogły jeszcze być domowe w wersjach 12, lub najwyżej 16 rdzeni. Teraz te miejsce zajmuje Ryzen 3900X i 3950X.

A 'w domu' wykorzystasz te 16 rdzeni? Aaa no tak, zapewne na przeglądaniu neta i w grach.
I nie, nie każdy streamuje...
supervisorZobacz profil
Poziom ostrzeżenia: 0%
supervisor2019.10.16, 18:52
blubaju @ 2019.10.16 18:21  Post: 1220206
supervisor @ 2019.10.16 17:21  Post: 1220198
Poprzednie Threadrippery mogły jeszcze być domowe w wersjach 12, lub najwyżej 16 rdzeni. Teraz te miejsce zajmuje Ryzen 3900X i 3950X.

A 'w domu' wykorzystasz te 16 rdzeni? Aaa no tak, zapewne na przeglądaniu neta i w grach.
I nie, nie każdy streamuje...

Oczywiście że wykorzystam, domowi youtuberzy nie idą w HEDT i muszą na czymś obrabiać video. Stream to kolejna sprawa, oprócz tego jest jeszcze multitasking - ja np. gram w Total Wara i w tle chodzą mi tury, a w międzyczasie pykam w World of Warships czy Path of Exile, plus przeglądarka, i szczerze chciałbym jeszcze ze 4 rdzenie (12 rdzeni) aby to wszystko jeszcze trochę upłynnić..
12 i 16 rdzeni znajdzie jeszcze swoje miejsce u 'domowego' użytkownika. Wszystko powyżej to już jednak sprzęt dla profesjonalistów.

Domowy użytkownik =/= leming.
Lemingi nie potrzebują więcej niż wymaga ich 'jedna gra'.
Edytowane przez autora (2019.10.16, 19:08)
NamonakiZobacz profil
Poziom ostrzeżenia: 0%
Namonaki2019.10.16, 19:18
jar3czek @ 2019.10.16 17:14  Post: 1220196
Kenjiro @ 2019.10.16 14:03  Post: 1220173
@liko: Niestety, przygotowanie takiego softu nie jest łatwe, a przepisanie starego, aby wykorzystywał wiele rdzeni jeszcze trudniejsze.
Do tego dochodzą inne ograniczenia, np. UI w Windowsie jest jednowątkowe i nie da się zaktualizować kilku list/pól/whatever równocześnie, i trzeba się babrać w mieszanie kodu wielowątkowego z jednym wątkiem UI.

Większość frameworków od GUI(czy to Windows, QT, Android czy inne) działa na zasadzie jednego głównego wątku służącego do wyświetlania aktualizacji UI i powoływaniu długich/blokujących operacji w dodatkowych wątkach, które następnie komunikują się z wątkiem UI za pomocą np. callbacków (typowy case -> pobranie danych w request http i wywołanie callbacku do wątku UI w celu wyświetlenia danych). I to akurat nie jest żaden bottleneck.

W przypadku Windows API obsług GUI jest zbudowana za pomocą mechanizmu wiadomości; OS wysyła wiadomości o klikniecie, ruchu myszą, zmianie wyświetlanego tekstu czy zamknięciu okna.
Każdy watek a nawet proces może wysyłać wiadomości za pośrednictwem systemu do aplikacji.
Obsługa przychodzących wiadomości zajmuje się tak zwana 'pompa wiadomości' rezydująca najczęściej w głównym wątku
czyli szereg wywołań GetMessage (, TranslateMessage) i DispatchMessage. W grach zamiast blokującej GetMessage jest używana PeekMessage.
Przetwarzaniem wiadomości zajmuje się callback WNDCLASS::lpfnWndProc zwany 'procedura okna'.
Ale o ile wiem to każda wiadomość jest przetwarzana w oddzielnym wątku przynajmniej na rodzinie Windows NT.
https://docs.microsoft.com/en-us/windows/w...sting-a-message
PS: QT już od dawna nie jest jedynie 'framework'iem od GUI'
Edytowane przez autora (2019.10.16, 19:29)
Zaloguj się, by móc komentować
1