Link alla notizia: http://www.hwupgrade.it/news/cpu/17390.html

La prossima generazione di processori K8 integrerà varie novità architetturali

Click sul link per visualizzare la notizia.

conferma per le ddr3, figo!

dubbione:
a pc acceso, in che situazioni si puo' disattivare il memory controller per risparmiare energia??!

Se si parla di macchine multi-CPU...quando nessuno dei core di una CPU viene utilizzato...

Dubbio:
le licenze di XP Home (non so Vista) non supportano fino a 2 processori/core massimo?

magari in aggiunta alla virtualizzazione potrebbe esser disabilitato il singolo memory controller (se fosse diviso per core)

Ho notato in questi mesi che AMD nell'implementazione di nuove tecnologie è sempre un passettino indietro a Intel (parlo di 65nm, DDR2 e DDR3, Dual core) nel presentarle. Salvo poi avere dei benefici da queste introduzioni che Intel di solito almeno all'inizio non sembra avere...

In sostanza AMD ha introdotto i 90nm e ha risparmiato WATT a go go e guadagnato circa 1 GHz di frequenza al contrario di Intel che non è riuscita ad avere grandi benefici in frequenza, aumentando in maniera spaventosa i consumi.

Le DDR2 fino a questo momento, a parte qualche rara applicazione, non hanno portato benefici evidenti. Forse ora lòa tecnologia è matura e i timing di queste memorie accettabili.

Nei dual core il progetto K8 nasce vincente grazie al bus di interconnessione che nasce multicore (ringraziamo la cara e defunta digital) e la dimostrazione è nel modo in cui scalano in prestazione gli opteeron in confronto agli Xeon all'aumentare del numero di processori.

Ho un brutto presentimento:
Conroe sarà un processore forse poco più potente degli A64 X2, forse bilancerà la faccenda dei consumi e nel giro di un annetto riceverà verrà risorpassato da qualcge ottimizzazione AMD (cache L3?)...

penzo praticamente mai.... solo in stanby prob è una caratteristica implementata per i noteboock.

questi processori saranno ovviamente a 65micron? dovremmo aspetterci guadagni in termini di consumi e temperature oppure la cache L3 vanificherà questo passaggio?

dovremmo aspettarci un FX66 a 3200Mhz con 2Mb cache L2 e 4/6Mb di cache L3?
non sarebbe utile implementarla solo per le soluzioni server?

non si parlava di un Virtualizazione integrata nella CPU?

verrà aumentata anche la cache L1? questa si che potrebbe essere una cosa a mio avviso utile nel ambito Home.

ciao a tutti!

Sarà infatti possibile gestire indipendentemente il voltaggio di alimentazione di ognuno dei 4 Core integrati in ogni processore, con evidenti benefici in termini di consumo energetico e contenimento del calore dissipato. Anche il memory controller potrà essere spento temporaneamente nel momento in cui fosse inattivo, così da ridurre ulteriormente il consumo.
Ottimo queste si che sono buone idee.

Ho notato in questi mesi che AMD nell'implementazione di nuove tecnologie è sempre un passettino indietro a Intel (parlo di 65nm, DDR2 e DDR3, Dual core) nel presentarle. Salvo poi avere dei benefici da queste introduzioni che Intel di solito almeno all'inizio non sembra avere...


Forse è proprio qui il gioco...
Intel è un passo indietro nell'ottimiazzazione delle tecnologie e applica nuove tecnologie a progetti vecchi.... un po' come la Ferrari dell'anno scorso (quest'anno va un po' meglio).

AMD dal canto suo, si puo' forse permettere di essere più cauta grazie cmq alla crescita costante che sta avendo (...crescita = sempre più fiducia) e pertanto fa arrivare sulla sua linea le nuove tecnologie solo quando sufficentemente mature... ;)

Dubbio:
le licenze di XP Home (non so Vista) non supportano fino a 2 processori/core massimo?

Forse nel 2007 non si avrà Vista?

magari in aggiunta alla virtualizzazione potrebbe esser disabilitato il singolo memory controller (se fosse diviso per core)
C'è un solo memory controller condiviso fra i core di ogni CPU...

Cache di 3o livello!!!??? Sto per commuovermi... CHE MOSSA!

mica è cosa nuova.. anzi intel lo ha già fatto in precedenza...
rimaniamo pacati e imparziali prego.

AM2 SI AM2 NO?

peccato che nelle varie roud upnon se ne era sentito parlare.. certo che una bella cache di 3° livello ha un sacco di pro... ma sul portafoglio si farà sentire..

la continua ricerca della riduzione dei consumi è davvero da lodare... Questo k8L lo vedo molto bene sono davvero curioso

Questa news fa capire come i tecnici Amd non dormano mai sugli allori, sono sempre alla ricerca di miglioramenti, e se Intel sembra avere con Conroe l'asso nella manica, mi sa che Amd riuscirà presto a riprendersi il trono, se mai l'avesse perso.

