Newsgroup: it.comp.hardware.cpu
Titolo: Come fa l' i5 750 a prendersele dal Phenom II X3 710 ??

O_o
http://www.phoronix.com/scan.php?page=article&item=intel_lynnfield&num=6
tutta la review mostra come il pii x3 a volte la sa lunga sugli i5 :S
-- 
SimBus82.net coming soon - 
http://www.simbus82.net
Blog allenamento - 
http://simbus82-workout.blogspot.com/
 

 
Quasi quasi mi faccio un x3 al posto dell'i5

 tutta la review mostra come il pii x3 a volte la sa lunga sugli i5 :S
Mah! Qualche *grossa* magagna a livello di kernel?
Perché su windows le cose vanno in modo *enormemente* diverso:
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=3634&p=1
Inoltre, il fatto stesso che i test phoronix a volte favoriscano l'i5
sull'i7, e pure molto, fa ridere i polli.
-- 
Bye, Lem
Ceterum censeo ISLAM esse delendum
____________________________________________________________________________
Non sprecare i cicli idle della tua CPU: 
http://boinc.berkeley.edu/index.php

 sull'i7, e pure molto, fa ridere i polli.
Effettivamente...

 sull'i7, e pure molto, fa ridere i polli.
resta il fatto che come phoronix è più autorevole della somma di tutti i 
siti benchmark più famosi foraggiati dalla case produttrici.....


 siti benchmark più famosi foraggiati dalla case produttrici.....
L'autorevolezza in sé e' relativa.
La forza di Phoronix, IMHO, e' che loro pubblicano TUTTA LA SUITE usata 
per il benchmark, compreso il codice. Si puo' riprodurre TUTTO il test 
al 100% bit per bit, verificare i sorgenti del software di test, e 
confutare i loro risultati, esattamente come si fa nel mondo scientifico 
quando si fa un esperimento. Le chiacchiere stanno a zero.
Questa e' la loro forza, e NESSUN altro sito di benchmark lo fa. Con gli 
altri ci si deve fidare della loro buona fede e di quella di chi 
fornisce i vari software closed.
-- 
BArrYZ

 sull'i7, e pure molto, fa ridere i polli.
Scusa eh, ma se fa "ridere i polli", perche' nessuno ha ancora 
pubblicato dei test usando la stessa metodologia contraddicendo quei 
risultati?
Io non ho visto ancora nessuno dire che la Phoronix test suite sia 
inaffidabile. Sono software di largo uso e quasi tutti opensource, 
chiunque puo' controllare il codice della suite e dei software usati per 
i test, e/o provare la suite sulle proprie macchine per confutare quei 
risultati.
Ma siccome nessuno lo ha ancora fatto, evidentemente tanto ridere i 
polli, non fa.
Soprattutto e' una suite estremamente "tecnica" e seria perche' misura 
veramente di tutto e di piu', e non solo come gira il Cinebench o altre 
stronzate del genere (chi cazzo lo usa Cinema 4D in ambito produttivo?). 
guarda tu stesso che livello di test ci stanno e dimmi se fa "ridere i 
polli":
super-pi
ramspeed
universe
multicore
compress-7zip
memory-bandwidth
iozone
disk
audio-encoding
encode-mp3
byte
lightsmark
universe-cli
build-apache
memory
ffmpeg
sqlite
nexuiz
scimark2
openssl
compliance-acpi
build-linux-kernel
compress-gzip
encode-flac
gtkperf
glmark
compilation
compliance-sensors
encode-ogg
tandem-xml
video-cpu-usage
computational
openarena
linux-system
compliance-ogl
x11perf
hdparm-read
mencoder
encode-wavpack
ut2004-demo
build-imagemagick
filesystem
graphics-magick
unigine
qgears2
java
unigine-tropics
tremulous
livecd
stresscpu2
video-extensions
sunflow
opengl-demos
specviewperf9
urbanterror
fio
bork
video-encoding
build-php
compression
system-memory
fgl-glxgears
netbook
java-scimark2
cryptography
apache
build-mplayer
c-ray
render-bench
et
gui-toolkits
encode-ape
unigine-sanctuary
xplane9
gnupg
ioquake3-games
compress-pbzip2
universe-x
x-testing
gaming
padman
encoding
bonnie
espeak
custom
etqw-demo
gaming-free
pcqs-processor
database
warsow
doom3
norsetto-shadow
wine-graphics
system-compliance
cachebench
j2dbench
tiobench
compress-lzma
system-disk
specviewperf10
Si spazia da applicativi server, database, compilazioni, multicore, 
dischi, fino ad arrivare ai giochi agli encoding e alle compressioni, 
con tutte applicazioni di larghissimo utilizzo.
A me non pare proprio faccia "ridere i polli".
-- 
BArrYZ

 benchmark piï¿œ famosi foraggiati dalla case produttrici.....
