Google: nieuwe 64bit-versie Chrome is kwart sneller

Google heeft een 64bit-testversie van Google Chrome uitgebracht. De 64bit-versie van de browser, die momenteel enkel via de release-kanalen voor testversies te verkrijgen is, is volgens Google niet alleen veiliger en stabieler, maar vooral sneller.

De versie is op dit moment enkel nog te verkrijgen via de dev- en canary-channels, maar moet uiteindelijk zijn weg vinden naar het bèta-kanaal en uiteindelijk het kanaal voor normale eindgebruikers, stelt Google. Binnen welke termijn dat zal gebeuren, is nog niet bekend.

Vooralsnog is de 64bit-versie enkel beschikbaar voor gebruikers van Windows 7 en 8; het is onduidelijk wanneer de Linux- en OS X-versies van de populaire browser eveneens ondersteuning voor 64bit krijgen.

Volgens Google is de 64bits versie onder meer sneller, doordat gebruik kan worden gemaakt van de 64bit-instructieset. Gemiddeld presteert de 64bit-versie op dat gebied 25 procent beter, stelt Google. Vooral op websites met veel grafische content zou de 64bit-versie zijn 32bit-broer voorbij streven.

Daarnaast is de nieuwe versie stabieler; de 64bit-versie zou nog maar half zo vaak crashen als gevolg van fouten bij het renderen. Ook de veiligheid zou moeten zijn verbeterd, onder meer doordat onder Windows 8 een veiligere versie van address space layout randomization kan worden gebruikt. Ook aanvallen die gebruikmaken van jit-spraying, waarbij de just-in-time-compiler wordt misbruikt, zouden nu minder kans moeten maken.

Reacties (155)

[Nimrodx]

Wat is nu 25% sneller geworden? De interface van Chrome? Het renderen van HTML? Het uitvoeren van JavaScript? Het is me totaal onduidelijk wat nu sneller is geworden. Daarnaast spreekt het artikel over een enorme winst bij websites met grafische content. Gaat het hier over flash/canvas/WebGL?

Ik heb het gevoel dat hier valse verwachtingen worden geschept.

[drZymo]

Ik vroeg het me ook al af. Het originele artikel laat iets meer info los:

64-bit allows us to take advantage of the latest processor and compiler optimizations, a more modern instruction set, and a calling convention that allows more function parameters to be passed quickly by registers. As a result, speed is improved, especially in graphics and multimedia content, where we see an average 25% improvement in performance.

Dus die 25% performance boost is alleen met graphics en multimedia content. Niet overall.

[Reactie gewijzigd door drZymo op 23 juli 2024 07:11]

[S-Cript]

Exact,
Niveau van de tweakers nieuws begint steeds meer op #adv te lijken

Dus graag een update :sneller dan wat?

[Verwijderd]

Wat is nu 25% sneller geworden? De interface van Chrome? Het renderen van HTML? Het uitvoeren van JavaScript? Het is me totaal onduidelijk wat nu sneller is geworden. Daarnaast spreekt het artikel over een enorme winst bij websites met grafische content. Gaat het hier over flash/canvas/WebGL?

Ik heb het gevoel dat hier valse verwachtingen worden geschept.

Dat staat toch in de post.

Gemiddeld presteert de 64bit-versie op dat gebied 25 procent beter, stelt Google.

Gemiddeld over de hele linie. Waarschijnlijk zal Chrome voor de gemiddelde gebruiker 25% sneller zijn.

[Fly-guy]

Toch klopt die info die in het artikel staat niet (geheel), zoals de reactie onder je, van drZymo laat zien.
De bron zegt immers dat er vooral op het gebied van "graphics and multimedia content" verbetering is ten grootte van 25%.

Dus alleen op die gebieden kom je (gemiddeld) tot 25%, over de rest wordt helemaal niets gezegd, afgezien van dat de rest ook sneller is, maar hoeveel?

[Verwijderd]

Over het algemeen zal de laadsnelheid van de browser zelfs afnemen omdat een 64 bits binary groter is en dus trager van een disk geladen wordt.

[Verwijderd]