Cache di 3o livello!!!??? Sto per commuovermi... CHE MOSSA!
Sinceramente mi convince poco... A occhio si potrebbe trattare di una cache unificata... Di per sè una cache di 3° livello non offre poi chissà quali miglioramenti, se non in particolari ambiti di utilizzo (vedi server)...ma se fosse unificata potrebbe sicuramente giovare ai core....

Dunque il K8L è una realtà!
Che cosa sappiano:
Sarà a 65nm, disponibile su socket AM2, S1 e socket 1207.
Avrà una L3 con dimensioni ancora sconoscute, un incremento delle prestazioni velocistiche grazie ad un raddoppio delle risorse a disposizione per istruzioni della famiglia SSE e forse con l'aggiunta delle SSE4,
Le prestazioni in virgola mobile saranno aumentate in un valore non confermato del 42%.
I pre-fetch verranno incrementati da 16 a 32 bytes, mentre l'indirizzabilità della memoria fisica verrà aumentata sino a 48bit.
La notizia parla che sarà la base dei QUAD core AMD; che però secondo una Roadmap precedente dovrebbero uscire per il primo periodo solo su CPU Opteron come il supporto per le memorie FB-Dimm.
Il K8L sarà la risposta di AMD contro INTEL Conroe?
Staremo a vedere...

AMD si muove..
Al contrario di Intel che reclamizza ogni singola puttanata che fa con pompose e faraoniche presentazioni AMD se ne stà zitta zitta e poi tira fuori il classico gioiellino.

E' confermato che K8L sara' compatibile con AM2 o cambieranno anche socket? AM2 mi pare non supporti le DDR3...

Cache di 3o livello!!!??? Sto per commuovermi... CHE MOSSA!
Ma quando dicevo che AMD ha meno MB di cache di Intel che farebbe bene ad aumentarla, ecc.. Tutti a darmi contro che "su AMD non serve a una sega averne tanta.. Intel sbaglia".
Adesso che ce ne mette quintalate (perchè se è L3 si viaggerà minimo sui 4/8MB), tutti a osannare questa mossa?
Oltretutto mi si diceva che AMD ce ne mette poca così va più veloce.. vale anche ora che ce ne mette tanta?? Poi di L3, chissà che fulmine!
Lo stesso potremmo dirlo della cache unificata (perchè sicuramente lo sarà), all'uscita degli X2 tutti a dire che la soluzione AMD era la più pulita...
mha... :|

Vabbè passiamo sopra a queste inconguenze e vediamo cosa ci aspetterà il futuro.
Quantomeno sul lato risparmio energetico c'è ben poco da criticare.

p.s. Si parla di 2007 inoltrato, fra 12 mesi, 1 anno, non tiriamo in ballo astruse comparazioni con Core Duo..

E' confermato che K8L sara' compatibile con AM2 o cambieranno anche socket? AM2 mi pare non supporti le DDR3...
il K8L è compatibile con il socket AM2... :)
Clicca qui... (http://www.hwupgrade.it/news/cpu/k8l-nuovo-core-amd-compatibile-con-socket-am2_16966.html)

E' confermato che K8L sara' compatibile con AM2 o cambieranno anche socket? AM2 mi pare non supporti le DDR3...
non c'è alcun motivo per cui AMD dovrebbe cambiare ancora Socket. Il passaggio ad AM2 non ha ragioi tecniche particolari, ma deriva solo dall'esigenza di evitare confusione tra gli utenti.... pensa se ci fossero contemporaneamente sul mercato alcuni processori e alcune schede madri Socket 939 con DDR ed altre con DDR2, che confusione che potrebbe succedere.
Quindi, se le DDR3 saranno pin-to-pin compatibili con le DDR2 non cambieranno di nuovo Socket.

Se verranno fuori ulteriori indiscrezioni riguardo questo K8L e cioè compatibilità con le schede madri che a breve usciranno per AM2 (vedi un anno fa A64 con X2 sul 939) sarò mooolto indeciso se andare su Conroe oppure dare fiducia ad AMD (cosa che negli ultimi tempi da parte mia si è guadagnata) e poi fare un upgrade con K8L...

Mah, io ho idea che la cache L3 sarà soprattutto appannaggio delle CPU server, almeno inizialmente, mentre potrebbe essere adottato sui desktop nel caso di utilizzo delle memorie DDR3. Questo perchè le DDR3 hanno delle latenze mostruose, e una congrua cache L3 potrebbe alleviare i problemi dovuti al loro utilizzo. Mentre per DDR/DDR2 questo problema è meno sentito.
Altre cose che AMD deve migliorare sul K8L:

1) diminuizione della latenza della cache L2
2) (soprattutto) Aumento della banda passante da cache L2 a L1 e da L1 al core.

