Link alla notizia: http://news.hwupgrade.it/13945.html

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

Click sul link per visualizzare la notizia.

La mia preoccupazione non e' tanto l'OS con i driver, ma i programmi, attualmente non so quanti programmi siano supportati da WIN64, a meno che non intergi un'emulazione 32 bit...boh :confused:

Va solo sugli AMD? :look:

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

Negli ultimi giorni vari rumors segnalano come data di rilascio per il nuovo windows a 64bit, il 29 Aprile.

un bel "ERA ORA" sti sta proprio bene... :tapiro:

Va solo sugli AMD? :look:

va anche con CPU Intel con tecnologia a 64bit ;)

...ma alla intel con che tipo di CPU l'hanno sviluppato e testato Win64bit??
No, è curioso da pensare...mi era venuto anche in mente che grazie agli AMD64 avessero potuto dare un forte impulso allo sviluppo di tale software ma evidentemente è un mio capriccio mentale :sofico:

Nemesis, da questo deduco che tu abbia un bel AMD :)
Cmq sia, credete valga la pena scaricarmelo per il mio 32bit, solo per vedere com'è fatto? Se è cambiato qualcosa? :)

Tra pochi minuti parto con l'installazione della versione trial/beta di win64

Ho un bel:
:cool: :cool:
Athlon64 3400+ (2400MHz-754pin)
Sapphire Radeon X800XT
2X 512MB Corsair CL 3-4-4-6
2X 160GB Maxtor S-ATA in RAID 0
LCD ACER 17" 16ms
:cool: :cool:

Si ragazzi... lo so... il tutto costa un patrimonio... Ma io tengo solo il sistema sempre aggiornato invece di spendere un botto di soldi ogni 2 anni perchè il vecchio pc vale 10euro !!!:cool:

E poi passo le ore a fare i test :D

Uè Corsini se hai bisogno di uno smanettone/tester... mi propongo !!
Chiedi a Raffaele, mi sono laureato con lui ;)

A.P.

Originariamente inviato da NemesisQ3A

TRA AMD64 e INTEL EMT64 non esistono particolari differenze, quindi questa versione di Windows girerà perfettamente con entrambe.
Il ritardo di win 64 era dovuto all'incompatibilità delle cpu intel 64 alla versione windows 64 che girava con tecnologia 64bit di AMD... :muro:

L'altra versione di Windows a 64bit era pensata per il supporto agli Itanium e Itanium2, basati su architettura IA64

Esiste una versione windows 64bit (IA-64) per cpu Itanium/Itanium2???:eek:

Originariamente inviato da capitan_crasy
Il ritardo di win 64 era dovuto all'incompatibilità delle cpu intel 64 alla versione windows 64 che girava con tecnologia 64bit di AMD... :muro:


e anche perchè Intel ha annunciato molto dopo l'utilizzo dei 64 bit nelle proprie cpu, rispetto alla roadmap MS ( e AMD)


Esiste una versione windows 64bit (IA-64) per cpu Itanium/Itanium2???:eek:

se per Windows intendi XP. sì ma è rimasta come Beta dato che la MS ne ha stoppato il progetto, il 2003 server invece è definitivo e funziona già da un pò...


cmq se realmente verrà rispettata la data, un plauso a MS perchè già da diverso tempo pronosticava la sua uscita per il Q2 del 2005.

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

Beh, le differenze a quantop are cui sono eccome ->
http://news.swzone.it/swznews-13867.php

Dai test i 64-bit Intel non solo sono più lenti di quelli AMD ( il che era prevedibile) ma producono anche prestazioni peggiori rispetto alla versione a 32-bit :D :D

yeah
virtual dub ringrazia :O

ho provato il link per scaricarlo, ma andando avanti nella procedura appare la classica pagina binaca, lo fanno scaricare oppure no?

come si era già detto, M$ ha semplicemente aspettato che anche Intel mettesse in commercio proci a 64bit... :O
che poi l'abbia fatto per puro scopo commerciale (più piattaforme a 64bit = più copie di win XP 64bit vendute; inoltre credo che se sia intel sia amd produrranno proci a 64bit, ci saranno più software, driver migliori,ecc. insomma più notorietà per questi 64bit) oppure in base a qualche losco accordo commerciale non lo so, ma da M$ questo ed altro.... :rolleyes:

Non ci capisco piu' nulla. XP a 64bit. E per i server? Win2003 e' a 64bit? E quando uscira' Longhorn? Dovranno rifare tutto?

Prezzi sempre da spavento o gli daranno una bella sfoltita?

Perchè di spendere 400€ per un OS da usare per 1 anno non ci penso neppure. Sopratutto quando con una qualsiasi release linux gratuita (a 64bit da tempo) faccio praticamente lo stesso lavoro che sotto windows, anche giocare!

Originariamente inviato da samslaves
Non ci capisco piu' nulla. XP a 64bit.

e fin qui ci siamo :D


E per i server?

i server sn un'altra cosa no?

Tu usi Xp su di un server o ne hai mai visto uno?

Io no per fortuna :D


Win2003 e' a 64bit?

2 versioni di Win Server 2003 vengono commercializzate anche per i 64 bit ( N.B che 32 e 64 bit sn due edizioni diverse)
La Datacenter Edition è stata progettata esclusivamente per l'itanium, mentre la Enterprise anche per Opteron e Xeon.

Quest'ultima però, poichè presenta sostanzialmente le stesse problematiche di Xp-64 bit si trova anch'essa in veste di Beta-testing
e sarà compatibile con AMD64 e + in generale con l'EM64T ( Pentium inclusi).


E quando uscira' Longhorn?

avremo due sistemi operativi da poter usare, come è successo per 2K e Xp ecc. ecc.


Dovranno rifare tutto?

Longhorn supporterà i 64bit e cmq ci vorranno altri due anni...mica potevamo aspettare quella data ;)

Vergognoso. Winxp64 era praticamente pronto ma hanno aspettato Intel per puri scopi commerciali.
Questa sì che è innovazione.

Originariamente inviato da hardskin1
Vergognoso. Winxp64 era praticamente pronto ma hanno aspettato Intel per puri scopi commerciali.
Questa sì che è innovazione.
Concordo in pieno.

Esistono infatti 3 modalità di esecuzione possibile:
- applicazioni 32bit in ambiente 32bit.
- applicazioni 32bit in ambiente 64bit.
- applicazioni 64bit in ambiente 64bit
_____________________________________________________

e per le vecchie applicazioni 16 bit non c'e' proprio nessuna speranza o saranno eseguibili tramite l'opzione di compatibilita' ?

Originariamente inviato da hardskin1
Vergognoso. Winxp64 era praticamente pronto ma hanno aspettato Intel per puri scopi commerciali.
Questa sì che è innovazione.

Concordo in pieno

Originariamente inviato da Manwë
Prezzi sempre da spavento o gli daranno una bella sfoltita?

Perchè di spendere 400€ per un OS da usare per 1 anno non ci penso neppure. Sopratutto quando con una qualsiasi release linux gratuita (a 64bit da tempo) faccio praticamente lo stesso lavoro che sotto windows, anche giocare!


Scusa ma che tu sappia anche Ubuntu Linux e' a 64 bit ?

ho questo CD tra le mani........mmmm.......prima o poi lo provo

Io non vorrei fare il guastafeste ma anche con l arrivo di windows xp a 64bit ne passerà di acqua sotto i ponti prima che chi ha comprato i proci a 64bit abbia qualche reale vanaggio.Un pò come quando è stato introdotto i 32bit che non sono serviti a una cippa per una vita :-)

Originariamente inviato da hardskin1
Vergognoso. Winxp64 era praticamente pronto ma hanno aspettato Intel per puri scopi commerciali.
Questa sì che è innovazione.

Di questo abbiamo certezze?

Per altro un po' tutti stanno aspettando intel, come hanno sempre fatto del resto... in un certo qual modo, anche AMD sta aspettando Intel :sofico:

E comunque mi sembra più che legittimo che un'azienda faccia come gli pare nel rilasciare i software... ;)

Prima disprezzano MS, poi tutti che si lamentano perché nn esce la versione a 64 bit... e mo che forse uscirà presto, si lamentano perché poteva uscire prima... tanto poi ci si lamenterà che nn ci sono applicazioni a 64bit, poi quando ci saranno ci si lamenterà perché il loro AMD 64 4000+ non sarà più sufficiente, le applicazioni saranno pesanti e staremo al Dual Core AMD64 6600+... e che cavolo un po' di contegno e coerenza ci servirebbe, non per niente... potevate usare Linux no? :oink:

curioso che abbiano aspettato intel quando amd era già uscita da un pezzo...

Originariamente inviato da GiovanniGTS
Scusa ma che tu sappia anche Ubuntu Linux e' a 64 bit ?

ho questo CD tra le mani........mmmm.......prima o poi lo provo
si c'è la versione per x86_64.

A me sembra normale che microsoft abbia aspettato intel dato che detiene l'80 percento dei processori....
Si chiama microsoft non fatebenefratelli!
L'uniuco scopo è il lucro ,e come biasimarli, del resto
bill ha fatto i dindi anche grazie a mirate scelte commerciali come questa.

intel sempre più giùùùù

Cartelli fra multinazionali, accordi sottobanco, spionaggi industriali, concorrenza sleale...
Benvenuti nel nostro mondo.
Solitamente di queste cose non ci accorgiamo, ora la mossa di MS era plateale, ma è una cosa normalissima.
Praticamente il 90% delle prossime tecnologie è già pronto solo che prima di passarne ad una nuova si cerca di sfruttare al 100% quella vecchia.

vorrai far guadagnare bene bene chi ha investito per ricercare le vecchie tecnologie oppure no!!!??
Anche questo è normale...i soldi muovono l'informatica ora e per sempre!!|

Originariamente inviato da hardskin1
Vergognoso. Winxp64 era praticamente pronto ma hanno aspettato Intel per puri scopi commerciali.
Questa sì che è innovazione.


Io invece non concordo .

Microsoft ha fatto bene a ritardare l'uscita di Win64 , non tanto per aspettare Intel , ma anche perchè i processori 64 bit fino a poco tempo fa erano pochissimi . Sappiamo bene quanto la gente comune (non esperta) preferisca spendere poco per un PC , e quindi di conseguenza sappiamo anche ,costando di + gli athlon64 dei vecchi athlon, quanto siano poco diffusi questi processori tra l'utente da "supermercato" .

Inoltre INTEL detiene +dell' 80% del mercato con i suoi P4 , mandare fuori WinXP 64 in una situazione del genere voleva dire "FLOP" per il nuovo prodotto Microsoft. Chi gliel'avrebbe fatto fare a un possibile acquirente di comprare un SO a 64bit con poche applicazioni , pochi driver ...etc semplicemente perchè poco diffuso?

Quando si vuole lanciare un SO nuovo bisogna fare in modo che questo possa diffondersi il più possibile nel suo target di mercato, e senza l'adeguamento di Intel sappiamo che non sarebbe stato possibile . Con linux è un altra cosa, non è un azienda che deve guardare il mercato , ma per M$ lo sappiamo tutti che non è un associazione di beneficienza.

Ciao

oserei dire anche il mondo...

Scusate raga ma da quand'è che linux supporta i 64 bit? un anno e mezzo più o meno, mi pare... buon tempismo MS, continua così!

Si, va be' con tutte ste balle delle solite dispute contro intel, che noia sentire sempre le solite tiritere, ora vorrei sapere come fare riconoscere un hd sata da sistema a 64bit in versione beta, sia con piattaforma via che nvidia non ci sono i driver da usare dopo f6, o almeno io non li ho trovati e quindi non mi sono potuto installare la beta. ciao e grazie.

Per i Via ci sono, li trovi sul sito viaarena.com, c'è la versione a 64 bit ed un readme che dice come recuperare la versione da "mettere su floppy".

non avete pensato che con questo ritardo avremo un paio di service pack in meno ;)

Ragazzi, il problema grosso (enorme)sono i driver, io ho scaricato la beta due mesi fa e funziona benissimo, sono riuscito a trovare anche i driver per la Radeon, per la scheda audio, per il chipset (VIA)...
Ma per il modem ADSL, per lo scanner e la stampante?
Niente di niente, capirai già all'epoca del passaggio a XP ho dovuto aspettare sei mesi i driver per lo scanner, ed era uscito ufficialmente!

la intel detiene il 80% del mercato? Ed io che pensavo avesse fatto quasi la fine dei cyrix della IBM... Io non ho ancoar un 64 bit, ma ovviamente prenderò un AMD.
Sono almeno 3-4 anni che riesco a convincere tutti quelli che voglio un PC da me a comprare un AMD. Ma c'è davvero cosi tanta gente che "tifa" intel?
Mi sembra molto strano, in fondo siamo noi smanettoni a tirar su il mercato.
O sbaglio?

Nn penso proprio siano gli smanettoni a tirar su il mercato visto che gli smanettoni sn una piccolissima parte rispetto gli utenti normali.
Vergognoso. Winxp64 era praticamente pronto ma hanno aspettato Intel per puri scopi commerciali.
Questa sì che è innovazione
bhe intel è pronta da un po' con i processori a 64 bit....gli attuali prescott sn già predisposti per la tecnologia E64MT. più tempo ci mette microsoft a fare un sistema operativo e melgio è! magari si accorgono di qualche buco e lo sistemano!

Originariamente inviato da Runfox
Per i Via ci sono, li trovi sul sito viaarena.com, c'è la versione a 64 bit ed un readme che dice come recuperare la versione da "mettere su floppy".

Maledetti dischi SATA! Possibile che nel 2005 ci sia bisogno ancora del floppy per installarli? Quando mi serve un floppy funzionante non riesco mai a trovarlo e devo fare i numeri da circo per installare windows! Quando uscirà SATA2 cosa dovrò mettere nel pc per poterli installare? Un lettore di schede forate? :muro:

se non sbaglio win 64 decreterà la fine delle vekkie applicazioni legacy a 16 bit.

x luckye
è proprio questo lo sbaglio ke commettete tutti!
il passaggio 16 bit 32 bit non ha NIENTE a ke vedere con quello 32 -64.
In quest'ultimo le maggiori prestazioni saranno dettate SOPRATTUTTO dal raddoppio dei registri del processore, con incrementi ke possono raggiungere anke il 20%.
inoltre sarà possibile un ULTERIORE boost x via dei programmi ke si avvantaggeranno del calcolo nativo a 64 bit. Ma non è assolutamente SOLO questo il guadagno. Anzi esso sarà un pò come la ciliegina sulla torta ke permetterà di avere prestazioni impensabili su quelle applicazioni ke necessitano di elaborare interi a 64 bit.

Credo che il mercato sia diretto da tutte le grosse catene di negozi che vendono dei pacchetti belli pronti, se ci fate caso spingono sopratutto Intel, dopo tutto chi compra a scatola chiusa, o dovrei dire a case chiuso, non ha che farsene di un Amd, non lo spingerà mai, probabilmente non sa nemmeno come fare, e se si blocca la macchina, la smonta e la porta in negozio a ripararla, sapete quanta gente ho visto pagare 80 euro per installare una misera patch antivirus? Proprio adesso ho davanti a me un ragazzo che appena sente Amd storce il naso ma non sa dirmi perchè preferisce Intel, dice che la PCI gli sembra un bella presa per il c**o, comprerà solo mobo Asus, e non conosce Gigabyte o Chaintech; ha appena comprato una radeon 9250, preferendola ad una 9600xt che volevo dargli usata (il mio usato ha al massimo 2-3mesi di lavoro sulle spalle), ma non si ricorda di che marca... questo è il mercato, di gente che non ha idea di quello che ha sottomano.
Ho visto comprare pc presso centri commerciali che vendono anche frutta e verdura.
Avete mai apreto PC con processori P4 da 2.80 e schede video mx400?

Involontariamente ho fatto invio...
Questo è il vero mercato e tutti questi utenti potranno aspettare la versione "definitiva" del nuovo sistema operativo, questi utenti non sapranno cosa farsene di 32 o 64 bit fino a quando non potranno farne a meno.
Per quanto riguarda la sudditanza fra Ms e Intel sicuramente esiste un patto di stabilità che tenta di sconfiggere sia Amd che Linux & company...
Se il 64 bit fosse uscito quando realmente era pronto allora Amd avrebbe fatto un enorme salto in avanti...