Ah ho capito...quindi solo Phoronix ï¿œ nel giusto, gli altri siti son 
tutti delle merdaccie al soldo di Intel, giusto? :)

 ha scritto nel messaggio 
news:mn.53bf7d999...@alientech.it...

nn dico questo (anche se molti bench sono EVIDENTEMENTE di parte)... cmq di 
sicuro ci saranno problemi magari perche linux nn riconosce propriamente 
queste cpu che sono nuove di stecca...


BS82 ha spiegato il 10/09/09 :

Ecco, forse hai centrato il problema...:D

 tutti delle merdaccie al soldo di Intel, giusto? :)
La differenza sostanziale e' che Phoronix sviluppa, distribuisce e usa, 
una suite al 100% open, quindi perfettamente verificabile da chiunque.
Per vedere se ci sono trucchi nel software che usa, non ti devi fidare 
di loro, puoi controllare tu stesso o chiunque altro, e fare a tua volta 
dei test con quella suite per verificare se si inventano i risultati.
IMHO la differenza e' abissale.
-- 
BArrYZ

 Ecco, forse hai centrato il problema...:D
Questo gia' e' piu' possibile, ma appunto e' verificabile da chiunque 
controllando la metodologia dei test e il software della suite, che 
ripeto e' open.
Ma da qui a dire che il test fa "ridere i polli", insomma, ce ne passa, 
IMHO.
-- 
BArrYZ

 IMHO la differenza e' abissale.
OK... quando e se avrï¿œ voglia di "cazzeggiare" li farï¿œ pure io :))

Il 10/09/09, BArrYZ ha detto :

Questo sicuramente no, anche se per fare una cosa ancora migliore 
potevano aggiungere qualche cpu in piï¿œ, tipo un PII 965, in modo da 
vedere poi le "strabilianti" prestazioni che avrebbe potuto esprimre in 
quei test... in ogni caso qualche dubbio in proposito lo posso 
ugualmente avere o ï¿œ vietato? :)

 ugualmente avere o è vietato? :)
Puoi avere tutti i dubbi che vuoi, figurati.
Anzi io dicevo appunto che e' *bene* averli, i dubbi, e non prendere 
sempre come oro colato quello che esce dai soliti siti di benchmark di 
cui cui bisogna fidarsi perche'... Lo dicono loro.
Da una parte hai una cosa che, giusta o sbagliata che sia, e' comunque 
misurabile, criticabile, verificabile tecnicamente coi sorgenti e la 
metodologia usata, dall'altra hai un AnandTech (tanto per dirne uno) che 
ti dice il suo inconfutabile sacro verbo.
Vedi tu cosa e' meglio per l'obiettivita'...
-- 
BArrYZ

 Vedi tu cosa e' meglio per l'obiettivita'...
Diciamo che per le mie esigenze (uso infatti per il 90% applicativi 
Windows) reputo piï¿œ indicativi i test degli "altri siti"...e comunque 
siccome appunto le cpu Lynnfield sono appena uscite, ï¿œ possibile che le 
cose in futuro possano cambiare anche per quanto riguarda Phoronix.

 "ampio respiro"...:)
Se uno cerca una recensione superpartes e obiettiva, molto meglio una 
colletta, che essere a libro paga di chi ti fornisce l'HW, penso. Almeno 
cosi' dice la logica.
-- 
BArrYZ

 cosi' dice la logica.
