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

Un continuo rinvio al debutto della nuova versione di sistema operativo Microsoft per cpu AMD64 e Intel EM64T

Click sul link per visualizzare la notizia.

In pratica si potrà installare nei primo trimestre del 2006.... :)

Mi pareva pure ora...
non voglio insistere,ma pare che microsoft aspetti Intel...

Originariamente inviato da Angelogeom
Mi pareva pure ora...
non voglio insistere,ma pare che microsoft aspetti Intel...

togli pure il pare IMHO...

Ma Windows XP a 64bit non era solo per sistemi AMD?
Io avevo capito così...
Che ci sta a fare intel?

usare una bella distro linux che supporti i 64bit no? :)

Spero non sarà una fregatura....avevo sentito che più che essere un win xp 64 fosse un win 2000 64 senza alcune funzioni di xp....

Originariamente inviato da dottorpalmito
usare una bella distro linux che supporti i 64bit no? :)

Per farci cosa poi?
:D

i giochi sboroni mica ci sono e manco i benchmark fighi :sofico:

Non è possibile avevano detto alla fine di quest'anno.

Originariamente inviato da lasa
Spero non sarà una fregatura....avevo sentito che più che essere un win xp 64 fosse un win 2000 64 senza alcune funzioni di xp....

La beta fin ora non mi ha dato questa impressione. Mi sa tanto di una cosa piuttosto simile a WinXpSP2 invece. Di contro ci sono ben poche cose che traggono vantaggio dai 64bit e notevoli problemi con certi driver, per non parlare del supporto java inesistente (sul browser a 64bit si intende)

"il dbeutto del sistema operativo Windows XP a 64bit sarebbe atteso per il primo trimestre 2005. La fonte di questa notizia è Intel Taiwan."

Intel taiwan?
Strano... :asd:

Originariamente inviato da ErminioF
"il dbeutto del sistema operativo Windows XP a 64bit sarebbe atteso per il primo trimestre 2005. La fonte di questa notizia è Intel Taiwan."

Intel taiwan?
Strano... :asd:

non l'ho capita...

Uscirà già con il SP2 incluso...

Originariamente inviato da Castellese
Per farci cosa poi?
:D

i giochi sboroni mica ci sono e manco i benchmark fighi :sofico:

e neanche maya, 3d studio max, alias studio, ecc ecc ecc :muro:
la finiamo di associare windows ai giochini e ai benchmark?
thanx

Originariamente inviato da DioBrando
non l'ho capita...

immagino fosse un commento ironico sulla correlazione ritardo winXp64 = ritardo supporto intel ai 64bit

Dragon 1978 hai provato Blender? Io non faccio grafica 3D ma ho visto i lavori delle varie persone che lo usano...
http://www.blender.it/

Beh...non è particolare che dopo oltre 1 anno e mezzo di attesa da parte di amd x un os a 64bit, sia la stessa intel (che ha appena fatto uscire i suoi processori col supporto ai 64bit) a dare questa notizia? :)

Originariamente inviato da Mezzelfo
Dragon 1978 hai provato Blender? Io non faccio grafica 3D ma ho visto i lavori delle varie persone che lo usano...
http://www.blender.it/

non scherziamo dai
un conto è postare immagini da appassionati, un altro conto è la grafica 3d fatta a livello professionali
in questo campo programmi come maya, softimage, lightscape hanno un livello troppo superiore a programmi come blender
per carità, mi fa piacere vedere che anche per linux si sta muovendo qualcosa sul campo 3d, ma io parlo di lavoro non di passione

confronta ad esempio questo render di blender
http://www.blender.it/img/gallery/cucina.jpg

con questo fatto con image studio/mental ray
http://www.alias.com/eng/community/galleries/image_gallery/land_rover/img/flipbook17.jpg

direi che si commentano da soli
e questo è solo uno degli aspetti, non parliamo neanche di car design (in cui alias studio-katia la fanno da padroni), realizzazione di video (maya e softimage), vari plugin implementati, è proprio un altro mondo

p.s.
sono dagon non dragon :p

Ragazzi ma non esiste un P4 con supporto 64bit e per quale ragione dovrebbe esistere un XP64, come dire che non esista un legerrissimo conflitto di interesse ;)

Tanto possono dire che hanno problemi con i driver o la sicurezza e quindi hanno bisogno di più tempo per farlo uscire :)

Avendo montato in tempi non sospetti il mio primo A64 qualche tempo dopo natale, e conseguentemente mi son tolto la curiosità di provare winXP64 beta, posso affermare che: il SO è molto reattivo, effettivamente usando soltanto programmi 64bit all'interno di windows, si nota una certa "potenza" in più, ma ogni volta che si lancia un programma 32bit, e quindi il SO lavora in emulazione, si perde quasi un 10-20% di prestazione rispetto a un normale winxp32...

in pratica winxp64 pare girare anche un 10% + veloce, ma se si lanciano all'interno applicativi 32bit (con una buona stabilità per giunta) si perdono un 20-30% di prestazioni per la strada...

Ergo, senza programmi 64bit è un buco nell'acqua sto sistema operativo...



(è anche vero che se non lo fanno nessuno farà applicativi ottimizzati 64bit...)

:D

Originariamente inviato da dagon1978
e neanche maya, 3d studio max, alias studio, ecc ecc ecc :muro:
la finiamo di associare windows ai giochini e ai benchmark?
thanx

va che per linux c'è:
maya
houdini
softimage sia xsi che 3d

tranne max che gira solo su win.

Originariamente inviato da kaksa
va che per linux c'è:
maya
houdini
softimage sia xsi che 3d

tranne max che gira solo su win.

a quanto so e a quanto dice il sito della alias non esiste maya per linux
se poi lo fai girare in emulazione win è un altro conto...

Originariamente inviato da kaksa
va che per linux c'è:
maya
houdini
softimage sia xsi che 3d

tranne max che gira solo su win.

Vectorworks, Cinema 4D, Revit e la maggiorparte dei vari CAD su linux non sn stati portati...

Originariamente inviato da DioBrando
Vectorworks, Cinema 4D, Revit e la maggiorparte dei vari CAD su linux non sn stati portati...

e autocad e 3d studio viz e i principali CAID alias studio, rhino3d

cmq siamo OT, il mio era solo un invito a chi "sponsorizza" linux a rispettare le esigenze di chi non usa win per giocare o fare benchmark, non certo un confronto di cosa c'è e cosa non c'è...

Originariamente inviato da dagon1978
e autocad e 3d studio viz e i principali CAID alias studio, rhino3d

cmq siamo OT, il mio era solo un invito a chi "sponsorizza" linux a rispettare le esigenze di chi non usa win per giocare o fare benchmark, non certo un confronto di cosa c'è e cosa non c'è...

sn perfettamente d'accordo...pdv che collide per altro con con quelli che ritengono Win sia in alcuni campi, purtroppo ( perchè la scelta è un bene), insostituibile...


Ecco perchè Win Xp 64bit è così atteso, oltre ad offrire finalmente il vero terreno di scontro della prox generazione di cpu ( l'A64 scalpita già da un pò a dire il vero ;))

Originariamente inviato da dagon1978
a quanto so e a quanto dice il sito della alias non esiste maya per linux
se poi lo fai girare in emulazione win è un altro conto...
maya per linux esiste eccome, però è una versione vecchia e riceve pochissimo supporto

Puoi vedere come linux compaia negli OS supportati da Qui (http://www.alias.com/eng/products-services/maya/system_requirements.shtml)

mi correggo, ho trovato il supporto di linux per maya, errore mio ;)

Originariamente inviato da Tetrahydrocannabin
maya per linux esiste eccome, però è una versione vecchia e riceve pochissimo supporto

Puoi vedere come linux compaia negli OS supportati da Qui (http://www.alias.com/eng/products-services/maya/system_requirements.shtml)
sìsì avevo trovato ;)
mi era venuto in mente che avevo partecipato a un benchmark per vedere le differenze del rendering win/linux in maya :p
sto un po' fuori oggi

cmq se vuoi vedere i lavori professionali vai su elysiun, non su blender.it.

a prop di cucine, guarda:

http://www.elysiun.com/forum/viewtopic.php?t=30682&postdays=0&postorder=asc&start=0

blender e stato usato per qualcosa in spiderman 2.

concordo che maya abbia tutti gli strumenti inimmaginabili(e cmq maya sara' quasi sempre sottoutilizzato), ma qualcuno usa blender anche su lato professionale, pochi ma buoni ;)

Cerchiamo di restare in topic ;)

Originariamente inviato da dagon1978
a quanto so e a quanto dice il sito della alias non esiste maya per linux
se poi lo fai girare in emulazione win è un altro conto...


esiste in nativo e funziona molto meglio che su win

raga non ci credo che quella macchina e quella cucina è fatta con computer grafica...
:-P
ed io che quando devo fare un sito web piango davanti al photoshop per qualsiasi elemento grafico!!!!

Originariamente inviato da ErminioF
Beh...non è particolare che dopo oltre 1 anno e mezzo di attesa da parte di amd x un os a 64bit, sia la stessa intel (che ha appena fatto uscire i suoi processori col supporto ai 64bit) a dare questa notizia? :)

hai ragione...mi era sfuggito il lato comico della notizia :D

Spero non sarà una fregatura....avevo sentito che più che essere un win xp 64 fosse un win 2000 64 senza alcune funzioni di xp....

meglio no. vorrà dire un bel boost prestazionale.

Beh ci sara' un motivo perche' ad intel e a microsoft ha dato mooolto fastidio la novitaì dei 64bit, perche' il mercato non ne ha bisogno sul lato desktop, sarebbe bastato benissimo il supporto di win 2003 e basta per i server.
Infatti l' opteron e' stato il vero successo di AMD non l'A64.
Perche' ha dato fastidio??? Semplice perche' ha creato hipe e la gente voleva i 64bit senza sapere se gli servissero o meno e senza vedere uno straccio di benchmark. Assurdo, se ci pensiamo un attimo, tutto sto casino e lamentele sui ritardi e' tutto campato in aria, avrei capito se fossero circolati decine di test che davano boost prestazionali allucinanti, niente di niente. La cosa forte si legge pero' tra le righe di questa news, AMD vende i 64bit da 2 anni, due anni a osannare i 64bit e nussuno ha visto un test.
Certo che bisogna dire che con l'hipe a certi livelli ci sanno proprio fare, venderebbero anche un pinguino delonghi in alaska.
Comunque sia a parer mio l' A64 e' una grande cpu e se non avesse la sigla 64 lo sarebbe comunque, visto che fino ad ora lo ha dimostrato con i 32bit.
Sarebbbe forte se una volta uscito WinXP64 ci si rendesse conto che e' meglio rimanere sui 32bit.
Se fosse cosi' bisognerebbe ammettere che intel e microsoft avevano ragione a dire che per i 64bit sui desktop era troppo presto e che forse avevano ragione a incazzarsi perche' costretti a stravolgere le loro roadmap per niente.
Comunque si vedra'.

Originariamente inviato da darkwings
Beh ci sara' un motivo perche' ad intel e a microsoft ha dato mooolto fastidio la novitaì dei 64bit, perche' il mercato non ne ha bisogno sul lato desktop, sarebbe bastato benissimo il supporto di win 2003 e basta per i server.


se per te la possibilità di vendere nuovi prodotti ( di pacca), siano esse HW ( cpu e servers per es) o SW ( licenze, bundles vari ecc) è un motivo di fastidio...


Infatti l' opteron e' stato il vero successo di AMD non l'A64.
Perche' ha dato fastidio??? Semplice perche' ha creato hipe e la gente voleva i 64bit senza sapere se gli servissero o meno e senza vedere uno straccio di benchmark.

non serve vedere dei benchmarks per capire che i 64bit saranno senz'altro il futuro dell'Informatica...bisogna capire se per l'utente medio questo comporterà dei vantaggi a breve termine...a lungo termine quando occorreranno ad es quantità di RAM parecchio + di alte di quelle attualici guarderemo indietro e vedremo che il passaggio è stato obbligato.

Farlo prima, con calma, "fare le cose fatte bene", è un vantaggio IMHO, n un handicap...


Assurdo, se ci pensiamo un attimo, tutto sto casino e lamentele sui ritardi e' tutto campato in aria, avrei capito se fossero circolati decine di test che davano boost prestazionali allucinanti, niente di niente. La cosa forte si legge pero' tra le righe di questa news, AMD vende i 64bit da 2 anni, due anni a osannare i 64bit e nussuno ha visto un test.

veramente i tests ci sn, sia su WinXp64 Beta sia su Linux.

Quelli pubblicati, mi sembra, utilizzando una Debian64bit sn impressionanti in certi ambiti...vedi videoediting per esempio


Certo che bisogna dire che con l'hipe a certi livelli ci sanno proprio fare, venderebbero anche un pinguino delonghi in alaska.
Comunque sia a parer mio l' A64 e' una grande cpu e se non avesse la sigla 64 lo sarebbe comunque, visto che fino ad ora lo ha dimostrato con i 32bit.
Sarebbbe forte se una volta uscito WinXP64 ci si rendesse conto che e' meglio rimanere sui 32bit.

come ho detto prima, sn discorsi che non hanno senso...vi sn delle caratteristiche tangibili e concrete, al di là dei tests, che fanno dei 64bit una scelta tecnologicamente + avanzata dei 32bit...ed è sempre stato così.


Poi ci si può ragionare sul fatto che ora serve o servirà tra un anno o due anni. Ma quando servirà, occorrerà essere pronti perchè un processore, un SO non esce dall'oggi al domani...
Quindi prima arrivano il nuovo WinXp e il resto degli applicaitivi per i 64bit e meglio sarà per tutti...


Se fosse cosi' bisognerebbe ammettere che intel e microsoft avevano ragione a dire che per i 64bit sui desktop era troppo presto e che forse avevano ragione a incazzarsi perche' costretti a stravolgere le loro roadmap per niente.
Comunque si vedra'.

Intel ha dovuto adeguarsi perchè AMD ha proposto una nuova cpu che concretamente si è rivelata un ottimo prodotto.
Fosse stata a 32 o 64 bit non sarebbe cambiato nulla, la strategia di adeguamento dal pdv commerciale sarebbe stata identica.

E poi Intel sulla carta non era costretta a fare proprio nulla di nulla, se non voleva cambiare la roadmap non la cambiava.

E invece l'ha cambiata (e ne sta soffrendo tantissimo) probabilmente perchè intravede che il suo nome piano piano si sta oscurando davanti a quei due numerini (64).

E'la legge della concorrenza, se la AMD ha fatto così ne ha solo che guadagnato il mercato non l'opposto!

Per il momento a mio avviso le lamentele di questa lentezza nell'uscita di win64 son più che dovute, lo avevano annunciato parecchio tempo fa e invece vanno piano e quindi la gente diventa curiosa!

Originariamente inviato da kaksa
esiste in nativo e funziona molto meglio che su win
questa è pura fantascienza!! l'ho provato e posso dirti che non è assolutamente all'altezza della versione windows ;)

Originariamente inviato da dagon1978
e neanche maya, 3d studio max, alias studio, ecc ecc ecc :muro:
la finiamo di associare windows ai giochini e ai benchmark?
thanx
beh era per fare un esempio lampante, da che ne so io ci potrebbero essere tanti software semi sconosciuti alla massa che magari fanno + o meno le stesse cose dei mostri sacri su Windows. ;)

A me sembra che winXP64 sarà solo una pezza, in attesa che esca il loghorn
Un po' quello che è successo col WinME nei confronti del winXP

CHI non lo sapesse.. CHI non abbia seguito gl'eventi della beta di WinXP64.. vi vorrei dire che il PRIMO processore supportato era INTEL, e non AMD.. quindi chi è che va dicendo che era predestinato solo per AMD??!!??

mmm , secondo me visto la quantita di pc 32 bit che ci sono ora sara bello lungo il passaggio definitivo e indolore :)

considerando che nel passato i pc nelle nostre case erano pochi molti non ne avevano manco uno ,ora e' facile trovare 2 pc o piu in una casa , e' naturale che ci voglia piu tempo ....


poi non si puo dire che non sia utile nel mercato consumer/desktop , perche alla fine qualsiasi tecnologia che viene fatta su larga scala scende di prezzo cosi da facilitare anche chi ci lavora con il pc (visto che parlavate di grafica 3d poi arrivera anche lo SLI per voi ;) )