Dobbiamo anche capire che tanta gente usa il computer per necessità(navigare, scrivere, ecc) e non per passione...Nella società il computer è e dovrà restare un oggetto di utilità, se poi per qualcuno diventa una passione questo è un'altro discorso, cambiare configurazione ogni 2mesi non lo si fa certo per utilità(eccetto che in rari casi)!!!

Un p4 2800 con SV mx400? andrebbe più che bene una scheda video integrata in moltissimi casi

Insomma basta con questi discorsi sulla gente comune che non capisce questo o quello, è come se andassimo a comprare la macchina e il concessionario con i suoi colleghi ci prende per il culo perché non conosciamo le ultime tecnologie negli impianti frenanti o nel computer di bordo!!!

Quindi è giusto che le cose vadano avanti così, che il mercato non sia trascinato dagli smanettoni, ma ve lo immaginate: esce la scheda video PincoPallinoGT Turbo Pro che mi fa girare Doom10 in 10000x10000 al misero prezzo di 1000euro e dopo 2mesi diventa uno standard!!!

Originariamente inviato da Mante80
Maledetti dischi SATA! Possibile che nel 2005 ci sia bisogno ancora del floppy per installarli? Quando mi serve un floppy funzionante non riesco mai a trovarlo e devo fare i numeri da circo per installare windows! Quando uscirà SATA2 cosa dovrò mettere nel pc per poterli installare? Un lettore di schede forate? :muro:

strano: :wtf:
ho appena installato win x64 e non ho avuto problemi con gli hard disk sata, li ha riconosciuti senza aggiunta di driver...

avete fatto una partizione?

Originariamente inviato da capitan_crasy
strano: :wtf:
ho appena installato win x64 e non ho avuto problemi con gli hard disk sata, li ha riconosciuti senza aggiunta di driver...
Può essere che finalmente con win64 microsoft abbia aggiunto il ricooscimento automatico dei SATA. Era ora visto che con winXP la cosa mi ha sempre creato qualche problema! Cmq win64 non l'ho ancora provato. Appena mi arriva il Winchester 3500+ e la mobo NForce4 provo. Un dubbio: visto che sul sistema di adesso ho 2 dischi in raid0 quando cambio mobo non ho nessun problema a fare riconoscere l'array presente dal nuovo sistema oppure mi tocca formattare? Grazie

Originariamente inviato da ^TiGeRShArK^
se non sbaglio win 64 decreterà la fine delle vekkie applicazioni legacy a 16 bit.

x luckye
è proprio questo lo sbaglio ke commettete tutti!
il passaggio 16 bit 32 bit non ha NIENTE a ke vedere con quello 32 -64.
In quest'ultimo le maggiori prestazioni saranno dettate SOPRATTUTTO dal raddoppio dei registri del processore, con incrementi ke possono raggiungere anke il 20%.
inoltre sarà possibile un ULTERIORE boost x via dei programmi ke si avvantaggeranno del calcolo nativo a 64 bit. Ma non è assolutamente SOLO questo il guadagno. Anzi esso sarà un pò come la ciliegina sulla torta ke permetterà di avere prestazioni impensabili su quelle applicazioni ke necessitano di elaborare interi a 64 bit.


http://digilander.libero.it/nokappa/male.htm

Non ho resistito :)

Hai perfettamente ragione, io comunque facevo riferimento a persone che dopo 2 giorni che hanno il pc cominciano a lanciare test, benchmark vari e non capiscono perchè ottengono risultati ridicoli e cominciano a lamentarsi; e vero anche che c'è tanta gente che con un vecchio pentium mmx va di lusso...
io per esempio uso un portatile Acer, da parecchio tempo, con un celeron 400, mi sono limitato a mettere un nuovo disco da 80 giga e ti garantisco che per office e per la posta è perfetto

Be dopotutto il commodore 64 era già arrivato ai 64 bit...
MAgari lancerei una nuova discussione sul forum...

Originariamente inviato da ^TiGeRShArK^ inoltre sarà possibile un ULTERIORE boost x via dei programmi ke si avvantaggeranno del calcolo nativo a 64 bit. Ma non è assolutamente SOLO questo il guadagno. Anzi esso sarà un pò come la ciliegina sulla torta ke permetterà di avere prestazioni impensabili su quelle applicazioni ke necessitano di elaborare interi a 64 bit.

Risposta seria ora.

Sfatiamo un mito una volta per tutte: le CPU a 64bit non servono per velocizzare i calcoli (ne' a 32 ne' a 64 bit), ma servono solo per indirizzare piu' memoria virtuale non segmentata, oltre i 4gb.

Perche' non serve per velocizzare i calcoli a 64bit? Due motivi principali:

1) Le CPU moderne con esecuzione out of order e tecnologie quali l'HT fanno un ottimo lavoro nel nascondere le latenze e i calcoli risultano nel 90% dei casi memory bound, limitati dalla banda passante verso la memoria e non dalla velocita' d'esecuzione della CPU. Giusto l'altro ieri ci siamo domandati se un pezzo di codice piuttosto complicato che necessitava di calcoli a 64bit su una cpu a 32 bit sarebbe stato piu' veloce se implementato a 32 bit: senza troppe speculazione abbiamo semplicemete provato e calcolato i tempi di esecuzione scoprendo, magari un po' a sorpresa, che non c'era alcuna differenza. Le due versioni erano eseguite nello stesso tempo, dimostrando che i moderni processori a 32 bit sono perfettamente efficienti anche nei calcoli a 64 bit.
Che cosa sarebbe cambiato se quel pezzo di codice fosse stato eseguito da una CPU a 64 bit? Magari sarebbe andato piu' lento per il motivo numero 2...

2) Su una CPU a 64bit tutti i puntatori sono a 64bit ed occupano esattamente il doppio della memoria rispetto agli stessi puntatori su una CPU a 32bit, andando a sovraccaricare la cache, riducendone le prestazioni (piu' spazio occupato nella cache a parita' di quantita' di informazioni significa hit rate piu' basso e minore banda passante verso la memoria centrale). Herb Sutter riporta in un articolo che ho postato tempo fa come sul compilatore C++ sul quale sta lavorando il suo team di sviluppo, i vantaggi architetturali della versione a 64bit (piu' registri) erano completamente annullati dal peggiore hit rate della cache causato dai puntatori a 64 bit.

In conclusione, ricompilando un'applicazione a 64bit non ci dovrebbe aspettare alcun miglioramento prestazionale, ma solo piu' memoria indirizzabile.

Originariamente inviato da fek
Risposta seria ora.

Sfatiamo un mito una volta per tutte: le CPU a 64bit non servono per velocizzare i calcoli (ne' a 32 ne' a 64 bit), ma servono solo per indirizzare piu' memoria virtuale non segmentata, oltre i 4gb.

Perche' non serve per velocizzare i calcoli a 64bit? Due motivi principali:

1) Le CPU moderne con esecuzione out of order e tecnologie quali l'HT fanno un ottimo lavoro nel nascondere le latenze e i calcoli risultano nel 90% dei casi memory bound, limitati dalla banda passante verso la memoria e non dalla velocita' d'esecuzione della CPU. Giusto l'altro ieri ci siamo domandati se un pezzo di codice piuttosto complicato che necessitava di calcoli a 64bit su una cpu a 32 bit sarebbe stato piu' veloce se implementato a 32 bit: senza troppe speculazione abbiamo semplicemete provato e calcolato i tempi di esecuzione scoprendo, magari un po' a sorpresa, che non c'era alcuna differenza. Le due versioni erano eseguite nello stesso tempo, dimostrando che i moderni processori a 32 bit sono perfettamente efficienti anche nei calcoli a 64 bit.
Che cosa sarebbe cambiato se quel pezzo di codice fosse stato eseguito da una CPU a 64 bit? Magari sarebbe andato piu' lento per il motivo numero 2...

2) Su una CPU a 64bit tutti i puntatori sono a 64bit ed occupano esattamente il doppio della memoria rispetto agli stessi puntatori su una CPU a 32bit, andando a sovraccaricare la cache, riducendone le prestazioni (piu' spazio occupato nella cache a parita' di quantita' di informazioni significa hit rate piu' basso e minore banda passante verso la memoria centrale). Herb Sutter riporta in un articolo che ho postato tempo fa come sul compilatore C++ sul quale sta lavorando il suo team di sviluppo, i vantaggi architetturali della versione a 64bit (piu' registri) erano completamente annullati dal peggiore hit rate della cache causato dai puntatori a 64 bit.

In conclusione, ricompilando un'applicazione a 64bit non ci dovrebbe aspettare alcun miglioramento prestazionale, ma solo piu' memoria indirizzabile.

il che dovrebbe voler dire che le evenuali maggiori prestazioni degli A64 sono merito soltanto della pipeline di più efficiente implementazione - da articoli su arstechnica ricordo ad esempio, accorgimenti che comprendono il decode in due stadi per le istruzioni corrispondenti a più risc86, il calcolo anticipato dell' address offset per alleggerire l' esecuzione in AGU delle istruzioni con indirizzamento relativo, la latenza di solo due cicli di clock, del loop schedule -> execute , lo shadow register file per il rollback delle istruzioni in caso di errata predizione, eccetera
ma sono tutte cose che prescindono dallo spazio indirizzabile ...

Originariamente inviato da jappilas
il che dovrebbe voler dire che le evenuali maggiori prestazioni degli A64 sono merito soltanto della pipeline di più efficiente implementazione - da articoli su arstechnica ricordo ad esempio, accorgimenti che comprendono il decode in due stadi per le istruzioni corrispondenti a più risc86, il calcolo anticipato dell' address offset per alleggerire l' esecuzione in AGU delle istruzioni con indirizzamento relativo, la latenza di solo due cicli di clock, del loop schedule -> execute , lo shadow register file per il rollback delle istruzioni in caso di errata predizione, eccetera
ma sono tutte cose che prescindono dallo spazio indirizzabile ...

Come ho scritto sembrerebbe che questi accorgimenti siano controbilanciati dall'intrinseca minore efficienza della cache con puntatori a 64 bit, su algoritmi che prevedano intenso uso di strutture dati complicate.

Può essere che finalmente con win64 microsoft abbia aggiunto il ricooscimento automatico dei SATA. Era ora visto che con winXP la cosa mi ha sempre creato qualche problema! Cmq win64 non l'ho ancora provato. Appena mi arriva il Winchester 3500+ e la mobo NForce4 provo. Un dubbio: visto che sul sistema di adesso ho 2 dischi in raid0 quando cambio mobo non ho nessun problema a fare riconoscere l'array presente dal nuovo sistema oppure mi tocca formattare? Grazie
Io nn ho problemi neanche con windows xp per i dischi sata (ho due seagate barracuda), ho prova sia con l'home edition sia con il professional!

Ok benissimo ma ho controllato sui siti delle mie periferiche...di driver a 64 bit neanche l'ombra e allora cosa me ne faccio dell'os a 64 bit???? mah....

ragazzi:

sto usando win x64 e per adesso tutto bene... :D
tranne per AquaMark3...

Beh , ho installato anche questa beta "nuova" di XP(feel the power)64 edit. sulla mia partizione dedicata .. e oltre a scompattare archivi più velocemente non mi è servita assolutamente a nulla .....per ora.

Originariamente inviato da zephyr83
Io nn ho problemi neanche con windows xp per i dischi sata (ho due seagate barracuda), ho prova sia con l'home edition sia con il professional!
Non è che i dischi in sè danno problemi. L'unica cosa è che, quando si installa il SO da zero il disco SATA non viene riconosciuto in automatico da XP ma bisogna inserire il floppy dei driver del controller SATA della motherboard. Il fatto è che praticamente nessuna casa ti fornisce il floppy ma ti da i drivers su cd. Alcuni cd delle motherboard utilizzano una procedura automatica che in fase di boot ti consente di inserire i drivers su floppy per poi poter procedere all'installazione del SO. Quando questa utilità non è fornita, per fare questa procedura ti tocca utilizzare un altro pc oppure utilizzare il prompt di dos. Mi sembra scandaloso che non sia possibile caricare i drivers del controller direttamente da cd. Il tuo winXP ti riconosce i dischi senza aver caricato da floppy i drivers del controller? Se la risposta è sì allora può essere colpa della mia versione di windows che è un po' vecchia

Originariamente inviato da fek

A che punto stiamo con l'erbetta? :asd:

l'ho installato ora... mi si riavvia appena inizia a caricare winXp 64 :(

Originariamente inviato da Mante80
Non è che i dischi in sè danno problemi. L'unica cosa è che, quando si installa il SO da zero il disco SATA non viene riconosciuto in automatico da XP ma bisogna inserire il floppy dei driver del controller SATA della motherboard. Il fatto è che praticamente nessuna casa ti fornisce il floppy ma ti da i drivers su cd. Alcuni cd delle motherboard utilizzano una procedura automatica che in fase di boot ti consente di inserire i drivers su floppy per poi poter procedere all'installazione del SO. Quando questa utilità non è fornita, per fare questa procedura ti tocca utilizzare un altro pc oppure utilizzare il prompt di dos. Mi sembra scandaloso che non sia possibile caricare i drivers del controller direttamente da cd. Il tuo winXP ti riconosce i dischi senza aver caricato da floppy i drivers del controller? Se la risposta è sì allora può essere colpa della mia versione di windows che è un po' vecchia

ti ripeto:
non ho dovuto installare con f6 driver per il controller sata della scheda mamma.
L'hard disk è un Maxtor DiamondMax 10 250Gb SATA nuovo di pacca mai stato formattato...
il tuo problema deriva da schede mamme che riconoscono il controller sata come uno scsi, quindi xp/xp x64 hanno bisogno di driver aggiuntivi.

ma come mai xp ha bisogno dei driver serial ata mentre win ME lo installa senza problemi:confused:

Il ritardo di Intel nei confronti del supporto ai 64 bit è solo uno dei motivi che ha portato all'uscita in ritardo di Windows XP 64 bit.

La maggioranza di voi non considera che programmare un sistema operativo a 64 bit non è una banalissima ricompilazione, ma richiede una ristrutturazione del kernel piuttosto pesante. Bisogna, inoltre, dare il tempo che i compilatori a 64 bit diventino stabili ed efficienti e che vengano forniti agli sviluppatori gli strumenti necessari per la realizzazione delle applicazioni a 64 bit e dei driver a 64 bit. Questi ultimi due punti non sono banalissimi. E' necessario tener presente che al di là del mondo delle schede video e dei chipset, gli altri produttori hardware sviluppano driver con una velocità nettamente inferiore perché investono meno risorse in questo campo. Quanti di noi si mettono ad aspettare con ansia i nuovi driver della stampante? Praticamente nessuno anche perché ne viene rilasciata una versione nuova all'anno se va bene.

Io ho seguito l'evoluzione delle varie beta di Windows XP a 64 bit e vi assicuro che l'anno scorso non era assolutamente pronto. Oggi, poi, è necessario tener presente di tutte quelle problematiche relative alla sicurezza e un'azienda come Microsoft, che viene continuamente criticata per le varie falle che si trovano nelle varie componenti di Windows, figuriamoci se rilascia una nuova versione di Windows XP (perché ripeto che non si tratta di una banale ricompilazione) senza essere sicura al 100% di non avere grosse falle nella sicurezza e senza aver fatto un beta testing estremamente accurato ed esteso.

Quindi, in definitiva, non sono d'accordo con chi ritiene che Microsoft abbia ritardato volotariamente l'uscita di questo sistema operativo. Sicuramente se la sono presa con comoda, ma per evidenti motivi legati allo sviluppo, ai compilatori e ad una diffusione hardware non adeguata, non certo per fare un dispetto ad AMD.

Inizio l'installazione e mi da una schermata blu (DOS) d'errore...
ho pensato fosse il raid...

ho provato su un WD400 (40GB)... stesso errore...

masterizzato male ?!?!?

scusate che programma avete usato per masterizzare l' ISO ?!?!?

Originariamente inviato da nonikname
Beh , ho installato anche questa beta "nuova" di XP(feel the power)64 edit. sulla mia partizione dedicata .. e oltre a scompattare archivi più velocemente non mi è servita assolutamente a nulla .....per ora.
prova virtual dub and xvid a 64 bit :D

c'ho su una versione beta da qualche mese con un amd 3400, carino, ci girano anche alcuni giochi. Mancano alcuni driver ma era scontato. Ho notato che anche le applicazioni 32bit emulate girano leggermente piu veloci del winxp, forse una mia impressione

Originariamente inviato da Jaguarrrr
scusate che programma avete usato per masterizzare l' ISO ?!?!?

nero...;)

