Newsgroup: it.comp.macintosh
Titolo: [OSX] 10 modi per aumentare le prestazioni


-- 
http://www.emeraldion.it
Too bad all the people who know how to run the country
are busy driving taxi cabs and cutting hair - G. Burns


Nessuno commenta questi tricks?
-- 
Andy Buckley (Mojopin)
www.mojopin.net
La musica è mia madre e mio padre... il mio lavoro e il mio riposo... il 
mio sangue... la mia bussola... il mio amore

> Nessuno commenta questi tricks?
Interessanti. Gli ho dato una letta veloce, ma mi sembra che si sia
dimenticato l'Acceleration framework per l'uso del processore Altivec
(per PPC) e SSE (per Intel). Ma forse a quell'epoca non esisteva.
Cmq questo mi ricorda una domanda che avevo da tempo, e che forse
qualcuno che ne sa' di piu' mi puo' spiegare. Perche' Apple continua a
compilare il sistema operativo usando gcc? Sono contentissimo che gcc
sia incluso nel sistema, ma come prestazioni e' molto indietro ai
compiler dell'Intel e dell'IBM. Perche' non usare i migliori per
qualcosa cosi' importante come il sistema operativo?
Diego

 qualcosa cosi' importante come il sistema operativo?
me lo chiedo anche io
p.s. - hai mica qualche link di riferimento sul confronto prestazionale
tra i vari compilatori alternativi a gcc? :?
-- 
I've always been more concerned with users. )\._.,--....,'``.
Programmers do their work but once, while  /,   _.. \   _\  (`._._,
users are saddled with it ever thereafter. `_.-(,_..'--(,_..'`-.;.'

 tra i vari compilatori alternativi a gcc? :?
Puoi provare sul sito di Intel, ma sarebbe come chiedere all'oste se il
vino e' buono.
Io me lo sono scaricato, anche se non ho avuto occasione di usarlo su OS
X. Su linux ho avuto un miglioramento del 30% nei tempi di esecuzione di
alcuni programmi...
d

 tra i vari compilatori alternativi a gcc? :?
No, mi spiace. Ma la differenza e' MOLTO grande da quello che ho
capito.
Un rapido giro per la rete (ma proprio rapido rapido) mostra che gcc si
aggira intorno al 30% di velocita' di un compiler fatto ad hoc: tipo
quelli della Sun, IBM o Intel. Ma puo' variare dal poco (5%) al tanto
(50%).
Fra l'altro la cosa peggiore e' che gcc fa' un uso molto ridotto delle
caratteristiche del processore, proprio perche' funziona su cosi' tanti
processori. Questo implica che feature atipiche non vengono sfruttate
molto, come il processore AltiVec dei Mac.
Questo e' un articolo che ho trovato:
http://209.85.129.104/search?q=cache:1SDSb1jySZ0J:www.ctoforaday.com/archives/2003_08.html+compiler+faster+gcc+vs+xlc&hl=en&gl=uk&ct=clnk&cd=1&client=firefox-a
Ciao
Diego

 molto, come il processore AltiVec dei Mac.
  Mi risulta il contrario. Apple e Motorola hanno pagato un'azienda
perché gli ottimizzasse gcc per sfruttare Altivec dei G4. Avevo un
appunto in tal senso e dalle ricerche che sto facendo per un articolo
sono emersi dati che confermano l'informazione.
-- 
Nicola D'Agostino
<!-- 
http://www.nicoladagostino.net
 -->
<!-- 
http://www.nezmar.com
 -->

 sono emersi dati che confermano l'informazione.
ma la vuoi smettere di cercare le cose che cerco io? :D
cioé manca solo che tu mi dica che stai facendo una ricerca sul primo
crash di internet (cfr thread su icr) :D


 alcuni programmi...
questo mi fa ulteriormente sospettare che Apple stia sacrificando troppa
potenza in funzione della scalabilità: non é possibile che il finder sia
un chiavica su qualunque macchina...


 molto, come il processore AltiVec dei Mac.
ragazzo mio, tu mi rubi i pensieri. qualcosa mi dice che l'"obsolescenza
programmata" passi dai compilatori...


 crash di internet (cfr thread su icr) :D
No. O meglio, non ancora... ;-)


 sono emersi dati che confermano l'informazione.
Forse (e la sto buttando li', non ne so praticamente nulla di
compilatori) Apple e Motorola hanno fatto ottimizzare gcc per il G4, MA
questo poteva solo essere fatto rimanendo dentro il _modello_ di CPU
generico del gcc. Quindi il beneficio e' stato limitato.
Vedi questo passaggio dall'link che ho mandato prima:
"Current GCC vs XLC performance comparisons show optimized GCC vs
optimized XLC compiles showing improvements of anywhere from 11% to 51%
on SPECint2000 scores. For floating point performance, the difference
is even more extreme - more of the numbers are over the 50% mark than
under; the G4/G5 have always had stronger floating point, and now the
compiler backs that up with the appropriate optimizations to make use
of the unique features of the architecture that enables that to be
true."
Diego


  Buona lettura. :)


potevate dirlo che si trattava di computer, io pensavo ad altro ......
:)

 true."
Ottimo. Performance in floating point, che su un OS contano quasi
*nulla*. Per il resto usa semper SPECint2000. Quindi ancora una volta
test ad hoc, che hanno poco a vedere sia con un uso tipico, sia con un
uso tipico dentro un OS.
-- 
blog:  
http://www.akropolix.net/rik0/blogs
 | Uccidete i filosofi,
site:  
http://www.akropolix.net/rik0/
      | tenetevi riso e
forum: 
http://www.akropolix.net/forum/
     | bacchette per voi.

 (50%).
Si, ma vai a vedere su quali tipi di programmi questo vale. 
Sul calcolo numerico e roba del genere. A livello di OS il divario è
molto piccolo (perchè ci sono un sacco di cose che semplicemente
dipendono dal silicio, tempi meccanici di risposta, rete etc).
D'altra parte compilando un OS con un compilatore diverso da quello che
viene usato dai tuoi utenti è un rischio. Per quanto dichiarata la
compatibilità binaria è sempre un 'tendere verso'. Introdurre una
potenziale fonte di bachi gratis per qualche performance in più è
stupido a dir poco.


 programmata" passi dai compilatori...
Hai voglia di spiegarmi in che parte di un OS vedresti bene l'uso di
un'unità di calcolo vettoriale?
