komentarze
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)
blubajuZobacz profil
Poziom ostrzeżenia: 0%
blubaju2019.10.16, 20:33
-5#11
supervisor @ 2019.10.16 18:52  Post: 1220209

Domowy użytkownik =/= leming.

Nie każdy jest YouTuberem i obrabia Terabajty Video
Nie każdy streamuje
Nie znam nikogo kto by grał w dwie gdy naraz. No ale może są tacy.

Ale abstrahując od tego, to mając nawet te 64 rdzenie zrobiłbyś to jeszcze szybciej/płynniej niż na 16 rdzeniach. :)
Czyli rozumiem że jak ktoś nie jest YouTuberem, nie streamuje itp to jest lemingiem?
Aha spoko.
Edytowane przez autora (2019.10.16, 20:36)
supervisorZobacz profil
Poziom ostrzeżenia: 0%
supervisor2019.10.16, 20:42
blubaju @ 2019.10.16 20:33  Post: 1220233
supervisor @ 2019.10.16 18:52  Post: 1220209

Domowy użytkownik =/= leming.

Nie każdy jest YouTuberem i obrabia Terabajty Video
Nie każdy streamuje
Nie znam nikogo kto by grał w dwie gdy naraz. No ale może są tacy.

Ale abstrahując od tego, to mając nawet te 64 rdzenie zrobiłbyś to jeszcze szybciej/płynniej niż na 16 rdzeniach. :)
Czyli rozumiem że jak ktoś nie jest YouTuberem, nie streamuje itp to jest lemingiem?
Aha spoko.
Leming zastosowałem jako uproszczenie mające wskazać najzwyklejszego 'używacza komputera'.
Widzę że nie dopuszczasz do siebie myśli że ktoś robi na komputerze więcej niż jedną rzecz naraz, no cóż, twoja sprawa. Jednak ludzi którzy robią więcej niż jedną rzecz jest naprawdę dużo. Gry wykorzystują już sześć rdzeni, dodatkowo jak ktoś ma otwartą masę okienek w przeglądarce już wykorzystuje potencjał 8rdzeniowego procesora.

Jednokomórkowce nigdy nie zrozumią organizmów złożonych.
p_liderZobacz profil
Poziom ostrzeżenia: 0%
p_lider2019.10.16, 21:00
Namonaki @ 2019.10.16 19:18  Post: 1220217
jar3czek @ 2019.10.16 17:14  Post: 1220196
(...)

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'

Ooo, widzę, że ktoś tutaj pisał w czystym WinAPI :) Pozdrawiam i witam w klubie :) BTW - dobrze napisane!
Zaloguj się, by móc komentować