Over het algemeen zal de laadsnelheid van de browser zelfs afnemen omdat een 64 bits binary groter is en dus trager van een disk geladen wordt.

Is er een wet die voorschrijft dat een 64 bits applicatie groter is? Ik was me daar niet van bewust. Het kan groter zijn, maar het kan door gebruik te maken van de specifieke 64 bit instructies even goed kleiner worden toch?

[Verwijderd]

maar het kan door gebruik te maken van de specifieke 64 bit instructies even goed kleiner worden toch?

De 64-bits instructieset is niet speciaal gemaakt om kleinere binaries op te leveren. Wel om gebruik te maken van meer en grotere registers en meer geheugen. Dat kan een verbetering opleveren van de snelheid zeker als er veel gerekend wordt binnen de registers of veel data wordt verwerkt en levert zeker een verbetering op bij aanspreken van (virtueel) geheugen.
In theorie zal het zo zijn dat bepaalde 64-bits instructies in bepaalde situaties (vooral bij grote floating point berekeningen) minder ruimte innemen dan een aantal 32-bits instructies die je nodig hebt om dezelfde handeling uit te voeren. In de praktijk zijn worden de meeste instructies uitgevoerd op hele kleine getallen en dan zijn 32 bits instructies vaak net zo nuttig maar wel de helft kleiner.

64 bits is dus vooral zinvol voor snelheid en dan nog met name als het gaat om verwerken grote stukken data of complexere berekeningen of applicaties die veel virtueel geheugen aanspreken (bijvoorbeeld databases). Een browser zal dus vooral voordeel boeken bij inlezen en verwerken van bijvoorbeeld video.

[Verwijderd]

De 64-bits instructieset is niet speciaal gemaakt om kleinere binaries op te leveren.

Nee natuurlijk niet, maar als in een 64 bits applicatie 1 instructie voldoende is een bepaalde bewerking, waar in een 32 bits applicatie 2 of meer instructies nodig zijn om het zelfde resultaat te bereiken, kan dit resulteren in een kleinere binary..

Een browser zal dus vooral voordeel boeken bij inlezen en verwerken van bijvoorbeeld video

Ik denk dat het renderen van een pagina ook een flinke aanslag doet op het geheugen. Zeker gecombineerd met video en andere actieve componenten. Daarom denk ik juist dat browsers flink kunnen winnen met 64 bit.

[Verwijderd]

Nee natuurlijk niet, maar als in een 64 bits applicatie 1 instructie voldoende is een bepaalde bewerking, waar in een 32 bits applicatie 2 of meer instructies nodig zijn om het zelfde resultaat te bereiken, kan dit resulteren in een kleinere binary.

Dat zei ik dus ook al maar in de praktijk zal dat dus niet niet zo zijn en zijn 64 bits executables fors groter dan 32 bits excutables.

Ik denk dat het renderen van een pagina ook een flinke aanslag doet op het geheugen

Dat is deels waar maar veel van de rendering van de grafische elementen in een pagina en zelfs de tekst wordt eigenlijk niet gedaan door de browser zelf maar door grafische OS onderdelen zoals bijvoorbeeld Direct2D in windows.
Chrome 35 bevat bijvoorbeeld font rendering dmv DirectWrite (een onderdeel van Windows Direct2D)

[Reactie gewijzigd door Verwijderd op 23 juli 2024 07:11]

[Verwijderd]

Kennelijk wordt er toch genoeg gedaan door de browser. Hoe wil je anders verklaren dat Google juist tijdens het renderen minder crashes verwacht?

Tenzij er een bug zit in Direct2D natuurlijk die minder snel aan het licht komt als er meer geheugen kan worden geadresseerd. Maar dat kan ik me niet goed voorstellen. het zou pas echt bespottelijk zijn als een dermate kritische functie door Microsoft niet goed dichtgetimmerd is.

Kortom, ik blijf bij mijn idee dat browsers flink kunnen winnen met 64 bit.

[Verwijderd]

Hoe wil je anders verklaren dat Google juist tijdens het renderen minder crashes verwacht?

Misschien juist omdat ze tegelijkertijd ook bezig zijn om meer rendering door Direct2D te laten doen.
Waarschijnlijk is die grafische API die ook de basis vormt van Windows eigen rendering het meest stabiel met de beste ondersteuning in grafische hardware drivers.

