Architetture Quad Core: forse nel 2007

[Redazione di Hardware Upg]

Link alla notizia: http://news.hwupgrade.it/14494.html

Il CEO di AMD conferma l'intenzione di passare, tra alcuni anni, ad architetture di processore con 4 Core. Il multicore è la via del futuro

Click sul link per visualizzare la notizia.

[sidewinder]

Adesso resta solo da iniziare a rivedere il SW in chiave multithreading.

[vincino]

Mi sembrava di averla già letta qualche gg fa questa notizia!

[Capirossi]

diventeremo azionisti enel ?

[zuLunis]

Uff mi sa ke le prossime evoluzioni tecnologiche in ambito di processori saranno solo l'aumento di core integrati... come per la corsa ai ghz, una noia mortale per l'evoluzione.

[adynak]

Ma ogni volta che si aggiunge un core bisognerà anche cambiare software per sfruttarlo ? Oppure assisteremo alla nascita di software in grado di riconoscere dinamicamente il numero di core e di sfruttarli in maniera adeguata ?
Perché se ogni volta che si cambia procio bisogna comprare di nuovo tutto il software ... lo stesso HW lo faccio durare almeno 5 anni !!!

[Michelangelo_C]

Originariamente inviato da zuLunis

Uff mi sa ke le prossime evoluzioni tecnologiche in ambito di processori saranno solo l'aumento di core integrati... come per la corsa ai ghz, una noia mortale per l'evoluzione.

Dai a me non sembra male la prospettiva che in futuro chiunque possa avere 4 CPU (o anche di più) da utilizzare sia in più applicazioni contemporaneamente, ma anche in una singola applicazione raggiungendo risultati incredibili. Sarebbe davvero bello se come dice adynak scrivessero sw in grado di riconoscere la presenza di più processori in modo dinamico, in modo da sfruttare a pieno tutta la potenza disponibile. Comunque se sviluppassero CPU con core eterogenei, sarebbe davvero un'evoluzione che porterebbe a cose oggi impensabili, una vera rivoluzione nel modo di concepire l'hw e il sw!

[Cimmo]