Non è che i dischi in sè danno problemi. L'unica cosa è che, quando si installa il SO da zero il disco SATA non viene riconosciuto in automatico da XP ma bisogna inserire il floppy dei driver del controller SATA della motherboard. Il fatto è che praticamente nessuna casa ti fornisce il floppy ma ti da i drivers su cd. Alcuni cd delle motherboard utilizzano una procedura automatica che in fase di boot ti consente di inserire i drivers su floppy per poi poter procedere all'installazione del SO. Quando questa utilità non è fornita, per fare questa procedura ti tocca utilizzare un altro pc oppure utilizzare il prompt di dos. Mi sembra scandaloso che non sia possibile caricare i drivers del controller direttamente da cd. Il tuo winXP ti riconosce i dischi senza aver caricato da floppy i drivers del controller? Se la risposta è sì allora può essere colpa della mia versione di windows che è un po' vecchia
Ripeto io nn ho avuto alcun problema di nessun tipo, sn riuscito a installare anche windows 98 SE (poi cancellato subito perché nn trovavo un ciufolo di drivers). Penso che il problema derivi dal tuo controller sata.
Poi perché dici che i driver nn li puoi caricare da cd? Sn andato nel sito della seagate e ti permettono di scaricare sia la versione per floppy sia quella per cd bootable! ormai tutte le schede madri fanno il bbot anche da hard disk.....la mia anche dal lettore di memory card!!

Appunto!
il problema è proprio la banda della memoria!
X questo il raddoppio dei registri con X86-64 provoca un aumento delle prestazioni mediante una banale ricompilazione. Perkè in questo modo i programmi potranno sfruttare un numero di registri maggiori e DI CONSEGUENZA si avranno meno accessi alla cache (dato ke un processore x caricare i dati dai registri non accede mai direttamente alla memoria, ma prima i dati e le istruzioni vengono memorizzati nella cache L1 E L2 nel caso di memoria inclusiva, oppure solo in una di queste nel caso di progettazione esclusiva, detto MOLTO grossolanamente).
Il raddoppio dei puntatori è proprio il motivo ke mi fa pensare ke le prestazioni delle makkine intel saranno peggiori rispetto a quelle AMD, dato ke le prime sono particolarmente assetate di banda x via delle pipeline spropositamente lunghe.
D'altro canto le makkine AMD guadagnano prestazioni col dual channel in maniera sensibile solo in alcune applicazioni particolarmente assetate di banda.....
prova un pò a confrontare il guadagno ke si ha avuto tra northwood con bus 533 e northwood con bus 800.... mentre tra socket 754 e socket 939, nonostante RADDOPPI effettivamente la banda, non si vedono assolutamente guadagni di quel tipo (anke perkè l'MCH integrato fa il suo porco lavoro riducendo notevolmente le latenze di accesso alla memoria).

X quanto riguarda i calcoli a 64 bit io credo ke un discreto vantaggio si debba ottenere....
infatti una cosa è eseguire un calcolo in un ciclo di clock, e una cosa in due... tu dirai ke questo sarà nascosto dal raddoppio dei puntatori, e sarebbe anke vero se la cpu lavorasse per la maggior parte del tempo dai dati presi in RAM, ma sappiamo benissimo tutti ke, grazie al principio di località, la maggior parte delle operazioni svolte dalla CPU avvengono in cache, e la memoria cache ha latenze molto più basse rispetto alla RAM. Per cui caricare i registri con puntatori a 64 bit imho non dovrebbe prendere il DOPPIO del tempo rispetto all'utilizzo di puntatori a 64 bit.... anke perkè il bus della cache è ben più ampio di 64 bit e quindi potranno essere caricati diversi dati in una volta.

OT x l'uso della k.....
tieni conto ke se ti metti a scrivere da un portatile disteso sul letto non ti viene motlo comodo usare la tastiera, qdi tenti di ridurre AL MASSIMO i tasti da premere.... e una volta ke mi ritrovo sul computer fisso mi resta l'abitudine.... un pò come qdo si è abituati a scrivere "e', perche', cioe'" dato ke in molte applicazioni su internet vengono visualizzati male (MUD, TELNET....)

E cmq "il tempo è denaro!" ;)

Originariamente inviato da fek
1) Le CPU moderne con esecuzione out of order e tecnologie quali l'HT fanno un ottimo lavoro nel nascondere le latenze e i calcoli risultano nel 90% dei casi memory bound, limitati dalla banda passante verso la memoria e non dalla velocita' d'esecuzione della CPU. Giusto l'altro ieri ci siamo domandati se un pezzo di codice piuttosto complicato che necessitava di calcoli a 64bit su una cpu a 32 bit sarebbe stato piu' veloce se implementato a 32 bit: senza troppe speculazione abbiamo semplicemete provato e calcolato i tempi di esecuzione scoprendo, magari un po' a sorpresa, che non c'era alcuna differenza. Le due versioni erano eseguite nello stesso tempo, dimostrando che i moderni processori a 32 bit sono perfettamente efficienti anche nei calcoli a 64 bit.
Che cosa sarebbe cambiato se quel pezzo di codice fosse stato eseguito da una CPU a 64 bit? Magari sarebbe andato piu' lento per il motivo numero 2...

:confused:
questo passaggio onestamente mi sfugge....
"Giusto l'altro ieri ci siamo domandati se un pezzo di codice piuttosto complicato che necessitava di calcoli a 64bit su una cpu a 32 bit sarebbe stato piu' veloce se implementato a 32 bit"

Un codice a 64 bit x girare su una CPU a 32 bit DEVE essere necessariamente implementato a 32 bit... non puoi eseguire calcoli a 64 bit in una sola passata, ma si devono spezzare in due parti da 32 bit....
partendo dal fattto ke ovviamente ne sei consapevole, o hai sbagliato a scrivere qualcosa, o sono io ke non riesco proprio a capire quello ke vuoi dire :confused:

cmq x il fatto ke un codice a 64 bit sia più prestante, ormai credo non ci siano più dubbi, dato ke diversi siti online hanno riportato le prestazioni sia di programmi commerciali ricompilati a 64 bit ke di programmini scritti appositamente.....
È ovvio ke questi incrementi non ci sono in TUTTE le applicazioni, anzi in alcune abbiamo pure un decremento a causa dei motivi che giustamente hai riportato, però la MAGGIOR PARTE di esse presentava degli incrementi sostanziali, superiori ai decrementi ke si avevano in quelle poke applicazioni.

IMHO i 64 bit, sono un passo importante ke ci regaleranno un buon incremento prestazionale. Dopotutto in ambito di encoding video si parla di incrementi del 15% SOLAMENTE utilizzando winxp 64 con un encoder a 32 bit.... onestamente mi para un pò difficile ke utilizzando encoders a 64 bit le prestazioni peggiorino....

>Maledetti dischi SATA! Possibile che nel 2005 ci sia bisogno ancora del floppy per installarli? Quando mi serve un floppy funzionante non riesco mai a trovarlo e devo fare i numeri da circo per installare windows! Quando uscirà SATA2 cosa dovrò mettere nel pc per poterli installare? Un lettore di schede forate?<

passa a Mac...

....:senzaparole:

ragazzi, come faccio a vedere se il mio pc supporta i 64bit?

semplice, se hai un Athlon 64 supporta i 64 bit, altrimenti no!

A quando i programmi solo 64bit, così che siamo costretti all'upgrade? :rolleyes:

quindi intel non ha ancora messo in vendita i processori che supportano i 64bit..

Era ora che microzzoz si decidesse a puntare ufficialmente su win 64.
Adesso sarebbe il caso che le case software facessero lo stesso.
Altrimenti rimarrà un s.o. non sfruttato a dovere ancora per parecchio tempo.
Stiamo a vedere......

no, dovrebbero uscire x fine febbraio-inizio marzo secondo le voci ke circolano x ora...
cmq a qto pare l'implementazione di amd dovrebbe essere più efficiente dai test ke si sono visti in giro.....

Ridefinisco meglio il mio commento di prima: non sono assolutamente contrario al progresso, ma, anni fa, sono rimasto sconcertato nel vedere che windows 95 OSR2 non veniva più supportato, mentre windows 98 sì. La differenza fra i due è talmente esigua, che era chiaramente una scelta di marketing, per far aggiornare il proprio pc.
Da qui il mio commento... :)

io ho un Athlon64 3200+ ma l' aggiornamento nn me lo fa fare:d

non è un aggiornamento, lo devi installare in un'altra partizione, anke perkè non ti conviene sovrascrivere win xp 32, ma ti conviene usarli entrambi.

speriamo che creative esca con dei driver per win x64, altrimenti niente audigy 2...:mad:

Originariamente inviato da capitan_crasy
speriamo che creative esca con dei driver per win x64, altrimenti niente audigy 2...:mad:

sai che perdit...:ops:


:D

Originariamente inviato da DioBrando
sai che perdit...:ops:


:D

non ci dormo la notte...:sofico:

Creative ha già rilasciato driver per le schede Audigy 2 compatibili con Windows XP a 64 bit. Sono in versione beta.

http://preview.creativelabs.com

Originariamente inviato da ^TiGeRShArK^
:confused:
questo passaggio onestamente mi sfugge....
"Giusto l'altro ieri ci siamo domandati se un pezzo di codice piuttosto complicato che necessitava di calcoli a 64bit su una cpu a 32 bit sarebbe stato piu' veloce se implementato a 32 bit"


Qui c'e' una considerazione importante: fare speculazioni sui tempi di esecuzione del codice e' divertente, ma raramente ci si azzecca.
L'unica soluzione e' provare e prendere i tempi di esecuzioni e poi speculare sui risultati cercando di spiegarli.
Detto questo, ci siamo domandati se quell'algoritmo che averebbe necessitato di calcoli a 64 bit sarebbe stato meno veloce se implementato a 32 bit e abbiamo scoperto che i tempi di esecuzione non cambiavano.
Questo e' un dato di fatto, e' il risultato dell'esperimento.
Poi abbiamo provato a cercare di capire il perche' di questo risultato.


Un codice a 64 bit x girare su una CPU a 32 bit DEVE essere necessariamente implementato a 32 bit... non puoi eseguire calcoli a 64 bit in una sola passata, ma si devono spezzare in due parti da 32 bit....
partendo dal fattto ke ovviamente ne sei consapevole, o hai sbagliato a scrivere qualcosa, o sono io ke non riesco proprio a capire quello ke vuoi dire :confused:


La spiegazione e' semplice: un codice che richiede calcoli a 64 bit, implementato a 32 bit necessita di piu' istruzioni, ma spesso e volentieri il motore di esecuzione out of order, che ricordo si occupa di spostare le istruzioni di modo da ottimizzarne l'esecuzione, riesce a muovere queste istruzioni in piu' in colpi di clock che sarebbero altrimenti persi ad attendere che i dati arrivino dalla memoria.
Questa e' la norma in un'applicazione, che nella stragrande maggioranza dei casi e' memory bound. Chiaramente e' possibile immaginare particolari situazioni nelle quali inner loop molto corti che lavorano su dati molto coerenti verrebbero avvantaggiati dal poter fare calcoli nativi a 64 bit, ma questa e' un'eccezione rara.

Per questo e' molto raro notare questi fantomatici incrementi e nella maggior parte delle situazioni le CPU a 32 bit sono perfettamente in grado di eseguire codice a 64 bit senza perdita di prestazioni.




cmq x il fatto ke un codice a 64 bit sia più prestante, ormai credo non ci siano più dubbi, dato ke diversi siti online hanno riportato le prestazioni sia di programmi commerciali ricompilati a 64 bit ke di programmini scritti appositamente.....


E' proprio questo il punto, i dubbi ci sono e sono molto forti e all'atto pratico esistono molti casi in cui codice a 64 bit possa risultare anche piu' lento di codice a 32 bit.

Ecco uno di questi casi, tratto da un articolo di Herb Sutter che ho postato tempo fa:


(Aside: Here’s an anecdote to demonstrate “space is speed” that recently hit my compiler team. The compiler uses the same source base for the 32-bit and 64-bit compilers; the code is just compiled as either a 32-bit process or a 64-bit one. The 64-bit compiler gained a great deal of baseline performance by running on a 64-bit CPU, principally because the 64-bit CPU had many more registers to work with and had other code performance features. All well and good. But what about data? Going to 64 bits didn’t change the size of most of the data in memory, except that of course pointers in particular were now twice the size they were before. As it happens, our compiler uses pointers much more heavily in its internal data structures than most other kinds of applications ever would. Because pointers were now 8 bytes instead of 4 bytes, a pure data size increase, we saw a significant increase in the 64-bit compiler’s working set. That bigger working set caused a performance penalty that almost exactly offset the code execution performance increase we’d gained from going to the faster processor with more registers. As of this writing, the 64-bit compiler runs at the same speed as the 32-bit compiler, even though the source base is the same for both and the 64-bit processor offers better raw processing throughput. Space is speed.)

http://www.gotw.ca/publications/concurrency-ddj.htm


È ovvio ke questi incrementi non ci sono in TUTTE le applicazioni, anzi in alcune abbiamo pure un decremento a causa dei motivi che giustamente hai riportato, però la MAGGIOR PARTE di esse presentava degli incrementi sostanziali, superiori ai decrementi ke si avevano in quelle poke applicazioni.

IMHO i 64 bit, sono un passo importante ke ci regaleranno un buon incremento prestazionale. Dopotutto in ambito di encoding video si parla di incrementi del 15% SOLAMENTE utilizzando winxp 64 con un encoder a 32 bit.... onestamente mi para un pò difficile ke utilizzando encoders a 64 bit le prestazioni peggiorino....

E' l'esatto contrario, solo in situazioni particolarmente di nicchia si possano notare questi incrementi prestazionali, ma nella maggior parte dei casi no. Posso immaginare che alcuni encoder possano avere inner loop che beneficino di istruzioni a 64 bit.

Originariamente inviato da ^TiGeRShArK^
tieni conto ke se ti metti a scrivere da un portatile disteso sul letto non ti viene motlo comodo usare la tastiera, qdi tenti di ridurre AL MASSIMO i tasti da premere.... e una volta ke mi ritrovo sul computer fisso mi resta l'abitudine.... un pò come qdo si è abituati a scrivere "e', perche', cioe'" dato ke in molte applicazioni su internet vengono visualizzati male (MUD, TELNET....)


Stai speculando, ma i dati che ho visto dipingono scenari diversi.
Risolvere la questione e' molto semplice: scrivi un pezzo di codice, compilalo a 32 e 64 bit e guarda le differenze di prestazioni :)

Noi lo abbiamo fatto, Sutter lo ha fatto, nessuno dei due ha trovato differenze.

Per favore scrivi senza k, si fa molta fatica a leggerti ed e' un segno di rispetto verso chi ti legge non affaticarlo inutilmente.

Originariamente inviato da GiovanniGTS
e per le vecchie applicazioni 16 bit non c'e' proprio nessuna speranza o saranno eseguibili tramite l'opzione di compatibilita' ?
Non credo: dovrebbero essere del tutto abbandonate.

Comunque se dopo vent'anni dall'introduzione dei 386 hai ancora l'esigenza di far girare software a 16 bit, puoi sempre affidarti agli emulatori: anche se in emulazione, i processori attuali permettono di far girare molto velocemente le applicazioni a 16 bit.

Per arricchire la discussione vorrei portare un esempio pratico, ma e' un po' tecnico.