[Verwijderd]

Misschien juist...

Het wordt mij te speculatief. Google brengt het naar buiten als een voordeel bij de 64bit versie. Jouw verklaring zou een algehele verbetering moeten betekenen lijkt me.

[Verwijderd]

Een mogelijk punt is dat 64 bit Chrome niet draait op XP of Server 2003.
Direct2D deed dat ook niet omdat die geintroduceerd werd bij Vista.
Google kan ondersteuning voor Vista en hoger OS features dus default aan zetten in 64 bits Chrome.

[Verwijderd]

Dat lijkt me echt ongelofelijk extreem waarschijnlijk...

[Blubber]

[...]

Dat staat toch in de post.

[...]

Gemiddeld over de hele linie. Waarschijnlijk zal Chrome voor de gemiddelde gebruiker 25% sneller zijn.

Waarschijnlijk? Blijkbaar staat het toch niet zo duidelijk benoemt in het artikel ...

Het is een terechte opmerking, men claimt links en rechts dat browser x% sneller zijn dan de vorige versie, vaak gaat het dan over Javascript. Feit is dat JS tegenwoordig dermate snel is, dat het volstrekt irrelevant is of je nog 25% of 100% of wat dan ook aan verbetering kunt halen op dat gebied. De DOM is momenteel de grootste vertragende factor, als deze Chrome versie 25% sneller is met DOM manipulaties, dan ga je dat direct als gebruiker merken. Echter, als de JS engine 25% is, dan merk je daar absoluut niets van.

[himlims_]

download;
- https://www.google.com/intl/en/chrome/browser/canary.html
- https://www.google.com/ch...dex.html?extra=devchannel

[Verwijderd]

het is onduidelijk wanneer de Linux- en OS X-versies van de populaire browser eveneens ondersteuning voor 64bit krijgen.

Dat maakt de Linux gebruiker niet uit. Bij de distro's wordt de opensource versie Chromium geleverd. Deze is al een hele tijd 64 bits. Ik weet niet sinds wanneer precies, mogelijk zelfs altijd.

Op OSX kan ook de 64 bits versie van Chromium gebouwd worden. Ik vermoed dat er ook packages voor OSX bestaan.

[magatsu]

Amai, dat was tijd aan het worden dat die x64 was .
Ben wel benieuwd hoe die prestaties zich uiten in de benchmarks . Misschien een hint naar T.Net? Verschil tussen x86 - x64 chrome testen?

[oef!]

Ik heb even snel Sunspider gedraaid https://www.webkit.org/perf/sunspider/sunspider.html

De vergelijking hier neerzetten is too much maar 64 bit is significant sneller op 25 van de 30 tests en op 5 punten langzamer. Getest met Chrome 32 bit en 64 bit op een core i5-2430.

** TOTAL **: // 1.34x as fast // 332.4ms +/- 10.9% // 248.6ms +/- 1.7% significant

Peacekeeper van Futuremark geeft een ander beeld:
Chrome 32bit: 3524
Chrome 64bit: 3154

64bit is hier blijkbaar op alle punten behalve graphics renderen trager.

Edit: Uit interesse de Futuremark Peacekeeper ter referentie op mijn Galaxy S4 (4.4.2 custom GPE ROM, Ktoonsez kernel)
Chrome beta: 661

[Reactie gewijzigd door oef! op 23 juli 2024 07:11]

[SmokingCrop]

Met m'n core i5-3570K is het beeld helemaal anders, 2 sunspider runs gedaan:
• 64 bit: 133,0ms & 133,8ms
• 32 bit: 129,4ms & 132,7ms
32 bit is marginaal sneller in string & datetime, 64bit is marginaal sneller in bitops & math.

Peacekeeper:
• 32bit: 5481
• 64bit: 4587

Browsermark:
• 32bit: 5852 http://browsermark.rightware.com/results/269196
• 64bit: 5572 http://browsermark.rightware.com/results/269201

