Linpack: perchè sono così strani i valori?

Ciao a tutti,

guardate con attenzione gli scores sul sito del linpack per android:

Linpack by Device GreeneComputing

Sono completamente senza senso!

Come è possibile che un milestone @ 1300mhz vada meno di un droid @ 1000 ? (che sono lo stesso telefono?)

O ancora che un milestone @ 1000mhz vada la metà di un desire @ 1000 mhz, quando in realtà a parità di mhz il cortex A8 del milestone è piu' performante dello snapdragon?

Come vengono fuori questi valori!?

AD ESEMPIO:

HTC DESIRE @ 1100 mhz:

10 Midian 45.49 MFLOPS HTC Desire 1113.6MHz google/passion/passion/mahimahi:2.2/FRF91/43546:user/release-keys

MILESTONE @ 1300 mhz:

10 Donny~Boulder,Co. 18.225 MFLOPS Milestone 1343.0MHz verizon/voles/sholes/sholes:2.1-update1/ESE81/29593:user/release-keys

ALTRO ESEMPIO:

MILESTONE
Video Linpack test milestone + froyo @ 1,25ghz
Risultato: 19 MFLOPS

DESIRE
Video Linpack test nexus one + froyo @ 1,1ghz
Risultato: 40 MFLOPS

Come diavolo è possibile questa differenza?!

E non ditemi che lo snapdragon a parità di mhz va meno di un cortex a8 che non è vero!

A parte che i benchmark sintetici hanno sempre lasciato il tempo che trovano, ti sei mai chiesto com'è che sotto windows i processori compatibili, al momento vanno molto meglio di quelli AMD mentre sotto linux un tricore AMD da 90 euro va come un quad core compatibile top di gamma o quasi ?

I sw ed i compilatori non sono mai politically correct, alla fine il codice generato gira meglio da una parte che dall'altra, indipendentemente dai muscoli.

Sarà così anche tra snapdragon ed omap...

Quote:

---

Originariamente inviato da TheSolutor

A parte che i benchmark sintetici hanno sempre lasciato il tempo che trovano, ti sei mai chiesto com'è che sotto windows i processori compatibili, al momento vanno molto meglio di quelli AMD mentre sotto linux un tricore AMD da 90 euro va come un quad core compatibile top di gamma o quasi ?

I sw ed i compilatori non sono mai politically correct, alla fine il codice generato gira meglio da una parte che dall'altra, indipendentemente dai muscoli.

Sarà così anche tra snapdragon ed omap...

---

Conosco bene l'annosa questione del compilatore ottimizzato intel.
Ti assicuro però che in gnu/linux, ci sono ambiti dove vai molto piu' fluido di win ed ambiti dove vai peggio(maledetto server x...pero' questa è un altra questione).

qualche differenza ci puo' stare...ma qui parliamo del DOPPIO del risultato...una roba assurda...e poi linpack utilizza l'algoritmo linx che in teoria non è ottimizzato per niente....

continuo a non spiegarmelo...

Quote:

---

Originariamente inviato da WingZero

Ti assicuro però che in gnu/linux, ci sono ambiti dove vai molto piu' fluido di win ed ambiti dove vai peggio

---

Non sto parlando di windows vs linux sto parlando di amd v.s. intel sotto linux e sotto windows e dello sbalzo enorme che c'è tra i due confronti.

In ogni caso basta una singola istruzione eseguita molto peggio da un processore che da un altro e i risultati dei benchmark sintetici sballano, se quella singola istruzione è usata pesantemente dal benchmark.

Quote:

---

Originariamente inviato da TheSolutor

Non sto parlando di windows vs linux sto parlando di amd v.s. intel sotto linux e sotto windows e dello sbalzo enorme che c'è tra i due confronti.

In ogni caso basta una singola istruzione eseguita molto peggio da un processore che da un altro e i risultati dei benchmark sintetici sballano, se quella singola istruzione è usata pesantemente dal benchmark.

---

tutto quello che vuoi, ma qui si parla del doppio esatto dei megaflops... non sono semplici ottimizzazione che puo' favorire l'uno o l'altro... :/

altro esempio: nel banch 3D di quadrant quello in cui ci sono 2 pianeti uno grande arancione ed uno piccolo grigio che girano, il desire fa 50 fps, il milestone @ 1ghz ne fa 10. -.-"

