Linpack: perchè sono così strani i valori?

Quote:

---

Originariamente inviato da TheSolutor

Sai come si suol dire, lavar la testa all'asino acqua e sapone perso, e non ho un abbonamento con la procter e gamble, quindi non ci sperare troppo...

---

Tanto va la gatta al lardo che ci lascia lo zampino .

Un altra risposta argomentata, coerente, e molto poco "trollosa" delle tue.
Guarda, te lo faccio in un abbonamento per una scorta a vita di saponi se continui a rispondere in questa maniera ai miei thread roftl roftl

Poi mi lavi pure i capelli gratis, che voglio di piu' roftl

roftl.

guarda che o hai letto superficialmente o mi sono espresso male, con ottimizzazione per una cpu più che per un altra, non parlavo dell'algoritmo di bench, ma della jit, ovvero, le istruzioni compilate dalla jit sono evidentemente pensate con le capacità della piattaforma snapdragon, ergo la jit traduce più istruzioni o semplicemente le "traduce" meglio su questi piuttosto che su altri.
Non ho proprio parlato di bench ottimizzato per una o l'altra, e credimi ho scritto molto più di 3 righe di codice.

Che sia nei video android 2.2 non vuol dire nulla se usano kernel diversi.
Il nocciolo del problema è il kernel (scusa il gioco di parole) perchè se tu guardi le date oltre che i video ti accorgi che sono di prima che fosse disponibile una prima leaked di froyo per il droid, la 2.2 che gira su quel droid è tutto meno che una 2.2 completa. Una vera 2.2 si è potuta avere solo dopo che motorola ha rilasciato i sorgenti, e anche una volta rilasciati non sono completi, mancano di tutte le parti proprietarie. Mentre il nexus ha tutto subito data la sua natura di terminale di sviluppo.

Poi scusa che un algoritmo qualunque esso sia, esegue più operazioni piuttosto che altre, e quelle operazioni sono eseguite più velocemente da un'architettura, a casa mia quando questo accade, si dice che quell'algoritmo è ottimizzato per quell'architettura, che questa ottimizzazione poi sia by design o meno è un altro conto, ma sempre ottimizzato è.

