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

La prossima disponibilità di architetture multicore richiede un lavoro di ottimizzazione da parte dei programmatori; Intel sviluppa a riguardo alcuni nuovi tool

Click sul link per visualizzare la notizia.

L'uso di istruzioni dedicate porterebbe forse ad un avvicinamento alle prestazioni di un dual Processor (tipo Xeon od Optheron).

Se tutti programmassero avendo come linea guida la vera genuina astrazione, nel momento in cui un software è stato scritto per usare core plurali sarebbe pronto,con variazioni in linea di massima a seconda del servizio, per qualsiasi futuro numero di core (dai due in su).Non voglio neppure immaginare ci siano sviluppatori di importanti software professionali che agiscano diversamente.

Si vede che non hai mai lavorato in una SW house ;)

No, si vede che non si è mai scontrato con le problematiche derivanti dalla compatibilità dei linguaggi di programmazzione con le varie macchine della famiglia x86

Per me dovrebbero farci degli standard su queste cose.
Se lo fa solo Intel (quale monopolista) in formato unicamente proprietario, tutte le case concorrenti ne avrebbero solo degli handicap... che ovviamente pagheremmo comunque noi.

Comunque i dual core sono fuori da un pezzo... di ottimizzazioni ancora un pò pochine... si dessero una mossa...

Ciao

Guarda che dal punto di vista software Intel non ha rivali, addirittura si dice che parte del successo di AMD nei server con gli Opteron sia dovuta al fatto che queste cpu lavoravano meglio con il compilatore Intel C++ dei p4......

Mhmmm mi sà di marmotta che confeziona la cioccolata quest'ultima affermazione...

Per me dovrebbero farci degli standard su queste cose.
Se lo fa solo Intel (quale monopolista) in formato unicamente proprietario, tutte le case concorrenti ne avrebbero solo degli handicap... che ovviamente pagheremmo comunque noi.

Comunque i dual core sono fuori da un pezzo... di ottimizzazioni ancora un pò pochine... si dessero una mossa...

Ciao

non solo... i dual processors lo sono anche da molto di piu' ;)
quasi tutti i software applicativi per server sono multithread, le cose devono invece ancora maturare per gli applicativi client.

thread crackers e profilers sono ottimi strumenti, ma la cosa piu' importante e' programmare pensando di far girare poi il software su n processori (o cores/threads)
purtroppo nella realtaà troppo spesso ci si mette ad ottimizzare il codice in ottica multithreading solo quando ci si rende conto che l'applicativo sta diventando un autentico collo di bottiglia..(di solito in seguito alle lamentele dei clienti :D )

Beh Intel è sempre stata all'avanguardia nella progettazione di software che permette di sfruttare al massimo i suoi processori, come il suo compilatore C/C++ che permette di avere un notevolissimo boost prestazionale con i processori della serie Pentium. ;)
Non mi stupisce che ora si stiano muovendo verso l'ottimizzazione per i multicore considerando che nel loro compilatore hanno il miglior vettorizzatore in grado di sfruttare al massimo le chiamate alle SSE. :p

Sul fatto che invece AMD traesse vantaggio dal Intel C/C++ Compiler ho i miei forti dubbi dato che gli AMD64 venivano forzati sul code path del Pentium 3 quando sarebbe stato meglio forzarli sul code path dei Pentium M, oppure venivano indirizzati su code path non ottimizzati (senza SSE). :)

Scusate una domanda: ma dato che la licenza di Windows è legata al numero di CPU presenti nel sistema, ed il kernel penso non possa utilizzarne più di 2, come si pone il problema davanti a 4 core?

La tecnologia HT ovvia a questo problema in quanto il secondo processore è logico e non fisico, ma con 4 core? Conta il package o il numero di core?

Scusate se sono OT.

Ciauz!

Si vede che non hai mai lavorato in una SW house ;)

No, si vede che non si è mai scontrato con le problematiche derivanti dalla compatibilità dei linguaggi di programmazzione con le varie macchine della famiglia x86

Vedete pure quello che volete vedere.Il mio era un discorso di principio da cui non potete trarre proprio alcuna conseguenza sulla mia persona, vedo che voi piuttosto avete molta facilità nel sentenziare senza argomentare e quindi quello che si può vedere invece dai vostri commenti è un bello zero tondo tondo. :D