Mi spiace , ma quelli che pensano di vedere importanti aumenti prestazionali a breve termine su applicazioni desktop , saranno abbastanza delusi...
Non voglio dire che il x86-64 o l'EMT64 non siano un innovazione , sia ben inteso..
Per avere un S.O. performante e stabile , almeno ai livelli dell'attuale XP32 , deve funzionare in modo ideale quello stretto rapporto che lega il software all'hardware : I Driver...
Ora , per sfruttare bene una periferica , bisogna riscrivere sti benedetti driver : compilarli da 32 a 64 è una cosa che non ha senso : dato che molto codice va scritto a basso livello per essere performante...e questo richiede molto tempo ...betatesting..e release su release per raggiungere prestazioni e stabilità paragonabile a quella di XP attuale...

E' anche ovvio che , sempre in ambito desktop , una CPU x86-64 e relativo S.O. , serviranno solo in determinati casi specifici ...e di sicuro non a breve , dato che x le applicazioni attuali i registri di una CPU a 32 bit sono più che sufficienti e l'indirizzamento a + di 4 Gb di ram basta ancora per almeno 2 anni ...
Poi , la stragrande maggioranza degli utenti desktop , utilizza il PC in ambito videoludico : quindi dover usare in emulazione il S.O. per far girare le comuni applicazioni a 32 bit è una cosa controproducente.... Un emulatore , per ben fatto che sia , non avrà mai un efficienza pari al 100% e se devo essere sincero , l'ultima volta che l'ho provato sono rimasto abbastanza deluso dalla percentuale di perdita...(bisogna installare solo driver a 64bit e quando il S.O. funziona a 32bit anche i driver vanno in emulazione , con perdita di performance fino al 20% :( )

Io sinceramente preferirei che lanciassero questo XP64 con una buona infrastruttura , driver e parco applicazioni ...e lascerei questo S.O. in mano alle software-house per il tempo necessario a far diventare il passaggio 32-64 profiquo per la grande massa...
Sia ben chiaro , hanno fatto benissimo a introdurre sul mercato l'Athlon64 , dato che come CPU a 32 bit è una bomba , mentre a 64 bit serve moltissimo come supporto dove costruire le future applicazioni e sperimentarle sul campo su un effettivo 64bit e non su una simulazione che da risultati meno coerenti ..

Perchè allora tutta questa fretta per avere un S.O. nuovo ?? avere una cosa e non poterne trarre vantaggio se non fra un anno o più non mi sembra una scelta così ovvia , anche per chi ha una CPU a 64bit ...
Questa non è una miglioria architetturale di una CPU o un aggiornamento qualsiasi a XP... questa è LA Rivoluzione , una simile l'abbiamo avuta dai 16bit ai 32bit (in termini tecnici anche più importante)
Imho è una cosa che merita e richiede tutto il tempo necessario affinchè sia vincente !!! altrimenti è la solita operazione commerciale atta a smuovere il mercato e ad incrementare gli HW-upgrade :D..
Sia ben chiaro che il mio discorso è incentrato sulla fascia di utilizzo di XP64 e cioè ambito desktop ...I 64bit delle Workstation e dei Server non sono in questione!!

P.S. se dovete quotarmi , non fatelo frase per frase : quotatemi l'intero post , se è possibile ...
Almeno rispondete al concetto che ho espresso e non alla singola frase che presa da sola è al di fuori del proprio contesto..... grazie :)

Originariamente inviato da darkwings
Sarebbbe forte se una volta uscito WinXP64 ci si rendesse conto che e' meglio rimanere sui 32bit.

Aspetta che i programmi a 32 bit, pur continuando a usare interi a 32 bit e non richiedendo memoria aggiuntiva, vengano ricompilati a 64 bit per sfruttare i registri aggiuntivi (ti ricordo che sono raddoppiati) e vedremo se non ci sarà un boost prestazionale ;). Poter vendere una "nuova" versione che guadagna qualcosa in velocità rispetto alla vecchia, che poi altro non è che la vecchia ricompilata e pubblicizzata per il supporto ai 64 bit, non mi sembra un gran fastidio ;).

Originariamente inviato da Conan_81
vi vorrei dire che il PRIMO processore supportato era INTEL, e non AMD..

Ti sbagli. La prima versione beta di questo os è stata rilasciata proprio con supporto agli AMD, di processori Intel con supporto a x86-64 non c'era nemmeno l'ombra. Pochi giorni prima del rilascio della beta, all'IDF Intel aveva annunciato la "prossima" tecnologia CT, che poi ha preso il nome di EM64T e da poco è stata implementata negli xeon; c'è anche nei prescott, ma è disabilitata. Quindi, se uscisse oggi, in ambito desktop potresti usarlo solo con le cpu AMD ;). Prima ancora dell'annuncio di CT è uscita la beta di Windos server 2003 EE compatibile con i 64bit di AMD, sulla prossima implementazione da parte di Intel c'erano solo voci di corridoio su Yamhill. Probabilmente tu confondi questo sistema operativo con la versione di windows per IA64, ovvero Itanium, che effettivamente è stata sviluppata prima, però si tratta di un os completamente diverso che non ha niente a che vedere con questo, se non il termine 64bit, ma si tratta di implementazioni completamente diverse e totalmente incompatibili. E' come dire che c'erano software nativi a 64 bit già per gli alpha e altri risc, ma che c'entra? ;)

x dagon1978

Premetto di non essere assolutamente un "esperto" del settore. Il rendering effettuato con blender che hai postato mi sembra fatto con la sola radiosity e con una definizione di oggetti e materiali non precisissima. Per giudicare correttamente questo programma bisognerebbe vedere se è possibile fare qualcosa di più sia per la definizione degli oggetti, sia per le impostazioni sul rendering (e sul tipo di rendering da effettuare). Dall'immagine postata da Mason si direbbe che è possibile ottenere risultati di tutto rispetto: da "profano" (non ho mai fatto rendering personalmente, quindi non ho esperienza sul campo) ho l'impressione che sia stata fatta una prima passata di radiosity con substructuring (in alcuni punti mi pare di scorgere qualche imperfezione che mi fa pensare ad un eccessiva suddivisione delle patch, tipica di questo algoritmo) e poi un bel "colpo" di raytracing (a giudicare da certi riflessi mi viene da pensare al two pass, ma non vorrei sbagliare). Comunque, in linea di massima mi trovi d'accordo: in questo settore ci sono molti più applicativi per win, prima di criticare la scelta di un os bisogna capirne le motivazioni (vale ovviamente per tutti gli os).

Originariamente inviato da cionci
Cerchiamo di restare in topic

Beh, lo sai che Windows tradotto vuol dire "si, ma Linux..." e viceversa, no? Qui dal confronto tra gli os si è passati a un confronto tra i sw per le piattaforme, almeno è stato un off topic senza flame... :D

x nonikname

Il motivo principale delle differenze prestazionali è il ritardo nello sviluppo di driver. Però, considera che questo ritardo è dovuto al fatto che l'introduzione dell'os era (è) lontana: se da MS fossero giunte pressioni consistenti, o se l'os fosse già "uscito" e discretamente diffuso, la qualità dei driver sarebbe ben superiore. I videogiochi costituiscono la categoria che più è svantaggiata nel passaggio, ma questo è dovuto proprio alla scarsa ottimizzazione dei driver: se ci fai caso, le differenze si assottigliano all'aumentare della risoluzione di test, perchè il sistema diventa gpu limited, il lavoro della gpu, fermo restando quello della cpu, aumenta, per cui in una stessa finestra temporale nei due casi (bassa e alta risoluzione di test) dovrebbero esserci meno chiamate alle funzioni dei driver alle risoluzioni più alte e, di conseguenza, la bassa qualità dei driver influisce in minor misura. Se tu potessi (e volessi) fare una prova, potrebbe essere interessante (o almeno curioso) verificare le differenze tra i due os usando non i driver propri della vga, bensì quelli "standard" dell'os, che la riconoscono come graphic adapter a 16 bit e non si appoggiano all'implementazione hw delle funzioni delle librerie grafiche: il risultato esteticamente sarebbe poco gradevole, però si dovrebbe poter eliminare l'incognita del legame tra l'esito del test e i driver.

Quanto all'emulazione, la differenza non può essere così drammatica: non si emula una cpu (per intenderci, un po' come fanno le VM java), poichè gli A64 sono compatibili nativamente con il codice a 32 bit anche quando operano a 64 bit, si emula (anche se la parola è un po' grossa) un os, e questo vuol dire intervenire "solo" quando vengono richiesti dei servizi al sistema operativo, e tutto si risolve praticamente nel rimappare per quanto possibile le funzioni dell'os "nativo" su quelle dell'os "ospite", in pratica un'ulteriore chiamata a funzione con eventualmente qualche overhead di calcolo per qualche controllo o per la scelta della funzione giusta, poco più di un wrapping. Inoltre, trattandosi di un emulazione di windows su windows l'operazione dovrebbe essere ancora più semplice, le funzioni chiamate potrebbero coincidere anche in molti casi, e più o meno dovrebbe incidere non più dell'abilitazione della retrocompatibilità con un os specifico in xp a 32 bit (protrebbe essere anche più veloce dell'emulazione dei 16 bit per le applicazioni dos). In ogni caso i driver non vanno in emulazione con le applicazioni a 32 bit, se fosse possibile emularli allora potresti installare quelli per xp a 32b, e IMHO le prestazioni sarebbero migliori; purtroppo non è possibile, in quanto i driver "girano" allo stesso "livello" dell'os, mentre ciò che viene emulato si trova ad un livello "superiore" (l'emulazione consiste proprio in una chiamata allo strato sottostante). Caso mai, viene emulata la chiamata da parte del programma a 32 bit alle funzioni dei driver (ovvero a servizi dell'os che si appoggiano sui driver specifici), ma questo rientra nell'emulazione (che sostanzialmente consiste proprio in questo), quindi non aggiunge nessun ulteriore rallentamento.

Ciao :)

@ xeal http://www.dinoxpc.com/Tests/PROCESSORI/AMD64_WINXP64/pag4.asp (articolo XP32 vs XP64 in italiano su Dinox PC;)

Sono comunque rimasto piacevolmente sorpreso dall'ultima build di XP64bit edition ...

http://www.gamepc.com/labs/view_content.asp?id=xp641218&page=1

Does WoW64 (Windows-On-Windows 64) decrease performance?
http://www.gamepc.com/images/labs/rev-winxpamd64tp-wow64.jpg

...."WoW64 does not have the performance penalties that full-scale 32-bit emulation incurs. But, as the CPU is translating 32-bit calls into 64-bit calls, there is always a bit of performance overhead, which takes away speed from the application."...


EDIT : WoW = Windows on Windows (S.O. 32bit nel S.O. a 64bit)

Originariamente inviato da xeal
x dagon1978

Premetto di non essere assolutamente un "esperto" del settore. Il rendering effettuato con blender che hai postato mi sembra fatto con la sola radiosity e con una definizione di oggetti e materiali non precisissima. Per giudicare correttamente questo programma bisognerebbe vedere se è possibile fare qualcosa di più sia per la definizione degli oggetti, sia per le impostazioni sul rendering (e sul tipo di rendering da effettuare). Dall'immagine postata da Mason si direbbe che è possibile ottenere risultati di tutto rispetto: da "profano" (non ho mai fatto rendering personalmente, quindi non ho esperienza sul campo) ho l'impressione che sia stata fatta una prima passata di radiosity con substructuring (in alcuni punti mi pare di scorgere qualche imperfezione che mi fa pensare ad un eccessiva suddivisione delle patch, tipica di questo algoritmo) e poi un bel "colpo" di raytracing (a giudicare da certi riflessi mi viene da pensare al two pass, ma non vorrei sbagliare). Comunque, in linea di massima mi trovi d'accordo: in questo settore ci sono molti più applicativi per win, prima di criticare la scelta di un os bisogna capirne le motivazioni (vale ovviamente per tutti gli os).

non ho commentato prima il rendering postato da Mason perché siamo fortemente in OT, cmq ti posso dire che le imperfezioni sono moltissime anche in quel rendering (che pure è di per sé...diciamo "scenografico")
è molto distante dalla resa fotorealistica, intanto per l'eccessivo utilizzo delle riflessioni (ad sempio fa effetto vedere il riflesso dell'acciaio, ma non ha niente di fotorealistico, a meno che non sia tutto cromato e lucidato a specchio), ci sono dei riflessi sparatissimi dovuti alla radiosity dei materiali che sono stati usati in modo sbagliato, l'AA è sicuramente di qualità non paragonabile a software come maya o 3dstudio (e questo l'ho potuto notare più volte su rendering eseguiti con blender), e l'analisi potrebbe andare avanti, le imprecisioni sono tante in quel rendering, che pure sembra di buona qualità a prima vista...
non ho capito bene la tua analisi sulla radiosity, perché affermi che il rendering della cucina ti sembra fatto con la "sola radiosity"?
a me, al contrario, pare che quel rendering sia stato usato soltanto il raytracing senza la radiosity, oppure hanno usato malissimo la radiosity...
il modello di radiosity è certamente il più fotorealistico, quindi non ti seguo molto quando distingui radiosity-raytracing, anche per l'analisi sull'immagine postata da Mason (non ho neanche idea di che parametri usi Blender onestamente) i riflessi ad esempio non mi sembrano per niente frutto del raytracing, ma della radiosity (o al limite delle caustiche, anche se non so neanche se blender supporti questo algoritmo)
in conclusione, a me non sembra uno strumento di lavoro, almeno per adesso... i livelli raggiunti da altri software in questo campo sono notevoli, e non parliamo solo di rendering (l'ho usato come esempio perché è il più veloce da "mostrare")... la specializzazione di alcuni software in settori specifici fà si che non esista un programma 3d perfetto in tutti i campi (ad esempio non utilizzerei mai maya per la modellazione di superfici, per quello uso alias studio o rhino che sono molto più adatti, come non utilizzerei mai studio per fare animazioni o per renderizzare, visto che non è stato ancora implementato alcun algoritmo di radiosity... e così via...), Blender mi pare di tutto un po', ma, a occhio, non mi sembra che possa competere con nessuno di questi software nel suo campo specifico...

poi la questione sollevata sui software 3d non voleva essere una provocazione o una sfida a chi usa linux per capire chi ha i programmi migliori, credo che in ambiente windows la scelta sia più ampia, ma non è solo questo che porta tante persone a dover usare questi programmi su windows
ad esempio io non posso imporre windows sul campo di lavoro, se vengo assunto da una società che fa grafica 3d al 99% dovrò usare windows perché è lo standard, quindi è inutile che mi si venga a dire su linux Maya mi gira meglio (cosa tra l'altro non vera, avendo partecipato, come dicevo, a dei rendering comparativi tra le due versioni lo posso affermare con certezza)
per concludere, mi da fastiodio chi accosta windows ai giochini e ai benchmark, c'è gente che ci lavora seriamente e senza avere esigenze di passare ad altro, tutto qui ;)

secondo me non si sente l esigenza di passare ad altro perche i pc sono diventati talmente veloci che gia questi e' difficile sfruttarli a fondo .... se era al tempo dei pentium 2 forse sarebbe stato piu atteso ;)

Originariamente inviato da nonikname
Does WoW64 (Windows-On-Windows 64) decrease performance?
http://www.gamepc.com/images/labs/rev-winxpamd64tp-wow64.jpg

...."WoW64 does not have the performance penalties that full-scale 32-bit emulation incurs. But, as the CPU is translating 32-bit calls into 64-bit calls, there is always a bit of performance overhead, which takes away speed from the application."...


EDIT : WoW = Windows on Windows (S.O. 32bit nel S.O. a 64bit)


Dipende.. se le prestazioni del SO a 64 bit sono tali da controbilanciare o superare la penalità dovuta al layer WOW aggiuntivo, si potrebbero comunque avere prestazini uguali o superiori ;) Più in generale, dipenderà dal tipo di applicazioni. Chiaro che la vera differenza si vedrà quando vi saranno applicazioni veramente ottimizzate per i 54 bit, il che potrà essere solo dopo l'uscita del SO definitivo .

Originariamente inviato da ti4600
secondo me non si sente l esigenza di passare ad altro perche i pc sono diventati talmente veloci che gia questi e' difficile sfruttarli a fondo .... se era al tempo dei pentium 2 forse sarebbe stato piu atteso ;)

al tempo dei pentium pro e pentium 2 esisteva ancora la piattaforma Alpha, che era a 64 bit e che alcuni vedevano degna di ereditare dalla X86 il titolo di base tecnologica mainstream... (tra l' altro, DEC fece parecchio per far sembrare questo passaggio, logico e naturale... la dotazione del SW FX32! con ogni Alphastation con WinNT, modifiche al chip per rendere il byte alignment compatibile con quello x86... )

una migrazione in grande stile avrebbe potuto aver luogo all' epoca, invece non c' è stata assolutamente
il che forse vuol dire che all' epoca dei pentium 2 il "nuovo" (i 64 bit) era semmai, MENO atteso ... (d' altra parte, si era ancora relativamente lontani dal volere effettivamente sfruttare lo spazio d' indirizamento limite di 4 GB... metti poi in conto un minimo di "miopia" nel grande pubblico...) :rolleyes:

Anche perchè a quei tempi si sentiva meno il limite dei 4 Gb...
Ci sono già molte workstation che hanno 4 Gb di Ram... Dei server non ne parliamo...in quegli ambiti il limite dei 4 Gb è limitante già da tempo (ed è stato aggirato con il PAE anche se con prestazioni orribili)... Se non lo sapete le funzionalità di ricerca di questo forum sono limitate ai post dell'ultimo mese perchè è stato avvicinato il limite dei 4Gb...

Nel campo desktop il limite dei 4 Gb non si sente, ma quanto tempo pensate che ci voglia ancora ?

Originariamente inviato da nonikname
@ xeal http://www.dinoxpc.com/Tests/PROCESSORI/AMD64_WINXP64/pag4.asp (articolo XP32 vs XP64 in italiano su Dinox PC

E' proprio il test a cui pensavo: non mi sono piaciute molto le conclusioni (e non solo a me) perchè danno a mio avviso troppo peso al settore videoludico che è si uno dei principali ambiti di utilizzo di Windows tra gli utenti home, ma è troppo dipendente dalla qualità dei driver. Se noti, nel passare dalla risoluzione di 640x480 a quella di 1280x768 il decadimento in Unreal Tournament è più che dimezzato e in 3dmark 2001 i due sistemi si equivalgono (c'è addirittura un guadagno, ma è irrisorio, si può considerare credo entro il margine di variabilità del test), probabilmente a risoluzioni più elevate il risultato di xp64 migliorerebbe. Questo me lo spiego in questo modo: a risoluzioni basse la gpu deve lavorare meno per elaborare la grafica, per cui il sistema può elaborare molti più frame e, di conseguenza, se consideriamo un intervallo di tempo preciso in cui la scena si evolve in un certo modo, verranno eseguite molto più spesso le funzioni dei driver e la loro qualità (e la qualità della gestione dell'hardware) si inciderà notevolmente; aumentando la risoluzione, sempre nello stesso intervallo di tempo e con la stessa evoluzione della scena, la gpu deve lavorare comunque di più, per cui la differenza tra i due sistemi dovuta alla diversa ottimizzazione dei driver si assottiglia, essendo minore il numero di frame che la gpu elabora e maggiore il tempo necessario ad elaborare ciascun frame. Provo a essere più chiaro: la gpu impiegherà un certo tempo a elaborare ciascun frame, e questo tempo possiamo pensarlo determinato dalla velocità di esecuzione di ciascuna operazione che compie e dalla velocità con cui il driver gestisce la periferica (ad esempio per caricare i dati e scegliere le operazioni nel modo migliore), oltre che dalla velocità con cui viene eseguita la funzione del driver; all'aumentare della risoluzione aumenta il tempo impiegato dalla gpu per i calcoli e, quindi, in proporzione il tempo impiegato dal driver per preparare l'elaborazione dovrebbe incidere meno. Questo mi sembra confermato anche dal test con cinebench sullo shading in ambiente opengl con lighting hw e sw: nel caso dello shading hw, in cui interviene pesantemente la gpu e, quindi, il suo driver, si ha una perdita del 16%, mentre con lo shading sw, con una minore incidenza della gpu, la differenza scende al 7%; con Cinema4d, in cui credo che i calcoli vengano effettuati praticamente tutti dalla cpu si ha un vantaggio del 13,7%, pur essendo la suite di test a 32 bit (e quindi emulata); stesso discorso per xmpeg.

"WoW64 does not have the performance penalties that full-scale 32-bit emulation incurs. But, as the CPU is translating 32-bit calls into 64-bit calls, there is always a bit of performance overhead, which takes away speed from the application."...


Appunto, si tratta fondamentalmente di una ulteriore chiamata a funzione, che (mi pare) in alcuni casi incide, data l'architettura delle cpu x86 attuali, meno di un salto condizionato (di cui i programmi sono pieni). Con dei driver stabili e sufficientemente ottimizzati, non mi stupirei se la differenza percentuale fosse del tutto irrilevante, come avviene in quella recensione per i test sintetici, poi, come dice leoneazzurro, le caratteristiche dell'os potrebbero rendere complessivamente tutto più veloce, superando il "limite" dell'emulazione. WoW c'è anche in xp a 32 bit: è il layer che ti consente di eseguire applicazioni dos e di impostare la retrocompatibilità per tentare di risolvere certi problemi. L'altro articolo che hai postato non l'ho letto tutto (ho dato uno sguardo ai grafici), i risultati sono comunque interessanti; però non sono riuscito a capire (forse avrei dovuto leggere meglio) se la memoria usata sul sistema xeon è di tipo registered (come quella che usano gli opteron), o unbuffered.

Ciao :)

originariamente inviato da dagon1978
non ho capito bene la tua analisi sulla radiosity, perché affermi che il rendering della cucina ti sembra fatto con la "sola radiosity"?

Devo essermi espresso male: mi sembra di vedere (al massimo) solo la radiosity nella cucina renderizzata su blender.it, non su quella che ha postato Mason. In quest'ultima il raytracing c'è di sicuro, però mi pare di scorgere un po' di aliasing nello spigolo basso dell'armadietto a muro più vicino alla finestra (ad esempio) che mi fa pensare ad una ricorsione eccessiva sull'algoritmo di radiosity (la stessa, ad esempio, che può produrre un'anomala "fuoriuscita" di luce da bordo di una plafoniera a muro come se ci fosse una crepa). Perchè ti sembra strano il riflesso sull'acciao della pentola? Io ho sempre notato un minimo di riflessione sulle pentole, poi quella dell'immagine sembra nuova (e di solito, in questo caso, sono molto lucide :D). Comunque, le riflessioni sono un po' eccessive, su questo ti do pienamente ragione, anche se le mattonelle mi fanno pensare ad un tipo di ceramica lucida, che tende a riflettere (mi è capitato di notare, a volte, delle riflessioni con luce artificiale, ma non faccio rendering, quindi non ho mai prestato troppa attenzione a questi dettagli :D). La finestra non mi piace molto, sembra quasi un enorme neon.

