Eerste blik op 64-bit gameprestaties met AMD64 Far Cry

Begin deze week heeft Crytek in samenwerking met AMD een patch uitgebracht voor Far Cry waarmee het spel in 64-bit mode kan draaien. Bij AnandTech is een kort artikel geplaatst waarin de prestaties van de 64-bit variant van het spel vergeleken worden met de 32-bit versie. Het blijkt dat het spel niet veel profiteert van de extra bits die beschikbaar zijn. Op 1024x768 met de “very high quality settings” is het spel op het AMD-platform 4 procent sneller en op het Intel-platform wordt een winst van 6,5 procent geboekt. Grote prestatiewinsten zullen gamers dus niet hoeven te verwachten met de overstap naar 64-bit.

Reacties (97)

[Verwijderd]

Grote prestatiewinsten zullen gamers dus niet hoeven te verwachten met de overstap naar 64-bit.

Is dat niet wat kort door de bocht, zo'n oordeel basseren op één enkele benchmark met één enkel spel? Daarbij, het is gebeurd door een patch, wordt daardoor het hele spel meteen 100% 64-bit?

//edit meer mensen met dat idee

[wzzrd]

Iets is óf 32-bit, óf 64-bit code. Een tussenweg bestaat niet. Je kunt een 64-bits binary niet linken tegen 32-bits libraries, en een 64-bits library is onbruikbaar voor een 32-bits binary. Je kunt een 32-bits programma wel draaien in een 64-bits omgeving, mits er geen 64-bits bibliotheken gebruikt hoeven worden. Dan moet er een compatibility layer gebruikt worden, door extra 32-bits libs te installeren.

Hoe ze het hebben gedaan, weet ik ook niet, en ik vraag me af hoe groot die patch is, maar 64-bit is 64-bit.

Of zit ik er nou helemaal naast

[arjankoole]

Of zit ik er nou helemaal naast

nee. Een 64bit kernel module kan bijvoorbeeld geen 32 bit module pakken. Een leuk voorbeeld kwam ik pas tegen met ndiswrapper onder Linux.

m'n zwager heeft pas een laptop gekocht met een amd64 d'r in, en hij wilde onder linux ook graag de broadcom wireless gebruiken. De standaard broadcom drivers (van windows) die ik onder linux gebruik werkten niet, omdat z'n ndiswrapper 64 bit is, in een 64 bit kernel. Toen we de 64bit windows drivers hadden gevonden van broadcom werkte het echter direct.

[wibra]

je zit er naast
als je een simpel programmatje zou schrijven dat geluidsbestandjes van mp3 naar wav zou omzetten. dan zal je in- en output niet verschillen of je het nu met een 64 of 32 compiler hebt gemaakt.

idem voor textures die op uw scherm moeten komen. een texture is een texture. de uitdrukking "aantal bits" bij die texture zou enkel slaan op de kleurendiepte, niet op een of andere cpu-parameter.

[Jeroen V]

Dat hangt er helemaal vanaf hoe ze dat spel hebben geprogrammeerd, dat kan je zo helemaal niet zeggen. Maar aangezien er vrijwel niet meer in assembly wordt geprogrammeerd is het vrij eenvoudig om het spel snel en volledig om te zetten naar een 64 bits platform.

Maar ik heb het idee dat vrijwel iedereen denkt dat een 64 bits programma per definitie sneller is dan hetzelfde programma dat gecompileerd is door een 32 bits compiler, en dat is helemaal niet zo.

Er zijn simpel gezegd twee grote verschillen tussen een 64 en een 32 bits omgeving. Ten eerste kan je meer dan de bekende 4GB geheugen addresseren, maar dat is voor een spel als FarCry totaal niet boeiend, die 4GB is meer dan zat.

Ten tweede is er voordeel te behalen als je een dusdanig grote nauwkeurigheid nodig hebt dat je dat niet kwijtkan in een 32 bits getal. Een willekeurig programma kan prima met 64 bits getallen omgaan, alleen zal de compiler en/of processor behoorlijk wat moeten doen om dat werkend te krijgen. Simpel gezegd, eerst de lower 32 bits in de registers laden, verwerken, rekening houden met eventuele overloads, higher 32 bits laden, eventuele overload weer verwerken, en uiteindelijk heb je dan je resultaat. Bij een 64 bit processor is dat helemaal niet nodig en wordt de bewerking direct gedaan. In dit geval kan je enorm veel prestatie winst halen indien alles (platform en processor) direct de 64 bits ondersteunen. En ook hier denk ik dat FarCry dat niet zal doen, en dus ook geen meter sneller zal worden.....

[Verwijderd]

Dus je weet het wel......

Prima uitleg, alhoewel je vergat erbij te vertellen dat een van die berekening types niet precieser werd gedaan met AMD64, of het nu ALU of FPU was, ik ben het vergeten, ik hoop niet FPU, das de meest gebruikte voor spellen. Zolang een spel niet tegen de limiet van de preciesie aan zit, heeft het geen enkel effect.

En nee, het heeft erg ERG weinig betrekking op viewdistance, en ook weinig op textures, en zover ik weet ook weinig betrekking op maps.

[brada]

Lijkt me sterk dat je met één patch een heel spel kan veranderen naar 64-bits. Om dat te doen moet toch bijna het hele spel worden overgeschreven.?

[MacWolf]

Volgens mij is er bij games sowieso niet veel winst te halen door naar 64-bit te gaan.