In generale no non dovrai cambiare software ogni volta che aumentano i core/processori, nel senso che il software scritto per sfruttare piu' core/processori apre N thread e poi nel caso di 2 core/processori ognuno svolgera' N/2 thread (in realta' dipende a seconda delle richieste delle altre applicazioni, ma semplifichiamo), se sono 4 core/processori ognuno svolgera' N/4 thread, tutto questo senza piu' riscrivere alcuna riga di codice

[Michelangelo_C]

Originariamente inviato da Capirossi

diventeremo azionisti enel ?

Eh già, però mi viene un dubbio: non era stato detto che il TDP dei dual core era lo stesso dei single? Ma soprattutto, come è possibile questo? Va bene che le due cpu condividono alcune componenti, ma comunque si parla di mettere due CPU (e anche due cache) là dove ce ne stava solo una!

[JohnPetrucci]

Originariamente inviato da zuLunis

Uff mi sa ke le prossime evoluzioni tecnologiche in ambito di processori saranno solo l'aumento di core integrati... come per la corsa ai ghz, una noia mortale per l'evoluzione.

Condivido pienamente.
Soprattutto sottolineo che il software dovrà continuamente essere aggiornato al frazionamento continuo dei core delle cpu, per essere sfruttato a dovere.
Cosa che con l'incremento dei MHZ almeno non avveniva!

[TripleX]

mai sentito parlare di die shrink verso 0,065 micron? e' naturale che con l'evolversi del numero cpu si evolvera' il processo produttivo,naturalmente al diminuire del vcore necessario corrispondera' un incremento di Ampere richiesto,quindi la circuiteria delle mobo in prospettiva dovra'soddisfare requisiti di olre 200A e sicuramente i produttori di mobo approfitteranno in tal senso facendo si'che se per le mobo dualcore basti un mero aggiornamento bios x le quad occorrera' una nuova revision con finali molto piu' potenti...

[TripleX]

ops errata corrige naturalmente x dual e quad intendo il supporto alle cpu con relativi n core!

[Cimmo]

Originariamente inviato da JohnPetrucci

Condivido pienamente.
Soprattutto sottolineo che il software dovrà continuamente essere aggiornato al frazionamento continuo dei core delle cpu, per essere sfruttato a dovere.
Cosa che con l'incremento dei MHZ almeno non avveniva!

Ma non e' vero!
Leggi il mio post precedente...

[Tanner]

Per ora l'unico Sistema Operativo desktop in grado di sfruttare a dovere la presenza di più core è il vecchio, amatissimo BeOS... quindi gettiamoci tutti a capofitto su ZETA... o aspettiamo Haiku...
(fonti: yellowtab.com e haiku-os.org)

[shodan]

Originariamente inviato da Cimmo

In generale no non dovrai cambiare software ogni volta che aumentano i core/processori, nel senso che il software scritto per sfruttare piu' core/processori apre N thread e poi nel caso di 2 core/processori ognuno svolgera' N/2 thread (in realta' dipende a seconda delle richieste delle altre applicazioni, ma semplifichiamo), se sono 4 core/processori ognuno svolgera' N/4 thread, tutto questo senza piu' riscrivere alcuna riga di codice

Non è detto... dipende da come è fatta l'applicazione.
Se infatti usa due thread (per portare avanti due calcoli indipendenti) anche con 8 core non avrai prestazioni superiori rispetto a 2 core.
Se invece l'applicativo lancia un nuovo thread ogni volta che se ne fa richiesta, a seconda del carico avrai beneficio nell'aumentare il numero di core. Questo però lo vedo difficile da implementare in applicazioni che non siano interattive. Esempio: tempo fa ho scritto un piccolo server telnet multithread, facendo in modo che ogni nuova connessione sia gestita da un nuovo thread. In questo caso, avendo 8 core, se apro 8 connessioni queste sarebbero gestite in modo equo tra i vari core, traendone quindi beneficio. Ma se faccio solo 1 o 2 connessioni, non avrò beneficio di tutti gli altri core che non vengono utilizzati (ho semplificato in misura estrema, mi scuso per le evenutali imperfezioni che sicuramente salteranno fuori a un'occhio "allenato").

Ciao.

[shodan]

Originariamente inviato da Tanner

Per ora l'unico Sistema Operativo desktop in grado di sfruttare a dovere la presenza di più core è il vecchio, amatissimo BeOS... quindi gettiamoci tutti a capofitto su ZETA... o aspettiamo Haiku...
(fonti: yellowtab.com e haiku-os.org)

Be, anche gli altri derivati UNIX non sono affatto male, anzi, con linux puoi addirittura scegliere il tipo di scheduler da utilizzare (ce ne sono 3, di cui uno realtime... fantastico!).

Ciao.

[ErminioF]

Beh cmq si parla dei primi sample nel 2007, quindi di tempo per vedere come si evolverà la situazione ce n'è

[RE DEI VIRUS]

EVVIVA SI CAMBIA IL CONTATORE.....
CI ALLACCIAMO DIRETTAMENTE ALLA CENTRALE

Ho un dubbio ma i case quanto saranno grandi???
Oppure i proci quanto saranno piccoli??

[jappilas]

Originariamente inviato da shodan

Non è detto... dipende da come è fatta l'applicazione.
Se infatti usa due thread (per portare avanti due calcoli indipendenti) anche con 8 core non avrai prestazioni superiori rispetto a 2 core.
Se invece l'applicativo lancia un nuovo thread ogni volta che se ne fa richiesta, a seconda del carico avrai beneficio nell'aumentare il numero di core. Questo però lo vedo difficile da implementare in applicazioni che non siano interattive. Esempio: tempo fa ho scritto un piccolo server telnet multithread, facendo in modo che ogni nuova connessione sia gestita da un nuovo thread. In questo caso, avendo 8 core, se apro 8 connessioni queste sarebbero gestite in modo equo tra i vari core, traendone quindi beneficio. Ma se faccio solo 1 o 2 connessioni, non avrò beneficio di tutti gli altri core che non vengono utilizzati (ho semplificato in misura estrema, mi scuso per le evenutali imperfezioni che sicuramente salteranno fuori a un'occhio "allenato").

Ciao.

mi hai fatto ricordare il programmino di downloading che stava scrivendo un mio amico, multithread e dinamico in un modo che non avevo mai visto... qui il problema di non avere abbastanza threads non sussiste, per il semplice motivo che essendo multiprotocollo (ftp, http, potenzialmente p2p...) multi-connessione (ho visto 32 socket per dei download http dallo stesso server, il che in realtà violerebbe le specifiche ) e multi-fonte, e usando un thread per socket (e tenendo conto che ad es una connessione ftp di socket ne usa due, uno per i comandi uno per i dati...)... a ciò si aggiunge che l' interfaccia di suo, usa tot thread....
il punto è che in certi casi (compiti non cpu bound) le richieste della singola unità esecutiva tendono a diventare abbastanza leggere, da non richiedere certamente le prestazioni che un core può dare anche da solo, e rendere consistente la percentuale di overhead indotta dallo sfruttamento di "troppi" thread...

[jappilas]

Originariamente inviato da RE DEI VIRUS

EVVIVA SI CAMBIA IL CONTATORE.....
CI ALLACCIAMO DIRETTAMENTE ALLA CENTRALE

Ho un dubbio ma i case quanto saranno grandi???
Oppure i proci quanto saranno piccoli??

ehm, non hai letto i commenti precedenti...si diceva appunto che il processo produttivo che verrà adottato nel 2007 sarà con tutta probabilità più raffinato degli attuali (0,065 micron o meno) con conseguenti consumi energetici e dissipazione, inferiori..