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
 
I migliori sconti su Amazon oggi

AMAZFIT Active 2 Smart Watch 44mm, AI, Controllo Vocale, GPS e Mappe incluse, Batteria da 10 Giorni, 160+ Modalità Sportive, Resistente allAcqua 5 ATM per Android e iPhone, Nero

Compra ora

TCL 55T6C 55" QLED TV 4K HDR, Fire TV (Smart TV con Dolby Vision e Atmos, HDR10+, Premi e Chiedi ad Alexa)

Compra ora
211 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
Dobermann7531 Gennaio 2005, 21:28 #141

Re: Non facciamo confusione...

Originariamente inviato da NemesisQ3A
Gli applicativi a 32bit gireranno quasi tutti anche in ambiente 64bit, questa è una caratteristica fondamentale dei processori compatibili con x86_64.
Esistono infatti 3 modalità di esecuzione possibile:
- applicazioni 32bit in ambiente 32bit.
- applicazioni 32bit in ambiente 64bit.
- applicazioni 64bit in ambiente 64bit.
Chiaramente fanno discorso a se i drivers, che devono essere progettati espressamente per la nuova architettura.
TRA AMD64 e INTEL EMT64 non esistono particolari differenze, quindi questa versione di Windows girerà perfettamente con entrambe.
L'altra versione di Windows a 64bit era pensata per il supporto agli Itanium e Itanium2, basati su architettura IA64.

Comunque direi che sarebbe anche l'ora che questo sistema operativo uscisse, l'aspetto da più di un anno...


Ciao, sai come và a compatibilità con le varie periferiche?
ad esempio,lo si può impostare a 32 bit per caricare i driver delle stampanti, scanner (ad es.: epson cx6600) macchine fotografiche
che per ora non hanno driver x 64bit?
repne scasb31 Gennaio 2005, 21:31 #142
DioBrando31 Gennaio 2005, 21:35 #143
Originariamente inviato da repne scasb
Per quello che ho compreso, provo ad aiutarti a comprendere.

E l'utente "fek" ha ragione.

E qui si e' sbagliato. Ha postato, l'"UNICO" codice che a causa di una moltiplicazione in un codice ridotto quanto a complessita', e' piu' veloce a 64-bit indipendentemente dall'architettura della CPU (Athlon64 nello specifico); cio' perche' a 64-bit c'e' un istruzione "nativa" per fare le moltiplicazioni a 64-bit.

Qui, l'utente "fek", si e' sbagliato a postare il codice assembly (come da lui stesso ammesso), che non e' equivalente al codice C(++).