(poi negli altri bench 3d il milestone è superiore al desire grazie alla scheda video integrata piu' potente...superiore di poco 3-4 fps...pero' in questo qua la differenza fa paura a favore del desire...c'è qualcosa che mi sfugge...)

Quote:

---

Originariamente inviato da WingZero

tutto quello che vuoi, ma qui si parla del doppio esatto dei megaflops... non sono semplici ottimizzazione che puo' favorire l'uno o l'altro... :/

---

[Phoronix] AMD Phenom II X3 On Linux Review

Guardati questo, x esempio

Nel primo benchmark un x3 amd (neanche il più veoce) ci mette quasi la metà del tempo di un core i7 (il top di gamma al momento del benchmark) a eseguire il singolo benchmark, in altri benchmark la differenza non è così netta, sotto windows, di solito è l'i7 a metterci la meta di un phenom 2 710 a fare le cose.

Morale anche senza considerare i compilatori furbetti, differenze anche enormi sono possibili tra due processori della stessa architettura.

Quote:

---

Originariamente inviato da TheSolutor

[Phoronix] AMD Phenom II X3 On Linux Review

Guardati questo, x esempio

Nel primo benchmark un x3 amd (neanche il più veoce) ci mette quasi la metà del tempo di un core i7 (il top di gamma al momento del benchmark) a eseguire il singolo benchmark, in altri benchmark la differenza non è così netta, sotto windows, di solito è l'i7 a metterci la meta di un phenom 2 710 a fare le cose.

Morale anche senza considerare i compilatori furbetti, differenze anche enormi sono possibili tra due processori della stessa architettura.

---

La metà del tempo??
Guarda che da quei bench ci mette un 10-20% in meno.

Per quando riguarda la situazione desktop ti do ragione: i compilatori sono ottimizzati per le cpu intel (e come ho detto prima questa è una annosa questione che potremmo discure in un altro thread) ma con il raffronto che stavo facendo io NON C'entra nulla!

In primo luogo, la differenza nel caso che specificavo io era esattamente del doppio: tra 19 e 40 mflops ce ne passa e non puo' essere solo questione di ottimizzazione o di librerie differenti.

Inoltre l'"ottimizzazione del compilatore" per differenti architetture desktop x86 , in questo caso non c'entra proprio nulla:
Io stavo confrontanto lo snapdragon con il cortex A8 @1ghz che sono entrambi architettura ARM. Ed inoltre l'inteprete java in questo caso è assolutamente imparziale.

Un spiegazione decente al problema potrebbe essere (Ad esempio) l'unità FP del cortex A8 è peggiore dello snapdragon, per questo i risultati sono falsati in questo modo.

Ma ciò che hai tirato in ballo tu nn c'entra assolutamente nulla, mi disp.

@wingzero hai provato a fare un confronto con i valori linpack del droid americano? lo so tra il nostro milestone e il droid la differenza sta nel bootloader bloccato , cosa nn di poco conto , prova a controllare in qualche rom per il droid che nn ci siano dei driver ottimizati per l'arm cortex A8 e la gpu magari sono quelli che fanno sfasare i risultati. :)

Quote:

---

Originariamente inviato da cicemon212

@wingzero hai provato a fare un confronto con i valori linpack del droid americano? lo so tra il nostro milestone e il droid la differenza sta nel bootloader bloccato , cosa nn di poco conto , prova a controllare in qualche rom per il droid che nn ci siano dei driver ottimizati per l'arm cortex A8 e la gpu magari sono quelli che fanno sfasare i risultati. :)

---

Escluderei la gpu che il linpack è un test solo per la cpu.
Ma fammi capire...perchè con il bootloader sbloccato si dovrebbe andare di piu'?! Che fanno ci castrano il milestone questi qua?? O_o

Cmq vedendo i video su youtube, come quello che ti ho linkato, il droid con fw custom, froyo 2.2, arriva a massimo 19 fps.
Contro i 40 del nexus one! E' assurdo! sono entrambe ad 1 ghz...perchè il cortexa8 fa la metà dello snapodragon?

io ho fatto questo ragionamento : avendo il bootloader bloccato non possiamo mettere ottimizazioni al kernel quindi non possiamo cambiare dei driver che migliorano le prestazioni del nostro terminale come invece l'americano droid può fare. infatti penso se tu vai a vedere qualche rom custom americana e controlli il kernel noterai che sarà diverso dal nostro nelle parti che rigardano i driver della cpu ( o almeno penso io )... ps nn so nulla di programmazione ma penso che ragionando sia presumibilmente cosi

Quote:

---

Originariamente inviato da WingZero

La metà del tempo??
Guarda che da quei bench ci mette un 10-20% in meno.

---

Beh, 41 secondi contro 27...

Mi sa che hai uno strano concetto delle percentuali...

in ogni caso, anche quì

[Phoronix] AMD Phenom II X3 On Linux Review

1220 contro 2186 transazioni al secondo, non è il doppio ma quasi

Quote:

---

Per quando riguarda la situazione desktop ti do ragione: i compilatori sono ottimizzati per le cpu intel (e come ho detto prima questa è una annosa questione che potremmo discure in un altro thread) ma con il raffronto che stavo facendo io NON C'entra nulla!

---

Vediamo di capire quello che si sta dicendo prima di partire per la tangente, i benchmark linkati sono fatti tutti nello stesso ambiente con lo stesso oss sotto, e compilati con GCC.

Qui il confronto è teoricamente equo, cio non toglie che ci siano differenze macroscopiche tra un processore e l'altro, in un senso e nell'altro.

Quote:

---

Inoltre l'"ottimizzazione del compilatore" per differenti architetture desktop x86 , in questo caso non c'entra proprio nulla:
Io stavo confrontanto lo snapdragon con il cortex A8 @1ghz che sono entrambi architettura ARM.

---

E di grazia dove starebbe la differenza tra il confrontare le differenze tra due differenti cpu x86 rispetto a confrontare due differenti cpu arm ?

Quote:

---

Un spiegazione decente al problema potrebbe essere (Ad esempio) l'unità FP del cortex A8 è peggiore dello snapdragon, per questo i risultati sono falsati in questo modo.

Ma ciò che hai tirato in ballo tu nn c'entra assolutamente nulla, mi disp.

---

Tutto fa brodo, è lapalissiano.

Resta il punto, che se hai voglia di discutere un argomento interessante sto qua per questo, se invece hai voglia di imporre delle idee preconcette senza rispetto per l'interlocutore, ho un sacco di altre cose da fare.

Peraltro benchmark o non benchmark, un nexus one si muove con un'altra reattività rispetto al milestone, basta averli presi in mano entrambi, er cui al dilà dei numerini direi che non c'è il minimo dubbio che lo snapdragon sia un processore migliore, almeno considerando l'applicazione di cui si sta discutendo.

Esattamente come non c'è il minimo dubbio che un core i 7 sia un processore migliore di un x3 710 se si parla di pc con windows sopra, poi si può parlare del perché per un anno ma il succo non cambia.

Quote:

---

Originariamente inviato da TheSolutor

Beh, 41 secondi contro 27...

Mi sa che hai uno strano concetto delle percentuali...

in ogni caso, anche quì

[Phoronix] AMD Phenom II X3 On Linux Review

1220 contro 2186 transazioni al secondo, non è il doppio ma quasi



Vediamo di capire quello che si sta dicendo prima di partire per la tangente, i benchmark linkati sono fatti tutti nello stesso ambiente con lo stesso oss sotto, e compilati con GCC.

Qui il confronto è teoricamente equo, cio non toglie che ci siano differenze macroscopiche tra un processore e l'altro, in un senso e nell'altro.



E di grazia dove starebbe la differenza tra il confrontare le differenze tra due differenti cpu x86 rispetto a confrontare due differenti cpu arm ?



Tutto fa brodo, è lapalissiano.

Resta il punto, che se hai voglia di discutere un argomento interessante sto qua per questo, se invece hai voglia di imporre delle idee preconcette senza rispetto per l'interlocutore, ho un sacco di altre cose da fare.

Peraltro benchmark o non benchmark, un nexus one si muove con un'altra reattività rispetto al milestone, basta averli presi in mano entrambi, er cui al dilà dei numerini direi che non c'è il minimo dubbio che lo snapdragon sia un processore migliore, almeno considerando l'applicazione di cui si sta discutendo.

Esattamente come non c'è il minimo dubbio che un core i 7 sia un processore migliore di un x3 710 se si parla di pc con windows sopra, poi si può parlare del perché per un anno ma il succo non cambia.

---

Innanzitutto l'80% di quei bench vedi il phenom sopra di un 10-20%. In altri di piu' in altri vince l'i7. Quindi prendere un unico bench come riferimento generale è quantomeno fazioso.
Poi prima di dare aria alla bocca vediamo di capire come stanno le cose.

E' risaputo da sempre, perlomeno da chi frequenta il settore, che l'unità FP delle architetture amd è stato sempre superiore a quella intel, ed è proprio in questi test che su linux (quindi senza favoritismi di sorta) il phenom le da all'i7. niente da dire.

Ora, venendo a noi, il linpack altro non è che un algoritmo per eseguire sistemi di equazioni lineari che confronta il tempo di risoiluzione con il numero di equazioni risolte per tirare fuori i MFlops della cpu.

E "di grazia" (come mi insegni te), un algoritmo di questo genere non è influenzato da ottimizzazioni di sorta, ed il raffronto che fai te continua ad essere completamente inutile.

Prova a frovarmi un bench tramite algoritmo linx (OCCT et simila) che su win il phenom fa la metà dei mflops dell'i7 e su linux succede il contrario...non esiste. I valori saranno quasi identi da una parte come dall'altra!

Nexus one altra reattività rispetto al droid? li ho avuti tutti e 2, e non è assolutamente così. A parità di clock sn identici.

Forse sarebbe meglio fare ipotesi plausibili, come ha fatto cicemon, oppure ad esempio ipotizzare che si acolpa del quatitativo di ram dimezzato rispeto al N1, piuttosto che "trasportare" insensati confronto tra architettura x86 ad architetture arm. -.-"

Resta il punto che io sono ben contento e consapevo di voler discutere questo argomento con chiunque: a patto di non voler stravolgere la realtà ed inventarsi raffronti senza alcuna base oggettiva.
Le architetture x86 con i relativi problemi di sorta lasciali stare.

Se il cortexA8 fa 19 mflop e lo snapdragon ne fa 40, non è certo dovuto al bench o al sistema .

Quando torno stasera posso linkarti meglio, comunque linpack si basa su una serie di "operazioni", e lo snapdragon ha un unita FP piu performante di quella del A8, mi sembra gestisca 128 bit vs i 64 dell'a8!!

Stasera ti posso linkare meglio, comunque in linpack e questo il punto!

Quote:

---

Originariamente inviato da WingZero

Innanzitutto l'80% di quei bench vedi il phenom sopra di un 10-20%. In altri di piu' in altri vince l'i7. Quindi prendere un unico bench come riferimento generale è quantomeno fazioso.

---

Ci hai fatto caso che stiamo confrontando un processore di fascia medio bassa con uno top, di una generazione successiva, vero ?

Teoricamente l'i7 dovrebbe umiliare l'x3 in ogni singolo cacchio di benchmark, e invece ci sono singoli benchmark dove le prende alla grande.

Questo è il punto, il resto è fuffa.

Quote:

---

E' risaputo da sempre, perlomeno da chi frequenta il settore, che l'unità FP delle architetture amd è stato sempre superiore a quella intel, ed è proprio in questi test che su linux (quindi senza favoritismi di sorta) il phenom le da all'i7. niente da dire.

---

E' risaputo, cosa ?

La unità fp di amd è sempre stata il suo tallone d'achille, solo in era athlon/pIII amd ha sopravanzato nettamente intel, successivamente c'è stata una rincorsa tra le due con fasi alterne.

Quote:

---

Ora, venendo a noi, il linpack altro non è che un algoritmo per eseguire sistemi di equazioni lineari che confronta il tempo di risoiluzione con il numero di equazioni risolte per tirare fuori i MFlops della cpu.

---

Il linpack è un benchmark sintetico come tanti altri, ed è influenzato dalla scrittura del codice, da come è compilato e dal processore su cui gira, come ogni altro benchmark, come ogni altro sw di questa terra.

Fai girare superpi su due proc intel e amd di classe (e prezzo) equivalenti, ed ottieni che il proc amd ci mette circa il doppio, fai girare linpack su snapdreagon e omap e capita la stessa cosa, punto.

Quote:

---

Nexus one altra reattività rispetto al droid? li ho avuti tutti e 2, e non è assolutamente così. A parità di clock sn identici.

---

Avremo provato cellulari differenti evidentemente.

Quote:

---

Forse sarebbe meglio fare ipotesi plausibili, come ha fatto cicemon, oppure ad esempio ipotizzare che si acolpa del quatitativo di ram dimezzato rispeto al N1, piuttosto che "trasportare" insensati confronto tra architettura x86 ad architetture arm. -.-"

---

Davvero il saputello che ogni forum si ritrova ad avere ce lo abbiamo già, non ce ne serve un altro, vado ad usare il mio tempo altrove piuttosto che sprecarlo tentando di discutere con te.

Buona serata.

@the soluto se ti riferisci a me come saputello sbagli di grosso!! Ho espressamente detto che nn ne capisco di programmazzione ho solamente fatto una ipotesi su l'unica differenza che hanno il droid e il milestone e sull'evidente disparità di punteggio in linpack, infatti ho anche suggerito di andare a controllare una custom rom per il droid e vedere il kernel se effettivamente ha migliorie o meno.
ps era un ipotesi sbagliata vedendo i video
@wingzero nn ho visto i link del video e avevo anche letto male la tua rx lol :) cmq si e propio vero c'è una enorme disparità tra n1 e milestone... nn so se ricordo male io ma mi sembra che il cortex a parità di clock cn la 2.1 e la jit del 2.2 faceva meglio dell'n1 o arrivava a quei risultati !