il modello di radiosity è certamente il più fotorealistico, quindi non ti seguo molto quando distingui radiosity-raytracing, anche per l'analisi sull'immagine postata da Mason (non ho neanche idea di che parametri usi Blender onestamente) i riflessi ad esempio non mi sembrano per niente frutto del raytracing, ma della radiosity (o al limite delle caustiche, anche se non so neanche se blender supporti questo algoritmo)


:confused: Io sapevo il contrario, o meglio, so che la radiosity è preferibile per gli interni, poichè prevalgono le superfici "matte", e gli algoritmi di radiosity considerano le superfici appunto come lambertiane, mentre il raytracing simula ricorsivamente le riflessioni dei raggi luminosi sulle superfici che hanno un elevato coefficiente di riflessione speculare, fermando la ricorsione quando questo coefficiente diventa ragionevolmente molto basso. La cucina di blender.it mi sembra renderizzata solo con la radiosity anche perchè non c'è nessun riflesso, e la bottiglia e il bicchiere, oltre a essere un po' imprecisi, hanno superfici opache, neanche trasparenti. Per quanto ne so, gli effetti migliori per il fotorealismo si dovrebbero ottenere con una prima passata di radiosity per renderizzare le superfici più opache (e la componente lambertiana delle altre), quindi procedendo con il raytracing per le superfici che presentano riflessione speculare, attribuendo un coefficiente di riflessione bassissimo (o nullo) alle superfici che si considerano renderizzate in maniera soddisfacente con la sola radiosity.

poi la questione sollevata sui software 3d non voleva essere una provocazione o una sfida a chi usa linux per capire chi ha i programmi migliori, credo che in ambiente windows la scelta sia più ampia, ma non è solo questo che porta tante persone a dover usare questi programmi su windows
ad esempio io non posso imporre windows sul campo di lavoro, se vengo assunto da una società che fa grafica 3d al 99% dovrò usare windows perché è lo standard, quindi è inutile che mi si venga a dire su linux Maya mi gira meglio (cosa tra l'altro non vera, avendo partecipato, come dicevo, a dei rendering comparativi tra le due versioni lo posso affermare con certezza)
per concludere, mi da fastiodio chi accosta windows ai giochini e ai benchmark, c'è gente che ci lavora seriamente e senza avere esigenze di passare ad altro, tutto qui

Su questo sono pienamente d'accordo :)
Fa comunque piacere vedere che qualcosa si muova anche per linux, le alternative non fanno mai male :D

Ciao

Originariamente inviato da cionci
Se non lo sapete le funzionalità di ricerca di questo forum sono limitate ai post dell'ultimo mese perchè è stato avvicinato il limite dei 4Gb...

E cosa aspettano a passare a Opteron? Infondo, sulle macchine fanno girare linux, quindi l'os a 64 bit per gestire la memoria già ce l'hanno, per i loro scopi non devono aspettare xp :D:D:D

Ovviamente sto scherzando, comunque mi pare di aver capito che stiano aggiornando il parco macchine, ma con cosa?

scusate un secondo , ok con i 32 bit i 4gb sono il limite , ma ho notato almeno ho controllato sono l asus a8v deluxe per 939 e vedo che :

Memoria - 4 Socket per DIMM a 184-pin e supporto max. di memoria 4GB DDR400/DDR333/DDR266 non-ECC un-buffered DDR SDRAM
- Architettura di Memoria Dual Channel

mmm sono sempre 4 gb :) , sara la mobo limitata forse perche e' destinata al mercato consumer?

ma quali sono i prescot che attualmente supportano i 64bit?
o meglio, qualcuno di voi ha detto che le istruzioni sono già presenti negli attuali prescott ma sono "dormienti"....quello che vorrei sapere è, quando uscirà XP64, sarà possibile "risvegliare" le istruzioni dormienti nei proci intel?

Ps.non uccidetemi per ciò che ho scritto, sono abbastanza ignorante in materia.... :D

Di quella recensione di DinoX PC ne abbiamo parlato tempo addietro: le conclusioni a cui sono giunte sono del tutto sballate, come ha giustamente rilevato xeal.
Peccato che le funzioni di ricerca del forum siano limitate... :muro:

Sì...se non sbaglio si erano limitati a valutare le prestazioni a 32 bit su applicazioni in cui la dipendenza dai driver era netta (giochi ad esempio)... Ovviamente i driver in beta hanno fatto il resto...

Originariamente inviato da xeal
Devo essermi espresso male: mi sembra di vedere (al massimo) solo la radiosity nella cucina renderizzata su blender.it, non su quella che ha postato Mason. In quest'ultima il raytracing c'è di sicuro, però mi pare di scorgere un po' di aliasing nello spigolo basso dell'armadietto a muro più vicino alla finestra (ad esempio) che mi fa pensare ad una ricorsione eccessiva sull'algoritmo di radiosity (la stessa, ad esempio, che può produrre un'anomala "fuoriuscita" di luce da bordo di una plafoniera a muro come se ci fosse una crepa). Perchè ti sembra strano il riflesso sull'acciao della pentola? Io ho sempre notato un minimo di riflessione sulle pentole, poi quella dell'immagine sembra nuova (e di solito, in questo caso, sono molto lucide :D). Comunque, le riflessioni sono un po' eccessive, su questo ti do pienamente ragione, anche se le mattonelle mi fanno pensare ad un tipo di ceramica lucida, che tende a riflettere (mi è capitato di notare, a volte, delle riflessioni con luce artificiale, ma non faccio rendering, quindi non ho mai prestato troppa attenzione a questi dettagli :D). La finestra non mi piace molto, sembra quasi un enorme neon.





:confused: Io sapevo il contrario, o meglio, so che la radiosity è preferibile per gli interni, poichè prevalgono le superfici "matte", e gli algoritmi di radiosity considerano le superfici appunto come lambertiane, mentre il raytracing simula ricorsivamente le riflessioni dei raggi luminosi sulle superfici che hanno un elevato coefficiente di riflessione speculare, fermando la ricorsione quando questo coefficiente diventa ragionevolmente molto basso. La cucina di blender.it mi sembra renderizzata solo con la radiosity anche perchè non c'è nessun riflesso, e la bottiglia e il bicchiere, oltre a essere un po' imprecisi, hanno superfici opache, neanche trasparenti. Per quanto ne so, gli effetti migliori per il fotorealismo si dovrebbero ottenere con una prima passata di radiosity per renderizzare le superfici più opache (e la componente lambertiana delle altre), quindi procedendo con il raytracing per le superfici che presentano riflessione speculare, attribuendo un coefficiente di riflessione bassissimo (o nullo) alle superfici che si considerano renderizzate in maniera soddisfacente con la sola radiosity.





ok, qui parliamo di due cose distinte
la teoria della radiosity e l'implementazione nei vari motori di resa fotorealistica
la riflessione speculare non è in genere implementata nei motori di rendering, perché sarebbe troppo dispendiosa in ambito di risorse spese, quindi vengono utilizzati metodi misti radiosity/raytracing in cui diffusione e riflessione/rifrazione possono essere ben rappresentate secondo un modello fotorealistico.
Ora questa è la teoria, in pratica, come dicevo, non conosco il funzionamento di Blender, ma mi sembra un vero suicidio suddividere la radiosity dal raytracing! Mental Ray ad esempio usa un motore misto radiosity/raytracing implementando in automatico il raytracing (non vedo il perché di una distinzione, o meglio, lo vedo se si vuole escludere la radiosity, ma non lo vedo se si esclude il raytracing, che vantaggi darebbe usare un modello incompleto?)
Se Blender distingue le due cose e permette di escludere il raytracing e renderizzare solo con la radiosity porta decisamente in errore chi deve fare i rendering (non avrà mai una resa fotorealistica se non simula anche la luce riflessa)
La radiosity è preferibile per gli interni e per gli esterni indistintamente (con rese diverse), ovviamente per entrambi il modello è sempre un misto radiosity/raytracing e non solo radiosity. A questo punto non so dirti se la cucina di Blender.it avesse proprio questo errore di fondo, ma se così fosse si spiegherebbe benissimo la piattezza dell'immagine. Cmq facendo un giro sul sito postato da Mason http://www.elysiun.com/ ho notato lo stesso problema su molti rendering fatti con Blender (molti sembrano dei raycaster molto poco qualitativi), quindi qualche errore di fondo ci deve essere...
Per quando riguarda la cucina l'immagine, come ripeto, è molto "scenografica", ma ha diversi problemi che la rendono molto poco "fotorealistica".
Ne elenco alcuni, quelli che ho notato d'impatto, non ho fatto certo un'analisi approfondita:
- l'acciaio non avrà mai quei riflessi (intanto non è cromo, quindi quella riflessione, che mi pare sia quasi al 100% è eccessiva). Non troverai mai una pentola così riflettente in giro per una casa, neanche se è stata lucidata a specchio pochi secondi prima...
Ma facciamo finta che la riflessione vada bene, uno dei principali nemici del fotorealismo sono le superfici pulite. Chi renderizza per professione sa che è bene "sporcare" le superfici (specie se hanno una riflessione così evidente!) e per farlo ci sono vari metodi (uno è usare le bleur reflections/refractions), una superficie con una riflessione così perfetta è a mio modo di vedere totalmente innaturale, ma è vero che "fa scena"!
- Le riflessioni eccessive si vedono un po' dappertutto, specie sulla plastica
i pomelli dei pensili hanno riflessi eccessivi, il tostapane è troppo lucido e riflette troppo (e troppo nettamente) il forno ha dei pomelli in plastica troppo "piatti", e riflette troppo (e troppo nettamente)
- è stato usato (sicuramente in photoshop) un filtro di disturbo che rende l'immagine molto "crisp". questo funziona molto bene sulle mattonelle (come facevi notare anche tu), ma stride troppo con altre parti pulite del rendering (es il tostapane)
- i pomodori sono proprio bruttini (anche qui la regolarità li rende totalmente innaturali... in questo caso "sporcare"=renderli irregolari, utilizzare una texture che simuli venature ecc)
- l'aliasing che hai notato tu, a mio avviso, non è dato tanto dalla radiosity quando dall'utilizzo di un "trucco" in postproduzione (potrei sbagliarmi...;)), questo trucco viene utilizzato per simulare o avvicinarsi alla resa di rendering come quelli di Alax Konst http://alkonaft.dezigner.ru/Alex_Konst_may.jpg che non ha mai reso noto i metodi utilizzati per arrivare a un contrasto così efficace (da quello che so oltre all'AA e alla postproduzione utilizza dei metodi particolari di illuminazione)
Non sempre però l'utilizzo di filtri in post produzione porta ai risultati sperati (da qui gli artefatti di cui si parlava;))
- la luce finestra è decisamente sbagliata, come dicevi tu sembra più un neon (ho fatto fatica a capire cosa fosse per un po'), che una finestra e in più non ha nessun effetto di profondità (sembra una lastra luminosa appiccicata alla parete... come in realtà è :p)
- la stessa luce della finestra viene sparata dal piatto vicino al lavandino con un tipico effetto dovuto alla radiosity, ma è decisamente innaturale perché è un effetto di diffusione tipico dei metalli non della porcellana

questa è un'analisi molto veloce ma di sicuro di difetti ce ne sono tanti altri.
con questo non voglio dire che quello non sia un bel rendering (per carità ho fatto rendering ben peggiori io stesso!;)), ma che è lontano dalla resa fotorealistica... una cosa che mi ha stupito in positivo è la resa del vetro (in particolare i bicchieri sul pensile), notoriamente il vetro è uno dei materiali più ostici nel rendering. Sarei curioso di sapere quanto tempo ha impiegato per renderizzare tutta la scena...
ora spero di non essere sparato dal moderatore per i vari post in OT, ma il rendering è la mia passione oltre che un lavoro quindi non ho resistito :p
cmq se sei uno che nota certi tipi di riflessione, i riflessi dei materiali ecc e hai questa curiosità verso la CG ti consiglio di provare qualche programma 3d, è divertente ;) da quello che mi pare di capire hai delle buone basi teoriche che ti potrebbero tornare utili... e se hai bisogno di qualche consiglio chiedi pure ;)