Forse nel 2007 non si avrà Vista?
Dubito che nel 2007 il 90% dei pc montera' vista e in ogni caso come siamo messi con le varie incarnazioni di questo SO per quanto riguarda le cpu supportate?

Sinceramente mi convince poco... A occhio si potrebbe trattare di una cache unificata... Di per sè una cache di 3° livello non offre poi chissà quali miglioramenti, se non in particolari ambiti di utilizzo (vedi server)...ma se fosse unificata potrebbe sicuramente giovare ai core....

Sì ma se ben ricordo la cache di 3o è sempre esterna al core (fino ad adesso uno solo per socket o slot) e quindi se sullo stesso socket esistessero più core con capacità di cache di 3o livello non c'è motivo per cui essi debbano avere 3o livello separato. Amd inoltre dispone già da un po' di tempo dell'interlink tra i core, quindi un banco unico per tutti è più che ipotizzabile.
Inoltre il prezzo di questa cache dovrebbe essere molto inferiore anche perchè dubito fortemente che sia più di un quarto del clock reale del processore.
Ciao cionci :)

Mah se AMD ora può ottimizzare le tecnologie è per la sua "bassa" possibilità produttiva rispetto a Intel.

Quando hai mandato a regime 25 fabbriche che ti producono Prescott (sostituiscici qualsiasi tecnologia "mal riuscita" per vari aspetti) non è così semplice dire "Abbiamo una tecnologia nuova che farà più felici gli utenti, spegnete tutto e produciamo quella"...

Se AMD avesse un market share superiore avrebbe sicuramente più problemi in tale senso.

E' confermato che K8L sara' compatibile con AM2 o cambieranno anche socket? AM2 mi pare non supporti le DDR3...

In AMD il socket/chipser è indipendente dalle memorie, a differenza di Intel, perchè il mem-conmtroller è integrato nel processore.

Dubito che nel 2007 il 90% dei pc montera' vista e in ogni caso come siamo messi con le varie incarnazioni di questo SO per quanto riguarda le cpu supportate?

Dubito che uno che compra una CPU di questo tipo nel 2007 ci mette su XP. Di certo il 100% dei PC nuovi usciti nel 2007 dopo il lancio di Vista monteranno Vista. Suvvia un po di logica. Oltretutto con Vista il discorso licenze/core cambia radicalmente passando a licenze/socket presenti su MOBO.

Dubito che uno che compra una CPU di questo tipo nel 2007 ci mette su XP. Suvvia un po di logica. Oltretutto con Vista il discorso licenze/core cambia radicalmente passando a licenze/socket presenti su MOBO.
si ma continui a non rispondere alla domanda.
Come sono le licenze di Vista rispetto alle varie versioni che sono state presentate?
TUTTE le versioni Vista supportano almeno 4 core?

Lo chiedo perche' non lo so...

si ma continui a non rispondere alla domanda.
Come sono le licenze di Vista rispetto alle varie versioni che sono state presentate?
TUTTE le versioni Vista supportano almeno 4 core?

Lo chiedo perche' non lo so...


Su questo ammetto di non essere informato neanche io, ma già XP PRO attualmente supporta 2 core fisici e 2 logici, ovvero 4 core in tutto, quindi è logico aspettarsi che vi sarà un incremento di tale valore, anche in considerazione della direzione multicore intrapresa dal mercato CPU.

Su questo ammetto di non essere informato neanche io, ma già XP PRO attualmente supporta 2 core fisici e 2 logici, ovvero 4 core in tutto, quindi è logico aspettarsi che vi sarà un incremento di tale valore, anche in considerazione della direzione multicore intrapresa dal mercato CPU.
beh io non sarei cosi' sicuro che la versione + sdozza di vista supporti 4 core... cmq se qualcuno sa qualcosa di + certo lo scriva grazie!

Cache 3° livello

Me l'aspettavo da quando si è parlato dell'acquisizione della licenza per la Z-Ram da parte di amd...

Uno dei punti di forza nella gestione della cache nelle cpu amd è stata l'esclusività della L2 rispetto alla L1, cosa che, congiuntamente all'introduzione del MCH integrato con una elevata banda verso la memoria, ha consentito il contenimento delle dimensioni a vantaggio delle latenze e delle prestazioni. Tuttavia, in ambito multicore può tornare utile una cache condivisa, che però, a mio avviso, potrebbe creare problemi di latenza mantenendo l'architettura a cache esclusive (alle contese sulla L2 condivisa si aggiungerebbero le - eventuali - ispezioni delle L1). La L3 penso che potrebbe ovviare proprio a questo, nel caso fosse condivisa e inclusiva rispetto alla cache "proprietaria" di ciascun core (L1 + L2 esclusive tra di loro), e di dimensioni sufficientemente elevate: specialmente nei quad-core, ciascuno potrebbe ottenere i dati che necessita senza rompere troppo le scatole agli altri, naturalmente a patto che la velocità sia sufficiente, e chissà che non venga integrata on die...