@cice

ma figurati se mi riferivo a te...

Quote:

---

Originariamente inviato da 89luca89

Quando torno stasera posso linkarti meglio, comunque linpack si basa su una serie di "operazioni", e lo snapdragon ha un unita FP piu performante di quella del A8, mi sembra gestisca 128 bit vs i 64 dell'a8!!

Stasera ti posso linkare meglio, comunque in linpack e questo il punto!

---

tnx luca!

@ thesolutor: Ecco una risposta sensata e pertinente! Vai pure a confrontare le architetture x86 con quelle arm in un altro forum se ti diverti. Che di presuntuosi come te ne vedo fin troppi in giro.

Quote:

---

Originariamente inviato da TheSolutor

Ci hai fatto caso che stiamo confrontando un processore di fascia medio bassa con uno top, di una generazione successiva, vero ?

Teoricamente l'i7 dovrebbe umiliare l'x3 in ogni singolo cacchio di benchmark, e invece ci sono singoli benchmark dove le prende alla grande.

Questo è il punto, il resto è fuffa.



E' risaputo, cosa ?

La unità fp di amd è sempre stata il suo tallone d'achille, solo in era athlon/pIII amd ha sopravanzato nettamente intel, successivamente c'è stata una rincorsa tra le due con fasi alterne.