Bene... quindi ok per la colletta :D

 
Mmmmm .... io farei attenzione a sottovalutare questa suite.
Il valore di potersi controllare i test non � certo trascurabile, anche 
perch� la maggior parte dei software commerciali � ottimizzato (in 
compilazione) per Intel.
Questo significa che il codice ottenuto gira intrinsicamente meglio sui 
processori Intel.
Diversa la questione nel mondo Linux, rispetto a Windows.
Uno dei problemi che mi sono sempre posto � QUANTO siano affidabili i 
bench che fanno case di software proprietario, specialmente sapendo che 
Intel non ha mai avuto scrupolo a "corrompere" pur di ottenere risultati 
(la causa AMD Vs Intel ....).
Diciamo che al 99% degli utilizzatori i test non servono, cos� come non 
serviranno ne' gli I5 ne' gli I7. Ma la tecnica procede, e quello che 
conta, alla fine, sar� in costo complessivo del sistema.
Che, almeno per user normale, Intel ha intenzione di fare diventare 
MOLTO aggressivo (I5).
Stiamo a vedere .....
-- 
"Non ho paura degli urli dei violenti, ma del silenzio degli onesti"
Martin Luther King.

 IMHO.
Non intendevo generalizzare. Ma il primo test di questa pagina
http://www.phoronix.com/scan.php?page=article&item=intel_lynnfield&num=9
dimmi tu se non fa ridere i polli. Lì è palese che i risultati sono
pesantissimamente influenzati da come il software tratta i diversi
sistemi, non può essere altrimenti. E, se capita così evidentemente lì,
può capitare anche altrove.
Per esempio, ho letto che esiste un problema nel gestire efficacemente
i core virtuali dati dall'HT. Se il SO sballonzola continuamente i
processi da core fisico a core fisico, ciò in certi casi può comportare
pesanti rallentamenti. Linux è 'na favola a gestire i multicore, ma non
so come se la cavi coi core virtuali di ultimissima generazione. E gli i5
e gli amd non hanno l'HT, gli i7 e gli i9 sì. Giusto per buttarla lì...


 risultati?
Quale parte di "kernel" non era chiara, esattamente?


 e gli amd non hanno l'HT, gli i7 e gli i9 sì. Giusto per buttarla lì...
l'i7 750 nel test e come da modello.. non ha l'HT. i core sono 4 come i 
thread trattati.


 thread trattati.
L'i7 750 non c'è.
L'i5 750 non ha l'HT, come ho appena scritto. L'i7 870
ovviamente ce l'ha, come l'i7 920 (che, non so perché, indico sempre come
i9... bah).


 i9... bah).
errore di battitura mio ... i5 750.... -_- madò oh...


 
mhh
allora fan ridere di piï¿œ quelli di toms
succede qualcosa di simile :D

 
io ci sto
cmq valuterei un particolare
secondo me questo test di phoronix
credo faccia solo presente che
tutto questo ben di dio non lo sfruttiamo
meglio allora ripiegare su qualcosa di meno
performante e meno costoso
sia intel che amd
che il risultato non cambia poi cosï¿œ tanto

Il 10/09/09, 
powernews.libero.it
 ha detto :

Tom's e tutte le altre decine di siti allora...:P

 ovviamente ce l'ha, 
  ma con quel che costa gli
sarà venuto un infarto
(a me 2)

 sarà venuto un infarto
Va beh, l'870 non ha senso. Ma l'860 costa la metà, costa come il 920, ed
IMHO è una bella cpu.


E' sicuramente un problema nel kernel di linux, precisamente nello skeduler, 
il processo che assegna ai vari cori gli altri processi.
Infatti in linux su ogni processore inutilizzato fa girare in continuazione 
una copia dello skeduler per essere pronto a far partire un nuovo processo e 
intanto non togliere cicli ai processori utilizzati. Questo probabilmente da 
fastidio ai nuovi processori INTEL limitando il POWER MODE.
Inoltre si sa perfettamente che se lo skeduler manda due processi sullo 
stesso core fisico in HT invece di utilizzare due core fisici liberi  si ha 
una perdita del 20%-25%. E il kernel di linux (a meno di variazioni nelle 
ultime release) assegna i processi nell'ordine in cui vede i processori 
virtuali:
primo processore virtuale del primo core
secondo processore virtuale del primo core
primo processore virtuale del secondo core
ecc..
L'algoritmo furbo da utilizzare per uno skeduler per i nuovi processori 
INTEL � il seguente:
Se il proccesso ha un grosso runtime (passa molto tempo a calcolare) 
utilizza un nuovo core fisico se disponibile in modo da non utilizzare l'HT 
e rallentare gli altri processi.
Se il processo ha un piccolo runtime (passa molto tempo in attesa) mandalo 
in HT con altri processi simili su un core fisico gi� utilizzato in modo da 
tenere i core rimanenti parcheggiati e poter utilizzare il TURBO MODE in 
maniera ottimale.
Naturalmente questo deve essere fatto runtime in maniera da riorganizzare i 
processi in ogni momento in maniera ottimale. In Windows 7 questo viene 
fatto dal nuovo skeduler mentre in Linux a quanto so si cerca di distribuire 
in modo equo i processi sui vari processori virtuali che � la soluzione 
migliore con gli AMD e i vecchi quad INTEL. 

 skeduler [...]
