cicli nidificati: è più veloce un p4 2,4 Ghz o un E6300?

[fabbius69]

Spesso uso dei programmi in ms-dos con molti cicli nidificati per fare dei calcoli matematici, ora posseggo un pentium 4 da 2,4 Ghz (18x133), con molti programmi implementate da me ci mettono circa 40 minuti per completare il run, ora se acquisto un nuovo pc con il processone E6300 avendo una velocità di 1,866 Ghz teoricamente ci dovrei mettere di più??? oppure essendo un core 2 duo con 2 mb L2 potrebbe andare più veloce????

Mi serve una risposta, ho paura di sbagliare processore per il mio futuro pc :mc:

[mad_hhatter]

intanto lascia perdere la pura frequenza di clock: quello che conta è il numero di istruzioni per ciclo di clock e il core 2 duo è sicuramente più efficiente del p4... a titolo di cronaca ho un fisso p4 2.6GHz e un portatile con pentium M 1.86GHz (quindi precedente al core 2 duo): tempo fa ho scritto un programma che conteneva algoritmi di geometria computazionale... risultato: lo stesso problema veniva risolto dal pentium M in META' tempo rispetto al pentium 4 (poco meno di 1 minuto per im PM, poco più di 2 minuti il p4)... ovvio, sono dati un po' alla caxxo, ma significativi

in più sicuramente col core 2 duo hai ram e fsb più veloci

[fabbius69]

Grazie :mano:

[jappilas]

intanto lascia perdere la pura frequenza di clock: quello che conta è il numero di istruzioni per ciclo di clock e il core 2 duo è sicuramente più efficiente del p4... a titolo di cronaca ho un fisso p4 2.6GHz e un portatile con pentium M 1.86GHz (quindi precedente al core 2 duo): tempo fa ho scritto un programma che conteneva algoritmi di geometria computazionale... risultato: lo stesso problema veniva risolto dal pentium M in META' tempo rispetto al pentium 4 (poco meno di 1 minuto per im PM, poco più di 2 minuti il p4)...siccome il pentium M non ha inerentemente un' efficienza media doppia rispetto a quella dei un processore netburst di frequenza superiore , direi che hai beccato una situazione peculiare...
sarebbe interessante avere un' idea più precisa dell' algoritmo, e delle condizioni di contorno (compilatore, profilo di ottimizzazione usato, ottimizzazioni nel codice, eccetera) per fare un po' di profiling :)

[mad_hhatter]

siccome il pentium M non ha inerentemente un' efficienza media doppia rispetto a quella dei un processore netburst di frequenza superiore , direi che hai beccato una situazione peculiare...
sarebbe interessante avere un' idea più precisa dell' algoritmo, e delle condizioni di contorno (compilatore, profilo di ottimizzazione usato, ottimizzazioni nel codice, eccetera) per fare un po' di profiling :)

come ho specificato, quello che ho postato non voleva e non poteva essere un benchmark, voleva solo dimostrare che un PM PUO' essere più veloce di un P4 anche se quest'ultimo ha frequenza di clock superiore. In ogni caso, l'architettura del PM è sicuramente più efficiente di quella del P4, mi pare in rete ci siano benchmark a supporto di questa tesi.

[jappilas]

come ho specificato, quello che ho postato non voleva e non poteva essere un benchmark, voleva solo dimostrare che un PM PUO' essere più veloce di un P4 anche se quest'ultimo ha frequenza di clock superiore. In ogni caso, l'architettura del PM è sicuramente più efficiente di quella del P4, mi pare in rete ci siano benchmark a supporto di questa tesi.non hai bisogno di dimostrarmelo, so che il livello di efficienza normalizzato a pari frequenza è maggiore, e anche il perchè :)
ma proprio per questo mi chiedevo se nel tuo programma ad esempio fossero presenti molti salti, che un p4 soffirrebbe più di un PM e giustificherebbero una disparità prestazionale maggiore rispetto a quella che (se non erro) sussiste tra i rispettivi livelli di efficienza su codice normale...

[mad_hhatter]

non hai bisogno di dimostrarmelo, so che il livello di efficienza normalizzato a pari frequenza è maggiore, e anche il perchè :)

mi spieghi il perchè perfavore (se non ci vuole troppo)?

ma proprio per questo mi chiedevo se nel tuo programma ad esempio fossero presenti molti salti, che un p4 soffirrebbe più di un PM e giustificherebbero una disparità prestazionale maggiore rispetto a quella che (se non erro) sussiste tra i rispettivi livelli di efficienza su codice normale...

come ho detto, il test era alla cazzo perchè troppe cose erano diverse: java 1.4.2 sul p4, java5 sul pM, sistema (win xp sp2) molto ben tenuto sul portatile, sistema (win xp sp2) un po' trasandato sul p4... troppe variabili da normalizzare per poter fare un confronto serio, ma il risultato era, per me, abbastanza degno di nota... l'algoritmo in questione me lo ricordo a spanne... MI PARE che, presa in input una bitmap e trasformata in una matrice di char, l'algoritmo trovasse i bordi dei singoli oggetti in essa contenuti e li orientasse in senso antiorario sfruttando maschere di pixel 3x3 e sì, forse faceva molti salti, ma vado troppo a memoria

[jappilas]

mi spieghi il perchè perfavore (se non ci vuole troppo)? elementi strutturali del P4 frutto di una certa impostazione di progetto e in qualche caso di compromessi, quali:
il decoder a monte della cache L1I , ma non superscalare (quindi, una sequenza di istruzioni x86 non decodificate, deve attraversare la pipeline del front end /decoder una alla volta - laddove un A64 carica e decodifica, producendo anche un paio di risc-ops per ognuna, 3 istruzioni X86 per ciclo e Core fino a 4);
la cache L1I execution trace, che pur essendo progettata per una dimensione della singola linea e del buffer di uscita, pari a 6 ( in termini di microops) , quelle che effettivamente può produrre diventano 3 sul northwood (*) e poi 4 sul prescott per via di una riorganizzazione della ETC (16k uops in linee da 4 piuttosto che 12k in linee da 6), sempre però pari o al di sotto delle microistruzioni risc-type che vengono inviate a valle del decoder in architetture come quelle più recenti, in cui l' esecuzione e in certi casi lo scheduling, avviene su gruppi di microistruzioni aggregate (che però non vengono bufferizzate ma, ridecodificate qualora il codice debba essere rieseguito) ... quindi con una ipc media tendenzialmente maggiore;
la rom a sequenziazione di microcodice, che per le istruzioni X86 complesse bypassa la ETC e il decoder per alimentare una singola ALU dedicata (quindi se incontra un' istruzione X86 di tipo complesso P4 diventa per qualche ciclo un processore inorder non superscalare)
l' unità sse/floating point a una sola via ma a doppia frequenza come le alu intere, e interleaved (secondo alcuni documenti, su altri è riportata una sola porta tra l' unità e la reservation station) - cosa che inficia particolarmente l' esecuzione di sezioni di codice basato su istruzioni X87 (floating point legacy) e MMX, rispetto agli altri processori , e il modo per ottimizzare l' esecuzione di SW che debba effettuare operazioni matematiche o anche di manipolazione di blocchi di dati (forzando l' uso delle SSE)
Poi si aggiungono quelle che potrebbero essere le conseguenze ("bolle") del maggior numero di stadi nell' intervallo tra le fasi di trace ed execute in caso di salto condizionale e dell' assenza dello stadio di ripristino (presente sugli AMD, non mi pare però su Core)...
tutto semplificando e a meno di memory fading del mio neurone ( esaminai netburst qualche anno fa, il fading è in agguato), ma spero di aver dato almeno un' idea :)
come ho detto, il test era alla cazzo perchè troppe cose erano diverse: java 1.4.2 sul p4, java5 sul pM, sistema (win xp sp2) molto ben tenuto sul portatile, sistema (win xp sp2) un po' trasandato sul p4... troppe variabili da normalizzare per poter fare un confronto serio, ma il risultato era, per me, abbastanza degno di nota... in effetti sì ... quantomeno per le prestazioni dell' "insieme A" a confronto con quelle dell' "insieme B" con "insieme" l' abbinamento di "ambiente" e archiettura) , anche se in genere un test è tanto più indicativo quanto più omologo è l' "ambiente" per il primo e per il secondo soggetto ;)

[mad_hhatter]

elementi strutturali del P4 frutto di una certa impostazione di progetto e in qualche caso di compromessi, quali:
il decoder a monte della cache L1I , ma non superscalare (quindi, una sequenza di istruzioni x86 non decodificate, deve attraversare la pipeline del front end /decoder una alla volta - laddove un A64 carica e decodifica 3 istruzioni X86 per ciclo e Core fino a 4);
la cache L1I execution trace, che pur essendo progettata per una dimensione della singola linea e del buffer di uscita, pari a 6 ( in termini di microops) , quelle che effettivamente può produrre diventano 3 sul northwood (*) e poi 4 sul prescott per via di una riorganizzazione della ETC (16k uops in linee da 4 piuttosto che 12k in linee da 6), sempre però pari o al di sotto delle microistruzioni risc-type che vengono inviate a valle del decoder in architetture come quelle più recenti in cui l' esecuzione e in certi casi lo scheduling, avviene su gruppi di microistruzioni aggregate (che però non vengono bufferizzate ma, ridecodificate qualora il codice debba essere rieseguito) ... quindi con una ipc media tendenzialmente maggiore;
la rom a sequenziazione di microcodice, che per le istruzioni X86 complesse bypassa la ETC e il decoder per alimentare una singola ALU dedicata (quindi se incontra un' istruzione X86 di tipo complesso P4 diventa per qualche ciclo un processore inorder non superscalare)
l' unità sse/floating point a una sola via ma a doppia frequenza come le alu intere, e interleaved (secondo alcuni documenti, su altri è riportata una sola porta tra l' unità e la reservation station) - cosa che inficia particolarmente l' esecuzione di sezioni di codice basato su istruzioni X87 (floating point legacy) e MMX, rispetto agli altri processori , e il modo per ottimizzare l' esecuzione di SW che debba effettuare operazioni matematiche o anche di manipolazione di blocchi di dati (forzando l' uso delle SSE)
Poi si aggiungono quelle che potrebbero essere le conseguenze del maggior numero di stadi nell' intervallo tra le fasi di trace ed execute in caso di salto condizionale ...
tutto semplificando e a meno di memory fading del mio neurone ( esaminai netburst qualche anno fa, il fading è in agguato), ma spero di aver dato almeno un' idea :)
in effetti sì ... quantomeno per le prestazioni dell' "insieme A" a confronto con quelle dell' "insieme B" con "insieme" l' abbinamento di "ambiente" e archiettura) , anche se in genere un test è tanto più indicativo quanto più omologo è l' "ambiente" per il primo e per il secondo soggetto ;)

ti ringrazio, mi hai dato ben più di "un'idea" :) anche perché molte delle cose che hai detto le comprendo a livello intuitivi ma non ne ho conoscenza approfondita (tranquillo, non ti sto chiedendo di spiegarmi l'architettura di una cpu moderna reale, so dove reperire le info dettagliate, se e quando avrò tempo :) )

per il test, è appunto un tentativo di confrontare mele e pere quindi ha poco significato, solo che la differenza prestazionale era tale da permettermi di ricordarmela :D