Newsgroup: it.comp.hardware
Titolo: Multithreading e multicore, stendiamo un velo pietoso

One reason for the underwhelming performance on the desktop is that the 
Bulldozer architecture emphasizes multithreaded performance over 
single-threaded performance.
 
http://arstechnica.com/business/2011/11/bulldozer-server-benchmarks-are-here-and-theyre-a-catastrophe/1/
 

acc ha scritto:

Io non ho capito un Cazzo! 
 
 

 Io non ho capito un Cazzo!
 
E' il fallimento di un processore basato sul concetto che 
multi-threading e multi-core spinti possano risolvere i problemi di 
prestazioni.
Nei test e' risultato anche piu' lento della serie precedente.

acc ha scritto:

Cosa lo hanno fatto uscire a fare? 
 
 

 Cosa lo hanno fatto uscire a fare?
 
Ormai la frittata era fatta...
Si sono sbagliati, capita.


  SE gli applicativi se ne fottono delle specifiche AMD non ci sono
santi... 
 
 


mi hai tolto le parole da sotto i tasti
 
 

 santi...
 
Perche' non gli scrivi e gli dici che hanno sbagliato tutto?
Sono sicuro che ti ringrazieranno del tuo aiuto.
 
Gli indirizzi sono sul sito: 
http://www.spec.org/
 


by Peter Bright - Nov 22 2011, 3:00am
 
Complimenti per la prontezza di riflessi.

 Complimenti per la prontezza di riflessi.
 
Non ho capito, dici che e' "scaduto" o che non te n'eri accorto?
Beh meglio tardi che mai. :-)

Sono sicuro che ti ringrazieranno del tuo aiuto.
 
  ... ma io sono stronzo!
 
 

Beh meglio tardi che mai. :-)
 
  Hai qualche altra "lieta novella" di cui parlare?! chesso'...
qualcosa sulla superiorita' degli SSD sugli HD meccanici... 
 


in campo scientifico viene definito "cherry picking"
ovvero estrapolare un singolo dato da un set pretendendo di confutare 
quanto mostrato invece chiaramente da tutti gli altri dati
 
certamente il passaggio al multicore è dipeso prima di tutto dal fatto 
che non era più possibile aumentare la potenza di elaborazione solo 
incrementando la frequenza di lavoro dei processori
 
certamente molti programmatori hanno trovato difficoltà nel recepire 
il concetto di elaborazione parallela, ma indipendentemente dalle 
difficoltà di comprendonio dei singoli programmatori, gran parte dei 
programmi può trarre vantaggio dalla elaborazione parallela dei dati
 
perfino i programmi che passano la maggior parte del tempo in idle 
aspettando l'input dall'utente (come per esempio un programma di 
scrittura di testo) in casi particolari (per esempio il cambiamento di 
stili, ricerche e sostituzioni, ecc. su un testo o testi molto lunghi) 
possono trarre vantaggio dalla parallelizzazione
 
i nuovi sistemi di calcolo, che probabilmente in futuro renderanno del 
tutto obsoleta l'architettura del classico PC, ovvero i sistemi di 
calcolo quantistico o quelli basati sui memristor, sono basati 
essenzialmente sull'uso massiccio del calcolo parallelo (come del 
resto anche i calcolatori biologici)
 
i nuovi linguaggi di programmazione e i nuovi compilatori con i vecchi 
linguaggi cercano di rendere il compito più facile per i programmatori
 
ti devi rassegnare: il calcolo parallelo è il presente e il futuro
 
poi se pretendi di dimostrare l'inutilità dello stesso per il fatto 
che il DOS 6 non ne trae alcun vantaggio è un'altra questione
 
-- 
bye
!(!1|1)
 
 
 

 qualcosa sulla superiorita' degli SSD sugli HD meccanici...
 
*plonk*

 il DOS 6 non ne trae alcun vantaggio è un'altra questione
 
Gli esempi che ho fatto riguardano i sistemi attuali (Windows NT in 
tutte le salse), quelli obsoleti come OS/2, BeOS e adesso DOS, li hai 
tirati in ballo tu.

ti devi rassegnare: il calcolo parallelo è il presente e il futuro
 
detta cosi', sembra un'esortazione di un "cyberman"
o un "borg": la resistenza e' inutile (scherzo, aheh)
 
ciao
luca
 
 

 Mal comune mezzo gaudio :-)
 
Mah, diciamo che tutta una serie di eventi
ha causato un certo allontanamento dalla
programmazione parallela.
 
Con un SO *serio*, anche con un single core,
conviene *comunque* scrivere SW parallelo.
 
Il motivo e` che se un processo deve attendere
dell'I/O, un altro puo` comunque elaborare dati.
Quindi la CPU, che e` una risorsa preziosa e
costosa, e` sfruttata al massimo.
 
Purtroppo, l'avvento e la dominanza di SO non
multi-tasking, ha causato quello che definirei
"analfabetismo di ritorno", riguardo l'uso di
piu` thread o task per un SW.
 
Adesso *sembra* che la programmazione parallela
sia un concetto mistico, da usare solo in casi
specifici ed adatti.
 
In realta` e` un concetto banale, da usarsi il
piu` spesso possibile.
 
Tanto per fare un esempio sciocco, uno script
shell esegue comandi in sequenza. Nel caso in
cui questi comandi siano indipendenti, e` sempre
possibile terminare la riga con "&", rendendo
lo script parallelo.
 
Il vantaggio?
Come scritto prima, se in uno script ho:
 
rm tmpfile
 
Posso scrivere
 
rm tmpfile &
 
E non dover aspettare la cancellazione del fle
prima di poter procedere con il comando successivo.
Anche su un single core.
 
Quindi, per concludere, il problema dello
sfruttamento di sistemi multi-core e` puramente
mentale, non tecnico.
 
