Microsoft Windows XP 64 bit: ormai manca poco!

Microsoft Windows XP 64 bit: ormai manca poco!

Negli ultimi giorni vari rumors segnalano come data di rilascio per il nuovo windows a 64bit, il 29 Aprile. Per ingannare l'attesa Microsoft ha distribuito una versione trial che, stando a vari commenti raccolti in rete, appare abbastanza matura e non ha creato particolari problemi nel riconoscimento

di pubblicata il , alle 17:23 nel canale Programmi
MicrosoftWindows
 
211 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
cdimauro01 Febbraio 2005, 10:37 #161
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).
cdimauro01 Febbraio 2005, 10:44 #162
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 scasb01 Febbraio 2005, 10:55 #163
repne scasb01 Febbraio 2005, 11:00 #164
cdimauro01 Febbraio 2005, 11:03 #165
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 scasb01 Febbraio 2005, 11:08 #166
Banus01 Febbraio 2005, 11:14 #167
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.
cdimauro01 Febbraio 2005, 11:20 #168
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.
cdimauro01 Febbraio 2005, 11:24 #169
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...
GiovanniGTS01 Febbraio 2005, 13:13 #170
[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!

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
 
^