Il linpack è un benchmark sintetico come tanti altri, ed è influenzato dalla scrittura del codice, da come è compilato e dal processore su cui gira, come ogni altro benchmark, come ogni altro sw di questa terra.

Fai girare superpi su due proc intel e amd di classe (e prezzo) equivalenti, ed ottieni che il proc amd ci mette circa il doppio, fai girare linpack su snapdreagon e omap e capita la stessa cosa, punto.



Avremo provato cellulari differenti evidentemente.



Davvero il saputello che ogni forum si ritrova ad avere ce lo abbiamo già, non ce ne serve un altro, vado ad usare il mio tempo altrove piuttosto che sprecarlo tentando di discutere con te.

Buona serata.

---

roftl ! Ma per favore! Il linpack è ovvio che è influenzato dall'architettura come ha spiegato perfettamente luca ! Pero' questo con il discorso inutile e fuori luogo dei compilatori "ottimizzati" amd vs intel non c'entra proprio nulla. Il risultato del linpack non viene influenzato da come è "scritto il codice" e come è compilato!!
A star a sentire a te i Mflops potrebbe variare in base a come è scritto / compilato il programmino "linpack". roftl . Semplicemente Assurdo. E' come dire che un superpi sotto windows va meglio l'intel del 200% e sotto linux succede il contrario, è amd ad andare il 200% dell'intel.
Il linpack come il superpì è influenzato UNICAMENTE dall'architettura , e non da fantomatiche ottimizzazioni del compilatore o di come è scritto il codice.
Vatti a vadere come funziona l'algoritmo "linx" e poi ne riparliamo! -.-".
(E ti ricordo che sotto android i programmi nn sono compilati nel senso classico del termine, usando una VM java con il JIT)