Grazie. :)


 
Direi che l'open source, in questo caso, ï¿œ il requisito minimo per
passare il limite della decenza.

 processori virtuali
Sai male: a meno di disabilitarli esplicitamente dalla configurazione del
kernel, sia il supporto per l'HyperThreading che quello per il multi-core
sono abilitati di default. La cosa che non gestisce bene e' il Turbo Mode,
che infatti in questi test e' stato disabilitato.
Riguardo al test in questione, c'e' da considerare che quasi tutti i test
sono single-thread: per questo ci sono dei risultati che paiono alquanto
"bizzarri". In tutti quelli multi-thread si vede la supremazia di Intel.
Ciao!
  Luca

 alquanto "bizzarri".
Spiegheresti, per cortesia, l'enorme superiorità dell'i5 sugli i7 nel test
che ho segnalato specificamente in altro articolo del filone?
Nessuno nega che il supporto per l'HT nel kernel ci sia. Si ipotizza che
non funzioni al meglio, specie magari colle *nuove* cpu, che fra parentesi
sono *sia* multicore, e pesantemente, *sia* HT. In W7 hanno fatto
appositamente un *nuovo* scheduler, mi pare: magari ci sarà un perché.
Il problema non sta nel fatto di vedere le cpu virtuali, sta semmai nel
fatto di non tenere adeguatamente presente il fatto che le cpu virtuali
"girano" su cpu fisiche *diverse*. HT-aware passive load-balancing,
HT-aware task pickup, HT-aware affinity etc.: esistono già, certo, dal
kernel 2.5. Può essere che non funzionino al meglio colle nuove cpu?
È un'ipotesi così strampalata, visti i risultati dei test? Anche
perché qualcuno evidenziò problemi già anni fa: per esempio
http://kerneltrap.org/node/391#comment-10278
Se problemi c'erano allora, potrebbero essercene (altri) adesso, no?
Visto che uso solo Linux, mi piacerebbe che la cosa venisse investigata,
e non ci si trincerasse dietro un opensource è bello, quei test sono
affidabili, gli altri son bacati, quando è proprio ovvio che non è così.


 affidabili, gli altri son bacati 
E questo l'avrebbe detto, di grazia?
-- 
BArrYZ

 affidabili, gli altri son bacati
E questo chi l'avrebbe detto, di grazia?
-- 
BArrYZ

 E questo chi l'avrebbe detto, di grazia?
Abbiamo capito... :D

 affidabili, gli altri son bacati, quando è proprio ovvio che non è così.
Il problema, secondo me, è più generale e non ha senso affermare che
sia il kernel linux ad avere problemi solo perché qualcuno ha tirato
fuori una CPU che funziona meglio se il codice viene assemblato
diversamente o se il codice utilizza un nuovo set di istruzioni.
Certo a tutti noi piacerebbe avere del software che sia in grado
di sfruttare al meglio le capacità del nostro processore ma non è
sempre così e il problema non si limita certo al kernel ma riguarda
ogni applicativo. Non mancano certo gli applicativi progettati e
ottimizzati per 8086, ad esempio, ancora oggi.
A questo punto occorre sezionare un po' il concetto di prestazione
per basarsi su cose più oggettive.
Il test sul kernel linux è, ovviamente, significativo per determinare
le prestazioni sulla propria macchina linux ma non dice nulla
riguardo alle potenzialità legate alle nuove caratteristiche del
processore che potrebbero richiedere dei nuovi adattamenti del
software per essere sfruttate.
Dal punto di vista oggettivo, per determinare le potenzialità
di un processore occorrerebbe un sw costruito dalla stessa casa
costruttrice che faccia un lavoro oggettivamente determinabile
e il confronto sulle potenzialità lo si farebbe in base alla
capacità di effettuare quel lavoro verificabile.
Resta da vedere, però, il non trascurabile dettaglio dell'efficienza
con il software da noi utilizzato. Molti, ad esempio, non se
ne farebbero nulla di un processore lentissimo sotto XP ma
una scheggia sotto Windows 7.
L'open source è indispensabile affinché chiunque possa verificare
che il sw di test non sia truccato, non tutti amano fare i grulli
da videopoker.

 cosï¿œ.