ciau

Ciao ragazzio io ormai non capisco una cosa ma lo zietto bill non è che sotto sotto si è comprata anche l'intel?
Perchè AMD ormai sono due anni che ha un bel proc. pronto a 64 bit, come mai winzzoz solo ora si è decisa visto???
Mah

Originariamente inviato da Carpix
Ciao ragazzio io ormai non capisco una cosa ma lo zietto bill non è che sotto sotto si è comprata anche l'intel?
Perchè AMD ormai sono due anni che ha un bel proc. pronto a 64 bit, come mai winzzoz solo ora si è decisa visto???
Mah

forse perche non e' semplice sfornare un "nuovo" os con supporto 64 bit/ 32bit che sia stabile come lo e' windows xp che usiamo tutti ....

cmq penso che microsoft non vuole rischiare di far uscire un os che non possono usare tutti quindi aspetta che i 64 bit vengano venduti un po a tutti

cmq telefona a zio bill e fatti dire le sue ragioni ;)

Rendetevi conto che è stata Microsoft ad imporre a M$ un supporto a x86-64 compatibile con quello di AMD...ed è stato ovvio che Microsoft abbia aspettato...

da che mondo è mondo INTEL e MS sono sempre andati a breccetto....
e cmq sarebbe + logico aspettare il + grande produttore di CPU al mondo....in modo da avere un parco makkine maggiore....
e intanto testare il soft su AMD

il fatto che Em64T e x86-64 siano compatibili è una gran cosa....

BYEZZZZZZZZZZZ

Mah, secondo me, (ma non ho provato nulla di serio ancora, per cui prendete la cosa con le molle) 'sti 64bit sono la solita scusa per vendere computer più potenti e farci il lavaggio del cervello a noi utenti convincendoci della necessità dei 64 bit. Linux a 64 bit va esattamente come a 32 bit (ha solo qualche problema in più di compatibilità, e molti infatti lo installano sia a 64 che a 32), e così sarà anche per Win64. Solo le applicazioni compilate ed ottimizzate a 64 bit vanno meglio (quanto, è ancora da vedere), ma è sempre stato così, ovvero il software ottimizzato per il tuo HW e OS va meglio, ovvio. Ma siamo sicuri che in fondo 'sti 64 bit ci servano davvero? A parte videogiochi e grafica pesante, che ce ne facciamo? 64 bit vogliono anche dire programmi più "pesanti", bisogno di più memoria (ancora!?), e quindi PC più potenti. Vi ricordate il passaggio da win3.1 a win95? Una evoluzione di sicuro, ma per le prestazioni effettive non saprei, in fondo chi usava word e PSP, ha continuato a farlo, solo che adesso andava più piano di prima e doveva cambiare il PC per forza. Mah...

Molto bene.Ben venga il 64 bit senza troppe storie.

Originariamente inviato da LordPBA
Linux a 64 bit va esattamente come a 32 bit
Un linketto ai benchmark?

Hmmmm... non ce l'ho qua di preciso, ma le prove sono su Anandtech. Linux di per se va + o - uguale, solo alcune applicazioni a 64 bit migliorano. Ah no, eccolo qua, mitico! Il link: http://www.anandtech.com/linux/showdoc.aspx?i=2114&p=1

Originariamente inviato da LordPBA
Hmmmm... non ce l'ho qua di preciso, ma le prove sono su Anandtech. Linux di per se va + o - uguale, solo alcune applicazioni a 64 bit migliorano. Ah no, eccolo qua, mitico! Il link: http://www.anandtech.com/linux/showdoc.aspx?i=2114&p=1

Hai ragione, ricordavo male. Migliorano prevalentemente (esclusivamente?) le applicazioni che fanno uso di dati di grandi dimensioni, int64_t per dire.
Almeno in quei casi migliorano di brutto :D


http://www.thejemreport.com/modules.php?op=modload&name=News&file=article&sid=117

x Chicco#32

Non credo che si possano "risvegliare", più che dormienti dovrebbero essere proprio disattivate, per cui non credo proprio che basterà smanettare sulla cpu (con vernice conduttiva, intervenendo su certi pin, ...) per sbloccarli. Con tutta probabilità si dovrà cambiare processore, come è stato per avere HT sui Northwood, anche se era già presente nei core prodotti precedentemente all'introduzione ufficiale (e funzionante) della tecnologia: non mi pare che su quelle cpu si potesse riabilitare la funzionalità Hyper Threading.

Ciao.

Originariamente inviato da cdimauro
Peccato che le funzioni di ricerca del forum siano limitate...

Lo dicevo io che bisogna passare a opteron :D
Scherzi a parte, quel thread era solo sul forum, oppure è legato a qualche news? Sulle news non ci sono limiti temporali, ricordando l'argomento, se si trattava di una news, un tentativo si potrebbe fare. Va be', l'argomento esatto della news sarebbe un tantinello più difficile da ricordare :D lasciamo perdere :asd:

Originariamente inviato da LordPBA
Ma siamo sicuri che in fondo 'sti 64 bit ci servano davvero? A parte videogiochi e grafica pesante, che ce ne facciamo? 64 bit vogliono anche dire programmi più "pesanti", bisogno di più memoria (ancora!?), e quindi PC più potenti.

Perchè dovrebbero richiedere necessariamente più memoria? Il fatto che si possa gestire direttamente in hw più memoria (e più velocemente) non vuol dire che debba per forza diventare un requisito minimo o consigliato per un programma. Ovviamente, man mano che si diffonderanno sistemi con maggiori quantitativi di RAM, gli sviluppatori sw si porranno sempre di meno il problema di ottimizzare le applicazioni su quel "versante", oppure riterrano superflue precedenti limitazioni su certe caratteristiche (dimensioni e qualità delle texture dei videogiochi, ad esempio) e i sw diventeranno più "pesanti", ma questo è un processo "fisiologico", un trend che ormai accompagna ogni aumento delle risorse disponibili a basso costo (o comunque a costi accettabili per i potenziali clienti). Comunque, di per sè, il fatto che i processori x86-64 gestiscano interi a 64 bit nativamente non implica che non si possano più usare dati di dimensioni inferiori se sono sufficienti, comunque questa architettura porta qualche vantaggio anche in questo caso, poichè le nuove cpu hanno praticamente il doppio dei registri, quindi diminuiscono gli accessi alla memoria RAM (che comporta dei rallentamenti). Ovviamente, si avranno risultati più rilevanti con i programmi che necessitano di lavorare su interi a 64 bit (perchè rispetto ai processori 32 bit, ad esempio, è possibile dimezzare il tempo di una somma, di uno shift...). Inoltre, poichè i dati a 64bit nei processori a 32 richiedono l'uso di 2 registri (2*32), ed essendo stato raddoppiato il numero dei registri interi di uso generale, in alcuni casi sarà come se questi programmi avessero a disposizione il quadruplo dei registri rispetto a prima (chiaramente si tratta di situazioni molto particolari, in cui il processore si ritrova ad elaborare praticamente solo interi a 64 bit).

ancora con sti 64bit???
uffa ma la gente e' dura a convincersi.....
oramai mi sono rassegnato......
avro' scritto 1 milione di volte che e' soltanto una implementazione su microcode e che non cambia nulla, ma qua tutti ad aspettare....cosa poi non lo capisce nessuno.....
il pci-X e' la migliore e piu' grande innovazione disponibile sui nostri pc e noi pensiamo ai 64bit.....
bho....
io ho un giga di ram e non riesco a riempirlo ne' con doom3 e ne' con photoshop lavorando a risoluzioni assurde da 8000x8000...
mentre comprare un raid mi ha velocizzato parecchio adesso ci servono 8giga di ram?!?!?
ma....
insomma piu' sono inutili le cose e piu' questi ci tornano sopra....
quanto ci saranno processori "veri" che non siano x86 ne riparliamo per il momento tenetevi il vostro bel XP-32bit che va tanto bene con un bel P4 northwood @3.6ghz

x dagon1978

Chiaramente io parlo di teoria (quella conosco, e ancora neanche in dettaglio :p). So che gli effetti migliori si ottengono appunto effettuando sia la radiosity sia il raytracing (ovvero un modello misto), anche se mi pare che con entrambi i modelli si possano ottenere risultati buoni (o discreti) nel campo diciamo di competenza dell'altro (non ricordo i dettagli, anzi, a dire il vero non li ho ancora studiati :D). Poi, è chiaro che se, invece di eseguire separatamente i calcoli di entrambi gli algoritmi, si riesce a realizzare un algoritmo misto che applica contemporaneamente entrambi i modelli (in un certo senso sulla falsariga dei vari algoritmi scan line) si velocizza tutto, anche se mi piacerebbe capire un po' meglio come vengano integrate le due ricorsioni (considerando anche che l'algoritmo di substructuring con la radiosity, che per quanto ne so, e cioè molto poco, è il più usato, va ad alterare la geometria della scena, suddividendo i poligoni ricorsivamente per ottenere risultati migliori, anche se può produrre qualche artefatto). E' anche chiaro che gli autori di Mental Ray non me lo diranno mai :D

Quanto alla cucina di Blender.it, di sicuro le caratteristiche dei materiali non sono definite bene, bicchiere e bottiglia sarebbero sicuramente venuti meglio con semplicemente lo shading di Gourod e alpha-blending (anche se onestamente non ricordo se e come si possa ottenere la trasparenza con la sola radiosity), poi la prospettiva mi sembra un po' strana, come anche l'illuminazione degli oggetti (è solo un'impressione mia, o l'orologio a muro non sembra perfettamente parallelo alla parete?).

Le tue critiche le condivido (troppi riflessi, la pentola in effetti riflette come delle cromature, eccessiva pulizia, eccessiva regolarità dei pomodori, cui aggiungerei che sembrano finti, tipo la frutta che si usa come ornamento in un cesto, anche se quella di vetro è più lucida, poi mi sembrano (potrei sbagliare) un po' troppo opachi, come se la luce che li colpisce fosse artificiale, non molto intensa e la sorgente non vicinissima, non certo il sole in pieno giorno, ecc.), comunque sarebbe interessante poter stabilire se è "colpa" del sw o delle scelte fatte, anche perchè mi pare di aver letto le stesse critiche in quel forum, pur tra l'approvazione generale, e l'autore si difendeva dicendo di aver usato impostazioni per la riflessione (se non ho tradotto male) più basse del (suo) solito. Forse la finestra è parzialmente (molto parzialmente) giustificabile: da una rapida occhiata all'"originale" che ha ispirato quel rendering (sufficiente a evidenziare i difetti della "copia"), sembra che sia coperta da una tenda (poco visibile) dalla quale traspare praticamente solo un fascio di luce molto intenso (ma potrebbe essere un'illusione dovuta a un'inquadratura non perfetta), ma in ogni caso non così uniforme e omogeneo (e irreale). Se è vero che blender è stato usato in Spiderman 2, sarebbe interessante vedere quelle scene. Non ho capito poi bene come è stato realizzato quel rendering, soprattutto non ho capito a cosa sia servito yafray (è un programma che non conosco :D). Mi pare che nel forum si parlasse di 40 ore per il rendering, ma non si descriveva la macchina.

Ciao :)

Originariamente inviato da xeal
x Chicco#32

Non credo che si possano "risvegliare", più che dormienti dovrebbero essere proprio disattivate, per cui non credo proprio che basterà smanettare sulla cpu (con vernice conduttiva, intervenendo su certi pin, ...) per sbloccarli. Con tutta probabilità si dovrà cambiare processore, come è stato per avere HT sui Northwood, anche se era già presente nei core prodotti precedentemente all'introduzione ufficiale (e funzionante) della tecnologia: non mi pare che su quelle cpu si potesse riabilitare la funzionalità Hyper Threading.

Ciao.

ok...grazie....

:)

Originariamente inviato da homero
ancora con sti 64bit???
uffa ma la gente e' dura a convincersi.....
oramai mi sono rassegnato......
avro' scritto 1 milione di volte che e' soltanto una implementazione su microcode e che non cambia nulla, ma qua tutti ad aspettare....

in alcune delle 1000 mila uscite, mi ricordo degli scontri con cdimauro in cui n ne sei uscito "benissimo" :D


Però magari, se estendessi il tuo pensiero qui, ci possiamo ragionare sopra...per quel motivo insomma, troveresti i 64 bit inutili.


mentre comprare un raid mi ha velocizzato parecchio adesso ci servono 8giga di ram?!?!?
ma....
insomma piu' sono inutili le cose e piu' questi ci tornano sopra....

francamente trovo molto meno rivoluzionario ed utile l'utilizzo del RAID a livello SOHO del passaggio 32-64bit.

La prima porta vantaggi concreti solo in ben determinate aree di utilizzo, solo a certe condizioni, ( cmq n voglio toccare di nuovo l'argomento, anche perchè ne avrò parlato almeno 10 volte :D...se ti interessa la mia opinione usa pure la ricerca così evitiamo di andare OT ;)), la seconda, prima o dopo sarà l'inizio di una nuova era dell'Informatica.


quanto ci saranno processori "veri" che non siano x86 ne riparliamo per il momento tenetevi il vostro bel XP-32bit che va tanto bene con un bel P4 northwood @3.6ghz

quanto ci saranno processori "veri" che n siano x86 ne riparliamo...

:confused: che intendi dire?

ancora co sta storia del microcode???

Originariamente inviato da homero
avro' scritto 1 milione di volte che e' soltanto una implementazione su microcode e che non cambia nulla,

E hai fatto capire 1 milione di volte che non conosci questa architettura... Ci sono nuove istruzioni, ci sono nuovi registri, i 16 registri di uso generale per interi sono a 64 bit (e visti a 32 bit dalle applicazioni a 32 bit). Mi spieghi come fai con il microcode a far "vedere" ad una applicazione il doppio dei registri? e come fai a raddoppiarne le dimensioni?

E poi, che vuol dire che gli x86 non sono processori "veri"? Credevo di essere seduto davanti a un computer "vero" e funzionante fino a pochi istanti fa... Oppure per te i processori "veri" sono solo i RISC/VLIW/EPIC? Devo dedurre che per te condizione necessaria affinche un processore possa essere definito a 64 bit è che non abbia architettura x86... Credevo che si usassero altri parametri (dimensione massima del formato istruzione? non sempre è il parametro corretto, ok... dimensione dei registri di uso generale, che possono contenere anche indirizzi di memoria? in genere non si usa questo?...)

E la ram non serve? sui desktop magari ancora no (ma negli anni a venire le cose potrebbero cambiare, meglio che la tecnologia cominci a diffondersi e a calare di prezzo) ma sulle workstation professionali? e sui server? un server multiprocessore con opteron che elabora continui accessi e scritture su un database ti fa schifo? Pensi che itanium andrebbe meglio in questo ambito, non essendo x86, anche se poi nei calcoli sugli interi (che sono a dir poco fondamentali nella gestione di un database) si dimostra lentuccio?

se sperate che scriva una relazione di 20 pagine per spiegarvi e spiegare a CDmauro che cosa sia il microcode e per quale ragione i 64bit x86 siano soltanto un piccola evoluzione nel campo dei microprocessori a livello prestazionale ve lo potete scordare (a meno che qualcuno non mi paghi per farlo), e' come utilizzare su un autovettura un cambio diverso sullo stesso motore.
in alcun situazioni si hanno dei vantaggi in altre degli svantaggi....ma il motore resta quello....

per quanto riguarda il raid era soltanto per delineare come l'abbondanza di ram non costituisce con i sistemi operativi attuali un sostituto di un buon sottosistema dischi, in questo il raid (o qualunque altra soluzione renda l'accesso e la memoriazione/lettura dei dati su hard disk piu' veloce in alcune applicazioni photoshop in testa da' aumenti prestazionali e diminuzione delle latenze notevoli anche con un solo gigabyte di ram)

