mboost-dp1
Billig Windows 7?
#50
Min SQL "foeles" fx hurtigere, men det er jo rimeligt svaert at maale, naar man har overhead.
Nejda, men jeg kan ogsaa slynge 30% ud af roeven hvis det er? :)
Men samtlige udviklere jeg har spurgt om det, siger at 64bit fordelene klart opvejer memory heap.
Formodes af hvem?
Og den udvikler jeg lige har spurgt, kigger paa mig som om jeg er dummere end snot.
Kort fortalt, saa mener han klart at de ekstra registre i AMD64 opvejer performance tabet.
Saa ikke 30%?
Hvilket ikke ser ud til at have nogen som helst indflydelse paa performance her?
Nu hvor jeg har koert det samme HW i lang tid, med baade 32bit og 64bit, saa har jeg kun bemaerket fordele og optimeringer ved at skifte til en 64bit platform.
Hvad er det for server-apps du benytter der performer bedre under 64bit? (jeg formoder du benytter Debian som server OS)
Min SQL "foeles" fx hurtigere, men det er jo rimeligt svaert at maale, naar man har overhead.
Har du tal for det?
Nejda, men jeg kan ogsaa slynge 30% ud af roeven hvis det er? :)
Mine kommentare har iøvrigt ikke været henvendt alene til en vilkårlig Windows - det er en problematik der gør sig gældene på samtlige platforme, uanset OS.
Men samtlige udviklere jeg har spurgt om det, siger at 64bit fordelene klart opvejer memory heap.
En fullblown 64bit JVM formodes at yde 10-30% dårligere end dens 32bit pendant, afhængig af opgavetyper, memoryforbrug og HW. (tradeoff er mindre på AIX eller mainframe mens PC-systemer ligger i den dyre ende)
Formodes af hvem?
Og den udvikler jeg lige har spurgt, kigger paa mig som om jeg er dummere end snot.
Kort fortalt, saa mener han klart at de ekstra registre i AMD64 opvejer performance tabet.
Løsningen jeg har set, har været at nedskalere mængden af bits der benyttes internt, så et objekt eksempelvis er 40bit. Det giver en potentiel heap på 25GB, og hvor performance-tradeoff'et er meget lille.
Saa ikke 30%?
...for mere optimal udnyttelse af RAM og cache.
Hvilket ikke ser ud til at have nogen som helst indflydelse paa performance her?
Nu hvor jeg har koert det samme HW i lang tid, med baade 32bit og 64bit, saa har jeg kun bemaerket fordele og optimeringer ved at skifte til en 64bit platform.
#51
En database-server har det nemmere, fordi den kan læse mere op i hukommelsen, men det kræver naturligvis mere hukommelse...! :)
Slyng du bare, mine tal er baseret på resultater fra IBM's performance labs, så kan du ligge i det hvad du vil.
Sorry - no offence, men det viser bare hvorfor de er udviklere og ikke teknikkere.
...og hvilken highlevelkode er det han skriver, der benytter de nye instruktioner så effektivt at det opvejer performancetabet?
Det er ikke påstande jeg sidder og drømmer op, det er påstande der er baseret på performance-tuning og test i IBM labs.
Det er sikkert dygtige programmøre du taler med, de ved en masse om deres fagområde...men det her er min hjemmebane - det er her jeg tjener mine penge.
Nej, løsningen giver en performance der minder om 32bit miljøer, og med markant større heap.
Men det er IKKE en fullblown 64bit, og det her er ikke en standardløsning for 64bit apps, men en dedikeret java applikationsserver.
Min SQL "foeles" fx hurtigere, men det er jo rimeligt svaert at maale, naar man har overhead.
En database-server har det nemmere, fordi den kan læse mere op i hukommelsen, men det kræver naturligvis mere hukommelse...! :)
Nejda, men jeg kan ogsaa slynge 30% ud af roeven hvis det er? :)
Slyng du bare, mine tal er baseret på resultater fra IBM's performance labs, så kan du ligge i det hvad du vil.
Men samtlige udviklere jeg har spurgt om det, siger at 64bit fordelene klart opvejer memory heap.
Sorry - no offence, men det viser bare hvorfor de er udviklere og ikke teknikkere.
Formodes af hvem?
Og den udvikler jeg lige har spurgt, kigger paa mig som om jeg er dummere end snot.
Kort fortalt, saa mener han klart at de ekstra registre i AMD64 opvejer performance tabet.
...og hvilken highlevelkode er det han skriver, der benytter de nye instruktioner så effektivt at det opvejer performancetabet?
Det er ikke påstande jeg sidder og drømmer op, det er påstande der er baseret på performance-tuning og test i IBM labs.
Det er sikkert dygtige programmøre du taler med, de ved en masse om deres fagområde...men det her er min hjemmebane - det er her jeg tjener mine penge.
Saa ikke 30%?
Nej, løsningen giver en performance der minder om 32bit miljøer, og med markant større heap.
Men det er IKKE en fullblown 64bit, og det her er ikke en standardløsning for 64bit apps, men en dedikeret java applikationsserver.
#52
Min SQL Server har 2GB RAM, og foeles stadig hurtigere under AMD64, fremfor i386.
Tak, jeg ville bare have at vide hvor de tal kom fra.
30% lyder bare ikke som noget der haenger sammen med virkeligheden, set ud fra alle de installationer og performance tests jeg har set / lavet.
Jeg *har* set tab, men det har vaeret en blandet landhandel, hvor nogle ting var hurtigere, andre langsommere.
Om det saa skyldes at 64bit versionen af det paagaeldende software bare er "bedre lavet", skal jeg selvfoelgelig ikke sige.
Mjoeh, nu laver han saa udvikling som er ret saa lowlevel og fx meget specifikt paa driver niveau.
Jeg kan spoerge ham hvilken kode det er han skriver, men om det er high eller lowlevel, er det vel kun ham der kan svare paa :)
Jojo, jeg siger bare at det ikke haenger saerligt godt sammen med den virkelighed jeg umiddelbart opfatter her.
Din hjemmebane er 64bit instruktionssaet? o.O
Altsaa, teknikken bag, fremfor udviklerne der rent faktisk skal udvikle til det ene eller det andet? :)
Jow.
Jeg har bare svaert ved at se hvorfor memory heap skulle udgoere et saa stort tab, at det ikke opvejes af flere generel purpose threads, fx.
Har du nogle lidt mere "real-life" tests til at underbygge dette performance-tab?
Gerne noget mere klient-specifikt :)
Min SQL Server har 2GB RAM, og foeles stadig hurtigere under AMD64, fremfor i386.
Slyng du bare, mine tal er baseret på resultater fra IBM's performance labs, så kan du ligge i det hvad du vil.
Tak, jeg ville bare have at vide hvor de tal kom fra.
30% lyder bare ikke som noget der haenger sammen med virkeligheden, set ud fra alle de installationer og performance tests jeg har set / lavet.
Jeg *har* set tab, men det har vaeret en blandet landhandel, hvor nogle ting var hurtigere, andre langsommere.
Om det saa skyldes at 64bit versionen af det paagaeldende software bare er "bedre lavet", skal jeg selvfoelgelig ikke sige.
Sorry - no offence, men det viser bare hvorfor de er udviklere og ikke teknikkere.
Mjoeh, nu laver han saa udvikling som er ret saa lowlevel og fx meget specifikt paa driver niveau.
...og hvilken highlevelkode er det han skriver, der benytter de nye instruktioner så effektivt at det opvejer performancetabet?
Jeg kan spoerge ham hvilken kode det er han skriver, men om det er high eller lowlevel, er det vel kun ham der kan svare paa :)
Det er ikke påstande jeg sidder og drømmer op, det er påstande der er baseret på performance-tuning og test i IBM labs.
Jojo, jeg siger bare at det ikke haenger saerligt godt sammen med den virkelighed jeg umiddelbart opfatter her.
Det er sikkert dygtige programmøre du taler med, de ved en masse om deres fagområde...men det her er min hjemmebane - det er her jeg tjener mine penge.
Din hjemmebane er 64bit instruktionssaet? o.O
Altsaa, teknikken bag, fremfor udviklerne der rent faktisk skal udvikle til det ene eller det andet? :)
Nej, løsningen giver en performance der minder om 32bit miljøer, og med markant større heap.
Men det er IKKE en fullblown 64bit, og det her er ikke en standardløsning for 64bit apps, men en dedikeret java applikationsserver.
Jow.
Jeg har bare svaert ved at se hvorfor memory heap skulle udgoere et saa stort tab, at det ikke opvejes af flere generel purpose threads, fx.
Har du nogle lidt mere "real-life" tests til at underbygge dette performance-tab?
Gerne noget mere klient-specifikt :)
Mjoeh, nu laver han saa udvikling som er ret saa lowlevel og fx meget specifikt paa driver niveau.
Hvis vi taler drivere, er det sandsynligvis nogle andre ting der gør sig gældene.
De fleste apps og server apps, er skrevet i highlevelsprog, som java og .NET og det er i disse scenarier det gør sig gældene.
Drivere bliver ofte skrevet langt mere specifikt, hvilket betyder man kan vælge og fravælge de store referencer.
I sidste ende betyder en hurtig driver at du kan udnytte HW mere optimalt, men hvis den applikation du laver selve logikken i, er langsom grundet objekt-bloating så forsvinder lidt af ideen.
De her ting er naturligvis meget afhængig af hvad det er du forsøger at lave og hvordan du gør det. Hvis du eksempelvis har tunge videnskabelige beregninger der kræver objekter på 10GB, er det klart at det er hurtigere at have disse objekter direkte i heapen istedet for på disk.
Din hjemmebane er 64bit instruktionssaet? o.O
Altsaa, teknikken bag, fremfor udviklerne der rent faktisk skal udvikle til det ene eller det andet? :)
Som oftest er det system arkitektur, stabilisering og tuning af systemerne, når udviklerne har afleveret deres besyv.
Under det ligger vurderinger som 32 vs 64bit arkitektur, cluster-konfiguration etc.
De færreste udviklere gør sig de store ideer om hvor meget memory deres array fortærrer, eller hvilke instruktioner der er de mest effektive.
Det er der som sådan ikke noget galt i, men at tro at bare fordi man er udvikler, så kender man alt til teknik, maskinarkitektur etc. ... forget it.
Der er en grund til udviklerne er sat i verden, og der er en grund til at man sætter dyrt betalte teknikkere til at etablere og håndtere miljøerne bagefter, ligesom man sætter DBA'er til at tune og optimere basen, eventuelt komme rettelser til udviklerens metoder.
...og der er en god grund til, at udvikling og drift af store enterprise-systemer koster knapper...rigtig mange knapper - og her er licensomkostningerne som oftest den mindste af posterne.
Har du nogle lidt mere "real-life" tests til at underbygge dette performance-tab?
Gerne noget mere klient-specifikt :)
Jeg arbejder og forholder mig til server-baserede systemer, men da afvikling af et javaprogram i en applikationsserver, ikke er meget forskellige fra afvikling af en klient udviklet i .NET (på det her niveau) er det de samme regler der gælder.
Man kan komme udenom en del af det her, ved at afvikle C/C++ kode compilet af en 32bit compiler, så din applikation er en 32bit app, afviklet i et 64bit miljø - men rene 64bit apps...tilbage til square one.
De real lige test jeg har...er nok mere praktisk erfaring, forholdt med de teorier som vi fungere under - so no white paper.
Men begynd endelig at læs red books, og du vil se en del af de ting jeg beskriver gentaget.
Meget overordnet, gensender jeg gerne mit link fra tidligere:
http://www.redbooks.ibm.com/abstracts/tips0475.htm...
...den sidste del fra mit link:
...og her nævner de ikke engang at de store objekter vil gøre din cache mindre effektiv...men det siger vel også sig selv.
"Link" skrev:In fact, since 64-bit computing generally requires instructions and some data to be stored as 64-bit objects, and these objects consume more physical memory than the same object in a 32-bit operating environment, the memory capacity inflation of 64-bit can only be offset by an application taking advantage of the capabilities of 64-bit. For greater addressing or increased calculation performance for high-precision operations, but where an application does not make use of the 64-bit operating environment features, it often experiences the overhead without the benefit. In this case the overhead is increased memory consumption, leaving less physical memory for operating system buffers and caches. The resulting reduction in effective memory can decrease performance.
...og her nævner de ikke engang at de store objekter vil gøre din cache mindre effektiv...men det siger vel også sig selv.
#56
Ja, hvis man vaelger et sprog hvor man ikke kan udnytte 64-bit fordelene lidt mere direkte, saa er det jo klart.
Ja, eller programmer i C/C++, fx.
Jada.
Men saa skal vi ud i at have stoerre memory maengde, som vi jo netop diskutere at man ikke havde :)
Vurderinger baseret paa udnyttelsen af instruktionssaet?
Eller baseret paa de slamkodere i har ansat idag?
Foerste del vidner om slamkodere.
Anden del haandteres af din compiler - som meget gerne skulle have godt fat i fordelene ved 64bit.
Men nu ved jeg jo ikke om i bruger Visual Studio :P
Naeh, men i sidste ende saa er det en rimeligt god ide at have et basalt kendskab til den arkitektur man udvikler til - og i lige netop dette tilfaelde, ved udvikleren ganske meget om dette.
Jeg tror det er en farlig debat at gaa ind i her, hvis ikke du vil ud i at stemple folk som slamkodere.
Laver du dit lort ordentligt, saa boer du ikke have DBA'er til at "fiske rundt" bagefter. ( Medmindre der er tale om en decideret aendring )
Teknikkerne er selvfoelgelig ansat til drift og opsaetning, herunder er der selvfoelgelig krav om arkitektur forstaaelse, men at sige udvikleren bare kaster kode ud uden omtanke .. Det er slamkode paa vaerste plan :D
Men hvis du siger at 64bit er daarligt udnyttet i .NET og Windows, hvorfor fanden skulle man saa bruge det?
Det er et spoergsmaal om penge - ikke idelogi.
Det vil vaere ligesaa dyrt, eller dyrere, at udvikle til C/C++, fordi man ikke har basen fra .NET eller JAva - er det normale argument.
Saa hvad er egentligt argumentet her?
Og det forklarer ikke noget om 32bit vs. 64bit - 64bit virker fint i Debian AMD64 og jeg har ikke noget maerkbart performancetab - hvor jeg tilgengaeld har en maerkbar oegning af performance.
Hvis det skyldes at jeg ikke bruger .NET ( som jeg kan se som argument #1? ) eller at programmerne ikke er slamkodet ( argument #2 ? ), saa er jeg da kun glad :)
Hvis vi taler drivere, er det sandsynligvis nogle andre ting der gør sig gældene.
De fleste apps og server apps, er skrevet i highlevelsprog, som java og .NET og det er i disse scenarier det gør sig gældene.
Ja, hvis man vaelger et sprog hvor man ikke kan udnytte 64-bit fordelene lidt mere direkte, saa er det jo klart.
Drivere bliver ofte skrevet langt mere specifikt, hvilket betyder man kan vælge og fravælge de store referencer.
Ja, eller programmer i C/C++, fx.
I sidste ende betyder en hurtig driver at du kan udnytte HW mere optimalt, men hvis den applikation du laver selve logikken i, er langsom grundet objekt-bloating så forsvinder lidt af ideen.
Jada.
De her ting er naturligvis meget afhængig af hvad det er du forsøger at lave og hvordan du gør det. Hvis du eksempelvis har tunge videnskabelige beregninger der kræver objekter på 10GB, er det klart at det er hurtigere at have disse objekter direkte i heapen istedet for på disk.
Men saa skal vi ud i at have stoerre memory maengde, som vi jo netop diskutere at man ikke havde :)
Som oftest er det system arkitektur, stabilisering og tuning af systemerne, når udviklerne har afleveret deres besyv.
Under det ligger vurderinger som 32 vs 64bit arkitektur, cluster-konfiguration etc.
Vurderinger baseret paa udnyttelsen af instruktionssaet?
Eller baseret paa de slamkodere i har ansat idag?
De færreste udviklere gør sig de store ideer om hvor meget memory deres array fortærrer, eller hvilke instruktioner der er de mest effektive.
Foerste del vidner om slamkodere.
Anden del haandteres af din compiler - som meget gerne skulle have godt fat i fordelene ved 64bit.
Men nu ved jeg jo ikke om i bruger Visual Studio :P
Det er der som sådan ikke noget galt i, men at tro at bare fordi man er udvikler, så kender man alt til teknik, maskinarkitektur etc. ... forget it.
Naeh, men i sidste ende saa er det en rimeligt god ide at have et basalt kendskab til den arkitektur man udvikler til - og i lige netop dette tilfaelde, ved udvikleren ganske meget om dette.
Der er en grund til udviklerne er sat i verden, og der er en grund til at man sætter dyrt betalte teknikkere til at etablere og håndtere miljøerne bagefter, ligesom man sætter DBA'er til at tune og optimere basen, eventuelt komme rettelser til udviklerens metoder.
Jeg tror det er en farlig debat at gaa ind i her, hvis ikke du vil ud i at stemple folk som slamkodere.
Laver du dit lort ordentligt, saa boer du ikke have DBA'er til at "fiske rundt" bagefter. ( Medmindre der er tale om en decideret aendring )
Teknikkerne er selvfoelgelig ansat til drift og opsaetning, herunder er der selvfoelgelig krav om arkitektur forstaaelse, men at sige udvikleren bare kaster kode ud uden omtanke .. Det er slamkode paa vaerste plan :D
...og der er en god grund til, at udvikling og drift af store enterprise-systemer koster knapper...rigtig mange knapper - og her er licensomkostningerne som oftest den mindste af posterne.
Men hvis du siger at 64bit er daarligt udnyttet i .NET og Windows, hvorfor fanden skulle man saa bruge det?
Det er et spoergsmaal om penge - ikke idelogi.
Det vil vaere ligesaa dyrt, eller dyrere, at udvikle til C/C++, fordi man ikke har basen fra .NET eller JAva - er det normale argument.
Saa hvad er egentligt argumentet her?
Og det forklarer ikke noget om 32bit vs. 64bit - 64bit virker fint i Debian AMD64 og jeg har ikke noget maerkbart performancetab - hvor jeg tilgengaeld har en maerkbar oegning af performance.
Hvis det skyldes at jeg ikke bruger .NET ( som jeg kan se som argument #1? ) eller at programmerne ikke er slamkodet ( argument #2 ? ), saa er jeg da kun glad :)
#59
Jojo, det goer jeg skam ogsaa;
Laeser man:
Saa vil du jo netop se at memory heap kan blive opvejet af 64bit instruktionssaettets fordele.
Og det er mere dette som Borg taler om.
Hvilket netop er det der sker, men i sidste ende kan det opvejes af at have 4 general purpose registre, fremfor 2 fx.
Saa det handler ikke om foelelser, det handler om at laese hvad der staar og udfra dette, forstaa hvilken baggrund der er for deres argumenter.
Uden at vide alt for meget om det (Bruger selv 64bit kun pga. jeg har 4gb ram), så tror jeg at Borg vægter IBM's undersøgelser/analyser højere end dine føelser Fido.
Jojo, det goer jeg skam ogsaa;
Laeser man:
In fact, since 64-bit computing generally requires instructions and some data to be stored as 64-bit objects, and these objects consume more physical memory than the same object in a 32-bit operating environment, the memory capacity inflation of 64-bit can only be offset by an application taking advantage of the capabilities of 64-bit.
Saa vil du jo netop se at memory heap kan blive opvejet af 64bit instruktionssaettets fordele.
For greater addressing or increased calculation performance for high-precision operations, but where an application does not make use of the 64-bit operating environment features, it often experiences the overhead without the benefit.
Og det er mere dette som Borg taler om.
In this case the overhead is increased memory consumption, leaving less physical memory for operating system buffers and caches. The resulting reduction in effective memory can decrease performance.
Hvilket netop er det der sker, men i sidste ende kan det opvejes af at have 4 general purpose registre, fremfor 2 fx.
Saa det handler ikke om foelelser, det handler om at laese hvad der staar og udfra dette, forstaa hvilken baggrund der er for deres argumenter.
Men fidomuh,
Hvad vil du så anbefale mig?
Jeg har følgende system, der nok mest bliver brugt til at se video, musik og gaming:
MB: XFX NVIDIA nForce 780i S
CPU: Intel Core 2 Quad Q6600, BOX, LGA775
RAM: Corsair TWIN2X4096-8500C5DF, 2x2048mb
GFX: Inno3D GeForce 8800GT, 512MB, PCI-E
HDD: Samsung SP F1 750GB, 32MB, SATAII
32bit eller 64bit?
Hvad vil du så anbefale mig?
Jeg har følgende system, der nok mest bliver brugt til at se video, musik og gaming:
MB: XFX NVIDIA nForce 780i S
CPU: Intel Core 2 Quad Q6600, BOX, LGA775
RAM: Corsair TWIN2X4096-8500C5DF, 2x2048mb
GFX: Inno3D GeForce 8800GT, 512MB, PCI-E
HDD: Samsung SP F1 750GB, 32MB, SATAII
32bit eller 64bit?
fidomuh (58) skrev:#56
Ja, hvis man vaelger et sprog hvor man ikke kan udnytte 64-bit fordelene lidt mere direkte, saa er det jo klart.
???
Både java og .NET udnytter 64bit til fulde, men fordelen ved begge sprog er vel at man slipper for at skrive nativ kode.
Vurderinger baseret paa udnyttelsen af instruktionssaet?
Eller baseret paa de slamkodere i har ansat idag?
Vurderingen er alene ud fra hvor godt en kode har det i et specifikt miljø, og er, om du vil det eller ej, temmelig immun overfor kvaliteten af dine programmøre.
De målinger der findes på området er generelle målinger og betragtninger, og uanset hvad du og jeg mener om kvaliteten af et hold programmøre, så er ændrer det jo ikke rigtig på tingenes tilstand.
Foerste del vidner om slamkodere.
Anden del haandteres af din compiler - som meget gerne skulle have godt fat i fordelene ved 64bit.
Fido - jeg tror simpelthen ikke du har forstået problemets kerne.
...og jeg synes måske også dine kommentar er en anelse mærkelige.
Jeg beskriver et generelt problem ved at vælge en teknologi fremfor en anden.
Dit svar, er at du mener kvaliteten af nogle ukendte kodere ikke er god nok.
Jeg forklarer om generelle målinger fra IBM's labs.
Du peger igen på kvaliteten af programmørene.
De ting jeg taler om, kommer bl.a. direkte fra tuningsteamet hos IBM, der sidder og optimere og tuner IBM's JVM-implementering.
Det er de hårde drenge, og med al respekt for dine holdninger og mavefornemmelse overfor din AMD-server...jeg ved godt hvor jeg sætter mine sparepenge.
Men nu ved jeg jo ikke om i bruger Visual Studio :P
...og det er måske så ved denne her kommentar jeg godt kan se at hele diskussionen med dig er omsonst.
Du har meget enkelt ingen ide om hvad du snakker om.
Ikke for at fornærme dig, træde dig eller nogen andre over fødderne, men diskussionen her er håbløs.
...jeg tror bare vi skal parkere den her.
Jeg tror det er en farlig debat at gaa ind i her, hvis ikke du vil ud i at stemple folk som slamkodere.
Laver du dit lort ordentligt, saa boer du ikke have DBA'er til at "fiske rundt" bagefter. ( Medmindre der er tale om en decideret aendring )
Teknikkerne er selvfoelgelig ansat til drift og opsaetning, herunder er der selvfoelgelig krav om arkitektur forstaaelse, men at sige udvikleren bare kaster kode ud uden omtanke .. Det er slamkode paa vaerste plan :D
...og udvikling/drift af store enterprise-systemer er tilsyneladene heller ike noget du har prøvet.
Men hvis du siger at 64bit er daarligt udnyttet i .NET og Windows, hvorfor fanden skulle man saa bruge det?
Det er din fortolkning ikke min.
Du har nøjagtig samme problematik, uanset om du vælger Windows, Linux, OS X, AIX, HP-UX, z/OS - you name it.
Trade off'et er et spørgsmål om ressourcer, og det kan du ikke ændre, uanset hvilket sprog, OS eller maskinarkitektur du vælger.
Det er et spoergsmaal om penge - ikke idelogi.
Det vil vaere ligesaa dyrt, eller dyrere, at udvikle til C/C++, fordi man ikke har basen fra .NET eller JAva - er det normale argument.
Saa hvad er egentligt argumentet her?
...du blander igen tingene sammen.
Det er ikke dyrere at udvikle til en 32bit eller 64bit platform - i de fleste tilfælde ændrer du compileren, og kører den samme kode igen.
Det har intet med det trade off jeg taler med at gøre.
...og hvor kom ideologi fra?
Jeg taler om tørre ting som facts og tingenes indbyrdes sammenhæng.
Og det forklarer ikke noget om 32bit vs. 64bit - 64bit virker fint i Debian AMD64 og jeg har ikke noget maerkbart performancetab - hvor jeg tilgengaeld har en maerkbar oegning af performance.
right you are...
Hvis det skyldes at jeg ikke bruger .NET ( som jeg kan se som argument #1? ) eller at programmerne ikke er slamkodet ( argument #2 ? ), saa er jeg da kun glad :)
Det er IKKE argument nr 1.
Argument nr 1 er *igen*igen*:
En integer i et 32bit systemer...fylder 32bit
En integer i et 64bit systemer...fylder 64bit
...altså dobbelt op.
En adresse i et 32bit systemer...fylder 32bit
En adresse i et 64bit systemer...fylder 64bit
...altså dobbelt op.
etc.
ergo - dine objekter kommer til at fylde mere i memory.
Større optager mere plads i memory, og nedsætter din effektiviteten i din cache.
Uanset, OS, Hardware, programmeringssprog, compiler, kvalitet på udvikler etc.
Forstå det eller lad være...I don't care!
Selvom min fornemmelse er, at man har mere travl med at komme med underlige påstande og "vinde" diskussionen, så har jeg algt en præsentation op, om dette emne:
http://linkfighter.com/WSI19_32_vs_64.pdf
Den taler en del om WAS, men som jeg har skrevet et par gange...bloatingen er et generelt trade off ved 64bit.
#63
Jeg tror bare vi springer alt det forvirring over der fylder debatten og gaar tilbage til noget af det foerste jeg skrev:
Jojo.
Og nu har du saa 4 general purpose registre, fremfor 2, hvilket giver dig ekstra performance.
Korrekt, det var dig der bragte .NET og JAVA ting ind i det, jeg siger jo netop at der ER fordele i 64bit, praecis som IBM ogsaa goer.
Og jeg har rent faktisk laest dine kilder.
Har du bemaerket at de allesammen skriver at problemerne kan opvejes af 64bit instruktionssaet?
Ikke at de kan opvejes "helt", men om ikke andet, saa langt henad vejen.
You care enough to keep misreading.
Jeg linker nu til wiki:
http://en.wikipedia.org/wiki/64-bit
Outtake:
Pros/cons anyone?
Og lige netop dette ( Windcape ) goer at du skal vaelge 64bit, selvom du har under 5GB RAM ..
Men er egentligt, som jeg forstaar det, loest - omend det ikke fungerer "super godt".
Velkommen til 64bit, folk der kan lide filer paa mere end 4GB.
( Hvilket vil sige 99% af newz.dks brugere? )
( Alle der koerer stoerre databaser? )
( Alle der har med datastore / backup at goere? )
Og her kommer sikkerhedsspoergsmaalet vel saa ind?
Hvis du ynder at bruge en form for kryptering paa bare lidt af dit data, saa vil du se en maerkbar forskel i "live" dekryptering af en partition fx.
Og den der er bare weird, men fair nok da :P
Borg, jeg ser ikke det store argument for at koere 32bit.
Performancetabet ved stoerre Memory heap er forstaaeligt og logisk, men i sidste ende er der vaesentlige fordele der vil opveje dette - for stort set alle brugere.
Jeg tror bare vi springer alt det forvirring over der fylder debatten og gaar tilbage til noget af det foerste jeg skrev:
Argument nr 1 er *igen*igen*:
En integer i et 32bit systemer...fylder 32bit
En integer i et 64bit systemer...fylder 64bit
...altså dobbelt op.
En adresse i et 32bit systemer...fylder 32bit
En adresse i et 64bit systemer...fylder 64bit
...altså dobbelt op.
etc.
ergo - dine objekter kommer til at fylde mere i memory.
Større optager mere plads i memory, og nedsætter din effektiviteten i din cache.
Jojo.
Og nu har du saa 4 general purpose registre, fremfor 2, hvilket giver dig ekstra performance.
Uanset, OS, Hardware, programmeringssprog, compiler, kvalitet på udvikler etc.
Korrekt, det var dig der bragte .NET og JAVA ting ind i det, jeg siger jo netop at der ER fordele i 64bit, praecis som IBM ogsaa goer.
Og jeg har rent faktisk laest dine kilder.
Har du bemaerket at de allesammen skriver at problemerne kan opvejes af 64bit instruktionssaet?
Ikke at de kan opvejes "helt", men om ikke andet, saa langt henad vejen.
Forstå det eller lad være...I don't care!
You care enough to keep misreading.
Jeg linker nu til wiki:
http://en.wikipedia.org/wiki/64-bit
Outtake:
A common misconception is that 64-bit architectures are no better than 32-bit architectures unless the computer has more than 4 GB of main memory. This is not entirely true:
Pros/cons anyone?
Some operating systems reserve portions of process address space for OS use, effectively reducing the total address space available for mapping memory for user programs. For instance, Windows XP DLLs and other user mode OS components are mapped into each process's address space, leaving only 2 to 3 GB (depending on the settings) address space available. This restriction is not present in 64-bit operating systems.
Og lige netop dette ( Windcape ) goer at du skal vaelge 64bit, selvom du har under 5GB RAM ..
Memory-mapped files are becoming more difficult to implement in 32-bit architectures
Men er egentligt, som jeg forstaar det, loest - omend det ikke fungerer "super godt".
especially due to the introduction of relatively cheap recordable DVD technology. A 4 GB file is no longer uncommon, and such large files cannot be memory mapped easily to 32-bit architectures; only a region of the file can be mapped into the address space, and to access such a file by memory mapping, those regions will have to be mapped into and out of the address space as needed. This is a problem, as memory mapping remains one of the most efficient disk-to-memory methods, when properly implemented by the OS.
Velkommen til 64bit, folk der kan lide filer paa mere end 4GB.
( Hvilket vil sige 99% af newz.dks brugere? )
( Alle der koerer stoerre databaser? )
( Alle der har med datastore / backup at goere? )
Some programs such as data encryption software can benefit greatly from 64-bit registers (if the software is 64-bit compiled) and effectively execute 3 to 5 times faster on 64-bit than on 32-bit.
Og her kommer sikkerhedsspoergsmaalet vel saa ind?
Hvis du ynder at bruge en form for kryptering paa bare lidt af dit data, saa vil du se en maerkbar forskel i "live" dekryptering af en partition fx.
Some complex numerical analysis algorithms are limited in their precision by the errors that can creep in because not all floating point numbers can be accurately represented with a small number of bits. Creeping inaccuracies can lead to incorrect results, often leading to attempts to divide by zero, or to not identify two quantities as being identical for practical purposes. International Computers Limited added 128-bit support to the ICL 2900 Series in 1974 largely as a result of requests from the scientific community.
Og den der er bare weird, men fair nok da :P
Borg, jeg ser ikke det store argument for at koere 32bit.
Performancetabet ved stoerre Memory heap er forstaaeligt og logisk, men i sidste ende er der vaesentlige fordele der vil opveje dette - for stort set alle brugere.
Fandt noget mere info:
Ah, saa det er 8 vs 16.
Der kan man bare se.
More performanceboosts! Yay :)
There are many more general-purpose CPU registers in 64-bit mode. Registers are the fastest memory in your entire system. There are only 8 in 32-bit mode and 16 general purpose registers in 64-bit mode. In scientific computing applications I've written, I've seen up to a 30% performance boost by recompiling in 64-bit mode (my application could really use the extra registers and it wasn't hurt too much by the double-sized pointers).
Ah, saa det er 8 vs 16.
Der kan man bare se.
More performanceboosts! Yay :)
Jojo.
Og nu har du saa 4 general purpose registre, fremfor 2, hvilket giver dig ekstra performance.
Ja - men de hverken ændrer på hvordan tingene hænger sammen, eller giver dig nok boost til, at du kommer ud over den ineffektivisering der sker af din RAM.
Korrekt, det var dig der bragte .NET og JAVA ting ind i det, jeg siger jo netop at der ER fordele i 64bit, praecis som IBM ogsaa goer.
Og jeg har rent faktisk laest dine kilder.
Begge sprog er objektorienteret helt ud til mindste enhed, hvorfor man sandsynligvis vil se denne trend mere tydeligt.
[/quote]Har du bemaerket at de allesammen skriver at problemerne kan opvejes af 64bit instruktionssaet?
Ikke at de kan opvejes "helt", men om ikke andet, saa langt henad vejen. [/quote]
Det dokument jeg linker til fra IBM, konkludere at HVIS du står i en situation hvor du eks. har brug for meget præcis data eller lagring af meget store objekter i heapen, så giver det mening at vælge 64bit. RAM er trods alt hurtigere end SWAP.
Såfremt du IKKE benytter dig af disse parameter er anbefalingen at gå 32bit - faktisk anbefaler de at du hellere balancere over 2x32bit JVM mde hver 4GB heap, end 1x64bit JVM med 8GB.
( Alle der koerer stoerre databaser? )
( Alle der har med datastore / backup at goere? )
DB-servere har kørt 64bit en del år efterhånden, netop fordi der bliver forbrugt store mængder hukommelse og her giver det rigtig god mening.
De private der flytter rundt på nogle filer, spiller et spil, PHP-programmere lidt og bruger et tegneprogram...somehov I doubt it.
...og er memorymængden så lille at de større objekter tvinger OS til at swappe hurtigere...you do the math.
Mht fil-mapningen var det faktisk en interessant pointe, som jeg ikke kendte til.
Og her kommer sikkerhedsspoergsmaalet vel saa ind?
Hvis du ynder at bruge en form for kryptering paa bare lidt af dit data, saa vil du se en maerkbar forskel i "live" dekryptering af en partition fx.
Flere bit vil give mere præcise tal, og nemmere håndtering af kryptering/dekryptering.Du vil finde rigelig med gode grunde til at skifte til 64bit, spørgsmålet er som oftest hvad er det en maskine bliver brugt til, og hvordan bliver den brugt.
Min formodning omkring den gængse newz-bruger er:
Han spiller, laver lektier, lave lidt udvikling i PHP, .NET eller lignende niveau, så surfer han internet, laver måske lidt animationer, musik eller grafik....og så spiller han lidt mere.
Den profil vil sandsynligvis have brug for filmapninger af filer over 4GB og han vil måske også kryptere/dekryptere....en gang imellem. Til gengæld har han betalt kassen for sit system, så den kan trække Crysis, hvor hverken filmapning eller andet hjælper han.
Og den der er bare weird, men fair nok da :P
Det udvidede register giver mulighed for mere præcise tal, hvilket er en fordel for tunge forskningsberegninger.
Det er derfor de bl.a. benytter supercomputere der har kørt 64bit i årevis.
Og igen - jeg medgiver at der er en række tilfælde hvor det giver bedre mening, men hvis du vil opnå den bedste performance af Crysis og WoW...it is not the way.
#65 ved ikke hvor det kommer fra, og hvad det er han laver - som sagt der findes en stribe argumenter for hver sin platform, argumenter man skal tage med i sin analyse.
Jeg forholder mig som oftest til de applikationer der skal afvikles og deres krav, og jeg er endnu ikke stødt på apps der har aget stilling til 32/64bit, de er blot skrevet og bliver jo først compilet i runtime-øjeblikket.
De applikationer jeg har haft med at gøre, har håndteret finanssystemer, medicinalsystemer, sygehusvæsnet og fungeret som web applikationsserver for større danske websites.
Skalering sker ved at tilføje flere JVM'er, tweake GC/JVM/memorymanager, tweaker ressourcer etc.
Systemerne kører som oftest på Windows, Linux eller AIX.
#66
De udviklere jeg har snakket med siger ellers at fordelen sagtens kan opveje memory heap problemet.
Igen siger de at det kommer an paa hvordan du designer din kode.
RAM haandtering kan aabenbart optimeres ret meget i selve softwaren.
Tjah, hvilke OS'er kender du, som koerer 2x32bit og understoetter photoshop?
Eller Final Cut Pro?
Eller de utallige programmer som faar en fordel af 64bit?
Min DB server har under 4GB RAM.
Men hvor mange systemer idag, benytter databaser?
Og store database?
Skal vi noejes med at sige stort set alle?
De vil stadig faa fordelen af 64bit her, men de vil selvfoelgelig ogsaa faa ulempen med stoerre memory heap.
Spoergsmaalet er, igen, om det kan svare sig.
Personligt siger jeg ja.
Brug et OS der kan finde ud af laegge de ting du skal bruge i RAM.
Det tog mig ogsaa kun ~20 sekunders googling at finde det :P
Men det er faktisk et helt specifikt problem jeg har oplevet i Mac OS X LEopard.
Jojo, nu var det bare i relation til desktop maskiner jeg taenkte :P
Tjah, WoW kraever stort set intet.
Crysis? Tjah, mon ikke den vil faa en staerk fordel af at kunne udnytte alle 4GB RAM, fx?
Eller reelt bare at RAM haandteringen er hurtigere og bedre?
Spoergsmaalet er, om din memory heap size vil vaere stor nok til at goere en indflydelse, set ifht. de ekstra general purpose regsitre, fx.
Mit bud er at det er iigegyldigt.
64bit vil tage fordelen saa snart dit program er optimeret til det, medmindre du bruger "medium" maengder af ram, i meget smaa allokationer.
Og i det tilfaelde kan du bare kaste mere RAM i maskinen, og 64bit vinder alligevel.
Praecis.
Jeg kender en del.
En hel del, faktisk.
Men primaert er det jo nok compileren der har taget stilling og derigennem kan den optimere for 64bit.
Udvikleren skal kun interessere sig en lille smule for 64bit for at vide hvad han skal goere anderledes, som jeg forstaar det.
Og alle disse koerer 32bit? Eller 2x32bit?
Nej? Godt saa :)
Selvfoelgelig kan du finde specifikke eksempler hvor 16bit er hurtigere, det skal ses med generelle oejne.
Og saa snart udviklerne reelt tager sig sammen og designer deres software efter 64bit, saa boer memory heap problemet vaere umaerkbart ifht. fordelene.
Ja - men de hverken ændrer på hvordan tingene hænger sammen, eller giver dig nok boost til, at du kommer ud over den ineffektivisering der sker af din RAM.
De udviklere jeg har snakket med siger ellers at fordelen sagtens kan opveje memory heap problemet.
Igen siger de at det kommer an paa hvordan du designer din kode.
RAM haandtering kan aabenbart optimeres ret meget i selve softwaren.
Det dokument jeg linker til fra IBM, konkludere at HVIS du står i en situation hvor du eks. har brug for meget præcis data eller lagring af meget store objekter i heapen, så giver det mening at vælge 64bit. RAM er trods alt hurtigere end SWAP.
Såfremt du IKKE benytter dig af disse parameter er anbefalingen at gå 32bit - faktisk anbefaler de at du hellere balancere over 2x32bit JVM mde hver 4GB heap, end 1x64bit JVM med 8GB.
Tjah, hvilke OS'er kender du, som koerer 2x32bit og understoetter photoshop?
Eller Final Cut Pro?
Eller de utallige programmer som faar en fordel af 64bit?
DB-servere har kørt 64bit en del år efterhånden, netop fordi der bliver forbrugt store mængder hukommelse og her giver det rigtig god mening.
Min DB server har under 4GB RAM.
Men hvor mange systemer idag, benytter databaser?
Og store database?
Skal vi noejes med at sige stort set alle?
De private der flytter rundt på nogle filer, spiller et spil, PHP-programmere lidt og bruger et tegneprogram...somehov I doubt it.
De vil stadig faa fordelen af 64bit her, men de vil selvfoelgelig ogsaa faa ulempen med stoerre memory heap.
Spoergsmaalet er, igen, om det kan svare sig.
Personligt siger jeg ja.
...og er memorymængden så lille at de større objekter tvinger OS til at swappe hurtigere...you do the math.
Brug et OS der kan finde ud af laegge de ting du skal bruge i RAM.
Mht fil-mapningen var det faktisk en interessant pointe, som jeg ikke kendte til.
Det tog mig ogsaa kun ~20 sekunders googling at finde det :P
Men det er faktisk et helt specifikt problem jeg har oplevet i Mac OS X LEopard.
Det udvidede register giver mulighed for mere præcise tal, hvilket er en fordel for tunge forskningsberegninger.
Det er derfor de bl.a. benytter supercomputere der har kørt 64bit i årevis.
Jojo, nu var det bare i relation til desktop maskiner jeg taenkte :P
Og igen - jeg medgiver at der er en række tilfælde hvor det giver bedre mening, men hvis du vil opnå den bedste performance af Crysis og WoW...it is not the way.
Tjah, WoW kraever stort set intet.
Crysis? Tjah, mon ikke den vil faa en staerk fordel af at kunne udnytte alle 4GB RAM, fx?
Eller reelt bare at RAM haandteringen er hurtigere og bedre?
Spoergsmaalet er, om din memory heap size vil vaere stor nok til at goere en indflydelse, set ifht. de ekstra general purpose regsitre, fx.
Mit bud er at det er iigegyldigt.
64bit vil tage fordelen saa snart dit program er optimeret til det, medmindre du bruger "medium" maengder af ram, i meget smaa allokationer.
Og i det tilfaelde kan du bare kaste mere RAM i maskinen, og 64bit vinder alligevel.
ved ikke hvor det kommer fra, og hvad det er han laver - som sagt der findes en stribe argumenter for hver sin platform, argumenter man skal tage med i sin analyse.
Praecis.
Jeg forholder mig som oftest til de applikationer der skal afvikles og deres krav, og jeg er endnu ikke stødt på apps der har aget stilling til 32/64bit, de er blot skrevet og bliver jo først compilet i runtime-øjeblikket.
Jeg kender en del.
En hel del, faktisk.
Men primaert er det jo nok compileren der har taget stilling og derigennem kan den optimere for 64bit.
Udvikleren skal kun interessere sig en lille smule for 64bit for at vide hvad han skal goere anderledes, som jeg forstaar det.
De applikationer jeg har haft med at gøre, har håndteret finanssystemer, medicinalsystemer, sygehusvæsnet og fungeret som web applikationsserver for større danske websites.
Skalering sker ved at tilføje flere JVM'er, tweake GC/JVM/memorymanager, tweaker ressourcer etc.
Systemerne kører som oftest på Windows, Linux eller AIX.
Og alle disse koerer 32bit? Eller 2x32bit?
Nej? Godt saa :)
Selvfoelgelig kan du finde specifikke eksempler hvor 16bit er hurtigere, det skal ses med generelle oejne.
Og saa snart udviklerne reelt tager sig sammen og designer deres software efter 64bit, saa boer memory heap problemet vaere umaerkbart ifht. fordelene.
Jeg synes de udviklere du taler med ændrer forklaring, efterhånden som du bliver mere skarp på problematikken.fidomuh (67) skrev:#66
De udviklere jeg har snakket med siger ellers at fordelen sagtens kan opveje memory heap problemet.
Igen siger de at det kommer an paa hvordan du designer din kode.
RAM haandtering kan aabenbart optimeres ret meget i selve softwaren.
Igår anede de ikke der var et problem, til trods for at de skrev drivere - idag erhh..."optimere" de sig ud af sagernes tilstand.
Kan du lige forklarer mig hvordan man optimere en 64bit adressering ned, så den fylder 32bit - for det forstår jeg ikke.
Tjah, hvilke OS'er kender du, som koerer 2x32bit og understoetter photoshop?
Eller Final Cut Pro?
Erhhh jeg forstår ikke dit sprøgsmål.
En 32bit applikation afviklet i et 64bit OS, fungere som en 32bit applikation internt. Det betyder 4GB adresserum, mindre integers etc.
Min DB server har under 4GB RAM.
Men hvor mange systemer idag, benytter databaser?
Og store database?
Skal vi noejes med at sige stort set alle?
???
Hvad er det du argumentere for der?
At store DB-servere skal afvikles i et 64bit miljø?
For så er det jo bare en ren gentagelse af hvad jeg hele tiden har sagt.
De vil stadig faa fordelen af 64bit her, men de vil selvfoelgelig ogsaa faa ulempen med stoerre memory heap.
Spoergsmaalet er, igen, om det kan svare sig.
Personligt siger jeg ja.
Baseret på...?
Brug et OS der kan finde ud af laegge de ting du skal bruge i RAM.
Hvis du ligger mærke til det, er mine argumenter generiske.
Memorymanageren i Windows er ikke synderlig imponerende, men en vilkårlig Linux/UNIX forbruger stadig 64bit adressering...du ved...samme problem.
Jeg forstår ikke du bliver ved med at trække Windows op af hatten.
Jojo, nu var det bare i relation til desktop maskiner jeg taenkte :P
Ditto, hvorfor jeg synes det er omsonst at tage store DB-servere med i diskussionen.
Tjah, WoW kraever stort set intet.
Crysis? Tjah, mon ikke den vil faa en staerk fordel af at kunne udnytte alle 4GB RAM, fx?
Eller reelt bare at RAM haandteringen er hurtigere og bedre?
Det er begge 32bit apps, som langt de fleste spil er, hviket der er en god grund til....performance you know!
Spoergsmaalet er, om din memory heap size vil vaere stor nok til at goere en indflydelse, set ifht. de ekstra general purpose regsitre, fx.
Mit bud er at det er iigegyldigt.
64bit vil tage fordelen saa snart dit program er optimeret til det, medmindre du bruger "medium" maengder af ram, i meget smaa allokationer.
Og i det tilfaelde kan du bare kaste mere RAM i maskinen, og 64bit vinder alligevel.
Igen...dit bud kontra kedelige test.
...desuden, hvis vi skal hænge i det, kræver det jo at din applikation kan udnytte der er mere RAM.
Du kan jo sagtens lave en app der forbruger 500MB heap, hvilket så vokser til 800MB ved 64 bit - så er det kun neddroslingen af cache der hænger ved.
Hvis din lille DB-server derhjemme forbruger 1.2GB RAM, kan du hælde alt det i den du vil, den kommer jo ikke op at bruge mere.
Man kan sige at du stresser den nok heller ikke tilstrækkelig hårdt til at det har den store betydning.
Og alle disse koerer 32bit? Eller 2x32bit?
Nej? Godt saa :)
...de gør de så - vi optimere for mest mulig performance af den enkelte applikation.
Selvfoelgelig kan du finde specifikke eksempler hvor 16bit er hurtigere, det skal ses med generelle oejne.
Der var nøjagtig samme diskussion da 32bit kom på scenen. Mange regnede med det ville give nyt liv til deres systemer, men reaktionen var nærmest det modsatte. Der gik en del år, før 32bit rigtig tog over.
Det var først da man begyndte at virkelig udnytte den øgede mængde hukommelse, at 32bit rykkede fra 16bit.
Og saa snart udviklerne reelt tager sig sammen og designer deres software efter 64bit, saa boer memory heap problemet vaere umaerkbart ifht. fordelene.
...igen, hvordan får du et 64bit adresserum komprimeret ned til at optage 32bit.
64bit er fremtiden.
Har du brug for massive mængder RAM er 64bit den eneste vej.
Men ligenu? Den gængse Newz-brugers hjemmePC?
No way.
#68
Ved du hvordan general purpose registre fungerer?
Som jeg forstaar det, er det stort set her alt performance boost ved 64bit kommer fra.
( Naar vi ikke snakker kryptering og saadan )
Det er saadan set det samme jeg siger:
General purpose regsitre.
Problemet er selvfoelgelig kendt, igen det er dig der paastaar at udviklere ikke aner en skid om teknik .. ? :)
Udvikleren her har hele tiden sagt at problemet ikke er noget han ser som en hindring for at koere 64bit, netop fordi det opvejes af andre fordele.
Hvor har jeg sagt at du kan det?
Du ved vel godt at AMD64 har flere fordele end muligheden for at have mere end 3GB RAM ? :)
Saaeh, man starter IE og et random spil ? :P
Sidst jeg kiggede her, saa var RAM forbruget paa diverse spil ret hoejt.
Specielt hvis man ynder at have random ting koerende i baggrunden.
At databaser ikke er forbeholdt Exchange servere, eller SQL Servere, eller servere i det hele taget.
Et hurtigt kig paa Lightwave ( billedearkiv-behandlings-program-ting ), siger at min database er muthafucker stor.
Allerede her, vil jeg have en fordel af 64Bit.
Nej.
Hvis du med "desktop" mener en person der booter sit OS og starter en mailklient, en browser og maaske til noeds et IM program, saa ja, saa vil 32bit vaere rigeligt de naeste 10 aar.
Det vil 16bit som saadan ogsaa.
Langt de fleste newz.dk brugere, har et mere udpraeget behov.
Alene i spilverden vil der komme mange fordele ved at bruge 64bit, da man snildt kan faa fordel af de ekstra registre, samt at man allerede idag har store filer som haandteres internt.
De er typisk brudt op i mindre filer, hvilket man ikke behoever med 64bit.
Databaser bruges ogsaa ofte i stoerre spil.
Ved du hvordan general purpose registre fungerer?
Som jeg forstaar det, er det stort set her alt performance boost ved 64bit kommer fra.
( Naar vi ikke snakker kryptering og saadan )
Jeg synes de udviklere du taler med ændrer forklaring, efterhånden som du bliver mere skarp på problematikken.
Det er saadan set det samme jeg siger:
General purpose regsitre.
Igår anede de ikke der var et problem, til trods for at de skrev drivere - idag erhh..."optimere" de sig ud af sagernes tilstand.
Problemet er selvfoelgelig kendt, igen det er dig der paastaar at udviklere ikke aner en skid om teknik .. ? :)
Udvikleren her har hele tiden sagt at problemet ikke er noget han ser som en hindring for at koere 64bit, netop fordi det opvejes af andre fordele.
Kan du lige forklarer mig hvordan man optimere en 64bit adressering ned, så den fylder 32bit - for det forstår jeg ikke.
Hvor har jeg sagt at du kan det?
Du ved vel godt at AMD64 har flere fordele end muligheden for at have mere end 3GB RAM ? :)
...desuden, hvis vi skal hænge i det, kræver det jo at din applikation kan udnytte der er mere RAM.
Du kan jo sagtens lave en app der forbruger 500MB heap, hvilket så vokser til 800MB ved 64 bit - så er det kun neddroslingen af cache der hænger ved.
Saaeh, man starter IE og et random spil ? :P
Sidst jeg kiggede her, saa var RAM forbruget paa diverse spil ret hoejt.
Specielt hvis man ynder at have random ting koerende i baggrunden.
Hvad er det du argumentere for der?
At store DB-servere skal afvikles i et 64bit miljø?
At databaser ikke er forbeholdt Exchange servere, eller SQL Servere, eller servere i det hele taget.
Et hurtigt kig paa Lightwave ( billedearkiv-behandlings-program-ting ), siger at min database er muthafucker stor.
Allerede her, vil jeg have en fordel af 64Bit.
For så er det jo bare en ren gentagelse af hvad jeg hele tiden har sagt.
Nej.
Hvis du med "desktop" mener en person der booter sit OS og starter en mailklient, en browser og maaske til noeds et IM program, saa ja, saa vil 32bit vaere rigeligt de naeste 10 aar.
Det vil 16bit som saadan ogsaa.
Langt de fleste newz.dk brugere, har et mere udpraeget behov.
Alene i spilverden vil der komme mange fordele ved at bruge 64bit, da man snildt kan faa fordel af de ekstra registre, samt at man allerede idag har store filer som haandteres internt.
De er typisk brudt op i mindre filer, hvilket man ikke behoever med 64bit.
Databaser bruges ogsaa ofte i stoerre spil.
Hvad er chancen for, at det holder i retten hvis man køber den her version via eBay - og at man ikke fårproblemer senerehen:
http://cgi.ebay.co.uk/Window-7-Professional-32bit-...
http://cgi.ebay.co.uk/Window-7-Professional-32bit-...
#70
Du kan netop købe Win7 uden et fysisk medie direkte fra MS, hvor du bare får en nøgle og et download link, så der tror jeg ikke der er problemer.
Men jeg ville lige dobbelttjekke ratings osv. for at være sikker på at du får et reelt produkt.
Du kan netop købe Win7 uden et fysisk medie direkte fra MS, hvor du bare får en nøgle og et download link, så der tror jeg ikke der er problemer.
Men jeg ville lige dobbelttjekke ratings osv. for at være sikker på at du får et reelt produkt.
#70 den holder ikke i retten. Det er Technet keys der bliver solgt på eBay, og det er ulovligt ifølge Microsoft's eula.. Tror det er rimeligt 50/50 om du bliver opdaget, men hvis du bliver opdaget sker der nok ikke andet end at din key bliver blacklisted. Spørgsmålet er så om det er noget du vil risikere.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Software
Gå til bund