Ik denk dat de enige winst die een spel kan hebben door naar 64-bit te gaan, is dat meer geheugen kan worden gebruikt. Maar welk spel is op de markt dat op dit moment 2 GB nodig heeft? Volgens mij zijn die nog niet te vinden en dat zal de komende jaren niet drastisch veranderen.

Andere voordelen van een 64-bits processor zijn m.i. voor spellen niet relevant (zoals bijv. de mogelijkheid om grotere variablen te gebruiken, etc...)

[The - DDD]

Leukste nadeel van 64bit. Alle gangbare datatype worden twee keer zo groot. Zonder optimalisatie betekend dit dat er standaard twee keer zoveel data heen en weer gepompt moet worden tussen de CPU en het geheugen.

En helaas, de bandbreedte tussen de CPU en het geheugen is nou eenmaal de grootste bottleneck in de huidige PC architectuur. Dat probleem wordt alleen maar groter.

't Is niet voor niets dat grafische kaarten achterlijk veel onboard geheugen krijgen. Gewoon de bottleneck omzeilen.

[froggie]

Ik dacht dat volgens de specificaties alleen de types long en double 64bit zijn op 64bit CPU's. Alle overige types behouden hun gewone aantal bits.

[Jeroen V]

Ik denk niet dat dat echt een heel erg groot nadeel is. Je hebt uiteraard helemaal gelijk dat er twee keer zoveel data verplaatst moet worden, alleen is de hoeveelheid data waar je het over hebt niet echt groot in tegenstelling tot bijvoorbeeld de textures. Wat verder nog wel redelijk wat ruimte inneemt zijn de maps, maar je kan je afvragen of die omgezet zijn naar 64 bit. (ik kan het me namelijk bijna niet voorstellen)

[Verwijderd]

Geheugen adressen zijn nog altijd geen 64 maar 48bits. Das dus niet 2 keer zo groot, iets waardoor het er dus op lijkt dat je niet weet waar je het over hebt.

Als je je pointers met 48bits in het geheugen zet heb je 2 nadelen:

Het alligned niet als je 64bits accesses doet.
Je moet duidelijk afspreken voor je binary format dat de pointers 48bits zijn, anders gaat je CPU later meer bits inladen als wel de volledige 64bits gebruikt worden.

Het is inderdaad zo dat op de vele zogenaamde 64bits architecturen voor de desktop (AMD64, Intel, en de IBM G5) geen enkele de volledige 64bits voor adressering gebruikt. Ik dacht dat de G5 zelfs maar 42bits deed. Echter in iniedergeval MSVC (cl.exe) en de Intel compiler (icl.exe) alsmede gcc, zijn 64bits pointers wel degelijk 64bits in het geheugen en zeker niet 48bits.

Merk op dat het aantal bits dat een compiler gebruikt voor een pointer voor een bepaalde target architectuur implementation specific is. Voor dezelfde CPU zou gcc het anders kunnen doen dan cl.exe. Alleen voor de Itanium is een zogenaamde ABI afgesproken.

Zie: http://www.intel.com/design/itanium/downloads/24537003.pdf

En dan sectie 3.2.1 voor de types. Het C long long type (C++ heeft nog geen officieel 64bits type) is daar 8 bytes (64 bits dus).

[Jeroen V]

@Arro: klopt, maar er is natuurlijk meer dan alleen de data die je zelf gedefinieerd hebt in je programma. Als je een simpele opdracht geeft waarbij twee getallen van 32 bits van elkaar moeten worden afgetrokken, dan zal de compiler code genereren waarbij eerst de getallen in de registers worden geladen, en de geheugenadressen zijn bijvoorbeeld al twee keer zo groot geworden. (Hetzelfde zou kunnen gelden voor opcodes, maar dat weet ik voor het AMD64 platform niet.)

[LeX-333]

Leukste nadeel van 64bit. Alle gangbare datatype worden twee keer zo groot.

Niet helemaal waar, ook native 64-bits code gebruikt 32-bits ints, zoals in de documentatie van GCC te zien is:

The 32-bit environment sets int, long and pointer to 32 bits and generates code that runs on any i386 system. The 64-bit environment sets int to 32 bits and long and pointer to 64 bits and generates code for AMD's x86-64 architecture.

Ook in de documentatie van de Microsoft compiler staat iets soortgelijks. De gewone variabelen blijven dus 32 bits en alleen als er expliciet om gevraagd wordt, worden ze breder. Zelfs al zou de processor intern een 64-bits bewerking doen, levert dit nog geen direct performace verlies omdat de geheugen fetches 32-bits blijven. Natuurlijk geldt dat nadeel wel voor pointers, maar dat is marginaal en heeft aan de andere kant natuurlijk veel voordelen zoals een grotere addresserruimte.

Een 64-bits procesor biedt natuurlijk niet direct betere performance in games, zeker niet als de game in eerste instantie voor een 32 bits processor gemaakt is. Echter de beschikbare (snel) addresseerbare geheugenruimte voor een programma onder Windows is 2 Gigabyte (tenzij je gaat prutsen), deze grens zal voor werkstations waarschijnlijk als eerste door games verbroken worden, dan is 64 bits al snel een "must have".

[Verwijderd]

Klopt, maar een 64-bits cpu moet elke clockcycle een twee keer zo grote dataset gebruiken. Vergelijk het met een veerpont die 32 auto's over kan zetten elke cycle en 1 die dat met 64 doet. De meeste tijd is de kleine bezig met minder dan 32 auto's, meestal zelfs veel minder. (Denk maar aan de vormen van data die in programmeertalen het meest voorkomen, strings, datawords e.d.).