Spero veramente che continui ad usare il tuo tempo altrove come hai detto tu. Non ho davvero voglia di leggerti ancora.

Quote:

---

Originariamente inviato da 89luca89

Quando torno stasera posso linkarti meglio, comunque linpack si basa su una serie di "operazioni", e lo snapdragon ha un unita FP piu performante di quella del A8, mi sembra gestisca 128 bit vs i 64 dell'a8!!

Stasera ti posso linkare meglio, comunque in linpack e questo il punto!

---

Grazie ancora luca! Attendo spiegazioni dettagliate, e magari capire in quali ambiti uno snapdragon puo' sopravanzare di molto il cortexa8...

Quote:

---

Originariamente inviato da WingZero

tnx luca!

Vai pure a confrontare le architetture x86 con quelle arm

---

Eccolo lì, i saputelli peggiori, non solo esprimono la propria opinione senza il minimo rispetto per quella altrui, ma semplicemente non si curano neanche di avere capito quale sia l'opinione dell'interlocutore.

E direi che questo è un caso lampante.

Quote:

---

Originariamente inviato da TheSolutor

Eccolo lì, i saputelli peggiori, non solo esprimono la propria opinione senza il minimo rispetto per quella altrui, ma semplicemente non si curano neanche di avere capito quale sia l'opinione dell'interlocutore.

E direi che questo è un caso lampante.

---

Infatti era proprio un caso lampante, ti riassumo la tua opinione:

"Il cortex A8, fa la metà dei megaflops dello snapdragon alla stessa frequenza PERCHE' il software linpack ha delle ottimizzazioni particolari che a seconda di come viene compilato / scritto favorisce una architettura rispetto all'altra, così come succede in ambito desktop con i processori amd/intel"

Quali ottimizziazioni? Ma lo sai come funziona il bench linpack? lo sai che tipo di algoritmo è? Lo sai che se usi quell'algoritmo comunque e dove lo implementi i mflops sono sempre quasi costanti? Lo sai che in java i programmi non sono compilati?

Il raffrontoc he hai fatto non c'entra un piffero con la mia domanda.

Dai su, parli senza sapere le cose. L'ennesimo esempio del classico lamer infesta-thread. :(
Io ho posto lo stesso rispetto alla tua opinione di quanto tu ne abbia posto verso la mia. E non ho iniziato certo io ad accendere i toni. Visto che sei stato tu a "tacciarmi" per uno che non rispetta l'opinione altrui solo per averti detto, testualmente :"il confronto che hai proposto tu non c'entra nulla". Cosa assolutamente vera d'altronde.

P.S.:

Vedi che cerchi di evitare il contenuto per concentrarti sulla forma dei post. Classico sistema di chi non ha argomentazioni.
Se vuoi affermare, come hai fatto, che il linpack offre un risultato che cambia (nel senso che una volta va a favore di uno ed una volta dell'altra) a seconda di come è scritto e di come viene compilato, allora parliamone, e dimmi:
1) Che tipo di algoritmo è
2) Come si implementa
3) In che modo si potrebbe implementare per favorire uno o l'altro.