Tempo addietro avevo letto di un test in cui avevano imbrogliato via sw un compilatore Intel facendo passare un Opteron per Xeon (o un Athlon per P4, non ricordo più), scoprendo che aumentavano le prestazioni fino al 40% (in media intorno al 10%).
Non è una cosa corretta, ma ha una logica. E'meno costoso 'ottimizzare' un compilatore piuttosto che la cpu stessa.
Purtroppo non sono stati i primi nè saranno gli ultimi a farlo, penso che anche Amd lo farebbe, se potesse.

Scusate una domanda: ma dato che la licenza di Windows è legata al numero di CPU presenti nel sistema, ed il kernel penso non possa utilizzarne più di 2, come si pone il problema davanti a 4 core?

La tecnologia HT ovvia a questo problema in quanto il secondo processore è logico e non fisico, ma con 4 core? Conta il package o il numero di core?

Scusate se sono OT.

Ciauz!

del problema se ne parla da tempo, (dall'avvento dell'HyperThreading sugli xeon) soprattutto per le licenze dei prodotti server (Oracle, SQLserver e molti altri) i cui prezzi salgono di molto quando le CPU rilevate dal sistema operativo sono piu' di due..
A quanto ero rimasto, ogni Software house ha fatto a modo suo, cmq spesso conteggiando i socket fisici dei processori piu' che contando le unita' esecutive. Ovviamente se qualcuno dovesse avere info + fresche sul licensing ben venga! ;)

Scusate ma OpenMP non dice nulla. Di che altre estensioni al C/C++ si hanno bisogno? Usiamo quello che c'e' no?
Tra l'altro e' gia' supportato dai compilatori intel e sun.
Cmq sara' roba apagamento, quindi basta farsi un giro alla SUN, scaricarsi lo Studio 11 ed avere tutto a macca compresa un'altra ottimizzazione per AMD e Intel piu' tools di ottimizzazione.

Microsoft se non sbaglio ha espressamente considerato i dual core (presumo che anche per i multi-core varrà lo stesso) come singolo processore, quindi nn cambiava nulla in termini di licenza.

Edit: lol nn avevo letto la risposta di Ratatosk (ho risposto dopo il post di piffe).

Per me dovrebbero farci degli standard su queste cose.
Se lo fa solo Intel (quale monopolista) in formato unicamente proprietario, tutte le case concorrenti ne avrebbero solo degli handicap... che ovviamente pagheremmo comunque noi.

Comunque i dual core sono fuori da un pezzo... di ottimizzazioni ancora un pò pochine... si dessero una mossa...

Ciao

Gli standard già ci sono. E si chiamano OpenMP (http://www.openmp.org) e MPI (http://www-unix.mcs.anl.gov/mpi/).
Sono standard già pronti, implementati, sperimentati e funzionanti. E ciè che è piu' importante, accettati.
Per come la vedo io questa mossa di Intel sarà un flop o, se non proprio un flop, l'ennesima tecnologia di nicchia a non proprio ampio margine. Inoltre non mi sembra che applicare delle estensioni non standard a C++ sia la scelta migliore (indipendentemente dal risultato). C++ sta subendo una nuova revisione dello standard. Non un semplice "aggiornamento" ma una vera e propria revisione massiccia dello standard. Bjarne Stroustrup lo chiama C++0x, ad indicare che sarà ultimato sicuramente prima del 2010. Si parlava anche di supporto nativo per la programmazione parallela direttamente nel linguaggio. Quindi direi che la mossa di Intel mi lascia indifferente al massimo.

Scusate ma OpenMP non dice nulla. Di che altre estensioni al C/C++ si hanno bisogno? Usiamo quello che c'e' no?

Ecco, appunto... Ho parlato troppo presto...


Tra l'altro e' gia' supportato dai compilatori intel e sun.


E non solo! GCC 4.2 (previsto per Natale circa) avrà un'implementazione completa delle specifiche OpenMP 2.5 unificate sia su C che C++ che Fortran. ;)


Cmq sara' roba apagamento, quindi basta farsi un giro alla SUN, scaricarsi lo Studio 11 ed avere tutto a macca compresa un'altra ottimizzazione per AMD e Intel piu' tools di ottimizzazione.

Esattamente. A pagamento e soprattutto roba legata ad un prodotto.