Nu heeft men echter een nieuwe, grotere veerpont ontwikkeld die dus 64 auto' s in 1 klap over kan zetten. Dat is leuk voor tijdens de spits, maar tussendoor vreet dat ding alleen maar extra energie om zichzelf voort te slepen.

Maw: Een 64-bits processor is leuk voor hele grote datasets, maar is op z'n best niet sneller bij kleine. En de meest datasets zijn nog steeds 32-bits.

[NoepZor]

Maar de CPU kan nu berekeningen die normaal opgesplitst worden uitvoeren in 1 clockcycle waardoor het sneller is ? Ergens moeten die 64-bits voordelen opwegen tegen de nadelen, anders was het echt niet sneller

[Verwijderd]

@NoepZor

Voor wetenschappenlijk toepassingen heeft het zeker zin. Afhankelijk van watvoor toepassing heeft een dual-core wel of geen zin. Maar 64 bits heeft voor "Computational Science" zeker zin. Ik ben zelf ook aan t wachten op een Matlab die van grond af aan gemaakt is in 64 bit.

[Verwijderd]

@Jeroen V

Maps omzetten naar 64bit? Denk je dat dat er ook maar iets mee te maken heeft?

[Verwijderd]

Daar sla je de plank mis met de meest gemaakte fout van dit moment !!!

Als je meer dan 4 Gb geheugen gebruiken wilt onder steund XP dat niet. Simpel omdat alle adresse dan in gebruik zijn ! Maar Windows XP x64 ondersteund wel meer dan 4 Gb geheugen maar 4 Gb geheugen is niet noodzakelijk om van 64 bit gebruik te maken.
Dat heeft niks met elkaar te maken.

Dus ook Farcry kan met behulp van de patch om gecompileerd worden en veel toevoegen los van het feit of je nu 512, 1gb of meer geheugen gebruikt in je Computer.

Dankzij 64 bits instructies kan er gewoon weg meer data verplaatst en/of geladen worden in de zelfde tijd.
Heb Farcry geinstalleerd onder XP incl. Patch. en zie dat er meer gewerkt is met grotere textures en het gehaal erg veel mooier is geworden. Jammer dan ook dat er enkel gekeken wordt naar een eventuwelen snelheids verschil tussen 32 en 64 bits versie van het spel.
Terwijl ze van Crytek zo hun aandacht hebben gevestigt aan het uiterlijk van de game. Het is een goede test om al een beetje de nieuwe mogelijkheden te laten zien vindt ik.

[Astennu]

Dit hebben ze ook gedaan. Ze hebben duidelijk laten zien dat onder de 64 bit versie alles er stukken mooier uit ziet.

dus ik denk als de beelden gelijk waren aan de 32 Bit versie dan je dan veel meer prestatie verschil had gezien dan nu. Ik heb het een hele grote verbetering.

Ik zou zeggen open de link naar anadtech

[thettes]

Volgensmij is de reden dat het niet extreem verbetert (naast de nieuwe bump maps etc) dat de drivers voor 64 bit verre van optimaal draaien. Zeker in 64 bit modus.

[DEXSTAR]

Sorrie geen winst te halen ? Als een Datapad echt breed genoeg was dan zou, je alles in klokslag kunnen doen. Voorlopig heeft de CPU nog meerdere klokslaggen voor bijna elke bewerking nodig. Is de dev. software ervoor voldoende geoptimaliseerd ? Nee, Zou het zin hebben ja lijkt me wel.

[loodgieter]

misschien niet met de 64-bit maar als er games uit gaan komen die multi core ondersteunen en 64-bit dan moet de winst toch aanzienlijk groeien ten opzichte van een single core (32-bit of 64-bit)

[Erycius]

Dat overschrijven doen ze dan ook: de patch is maar liefst 1.5 GB groot

EDIT: bron

[mvds]

Je vergeet dat het "hele spel" voor een groot deel de graphics zijn, oftewel de textures. En die veranderen niet of je nou een 8, 16, 32 of 1024 bits PC hebt. Alleen de engine van het spel is een executable en die moet 64 bits gemaakt worden. De rest blijft hetzelfde. Dat die patch 1,5GB is komt doordat ze verbeterde textures toegevoegd hebben en extra levels, dat heeft weinig te maken met 32-bits of 64-bits. Ze hadden die betere textures ook met de 32-bit versie mee kunnen leveren.

[PeterFortuin]

Nee, alleen de runbare code moet overschreven worden. Een spel bestaat natuurlijk uit veel meer dan alleen maar runbare code. Geluiden, textures, models, enz hoeven natuurlijk niet veranderd te worden als er overgegaan word naar 64-bit. Het zou dus best makkelijk in een enkele patch gestopt kunnen worden.
Of er echt 100% voor 64bit geoptimaliseerd is zet ik mijn vraagtekens bij. Maar dat zullen we wel zien bij toekomstige games.

[xerix]