Il resto è fuffa.

Quote:

---

Originariamente inviato da WingZero

Infatti era proprio un caso lampante, ti riassumo la tua opinione:

---

Come volevasi dimostrare.



roftl

Quote:

---

Originariamente inviato da TheSolutor

Come volevasi dimostrare.



roftl

---

roftl roftl

Sono 2 post che eviti puntualmente di parlare del contenuto del thread. Argomentazioni finite. roftl

Q.E.D. roftl

Cmq parlando di argomentazioni serie, e post tecnicamente rilevanti: quanto ha detto 89luca89 è assolutamente corretto.

L'unita FP dello snapdragon sembra essere decisamente piu' performante, anche se poi perde in altro...
Sembra che sia proprio quello il motivo del basso score nel linpack, vista proprio la tipologia di algoritmo implementato.

Quote:

---

Originariamente inviato da WingZero

roftl roftl

Sono 2 post che eviti puntualmente di parlare del contenuto del thread. l

---

E' mia abitudine (da 50000 messaggi a questa parte) discutere e condividere il mio sapere con persone che lo meritino/che siano in grado di recepire, tu hai dimostrato di non rientrare ne nell'una ne nell'altra categoria.

Del contenuto del thread ho gia parlato a sufficienza, ma ai troll come te del contenuto del thread non importa un fico secco, hai lanciato una boutade per creare un po' di casino ed io sono stato talmente pollo da abboccare, rispondendoti, eccedendo (come al solito mio) in fiducia nel prossimo.

infatti il mio scopo era proprio creare casino...-.-" ma per piacere -.-"
Sono contento di aver aperto il post per aver ricevuto la risposta tecnicamente pertinente di 89luca89, era quello che speravo e come ho dimostrato quello a cui IO sono interessato.

Se ti aspetti che ognuno che ti si ponga davanti ti dia ragione, anche quando evidentemente non ce l'hai, mi disp ma non è così che va sempre. Se poi questo è un motivo per attaccare e scatenare flame non ci siamo proprio. Rileggi qualche post indietro: sei stato tu il primo ad insultare.

Se il tuo sapere è questo, felice di sapere che non vuoi condividerlo con me roftl

Buona Giornata.

P.S.:

Vedo che ancora non rispondi alle domande TECNICHE e PERTINENTI che ti ho posto prima sull'algoritmo del linpack. Se infatti ti degnassi di capire come funziona quell'agoritmo di risoluzione matematica di sistemi lineari, capiresti che non ha senso il discorso che hai fatto sull'ottimizzazione o meno...etc... -.-"
E poi sarei io il TROLL roftl

Quote:

---

Sono contento di aver aperto il posto per aver ricevuto la risposta di 89luca89

---

Guarda che leccare i piedi, da che mondo è mondo è sempre servito ad identificare i leccapiedi, a chi li si lecca e per quale motivo diviene a quel punto totalmente secondario.

Poi fai tu che sai. roftl

Quote:

---

Se il tuo sapere è questo, felice di sapere che non vuoi condividere il tuo sapere con me

---

Beh, si vede che sto sistema lo applichi da un pezzo, altrimenti non si spiega la tua condizione...

Quote:

---

Vedo che ancora non rispondi alle domande TECNICHE

---

Hahaha....

Educazione pochina, ma la faccia di bronzo non ti difetta affatto.


roftlroftlroftlroftl

Quote:

---

Originariamente inviato da TheSolutor

Guarda che leccare i piedi, da che mondo è mondo è sempre servito ad identificare i leccapiedi, a chi li si lecca e per quale motivo diviene a quel punto totalmente secondario.

Poi fai tu che sai. roftl



Beh, si vede che sto sistema lo applichi da un pezzo, altrimenti non si spiega la tua condizione...



Hahaha....

Educazione pochina, ma la faccia di bronzo non ti difetta affatto.


roftlroftlroftlroftl

---

1) leccapiedi di cosa? ho solo evidenziato il post utile e pertinente di 89luca89, che a differenza tua ha detto cose senzate e contestuali.

2) Io in che condizione sono ? roftl o madonna ragazzi...non rispondi alle domandi, non sai come funziona un algortmo di risoluzione di sistemi lineari, e poi sono io quello in pessime condizioni roftl

3) Educazione poca? Ma se sei tu quello che a piedi di argomentazioni hai iniziato ad insulatare roftl

Ma non la dovevi smettere di replicare?
Oppure rispondi alle mie domande sull'argomento.

Scegli o l'una o l'altra...

asd...

P.S.:

