Intel odsyła procesory Xeon Phi na emeryturę

1. Zeszło im (autor: kombajn4 | data: 25/07/18 | godz.: 08:14)
   zanim się zorientowali ze stworzyli krzem o który chyba nikt specjalnie nie prosił. Zapomnieli że poza wydajnym w specyficznych zastosowaniach krzemem musi być jeszcze do niego oprogramowanie i zapotrzebowanie na rynku.
   
   
2. @1. (autor: Kenjiro | data: 25/07/18 | godz.: 08:36)
   Po prostu nie nadążają za konkurencją, którą w tym przypadku jest nVidia, a ta obsadziła większość rynku obliczeń równoległych.
   Myśleli, że przyciągną ludzi zgodnością z x86, ale nikomu na tym nie zależy, szczególnie że nVidia daje kompilator C/C++, co załatwia temat.
   
   
3. @Kenjiro (autor: pandy | data: 25/07/18 | godz.: 10:45)
   Wybacz ale chyba nie bardzo rozumiesz obszar o którym piszesz. NV nie oferuje żadnego podobnego rozwiązania a GPU to nie są CPU.
   Podobnie jest z naiwna wiara w kompilatory...
   jeśli byłoby tak jak piszesz to mielibyśmy x264 czy x265 skompilowane magicznymi kompilatorami na GPU NVidii i deklasowałyby one x264 i x265 na x86 a tak zwyczajnie nie jest i nikomu nie udała się ta sztuka (z chęcią zobaczę rezultaty x264 na x86 i na GPU Nvidi)
   Prywatnie uważam ze po prostu Intel zaczyna rozumieć ze x86 ma swoje ograniczenia... zobaczymy co zrobi Intel w swoich GPU.
   
   
4. @pandy (autor: ligand17 | data: 25/07/18 | godz.: 14:18)
   chyba sam nie rozumiesz obszaru, o którym jest mowa. Po prostu w przypadku obliczeń nVidia i jej CUDA aktywowane dedykowanym kontrolerem oferują większą wydajność, niż Intel z Phi.
   A odnośnie x264/x265 to przecież nie od dzisiaj wiadomo, że (de)kodowanie sprzętowe z wykorzystaniem GPU jest dużo szybsze od programowego, robionego przez CPU.
   
   
5. do 3 (autor: Atak_Snajpera | data: 25/07/18 | godz.: 14:23)
   Nawet do kompresji wideo ten PHI słabo się nadawał.
   72 atomowe jaja taktowane zegarem 1,6GHz to bida z nędzą przy takim Threadripper 2950x@3,4GHz (32C). IPC tego PHI było ~2x mniejsze od Zen1. Nic dziwnego że intel ubija to dziwadło.
   
   
   
   
   
6. Do 4 (autor: Atak_Snajpera | data: 25/07/18 | godz.: 14:30)
   Sprzętowe kodery AVC/HEVC są szybkie bo idą mocno na skróty w kwesti jakości!
   
   HVENC (h.265) dostaje bęcki nawet od x264 (h.264)
   https://forum.videohelp.com/...NVENC-HEVC-(Staxrip)#post2523894
   
   
