DICE voorziet Frostbite-games die alleen werken op 64bit
Gameontwikkelaar DICE laat weten dat er in 2013 op de Frostbite 2.0-engine gebaseerde games op de markt komen, die enkel op een 64bits-besturingssysteem zullen werken. Drijfveer achter deze keuze is de toegang tot meer geheugen.
Johan Andersson, verantwoordelijk voor het grafische deel van de Frostbite-engine, liet dat weten in een tweet. Andersson noemt het een goede kans om te upgraden naar Windows 8, maar een 64bits-editie van Windows 7 of Vista voldoet ook.
De ontwikkelaar zegt dat het bij de overstap naar 64bit vooral te doen is om toegang tot meer werkgeheugen; een 64bits-besturingssysteem kan meer geheugen aanspreken en ook meer geheugen toewijzen aan een applicatie. De huidige versie van de engine maakt al gebruik van de extra mogelijkheden van 64bit-processors op een 64bits-besturingssysteem, maar kan ook met 32bits-software overweg.
DICE schuwt het laten vallen van ondersteuning voor oude technologie en standaarden niet; de Frostbite 2.0-engine, die onder meer gebruikt wordt in Battlefield 3, werkt bijvoorbeeld niet met DirectX 9, waardoor Windows XP-gebruikers buiten de boot vallen.
De nieuwste versie van de engine werd voor het eerst toegepast in Battlefield 3. Ook Need for Speed: The Run, Medal of Honor: Warfighter en Command & Conquer: Generals 2 maken gebruik van Frostbite 2.0 Laatstgenoemde moet in 2013 uitkomen. Of dat een van de games is waarop Andersson doelt, is nog niet bekend.
Reacties (155)
Eindelijk komt er echt massa voor 64-bit. De voordelen beginnen op te wegen tegen de nadelen!
Welke voordelen? EA kennende (afnemer van DICE Frostbite) is dit niet meer dan een groot excuus om games nog meer te rushen, met mogelijk nog meer onnodig geheugengebruik/leaks, alleen maar om te kunnen cashen.
De forums voor BF3 staan nog immer vol met tientallen bugs/issues over hoe zwaar BF3 op sommige systemen wel niet is maar voorlopig is het aantal patches 0 maar komen er wel allerlei betaalde DLC en ook een soort "CoD:Elite" aan.
/edit: je hebt niet meer dan 4GB nodig om een game op te kunnen starten en het e.e.a. te cachen; de rest van je systeem (zoals een 7200rpm drive en je RAM) zijn over het algemeen snel zat om tijdens het spel een paar pre-emptive textures en andere zaken te kunnen laden.
De forums voor BF3 staan nog immer vol met tientallen bugs/issues over hoe zwaar BF3 op sommige systemen wel niet is maar voorlopig is het aantal patches 0 maar komen er wel allerlei betaalde DLC en ook een soort "CoD:Elite" aan.
/edit: je hebt niet meer dan 4GB nodig om een game op te kunnen starten en het e.e.a. te cachen; de rest van je systeem (zoals een 7200rpm drive en je RAM) zijn over het algemeen snel zat om tijdens het spel een paar pre-emptive textures en andere zaken te kunnen laden.
[Reactie gewijzigd door MAX3400 op 23 mei 2012 09:02]
Het grote voordel wordt genoemd in het artikel: het is mogelijk om veel meer geheugen te gebruiken en dat zal in de toekomst natuurlijk belangrijk worden (we zijn ooit ook begonnen met een paar Kb en kijk waar we nu al staan).
Dat is eigenlijk tot op zekere hoogte hetzelfde verhaal als met Windows. Waarom is het een groot voordeel om veel meer geheugen te kunnen gebruiken? Als ik kijk hoe bepaalde games met het geheugen omgaan dan zie ik deze mogelijkheid gewoon als excuus voor de programmeurs om alweer minder efficiënt te werken. Is dit dan de manier om de ontwikkelkosten voor een game te minimaliseren? Gewoon zoveel geheugen beschikbaar krijgen dat veel performance problemen daardoor verdwijnen? Ik vind het nog steeds jammer... Je ziet dit niet alleen bij games maar bij heel veel programma's
En de gamers dan maar klagen dat de PC 10x betere hardware heeft vergeleken met consoles maar de beelden maar een fractie mooier zijn
En de gamers dan maar klagen dat de PC 10x betere hardware heeft vergeleken met consoles maar de beelden maar een fractie mooier zijn
Er zullen altijd wel spellen blijven die meer of spellen die minder efficiënt met geheugen omgaan. Toch is de beschikbaarheid van meer geheugen om mee te werken een positief iets is. Hoe je er mee om gaat is hierbij dus een volledig andere discussie.
De beschikbaarheid van meer geheugen is een positief iets. Dat een ontwikkelaar als DICE de klant wil verplichten om daadwerkelijk 64bit besturingssystemen te gebruiken vind ik weer typisch DICE.
Je verplicht klanten om te investeren in nieuwe Windows7, Vista, Windows 8 besturingssystemen, om je eigen tekortkomingen in het schrijven van een goede engine te verbloemen. Als je een goede engine schrijft, zorg je ervoor dat je de engine ook goed kan schalen voor het gebruik op minder toereikende hardware.
Maar ironisch gezien vind ik dit gedrag wel bij DICE passen. Ik heb als voorbeeld BF3 even gespeeld. En ik stoorde mij enorm aan de ontwikkelaars van DICE in hun ivoren toren.. De minachting die men daar toont voor klanten vind ik ver beneden elk peil. Als ik de houding van DICE naast die van Blizzard, Valve, etc leg, dan zie ik juist van Blizzard, Valve e.d. een veel bredere ondersteuning bieden op allerlei vlakken. DICE zegt eigenlijk gewoon tegen zijn klanten: Sorry maar wij hebben geen zin om bugfixes en lastige configuratie problemen op te lossen, ga maar gewoon een nieuw besturingssysteem kopen. kthnxbye.
Je verplicht klanten om te investeren in nieuwe Windows7, Vista, Windows 8 besturingssystemen, om je eigen tekortkomingen in het schrijven van een goede engine te verbloemen. Als je een goede engine schrijft, zorg je ervoor dat je de engine ook goed kan schalen voor het gebruik op minder toereikende hardware.
Maar ironisch gezien vind ik dit gedrag wel bij DICE passen. Ik heb als voorbeeld BF3 even gespeeld. En ik stoorde mij enorm aan de ontwikkelaars van DICE in hun ivoren toren.. De minachting die men daar toont voor klanten vind ik ver beneden elk peil. Als ik de houding van DICE naast die van Blizzard, Valve, etc leg, dan zie ik juist van Blizzard, Valve e.d. een veel bredere ondersteuning bieden op allerlei vlakken. DICE zegt eigenlijk gewoon tegen zijn klanten: Sorry maar wij hebben geen zin om bugfixes en lastige configuratie problemen op te lossen, ga maar gewoon een nieuw besturingssysteem kopen. kthnxbye.
Moet wel zeggen dat je bij bijna iedere nieuwe PC, Notebook tegenwoordig als standaard 64 bit OS krijgt. Alleen netbookies niet, maar daar wil je dan ook geen BF3 op spelen. Alles qua hardware is de laatste jaren al 64 bit voorbereid, dus zullen veel mensen bij een upgrade naar bijv Win8 toch wel overstappen op 64 bit.
Hij had waarschijnlijk beter kunnen zeggen dat ie over 2-3 jaar verwacht dat het geen nut meer heeft om 32 bit versies van een spel te maken.
Hij had waarschijnlijk beter kunnen zeggen dat ie over 2-3 jaar verwacht dat het geen nut meer heeft om 32 bit versies van een spel te maken.
En hoe inefficiënt gaan games met geheugen om? Ik lees dit vaak, met de beredenering dat een game "veel geheugen" gebruikt.
Natuurlijk hoeven ontwikkelaars niet meer maximaal efficiënt om te gaan met geheugengebruik, maar dit wil m.i. nog niet zeggen dat ze lui/inefficiënt produceren.
Natuurlijk hoeven ontwikkelaars niet meer maximaal efficiënt om te gaan met geheugengebruik, maar dit wil m.i. nog niet zeggen dat ze lui/inefficiënt produceren.
Mijn commentaar slaat ook niet direct op BF3 (geen ervaring mee) maar over het algemeen. Laatst speelde ik MW3 en heb ik dit een klein beetje vergeleken met The Witcher 2. Het verschil op mijn PC was duidelijk merkbaar. MW3 slurpte veel geheugen zonder dat de beelden het niveau van The Witcher 2 haalden. Natuurlijk is dit grotendeels te verklaren door de stok oude engine van MW3 maar het maakte mij wel iets duidelijk.
Het gaat zo goed met de natuur... Is het dan niet de moeite waard om verspilling te minimaliseren en hetgeen wat je hebt tot aan de max te benutten?
Ps. Ik heb het zoals ik in mijn post al heb aangegeven, niet alleen over games hoor, voor normale programma's geldt hetzelfde
Maar ja zoals SuperDre hieronder al aangeeft... Het is gewoon economisch (goede post trouwens!)
Het gaat zo goed met de natuur... Is het dan niet de moeite waard om verspilling te minimaliseren en hetgeen wat je hebt tot aan de max te benutten?
Ps. Ik heb het zoals ik in mijn post al heb aangegeven, niet alleen over games hoor, voor normale programma's geldt hetzelfde
Maar ja zoals SuperDre hieronder al aangeeft... Het is gewoon economisch (goede post trouwens!)
[Reactie gewijzigd door Mellow Jack op 23 mei 2012 09:33]
Werkgeheugen gebruik zegt niks over grafisch plaatje, werkgeheugen kan ook gebruik worden voor de tig andere taken, zoal AI. Jou vergelijk slaat daarom nog kant nog wal. zegt totaal niks! 64bit is voor al het geheugen niet alleen framebuffer.
En was jou punt nu niet dat oude engine efficiënter gemaakt werden omdat ze minder geheugen konden aanspreken? Je spreek je zelf nogal tegen daarmee.
Edit/
En anno 2012 gaan we toch niet klagen over geheugen, kost niks meer. Ik kom uit tijd dat je 200+ gulden moest betalen voor kleinste reepje geheugen. Nu krijg je normaal hoeveelheid voor 10 euro.
En was jou punt nu niet dat oude engine efficiënter gemaakt werden omdat ze minder geheugen konden aanspreken? Je spreek je zelf nogal tegen daarmee.
Edit/
En anno 2012 gaan we toch niet klagen over geheugen, kost niks meer. Ik kom uit tijd dat je 200+ gulden moest betalen voor kleinste reepje geheugen. Nu krijg je normaal hoeveelheid voor 10 euro.
[Reactie gewijzigd door mad_max234 op 23 mei 2012 10:10]
Daarom geef ik ook aan dat het niet alleen op games van toepassing is maar overal. Ik zeg zelf al dat het niet helemaal eerlijk is om te vergelijken al heeft het zeker wel een kern van waarheid. AI gezien is het verschil tussen MW en TW niet extreem (kan wel anders/minder efficiënt geprogrammeerd zijn) maar als je jezelf te focust op games dan loop je mijn punt voorbijWerkgeheugen gebruik zegt niks over grafisch plaatje, werkgeheugen kan ook gebruik worden voor de tig andere taken, zoal AI. Jou vergelijk slaat daarom nog kant nog wal. zegt totaal niks! 64bit is voor al het geheugen niet alleen framebuffer.
Nee ik zeg dat ze nu al inefficiënt programmeren en dat dit alleen maar erger zal wordenEn was jou punt nu niet dat oude engine efficiënter gemaakt werden omdat ze minder geheugen konden aanspreken? Je spreek je zelf nogal tegen daarmee.
Stel je voor dat 40 miljoen mensen hetzelfde denken en nu ipv 1 geheugenbank 2 banken gaan vullen. Als je kijkt naar het grote plaatje zal dit flink wat extra verbruik opleverenEdit/
En anno 2012 gaan we toch niet klagen over geheugen, kost niks meer. Ik kom uit tijd dat je 200+ gulden moest betalen voor kleinste reepje geheugen. Nu krijg je normaal hoeveelheid voor 10 euro.
Meer geheugen gebruik hoeft niet te komen door inefficient programmeren. Je hebt meer ruimte dus waarom er geen gebruik van maken? Er zijn bijvoorbeeld voorgecalculeerde berekeningen die je vooraf in het geheugen kan laden, waardoor een berekening word gereduceerd tot een lookup in een memory table.Nee ik zeg dat ze nu al inefficiënt programmeren en dat dit alleen maar erger zal worden
Zeker voor complexe physics zoals die in de Frostbite engine is een dergelijke techniek goed toepasbaar.
[Reactie gewijzigd door Laurens-R op 23 mei 2012 11:40]
Die 10 euro voor een reepje geheugen zal de drempel ook niet zijn. Nieuwe proc, mobo en bijbehorend OS daarintegen wel.
Volgens mij kan iedere processor van de afgelopen 5 jaar wel met 64-bit overweg, net zoals de andere hardware. Ook krijg je tegenwoordig meer wel dan geen 64-bit versie van Windows als OEM. Degene die dit niet hebben (netbooks, tablets?...) zijn ook niet de apparaten waarop gegamed zal worden.
Simpel, kijk wat de xbox 360 met 512 mb weet klaar te spelen, of de ps3 met 265. Ja, deze systemen gaan compleet anders met geheugen om dan een pc, maar kijk eens naar het belachelijke verschil met de minimum vereisten voor een pc versie. Dat moet toch wel iets zeggen?
Het verschil begint toch wel erg belachelijk te worden wanneer DICE beweert dat meer dan 4GB echt NODIG is, terwijl het door de nodige trucs en aanpassingen met de oude console hardware (en oude DirectX !!!) nog prima uit de voeten kan.
Het verschil begint toch wel erg belachelijk te worden wanneer DICE beweert dat meer dan 4GB echt NODIG is, terwijl het door de nodige trucs en aanpassingen met de oude console hardware (en oude DirectX !!!) nog prima uit de voeten kan.
Wel zo veel dat Skyrim allerlei bugs had op de PS3 waarvan de makers aangeven dat ze dat gewoon niet meer kunnen fixen omdat er simpelweg te weinig geheugen is voor een complexe engine, en dat terwijl er geklaagd wordt over dat het spel grafisch maar weinig hoogstaand is (wat op te lossen is met een flink aantal mods die het geheugengebruik flink doen stijgen, iets wat kennelijk niet lukt met een beperkte hoeveelheid geheugen). En op de pc heeft skyrim 'slechts' 2GB intern nodig, waarvan een groot deel al voor het OS is dus zoveel is het helemaal niet.Simpel, kijk wat de xbox 360 met 512 mb weet klaar te spelen, of de ps3 met 265.
En ja, het kan nog prima uit de voeten met wat aanpassingen. Maar ten eerste beperk je jezelf ermee (skyrim was misschien wel beter/mooier geworden als het PC-only was), en als je dus voor een echt hoogstaande game wilt gaan kan dat een reden zijn om dat geheugen ook gewoon te gebruiken zodat je er meer uit kunt halen. Ten tweede hebben ontwikkelaars niet altijd zin om zich nog te richten op gedateerde hardware/software. DX9 hebben ze gedropt omdat de meeste gamers inmiddels toch wel DX10 of DX11 aankunnen, en de extra moeite/kosten niet meer opwegen tegen die paar extra klanten. Die overweging zullen ze echt wel verstandig doen, als ze de helft van hun klanten uitsluiten zullen ze wel anders beslissen maar dat is dus kennelijk niet zo (of ze zijn heel stom bezig).
"Version 1.3.10.0 was released via Steam for the PC on 12/20/2011. This update was labeled as the "4GB Tuning" update that makes Skyrim large address aware (i.e. able to access up to 4GB of RAM instead of 2GB)."
Heb het even opgezocht, schijnbaar was 4GB al nodig om het geheel soepel te laten draaien. Naar mijn weten is dit echter nooit veranderd in de minimum specs. Laks. Maarja, er valt weinig tegen je argumentering in te brengen. Klasse!
Heb het even opgezocht, schijnbaar was 4GB al nodig om het geheel soepel te laten draaien. Naar mijn weten is dit echter nooit veranderd in de minimum specs. Laks. Maarja, er valt weinig tegen je argumentering in te brengen. Klasse!
4GB adres-ruimte is heel iets anders dan 4GB ram in je PC.
Die patch was dan ook alleen maar echt nodig als je de game op max wilt draaien. Wat een console sowieso niet aankan. Als je Skyrim op console-niveau instelt dan werkt het op de PC ook best met < 4GB geheugen.
Je vergeet dat BF3 voor de consoles zwaar achteruit loopt qua graphics, de maps kleiner zijn en er verschillende aanpassingen gedaan zijn.Simpel, kijk wat de xbox 360 met 512 mb weet klaar te spelen, of de ps3 met 265. Ja, deze systemen gaan compleet anders met geheugen om dan een pc, maar kijk eens naar het belachelijke verschil met de minimum vereisten voor een pc versie. Dat moet toch wel iets zeggen?
Het verschil begint toch wel erg belachelijk te worden wanneer DICE beweert dat meer dan 4GB echt NODIG is, terwijl het door de nodige trucs en aanpassingen met de oude console hardware (en oude DirectX !!!) nog prima uit de voeten kan.
Dat is helaas iets waar je mee moet leren leven, programma's worden steeds meer ontwikkeld in talen (Java), frameworks (.NET) en fileformats (XML) die NIET! resourcefriendly zijn. Het maakt het leven van een developer wel allemaal een heel stuk makkelijker, maar daar staat dus wel tegenover dat men moet inboeten op de performance.. Ook de diversiteit van de hardware (PC) is daarbij dan een probleem.
De overstap naar frameworks als HTML5 gaat daar ook zeker niet aan bijdragen.. Maar men (de gebruiker) wil ook het liefst dat elk programma datie heeft op elk device draait datie heeft, en dan ben je wel aangewezen op zulke talen/frameworks..
Als de programmeurs weer echt gebruik zouden maken van de hardware (en deze dus ook echt kennen) dan zou het allemaal vele malen sneller draaien, dat is dus ook de reden waarom ze meer uit een console kunnen trekken dan een vergelijkbare PC.
De overstap naar frameworks als HTML5 gaat daar ook zeker niet aan bijdragen.. Maar men (de gebruiker) wil ook het liefst dat elk programma datie heeft op elk device draait datie heeft, en dan ben je wel aangewezen op zulke talen/frameworks..
Als de programmeurs weer echt gebruik zouden maken van de hardware (en deze dus ook echt kennen) dan zou het allemaal vele malen sneller draaien, dat is dus ook de reden waarom ze meer uit een console kunnen trekken dan een vergelijkbare PC.
Hier ben ik het volledig mee eens...
Cores ten overvloede, disk space ten overvloede, memory ten overvloede...
Ik blijf er nog steeds bij dat als men inderdaad weer "strak" gaat coden, je veel meer game / applicatie voor je geld <> hardware krijgt.
In grote games of in Windows zelf zou dit echt veel schelen, qua disk ruimte, maar ook qua performance....
Het enigste nadeel is; je heb nu meerdere instructie sets waar je op kunt varen....
Aan de andere kant, daar liggen ook weer mooie uitdagingen
Cores ten overvloede, disk space ten overvloede, memory ten overvloede...
Ik blijf er nog steeds bij dat als men inderdaad weer "strak" gaat coden, je veel meer game / applicatie voor je geld <> hardware krijgt.
In grote games of in Windows zelf zou dit echt veel schelen, qua disk ruimte, maar ook qua performance....
Het enigste nadeel is; je heb nu meerdere instructie sets waar je op kunt varen....
Aan de andere kant, daar liggen ook weer mooie uitdagingen
Uiteraard, maar dat kost gewoon heel veel meer geld en geeft grotere risicos op fouten. Als extreem voorbeeld, als jij het in assembly gaat programmeren ga ik je verzekeren dat je een programmatje dat simpelweg een windows schermpje moet laten zien met standaard knoppen, about menutje, en hello world één grote bug wordt. Terwijl als jij bijvoorbeeld een leuk programmatje mbv .NET maakt het door elke idioot zo foutloos te maken is.
Ja het is wel minder efficient als het allemaal goed werkt, maar efficientie is niet alles.
En qua extra kosten kan er wel gezegd worden dat de bedrijven allemaal graaiers enzo zijn, maar uiteindelijk zullen die kosten dan dus ook gewoon naar de consument worden doorgerekend. En als diezelfde consument dan kan kiezen tussen bijvoorbeeld MW3 die beschikbaar is, of BF3 die ergens in 2018 beschikbaar is omdat ze de hele handel met een enorm team in enkel C zijn gaan proggen en die dan 200 euro kost en tegen die tijd zwaar verouderd is, dan neemt die consument wel het wel voor lief dat MW3 wat minder efficient is.
Ja het is wel minder efficient als het allemaal goed werkt, maar efficientie is niet alles.
En qua extra kosten kan er wel gezegd worden dat de bedrijven allemaal graaiers enzo zijn, maar uiteindelijk zullen die kosten dan dus ook gewoon naar de consument worden doorgerekend. En als diezelfde consument dan kan kiezen tussen bijvoorbeeld MW3 die beschikbaar is, of BF3 die ergens in 2018 beschikbaar is omdat ze de hele handel met een enorm team in enkel C zijn gaan proggen en die dan 200 euro kost en tegen die tijd zwaar verouderd is, dan neemt die consument wel het wel voor lief dat MW3 wat minder efficient is.
[Reactie gewijzigd door Sissors op 23 mei 2012 10:35]
Helemaal mee eens. Kijk bijvoorbeeld naar de eerste supreme commander: dat spel crasht vaak als ie over de 2GB geheugengebruik gaat. Werd ook instabieler naar mate een game vordert, en dat komt omdat back in 2006 iedereen pas net aan het overstappen was op dual-cores, >1GB ram enz. Supreme commander is een goed voorbeeld van een game dat ze beter x64 only hadden kunnen maken (maar in die tijd...). 32-bit hield het spel enorm tegen. Naar mate een game vorderde, werd er steeds meer in het geheugen geplaatst, zoals honderden units, wreckages, projectielen enz.
Op huidige systemen met een i5/i7 en 4GB ram of meer loopt het prima, was dus een game die z'n tijd vooruit was en nog steeds is.
Ben benieuwd wat bijvoorbeeld een volledig x64 ontwikkelde RTS kan brengen....
Op huidige systemen met een i5/i7 en 4GB ram of meer loopt het prima, was dus een game die z'n tijd vooruit was en nog steeds is.
Ben benieuwd wat bijvoorbeeld een volledig x64 ontwikkelde RTS kan brengen....
Dat makkelijker is vaak ook niet waar. Voor veel meuk wordt bijv. XML gebruikt waar INI bestanden honderd keer makkelijker waren, om het maar niet over 1000 keer leesbaarder te hebben...
En dat allemaal omdat ze te lam zijn om de library voor ini's te leren ofzo (en zo moeilijk is die niet...). XML is heeft zeker zijn nut, maar dat is maar in zo'n 10% van de gevallen dat het gebruikt wordt schat ik (en die schatting is heving onderhevig aan waar je mee werkt).
En dat allemaal omdat ze te lam zijn om de library voor ini's te leren ofzo (en zo moeilijk is die niet...). XML is heeft zeker zijn nut, maar dat is maar in zo'n 10% van de gevallen dat het gebruikt wordt schat ik (en die schatting is heving onderhevig aan waar je mee werkt
).
Xml biedt ook dingen als validatie, documentatie, data types, allerlei toeters en bellen die ini bestanden niet bieden die de performance, stabiliteit en uit eindelijk gebruikersvriendelijkheid ten goede komen.
Je vergeet alleen dat een XML ook maar gewoon een tekst bestand is net zoals een INI file, en ook bij een INI file zou je validatie, documentatie en data types kunnen toepassen.
Ik ben bv net op het werk bezig met SEPA -SCT, en ja dat is in principe netjes vastgelegd in een XSD, ware het niet dat je aan de XSD geen zak eigenlijk hebt omdat voor Nederland dus andere implementatie voorwaarden gelden die ook nog eens per bank kunnen verschillen, Nou, geef mij dan maar het simpele ClieOp03 formaat wat een stuk simpeler is..
Daar sta je dan met je XSD en je validatie, ofwel volg je netjes de XSD wordt het bestand afgekeurd door je bank omdat die niet aan het correcte formaat voldoet..
En zo ben ik ze nog wel vaker tegen gekomen.
Overigens wil ik niet zeggen dat XML slecht is, verre van, het is juist best handig als je een onbekend bestand krijgt en (als de veldnamen een beetje duidelijk zijn) je makkelijk het bestand kunt ontcijferen. Ook in dat geval is het makkelijk voor anderen om het visueel te controleren..
Ik ben bv net op het werk bezig met SEPA -SCT, en ja dat is in principe netjes vastgelegd in een XSD, ware het niet dat je aan de XSD geen zak eigenlijk hebt omdat voor Nederland dus andere implementatie voorwaarden gelden die ook nog eens per bank kunnen verschillen, Nou, geef mij dan maar het simpele ClieOp03 formaat wat een stuk simpeler is..
Daar sta je dan met je XSD en je validatie, ofwel volg je netjes de XSD wordt het bestand afgekeurd door je bank omdat die niet aan het correcte formaat voldoet..
En zo ben ik ze nog wel vaker tegen gekomen.
Overigens wil ik niet zeggen dat XML slecht is, verre van, het is juist best handig als je een onbekend bestand krijgt en (als de veldnamen een beetje duidelijk zijn) je makkelijk het bestand kunt ontcijferen. Ook in dat geval is het makkelijk voor anderen om het visueel te controleren..
Tuurlijk. En programmeren in C of Cobol of Pascal is ook een verspilling ! Gewoon allemaal in Assembler programmeren. Dan gaat het veel sneller ! Die programmeurs van tegenwoordig zijn allemaal luie fl****.
Waar heb ik dit eerder gehoord ?
Abstraction-layers in het programmeren zijn geweldig. Ze hebben vaak wat overhead. Maar daar staat tegenover dat ze het leven van programmeurs ontzettend veel makkelijker maken. Zoveel gemakkelijker dat programmeurs hele klassen van nieuwe problemen kunnen aanpakken, die vroeger veel te complex waren. Zonder hogere programmeer talen, zonder DirectX (of OpenGL), zonder al die frameworks, dan zaten we nu nog in het Doom1 tijdperk.
Waar heb ik dit eerder gehoord ?
Abstraction-layers in het programmeren zijn geweldig. Ze hebben vaak wat overhead. Maar daar staat tegenover dat ze het leven van programmeurs ontzettend veel makkelijker maken. Zoveel gemakkelijker dat programmeurs hele klassen van nieuwe problemen kunnen aanpakken, die vroeger veel te complex waren. Zonder hogere programmeer talen, zonder DirectX (of OpenGL), zonder al die frameworks, dan zaten we nu nog in het Doom1 tijdperk.
Puur in assembly programmeren hoeft niet, maar een taal die dicht bij de hardware staat (zoals C) is ook goed.
Ik moet eerlijk zeggen dat ik indertijd met de 286 en 386 (protected mode ofwel 1 big adress-space) bijna nog makkelijker vond dan in pascal programmeren, en het was nog leuk ook, en zelfs die paar engines die ik toen geschreven had draaien nu zelfs nog perfect onder dosbox..
WAT overhead? laag op laag op laag op laag op laag op laag op laag...
En ja, wij programmeurs zijn luie flikkers...
En de programmeur die niet wil onderkennen dat al die lagen wel degelijk zware invloed hebben op de performance kan ik alleen maar van stellen dat het een slechte programmeur is, want je moet je wel bewust zijn van dit soort dingen.. tja, dat is dus MIJN mening.. Zolang je weet dat het gevolgen heeft voor de performance is er niets aan de hand, maar ik zie vaak genoeg dat er maar wat geprogrammeerd wordt en dat het wel werkt, maar de performance is gewoon shite is, en met een beetje optimalisatie kan veel bereikt worden..
Zelf probeer ik ook zoveel mogelijk bij een taal/framework er achter te komen wat trage is en of er snellere functies zijn.. Het zal niet de eerste keer zijn dat ik timings doe op vergelijkbare stringfuncties of wiskundige functies.
Een mooi voorbeeld is toch nog steeds bv die vergelijking bij Android Dalvik en Android geport naar Mono, dat dat dus echt extreme verschillen zijn (en waarbij je als android gebruiker dus denkt, gvd waarom dumpen ze Dalvik niet en gaan over naar die Mono port (en gebruik dalvik hooguit nog voor Backwardcompatibility)).. en dan te bedenken dat het dus NOG sneller kan..
Ik moet eerlijk zeggen dat ik indertijd met de 286 en 386 (protected mode ofwel 1 big adress-space) bijna nog makkelijker vond dan in pascal programmeren, en het was nog leuk ook, en zelfs die paar engines die ik toen geschreven had draaien nu zelfs nog perfect onder dosbox..
WAT overhead? laag op laag op laag op laag op laag op laag op laag...
En ja, wij programmeurs zijn luie flikkers...
En de programmeur die niet wil onderkennen dat al die lagen wel degelijk zware invloed hebben op de performance kan ik alleen maar van stellen dat het een slechte programmeur is, want je moet je wel bewust zijn van dit soort dingen.. tja, dat is dus MIJN mening.. Zolang je weet dat het gevolgen heeft voor de performance is er niets aan de hand, maar ik zie vaak genoeg dat er maar wat geprogrammeerd wordt en dat het wel werkt, maar de performance is gewoon shite is, en met een beetje optimalisatie kan veel bereikt worden..
Zelf probeer ik ook zoveel mogelijk bij een taal/framework er achter te komen wat trage is en of er snellere functies zijn.. Het zal niet de eerste keer zijn dat ik timings doe op vergelijkbare stringfuncties of wiskundige functies.
Een mooi voorbeeld is toch nog steeds bv die vergelijking bij Android Dalvik en Android geport naar Mono, dat dat dus echt extreme verschillen zijn (en waarbij je als android gebruiker dus denkt, gvd waarom dumpen ze Dalvik niet en gaan over naar die Mono port (en gebruik dalvik hooguit nog voor Backwardcompatibility)).. en dan te bedenken dat het dus NOG sneller kan..
En jij denkt dat zo'n engine ook leuk in .Net of Java is gemaakt?
@LOTG: DICE, en ik dus ook, doelen op Frostbite
@LOTG: DICE, en ik dus ook, doelen op Frostbite
[Reactie gewijzigd door jip_86 op 23 mei 2012 11:04]
En waarom zou dat niet kunnen? Frostbite enzo waarschijnlijk niet nee, maar we hebben ook nog Managed DirectX, XNA en jmonkeyengine.
Ik vind het ook onzin om te roepen dat we allemaal weer terug moeten naar C++, het gaat er maar om waar je het gebruikt. Voor een PC is het onzin om al je software op assembly nivo te gaan zitten optimaliseren, als je maar netje met je resources om gaat.
Het blijft zo dat er een grote diversiteit is in hardware en dat die abstractie lagen gewoon goed werken en in de meeste gevallen hun werk ook goed doen als de programmeur dat ook doet.
Ik vind het ook onzin om te roepen dat we allemaal weer terug moeten naar C++, het gaat er maar om waar je het gebruikt. Voor een PC is het onzin om al je software op assembly nivo te gaan zitten optimaliseren, als je maar netje met je resources om gaat.
Het blijft zo dat er een grote diversiteit is in hardware en dat die abstractie lagen gewoon goed werken en in de meeste gevallen hun werk ook goed doen als de programmeur dat ook doet.
Sorry to burst your bubble, maar een managed applicatie (.Net of Java) kan een stuk resourcefriendlier zijn dan een gemiddelde native applicatie door het gebruik van de garbage collector, of eigenlijk specifiek het kunnen verplaatsen van geheugen. Geheugenfragmentatie is een groot probleem in games, na verloop van tijd zit je address space vol met kleine stukjes vrijgegeven blokken die je niet als 1 kunt alloceren omdat er andere blokken tussen zitten. Defragmentatie is niet heel makkelijk, omdat een native applicatie typisch geen metadata tot z'n beschikking heeft over waar alle pointers staan die geüpdatet moeten worden. Een managed applicatie heeft dat juist wel. Natuurlijk, managed code brengt ook weer andere nadelen met zich mee, maar als je een beetje je best doet dan is slechte resourcefriendlyness daar nou juist niet een van.
Diezelfde fragmentatie haakt overigens ook weer in op dit artikel, want het is onder een 64 bits address space veel minder een probleem. Je alloceert namelijk ranges van virtueel geheugen, en de fysieke pages die daaronder liggen kun je naar willekeur reassignen. Lege pages die kriskras vrijkomen kun je dus gewoon gebruiken om aan het eind van je gebruikte address range weer naast elkaar te alloceren. Kan met een 32 bits address space natuurlijk ook, maar dan loop je al vrij snel tegen het eind aan (2 tot ~4 GB afhankelijk van het gebruikte OS en settings) en dus zul je oude adressen moeten gaan hergebruiken (dus last van fragmentatie), terwijl een 64 bits address space zo goed als onuitputtelijk is (16TB onder Windows).
En dat laatste heeft geen drol met efficient programmeren te maken, voor de mensen die denken dat 64 bits gewoon een excuus is om lui te kunnen zijn.
Diezelfde fragmentatie haakt overigens ook weer in op dit artikel, want het is onder een 64 bits address space veel minder een probleem. Je alloceert namelijk ranges van virtueel geheugen, en de fysieke pages die daaronder liggen kun je naar willekeur reassignen. Lege pages die kriskras vrijkomen kun je dus gewoon gebruiken om aan het eind van je gebruikte address range weer naast elkaar te alloceren. Kan met een 32 bits address space natuurlijk ook, maar dan loop je al vrij snel tegen het eind aan (2 tot ~4 GB afhankelijk van het gebruikte OS en settings) en dus zul je oude adressen moeten gaan hergebruiken (dus last van fragmentatie), terwijl een 64 bits address space zo goed als onuitputtelijk is (16TB onder Windows).
En dat laatste heeft geen drol met efficient programmeren te maken, voor de mensen die denken dat 64 bits gewoon een excuus is om lui te kunnen zijn.
[Reactie gewijzigd door .oisyn op 23 mei 2012 10:55]
Daar heb je een goed punt. Er zijn echter ook programmeertalen (zoald D bijvoorbeeld) die compileren tot native code en ook een garbage collector hebben ...
@ .oisyn, wat ik niet snap: is dat mappen (virtuele range waar fysieke pages aan hangen) eigenlijk niet hetzelfde als fragmentatie? alsin, de virtuele range mag dan netjes op rij liggen, maar gaat het onderliggende geheugen niet alsnog gefragmenteerd zijn?
Ja, maar dat is niet erg. Het is niet zo als bij een harde schijf dat dan de toegangstijd langer wordt.
Tja, niets weerhoudt je ervan om zelf een fatsoenlijke garbagecollector te schrijven voor je native applicatie.. Maar een native windows applicatie is al geen echte native applicatie meer, die maakt al gebruik van zoveel libraries.....
Ik zeg echt niet dat we weer terug moeten keren naar de goede oude tijd, maar je weet zelf ook dat wil je meer uit bv een console hardware halen je toch vaak rechtstreeks op de HW moet gaan werken ipv gebruik te maken van de door de consolemaker geleverde libraries.
en ik ben het met je eens dat 64bit adressen niets te maken heeft met lui te kunnen zijn..
maargoed, als ik bedenk dat we vroeger met die 16K segmenten te maken hadden en daarbij ook veel moesten switchen, dan zie ik gewoon dat de hedendaagse programmeur dat gewoon verleerd is. Ik moet je eerlijk bekennen dat ik dat maar even gedaan heb en dat het me ook niet echt lekker lukte, totdat ik gelukkig toen die protected mode had en zo 1 groot brok geheugen had (net zoals bv de Amiga al langer had, god, dat waren de leuke tijden, nog echt bezig met rechtstreeks op de hardware werken)..
Ik zeg echt niet dat we weer terug moeten keren naar de goede oude tijd, maar je weet zelf ook dat wil je meer uit bv een console hardware halen je toch vaak rechtstreeks op de HW moet gaan werken ipv gebruik te maken van de door de consolemaker geleverde libraries.
en ik ben het met je eens dat 64bit adressen niets te maken heeft met lui te kunnen zijn..
maargoed, als ik bedenk dat we vroeger met die 16K segmenten te maken hadden en daarbij ook veel moesten switchen, dan zie ik gewoon dat de hedendaagse programmeur dat gewoon verleerd is. Ik moet je eerlijk bekennen dat ik dat maar even gedaan heb en dat het me ook niet echt lekker lukte, totdat ik gelukkig toen die protected mode had en zo 1 groot brok geheugen had (net zoals bv de Amiga al langer had, god, dat waren de leuke tijden, nog echt bezig met rechtstreeks op de hardware werken)..
Dat staat los van slordig of niet efficient programmeren, dat heeft zijn oorzaak in het feit dat het vaak ports zijn waarbij er verder nauwelijks windows api specifieke code wordt gebruikt (en dus ziet het er op de pc dan net zo brak uit als op een console).En de gamers dan maar klagen dat de PC 10x betere hardware heeft vergeleken met consoles maar de beelden maar een fractie mooier zijn
denk je nou werkelijk dat dat met 'api's' te maken heeft? en niet met de content zelf...
Ik denk dat het nog te vroeg is om enkel een 64bits versie uit te brengen, het overgrote deel van de wereld zit denk ik op 32bit.
Zou je ook niet via de settings gamers met de 64bit "belonen" met betere prestaties zonder de 32bit gamers uit te sluiten?
Zou je ook niet via de settings gamers met de 64bit "belonen" met betere prestaties zonder de 32bit gamers uit te sluiten?
Steam Survey April 2012.het overgrote deel van de wereld zit denk ik op 32bit.
http://store.steampowered.com/hwsurvey
54% van de gamers op Steam gebruiken Windows 7 64-bit. Plus 6% heeft 64-bit Vista.
Normaal kun je een "scalable engine" maken. Die meer eyecandy gebruikt in krachtiger systemen. Echter, met het 64 vs 32 bit probleem is het anders. Je moet kiezen. Dus een developer kan alleen maar 2 verschillende exe's bouwen. En voor alle andere resources (textures, models, etc) zal hij altijd duidelijk 2 verschillende sets moeten maken. Een hoop extra werk dus.Zou je ook niet via de settings gamers met de 64bit "belonen" met betere prestaties zonder de 32bit gamers uit te sluiten?
[Reactie gewijzigd door gryz op 23 mei 2012 10:45]
De textures enzo zijn voor beide versies hetzelfde. Die zijn afhankelijk van de gedetailleerdheid (waaronder resolutie, kleurdiepte), maar niet afhankelijk of het op een 64bit of 32bit os draait. Hooguit is de container in een ander formaat, maar dat is niet eens nodig.
Nou ja, ik kan me nog indenken dat je voor een high-poly model meer geheugen nodig hebt als voor low-poly. Dat zou dan alsnog betekenen dat je twee versies nodig hebt...
Zoals gryz al aangeeft is dit voor gamers zeker niet waar, en denk nou zelf, mama met de huis tuin en keuken PC die geen 64 bit Windows 7 heeft speelt zeer waarschijnlijk ook geen Battlefield 3.Ik denk dat het nog te vroeg is om enkel een 64bits versie uit te brengen, het overgrote deel van de wereld zit denk ik op 32bit.
Zou je ook niet via de settings gamers met de 64bit "belonen" met betere prestaties zonder de 32bit gamers uit te sluiten?
Volgens de Steam Hardware Survey draaien de meeste mensen die Steam draaien al Windows 7 x64 en ik dacht dat Microsoft laatst ook zei dat 64 bit Windows 7 meer verkocht was dan 32 bit. Sowieso komen zelfs OEM laptops/computers sinds Windows 7 standaard met 64 bit en dat zal in de toekomst alleen maar meer worden.
Conclusie : Ik zie het probleem niet.
[Reactie gewijzigd door Dylan93 op 23 mei 2012 11:22]
Wie heeft er nou meer dan 4GB in een PC, ja tweakers, maar verder.... tussen 32 of 64bit is dat dus voor een doorsnee gebruiker een 750/800MB extra geheugen wat gebruikt zou kunnen worden, zet weinig zoden aan de dijk.... laat ze inderdaad eens netjes programeren!
-> Straks gaan ze nog eisen dat je een snelle SSD en 16GB hebt, anders doet de game het niet
-> Straks gaan ze nog eisen dat je een snelle SSD en 16GB hebt, anders doet de game het niet
Dat zit er gegarandeerd aan te komen, ja. En wie heeft er meer als 8GB? Ik denk zo ongeveer elke > casual gamer. Vier GB is tegenwoordig in kantoorbakjes al standaard.
Zelf heb ik hier vanwege fotografie al 8 GB sinds 2007. Een volgende PC krijgt 16 GB omdat het nagenoeg gratis is. Zelfs sommige PC's bij de Aldi en Kruitvat hebben tegenwoordig al 8 GB....
Verbetering: meeste nieuwe computers die ik tegenkom (vooral HP, Medion bakjes dan) hebben ook al standaard 6 of 8 GB ipv 4GB ... (enkel computers onder de 600 euro doen ze de moeite niet om een extra latje erin te proppen)
Meer geheugen? Waarvoor? Texturegrootte? De grootte van textures is de afgelopen 5 jaar niet omhoog gegaan. Geen enkele game heeft meer dan 4GB RAM nodig. Daarnaast moet de game het vast ook op de PS3 doen, en die moet het doen met een miezerige 256MB RAM.
[Reactie gewijzigd door Wolfos op 23 mei 2012 21:09]
Ik speel al tijden BF3 en ik heb kunnen conculuderen dat 8GB wel degelijk verschil maakt. Laadtijden zijn korter, FPS stabieler.
dat was al bij BF1942, daar maakte het ook een wereld van verschil als je meer geheugen had..
Echter komt dat waarschijnlijk niet eens door BF3 zn manier van gegevens in het geheugen van die applicatie zetten, maar het feit dat windows de bestanden die benaderd worden gewoon in zn cache houd. Dat valt toch al buiten de 2GB limiet waar 32 bit applicaties mee zitten.
Maar ik snap het wel. 64 bit is intussen toch ingeburgerd en zou theoretisch het leven van de programmeurs makkelijker moeten maken.
Ik heb me er eigenlijk nog niet zo in verdiept en heb eigenlijk geen idee wat dit voor games zou betekenen (buiten meer RAM tot je beschikking hebben).
Ik vraag me alleen wel af of dit voor processen die erg veel data uit het RAM moeten halen geen negatieve impact gaat hebben omdat dezelfde code in een 64 bit applicatie meer gegevensverkeer tussen RAM en CPU zal opleveren, met prestatie problemen tot het gevolg.. Wie weet krijgen we straks wel bij de systeemeisen nog RAM/bus snelheid eisen ook
Maar ik snap het wel. 64 bit is intussen toch ingeburgerd en zou theoretisch het leven van de programmeurs makkelijker moeten maken.
Ik heb me er eigenlijk nog niet zo in verdiept en heb eigenlijk geen idee wat dit voor games zou betekenen (buiten meer RAM tot je beschikking hebben).
Ik vraag me alleen wel af of dit voor processen die erg veel data uit het RAM moeten halen geen negatieve impact gaat hebben omdat dezelfde code in een 64 bit applicatie meer gegevensverkeer tussen RAM en CPU zal opleveren, met prestatie problemen tot het gevolg.. Wie weet krijgen we straks wel bij de systeemeisen nog RAM/bus snelheid eisen ook
Hehe, toch nog liever dattie 2x meer uit RAM moet gaan halen (wat nu toch vaak al sneller kan dan de CPU deze data efficient kan verwerken en doorzenden) dan dattie ook af en toe es naar een cache bestandje moet schrijven op de HDD
@MAX3400
Toegang tot meer dan 4GB is dan dus zeer handig
@FireDrunk
Maar ben het wel met je eens dat er EINDELIJK meer komt waar pure x64 ondersteuning in zit zonder het gezeik van 32-bit!
Klopt, maar gezien je game niet het enige is dat draait (denk aan de resource hog Windows) kan het wel eens vaker voorkomen dan je denkt dat die 4GB vol raakt./edit: je hebt niet meer dan 4GB nodig om een game op te kunnen starten en het e.e.a. te cachen; de rest van je systeem (zoals een 7200rpm drive en je RAM) zijn over het algemeen snel zat om tijdens het spel een paar pre-emptive textures en andere zaken te kunnen laden.
Toegang tot meer dan 4GB is dan dus zeer handig
@FireDrunk
Welke nadelen ervaar je dan? Ik draai zelf sinds de release van Windows 7 op x64 en heb nog nooit een probleem gehad met compatibiliteit en drivers oid. Alleen ten tijden van de Beta met mijn videokaart, maar dat is vrij logischDe voordelen beginnen op te wegen tegen de nadelen!
Maar ben het wel met je eens dat er EINDELIJK meer komt waar pure x64 ondersteuning in zit zonder het gezeik van 32-bit!
In de bedrijfswereld is er nog niet voor alles een 64bit support. Dit komt omdat alles 100% zeker moet draaien, en het duurt lang voor er een stabiele launch wordt bekomen van bijvoorbeeld simatic manager.
VMware is wel een oplossing
VMware is wel een oplossing
Het nadeel van programmas releasen in 64-bit is niet voor jou.Welke nadelen ervaar je dan?
Het is een nadeel voor de ontwikkelaar.
De ontwikkelaar moet namelijk kiezen.
a) Hij geeft alle potentiele klanten met een oud 32-bit OS op. Hij released in 64-bit formaat-only. En hij verliest geld door gemiste inkomsten.
b) Hij released zijn game in 64-bit formaat, *en* in 32-bit formaat. Dat is dubbel werk. Hij moet 2x testen. En hij kan nog steeds niet echt meer dan 3GB ram gebruiken, omdat het spel dan op 32-bit niet werkt.
Ik denk dat als je "high-tech graphics" gebruikt om je games te verkopen, dat het dan een goede keus is om naar 64-bit-only over te stappen.
Nadelen waren vroeger vooral drivers. Ook AMD en Nvidia willen gebruik maken van meer geheugen en andere instructies, maar 32-bit houdt hen ook tegen.
[programmeur-jargon-alert]
De voordelen zijn, atomaire instructies waar het er vroeger 2 waren (denk aan long's bij elkaar optellen). Dit zorgt voor makkelijker multithreaded kunnen programmeren zonder locks. Minder locks zorgt weer voor overhead, en dus snelheid.
[/programmeur-jargon-alert]
64-bit only is Windows nog lang niet, zelfs een aantal core applicaties (nee, niet de kernel, maar gewone applicaties) zijn nog 32-bit. En dat blijft jammer.
Iets als x86_64-nomultilib (zoals linux dat kent) is nog ver vooruit op Windows.
[programmeur-jargon-alert]
De voordelen zijn, atomaire instructies waar het er vroeger 2 waren (denk aan long's bij elkaar optellen). Dit zorgt voor makkelijker multithreaded kunnen programmeren zonder locks. Minder locks zorgt weer voor overhead, en dus snelheid.
[/programmeur-jargon-alert]
64-bit only is Windows nog lang niet, zelfs een aantal core applicaties (nee, niet de kernel, maar gewone applicaties) zijn nog 32-bit. En dat blijft jammer.
Iets als x86_64-nomultilib (zoals linux dat kent) is nog ver vooruit op Windows.
Een 32 bit systeem heeft voor 1 applicatie maximaal 2gb beschikbaar. Die 4 gb kan een applicatie alleen krijgen op een 64bit systeem.
Bij 32bit neemt System al 1gb in, dan nog je grafische kaart en andere randapparatuur die wat geheugen tussen de 3gb en 4gb inpikken. Plak er nog wat achtergrond Apps bij en je houdt zelfs minder dan 2gb over voor de game en gaat je systeem al redelijk swappen. Dat swappen kost je mega performance
64bit en meer dan 2gb voor een applicatie is voor grote games toch wel een must aan het worden
Bij 32bit neemt System al 1gb in, dan nog je grafische kaart en andere randapparatuur die wat geheugen tussen de 3gb en 4gb inpikken. Plak er nog wat achtergrond Apps bij en je houdt zelfs minder dan 2gb over voor de game en gaat je systeem al redelijk swappen. Dat swappen kost je mega performance
64bit en meer dan 2gb voor een applicatie is voor grote games toch wel een must aan het worden
Een 32-bits applicatie kan maxilmaal 4 GB geheugen adresseren.
In Windows was de afspraak dat een applicatie maximaal 2GB aan geheugen-ruimte zal ogen alloceren.
In WIndows wordt ongeveer 1GB aan adres-ruimte gereserveerd door het OS. Dit is waar hardware-registers en hardware-buffers leven. Ook de buffers om te communiceren met de videokaart zitten in deze 1GB. Zelfs als je videokaart (of andere hardware) meer dan 1GB vram aan boord heeft, dan nog wordt dit gedeelte van 1GB adrresruimte niet groter.
Wanneer je de LAA-flag gebruikt (Larger Address Awareness), dan zal het OS je applicatie 3GB laten alloceren. Dit helpt als je applicatie dicht tegen de 2GB ram aan zit. Bij een spel als Skyrim bv hielp dit echt. Echter, het OS heeft die ene GB aan adres-ruimte echt nodig. 4GB - 1GB = 3GB. 3GB is echt het maximale dat een 32-bit applicatie kan alloceren.
Met een 64-bit OS blijft deze beperking voor een 32-bits applicatie. Een 32-bits applicatie onder een 64-bits OS kan niet meer dan 3GB alloceren. Echter, je kunt meerdere 32-bits applicatie tegelijk hebben draaien, die allemaal 3GB ram tegelijk gebruiken. Zonder te swappen. Je hebt dus theoretisch wel wat winst als je een 64-bit OS draait met 32-bit applicaties.
Echter, er zijn niet zo veel applicaties die zo veel geheugen gebruiken dat ze samen over de 3.25GB gaan, en dat ze dan gaan swappen. Veel applicaties in de "achtergrond" draaien, terwijl je in de voorgrond een spel speelt, is niet echt een probleem. Zodra het spel wordt opgestart, worden de kleine applicaties uit-geswapt, zodat het grote spel alle ram kan krijgen. Dit uitswappen is eenmalig, die kleine applicaties doen toch niks. Dat swappen zal dus niet constant zijn, en niet al te veel performance verlies opleveren. Wat erg was, was als een applicatie meer geheugen gebruikte dan dat je had. Dan ging die applicatie zelf constant swappen tijdens het draaien. En dat merkte je. Dit wordt "thrashing" genoemd. Als een systeem begint te "thrashen" dan is het afgelopen met performance.
Het grote voordeel van 64-bit is als zowel applicatie als OS 64-bit zijn. Niet omdat de programmeurs luier kunnen zijn. Maar omdat resources (textures, models, etc) steeds gedetaileerder zijn, en dus steeds meer geheugen nodig hebben. Simpel.
In Windows was de afspraak dat een applicatie maximaal 2GB aan geheugen-ruimte zal ogen alloceren.
In WIndows wordt ongeveer 1GB aan adres-ruimte gereserveerd door het OS. Dit is waar hardware-registers en hardware-buffers leven. Ook de buffers om te communiceren met de videokaart zitten in deze 1GB. Zelfs als je videokaart (of andere hardware) meer dan 1GB vram aan boord heeft, dan nog wordt dit gedeelte van 1GB adrresruimte niet groter.
Wanneer je de LAA-flag gebruikt (Larger Address Awareness), dan zal het OS je applicatie 3GB laten alloceren. Dit helpt als je applicatie dicht tegen de 2GB ram aan zit. Bij een spel als Skyrim bv hielp dit echt. Echter, het OS heeft die ene GB aan adres-ruimte echt nodig. 4GB - 1GB = 3GB. 3GB is echt het maximale dat een 32-bit applicatie kan alloceren.
Met een 64-bit OS blijft deze beperking voor een 32-bits applicatie. Een 32-bits applicatie onder een 64-bits OS kan niet meer dan 3GB alloceren. Echter, je kunt meerdere 32-bits applicatie tegelijk hebben draaien, die allemaal 3GB ram tegelijk gebruiken. Zonder te swappen. Je hebt dus theoretisch wel wat winst als je een 64-bit OS draait met 32-bit applicaties.
Echter, er zijn niet zo veel applicaties die zo veel geheugen gebruiken dat ze samen over de 3.25GB gaan, en dat ze dan gaan swappen. Veel applicaties in de "achtergrond" draaien, terwijl je in de voorgrond een spel speelt, is niet echt een probleem. Zodra het spel wordt opgestart, worden de kleine applicaties uit-geswapt, zodat het grote spel alle ram kan krijgen. Dit uitswappen is eenmalig, die kleine applicaties doen toch niks. Dat swappen zal dus niet constant zijn, en niet al te veel performance verlies opleveren. Wat erg was, was als een applicatie meer geheugen gebruikte dan dat je had. Dan ging die applicatie zelf constant swappen tijdens het draaien. En dat merkte je. Dit wordt "thrashing" genoemd. Als een systeem begint te "thrashen" dan is het afgelopen met performance.
Het grote voordeel van 64-bit is als zowel applicatie als OS 64-bit zijn. Niet omdat de programmeurs luier kunnen zijn. Maar omdat resources (textures, models, etc) steeds gedetaileerder zijn, en dus steeds meer geheugen nodig hebben. Simpel.
max voor een app op 32bits os is 3GB als je /3GB als boot parameter mee geeft middels de boot.ini in windows XP
http://msdn.microsoft.com...ws/hardware/gg487508.aspx
Updated: February 9, 2005
Operating systems based on Microsoft Windows NT technologies have always provided applications with a flat 32-bit virtual address space that describes 4 gigabytes (GB) of virtual memory. The address space is usually split so that 2 GB of address space is directly accessible to the application and the other 2 GB is only accessible to the Windows executive software.
The 32-bit versions of the Windows 2000 Advanced Server and Windows NT Server 4.0, Enterprise Edition, operating systems were the first versions of Windows to provide applications with a 3-GB flat virtual address space, with the kernel and executive components using only 1 GB. In response to customer requests, Microsoft has expanded the availability of this support to the 32-bit version of Windows XP Professional and all 32-bit versions of Windows Server 2003.
Windows 2000 Memory Support. With Windows 2000 Professional and Server, the maximum amount of memory that can be supported is 4 GB (identical to Windows NT 4.0, as described later in this section). However, Windows 2000 Advanced Server supports 8 GB of physical RAM and Windows 2000 Datacenter Server supports 32 GB of physical RAM using the PAE feature of the IA-32 processor family, beginning with Intel Pentium Pro and later.
Windows XP Professional and Windows Server 2003 Memory Support. The maximum amount of memory that can be supported on Windows XP Professional and Windows Server 2003 is also 4 GB. However, Windows Server 2003, Enterprise Edition supports 32 GB of physical RAM and Windows Server 2003, Datacenter Edition supports 64 GB of physical RAM using the PAE feature.
The virtual address space of processes and applications is still limited to 2 GB unless the /3GB switch is used in the Boot.ini file. When the physical RAM in the system exceeds 16 GB and the /3GB switch is used, the operating system will ignore the additional RAM until the /3GB switch is removed. This is because of the increased size of the kernel required to support more Page Table Entries. The assumption is made that the administrator would rather not lose the /3GB functionality silently and automatically; therefore, this requires the administrator to explicitly change this setting.
The /3GB switch allocates 3 GB of virtual address space to an application that uses IMAGE_FILE_LARGE_ADDRESS_AWARE in the process header. This switch allows applications to address 1 GB of additional virtual address space above 2 GB.
The virtual address space of processes and applications is still limited to 2 GB, unless the /3GB switch is used in the Boot.ini file. The following example shows how to add the /3GB parameter in the Boot.ini file to enable application memory tuning:
http://msdn.microsoft.com...ws/hardware/gg487508.aspx
Updated: February 9, 2005
Operating systems based on Microsoft Windows NT technologies have always provided applications with a flat 32-bit virtual address space that describes 4 gigabytes (GB) of virtual memory. The address space is usually split so that 2 GB of address space is directly accessible to the application and the other 2 GB is only accessible to the Windows executive software.
The 32-bit versions of the Windows 2000 Advanced Server and Windows NT Server 4.0, Enterprise Edition, operating systems were the first versions of Windows to provide applications with a 3-GB flat virtual address space, with the kernel and executive components using only 1 GB. In response to customer requests, Microsoft has expanded the availability of this support to the 32-bit version of Windows XP Professional and all 32-bit versions of Windows Server 2003.
Windows 2000 Memory Support. With Windows 2000 Professional and Server, the maximum amount of memory that can be supported is 4 GB (identical to Windows NT 4.0, as described later in this section). However, Windows 2000 Advanced Server supports 8 GB of physical RAM and Windows 2000 Datacenter Server supports 32 GB of physical RAM using the PAE feature of the IA-32 processor family, beginning with Intel Pentium Pro and later.
Windows XP Professional and Windows Server 2003 Memory Support. The maximum amount of memory that can be supported on Windows XP Professional and Windows Server 2003 is also 4 GB. However, Windows Server 2003, Enterprise Edition supports 32 GB of physical RAM and Windows Server 2003, Datacenter Edition supports 64 GB of physical RAM using the PAE feature.
The virtual address space of processes and applications is still limited to 2 GB unless the /3GB switch is used in the Boot.ini file. When the physical RAM in the system exceeds 16 GB and the /3GB switch is used, the operating system will ignore the additional RAM until the /3GB switch is removed. This is because of the increased size of the kernel required to support more Page Table Entries. The assumption is made that the administrator would rather not lose the /3GB functionality silently and automatically; therefore, this requires the administrator to explicitly change this setting.
The /3GB switch allocates 3 GB of virtual address space to an application that uses IMAGE_FILE_LARGE_ADDRESS_AWARE in the process header. This switch allows applications to address 1 GB of additional virtual address space above 2 GB.
The virtual address space of processes and applications is still limited to 2 GB, unless the /3GB switch is used in the Boot.ini file. The following example shows how to add the /3GB parameter in the Boot.ini file to enable application memory tuning:
Je hebt ook PAE nog waarmee je OS grotere hoeveelheden RAM dan 4GB kan gebruiken, + wat faciliteiten die OSen aanbieden om je applicatie meer dan 2GB RAM te laten gebruiken.. (denk aan AWE etc) dus puur meer RAM nodig hebben zal niet de enige reden zijn lijkt me.
Wat er zijn mensen op de BF3 fora die zeuren dat BF3 zwaar is!? Hebben die mensen überhaupt wel door wat BF3 is? BF3 is het paradepaartje van Dice en één grote showcase van een engine die de komende 5 jaar aan de top moet staan. Vanaf het begin van de ontwikkeling was al duidelijk dat het spel alleen op zware systemen zou draaien.
Als ik een engine zou showcasen dan zou ik niet (net zoals in crysis) er voor zorgen dat deze maar op 2% (weinig dus, 2 is een random getal) van de systemen werkt.
Steam Survey April 2012.
http://store.steampowered.com/hwsurvey
54% van de gamers op Steam gebruiken Windows 7 64-bit. Plus 6% heeft 64-bit Vista.
30% heeft 5GB or higher ram. 24% heeft 4GB ram.
50% heeft een DuoCore cpu. 38% heeft een QuadCore cpu.
39% have DirectX10. 42% have DirectX11.
Iets meer dan jouw schatting van 2%.
http://store.steampowered.com/hwsurvey
54% van de gamers op Steam gebruiken Windows 7 64-bit. Plus 6% heeft 64-bit Vista.
30% heeft 5GB or higher ram. 24% heeft 4GB ram.
50% heeft een DuoCore cpu. 38% heeft een QuadCore cpu.
39% have DirectX10. 42% have DirectX11.
Iets meer dan jouw schatting van 2%.
[Reactie gewijzigd door gryz op 23 mei 2012 10:37]
Door dit soort keuzes worden gamers wel min of meer gedwongen om betere hardware te kopen, waardoor het gemiddelde niveau van alle game-pcs omhoog gaat. Betere ervaring voor de gebruikers en meer mogelijkheden voor developers.
Crysis was een goede zet, iedereen ziet die game (en dus engine) grafisch gezien nog steeds als een van de beste ter wereld.
Crysis was een goede zet, iedereen ziet die game (en dus engine) grafisch gezien nog steeds als een van de beste ter wereld.
Er moet een keuze gemaakt worden tussen mogelijkheden van een engine en hardware die nodig is. Ik vind dat games niet strict moeten houden aan het supporteren van low performance hardware. Kun je net zo goed dezelfde engine 20 jaar gebruiken.
Als je niet wilt upgraden elke 2 jaar ofzo is het beter om naar een console over te gaan waar de graphics en mogelijkheden minder zijn.
Ik vind het nogal spijtig dat bevoorbeeld vorig jaar de meeste TPV voor Second Life de support droppen voor CPUs zonder SSE2 en veel mensen klaagde daar over. We hebben hier over een instructie set van de Pentium 4.
Toen TPVs PowerPC Macs stopte supporteren waren er ook mensen die klaagde.
De hardware veranderd snel, ze worden sneller, soms energie zuiniger, en in sommige gevallen kleiner. Waarom zouden spellen rekening moeten houden met low end of oude hardware? Beetje zoals vragen aan de dev om je G1 de laatste NOVA te ondersteunen.
Als je niet wilt upgraden elke 2 jaar ofzo is het beter om naar een console over te gaan waar de graphics en mogelijkheden minder zijn.
Ik vind het nogal spijtig dat bevoorbeeld vorig jaar de meeste TPV voor Second Life de support droppen voor CPUs zonder SSE2 en veel mensen klaagde daar over. We hebben hier over een instructie set van de Pentium 4.
Toen TPVs PowerPC Macs stopte supporteren waren er ook mensen die klaagde.
De hardware veranderd snel, ze worden sneller, soms energie zuiniger, en in sommige gevallen kleiner. Waarom zouden spellen rekening moeten houden met low end of oude hardware? Beetje zoals vragen aan de dev om je G1 de laatste NOVA te ondersteunen.
BF3 draait goed voor mij, het is ook prachting graphics gewijs.
Ik zat vaak tegen mijn 6 GB aan op windows 7 met games en andere zooi dat draait, ben nu naar 12GB gaan.
Je zegt dat er geen patches zijn...weet je wel hoeveel updates er al zijn geweest voor bugs en balance fixes?
Des te mooier en groter games worden des te meer is er vereist. Toen Crysis uitkwam was iedereen ook van WOW WTF ZO ZWAAR.
Frostbite is een engine met veel potentieel, denk aan zeer grote maps met veel destructie.
Ik vind rockstar erger dan EA, GTA4 was de slechtste console port ooit, veel resources nodig voor eigenlijk relatief simple graphics. LA Noire was performance gewijs beter maar had nog dingen zoals "PLEASE DONT TURN OFF YOUR CONSOLE". Ik ben niet zeker wie de PC port had gedaan voor LA Noire sinds dat Team Bundie failliet was verklaard.Rockstar is de uitgever.
Ik ben niet akkoord met sommige praktijken van EA maar Battlefield is leuk.
De overstap naar Windows 7 64 bit is toch geen probleem als je al op win7 x86 zit hardware gewijs. Wordt je 4GB te minste benut.(Spijtig genoeg toen ik in retail werkte veel laptops zien voorbij komen met x86 en 4+ GB ram.). Processors die x86-64 ondersteunen bestaan al jaren.
Ik zie niet echt een nut om x86 te draaien tenzij je legacy apps moet draaien in een bedrijf, maar tegenwoordig gebruiken ze daar al andere manieren voor.
Ik zat vaak tegen mijn 6 GB aan op windows 7 met games en andere zooi dat draait, ben nu naar 12GB gaan.
Je zegt dat er geen patches zijn...weet je wel hoeveel updates er al zijn geweest voor bugs en balance fixes?
Des te mooier en groter games worden des te meer is er vereist. Toen Crysis uitkwam was iedereen ook van WOW WTF ZO ZWAAR.
Frostbite is een engine met veel potentieel, denk aan zeer grote maps met veel destructie.
Ik vind rockstar erger dan EA, GTA4 was de slechtste console port ooit, veel resources nodig voor eigenlijk relatief simple graphics. LA Noire was performance gewijs beter maar had nog dingen zoals "PLEASE DONT TURN OFF YOUR CONSOLE". Ik ben niet zeker wie de PC port had gedaan voor LA Noire sinds dat Team Bundie failliet was verklaard.Rockstar is de uitgever.
Ik ben niet akkoord met sommige praktijken van EA maar Battlefield is leuk.
De overstap naar Windows 7 64 bit is toch geen probleem als je al op win7 x86 zit hardware gewijs. Wordt je 4GB te minste benut.(Spijtig genoeg toen ik in retail werkte veel laptops zien voorbij komen met x86 en 4+ GB ram.). Processors die x86-64 ondersteunen bestaan al jaren.
Ik zie niet echt een nut om x86 te draaien tenzij je legacy apps moet draaien in een bedrijf, maar tegenwoordig gebruiken ze daar al andere manieren voor.
Zeer grote maps dat weten we anders nog helemaal niet! Kijk eens naar de maps van Battlefield 3. Dit zijn de kleinste maps in de geschiedenis van Battlefield! Ik ben niet erg ondere de indruk van "dé frostbite engine". Heb wel betere engine's voor bij zien komen.
Ze kunnen groter in de engine.
Ik vind de grote van de maps ok, zou leuk zijn als er maps te grote van Chernarus(Dayz mod voor Arma 2).
Ik vind de grote van de maps ok, zou leuk zijn als er maps te grote van Chernarus(Dayz mod voor Arma 2).
Dit komt omdat de machine's dus geen grotere maps aankunnen vanwege, jawel, RAM geheugen gebrek. En constant alles van de harde schijf swappen dropt de performance naar nul.Zeer grote maps dat weten we anders nog helemaal niet! Kijk eens naar de maps van Battlefield 3. Dit zijn de kleinste maps in de geschiedenis van Battlefield! Ik ben niet erg ondere de indruk van "dé frostbite engine". Heb wel betere engine's voor bij zien komen.
trouwens @ Skye Menjou
LA Noire gebruikt niet de RAGE engine van Rockstar maar een eigen engine die ze al hadden voordat Rockstar zich ging bemoeien met het project.
Dat wist ik wel, maar Rockstar Leeds is de gene die het naar PC geport heeft.[...]
Dit komt omdat de machine's dus geen grotere maps aankunnen vanwege, jawel, RAM geheugen gebrek. En constant alles van de harde schijf swappen dropt de performance naar nul.
trouwens @ Skye Menjou
LA Noire gebruikt niet de RAGE engine van Rockstar maar een eigen engine die ze al hadden voordat Rockstar zich ging bemoeien met het project.
De performance is niet slecht maar het is een beetje spijtig dat ze die kleine foutjes er in laten.
Wat bedoel je met "afnemer van DICE Frostbite"? EA is slechts de uitgever, alles wordt gewoon in Stockholm gemaakt en deze keuze staat dan ook helemaal los van EA.
En wat je opmerking over geheugengebruik betreft, als je in die gedachte blijft hangen dan krijgen developers natuurlijk nooit de mogelijkheid om meer resources aan te spreken. Daarnaast is een 7200rpm drive veel te traag om de enorme assets van tegewoordig snel genoeg in te laden.
En wat je opmerking over geheugengebruik betreft, als je in die gedachte blijft hangen dan krijgen developers natuurlijk nooit de mogelijkheid om meer resources aan te spreken. Daarnaast is een 7200rpm drive veel te traag om de enorme assets van tegewoordig snel genoeg in te laden.
Zoals aangegeven hebben 64-bits games toegang tot meer werkgeheugen. Dit heeft meerdere voordelen. Ten eerste is er natuurlijk de snelheidswinst zodra het spel geladen is. Dit houdt in dat bijvoorbeeld de quick-save / quick-load functie een stuk vlotter wordt.
Daarbij wordt er met meer werkgeheugen minder van de harde schijf geswapt. Dit geeft een flinke prestatieverbetering. Als bijkomend voordeel kunnen spellen in de toekomst beter op SSD's worden geïnstalleerd. De game wordt veel sneller in het geheugen geladen terwijl de SSD minder lijdt doordat er minder gelezen en geschreven wordt van / naar het wisselbestand.
Een beetje machine heeft vandaag de dag toch wel 4 GB werkgeheugen aan boord. PC's die voor gamen worden gebruikt hebben in de regel toch wel meer RAM geïnstalleerd. Een geheugenupgrade kost meestal niet zo veel.
Vandaar een logische keus van Dice om in de toekomst enkel 64-bit games uit te brengen.
Daarbij wordt er met meer werkgeheugen minder van de harde schijf geswapt. Dit geeft een flinke prestatieverbetering. Als bijkomend voordeel kunnen spellen in de toekomst beter op SSD's worden geïnstalleerd. De game wordt veel sneller in het geheugen geladen terwijl de SSD minder lijdt doordat er minder gelezen en geschreven wordt van / naar het wisselbestand.
Een beetje machine heeft vandaag de dag toch wel 4 GB werkgeheugen aan boord. PC's die voor gamen worden gebruikt hebben in de regel toch wel meer RAM geïnstalleerd. Een geheugenupgrade kost meestal niet zo veel.
Vandaar een logische keus van Dice om in de toekomst enkel 64-bit games uit te brengen.
Er is meer geheugen te adresseren, waardoor games groter kunnen worden óf mooier.Welke voordelen? EA kennende (afnemer van DICE Frostbite) is dit niet meer dan een groot excuus om games nog meer te rushen, met mogelijk nog meer onnodig geheugengebruik/leaks, alleen maar om te kunnen cashen.
Daarnaast kan dan ook alle code alléén in 64 bits gecompileerd worden (verkleind de bestandsgrootte, je hebt alleen x64 libraries nodig e.d.), wat ook weer voor niks en gratis zo'n 20% extra performance oplevert tov 32 bits, doordat er meer bandbreedte beschikbaar is. Maar ja, vroeger was 640k ook voldoende... Maar als jij dat allemaal niet wilt, mij best hoor.
[Reactie gewijzigd door CptChaos op 25 mei 2012 10:38]
Volgens die logica zouden we nooit meer dan 1 kb geheugen nodig gehad moeten hebben, omdat het anders een excuus zou zijn om games te rushen.
32-bit apps hebben een limiet van 2gb (niet 4gb) in de software, met een speciale aanpassing kan je er 3gb van maken. 32-bit OS kunnen maximaal 4gb aanspreken, alhoewel dat niet altijd het geval is.
Het probleem hier is dat de geheugen limiet al een probleem was in 2004. Nu zijn we 8 jaar later en wordt de limiet nog steeds geforceerd op games omdat ondanks het feit dat bijna elke PC 64 bit is consumenten nog steeds 32 bit OS gebruiken. Ook consoles werken hieraan mee met de extreem lage geheugens hierop.
Naar mijn mening kan de industrie wel een 'upgrade' gebruiken. Het feit is namelijk ook dat het gebrek aan geheugen makkelijk crashes kan veroorzaken (zoals Skyrim al liet zien). De enige andere optie is om games zoveel mogelijk te limiteren.
Zouden we in 2020 nog steeds met een 2gb limiet moeten werken? Net zoals de ontwikkeling van Atari 2600 naar de NES / SNES / PSX / PS2 / etc is meer geheugen echt geen slechte zaak. Zoals gezegd, anders zouden we nog steeds games spelen op een 2600.
32-bit apps hebben een limiet van 2gb (niet 4gb) in de software, met een speciale aanpassing kan je er 3gb van maken. 32-bit OS kunnen maximaal 4gb aanspreken, alhoewel dat niet altijd het geval is.
Het probleem hier is dat de geheugen limiet al een probleem was in 2004. Nu zijn we 8 jaar later en wordt de limiet nog steeds geforceerd op games omdat ondanks het feit dat bijna elke PC 64 bit is consumenten nog steeds 32 bit OS gebruiken. Ook consoles werken hieraan mee met de extreem lage geheugens hierop.
Naar mijn mening kan de industrie wel een 'upgrade' gebruiken. Het feit is namelijk ook dat het gebrek aan geheugen makkelijk crashes kan veroorzaken (zoals Skyrim al liet zien). De enige andere optie is om games zoveel mogelijk te limiteren.
Zouden we in 2020 nog steeds met een 2gb limiet moeten werken? Net zoals de ontwikkeling van Atari 2600 naar de NES / SNES / PSX / PS2 / etc is meer geheugen echt geen slechte zaak. Zoals gezegd, anders zouden we nog steeds games spelen op een 2600.
Mocht een 32bit programma onder Windows echt 4GB kunnen aanspreken had je voorlopig nog een punt: 4Gb is zat voor games. Maar dat is niet zo: in windows hebben 32b apps slechts toegang tot 2GB geheugen. Dat wordt al erg snel erg krap: een degelijke RTS zoals Starcraft 2 bv (gemaakt door Blizzard, toch geen developer die dingen rusht en niet afwerkt) dlirt al erg vaak met de 2GB grens.
Je ziet nu steeds vaker 64bit patches voor games uitkomen, zeer goede ontwikkeling! 8GB werkgeheugen is steeds meer de standaard aan het worden. Het Windows XP tijdperk eindelijk voorbij?
8GB de standaard? Bijna alle desktop-machines tot 600 Euro die in de winkels staan, komen met 2 tot 6GB RAM, het gros van de laptops tot 1000 Euro waar je misschien een game op kan spelen komen met 2-4GB standaard en veel modellen kan je niet eens upgraden naar 8GB.
Snap trouwens je link niet naar Windows XP; afgezien van DX9-ondersteuning, kan je ook gewoon modernere Windows-OS'en kopen die 32bits zijn en dus ook niet meer dan xx GB RAM kunnen alloceren.
Snap trouwens je link niet naar Windows XP; afgezien van DX9-ondersteuning, kan je ook gewoon modernere Windows-OS'en kopen die 32bits zijn en dus ook niet meer dan xx GB RAM kunnen alloceren.
nou neej. 8gb is wel redelijk standaart voor pc.s van 500-800 euro.
ook komt inderdaad wel eens 6gb voo
ook komt inderdaad wel eens 6gb voo
In navolging van mijn post hierboven en jouw antwoord: PC's kant & klaar tot 650 Euro met meer dan 6GB geheugen: 10 stuks dus...
[Reactie gewijzigd door MAX3400 op 23 mei 2012 09:16]
32 bit ondersteunt maximaal 3,2 gb aan ram dus met 4gb heb je al profijt van een x64 systeem (is dan toch weer 25% van je totale ram erbij).
Je hebt niet goed gezocht. Een pc met 6+ GB begint blijkbaar al bij 400 euro.
Al die machines kunnen allemaal een 64-bit OS draaien, ook als ze 2-4GB aan boord hebben.
Ook is het zo dat een 32bit executable maximaal 2GB geheugen kan gebruiken. Op een 64bit OS met toch maar 4GB geheugen heb je dus toch meer geheugen voor de applicatie. Verder is het zo dat volgens de steam hardware survey nog maar 20% van de systemen 32bits zijn, je kunt er ook wel van uit gaan dat dit ook ongeveer de 20% oudste/langzaamste systemen zijn. Niet de doelgroep van nieuwe frostbite games dus.
Geheugen vandaag de dag kost geen fluit. Daarnaast, als ik de Best Buy Guide hier op Tweakers bekijk zie ik ook 8GB terugkomen. En ja, het is de high-end configuratie, maar de prijs voor 8GB is nog geen ¤50 en dus makkelijk toepasbaar op elke configuratie.
Klopt geheugen kost geen fluit, maar in veel kant en klare systemen worden alle geheugenbanks gevuld met 'kleine' reepjes waardoor je dus niet ff kunt upgraden zonder al het geheugen te moeten vervangen, en dat laatste is sowieso niet iets dat een doorsnee consument zal doen..
In het windows XP tijdperk was er erg matige driverondersteuning voor 64-bit windows XP.
Mede daarom gebruikte bijna niemand het, en was het dus niet interessant voor game developers om daar ook maar enigszins rekening mee te houden.
Nu zitten we in een tijdperk waar een beetje pc al 4-16GB geheugen aan boord heeft, ook laptops hebben hebben vaak wel meer dan 4GB geheugen aan boord, en zijn dan ook uitgerust met een X64 licentie van Windows.
Dus nu X64 gemeengoed begint te worden, zoals het voor de meeste tweakers al jaren is, word er ook steeds meer gebruik van gemaakt. Goede zaak dus.
Mede daarom gebruikte bijna niemand het, en was het dus niet interessant voor game developers om daar ook maar enigszins rekening mee te houden.
Nu zitten we in een tijdperk waar een beetje pc al 4-16GB geheugen aan boord heeft, ook laptops hebben hebben vaak wel meer dan 4GB geheugen aan boord, en zijn dan ook uitgerust met een X64 licentie van Windows.
Dus nu X64 gemeengoed begint te worden, zoals het voor de meeste tweakers al jaren is, word er ook steeds meer gebruik van gemaakt. Goede zaak dus.
Ik moet eerlijke zeggen dat ik nog nooit tegen een probleem was aangelopen met de hardware of software die ik had, en XP x64 draaide bij mij als een tierelier.
De 4GB limitatie van 32-bits adres-ruimte is ook geen probleem voor jou en andere gebruikers. Het is een probleem voor ontwikkelaars. Die moeten door hoepels springen, en concessies doen, om hun games en applicaties koste-wat-het-kost binnen de 3GB te houden.
Veel voorkomend is toch wel 4GB, minimaal. En laptop geheugen is veelal gemakkelijk om te vervangen. En ja, ik spreek uit ervaring.
Voor echte gamers is 6GB+ de standaard, meestal de PCs met 6GB zijn zo omdat ze trippel channel geheugen hebeen en ze niet 2x4 of 4x2 GB kunnen steken en 12 te duur is.
Mijn desktop heeft 12 GB, mijn laptop van 830 euro heeft 8GB geheugen en een AMD 6770M.
Het gaat hier wel over games, laptops zijn meestal geen game toestellen tenzij je naar een hogere prijs klasse gaat.
Mijn desktop heeft 12 GB, mijn laptop van 830 euro heeft 8GB geheugen en een AMD 6770M.
Het gaat hier wel over games, laptops zijn meestal geen game toestellen tenzij je naar een hogere prijs klasse gaat.
Ik heb zelf al jaren geen PC's die minder dan 16 GB geheugen hebben.
Zelfs laptops hebben tegenwoordig al vlug 8 GB geheugen.
Ik gebruik dan ook al sinds XP 64-bits besturingssystemen.
Zelfs laptops hebben tegenwoordig al vlug 8 GB geheugen.
Ik gebruik dan ook al sinds XP 64-bits besturingssystemen.
Vreemd inderdaad dat ondanks de lage RAM prijs zo weinig RAM in kant en klare systemen wordt gestopt. Als je applicaties het niet gebruiken, dan gebruikt je OS het om meer recent gelezen files gecached te houden dus, zoiezo wordt je systeem er dus sneller van, vooral als je hem niet iedere keer uit zet. Als je nu een niewe PC koopt (of bouwt) is het gewoon suf als je er geen 16GB in stopt gezien de prijzen van RAM op het moment.
Als je zo veel geld betaalt voor een PC met 2 GB geheugen ben je gewoon niet slim bezig. Stel je systeem gewoon zelf samen; dan bespaar je direct de kosten van de Windows OEM licentie.
Van dat geld kun je wel 8 GB in je PC proppen.
Van dat geld kun je wel 8 GB in je PC proppen.
Je weet dat je zelf het antwoord geeft op jouw eigen vraag? De 32 bits limiet is trouwens 3,2768GB (3,25GiB).Snap trouwens je link niet naar Windows XP; afgezien van DX9-ondersteuning, kan je ook gewoon modernere Windows-OS'en kopen die 32bits zijn en dus ook niet meer dan xx GB RAM kunnen alloceren.
RAM is belachelijk goedkoop op het moment. 8GB kun je voor 40 euro krijgen. OEM fabrikanten beginnen dit ook steeds meer door te krijgen en mensen die zelf hun PC bouwen (een niet insignificant deel van gamers) heeft geen reden meer om minder dan 8gb in te bouwen.
Dit kan ik inderdaad alleen maar toejuichen, ik snap ook niet waarom er nog 32 bit versies werden verkocht van windows. Hoe meer 64 bit only, hoe beter!
Omdat MS ook nog wilde verkopen aan van die mensen die graag een nieuwer OS wilde hebben op hun oude hardware, tja en waarom dan niet die 32bit versie uitleveren als je die toch hebt liggen..
Helaas is er van Windows 8 ook nog steeds een 32bits versie...
Helaas is er van Windows 8 ook nog steeds een 32bits versie...
Men loopt altijd achter op de technologie. Hoe lang men bijvoorbeeld met CDs is blijven werken. Op het einde plaatste men een game liever op 5 CDs dan op 1 DVD omdat er nog enkele % van de potentiele gamers geen DVD speler hadden.
Je kan een Windows 7 key gebruiken voor beide 64 als 32 bit, je moet alleen de DVD/ISO hebben.
Ik denk wel dat het een goede zet is, wat is anders het nut om een x64 systeem te gebruiken voor de gemiddelde gamer.
Ergens moet toch de omslag komen dat we x86 verlaten voor x64 niet?
Ergens moet toch de omslag komen dat we x86 verlaten voor x64 niet?
goede keuze van DICE.
bij BF3 moesten oude systemen een hack/work around doen om genoeg intern geheugen vrij te maken.
was ook grote reden waarom veel bf3 games crashde.
zat later in een patch verwerkt dacht ik?
bij BF3 moesten oude systemen een hack/work around doen om genoeg intern geheugen vrij te maken.
was ook grote reden waarom veel bf3 games crashde.
zat later in een patch verwerkt dacht ik?
Dat is dan toch kip & ei?
We maken wel een 32-bit game, hangen daar bepaalde minimale system-specs aan vast en als het dan toch niet werkt, gaan we allerlei vreemde/rare workarounds documenteren om het wel draaiend te houden? En nee, voor zover ik me kan herinneren zit er geen structurele oplossing in een recente patch.
We maken wel een 32-bit game, hangen daar bepaalde minimale system-specs aan vast en als het dan toch niet werkt, gaan we allerlei vreemde/rare workarounds documenteren om het wel draaiend te houden? En nee, voor zover ik me kan herinneren zit er geen structurele oplossing in een recente patch.
Ben benieuwd op wat voor manieren DICE dat extra beetje geheugen gaat gebruiken in hun games.
Het zou kunnen dienen voor beter graphics (meer streams tegelijkertijd) of het kan gewoon puur gebruikt worden om de code beter en soepeler te kunnen laten lopen door meer geheugen?
Het zou kunnen dienen voor beter graphics (meer streams tegelijkertijd) of het kan gewoon puur gebruikt worden om de code beter en soepeler te kunnen laten lopen door meer geheugen?
Persoonlijk denk ik dat het meer zal zijn om de games sneller / soepeler van level naar level te laten lopen omdat je dan al een compleet level in het geheugen kan laden.
Nu moet dit nog vanaf de harddisk wat een enorme bottleneck is.
Nu moet dit nog vanaf de harddisk wat een enorme bottleneck is.
Heeft zeker ook te maken met de komst van DDR4 rond die tijd? Hoe zit het dan met DDR4 en 32-bit systemen, zal tegen die tijd 64 bit al de standaard zijn?
Systemen zijn, voor consumenten, al sinds de AMD Athlons 64-bit ready alleen vanwege allerlei legacy applicaties en niet progressief programmeren, draaien we al 15 jaar 32-bits meuk.
De standaard is er dus al decennia, bijbehorende OS'en zijn er ook al een jaar of 10 alleen geen gamestudio die er gebruikt van durfde te maken.
De standaard is er dus al decennia, bijbehorende OS'en zijn er ook al een jaar of 10 alleen geen gamestudio die er gebruikt van durfde te maken.
http://en.wikipedia.org/wiki/Athlon_64
The Athlon 64 is an eighth-generation, AMD64-architecture microprocessor produced by AMD, released on September 23, 2003.
Zeven en een half jaar geleden dus.
We hebben nog maar sinds 7.5 jaar een mainstream CPU met een 64-bit architectuur. Niet 15 jaar.
The Athlon 64 is an eighth-generation, AMD64-architecture microprocessor produced by AMD, released on September 23, 2003.
Zeven en een half jaar geleden dus.
We hebben nog maar sinds 7.5 jaar een mainstream CPU met een 64-bit architectuur. Niet 15 jaar.
Eh... was de Pentium 1 niet al 64-bit?
Er zijn ook Pentium 1 servers met 64-bit moederborden en -sloten.
Er zijn ook Pentium 1 servers met 64-bit moederborden en -sloten.
De processor was het dan blijkbaar niet.
Itanium (2001) was eerste 64 bit CPU van Intel volgens deze WiKi
http://nl.wikipedia.org/wiki/Lijst_van_Intel-processors
Hoewel er wel CPU's waren met EM64T blijkbaar:
http://nl.wikipedia.org/wiki/EM64T
Sun Ultrasparc is dan hun eerste 64 bit aangekondigd 2005.
En PowerPC Processor is met G5 uit 2003 dan ook 64 bit geworden.
http://nl.wikipedia.org/wiki/PowerPC
Itanium (2001) was eerste 64 bit CPU van Intel volgens deze WiKi
http://nl.wikipedia.org/wiki/Lijst_van_Intel-processors
Hoewel er wel CPU's waren met EM64T blijkbaar:
http://nl.wikipedia.org/wiki/EM64T
Sun Ultrasparc is dan hun eerste 64 bit aangekondigd 2005.
En PowerPC Processor is met G5 uit 2003 dan ook 64 bit geworden.
http://nl.wikipedia.org/wiki/PowerPC
huh? wat heeft DDR4 er nu mee te maken? DDR3 werkt perfect en is in grote 'formaten' te krijgen voor elk 64bits systeem.. DDR4 heeft er dus geen bal mee te maken..
DICE zegt toegang te willen krijgen tot meer geheugen, in 2013. Aangezien DDR4 bijna af is en rond die tijd verschijnt, kan dit iets zijn dat ze mee hebben genomen in hun wens. Dat vroeg ik me dus af, evenals de link met 64-bits architectuur.
Mocht ook wel eens tijd worden. 64bit CPU's (64bit ondersteunen) bestaan ook al 10 jaar (of iets meer?)...
[Reactie gewijzigd door guido09 op 23 mei 2012 09:11]
Zeven en een half jaar. September 2003.
Dat is AMD. Intel heeft ze al veel langer.
Dat waren dure CPUs voor servers. De eerste mainstream 64-bit CPUs waren de Athlon64s.
Reclame? games gaan "zeker" (sarcasme) gebruik maken van Metro...Andersson noemt het een goede kans om te upgraden naar Windows 8,
Hmm de eerste game die ik ooit heb gezien als 64-bit versie van toch wel de eerste Crysis, voor de rest moet ik wel zeggen dat 32-bit echt afgeschaafd moet worden, dat is echt achterhaald.
Sorry, maar 1 van de eerste grote commerciele games is toch UT2004 geweest, das lang voor Crysis..
Far Cry had een 64-bit patch in 2004 (versie 1.3 als ik me niet vergis).
Is dit een hint dat de komende generatie consoles ook 64-bit CPU's gaan bevatten?
Nee... zowel de PS3 als de XBOX360 hebben al CPU's aan boord die 64-bit extensies ondersteunen voor bepaalde zaken. Het is alleen niet praktisch toepasbaar als je het hebt over porten van games tussen consoles & 64-bit PC's.
Het gaat om een 64 bits address space. Geen van de consoles ondersteunt dat, dus je opmerking is totaal niet van toepassing. Overigens denk ik dat het weldegelijk voor de hand ligt dat de volgende generaties van consoles een 64 bits address space gaan ondersteunen.
De Nintendo 64 (vandaar de naam) had al een 64-bit cpu.
Dit was meer dan 15 jaar geleden, ik zat toen nog op school
De Playstation 1 was toen nog niet eens op de markt verschenen.
Het gaat echter niet om de CPU, het gaat om het gebruik van geheugen via 64-bit adressering, waardoor je meer dan 2 GB kan gebruiken per applicatie en 3,25 GB totaal.
Dit was meer dan 15 jaar geleden, ik zat toen nog op school
De Playstation 1 was toen nog niet eens op de markt verschenen.
Het gaat echter niet om de CPU, het gaat om het gebruik van geheugen via 64-bit adressering, waardoor je meer dan 2 GB kan gebruiken per applicatie en 3,25 GB totaal.
Op dit item kan niet meer gereageerd worden.
Onderwerpen
© 1998 - 2013 Tweakers.net B.V. onderdeel van De Persgroep, ook uitgever van Computable.nl, Autotrack.nl en Carsom.nl • Hosting door True