Ho preso una funzione molto semplice che calcola la seguente espressione con interi a 64 bit:

risultato = (x + y) * (x - y)

Questa e' la funzione:


void __fastcall func_64(
__int64* res,
__int64 arg1,
__int64 arg2)
{
__int64 res1 = *arg1 + *arg2;
__int64 res2 = *arg1 - *arg2;

*res = res1 * res2;
}


L'espressione calcolata potrebbe essere piu' complicata, ma questo non cambierebbe di molto la situazione (a meno che non ci sia un inner loop totalmente non memory bound, ma e' una situazione piuttosto rara come abbiamo detto).

Questa funzione viene compilata nel seguente codice asm su architettura X86:


00677ED8 push ebp
00677ED9 mov ebp,esp
00677EDB mov eax,dword ptr [ebp+8]
00677EDE push esi
00677EDF push edi
00677EE0 mov esi,ecx
00677EE2 mov ecx,dword ptr [ebp+0Ch]
00677EE5 mov edx,eax
00677EE7 sub edx,dword ptr [arg2]
00677EEA mov edi,ecx
00677EEC sbb edi,dword ptr [ebp+14h] ; (*)
00677EEF add eax,dword ptr [arg2]
00677EF2 adc ecx,dword ptr [ebp+14h] ; (*)
00677EFE pop edi
00677EFF mov dword ptr [esi],eax
00677F01 mov dword ptr [esi+4],edx
00677F04 pop esi
00677F05 pop ebp
00677F06 ret 10h


Ho marcato con (*) le istruzioni in piu' che sono necessarie per effettuare un calcolo a 64 bit su una CPU a 32 bit. E' da notare che tutte le volte che vedere "dword ptr [qualcosa]" la CPU sta facendo un accesso alla memoria che puo' essere in cache ma puo' anche non esserlo. Ogni accesso alla memoria puo' lasciare teoricamente la CPU in attesa a far nulla per qualche ciclo di clock o anche per migliaia di cicli di clock (a seconda che il dato sia in cache oppure no). Tutte le CPU moderne cercano di trovare qualcosa da fare alla CPU durante queste attese, implementano pipeline lunghe con molti stadi, riordinano le istruzioni, eseguono addirittura altri processi in quei cicli di clock altrimenti persi (HyperThreading). Molto probabilmente le istruzioni che ho marcato con (*) verranno schedulate per essere eseguite molto vicine ad uno degli accessi alla memoria per tenere occupata la CPU che altrimenti non avrebbe avuto nulla da fare. Quelle istruzioni in piu' che servono per fare calcoli a 64 bit molto probabilmente saranno gratuite in questo esempio.

Ovviamente in caso di calcoli piu' complessi, funzioni piu' lunghe, cicli piu' stretti, usare meno registri permetterebbe di ridurre gli accessi alla memoria, come e' possibile che che il working set piu' ampio peggiori le prestazioni della cache; si possono dipingere molti scenari.

La sintesi di questo discorso e' che non e' affatto detto che ricompilare un programma a 64 bit dia un incremento prestazionale enorme, in generale non cambiera' molto probabilmente nulla.

Spero di essere stato chiaro perche' il post e' un po' tecnico e noioso.

x fek: indubbiamente non tutte le applicazioni beneficeranno dei vantaggi offerti dall'architettura x86-64, ma mediamente dovremmo assistere a un aumento delle prestazioni nell'ordine del 15-20% (questi dati li fornì AMD, penso circa 3 anni fa, dai risultati delle simulazioni che fece).

Ad esempio, se prendiamo i test effettuati lo scorso anno con la beta di XP/64, notiamo che la compressione di un video con XviD è migliorata del 15% (in meno del tempo di esecuzione), pur essendo programma e codec a 32 bit.

Le prove con i giochi hanno fatto vedere che, a causa dei driver immaturi, le prestazioni fino a 1024x768 erano nettamente inferiori all'esecuzione degli stessi con XP (a 32 bit), ma andavano via via migliorando e addirittura a 1280x1024 erano migliori: quindi il layer WOW64 è stato capace di sopperire, e addirittura di migliorare, ai problemi dei driver.

Le prove fatte con Linux hanno evidenziato che POVRay e MySQL compilati a 64 bit e fatti girare sul s.o. a 64 bit hanno avuto incrementi prestazionali anche superiori al 40% sulla stessa macchina, ma con le medesime versioni a 32 bit.

E' chiaro che, come giustamente sottolinei, nell'usare i puntatori a 64 bit siamo in presenza di una perdita di prestazioni, ma è anche evidente che il maggior numero di registri general purpose disponibili (anche per le SSE), unito all'ortogonalità dei registri (che aiuta i compilatori) e alla presenza di una modalità d'indirizzamento relativa al PC, hanno contribuito, e non poco, a sanare questa perdita e mediamente ad ottenere dei risultati migliori.

E' anche chiaro che non interessa a nessuno sapere che la GUI delle applicazioni, che fanno ampio uso di oggetti e quindi di puntatori, avranno generalmente un decadimento prestazionale, ma è anche vero che gli incrementi che interessanno e che fanno veramente la differenza le vediamo non con le GUI, ma con l'esecuzione di applicazioni che effettuano dei calcoli intensivi, e queste normalmente beneficeranno del nuovo ambiente, come appare appunto dagli esempi che ho citato.

Io non conosco il contesto delle prove che avete fatto, per cui non mi posso esprimere in merito: avete sicuramente trovato un esempio in cui non c'è differenza fra l'esecuzione di codice a 32 e a 64 bit.
Ma ti posso anche dire che, se devo effettuare una conversione dallo spazio RGB allo YUV (o YCbCr o altro) o viceversa, trovo decisamente molto comodo e molto più efficiente / veloce poter utilizzare una moltiplicazione 32x32 -> 64 bit e usare poi le istruzioni a 64 bit per manipolare queste quantità, anziché ricorrere ai long long "emulati" con istruzioni a 32 bit. Questo per fare un altro esempio.
Dipende tutto dal tipo di algoritmo che si deve implementare.

EDIT: ho appena visto l'altro messaggio che hai postato, e sono d'accordo. ;)

Originariamente inviato da cdimauro
Dipende tutto dal tipo di algoritmo che si deve implementare.


Esatto dipende troppo dalla situazione, non si puo' assolutamente dire che mediamente si vedra' un aumento del 15/20%, anzi; dai, nessuno crede ai risultati forniti dalle simulazioni dei reparti di marketing, vero? ;)

MySQL mi sembra sospetto, hai un link a questa prova? Sono curioso. PovRay e XVid sicuramente possono beneficiare.

Originariamente inviato da Vifani
Creative ha già rilasciato driver per le schede Audigy 2 compatibili con Windows XP a 64 bit. Sono in versione beta.

http://preview.creativelabs.com

grazie...

Originariamente inviato da fek

......

La sintesi di questo discorso e' che non e' affatto detto che ricompilare un programma a 64 bit dia un incremento prestazionale enorme, in generale non cambiera' molto probabilmente nulla.

Spero di essere stato chiaro perche' il post e' un po' tecnico e noioso.

Correggimi se sbaglio ma, se non ho inteso male, con "ricompilare" intendi modificare e adattare un codice a 32bit per "trasformarlo" in 64bit, oppure il discorso si applica anche se si "pensa e si scrive" nativamente a 64bit?

Originariamente inviato da fek
Esatto dipende troppo dalla situazione, non si puo' assolutamente dire che mediamente si vedra' un aumento del 15/20%, anzi; dai, nessuno crede ai risultati forniti dalle simulazioni dei reparti di marketing, vero? ;)
No, ma analizzando le differenze architetturali fra un Athlon e un Athlon64 in modalità x86-64, direi che sono abbastanza plausibili... ;)
MySQL mi sembra sospetto, hai un link a questa prova? Sono curioso. PovRay e XVid sicuramente possono beneficiare.
Ho trovato un po' di materiale. In particolare, per MySQL qui http://anandtech.com/linux/showdoc.aspx?i=2127&p=5 trovi che nei test relativi alla SELECT la versione a 32 bit impiega il 35% circa in più rispetto a quella a 64 bit, mentre nell'INSERT impiega l'11% circa in più.

Nelle altre pagine ci sono altri test relativi ad altre tipologie. Riporto i più significativi miglioramenti ottenuti: LAME a 32 bit impiega il 46% in più di quello a 64 bit, POVRay/32 il 25% in più, Wolfestein Enemy Territory/64 genera il 13% di frame in più.

Effettivamente ricordavo male: oltre il 40% era il risultato del LAME, e non di POV-Ray e MySQL, ma in ogni caso il 25% e il 35% mi sembrano comunque degli ottimi valori, considerato che è stata necessaria solamente la ricompilazione. ;)

Altri test interessanti li troviamo in una recentissima recensione di x86-secrets qui http://www.x86-secret.com/articles/cpu/32vs64/32vs64-3.htm. E' riservata ai processori server (Opteron e Nocona), ma sono fornite le prestazione sia a 32 bit che a 64 bit. In particolare sono presenti una serie di test con Windows x64 RC1 qui http://www.x86-secret.com/articles/cpu/32vs64/32vs64-5.htm. Riporto i più significativi miglioramenti:

MiniGZip (compressione) è passato da 20,81 secondi della versione a 32 bit ai, 9,28 di quella a 64 bit.
Blobbly Dancer (demo tecnologico) da 26,67 fps a 30,21 fps.
POV-Ray (landscape.pov) da 60,31 secondi a 43,89.

Quelli di MiniGZip (specialmente) e POV-Ray sono semplicemente impressionanti, non credi? ;)

Originariamente inviato da repne scasb
Se interessa posso produrre il codice di alto livello postato da fek sia in assembly x86_32 che in assembly x86_64, cosi da poterne apprezzae le differenze.
A me interessano. ;)

Comunque sarebbe interessante vedere gli equivalenti a 32 e 64 bit generati da qualche compilatore, che sono gli strumenti più usati (sono poche le applicazioni che hanno ancora sezioni scritte in assembly).

Originariamente inviato da RaouL_BennetH
Correggimi se sbaglio ma, se non ho inteso male, con "ricompilare" intendi modificare e adattare un codice a 32bit per "trasformarlo" in 64bit, oppure il discorso si applica anche se si "pensa e si scrive" nativamente a 64bit?
No, per ricompilare s'intende prendere i sorgenti già esistenti per un'applicazione, e generare l'eseguibile per una specifica architettura.

Originariamente inviato da fek
Esatto dipende troppo dalla situazione, non si puo' assolutamente dire che mediamente si vedra' un aumento del 15/20%, anzi; dai, nessuno crede ai risultati forniti dalle simulazioni dei reparti di marketing, vero? ;)

MySQL mi sembra sospetto, hai un link a questa prova? Sono curioso. PovRay e XVid sicuramente possono beneficiare.

Ecco il link:
http://www.anandtech.com/linux/showdoc.aspx?i=2127

Come vedi le mie non sono speculazioni...
mi sono basato sulle prove effettuate su diversi software reali, in cui si vedono chiaramente i benefici dei 64 bit in quasi tutti i campi.

È possibilissimo ke il tuo codice non abbia beneficiato x niente dei 64 bit, ma non puoi generalizzare solamente dalle prove che hai effettuato.....

può essere che hai beccato uno degli algoritmi ke non traggono assolutamente vantaggio dai 64 bit.
Ma questo non vuole dire ke nessun altro algoritmo può essere avvantaggiato.

Infine *credo*, da quello ke ricordo della struttura dei database, ke essi utilizzino molto dati interi a 64 bit x l'indirizzamento dei dati all'interno del database.....

P.S. c'è repne ke mi fa sempre + paura :eek: ;)

Qdo ho iniziato a scrivere ancora non c'era il commento di cdimauro! :muro:

Originariamente inviato da repne scasb
1) Il codice: [...]


1) 2) 3) 4) 5) Non ho scritto quel codice a mano, e' il risultato del compilatore e delle sue ottimizzazioni.


6) Un ultimo appunto sul compilatore che stai utilizzando: sta leggendo in memoria arg2_(64-bbit) due volte, sei sicuro di aver attivato tutte le ottimizzazioni possibili?

Si', tutte le ottimizzazioni attivata, VS2005 (la BETA2), dopo l'Intel Compiler e' decisamente il piu' ottimizzante su piattaforma X86.


Se interessa posso produrre il codice di alto livello postato da fek sia in assembly x86_32 che in assembly x86_64, cosi da poterne apprezzae le differenze.

Se pensi sia utile, si'. Possiamo vedere il codice prodotto da altri compilatori su piattaforma X86 e confrontarli, ma non credo che cambi molto il succo del discorso:
1) servono alcune istruzioni per implementare i calcoli a 64 bit
2) queste istruzioni vengono presumibilmente nascoste dalla latenza degli accessi alla memoria.

Originariamente inviato da cdimauro
Quelli di MiniGZip (specialmente) e POV-Ray sono semplicemente impressionanti, non credi? ;)

Si', sono decisamente il caso di calcoli intensivi su inner loop molto stretti (il raytracing ad esempio). Ma quelli sono calcoli in floating point...
Mi stona molto il risultato di MySQL... ma siamo sicuri che qui stiamo analizzando le ottimizzazioni architetturali oppure la differenza fra codice a 32 bit e 64 bit?
Perche' non vedo davvero dove la seconda possa entrare in calcoli floating point effettuati da un raytracer...

Originariamente inviato da ^TiGeRShArK^
Come vedi le mie non sono speculazioni...
mi sono basato sulle prove effettuate su diversi software reali, in cui si vedono chiaramente i benefici dei 64 bit in quasi tutti i campi.


E' quello che cerco di spiegarti, in un raytracer non apprezzi i benefici dei 64 bit, apprezzi i benefici di un'architettura piu' performante ed e' un discorso molto diverso. Ed un raytracer non e' "in quasi tutti i campi", e' un solo campo.

Quello che ti sto contestando e' che il passaggio da 32 a 64 bit possa portare benefici prestazionali in tutti i campi, no, non e' vero. I miglioramenti dell'architettura si', i 64 bit no.


È possibilissimo ke il tuo codice non abbia beneficiato x niente dei 64 bit, ma non puoi generalizzare solamente dalle prove che hai effettuato.....

Io non ho generalizzato, tu stai generalizzando "in tutti i campi". Io ho portato esempio di codice che necessita di calcoli a 64 bit, che immagino possa beneficiare di un'architettura a 64bit :)
Lo immagino, perche' a conti fatti non ne beneficia.


può essere che hai beccato uno degli algoritmi ke non traggono assolutamente vantaggio dai 64 bit.
Ma questo non vuole dire ke nessun altro algoritmo può essere avvantaggiato.

Non ho mai detto che nessun altro algoritmo possa esserene avvantaggiato.

PS. Per favore, puoi scrivere senza k? E' sempre piu' faticoso seguirti.

percio adesso chi ha un sistema a 64 bit usa ancora windows xp 32 bit???:confused:

Originariamente inviato da repne scasb

[...]




Nel tuo codice hai omesso tutta una serie di istruzioni di ripristino dei registri che presuppongono accessi alla memoria (lo stack), istruzioni che io ho inserito.

Voglio credere che questa sia solo una ingenua dimenticanza, perche' quando inserisci anche quelle istruzioni nel codice dimostri quello che ho detto: una serie di istruzioni matematiche, immerse in una serie di accessi alla memoria che rendono le istruzioni risparmiate nel codice a 64 bit sostanzialmente gratuite.


Non hai correttamente letto la mia risposta, o non hai letto la mia risposta in modo intregrale.

Non e' il risultato del compilatore, in quanto nel sorgente 'C(++)' c'e' una moltiplicazione che non c'e' nel codice assembly generato dal compilatore. Spero di aver chiarito.

Non hai letto correttamente o in maniera integrale la mia risposta alla tua risposta: ho fatto copy&paste del codice prodotto dal compilatore (a meno di una chiamata al codice di controllo dei buffer overrun che non ci interessa).