Il mio sapere me lo procuro da altre fonti (hai presenti i libri?) e non da personaggi come te . Che tristezza certe volte :(

Cmq questo divario tra snapdragon e cortex è nato con froyo...prima con la 2.1 il nexus faceva intorno ai 7 mflops...il milestone a 1 ghz lo batteva facilmente...è il compilatore jit di froyo che favorisce nettamente la piattaforma snapdragon (forse perche froyo è stato sviluppato e ottimizzato sul nexus)

Quote:

---

Originariamente inviato da kirkluigi

Cmq questo divario tra snapdragon e cortex è nato con froyo...prima con la 2.1 il nexus faceva intorno ai 7 mflops...il milestone a 1 ghz lo batteva facilmente...è il compilatore jit di froyo che favorisce nettamente la piattaforma snapdragon (forse perche froyo è stato sviluppato e ottimizzato sul nexus)

---

Temo che sia un'altra risposta che non troverà il gradimento del nostro amico. :-[

sicuramente è così, del resto quello che fa il jit è proprio far eseguire un sottoinsieme del bytecode dalvik direttamente in istruzioni per il processore, compilandole a tutti gli effetti.
Ed è qui che il discorso del divario tra i due si riallaccia a quanto diceva TheSolutor. Anche sullo stesso ambiente è lapalissiano che i risultati siano differenti essendo processori diversi eseguono il codice diversamente.

Le differenze erano minime prima dell'avvento del JIT, proprio perchè la VM tendeva più o meno a normalizzare i risultati visto che magari mentre un processore eccelleva in determinate istruzioni, l'altro eccelleva in quelle dove l'altro era carente (e anche se l'ambiente è virtualizzato la vm è sempre compilata quindi ci possono sempre essere differenze nella sua esecuzione in base a come è scritta e compilata).

Con il JIT il divario è aumentato perchè evidentemente su tutte quelle istruzioni su cui lavora, lo snapdragon è favorito e non mi meraviglierei nemmeno che sia una realizzazione by design del jit di favorire enormemente la compilazione delle istruzioni su snapdragon essendo il nexus il terminale di sviluppo.

Detto questo, il divario degli esempi che porti è così accentuato, perchè prima di tutto sono test fatti in ambienti a tutti gli effetti diversi, hanno rom custom, kernel diversi, addirittura nel primo esempio confronti un terminale con 2.2 con 2.1.
Per vedere in modo più preciso e serio di quanto è il divario, e fare supposizioni varie, dobbiamo creare innanzitutto due ambienti più possibile uguali, quindi già non bisognerebbe guardare proprio i risultati dei milestone (il cui kernel è e sarà sempre quello motorola), stesso sistema, stessi programmi installati, eventuali stesse ottimizzazioni al kernel ect...
Solo dopo questo possiamo confrontare i due risultati, ci sarò sempre molto probabilmente una divario ed è così che deve essere essendo processori diversi, ma non sarà uno il doppio dell'altro.

Naturalmente tutto questo non c'entra con l'algoritmo impiegato da linpack o altri, quanto piuttosto con la sua esecuzione, sapere o meno l'algoritmo che usa è inutile ai fini del tuo discorso (quello servirebbe solo se lo devi confrontare un un altro algoritmo), la descrizione matematica o la sua implementazione sarà sempre ad un livello superiore della sua esecuzione, ed è di questo che chiedevi tu no? della sua esecuzione cpu diverse.

Quote:

---

Originariamente inviato da kirkluigi

Cmq questo divario tra snapdragon e cortex è nato con froyo...prima con la 2.1 il nexus faceva intorno ai 7 mflops...il milestone a 1 ghz lo batteva facilmente...è il compilatore jit di froyo che favorisce nettamente la piattaforma snapdragon (forse perche froyo è stato sviluppato e ottimizzato sul nexus)

---

Esattamente. Avevo notato anche io questa cosa, evidentemente con il compilatore JIT il divario a causa dell'unità FP piu' potente si acuisce...

Quote:

---

Originariamente inviato da theshine

sicuramente è così, del resto quello che fa il jit è proprio far eseguire un sottoinsieme del bytecode dalvik direttamente in istruzioni per il processore, compilandole a tutti gli effetti.
Ed è qui che il discorso del divario tra i due si riallaccia a quanto diceva TheSolutor. Anche sullo stesso ambiente è lapalissiano che i risultati siano differenti essendo processori diversi eseguono il codice diversamente.

Le differenze erano minime prima dell'avvento del JIT, proprio perchè la VM tendeva più o meno a normalizzare i risultati visto che magari mentre un processore eccelleva in determinate istruzioni, l'altro eccelleva in quelle dove l'altro era carente (e anche se l'ambiente è virtualizzato la vm è sempre compilata quindi ci possono sempre essere differenze nella sua esecuzione in base a come è scritta e compilata).

Con il JIT il divario è aumentato perchè evidentemente su tutte quelle istruzioni su cui lavora, lo snapdragon è favorito e non mi meraviglierei nemmeno che sia una realizzazione by design del jit di favorire enormemente la compilazione delle istruzioni su snapdragon essendo il nexus il terminale di sviluppo.