Tests met Laptop (i5-2540m), 3 sunspider-runs:
• 32bit: 230,1ms / 214,9ms / 245,7ms
• 64bit: 399,3ms / 357,6ms / 314,3ms

dus ja.. voor mij is de 64 bit versie op dit moment slechter.
(telkens alles gesloten bij tests etc, zelfde omstandigheden voor beide browsers)

[Reactie gewijzigd door SmokingCrop op 23 juli 2024 07:11]

[RadioKies]

Zijn die tests er niet om alle aspecten te testen?

Is het dan niet mogelijk dat sites zoals Tweakers en Youtube dan toch sneller draaien op de 64bit variant? Als de algemene vaak bezochte sites sneller zijn met een 64bit browser, dan kan mij een futuremark of wat voor test dan ook niet boeien.

Of kun je er toch vanuit gaan dat die tests betrekking hebben op alle websites? Ik ben redelijk een leek op dit gebied en vroeg mij dit ineens af na het zien van jullie berichten.

[SmokingCrop]

Dat zou kunnen ja.
Of ik dat zou merken, waarschijnlijk niet.

[KeRsTmAnNeKe]

Gelijk een browsertest doen met alle relevante recente browsers, op diverse platformen. Daar kan je best leuke dingen mee doen volgens mij, oa kijken of IE bashing nog steeds nodig is, hoe de status van mobiele vs desktopbrowsers is enz.

[Korben]

XP wordt niet meer ondersteund, dus daar mag je niet over klagen. Vista heeft ook nog maar een klein marktaandeel, van ongeveer 2%. Windows 8 daarentegen, heeft een marktaandeel van > 8%.

[Verwijderd]

In Nederland zit bijvoorbeeld XP nog maar op 5% en Windows 8 op 15% tot 18%

[haling]

[...]
Zoals je al merkt aan je downmods, wordt het verkondigen van onwaarheden niet echt gewaardeerd.

Alleen betalende gebruikers als de overheid hebben daar tot 2019 nog recht op.

nieuws: Windows XP-gebruikers kunnen door registerhack updates blijven ontvangen

[Loller1]

XP en Vista hebben samen zo'n 28% van de markt in handen, 25% voor XP, 2,9% voor Vista. Zeker voor Vista is het daardoor niet meer aantrekkelijk om ervoor te ontwikkelen, en ondersteuning voor XP is er niet meer. Windows 7 en 8 aan de andere kant, hebben 64% van de markt in handen, 50% voor 7, 14% voor 8. En beide platformen zijn makkelijker te ondersteunen.

Nu mag je er wel op rekenen dat, als Internet Explorer 12 niet voor het eind van dit jaar uit komt, ook Windows 7 zal blijven hangen op IE11.

[bantoo]

Sorry maar Vista en XP zijn echt not done.

[Loller1]

Ondersteuning voor XP is in april verlopen, het enige dat nog gedaan wordt is het fixen van veiligheidslekken. Het is over en uit voor Windows XP, en als je op zo'n oud OS zit, heb je ook niks aan een moderne browser. Vista is dan weer geen groot OS meer, met 2,9% is het totaal niet interessant meer om te ondersteunen, daarbij is IE9 nog best goed. Ik verwacht dat andere browsers ondersteuning voor Vista ook zullen laten vallen samen met XP...

[glydoscoop]

Klinkt inderdaad leuk. alleen dat IE bashing eigenlijk niet meer helemaal nodig is dat is natuurlijk al wel een beetje bekend. Google en gij zult vinden dat IE vooral sneller is op sommige vlakken en prima meekomt met Google Chrome, Firefox, Opera etc
http://www.digitaltrends....firefox-vs-safari/#!UlFkc

[sjaak88]

Maar deze test is alweer meer dan een jaar oud...
Niet echt relevant dus.

[NoBrakes]

Hopelijk eens verschillende browsers in het algemeen

[Verwijderd]

Bij mijn benchmarking van Pale Moon was de 32-bitter sneller dan de 64-bitter. Maar dat was al geruime tijd geleden.
Die kan Tweakers dan mooi ernaast zetten, dat geeft ook een beter beeld.

[Deem]

Wel interessant dat er zo een performancewinst is. Mozilla heeft net de 64bit versie van Firefox afgeschaft.