Originariamente inviato da repne scasb
Un ultimo appunto, sulle prestazioni dei due codici 32 e 64 bit postati piu' sopra. Non ho spremuto al massimo il codice a 32-bit, comunque il codice a 64-bit e su Athlon64 3500+ e MSI K8N Neo2 Platinum il 278% piu' veloce (RDTSC/1.000.000.00 di iterazioni).

Voglio credere anche qui che hai dimenticato in buona fede di riportare le condizioni del tuo profiling, che sono il nodo centrale del discorso.
Come hai preso questi tempi?
Hai inserito la chiamata a funzione "in mezzo a del codice" oppure l'hai messa in mezzo ad un loop con solo la chiamata?

Ovvero:

codice;
codice;
codice;
chiamata a funzione;
codice;
codice

Oppure:
loop 1.000.000
chiamata a funzione

Perche' se hai fatto il secondo esperimento, hai dimostrato quello che ho detto fino ad ora: in caso di inner loop molto stretti (con tutto il working set in cache) e' ovvio che la seconda versione e' piu' veloce.

Ma questo non e' un esperimento realistico, e' una condizione limite, mi sembra un errore troppo ingenuo l'aver riportato quei dati in quella maniera con una conclusione cosi' perentoria che... e' falsa.

Ripeti l'esperimento buttando la chiamata a funzione in mezzo a dell'altro codice, in una situazione piu' realistica, e vediamo se noti la stessa differenza.

Questo e' il 319% piu veloce.

Ho utilizzato l'istruzione RDTSC come da me gia riportato. Per documentazione: IA_32 Intel Architecture Software Developer's Manual - Sezione 4-162 Volume 2B.

Ehehe... repn, in quanti cicli di clock viene eseguita da un P4 (scegli tu quale), questa istruzione:

mov eax, [mem]

Minimo e massimo :)

(ti faccio questa domanda perche' dalla tua ultima risposta mi viene il sospetto che tu non sappia come si faccia il profiling del codice)

Originariamente inviato da repne scasb
Forse e' il caso che precisi il significato "esatto" della mia precedente risposta, in modo da "non" permettere manipolazioni.

In sostanza, il test verte sul confronto 32/64 bit a parita di CPU. Nel caso specifico una CPU AMD Athlon64.

L'uso di istruzioni a 32 bit mov rg,[addr$] su Athlon64 permette (se gli accessi sono allineati ad 8 bytes), di ottenere prestazioni migliori rispetto a mov rg,[rg+off$]. Ne caso specifico, come gia' detto, non ho spremuto il massimo dalla routine a 32-bit, ma dovendo essere utilizzata su un Athlon64, ho preferito il primo tipo di indirizzamento rispetto al secondo. Altrimenti la routine sarebbe stata ancora piu' lenta rispetto alla versione a 64-bit.


Qui nessuno sta manipolando nulla. Oddio qualcuno ci sta provando, ma con scarsi risultati.

Ripeto la mia domanda, che e' assolutamente seria e precisa; quanti cicli di clock minimo e massimo sono necessari per eseguire la seguente istruzione:

mov eax, [mem]


Per quanto riguarda il profiling, consiste nel chiamare l'istruzione RDTSC prima della routine, salvare il contatore di clock, chiamare RDTSC alla fine, sottrarre il contatore di clock, dividere per il numero di iterate, derivarne le prestazioni in scala lineare, ossia:

Routine a 32 bit 1000 cicli di clock medi (esempio)
Routine a 64 bit 500 cicli di clock medi (sempre esempio)

da cui 1000/500=2 la routine a 64 bit e' il doppio piu' veloce. Spero sia tutto chiaro.

Se il profiling fosse solo chiamare RDTS sarebbe un mondo piu' bello e piu' semplice. Purtroppo la realta' e un po' piu' complessa e la seguente affermazione "tale funzione e piu' veloce di tal altra del 318.953235%" e' perfettamente priva di significato nel mondo reale.

Come provare a fregarci con un inner loop per dimostrare che il codice a 64 bit e piu' veloce di quello a 32 bit.
Nice try ;)

Rispondi alla mia domanda per cortesia? Per te che ci fai sempre tale sfoggio, non dovrebbe essere una risposta troppo complicata. Grazie.

Originariamente inviato da fek
Ripeto la mia domanda, che e' assolutamente seria e precisa; quanti cicli di clock minimo e massimo sono necessari per eseguire la seguente istruzione:

mov eax, [mem]


Ok, rispondo io alla domanda.

Quell'istruzione puo' impiegare ad essere eseguita da un minimo di zero cicli, se la cella di memoria e' nella cache di primo livello e la latenza viene coperta da altre istruzioni di accesso alla memoria, ad un massimo di milioni di clicli di clock, se la pagina della quale fa parte e' stata magari paginata su hard disk e quell'accesso causa un page fault, la CPU e' costretta ad una transizione in ring 0, caricare la pagina di memoria dall'hard disk alla memoria centrale, tornare in ring 3 e riprendere l'esecuzione.

In sintesi, le prestazioni di un frammento di codice dipendono fortemente dalle condizioni al contorno nel quale il codice stesso e' eseguito.
Per questo affermare che la versione di quella funzione a 64 bit e' due volte piu' veloce della versione a 32 bit significa non sapere di che cosa si sta parlando. Quella versione e' due volte piu' veloce nelle condizioni dell'esperimento, ovvero nelle condizioni ideali d'esecuzione, in un inner loop, con tutto il working set in cache, codice in cache, salti tutti predetti correttamente. Purtroppo sono condizioni di esecuzioni irrealistiche :)

In condizioni di esecuzione piu' realistiche, dove la stessa chiamata a funzione e' effettuata all'interno di un algoritmo piu' complesso, con il suo working set che magari non e' sempre in cache, con determinati pattern d'accesso alla memoria, la versione a 64 bit potrebbe anche risultare piu' lenta di quella a 32 bit, o di qualche punto percentuale piu' veloce, oppure esattamente equivalente. Dipende fortemente dalle condizioni di esecuzione.

Per questo mi e' venuto il dubbio che repne non sappia di che cosa sta parlando, o, molto piu' probabilmente, sa di che parla ma ha provato a fare orecchie da mercante ed ha solo cercato di manipolarsela a suo favore per chissa' quale motivo di autocelebrazione.

Un altro esempio per chiarire, la famosa tecnica di ottimizzazione per calcolare il valore del coseno di un angolo: invece di fare i calcoli della funzione (o di una sua approssimazione) si memorizzano i risultati in una tabella dove per ogni angolo e' memorizzato il valore del suo coseno. Dato l'angolo, con una semplice lettura dalla memoria si ha il risultato, apparentemente molto piu' veloce che farsi i calcoli.
Funzionava a meraviglia dieci anni fa; magari chiamando questa funzione del coseno un milione di volte anche oggi si trova che e' dieci volte piu' veloce della versione che calcola il valore senza la tabella, poi si chiama la stessa funzione dall'algoritmo che si sta cercando di ottimizzare e si scopre che... va piu' lento. La tabella di coseni occupa spazio nella cache di primo livello che causa un aumento del working set dell'algoritmo rallentandolo. Mi e' successo l'anno scorso.

Morale della favola, fare profiling non significa chiamare RDTSC, significa capire le condizioni di esecuzione di un frammento di codice e da li' capirne il profilo prestazionale interpretando i dati del profiler.

Originariamente inviato da fek
Si', sono decisamente il caso di calcoli intensivi su inner loop molto stretti (il raytracing ad esempio). Ma quelli sono calcoli in floating point...
Mi stona molto il risultato di MySQL... ma siamo sicuri che qui stiamo analizzando le ottimizzazioni architetturali oppure la differenza fra codice a 32 bit e 64 bit?
Perche' non vedo davvero dove la seconda possa entrare in calcoli floating point effettuati da un raytracer...
Per quanto mi riguarda sto confrontando le differenze architetturali nell'esecuzione di codice fra x86 e x86-64: quindi non semplicemente fra codice a 32 e 64 bit, se non intendendo con ciò x86-32 e x86-64 rispettivamente, nel loro complesso.

E' chiaro che i 64 bit di per sé non posso influire da soli nei risultati: è l'intera architettura che, essendo diversa, comporta delle differenze in termini prestazionali. Con ciò si spiega il guadagno di POV-Ray, che fa massiccio uso di calcoli in floating point, come giustamente sottolinei, e penso nessun uso di variabili intere a 64 bit. Evidentemente il maggior numero di registri GPR/SSE, ecc. ha portato a questo risultato.

Originariamente inviato da fek
Non hai letto correttamente o in maniera integrale la mia risposta alla tua risposta: ho fatto copy&paste del codice prodotto dal compilatore (a meno di una chiamata al codice di controllo dei buffer overrun che non ci interessa).
Rimane il fatto che nel disassemblato che hai fornito non è presente neppure un'istruzione di moltiplicazione, che è assolutamente necessaria (ce ne vogliono almeno tre, come giustamente ha riportato repne scasb) per calcolare in maniera corretta la funzione che hai riportato.
Infatti i due sorgenti che hai postato, in C e assembly, non calcolano la stessa funzione, ed è questo (penso) che voleva farti notare repne scasb.

Originariamente inviato da fek
In sintesi, le prestazioni di un frammento di codice dipendono fortemente dalle condizioni al contorno nel quale il codice stesso e' eseguito.
Per questo affermare che la versione di quella funzione a 64 bit e' due volte piu' veloce della versione a 32 bit significa non sapere di che cosa si sta parlando. Quella versione e' due volte piu' veloce nelle condizioni dell'esperimento, ovvero nelle condizioni ideali d'esecuzione, in un inner loop, con tutto il working set in cache, codice in cache, salti tutti predetti correttamente. Purtroppo sono condizioni di esecuzioni irrealistiche :)

In condizioni di esecuzione piu' realistiche, dove la stessa chiamata a funzione e' effettuata all'interno di un algoritmo piu' complesso, con il suo working set che magari non e' sempre in cache, con determinati pattern d'accesso alla memoria, la versione a 64 bit potrebbe anche risultare piu' lenta di quella a 32 bit, o di qualche punto percentuale piu' veloce, oppure esattamente equivalente. Dipende fortemente dalle condizioni di esecuzione.
Questo è pacifico: le condizioni al momento dell'esecuzione posso chiaramente influenzare anche pesantemente l'esecuzione del codice, ma se dovessimo considerare tutte le variabili che possono incidere, che senso avrebbe effettuare il profiling di un codice? Nessuno, perché non si sa mai in quali condizioni verrà eseguito: quali pagine del codice, dei dati e dello stack sono caricati in memoria, quali parti stanno nella cache L1, in quella L2 (eventualmente nella L3), quali pagine sono mappate nei tag del TLB, ecc. ecc. ecc.

Penso che sia ragionevole, invece, spostare l'attenzione sul punto di vista di un compilatore, che di tutte queste variabili non è assolutamente a conoscenza e comunque, sorgente "alla mano", deve pur tirare fuori un codice eseguibile.
Da questo punto di vista, analizzando indifferentemente le prime o le seconde versioni a 32 e 64 bit della funzione di cui sopra, mi sembra più che evidente che il codice che POTENZIALMENTE girerà più velocemente e quello per x86-64: è molto più compatto (quindi occupa meno spazio nella cache), utilizza meno istruzioni, meno accessi alla memoria, esegue una sola moltiplicazione, utilizza meno registri e quindi può anche fare a meno di spostare avanti e indietro registro nello stack/cache/memoria.

D'altra parte ti sarai reso conto che POV-Ray ha evidenziato un notevole miglioramento, pur non usando registri (interi) a 64 bit: eppure i puntatori "pesano" il doppio, le strutture quindi occupano più spazio -> più accessi alla memoria -> più accessi alla cache & meno spazio disponibile per gli altri dati/codice, il codice x86-64 occupa il 20% circa in più di spazio, ecc. ecc.

Morale della favola, fare profiling non significa chiamare RDTSC, significa capire le condizioni di esecuzione di un frammento di codice e da li' capirne il profilo prestazionale interpretando i dati del profiler.
D'accordo, ma vedi sopra: possiamo andare avanti per centinaia di messaggi, ed è chiaro che fare il profiling di due codici completamente diversi, quali sono quelli a 32 e 64 bit di cui sopra, non porterà a niente. Com'è anche più che evidente che gli incrementi prestazionali dell'architettura x86-64 esistono, e spesso sorprendono anche te... ;)

Originariamente inviato da cdimauro
Per quanto mi riguarda sto confrontando le differenze architetturali nell'esecuzione di codice fra x86 e x86-64: quindi non semplicemente fra codice a 32 e 64 bit, se non intendendo con ciò x86-32 e x86-64 rispettivamente, nel loro complesso.

E' chiaro che i 64 bit di per sé non posso influire da soli nei risultati: è l'intera architettura che, essendo diversa, comporta delle differenze in termini prestazionali. Con ciò si spiega il guadagno di POV-Ray, che fa massiccio uso di calcoli in floating point, come giustamente sottolinei, e penso nessun uso di variabili intere a 64 bit. Evidentemente il maggior numero di registri GPR/SSE, ecc. ha portato a questo risultato.

Si', mi trovi d'accordo, anch'io direi che la maggior parte dei miglioramenti che hai riportato sono dovuti all'architettura piu' efficiente.

Originariamente inviato da cdimauro
Rimane il fatto che nel disassemblato che hai fornito non è presente neppure un'istruzione di moltiplicazione, che è assolutamente necessaria (ce ne vogliono almeno tre, come giustamente ha riportato repne scasb) per calcolare in maniera corretta la funzione che hai riportato.
Infatti i due sorgenti che hai postato, in C e assembly, non calcolano la stessa funzione, ed è questo (penso) che voleva farti notare repne scasb.

Mi fai sorgere il dubbio di aver sbagliato il copy&paste dal debugger.

Originariamente inviato da cdimauro
Questo è pacifico: le condizioni al momento dell'esecuzione posso chiaramente influenzare anche pesantemente l'esecuzione del codice, ma se dovessimo considerare tutte le variabili che possono incidere, che senso avrebbe effettuare il profiling di un codice? Nessuno, perché non si sa mai in quali condizioni verrà eseguito: quali pagine del codice, dei dati e dello stack sono caricati in memoria, quali parti stanno nella cache L1, in quella L2 (eventualmente nella L3), quali pagine sono mappate nei tag del TLB, ecc. ecc. ecc.

Esatto, non ha senso fare il profiling di una funzione separata dal contesto. E' proprio il punto al quale volevo arrivare.
E' un esercizio che non porta a nessuna informazione e che lascio volentieri agli accademici ;)

A me interessano i discorsi pragmatici e valutare mediamente quale impatto prestazionale possa avere il codice a 64 bit rispetto a quello a 32 bit in media. Alla luce della discussione direi molto basso se non in casi molto specifici. Qui sto parlando di codice a 64 bit non di codice per l'architettura x86-64, dal quale credo sia nata la confusione.

Da questo punto di vista, analizzando indifferentemente le prime o le seconde versioni a 32 e 64 bit della funzione di cui sopra, mi sembra più che evidente che il codice che POTENZIALMENTE girerà più velocemente e quello per x86-64: è molto più compatto (quindi occupa meno spazio nella cache), utilizza meno istruzioni, meno accessi alla memoria, esegue una sola moltiplicazione, utilizza meno registri e quindi può anche fare a meno di spostare avanti e indietro registro nello stack/cache/memoria.

Di nuovo no, questa conclusione e' errata, perche' quel codice puo' potenzialmente essere piu' lento, piu' veloce oppure uguale. Una volta messo nel suo ambiente si puo' dare una risposta e questa risposta dipende da svariati fattori.

Accedere una tabella trigonometrica ha meno istruzioni (solo una), usa meno registri (solo uno), ha meno accessi alla memoria (solo uno), potenzialmente girera' molto piu' velocemente rispetto a fare i calcoli. Toh, va piu' piano :)

D'accordo, ma vedi sopra: possiamo andare avanti per centinaia di messaggi, ed è chiaro che fare il profiling di due codici completamente diversi, quali sono quelli a 32 e 64 bit di cui sopra, non porterà a niente. Com'è anche più che evidente che gli incrementi prestazionali dell'architettura x86-64 esistono, e spesso sorprendono anche te... ;)