io esprimo la mia ma non pretendo certo che siate d'accordo con me.

Originariamente inviato da cionci
Sì...se non sbaglio si erano limitati a valutare le prestazioni a 32 bit su applicazioni in cui la dipendenza dai driver era netta (giochi ad esempio)... Ovviamente i driver in beta hanno fatto il resto...
Esattamente. E dicevano che WOW64 andava male: una cosa assurda. Proprio la bontà di WOW64 era quella che, alle alte risoluzioni, copriva tutti i problemi legati ai driver a 64 bit immaturi e mostrava addirittura un frame rate più elevato rispetto alla controparte a 32 bit.

Giaaaanniiiii! Ma come non si fa a vedere delle cose macroscopiche come queste!!! :D

Originariamente inviato da homero
ancora con sti 64bit???
uffa ma la gente e' dura a convincersi.....
oramai mi sono rassegnato......
Io pure. :rolleyes:
avro' scritto 1 milione di volte che e' soltanto una implementazione su microcode e che non cambia nulla, ma qua tutti ad aspettare....cosa poi non lo capisce nessuno.....
DATI ALLA MANO, t'avrò smentito un altrettanto milione di volte. Continui ancora a sostenere le tue assurde tesi sul microcodice, quando non hai MAI aperto un manuale dell'architettura x86 e tanto meno x86-64... :mc:
La tua ignoranza in materia è abissale, e stranota a tutti i frequentatori del forum, come dimostrano i precedenti messaggi. Ma dico, sei masochista? Chi te lo fa fare a continuare sulla stessa, perdente linea? :rolleyes:
quanto ci saranno processori "veri" che non siano x86 ne riparliamo per il momento tenetevi il vostro bel XP-32bit che va tanto bene con un bel P4 northwood @3.6ghz
Certo, se poi sei in grado di darci una definizione di processore "vero", ci faresti un grosso favore. :mc:

Originariamente inviato da homero
se sperate che scriva una relazione di 20 pagine per spiegarvi e spiegare a CDmauro che cosa sia il microcode
Bisogna essere non troppo brillanti per impiegare ben 20 pagine per spiegare un concetto semplice come quello del microcodice... :asd:
e per quale ragione i 64bit x86 siano soltanto un piccola evoluzione nel campo dei microprocessori a livello prestazionale
Certo, certo: tanto piccola da sfuggire persino ai redattori. Hai mai letto qualche recensione di processori?
ve lo potete scordare (a meno che qualcuno non mi paghi per farlo),
Mettiamo le cose in chiaro: non hai gli attribuiti per poterlo fare. Perché un vero uomo, che sostiene le proprie tesi, non tira la pietra e nasconde la mano... :mc:

Qui sì che ha senso parlare di "veri" uomini. Come diceva Sciascia, esistono cinque tipi di uomini: gli uomini, i mezzi uomini, gli "ominicchi", i ruffuani, e gli quaqquaraquà. A quale categoria appartieni tu?
e' come utilizzare su un autovettura un cambio diverso sullo stesso motore.
in alcun situazioni si hanno dei vantaggi in altre degli svantaggi....ma il motore resta quello....
Ovviamente queste tue "attente" riflessioni derivano da una notevole conoscenza delle architetture x86 e x86-64, vero? :asd:
o esprimo la mia ma non pretendo certo che siate d'accordo con me.
Sei liberissimo di farlo. Resti però una mosca bianca, perché soltano uno come te ha il coraggio di continuare ad affermare certe assurdità, quando in OGNI occasione sei stato smentito, dati alla mano.
Perfino quando parlavi dell'Itanium e della sua velocità ben QUATTRO volte superiore a quella dei migliori PC, e con i dati che TU STESSO hai riportato: una bolla di sapone scoppiata fin troppo facilmente.

Torna a casa, Lassie...

azz...non vedo allora perche' continuino ad usarlo in facoltà.....
invece dell'opteron.....
e dire che le ho passate tutte dalle schede trasputer su 386 del 1990 ai primi alpha a 64bit della digital a 150mhz fino ai PA-RISC HP del 1999 multinodo da 32 cpu....ora da 1 anno stiamo su itanium, o sono tutti matti a buttare i soldi cosi' o i vostri conti non tornano.
visto che sono ignorante e certamente lo sono, non si puo' sapere tutto nella vita, spero che qualcuno possa spiegarmi la differenza che c'e' tra unità di calcolo gestite tramite microcode e unità di calcolo gestite in modalità nativa.
ed inoltre i metodi di calcolo dei timing di latenza per l'esecuzione delle istruzioni su microcode e quelli per l'esecuzione delle istruzioni native. una volta che il dotto cdmauro mi avra' spiegato queste informazioni e mi avra' prodotto un codice X86 ed il suo equivalente X86-64 con cui il gap prestazionale sia evidente e marcato allora ne parliamo.....
il 15% piu' veloce sugli interi?!?!?
il 4% sugli fp?!?!?
il 20% sugli shift dei registri?!?!?

:)

non penso si possa andare oltre queste ottimistiche ipotesi....risultando in definitiva il passaggio dai 32 ai 64 alla pari di quello tra un p4 in modalità normale ed uno in modalità HT, sempre grazie all'arte di gestione delle unità di calcolo mediante microcode....

Ma mi sa che sarà solo un'altro palliativo o mossa comerciale, xchè se non fosse cosi hai voglia che il buon Billy avrebbe gia sfornato il S.O a 64bit, se invece sta andando avanti cosi è proprio xchè alla fine è solo molto lavoro e poco profitto e quando anche gli utenti avranno modo di toccarlo con mano e accorgersi di questo avranno trovato nel frattempo qualcosa che riduce il gap prestazionale, infatti se non fosse stato x AMD che ha stressato con la sua cpu a 64bit avrebbero lasiato volentieri le cose come stavano......................


Immo è solo come la vedo io (non fustigatemi) :D .............
ByeZ..............
;)

Originariamente inviato da homero
azz...non vedo allora perche' continuino ad usarlo in facoltà.....
invece dell'opteron.....
e dire che le ho passate tutte dalle schede trasputer su 386 del 1990 ai primi alpha a 64bit della digital a 150mhz fino ai PA-RISC HP del 1999 multinodo da 32 cpu....ora da 1 anno stiamo su itanium, o sono tutti matti a buttare i soldi cosi' o i vostri conti non tornano.
visto che sono ignorante e certamente lo sono, non si puo' sapere tutto nella vita, spero che qualcuno possa spiegarmi la differenza che c'e' tra unità di calcolo gestite tramite microcode e unità di calcolo gestite in modalità nativa.
ed inoltre i metodi di calcolo dei timing di latenza per l'esecuzione delle istruzioni su microcode e quelli per l'esecuzione delle istruzioni native. una volta che il dotto cdmauro mi avra' spiegato queste informazioni e mi avra' prodotto un codice X86 ed il suo equivalente X86-64 con cui il gap prestazionale sia evidente e marcato allora ne parliamo.....
il 15% piu' veloce sugli interi?!?!?
il 4% sugli fp?!?!?
il 20% sugli shift dei registri?!?!?

:)

non penso si possa andare oltre queste ottimistiche ipotesi....risultando in definitiva il passaggio dai 32 ai 64 alla pari di quello tra un p4 in modalità normale ed uno in modalità HT, sempre grazie all'arte di gestione delle unità di calcolo mediante microcode....


L'Itanium è molto forte nell' FP. Per questo, nelle applicazioni FP (calcoli ingegneristici, per es.) e dove il rapporto prezzo/prestazioni non è fondamentale l'Itanium è in linea teorica preferibile all'Opteron. Se invece vuoi gestire un database con l'Itanium, significa che sei masochista perchè spendi di più ottenendo prestazioni allineate o peggio. Tutto qui.
Tra l'altro la vergogna di HP e Intel è che abbiano fatto morire l'Alpha che se oggi avesse le frequenze dell'Itanium e le corrispettive cache sarebbe ancora un progetto validissimo e molto competitivo, proprio nel campo FP.

Per quanto riguarda l'incremento prestazionale nel passaggio da 32 a 64 bit in campo x86, è prematuro parlare.
Ci saranno applicazioni dove l'incremento di prestazioni sarà nullo. Altre invece andranno al doppio della velocità. In media? non si può dire, vedremo. Ah, in determinate applicazioni l'HT dà un boost prestazionale ai P4 per nulla trascurabile, anzi senza di esso il P4 probabilmente sarebbe indietro nel 95% dei test rispetto agli A64 in modalità 32 bit. Magari allora si avesse questo boost ;)

Originariamente inviato da homero
se sperate che scriva una relazione di 20 pagine per spiegarvi e spiegare a CDmauro che cosa sia il microcode e per quale ragione i 64bit x86 siano soltanto un piccola evoluzione nel campo dei microprocessori a livello prestazionale ve lo potete scordare (a meno che qualcuno non mi paghi per farlo), e' come utilizzare su un autovettura un cambio diverso sullo stesso motore.

permettimi, ma anche uno che di pc ne capisce poco, s evede il disegno dell'architettura di un K7, confrontato a quella del K8 può notare come la differenza non si esaurisca solo nella frase
e' soltanto una implementazione su microcode e che non cambia nulla

Se poi vuoi motivare le tue idee liberissimo, altrimenti liberissimo =mente ( ci mancherebbe), solo non sperare di convincere tutti gli altri solo con la metafora della macchina.

Oltretutto sei tu che hai fatto quel post, "controcorrente" e tu dovresti motivare il motivo del perchè hai scritto quel che hai scritto.
Un pò troppo facile dire "lo faccio se mi pagate".
Dato che nessuno ti pagherà mai per farlo...


in alcun situazioni si hanno dei vantaggi in altre degli svantaggi...



per quanto riguarda il raid era soltanto per delineare come l'abbondanza di ram non costituisce con i sistemi operativi attuali un sostituto di un buon sottosistema dischi, in questo il raid (o qualunque altra soluzione renda l'accesso e la memoriazione/lettura dei dati su hard disk piu' veloce in alcune applicazioni photoshop in testa da' aumenti prestazionali e diminuzione delle latenze notevoli anche con un solo gigabyte di ram)

prima di tutto occorre specificare l'ambito in cui stai delineando il problema.
Se parli di mercato consumer, SOHO sn d'accordo con te che la RAM ha la sua importanza, ma difficilmente la richiesta sarà tale da superare i 4GB ( per ora), nel mercato workstation/server invece è TUTTO un altro paio di maniche...l'esempio del database di HWupgrade è abb sintomatico.

Per il RAID però, IMHO, valgono le stesse considerazioni...quando si tratta di affidabilità è chiaro come risulti una soluzione molto efficace se n obbligatoria in moltissimi casi, però chiaramente ci vuole un'infrastruttura adeguata, dischi adeguati ( SCSI+controllers).
Serve tutto questo per un utente normale che giochicchia, lavora con suite office e naviga?

La risposta è no; servirà a chi per lavoro si occupa di 3D rendering molto pesanti o chi utilizza il proprio pc, massicciamente, in lavori di encoding/decoding...ma quanti sn sul complessivo di utenti?
Diciamo "pochi"...qui si esaurisce il discorso del RAID, i 64bit invece sn una "sorpresa" tutta proiettata al futuro.


io esprimo la mia ma non pretendo certo che siate d'accordo con me.

ci mancherebbe...però sei concorde con me sul fatto che se io faccio una "sparata", poi per mantenere il dialogo, debba anche motivare le mie idee.

Altrimenti da domani ci mettiamo a scrivere le cose + assurde, tipo che in realtà il Nortwood già integra l'EMT64 o che i K8 emulano l'esecuzione del codice a 32bit, tanto se poi non dobbiamo dimostrare la tesi...checcefrega?

;)

Originariamente inviato da thoby
Ma mi sa che sarà solo un'altro palliativo o mossa comerciale,

ovviamente sn SEMPRE mosse commerciali, si stà parlando di un mercato potenziale di miliardi di dollari, non bruscolini


xchè se non fosse cosi hai voglia che il buon Billy avrebbe gia sfornato il S.O a 64bit,

proprio perchè si tratta di una politica che risponde alla logica del profitto ( come è ovvio), n si tratta di avere voglia di fare qlc, ma di analizzare se ci siano i presupposti economici o meno per farlo.

Ovviamente non si poteva sperare che Microsoft facesse uscire il suo SO a 64bit solo per AMD.
Primo, perchè, e lo penso sinceramente, come tutto il resto degli addetti ai lavori, è rimasta sorpresa dal progetto K8 di AMD e della sua bontà nell'eseguire codice nativo a 32bit.
Insomma nessuno si aspettava che il comportamento della cpu fosse così valido in entrambe le modalità...ed ecco perchè ha avuto un buon successo da quanto è stato introdotto nonostante il parco sw continui a latitatare.
E quindi non c'è stato il tempo per uno sviluppo così repentino da seguire l'evoluzione del mercato dei processori.

In secondo luogo, perchè si sarebbe trattato di progettare due distinte versioni di Xp-64, una compatibile con AMD e una per Intel...questo è inaccettabile per la stessa Microsoft.

Quindi si è trovata "costretta" ad aspettare le mosse di Intel, che ha finalmente introdotto l'EMT64 e che ricordiamo detiene + dell'80% del mercato dei semiconduttori.
Insomma, ti pare onestamente logico che Microsoft, sw house leader nel mondo ( 90% e + ei computer hanno installato un suo SO) sviluppi un nuovo SO solo per AMD, che non arriva al 20% dello share totale dei processori?

A me francamente no...


se invece sta andando avanti cosi è proprio xchè alla fine è solo molto lavoro e poco profitto e quando anche gli utenti avranno modo di toccarlo con mano e accorgersi di questo avranno trovato nel frattempo qualcosa che riduce il gap prestazionale, infatti se non fosse stato x AMD che ha stressato con la sua cpu a 64bit avrebbero lasiato volentieri le cose come stavano......................


Immo è solo come la vedo io (non fustigatemi) :D .............
ByeZ..............
;)

da una parte, non possono permettersi il lusso di fare uscire un prodotto "alla cieca", senza una buona base di beta-testing, supporto HW e tutto quel che concerne la realizzazione di un ( buon) sistema operativo.
Dall'altra, MS sà benissimo che i 64bit sn potenzialmente un'ENORME gallina dalle uova d'oro...quindi non credo tarderà ancora per molto a presentarsi sul mercato, sperando poi che tutte le altre sw houses la seguano di conseguenza...

Originariamente inviato da homero
azz...non vedo allora perche' continuino ad usarlo in facoltà.....
invece dell'opteron.....
e dire che le ho passate tutte dalle schede trasputer su 386 del 1990 ai primi alpha a 64bit della digital a 150mhz fino ai PA-RISC HP del 1999 multinodo da 32 cpu....ora da 1 anno stiamo su itanium, o sono tutti matti a buttare i soldi cosi' o i vostri conti non tornano.
T'hanno già risposto: dipende dalle applicazioni che ci fate.
visto che sono ignorante e certamente lo sono, non si puo' sapere tutto nella vita,
Da come parlavi, sembra tu fossi un luminare...
spero che qualcuno possa spiegarmi la differenza che c'e' tra unità di calcolo gestite tramite microcode e unità di calcolo gestite in modalità nativa.
Uno che dice di impiegare 20 pagine per scriverlo dovrebbe saperlo.
ed inoltre i metodi di calcolo dei timing di latenza per l'esecuzione delle istruzioni su microcode e quelli per l'esecuzione delle istruzioni native. una volta che il dotto cdmauro mi avra' spiegato queste informazioni
Il dotto cdimauro t'invita a scaricarti il seguente manuale http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/25112.PDF e a prenderne visione personalmente.
E t'invita anche a riportare cosa significa che le istruzioni dell'ISA x86 e x86-64 vengano tradotte in Direct Path, Direct Path Double o Vector Path.
e mi avra' prodotto un codice X86 ed il suo equivalente X86-64 con cui il gap prestazionale sia evidente e marcato allora ne parliamo.....
il 15% piu' veloce sugli interi?!?!?
il 4% sugli fp?!?!?
il 20% sugli shift dei registri?!?!?