A questo potrebbe provvedere la tecnologia ZRam, che dovrebbe consente la realizzazione di cache con celle a 1 transistor, contro le 6 delle SRAM tradizionali: considerando solo le celle, con gli stessi transistor di una cache da 2 MB si dovrebbero poterne realizzare ben 12 (naturalmente va considerata anche tutta la circuiteria a contorno, ma il grosso sta lì, no? ), con un notevole risparmio di spazio (e chissà, anche di consumi...). Del resto, mi pare che nelle news precedenti sull'argomento si fosse detto che i K8L avrebbero sfruttato la ZRAM e che i quadcore avrebbero avuto una cache condivisa... Staremo a vedere...

windows secondo quanto detto dalla stessa microsoft ha una licenza a procesore: contano i processori fisici e non i core singoli.

per quanto riguarda la cache sembra che solo in ambito server si avranno dei quad core con cache L2 normale e cache L3 condivisa tra tutti i core

Questa news fa capire come i tecnici Amd non dormano mai sugli allori, sono sempre alla ricerca di miglioramenti, e se Intel sembra avere con Conroe l'asso nella manica, mi sa che Amd riuscirà presto a riprendersi il trono, se mai l'avesse perso.

talmente AMD non sta sugli allori che il K8L è previsto fra un anno
e per intanto, nel frattempo, che farà, vedrà eroso inesorabilmente il suo 20% di share di mercato?

talmente AMD non sta sugli allori che il K8L è previsto fra un anno
e per intanto, nel frattempo, che farà, vedrà eroso inesorabilmente il suo 20% di share di mercato?
parlate tutti come se aveste gia' bench ufficiali alla mano... per favore...

AMD si muove..
Al contrario di Intel che reclamizza ogni singola puttanata che fa con pompose e faraoniche presentazioni AMD se ne stà zitta zitta e poi tira fuori il classico gioiellino.
beh certo se Intel sei mesi prima di un radicale cambiamento presenta un archittetura completamente diversa rispetto a netburst, allora fa una "puttanata"
mentre se AMD annuncia un semplice miglioramento della sua architettura, un anno prima che compaia, allora invece fa una cosa intelligente
e basta con questi spot da fanboy :rolleyes:

parlate tutti come se aveste gia' bench ufficiali alla mano... per favore...

non una questione tanto di bench, quanto di prezzo
a quanto pare i futuri AM2 non saranno proprio a buon mercato
ma anche AMD stessa nei prossimi trimestri prevede una flessione, c'era una news a proposito, se vuoi, cercatela
quindi per una volta fai tu un favore a te stesso ed evita queste inutili considerazioni

si ma continui a non rispondere alla domanda.
Come sono le licenze di Vista rispetto alle varie versioni che sono state presentate?
TUTTE le versioni Vista supportano almeno 4 core?

Lo chiedo perche' non lo so...

ammesso che quanto riportato al seguente indirizzo sia corretto,

http://www.winsupersite.com/showcase/winvista_editions_final.asp