bye,
 
-- 
 
piergiorgio

 piu` thread o task per un SW.
 
Scusa ma a quali SO ti riferisci?

 Scusa ma a quali SO ti riferisci?
 
Per es. DOS, dove la cosa piu` multi-tasking
erano i virus...
 
Quanto ci e` voluto prima che Win diventasse
realmente MT?
Stessa cosa per i vari MacOS.
 
IBM presento`, a suo tempo, un PPC dual core,
ma quelli che avrebbero dovuto/potuto usarlo
(quelli con la mela), non pensavano neanche
loro che uno potesse avere piu` di un programma
in funzione allo stesso tempo.
 
Considera che gia` AmigaOS, che *non* era di
nicchia, era multi-tasking.
Tutta la famiglia unix (BSD, SysV, etc.) era
multi-tasking "by design". Tant'e` che le prime
CPU multi core sono state Sparc e MIPS.
 
Purtroppo, pero`, quei SO o sono scomparsi o
sono rimasti nel settore server.
I SO piu` diffusi per il settore "personal"
ci hanno messo tempo prima di supportare un
multi-tasking vero, quindi i programmatori
sono cresciuti con l'idea che andasse bene
scrivere SW single-thread/task.
 
Adesso c'e` tutta una generazione di programmatori
che non e` molto "pratica" di programmazione MT.
Quindi, come tu stesso sottolinei, avere una CPU
con 4 core serve a poco, perche` non sembra sia
facile trovare qualcuno che scriva programmi MT.
D'altro canto, non e` neanche facilissimo.
 
bye,
 
-- 
 
piergiorgio

 facile trovare qualcuno che scriva programmi MT.
 
Non proprio, io dico che 2 core servono quasi sempre, mentre 4 
verrebbero raramente sfruttati, anche con software ottimizzato.
Cioe' in ambito generale preferisco un dual core a 3 GHz, piuttosto di 
un quad a 2 GHz, che resta un processore piu' lento, tranne in alcune 
(rare) occasioni.

 (rare) occasioni.
 
Il che puo` essere vero, ma molto triste
(non la tua preferenza, ma la situazione
che descrivi).
 
Questo e` sempre un problema di mentalita`.
 
Il PC e` concepito come una scatola di utensili,
dove se si usa il martello, il cacciavite non
puo` essere usato.
Se uso Word, di sicuro non mi serve Excel che
fa conti in background.
 
Il fatto e`, invece, che il PC e` *programmabile*,
quindi puo` fare un sacco di cose mentre io gioco
a Flight Simulator.
Solo che quasi nessuno concepisce questo uso, quindi
non ha senso rompersi la testa nel fornire tale
possibilita`. Il che e` molto triste, appunto.
Perche` sarebbe molto meglio aver 8 core ad 1GHz ed
usarli tutti, invece che 2 core a 4GHz.
Nel senso che se io scrivo un programma "parallelo",
ad ogni raddoppio di numero di core ho circa un
raddoppio di prestazioni.
E questo viaggia meglio di un raddoppio di frequenza.
 
Nota che non sto scrivendo che non sia vero il
fatto che un dual core sia sufficiente per un
uso "standard", sto scrivendo che la situazione
e` cosi` per tutta una serie di ragioni storiche.
 
bye,
 
-- 
 
piergiorgio

 a software non lo prenderei ad esempio.
 
e fai male. oppure non lo conoscevi. oppure i SO non sono il tuo campo di 
esperienza

 E questo viaggia meglio di un raddoppio di frequenza.
 
Solo se i due processi viaggiano separati e non hanno bisogno di 
sincronizzazione, un caso ideale come ne esistono pochi.

 esperienza
 
Aggiungerei "oppure ti sbagli tu", cosi' ci prendi per forza.
 
Quali sarebbero le cose interessanti e originali di AmigaOS?

 sincronizzazione, un caso ideale come ne esistono pochi.
 
E questo non e` un fatto "teorico", ma solo
dovuto a programmatori che non sanno come
risolvere il problema.
 
La parallelizzazione si applica in moltissimi
contesti, esistono solo pochi casi in cui non
e` applicabile.
E` il contrario di quello che credi tu.
Certo, a volte o spesso richiede una certa
capacita` di analizzare il problema.
Questo pero` e` una questione, appunto,
scolastica, non tecnica.
 
E` solo e semplicemente una questione di abitudine,
se uno ragiona in termini di "parallelismo", allora
tutto il SW scritto sarebbe multi-core e ne trarrebbe
vantaggio, a diversi livelli.
 
Ti posso assicurare anche un'altra cosa. Se invece
di aver fatto la gara dei MHz, avessero fatto la
gara dei core, oggigiorno tutto il SW sfrutterebbe
la cosa ed avremmo solo multi-threading/tasking.
 
bye,
 
-- 
 
piergiorgio

 Quali sarebbero le cose interessanti e originali di AmigaOS?
 
Beh, per es. era l'unico SO "personal"
capace di un multi-tasking vero... :-)
 
bye,
 
-- 
 
piergiorgio


 
ecc...
-- 
bye
!(!1|1)
 

 o un "borg": la resistenza e' inutile (scherzo, aheh)
 
è un dato di fatto... ormai l'unico aumento prestazionale può derivare 
solo da software in grado di sfruttare il calcolo parallelo
 