:)
Mi basta riportare qualche grafico dai link precedentementi segnalati:
http://images.anandtech.com/graphs/amd%20and%20linux%20reaching%20for%20the_07080410724/3006.png
http://images.anandtech.com/graphs/amd%20and%20linux%20reaching%20for%20the_07080410724/3009.png
Questo giusto per confrontare le prestazioni. Per vedere le differenze di codice, puoi sempre dissamblertelo, se proprio ci tieni...
non penso si possa andare oltre queste ottimistiche ipotesi....
In quei due test abbiamo un risparmio del 20% e del 25% rispettivamente, che possiamo leggere anche come un aumento del 26% e del 35% del codice a 32 bit rispetto a quello a 64 bit, sulla stessa macchina.
Nei test di compressione con OGG Vorbis di questo link http://www.thejemreport.com/modules.php?op=modload&name=News&file=article&sid=117 i risultati sono anche superiori... ;)
risultando in definitiva il passaggio dai 32 ai 64 alla pari di quello tra un p4 in modalità normale ed uno in modalità HT, sempre grazie all'arte di gestione delle unità di calcolo mediante microcode....
Innazitutto vediamo che le tue previsioni sono state nettamente frantumate. Poi continui ancora con la storia del microcodice: lo vuoi capire una volta per tutte che le istruzioni Direct Path e Direct Path Double (che costituiscono la stragrande maggioranza fra quelle utilizzate) sono ESEGUITE DIRETTAMENTE dall'unità RISC86 presente negli x86-64? ESATTAMENTE come per il tuo beneamato Itanium. Le sole istruzioni che ricorrono ancora al microcodice sono le Vector Path che, ripeto, sono praticamente inutilizzate. O vuoi forsi dirmi che esiste ancora qualche compilatore che genera codice che utilizza le istruzioni AAA, AAM, BOUND, ENTER, PUSHA, ecc. ecc. ecc.?

Mettiti in testa una volta per tutte che il microcodice lo vedono col binocolo gli x86-64. E' chiaro, o c'è bisogno di ripetere per la milionesima volta questo BANALE concetto? :rolleyes:

Originariamente inviato da cionci
Anche perchè a quei tempi si sentiva meno il limite dei 4 Gb...
Ci sono già molte workstation che hanno 4 Gb di Ram... Dei server non ne parliamo...in quegli ambiti il limite dei 4 Gb è limitante già da tempo (ed è stato aggirato con il PAE anche se con prestazioni orribili)... Se non lo sapete le funzionalità di ricerca di questo forum sono limitate ai post dell'ultimo mese perchè è stato avvicinato il limite dei 4Gb...

Nel campo desktop il limite dei 4 Gb non si sente, ma quanto tempo pensate che ci voglia ancora ?

Esatto.
Un anno? Due anni? Forse tre ad essere pessimisti, ma sicuramente si sta raggiungendo il limite. Sulla mia macchina di lavoro ho 2gb di RAM, l'anno scorso avevo 1gb, l'anno prima 512k. E' giusto un esempio che non vuol essere definitivo.

E' giusto quindi che si inizi a parlare oggi di CPU e SO a 64bit, di modo che nel giro di un paio di anni si possa iniziare la migrazione.
Dal punto di vista puramente prestazionale, senza tenere conto dei decadimenti di prestazioni che avere meno RAM di quella necessaria provoca, non c'e' quasi alcuna differenza fra un'applicazione a 32 ed una a 64 bit. Ad esempio, per un gioco, al giorno d'oggi non c'e' nulla che giustifichi una versione a 64 bit.

Originariamente inviato da homero
se sperate che scriva una relazione di 20 pagine per spiegarvi e spiegare a CDmauro che cosa sia il microcode e per quale ragione i 64bit x86 siano soltanto un piccola evoluzione nel campo dei microprocessori a livello prestazionale ve lo potete scordare (a meno che qualcuno non mi paghi per farlo), e' come utilizzare su un autovettura un cambio diverso sullo stesso motore.
in alcun situazioni si hanno dei vantaggi in altre degli svantaggi....ma il motore resta quello....


Io sarei interessato a questa spiegazione di 20 pagine, perche' non vedo proprio come un registro dati o d'indirizzo a 32 bit possa essere esteso a 64 bit solo modificando il microcodice.

quelli proposti non sono in alcun modo bench attendibili....
quel link con quel pdf me lo hai gia' postato tempo fa....
disammblere 10000 righe di codice quando ne basterebbe un programmino di poche decine mi sembra alquanto superfluo....
in particolar modo il benchmark di povray che se fosse attendibile sarebbe realmente uno scoop, e sopratutto tirare fuori un algoritmo replicabile sintetico di calcolo sarebbe la cosa piu' facile con questi tempi cosi' marcati, peccato che siano soltanto di fantasia....
ho letto la pagina di test eseguiti che hai postato

http://www.thejemreport.com/modules.php?op=modload&name=News&file=article&sid=117

e ogg e' l'unico test in cui amd64 primeggia tutti gli altri lo vedono alla pari con scarti di circa +/- 5% e vogliamo gridare per questo che i 64bit sono superiori, hai omesso di dirlo nella tua risposta

inoltre osserva lo stesso autore che amd64 e HT sono tecnologie paragonabili.....con naturali differenze....

come ho scritto e come suppone l'autore gli integer 64 sono l'unico punto in cui il processore rende meglio con le istruzioni a 64bit questo ad ogni modo non basta per ottenere un boost di prestazioni degno di nota....

Una domanda:

Ma un aumento tra il 5-20% delle prestazioni, per come da voi riportato, è corretto pensare che, mentre in termini "umani" siano un pò "pochini", rapportati invece al mondo dell'elaborazione siano "un'enorme" guadagno prestazionale?

Originariamente inviato da homero
come ho scritto e come suppone l'autore gli integer 64 sono l'unico punto in cui il processore rende meglio con le istruzioni a 64bit questo ad ogni modo non basta per ottenere un boost di prestazioni degno di nota....
Perchè ? Dove te li aspettavi ulteriori incrementi ?

Se non erro sono stati aggiunti anche dei registri SSE, ma non vorrei sbagliarmi.
La sezione FP è rimasta quella degli Athlon XP.

Sì...sonos tati aggiunti anche altri registri per SSE...

appunto!!!
io non m li aspetto proprio
visto che gli integer a 64bit non sono molto usati negli algoritmi.....

Originariamente inviato da cionci
Perchè ? Dove te li aspettavi ulteriori incrementi ?

Detto altrimenti: perchè, a cos'altro si può pensare parlando di 64 bit in un processore, se non ai calcoli interi e all'indirizzamento della memoria aumentato, quando da una vita ormai le fpu lavorano internamente a 80 bit e le SIMD degli x86 a 128 bit?

Francamente l'unica aggiunta di microcode rispetto ai K7 la vedo possibile nella gestione da parte del sottosistema di controllo delle modalità operative (64 nativi, legasy, ecc.), ad esempio per gestire la lettura/scrittura in modalità 32 bit della longword meno significativa del registro e mascherare i registri aggiuntivi, oppure per variare la decodifica delle istruzioni aggiungendo, in modalità 64 bit, il supporto alle nuove istruzioni. Ora, se dobbiamo scandalizzarci per la latenza di qualche porta e la gestione di qualche segnale di controllo in più, arrivando ad affermare che la differenza la fa il microcodice...

Originariamente inviato da homero
appunto!!!
io non m li aspetto proprio
visto che gli integer a 64bit non sono molto usati negli algoritmi.....
Vai a vedere nei databse... Comunque l'aumento del numero dei registri della ALU si risente anche in qualsiasi software compilato per AMD64 che fa uso di interi a 32 bit...pensa a quante PUSH e POP ci si risparmia...

Stessa cosa per le operazioni in virgola mobile effettuate mediante SIMD, che ormai sono lo standard nelle applicazioni x86; se si usasse (o tornasse) ad usare maggiormente l'FPU, gli AMD saprebbero farsi valere maggiormente anche lì.

pensa a quante push e pop si risparmia....se i push e pop corrispondessero a delle precise unità architetturali, ma queste vengono smembrate dal microcode in istruzioni native riordinate e date in pasto all unità di esecuzione...quindi a priori non si sa se 10 push a 32bit e 5 push a 64bit siano effettivamente piu' performanti quello che ' sicuro che tradurre 10 push in istruzioni native e certamente piu' oneroso che tradurne 5 ma livello prestazione non cambia nulla....

Originariamente inviato da homero
pensa a quante push e pop si risparmia....se i push e pop corrispondessero a delle precise unità architetturali, ma queste vengono smembrate dal microcode in istruzioni native riordinate e date in pasto all unità di esecuzione...quindi a priori non si sa se 10 push a 32bit e 5 push a 64bit siano effettivamente piu' performanti quello che ' sicuro che tradurre 10 push in istruzioni native e certamente piu' oneroso che tradurne 5 ma livello prestazione non cambia nulla....
Non era quello il mio discorso...con 16 registri ALU si ricorrerà sicuramente meno alla push e alla pop... Prima appena si avevano 8 registri pieni si ricorreva alla push e alla pop quando ci mancavano registri per contenere gli operandi...

Originariamente inviato da xeal
x dagon1978

Chiaramente io parlo di teoria (quella conosco, e ancora neanche in dettaglio :p). So che gli effetti migliori si ottengono appunto effettuando sia la radiosity sia il raytracing (ovvero un modello misto), anche se mi pare che con entrambi i modelli si possano ottenere risultati buoni (o discreti) nel campo diciamo di competenza dell'altro (non ricordo i dettagli, anzi, a dire il vero non li ho ancora studiati :D). Poi, è chiaro che se, invece di eseguire separatamente i calcoli di entrambi gli algoritmi, si riesce a realizzare un algoritmo misto che applica contemporaneamente entrambi i modelli (in un certo senso sulla falsariga dei vari algoritmi scan line) si velocizza tutto, anche se mi piacerebbe capire un po' meglio come vengano integrate le due ricorsioni (considerando anche che l'algoritmo di substructuring con la radiosity, che per quanto ne so, e cioè molto poco, è il più usato, va ad alterare la geometria della scena, suddividendo i poligoni ricorsivamente per ottenere risultati migliori, anche se può produrre qualche artefatto). E' anche chiaro che gli autori di Mental Ray non me lo diranno mai :D

Quanto alla cucina di Blender.it, di sicuro le caratteristiche dei materiali non sono definite bene, bicchiere e bottiglia sarebbero sicuramente venuti meglio con semplicemente lo shading di Gourod e alpha-blending (anche se onestamente non ricordo se e come si possa ottenere la trasparenza con la sola radiosity), poi la prospettiva mi sembra un po' strana, come anche l'illuminazione degli oggetti (è solo un'impressione mia, o l'orologio a muro non sembra perfettamente parallelo alla parete?).

Le tue critiche le condivido (troppi riflessi, la pentola in effetti riflette come delle cromature, eccessiva pulizia, eccessiva regolarità dei pomodori, cui aggiungerei che sembrano finti, tipo la frutta che si usa come ornamento in un cesto, anche se quella di vetro è più lucida, poi mi sembrano (potrei sbagliare) un po' troppo opachi, come se la luce che li colpisce fosse artificiale, non molto intensa e la sorgente non vicinissima, non certo il sole in pieno giorno, ecc.), comunque sarebbe interessante poter stabilire se è "colpa" del sw o delle scelte fatte, anche perchè mi pare di aver letto le stesse critiche in quel forum, pur tra l'approvazione generale, e l'autore si difendeva dicendo di aver usato impostazioni per la riflessione (se non ho tradotto male) più basse del (suo) solito. Forse la finestra è parzialmente (molto parzialmente) giustificabile: da una rapida occhiata all'"originale" che ha ispirato quel rendering (sufficiente a evidenziare i difetti della "copia"), sembra che sia coperta da una tenda (poco visibile) dalla quale traspare praticamente solo un fascio di luce molto intenso (ma potrebbe essere un'illusione dovuta a un'inquadratura non perfetta), ma in ogni caso non così uniforme e omogeneo (e irreale). Se è vero che blender è stato usato in Spiderman 2, sarebbe interessante vedere quelle scene. Non ho capito poi bene come è stato realizzato quel rendering, soprattutto non ho capito a cosa sia servito yafray (è un programma che non conosco :D). Mi pare che nel forum si parlasse di 40 ore per il rendering, ma non si descriveva la macchina.

Ciao :)

credo proprio che gli autori di mental ray non ti daranno molte info sul loro programma, però puoi sempre provare a rivolgerti a chi sta sviluppando yafray (il motore di rendering di Blender), se non sbaglio è un progetto open source ;)
Blender è stato usato effettivamente per Spiderman, ma non certo per il rendering o per le animazioni (se hai visto il film nei titoli di coda ci troverai un certo Maya ;)) quanto per gli animatics (dove in genere si usa Houdini...)
cmq 40 ore di rendering non sono poche, ma la complessità della scena (soprattutto dei materiali) è alta quindi tutto sta nel vedere che pc hanno usato (sono troppo pigro, ma magari farò un salto su quel forum)
cmq leggendo un po' in giro quasi devo ricredermi... ho trovato molti commenti entusiastici su Blender, anche di persone con una certa esperienza ;)
ciau

Perbacco, in questo forum basta poco per innalzare la temperatura. Comunque...

Mi dispiace pensare che le capacità prestazionali siano considerate utili solo per i videogiochi. Io uso, da un po' di tempo, Magix Video Deluxe per il montaggio video e - dato che lavoro con due monitor - mi piace controllare sul secondo, con TaskManager/Prestazioni, l'impegno del mio PC (AMD Athlon XP 2600+, 512 MB Ram, 80 giga HD). Ebbene: durante l'elaborazione finale di un progetto video, il processore lavora al 100%, per la durata di un'ora intera per ogni mezz'ora di filmato, mentre lo swap su disco è quasi inesistente (lo deduco, e magari sarò superficiale, dal fatto che il led dell'HD si illumina molto raramente).
Conclusione: aggiornerò il mio sistema HW / SW solo quando:
1) Saranno disponibili sistemi a 64 bit (già fatto, a quanto pare, grazie AMD!)
2) Sarà disponibile un SO a 64 bit che sia capace di sfruttare il processore (Bill, datti una mossa)
3) Sarà possibile acquistare un sw di editing video che riduca almeno del 50% (cioè non più di un'ora di elaborazione per un'ora di filmato).

Ora come ora, infatti, non saprei che farmene di un sw che, invece di un'ora, tenga impegnato il mio PC per "soli" 50 minuti.

Suggerisco quindi, prima di dare valutazioni sulle performance di qualunque cosa (Hw, Sw), di tenere conto delle esigenze *reali* degli utenti e non di benchmark fine a se stessi.

un altro ritardo per la microsoft...
oltre al longhoron ci si mette anche windows xp 64 bit :muro: :muro: :muro: :muro:

Originariamente inviato da homero
quelli proposti non sono in alcun modo bench attendibili....
POV-Ray sì e gli altri no? E perché?
quel link con quel pdf me lo hai gia' postato tempo fa....
Questo non depone certo a tuo favore. :rolleyes: A questo punto posso dedurre due cose: o non l'hai letto o non c'hai capito nulla.
Eppure continui spavaldamente a parlare di microcodice...
disammblere 10000 righe di codice quando ne basterebbe un programmino di poche decine mi sembra alquanto superfluo....
In questo è la logica ad essere superflua, mi sa. Se lo STESSO programma viene compilato prima a 32 bit e poi a 64 bit, e fatto girare sulla STESSA macchina, ottenendo dei risultati DIVERSI, QUALCOSA dovrà pur essere cambiato, giusto? Vuol dire che POV-Ray, ad esempio (ma vale anche per MySQL, l'encoder OGG Vorbis, ecc.), utilizzano delle caratteristiche PECULIARI dell'architettura x86 che permettono di ottenere dei MIGLIORAMENTI nella velocità di esecuzione.
Logico, no? A cosa serve confrontare il disassemblato dei due programmi?
in particolar modo il benchmark di povray che se fosse attendibile sarebbe realmente uno scoop,
E perché non dovrebbe esserlo? E' stato compilato prima a 32 bit e poi a 64 bit (parlo di architetture comunque): dove sta l'inghippo secondo te?
e sopratutto tirare fuori un algoritmo replicabile sintetico di calcolo sarebbe la cosa piu' facile con questi tempi cosi' marcati, peccato che siano soltanto di fantasia....
Non è una fantasia semplicemente ricompilare un'applicazione per la nuova architettura e notare dei benefici.
ho letto la pagina di test eseguiti che hai postato

http://www.thejemreport.com/modules.php?op=modload&name=News&file=article&sid=117

e ogg e' l'unico test in cui amd64 primeggia tutti gli altri lo vedono alla pari con scarti di circa +/- 5% e vogliamo gridare per questo che i 64bit sono superiori, hai omesso di dirlo nella tua risposta
Non ho omesso proprio niente: qui NESSUNO ha mai detto che con l'architettura si ottengono esclusivamente dei benefici. Esistono anche dei casi di perdita di prestazione, ma si tratta di poca cosa: qualche punto percentuale, come hai potuto notare. Rimane il fatto che MEDIAMENTE la nuova architettura comporta un aumento di prestazioni pari al 15-20%: fonte AMD.
inoltre osserva lo stesso autore che amd64 e HT sono tecnologie paragonabili.....con naturali differenze....
Non sono affatto paragonabili: sono completamente diverse. Se ha scritto così, ha detto una cazzata immane. Paragonabile ci può essere soltanto il miglioramento che permettono di ottenere nelle prestazioni del sistema, ma null'altro.
come ho scritto e come suppone l'autore gli integer 64 sono l'unico punto in cui il processore rende meglio con le istruzioni a 64bit questo ad ogni modo non basta per ottenere un boost di prestazioni degno di nota....
Beh, intanto il boost c'è, ed è degno di nota. Specialmente se consideri che POV-Ray, ad esempio, non fa praticamente uso di interi a 64 bit. Quindi il guadagno è dovuto al cambio di architettura.
Con i database, che fanno uso di interi a 64 bit (per valori e/o campi autoincrementanti, e soprattutto per il tipo di dati Currency), il boost è notevole, anche se le prove fatte con MySQL sono orientate al web, e quindi ne fanno poco uso (nei software di gestione aziendale, ad esempio, sono usatissimi i Currency).

Originariamente inviato da RaouL_BennetH
Una domanda:

Ma un aumento tra il 5-20% delle prestazioni, per come da voi riportato, è corretto pensare che, mentre in termini "umani" siano un pò "pochini", rapportati invece al mondo dell'elaborazione siano "un'enorme" guadagno prestazionale?
Dipende sempre da quello che ci fa e dal valore che dai al guadagno ottenuto.
Comunque, AMD dichiara un aumento del 15-20% medio.

Originariamente inviato da homero
quindi a priori non si sa se 10 push a 32bit e 5 push a 64bit siano effettivamente piu' performanti quello che ' sicuro che tradurre 10 push in istruzioni native e certamente piu' oneroso che tradurne 5 ma livello prestazione non cambia nulla....

Quindi 5 accessi alla memoria incidono sulle prestazioni quanto 10...

Poi, mi sorprenderebbe se le microop corrispondenti alle push e pop, in un processore che cerca di mantenere quanto più possibile la compatibilità tra le sue due modalità native, dovrebbero essere differenti quando si opera nell'una piuttosto che nell'altra: all'eseguibile importa poco di come vengono eseguite internamente, no? Quindi, al limite, avrebbe più senso cercare di migliorare le operazioni interne, oppure lasciarle invariate, ma comunque non modificare il modo in cui vengono eseguite fintanto che non si cambia il formato istruzione/ il modo di interpretarlo, ovvero il modo di decodificarlo e ricondurlo alle microop. Caso mai, potrebbe cambiare (probabilmente nemmeno in modalità legacy) il modo di indirizzare la memoria, ma qui torniamo alla logica (poca, credo) e ai segnali di controllo aggiuntivi, per modificare il modo di operare, ad esempio, sul MAR, ma questo succederà in entrambe le modalità native, quindi l'eventuale rallentamento dove può essere?

Originariamente inviato da SuperSandro
Ora come ora, infatti, non saprei che farmene di un sw che, invece di un'ora, tenga impegnato il mio PC per "soli" 50 minuti.

Dipende tutto da quello che ci devi fare. Magari per te quei 10 minuti sono un guadagno irrisorio, ma per qualcuno che facesse lavori più complessi (anche in altri ambiti), qui 10 minuti potrebbero rappresentare un'ora intera risparmiata su 7 ore che avrebbe impiegato in precedenza, un lavoro che prima ti richiedeva 40 ore lo porti a termine in poco più di 34, a certi livelli non è poco, stiamo parlando sempre di circa il 17% di tempo risparmiato. Ovviamente nel tuo caso il gioco potrebbe non valere la candela, quindi fai bene ad aspettare, non bisogna comprare per forza qualcosa che poi non serve veramente ;).

Originariamente inviato da dagon1978
cmq 40 ore di rendering non sono poche, ma la complessità della scena (soprattutto dei materiali) è alta quindi tutto sta nel vedere che pc hanno usato (sono troppo pigro, ma magari farò un salto su quel forum)

In quel thread mi pare non fosse specificato, però ricordo che l'autore diceva di aver notato operazioni continue di swapping, quindi probabilmente non sarà una macchina particolarmente potente e con molta memoria.

cmq leggendo un po' in giro quasi devo ricredermi... ho trovato molti commenti entusiastici su Blender, anche di persone con una certa esperienza

Beh, provalo, usa le texture e i dati di un lavoro che hai già fatto (in particolare le impostazioni per i materiali) e confronta i risultati, magari trovi anche una funzione di import per i modelli degli oggetti (e poi, che sarà mai ridisegnare un centinaiio di geometrie complesse :D), e il gioco è fatto ;) :D :sofico:

Originariamente inviato da cdimauro
A questo punto posso dedurre due cose: o non l'hai letto o non c'hai capito nulla.


Ci sarebbe anche una terza ipotesi (che potrebbe anche essere causa della prima o conseguenza della seconda che hai formulato): considera la fonte poco attendibile, in quanto si tratta del produttore stesso della cpu, trascurando che falsare in qualche modo quei dati significa impedire ad un compilatore che volesse supportarla di ottimizzare bene il codice, per cui non solo il processore non farebbe una gran figura, ma lo stesso compilatore potrebbe addirittura risultare peggiore di uno che non applichi ottimizzazioni specifiche per quel processore (oltre a quanto sarebbe inevitabile fare (e nel caso specifico lo sarebbe), supponendo di poter sfruttare certe caratteristiche anche in maniera "superficiale", senza presupporre una conoscenza approfondita dell'architettura e della velocità con cui vengono eseguite certe istruzioni), mandando a p***ne, dopo il primo fallimentare "approcio" da parte degli sviluppatori, la possibilità di veder mai supportate delle caratteristiche che potrebbero fare la differenza con i prodotti della concorrenza.

Ma potrebbe esserci anche una quarta ipotesi: se il numero delle pagine da leggere è maggiore o uguale a 20 vuol essere pagato :asd:

voi che avete "letto" e "compreso" spiegate i punti di forza di questa architettura.....
...penso che riposterete il medesimo link.....e chioserete con un "e' tutto scritto li'"
.......

Il link l'ho inserito in merito alla discussione sul "microcodice sì o no" che hai tirato in ballo tu. Mi bastano un po' di righe per poterti rispondere su questo.

LA STORIA

A partire dal K5 di AMD, tutti i processori x86 sono dotati di un'unità RISC dedicata (chiamata in gergo RISC86), che si occupa effettivamente di portare avanti i calcoli e le operazioni. Tutte le istruzioni dell'ISA x86 vengono, quindi, convertite "on the fly" (in questo fa eccezione l'architettura NetBurst del P4, ma preferisco non parlarne in questo contesto) nelle equivalenti RISC86, che poi sono eseguite, appunto, da core RISC86. Le istruzioni RISC86 NON FANNO USO DI MICROCODICE.

IL PRESENTE

AMD col K7 prima, e col K8 adesso distingue in 3 tipi di istruzioni: Direct Path, DirectPath Double (non presente nei K7) e Vector Path. Quindi un'istruzione x86(-64) viene "tradotta" in una Direct Path, Direct Path Double e Vector Path.
DirectPath e Direct Path Double sono eseguite direttamente (senza microcodice, ripeto) dall'unità RISC86, e differiscono solamente nei vincoli posti dal RISC86 per la loro esecuzione.
Le istruzioni classificate come Vector Path non sono, invece, traslate in istruzioni RISC86, ma passate all'unità di esecuzione dedicata che fa uso di una nanorom per eseguire il microcodice ad esse relativo.

LA CASISTICA

E' bene precisare che

- la maggioranza delle istruzioni x86(-64) viene convertita in Direct Path, e aggiungendo quelle Direct Path Double arrivano a superare il 75%; le rimanenti fanno parte dell'insieme di istruzioni Vector Path;

- la stragrande maggioranza delle istruzioni di tipo Vector Path è di tipo "legacy", quindi generalmente non più utilizzata.

Da ciò si deduce che il codice è costituito quasi esclusivamente da istruzioni di tipo Direct Path e Direct Path Double. Per essere precisi: da un po' di anni a questa parte, i compilatori producono codice che non fanno uso di istruzioni Vector Path, a meno che non ritengono che il loro uso non possa effettivamente comportare dei vantaggi (es: si intende compilare tenendo d'occhio la dimensione del codice piuttosto che la velocità. Oppure il "workaround" per "emulare" il funzionamento di un'istruzione Vector Path sarebbe più lento della sua esecuzione). Codice più vecchio presenta chiaramente istruzioni di tipo Vector Path, ma comunque non in grosse quantità. Per inciso: possiamo trovare roba come REPNE SCASB :D, PUSHA, ecc., ma difficilmente troveremo una AAA, DAA, ecc.


Rispondendo in generale alla tua domanda:

PRINCIPALI VANTAGGI DELL'ARCHITETTURA x86-64 RISPETTO a x86:

- 16 registri general purpose (anziché 8)
- 16 registri SSE/SSE2 (anziché 8)
- nuova modalità d'indirizzamento relativa al PC
- presenza del solo modello di paginazione della memoria (non c'è più la segmentazione).
- modalità NO EXECUTE per le pagine
- molte più istruzioni x86 vengono convertite in Direct Path o Direct Path Double (riducendo quindi il numero di istruzioni Vector Path)
- controller della memoria integrato (minori latenze d'accesso)
- controller HyperTransport per la comunicazione coerente e non con altri processori o con dispositivi di I/O (permette di costruire sistemi fino a 8 vie senza chipset dedicato per l'arbitraggio delle risorse).

Qualcosa mi può essere sfuggito, comunque dovrebbe bastarti.

x xeal: LOL. :D

Hmmm...

il no execute è disponibile ance in 32 bit, e il controller integrato e l'HT sono pecurialità Hardware che vanno sempre.
Io li toglierei e ci aggiungerei il supporto NUMA epr il multi-processor, ad esempio.

adesso cominciamo in parte a ragionare.....

Originariamente inviato da homero
adesso cominciamo in parte a ragionare.....
Eh, finalmente si ragiona!
...ridicendo per la 1000+1 esima volta le stesse cose emerse in thread precedenti... Mah...

Originariamente inviato da leoneazzurro
il no execute è disponibile ance in 32 bit, e il controller integrato e l'HT sono pecurialità Hardware che vanno sempre.

Si, è vero, però stiamo sempre parlando dell'architettura degli Hammer, che è appunto x86-64 nel suo insieme, quindi in un discorso di carattere generale sulla nuova architettura di questo processore non conviene distinguere tra caratteristiche in modalità 32 bit e caratteristiche 64-bit (esclusive queste ultime), in fondo potremmo considerare le funzionalità 32 bit come una retrocompatibilità "perfetta", anche se è quello il progetto di base e la totale compatibilità nativa sia con i 32 bit, sia con i 64, può portare a voler distinguere tra le caratteristiche "generali", che "vanno" in tutte le modalità, e quelle "specifiche" dell'esecuzione di codice a 64 bit: dipende dal tipo di discorso che si fa. In questo caso, IMHO, è meglio (come ha fatto Cesare) considerare l'architettura nel suo complesso per poterne meglio evidenziare i punti di forza, anche perchè queste due (non execute bit e memory controller integrato) sono peculiari di questa architettura e la distinguono dalle precendenti (nel "mondo" degli x86) ;)

Ciao

l'ultima parte vale anche per hyper transport, ovviamente

Originariamente inviato da xeal
Ma potrebbe esserci anche una quarta ipotesi: se il numero delle pagine da leggere è maggiore o uguale a 20 vuol essere pagato :asd:

:rotfl: ( dov'è la faccina che piange dal ridere? :D)


oppure ci potrebbe essere un'altra ipotesi...e cioè che soffra di un'amnesia talmente grave da non ricordarsi cosa tutto ciò che ha letto prima di oggi, come il protagonista di Memento insomma :wtf:

:asd:








Originariamente inviato da homero
adesso cominciamo in parte a ragionare.....

:eek:


Ma http://d1obrando.altervista.org/Faccine/malol.gif

Originariamente inviato da cdimauro
possiamo trovare roba come REPNE SCASB

Mi sa che a qualcuno ronzeranno le orecchie, e magari si offenderà anche (perchè come tutte le donne amerà sentirsi dire che è unica e inimitabile, non che in giro "possiamo trovare roba" simile :D :D :D)
Qualcosa mi può essere sfuggito

Originariamente inviato da leoneazzurro
aggiungerei il supporto NUMA

Il NUMA!!!! Hai dimenticato il NUMA!!!
Meno male che l'ultima lettera è una 'A' e non una 'E' o una 'I' oppure ti vedevi arrivare Zeus incavolato nero con tutta la compagnia, e ti costringevano a mangiare i 4 salti in pad**** per l'eternità!!!!

Ci sono state anche migliorie realtive alla latenza delle moltiplicazioni intere a 32 bit... Le moltiplicazini intere a 64 bit hanno la stessa latenza di quelle a 32 bit nel K7...

Originariamente inviato da DioBrando
dov'è la faccina che piange dal ridere?:D

Non ti eri accorto di averla già messa, o mi prendi un po' in giro :D? No, perchè un po' di tempo fa rompevo un po' le scatole chiedendo di alcune faccine (questa e sofico, in particolare), senza accorgermi di usarle qualche volta in maniera del tutto casuale. Il fatto è che a volte (almeno a me capita) le animazioni degli smilies non vengono visualizzate, forse per problemi momentanei del forum, o non so cos'altro :D

P.S. Il LOL che hai aggiunto dove lo hai pescato? :D

Ciao :)

Originariamente inviato da xeal
Si, è vero, però stiamo sempre parlando dell'architettura degli Hammer, che è appunto x86-64 nel suo insieme, quindi in un discorso di carattere generale sulla nuova architettura di questo processore non conviene distinguere tra caratteristiche in modalità 32 bit e caratteristiche 64-bit (esclusive queste ultime), in fondo potremmo considerare le funzionalità 32 bit come una retrocompatibilità "perfetta", anche se è quello il progetto di base e la totale compatibilità nativa sia con i 32 bit, sia con i 64, può portare a voler distinguere tra le caratteristiche "generali", che "vanno" in tutte le modalità, e quelle "specifiche" dell'esecuzione di codice a 64 bit: dipende dal tipo di discorso che si fa. In questo caso, IMHO, è meglio (come ha fatto Cesare) considerare l'architettura nel suo complesso per poterne meglio evidenziare i punti di forza, anche perchè queste due (non execute bit e memory controller integrato) sono peculiari di questa architettura e la distinguono dalle precendenti (nel "mondo" degli x86) ;)

Ciao

l'ultima parte vale anche per hyper transport, ovviamente

Era solo per ovviare alle (prevedibili) reazioni di homero, si stava parlando di architettura e x86-64 più dal punto di vista di ciò che ci si può aspettare in termini di miglioramenti dei programmi passando dall'ambiente 32 a quello a 64 bit, anzichè passando da Athlon XP a Athlon 64 (visto che HT e controller integrato funzionano in entrambi gli ambienti).

Per quanto riguarda il NUMA, che ho detto di strano?

:confused:

Originariamente inviato da cionci
Ci sono state anche migliorie realtive alla latenza delle moltiplicazioni intere a 32 bit... Le moltiplicazini intere a 64 bit hanno la stessa latenza di quelle a 32 bit nel K7...

Questo mi era sfuggito. Insomma, hanno migliorato praticamente tutto :)

Originariamente inviato da leoneazzurro
Per quanto riguarda il NUMA, che ho detto di strano?

:confused:

Niente! Scherzavo solo sul fatto che Cesare l'aveva tralasciato e sul fatto che la parola assomiglia a "numi", dei, e mi è tornata in mente la pubblicità con Giove che cucinava da dio... :D

Ah, OK :)

Originariamente inviato da homero
adesso cominciamo in parte a ragionare.....

Scusa, che intendi dire con "in parte"? Vuoi dire che le argomentazioni cominciano a sembrarti complete e convincenti (o almeno ragionevoli), oppure ti riferisci al fatto che, comunque, le istruzioni, anche se non eseguite mediante microcode, potrebbero essere decodificate e tradotte "on the fly" con l'intervento dell'esecuzione? In questo caso, onestamente devo dire che non ho approfondito su questi dettagli, però non credo che sia così: in fondo, le istruzioni (la maggioranza) da far eseguire direttamente all'unità RISC86 sono stabilite a priori (e sicuramente ne è stato studiato l'ordine d'esecuzione più rapido), quindi è sicuramente possibile implementarne la traduzione direttamente nella logica che effettua la decodifica. Poi interviene la logica out-of-order, ma si tratta di un lavoro di affinamento dell'ordine previsto a priori, per adattarlo alle necessità contingenti.

Originariamente inviato da xeal
Non ti eri accorto di averla già messa, o mi prendi un po' in giro :D? No, perchè un po' di tempo fa rompevo un po' le scatole chiedendo di alcune faccine (questa e sofico, in particolare), senza accorgermi di usarle qualche volta in maniera del tutto casuale. Il fatto è che a volte (almeno a me capita) le animazioni degli smilies non vengono visualizzate, forse per problemi momentanei del forum, o non so cos'altro :D

nono sn serio :D

è perchè un mio amico la usa sempre su MSN, solo se n sò se esista il corrispettivo anche come smily per i forums :)...di sicuro non è tra quelle attualmente disponibili

stasera ti lascio il link dell'img così capisci meglio cosa intendo ^^


P.S. Il LOL che hai aggiunto dove lo hai pescato? :D

viene da un forum di amici :D ( poi l'ho messo nel path della mia "pagina" su altervista per comodità :))...ma penso che scartabellando tra le varie raccolte di smilies in giro per la rete lo trovi, insieme a tanti altri tipo rotflmao ecc

:sofico:


Ciao :)

Saluti ;)






P.S.: azz ora ho capito perchè mi hai scritto se ti prendo in giro...n mi ero accorto delle lacrime del rotfl...:muro:

vabbè dai quello che intendo io è + ""plateale"..:D

Ok, hai fatto come me, che chiedevo in giro per questo forum quale fosse lo smiley col "pescione" che si ingrandisce e non mie ero accorto di averlo già usato in precedenza :asd:. Però quando è successo io non riuscivo proprio a veder muovere gli smiley :D

Alla prossima per la faccina "plateale" :D

Originariamente inviato da homero
adesso cominciamo in parte a ragionare.....
Beh, diciamo che "il caso è chiuso": non vedo di cos'altro si dovrebbe parlare. Hai ricevuto TUTTE le informazioni necessarie. ;)

Originariamente inviato da xeal
Mi sa che a qualcuno ronzeranno le orecchie, e magari si offenderà anche (perchè come tutte le donne amerà sentirsi dire che è unica e inimitabile, non che in giro "possiamo trovare roba" simile :D :D :D)
Beh, ma lei E' unica: dove la trovi una con una competenza come la sua? ;)
La citazione, anzi, è un omaggio a cotanta sapienza. :)
Il NUMA!!!! Hai dimenticato il NUMA!!!
Meno male che l'ultima lettera è una 'A' e non una 'E' o una 'I' oppure ti vedevi arrivare Zeus incavolato nero con tutta la compagnia, e ti costringevano a mangiare i 4 salti in pad**** per l'eternità!!!!
SGORGLE. Così mi fate ribaltare sul posto di lavoro, di prima mattina. :D