Stai partendo da supposizioni errate: l'unica cosa da
investigare/migliorare e' il supporto per la gestione del risparmio
energetico con processi single-thread (il problema c'e' anche sui
processori AMD i cui core possono cambiare frequenza indipendentemente).
Ciao!
  Luca

 skeduler
^^^^^^^^^^
UAH UAH UAH UAH UAH!!!!!!!!!!!!!!!!!!!!!!
Ne' capisce ne' sa scrivere. LOLLONE.

 processori AMD i cui core possono cambiare frequenza indipendentemente).
Scusa, ammetto di voler approfondire, per quel poco che posso:
saresti così cortese di darmi qualche riferimento? 


 cosï¿œ cortese di darmi qualche riferimento?
Il mio PC: mettendo il gestore della frequenza della CPU "ondemand" e
avendo un carico di circa il 60-70% (esempio: una pipeline di codifica
video da AVI-DV a MPEG-2, dove puoi avere 5-6 thread), i processi
passano abbastanza spesso da un processore all'altro con conseguente
continuo adeguamento della frequenza e peggioramento delle prestazioni.
Altro esempio e' il "configure" di qualsiasi programma: siccome vengono
lanciati molti processi uno dopo l'altro, la CPU assegnata non e' sempre
quella che aveva gia' aumentato la frequenza, con la conseguenza che le
CPU rimangono quasi sempre alla frequenza piu' bassa. Entrambi i problemi
si risolvono con il taskset o disabilitando temporaneamente il gestore
ondemand (o configurandolo adeguatamente).
Penso che problematiche simili possano esserci con il Turbo Boost di
Intel, con il fatto pero' che non e' possibile configurarlo a proprio
piacimento, visto che e' gestito tutto dal processore.
Ciao!
  Luca

 Il mio PC: [...]
Grazie: non usando mai gestori di frequenza, ero completamente a digiuno
dell'argomento. :)


 usiamo.