[Maurits van Baerle]

Alleen voor Windows. Voor Linux en OS X is Firefox jaren geleden al overgestapt op 64 bits. Op OS X waren destijds de behaalde snelheidswinsten erg fors:

Cold startup: x86_64 is ~26% faster
Warm startup: x86_64 is ~5% faster
MS Psychadelic Browsing Demo: x86_64 is ~540% faster
MS Speed Reading Demo: x86_64 is ~35% faster
Firefox 4 for Mac OS X: Under the Hood

Overigens heeft Mozilla de ontwikkeling van de 64 bit versie Windows alweer hervat.

[cyberstalker]

Ik snap niet wat er precies verandert is. Op mijn werksysteem (Ubuntu 14.04), is de executable (/usr/lib/chromium-browser/chromium-browser) gewoon een 64-bit executable:

$ file /usr/lib/chromium-browser/chromium-browser
/usr/lib/chromium-browser/chromium-browser: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=749fdde099d8e0cd6e977c4ec714f75b056426dc, stripped

Mis ik hier nu iets of was enkel de Google-branded versie 32-bits en gaan ze nu ook mee met de tijd?

[Reactie gewijzigd door cyberstalker op 23 juli 2024 07:11]

[Stevie-P]

Mis ik hier nu iets of was enkel de Google-branded versie 32-bits en gaan ze nu ook mee met de tijd?

Precies dit dus.

[matthijsln]

Ook de Google-branded Chrome voor Linux was al 64 bit.

[dezero]

64 bit Google Chrome voor Linux bestaat al jaren, 64 bit Firefox ook trouwens. Mogelijk komen ze nu met meer optimalisaties voor 64 bits systemen, dat is natuurlijk altijd welkom.

[Snake]

Wel jammer dat ie nog altijd staat in Program Files (x86), staat beetje lelijk.

[juniorvdloop]

inderdaad raar,
wat nog raarder is, is dat hij bij mij in mijn appdata staat....

[Snake]

Dat is minder raar, als je UAC hebt aanstaan installeert hij daar. Het is dan niet nodig voor Administrative Access te vragen.

[YopY]

Chrome (de binary etc) staat al vanaf dag 1 in app data; dit zorgt ervoor dat hij automatisch kan updaten zonder dat hij om administrator rechten vraagt, zoals andere browsers dat doen (deden?).

[juniorvdloop]

oké duidelijk, maar nu staat ook chrome.exe etc in appdata, dat was eerst toch niet?

[Loller1]

Chrome installeert in de AppData folder om diverse beveiligingen van Windows te omzeilen, zoals het User Account Control. Dit had ook eens tot gevolg dat Microsoft Security Essentials Chrome aanzag als een virus.

[sjongenelen]

Wordt dit net zo populair als andere 64 bit Browsers? Blijven alle Extensions werken?

[floorcula]

In principe wel, extensies worden geschreven in javascript + html. Hoogstens wanneer er functies als websql of api's worden verwijderd werkt er een extentie niet

[Reactie gewijzigd door floorcula op 23 juli 2024 07:11]

[sjongenelen]

Ah mooi, twijfelde daar over, geloof dat het in IE niet zo werkt

[Reactie gewijzigd door sjongenelen op 23 juli 2024 07:11]

[dtech]