Comunque, hai centrato: ho aggiunto NX, memory controller e HT nel discorso perché volevo proprio rimarcare le differenze fra K8 e K7. E' tutta l'architettura che è vincente, e utilizzarla solamente nell'ambiente a 32 bit, sebbene offra comunque delle ottime prestazioni, non le rende giustizia e merito.

Originariamente inviato da cionci
Ci sono state anche migliorie realtive alla latenza delle moltiplicazioni intere a 32 bit... Le moltiplicazini intere a 64 bit hanno la stessa latenza di quelle a 32 bit nel K7...
Hai ragione: l'avevo dimenticato. :p Esegue moltiplicazioni 64x64 -> 128 bit con una latenza di soli 3 cicli di clock: semplicemente mostruoso. Le applicazioni di crittografia e di database (che usano il tipo di dati Currency) ci vanno a nozze. :D

Quasi dimenticavo. Il NUMA m'è sfuggito, ma era insito nel discorso: parlando di memory controller separato e di bus HT dedicato alla scambio di dati con altri processori, è chiaro che l'unica cosa sensata che possono scambiarsi dei processori collegati fra di loro sono i dati della loro memoria locale (o i dati di I/O, per il processore che si occupa dell'interfaccia con le periferiche. ;))

Originariamente inviato da cdimauro
Hai ragione: l'avevo dimenticato. :p Esegue moltiplicazioni 64x64 -> 128 bit con una latenza di soli 3 cicli di clock: semplicemente mostruoso. Le applicazioni di crittografia e di database (che usano il tipo di dati Currency) ci vanno a nozze. :D
La latenza delle moltiplicazioni a 64 bit è 4 ;) Quella dele moltiplicazioni a 32 bit è 3...

Originariamente inviato da cdimauro
Beh, ma lei E' unica:

Concordo in pieno :)

dove la trovi una con una competenza come la sua?

Ma su hwupgrade, a discutere con noi altri, dove se no?! :D

Così mi fate ribaltare sul posto di lavoro, di prima mattina.

LOL :D

Originariamente inviato da cionci
La latenza delle moltiplicazioni a 64 bit è 4 ;) Quella dele moltiplicazioni a 32 bit è 3...
Hai ragione: piccolo lapsus. :p

Questo: pushfd
pop ebx
shr ebx,0Bh
sbb ebx,ebx
lea ebx,[ebx * 4]
or ecx,ecx
je label_001
label_002:
cmp eax,es: dword [di]
lea edi,[ebx + edi]
je label_001
sub ecx,1
jne label_002
label_001:
O questo: pushfd
pop ebx
shr ebx,0Bh
sbb ebx,ebx
or ecx,ecx
je label_001
label_002:
cmp al,es: byte [di]
lea edi,[ebx + edi]
je label_001
sub ecx,1
jne label_002
label_001:

Cosa preferisci? :p

Originariamente inviato da cdimauro


SGORGLE. Così mi fate ribaltare sul posto di lavoro, di prima mattina. :D
.

Segnalato :O

Utilizzo improprio di strumenti aziendali sul posto di lavoro :O



:D

Azz. E' da nemmeno un mese che lavoro e mi devi già far buttare fuori? :cry: :D

OK, visto che anch'io avevo sbagliato, aggiusto la mia:
pushfd
pop ebx
mov edx,1
shr ebx,0Bh
sbb ebx,ebx
cmovnc ebx,edx
or ecx,ecx
je label_001
label_002:
cmp al,es: byte [di]
lea edi,[ebx + edi]
je label_001
sub ecx,edx
jne label_002
label_001:

Originariamente inviato da cdimauro
Esattamente. E dicevano che WOW64 andava male: una cosa assurda. Proprio la bontà di WOW64 era quella che, alle alte risoluzioni, copriva tutti i problemi legati ai driver a 64 bit immaturi e mostrava addirittura un frame rate più elevato rispetto alla controparte a 32 bit.

Giaaaanniiiii! Ma come non si fa a vedere delle cose macroscopiche come queste!!! :D

eh già i driver immaturi
per te all'uscità sti benedetti driver saranno abbastanza maturi?
o magari anche per allora questa sarà una scusa già bella pronta e confezionata?
fossi in te prima di partire lancia in resta aspetterei di vedere che risposte darà questo windows 64 senza dare responsi e perseguire nelle proprie teorie che fino alla prova pratica e senza entrare nel merito andranno dimostrate da riscontri effettivi
sino ad allora non saranno altro che opinabili teorie......

Originariamente inviato da homero
ancora con sti 64bit???
uffa ma la gente e' dura a convincersi.....
oramai mi sono rassegnato......
avro' scritto 1 milione di volte che e' soltanto una implementazione su microcode e che non cambia nulla, ma qua tutti ad aspettare....cosa poi non lo capisce nessuno.....
il pci-X e' la migliore e piu' grande innovazione disponibile sui nostri pc e noi pensiamo ai 64bit.....
bho....
io ho un giga di ram e non riesco a riempirlo ne' con doom3 e ne' con photoshop lavorando a risoluzioni assurde da 8000x8000...
mentre comprare un raid mi ha velocizzato parecchio adesso ci servono 8giga di ram?!?!?
ma....
insomma piu' sono inutili le cose e piu' questi ci tornano sopra....
quanto ci saranno processori "veri" che non siano x86 ne riparliamo per il momento tenetevi il vostro bel XP-32bit che va tanto bene con un bel P4 northwood @3.6ghz

in questo forum molti sono specializzati nel formulare teorie sull'inutile e il superfluo :D
è un attittudine in cui molti si cimentano, un vero e proprio vezzo
non riescono a sfruttare i processori odierni e già vagheggiano di dual core e compagnia bella
ti dicono che MS è una sprca monopolista e tutti ad aspettare l'inutile win64 così avranno nel pc un bel dual boot uno con win32 e un altro con win64 per fare le medesime cose (anzi non le medesime, all'inizio win64 partirà menomato anzi castrato per la minor offerta di programmi a 64bit e loro faranno girare programmi a 32 con perdita seppur lieve di prestazioni)
ti diranno che con win64 potrai montare oltre un 4 di ram, ma schede madri che possano montare oltre 4 giga della suddetta ram per computer desktop chissà quando si vedranno, e la loro utilità rimane un mistero (sempre in ambito desktop, invece in ambito server gli oltre 4 giga di ram avranno una loro ragione)
diranno insomma tutte queste belle cose per non dire nella sostanza niente, lo faranno per vezzo, è un copione già scritto :D

Originariamente inviato da von Clausewitz
eh già i driver immaturi
per te all'uscità sti benedetti driver saranno abbastanza maturi?
Lo spero. Chiaramente tu che sei dotato di una bella sfera di cristallo ne saprai più di me...
o magari anche per allora questa sarà una scusa già bella pronta e confezionata?
Che i driver siano ancora immaturi è stato ampiamente dimostrato.
fossi in te prima di partire lancia in resta aspetterei di vedere che risposte darà questo windows 64 senza dare responsi e perseguire nelle proprie teorie che fino alla prova pratica
Veramente le cose che sono state dette derivano proprio dalle prove pratiche che sono state finora effettuate.
e senza entrare nel merito andranno dimostrate da riscontri effettivi
sino ad allora non saranno altro che opinabili teorie......
Vedi sopra: qui finora abbiamo parlato di prove pratiche. Windows XP/64 è stato testato da parecchi "riviste" del settore, e gli articoli con benchmark e tutto il resto non sono stati scritti in base a un foglio di carta che è stato recapitato da Microsoft, ma sun prodotto che tra l'altro chiunque può scaricarsi dal suo sito.
Le teorie le vedi soltanto tu...

Originariamente inviato da von Clausewitz
in questo forum molti sono specializzati nel formulare teorie sull'inutile e il superfluo :D
è un attittudine in cui molti si cimentano, un vero e proprio vezzo
E' l'LSD che ti fa quest'effetto o sei proprio così di natura? Perché soltanto un visionario può permettersi certe sparate...
non riescono a sfruttare i processori odierni e già vagheggiano di dual core e compagnia bella
Si tratta di una realtà che arriverà a breve. Poi, per chi è abituato ad avere la testa fra le nuvole, si tratterà sempre di favole...
ti dicono che MS è una sprca monopolista
E questo chi lo dice? Certamente non chi ha comprato una regolare licenza di Windows o chi preferisce altri s.o...
e tutti ad aspettare l'inutile win64 così avranno nel pc un bel dual boot uno con win32 e un altro con win64 per fare le medesime cose
Basterà soltanto il secondo.
(anzi non le medesime, all'inizio win64 partirà menomato anzi castrato per la minor offerta di programmi a 64bit
Non penso che MS tiri fuori un s.o. senza un parco di applicazioni: senza software nessuno avrebbe interesse a comprarlo.
e loro faranno girare programmi a 32 con perdita seppur lieve di prestazioni)
Lieve in alcuni casi, ma con vantaggi anche grandi in altri...
ti diranno che con win64 potrai montare oltre un 4 di ram,
Dipende dalla piastra madre, mica dal s.o.: sono poche quelle che permettono di montare più di 4GB. Già con s.o. a 32 bit è possibile indirizzare fino a 64GB tramite PAE, ma è un meccanismo complicato e che fa perdere tempo, per cui non viene utilizzato...
ma schede madri che possano montare oltre 4 giga della suddetta ram per computer desktop chissà quando si vedranno,
Non sono ancora tante, ma a breve diventeranno comuni.
e la loro utilità rimane un mistero (sempre in ambito desktop, invece in ambito server gli oltre 4 giga di ram avranno una loro ragione)
E' chiaro che per il momento è il settore dove servono di più. Ma certamente anche in ambito desktop, per chi fa grafica i 4GB possono rappresentare un limite consistente...
diranno insomma tutte queste belle cose per non dire nella sostanza niente, lo faranno per vezzo, è un copione già scritto :D
Il problema è che dei 64 bit tu vedi soltanto il maggior indirizzamento della memoria. In pratica quello che spaccia Intel per le "sue" estensioni EMT64. ;) In realtà l'architettura x86-64 DI AMD offre ben altro, e i risultati si vedono...
Poi è chiaro che ci sarà sempre gente che certe cose non le vorrà vedere a priori, ma qui metto le mani avanti...

x von Clausewitz

driver
Perchè secondo te la maturità dei driver non è un problema reale e tangibile anche a 32 bit? I driver non vengono costantemente ottimizzati per migliorare le prestazioni di TUTTO? Ne sono un esempio il rilascio continuo di driver per le schede video, al fine di guadagnare anche solo una manciata di fps (al di là della "guerra" commerciale, l'ottimizzazione costante è comunque un'esigenza). I driver devono essere SEMPRE ottimizzati, e incidono SEMPRE sulle prestazioni di TUTTO il sistema, non si possono MAI considerare veramente "maturi" nel senso di "perfetti", "definitivi". Semmai, bisognerà vedere se saranno "sufficientemente" maturi al debutto, ma in ogni caso il problema dell'ottimizzazione si porrà comunque. Poi, col tempo, come per tutte le cose, la migrazione ai 64 bit farà si che il lavoro di ottimizzazione maggiore si sposterà sui driver a 64 bit. Se proprio vuoi farmelo dire, si, la scusa è pronta, perchè non ci sono altre possibili cause per un rallentamento sensibile delle applicazioni a 32 bit operando a 64 bit, visto che l'os è praticamente lo stesso e operare a 64 bit introduce dei vantaggi.

innovazione

E' chiaro che si tratta di una tecnologia innovativa e che non ha ancora impieghi effettivi, al di là dei vantaggi (memory controller,...) che si ripercuotono anche sulla modalità 32bit nativa. Tuttavia, si tratta di una tecnologia molto probabilmente destinata a diventare lo standard futuro, quindi è meglio che cominci a diffondersi in maniera "indolore", senza costi eccessivi e con una totale compatibilità con i 32 bit. Oppure preferiresti uno scenario in cui prima arrivino in massa le applicazioni a 64 bit e poi i processori, così saresti costretto a migrare e a sborsare uno sproposito (ti ricordo che questa tecnologia la implementa anche Intel, quindi il futuro di questa architettura è molto più che teoria o ipotesi)?
Poi sei andato a quotare il post di homero con le sparate sul microcode...

x repne scasb

Vorrei chiarirmi un dubbio: i vantaggi che hai riscontrato nel tuo test "su strada" relativamente ai salti non allineati e alla sequenza delle istruzioni riguardano solo applicazioni a 64 bit, o pensi che potrebbero incidere anche su quelle a 32 bit fatte girare da un modulo a 64 bit nativo in Ring 0 (ovvero con os a 64 bit che le "emula")?

Ciao :)

x repne scasb

Ok, grazie lo stesso :)

Lo rispettarono l'impegno... si si :D

Quale? Il thread è un po' vecchiotto... :p