I risultati dell'architettura non mi sorprendono affatto, mi sorprenderebbe se passare da 32 bit a 64 bit (non da architettura ad architettura) portasse ad incrementi medi del 30% come qualche utente ho sostenuto, ed e' cio' che contesto.

Domanda forse capziosa: se i miglioramenti architetturali (piu' registri, etc) fossero stati implementati senza i registri a 64bit secondo te avremmo ottenuto incrementi prestazionali simili, superiori o inferiori? Direi simili.

Scusate ma si può scaricare oppure no?

Originariamente inviato da fek
Di nuovo no, questa conclusione e' errata, perche' quel codice puo' potenzialmente essere piu' lento, piu' veloce oppure uguale.
Ovviamente il discorso di cdimauro è nel campo delle supposizioni.
Dal momento che puntatori a 64 bit occupano più spazio ti aspetti un maggior numero di cache miss, e quindi prestazioni peggiori a parità di altri fattori.
Dal momento che il codice della funzione che hai postato compilato a 64 bit è molto più compatto, ti aspetti che porti a meno cache miss e prestazioni migliori in alcuni casi (anche se stiamo parlando di cache del codice, non è la stessa cosa :p).

Domanda forse capziosa: se i miglioramenti architetturali (piu' registri, etc) fossero stati implementati senza i registri a 64bit secondo te avremmo ottenuto incrementi prestazionali simili, superiori o inferiori? Direi simili.
Credo che questo risponda adeguatamente:
http://www.anandtech.com/guides/viewfaq.html?i=112

Di fatto solo lo spazio di indirizzamento maggiore richiede necessariamente 64 bit. I miglioramenti nel calcolo di interi sono marginali.
AMD è stata molto astuta nell'aggiungere molti miglioramenti architetturali negli Athlon64, in modo da rendere più vantaggioso il passaggio alla nuova piattaforma, anche in assenza di codice in grado di sfruttarne le caratteristiche.
Nessuno si aspetta prestazioni maggiori dai G4 perchè a 64 bit...

Originariamente inviato da Banus
Credo che questo risponda adeguatamente:
http://www.anandtech.com/guides/viewfaq.html?i=112


Piu' che adeguatamente :)


I’ve been seeing a lot of confusion surrounding 64-bit computing lately, undoubtedly spurred by discussion of AMD’s Hammer. There seems to be this idea that 64-bit computing will provide a 2X performance increase over 32-bit computing; this couldn’t be more false. This idea was probably proliferated by video game console marketing (ie, a “64-bit” game console is twice as fast as a “32-bit” one.) I often see the phrase “a 64-bit CPU can process twice as much data per cycle as a 32-bit CPU” or something similar in articles, implying that the 64-bit CPU is twice as fast.

Originariamente inviato da fek
E' quello che cerco di spiegarti, in un raytracer non apprezzi i benefici dei 64 bit, apprezzi i benefici di un'architettura piu' performante ed e' un discorso molto diverso. Ed un raytracer non e' "in quasi tutti i campi", e' un solo campo.

Quello che ti sto contestando e' che il passaggio da 32 a 64 bit possa portare benefici prestazionali in tutti i campi, no, non e' vero. I miglioramenti dell'architettura si', i 64 bit no.


Appunto. Per risponderti leggi uno dei miei primi post in questo thread:


il passaggio 16 bit 32 bit non ha NIENTE a ke vedere con quello 32 -64.
In quest'ultimo le maggiori prestazioni saranno dettate SOPRATTUTTO dal raddoppio dei registri del processore, con incrementi ke possono raggiungere anke il 20%.
inoltre sarà possibile un ULTERIORE boost x via dei programmi ke si avvantaggeranno del calcolo nativo a 64 bit. Ma non è assolutamente SOLO questo il guadagno.


che cosa ho detto di diverso rispetto a quello ke tu stai dicendo nel pezzo ke ho quotato???

e cmq il raytracer è solo un campo, ma anke l'encoding video, l'encoding audio, la compressione, i database sono altri campi....
qdi permettimi di dire ke non sono poi così poche le applicazioni che beneficieranno di WIN XP 64.

Originariamente inviato da repne scasb
Purtroppo l'esempio di fek e' stato infelice, in quanto ha postato del codice con una moltiplicazione a 64-bit. Si tratta, in effetti, di un "raro" caso in cui il codice a 64-bit e' sicuramente piu' veloce, in quanto "esiste" in mode_64 un istruzione "nativa" per fare una moltiplicazione a 64-bit (cosa che in PM_32 richiede almeno 3 moltiplicazioni).


"Sicuramente piu' veloce". Evidentemente non hai letto nulla di quello che ho scritto io e neppure hai letto l'articolo. Mi sembra offensivo nei confronti di chi legge dover ripetere daccapo il concetto.

Pazienza, hai sprecato una buona occasione.

Originariamente inviato da repne scasb
Sveglia. Magari cosi' e' piu' chiaro:

Si tratta, in effetti, di un "RARO" caso in cui il codice a 64-bit e' sicuramente piu' veloce

Per prima cosa "sveglia" lo dici alle tue amichette, non mi sembra di averti mai mancato di rispetto.
Poi, e te lo ripeto per l'ultima volta, quel codice non e' sicuramente piu' veloce, ma dipende dal contesto.
Sembra che tu non abbia mai preso in mano un profiler in vita tua.


P.S. Gia' che ci sei impara anche a fare copia e incolla dal debugger.

Ho sbagliato a fare il copia e incolla, sai, io non ho problemi ad ammettere quando commetto un errore, e' perfettamente umano ed in genere non mi faccio prendere da crisi isteriche, tanto meno su un forum :)

La prossima volta sarai piu' fortunata.

x repne

scusa, potresti rispondere alle obiezioni di fek, di 2-3 post fà, domanda inclusa?

Perchè n riesco a stare dietro al proseguo della discussione e andando passo per passo forse mi risulterebbe + chiario il contraddittorio.

Se n ti dispiace eh, lo chiedo solo perchè vorrei capirne di + :)

Originariamente inviato da repne scasb
Sveglia. Magari cosi' e' piu' chiaro:

Si tratta, in effetti, di un "RARO" caso in cui il codice a 64-bit e' sicuramente piu' veloce

P.S. Gia' che ci sei impara anche a fare copia e incolla dal debugger.
:rolleyes:
se nn sai è meglio che ti stai zitto ;)

Originariamente inviato da Capirossi
:rolleyes:
se nn sai è meglio che ti stai zitto ;)

ha parlato il guru della programmazione :rolleyes: ( e poi è una donna, se tu avessi mai seguito qlc thread della sezione dove ha postato)


P.S.: possiamo fare in modo che la discussione n degeneri

a me interessava molto...



Thx

Originariamente inviato da Capirossi
:rolleyes:
se nn sai è meglio che ti stai zitto ;)

Su su su, non degeneriamo.

Originariamente inviato da DioBrando
ha parlato il guru della programmazione :rolleyes: ( e poi è una donna, se tu avessi mai seguito qlc thread della sezione dove ha postato)

il guro no :muro: ma in 64 bit mode il winch attiva dei registri interni nel processore , quindi le prestazioni nn dovrebbero diminuire :D
ma forse si riferisce ai driver ancora immaturi per in win 64 e nn è colpa dei 64 bit :D

Originariamente inviato da fek
Sembra che tu non abbia mai preso in mano un profiler in vita tua

Le obiezioni pubblicate da "fek" sono irrilevanti.
La domanda pubblicata da "fek" e' irrilevante.

L'irrilevanza consiste nel fatto che una risposta sensata alle obiezioni di "fek" non aggiunge o toglie nulla al contesto della discussione.

Il punto e' questo:

1) L'utente "fek" posta del codice ad alto livello, e il suo equivalente in assembly prodotto dal debugger di cui fa uso.
_______________________________________________

Sembra che rispondi con un linguaggio da star trek!

Originariamente inviato da Capirossi
il guro no :muro: ma in 64 bit mode il winch attiva dei registri interni nel processore
Leggi la discussione dall'inizio ;)
Di questo ne abbiamo già parlato :D

Secondo me è meglio chiarire i termini.
E' evidente che il codice della funzione compilata a 64 bit è più veloce, ha meno istruzioni e accessi in memoria. Infatti nei test di repne si ottengono prestazioni migliori del 300% almeno.

Non è detto che questo comporti una migliore efficienza del programma in cui la funzione è inserita, che dipende da molti altri fattori, fra cui la dimensione della cache. Può esserci il caso disgraziato in cui l'overhead dovuto a puntatori a 64 bit (sto assumendo che in modalità 64 bit i puntatori siano necessariamente interi a 64 bit) è determinante e causa cache miss.
Oppure se l'esecuzione è limitata dagli accessi in memoria, anche il codice a 32 bit avrà buone prestazioni perchè non è il processore a determinare la velocità.
Ma queste supposizioni da un certo punto di vista sono inutili... basta prendere un profiler e verificare effettivamente cosa succede, e trarre le conclusioni. Oppure eseguire benchmark su applicazioni diverse, con diverse caratteristiche. E da questo punto di vista l'Athlon64 se la cava bene, e mostra il vantaggio di usare la modalità a 64 bit.

Originariamente inviato da GiovanniGTS
Sembra che rispondi con un linguaggio da star trek!
[OT] Negotiation is irrelevant, resistance is futile :D

Originariamente inviato da repne scasb
Le obiezioni pubblicate da "fek" sono irrilevanti.
La domanda pubblicata da "fek" e' irrilevante.

Sono irrilevanti per te perche' non ne conoscevi la risposta.

E ti ripeto che io non sono una delle tue amichette, rivolgiti con rispetto.
E' evidente che non sei in grado di affrontare una discussione matura, percio' ti saluto.

Originariamente inviato da Capirossi
il guro no :muro: ma in 64 bit mode il winch attiva dei registri interni nel processore , quindi le prestazioni nn dovrebbero diminuire :D
ma forse si riferisce ai driver ancora immaturi per in win 64 e nn è colpa dei 64 bit :D

lasciamo stare che è meglio...

Originariamente inviato da repne scasb
Possile che non parliamo la stessa lingua?
Credo che intenda il "sicuramente" in senso matematico.

Originariamente inviato da repne scasb
Le obiezioni pubblicate da "fek" sono irrilevanti.
La domanda pubblicata da "fek" e' irrilevante.

L'irrilevanza consiste nel fatto che una risposta sensata alle obiezioni di "fek" non aggiunge o toglie nulla al contesto della discussione.

Il punto e' questo:

1) L'utente "fek" posta del codice ad alto livello, e il suo equivalente in assembly prodotto dal debugger di cui fa uso.
2) Le due parti non sono congruenti. Ossia il codice dell'uno non combacia in consistenza con il codice dell'altro.
3) Faccio notare 2 volte cio' all'utente "fek", senza che nelle sue risposte trapeli che abbia compreso quanto dico.
4) In un mio post chiarisco in modo "ineluttabile" che sono d'accordo con quanto espresso da fek: ossia che non ci sono incrementi prestazionali dal passaggio da 32 a 64 bit.
5) Ancora una volta "fraintende" il mio pensiero. Da cui deduco che sta dormendo.
6) Sveglia e il carattere grande con la scritta "raro" sono utilizzare da me per destare la sua attenzione.
7) Ancora una volta non comprende.
8) Domanda: dorme ancora?

scusa, ma stò perdendo del tutto il significato della discussione.

All'inizio si era partiti con il passaggio dai 32 ai 64 bit comporta o non comporta degli incrementi ( a mio modesto parere, vedendo i vari tests che sn stati pubblicati sì).
Fek se n sbaglio afferma invece che gli incrementi non ci sn, salvo rare eccezioni ( come quella di PovRay) e che il miglioramento delle prestazioni deriva dall'architettura dell'Athlon64 non dall'utilizzo dei 64 bit...

Per dimostrare la sua tesi posta del codice e la sua traduzione in Assembly effettuata da un debugger.

Tu ribatti che però questa traduzione non è corretta specificando nel dettaglio.
Ora però affermi che sei sostanzialmente d'accordo con la sua tesi e cioè che di per sè il passaggio ai 64bit è ininfluente ( fek anzi ha ipotizzato addirittura un calo di prestazioni in certi ambiti e che cmq dipende dalle condizioni in cui questa architettura viene impiegata).


Insomma il motivo del vostro disaccordo è "solamente" il fatto che il codice postato in precedenza non è ( per te) quello corretto?

Cioè i 64 bit n c'entrano +, o mi sbaglio...?

Originariamente inviato da repne scasb
Puoi spiegarti meglio, sono curiosa. Grazie.
Nel senso che:
- Per ogni programma che incorpora la funzione func_64 nel codice
- Per ogni possibile esecuzione del programma (cioè dato qualsiasi input)

tempo di esecuzione 64 bit <= tempo di esecuzione 32 bit

per programma e sequenza di input fissati.

Ovviamente la certezza in generale non si può avere perchè è un caso particolare del problema della terminazione di un programma :p

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?

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 :)

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.

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 :)

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 :)

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

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.

Originariamente inviato da fek
Esatto, non ha senso fare il profiling di una funzione separata dal contesto. E' proprio il punto al quale volevo arrivare.
E' un esercizio che non porta a nessuna informazione e che lascio volentieri agli accademici ;)
E a chi scrive compilatori... :D
A me interessano i discorsi pragmatici e valutare mediamente quale impatto prestazionale possa avere il codice a 64 bit rispetto a quello a 32 bit in media.
Il problema è stabilire quel "in media" di cui parli: se non specifichi chiaramente quali sono le condizioni "nella media", sia per il codice per x86 sia per quello x86-64, non ne usciamo più.
D'altra parte tu fai profiling (e ci mancherebbe ;)) per cui per valutare se un codice è "più veloce di un altro" (occhio alle virgolette, eh! :)) devi per forza di cosa fissare i parametri relativi al profiling.
Fissati questi, IMHO, si può pensare di fare un confronto fra l'esecuzione di codice x86 e x86-64 sulla stessa macchina per lo stesso programma.
Alla luce della discussione direi molto basso se non in casi molto specifici. Qui sto parlando di codice a 64 bit non di codice per l'architettura x86-64, dal quale credo sia nata la confusione.
Lo credo anch'io. Comunque l'importante è che si sia fatta luce sul significato di 32 e 64 bit in seno alla discussione.
Di nuovo no, questa conclusione e' errata, perche' quel codice puo' potenzialmente essere piu' lento, piu' veloce oppure uguale. Una volta messo nel suo ambiente si puo' dare una risposta e questa risposta dipende da svariati fattori.
OK, e sono d'accordo (infatti ho evidenziato che quello è il punto di vista del compilatore): vedi sopra comunque. Cerchiamo di fornire un contesto preciso e vediamo cosa succede.
Accedere una tabella trigonometrica ha meno istruzioni (solo una), usa meno registri (solo uno), ha meno accessi alla memoria (solo uno), potenzialmente girera' molto piu' velocemente rispetto a fare i calcoli. Toh, va piu' piano :)
"Il precalcolo è alla base del real-time" era una massima in voga fino a poco tempo fa... ;)
I risultati dell'architettura non mi sorprendono affatto, mi sorprenderebbe se passare da 32 bit a 64 bit (non da architettura ad architettura) portasse ad incrementi medi del 30% come qualche utente ho sostenuto, ed e' cio' che contesto.
E su cui sono AMPIAMENTE d'accordo: ho sempre rimarcato, da tre anni a questa parte, che non è la sola estensione dei registri a 64 bit che comporterà un aumento di velocità per l'architettura x86. ;)
Domanda forse capziosa: se i miglioramenti architetturali (piu' registri, etc) fossero stati implementati senza i registri a 64bit secondo te avremmo ottenuto incrementi prestazionali simili, superiori o inferiori? Direi simili.
Io direi superiori. ;) Rimanendo a 32 bit, i puntatori occuperebbero meno spazio, con tutte le conseguenze di cui abbiamo discusso finora. Questo tenendo sempre presente che comunque il codice che utilizza i nuovi registri (alla fine sarebbe soltanto questa la differenza a livello di ISA fra x86-64 e la medesima "castrata" del supporto ai 64 bit) occupa dello spazio in più.