Nee, in theorie hoef je alleen de source opnieuw te compilen met een compiler die 64bit's code uitpoept. Er zullen wel hier en daar optimalizaties zijn doorgevoerd. Mensen die denken dat het coden voor 64bit's platformen heeeeel anders is als coden voor 32bit's platformen, think again. Dit is absoluut niet zo, alleen de geoptimaliseerde assembly code zal herschreven moeten worden.
In tegenstelling tot wat veel mensen denken zijn de 64bit's instructies ook maar een toevoeging op de bestaande instructie set, met daarbij natuurlijk de extra registers. Simplistisch gesteld kan je het vergelijken met de SSE instructies, welke trouwens 128bit registers gebruiken..
Ik snap die hype rond 64bit ook niet, ja het is leuk dat men nu >4GB kan aanspreken maar verder.. de berekeningen zullen echt niet opeens velen malen sneller gaan.
Beetje jammer dat men altijd onwaarheden de wereld inspuid om de tegenvallende (AMD) resultaten te verklaren.
'Er is dan wel weinig prestatieverschil, maar hoe het er graphisch uit ziet is enorm omhoog gegaan...'
Totdat de videokaarten intern op 64bit's werken maakt het absoluut geen verschil in beeldkwaliteit. Ja misschien kunnen er wat details hoger worden gezet omdat deze sneller berekend kunnen worden met 64bit's instructies maar dit zet geen zoden aan de dijk.

[drahca]

>>Nee, in theorie hoef je alleen de source opnieuw te
>>compilen met een compiler die 64bit's code uitpoept.

In theorie.. helaas is de praktijk toch echt anders. C++ (waarin bijv. FarCry geschreven is) zegt niks over het aantal bits van de verschillende datatypen, het enige dat gegarandeerd wordt is bijv dat een int groter of gelijk is aan een short. Dit kan dus wel degelijk problemen opleveren bij het porten van 32-bits programmas naar 64 bit.

Ik snap die hype rond 64bit ook niet, ja het is leuk dat men nu >4GB kan aanspreken maar verder.. de berekeningen zullen echt niet opeens velen malen sneller gaan.

De x86 architectuur zit zo in elkaar dat er slecht 8 General Purpose registers beschikbaar zijn en ook slechts 8 Floating Point registers. x86-64 lost het probleem van de GP registers enigzins op door er 16 aan te bieden aan de compiler. Helaas is FarCry afhankelijk van de Floating Point prestaties van een processor en zullen de programmeurs SSE instructies gebruikt hebben (128-bit SIMD) en niet het verouderde x87 floating point instructieset. De 64-bit-heid van de AMD64 brengt dus bij voorhand al niet een enorme prestatiewinst, echter de extra registers kunnen dit wel doen maar waarschijnlijk voornamelijk bij programmas die afhankelijk zijn van integer code (denk aan encryptie bijv) of x87 FP code. Hierbij zal het verschil tussen de x86 en de x86-64 mode aanzienelijk kunnen zijn.

Conclusie: een benchmark van één spel zegt niks over de prestatiewinst die behaald kan worden met het nieuwe x86-64 instructieset.

[Verwijderd]

In theorie.. helaas is de praktijk toch echt anders. C++ (waarin bijv. FarCry geschreven is) zegt niks over het aantal bits van de verschillende datatypen, het enige dat gegarandeerd wordt is bijv dat een int groter of gelijk is aan een short. Dit kan dus wel degelijk problemen opleveren bij het porten van 32-bits programmas naar 64 bit.

Het is absoluut zo dat basic types in C++ alleen relatief gespecificeerd zijn. Je zou verwachten dat de standaard int dus mee zou groeien van 32 naar 64 bits. Dit was ten tijde van de 16 bit naar 32 bit overgang ook zo. Long zou dan 128 bits moeten worden (was immers 32 op 16 bits architecturen).

Alleen...

Het gebeurd niet! Niet via de C++98 ISO standaard, maar defacto zit de int in C++ vast op 32 bits. De compiler bouw community is maar een klein wereldje, en er is een soort van heren akkoord dat de int niet meer gaat veranderen zodat er dus opeens een apart groter type nodig is. In C (waar de types in de spec net zo goed relatief staan) achtte men het zelfs nodig om LongLong in te voeren.

In C++ is het nu nog allemaal compiler specific. int_64, int64, etc. De hele indeling van char, short, int, en long is er erg warrig door geworden. Er wordt voor de volgende revisie wel aan een standaard 64 bits type gewerkt, en dat zal dus niet de int worden. (die nieuwe revisie zal waarschijnlijk zo rond +-2009 komen)

[Munters]

Dit was ten tijde van de 16 bit naar 32 bit overgang ook zo.

Dat vind ik wel zo'n beetje de slechtste "reden".
C definieert datatypes inderdaad alleen relatief. Een "long" is bijvoorbeeld minimaal zo groot als een "int". (En ik geloof dat een "long" ook minimaal zo groot is als een pointer (type void*)). En een "int" is het "natuurlijke" formaat van de processor.

Daarom zou ik inderdaad een 64 bits int verwachten. En dan ook een 64 bits long.

*Maar dat wordt dus niet door de taal bepaald.* Een andere compiler kan best met 64 bits integers werken.

Dat LongLong type vind ik echt een grote fout. C had gewoon altijd al een int16, int32 en int64 (plus de rest natuurlijk) moeten bevatten, voor het geval je een vaste grootte nodig hebt in de programma.

[Verwijderd]

Om dat te doen moet toch bijna het hele spel worden overgeschreven.?

Er hoeft -bijna- niets te worden herschreven, de sourcecode opnieuw compileren met een compiler die de code optimaliseert voor 64 bits is genoeg.

[Munters]

Hercompileren is gewoon genoeg. Een programma kan ook gewoon met 32-bits waarden blijven werken, de "bovenste" bits blijven dan gewoon 0.
De waardes van een "integer" en een "long" en zo, zijn niet voor niks gedefinieerd als "kan minimaal waardes tot xxx bevatten".