Sono d'accordo su (A), per (C) ha ammesso l'errore (umano chiaramente, tutti possiamo sbagliare a copiare, ma pochi non sono in grado di accorgenese dopo DUE note (alla terza di cdimauro se ne e' accorto)), per (B) non ci siamo capiti, "credo".


quindi diciamo che è un problema di forma...e cioè che ha sbagliato a postare il codice ma nella sostanza ha ragione nel dire che rimanendo sul codice appunto, da 32 a 64 bit non vi sn incrementi sostanziali.



Però nel momento in cui affermi che per fare una moltiplicazione a 64 bit nei 64bit basta una sola istruzione invece che 3 istruzioni (come per i 32bit), n affermi implicitamente, invece, che alcune differenze sostanziali ( in meglio), al di là dell'archittettura esistono?

P.S.: in tutto questo il profiling, cosa c'entra/che ruolo ha?

Thx per le delucidazioni
Banus31 Gennaio 2005, 21:47 #144
Originariamente inviato da DioBrando
P.S.: in tutto questo il profiling, cosa c'entra/che ruolo ha?

C'entra perchè in programmi complessi (praticamente tutti quelli di interesse) non è mai evidente il legame fra istruzioni e velocità di esecuzione. Un esempio interessante è quello della lookup table già citato da fek: ti aspetti che precalcolando i valori di una funzione risparmi cicli macchina, e scopri invece che aumenta i cache miss portando a un rallentamento globale.

Il profiling serve appunto per individuare i punti in cui il programma "perde più tempo" e intervenire solo su quelli. E' inutile ad esempio ottimizzare il codice del menu iniziale di un programma DOS, 1ms o 1 ns non fanno differenza per l'utente. Invece si cercano le sezioni di codice "critiche" in modo da concentrare gli sforzi solo su quelle.
repne scasb31 Gennaio 2005, 21:49 #145
DioBrando31 Gennaio 2005, 22:17 #146
Originariamente inviato da Banus
C'entra perchè in programmi complessi (praticamente tutti quelli di interesse) non è mai evidente il legame fra istruzioni e velocità di esecuzione. Un esempio interessante è quello della lookup table già citato da fek: ti aspetti che precalcolando i valori di una funzione risparmi cicli macchina, e scopri invece che aumenta i cache miss portando a un rallentamento globale.

Il profiling serve appunto per individuare i punti in cui il programma "perde più tempo" e intervenire solo su quelli. E' inutile ad esempio ottimizzare il codice del menu iniziale di un programma DOS, 1ms o 1 ns non fanno differenza per l'utente. Invece si cercano le sezioni di codice "critiche" in modo da concentrare gli sforzi solo su quelle.


ora mi è + chiaro l'esempio di fek grazie
DioBrando31 Gennaio 2005, 22:24 #147
Originariamente inviato da repne scasb
Si, e' cosi', a meno di casi particolari. (MODIFICA). A scanso di equivoci: nell'athlon 64 dal passaggio da 32 a 64 bit gli incrementi prestazionali ci sono, non dipendono dai 64-bit, ma dal diverso "modo" (piu' efficiente) di funzionare a 64-bit (leggere il link che ho postato alcuni messaggi indietro). Io, chiamo cio' architettura. Se non sono chiara posso sppiegare ulteriormente.


No, no chiarissima...aggiungo un'ipotesi/considerazione...è anche per questo motivo che l'esecuzione di codice a 32bit è molto efficiente negli Athlo64/Opteron rispetto ad architetture in qlc modo affini ma a 32bit, forse? ( penso agli Xp)

E' una obiezione sensata. Tento una risposta sensata: nel primo quote ti ho risposto: "Si, e' cosi', a meno di casi particolari."
Domanda: una moltiplicazione a 64-bit e' o non e' un caso particolare? (attenzione moltiplicazione di interi a 64-bit non a 32).
Non ho una casistica dettagliata, quindi ti dovrai accontentare di una mia casistica personale accumulata nel tempo: mi sara' capitato 2-3 volte di fare una moltiplicazione con interi a 64-bit (uso nel caso un float double extended a 80-bit), quindi "PER ME" e' un caso particolare. E' poi assolutamente possibile che magari esista un qualche software che esegue una "montagna" di moltiplicazioni a 64-bit, in quest'ultimo caso i 64-bit vincono sui 32-bit indipendentemente dall'architettura (qui ricare l'esempio "sofrtunato" dell'utente "fek".


adesso mi è anche + chiaro quello che intendi per esempio sfortunato.

Altra domanda...è possibile che sw come quelli utilizzati nei tests du database e rendering 3D che si avvantaggiano non di poco dei 64bit, debbano queste prestazioni così "eclatanti" proprio all'istruzione di cui tu fai menzione?
Perchè almeno per come lo ricordi io i DB usano massicciamente gli interi...

Il "profiling" consiste nella valutazione di quali sezione di un codice, richiedano piu' meno tempo macchina per l'esecuzione. Si esegue attraverso un opportuno software (Profiler). Tale software e' in grado di "evidenziare" dove il codice e' lento o dove e' piu' conveniente "agire" se si vogliono migliorare le prestazioni di un codice.

Nel caso specifico di questa discussione, e' irrilevante, in quanto non necessario. Per valutare le prestazioni del codice assembly 32 contro 64 provenienti dal codice di alto livello postato dall'utente "fek" e necessario solo l'istruzione RDTSC e non importa sapere "punto per punto" come si comporta la routine. So che la routine a 64-bit e' mediamente il 319% piu' veloce. STOP.


capito, grazie anche a te
repne scasb31 Gennaio 2005, 23:26 #148
capitan_crasy31 Gennaio 2005, 23:32 #149

Re: Re: Non facciamo confusione...

Originariamente inviato da Dobermann75
Ciao, sai come và a compatibilità con le varie periferiche?
ad esempio,lo si può impostare a 32 bit per caricare i driver delle stampanti, scanner (ad es.: epson cx6600) macchine fotografiche
che per ora non hanno driver x 64bit?


a quanto pare se la periferica non ha driver per win x64 non è possibile installarla
es: ho una audigy2, con i driver 32bit non riconosce la periferica.
con i driver per x64 (beta) la periferica funziona.
Ho provato anche con altre periferiche (schede acquisizione video, scanner, stampante) ma senza i driver per win x64 non ce niente da fare...
RaouL_BennetH01 Febbraio 2005, 00:27 #150
Originariamente inviato da cdimauro
No, per ricompilare s'intende prendere i sorgenti già esistenti per un'applicazione, e generare l'eseguibile per una specifica architettura.


perdonami, ma questo non genera un eseguibile "non pensato" a monte (sorgente) per una determinata architettura e, di conseguenza, meno efficiente?

E, nel caso in cui sia così, sarebbero trascurabili le eventuali migliorie che potrebbero essere fatte scrivendo nativamente?

Thx.

RaouL.
« Pagina Precedente     Pagina Successiva »

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