Mi spiace, ma sono in completo disaccordo: primo perche' l'open source e'
ormai diffusissimo in qualsiasi ambito, in secondo luogo perche' questi
test dovrebbero aiutare a fare una scelta per un nuovo sistema da
adottare, e per sistema si intende il complesso hardware/software: se tu
fai i test prevalentemente con software proprietario e/o compilato in modo
che venga favorito un processore piuttosto che un altro, condizioni
pesantemente la scelta. Ad esempio io uso solo ed esclusivamente software
libero (e' una scelta "morale", a prescendire dalle prestazioni) e quindi
tutti i test con software proprietario, dal mio punto di vista, sono
perfettamente inutili, perche' a me non interessano.
Benche' la validita' dei test Phoronix sia tutta da verificare ed e' forse
lacunosa sotto certi punti di vista, li ho apprezzati enormemente perche'
toccano da vicino l'uso che faccio io del computer e, in generale, danno
"aria" verso la scelta di un sistema alternativo - e magari piu' prestante
- a quello chiuso e proprietario.
Ciao!
  Luca

http://arstechnica.com/hardware/reviews/2008/07/atom-nano-review.ars/6

 condivisa. I test in questione sono stati fatto con il kernel 2.6.31.
Non basta riconoscere che ha dei processori virtuali e utilizzzarle (quello 
che fa il supporto SMT) ma distinguere i processori fisici da quelli 
virtuali e utilizzare un algoritmo di skeduling differente da quello 
utilizzato normalmente e differente da quello ottimale per i vecchi dual 
prescot in quanto deve tener conto anche del parking mode per poter usare il 
TURBO MODE.
A quanto mi risulta il kernel identifica il processore virtuale di un core 
grazie al suo serial number, sei sicuro che riesca a identificare 
correttamente i nuovi processori?

 grazie al suo serial number
No, i core virtuali vengono identificati tramite l'APIC-ID. Per ottenere
l'APIC-ID occorre eseguire l'istruzione CPUID con il registro EAX
impostato a 1. L'APIC-ID e' contenuto nel byte piu' significativo del
registro EBX.
Ciao!
  Luca

 
Eccheccazzo, nessuno dice niente? PCMark05 aumenta deliberatamente i 
valori dei benchmark della memoria se crede che ci sia un processore 
Intel. Avanti porco giuda, fate i vostri commenti santocazzo.

 Intel. Avanti porco giuda, fate i vostri commenti santocazzo.
Ma no no, che malfidato, cosa mi vai a pensare queste cose brutte...
-- 
BArrYZ

 porco giuda, fate i vostri commenti santocazzo.
Sboccato! :P

 ha scritto nel messaggio news:4ab003c7$0$1104$4faf...@reader3.news.tin.it...

Uhmm...da come l'ho capita io sembra che il programma non attivi
 le SIMD (SSE, SSE2) col C7, pur essendo implementate nativamente
 nel processore.
Quindi mi viene da pensare che: o bisognava (prima del test) installare
il SystemInfo Hotfix Oct07 di Futuremark appunto (per la cronaca PCMark05
 riconosce l' Athlon Neo MV40 senza Hotfix), oppure VIA si � dimenticata
 di "ungere" ($) Futuremark stessa...
Grizlod{R} 

marimbarza ha scritto:

Lo sanno anche i bimbominkia che questi test sono totalmente inaffidabile.
Famosa la polemica Nvidia vs Ati, con NVidia che aveva palesemente 
"unto" per far taroccare i test a proprio favore....
-- 
"Non ho paura degli urli dei violenti, ma del silenzio degli onesti"
Martin Luther King.

 tutta la review mostra come il pii x3 a volte la sa lunga sugli i5 :S
Aggiornamento: il pii x3 in realtà le prende di brutto:
http://www.phoronix.com/scan.php?page=article&item=intel_lynnfield_add&num=1
CVD.


 CVD.
Non pare proprio.
I test confermano di nuovo che gli X3, con il loro basso costo, sono 
ottimi processori battendo spesso e volentieri sia gli I5 che gli I7 
sotto Linux.
E considerando la differenza di costo, e il fatto che sono X3 e non X4, 
mi sarebbe piaciuta una prova anche con questi ultimi.
Potrebbe essere uno sfacelo per gli I5 e I7 sotto Linux.


 Non pare proprio.
Non pare proprio cosa? Basta leggere i numeri dei test rifatti col bios
giusto.


 giusto.
Hai notato le differenze? Hai notato la differenza di costo?
Mi pare che vada benino lo stesso, no? Senza dimenticare che il problema 
si poneva nella stessa scheda madre Intel e questo mi pare alquanto grave.
Inoltre spesso il miglioramento rispetto all' X3 � nell'ordine di un 
30/40 % e addirittura in test Apache � ancora nettamente a favore di X3 ...
Il che significa che sarebbe da provare l'X4 nelle stesse condizioni.


 CVD.
Tra un altro pï¿œ di tempo sarï¿œ ancora peggio...:D

 Tra un altro pò di tempo sarà ancora peggio...:D
Francamente con il benchmark aggiornato, non vedo tutta questa
differenza abissale con prima. La differenza c'e' perche' ora funge il
turbo mode, e' vero, ma alla fin fine sono incrementi marginali, ove
presenti. Per esempio con Apache, turbo o meno, l'i5 le prende
sonoramente da un misero X3, il che mi pare interessante.
Perche', ricordo, parliamo sempre di un x3 contro un x4, e in alcuni
task tiene quasi testa. Per me restano risultati che fanno riflettere.
-- 
BArrYZ

 sonoramente da un misero X3, il che mi pare interessante.
Non "per esempio". Apache è l'_UNICO_ caso in cui l'i5 le piglia ancora.


 Non "per esempio". Apache ï¿œ l'_UNICO_ caso in cui l'i5 le piglia ancora.
in ogni caso i benchmark di phoronix, quando si riferiscono a hardware rilasciato da poco, sono da prendere con le molle, come confermano anche i test pubblicati la scorsa settimana del nuovo chipset AMD con video integrato che danno risultati inferiori a quelli del vecchio chipset
-- 
bye
main(){printf("%u\n",!(!1|1));}

 task tiene quasi testa. Per me restano risultati che fanno riflettere.
Sto 
riflettendo...............................................................................................................................................................................................................................................................................
:PPP