Detto questo, il divario degli esempi che porti è così accentuato, perchè prima di tutto sono test fatti in ambienti a tutti gli effetti diversi, hanno rom custom, kernel diversi, addirittura nel primo esempio confronti un terminale con 2.2 con 2.1.
Per vedere in modo più preciso e serio di quanto è il divario, e fare supposizioni varie, dobbiamo creare innanzitutto due ambienti più possibile uguali, quindi già non bisognerebbe guardare proprio i risultati dei milestone (il cui kernel è e sarà sempre quello motorola), stesso sistema, stessi programmi installati, eventuali stesse ottimizzazioni al kernel ect...
Solo dopo questo possiamo confrontare i due risultati, ci sarò sempre molto probabilmente una divario ed è così che deve essere essendo processori diversi, ma non sarà uno il doppio dell'altro.

Naturalmente tutto questo non c'entra con l'algoritmo impiegato da linpack o altri, quanto piuttosto con la sua esecuzione, sapere o meno l'algoritmo che usa è inutile ai fini del tuo discorso (quello servirebbe solo se lo devi confrontare un un altro algoritmo), la descrizione matematica o la sua implementazione sarà sempre ad un livello superiore della sua esecuzione, ed è di questo che chiedevi tu no? della sua esecuzione cpu diverse.

---

I 2 video su youtube sono entrmbi con android 2.2
E gli altri non sono esempi che ho portato io ma è il sito ufficiale dove si raccolgono i risultati del linpack.
Concordo che servirebbe stesse identico sistema e rom per confrontare i risultati ma sostanzialmente punto percentuale in più o meno i vede che con il milestone si raggiunge a fatica i 20 mflops e con il nexus one si supera abbondandemente i 40.

La mia domanda era semplicemente capire a livello hardware quali erano le differenze che portavano ad un distacco così sostanziale.
L'implementazione dell'algortimo centra nella misura in cui questo vada ad eseguire alcune istruzioni piuttosto che altre, ed è partendo da ciò che si puo' analizzare il comportamento differente dei 2 processori.

Ovviamente è assurdo a mio modo di vedere, ipotizzare che la VM compilata nel FW del milestone non abbia alcune ottimizzazione che ha la VM nel nexus one. (perchè thesolutor è di questo che stava parlando quando si riferiva al compilatore intel: chi è del campo sa che il compilatore ottimizzato intel, semplicemente, quando riconosce una cpu amd non inserisce alcuni flag non effettuando delle ottimizzazione specifiche de andrebbero fatte su tutte le cpu x86).
E' altrettanto assurdo far ricadere la colpa solo su una presunta ottimizzazione rispetto ad una cpu piuttosto che di un altra della VM: chi ha sviluppato qualcosa che non sia composto da 3 righe di codice sa che una differenza del genere, con un algoritmo a basso livello quale il linx, non puo' essere ricondotta a ciò.

Quote:

---

Originariamente inviato da WingZero

(perchè thesolutor è di questo che stava parlando

---

Il compilatore Intel l'hai tirato fuori tu, fino a prova contraria (scripta manent grazie al cielo).

Quote:

---

Originariamente inviato da TheSolutor

Il compilatore Intel l'hai tirato fuori tu, fino a prova contraria (scripta manent grazie al cielo).

---

Grazie al cielo!

Quote:

---

Originariamente inviato da TheSolutor

I sw ed i compilatori non sono mai politically correct

---

Quote:

---

Originariamente inviato da TheSolutor

sto parlando di amd v.s. intel sotto linux e sotto windows e dello sbalzo enorme che c'è tra i due confronti.

---

Sei fazioso oltre ogni limite! E ti smentisci ogni volta negando quello che hai detto ogni 5 minuti!

Che roba ragazzi :/

Vabbè, vado a nanna che domani mi devo alzare presto e sto fuori tutta la giornata, quindi non penso di poter replicare.

Quote:

---

Originariamente inviato da WingZero

Che roba ragazzi :/

---

Intendi quella che ti sei fumato oggi ? roftl

Quote:

---

Originariamente inviato da TheSolutor

Intendi quella che ti sei fumato oggi ? roftl

---

No intendo a quella che ti sei fumato tu roftl

Quote:

---

Originariamente inviato da TheSolutor

I sw ed i compilatori non sono mai politically correct
[CUT]
sto parlando di amd v.s. intel sotto linux e sotto windows e dello sbalzo enorme che c'è tra i due confronti.

---

E poi 2 ore dopo:

Quote:

---

Originariamente inviato da TheSolutor

Il compilatore Intel l'hai tirato fuori tu, fino a prova contraria

---

roftl roftl roftl

Ti prego rispondi di piu' ai miei thread, mandami qualche pm, che mi fai spisciare troppo dalle risate! roftl

Quote:

---

Originariamente inviato da WingZero

Ti prego rispondi di piu' ai miei thread, mandami qualche pm, che mi fai spisciare troppo dalle risate! roftl

---

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...