Anzi, preciso che prima ho detto che il codice per x86-64 occupa mediamente un 20% in più: ciò non è esatto (la fretta è cattiva consigliera purtroppo :(), perché non è relativo a tutto il codice, ma quanto scritto si verifica quando si utilizzano i nuovi registri e/o se ne forza l'uso a 64 bit.

Questo, però, è controbilanciato dal fatto che si usano molti meno accessi alla memoria e il codice, in fin dei conti, risulta molto più compatto (com'è evidente anche dai sorgenti della tua funzione per x86 e x86-64), e quindi occupa meno spazio (coi vantaggi che ciò può comportare).

EDIT: correzione grammaticale... :p

Originariamente inviato da RaouL_BennetH
perdonami, ma questo non genera un eseguibile "non pensato" a monte (sorgente) per una determinata architettura e, di conseguenza, meno efficiente?
Sicuramente, ma questo vale per tutti i processori che presentano qualche miglioramento architetturale. E comunque credo che un compilatore ottimizzato per il particolare processore riesca a ridurre di molto la differenza.

Il rischio è un altro. Un'applicazione può contenere del codice pensato specificatamente per i 32 bit, ad esempio, tratta i puntatori come interi a 32 bit. Si tratta di tecniche di programmazione che è meglio evitare se si vuole codice pulito e facilmente leggibile, ma può capitare.
In quel caso è possibile che l'applicazione non funzioni, o non funzioni nel modo corretto.
Visual Studio 2003 ha l'opzione "controlla compatibilità 64 bit" proprio con l'intenzione di favorire codice portabile a 64 bit senza modifiche.

Originariamente inviato da Banus
Ovviamente il discorso di cdimauro è nel campo delle supposizioni.
Dal momento che puntatori a 64 bit occupano più spazio ti aspetti un maggior numero di cache miss, e quindi prestazioni peggiori a parità di altri fattori.
Dal momento che il codice della funzione che hai postato compilato a 64 bit è molto più compatto, ti aspetti che porti a meno cache miss e prestazioni migliori in alcuni casi (anche se stiamo parlando di cache del codice, non è la stessa cosa :p).
Hai centrato il senso del mio messaggio. ;) Poi è chiaro che il contesto può cambiare tutto, come giustamente afferma fek.
Credo che questo risponda adeguatamente:
http://www.anandtech.com/guides/viewfaq.html?i=112

Di fatto solo lo spazio di indirizzamento maggiore richiede necessariamente 64 bit. I miglioramenti nel calcolo di interi sono marginali.
AMD è stata molto astuta nell'aggiungere molti miglioramenti architetturali negli Athlon64, in modo da rendere più vantaggioso il passaggio alla nuova piattaforma, anche in assenza di codice in grado di sfruttarne le caratteristiche.
Infatti non è un caso il fatto che di default le operazioni siano a 32 bit, e che per usare i 64 bit bisogna forzare gli opcode con l'apposito prefisso. ;)
Nessuno si aspetta prestazioni maggiori dai G4 perchè a 64 bit...
Esattamente. Questo è anche il motivo per cui Apple per Tiger ha preferito una soluzione "ibrida" per il suo nuovo s.o.: le applicazioni dotate di GUI rimangono sempre a 32 bit, e per usare i 64 bit si deve scrivere un'altra applicazione che s'interfaccia con la prima tramite messaggi.
In pratica i 64 bit vengono assolutamente sconsigliati, se non per i casi in cui i programmatori ritengono ci possano essere degli effettivi vantaggi (consistenti manipolazioni di dati a 64 bit e/o indirizzamento a 64 bit della memoria): i puntatori a 64 bit occupano troppo spazio, e il context switch di un task che usa registri a 64 bit è chiaramente più lento.

D'altra parte, a differenza degli AMD64, i G5 comportano esclusivamente un'estensione a 64 bit dei registri (e quindi dei puntatori): non esistono altre novità architetturali che possano permettere incrementi prestazionali, e quindi bilanciare ed eventualmente superare il decadimento prestazionale di cui sopra (puntatori a 64 bit in primis).

Originariamente inviato da repne scasb
Sono intervenuta, con soltanto questa motivazione.
Avevo capito bene allora... :)
Purtroppo l'esempio di fek e' stato infelice, in quanto ha postato del codice con una moltiplicazione a 64-bit. Si tratta, in effetti, di un "raro" caso in cui il codice a 64-bit e' sicuramente piu' veloce, in quanto "esiste" in mode_64 un istruzione "nativa" per fare una moltiplicazione a 64-bit (cosa che in PM_32 richiede almeno 3 moltiplicazioni).
Più tutte le somme (che generano anche dipendenza nei risultati), e l'ampio uso di registri, tanto da richiedere degli accessi ripetuti alle stesse locazioni di memoria (si sarebbero potuti evitare salvando il registro EBP nello stack al momento opportuno e usando, come pure l'uso del registro EBX: ma sono "finezze" che generalmente sfuggono a un compilatore... ;)).

Credo che questo sia uno dei pochi esempi in cui, tralasciando tutto il discorso del contesto a cui è legato il codice, i vantaggi dell'uso di registri e operazioni a 64 bit siano notevoli (sempre sulla carta).
Nello specifico, l'aumento di prestazione dell'Athlon64 da PM_32 a mode_64 non dipende affatto dai 64-bit (tranne lo "sfortunato" esempio di fek) (http://forum.hwupgrade.it/showthread.php?s=&threadid=595067&perpage=20&highlight=&pagenumber=7), dalla cui transizione c'era addirittura sentore di un deterioramento delle prestazioni, ma da alcune scelte "architetturali" attive solo in mode_64.
Avevo già letto quel tuo post (e i seguenti) molto interessante, e devo dire che sono rimasto sorpreso da queste scelte. Comunque penso che sia necessario un maggior approfondimento e altre prove per verificare con assoluta certezza se effettivamente l'esecuzione del codice in modalità x86 (32) sia stata "castrata" a favore dell'esecuzione in x86-64.

Originariamente inviato da cdimauro
Anzi, preciso che prima ho detto che il codice per x86-64 occupa mediamente un 20% in più: ciò non è esatto (la fretta è cattiva consigliera purtroppo :(), perché non è relativo a tutto il codice, ma quanto scritto si verifica quando si utilizzano i nuovi registri e/o se ne forza l'uso a 64 bit.
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. Arstechnica parla di un byte di overhead (su 4 del codice a 32 bit) per le istruzioni a 64.
D'altra parte con meno accessi alla memoria mi aspetterei meno istruzioni, che quindi controbilancerebbero l'overhead. Quindi il 10% è ottenuto dal confronto fra codici compilati (= test), o è una stima basata sulla ricorrenza media di un certo tipo di istruzione?

Però ragazzi il prodotto non è ancora uscito è già fate tutto questo gran casino, oppure dovrei usare un termine politicaly correct come rumors...
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...

Originariamente inviato da Capirossi
il guro no :muro: ma in 64 bit mode il winch
Conosco il Grinch, ma non ho mai sentito parlare del "winch"... ;)
attiva dei registri interni nel processore , quindi le prestazioni nn dovrebbero diminuire :D
Vedo che hai capito molto di tutto quello che abbiamo detto finora... :rolleyes: :muro:
ma forse si riferisce ai driver ancora immaturi per in win 64 e nn è colpa dei 64 bit :D
OK, come sopra: ma non era meglio se non lo scrivevi questo messaggio? :rolleyes:

Originariamente inviato da DioBrando
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...
Rispondo io a questa tua domanda, visto che ho accumulato abbastanza esperienza nel campo dei database. :)

L'engine di un database può avvantaggiarsi dei 64 bit (dicendo ciò limito la discussione solamente all'uso di quantità a 64 bit e alle operazioni su di esse) nei seguenti casi:

- tipo di dati intero a 64 bit (usato spesso per generare l' "ID" di un ben preciso record);
- tipo di dati "currency", che a tutti gli effetti utilizza un intero a 64 bit.

A ciò, nella mia esperienza con l'engine SQL InterBase / FireBird, aggiungo anche un ID "interno" che il sistema transazionale utilizza per identificare in maniera univoca un ben determinato record all'INTERNO DI UNA DETERMINATA TRANSAZIONE, e che fa uso di un intero a 64 bit (se non ricordo male deriva dalla combinazione del numero di pagina all'interno del file in cui si trova il record, più l'offset all'interno del record, più un valore legato alla transazione in oggetto).

In particolare quest'ultimo punto può portare notevoli vantaggi, dato l'elevato numero di record che può interessare una transazione (InterBase / FireBird utilizza un sistema transazionale di tipo "ottimistico", per cui ogni transazione "vede" una SUA copia dei record con cui interagisce, in lettura e/o scrittura).

Non solo: aggiungo che questo particolare engine SQL permette, tramite un'estensione proprietaria del suo "linguaggio SQL", di accedere a questo "ID interno" direttamente, per cui se usato SAPIENTEMENTE (si tratta di un'informazione MOLTO delicata, com'è facile intuire) permette di scrivere delle query che posso essere eseguite anche MOLTO, ma MOLTO velocemente rispetto alla medesima, ma scritto in modo "pulito" (beh, anche questo è un modo "pulito", perché concesso dall'engine SQL ;)).
N.B. Anche Oracle mi sembra che abbia un meccanismo similare. ;)

OK, tornando a noi e ai 64 bit (e tralasciando l'esempio di InterBase / FireBird: non tutti gli engine SQL funzionano così ;)), è evidente che l'incremento prestazionale si ottiene perché gli ID a 64 bit sono molto usati di per sé, come pure nelle applicazioni che hanno a che fare con i soldi il currency è il tipo di dati usato per eccellenza.

Detto ciò, i vantaggi mostrati da MySQL derivano anche dal resto dell'architettura x86-64: ad esempio l'SQL è un linguaggio molto complesso, e un parser che ha disposizione numerosi registri "ci va a nozze" per quest'operazione... ;)

Spero di aver soddisfatto la tua curiosità / i tuoi dubbi... :)

Originariamente inviato da RaouL_BennetH
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.
Considera che il sorgente di un programma normalmente non viene espressamente pensato / scritto per una determinata architettura. Questo può anche verificarsi (ad esempio, se so che l'architettura utilizzata è VLIW o è fortemente penalizzata dai salti, cercherò di scrivere il codice limitandoli il più possibile, per quel che si può fare), ma appunto non è la norma.

Per il resto, ti ha già risposto Banus... ;)

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

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". :rolleyes:
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.

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... :D
Tutto ciò IMHO, chiaramente. ;)

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 :p
Comunque mi ricordo che ne parlavi nell'altro thread, è una caratteristica molto interessante.

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 :D), 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 :cry: ).

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.

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

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



[B]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". :rolleyes:



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!

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;)

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". ;)

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 :p, 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 :p

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

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 !

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 :)

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.

Molto interessante questa discussione!
Prima di leggerla ero convinto che passare a 64bit comportava solo vantaggi :p

Dopo aver letto tutta la discussione sono pienamente daccordo con fek, i vantaggi migliori si avrebbero su calcoli ripettivi su pacchetti di dati e/o variabili di dimensioni abbastanza ridotti da poter essere contenuti nella cache evitando accessi alla memoria esterna, condizione che credo sia abbastanza rara per la maggior parte dei programmi.

Faccio un esempio (mooolto a spanne (ergo: con numeri inventati :D ) e senza considerare miglioramenti di architettura in generale ) di quello che penso potrebbe accadere in una applicazione "pippo" che non è stata pensata per girare meglio su 64 bit :

Se per eseguire 100 routine diverse con codice a 64bit impiego in media 20nS a routine ma devo accedere 100 volte alla memoria esterna per recuperare delle variabili che non ci stanno in cache per un tempo di 50nS ad accesso ottengo un totale di 7uSecondi.
Se le eseguo in codice 32bit magari impiego 40nS a routine ma accedo solo 50volte alla memoria esterna ottengo 6,5uS.

PS. vi lascio liberi di caziarmi se ho sparato qualche fregnaccia soprattutto per i tempi di accesso in memoria :D ;)

Originariamente inviato da Banus
Proprio sulla possibilità del punto 2) e 3) si basava il discorso di fek ;)
Esatto. Comunque hai azzeccato proprio tutto... :D
I punti 1), 2) e 3) garantiscono che la somma dei tempi di esecuzione delle singole istruzioni corrisponde al tempo di esecuzione della routine.
Esatto. Anche considerando il caso migliore per il codice a 32 bit (tutte le istruzioni e i dati che sono perfettamente allineate alla dimensione della linea di cache) e quello peggiore per il codice a 64 bit (istruzioni disallineate e letture/scritture dei valori a 64 bit disallineati), calcolatrice alla mano, non si scappa. ;)
Incidenza degli accessi in memoria:i punti 2), 3) garantiscono che i dati si trovano in cache.
Perfettamente.
Il 2) "obbliga" la pagina dello stack in cui verranno scritti tutti gli argomenti a trovarsi in memoria.
Il 3) è un vincolo più rilassato, perché una volta che il codice è sta nella cache e la pagina dei dati (stack) è caricata, il processore non potrà mai generare un'eccezione dovuta a un page fault.
Assunzione (sicuramente verificata nell'Athlon64): due accessi a 32 bit sono più lenti di un singolo accesso a 64 bit, dalla cache.
Esatto. Anche nel caso peggiore per l'Athlon64.
Resta solo da valutare, calcolatrice alla mano :p, l'incidenza del salvataggio dei registri (a 64 bit sono in numero maggiore e più grandi).
Infatti. Questo era il vincolo rimasto per l'altro esempio. :)
Non è una dimostrazione formale ma una traccia di come affronterei il problema :p
Per la "formalità" basta conteggiare il numero di cicli di clock considerando il caso migliore per il codice a 32 bit e quello peggiore per quello a 64 bit, e il gioco è fatto... :p

Complimenti! :)

x repne scasb: come vedi, per come sono poste le condizioni, eccezioni di fatto non ce ne possono essere. Il codice verrà sempre eseguito senza alcuna interruzione. ;)

Originariamente inviato da fek
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 ;)
Si può anche essere in buona fede, ma avere dimenticato un dettaglio, anche se importante. :)
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.
Il problema, come ti dicevo anche nel mio messaggio precedente, è quello di stabile le condizioni reali: se non lo si fa, anche il codice di repne scasb risulta validissimo.
Proprio per questo motivo ho buttato la pietra della "dimostrazione formale". ;)
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.
D'accordo, ma vedi messaggio precedente (che t'ho scritto): mancavano le condizioni relative alla definizione di "normalità".
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.
D'accordo, ma permettimi di farti le seguenti osservazioni:

1) la logica di prefetch per quanto riguarda il caricamento del codice nell'apposita sezione della cache L1 "normalmente" fa un ottimo lavoro: i cache miss dovuti all'esecuzione di codice non presente nella cache DI NORMA sono dovuti a salti condizionati di cui si è sbagliata la predizione; questo rispecchia il punto "1" della mia dimostrazione;

2) i dati di cui si parla negli esempi trattati sono gli argomenti "pushati" (che brutto termine); il tuo discorso lo si può applicare quando il processore deve andare a "pescare" dalla memoria quei dati, ma certamente non lo puoi applicare quando poi te li ritrovi nello stack: per sua stessa natura lo stack conserva dei dati "recenti", le pagine dello stack fanno parte normalmente del working set (se non fosse così il decadimento prestazionale dovuto alla chiamata di una funzione, specie con diversi argomenti, sarebbe notevole), e che normalmente il processore si ritrova nella cache L1.
Questo mi sembra proprio il caso nostro: quando il processore ha eseguito il push, ha posto i dati/argomenti nella cache L1 (per poi essere scritti nella cache L2 e quindi in memoria, ma di questo se ne occupa la sezione di load/store) e di conseguenza quando nella funzione si torna a leggerli, sono già lì, a portata di mano; questo rispecchia il punto "3" della mia dimostrazione;

