Mac chat


chest
 Share

Recommended Posts

CHE CASINO.

Allora. I valori importanti sono lo user time (e non quello totale) e la frequenza e larghezza del bus (che nessuno ha specificato ¬_¬).

Ancora meglio dello user time riportato da time sarebbe la misura del tempo speso nel ciclo. Qui però non si riesce ad ottenere un risultato coerente.

Ho provato a misurare il tempo usando clock() e getrusage(), oltre al comando time.

Su Linux (2.4, mi pare), time e getrusage() riportano valori simili o uguali per lo user time, mentre naturalmente il system time è diverso (non ci sono system call nel ciclo). clock() riporta qualcosa che assomiglia più al tempo complessivo (?!). O forse me lo sono sognato. Più tardi magari riprovo.

Su OS X 10.2, clock() riporta lo stesso valore dello user time di getrusage() (e direi che è giusto), ma time riporta valori di molto inferiori! Lo user time che riporta time per l'intero programma è circa un terzo di quello misurato per il ciclo (?!?).

Il programma calcola anche direttamente la larghezza di banda e la frequenza stimata per il bus. Un iBook 900 e un Duron 700 riportano praticamente gli stessi valori (bene, vuol dire che il programma è effettivamente memory-bound: entrambi hanno un bus da 100 MHz), solo che la stima ottenuta dal programma è circa un terzo della velocità effettiva del bus. Curiosamente, usando lo user time riportato da time su OS X si otterrebbe invece il valore esatto (con ottima approssimazione), ma non so che system call usi per ottenerlo. Si potrebbe guardare nel sorgente di Darwin. Che palle.

Ah, un'altra cosa: la risoluzione del clock su OS X è appena di un centesimo di secondo, mentre su Linux dovrebbe essere di un microsecondo.

Che palle.

Link to comment
Share on other sites

  • Replies 22.6k
  • Created
  • Last Reply

Top Posters In This Topic

CHE CASINO.

Allora. I valori importanti sono lo user time (e non quello totale) e la frequenza e larghezza del bus (che nessuno ha specificato ¬_¬).

Ancora meglio dello user time riportato da time sarebbe la misura del tempo speso nel ciclo. Qui però non si riesce ad ottenere un risultato coerente.

Ho provato a misurare il tempo usando clock() e getrusage(), oltre al comando time.

Su Linux (2.4, mi pare), time e getrusage() riportano valori simili o uguali per lo user time, mentre naturalmente il system time è diverso (non ci sono system call nel ciclo). clock() riporta qualcosa che assomiglia più al tempo complessivo (?!). O forse me lo sono sognato. Più tardi magari riprovo.

Su OS X 10.2, clock() riporta lo stesso valore dello user time di getrusage() (e direi che è giusto), ma time riporta valori di molto inferiori! Lo user time che riporta time per l'intero programma è circa un terzo di quello misurato per il ciclo (?!?).

Il programma calcola anche direttamente la larghezza di banda e la frequenza stimata per il bus. Un iBook 900 e un Duron 700 riportano praticamente gli stessi valori (bene, vuol dire che il programma è effettivamente memory-bound: entrambi hanno un bus da 100 MHz), solo che la stima ottenuta dal programma è circa un terzo della velocità effettiva del bus. Curiosamente, usando lo user time riportato da time su OS X si otterrebbe invece il valore esatto (con ottima approssimazione), ma non so che system call usi per ottenerlo. Si potrebbe guardare nel sorgente di Darwin. Che palle.

Ah, un'altra cosa: la risoluzione del clock su OS X è appena di un centesimo di secondo, mentre su Linux dovrebbe essere di un microsecondo.

Che palle.

Link to comment
Share on other sites

CHE CASINO.

Allora. I valori importanti sono lo user time (e non quello totale) e la frequenza e larghezza del bus (che nessuno ha specificato ¬_¬).

Ancora meglio dello user time riportato da time sarebbe la misura del tempo speso nel ciclo. Qui però non si riesce ad ottenere un risultato coerente.

Ho provato a misurare il tempo usando clock() e getrusage(), oltre al comando time.

Su Linux (2.4, mi pare), time e getrusage() riportano valori simili o uguali per lo user time, mentre naturalmente il system time è diverso (non ci sono system call nel ciclo). clock() riporta qualcosa che assomiglia più al tempo complessivo (?!). O forse me lo sono sognato. Più tardi magari riprovo.

Su OS X 10.2, clock() riporta lo stesso valore dello user time di getrusage() (e direi che è giusto), ma time riporta valori di molto inferiori! Lo user time che riporta time per l'intero programma è circa un terzo di quello misurato per il ciclo (?!?).

Il programma calcola anche direttamente la larghezza di banda e la frequenza stimata per il bus. Un iBook 900 e un Duron 700 riportano praticamente gli stessi valori (bene, vuol dire che il programma è effettivamente memory-bound: entrambi hanno un bus da 100 MHz), solo che la stima ottenuta dal programma è circa un terzo della velocità effettiva del bus. Curiosamente, usando lo user time riportato da time su OS X si otterrebbe invece il valore esatto (con ottima approssimazione), ma non so che system call usi per ottenerlo. Si potrebbe guardare nel sorgente di Darwin. Che palle.

Ah, un'altra cosa: la risoluzione del clock su OS X è appena di un centesimo di secondo, mentre su Linux dovrebbe essere di un microsecondo.

Che palle.

Link to comment
Share on other sites

Macteo: <FONT COLOR="119911">beh, non proprio... gli 8 slot di memoria (standard), i due processori (che da soli, con i dissipatori, sono grandi quanto lo zuccotto), i 4 slot d'espansione per schede (di cui uno AGP 8x), li hai dimenticati?</FONT>

Appunto! Dopo il danno la beffa! Niente spazio per i drive, e poi ci mettono tutta questa roba inutile. :P

Link to comment
Share on other sites

che c'è di nuovo?

ah, sì... eMac a 1,25 GHz... e radeon 9200 (o c'era già?): 799 e 999$

nessun riscontro sul sito italiano, per ora...

spero solo possa essere il primo annuncio di una serie... in crescendo... Posted Image

Link to comment
Share on other sites

Camillo> <FONT COLOR="ff0000">Appunto! Dopo il danno la beffa! Niente spazio per i drive, e poi ci mettono tutta questa roba inutile. :P</FONT>

ma come???

adesso vi lamentate se un Mac è espandibile???

insomma, decidetevi! :P

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share