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
Printable View
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!Quote:
Originally Posted by Hador
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.
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 :Quote:
Originally Posted by Hador
http://projectfortress.sun.com/Projects/Community
:angel:
per HPC è_é
che poi imo è lisp :nod:
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.Quote:
Originally Posted by Hador
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.........
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.
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.
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).
Diciamo che si fa da 10 anni ma che si potrebbe fare di piu e di necessità virtuQuote:
Originally Posted by Hador
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.Quote:
Originally Posted by ahzael
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 contestoQuote:
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?
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 buonanotteQuote:
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.
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àQuote:
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,
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.Quote:
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.
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 soluzioniQuote:
Poi ognuno e' libero di pensare come gli pare,
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 performanceQuote:
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.
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 suicidioQuote:
Originally Posted by Hador
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
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............Quote:
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