IE plugins (BHO's) zijn binaries, die dus verschillend gecompiled moeten worden voor de 32 en 64-bit versie van IE.
Chrome plugins zijn meer een soort fancy webpagina's, waar de browser zelf het "compilen" voor zijn rekening neemt.

[Korben]

Er is een verschil tussen plug-ins en extensions. Extensions zijn inderdaad fancy webpagina's, die zullen blijven werken of je nou 16-, 32- of 64-bit draait. Plug-ins zijn echter bijna altijd binary, dus die zullen moeten worden geüpgraded.

Na een klein experiment wringt hem daar voorlopig al de schoen; Flash werkt niet meer, wellicht omdat Chrome probeert om Flash uit de 32-bit directory te laden.

[Free rider]

Andere 64-bits browsers zijn volgens mij populair omdat plug-ins, extensies enz. *niet* werken. Ik vind het heerlijk om te browsen met 64-bit IE omdat al die flash-reclames enz. je bespaard blijven.

[Verwijderd]

Dat zou prima zijn!
Kunnen we eindelijk op onze 64bit servers chrome x64 installeren ipv x32.

[scsirob]

Tenzij het VDI servers zijn lijkt het me niet heel relevant wat voor browser er op een server geïnstalleerd is.

[Rob Wu]

Om maar twee voorbeelden te geven van waarom de browserkeus wel relevant kan zijn: Headless unit testing / web screenshot/scraper service.

[Reactie gewijzigd door Rob Wu op 23 juli 2024 07:11]

[YopY]

Alleen als het Chrome is, is het niet headless .

[NEO256]

Kan nog steeds. Headless betekent in de regel dat er geen scherm op de computer/server zit. Kun nog steeds prima een virtuele desktop laten renderen of gewoon scherm uit hebben staan waar screenshots worden gemaakt

Voor bijvoorbeeld rapportages.

[Verwijderd]

Wat ik me afvraag is of ze de onderliggende Webkit code ook naar 64bit hebben geport, en zo ja, welke andere browsers hier dan van gaan profiteren.

[Verwijderd]

Nee, want Chrome heeft webkit geport geforkt en is nu blink geworden.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 07:11]

[Verwijderd]

Nee, want Chrome heeft webkit geport en is nu blink geworden.

Dan bedoel je waarschijnlijk "geforkt".

[Mizgala28]

Of je had WaterFox of IE 64-bit kunnen gebruiken, ik vind Chrome persoonlijk onnodig zwaar.

[jarrin]

En Java gebruiken op Mac OS in chrome. Dat kon al jaren niet....

[Rob Wu]

Java werkt al niet meer sinds Chrome 35 omdat NPAPI ondersteuning is verwijderd.

[.oisyn]

Java werkt prima in Chrome 35. Dat er geen NPAPI ondersteuning is wil niet zeggen dat je geen Java plugin kunt installeren.

[Reactie gewijzigd door .oisyn op 23 juli 2024 07:11]

[Rob Wu]