De reden dat simpel compileren toch snelheidswinst kan opleveren is dat er bij de x86 in 64-bits mode extra registers zijn toegevoegd. Deze zijn helaas alleen beschikbaar in 64-bits mode.
Maar de marketing heeft zich op de 64-bits gestort, terwijl de "stiekeme" toevoeging van 8 extra registers voor de meeste programma's meer zin heeft.

Dus een programma die baat heeft bij meer interne registers zal profiteren van een hercompilatie.
Er is maar een beperkt aantal programma die baat heeft bij meer geheugenruimte (>3GB per proces op XP), of grotere getalwaardes.

Kort gezegd:
- meer geheugen eenvoudig aanspreken -> typisch iets waar grote databases van profiteren
- 64-bits reken-registers -> typisch iets voor grotere rekenprogramma's, of discrete foto-filters.
- meer interne registers -> de meeste programma's.

[Verwijderd]

Als het goed is, is het puur hercompileren voor het 64 bits. Misschien hebben ze op knelpunten nog wat geoptimaliseerd voor het nieuwe OS maar dat waag ik te betwijfelen.

Het nut van deze actie is dat er nu een native 64 bits applicatie op een 64 bits OS draait. De WOW64 laag wordt dus niet meer gebruikt en dat zal wat performance verbeteringen moeten brengen.

[Verwijderd]

Lijkt me sterk dat je met één patch een heel spel kan veranderen naar 64-bits. Om dat te doen moet toch bijna het hele spel worden overgeschreven.?

Enige wat je hoeft te veranderen is de .exe (zodat daar x86-64 intstructies in komen te staan) en zoals ze hier gedaan hebben ook nog beetje meer eye-candy toegevoegd (betere textures,bump-maps etc)

Valt dus best wel mee...

[MaxxBass]

Denk dat alleen de engine naar 64 bit gaat, de textures, characters, enz.. veranderen niet...

Lijkt me wel dat de drivers voor de hardware in 64 bit nog niet geheel zijn geoptimaliseerd zijn.... wellicht scheelt dat nog..

[duce]

let wel op door dat Far Cry in 64Bit draait heeft crytek de GFX op gekriked met meer Phisycs en meer bommen en meer dieren dus ja dan kan het best dat de presetatie niet echt om hoog gaat.

let ook op dat de kernel die Far Cry gebruikt maar uit een paar DLL bestandjes bestaat die je zo kan vervangen, de rest van de engine draait op een soort input files achtige .LUA bestande dus het is zeer goed mogelijk de engine van Far Cry aan te passen/vervangen de Cry engine is een erg open systeem die je makelijk kan modden en als je de juist sdk heb zo nieuwe Source er bij kan prakken wat dus ook gedaan is met de Shader model 3.0 die is er gewoon bij ge prakt.

kan niet wachte tot Far Cry2 komt ook ergens tussen 2006 en 2007 in de buurt van Unreal3 en Unreal championship 2007

[NuKeFaCe]

Lijkt me sterk dat je met één patch een heel spel kan veranderen naar 64-bits. Om dat te doen moet toch bijna het hele spel worden overgeschreven.?

Tuurlijk niet, alleen de executables (dus de basis van de game) hoeven veranderd te worden, aan de graphics en sounds gebeurt verder niets.

[SuperDre]

ben ik nou gek ofzo (ja tuurlijk), maaruh er was toch al long een 64bits versie van ut2004 en Doom3? dus dit is toch helemaal niet zo spectaculair..

[Gert]

Je moet lezen wat er allemaal mogelijk is met deze patch, het spelen van Far Cry wordt meer dan een sensatie, het wordt gewoon fantastisch!

Nouja, zo zie je maar wat een marketing verhaal kan maken van 6fps.

[Phyxion]

Grote prestatiewinsten zullen gamers dus niet hoeven te verwachten met de overstap naar 64-bit.

Dit gaat neem ik aan alleen over Far Cry? Wat bij Far Cry gebeurd, hoeft namelijk nog niet meteen bij andere games zo te zijn.
Daarnaast is de imagequality echt enorm veel beter. Ook heb je veel verder zicht, en is alles graphisch veel mooier geworden door hem op x64 te draaien.
Dit leek me ook wel een vernoeming waard moet ik zeggen.
Er is dan wel weinig prestatieverschil, maar hoe het er graphisch uit ziet is enorm omhoog gegaan...

[Hielko]

Het feit dat de beeldkwaliteit beter wordt met deze patch heeft absoluut niks te maken met de 64-bit mogelijkheden; dat is gewoon gedaan door AMD en Crytek om 't interessant te maken voor de gamers.

[Phyxion]

Dat zou kunnen. Maar je moet niet vergeten dat je veel verder zicht hebt, en alle textures ook beter zijn. Dat betekend dat de videokaart meer moet renderen, en dat dus resulteert in minder fps. Dan kan je niet zeggen dat het zo veel percentage beter is, want dat is in wezen veel meer, want er moet immers meer gerenderd worden. Dat betekent dat je toch meer kracht krijg door de CPU, want anders waren de fps wel een stuk lager geweest...

[Phyxion]

Als je op deze pagina kijkt, zie je het verschil in image quality tussen de 32 bit en 64 bit. Dat zegt Anandtech in ieder geval.
Maar het is wel zo dat het verre zicht e.d. net zo goed in 32 bit hadden kunnen draaien, maar dat het gewoon exclusief voor AMD64 is... Dus ja, in hoe verre je alles kan vergelijken, als ik Anandtec zo bekijk zie ik wel degelijk verschil tussen 32 bit en 64 bit, en dan bedoel ik ook zonder die exclusive content patch. Het verre zicht e.d. is namelijk standaard enabled @ very high quality, en betekent toch dat de GPU meer moet renderen, en dus minder fps heeft...

