Intel, addio a Hyper Threading?

In che senso "strategico"? Considerando quanti ne hanno venduti e quanto ci hanno guadagnato, è difficile considerarlo un "disastro" da un punto di vista aziendale. L'aspetto tecnologico è secondario rispetto allo scopo primario di Intel (come di tutte le altre aziende): fare profitto.

Con un'architettura come quella P6+ degli attuali Pentium M/Core Duo e Core Solo era prevedibile che Intel decidesse di togliere HT che non avrebbe sicuramente portato benefici tangibili ed avrebbe introdotto un maggior numero di circuiti di controllo per avere un risultato non certamente eclatante...

Se non ricordo male, MS ci aveva messo una pezza dopo che il problema si era manifestato sugli Xeon biprocessore. Credo che sia questa.

si, si...

...fette di salame grandi così ...ma cosa dici !?...Ma ti ricordi che quando intel ha tirato fuori HT, amd non sapeva neanche cos'era un dual core e neanche Intel all'epoca ? Vogliamo provare a prendere un P4 con HT e uno senza e vedere quello che ti fa girare meno le balle ?? Grazie al cavolo che l'fx-60 adesso viaggia bene, come magari anche un dual core di Intel (magari anche meno, ma non sente la necessità di HT)....ma perche fate sempre gli sboroni ? perchè volete sempre aver ragione e prendere le constatazioni altrui come cosa da cestinare ridicolizzando ?...e ovvio che poi uno come me scrive "fette di salame" certo che l'obbiettività è raramente di questo forum, e quando qualcuno viene toccato nel suo BRAND più caro, ne fa subito un flame

Seppelliamo Von Neuman!

Mi stupisce che l'"Instruction Level Parallelism" (cioè il SIMD) sia presentato come una cosa superata. Io penso che vada recuperata in qualche misura, se si vuole arrivare a sfruttare veramente decine e decine di core. O, meglio, decine e decine e decine di pipelines.



Forse la Connection Machine? Comunque, grazie per aver tirato in ballo un tema importante: la programmazione con linguaggi che rendono esplicito il parallelismo. Server a parte, non faremo mai un buon uso di 32 o più core senza superare il paradigma sequenziale con il quale programmiamo da 60 anni. IBM sta lavorando a strumenti di compilazione che semi-automatizzino la parallelizzazione del codice, ma penso che ci si debba spingere più in là per sfruttare veramente le macchine che verranno: adottare linguaggi di programmazione pensati da zero per un uso non sequenziale. A quel punto può occuparsi il compilatore (un signor compilatore, forse bisognerebbe chiamarlo in qualche altro modo, più probabilmente una macchina virtuale) a smistare istruzioni e dati fra diverse "unità di esecuzione" che possono essere dati paralleli in un flusso sequenziale SIMD, pipeline, core di una CPU multicore, CPU fisicamente distinte, nodi di un cluster o di un Grid distribuito su scala geografica. Il software esporrebbe tutte queste risorse in modo omogeneo, distinguendole intelligentemente sulla base della latenza necessaria a passare da una all'altra (dai nanosecondi delle pipeline ai secondi del Grid). Credo che ci sia molta ricerca in corso in questa direzione.

si certo...tu ti metti a ridicolizzare un fx 57 e ce le abbiamo noi le fette di salame sugli occhi....
siamo noi i tifosi attaccati ad un brand...
cmq io non dirò + una sola parola dato che non serve sprecare fiato con chi si diverte a guardare la pagliuzza nell'occhio degli altri senza guardare la trave che ha nei suoi....
e inoltre leone ha già detto di non scendere nel solito flame...
au revoir....

...bhè sembra un bel progetto...però ci sn delle cose a sfavore

il costo... 100 core nn sn mica pochi...

il calore prodotto...

le dimensioni del die...

e poi come vengono gestiti 100 core da un os??? su win ce ne possono essere al max 30... teoriche

e poi che bisogno ci sarebbe della scheda grafica.... cmq nel '90 bill gates prevedeva che i computer avrebbero avuto un unico core che faceva tutto.... più o meno c'ha azzeccato...

IBM con Blue gene fa già una cosa del genere credo, infatti sul grid computing penso che sia l'azienda più avanti

Istruction Level Parallelism non è la stessa cosa di SIMD (Single Instruction Multiple Data, che possono essere le varie istruzioni che lavorano sui vettori come le SSE & C., ma in generale è una macchina con diversi data processor ed un solo instruction processor che "comanda" i data processor che lavorano su dati diversi, ad esempio gli array/vector processor)...
L'Instruction Level Parallelism è presente in IA64 di Itanium...e serve a specificare alla CPU come deve allocare le varie unità di esecuzione in modo da far eseguire parallelamente il maggior numero possibile di sitruzioni...
Per sfruttare la quantità di core di cui si parla sicuramente da qualche parte deve venir fuori...senza ombra di dubbio... Il problema è che ormai la strada della compatibilità x86 sembra essere quella che verrà percorsa anche in futuro... Quello che mi viene in mente è che oltre ad unità di fetch & decode in comune questi core avranno anche una unità che analizzerà le dipendenze e specifichera (nelle micro-(o macro)-ops) come le istruzioni dovranno essere allocate nei vari core... Una specie di out-order execution, ma in cui non è più l'ordine di presentazione a determinare l'ordine di esecuzione, ma istruzioni presentate sequenzialmente dovranno essere eseguite parallelamente su più core...
Inoltre in questo modo, con l'aiuto di un register file adeguato, si potrebbero anche risolvere alla base i problemi di predizione dei salti...semplicemente eseguendo entrambi i branch...

Come stiamo supponendo...non saranno core completi come sono adesso i P-M o gli A64, ma core sicuramente più semplici e quindi più piccoli...

Inoltre ora che ci penso la gestione che ho proposto sopra è molto simile al SMT...

Ed i core ritornerebbero ad essere visti come logici dal sistema operativo...