Eerste blik op 64-bit gameprestaties met AMD64 Far Cry

Reacties

« 1 2 3 »

Door damaded, woensdag 11 mei 2005 18:59

Door wzzrd, woensdag 11 mei 2005 19:06

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

Door babbaloerie, woensdag 11 mei 2005 19:25

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

Door henk_DE_man, woensdag 11 mei 2005 21:21

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

Door Raine, woensdag 11 mei 2005 19:00

Door Jan Groothuijse, woensdag 11 mei 2005 20:33

AMD vs Intel heeft hier weinig mee van doen, het gaat hier om het feit dat 64bit weinig of geen effect heeft op de snelheid van spellen. Ik denk dat de belangrijkste reden voor 64bit nog steeds de adress ruimte is, 32bit heeft een theorethisch maximum van 4GB alloceerbaar geheugen, met 64bit maak je daar 16 Peta byte of iets in die richting van....

Door Paszzz, donderdag 12 mei 2005 11:37

64bits cpu's the future? Ik dacht dat quantum computers juist de future waren!

Door Pietervs, donderdag 12 mei 2005 13:15

maybe moeten ze die farcry code in 64bit shit down dan pas wordt het wat sneller
Mag ik dit vertalen als:
misschien moeten ze farcry eens hercompileren m.b.v. een 64 bits processor (en compiler) voor het verschil echt merkbaar wordt?
Want als je dat bedoeld, heb je (misschien) gelijk. Nu staat er gewoon een hoop geblaat waar zelfs een schaap geen wijs uit kan...

Door brada, woensdag 11 mei 2005 19:00

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

Door MacWolf, woensdag 11 mei 2005 19:10

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

Door The - DDD, woensdag 11 mei 2005 19:22

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.

Door Jeroen V, woensdag 11 mei 2005 19:34

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)

Door froggie, woensdag 11 mei 2005 19:44

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.

Door Jeroen V, woensdag 11 mei 2005 19:50

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

Door Jan Groothuijse, woensdag 11 mei 2005 20:35

@Jeroen V

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

Door NBK, woensdag 11 mei 2005 21:12

Door henk_DE_man, woensdag 11 mei 2005 21:39

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

Door LeX-333, woensdag 11 mei 2005 22:53

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

Door crusty1507, donderdag 12 mei 2005 04:50

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.

Door NoepZor, donderdag 12 mei 2005 09:13

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

Door aca, donderdag 12 mei 2005 10:30

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

Door loodgieter, woensdag 11 mei 2005 20:23

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)

Door DEXSTAR, woensdag 11 mei 2005 22:01

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.

Door Briandewis, woensdag 11 mei 2005 23:17

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.

Door Astennu, donderdag 12 mei 2005 08:52

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

Door thettes, donderdag 12 mei 2005 14:57

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.

Door zerobit, woensdag 11 mei 2005 19:12

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.

Door Munters, donderdag 12 mei 2005 11:08

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.

Door Erycius, woensdag 11 mei 2005 19:14

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

EDIT: bron

Door xerix, woensdag 11 mei 2005 19:19

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.

Door drahca, woensdag 11 mei 2005 20:18

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

Door henk_DE_man, donderdag 12 mei 2005 00:37

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)

Door Munters, donderdag 12 mei 2005 12:20

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.

Door obsidian, woensdag 11 mei 2005 19:23

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.

Door PeterFortuin, woensdag 11 mei 2005 19:48

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.

Door Pietje Puk, woensdag 11 mei 2005 20:28

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.

Door RuL0R, donderdag 12 mei 2005 01:09

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

Door MaxxBass, donderdag 12 mei 2005 07:59

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

Door duce, donderdag 12 mei 2005 08:46

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

Door NuKeFaCe, donderdag 12 mei 2005 10:23

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.

Door .dani., woensdag 11 mei 2005 19:00

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

Door wzzrd, woensdag 11 mei 2005 19:11

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

Door wibra, woensdag 11 mei 2005 20:19

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.

Door arjankoole, donderdag 12 mei 2005 08:12

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.

Door Jeroen V, woensdag 11 mei 2005 19:46

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

Door Jan Groothuijse, woensdag 11 mei 2005 21:17

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.

Door mimic, woensdag 11 mei 2005 19:01

Ik vind dit artikel nietszeggend omdat het gehele spel geschreven is voor 32-bits computers. Met een simpele patch kun je het spel DRAAIEN in 64-bits modus, maar dan is het spel zelf nog niet 64-bit gecode.

Door CARman, woensdag 11 mei 2005 19:13

Dan nog, is het aantal PFS niet ook sterk afhankelijk van de GPU ? 1024x768 met ALLE eyecandy aan, is natuurlijk ook een flinke belasting voor de GPU hè.

Je kan er in mijn optiek niet vanuit gaan dat een game zomaar 50% of meer sneller wordt als ie 64-bits in plaats van 32-bits wordt uitgevoerd, tenzij overduidelijk is, dat de bottleneck bij de CPU ligt en niet bij de GPU of de drivers daarvan. Het blijft hoe dan ook een samenspel van best veel factoren, een beetje vreemd om nu 4-6% extra frames puur en alleen op te hangen aan wel of niet 64-bits gamen.

Door Nap, woensdag 11 mei 2005 19:51

op lage resoluties is het dan ook veel meer rekenwerk dan renderwerk wat de klok slaat (in verhouding met hoge resoluties)

Door Phyxion, woensdag 11 mei 2005 19:03

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

Door Hielko, woensdag 11 mei 2005 19:10

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.

Door Phyxion, woensdag 11 mei 2005 19:16

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

Door Hielko, woensdag 11 mei 2005 19:19

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.

Door Phyxion, woensdag 11 mei 2005 19:24

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

Door Pietje Puk, woensdag 11 mei 2005 20:41

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.

Door Madrox, woensdag 11 mei 2005 23:50

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

Door DaWaN, woensdag 11 mei 2005 19:03

Vergeet niet dat het qua eyecandy er mooier uitziet als de 32bit versie!!

Door PainkillA, woensdag 11 mei 2005 19:03

En als 2e voordeel van die patch is die view distance verhoogd en zijn sommige grondtextures beter. Raar dat er hier niets over word gezegd want in sommige levels is het verschil enorm merkbaar.
(mm net te laat met deze opmerking

)

Door SuperDre, woensdag 11 mei 2005 19:13

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

Door Gert, woensdag 11 mei 2005 19:21

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.

Door AgentSmith, woensdag 11 mei 2005 19:22

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.

« 1 2 3 »

Op dit item kan niet meer gereageerd worden.

19:46	Brein klaagt providers aan om abonneegegevens te krijgen
17:28	HDA X-Mystique 7.1 Gold beluisterd

	STRATO - Full webhosting provider
	Alles weten over Far Cry 2. Lees de Tweakers special
	Alles over Outsourcing? Klik hier
	IT Directory.nl: vind nu een security leverancier

Frontpage

Archieven

Pricewatch

Forum

Community

Jobs

My Tnet

Nieuws I/O

Shortcuts

Categorieën

Gerelateerde artikelen

Reacties

12-10 Nieuws

12-10 Uit de rubrieken

00:29 Productreview

07:29 Vraag & Aanbod

12-10 Jobs

05:35 Etc.

08:05 Reacties

08:09 Forum

10-10 Far Cry 2 special

23:26 Tweakblogs

07:01 Computable headlines

00:00 Emerce headlines