Come Architettura, ovvero il supporto per istruzioni 128bit del snap mentre gli a8 no, (influisce realtà più in termini di prestazioni influisce di più il fatto che l'unità FP pipelined) porterebbe si un distacco in termini di bench ma molto minore. Tutto quello che lo snapdragon si ritrova in più è grazie al jit che è stato di fatto pensato per lui, prima del jit, il droid a 1.1ghz superava il nexus.

E comunque, visto che fai tanto il saccente, fammelo fare anche a me e ti correggo un po' qua e là.
Non esiste una cosa come algoritmo linx, linx è solo il programma che esegue il benchmark linpack su windows. A meno che con linx non ti riferisci al progetto opensource.
Esiste il benchmark linpack che è documentato e descritto, ma sempre a livello matematico, l'unica sua implementazione valida data è in Fortran, e sarabbe questa l'unica valida che va usata per eseguire il bench.
Riscrivendo l'algoritmo in un altro linguaggio perde, poco, ma perde.
Perchè un conto è dire, questo è l'algoritmo matematico per risolvere un sistema denso di equazioni lineari, un altro conto è codificarlo e come lo codifichi.
Comunque in definitiva, quello che ti era stato detto anche all'inizio prima che il discorso partisse per la tangente, Linpack, come tutti i benchmark (e dire benchmark sintetici è ridondante, chiunque abbia dato un esame di modelli di impianti o simili sa che i benchmark sono solo modelli di carico sintetici) misura solo quello per cui è stato pensato, né più né meno, in questo caso è risolvere sistemi di equazioni lineari, non può essere preso come indice per valutare un sistema nella sua interezza o almeno non da solo.

TheSolutor e wingzero smettetela!

Quote:

---

Originariamente inviato da theshine

guarda che o hai letto superficialmente o mi sono espresso male, con ottimizzazione per una cpu più che per un altra, non parlavo dell'algoritmo di bench, ma della jit, ovvero, le istruzioni compilate dalla jit sono evidentemente pensate con le capacità della piattaforma snapdragon, ergo la jit traduce più istruzioni o semplicemente le "traduce" meglio su questi piuttosto che su altri.
Non ho proprio parlato di bench ottimizzato per una o l'altra, e credimi ho scritto molto più di 3 righe di codice.

Che sia nei video android 2.2 non vuol dire nulla se usano kernel diversi.
Il nocciolo del problema è il kernel (scusa il gioco di parole) perchè se tu guardi le date oltre che i video ti accorgi che sono di prima che fosse disponibile una prima leaked di froyo per il droid, la 2.2 che gira su quel droid è tutto meno che una 2.2 completa. Una vera 2.2 si è potuta avere solo dopo che motorola ha rilasciato i sorgenti, e anche una volta rilasciati non sono completi, mancano di tutte le parti proprietarie. Mentre il nexus ha tutto subito data la sua natura di terminale di sviluppo.

Poi scusa che un algoritmo qualunque esso sia, esegue più operazioni piuttosto che altre, e quelle operazioni sono eseguite più velocemente da un'architettura, a casa mia quando questo accade, si dice che quell'algoritmo è ottimizzato per quell'architettura, che questa ottimizzazione poi sia by design o meno è un altro conto, ma sempre ottimizzato è.

Come Architettura, ovvero il supporto per istruzioni 128bit del snap mentre gli a8 no, (influisce realtà più in termini di prestazioni influisce di più il fatto che l'unità FP pipelined) porterebbe si un distacco in termini di bench ma molto minore. Tutto quello che lo snapdragon si ritrova in più è grazie al jit che è stato di fatto pensato per lui, prima del jit, il droid a 1.1ghz superava il nexus.

E comunque, visto che fai tanto il saccente, fammelo fare anche a me e ti correggo un po' qua e là.
Non esiste una cosa come algoritmo linx, linx è solo il programma che esegue il benchmark linpack su windows. A meno che con linx non ti riferisci al progetto opensource.
Esiste il benchmark linpack che è documentato e descritto, ma sempre a livello matematico, l'unica sua implementazione valida data è in Fortran, e sarabbe questa l'unica valida che va usata per eseguire il bench.
Riscrivendo l'algoritmo in un altro linguaggio perde, poco, ma perde.
Perchè un conto è dire, questo è l'algoritmo matematico per risolvere un sistema denso di equazioni lineari, un altro conto è codificarlo e come lo codifichi.
Comunque in definitiva, quello che ti era stato detto anche all'inizio prima che il discorso partisse per la tangente, Linpack, come tutti i benchmark (e dire benchmark sintetici è ridondante, chiunque abbia dato un esame di modelli di impianti o simili sa che i benchmark sono solo modelli di carico sintetici) misura solo quello per cui è stato pensato, né più né meno, in questo caso è risolvere sistemi di equazioni lineari, non può essere preso come indice per valutare un sistema nella sua interezza o almeno non da solo.

---

Avevo capito ti riferissi al jit (come è ovvio d'altronde, sarebbe impossibile fare ottimizzazioni pensato ad una applicazione che esegue il linpack). Ed infatti non ho mai detto il contrario.

Stavo solo sottolineando il fatto che probabilmente la differenza di prestazioni è data ad una diversa ottimizzazione del jit per il nexus one nei FW che si trovano ora. Ti stavo dando ragione.

Quello che mi premeva sottolineare, che evidentemente non si è capito, è che un ottimizzazione dle jit dedicata al nexus on, ed una unità FP piu' potente sono tutte cause plausibili.
Quello che non è possibile è che tutta sta differenza dipensa solo dal bench e da come è scritto. soprattutto un bench di questo genere.

Onde evitare ulteriori problemi, chiudiamo il thread :)