3) se, come dici, "di solito" quel codice è "memory bound", mi sembra razionale supporre che lo sia tanto per quello a 32 bit quanto per quello a 64 bit.
Spero di essere stato piu' chiaro ora, e a chi pensa di parlare una lingua diversa dalla mia, consiglio di imparare prima l'italiano :)
Fermo restando che è chiaro, come hai detto, che i benefici derivanti dal fatto che quel codice a 64 bit verrà eseguito, sì, eseguito in meno tempo, ma che in mezzo a un codice (e non un inner loop) non farebbe la differenza (il profiling non lo so si fa certo per velocizzare l'esecuzione di una routine "isolata" e "poco usata"), spero che le argomentazioni che ho portato qui sopra servano a "distendere" un po' la discussione... ;)

x ripsk Non hai sparato delle "fregnacce": sono delle giuste considerazioni.

Però c'è da dire che il codice generato per lo stesso programma, ma per architetture diverse, tende ad avere lo stesso "comportamento", tanto più quanto le architetture "si assomigliano".
E' difficile, quindi, pensare che la routine a 32 bit esegua la metà di accessi in lettura di quella a 64 bit. Può benissimo succedere, per carità, e il motivo (per quanto riguarda il confronto x86 VS x86-64) è già stato detto: i puntatori occupano il doppio di spazio.

Ma dai risultati che abbiamo potuto vedere si assiste, a mio avviso, a un quadro abbastanza chiaro: mediamente lo stesso programma compilato ed eseguito per x86-64 offre un miglioramento delle prestazioni. Questo anche se non fa uso di dati interi a 64 bit (POV-Ray, nuovamente): i benefici derivano dalla nuova architettura.

Consiglio un po' più di calma ;)

Quoto: non lasciamo degenerare un thread bello come questo. :)

x repne scasb: neppure io sono madrelingua italiano. ;)

Originariamente inviato da cdimauro
Esatto.
Per fortuna... Temevo di aver frainteso il significato di "interruzione" :D

Originariamente inviato da cdimauro
neppure io sono madrelingua italiano.
Questo è il thread delle rivelazioni :eek:

Originariamente inviato da repne scasb
E' un chiaro riferimento alla mia persona. Tengo a precisare, che non sono di madrelingua italiana, e accetto il consiglio. La vostra lingua ha delle "sfumature" che alcune volte mi sfuggono.

Non faccio fatica a crederti.

Originariamente inviato da cdimauro
Si può anche essere in buona fede, ma avere dimenticato un dettaglio, anche se importante. :)

Un dettaglio tipo eseguire il profiling di un inner loop? :)


Il problema, come ti dicevo anche nel mio messaggio precedente, è quello di stabile le condizioni reali: se non lo si fa, anche il codice di repne scasb risulta validissimo.
Proprio per questo motivo ho buttato la pietra della "dimostrazione formale". ;)


Quel codice non e' validissimo, perche' come avevo ripetuto una decina di volte era eseguito in una condizione ideale e irreale (l'inner loop) che era gia' stata indicata da me come il caso perfetto in cui il codice a 64 bit risulta nettamente piu' veloce. Sostanzialmente ha dimostrato l'ovvio su un caso particolare per poi cercare di estenderlo per induzione a tutti i casi. Un tentativo un po' goffo.


D'accordo, ma permettimi di farti le seguenti osservazioni:

1) [...]

2) [...]

3) se, come dici, "di solito" quel codice è "memory bound", mi sembra razionale supporre che lo sia tanto per quello a 32 bit quanto per quello a 64 bit.


1) assolutamente si'

2) i dati sono anche i due operandi, non per altro nella versione C li ho passati di proposito come puntatori a interi lunghi, per risaltare il fatto che quei dati provenivano dalla memoria, potenzialmente in due pagine totalmente separate, e ancora potenzialmente non in cache

3) assolutamente si', infatti la mia conclusione voleva essere che i due pezzi di codice di solito saranno probabilmente (e non sicuramente) prestazionalmente equivalenti perche' di solito si troveranno in ambienti memory bound dove il collo di bottiglia e' l'accesso alla memoria e non il numero di istruzioni eseguite

spero che le argomentazioni che ho portato qui sopra servano a "distendere" un po' la discussione... ;)

Tu aiuti sicuramente a distendere la discussione :)
Ma la discussione non si sarebbe neppure scaldata se la nostra amica ammettesse ogni tanto qualche suo errore, soprattutto quando sono cosi' goffi, invece di limitarsi ad arrampicarsi sugli specchi e insultare l'interlocutore che glieli fa notare.

X Helstar:
scusa se ho fatto scendere il livello della discussione con le mie buffonate....
non mi pare di aver offeso nessuno con il mio scherzoso commento (al contrario di te), e del resto non sei costretto a partecipare a questa discussione se non la reputi alla tua altezza.

Originariamente inviato da Solido
Scusate ma si può scaricare oppure no?

Originariamente inviato da fek
Tu aiuti sicuramente a distendere la discussione :)
Ma la discussione non si sarebbe neppure scaldata se la nostra amica ammettesse ogni tanto qualche suo errore, soprattutto quando sono cosi' goffi, invece di limitarsi ad arrampicarsi sugli specchi e insultare l'interlocutore che glieli fa notare.
fek: rileggiti per bene quello che è stato scritto... Non vi siete capiti...
Sta dicendo la tua stessa cosa...cioè che di per se un istruction set a 64 bit non porta reali vantaggi... Il codice che tu hai riportato sembrava fatto per fargli capire che in quella situazione (in effetti non hai specificato niente dell'ambiente esterno) il codice a 64 bit era intrinsecamente più lento... Prendendola in questo modo lei ti ha fatto vedere che proprio quel codice, nella situazione migliore (inner loop), è estremamento più veloce del corrispondente a 32 bit...

Quando gli hai chiesto come si fa il profiling, lei ha capito come si fa "in questo caso" il profiling e ti ha fatto il discorso del RDTSC...tu hai capito che facesse il profiling solo in quel modo e ti sei inalberato dicendo che non era capace di fare il profiling... Siccome repne scasb è capacissima di farlo...si è ovviamente incavolata...

Quindi smettetela e fate la pace ;)

Riguardo al discorso del memory bound...non sempre si è memory bound...magari nel tu lavoro la quantità di accessi e la variabilità di questi accessi è tale da renderti sempre memory bound... In molti altri campi questo non succede...

Originariamente inviato da Solido


non penso....come tutti i SO microsoft nn si puo scaricare dal sito ufficiale

Sì...almeno lo si può fare solitamente...

Ecco qua: http://microsoft.order-9.com/winxp64/handoff.asp?id=dl

Ho una voglia matta di un sistema a 64 bit...non sapete quante prove avrei voglia di farci :(

Quel codice non e' validissimo, perche' come avevo ripetuto una decina di volte era eseguito in una condizione ideale e irreale (l'inner loop) che era gia' stata indicata da me come il caso perfetto in cui il codice a 64 bit risulta nettamente piu' veloce. Sostanzialmente ha dimostrato l'ovvio su un caso particolare per poi cercare di estenderlo per induzione a tutti i casi. Un tentativo un po' goffo.

Come ha perfettamente detto Cionci, le cose stanno un po' diversamente in quanto sei stato tu (Fek) a portare in primo luogo quell'esempio (per giunta con errori vari riconosciuti ma questo e' un altro discorso) ma manco a farlo apposta era proprio uno di quei rari casi in cui a 64bit si va piu' veloci :)
Inoltre non credo sia stato il massimo dell'obiettivita' il tuo atteggiamento un po', come dire, sopra le righe nei confronti di repne, arrivando anche a frecciate di dubbio gusto e facendo l'offeso.
Se hai beccato qualcuno che puo' starti dietro nel tuo campo qui sul forum, non averne a male, nessuno ti sta facendo scendere dal piedistallo e la stima di tutti resta immutata, anche se da parte mia hai perso qualche punto per via di certo sarcasmo gratuito ... =)
Cio' non toglie comunque che in 'generale' hai ragione tu sul discorso dei 'presunti' vantaggi (come gia' confermato anche da repne, cdmauro, banus e tutti gli altri) dei 64bit.

Gabido: ma perche' scherzare proprio in questo thread e soprattutto, se non ne puoi fare a meno, in maniera cosi' infantile ?

Originariamente inviato da Helstar
Come ha perfettamente detto Cionci, le cose stanno un po' diversamente in quanto sei stato tu (Fek) a portare in primo luogo quell'esempio (per giunta con errori vari riconosciuti ma questo e' un altro discorso) ma manco a farlo apposta era proprio uno di quei rari casi in cui a 64bit si va piu' veloci :)
Non è proprio così...quella routine va sicuramente più veloce a 64 bit solamente nel caso in cui tutti i dati a cui accede siano in cache...ed è per quello che l'aveva introdotta fek...
Diciamo che fek, conscio delle minori operazioni necessarie, voleva mettere in evidenza il fatto che nonostante siano necessarie meno istruzioni la velocità di esecuzione di quella routine dipende dal contesto in cui essa viene richiamata...

Originariamente inviato da fek
2) i dati sono anche i due operandi, non per altro nella versione C li ho passati di proposito come puntatori a interi lunghi, per risaltare il fatto che quei dati provenivano dalla memoria, potenzialmente in due pagine totalmente separate, e ancora potenzialmente non in cache
Rispondo solamente a questa parte, perché per il resto concordo o ne abbiamo già parlato. Citando i dati passati come puntatori, mi è sorto un dubbio: sono andato a controllare e probabilmente la routine che hai riportato non era corretta. La riporto integralmente:
void __fastcall func_64(
__int64* res,
__int64 arg1,
__int64 arg2)
{
__int64 res1 = *arg1 + *arg2;
__int64 res2 = *arg1 - *arg2;

*res = res1 * res2;
}
Magari sbaglio, ma usando i puntatori forse doveva essere scritta così:
void __fastcall func_64(
__int64* res,
__int64 *arg1,
__int64 *arg2)
{
__int64 res1 = *arg1 + *arg2;
__int64 res2 = *arg1 - *arg2;

*res = res1 * res2;
}
In effetti usando i puntatori si verifica quel che hai scritto: è possibile che ciascun accesso in memoria possa provocare un page fault (tre, se consideriamo anche quello del risultato, che è anch'esso un puntatore).

Quella routine poteva anche essere scritta così (l'ho scritta così perché il mio stile è diverso dal tuo):
__int64 __fastcall func_64(__int64 arg1, __int64 arg2) {
return (arg1 + arg2) * (arg1 - arg2);
}
E' chiaro che il problema dell'accesso ai due argomenti (e i conseguenti possibili page fault) è sempre lo stesso: è soltanto anticipato all'inizio della chiamata alla funzione (e posticipato per la scrittura del risultato tornato).

C'è da dire, però, che le routine, sebbene facciano lo stesso lavoro, non sono affatto "identiche": la prima viene "digerita meglio" dai sistemi a 32 bit, perché vengono passati 3 puntatori a 32 bit, mentre nei sistemi a 64 bit un puntatore è a 64 bit (con le conseguenze di cui abbiamo parlato); la seconda è "digerita meglio" dai sistemi a 64 bit, perché si evita il passaggio di un puntatore, ma soprattutto il dato sta interamente in un registro.

Qui nasce anche un problema "etico" per un programmatore: quale forma preferire?
Più in generale: per dati che sono contenuti in 64 bit, è meglio passarne direttamente il valore o il puntatore? ;)

Originariamente inviato da cdimauro
Qui nasce anche un problema "etico" per un programmatore: quale forma preferire?
Più in generale: per dati che sono contenuti in 64 bit, è meglio passarne direttamente il valore o il puntatore? ;)


Nella prima versione del codice che hai riportato il passaggio e' per valore ma gli argomenti sono deferenziati come fossero puntatori, quella versione neppure dovrebbe compilare.
Mi sembra strano che l'abbia postata in quel modo, perche' ho postato anche il disassemblato del debugger e devo averla compilata :D

edit: confermo, l'ho postata senza l'asterisco sugli argomenti, devo aver fatto casino con il copy&paste per la seconda volta... per fortuna ho i correttori di bozze che si leggono tutto quello che scrivo in cerca di errori; vi posso assumere mentre programmo? ;)

Posso assicurarti che anch'io ho le mie gatte da pelare: non ne voglio aggiungere altre... :D

Comunque non sono gli errori (chiaramente accidentali) l'oggetto del mio messaggio né lo è l'accesso in memoria e il relativo contesto trattato: l'interrogativo lascia spazio per altre discussioni rispetto a quelle che abbiamo già fatto... ;)

Helstar: dammi tu la lista di post dove si può scherzare, dato che a quanto pare sei tu che decidi(?)
Comunque mi pare che ti stia lamentando solo tu..
In genere le persone infatili sono quelle che non accettano i commenti (seri o scherzosi, l'importante che siano garbati) altrui.
Se il mio commento non ti piaceva potevi benissimo ignorarlo, come hanno fatto tutti gli altri, o comunque essere più garbato nella risposta (altro atteggiamento infantile: l'arroganza).
Comunque chiudiamola qui, ho altro da fare che entrare a tu per tu con con te.
Un consiglio: non prendere sempre tutto (te compreso) troppo sul serio, vedrai che vivrai meglio.

Comunque mi pare che ti stia lamentando solo tu..
E' diverso ... il tuo post era talmente stupido che gli altri ti hanno direttamente ignorato, io ho sbagliato finora a darti corda.
Per il resto sono d'accordo, hai vinto tu, bravo. Sayonara.

ecco bravo, la prossima volta ignora, sempre meglio che dare risposte da maleducati...

Riporto in auge la discussione (tralasciando gabibbo) con un bel link:
http://www.xbitlabs.com/articles/cpu/display/x86-64-rc1.html

Sì, ma da un po' di giorni è disponibile la RC2... ;)

Caro conterraneo, aspettiamo un altro bench allora :D

Io aspetto la versione finale, a questo punto... :sofico:

Originariamente inviato da Helstar
Riporto in auge la discussione (tralasciando gabibbo) con un bel link:
http://www.xbitlabs.com/articles/cpu/display/x86-64-rc1.html

Insomma, come prevedibile, il solo passaggio ai 64bit (senza ottimizzazioni per le nuove architetture) porta ad un rallentamento del codice anche del 25%. Ottimizzando invece il codice per le nuove architetture (in pratica processori ben differenti rispetto all'ISA di riferimento 32bit) invece i miglioramenti possono arrivare anche al 100% e oltre.

Il vantaggio quindi non sono i 64 bit ma l'abbandono dell'arcaica ISA 32bit...
Però Intel e AMD sono bestie differenti e richiedono codice oggetto differente per poter esprimere in pieno le loro capacità.

Originariamente inviato da Criceto
Insomma, come prevedibile, il solo passaggio ai 64bit (senza ottimizzazioni per le nuove architetture) porta ad un rallentamento del codice anche del 25%.
Ti riferisci all'esecuzione di codice a 32 bit in un s.o. a 64 bit?
Ottimizzando invece il codice per le nuove architetture (in pratica processori ben differenti rispetto all'ISA di riferimento 32bit) invece i miglioramenti possono arrivare anche al 100% e oltre.
Appunto: in tutti i test riportati in quel link con applicazioni a 64 bit si assiste solamente a incrementi prestazionali.
Il vantaggio quindi non sono i 64 bit ma l'abbandono dell'arcaica ISA 32bit...
Ma la nuova ISA x86-64 ha molto in comune con quella "vecchia" x86...
Però Intel e AMD sono bestie differenti e richiedono codice oggetto differente per poter esprimere in pieno le loro capacità.
Esattamente, ma già i primi risultati sembrano molto buoni...

Originariamente inviato da Criceto
Insomma, come prevedibile, il solo passaggio ai 64bit (senza ottimizzazioni per le nuove architetture) porta ad un rallentamento del codice anche del 25%.
Abbiamo visto benchmark diversi ?!?!!?

Originariamente inviato da cionci
Abbiamo visto benchmark diversi ?!?!!?

forse sì :D


tra l'altro si fanno calcoli ma senza l'"oste" e senza avere un parco drivers sufficientemente ampio e stabile.