I Roskilde har vi nu besluttet at lægge yderligere teknologisk afstand til vikingeskibene ude i fjorden ved at udskifte det veludtjente XP styresystem med Windows7 på organisationens 2-3000 arbejdspladser.
I den forbindelse rejser der sig som noget nyt et spørgsmål, hvorvidt man skal vælge 32-bit- eller 64-bit udgaven af det nye styresystem.
Vi har lavet lidt research på emnet og er kommet frem til følgende:
Generelt fornemmer vi, at vinden blæser i retning af 64-bit styresystemer, men som landet ligger lige p.t. er der en række forhold, der får os til at vælge 32-bit udgaven for de kommende par år:
...men hvis man skal gøre det nu så er 64-bit klart vejen at gå, det er bare spg. om kort tid inden de første 64-bit only versioner dukker op. På en 64-bit Windows 7 Pro følger en fuld virtualiseret Windows XP.
Hvis jeg skulle vælge ville jeg i stedet enten gå Citrix-vejen eller køre med virtuelle desktops og køre på små tynde klienter, det giver nemmere og mindre vedligeholdelse og data ligger centralt og sikkert.
er typisk den værste synder men er blevet bedre med 7 end med Vista.
AV er typisk ikke et problem mere.
64bit hardware dep og patchguard er også et plus men spørgsmålet er om det er driver besværet værd.
I Roskilde har vi nu besluttet at lægge yderligere teknologisk afstand til vikingeskibene ude i fjorden
Selv den dag i dag, vil vikingeskibene som type være i stand til at bringe en sikkert over atlanten - det er mere end hvad man kan sige om et fartøj nittet sammen af 0,5 mm aluminiumsplader og påmonteret 32 stk. 4 hestes påhængsmotorer.
/Christian
Jeg er sådan set relativt glad for min x64 Win7, men det har været en kamp op ad bakke på nogle områder:
Cisco laver ikke en x64 VPN-klient
Printerdrivers
non-MS x64-bit software
Når det så er sagt, så vil jeres "productivity-gains" nok mere være forårsagede af skiftet fra XP til Win7 som sådan og ikke om det er x64 eller x32 Win7.
Det er korrekt, at Cisco længe har haltet bagefter på x64 vognen, men de er langt om længe kommet med i form af deres Cisco Anyconnect.
Mine anbefalinger er klar x64 vejen - x86 er en døende platform (omend den vil blive holdt kunstigt i live via WoW64 i fht. bagundkompatibilitet)!
Hej Michael,
Det er korrekt, at Cisco længe har haltet bagefter på x64 vognen, men de er langt om længe kommet med i form af deres Cisco Anyconnect.
Det er korrekt - men AnyConnect virker jo ikke, hvis endpointet ikke understøtter det.
(det er et konkret problem for de af os, der supporterer kunder, der ikke alle har "opgraderet" til AnyConnect)
"Når det så er sagt, så vil jeres "productivity-gains" nok mere være forårsagede af skiftet fra XP til Win7 som sådan og ikke om det er x64 eller x32 Win7."
Nu er Windows 7 ikke ligefrem en drøm at få i hænderne, så jeg forudser et "productivity-loss" på den konto.
Hej Jesper,
Nu er Windows 7 ikke ligefrem en drøm at få i hænderne, så jeg forudser et "productivity-loss" på den konto
Det er muligt, at det ikke er [b]din[/b] drøm, men i forhold til XP er det min egen erfaring, at der i mit daglige arbejde er ting, som jeg nu ikke længere skal bakse med.
Det betyder mere værdi for min kunde :o)
(og det er naturligvis helt sikkert, at andre har andre erfaringer)
Nu er det vel ikke sådan at du vil udskifte den fysiske hardware. Du kan jo ikke installere en 64 bit operativsystem på en 32 bit processor. Så hvis du ikke umiddelbart ønsker at belaste de kommunale budgetter med nye maskiner er valget vel ikke så svært.
På nye maskiner derimod ville jeg klart vælge 64 bit. 3 gigabyte ram er ikke alverden, og da slet ikke hvis man kikker bare få år fremad.
Så svaret er tvetydigt. Det er ikke 32 eller 64 bit, det er både og...
Hej Klaus,
Nu er det vel ikke sådan at du vil udskifte den fysiske hardware. Du kan jo ikke installere en 64 bit operativsystem på en 32 bit processor. Så hvis du ikke umiddelbart ønsker at belaste de kommunale budgetter med nye maskiner er valget vel ikke så svært.
De kan sagtens have maskiner, der er x64-kompatible i forvejen. Jeg har fx haft min T61p i et par år nu, så i mit tilfælde kunne jeg skifte til x64 ... uden at skulle skifte hardware.
:o)
Jeg var sent ude med 64-bit CPU tilbage i 2006. Mon ikke maskinerne i Roskilde Kommune er nyere?
"Det er muligt, at det ikke er din drøm, men i forhold til XP"
Jeg kender mange der må leve med Windows 7, som følge at hardwareopgraderinger der kræver det OS, men der er godt nok ikke mange af dem der ligefrem nyder at bruge det.
Selv holder jeg mig fra hardware der kræver Win7.
Hej Jesper,
men der er godt nok ikke mange af dem der ligefrem nyder at bruge det.
Tja :o)
Selv holder jeg mig fra hardware der kræver Win7.
Hvilken hardware kræver Win7?
(jeg ved ikke så meget om hardware - det bliver som oftest stillet til rådighed)
"Hvilken hardware kræver Win7?"
AMD/ATI's nye 5000-serie grafikkort. Der er drivere til Windows 7. Punktum.
Det er noget vrøvl Jesper P. Der er drivere til XP Vista, Win7 m.fl.
Det er muligt at din specifikke producent har valgt kun at tilpasse driverpakken til Windows 7, men så må du jo bruge AMD/ATI versionen istedet.
http://game.amd.com/us-en/drivers_catalyst.aspx?p=xp/radeonx-xp
Jeg gyser når jeg ser personer der på deres nye PC'er med Win7 præinstalleret starter med at installere deres elskede XP.
IT flytter sig, skal du med?
"Hvilken hardware kræver Win7?"
AMD/ATI's nye 5000-serie grafikkort. Der er drivere til Windows 7. Punktum.
Hvor har du det fra? Jeg kan da finde HD 5000 drivere til XP, Vista, 7 og Linux i både 32 og 64 bit udgaver på AMDs hjemmeside.
Nu har vi i UNIX-miljøet haft fornøjelsen af 64-bit operativsystemer på vores 64-bit maskiner i et stykke tid. Fordi meget af softwaren er Open Source er problemet med et skifte fra 32 til 64 noget mindre her. Vi kan simpelthen bare rette problemerne i softwaren direkte og genoversætte det til den nye platform. Naturligvis er det ting såsom Flash (closed source generelt) der har skabt problemer, men det er nu også så småt ved at være på plads.
Det er ikke altid en fornøjelse at vælge 64-bit dog. Bemærk at godt nok kan der addresseres hukommelse over 3 gigabyte-grænsen, men da enhver pointer fylder det dobbelte betyder det også at programmer bruger mere hukommelse når de kører. Et skud er omkring 20-30% mere, men det afhænger naturligvis af softwaren. Det er væsentligt at have med i overvejelserne når man udruller til 2-3000 maskiner og kender deres RAM-konfiguration. Spørgsmålet beror på om maskiner med eksempeltvist 2-4 Gigabyte bestykning ikke er bedre tjent med 32-bit fordi de så vinder lidt mere hukommelse på at pointere fylder mindre.
Der hvor 64-bit virkeligt batter er når man går til 8 gigabyte RAM eller mere. Umiddelbart skal vi så have den store tunge masse af Windowsmaskiner flyttet 32 -> 64 og det er som sagt ikke en nem øvelse fordi meget af softwaren ikke kan "reddes" med en rettelse og genoversættelse. Med andre ord kan der nemt komme til at gå noget tid hvor 32 bit stadig benyttes. Desuden kan man komme noget af vejen med PAE:
http://en.wikipedia.org/wiki/Physical_Address_Extension
Men udfra listen på Wikipedia lader det til at det er nogo for Windows 7, fordi Microsoft har valgt at det skulle være sådan. Formentlig dels for at tvinge folk op på 64 bit, dels for at tjene penge. Det giver nemlig god mening for udviklingen hos microsoft at man kan slagte 32-bit support i den nærmere fremtid og derved spare udviklingstimer.
"IT flytter sig, skal du med?"
Er er i fuld gang - bare ikke på Windows. Når spilsupporten for XP dør ud, så er Windows dødt hos mig. Helt dødt.
Jeg har Linux som primære OS og det skifter jeg ikke væk fra.
"Hvor har du det fra?"
Det har jeg fra 3 købere af HD 5770. Det er muligt at de andre er kommet til senere. HD 5770 var ret nyt, da de indkøbte deres kort.
"andre ord kan der nemt komme til at gå noget tid hvor 32 bit stadig benyttes. Desuden kan man komme noget af vejen med PAE:"
PAE findes som en boot-parameter i XP, men kun for at give mulighed for NX-bit (det er bit 63 i register CR3).
PAE er muligt i større Windows Server - selv i en version af 2000 Server. Grunden til at desktop-Windows ikke understøtter andet end NX-bit med deres /PAE er at ikke alt software kan finde ud af at der er RAM over 4GiB-grænsen.
Mht. Linux, så har jeg 32-bit og PAE-support til mit 8GiB-system. Og Compiz-Fusion med hele GUI kørende på grafikkortet.
Det er ikke altid en fornøjelse at vælge 64-bit dog. Bemærk at godt nok kan der addresseres hukommelse over 3 gigabyte-grænsen, men da enhver pointer fylder det dobbelte betyder det også at programmer bruger mere hukommelse når de kører. Et skud er omkring 20-30% mere, men ...
Jeg har hørt det argument før, men har svært ved at tro at effekten kan være signifikant.
Hvis et program i 32-bit allokerer 3GB RAM, og hvis det i 64-bit skulle allokere 25% mere (768MB) på grund af den fordoblede pointer-størrelse, så skulle programmet have godt 200 mio. ative pointere på een gang.
Det synes jeg lyder som et usædvanligt stort antal aktive pointere (med mindre man (mis)bruger rekursive funktioner).
Jeg har ganske god erfaring med 64-bit Windows 7, men jeg synes at det er det rigtige valg at basere sig på 32-bit når man skal rulle ud på 2-3000 arbejdsstationer.
Det er på mange måder det sikre valg og hvis man ikke har et stort ram-behov på disse arbejdsstationer så er det også svært at argumentere for 64-bit. Som Flemming nævner er der dog nogle sikkerhedsmæssigt spændende tiltag i 64-bit udgaverne, men man kan omvendt argumentere for at det er gået alvorligt galt i første omgang, hvis noget malware er ved at forsøge at lave kernel-patching.
Så alt i alt synes jeg at jeres valg lyder ganske fornuftigt.
Lars: Jeg er helt enig i din observation. Jeg har heller ikke i praksis oplevet signifikant forøgelse i hukommelsesforbruget ved skift fra 32 til 64-bit. Alligevel dukker argumentet jævnligt op.
Med den applikationsportefølje, som kommunen p.t. anvender, vurderer vi, at 98% af alle vores brugere vil leve rigtig fint med et 32-bit styresystem. Kun et lillebitte mindretal vil have gavn af et 64-bit styresystems mulighed for at tilgå mere RAM og de deraf afledte muligheder for at køre avancerede applikationer - og flere på samme tid.
Hvor mange % af kommunens brugere vil kunne leve fint med Windows XP?
Ole, det slår mig, at du på intet tidspunkt kommer med en reel begrundelse for at skifte alle arbejdspladser ud med Windows 7. Mangler I noget at tage jer til på IT-kontoret i Roskilde Kommune?
Misforstå mig ikke, det er ikke et forsøg på at være fræk, men derimod en oprigtig undren over hvilke programmer man mon kan køre i den kommunale sektor, der ikke kører lige så godt i Windows XP som i Windows 7.
At Microsoft har fundet en ny guldkalv er vel i sig selv ikke grundlag for at bruge en masse skattekroner og skatteyderbetalte IT-medarbejdertimer på at udskifte kommunens operativsystemer?
Jeg har hørt det argument før, men har svært ved at tro at effekten kan være signifikant.
Ud over pointerstørrelsens forskel er der som regel også andre alignment-krav. Det spiller en del ind i forbindelse med caches, padding mm.
Der ryger der en del pointere hver gang et program allokerer noget hukommelse til malloc-implementationen. Garbage-collectors har som regel også større GC-headers på en 64-bit arkitektur.
Men det helt afgørende, og det du er inde på, er hvor mange pointere programmet rent faktisk har. Typiske programmer der er rigtigt glade for hukommelse har det med at allokere den i store klumper og dermed har de et minimalt antal pointere. Du kan formentlig ikke se forskellen på disse.
På den anden side har du programmer, typisk garbage collectede og naivt kodede, som smider om sig med pointere. Når GC-headeren fylder det dobbelte og man allokerer mange små objekter, så kan det hurtigt løbe op. Du kan også se det på en anden måde: Hvor mange procent af dine data-strukturer i programmet sidder med en reference/pointer til andet data? Og hvor mange af disse allokeres der hver især?
Jeg må indrømme at jeg ikke helt kan følge dig mht. rekursive funktioner og hukommelsesforbrug. Enten er den rekursive funktion hale-rekursiv og er dermed svarende til en løkke, eller også bruger den stak-plads i hvilken forbindelse jeg ikke kan se hvordan den skulle have brug for mere hukommelse.
Teoretisk set lyder din teori god - den praktiske erfaring på eks. .NET platformen er dog en anden.
Ved x86 applikationer bliver der smidt en OutOfMemoryException ved omkring 1-1.2 GB forbrugt fysisk hukommelse.
Hvis du kompilere selvsamme applikation til en ren x64 applikation, så bruger den bare løs, også til den begynder at swappe.
Vi kan så hurtigt blive enige om, at applikationen ikke bør bruge så meget hukommelse, men det var mere for at skitsere et praktisk eksempel over et teoretisk :-)
Hvor mange % af kommunens brugere vil kunne leve fint med Windows XP?
Kan man overhovedet købe en ny PC længere hvor producenten er villig til at sige XP er understøttet? Eller måske, hvor længe endnu uden prisen bliver urimelig?
"Det har jeg fra 3 købere af HD 5770. Det er muligt at de andre er kommet til senere. HD 5770 var ret nyt, da de indkøbte deres kort."
Det giver ingen mening overhovedet - XP er stadigt det klart mest brugte OS, det ville være totalt hul i hovedet ikke at have XP drivere ved release.
Jeg må indrømme at jeg ikke helt kan følge dig mht. rekursive funktioner og hukommelsesforbrug. Enten er den rekursive funktion hale-rekursiv og er dermed svarende til en løkke, eller også bruger den stak-plads i hvilken forbindelse jeg ikke kan se hvordan den skulle have brug for mere hukommelse.
Ethvert funktions-kald smider mindst een adresse på stakken, og på en 64-bit maskine vil dette betyde øget hukommelsesbrug på samme måde som brug af pointere. Det kan løbe op, hvis man har meget dyb rekursion.
Iøvrigt så har applikationerne her på gangen typisk op til mellem 1.000 og 100.000 aktive pointere.
"Det giver ingen mening overhovedet - XP er stadigt det klart mest brugte OS, det ville være totalt hul i hovedet ikke at have XP drivere ved release."
Enig. Og det har man nok efterfølgende erfaret. Men ved release hed det Win 7 og ville man bruge sit nye kort, så måtte man nedgradere til Win 7.
Ole Bech,
Jeg kunne egentlig også godt tænke mig, at se en økonomisk beregning som retfærdiggør et skifte.
Hvad regner du med at skiftet kommer til at koste, alene i tidsforbrug i forbindelse med installation og undervisning af slutbrugere ?
Set i sammenhæng med din holdning til kontorpakker i folkeskolen (http://www.version2.dk/artikel/13805-officepakker-har-foraeldres-bevaage...) vil jeg tillade mig, at konkludere:
Finanskrisen er ikke slået igennem i Roskilde kommune!
Driverne til XP fulgte med på cd'en ifølge diverse forums.
Iøvrigt så har applikationerne her på gangen typisk op til mellem 1.000 og 100.000 aktive pointere.
Det skyder unægteligt teorien ned om at det er pointere, om overhovedet noget, der påvirker det øgede hukommelsesforbrug.
"Driverne til XP fulgte med på cd'en ifølge diverse forums. "
Så er den kommet til siden, skriver jeg jo.
Det er nok ikke for sjov at 3 mand går ud og investerer i Windows 7, bare for at kunne bruge deres nye 5770 - når deres OS i forvejen var godt nok til opgaven!
Ved x86 applikationer bliver der smidt en OutOfMemoryException ved omkring 1-1.2 GB forbrugt fysisk hukommelse.
Windows VM-model er ikke min stærke side, men lad mig alligvel lave et kvalificeret gæt:
Du har kun 2Gb til rådighed. Ellers er det 3Gb. Det kommer lidt an på hvorledes windows behandler x86-arkitekturen. .NET har en Garbage collector som skal bruge noget friplads for at kunne kopiere live-objects rundt. Derfor rammer du muren omkring 1-1.2Gb fordi der vitterligt ikke er mere plads at tage af på en x86 arch.
På x86-64 har du noget mere at give af, fordi du ikke er klemt inde i det forholdvist lille hukommelsesområde 2Gb er. Derfor kan page-filen og andet VM-snask komme i spil på den arkitektur.
Jesper:
Drivere har fulgt med på cd'er lige så længe jeg kan huske.
Jeg siger ikke, at du lyver, jeg tror bare ikke dine kammerater har kigget godt nok efter. Driverne var tilgængelige på cd'en og på amd's hjemmeside ved launch.
Min erfaring er at det kun er ASP.NET under 32-bit IIS der har denne 1-1.2 GB begrænsning. Alm. 32-bit .NET applikationer og services mener jeg sagtens kan gøre fuld brug af hukommelsen (enten 2GB usermode eller 3GB usermode såfremt /3GB switchen er sat)
Jeg er lidt i tvivl om denne grænse også gælder for 32-bit IIS 7 eller om den kun var relevant for IIS 6 - jeg har dog kun arbejdet med IIS 7 på 64-bit, men der er tale om en helt ny arkitektur i 7'eren så det er bestemt en mulighed - jeg er blot glad for ikke længere at rende ind i den :-)
Min erfaring er at det kun er ASP.NET under 32-bit IIS der har denne 1-1.2 GB begrænsning. Alm. 32-bit .NET applikationer og services mener jeg sagtens kan gøre fuld brug af hukommelsen (enten 2GB usermode eller 3GB usermode såfremt /3GB switchen er sat)
Det er ligegyldigt om det ASP.NET eller traditionelle Windows-applikationer - er det .NET samt en x86 version af OS, så er grænsen omkring de 1-1.2GB. Forskellen er blot, at under ASP.NET kan man komme uden for en egentlig "frysning" af W3P processen .. dvs. den smider ikke nødvendigvis OutOf..., men holder ganske enkelt op med at svare.
Denne viden er kun kommet gennem uhensigtsmæssig kodning - så intet er så galt, at det ikke er godt for noget. Lesson learned ;-)
Windows VM-model er ikke min stærke side, men lad mig alligvel lave et kvalificeret gæt:
Du har kun 2Gb til rådighed. Ellers er det 3Gb. Det kommer lidt an på hvorledes windows behandler x86-arkitekturen. .NET har en Garbage collector som skal bruge noget friplads for at kunne kopiere live-objects rundt. Derfor rammer du muren omkring 1-1.2Gb fordi der vitterligt ikke er mere plads at tage af på en x86 arch.
På x86-64 har du noget mere at give af, fordi du ikke er klemt inde i det forholdvist lille hukommelsesområde 2Gb er. Derfor kan page-filen og andet VM-snask komme i spil på den arkitektur.
Jeg ved ikke helt hvorfor du blander VM ind i det, men en applikation bygget til x86 (og ikke x32 som nogle fejlagtigt skriver) har vitterligt denne grænse. Det kan meget vel være GC'en der spiller ind, men bygger jeg selvsamme applikation til x64 så sparker den derud af.
Måske er begrænsingen vitterligt i .NET x86 afvikling - og det er så ligegyldigt om den bliver eksekveret på et rent x86 OS med /3GB slået til eller under WoW64 - 1-1.2GB er grænsen.
Maskinen i mit eksempel har 8GB RAM og er udført på både Vista samt 7 - begge x64 versioner.
En lille anbefaling til alle kodere - don't do strings ;-)
Hej Michael
Jeg følte mig ret sikker på at jeg havde testet grænsen før og kun fundet den aktuel for IIS-hostede .NET applikationer, men jeg har lige skrevet et lille test-program for at efterprøve igen og jeg må medgive at det ser ud til at du har ret - den smider en outofmemory lige omkring når den runder 1 GB forbrug. Ved du noget om årsagen hertil? Jeg undrer mig en smule da der jo burde være 2 GB usermode memory tilrådighed.
Jeg prøvede lige for sjov samme program under x64 og på min workstation med 6,4GB fri hukommelse lykkedes det at allokere samtlige 6,4GB - altså ingen mystisk begrænsning her eller behov for at have noget overskydende ledig hukommelse tilrådighed.
Men hatten af for det, jeg må erkende at jeg tog fejl :-)
....men hvorfor er det overhovedet nødvendigt, at opgradere jeres systemer? Det jeg mener er at jeg har svært ved at se hvor det er brugernes behov bevæger sig udenfor f.eks. XP. Det er vel begrænset hvor mange brugere i har siddende rundt omkring, der bruger computeren til andet end mails, teksbehandling og adgang til specifikke databaser??? Nu er jeg ganske udemærket klar over at IT har det med at gå i stykker og derfor skal udskiftes. Jeg er endvidere også ganske udemærket klar over at den løbende udskiftning naturligvis også vil medføre en eller anden form for organisk opgradering af systemerne. Med andre ord ved jeg sådan set godt det ikke er realistisk, at låse en kommunes IT fast for evigt. Pointen er at de eneste overvejelser en kommunal IT-chef bør gøre sig, i forbindelse med opgradering, må være følgende:
Kan skidtet sende og modtage mails? Kan det klare almindelig teksbehandling? Kan koble det til vores printere/Skal vi have nye printere? Kan vi beskytte det mod virus (og medarbejderne)? Hvor længe er det realistisk at have dette system kørende, inden vi skal skifte igen?
Det første spørgsmål burde være nemt at klare - man skal ihvertfald nok lede længe efter et system der ikke kan leve op til det krav. Det næste spørgsmål er vel lidt samme melodi... Mht. printere og virus vil jeg påstå det er en situation hvor i kan spille med musklerne overfor de fleste alternativer - mon ikke enten producenten af det nye system eller jeres nuværende virusbeskytter/printerleverandør kan finde ud af noget smart der, med de 3000 slutbrugere i baghovedet? Mht. levetiden for systemet er det jo der IT-chefen virkeligt skal tjene sine penge - men mon ikke han får nok i lønningsposen til man kan forvente han kan vurdere den slags?
Beklager off-topic.
Daniel & Michael:
Forstår jeg jer ret, hvis i siger, at hvert program maks. kan allokere 1 GB RAM i Windows XP/Vista/7 32-bit?
I så fald, så begynder jeg at kunne forstå, hvorfor vi har så mange problemer med Illustrator, der løber tør for hukommelse. :)
Forstår jeg jer ret, hvis i siger, at hvert program maks. kan allokere 1 GB RAM i Windows XP/Vista/7 32-bit?
For Javaprogrammer gælder det ihvertfald at man ikke kan lade dem bruge mere end ca 1.2 GB RAM på 32 bit Windows. Det har intet at gøre med x86 arkitekturen, da jeg sagtens kan lade samme program bruge op til 3 GB på en 32 bit Linux. Og på 64 bit OSer er der ingen problemer med at bruge meget mere. Grænsen på 1.2 GB er ikke helt fast men varierer fra PC til PC.
Forstår jeg jer ret, hvis i siger, at hvert program maks. kan allokere 1 GB RAM i Windows XP/Vista/7 32-bit?
Jeg har tidligere læst at begrænsningen skyldes at de 1.2 GB er den største sammenhængene blok som kan allokeres på 32 bit Windows. Hvis et program allokerer RAM fra operativsystemet i flere blokke, så kan programmet godt få mere RAM end 1.2 GB. Jeg har dog ikke selv afprøvet om denne forklaring passer.
Forstår jeg jer ret, hvis i siger, at hvert program maks. kan allokere 1 GB RAM i Windows XP/Vista/7 32-bit?
For Win XP 32-bit er det, ifølge Microsoft selv, max. 2 GB som evt. kan udvides til 3 GB med /3GB switchen i boot.ini den kan dog give problemer og kan derfor justeres med /userva=2900 (2900 er bare et eksempel).
Mange programmer (f.eks. Excel) er totalt paranoide når det gælder swap, jeg har maskiner med 16 GB RAM (på W2K3 Enterprise 32-bit) hvor vi fjernede swap og det resulterede i en "Out of memory"-lignende fejl.
Jeg har lige prøvet Mark Russinovich's TestLimit program (kan hentes her: http://download.sysinternals.com/Files/Testlimit.zip )
Kørt med -d som argument, allokerer den fint samtlige 2GB usermode memory processen burde have tilrådighed. Og ifølge hvad han selv skriver burde den også fint allokere samtlige 3GB hvis man har /3GB switchen sat. Jeg tror dermed ikke at det er et generelt Windows problem.
Jeg har kun udført min egen test under .NET runtimen, hvor jeg ramler ind i den her 1 GB begrænsning - har googlet lidt på det, men indtil videre forgæves.
Hvad med Ubuntu: kommer du til at vælge 32/64bit forkert kan du HELT GRATIS vælge igen!
Kan det tænkes, at det er noget legacy 16-bit kompatibilitet der spøger?
Kan det tænkes, at det er noget legacy 16-bit kompatibilitet der spøger?
Det tror jeg ikke. Det er langt mere sandsynligt at det er en kombination af garbage collection og måden den virker på samt hvor man får hukommelse i segmentet når man spørger virtual-memory systemet om det. Fordi man kan allokere 2 gigabyte hukommelse i et naivt program, hælder jeg til at tro det er det første (i.e., garbagecollectoren).
Ikke desto mindre, så finder jeg at denne diskussion, om end den har taget en tangent, så i aller højeste grad belyser nogle af de problemer som 32-bit giver. Det er stof til eftertanke for programmøren og systemadministratoren.
ok jeg tror at jeg er ved at have fundet årsagen. Ved at optimere lidt på min ramtest lykkedes det nu at allokere 1,7 GB under 32-bit .NET
Problemet lader til at have at gøre med måden store objecter alignes på i GC'ens Large Object Heap.
Ved at allokere i chunks der er mindrer end grænsen for hvornår de allokeres på LOH'en lykkedes det mig at flytte grænsen op på de 1,7 GB - det er stadig ikke helt 2 GB. Jeg har en teori om at det er mit List object (det eneste der bliver stort nok til at ende på LOH'en) jeg bruger til at gemme referencer til data-chunksene i som ender med at blive fragmenteret på LOH'en pga. den måde en List udvider sig på (lidt samme problematik som string concatenations vs StringBuilder) - dette gør det formentlig op for de 300 MB fragmenteret plads, en linked liste ville formentlig løse den, men det må lige testes en anden gang (nu er det vist ved at være sengetid :p)
Men når man i et alm. program allokerer så meget data at man ryger op over 1 GB, så er det nok meget normalt at der er tale om store chunks data, som vil lægge sig på LOH'en og derfor er det i praksis nok svært at allokere ret meget mere i noget der ikke er en optimeret ramtest applikation - måske undtaget serverløsninger med rigtig mange brugere og små mængder data.
Det er formentlig samme "problem" der gør sig gældende for Java - det er nok en pris der er svær at komme udenom når man skal have en velfungerende og hurtig GC og et addresseringsrum begrænset til 2 GB.
På 64-bit er der formentlig en lign. begrænsning, men da addresseringsrummet her er 2^64 er det nok teoretisk at vi får nok ram proppet i vores maskiner til at komme til at opleve den i vores tid :p Hvilket altså er årsagen til at vi oplever at kunne allokere ubegrænset i praksis under 64-bit.
Det er jo ligefør man burde skrive en blogpost ved lejlighed, forvirringen på diverse forums om emnet ser ihvertfald ud til at være stor :-)
Hvis jeres AV producent ikke kan optimere deres produkter til 64 bit, vil jeg nok kraftigt anbefale at finde en anden løsning.
Microsoft's egen er fin fin, og fungere helt perfekt på 64bit.
DANIEL
Jeg følte mig ret sikker på at jeg havde testet grænsen før og kun fundet den aktuel for IIS-hostede .NET applikationer, men jeg har lige skrevet et lille test-program for at efterprøve igen og jeg må medgive at det ser ud til at du har ret - den smider en outofmemory lige omkring når den runder 1 GB forbrug. Ved du noget om årsagen hertil? Jeg undrer mig en smule da der jo burde være 2 GB usermode memory tilrådighed.
Det blev lidt off-topic det her, men udviklet sig ganske positivt i fht. nogle af de udfordringer man kan støde på med 32-bit applikationer i kombination med .NET og GC. Det er dog positivt i den forstand, at der sandsynligvis er noget grundliggende galt i ens kodning hvis RAM forbruget er så højt - bla. derfor var jeg så påståelig i fht. 1-1.2GB grænsen - vi har vel alle kodet lidt uhensigtsmæssigt fra tid til anden :-)
Ved at optimere lidt på min ramtest lykkedes det nu at allokere 1,7 GB under 32-bit .NET
Problemet lader til at have at gøre med måden store objecter alignes på i GC'ens Large Object Heap.
Daniel, du varmer mig gamle udvikler hjerte når du når så langt ned i merterien på GC'en. I fht. mit eget projekt, Cuemon .NET Framework Additions, så har jeg selv været dybt inde i GC'ens indre med CLR Profiler fra Microsoft (http://bit.ly/9pk3jK), og her ser man hurtigt hvor "skadeligt" string's er i fht. RAM.
Anyway, super godt spottet - og mange tak for delingen af opdagelsen!
THOMAS
Forstår jeg jer ret, hvis i siger, at hvert program maks. kan allokere 1 GB RAM i Windows XP/Vista/7 32-bit?
I så fald, så begynder jeg at kunne forstå, hvorfor vi har så mange problemer med Illustrator, der løber tør for hukommelse. :)
I fht. Illustrator (og Photoshop), så kan jeg ikke afvise at det er noget lign. der gør sig gældende (lyder yderst plausibelt), men disse programmer benytter antagelsesvis kun eget udviklet software, hvorfor der ikke er en umiddelbar sammenhæng til .NET og GC.
Både Illustrator og Photoshop benytter sig af et begreb kaldet "scratch disk" (lidt a'la swap), som måske kan afhjælpe på problemet?
Læs evt. mere her: http://bit.ly/8YJGaS
niels, maciej, michael:
Super, tak for info. Har sat dem op med en scratch disk, men vi oplever fortsat problemet jævnligt. Måske man skulle få fat i en 64-bit version og smide nogle flere ram i.
Daniel, du varmer mig gamle udvikler hjerte når du når så langt ned i merterien på GC'en.
hehe det er jeg glad for at høre. Må erkende at vi kom en smule offtopic, men det irriterede mig ikke at vide hvad det var der foregik og lå til grund for denne lidt absurde begrænsning - så jeg blev stædig ;)
Efter lidt dump-analyse var det tydeligt at jeg allokerede alle mine chunks på LOH'en og det viste sig at være synderen.
Faldt over en artikel senere der kaster lidt mere lys over hvordan LOH'en fungerer, den kan findes her hvis det har interesse:
http://www.simple-talk.com/dotnet/.net-framework/the-dangers-of-the-larg...
Jesper Poulsen
Enig. Og det har man nok efterfølgende erfaret. Men ved release hed det Win 7 og ville man bruge sit nye kort, så måtte man nedgradere til Win 7.
Det var kun 1 driver release hvor XP af uforklarlige årsager ikke var understøttet, Catalyst 9.10. 9.9 og 9.11 har/havde begge understøttelse af HD5770 og Windows XP. Så jo, man kunne godt bruge sit HD5770 med Windows XP ved launch, selvom nyeste driver ikke understøttede det. Nogle producenter omgik dette ved at medlevere en ældre driver version på cd'en. ATI/AMD leverer nye drivere en gang om måneden og er flinke til at udgive beta-drivere der løser akutte problemer - som f.eks. den manglende XP-understøttelse i 9.10, så var der hurtigt en 9.11 beta klar.
Hvis jeres AV producent ikke kan optimere deres produkter til 64 bit, vil jeg nok kraftigt anbefale at finde en anden løsning.
Det er der også rigtigt mange af os som har fundet... Vi har sikiftet OS til noget som er mindre udsat og mere stabilt for længe siden.
Undskyld, den lå altså lige til højrebenet...
Er ved at skifte til 32-bit på min bærbare.
Gjorde det samme på min stationære (efter at have prøvet 64-bit).
64-bit Windows (kun Windows! Linux kører fint) har en tendens til at være rasende ustabil på alle systemer jeg og min far (AV tekniker på KUA) installerer det på. Det kører i sig selv fint nok, men når noget skal startes/lukkes, dokumenter skal åbnes/gemmes eller der skal arbejdes sammen med eksterne enheder samt DVD-drevet (som teknisk set også er ekstern) kan hele systemet hænge i timevis. Intet kan starte, intet kan lukke, og flere programmer hænger totalt.
64-bit kører dog mange programmer hurtigere, så hvis I kan få det op at stå kan det klart anbefales - men ved de mindste stabilitetsproblemer under opsætningen så skift til 32-bit med det samme. Meget bedre end at potentielt miste data.
RED: For nogle måneder siden var der et mindre IT-nedbrud ude på KUA fordi 64-bit Windows besluttede sig for at være morsomt. De havde forsøgt at anskaffe 32-bit Windows, men det kunne "ikke skaffes".
Indrømmer at jeg ikke er den store ekspert på området, men jeg ville da dele ud af mine erfaringer alligevel. 64-bit Windows kører hurtigere end 32-bit, men kan meget hurtigt gå hen og blive en frygtelig hovedpine.
Christian: Jeg kan ihvertfald oplyse at det ikke er et generelt problem med 64-bit Windows. Vi kører 64-bit Windows i forskellige udgaver på 20+ arbejdsstationer og 100+ servere på arbejde og personligt har jeg 3 stk. 64-bit computere med Windows på. Ingen stabilitetsproblemer eller lign. på nogle af dem, men der er også stortset udelukkende tale om forholdsvis ensartet HP udstyr.
Normalt skyldes den slags problemer du har oplevet en inkompatibel driver - det er desværre ikke alle producenter der har været lige gode til at tilbyde 64-bit drivere til deres produkter og nogle af dem der tilbydes kan nogle gange være på et tidligt beta-stadie. Det kan være et mareridt at finde en sådan driver der laver rav i systemet og jeg kan sagtens forstå man bliver frustreret og ender med at gå tilbage til en 32-bit der somregel bare virker når man render ind i problemet (har selv været der med en Sony Vaio laptop) :-)
@Daniel: Ja, jeg forstår også at det virker udemærket for ret mange, og har også længe haft på fornemmelsen at det er en DVD-brænder driver, der ikke fungerer ordenligt.
Min bærbare er en Compal KLH0 og min stationære er hjemmebygget med et LG combi-drev. Begge har 6GB DDR3-RAM (og med 1GB grafikkort) så du kan nok forstå at mine problemer med 64-bit er ret ærgerlige.
Samme problemer opstår i nogle server-clustre på KUA, mens på andre kører det ganske udemærket. Det kører primært med IBM. Min fars server, som i øjeblikket hoster en mail samt en simpel HTTP side med lidt historie, kører i øjeblikket Fedora 11 64-bit. Før da kørte den Windows Server 2003 32-bit, efter at han havde haft så mange problemer med 64-bit udgaven af Windows Server 2003 at han gav op.
Samtidig er der tonsvis af 64-bit computere hos bekendte som kører ganske fortrineligt.
Det er derfor jeg altid anbefaler folk at prøve 64-bit, for det er hurtigere, smartere og mere (fremtids)sikkert når det fungerer, men man skal være forberedt på, at det meget vel kan hende, at det ikke fungerer!
RED: Det er dog lidt morsomt at det altid rammer os to. Har længe overvejet om vi gjorde noget forkert. Men nej, selv når andre installerer og opsætter det på mine maskiner, går det helt galt.
Nu ved jeg ikke om jeg taler hen over hovedet på dig :-)
Men hvis du får lyst til at gøre forsøget med 64-bit igen og f.eks. oplever BSODs, så vil der typisk blive taget et kernel-dump af hukommelsen som defaulter til %SystemRoot%\MEMORY.DMP - dette kan du indlæse i WinDbg (Hent debugging tools for Windows) og udfør en !analyze -v herpå. Ignorer alle de lidt langhårede detaljer og se efter om den outputter en .sys fil i analysen - find frem til den .sys fil på din harddisk og se i properties om du ikke kan spore dig ind på hvilken producent og enhed den tilhører - det er ikke altid det er så let, men ofte kan det være nok til at find frem til den driver der forårsagede BSOD'en.
Det er dog noget sværere hvis du blot oplever hangs.
Ahh, hvis bare det var så nemt. Det er nemlig hangs. :(
Den BSOD'er ikke. Alle programmer fortsætter med at fungere som de skal, men nye programmer kan ikke startes, og save/load funktioner kan ikke starte (og får så programmet til at hænge når man prøver). Ej heller kan nogle programmer lukkes - heller ikke med End Process Tree fra processes-tabben i system-monitoren.
Prøvede dog det du sagde for længe siden ved at forårsage en BSOD med vilje mens den var låst (jeg er ret bekendt med C++ og DirectX8 og 9. Kan lave ret meget kaos med dem! ;D ) og kiggede på crash-dumpen, som ikke afslørede noget ud over en busted lyddriver (gud ved hvorfor!), desværre!
RED: Indrømmer at det ikke var nogen smuk måde at crashe en maskine på, men det var nemmest. Bad lydkortet om at spille en .jpg fil som en midifil i ubeskyttet tilstand. Det kunne den alligevel ikke klare! ;P )
RED2: Compals side er i øvrigt ikke til megen hjælp i disse sammenhænge. Den siger om mit DVD drev: "A DVD drive". Ligeledes sagde den om min touchpad "Generic touchpad" -.- Endte med at få den genkendt som en Synaptics PS/2 touchpad (downloadede bare driveren og prøvede), hvilket jeg ikke klager over. En af mine venner har i øvrigt en bærbar næsten magen til som godt kan tåle 64-bit - den er dog en anelse ældre. (½ år mener jeg)
Det er korrekt - men AnyConnect virker jo ikke, hvis endpointet ikke understøtter det.
(det er et konkret problem for de af os, der supporterer kunder, der ikke alle har "opgraderet" til AnyConnect)
Nu er Ciscos IPsec implementering ikke noget uhåndterbart: i OS X (og iPhone) findes en Cisco-kompatibel IPsec klient, på Linux virker vpnc fint så mon ikke man kan finde en tredjeparts IPsec klient til Windows ?
Jesper Lund Stocholm, 23. februar 2010 11:10
- Printerdrivers
- sørg for at undersøge jeres printere for kompatibilitet. Det er IKKE "noget møg" som udgangspunkt, men kan naturligvis være det, hvis der ikke findes drivere til jeres printere.
Det problem har jeg aldrig forstået ... måske fordi jeg køber postscript printere ... men hvorfor bruger man ikke http://en.wikipedia.org/wiki/PostScript_Printer_Description ?
Christian:
Handler det ikke om, at man kan risikere at undvære "specielle features" (bakkevalg, foldning, hæftning osv) ved at bruge en standard PS-driver?
Thomas Bundgaard, 26. april 2010 20:01
Handler det ikke om, at man kan risikere at undvære...
Se http://partners.adobe.com/public/developer/en/ps/5003.PPD_Spec_v4.3.pdf side 15
The following items should occur after media size selection:
• job control requests such as duplex, automatic tray switching, signaturing, output bin selection, and finishing features such as folding, binding, and stapling
Super, tak for info. Du ved alligevel en hel del :)
Det gør det jo noget nemmere må man sige.
Det problem har jeg aldrig forstået ... måske fordi jeg køber postscript printere ... men hvorfor bruger man ikke http://en.wikipedia.org/wiki/PostSc... ?
Postscript har også sine problemer, så derfor udviklede Adobe sproget PDF som ligner postscript en del men er stærkt forbedret på en række punkter, så det giver færre printproblemer. I det professionelle område (trykkerier) bruger man i høj grad PDF som printformat.
Men desværre er der ikke mange almindelige printere som accepterer PDF. Til gengæld er der flere og flere som understøtter "XHTML print" som er den standard der bruges ved "bluetooth print" og "DLNA print", så hvis man fremover gerne vil kunne printe fra sin mobiltelefon eller sit TV, så sørg for at få en printer som understøtter disse standarder.
Google er tilsyneladende på vej med sin egen løsning hvor man printer til "skyen" og Google så klarer konverteringen til ens printer. Mon de bruger et af standardformaterne (postscript/PDF/XHTML print) eller har de deres eget?
Postscript har også sine problemer, så derfor udviklede Adobe sproget PDF som ligner postscript en del men er stærkt forbedret på en række punkter, så det giver færre printproblemer. I det professionelle område (trykkerier) bruger man i høj grad PDF som printformat.
PDF betyder [b]Portable Document Format[/b]. Fordelen ved PDF er at man kan tage det med fra en maskine til en anden uden kvalitetstab. Det bygger på effektiviteten i PostScript.
Når trykkerier alligevel anvender PDF kan det skyldes at det er let at håndtere. Der findes flere programmer der kan få noget meningsfyldt ud af en PDF-fil end af en PS-fil.
Min printer kan opgraderes til at printe PDF - jeg ser bare ingen grund til det. PS virker.
PDF betyder Portable Document Format. Fordelen ved PDF er at man kan tage det med fra en maskine til en anden uden kvalitetstab. Det bygger på effektiviteten i PostScript.
Det har du misforstået. Man kan ligeså godt tage postscript fra en maskine til en anden uden kvalitetstab. Mange af operatorerne i de to sprog ligner hinanden til forveksling.
Men postscript har problemer med at holde styr på hvad der hører til hvilke sider og på at holde styr på hvilke fonte der skal bruges. Disse problematikker er der bedre styr på i PDF. Det er også derfor det er nemmere at skrive en viewer (f.ex Adobe Reader) til PDF end det er til postscript.
Man kan ligeså godt tage postscript fra en maskine til en anden uden kvalitetstab.
Det ved jeg. Men hvilke programmer kan læse det og få noget fornuftigt ud af det?
Men postscript har problemer med at holde styr på hvad der hører til hvilke sider og på at holde styr på hvilke fonte der skal bruges.
Det er jo ikke aktuelt når man bare vælter noget afsted til en printer. Der har PS-driveren i computeren jo defineret hvad der hører til hvilke sider - det er bare op til printeren at vælte det ud.
Disse problematikker er der bedre styr på i PDF.
Fordi PDF er skabt til at være et portabelt format, ofte bestående af mange sider og ofte slet ikke udprintet - i det mindste sjældent på en PS-printer.
PDF er [u]ikke[/u] et bedre printformat end PS. PDF er et bedre [b]portabelt[/b] format end PS.
Der har PS-driveren i computeren jo defineret hvad der hører til hvilke sider - det er bare op til printeren at vælte det ud.
Du har vist aldrig fået en "OffendingCommand" fejlmelding eller en fejlmelding vedrørende manglende font fra en Postscriptprinter. I begge tilfælde får man sjældent ret meget ud på siden. Begge dele er væsentligt mindre sandsynlige med PDF.
PDF er ikke et bedre printformat end PS.
Adobe skriver selv om det på http://www.adobe.com/print/features/psvspdf/index.html :
A PDF file is actually a PostScript file which has already been interpreted by a RIP and made into clearly defined objects. These objects are viewable on screen not in code, but in visual objects that everyone can see. Because these files are already interpreted by the RIP, they can be more reliable than an EPS or a .PS file when printed.
Så Adobe skriver helt klart at PDF er et bedre printformat end EPS. Der er langt strengere krav til en PDF fil end en postscript fil, så risikoen for "OffendingCommand" eller lignende er meget mindre.
Kan vi så ikke komme tilbage til 32 vs. 64 bit?!
64 bit fra nu af, helt klart. 32 bit vil blive faset ud, ligesom 16 bit blev det.
Embedded kan der dog være fordele i 32 til nogle ting (ligesom der bruges 8 og 16 bit til andre).
Så Adobe skriver helt klart at PDF er et bedre printformat end EPS.
Selvfølgelig skriver Adobe det, de skal jo leve af et eller andet... Microsoft skriver også at nyeste Windows er bedre end forgøngeren.
@Jesper & Niels Kan I ikke diskutere PDF og PS (tag gerne LaTeX med) et andet sted, end i en tråd der handler om valget mellerm 32 eller 64 bit Windows?
Hvordan kan nogle overhovedet give jer positive bedømmelser for at jeres indlæg er relevante for debatten. Det er da dybt sært.