e prima o poi si avrà un ricambio generazionale e ci si libererà di 
chi è cresciuto tarato sul DOS come quegli idioti di FastStone Viewer 
che hai citato
 
come ho già scritto, già 20 anni fa c'erano programmi di grafica in 
grado di sfruttare anche 64 core... e 10-15 anni fa ho realizzato 
anche io diversi programmi (anche se solo con 2 o 3 thread)
 
il problema è che il 99% dei programmatori di una certa età si è 
formato su sistemi e su linguaggi su cui era quasi inconcepibile il 
calcolo parallelo
 
-- 
bye
!(!1|1)
 
 

 E` il contrario di quello che credi tu.
 
Esatto e non mi hai affatto convinto.
Fammi un esempio concreto di divisione di un calcolo dove le varie 
componenti non siano slegate tra loro.

 derivare solo da software in grado di sfruttare il calcolo parallelo
 
a parte che era una battuta, forse non sono
stato sufficientemente chiaro nel prendere
posizione a favore della programmazione parallela
e contro i programmatori vecchio stile
(come lo sono anch'io, d'altronde..)
 
ciao
luca
 
 
 


 
Che vuol dire in tutti i programmi?
Mi sembra un'affermazione troppo lapidaria per essere presa sul serio.
 


 
Rileggiti quello che ho scritto, io parlavo di efficienza.

 componenti non siano slegate tra loro.
 
Algoritmi di sorting paralleli.
E` uno dei casi peggiori, dato che esiste
una dipendenza locale e globale tra dati
Eppure sono stati sviluppati, perche`, sempre
quelli del DARPA, ne avevano necessita`.
 
In questo link c'e` un esempio interessante:
 
https://computing.llnl.gov/tutorials/parallel_comp/
 
 
Il calcolo di PI in parallelo, cosa apparentemente
difficile, data la dipendenza tra dati.
Tra l'altro la parallelizzazione degli algoritmi a
volte ha soluzioni piuttosto originali...
 
Sono anni che si cercano soluzioni parallele a
tutti gli algoritmi che si conoscono, con vari
risultati, ma di sicuro al di sopra di quanto
uno non possa immaginare.
Come scrivevo prima, l'uso mono-task del PC ha
mascherato tutto quello che e` stato fatto in
ambito di parallel processing.
 
bye,
 
-- 
 
piergiorgio

 Mi sembra un'affermazione troppo lapidaria per essere presa sul serio.
 
Sono anni che vengono sviluppati algoritmi
paralleli per tutti gli scopi possibili
immaginabili.
Come scrivevo nell'altro post, i computer
paralleli erano solo un prodotto per gente
come il DARPA.
Questi hanno spinto lo sviluppo di algoritmi
paralleli, ovviamente.
 
Adesso, pero`, i computer paralleli sono
disponibili un po' per tutti, quindi e`
immaginabile che gli algoritmi di cui sopra
possano essere usati anche in applicazioni
consumer.
 
bye,
 
-- 
 
piergiorgio

 Quali sarebbero le cose interessanti e originali di AmigaOS?
 
Con gli occhi di adesso, nulla.

 volte ha soluzioni piuttosto originali...
 
Una tipica applicazione che non deve mai mancare sul PC, ma dai! :P

 Una tipica applicazione che non deve mai mancare sul PC, ma dai! :P
 