[Verwijderd]

Of ze hebben de engine wat verbetert zodat de betere beeldkwaliteit behaald kan worden met mínder rekenkracht.

Zonder dat je inzicht hebt in wat de ontwikkelaars veranderd hebben is alle discussie over de snelheidswinst puur speculatie. Pas als er verschillende games zijn waarvan de 32 en 64 bits versies functioneel gelijk zijn kun je iets zinnigs gaan zeggen over de snelheidsverschillen tussen 32 en 64 bits.

[Hielko]

Nee, want AnandTech heeft de tests uitgevoerd zonder de "exclusive content" update te installeren. Dus gewoon het normale spel, zoals het in 32-bit ook is, maar dan met de 64-bit executable. Prima vergelijkbaar dus.

[Madrox]

Bij Anand is 32bit > zonder de 64bit patch
en de 64bit > met de 64bit patch

Er is dus grafisch niet gekeken naar:

32bit CPU/OS > 64bit Farcry
64bit CPU/OS > 64bit Farcry

Want dat kunnen ze niet, de 64bit patch werkt alleen met een 64bit OS.

Wat Anand dus doet is appels met peren vergelijken en dat zegt hij ook tussen de regels door. Vandaar ook deze slot-opmerking

...but the fact of the matter is that none of the visual improvements enabled by the Far Cry patches had anything to do with AMD64 or EM64T. They are artificially limited to run on those platforms alone, but could work just as well on a 32-bit platform

but could work just as well on a 32-bit platform

Wat we helaas niet kunnen testen, want er is geen 32bit Patch. Waarom die er niet is/komt, mag je raden

Maar wat Anand letterlijk zegt is dat de grafische verbeteringen niks, maar dan ook niks met 64bit instructies te maken heeft maar gewoon met de patch, een patch die net zo goed voor 32bit had kunnen worden geschreven . . .

[wzzrd]

"Veelbelovend"? 4 procent, vind jij dat "veelbelovend"? Als ze dit in samenwerking met AMD hebben gemaakt en een Intel-proc er meer van profiteert (relatief dan), als we welgeteld 6 frames per seconde meer trekken, terwijl we er al 150 per seconde hadden, dan noem jij dat 'veelbelovend'? Sorry voor de rant hoor, NOFI Ik ben eigenlijk een beetje teleurgesteld door deze resultaten...

Ik zou het toch eerder een 'matige start' willen noemen, of 'kinderziekten', of desnoods wil ik nog zeggen dat Far Cry al zo optimaal geschreven was, dat er weinig progressie meer te boeken was, maar 'veelbelovend' is nogal overtrokken.

[babbaloerie]

Het gaat misschien niet veel sneller maar de 64 bits versie heeft veel meer detail en een hogere view distance. Lees het artikel maar eens: www.anandtech.com/cpuchipsets/showdoc.aspx?i=2411

[Verwijderd]

"Veelbelovend"? 4 procent, vind jij dat "veelbelovend"?

Als je een beetje nadenkt was het ook wel te verwachten. Belangrijker vind ik dat het niet langzamer erop wordt. Vaak zie je toch dat je met nieuwe technieken in de eerste instantie iets moet inleveren: dat was iniedergeval zo met 9x -> NT (XP) en met de introductie van hyperthreading.

Ik vermoed dat de meeste winst nog wordt geboekt doordat de architectuur meer registers heeft, zodat de compiler daar veel makkelijker op kan optimizen. Het echt rekenen met 64 bits integers komt niet zo vaak voor, zeker niet in spellen.

Gezien het feit dat het altijd enorm lang duurt voor nieuwe technieken ingeburgert zijn (zeker zulke ingrijpende als de 64bits transitie) is het echter wel belangrijk dat het nu al gebeurd. Over pak 'm beet 5 jaar is het zeer waarschijnlijk dat het main memory over de 4GB gaat. Als je -dan- nog met je transitie moet gaan beginnen ben je helemaal zuur.

Als je nu kijkt naar hoe lang het uberhaupt al geduurt heeft voor de OS support op gang komt: een goede 2 jaar voor Windows, en wie weet nog hoe lang voor de beste Linux distributie (debian) met een 64bits stable komt?

Daarnaast geldt ook nog dat de typische zuurpruimen van die hier lurken altijd alles negatief vinden:

AGP4 was onzin: want maar enkele procenten winst.
AGP8 was onzin: want maar enkele procenten winst.
HT was onzin: want maar enkele procenten winst.
Serial ATA was onzin: want maar enkele procenten winst.
Dual channel ram was onzin: want maar enkele procenten winst.
DVI was onzin: want maar nauwelijks merkbaar beter beeld.
...

Maar doe het maar eens allemaal zonder, dan zit je alles bij elkaar toch wel duidelijk op een minder krachtig systeem. Voor het totaal beeld helpen toch alle beetjes.

[Jazco2nd]

inderdaad je kan net zo goed zeggen dat Windows XP 64-bit Edition ook geen 64-bit is... omdat het een slechts een 64bit laag op een 32 bit laag is (zoiets was het toch, WoW)

[Verwijderd]

Andersom: WoW is juist een 32bit-laag op een 64-bit basis! Als je 64bits programma's draait in XP x64, komt er geen 32bits code meer aan te pas.

[Verwijderd]

Wat ik een beetje kwalijk vind aan deze nieuwspost is dat er niet vermeld wordt dat de graphics kwaliteit omhoog is gegaan, het komt nogal negatief over op deze manier voor mensen die de daadwerkelijke review niet lezen..

Dus niet alleen (een beetje) sneller, de graphicskwaliteit is ook nog eens omhoog gegaan. 2 vliegen in één klap.

[Madrox]

Valt toch wel mee. Er word (terecht) gekeken naar het voordeel van 64bit t.o.v. 32bit.

Dat het er dan strakker/mooier uitziet met deze patch is leuk, het zegt echter niets in hoeverre 64bit hier de hand in heeft. Anantech gelovende, helemaal niets getuige hun slotopmerking

...but the fact of the matter is that none of the visual improvements enabled by the Far Cry patches had anything to do with AMD64 or EM64T. They are artificially limited to run on those platforms alone, but could work just as well on a 32-bit platform".

Vertaald: De visuele verbeteringen die deze patch laten zien hebben niets maar dan ook niets te maken met AMD64/EMT64t of een 64bit OS. Ze zijn alleen gelimiteerd tot het gebruik op zo'n 64bit platform, maar zouden net zo goed op een 32bit systeem kunnen werken.

Je opmerking [quote]
Als je naar de review kijkt de plaatjes met 64bit is mooier
[/quote] relateren met de 64bit architectuur slaat dan ook de plank compleet mis.

En wie denkt dat 64bit grote snelheidsverbeteringen zal teweeg brengen, denk nog maar eens. Als ze 10% halen, neem ik mijn pet af. Halen ze 20% of meer, dan zal ik diep buigen. Maar een marginale verbetering is méér te verwachten, snelheid komt zeker niet alleen vanaf de bit-breedte maar is afhankelijk van meer zaken...

[nr12]

naja opzich is het wel een feit dat bij de review de plaatjes met 64 bit mooier zijn dan de 32 bit ondanks dat een 32 bit CPU het misschien ook zou aan kunnen,.

en verder hangt de snelheid uiteraard van heel veel dingen af. Maar bij 32 bit of 64 bit heb je volgens mij wel je bandbreedten verdubbeld,.. en dat hoeft natuurlijk niet meteen in een verdubbeling van prestatie te lijden maar wel tot verbetering,..

En ik denk dat 64 bit zeker toekomst heeft in de volgende generatie games,. (farcy is gewoon 1 van de eerst (misschien wel de eerst) die probeerd het spel te draaien op 64 bit),. de eerst console game zijn ook niet altijd het best en mooiste en kunnen ook niet altijd meteen de console 100 % goed benutten,.

maarja tijd zal het ons leren ,..

EDIT: wat er dus gedaan is dat de 64 bit wat extra snufjes bij het spel hebben gehad,. zoals iets verdere draw distance en heldere textures mooier water enz. bij de 32 bit versie is dat niet zo.
Maar het kost wel extra rekenkracht (verder draw distance kost zo ie zo meer rekenkracht). De 64 bit versie is dus ook iets zwaarder dan de 32 bit versie. Ondanks dit is de 64 bit versie sneller dan de 32 bit.
opzich is het dan niet moeilijk te zien dat de 64 bit versie sneller dan de 6.5 % (wat uit de fps te zien is) is.

en of we nou rekenen in fps of in beter beeldkwaliteit het kost alle 2 meer rekenkracht. dus op 2 fronten presteerd hij hier beter. (het is namelijk raar om 2 procesoren te vergelijken als je de ene meer detail laat uitrekenen).

[Madrox]

nogmaals, mensen: lees eerst dit eens:

...but the fact of the matter is that none of the visual improvements enabled by the Far Cry patches had anything to do with AMD64 or EM64T. They are artificially limited to run on those platforms alone, but could work just as well on a 32-bit platform

Wat bedoelen ze daar nu mee ?
In mijn ogen dat de visuele verbeteringen uitsluitend door de patch worden veroorzaakt die helaas alleen bruikbaar is met een 64-bit OS. De vergelijking die ze laten zien met de plaatjes is naar mijn weten een vergelijk tussen de 64bit patched Farcry en de ongepatchte 32bit Farcry . Vandaar ook dat ze besluiten met enkele plaatjes van die alléén met de patched versie gemaakt kunnen worden; die met de extra levels.

Helaas is dit niet helemaal duidelijk naar voren gebracht, vandaar dat er mensen op het verkeerde been worden gezet. De plaatjes zouden met een 32bit OS en 32bit CPU mét de patch net zo mooi zijn, als ik het goed gelezen heb. Dat verklaart ook Anand's opmerking die ik hier quote.

Zoals Anand al zegt, leuke truuk van AMD/Crytek maar hij heeft ze door: Niet het 64bit OS/CPU zorgt voor de grafische verbeteringen, maar alleen de patch. Die dus net zo makkelijk voor de 32bit omgeving had kunnen worden gemaakt, iets wat ze om marketing redenen nu juist niet hebben gedaan. En dat het werkt blijkt wel, een hoop mensen trappen erin.

Anand gelukkig niet, en ik ook niet

[nr12]

Je hebt helemaal gelijk.
Als je naar de review kijkt naar de plaatjes met 64bit is mooier,.
Vooral het water is aanzienlijk mooier met 64 bit.
Verder kan je zien dat de textures beter naar voren komen en dat je bijvoorbeeld bergen op de achtergrond ziet die je normaal niet met 32 bit kan waarnemen (draw distance is groter)

