Artikelkommentarer
Vi håller just nu på att uppgradera våra kommentarsystem. Mer info om hur du kommenterar och kommer åt dina gamla kommentarer hittar du på vår FAQ: idg.se/faq
Kommentatorn ansvarar själv fö;r sina inlägg. Inlägg som innehåller diskriminerande uttalanden, personliga påhopp eller språk som kan uppfattas som stötande, kommer att tas bort av tjänstgörande redaktör. Även poänglösa datorkrigsinlägg tas bort.
OBS! Läs dessa regler som gäller vid postning av inlägg.
Regler för inlägg i artikelforumet
Kommentatorn ansvarar själv för sina inlägg. Inlägg som innehåller diskriminerande uttalanden, personliga påhopp eller språk som kan uppfattas som stötande, kommer att tas bort av tjänstgörande redaktör. Även datorkrigsinlägg och inlägg som är utanför ämnet, kan tas bort.
IDG förbehåller sig dessutom rätten att i varje enskilt fall bedöma huruvida ett inlägg ska tas bort, även om det inte faller under någon av reglerna ovan.
Upprepat postande av olämpliga inlägg kan medföra avstängning från artikelforumen.
Frågor? Mejla till redaktören, carl.grape@idg.se.
Inte ARM heller?
2012-04-26 13:17
M M
Inte ARM heller?
2012-04-26 13:26
snajk
Inte ARM heller?
2012-04-26 13:44
M M
Inte ARM heller?
2012-04-26 13:54
snajk
(Inlägget är borttaget av moderator)
2012-04-26 13:58
Inte ARM heller?
2012-04-26 14:09
Att detta skulle påverka livslängden vet jag inte. Eller, en tio är gammal surfplatta lär inte vara lika användbar som en tio år gammal dator så det är självklart en minskad livslängd. Men för den som köper enheten från början så påverkas inte livscykeln direkt då de ändå lär köpa en ny inom typ tre år. Varför det skulle krävas skrotning vid virusangrepp vet jag inte, det lär ju komma antivirusprogram även till W8 RT precis som det redan finns till Android.
snajk
Inte ARM heller?
2012-04-26 15:58
Tänk bara på alla datorer med Virus... detta skulle resultera i att en mängd datorer skulle hamna på återvinningen direkt!
Så länge man kan göra en grundinstallation så kan man också vara "nästan" säker på att viruset också försvinner!
Skulle du få in ett virus i din enhet måste du gå igenom alla binärer och filer är orginal versioner. Svårigheten är att verifiera dessa filer OM ditt system nu är påverkat!
ottan
Inte ARM heller?
2012-04-26 15:17
Saknar man även kunskaper i att blåsa om en pryl så skulle man nog inte ha den från början.
Vinkelberg
Inte ARM heller?
2012-04-26 16:00
ottan
Inte ARM heller?
2012-04-26 16:03
Snabel75
Inte ARM heller?
2012-04-26 16:06
Inte f.n har man råd med att köpa... det får du och andra göra!
ottan
Inte ARM heller?
2012-04-26 16:11
edit: Inte att du köpte någon för några dagar sedan, utan att du skrev om det.
Vinkelberg
Inte ARM heller?
2012-04-26 16:13
ottan
Inte ARM heller?
2012-04-26 16:48
Det handlade om någon maskin du inte kunde installera om och därmed gick tillbaka till butiken och åberopade någon garanti och i slutändan fick du en bättre maskin.
Letar vidare.
Vinkelberg
Inte ARM heller?
2012-04-26 16:54
hans.pedersen
Inte ARM heller?
2012-04-27 03:17
Inge Hjort
Inte ARM heller?
2012-04-26 16:20
Snabel75
Inte ARM heller?
2012-04-26 16:23
Orkar de inte så får de väl göra vilka val de vill.
ottan
Inte ARM heller?
2012-04-26 17:05
Kan du verkligen inte rekommendera någon mobil som du anser är säker?
Snabel75
Inte ARM heller?
2012-04-26 16:09
M M
Inte ARM heller?
2012-04-26 16:24
ottan
Inte ARM heller?
2012-04-26 16:29
Neptune
Inte ARM heller?
2012-04-26 16:39
Mjukvarorna utvecklas för hastigt men nästan inga tester alls!
Du kommer kanske ihåg att regimen...
http://www.svd.se/naringsliv/ericsson-hjalper-syriens-regim-med-mobilteknik_6659276.svd
ottan
Inte ARM heller?
2012-04-26 16:49
"Det finns några få mobiler som faktiskt går att använda turligt nog men allt för många köper bara för något är snyggt och inte säkert!"
Undrar just vad du syftade på där. Men nu verkar det inte finnas några säkra telefoner. Knepigt!
Neptune
Inte ARM heller?
2012-04-26 16:56
M M
Inte ARM heller?
2012-04-26 17:07
Neptune
Inte ARM heller?
2012-04-26 17:16
Bojk-ottan har gjort det igen.
Snabel75
Inte ARM heller?
2012-04-26 16:12
Vinkelberg
Inte ARM heller?
2012-04-26 16:21
Detta kan vi tacka mediamaffian för och inget annat och här har också tillverkningsindustrin hängt på.
Varning säger jag bara och detta ÄR befogat!
Det håller på att bildas en snårskog och ser kunderna inte upp så finns det risk att de fastnar i denna och får bara en valmöjlighet och det är att skrota enheten och köpa en ny!
Denna affärsmetod borde bojkottas!
Apple, Nokia, Sony, HTC, Samsung, med flera använder den redan i sina produkter.
Det var väl inte så länge sedan som Sony levererade ett root-kit..
http://en.wikipedia.org/wiki/Sony_BMG_copy_protection_rootkit_scandal
Och jag tror inte att detta var det sista otrevligheter ifrån alla dessa företag!
ottan
Inte ARM heller?
2012-04-26 17:12
Capital
Inte ARM heller?
2012-04-26 17:15
M M
Inte ARM heller?
2012-04-26 15:35
32-bitars Windows ger t ex 32-bitars program en gräns på 2GB minne utan stöd för /3G switchen eller Largeaddressaware som om programmet valt att stödja det (det är en switch när man bygger det) kan ge programmen upp till 3GB minne på 32-bitars Windows och hela 4GB på 64-bit Windows. (64-bit Desktop Windows stödjer också mer än 4GB, Servervarianterna hade inga problem att stödja mer på 32-bitars med PAE som även finns på skrivbordsvarianten men begränsas till 4GB ändå). 2GB var en gräns många professionella applikationer råkade ut för, men programmen behövde inte byta till att stödja 64-bit för att ta sig förbi det. Det hjälpte däremot att tvinga användarna till 64-bitars Windows och köra largeadressaware även om dina program inte stödjer (64-bit) det. Fortsätta bygga 32-bitarsprogram betyder också att du behåller stöd för Windows XP. Många programvaror överger därför inte 32-bitars även om de genomfört sitt skifte och stödjer 64-bitars och diverse nya funktioner där.
Företag kör nog 64-bitars Windows när de kan så jag vet inte riktigt vart skiftet skulle vara. Det handlar inte bara om klienter, datorer är datorer och servrarna ser precis likadana ut med UEFI osv och företagen har erfarenhet av 64-bitars system sedan 80-talet. Så länge drivrutinerna finns kör de 64-bitars operativ även om inte programvaror. Så länge de inte behöver köra 32-bitars eller XP. De kan du virtualisera om det duger däremot. Klienter betyder att det däremot handlar om skrivbords-Windows så artikeln var tydlig där även om inte hemanvändare var riktmålet. Här handlar det om Windows 7 Professional 64-bit och Windows 7 Enterprise 64-bit, samt funktioner som kommande Windows 8 stödjer som många kommer hoppa över, Metro passar inte i en produktiv miljö, man har inte tid att pyssla med metroprogram och sysslar med nyttoprogram i gamla gränssnittet som snarare krockar med nya arbetssättet. Surfplattor med Windows RT (inte 8) kör inte på 64-bitarskapabel plattform (än) och klarar helt enkelt inte nyttoprogrammen från världens största leverantörer och inte programmen företag utvecklat internt. Det är stort att gå från Win32/ATL/MFC eller .NET/WPF/Winforms på VS2005, VS2008, VS2010 osv till VS11 och WinRT-ramverket. Det är en helt annan miljö från utvecklarnas sida. Dit kommer de inte flytta än. Företag kommer till stor del köra x86 (PC) Windows 8 Pro tablets. Klientoperativ hos företagen är alltid Microsofts professionella eller enterprisevariant. Om de inte pratar om Mac OS X då. Där tvingar leverantören dig att köra operativsystemet i 64-bitarsläge. Det gör o andra sidan de flesta datorleverantörer med Microsoftprogram också om du inte frågar efter annat. Vad det gäller Windows RT har du inte ens MS Outlook där så det kommer inte riktigt platsa i företagsmiljö.
Hyper-V fanns förut bara i Servervarianten. Hyper-V har alltid bara funnits till x86-64-varianten. Finns t ex inte till Intel Itanium (IA64) varianten av Windows Server.
XP-Mode går t ex att köra på 32-bitar Windows.
Secure Boot kommer säkert stängas av hos företag eller fungera med nedsatt säkerhet. Jag vet inte riktigt om de längtat efter att inte kunna köra sina verktyg på datorerna.
Vad det gäller olika funktioner i olika varianter av Windows 8 så kan jag bara referera till -> som verkar har bäst översikt. http://en.wikipedia.org/wiki/Windows_8_editions#Comparison_chart
Windows 8 är bara ett klientoperativ för skrivbords (desktop) datorer. Servervarianten heter Windows Server 2012 och konsumentsurfplatt-varianten heter helt enkelt inte Windows 8. Vilket är bra när syftet inte är att ersätta PCs.
Penti
Inte ARM heller?
2012-04-26 16:45
Vart har du sett att Outlook inte kommer att finnas för Windows RT?
"Hyper-V fanns förut bara i Servervarianten. Hyper-V har alltid bara funnits till x86-64-varianten. Finns t ex inte till Intel Itanium (IA64) varianten av Windows Server."
Du menar väl att Hyper-V enbart finns till x64? Hyper-V har aldrig funnits till x86.
"Secure Boot kommer säkert stängas av hos företag eller fungera med nedsatt säkerhet. Jag vet inte riktigt om de längtat efter att inte kunna köra sina verktyg på datorerna."
Varför tror du det?
Neptune
Inte ARM heller?
2012-04-26 17:15
Men x86-64 avser en x86 processor med stöd för 64 bitars instruktioner.
http://en.wikipedia.org/wiki/X86-64
Capital
Inte ARM heller?
2012-04-26 17:17
Neptune
Inte ARM heller?
2012-04-26 17:56
Secure boot gör det omöjligt att boota egna verktyg som inte är signerade av Microsoft. Har man lite verktyg som inte är signerade och behöver sköta om maskinparken så behöver man. Handlar om preboot-verktyg av olika slag, egna bootimages med olika verktyg, för att kunna hantera problem över nätverket, installation av vissa lösningar, backup, modifieringar, recovery osv.
Penti
Inte ARM heller?
2012-04-26 13:58
(RoLaNd LyGeL -<|" Anakin-S, den självironiska Star Wars-Fanboyen "|>-)
Inte ARM heller?
2012-04-26 14:13
snajk
Inte ARM heller?
2012-04-26 16:26
OS X gjorde ju övergången betydligt mer sömlös. De har ju tom gått från PowerPC -> x86-32 -> x86-64, utan att många användare ens märkte något.
Farull
Inte ARM heller?
2012-04-26 16:47
M M
Inte ARM heller?
2012-04-26 17:40
Farull
Inte ARM heller?
2012-04-26 16:25
Neptune
Inte ARM heller?
2012-04-26 19:23
Citat: "But though it looks the same as the traditional desktop, it has one major difference: it won't run any old application. Microsoft has long said that WOA will not include an x86 emulator, so legacy applications would never run directly on the platform, but there was always the possibility that existing desktop applications could be recompiled. That option is now unambiguously eliminated, with Microsoft saying "WOA does not support running, emulating, or porting existing x86/64 desktop apps." Office is a special, unique case. All third-party applications for WOA will be Metro applications delivered via the Windows Store, and must meet the restrictions imposed on those applications."
snajk
Inte ARM heller?
2012-04-26 20:49
Ozymandias
Både bra och dåligt...
2012-04-26 13:37
Dåligt att bloatware UEFI börjar bli standard. Firmware skall inte innehålla drivrutiner och annan tjafs. Coreboot som standard hade varit betydligt bättre för alla.
zynaps
Både bra och dåligt...
2012-04-26 14:05
Om jag fattat det rätt så kommer det att kräva att BIOS avskaffas först, eftersom maskinerna fortfarande startar i "real mode", vilket är ännu sunkigare än 32-bit.
Japp, vi lever delvis kvar i 70-talet fortfarande, tack vare BIOS.
japh
Både bra och dåligt...
2012-04-26 14:30
xlc
Både bra och dåligt...
2012-04-26 14:56
japh
Både bra och dåligt...
2012-04-26 22:37
Nordbrygga
Känns gammalt
2012-04-26 13:38
*???*??
Känns gammalt
2012-04-26 13:42
Äter verkligen andra system så mycket minne att de redan för tio år sedan körde med 64 bit som standard? Eller hur menade du?
Vinkelberg
Känns gammalt
2012-04-26 13:56
Andra system har väl inte gjort lika tydliga övergångar. Men t.ex. Solaris har varit 64-bitars sen 1998, utan att för den sakens skull kräva 64-bitarsapplikationer. Det har gått alldeles utmärkt att mixa som man vill.
Jag är lite osäker på varför inte andra lyckats med det utan måste vara så noga med att skilja på 32/64-bitars.
japh
Känns gammalt
2012-04-26 14:39
aluser
Känns gammalt
2012-04-26 15:06
Man säger inte "vi kommer inte att vara begränsade till 32 bitar längre", utan det är "över" med 32 bitar.
Andra (som Solaris) har kunnat köra 64- och 32-bitarsprogram väldigt länge och har fortfarande en massa applikationer i os:et som är 32-bit.
Det finns t.ex. ingen poäng med att göra "ls" i en 64-bitarsversion, så den är fortfarande 32-bit.
Det är heller inte som i Windows-världen där man inte har stöd för vissa saker i 32-bitarsläge.
japh
Känns gammalt
2012-04-27 09:00
xlc
Känns gammalt
2012-04-27 09:56
Oracles Solaris 11 är nu ren 64 bitar. Det går inte att köra på en 32 bitars dator. Men det finns massa öppna Solaris forkar (Nexenta, Illumian, etc), och de tror jag fortfarande tillåter 32 bitars cpuer.
Men 32 bitar på Solaris har inte funkat bra på lång tid (t.ex. ZFS får låga prestanda om man använder 32 bitar), och man har länge rekommenderats att köra 64 bitar. Sen är ju Solaris ett Enterprise ServerOS, och på stora dyra servrar har man ju mycket resurser, 64bitar, mycket RAM, etc. Så RAM är inget problem, inte heller CPU.
(T.ex. ZFS kräver mycket minne (eftersom Solaris kräver 1GB RAM). Och ZFS är ju för större servrar som har minst 1GB RAM. Trots det, finns folk som klagar på att ZFS inte kan användas på 256MB maskiner, och är därför inget de tänker köra hemma, och de hellre kör Linux + ext3 som tillåter 256MB RAM. De säger att ZFS är "bloat och skräp". När man undrar hur många 256MB RAMs maskiner de har hemma, så har de inga såna PCs. Det låter som märkliga skäl till att undvika ZFS. Ok om de hade vettiga skäl, men det verkar de inte ha, deras skäl är lite märkliga.)
Kebab Bert
Känns gammalt
2012-04-26 14:02
Sedan så städades x86-arkitekturen upp en hel del i samband med 64-bitars övergången.
Så det finns definitivt fler anledningar än att kunna använda mycket RAM. Det gick ju faktiskt att hantera upp till 64GB i 32-bitars läge även om stödet på Windows för PAE var rätt uselt (kräver stöd från alla drivrutiner). PAE på Linux fungerar klockrent då detta läge använder samma drivare som 64-bitars läget.
Uridium
Känns gammalt
2012-04-26 16:05
Den största fördelen med x86-64 är väl att det finns fler register.
Farull
Känns gammalt
2012-04-26 17:25
Finns det någon praktisk nytta med fler register i processorn?
Kan dagens kompilatorer använda sig av dessa för att "snabba upp" programmen?
Och [jag vet att jag för en vecka sen ställde en liknande fråga] är det nått vi vanliga användare kommer att märka?
Berger Brosa
Känns gammalt
2012-04-26 17:54
Dessutom så är ju registerna dubbelt så stora, så vissa heltalsberäkningar kan göras effektivare.
Dagens kompilatorer använder sig av dessa register, men det är oftast bara i riktigt beräkningsintesiva applikationer man verkligen ser en prestandaskillnad. Framförallt eftersom de dubbla pekarstorlekarna gör att programmen växer i storlek, och större program använder större minnesbandbredd, vilket i vissa fall kan kvitta ut prestandavinsten.
Farull
Känns gammalt
2012-04-26 19:04
(skönt att det inte bara är pajkastning här på IDG - tänk om alla trådar vore seriösa ...).
Q1: Använder en kompilator i första hand registren för att lagra variabler eller lägger den bara minnespekare där eller sker det nått slags optimering av vad den lägger data?
Q2: Vad är en "beräkningsintensiv applikation"? Program som ser till att obyggda broar håller, videoredigering eller realtidsuträkning av hur vitruella musikinstrument ska låta (realtidssyntes)?
Q3: Kan man/kompilatorn ha nytta av dessa fler register när man lagrar objektens egenskaper i en relationsdatabas (som sen givetvis måste hydrearas till objekt)?
Berger Brosa
Känns gammalt
2012-04-26 19:37
Q1: Det beror ju såklart på vilken kompilator som körs och vilka optimeringspass som körs. Men svaret är nog att den lägger det som behövs i dessa register (pekare eller variabler) allt utifrån förutsättningarna att minska antalet minnesaccesser så gott det går.
Q2: En beräkningsintensiv applikation i det här fallet är en som använder mycket heltalsaritmetik. Alltså troligtvis oftare videoredigering och cadprogram än realtidssyntes av ljud, då ljudsyntes oftast använder sig av flyttal. Men många videoredigerings- och cadprogram använde sig av SSE (som har 128-bitsregister) redan innan övergången till 64-bit. :-)
Q3: Det är inte troligt att just det scenariot gynnas specifikt av de extra registren utöver den generella prestandavinsten alla program får.
Edit: Jag låter ju som en politiker när jag svarar. :-) Det går inte att säga rakt ut hur mycket vinst någonting ger eftersom det är så otroligt många faktorer som påverkar. Någonting som jag lärt mig genom åren som programmerare är att många optimeringar man gör inte alls visar sig vara optimeringar eftersom man ofta blir straffad på något annat oväntat sätt. Och det som visar sig gå snabbare på en processor går långsammare på en annan. Det var bättre förr. :-)
Farull
Känns gammalt
2012-04-26 20:05
Och jag, som utvecklare, vet att det inte går att säga "bu eller bä".
Igen: tänk om man kunde ha sån här nytta av alla trådar och slippa Apple/Microsoft/Anroid-kriget, men framförallt slippa Brosa som tror att han är så lustig hela tiden :-).
Berger Brosa
Känns gammalt
2012-04-26 21:01
Vilken kompilator har du tittat på? Visst de 8 register som x86 hade var väl lite, framförallt då vissa register hade speciella uppgifter (esp, ebp, esi, edi och eax) och inte kunde användas hur som helst.
Tittar man på assembler genererad av kompilatorer för MIPS, PPC, SPARC eller någon annan CPU med 32 register så är det ytterst sällsynt att mer än hälften av registeren används. Inte ens på ARM eller x86-64 är det speciellt vanligt att alla 16 register används.
Fast tänker man lite mer kring detta så är det kanske inte så konstigt. Register innehåller normalt sett den data man just nu jobbar med. Om koden är skriven av vettiga programmerare så kommer den inte innehålla massor med automatiska variabler och massor med referenser till höger och vänster. Så att kompilatorer har svårt att utnyttja massor med register ska man kanske inte skylla på usla kompilator-utvecklare :)
Att öka antalet register har en uppenbar nackdel: kostnaden för att göra en switch mellan olika trådar/processer ökar när man ökar antalet register.
16 register verkar vara en riktigt bra kompromiss.
Att register är 64-bit är inte alls enbart positivt. Det är ytterst sällan man har nytta av så pass stora heltal. AMD insåg detta när de skapade x86-64 vilket man ser i att de flesta (alla?) instruktioner använder 32-bitar som förval och det krävs en speciellt prefix-byte för att använda 64, 16 eller 8 bitar i stället (d.v.s instruktionen blir 1 byte längre om den inte jobbar med 32-bitars register).
Men i de fall man behöver >32-bitar så blir det självklart en stor prestandafördel när CPUn har direkt stöd för detta jämfört med att hantera detta från programvara.
För SSE(128-bitar)/AVX(256-bitar) så detekterar CPUn om man överhuvudtaget använt dessa register sedan senaste kontext-switch. De sparas bara ner om man använt dem just för att minska switch-kostnaden .
Uridium
Känns gammalt
2012-04-26 22:59
Hur många register som kompilatorn använder har väl inte så mycket att göra med hur vettig kod man skriver som vilken typ av kod man skriver? Men såklart, det gynnar kanske både de som skriver dålig kod och de som skriver komplexa algoritmer. :-)
Dessutom så kan det ju underlätta för kompilatorn att inlinea funktioner om den inte behöver spara undan register.
Då tänker jag dessutom mest på kod skriven i C/C++. Jag har ingen aning om hur det påverkar tex funktionella språk.
Farull
Känns gammalt
2012-04-27 00:58
Men en fördel med många register är att kompilatorn kan lägga ut "load" instruktioner väldigt tidigt. Åter igen ger det en out-of-order CPU stort spelrum att utföra den operationen när det passar bara den är klar när man faktiskt vill använda värdet. Rätt gjort så kan man väldigt effektivt gömma den "load-to-use" latens som finns både mot cache och framförallt mot RAM.
Men när jag tittat i kod genererat med gcc och några andra kompilatorer, d.v.s C-kod, så var jag förvånad att man använder så pass få register av de 32 som PowerPC och MIPS har. Känns inte som de 16 register ARM och x86-64 (och m68k, även om det var 8 data och 8 address) skulle vara en begränsning.
Uridium
Känns gammalt
2012-04-26 20:51
Visst, det har även varit möjligt i *NIX system. Man kunde adressera mer än 64kB på 16-bitars tiden med x86 också. Men var det enkelt och effektivt?
Borde kanske skrivit: det är inte enkelt och effektivt att hantera minnes-mappade filer som är >4GB på en 32-bitars CPU.
x86-64 har en rad fördelar över IA32, dubbelt så många register är en av dessa. Andra fördelar är att ABI (Application Binary Interface) nu säger att argument ska skickas på register (4 första under WIndows, 6 först under Linux) i stället på stacken (som i x86).
Funktioner som inte anropar andra funktioner behöver inte heller skapa en stack-ram också en optimering i ABI.
Uridium
Otydligt
2012-04-26 13:59
japh
Varför?
2012-04-26 14:13
Låter ju helt vansinnigt i de flesta fall att designa systemet med stöd för mer än 32-bitar.
Alltså... 32 bitar räcker till fullfärgsfoton. Högkvalitativt ljud. Det räcker till för textdokument och e-post på alla världens språk. Det räcker för att indexera gaaaaanska stora register.
Jag får en känsla av att det är i många fall är fel på systemmjukvaran om det ska behöva ta upp så mycket minne för att surfa och kolla e-post att man behöver mer än 4 GB minne.
Borde inte produktionskostnader, batteritid mm vara argument emot denna utveckling?
henriko
Varför?
2012-04-26 14:36
Strejf
Varför?
2012-04-26 18:14
Däremot antyder artikeln att 32-bitar inte duger åt någon.
Det är det jag STARKT vänder mig emot.
Varför ska vi ha en massa extra bitar, bara för att det är modernt, och för att vi kan, om det inte behövs?!?!
Jag skulle givetvis kunna ha två kylskåp hemma. Men jag anser inte att jag behöver mer än ett. Kan du förklara varför jag och alla andra som inte behöver nu helt plötsligt måste skaffa två kylskåp?
henriko
Varför?
2012-04-27 09:23
Detsamma gäller OS där företagen måste gräva ner pengar i att stödja båda 32-bitar och 64-bitar.
Därför är det önskvärt för de flesta att göra sig av med 32-bitarsbördan och kunna fokusera på enbart 64-bitarssystem (oavsett om det är programvara eller hårdvara).
Scyphe
Varför?
2012-04-27 12:51
Resonerar du likadans med mopeder och bilar... att alla ska köra lastbil för att slippa utveckla mopeder?
henriko
Varför?
2012-04-27 15:53
Fel jämförelse. Förr i tiden fanns det flera olika sorters vanlig bensin till personbilar som drivs med bensin, idag är det 95-oktanig som gäller. Det finns ett antal mackar som kör med V-power eller 98-oktan för special, något som kan jämföras med ARM, IA64 etc.. Det var extrajobb, extrakostnader och omständligt för mackar och marknad med 3-4 olika sorters bensinsorter.
Scyphe
Varför?
2012-04-28 13:02
Är det inte dessutom så, i oktanfallet, att vi gått ner från en hög oktanhalt till en lägre för att den ansågs räcka, så din liknelse tycker jag haltar rätt grovt.
henriko
Varför?
2012-04-26 14:52
thommym
Varför?
2012-04-26 18:38
På samma sätt kan man ju kombinera 32-bitarsord för att få 64-bitars-ord eller 512-bitarsord eller vad man behöver.
Men detta blir då inte lika effektivt, i de fall man behöver göra så.
Just 32-bitar har ju visat sig ganska praktiskt och effektivt för konsumtion av data, då, som jag skrev, de flesta nästan aldrig behöver fler än 32-bitar, men väldigt ofta fler än 8.
Bilder ligger ofta på 24(+8) bitar. Ljud låter bra vid typ 16 bitar.
Text som är baserad på 8 bitar har ju visat sig inte duga riktigt i den globaliserade världen, så för att hantera text effektivt kan 32-bitar vara lämpligt. (Mircosoft tror jag valt 16-bitar internt för text?)
Vid beräkning duger också 32-bitar för det mesta som privatpersoner, och normala företag, håller på med, både vad det gäller precision och talomfång.
Det ska till rätt ofantliga data för att man behöver mer än 32-bitar.
Men ja. I de sammanhang där 8-bitarsprocessorer duger så är de ju väldigt billiga. 15 spänn?
henriko
Varför?
2012-04-26 15:07
2. Om man inte bara surfar och kollar e-post så är det väldigt lätt att slå i minnestaket om man kör många program samtidigt eller redigerar film.
KAEF
Varför?
2012-04-26 16:04
fredrik70
Varför?
2012-04-26 16:14
MangeJ
Varför?
2012-04-26 16:29
Inte ens Windows kan vara så dumt konstruerat.
unsound
Varför?
2012-04-26 17:20
32 bitars addressering ger dig 4GB att addressera. Vill du att varje process ska ha tillgång till mer så kan du inte addressera det som vanligt minne. Då blir det "bank switching" och andra hemskheter.
japh
Varför?
2012-04-26 17:22
unsound
Varför?
2012-04-26 17:21
japh
Varför?
2012-04-26 23:31
Vista hade också PAE, som precis som i Windows 7 är påslagen default för att DEP/NX är påslaget default, och du kan inte slå på DEP utan PAE för den registerbiten behöver mer än 32 bitars längd.
Nordbrygga
Varför?
2012-04-26 16:20
Så att man kör många program gör inte att man slår i 32-bitsminnestak snabbare än om man kör programmen för sig.
M M
Varför?
2012-04-26 18:02
Det måste ju vara väldigt system-specifikt. Men visst några mindre block är det vanligt att man reserverar för IO-interface och interuptvektorer.
Men det var kanske lite det jag efterlyste i artikeln. Att den kanske handlade specifikt om feta Windows-arbetsstationer?
Och inte en vettig netbook, surfplatta, eller surf-TV... eller tvättmaskin, eller motorkontrollen på en moped.
Om man inte bara surfar och kollar e-post så är det väldigt lätt att slå i minnestaket om man kör många program samtidigt eller redigerar film.
> 2. Om man inte bara surfar och kollar e-post så är det väldigt lätt att slå i minnestaket om man kör många program samtidigt eller redigerar film.
Som sagt. Det borde framgått i artikeln att 64-bitar är något som ger stor nytta för vissa specifika ändamål.
henriko
Varför?
2012-04-26 15:21
Vinkelberg
Varför?
2012-04-26 18:09
Privat konsumerar de mest data. Och i princip en sak i taget. Så bara maskinerna har tillräckligt med minne för att buffra ljud och video så duger de rätt långt.
Speciellt enkla uppgifter utför de på sina kontor. Där är det mest enkla bokstäver och siffror som hanteras.
henriko
Inte aktiverat ???
2012-04-26 14:42
KAEF
Inte aktiverat ???
2012-04-26 16:34
unsound
banken
2012-04-26 14:54
Mellin
banken
2012-04-26 15:06
Om det ändå strular, kör
ldd $(which <namen-på-bankid-app>)
så får du en lista på de bibliotek som används och du ser då vilka som saknas. Installera 32-bitars varianten av de bibliotek som fattas.
Uridium
banken
2012-04-26 15:19
Mellin
banken
2012-04-26 15:41
Uridium
banken
2012-04-26 15:20
Kuf
banken
2012-04-26 15:26
bankid på kort för säker inloggning på flera ställen inte bara banken är säkrare
Mellin
(Inlägget är borttaget av moderator)
2012-04-26 15:27
banken
2012-04-26 16:08
Zelest
banken
2012-04-26 16:14
Min ursprungliga fråga var rätt relevant; Och svar fick man:
1. "använder du osäker mobiltelefon?" som sedan ändrades till "använder du röksignaler eller?"
2. "bankid på kort för säker inloggning på flera ställen inte bara banken är säkrare"
Smartass!
Kuf
banken
2012-04-26 16:18
Aja, jag drar mig ur och fortsätter arbeta istället, hur kul det än är att trolla. =)
Zelest
(Inlägget är borttaget av moderator)
2012-04-26 16:19
banken
2012-04-26 17:21
Mellin
banken
2012-04-26 17:26
Mellin
(Inlägget är borttaget av moderator)
2012-04-26 17:38
banken
2012-04-26 17:47
Mellin
banken
2012-04-26 17:18
Mellin
(Inlägget är borttaget av moderator)
2012-04-26 17:20
banken
2012-04-26 19:11
Cliff Carlson
banken
2012-04-26 19:29
Mellin
(Inlägget är borttaget av moderator)
2012-04-26 19:46
(Inlägget är borttaget av moderator)
2012-04-26 22:31
banken
2012-04-26 16:40
vogon_jeltz
(Inlägget är borttaget av moderator)
2012-04-26 16:48
banken
2012-04-26 22:34
Mellin
32-bits Windows kan visst använda mer än 4 GB
2012-04-26 15:21
Det enda dessa stackars sju bytes gör är att begränsa den mängd RAM som Windows XP / 2003 (och säkert även Vista / 7 / 2008) *tillåts* adressera.
Ingen annan förändring behövs, det handlar helt enkelt om att sätta värdet för maximalt adresserbar mängd RAM till 128 GB oavsett SKU, precis samma värde som Windows Server 2003 Datacenter Edition använder.
Skippa tjafset om max 4 GB för 32-bits OS, det är enbart FUD.
Krokodill
32-bits Windows kan visst använda mer än 4 GB
2012-04-26 16:14
Så, nej det är inte enbart FUD. Det finns en begränsning på 4 GB per process i 32-bits OS. Det är naturligtvis tillräckligt för de flesta applikationer, men det finns också andra fördelar med (intels) 64-bitarsarkitektur.
Farull
32-bits Windows kan visst använda mer än 4 GB
2012-04-26 21:05
Vad jag har invändningar mot är att det närmast framställs som begränsande när applikationer inte kan få tillgång till mer än 4 GB RAM.
För mig är det nästintill ofattbart att så mycket inte ska räcka till och att det så lättvindigt accepteras att program slukar enorma mängder resurser.
För typ 20 år sen kördes vi exempelvis OS/2 1.3 + Lan Manager + SQL Server på 16 MB RAM och klarade av att agera skrivar + databas + filserver åt ett tiotal personer utan problem. Nuförtiden verkar det som om drygt 200 ggr. mer RAM inte räcker till för enstaka program? Absurt...
Krokodill
32-bits Windows kan visst använda mer än 4 GB
2012-04-26 23:20
Ett virtuellt instrument kan lätt ha samplingsbanker som överstiger 1 GB. Vilken sampling som helst måste kunna börja spela inom 1 ms från att den triggas, från vilken position som helst. Det utesluter all form av streaming från disk, allt måste finnas i minnet. Många skulle gärna använda 10 sådana instrument i en låt, men har inte kunnat tidigare.
Även om gränsen inte var lika hård nu som vid 640kb så tror jag att det finns många användningsområden som vi helt enkelt inte tänkt på tidigare. Men det kommer troligtvis att kännas lika naturligt som det gjorde när man gick från megabytes till gigabytes i arbetsminne. Så småningom. :-)
Farull
32-bits Windows kan visst använda mer än 4 GB
2012-04-26 17:50
Det finns ingen naturlag som säger att det är max 4GB, men Vista och nyare MS-operativsystem verkar inte klara det.
http://support.microsoft.com/kb/929605
Läs under "PAE-mode-induced driver compatibility issues"
Det må vara felskrivna drivers eller inte, men faktum är att MS säger att PAE inte funkar på Vista.
japh
32-bits Windows kan visst använda mer än 4 GB
2012-04-26 20:57
Krokodill
32-bits Windows kan visst använda mer än 4 GB
2012-04-26 22:02
problem. Var hittar du "Vista stödjer ej PAE"?
Mer info:
http://en.wikipedia.org/wiki/Physical_Address_Extension
Enligt wiki finns patchar för Vista och senare om man vill att en app ska få >4 GB ram. Då kan man ju undra varför man inte använder 64-bits versionen istället? Verkar betydligt enklare.
.NET Rules!