Tu hai chiesto di un problema "non slegato".
L'esempio dimostra (e ve ne sono molti altri),
come un problema apparentemente difficile da
trattare si possa rendere i parallelo.
Fai le dovute proporzioni e vedi come il
problema della "legatura" non sia proprio
cosi` grave come dici tu.
 
bye,
 
-- 
 
piergiorgio

 Rileggiti quello che ho scritto, io parlavo di efficienza.
 
julia e go sono già più veloci del C in diversi casi
 
e certamente negli ambiti in cui il calcolo parallelo e distribuito 
non sono un'opzione, ma una necessita imprescindibile, i vecchi 
linguaggi possono sopravvivere solo con modifiche che facilitino la 
programmazione parallela
 
-- 
bye
!(!1|1)
 
 

 for (i=1; i<100000000; ++i) nheads+=rand();
 
sono anni che non programmo più a livello professionale e non sono 
molto aggiornato rispetto all'evoluzione dei linguaggi classici
 
ma direi che è già un enorme passo avanti rispetto ai miei tempi 
quando per fare una cosa del genere dovevi scrivere 20-30 righe di 
codice usando le API di basso livello del s.o.
 
non ci sono più alibi per non usare il calcolo parallelo
-- 
bye
!(!1|1)
 
 

 Quando i processori erano da un megaherz aveva senso.
 
figuriamoci
c'è il calcolo distribuito dove i programmi sono divisi tra più 
macchine perché non esistono processori con sufficiente numero di core
 
il problema è che tu non sei in grado di vedere più in la del DOS e di 
PONG
 
certamente per chi usa il PC solo come macchina da scrivere potrebbe 
bastare anche un pentium 1, ma anche solo per navigare su internet un 
4 core a volte fa comodo
 
per esempio c'è il sito ebay di un rivenditore cinese di componenti 
elettronici che mi inchioda il PC se apro più di 3 schede con un dual core
 
probabilmente è colpa di quella monnezza di flash, ma questo comunque 
dimostra che anche per le cose più banali un maggior numero di core 
può fare la differenza
 
ma del resto non mi sembra che conversione/editing audio/video siano 
applicazioni così di nicchia
 
e sono applicazioni che vengono completate nella metà del tempo se si 
raddoppia il numero dei core (e i test dimostrano come questo si 
traduca anche in un risparmio energetico)
 
-- 
bye
!(!1|1)
 
 
 

 Tu hai chiesto di un problema "non slegato".
 
Peccato che l'articolo l'ho letto, e afferma chiaramente che i risultati 
si ottengono dove i calcoli sono slegati. Magari leggitelo meglio anche tu.
 
Ribadisco ancora una volta, l'utilizzo di queste tecniche e' buona cosa 
laddove applicabile, ma parliamo di ambiti particolari, mentre cercare 
di applicarlo anche dove e' evidente che non c'e' alcun vantaggio e' 
solo per testardaggine o stupidita'.  E fin qua la cosa mi interessa 
relativamente, non mi piace vedere illudere la gente con fumo negli 
occhi, a che pro? Per il marketing?

 parallela
 
Un linguaggio puo' soltanto integrare quelle che sono prerogative di un 
sistema operativo, non certo sostituirsi ad esso nella loro gestione, 
quando questo succede i risultati non sono certo ottimali.

 elettronici che mi inchioda il PC se apro più di 3 schede con un dual core
 
Ah ecco dove perdi il tuo tempo, ora si spiegano alcune cose.
Buon shopping di cinesate col quad core. :-)


 
-- 
bye
!(!1|1)
 


 
Osservando la media, cosa piu' corretta, si vede Julia che e' quasi il 
doppio piu'lento (1.765), Go invece quasi 5 (4.68).
 
Ma ci si potrebbe chiedere che razza di valenza abbiano questi test 
effettuati in single threading e single core, per valutare le 
prestazioni di un linguaggio orientato al multi threading e multi core.
La spiegazione potrebbe essere che e' un buon esempio delle tue perle.

 La spiegazione potrebbe essere che e' un buon esempio delle tue perle.
 
a parte che si tratta di linguaggi che devono ancora maturare 
(basterebbe fare il confronto tra le prestazioni delle prime versioni 
di java e quelle attuali) l'efficienza di un linguaggio può essere 
intesa in molti modi, non solo come esecuzione, ma anche come 
semplicità di scrittura del codice, come facilità di scrivere codice 
sicuro (per esempio rispetto ai noti problemi della sovrascrittura dei 
buffer del C, dei pointer non inizializzati, ecc.), ecc...
 
e questo comunque non dimostra affatto che un processore dual core è 
più performante di un processore a più core come sostieni tu
 
questo può al massimo valere per chi usa il PC solo per scrivere testi 
semplici di poche pagine, ma perfino per navigare in internet, in 
molti siti, avere più core può essere vantaggioso
 
solo per programmi veramente banali non ha senso preoccuparsi del 
multithreading, ma più che programmi direi script bash o di shell 
veramente semplici
 
e perfino riguardo i semplici script, quando usavo OS/2 avevo uno 
script REXX che mi leggeva i link (che salvavo di giorno in giorno in 
una cartella) e mi scaricava in parallelo da una decina di siti 
diversi i testi html, immagini, ecc., me li riformattava cancellando 
pubblicità e informazioni che non mi interessavano e me li salvava in 
cartelle differenti...
 
e il tempo di esecuzione, perfino con un pentium mono-core era di gran 
lunga inferiore a quello di esecuzione sequenziale visto che mentre un 
processo era occupato ad aspettare dati da internet gli altri 
lavoravano elaborando i dati scaricati in precedenza
 
ma il problema principale è che sei mono-thread e non sei in grado di 
guardare più in la del thread che stai lentamente elaborando :-D
-- 
bye
!(!1|1)
 
 

 elaborando i dati scaricati in precedenza
 
Confondi multithreading con multitasking, aggrappandoti alle limitazioni 
di un linguaggio di script.
Limitazioni che non esistono utilizzando un qualunque linguaggio in 
grado di sfruttare l'I/O asincrono presente nei vari OS ormai da 
svariati lustri.

 CPU, e' pura idiozia.
 
con il calcolo parallelo il processore invece di girarsi i pollici 
aspettando l'input, elabora i dati già acquisiti mentre un altro 
thread/processo acquisisce altri dati
 
la dimostrazione è che lo stesso script, per quanto banale, eseguito 
sequenzialmente impiegava un tempo molto superiore
 
all'epoca avevo una connessione internet a tempo e la maggiore 
velocità non era certo un'opinione, ma un fatto misurato con appositi 
benchmark
 
ma quanto scrivevo era volto soprattutto ad evidenziare quanto fosse 
fondamentale "pensare parallelo"... anche con semplici script
 
e quanto hai risposto dimostra ancora una volta quanto, fossilizzato 
nelle tue ridicole convinzioni, sei legato al calcolo sequenziale
 
dai... esci dalla tana... supera il tuo stadio di australopiteco... :-D
 
P.S. "stai sereno" a differenza di te conosco bene la differenza tra 
multithreading e multitasking
di quanto differisca l'efficienza e le risorse allocate per avviare o 
schedulare tra un nuovo thread e un nuovo processo dipende 
essenzialmente dall'architettura del sistema operativo
 
ma in entrambi i casi - a meno che architettura del sistema operativo 
e del processore non siano dei cessi - maggiore è il numero dei core, 
maggiore è la velocità di esecuzione
 
poi se tieni il pc spento uso comodino, hai ragione, non c'è 
differenza di efficienza tra un mono-core e un mille-mila-core :-D
-- 
bye
!(!1|1)
 
 

 maggiore è la velocità di esecuzione
 
Solo quando l'elaborazione si puo' dividere in piu' thread con un buon 
grado di indipendenza (quindi pochi casi), la sincronizzazione genera 
sempre overhead e il limite e' dato appunto da questa.
 
Tu fai esempi sbagliati, come quello dell'I/O, per confondere le cose, 
ma chi ha un single core puo' lanciare una copia e fare altre cose e i 
tempi sono gli stessi che su un multi core, solo il *tuo* PC ha questi 
problemi.
E che dire allora di IOCP vs epool?  Non e' forse un buon esempio di 
quanto abbondare coi thread sia sconveniente?

 
http://arstechnica.com/business/2011/11/bulldozer-server-benchmarks-are-
 
here-and-theyre-a-catastrophe/1/
 
hai segnalato questo articolo a nvidia ? insistono a vendere schede 
grafiche con decinaia di core, fermali.

 grafiche con decinaia di core, fermali.
 
Non c'entra nulla con l'articolo in questione.
Anzi, il fatto che (giustamente) molte delle operazioni 3D vengano 
gestite localmente nella scheda video rende ancor piu' superflua 
l'esigenza di un maggior numero di core nella CPU.

 riguarda l'utilita' di avere piu' di due core.
 
il caso citato era volto a dimostrare come "pensare in parallelo" 
comportasse vantaggi sensibili anche ai tempi dei processori monocore
 
ma ormai i software che fanno largo uso di elaborazione parallela sono 
numerosi (criptazione, compressione, conversione multimediale, 
elaborazione immagini, ecc.) e non mi sembra siano così di nicchia 
come sostieni tu
 
poi se uno usa il PC solo per giocare al solitario (come fanno molti 
anziani) può benissimo usare un pentium 1...
-- 
bye
!(!1|1)
 
 
 

 poi se uno usa il PC solo per giocare al solitario
 
Meglio che fare script in Rexx.

 Meglio che fare script in Rexx.
 
fai di tutto per mostrare la tua incompetenza?
 
secondo te avrei dovuto usare l'assembler per una cosa del genere?
 
ogni linguaggio ha la sua ragione di essere
 
come ho già scritto, lo script in questione aveva lo scopo di 
modificare, eliminando parti e riformattando in uno stile uniforme 
pagine scaricate da diversi siti web
 
visto che i siti cambiano spesso la formattazione e visto che 
aggiungevo spesso nuovi siti, lo script (ora in python) viene 
modificato abbastanza spesso ed è molto più comodo fare una cosa del 
genere con linguaggi che rendono più facile la gestione del testo e si 
occupano automaticamente della gestione della memoria
 
il REXX poi era perfettamente integrato con OS/2 e dotato di librerie 
che si interfacciavano direttamente a diverse API
 
poi ovviamente per programmi e librerie che vendevo o che ho reso 
disponibile come open source ho usato C, dove strettamente necessario 
assembler e quasi sempre ho fatto ricorso direttamente alle API del 
sistema operativo per avere programmi più veloci, compatti e che 
usavano meno memoria
 
chiaramente sono cose che uno come te, tutte teorie strampalate, ma 
nessuna esperienza pratica, difficilmente può capire
--
bye
!(!1|1)
 
 

 nessuna esperienza pratica, difficilmente può capire
 
Tu non mi conosci, al contrario di quello che pensi io accetto qualunque 
critica, specie se viene da un programmatorino che si diletta in Rexx e 
Python, mi fa bene all'umore. :-)

 One reason
 
Azz...
 
http://highscalability.com/blog/2014/12/31/linus-the-whole-parallel-computing-is-the-future-is-a-bunch.html
 


Simpatica la prima risposta:
<<In other words: "4 cores should be enough for anybody">> ;-))
 
Cmq per quanto riguarda il discorso "commerciale" sono d'accordo con Linus.
 
 
-- 
 
Bob
 
http://www.webalice.it/argonex/
 

 Cmq per quanto riguarda il discorso "commerciale" sono d'accordo con Linus.
 
Il problema e`, come sempre, quanto si
vuole scalare (in alto) sulle prestazioni.
 
