addio legge di moore :(

[Rayvaughan]

si sapeva già, QQ cmq
http://www.tomshw.it/news.php?newsid=18511

[Alkabar]

si sapeva già, QQ cmq
http://www.tomshw.it/news.php?newsid=18511

Ci sono gia' soluzioni allo studio per differenti architetture e transistor.

Semmai cmos addio :D.

[Evildark]

neediamo new technologies :metal:

[Hador]

se vabbè nel 96 tipo erano li a dire SOTTO I 70 NANOMETRI E' IMPOSSIBBBBBBBILE CONTRO LA FISICAH :nod:

[bakunin]

beh pero non si dice una cosa: è da parecchio tempo che la potenza di calcolo non è piu un elemento critico, quindi se qualcuno ferma l'innovazione probabilmente sara il mercato. il pc nei centri commerciali costa 300€, i notebook hanno superato le vendite dei desktop. la potenza del processore non è piu l'unica cosa che conta quando si compra un pc (da tanti anni)... a breve, quando la potenza della scheda video potra essere sommata a quella del processore in tutte le applicazioni, questa società si nasconderà sotto terra per 3 o 4 anni, anche perche per aumentare la potenza di calcolo a ritmi da legge di moore non si puo piu cercare solo la strada della miniaturizzazione (processori con piu core ne sono l'esempio)

cmq è da almeno 15 anni che si parla di salto tecnologico nell'abbandonare il silicio, pero sembra che piu si va avanti e piu è difficile superarlo visto che tutta la ricerca si fa per affinare la tecnologia esistente... si deve aspettare lo stallo, se mai ci sarà

cioè si parlava di computer quantistico e di processori a fibre ottiche quando ancora in italia non esisteva internet e si telefonava con i gettoni sip. oggi in una cyclette, senza scomodare un lettore mp3, c'è piu potenza di calcolo di quella che si portava dietro lo shuttle negli anni 60... io direi che se rallentiamo da quel punto di vista non succede nulla tanto si sperimenta su tanti altri campi

[Hador]

al di la di questo già ora tecnologia < architettura, attualmente la potenza dei processori sta più nella loro architettura che nelle caratteristiche fisiche. Non era così una decina di anni fa e in ogni caso la prima vera dimostrazione di questo è stato il core duo in ambito desktop

[marlborojack]

al di la di questo già ora tecnologia < architettura, attualmente la potenza dei processori sta più nella loro architettura che nelle caratteristiche fisiche. Non era così una decina di anni fa e in ogni caso la prima vera dimostrazione di questo è stato il core duo in ambito desktop
:nod: c'è anche da tenere conto che ormai i fenomeni quantistici a quelle grandezze non possono essere trascurati... vedremo un po', ci sono tecnologie interessanti che devono uscire, prima tra tutti un'architettura seria per l'informatica quantistica, che ancora stenta ad essere prodotta

EDIT: la legge di moore m'è sempre sembrata una cazzata alla "640k sono più che sufficienti" (cit.)

[Burner]

se vabbè nel 96 tipo erano li a dire SOTTO I 70 NANOMETRI E' IMPOSSIBBBBBBBILE CONTRO LA FISICAH :nod:


ahahah vero mi ricordo che ad ogni processore che usciva c'era la storia eehh sotto di questo impossibile andare, e poi puntuale usciva quello a 10 nanometri in meno.

cmq i quantum processor ci aspettano :nod:
per ora a fare il sudoku sono forti :confused:

[Hador]

:nod: c'è anche da tenere conto che ormai i fenomeni quantistici a quelle grandezze non possono essere trascurati... vedremo un po', ci sono tecnologie interessanti che devono uscire, prima tra tutti un'architettura seria per l'informatica quantistica, che ancora stenta ad essere prodotta

EDIT: la legge di moore m'è sempre sembrata una cazzata alla "640k sono più che sufficienti" (cit.)vabbè non è una passeggiata,o che poi molti non si rendono conto di quanto ci sia ancora da fare... anche riuscire a implementare una ndtm sarebbe una cosa carina :nod:

[Dr.Doomed]

si sapeva già, QQ cmq
http://www.tomshw.it/news.php?newsid=18511

Un valido sprone a scrivere codice migliore, almeno per applicazioni non troppo uber. :nod:

PS: a parte che la legge di Moore l'ha scritta il signor Moore, fondatore di Intel... mi sa che almeno fino a qualche tempo fa faceva lo stesso giochetto di Bubka: 1 cm in piu` ogni volta il russo, un raddoppio ogni 18 mesi l'americano, per tirare piu` soldi... ;)

[Hardcore]

forse si comincerà a migliorare la logica delle cpu invece che aumentarne solo la frequenza.

[Kjoene]

Il 2012 è vicino.

[Hador]

forse si comincerà a migliorare la logica delle cpu invece che aumentarne solo la frequenza.
cosa che si fa già da 10 anni come ho scritto sopra :rain:

[Ercos]

cosa che si fa già da 10 anni come ho scritto sopra :rain:

mi hai letto nel pensiero lol.

[Rayvaughan]

bho io sono interessato a nuove architetture, specie di come viene gestita la memoria ed il sistema di interrupt, obsoleti ma ancora in uso, visto che costerebbe tantissimo rivoluzionare su larga scala tale logiche

[Hador]

obsoleti un par di palle, è che non gli hai (ancora) studiati è_é
poi c'è sempre il discorso compatibilità, qua non puoi buttare via tutto da un giorno all'altro

[Rayvaughan]

obsoleti un par di palle, è che non gli hai (ancora) studiati è_é
poi c'è sempre il discorso compatibilità, qua non puoi buttare via tutto da un giorno all'altro
esatto, è la compatibilità, la voglia di scrivere sistemi operativi da capo e linguaggi assemblatori da zero.... poi non andranno i giochi uuuhhhhhhh che palle!

[ahzael]

Veramente le nuove tecnologie e architetture sono gia in atto, basti vedere la tecnologia multicore , che e' solo recentemente diventata di publico dominio, le universita' avevano a disposizione sistemi multiprocessori da diversi anni, ma mai si era arrivato che arrivase al publico, invece visti i limiti fisici, siamo dovuti passarci per forza, la legge di moore non e' sbagliata, va solo adeguata, infatti oramai non si parla di transistor, ma di numero di core, infatti gia nel 2010 ci aspettiamo il processore a 8 core disponibile sul mercato, per arrivare almeno a 64 tra qualche anno.
La programmazione sequenziale e' oramai troppo obsoleta, quello ce da dire, e le universita' devono mettere reali corsi di programmazione parallel, non solo stupide introduzione al distributed computing, nello stesso momento in cui si fa c++, bisogna insegnare anche openmp o posix.

[Hador]

sta roba della programmazione concorrente la devo capire... perchè ritornare a livello macchina? abbiamo fatto tutta sta menata degli oggetti per piantarla di chiamare i puntatori a mano e poi vogliamo gestire la concorrenza a livello di codice?
Concorrenza? lavoro a thread dove necessario poi si deve smazzare tutto il compilatore e l'architettura, fermorestando che attualmente il modello di esecuzione è sequenziale, anche con più core. Tutti i tentativi di formalizzare dei modelli di calcolo alternativi sono falliti miseramente...

[Alkabar]

sta roba della programmazione concorrente la devo capire... perchè ritornare a livello macchina? abbiamo fatto tutta sta menata degli oggetti per piantarla di chiamare i puntatori a mano e poi vogliamo gestire la concorrenza a livello di codice?
Concorrenza? lavoro a thread dove necessario poi si deve smazzare tutto il compilatore e l'architettura, fermorestando che attualmente il modello di esecuzione è sequenziale, anche con più core. Tutti i tentativi di formalizzare dei modelli di calcolo alternativi sono falliti miseramente...

nevvero :

http://projectfortress.sun.com/Projects/Community

:angel:

[Hador]

per HPC è_é
che poi imo è lisp :nod:

[ahzael]

sta roba della programmazione concorrente la devo capire... perchè ritornare a livello macchina? abbiamo fatto tutta sta menata degli oggetti per piantarla di chiamare i puntatori a mano e poi vogliamo gestire la concorrenza a livello di codice?
Concorrenza? lavoro a thread dove necessario poi si deve smazzare tutto il compilatore e l'architettura, fermorestando che attualmente il modello di esecuzione è sequenziale, anche con più core. Tutti i tentativi di formalizzare dei modelli di calcolo alternativi sono falliti miseramente...

Ma anche no, l architettura che si usa in parallelo non e' per niente uguale all architettura in sequenza, anche se comunque la legge di amdhali (o come cazzo si chiama) dice che in ogni sua parte, un programma non puo andare piu veloce della sua parte in sequenza, ma gestire un programma multithreaded in c++ o qualunque altro linguaggio e' lento e dispendioso, sia come risorse che come tempistica, ovvio che se tu vivi in burundistan, e nessuno sa', puoi anche metterci 20 anni a scrivere un programma che utilzza un milione di semafori o quello che ti pare per sincronizzare tutti i thread, poi un giorno arrivo io che ti faccio lo stesso programma senza nemmeno metterci una giornata e utilizzando un milionesimo delle linee di codice tue, allora qualcuno comincia a pensare che forse sia meglio dare i tuoi soldi a me.

attacato ci ho messo un esempio banale di un programma scritto un semplice pragma di open mp, prova a disattivare il pragma e poi mi racconti quanto ci metti.........

[Hador]

se devo scrivere programmi ad alte prestazioni non mi metto ad usare i thread ma neanche mi metto a usare java, ma HPC a parte java (ma anche c#) ha un ottima gestione del parallelismo, basta usarlo.
Non sono particolarmente interessato a quel tipo di programmazione scientifica, di certo non veniamo a dire però che mo per programmare applicativi per desktop o gestione di sistemi mi debba mettere ad usare linguaggi per la programmazione parallela.

[ahzael]

Be si, puoi anche usare java e c#, a no spetta, mi ero scordato che c# e java non sono linguaggi diretti, tanto e' vero che java avra il pieno supporto per il multicore solo nel 2010 con il release del prossimo pacchetto, poi usare HPC ? cioe fammi capire, io devo codificare un video, allora devo andare a prenermi un cluster mentre con un programma scritto in parallelo, con fine tuning apposito, quindi non solo multi threaded, ma studiato a appositamente, riesco a fare piu che se facessi su un cluser intero? cioe solo il fatto che passi da usare la cache di L2 a quella di L3 per comunicare tra i core gia hai un calo di performance assurdo, pensa se invece per comunicare usi il bus o magari il network visto che in un cluster questo si fa.
Cioe' non e' una scelta, ma un obligo saperlo fare, non si puo evitare, la Intel sta pagando milioni di dollari per andare nelle scuole a fare i corsi professionali ai dottorandi e ai professori per poi un giorno riutilizzare i propri software, lo stesso sta facendo la microsoft, che ha incluso il profiler multi core in VS2010, quindi qui si parla di esigneza di mercato vera e propria, visto che cmq sia, la programmazione classica sequenziale non puo migliorare visto che e' puramente dipendente dal clock, e visto che il clock sta fermo li, non si puo fare piu di tanto, anche se utilizzi i vari mmx, sse o qualunque altra cosa.

Poi ognuno e' libero di pensare come gli pare, io sto facendo la mia ricerca di dottorando appositamente per entrare nel mondo accademico, e' ovvio che a me interessa la performance estrema, mentre magari al programmatore + 1 che esce dall universita', ha solo necessita di saper scrivere un programma che utilizzera' come template per i prossimi 100/1000/10000 clienti, a cui fara' modeste modifiche qui e li' per accontentare tutti.

[Hador]

aho azha programmare il processo di rendering video e programmare il programma che ti lancia il rendering sono cose diverse ci arriviamo o no?
fermorestando che tempo 2-3 anni (già ci sono ora) avrò le mie belle librerie ed esattamente come estendo il java.thread estendo il java.SuppaThread che si smazza la gestione multicore da solo, chiaro se devo fare il software di gestione del cambio della ferrari non lo faccio in java ad oggetti, ma sto parlando di un'altra cosa.
Quello che bisogna imparare non è il linguaggio multicore ma la PROGETTAZIONE che sfrutti dove possibile il parallelismo, che poi questo tu lo implementi con il linguaggio di basso livello è dovuto solo al fatto che è roba nuova ma assolutamente destinata a scomparire, non siamo arrivati fin qua per poi tornare ad usare il c riveduto e corretto.
E l'ambito accademico non centra una mazza ognuno si specializza in cose diverse, dall'ingegneria del software alla progettazione di sistemi complessi ai sistemi informativi sta roba interessa un ambito, anche se so bene che quando ti metti a lavorare su una cosa ti pare sia quella che rivoluzionerà il mondo (oddio, possibile, ma tutto rivoluzionerà il mondo ora come ora).

[Hardcore]

cosa che si fa già da 10 anni come ho scritto sopra :rain:
Diciamo che si fa da 10 anni ma che si potrebbe fare di piu e di necessità virtu

[marlborojack]

Be si, puoi anche usare java e c#, a no spetta, mi ero scordato che c# e java non sono linguaggi diretti, tanto e' vero che java avra il pieno supporto per il multicore solo nel 2010 con il release del prossimo pacchetto,
Ma che cazzo dici? Java supporta in pieno il multicore visto che i thread java vengono mappati 1:1 su thread di sistema, che a loro volta vengono gestiti dall'architettura Symmetric Multi-Processing, disponibile su praticamente tutti i sistemi operativi, persino su Solaris? Mah, vatti a vedere http://java.sun.com/docs/hotspot/threads/threads.html è dalla 1.3 che ci sono i thread.



cioe fammi capire, io devo codificare un video, allora devo andare a prenermi un cluster mentre con un programma scritto in parallelo, con fine tuning apposito, quindi non solo multi threaded, ma studiato a appositamente, riesco a fare piu che se facessi su un cluser intero?

Ma che cazzo dici, secondo te una macchina sequenziale multiprogrammata va meglio di un cluster? ma non scherziamo, un multicore è cluster di processori, senza più unità di elaborazione non ti serve a nulla il "Tuning", tutta la tua multiprogrammazione viene eseguita su un unico core per cui in pratica hai solo sputtanato tempo nelle commutazioni di contesto



cioe solo il fatto che passi da usare la cache di L2 a quella di L3 per comunicare tra i core gia hai un calo di performance assurdo, pensa se invece per comunicare usi il bus o magari il network visto che in un cluster questo si fa.

Sì, ma solo per elaborazione dati. Se tutti i tuoi core devono comunicare con un'unica memoria, metti la ram, son tutti lì che aspettano di accederci in mutua esclusione per scriverci, e buonanotte



Cioe' non e' una scelta, ma un obligo saperlo fare, non si puo evitare, la Intel sta pagando milioni di dollari per andare nelle scuole a fare i corsi professionali ai dottorandi e ai professori per poi un giorno riutilizzare i propri software, lo stesso sta facendo la microsoft, che ha incluso il profiler multi core in VS2010, quindi qui si parla di esigneza di mercato vera e propria,

Se ti riferisci ai threads, è da VS2005 che si possono integrare i ThreadChecker e le altre librerie Intel. Al massimo Intel è interessata a far capire che se fai tutto in sequenza può andare tutto bene, se fai multiprogrammazione devi tener conto di deadlocks, corse critiche e altre amenità. Non sono da sottovalutare cmq, basta pensare che la Nasa con un errore nella progettazione dello schedulatore RealTime c'ha perso il primo robottino su marte, dove un thread a bassa priorità bloccava un thread a + alta priorità



visto che cmq sia, la programmazione classica sequenziale non puo migliorare visto che e' puramente dipendente dal clock, e visto che il clock sta fermo li, non si puo fare piu di tanto, anche se utilizzi i vari mmx, sse o qualunque altra cosa.

Questo è vero, anche se in realtà gioverebbe molto cmq portare tutte le periferiche alla velocità di elaborazione del clock. In alcune però ci sono limiti meccanici, per ora. Ultimamente si sente molto l'esigenza della velocità anche nel mio campo, l'automazione, perchè i controllori diventano sempre più complicati e quindi ti serve molta potenza di elaborazione tra un campionamento ed un altro.



Poi ognuno e' libero di pensare come gli pare,

NO, grazie a dio quando si entra nel campo dell'elaborazione, ci sono dati quantitativi e quindi si stabilisce un'ordinamento in termini di performance delle soluzioni



io sto facendo la mia ricerca di dottorando appositamente per entrare nel mondo accademico, e' ovvio che a me interessa la performance estrema, mentre magari al programmatore + 1 che esce dall universita', ha solo necessita di saper scrivere un programma che utilizzera' come template per i prossimi 100/1000/10000 clienti, a cui fara' modeste modifiche qui e li' per accontentare tutti.

Ma non è una questione di performance estrema, quella in realtà serve ma in un campo di applicazioni abbastanza limitato. La verità è che ora c'è molto interesse per i sistemi distribuiti, leggi applicazioni delle reti di sensori, ragion per cui la programmazione concorrente serve a prescindere dalle performance

[Hador]

si marblo ma ripeto, un conto è la "programmazione concorrente" a basso livello un contro è la progettazione concorrente, che tira in ballo anche reti di sensori.
Sono due discorsi paralleli, il primo so anche io ci sono linguaggi duri e crudi e un bel po' di ricerca su ottimizzazione algoritmica multicore, alla ricerca della performance assoluta, io ne avevo sentito parlare in ambito criptografico ma è cmq abbastanza di moda, il secondo è un discorso di mentalità ma proprio dell'ingegneria del software e già ampliamente supportato dai linguaggi ad oggetti, per formalizzare un sistema concorrente devi conoscere tutta una serie di robe ma di certo non ti devi curare di questa o quella cache o di indirzzare i thread a mano (il primo esame su sta al secodo anno usavamo ltsa per modellare e java per programmare, mi divertivo un sacco...).
Se il 90% dei programmi consumer, ad esempio i giochi, ancora ora girano su un core solo è colpa del secondo punto mica del primo.

[marlborojack]

si marblo ma ripeto, un conto è la "programmazione concorrente" a basso livello un contro è la progettazione concorrente, che tira in ballo anche reti di sensori.
Sono due discorsi paralleli, il primo so anche io ci sono linguaggi duri e crudi e un bel po' di ricerca su ottimizzazione algoritmica multicore, alla ricerca della performance assoluta, io ne avevo sentito parlare in ambito criptografico ma è cmq abbastanza di moda, il secondo è un discorso di mentalità ma proprio dell'ingegneria del software e già ampliamente supportato dai linguaggi ad oggetti, per formalizzare un sistema concorrente devi conoscere tutta una serie di robe ma di certo non ti devi curare di questa o quella cache o di indirzzare i thread a mano (il primo esame su sta al secodo anno usavamo ltsa per modellare e java per programmare, mi divertivo un sacco...).
Se il 90% dei programmi consumer, ad esempio i giochi, ancora ora girano su un core solo è colpa del secondo punto mica del primo.
:nod: certo, condivido. Sui giochi vedrai che la faccenda cambierà molto, imho, quando sempre più case si affideranno ad un motore fisico per gestire l'ambiente. Fare un motore fisico uniprogrammato è un suicidio

[ahzael]

Vabbe andatevi a leggere le varie release note per java 7 riguardo al supporto multicore per capire la vera differenza tra ora e quello che hanno in piano per il futuro.
Poi a voi non importa di avere magari un 1% di performance in piu' magari togliendo una virgola, ma a me' che si.

cmq questo punto giusto perche' mi e' venuto all occhio piu degli altri

Ma che cazzo dici, secondo te una macchina sequenziale multiprogrammata va meglio di un cluster? ma non scherziamo, un multicore è cluster di processori, senza più unità di elaborazione non ti serve a nulla il "Tuning", tutta la tua multiprogrammazione viene eseguita su un unico core per cui in pratica hai solo sputtanato tempo nelle commutazioni di contesto

Scusa ma che vuol dire una macchina sequenziale multiprogrammata ? Cioe non si chiamano dual / quad core perche' il nome fa fico, ogni core e' indipendente, quindi come puoi dire che e' sequenziale ? Ogni core ha i suoi registri e la sua cache e il suo "elaboratore" , quindi sono tutte unita' indipendenti.............la programamzione parallela serve appositamente per questo, per utilizzare tutti i core............

[marlborojack]

Vabbe andatevi a leggere le varie release note per java 7 riguardo al supporto multicore per capire la vera differenza tra ora e quello che hanno in piano per il futuro.
Poi a voi non importa di avere magari un 1% di performance in piu' magari togliendo una virgola, ma a me' che si.

cmq questo punto giusto perche' mi e' venuto all occhio piu degli altri

in realtà neanche mi interessa moltissimo, è solo che il supporto alla multiprogrammazione c'è già in java. Poi non so che ottimizzazioni mettano nella prossima, se è una differenza sostanziale spiega :scratch:



Scusa ma che vuol dire una macchina sequenziale multiprogrammata ? Cioe non si chiamano dual / quad core perche' il nome fa fico, ogni core e' indipendente, quindi come puoi dire che e' sequenziale ? Ogni core ha i suoi registri e la sua cache e il suo "elaboratore" , quindi sono tutte unita' indipendenti.............la programamzione parallela serve appositamente per questo, per utilizzare tutti i core............
Grazie della spiegazione del tutto inutile. Una macchina sequenziale multiprogrammata = macchina con una singola cpu con supporto software per i processi e i thread. Dicevo prima che un solo elaboratore multiprogrammato anche se lo "tuni" non ti serve ad un cazzo per un certo livello di elaborazione video rispetto ad un cluster, ma immagino tu intendessi la stessa cosa... :scratch: