Microsoft Windows XP 64 bit: ormai manca poco!

[repne scasb]

[cdimauro]

Originariamente inviato da Banus
Questa è una cosa che non mi è ancora chiara: ho visto da alcune fonti (Arstechnica, Anandtech) che si paga un 10% in spazio per il codice a 64 bit dell'Athlon64, ma non mi è chiaro se è riferito a tutto il codice o a solo alle parti specifiche a 64 bit.

A mio avviso questo discorso dovrebbe riferirsi esclusivamente alle parti in cui, appunto, è necessario aggiungere il byte di prefisso (per usare gli altri 8 registri e/o per forzare i 64 bit). Negli altri casi è chiaro che non risulta necessario alcun prefisso.

Arstechnica parla di un byte di overhead (su 4 del codice a 32 bit) per le istruzioni a 64.

Che io sappia la lunghezza media delle istruzioni in un codice a 32 bit si aggira attorno ai 2 byte e non a 4.

D'altra parte con meno accessi alla memoria mi aspetterei meno istruzioni, che quindi controbilancerebbero l'overhead.

E' quel che penso anch'io, e il codice di repne scasb mi sembra che lo dimostri: il codice (lo spazio totale) dovrebbe essere mediamente più "corto".

Quindi il 10% è ottenuto dal confronto fra codici compilati (= test), o è una stima basata sulla ricorrenza media di un certo tipo di istruzione?

Penso che sia una stima, ma vedi sopra: o si tratta di una stima errata oppure l'argomento è ristretto solamente nei casi d'uso di cui sopra (registri R8-15 e/o 64 bit).

[cdimauro]

Originariamente inviato da Onda Vagabonda
Però ragazzi il prodotto non è ancora uscito è già fate tutto questo gran casino, oppure dovrei usare un termine politicaly correct come rumors...

Rumor i nostri? Scusa, ma mi sento offeso da questa tua affermazione: mi sembra evidente da tutto ciò che abbiamo scritto che nessuno qui aveva voglia di riscrivere la Divina Commedia basandosi soltanto su dei "rumor".

Salvataggio registri, ripristino registri, profiling dei codici, routine di clock medi, confronti paralleli fra architettura a 32 bit e a 64 bit... tutto questo sulla versione beta?
Magari la versione beta è un ibrido (modello formula 1) e la versione definitiva sarà totalmente diversa, senza contare gli aggiornamenti iniziali...

Una beta può anche subire molti cambiamenti fino alla versione finale, ma generalmente non tali da stravolgere il prodotto finale. Comunque in questo momento è disponibile una RC1 di XP/64, e il prodotto finale è previsto per il 29 aprile: penso che da qui ad allora i cambiamenti saranno pochi, principalmente orientati ai bug fix ed eventualmente all'integrazione di driver.

[repne scasb]

[repne scasb]

[cdimauro]

Originariamente inviato da repne scasb
Se avesse scritto: "*res = res1 | res2;", nonostante tutto, il codice a 64-bit non sarebbe stato "fortemente" avvantaggiato rispetto al codice a 32-bit (nonostante le variabili a 64-bit)

Concordo: le differenze sarebbero state poche

Prendi il tutto con le "pinze", sono solo alcune prove che ho eseguito in mode_64. Potrei aver preso un abbaglio clamoroso. C'e' da dire pero' che quanto ho esposto in quella vecchia discussione "spiegherebbe" perche' alcuni software hanno un incremento di prestazioni a 64-bit nonostante si possa supporre che nel passaggio da 32 a 64 non ci sia stato alcun beneficio prestazionale dovuto all'ISA. E' curioso notare come nessun sito prestigioso "compreso Hardware Upgrade" abbia indagato sufficientemente su quest'aspetto. Ossia, domanda: "Nonostante le prestazioni "elevate" fatte registrate da un Athlon64 in PM_32, e' possibile che in realta' stia funzionando "con il freno a mano inserito" (<--"locuzione esagerata")?

Prendo sempre tutto con le pinze.

Comunque un eventuale "freno a mano" per l'esecuzione di codice a 32 bit mi sembra strano. Dico ciò perché penso che il principale interesse di un ingegnere che progetta un microprocessore dovrebbe essere quello di semplificarne il design, ma soprattutto di non complicarsi la vita aggiugendogli altri circuiti. Infatti se le differenze fossero volute, significherebbe che gli ingegneri avrebbero aggiunto dei controlli e limitato alcune sezioni del processore in base alla modalità d'esecuzione: si tratta sicuramente di modifiche non banali.

Per questo dicevo che sarebbe interessante chiarire la vicenda, magari facendo altri test. Se alcune differenze dovessero saltare fuori, probabilmente saranno dovute a dei fattori contingenti piuttosto che al "malvagio" disegno di qualche perverso ingegnere...
Tutto ciò IMHO, chiaramente.

[repne scasb]

[Banus]

Originariamente inviato da repne scasb
E' una routine che fa uso di dati a 8-bit, sembrerebbe "non" l'ideale per una CPU a 64-bit, ma qui "spunta" una curiosa caratteristica: l'Athlon64 "sembrerebbe" essere in grado di utilizzare "forzature" di opcode senza pagare penalizzazioni

Il codice non l'ho osservato attentamente perchè non ho molta dimestichezza con l'assembler x86
Comunque mi ricordo che ne parlavi nell'altro thread, è una caratteristica molto interessante.

[cdimauro]

Originariamente inviato da repne scasb
Pensavo, che non c'era d'aspettarsi un qualche aumento dovuto all'ISA a 64-bit. Invece, sembra proprio di si. Non mi era nota questa caratteristica (desumo che i database si siano molto evoluti negli ultimi anni).

Si sono evoluti non solo i database, ma anche le esigenze degli utenti: non è raro avere clienti che hanno database che superano i 4GB di spazio e/o che abbiano già superato da tempo i 4 miliardi di "movimenti" (movimento = acquisto o vendita di un singolo pezzo).
In particolare i clienti trovano MOLTO comodo poter modificare, ad esempio, una fattura (anche radicalmente ), per cui piuttosto che perdere tempo a scrivere del codice piuttosto "contorto" per tenere traccia degli ID associati a ogni movimento e "riciclarli" durante la modifica, trovo più semplice e immediato cancellare quelli "vecchi" e generarne di "nuovi" all'interno della transazione che chiude l'operazione di modifica.
E' evidente che tutto ciò facilita notevolmente la creazione di "buchi" per quanto riguarda gli ID, da cui deriva la necessità di utilizzare ID a 64 bit anziché a 32 bit.
Un tempo si faceva di tutto per cercare di non usare valori a 64 bit, riutilizzando gli ID, appunto, oppure andando a cercare qualche buco (magari lasciato da un'operazione di cancellazione vera e propria): si spostava la complessità sulle spalle del programmatore (croce e delizia. Croce, SOPRATTUTTO ).

La capacità dei dispositivi di massa e la potenza di elaborazione a disposizione, che permette di manipolare quantità a 64 bit senza subire forti penalizzazioni, ha cambiato radicalmente il modo di lavorare sia dei database sia dei programmatori che ci sviluppano delle applicazioni.

[cdimauro]

Originariamente inviato da repne scasb
Sono perplessa, in effetti sembra una stranezza. Ma: quante stranezze si sono viste nel campo delle architetture delle CPU? L'elenco e' in effetti non lungo ma esistente.

Concordo.

PS. Ricordo ancora, ad esempio, le istruzioni per l'estrazione di campi bit presenti nelle primissime revisioni dei 486, ma sparite del tutto in quelle successive...

[GiovanniGTS]

[b]Originariamente inviato da Onda Vagabonda
Però ragazzi il prodotto non è ancora uscito è già fate tutto questo gran casino, oppure dovrei usare un termine politicaly correct come rumors...

Originariamente inviato da cdimauro
Rumor i nostri? Scusa, ma mi sento offeso da questa tua affermazione: mi sembra evidente da tutto ciò che abbiamo scritto che nessuno qui aveva voglia di riscrivere la Divina Commedia basandosi soltanto su dei "rumor".

A me invece questa sembra una delle più belle discussioni che si possano trovare sull'argomento!
Forse una delle più belle su questo forum!

Grazie!

[capitan_crasy]

Originariamente inviato da GiovanniGTS
A me invece questa sembra una delle più belle discussioni che si possano trovare sull'argomento!
Forse una delle più belle su questo forum!

Grazie!

quoto

[cdimauro]

Originariamente inviato da repne scasb

Prendendo queste due routine che hai scritto (e che ho riportato sotto), fissando tre semplici condizioni posso azzardare una dimostrazione formale che l'esecuzione del codice a 32 bit è SEMPRE più lento di quello a 64 bit.

Le condizioni sono:
- che il codice (dal push degli argomenti alla fine della routine) stia interamente nella cache L1;
- che non si verifichi nessuna interruzione (nemmeno un page fault o eccezione) dal codice che esegue il push dei parametri fino alla prima istruzione (esclusa) della routine;
- che non si verifichi nessuna interruzione ESTERNA (i page fault e le eccezioni generate dal processore sono ammessi) dalla prima istruzione delle routine all'ultima.

Mi sembrano condizioni "ragionevoli" e che, IMHO, stanno ampiamente "nella media".

;	Mode: PM_32
;	Ottimizzazione: Nessuna

;	Codice per salvattaggio dei registri

	mov	eax,[arg1_low]
	mov	edx,[arg1_hi]
	mov	ebx,[arg2_low]
	mov	ecx,[arg2_hi]
	mov	esi,eax
	mov	edi,edx
	sub	esi,ebx
	sbb	edi,ecx
	add	ebx,eax
	adc	ecx,edx
	mul	ecx
	mov	eax,ecx
	mov	eax,edi
	mul	ebx
	add	ecx,eax
	mov	eax,esi
	mul	ebx
	add	edx,ecx
	mov	[result_low],eax
	mov	[result_hi],edx

;       Codice di ripristino dei registri

-----------------------------------------

;	Mode: PM_64
;	Ottimizzazione: Nessuna

;	Codice per salvattaggio dei registri

	mov	rax,[arg1]
	mov	rbx,[arg2]
	lea	rcx,[rax+rbx]
	sub	rax,rbx
	mul	rcx
	mov	[result],rax

;       Codice di ripristino dei registri

Per adesso tralascio la dimostrazione: se qualcuno volesse cimentarsi, è libero di farlo.

Per quanto riguarda l'altro esempio (quello con i pushad e la chiamata a routine), posso fornire un'altra dimostrazione simile, aggiungendo un'altra condizione abbastanza "ragionevole" e "nella media".

[repne scasb]

[Banus]

Originariamente inviato da cdimauro
Mi sembrano condizioni "ragionevoli" e che, IMHO, stanno ampiamente "nella media".

Proprio sulla possibilità del punto 2) e 3) si basava il discorso di fek

I punti 1), 2) e 3) garantiscono che la somma dei tempi di esecuzione delle singole istruzioni corrisponde al tempo di esecuzione della routine.
Incidenza degli accessi in memoria:i punti 2), 3) garantiscono che i dati si trovano in cache.
Assunzione (sicuramente verificata nell'Athlon64): due accessi a 32 bit sono più lenti di un singolo accesso a 64 bit, dalla cache.
Resta solo da valutare, calcolatrice alla mano , l'incidenza del salvataggio dei registri (a 64 bit sono in numero maggiore e più grandi).

Non è una dimostrazione formale ma una traccia di come affronterei il problema

[repne scasb]

[gabido]

Speriamo che non ci vogliano un mouse con quattro palle, un processore da 1000000 Mhz, 100000000 Mb di RAM DDR1000 per farlo "girare" decentemente....
ed un hd a 200000 rpm per caricarlo senza doversi addormentare sulla tastiera per l'attesa...

[Helstar]

Gabido: ti serve 'solo' un Athlon64 (o uno Xeon con le estensioni a 64bit). Per favore le buffonate altrove, che gia' in questo thread se ne sono visti troppi di clown ... e visto l'eccelso livello di discussione (*inchin* *inchin* *nsd* *nsd*) cerchiamo di non rovinare questo fantastico thread !

[fek]

Originariamente inviato da cdimauro
Prendendo queste due routine che hai scritto (e che ho riportato sotto), fissando tre semplici condizioni posso azzardare una dimostrazione formale che l'esecuzione del codice a 32 bit è SEMPRE più lento di quello a 64 bit.

E' questo il mio punto, e non si tratta di parlare lingue diverse, ma di sapere di che cosa si sta parlando oppure no, oppure di essere in malafede

Puoi riuscire a dimostrare che quel particolare pezzo di codice a 64 bit e' sempre piu' veloce a livello teorico, ma poi lo metti in condizioni reali, ne misuri le prestazioni e ti accorgi che nella realta' pratica difficilmente riuscirai a notare differenze prestazionali.

E' ovvio, che se qualcuno e' in malafede, puo' semplicemente buttare il codice in un inner loop e cercare di dimostrare anche che gli asini volano, ma il mio discorso e' sempre stato il seguente:
in condizioni di esecuzione normale, e' difficile che si possano apprezzare differenze perche' di solito quel codice e' memory bound.

In altre parole, se l'ambiente in cui quelle istruzioni sono eseguite contiene molte altre istruzioni e molti altri accessi ai dati, e' molto probabile che i dati per quelle istruzioni non saranno in cache e la CPU si trovera' ad attendere l'arrivo dei dati su cui operare per la maggior parte del suo tempo, rendendo del tutto vano il risparmo di istruzioni. Questa e' la situazione tipica, un inner loop non e' la situazione tipica.

Spero di essere stato piu' chiaro ora, e a chi pensa di parlare una lingua diversa dalla mia, consiglio di imparare prima l'italiano

[fek]

Originariamente inviato da Banus
Proprio sulla possibilità del punto 2) e 3) si basava il discorso di fek

Il mio discorso si basa sulla singola esecuzione di quella funziona in un contesto nel quale i dati su cui opera non sono in cache.

In questo contesto, che e' il piu' probabile, le due versioni saranno molto probabilmente perfettamente equivalenti, e non certo una sicuramente piu' veloce dell'altra.

Ho poi aggiunto che in generale (e non solo nel caso particolare) non ha senso parlare di funzioni sicuramente piu' veloci di altre perche' va prima analizzato l'ambiente nel quale vengono eseguite.