7. @ligand17 & et al (autor: pandy | data: 25/07/18 | godz.: 19:26)
   Serio? oferują większą wydajność ale tylko w bardzo specyficznych aplikacjach - klasycznym przykładem jest cała masa aplikacji które napisane są jedno góra dwuwątkowo bo synchronizacja wątków kosztuje więcej niż ewentualny zysk ze zrównoleglania - wydajność MPP zazwyczaj nie skaluje się liniowo a pewnym momencie dochodzi do załamania bo nie da się bardziej zrównoleglać problemu i komunikacja miedzy takimi "atomami" (zdekomponowanymi fragmentami na które można podzielić dane) zaczyna kosztować więcej niż zysk z ich ilości (a zegary są zazwyczaj mniejsze niż w CPU).
   Eksperymenty z takim przetwarzaniem są prowadzone od co najmniej 60 lat i dalej jest to nisza co prawda ulegająca poszerzeniu ale nisza.
   x264/x265 to są enkodery a nie dekodery i nie znam żadnego dekodera (tym bardziej enkodera) H.264/H.265 używającego GPGPU - używane są ASP czyli dedykowane bloki enkoderów/dekoderów (np NVENC) pracujące równolegle do GPU ale będące kompletnie niezależnym od GPU modułem. Nawet popularne RPi ma oddzielny GPU i oddzielny procesor video który dekoduje i enkoduje w kilku różnych formatach (i o ile dokumentacja do GPU jest dostępna o tyle dokumentacji do VPU nie ma).
   Nie znam żadnej implementacji enkodera/dekodera w CUDA ale chętnie się czegoś nowego dowiem.
   @Atak_Snajpera - owszem goły Phi być może nie radził sobie rewelacyjnie ale zakładam ze znasz takie rozwiązanie Intela jak Intel® Visual Compute Accelerator - tam siedzą 3 Xeony - myślę ze spokojnie jeden Phi zrobiłby ich robotę tylko może się okazać ze byłby droższy (np powierzchnia krzemu).
   Co do jakości - podobno to się mocno poprawiło po ostatnim firmware do NVEnc - po prostu takie ASP nie wykorzystując pełni możliwości codeca np AMD nie używa klatek B a NVidia robi to nieoptymalnie... tylko Intel a i to w trybie hybrydowym (CPU + QuickSync) oferuje bitstream zbliżony do takiego który produkuje np x265.
   Ja myślę ze Phi wyszło z rynku na jakiś czas - w przyszłości może pojawić się obudowane dodatkowo FPGA - warto pamiętać ze koncepcje superkomputera w mikroprocesorze to właśnie praca Intela i pamiętnego Intela 860 który dal efekt w postaci rodziny Pentium II i np instrukcjom wektorowym (MMX i późniejsze SSE, AVX etc) - to właśnie iAPX860 był pierwszym nowoczesnym procesorem który przenosił idee z superkomputerów do układu scalonego - nie był to sukces komercyjny Intela bo i i860 nie był zgody z rodzina x86, i mało wtedy RAM było i kompilatory niskiej jakości (ich jakość nie poprawiła się aż tak znacząco jak przedstawiają to miłośnicy CUDA) - być może Intel mógłby wrócić do tej koncepcji w przyszłości... (choć pewnie nie wykorzysta tej ciekawej ISA która miał i860).
   Napisze to raz jeszcze wyraźnie - najlepsze obecne kompilatory są kilka - kilkanaście razy wolniejsze niż dobrze napisany kod maszynowy - kompilatory po prostu nie rozumieją pewnych rzeczy i nie wyręczą programistów od tworzenia kodu w taki sposób by do maksimum wykorzystywał HW. To łatwo można sprawdzić wyłączając w x264/x265 używanie ręcznie zoptymalizowanych fragmentów kodu - spadek prędkości jest dramatyczny. Nieprzypadkowo w źródłach x264 czy x265 mamy foldery z krytycznymi funkcjami napisanymi ręcznie w assemblerze np x86 (ale nie tylko) - w git x264 w folderze x86 takich funkcji jest 21... Od kilkudziesięciu lat kompilatory są coraz lepsze ale czasem po prostu nie ma innego wyjścia jak ręcznie napisać kod a GPU nie są wyjątkiem (ze względu na pewne ograniczenia architekturalne mogą być nawet wrażliwsze niż CPU).
   
   Cytat z Wikipedii ( https://en.wikipedia.org/...phics_processing_units ) trafnie oddający istotę GPGPU:
   "GPGPU is fundamentally a software concept, not a hardware concept; it is a type of algorithm, not a piece of equipment. However, specialized equipment designs may even further enhance the efficiency of GPGPU pipelines, which traditionally perform relatively few algorithms on very large amounts of data."
   
   
8. @ligand17 (autor: grafenroot | data: 25/07/18 | godz.: 20:11)
   No toś chłopie błysnął z tymi x264/x265. Te enkodery są sprzętowe i nie mają nic wspólnego z GPU (poza tym, że są przeważnie na tym samym kawałku krzemu).
   
   
9. @pandy (autor: ligand17 | data: 26/07/18 | godz.: 10:31)
   przecież o to właśnie chodzi - o te specyficzne zastosowania, gdzie karty nV wgniatają w ziemię zwykłe procesory: przetwarzanie dużych ilości danych w datacenters, obliczenia inżynieryjna, obliczenia numeryczne, matematyczne itp.
   
   
10. @ligand17 (autor: pandy | data: 26/07/18 | godz.: 20:51)
    No nie - podaj np rozwiązanie NVidii oferujące podobne parametry co Intel Visual Compute Accelerator - Phi po prostu był zbyt drogi i zbyt mało popularny co nie oznacza automatycznie ze wolniejszy niż NVidia. Zresztą sama NVidia ma tu niepewną pozycje zważywszy na ciągle wątpliwości związane z dokładnością obliczeń...
    
    
11. @pandy (autor: ligand17 | data: 27/07/18 | godz.: 11:58)
    Pierwszy przykład z brzegu, nawet nie sięgając do wyspecjalizowanych zastosowań:
    https://www.xcelerit.com/...ocessors/k80_p100_phi/
    AFAIR to wątpliwości dotyczące dokładności były obserwowane, jak ktoś próbował używać zwykłej karty graficznej, zamiast dedykowanego rozwiązania?
    
    
12. @ligand17 (autor: pandy | data: 27/07/18 | godz.: 12:22)
    To są bardzo wyspecjalizowane zastosowania...
    Poza tym popatrzyłem sobie na ilosc rdzeni i jasne jest dla mnie ze jeśli problem można zdekomponować na taka ilosc rdzeni to GPUGP będzie górą - problemem jest podzielenie na tak dużą ilosc wątków czegoś innego.
    Z tego co czytam problemy obserwowano na Teslach a wiec tam gdzie używano ECC i jak podawała NVidia zoptymalizowanych do takiej klasy zastosowań...
    I by jednak wrócić do sedna sprawy - dlaczego nie ma na GPGPU np właśnie enkoderów video albo dlaczego nie można uruchomić na GPU np Linuxa? Sugestia wyrażona w komentarzach była taka - wziąć źródło np linuxa, kompilator CUDA i wygenerować kod który można uruchomić na GPU - np by mieć kilkaset - kilka tysięcy niezależnych maszyn z linuxem...
    
    
13. skoro i tak sie chca wbic (autor: pawel1207 | data: 28/07/18 | godz.: 00:04)
    w karty graficzne to mnie nie dziwi zarzynaja produkt aby zrobic miejsce dal nastepcy po co konkurowac samemu ze soba .