Link alla notizia: http://pro.hwupgrade.it/news/server-...ter_72328.html
Intel rimuove la futura generazione di acceleratori della famiglia Xeon Phi, in attesa di nuove microarchitettura e piattaforma associate Click sul link per visualizzare la notizia. |
Quote:
Intel negli ultimi anni sembra arrivare sempre un passo dopo gli altri, e ultimamente poi si sta facendo fregare da nVidia in tutti i nuovi mercati. |
Quote:
|
Quote:
i PHI li stanno dismettendo perchè non riescono a tenere il passo con le GPU nVidia e non si è creato quell'ecosistema che Intel sperava si creasse. le Tesla le vendono anche in workstation e trovano una miriade di applicazioni con software di terze parti gia pronti, le PHI, tolti gli accordi che fa Intel, non se le compra quasi nessuno e le prendono solo realta che poi si sviluppano anche il software. |
Pilotare decine di FPU con decine di core x86 era una idea sciocca che non poteva portare a risultati diversi. Ma era Intel e c'è voluto un po' perché gli investimenti scadessero e la concorrenza con duro lavoro lo dimostrasse (aiutata anche da i nuovi PP, vedesi miei antichi commenti sul fatto che i nuovi PP della concorrenza sarebbero stati una spina nel fianco per Intel non solo per quanto riguardava il mercato mobile).
Il prossimo passo di Koduri credo infatti che sarà mettere le enormi unità AVX in una architettura mesh (ala GPU) senza core x86 in mezzo a rubare spazio e a succhiare inutili W. D'altronde credo che anche Intel sia arrivata alla conclusione che l'architettura x86 non ha più il vantaggio che aveva prima (che era poi la quantità di transistor che poteva mettere in campo vs la concorrenza allo stesso prezzo e consumi) e nemmeno "l'avanzatissimo" PP che Intel proclama avere la aiuta più a coprire il gap che ha e da qualche anno sta cercando alternative, prima con le FPGA e ora con nuove architetture simil-GPU , ovviamente sempre collegate a x86, ma che sta prendendo un ruolo sempre più marginale rispetto a prima. Anche Intel ha smesso di voler spingere x86 ovunque anche là dove non è adatta allo scopo. In più altri contendenti sembrano interessati, come questi: https://en.wikichip.org/wiki/pezy/pezy-scx/pezy-sc2 Che già dimostrano come una architettura qualsiasi non necessariamente x86 può fare molto e anche meglio. |
INTEL deve finalmente cedere un po' del suo orgoglio e ricominciare a lavorare.
Colpire in qualche modo NVIDIA, lo ha fatto con l'accordo di partnership con AMD per processori modulari INTEL con grafica VEGA. Adesso, grazie all'acquisizione di Raja Koduri, non sarebbe improbabile pensare che AMD e INTEL convergano in un HW per Supercomputing condiviso (o per lo meno compatibile) in modo da non fare la fine di Labarree e creare i presupposti per un supporto software decente. In Fondo se NVIDIA "ha sfondato" è anche per il supporto software che ha dato alle sue schede video. |
Non ci si dovrebbe fermare soltanto al titolo, senza approfondire con la notizia e magari senza nemmeno aver visto la press release originale, prima di commentare.
Si parla chiaramente che il progetto Knights Hill, e solo questo, è stato cancellato perché l'azienda sta lavorando a una nuova MICRO-architettura (e nuova piattaforma. Di contorno, quindi). Dunque NON sarà una nuova ARCHITETTURA: quella rimarrà sempre x86/x64, che è ancora viva e vegeta nonostante i proclami di gufi, hater e novelli maghi Otelma, che la vorrebbero già morta da una 30ina d'anni ormai. Com'è anche chiaro che l'arrivo di Koduri ha influito su queste decisioni. D'altra parte è ben noto che le GPU di AMD siano ben più votate ai calcoli GPGPU, rispetto a quelle nVidia. Koduri ha contribuito grandemente allo sviluppo di tale architettura, per cui può ben contribuire anche allo sviluppo della prossima MICRO-architettura Intel votata al GPGPU-computing -> Xeon Phi. Infine, è bene notare che soluzioni esotiche possano ovviamente fare molto meglio di soluzioni più "generali/generiche". Ed è ovvio che sia così. Com'è, però, anche ovvio che sfruttarle richieda molti più sforzi (codice e/o compilatori ad hoc), e in ogni caso tali soluzioni sono difficilmente riutilizzabili per altri scopi. Infatti pezy-sc2 ha prestazioni stellari soltanto in virgola mobile a singola precisione, mentre di gran lunga inferiori per quelle a doppia o mezza precisione. Ergo: si chiama fuori da HPC e IA/deep-learning. |
Quote:
Quindi al massimo puoi parlare di soluzioni che hanno un diverso supporto, ma non certo che usare un determinato HW piuttosto che un altro diventa complicato per il programmatore. Inoltre la suddetta architettura non ha molto di "esoterico", certamente è meno fantasiosa nell'avere un inutile core x86 per pilotare 2 FPU che sono quelle addette a lavorare per davvero. Quote:
Ci sarà un motivo per cui la presenza di queste schede acceleratrici siano aumentate nel tempo nella classifica. E infatti stanno prendendo piede proprio nei server HPC, IA e DeepLearning (non so se hai capito che ogni scheda a 16FLOPS in FP16, tutt'altro che "poco" per il DeepLearning). Per quanto riguarda la MICRO-Architettura, è molto ma molto probabile che sarà pensata per fare un die con il core e "incollarlo" (usando la sintassi di Intel) ad un bel die separato creato dal Koduri che eseguirà i calcoli veri. L'MCM di Intel è promettente sotto questo punto di vista, e credo proprio che potrebbe salvargli la vita permettendogli di integrare roba non x86 per progredire. |
in realtà Intel ha annunciato di aver dismesso le schede addon xeon Phi, quelle discrete.
cosa già nota tre mesi fa, in cui ha smesso la produzione e mantenuto a magazzino uno stock per clienti particolari. le CPU xeon Phi continueranno comunque lo sviluppo. secondo la roadmap. rammento che le schede xeon Phi non erano altro che xeon Phi messi su scheda, dai quali, volendo, si poteva avviare anche un OS (non virtuale, ma nativo). questo fa venire in mente che già 3 mesi fa c'era piu' di qualcosa nell'aria per la costituzione della nuova divisione grafica Intel, con questi personaggi... queste cose non piovono certo dal cielo dall'oggi al domani, e sicuramente dietro c'è una strategia molto più profonda, che pian piano andremo a scoprire. |
cdimauro, glie lo spieghi tu a capadilegno cosa sono le AVX512, perchè sentirle chiamare FPU....
|
Quote:
media? quando usi un processore del genere sei sempre al limite dell'ultima istruzione utile, sempre se la riesci a sfruttare (perchè un processore non è solo pipeline di calcolo). comunque 180W su 16TeraFlops, se fossero 25 sarebbero 280W, con una Mi25 che ha 25TF per 300W. 20W in piu' di consumo a scapito di una massificazione di calcolo del 50% in piu', ossia usi meno schede, e piu' economiche, per ottenere la stessa potenza finale. come in tante altre cose, non devi guardare esclusivamente il consumo del singolo componente, ma come questo consumi insieme a tutto il resto per operare ad un certo livello di prestazioni. se devo metterci il 50% in piu' di ingegnerizzazione attorno, che dici, quei 20W sono ancora così fondamentali? Intel, acquisendo le IP AMD, puo' costruire blade che spaziano efficacemente ed efficientemente da INT8 a FP512 massimizzando sia l'efficienza che la potenza di calcolo assoluta. non c'e' alternativa, se non farsi un asic dedicato allo scopo, se non ti è chiaro il concetto. ed il tutto senza riesumare il cubotto fatto con le Vega di AMD, in cui si unisce potenza di calcolo a capacità comunicative insuperabili... giocare con quegli aggeggi è quasi meglio che giocare con i lego. e, di contorno, ROCm 1.7 oggi supporta pienamente Tensor Flow, oltre al fatto che con OpenCL Port il 99.6% del codice cuda per Caffè è automaticamente convertito in OpenCL. se nvidia non comincia a spacciare ile sue mattonelle a prezzi più concorrenziali, la vedo ben cupa. |
è un mesh, quindi ha hub dedicati alla memoria e diversi vie sui nodi per arrivarci;
ogni singolo processore ha sufficiente cache per mantenere dati in locale. il 7290 ha 32MB di L2 ed è comunque un esachannel 2400mhz (115GB/s) per 384GB di ram a CPU, oltre al fatto di essere NUMA e quindi di poter allocare la memoria fisicamente sulla dimm che serve, quindi sull'IMC piu' vicino e idoneo, di poter replicare il dataset su ogni canale etc, etc... certo, dipende comunque sempre dall'applicazione, ma di solito ci esegui calcoli assai differenti da come, ad esempio, lo sono quelli per le criptovalute a blockchain ricorsivo, quindi con elevato numero di letture in memoria. ecco, un bel set di HBM2 e si risolverebbero molte cose (soprattutto il consumo) ma, ad oggi, saresti limitato a 48GB (6 chip per 8GB l'uno, e nuovi IMC)... chissà se vogliono sfruttare la sinergia con AMD in tal senso. |
Quote:
Le parti in assembly, se ci sono, sono relative a funzioni di libreria che vengono utilizzate per "comporre"/calcolare ciò che, alla fine, serve realmente. Tali funzioni di libreria sono scritte per lo più in Fortran (sì, hai letto bene) e soltanto negli ultimi anni ne sono state scritte alcune versioni in C++, oppure vengono utilizzati dei wrapper per poter utilizzare direttamente quelle scritte in Fortran. Per poter sfruttare meglio che si può le capacità di calcolo di soluzioni HPC come queste vengono sfruttate le funzioni intrinsic, che servono a "segnalare" al compilatore il contesto d'esecuzione (in che modo vengono utilizzati i dati) o direttamente la tipologia di istruzioni da impiegare. Ovviamente ci sono anche parti in assembly dove serve / è stato fatto, ma impiegare direttamente l'assembly è estremamente costoso. Quote:
Prendi un algoritmo che si presta per calcoli di questo tipo, riporta il normale codice C/C++/Fortran, e poi quello CUDA (visto che nVidia va forte in questo mercato) e quello Xeon Phi. A quest'ultimo posso provvedere io, visto che è veramente e te lo posso realizzare in TRE versioni: con #pragma per il compilatore C/C++/Fortran, con le estensioni CILK+, o con MYO. Sì, Intel offre ben TRE (DIVERSI!) modelli/paradigmi per poter sfruttare il suo hardware, e non ho citato nemmeno le OpenCL perché queste sono più generali (tutti i produttori di CPU/GPU possono sfruttarle). Se prendi i codici finali, noterai delle "LEGGERISSIME" differenze. Eppure il calcolo eseguito, alla fine, è esattamente lo stesso. Quote:
E a parte questo, continui a non avere la minima idea di come funzionino non sole unità SIMD x86, ma la recentissima AVX-512 (che poi è quella utilizzata in queste soluzioni HPC). Giusto per essere chiari: c'è PIENA SINERGIA fra l'unità di calcolo "intera" x64 e l'unità SIMD. D'altra parte basta prendere un qualunque pezzo di codice, disassemblarlo, e vedere il mix delle suddette istruzioni che ne viene fuori. Quote:
"Operating at 1 GHz, the PEZY-SC2 has a peak performance of 8.192 TFLOPS (single-precision) and 4.1 TFLOPS (double-precision) while consuming around 180 Watts. Quote:
Quote:
Quote:
Poi POTREBBERO anche aggiungere uncore diversi, ma non è emerso dalla notizia/press release. |
Quote:
Sono, al contrario, soluzioni come le GPU, che ne erano del tutto sprovviste, che negli ultimi anni hanno integrato funzionalità/istruzioni per gestire questi casi. Comunque anche a fronte di funzionalità simili, un certo algoritmo andrà meglio o peggio in un'architettura anziché su un'altra. Bisogna provare, e vedere. Aggiungo che per gestire casi di conflitti & sincronizzazioni per l'accesso alla memoria, Intel ha pure introdotto le transazioni, che mi pare siano ancora non offerte dalle GPU. Dunque i programmatori, sempre a seconda del tipo di calcolo, hanno anche questa possibilità. |
Ho un minuto, e aggiungo una cosa al volo, importantissima, che m'è venuta in mente sotto la doccia.
I core pezy-sc2 hanno bisogno di core MIPS (prima avevano ARM) per coordinare il lavoro delle "tile" SC2. Questo significa che i programmatori sono costretti a scrivere DUE codici: quello che gira nelle tile SC2, e quello che gira nei MIPS che coordinano tutto il lavoro, e decidono se/come/quando spedire e recuperare poi il lavoro delle SC2. Quindi, come dicevo prima, c'è molto più lavoro per i programmatori. Similmente a quanto avviene con nVidia / CUDA. E' roba che si faceva con Xeon Phi (ma MOLTO più semplicemente) con le schede discrete, che però con Knights Landing sono state ormai dismesse. Quest'ultimo consente banalmente di far girare qualunque binario x86/x64 e con AVX-512. |
Quote:
Per lo sfruttamento delle unità di elaborazione serve che le funzioni base siano scritte in librerie che vengono poi chiamate. Ergo, per un programmatore se tali librerie siano per l'architettura A o B non cambia nulla. Non c'è difficoltà aggiunta a non usare x86. Quote:
Sforzo aggiunto pari a quello di capire dove l'architettura ha problemi ed evitare di pestare continuamente quel punto. Quote:
Quote:
Ah, e per evitare ulteriori derive all'argomento, intendo nella parte attiva dei conti. Ovvio che anche le GPU necessitano di un componente esterno che organizzi il lavoro e faccia da interfaccia al resto (come lo necessitano anche le Phi con gli Xeon a corredo). Quote:
Per te 16TFLOPS in FP16 sono pochi? E 4TFLOPS in FP64? Probabilmente hai letto le specifiche della vecchia versione (o quelli della scheda Intel) e ora ti stai arrampicando sugli specchi, perché dire che fa grandi numeri in FP32 e pochi in FP64 e FP16, quindi non adatta a HPC e DeepLearning, quando questi valori sono in perfetto scaling con le prestazioni FP32 vuol dire aver preso una enorme cantonata. Quote:
La potenza teoria non la raggiungi sempre (anzi praticamente mai), quindi non sei mai a potenza massima se non per pochissimo tempo. Inoltre forse non avete letto bene che tipo di memoria secondaria può usare. Quote:
Quote:
Il vantaggio quindi è altro rispetto alla vera capacità computazionale in cui sono state scalzate da altre architetture, e in prestazioni assolute e in efficienza (nonostante il PP migliore che Intel dice avere, figuriamoci a uguale PP che figura avrebbero fatto). Per riuscire a colmare il gap è necessario che le AVX così come sono messe oggi siano riviste e molto probabilmente saranno usate come cluster in die separati e "incollati" tra di loro. Quote:
Sarà che forse hai uno strano modo di vedere tutto ciò che non è Intel o x86 based, ma ti faccio notare che anche altri sanno fare compilatori, framework, driver e librerie per astrarre quello che è il lavoro sotto il cofano necessario per fare le operazioni complesse. E le PEZY-SC2 possono essere usate come unità indipendenti esattamente come le Xeon Phi, dato che su quei MIPS ci può benissimo girare un OS. Tornando al primo punto della discussione, puoi parlare di un diverso (migliore o peggiore) supporto alla scheda, non che di principio usarne una piuttosto che un'altra sia più complicato. |
Quote:
Non hai capito ed è evidente che non sai come funzioni e venga scritto codice HPC. Le funzioni di libreria sono come i mattoncini Lego: sono strumenti che ti AIUTANO a risolvere i tuoi problemi, che però richiedono codice ad hoc, perché ovviamente i problemi di chi lavora in settori HPC non sono assolutamente tutti uguali. Tutt'altro. Ma oltre al codice delle librerie, va "ovviamente" ottimizzato anche il codice che ne fa uso. In TUTTI E DUE i casi, se vuoi sfruttare al meglio l'architettura su cui gira il tuo codice (ed E' quello che vuoi fare, altrimenti non l'avresti comprata), ti serve adattare/modificare/riscrivere il tuo codice (per quello di libreria c'ha già pensato il produttore della libreria e/o della CPU. In mancanza, devi ottimizzartela tu la funzione/i che ti serve). L'ottimizzazione va dall'usare codice codice assembly (molto raro: è troppo costoso da scrivere e testare. Ecco perché in genere, se c'è, si trova nelle funzioni di libreria), agli intrinsic di cui parlavo prima, ad apposite #pragma, opzioni di compilazioni, etc.. In ogni caso ti leghi mani e piedi (specialmente nel caso di assembly e intrinsic) alla specifica architettura. Dunque è l'esatto contrario di quello che sostieni. Quote:
Il punto, però, era ed è che FPU e AVX sono completamente diverse, visto che sono unità diverse (e le micro-architetture possono anche avere porte/unità d'esecuzione del tutto disgiunte). Ma sono tutte cose che sono ovvie a chi sa cosa siano queste unità d'esecuzione, come funzionano, e come vengono usate in ambito HPC (dov'è lapalissiano che un'FPU non ha diritto di cittadinanza, visto che un'unità SIMD fa di gran lunga meglio il suo lavoro. A meno che non sia assolutamente necessaria una maggior precisione, e qui l'unica architettura che la offre è x86 con l'FPU x87, oppure soluzioni dedicate). Quote:
Ancora una volta, assolutamente no: la sinergia di cui parli in quello specifico contesto ce l'ha x86, gli stream processor delle GPU di nVidia, i core PEZY-SC2, e così via. Perché per effettuare i calcoli veri e propri ti servono le unità vettoriali E (congiunzione) anche altre unità di calcolo "scalari/intere" (nonché di load/store) per eseguire altri calcoli senza i quali le unità vettoriali starebbero a girarsi i pollici. La differenza fra Xeon Phi (Knights Landing in versione chip, e non scheda discreta) e nVidia/SC2/etc. (in genere tutte le soluzioni hardware che lavorano come coprocessori. Incluse Xeon Phi su scheda, ovviamente) è che non serve nessun core aggiuntivo per smistare il lavoro e i dati ai core dei coprocessori: dati e codice sono già immediatamente disponibili (nella memoria principale, che è condivisa da tutti i core), e serve soltanto lanciare i processi per avviare l'elaborazione (cosa molto più semplice e veloce: è parte del s.o.). Si tratta, per chiarire, dello stesso motivo per cui le CPU moderne continuano ad avere unità SIMD, che sono via via sempre più potenziate, nonostante ci siano GPU in grado di processare molti più dati IN LINEA TEORICA. Ma a livello pratico il costo dell'operazione di offloading uccide le prestazioni e rende conveniente continuare a usare le unità SIMD. Quote:
Da quella pagina è evidente, se ancora non ti fosse chiaro, che PEZY-SC2 nasce per operazioni in virgola mobile a precisione singola, visto che parliamo di un paio di ordini di grandezza di differenza. Sulla carta avrebbe prestazioni elevate anche in FP64 e FP16, ma sistemi custom come questo hanno soltanto sulla carta prestazioni elevate, ma con codice reale è molto, molto difficile riuscire ad avvicinarsi ai dati di targa. Peggio ancora con tipi di dati per cui non sono nati. Dunque dubito fortemente che siano papabili anche per l'HPC o l'IA. Quote:
Quote:
Solo che la DRAM ha di gran lunga latenze più elevate rispetto alle cache. Ed ecco che ritorna il discorso di cui sopra, sulle possibilità di avvicinarsi ai numeri teorici. Quote:
Le motivazioni le ho espresso sopra. D'altra parte con Knights Landing non ha proprio più senso sprecare soldi e risorse per utilizzare un coprocessore, quando con un chip "tradizionale" puoi lavorare di gran lunga meglio. Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Tu, invece, che esperienza puoi vantare SUL CAMPO? Da quel che hai scritto non hai la minima idea di come funzioni queste soluzioni, e di come si scriva codice per il mercato HPC. Quote:
Quote:
Quote:
Tu, invece, non hai ancora capito nemmeno come funzionino in linea di principio: figuriamoci come si scrive il codice per sfruttarle. |
Tutti gli orari sono GMT +1. Ora sono le: 07:37. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Hardware Upgrade S.r.l.