vista, nelle varie versioni client, dovrebbe supportare 1 o 2 (a seconda dell'edizione) cpu fisiche (non si dovrebbe proprio porre il problema licenza in quanto se hai nella macchina più cpu di quelle previste dalla edizione installata -ammesso che si installi lo stesso-, semplicemente non le userai; almeno da come espone la cosa quel sito)

per quanto riguarda il numero di core:

"...While all of the Vista product editions support only one or two physical processors, none are limited to the number of processor cores they will support..."

nessun limite quindi, o meglio per forza di cose ci sarà un limite, non credo che vista sia infinitamente scalabile, ma da come è messa la cosa dovrbbe trattarsi non di un limite "commerciale" e cmq > 4 (quad-core imminenti all'uscita di vista)

ammesso che quanto riportato al seguente indirizzo sia corretto,


confermo che sono corretti, me li ha confermati uno della MS sul newsgroup dei betatester

nessun limite quindi, o meglio per forza di cose ci sarà un limite, non credo che vista sia infinitamente scalabile, ma da come è messa la cosa dovrbbe trattarsi non di un limite "commerciale" e cmq > 4 (quad-core imminenti all'uscita di vista)
ah beh direi buono allora.
Cmq se un'applicazione e' BEN sviluppata puo' essere davvero indipendente dal numero di cpu che ci sono ed essere scalabile all'occorrenza, basta far fare tutto cio' che si puo' fare in parallelo ad un thread diverso e poi sara' il SO a gestire lo scheduling...

basta far fare tutto cio' che si puo' fare in parallelo ad un thread diverso e poi sara' il SO a gestire lo scheduling...
Hai detto niente :D E' una delle più grandi sfide dell'informatica dei prossimi 5-10 anni... La programmazione concorrente è una brutta bestia...almeno con i linguaggi attuali... Speriamo nella nascita di qualche linguaggio concorrente con i controca##i...

Hai detto niente :D E' una delle più grandi sfide dell'informatica dei prossimi 5-10 anni... La programmazione concorrente è una brutta bestia...almeno con i linguaggi attuali... Speriamo nella nascita di qualche linguaggio concorrente con i controca##i...
beh io qualche progetto con molti thread concorrenti l'ho fatto, tutto sta nel pensare in parallelo e parallelizzare tutto quello che si puo' fare.
Chiaro che + il progetto si complica e + e' difficile, oltre che aumenta esponenzialmente la difficolta' nel trovare dei bug che si presentano solo in determinate occasioni perche' alcuni thread sono andati avanti prima di altri...

beh io qualche progetto con molti thread concorrenti l'ho fatto, tutto sta nel pensare in parallelo e parallelizzare tutto quello che si puo' fare.

Poi magari fai il profiling e ti accorgi che hai parallelizzato quel fatidico 90% del programma che viene eseguito nel 10% del tempo, che i calcoli pesanti sono rimasti in un thread solo (che non scala per niente) e che gli altri magari, per via degli switch e della sincronizzazione vanno più lenti di prima (e il danno è poco) e vanno anche a rompere le scatole (magari perchè hai anche sbagliato la scelta delle priorità) al thread pesante o a thread/processi di altri programmi (e il danno può essere poco anche qui, ma rimane seccante se il presupposto di partenza era l'ottimizzazione e la scalabilità). Magari non era neanche una cosa tanto facile riuscire a parallelizzare bene, c'è voluto tempo per trovare il modo giusto e per fare un buon debug, e ti cade qualcosa... (il morale sotto le scarpe, che hai capito :p)...

Naturalmente io sto estremizzando, ma in generale non è banale riuscire a parallelizzare e far scalare l'applicazione (per questo potrebbe essere utile o almeno possibile creare dinamicamente un numero di thread dipendente dal numero di cpu disponibili, almeno finchè numero_cpu <= numero_max_thread_possibili, possibilmente con un'architettura master-warker/a lavagna per le operazioni simili), a meno di ricadere in uno di quei casi super-ultra-mega- noti/studiati/ottimizzati. Per questo vedo di buon'occhio sia tutto l'aiuto possibile da parte del linguaggio e del compilatore (per quanto possibile), come auspica cionci, sia l'evouluzione dell'unità per il calcolo fuori ordine allo studio da parte di amd e intel, che dovrebbe consentire di sfruttare le unità non sfruttate di altri core per massimizzare il parallelismo (si parlava di hyper threading al contrario), ma io estremizzerei il concetto (anche se potrebbe essere complicato e costoso in termini di circuiteria da implementare, per cui il gioco potrebbe non valere la candela) e cercherei di sfruttare anche le unità in virgola mobile non sfruttate nello stesso core, ad esempio convertendo automaticamente le operazioni su interi in operazioni floating point e/o dandole in pasto (ove possibile) alle unità SSEx/MMX sottoforma di vettori (sfruttando, sempre se possibile, le istruzioni su vettori di interi), bilanciando il tutto con un rapporto n/m tra le operazioni accodate nelle pipeline intere (n) e quelle accodate alla fpu (m), in modo che t_esecuzione(m) <= t_esecuzione(n + 1) (e questa è la parte complicata, poichè i tempi di esecuzione inevitabilmente variano da operazione a operazione; in prima istanza si potrebbe pensare di inviare alla fpu le m operazioni che questa è in grado di svolgere più rapidamente tra quelle disponibili - ma tra le rimanenti alcune potrebbero essere accorpate in un'operazione vettoriale - e scegliere come (n+1)esima operazione quella del "pacchetto" m che l'alu impiegherebbe più tempo a svolgere). Naturalmente, un simile bilanciamento impiegherebbe del tempo e potrebbe essere poco "scalabile", specialmente se implementato - in tutto o in parte - con del microcodice, quindi del tutto inutile, anche se, volendo, si potrebbe implementare un qualche algoritmo greedy, ad esempio si potrebbe considerare come tempo di esecuzione per tutte le operazioni alu/fpu/sse il loro (rispettivo) tempo medio, quindi accodarle inizialmente solo sull'alu finchè la somma dei tempi così calcolati per le n operazioni + 1 non diventa maggiore del tempo di esecuzione di una operazione fpu/sse (comprensiva di "casting" all' "andata" e al "ritorno" ), e non creare vettori, o crearli solo se si incontra un numero di operazioni uguali su dati diversi maggiori del numero di alu disponibili oppure si è raggiunto il numero minimo di operazioni in coda per chiamare in causa l'fpu ottenendo un beneficio (sempre che, in ogni caso, non si debba procedere ad un riordino per accorpare operazioni non "vicine" tra di loro che vanifichi tutto introducendo una latenza eccessiva). Inoltre tutto questo ha senso se si ha a disposizione un numero elevato di operazioni indipendenti, anche se si potrebbe provare ad aumentarlo eseguendo operazioni non indipendenti, ad esempio istruzioni in cui uno degli operandi dipende da un'altra operazione, ma con valori in un range definito e piccolo, possibilmente noti - in questo potrebbe essere d'aiuto/necessario il compilatore/un set di istruzioni specifico e il "supporto" da parte del programmatore - oppure da un'operazione booleana - probabilmente in questo caso sarebbe efficace solo nel caso in cui vengano eseguite più operazioni - per poi scegliere il/i risultato/i (e il ramo d'esecuzione) giusto/i (mi pare che itanium consenta qualcosa del genere, però in quel caso tutto è demandato al compilatore, qui l'approccio sarebbe radicalmente opposto); comunque, sarebbe tutto molto complicato... Certo, avendo a disposizione un computer quantistico... :p

ah beh direi buono allora.
Cmq se un'applicazione e' BEN sviluppata puo' essere davvero indipendente dal numero di cpu che ci sono ed essere scalabile all'occorrenza, basta far fare tutto cio' che si puo' fare in parallelo ad un thread diverso e poi sara' il SO a gestire lo scheduling...
si non c'è dubbio, la teoria è quella... solo che anche lo scheduler comprensivo di s.o. intorno bisogna scriverlo... e appunto si parlava innanzitutto di s.o., che neanche è tra la tipologia di progetti più smplici... ;)

non credo che ci sia un s.o. che non abbia un num. max di thread smp possibili e un conseguente numero max di cpu/core (poi dipende anche dalle architetture hw) sfruttabili (ma potrei sempre sbagliare eh, non è che abbia fatto esaustive ricerche appena prima di scrivere queste righe :) )

non so se in vista(client) il num max di core usabili (che non sappiamo quant'è, se 8, = 2 quadcore, se più, meno credo improbabile ) sarà uguale al max delle "capacità" dell'o.s. o più limitato per scelta, sicuramente il limte a 2 cpu fisiche non è dato da motivi tecnici dato che già xp(server) permette di sfrutttare decine di cpu (ma anche il 2000, nt non ricordo)

Poi magari fai il profiling e ti accorgi che hai parallelizzato quel fatidico 90% del programma che viene eseguito nel 10% del tempo, che i calcoli pesanti sono rimasti in un thread solo (che non scala per niente) e che gli altri magari, per via degli switch e della sincronizzazione vanno più lenti di prima (e il danno è poco) e vanno anche a rompere le scatole (magari perchè hai anche sbagliato la scelta delle priorità) al thread pesante o a thread/processi di altri programmi (e il danno può essere poco anche qui, ma rimane seccante se il presupposto di partenza era l'ottimizzazione e la scalabilità). Magari non era neanche una cosa tanto facile riuscire a parallelizzare bene, c'è voluto tempo per trovare il modo giusto e per fare un buon debug, e ti cade qualcosa... (il morale sotto le scarpe, che hai capito :p)...
passa all'unieuro, magari hanno unpo' di ottimismo in offerta speciale... :D
cmq, ottima applicazione la tua delle leggi di murphy e corollari allla programmazione concorrente :O :p

... Certo, avendo a disposizione un computer quantistico... :p
Se e quando avremo computer quantistici, magari ci metteremo un "attimo"(rispetto al tempo necessitato per averli) a trovare qualcosa per tenerli occupati al 100% e dover tornare subito alla paralellizzazione ed ottimizzazione software...

Il vantaggio dei computer quantistici dovrebbe essere la estrema facilità nella parallelizzazione (in pratica fanno tutto da soli): per sfruttarli (in senso positivo) potrebbe "bastare" programmarli con un linguaggio simile al prolog ed eseguire il backtraking in parallelo (sostanzialmente eseguendo tutte le istruzioni contemporaneamente con tutti i valori possibili per gli operandi non noti e scartando i risultati non validi appena diventano noti). Come impallarli? Vediamo se Murphy mi aiuta... ah, ecco: con una macchina simile potrebbe diventare una bazzecola condurre con successo un'attacco di tipo brute force o ricavare la parte privata di una chiave asimmetrica, quindi una trasmissione sicura richiederebbe l'utilizzo di chiavi sempre più grandi, con continui handshake per cambiarle, da effettuare in forma criptata, e criptando i dati non solo con l'ultima chiave, ma anche con n delle precedenti, in modo tale che un attacker messosi in ascolto in un istante x successivo ai primi n handshake non potrebbe risalire facilmente alle chiavi usate, perchè non le conosce, essendo i dati già criptati - suppongo in particolare che non si usi mai crittografia simmetrica - ma anche se si mettesse in ascolto dall'inizio si potrebbero scambiare da subito delle chiavi in numero sufficientemente grande (e sostituite in un successivo handshake ravvicinato) da rendere probabile che il tempo necessario a crakkarne una (alcune) sia sufficientemente alto affinchè le successive non siano più note all'attacker, il quale dovrebbe prima ricostruire la parte pubblica di ciascuna per risalire a quella privata (presumibilmente, non avendo informazioni utili, mediante brute force, provando una infinità di combinazioni possibili, cosa che potrebbe, con n sufficientemente grande e chiavi con mooooooolti bit, richiedere un tempo non compatibile nè con la durata della transazione, ne, ottimisticamente, con la vita dell'attacker - nel caso in cui avesse interesse a decrittografare i dati scambiati anche a transazione avvenuta); insomma, ogni connessione sicura potrebbe compartare n operazioni di crittografia con chiavi immense ed n tendente ad infinito, per ciascun pacchetto ricevuto e inviato... Dici che ci sono riuscito? :p :D

passa all'unieuro, magari hanno unpo' di ottimismo in offerta speciale... :D
cmq, ottima applicazione la tua delle leggi di murphy e corollari allla programmazione concorrente :O :p

Non è una situazione a la Murphy... E' priorio la realtà... Sono rare le applicazione che ci possiamo trovare di fronte ogni giorno che sono parallelizzabili...

Principalmente ci sono quelle che sfruttano il modello thread principale - worker threads in cui il thread principale "raccoglie" dati da fornire a pacchetti ai worker thread... Quelle le sa parallelizzare anche un mulo...

Ma anche qui, metti di avere un solo pacchetto da fornire al worker thread... Praticamente hai il thread principale che è in sleep in attesa di pacchetti...e il worker thread che lavora... Che parallelismo hai ottenuto ? Nessuno...

In molti dei restanti casi ci sono dipendenze troppo strette per parallelizzare efficientemente...

IMHO la soluzione di AMD di sfruttare diversi core con lo stesso thread sarebbe davvero la panacea per i programmatori...ma secondo me si parla ancora di qualche anno...

Il vantaggio dei computer quantistici dovrebbe essere la estrema facilità nella parallelizzazione (in pratica fanno tutto da soli)...
sui computer quantistici sono completamente ignorante, avevo inteso il tuo riferimento solo come salto prestazionale di ordini di grandezza dovuto al mezzo fisico "più veloce"... sorry :p

Non è una situazione a la Murphy... E' priorio la realtà... Sono rare le applicazione che ci possiamo trovare di fronte ogni giorno che sono parallelizzabili...
lo so (anche per eseprienza diretta purtroppo)..., volevo solo scherzare, prima
(comunque non è colpa mia, è il multithreading ad avere qualcosa contro di me :O :D )

IMHO la soluzione di AMD di sfruttare diversi core con lo stesso thread sarebbe davvero la panacea per i programmatori...ma secondo me si parla ancora di qualche anno...
al riguardo ho letto solo una news qui su hwupg, ma mi sono sempre chiesto: se il singolo thread è (+/- che sia) parallelizzabile, la cpu riuscirà a fare quello praticamente quello che prima era comptenza dei programmatori ? :confused:

Le strade sicuramente sono due: aggiungere istruzioni...ed in quel caso dovrebbe essere il compilatore a "guidare" la scheduler intenro alla CPU nello smistare le istruzioni fra i vari core... O lavorare al livello di CPU estraendo le unità di fetch e decode dai vari core e facendone una in comune... A questo punto avremmo già quelle che vengono chiamate da AMD MacroOPS... In tal caso ci potrebbe essere un ulteriore livello della pipeline che "mescoli" le istruzioni (questo già avviene, ma a livello delle sole unità interne ad ogni core per la out-of-order execution) analizzandonone le dipendenze... In questo modo sarebbe possibile organizzare le istruzioni indipendenti in gruppi, ogni gruppo dipendende da una determinata istruzione di un altro gruppo... Fino a quando l'esecuzione di quella determinata istruzione non è terminata il gruppo non può essere instradato verso le unità di esecuzione... Quando un gruppo viene mandato in esecuzione viene allocato parallelamente su tutte le unità disponibili fra i 4 (o N) core...
A questo punto, come avevo detto tempo fa, si risolverebbero alla base anche i salti condizionati... Infatti forse converrebbe eseguire entrambi i branch del salto...
La gestione di questo tipo di approccio è molto complessa e necessiterà sicuramente anche di un register file molto più grande...

Le strade sicuramente sono due: aggiungere istruzioni...ed in quel caso dovrebbe essere il compilatore a "guidare" la scheduler intenro alla CPU nello smistare le istruzioni fra i vari core... O lavorare al livello di CPU estraendo le unità di fetch e decode dai vari core e facendone una in comune... A questo punto avremmo già quelle che vengono chiamate da AMD MacroOPS... In tal caso ci potrebbe essere un ulteriore livello della pipeline che "mescoli" le istruzioni (questo già avviene, ma a livello delle sole unità interne ad ogni core per la out-of-order execution) analizzandonone le dipendenze... In questo modo sarebbe possibile organizzare le istruzioni indipendenti in gruppi, ogni gruppo dipendende da una determinata istruzione di un altro gruppo... Fino a quando l'esecuzione di quella determinata istruzione non è terminata il gruppo non può essere instradato verso le unità di esecuzione... Quando un gruppo viene mandato in esecuzione viene allocato parallelamente su tutte le unità disponibili fra i 4 (o N) core...
A questo punto, come avevo detto tempo fa, si risolverebbero alla base anche i salti condizionati... Infatti forse converrebbe eseguire entrambi i branch del salto...
La gestione di questo tipo di approccio è molto complessa e necessiterà sicuramente anche di un register file molto più grande...

non ho ben afferrato la prima ipotesi(aggiunta di istruzioni e compilatore che fa lo scheduling), ma direi molto, molto interessante la seconda (nonché sinteticamente ma ben spiegata, grazie), in particolare il fetch/decode "esterno" e comune con i core =solo execute (un tale approccio potrebbe il futuro facilitare, tra l'altro, la scalabilità in numero di core per cpu ?) e il raggruppamento istruzioni...
si sa che sono queste le idee che amd sta implementando o è una tua "speculazione" ? (speculazione in senso positivo, imho in tal caso dovresti cercare lavoro presso qualcuno che progetta cpu, se già non sei nel settore... :) )
e intel(o altri), si sa se sta lavorando a qaulcosa di analogo ?

Le strade sicuramente sono due: aggiungere istruzioni...ed in quel caso dovrebbe essere il compilatore a "guidare" la scheduler intenro alla CPU nello smistare le istruzioni fra i vari core... O lavorare al livello di CPU estraendo le unità di fetch e decode dai vari core e facendone una in comune... A questo punto avremmo già quelle che vengono chiamate da AMD MacroOPS... In tal caso ci potrebbe essere un ulteriore livello della pipeline che "mescoli" le istruzioni (questo già avviene, ma a livello delle sole unità interne ad ogni core per la out-of-order execution) analizzandonone le dipendenze... In questo modo sarebbe possibile organizzare le istruzioni indipendenti in gruppi, ogni gruppo dipendende da una determinata istruzione di un altro gruppo... Fino a quando l'esecuzione di quella determinata istruzione non è terminata il gruppo non può essere instradato verso le unità di esecuzione... Quando un gruppo viene mandato in esecuzione viene allocato parallelamente su tutte le unità disponibili fra i 4 (o N) core...
A questo punto, come avevo detto tempo fa, si risolverebbero alla base anche i salti condizionati... Infatti forse converrebbe eseguire entrambi i branch del salto...
La gestione di questo tipo di approccio è molto complessa e necessiterà sicuramente anche di un register file molto più grande...
si certo cio' che avevo sviluppato io era un sistema client-server che trasmetteva dati di grosse quantita' spezzandoli in tante parti.
Ogni client e ogni server lavorava in un thread per i cavoli suoi e tutto funzionava a meraviglia, chiaro che ci sono situazioni dove parallelizzare e' difficile, perche' dipendi da calcoli precedenti e quindi un approccio di questo tipo sarebbe davvero una manna dal cielo.

Sono speculazioni ovviamente...

Comunque ti spiego meglio l'aggiunta di istruzioni come potrebbe funzionare: metti che esistano due istruzioni per definire l'inzio e la fine di una sezione di codice parallelizzabile...e da quali registri queste istruzioni dipendono..

Il compilatore in un primo passo genererebbe il codice così come avviene adesso... In un secondo passo potrebbe fare un'analisi delle dipendenze e creare questi gruppi di istruzioni indipendenti fra loro e dipendenti da un certo numero di registri (numero che andrebbe limitato in base a prove pratiche)...

Si tratta a questo punto di creare nella CPU una unità che divida il gruppo di istruzioni fra i vari core e analizzi queste nuove istruzioni per creare le dipendenze rispetto ai vari registri... Queste saranno vincoli aggiuntivi per l'out-of-order execution... L'unica cosa è che i vari core dovrebbero comunque condividere il register file...

Riguardo alla seconda ipotesi, che secondo me è quella più valida e affascinante (mi sembra che AMD abbia già diversi brevetti per un multicore con fetch, decode e cache comuni), mi venne in mente quando Intel parlò di voler integrare fino a 100 core nella stessa CPU... Consentirebbe appunto di scalare molto bene e di semplificare ogni core... Di fatto il 30% (esclusa la cache) di ogni CPU è oggi occupato dall'unità di fetch e decode... Farne una, anche più complicata (perchè il numero di istruzioni che deve "sputare" fuori sarebbe nettamente maggiore) per tutti i core, sicuramente occuperebbe meno spazio di quello che occupa ora...
Sinceramente non vedo altre strade tecnicamente possibili rispetto a quella che ho supposto... Altrimenti ci sarebbero veramente troppe dipendenze fra i vari core per utilizzare qualsiasi altro approccio che mi viene in mente...