E` evidentemente chiaro che non e` piu`
possibile farlo senza aumentare i core.
 
Ora, ovviamente, uno puo` pensare che
un paio di core siano sufficienti per
un uso *normale*.
Ma cos'e` un uso normale?
Com'e` che gli smartphone continuano
ad aumentare i core?
Possibile che Facebook richieda 8 core?
 
Ovviamente no, ma quando si vuole (deve?)
far girare l'ultimo software di navigazione
con mappe 3D foto-realistiche e, in parallelo,
giocare ad Half-Life 5, mentre si twitta e
si chatta in FB, allora un single core non
basta piu`.
Sicuramente neanche per i consumi.
 
bye,
 
-- 
 
piergiorgio

 ad aumentare i core?
 
Perche' farlo e' semplice, poco costoso, non da vantaggi ma chi se ne 
frega, l'importante e' che fa vendere di piu', quindi e' perfetto per il 
marketing.
 
Attualmente su smartphone e tablet il numero di core effettivamente 
utilizzati e' due (tranne rare applicazioni).
Nell'utilizzo pratico, non c'e' differenza tra uno smartphone dual core 
e un quad.
 
Magari riguarda in particolare quelli basati sul lavoro di Linus
Torvalds, che sulla questione ha idee piu' estremiste delle mie:
 
The whole "let's parallelize" thing is a huge waste of everybody's time!

 The whole "let's parallelize" thing is a huge waste of everybody's time!
 
E qui si sbaglia.
 
Perche` se io scrivo un applicativo parallelo,
gia` sapendo che in futuro non aumentera` il
clock, ma il numero di core, mi sono assicurato
scalabilita` verso l'alto.
E no, l'aumento di cache non aumenta le prestazioni.
 
D'altro canto, nonostante quello che dice Torvalds,
il kernel di Linux e` multi-thread.
Il *kernel*, bada bene.
 
