Twoje PC  
Zarejestruj się na Twoje PC
TwojePC.pl | PC | Komputery, nowe technologie, recenzje, testy
M E N U
  0
 » Nowości
0
 » Archiwum
0
 » Recenzje / Testy
0
 » Board
0
 » Rejestracja
0
0
 
Szukaj @ TwojePC
 

w Newsach i na Boardzie
 
TwojePC.pl © 2001 - 2024
Środa 25 lipca 2018 
    

Intel odsyła procesory Xeon Phi na emeryturę


Autor: Zbyszek | źródło: Intel | 05:50
(13)
Intel poinformował o planach zakończenia produkcji ośmiu modeli procesorów obliczeniowych Xeon Phi z serii Knights Landing. W efekcie z oferty znikną modele Xeon Phi 7210, 7210F, 7230, 7230F, 7250, 7250F, 7290 i 7290F. Zamówienia na te układy będzie można składać tylko do 31 sierpnia bieżącego roku, wybierając datę dostawy nie późniejszą niż 19 lipca 2019 roku. Procesory Xeon Phi wykorzystują architekturę MIC (Many Integrated Cores). Zainteresowanie nimi raczej nie było nigdy zbyt duże - być może z tego powodu niedawno porzucono plany wprowadzenia ulepszonych procesorów Xeon Phi o nazwie kodowej Knights Hill, produkowanych w 10nm procesie litograficznym.

Intel tłumaczy decyzję o wycofaniu z oferty procesorów Xeon Phi tym, że oczekiwania i popyt rynkowy skierował się w stronę jego innych produktów. Być może krzemowy gigant zamierza zastąpić lukę po procesorach Xeon Phi własnymi akceleratorami graficznymi,opracowywanymi przez zespół Raja Koduriego.



 
    
K O M E N T A R Z E
    

  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 .

    
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ć.