[OT] Re: [PLUTO-help] Velocità dei processori

[Gian Uberto Lauri]

>>>>> "SS" == Simone Stevanin <simone a pluto.it> writes:

>> I test vanno  eseguiti molte volte coi programmi  che interessa usare,
>> non con benchmark.

SS> I bechmark (almeno quelli per Windows - leggo dalle riviste di
SS> settore) sono costituiti da un programma che simula l'esecuzione
SS> di un ventaglio di applicazioni.


I benchmark sono spesso traditori. Leggersi Hennessy Patterson:

	Un benchmark può  essere codificato in modo malandrino
	dando risultati per  euristica, ottimizzato per andare
	bene su una architettura e male su un'altra etc.

SS> Secondo me è abbastanza limitante fermarsi a testare un pc solo
SS> sulle applicazioni che si useranno perchè, a meno di utilizzi
SS> particolari, potrebbero cambiare col tempo. Un benchmark è
SS> predisposto anche per dare dei risultati, mediante il calcolo dei
SS> tempi interno al programma e la visulizzazione dei risultati a
SS> video: mettersi col cronometro a vedere quanto ci mette a
SS> caricarsi, che ne so, Firefox avrebbe un margine di errore che
SS> falserebbe completamente la misura ;-)

... 

SS> Le differenze saranno nell'ordine dei decimi di secondo per molti
SS> applicativi e per un uso comune.

"Vedere quanto ci  mette" è vero, non specifica il  come fai la misura
ed anche la mia frase non specificava un'altra cosa dando per scontato
che ovviamente  sto parlando  di applicazioni CPU  intensive: fintanto
che si tratta di battere i tasti,  usare Emacs sotto DOS su un 386 non
è tanto diverso da usare Emacs su un G5.

Il  come fare  la misura,  anche questo  era sottointeso,  richiede il
massimo  della  oggettività,  la   cosa  migliore  sarebbe  andare  in
assembler ed usare  un clock hardware, poi viene  l'uso di getrusage()
ed infine l'uso del comando time.

Occhio  che comunque  i risultati  possono essere  variati  dal carico
della macchina sia come CPU che come memoria (ho notato con saint6 che
in presenza  di swap pesante, getrusage() comincia  ad aumentare anche
gli user time).

>> Ma  la cosa  migliore è  vedere  quale dei  due fa  eseguire meglio  i
>> programmi che ti servono.

SS> Le differenze saranno nell'ordine dei decimi di secondo per molti
SS> applicativi e per un uso comune.  Certo, nell'editing audio/video
SS> o in altri campi ben specifici potrebbero essere ben maggiori.

Un'altra cosa dei benchmark per Windows è che si dovrebbe verificare a
che priorità girano  i thread del processo. Se  cominciano ad andare a
priorità maggiore  di 16 mi  sa che i  valori cominciano ad  essere un
"pelo" più distanti dalla realtà,  visto che il simpatico scheduler di
Windows lascia a  secco di CPU tutti i  programmi con proiorita minore
di X fintanto che c'è un thread X pronto per l'esecuzione.

Meglio invece vedere come quei programmi  che si usano di solito e che
fanno  largo  uso  di  CPU  (ricalcolo di  grossi  fogli  elettronici,
programmi come Octave  o il non libero Matlab,  giochi con grafica 3D,
editing audio, di immagini  e video girano, misurando oggettivamente i
dati.


-- 
 /\            ___
/___/\__|_|\_|__|___Gian Uberto Lauri_____________________
  //--\ | | \|  |   Integralista GNUslamico  
\/		    e coltivatore diretto di software