Il motivo qual'e`? Esattamente quello che ho scritto
qui sopra, cioe` che scala verso l'alto.
 
E di esempi pratici ne ho parecchi, perche` se hai
un RAID SW + LUKS, hai gia` almeno due thread in
kernel per leggere e scrivere i dati.
 
Quindi, per poter fare qualcosa, servono almeno 3 core,
in quella situazione.
 
E questa non e` una situazione da server.
 
Se avessero fatto il kernel single thread, si sarebbe
avuto un collo di bottiglia che avrebbe *limitato*
le prestazioni. Piu` tutti i problemi di abuso di cache.
 
Quindi, per concludere, il discorso parallelo e`
proprio per assicurarsi di avere un sistema che
funzioni decentemente in condizioni differenti.
 
Ed il kernel di Linux fa proprio questo.
 
bye,
 
-- 
 
piergiorgio

 in quella situazione.
 
https://lists.debian.org/debian-user/2012/03/msg01154.html
 
 


Quindi, la conclusione e` che il multi-threading,
e conseguentemente il multi-core, servono...
 
Il titolo del thread, quindi, va interpretato nel
senso che la *mancanza* di multi-threading sia
un problema...
 
bye,
 
-- 
 
piergiorgio

 e conseguentemente il multi-core, servono...
 
Il multi-threading serve sicuramente, il multicore un po' meno, il 
volerli applicare a sproposito e' stupido.
 
In molti casi il multi-threading si usa per comodita' di gestione, 
piuttosto che per parallelizzare processi che di fatto sono asincroni.
 
Riguardo all'esempio crittografico che citavi, basta osservare come 
questo problema viene risolto dove serve, tramite hardware dedicato, non 
aggiungendo core.

 The whole "let's parallelize" thing is a huge waste of everybody's time!
 
riguardo le opinioni di certi personaggi basterebbe ricordare:
 
T.Watson, fondatore di IBM, diceva che mai ci sarebbe stato bisogno di 
più di 5 computer
 
B. Gates, mai stato bisogno di più di 1MB di ram
 
Metcalfe (fondatore della 3Com e coinventore dello standard ethernet) 
prevedeva il collasso di internet nel '96
 
con la differenza che quelle erano *previsioni* sbagliate mentre 
questa è una visione sbagliata del presente, forse è più una questione 
psicologica, un imprinting dovuto alla natura originaria di linux (i 
thread sono una introduzione relativamente recente) monolitica e 
monthread piuttosto che modulare e multithread
 
chi ha avuto occasione di provarli, potrebbe ricordare come le 
interfacce di sistemi progettati per il multithreading e il 
multitasking, quali OS/2 (a parte problemi delle prime versioni 
riguardo la SIQ) e ancor più BeOS, restassero sempre pronti alle 
interazioni con l'utente a differenza di windows (ma le mie esperienze 
non sono recenti) e ancora oggi linux che si bloccano completamente 
quando più processi accedono pesantemente al disco
 
del resto all'opinione di Torvalds è contrapposta quella contraria di 
migliaia di programmatori sconosciuti e magari anche più in gamba,
architetturalmente linux - come kernel - non aveva un cazzo di 
avanzato rispetto ad altre architetture dell'epoca
 
ma L.Torwald ha un ego della grandezza dei vari Jobs, Gates & c., ed 
esattamente come loro non è né un genio né tantomeno un messia, ma le 
persone comuni sono affascinate dai narcisisti (anche in politica con 
effetti ancor più deleteri)
 
e a parte l'ego di Linus, i fatti nudi e crudi sono:
1) non ci sono in vista - a parte esperimenti di laboratorio su 
singoli transistor, non scalabili su chip con miliardi di porte 
logiche e ancor meno trasferibili su scala commerciale - soluzioni che 
permettano di incrementare la velocità dei processori, quindi l'unico 
miglioramento delle prestazioni può venire dall'incremento del numero 
di core (e semmai è molto più vicino alla diffusione commerciale il 
cambiamento architetturale in questo senso con i memristor)
2) perfino il cervello di un insetto è in grado di svolgere alcuni 
calcoli ad una velocità superiore a quella di un PC pur lavorando ad 
una velocità centinaia di migliaia di volte inferiore
 
alla luce di questi fatti, sostenere che "parallelizzare è uno spreco 
di tempo" fa impallidire tutte le cazzate di Watson, Gates & c.
 
-- 
bye
!(!1|1)
 
 
 

quando più processi accedono pesantemente al disco
 
Questa è una cosa che fa abbastanza incazzare.
Pochi giorni fa, durante delle operazioni sugli snapshot di Vmware
Workstation, ci sono rimasto male da quanto l'interfaccia grafica
avesse perso capacità di rispondere (quella testuale andava un po'
meglio).
In particolare ci sono rimasto male perché c'era un SSD: con un disco
normale sarei potuto andare a fare un giro in bici.
 
 
-- 
Ci sono 10 tipi di persone al mondo: quelle che capiscono il sistema binario
e quelle che non lo capiscono.

 non aggiungendo core.
 
ROTFL
l'hardware dedicato non è altro che un processore in più riservato ad 
un compito specifico quindi ancora una volta ti smentisci da solo
 
-- 
bye
!(!1|1)
 

 velocità centinaia di migliaia di volte inferiore
 
Oltre a non c'entrare un cazzo, questo e' palesemente falso.

 compito specifico
 
Che e' cosa ben diversa da un core in piu' riservato a compiti generici.

 normale sarei potuto andare a fare un giro in bici.
 
pensa cosa succedeva quando c'erano i floppy e con window o linux il 
computer per 2 minuti era inutilizzabile... e non si trattava di 
macchine virtuali
 
-- 
bye
!(!1|1)
 

 avesse perso capacità di rispondere
 
Questo problema e' da imputare all'eccessivo I/O su disco richiesto, in 
particolare dall'interfaccia grafica, non c'entra nulla con l'argomento 
in discussione.
A parita' di interfaccia grafica, un sistema multi-threading/multi-core 
si comporterebbe allo stesso modo.
Le vecchie distribuzioni su 486 (mono-core!) si comportavano meglio, 
solto perche' l'I/O era modesto.

 computer per 2 minuti era inutilizzabile...
 
Succedeva solo nella tua testa


hai idea dei calcoli di fisica che inconsciamente fa il cervello della 
mantide?
sicuramente no, ma chi studia l'intelligenza artificiale prende sul 
serio certe questioni, come molti altri problemi complessi risolti 
anche dai sistemi biologici più semplici, ma difficili invece da 
risolvere con i computer
-- 
bye
!(!1|1)
 

 Che e' cosa ben diversa da un core in piu' riservato a compiti generici.
 
certamente è differente da un core generico, ma sostanzialmente 
smentisce quanto sostieni tu: il fatto che avere più unità di calcolo 
che lavorino in parallelo sia inutile
 
rassegnati, l'unico velo pietoso da stendere è sulla tua patologica 
ignoranza
 
-- 
bye
!(!1|1)
 
 
 

 solto perche' l'I/O era modesto.
 
un ulteriore conferma della tua patologica incompetenza
 
dipende essenzialmente da come è progettato lo scheduler del sistema 
operativo e di come cambia dinamicamente la priorità dei vari processi
 
e al contrario di quanto affermi tu i dischi e i processori lenti di 
una volta esasperavano il problema (e chi non ha la memoria di un 
pesce rosso, come te, può ben ricordarlo)
 
con linux il problema viene attenuato usando kernel che usano un altro 
scheduler (ora non ricordo il nome)
 
ma ho citato la questione riguardo l'arretratezza di fondo del kernel 
linux
non c'è relazione diretta con il multithreading (anche se avere un 
interfaccia grafica multithreaded aiuta)
-- 
bye
!(!1|1)
 

 ignoranza
 
Aspetto ansioso le prossime perle di saggezza :-)

 serio certe questioni
 
Questa si che e' una bella notizia, se hai delle chicche da sparare 
anche su questo argomento, accomodati, io intanto preparo i popcorn...

 ma ho citato la questione riguardo l'arretratezza di fondo del kernel linux
 
Secondo te un kernel moderno qual'e'? Lunaris?

macchine virtuali
 
Questo lo so, mi capita ancora saltuariamente di usare un floppy.
E' che con un SSD la cosa fa venire il nervoso.


in discussione.
 
No, l'I/O richiesto non viene dall'interfaccia grafica.
Il problema è che l'interfaccia grafica viene affogata dall'I/O.
 
Sarebbe bello che l'interfaccia avesse priorità: mi va bene rallentare
l'I/O, però non farmi aspettare tre secondi per mettere una finestra
in primo piano.


 per i thread e' necessario uno stack di sistema separato.
 
ROTFL
infatti esiste solo lo stack... :-D
lo avevo dato per scontato... vorrei vedere che cazzo potrebbe fare un 
thread senza poter dichiarare variabili locali o funzioni
 
e pensare che una volta perdevo perfino tempo a scrivere e a 
paragonare le prestazioni di differenti algoritmi di allocazione di 
memoria...
 
ma in sintesi secondo te thread e processi sono identici
 
allora i sistemi operativi moderni, chi dall'inizio, chi dopo anni,
hanno implementato il threading solo per capriccio...
piuttosto avrebbero dovuto assumerti come consulente :-D
 
non è che sei un masochista e godi a fare certe figuracce?
 
e continua pure a insultarmi come hai fatto negli altri messaggi...
del resto tu stesso hai scritto:
"Di solito chi ha argomenti non ha bisogno di denigrare..." :-D
 
-- 
bye
!(!1|1)
 
 
 

 ma in sintesi secondo te thread e processi sono identici
 
Tu guardi sempre il dito e non la luna eh!
Non sono la stessa cosa, ma sono identici dal punto di vista delle 
prestazioni.

 Il problema è che l'interfaccia grafica viene affogata dall'I/O.
 
Normalmente l'interfaccia grafica non risente dell'I/O (intendo quello 
su disco), se ad esempio stai effettuando un backup, in teoria 
l'interfaccia dovrebbe rispondere velocemente come quando il sistema e' 
idle.  Nella realta' questo non avviene, l'interfaccia rallenta a causa 
delle operazioni di I/O su disco effettuate dalla stessa interfaccia 
grafica.
Il problema e' che mescolare le due operazioni su disco e' deleterio per 
le prestazioni, a conti fatti si traduce in un bel po' di overhead in piu'.
Una situazione con effetti simili si verifica quando si effettuano delle 
copie contemporaneamente, se ad esempio hai due grossi file che 
impiegano un minuto ciascuno per essere copiati, copiandoli insieme 
impiegheranno due minuti, ma se lanci la copia del primo e poi 
successivamente quella dell'altro (come processo separato con la stessa 
priorita') il tempo totale sara' ben maggiore.

le prestazioni, a conti fatti si traduce in un bel po' di overhead in piu'.
 
Perņ, visto che capita, l'interfaccia dovrebbe avere la prioritą.
Tanto non č che debba muovere chissą quanti dati, non dovrebbe
rallentare di molto il grande movimento.


 rallentare di molto il grande movimento.
 
Su questo sono d'accordo, ma il punto e' che non ha niente a che vedere 
con l'argomento in discussione.  Su di un sistema ad elevato 
parallelismo, con abbondanda di core, la situazione non cambierebbe.
Piuttosto bisognerebbe cercare di diminuire il ricorso all'I/O e/o 
tamponare con meccanismi di cache, se non separare fisicamenti i supporti.


 
A process is a "heavyweight" unit of kernel scheduling. Processes own 
resources allocated by the operating system. Resources include memory, 
file handles, sockets, device handles, and windows. Processes do not 
share address spaces or file resources except through explicit methods 
such as inheriting file handles or shared memory segments, or mapping 
the same file in a shared way.
[...]
A kernel thread is a "lightweight" unit of kernel scheduling. At least 
one kernel thread exists within each process. If multiple kernel 
threads can exist within a process, then they share the same memory 
and file resources.
 
e io avevo scritto letteralmente:
"sia pure con variazioni dipendenti dalle diverse implementazioni, in 
generale un thread richiede meno risorse di un processo separato e 
permette una condivisione di risorse comuni (con gli altri thread) più 
efficiente della condivisione tra processi"
 
certo se postassi le tue perle (riguardo gli scheduler, riguardo la 
gestione dell' I/O, ecc.) nei newsgroup adatti ci sarebbe da farsi 
delle belle risate
 
-- 
bye
!(!1|1)
 
 
 
 

 efficiente della condivisione tra processi"
 
Dove il "sia pure con variazioni dipendenti dalle diverse 
implementazioni" comprende anche il caso in cui la differenza potrebbe 
non essere apprezzabile.
A parte questo, non hai argomentato il motivo per cui il passaggio 
inter-thread dovrebbe essere piu' efficiente.

 un altro thread.
 
ROTFL
"Di fatto un thread non puo' accedere alla memoria di un altro thread"???
:-D :-D :-D :-D :-D
 
di fatto... uno tsunami di cazzate
 
poi... sembra una canzone di Branduardi:
il processo dà il permesso al thread, il processore dà il permesso al 
processo, il PC dà il permesso al processore e acc dà il permesso al 
PC... :-D
 
sicuramente wikipedia accetterà le correzioni di un genio informatico 
della tua portata
 
discutine con loro, o se preferisci continua a discuterne con te stesso...
tanto rispondi a cose che non ho mai scritto...
puoi benissimo continuare da solo :-D
 
-- 
bye
!(!1|1)
 
 
 
 
 
 
 
 
 

 scriverla in un altro (con gli opportuni meccanismi di sincronizzazione)
 
Significa solo che sei un idiota che non ha mai scritto una riga di 
codice.  Torna ai tuoi scriptini e a leggere articoli sulle cavallette 
tachioniche.

 tirati in ballo tu.
 
Veramente OS/2 gestisce il multithreading e molteplici core da prima
che fossero sdoganati nei sistemi x86... 
 
giusto per precisare

 giusto per precisare
 
Per dirla tutta sono cose che esistevano ben prima di OS/2.
Poi sarebbe interessante conoscere quali multi core gestiva OS/2, forse 
i 486 Duo? :P

>>>> 
http://www.ecomstation.it/pido2/
 :)<<<<<
.............................. [ -=- ] ..............................

 PPC
 
Quindi si parla sempre di una quota di mercato irrilevante.

 Quindi si parla sempre di una quota di mercato irrilevante.
 
dipende.... se vogliamo parlare di quote di mercato in effetti è una
quota molto bassa  
ma è sempre un valore che per qualcuno produce ancora dei profitti
 
non era comunque questo l' argomento di discussione dato che si
parlava degli aspetti tecnici

 ma � sempre un valore che per qualcuno produce ancora dei profitti
 
Ho precisato svariate volte che l'argomento in discussione riguarda 
l'utilizzo piu' diffuso, e non casi particolari (meno diffusi) dove 
invece valgono i criteri opposti.
Ma ogni volta arrivano interventi del tipo "si ma nel caso particolare 
che..."
Comunque, tu ti sei spinto fino agli OS/2 su multicore, che e' una mosca 
bianca con un occhio verde e uno azzurro.
Vediamo se qualcuno osa rilanciare.

 Vediamo se qualcuno osa rilanciare.
 
Boh ... ho perso i primi messaggi dell' argomento, non sono più sul
server ;-)

server ;-)
 
Qui ci sono tutti:
 
https://groups.google.com/forum/#!searchin/it.comp.hardware/$20Multithreading$20e$20multicore$2C|sort:relevance/it.comp.hardware/nH6jtTu6S-Y/Mv2JdX1OTvoJ
 
 
o
 
https://goo.gl/lmfzsZ
 
 
 
 
 
-- 
ciao
  Stefano

 
https://goo.gl/lmfzsZ
 
 
 
Sì vabbè.. ma quelle sono le puntate dell'altra stagione ;-)
 
 
-- 
 
Bob
 
http://www.webalice.it/argonex/
 

Sì vabbè.. ma quelle sono le puntate dell'altra stagione ;-)
 
Beh, il thread inizia il 14/2 e ci sono diversi rami, bisogna vedere a cosa si
riferisce Ermet€@pc00, lui ci ha scritto solo dal 12/5.
 
 
-- 
ciao
  Stefano