www.anandtech.com/cpuchipsets/showdoc.aspx?i=2411&p=3 (gewoon de review maar voor de luie onder ons heb ik het er even neer gezet).

[Verwijderd]

View distace zou je theorethisch zo groot kunnen maken als dat je zelf fijn vind, heeft weinig met de 64bitheid van die processors te hebben.

[Verwijderd]

@ #12,

64bit betekent neit altijd meer rekenkracht, zoals een wijze poster op dit forum reeds gezegd heeft:

Ten tweede is er voordeel te behalen als je een dusdanig grote nauwkeurigheid nodig hebt dat je dat niet kwijtkan in een 32 bits getal. Een willekeurig programma kan prima met 64 bits getallen omgaan, alleen zal de compiler en/of processor behoorlijk wat moeten doen om dat werkend te krijgen. Simpel gezegd, eerst de lower 32 bits in de registers laden, verwerken, rekening houden met eventuele overloads, higher 32 bits laden, eventuele overload weer verwerken, en uiteindelijk heb je dan je resultaat. Bij een 64 bit processor is dat helemaal niet nodig en wordt de bewerking direct gedaan. In dit geval kan je enorm veel prestatie winst halen indien alles (platform en processor) direct de 64 bits ondersteunen. En ook hier denk ik dat FarCry dat niet zal doen, en dus ook geen meter sneller zal worden.....

Ben ik het niet HELEMAAL mee eens, maar het gedeelte over een berekening die meer preciesie dan aanwezig is nodig heeft klopt, en dat is rekentechnisch zijn enige voordeel.

[nr12]

maar wel met de rekenkracht. hoe verdere View distace hoe meer rekenwerk,..

[nr12]

okey dankje.
denk je dat je dan ook meer prestatie wint kan halen als het programma er helemaal voor is geschreven? dan alleen een patch,.. of denk je dat er nooit zo veel prestatie wint zal zijn met de 64 bit versie bij games? ik kan me namelijk voorstellen dat als je beschikking hebt over 64 bit dat je dan aardig wat snelheid hier uit kan persen,. veel meer dan de 6.5 % die hier staat.

[siren]

Er zijn zoveel meer factoren dan alleen 64 bit aan het werk in een game. Hoeveel procent meer haal je uit een game als je processor 10 procent overklokt. Misschien een paar frames je oog zou het verschil niet merken.
Het hele verhaal leest als een marketing stunt bij de markt die de amd in handen heeft en graag wil houden. De gamers.
Iedereen die reviews bekijkt ziet dat in de meeste games de amd's de intels eruitdraaien, een uitzondering daar gelaten.
Ik ben alleen bang dat er steeds meer games worden uigebracht die zijn geoptimaliseerd voor een amd processor of een nvidia kaart. Als je de verkeerde combinatie hebt dan ben je twee keer in het nadeel.

[Bartjuh]

"Grote prestatiewinsten zullen gamers dus (nog) niet hoeven te verwachten met de overstap naar 64-bit."

Ik denk dat 64bit veel potentieel heeft, alleen is het spel in eerste instantie gemaakt voor 32bit, de gamedevelopers hebben (naar alle waarschijnlijkheid) nog zeer weinig ervaring met 64bit gamedevelopment, en veel drivers en omliggende software is nog niet optimaal op 64bit afgestemd.

[Verwijderd]

64bit gaat niet zo heel snel zo ontzettent veel uitmaken voor spellen, extra operand lente, GRP grote die toeneemt, ik dacht datz e zelf iets erg belangrijks 32bit lieten, weet al niet meer precies wat, ik verwacht weinig nut voor spellen van 64bit.

[TheOneLLama]

Op den duur natuurlijk wel, al was het maar omdat de 2GB grens doorbroken wordt.

Ik denk dat je onderschat in welke mate games geoptimaliseerd worden voor het type processor waar ze op draaien. Men houd wel degelijk rekening met hoeveel cycles bepaalde instructies duren, waar de latencies zitten, hoeveel registers beschikbaar zijn. Met 64 bit kan een bepaalde instructie 2x zoveel precisie hebben, maar als je simpelweg een 32bit app hercompileerd heb je daar geen voordeel van.

[Verwijderd]

Neen, niet 2 keer zoveel preciesie, preciesie^2, het is namelijk niet meer 2^32 maar 2^64.

Als een applicatie berekeningen uitvoerd die boven de preciesie gaan, heeft hercompileren wel degelijk zin, maar zou niet weten wat in games zo precies zou moeten worden uitgerekent.

Ze hebben wat registers toegevoegd voor 64bit, zogenaamde General Purpose Registers (GPR), maar die zijn nouwelijks van belang, optimalisaties zitten meer in de SSE1,2,3 registers, dat zijn dingen waar speller gebruik van maken, en die blijven weereens ongewijzigd voor 32 en 64 bit.

[Verwijderd]

Dergelijke kleine prestatiewinsten zijn in real world natuurlijk altijd mooi meegenomen, maar het gaat wel ver om dat meteen toe te schrijven aan het feit dat het om een 64bits OS gaat. Windows XP x64 bevat ook gewoon een jongere kernel (NT 5.2) dan Windows XP 32bits (NT 5.1).

Achter de GUI van XP x64 zit eigenlijk Windows 2003 verborgen dus zou het m.i. eerlijker zijn om Windows 2003 Server te tunen naar een end-user OS en de prestaties daarin te vergelijken met XP x64.

[Verwijderd]

MM doe mij maar de 32 bit dan kn ik iig mijn enemy aan zien komen lopen bij de rock textures