Er zijn nog geen PPAPI Java plugins, dus wanneer NPAPI volledig verdwijnt (aan het eind van dit jaar), dan zal Java (=een NPAPI plugin) niet meer draaien in Chrome (voor meer info, zie http://www.chromium.org/developers/npapi-deprecation).

NPAPI is al verwijderd uit Chrome 35 voor Linux (https://groups.google.com.../chromium-dev/xEbgvWE7wMk), maar draait op het moment nog wel in Windows (en waarschijnlijk ook Mac).

[RGAT]

Waarom zou je op een server uberhaupt een browser instaleren?...

@Eagle Creek: Je hebt gelijk, vooral inderdaad een terminal server is het erg handig , zat een beetje vast op webserver/dc ...

[Reactie gewijzigd door RGAT op 23 juli 2024 07:11]

[Eagle Creek]

Als het een terminal server betreft bijvoorbeeld, of een app-server voor het aanbieden van een gevirtualiseerde browser. Al vaak genoeg dergelijke situaties gezien .

Een server is maar wat jij ervan maakt natuurlijk.

Logische stap van Google enerzijds maar de complete overgang naar 64-bits applicaties komt maar moeizaam op gang. Windows is al bijna 15 jaar verkrijgbaar in 64-bits, IE wordt ook al tijden 64-bits meegeleverd maar toch is het 32-applicaties wat de klok slaat. Ben benieuwd of Google hierin weer het voortouw gaat nemen.

[Reactie gewijzigd door Eagle Creek op 23 juli 2024 07:11]

[Verwijderd]

Als het een terminal server betreft bijvoorbeeld, of een app-server voor het aanbieden van een gevirtualiseerde browser

Dan heb je meestal toch liever een browserversie die minder memory gebruikt en dus en 32 bits versie.

[Janssuh!]

Wat heeft het geheugen gebruik voor link met x64 of x86? x64 kán meer geheugen allokeren, dat houd niet automatisch in dat dit ook gebeurt.

Als je de server goed afregelt, zit er een limiet aan het maximum geheugengebruik per gebruiker. Niks aan de hand dus!

[Verwijderd]

64 bits versies gebruiken ook grotere data elementen die veel meer ruimte innemen. Pointers bijvoorbeeld. Om meer geheugen aan te kunnen spreken heb je ook de grotere verwijzers nodig in je geheugen. Ook elementen van je stack en je heap wordt 64-bits groot.
64 bits versies gebruiken bij gelijk gebruik dus altijd meer geheugen.

[Verwijderd]

Aan de andere kant kan je bij 32 bit de grote pech hebben dat het iets niet meer in je geheugen segment past en dat je de boel moet gaan segmenteren over meerdere blokken met alle overhead van dien.

Ik zou juist verwachten dat 64 bit wel enige toegevoegde waarde had bij een hongerig monster als een web browser.

Edit: Zou je dan trouwens niet het liefst terug willen naar 16 of 8 bit? Waarom ben je vooral zo tegen 64, terwijl 32 vaak ook niet hard nodig is?

[Reactie gewijzigd door Verwijderd op 23 juli 2024 07:11]

[.oisyn]

Aan de andere kant kan je bij 32 bit de grote pech hebben dat het iets niet meer in je geheugen segment past en dat je de boel moet gaan segmenteren over meerdere blokken met alle overhead van dien.

Dat is wel heel erg ouderwets. Segmenten had je in het 16-bits tijdperk. In 32 bits protected mode heb je selectors, maar binnen een enkele selector is 4GB aan adresseerbaar geheugen beschikbaar en daarom krijg je op vrijwel elk OS een flat address space. Je verhaal is dus onzin.

Edit: Zou je dan trouwens niet het liefst terug willen naar 16 of 8 bit? Waarom ben je vooral zo tegen 64, terwijl 32 vaak ook niet hard nodig is?

Nu doe je het voorkomen alsof het een conceptuele kwestie is, maar daar gaat het helemaal niet om. De praktijk is dat je een OS hebt die zowel 32-bits als 64-bits applicaties kan runnen, waarbij een 64-bits applicatie niet per definitie sneller is en zo goed als wel per definitie meer geheugen gebruikt. Aan de andere kant is een 64-bits applicatie weer niet gelimiteerd aan de 4GB aan adresseerbare geheugenruimte. Voor welke van de twee architecturen je wilt gaan voor je applicatie is dus puur een praktische afweging.

[Reactie gewijzigd door .oisyn op 23 juli 2024 07:11]

[Verwijderd]

Dat is wel heel erg ouderwets. Segmenten had je in het 16-bits tijdperk.

Dat was ook het tijdperk dat ik dicht genoeg op het metaal programmeerde om me druk te maken over geheugen adressering.

Ik dacht (omdat ik idd vrij ouderwets ben) dat de max bij 2gb lag, niet 4gb. Ik trek me dan ook verder uit de discussie terug, want het lijkt er inderdaad op dat ik onzin verkondig.

[Verwijderd]

De max voor een applicatie ligt bij 2 GB op een 32-bit OS, omdat de andere 2 GB gereserveerd wordt voor memory-mapped IO, en kernel/drivers/etc.
Tenminste, 2 GB is geen harde limiet, maar wel gebruikelijk. Onder Windows is er een boot-optie om die limiet naar 3 GB op te schuiven (/3G).

Bij een 64-bit OS kan die hele gereservereerde ruimte buiten de virtuele adresruimte van een 32-bit proces gemapt worden, en dus kan iedere applicatie gewoon de volledige 4 GB als virtuele adresruimte krijgen.

[.oisyn]

Onder Windows is er een boot-optie om die limiet naar 3 GB op te schuiven (/3G).

Ter aanvulling, zelfs dan moet de 32-bits applicatie ook nog zelf aangeven dat hij "large address aware" is (linken met /LARGEADDRESSAWARE onder Visual C++), anders krijgt ie sowieso maar 2GB (ook onder 64-bits Windows).

[Verwijderd]

Ik ben niet tegen 64 bits.
Het heeft echter heel beperkt voordeel en je kan het het beste toepassen voor specifieke applicaties.

Zeker in gevirtualiseerde client omgevingen is een 64-bit browser over het algemeen nog geen aanrader vanwege een toename aan geheugen gebruik. Moderne browsers gebruiken vaak al (te) veel geheugen en dan is een toename niet prettig.

Maar veel serverapplicaties bijvoorbeeld kunnen wel degelijk veel beter functioneren met 64-bit versies. Denk aan databaseservers. Daar valt de meeste winst te behalen dor toepassen van 64 bits programmatuur/

[Janssuh!]

In praktijk valt dit reuze mee (draai enkel 64 bits browsers) Waar je wel een punt hebt, is dat er 3rd party 32 bits plugins vereist zijn, deze naast de 64 bits versies geladen moeten worden wat extra geheugen kan gebruiken.

Ik denk dat dit erg afhankelijk is van het bedrijf waar je een dergelijke oplossing wilt gaan gebruiken. Ja het gebruikt meer geheugen, maar nee, dit zal niet zo schokkend zijn dat je 10% minder gebruikers kunt servicen omdat niet iedere gebruiker 100% resources claimt doormiddel van een browser.

[prinsvlad]

Geheugen is toch om gebruikt te worden?.

[Verwijderd]

In gevirtualseerde omgevingen is het prettig om applicaties te hebben die minder daadwerkelijk geheugen gebruiken. Daardoor kan het gedeelde geheugen van een server meer virtuele instances aan.

Als je bijvoorbeeld 100 clientssessies op een server hebt dan wil je geen veel geheugenvretende browsersessies en is een 32 bits browser voor de clients een betere optie dan een 64 bits browser.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 07:11]

[Janssuh!]

Als je een goede virtualisatietechniek gebruikt heb je ook hier geen last van. Blokken die dubbel voorkomen worden slechts 1 keer 'daadwerkelijk' in je geheugen gezet.

Verder zul je natuurlijk altijd juist moeten schalen in server hardware of genoegen nemen dat de user experience lager ligt.

Dit laatste is vaak geen technische beperking, maar een zakelijke. Als de Business meer mensen toe laat of nét die ene 64 bits web applicatie moet gebruiken zonder de server uit te willen breiden kun je ze er op wijzen en vertellen wat de gevolgen hiervan zijn. Een klagende werknemer-massa kan dan wonderen verrichten en de server opschalen.

[mxcreep]

Dat heeft weinig te maken met een 'goede' virtualisatie techniek. Memory deduplicatie is gewoon een feature, heel interessant als je grote hoeveelheden vm's hebt die steeds dezelfde blokken memory hebben, denk aan gelijkwaardige kernels etc. Maar het geeft ook de nodige overhead, net als bij elke vorm van deduplicatie. Dus niet per definitie geschikt voor alle toepassingen.

Vooral toepassingen of virtuele servers hebben die veel bewerkingen doen in RAM zijn niet gebaat bij deduplicatie. Ik zou bijvoorbeeld mijn Couchbase / Memcache cluster niet willen draaien met deduplicatie enabled.

Wanneer je voor max performance gaat is het antwoord heel simpel, RAM te kort ? Bijprikken...

[aadje93]

x86 zal je bedoelen...

[ruben]

Gaaf, ben benieuwd wanneer ChromeOS wordt ondersteund, aangezien er ook 64bits Chromebooks zijn.

[Noob_Saibot]

Is wel andere architectuur dan x86-64

[Dreamvoid]

De huidige ARM chromebooks zijn nog 32 bit.

[ruben]

De Chromebook 2 met Exynos 5 Octa is anders 64bit hoor..

[Dreamvoid]

Hoe kan dat? De Exynos 5 Octa is een 32-bit ARM chip.

[ruben]

Oeps, klopt, ik had erop gezocht en het eerste nieuwsbericht stond duidelijk dat het 64bit was, alleen dat klopt dus niet..

Maar de Chromebook Pixel is dus wel 64bit.. (en ja heb dit wel dubbel gechecked..)

[grol4]

Onzin. ChromeOS is gewoon x86. En is tijdelijk x86-64 geweest. En ja, er zijn inmiddels ook ARM-versies.