mboost-dp1
Microsoft Corporation
Fornuftigt at 32-bit er ved at blive udfaset. For min skyld måtte det gerne være sket med win7, men der er nok rigtig mange som stadig kører med 32-bit systemer og programmer. Men der kan jo nå at ske meget de næste 3 år.
Af samme grund er jeg glad for snow leopard da man også kan begynde at nyde hastighederne ved et 64 bit OS på mac. Så mangler jeg lige at VMware Fusion 3 udkommer, så kan jeg skifte fuldstændigt :)
Men vil da se frem til nyheder om kommende windows 8, for med win7 lader det virkelig til at MS er inde på rette kurs igen.
Af samme grund er jeg glad for snow leopard da man også kan begynde at nyde hastighederne ved et 64 bit OS på mac. Så mangler jeg lige at VMware Fusion 3 udkommer, så kan jeg skifte fuldstændigt :)
Men vil da se frem til nyheder om kommende windows 8, for med win7 lader det virkelig til at MS er inde på rette kurs igen.
Super, meen mon ikke der går lidt før vi ser noget seriøs hardware til 128 bit? i hvert fald til alm. consumer platform?
#2 64bit kører da fint?
Har kørt med XP Pro x64, Vista Ultimate x64 og kører nu med både Windows 7 Ent x64 og Server 2008 R2 x64 uden problemer? :)
Det eneste problem der er med 64bit er driverunderstøttelse men de er også begyndt at komme på plads.
#2 64bit kører da fint?
Har kørt med XP Pro x64, Vista Ultimate x64 og kører nu med både Windows 7 Ent x64 og Server 2008 R2 x64 uden problemer? :)
Det eneste problem der er med 64bit er driverunderstøttelse men de er også begyndt at komme på plads.
#0
Tidligt 1. april i år?
Jeg mener ikke at der eksisterer en IA-128 CPU arkitektur.
Windows 8 skal vel udkomme engang 2012-2013.
Hvis vi antager at behovet for virtual memory fordobles hvert år, så skulle det have taget 16 år at gå fra 16 bit til 32 bit og 32 år at gå fra 32 bit til 64 bit. Det er ikke helt ved siden af.
Men det betyder altså at det tager 64 år at gå fra 64 bit til 128 bit.
Altså ikke Windows 8 men Windows 28.
Tidligt 1. april i år?
Jeg mener ikke at der eksisterer en IA-128 CPU arkitektur.
Windows 8 skal vel udkomme engang 2012-2013.
Hvis vi antager at behovet for virtual memory fordobles hvert år, så skulle det have taget 16 år at gå fra 16 bit til 32 bit og 32 år at gå fra 32 bit til 64 bit. Det er ikke helt ved siden af.
Men det betyder altså at det tager 64 år at gå fra 64 bit til 128 bit.
Altså ikke Windows 8 men Windows 28.
#4
Problemet er jo, at der til dato udvikles rigtig mange 32-bit applikationer. De store firmaer har så småt taget 64-bit teknologien til sig, mens langt de fleste fritidsprogrammører stadig leger med 32-bit. Ofte er der jo ikke den store vinding ved at bruge 64-bit over 32-bit
Problemet er jo, at der til dato udvikles rigtig mange 32-bit applikationer. De store firmaer har så småt taget 64-bit teknologien til sig, mens langt de fleste fritidsprogrammører stadig leger med 32-bit. Ofte er der jo ikke den store vinding ved at bruge 64-bit over 32-bit
Mon ikke det som andre har spekuleret på er filsystemet der henvises til?
Vil jeg mene underbygger de spekulationer betydeligt bedre end at vi skulle få et 128 bits os om en 3 års tid.
Artiklen skrev:In Windows Server 2008 R2 release, the Server UX Test team (under the File Server Management organization) is finalizing the MMC [Microsoft Management Console] based User eXperience (UX)/Interfaces for the File Server Role. Currently the team owns DFS [Distributed File System] Management, Share and Storage Management, FSRM [File Server Resource Manager] & Classification UI, Disk Management, SMFS. For Windows 8, the SSD organization is working on the next version of the file server.
As the team moved to Windows 8, you will have 2 main responsibilities - (i) put on the customer/design critique hat as we plan our next version file server management experience (i) participating in the architectural design, and development and driving automated testing for managing the next generation file server. Our current automation does not meet the multi-machine paradigm requirement and so you will contribute significantly in the development of test automation to validate setup/configuration of the new server, managing configuration changes, performing diagnostics and reporting using Power Shell, Command line, Object Model, UI.
Vil jeg mene underbygger de spekulationer betydeligt bedre end at vi skulle få et 128 bits os om en 3 års tid.
Undskyld, men her er jeg bange for at Newz tager jer alle ved næsen.
Der kommer sgu da ikke en 128 bit version om 3 år. Vi er jo ikke gået igang med 64 bit endnu og hardwaren er jo slet ikke klar. Der må sidde en mand med stor humor og en masse nyhedsbureauer med røde øre når det går op for dem det er fis. Er der nogen som har hørt fra Microsoft? (Nej)
Der kommer sgu da ikke en 128 bit version om 3 år. Vi er jo ikke gået igang med 64 bit endnu og hardwaren er jo slet ikke klar. Der må sidde en mand med stor humor og en masse nyhedsbureauer med røde øre når det går op for dem det er fis. Er der nogen som har hørt fra Microsoft? (Nej)
#6 og #8
Desværre ja, men der er heller intet der presse på for 64bit udvikling og slet ikke blandt fritidsprogrammører. Før vi ser rigtig 64bit udvikling bliver vi nødt til at skubbe folk over og køre med 64bit computere så der er en reel grund til at begynde at kigge på det.
Endvidere behøver 64bit først at blive rigtig interessant når vi begynder at snakke om talknusning og funktionelle sprog da de færreste alm. programmer kan få noget reelt ud at køre 64bit andet end at sluge lidt mere ram pga. adresseringen.
Desværre ja, men der er heller intet der presse på for 64bit udvikling og slet ikke blandt fritidsprogrammører. Før vi ser rigtig 64bit udvikling bliver vi nødt til at skubbe folk over og køre med 64bit computere så der er en reel grund til at begynde at kigge på det.
Endvidere behøver 64bit først at blive rigtig interessant når vi begynder at snakke om talknusning og funktionelle sprog da de færreste alm. programmer kan få noget reelt ud at køre 64bit andet end at sluge lidt mere ram pga. adresseringen.
Nu bliver der jo snakket om at IA-128 er kompatibelt med IA-64.
Så det lyder rimeligt at antage at det er en videreudbygning på denne teknologi.
IA-64 bliver brugt i Intels Itanium processorer, dvs. det er en helt anden arkitektur end den x86-64 baserede processorer anvender.
De fleste af os benytte i vores computere x86-64 baserede processorer.
Intels teknologi for 64bit på x86 processorer hedder så vidt jeg ved EM64T, som blandt andet bliver brugt i Core 2's og i5/i7.
AMDs variant af x86-64 hedder AMD64.
Sådan som jeg ser det, ser det ud til at det har meget lidt relevans for de fleste af os, hvorvidt windows 8 kommer til at understøtte IA-128 eller ej, da det ikke er noget vi kommer til at bruge alligevel.
Så det lyder rimeligt at antage at det er en videreudbygning på denne teknologi.
IA-64 bliver brugt i Intels Itanium processorer, dvs. det er en helt anden arkitektur end den x86-64 baserede processorer anvender.
De fleste af os benytte i vores computere x86-64 baserede processorer.
Intels teknologi for 64bit på x86 processorer hedder så vidt jeg ved EM64T, som blandt andet bliver brugt i Core 2's og i5/i7.
AMDs variant af x86-64 hedder AMD64.
Sådan som jeg ser det, ser det ud til at det har meget lidt relevans for de fleste af os, hvorvidt windows 8 kommer til at understøtte IA-128 eller ej, da det ikke er noget vi kommer til at bruge alligevel.
#11 Hvorfor skulle 64 bit være en fordel for funktionelle sprog? Ok, ML bruger 1 bit til at markere om noget er en pointer, hvilket bringer adresserummet ned på 31 bit, men ellers kan jeg overhovedet ikke se hvad du mener. Alle de funktionelle sprog jeg kender til forhindrer i øvrigt én i at lave nogen antagelser om størrelser på ting, så ens programmer altid virker så længe der findes en compiler til maskinen.
Hvis vi antager at behovet for virtual memory fordobles hvert år, så skulle det have taget 16 år at gå fra 16 bit til 32 bit og 32 år at gå fra 32 bit til 64 bit. Det er ikke helt ved siden af.Nja, ændringen fra 32 til 64 har så vidt jeg ved kun betydet at memory-pointerne er gået fra 32 (eller faktisk 36) bit til 48 bit. Det er altså kun en forøgelse fra et OS perspektiv på 12 bit.
Er ikke enig i den test. Jeg har selv kørt win7 64bit i godt en måned, og det booter hurtigere end noget jeg har haft før.
Efter skrivebordet bliver vist, går der omkring 4 sek, før cpu går i idle.
Granted - min sys disk er en SSD, men stadig der går ikke mere end 15 sec efter den booter på C, til den er i idle.
BIOS start mm burde de nok nærmere arbejde på, da det tager væsenligt længere.!
Efter skrivebordet bliver vist, går der omkring 4 sek, før cpu går i idle.
Granted - min sys disk er en SSD, men stadig der går ikke mere end 15 sec efter den booter på C, til den er i idle.
BIOS start mm burde de nok nærmere arbejde på, da det tager væsenligt længere.!
[quote=RTM (12)
Intels teknologi for 64bit på x86 processorer hedder så vidt jeg ved EM64T, som blandt andet bliver brugt i Core 2's og i5/i7.
AMDs variant af x86-64 hedder AMD64.
[/quote]
Husk nu på, at det er AMD der lavede X86-64, og Intels indførelse af deres (AMD´s) teknologi, kaldte de EMT64. Selv om de lånte AMD´s teknologi, så gav intel det, sit eget navn.
ogen (16) skrev:
BIOS start mm burde de nok nærmere arbejde på, da det tager væsenligt længere.!
Hvor har du været? :)
http://blog.laptopmag.com/phoenixs-1-second-instan...
Tagger (6) skrev:Problemet er jo, at der til dato udvikles rigtig mange 32-bit applikationer. De store firmaer har så småt taget 64-bit teknologien til sig, mens langt de fleste fritidsprogrammører stadig leger med 32-bit.
Hvad for nogle fritidsprogrammører?
Det lille shareware program til Windows udviklet af en enkelt Delphi fritids programmør er en meget lille del af software markedet.
Men det er jo ikke som sådan et problem da 64 bit Windows fint kan afvikle 32 bit Windows programmer.
Tagger (6) skrev:Ofte er der jo ikke den store vinding ved at bruge 64-bit over 32-bit
Hvis man ikke har brug for adresserummet så er der ingen fordele. Hvis vi specifikt snakker x86 versus x86-64, så får man nogle flere registre i 64 bit mode, men memory forbruget går også op.
ipwn (8) skrev:En del libraries er desværre kun 32bit. Jeg kompilere som regel kun i 64bit, men jeg er ofte løbet ind i problemer med libraries. En del open source libraries syntes ikke at være klar til Win64 endnu
Mit gæt er at de pågældende libraries er klar til Linux 64 bit, så de er 64 bit klar, men at der ikke har været fokus på Windows 64 bit. Indtil videre - det ændrer sig nu.
Kenman (11) skrev:Før vi ser rigtig 64bit udvikling bliver vi nødt til at skubbe folk over og køre med 64bit computere så der er en reel grund til at begynde at kigge på det.
De fleste har da en 64 bit computer idag.
Kenman (11) skrev:Endvidere behøver 64bit først at blive rigtig interessant når vi begynder at snakke om talknusning og funktionelle sprog da de færreste alm. programmer kan få noget reelt ud at køre 64bit andet end at sluge lidt mere ram pga. adresseringen
Talknusning i sig selv stiller ikke store krav til adresse rum.
Og funktionelle sprog heller ikke.
RTM (12) skrev:Nu bliver der jo snakket om at IA-128 er kompatibelt med IA-64.
Så det lyder rimeligt at antage at det er en videreudbygning på denne teknologi.
Hvilket gør historien endnu mere utroværdig.
Man skal vist være meget Intel/HP glad for at mene at Itanium er en stor success.
mathiass (13) skrev:Nja, ændringen fra 32 til 64 har så vidt jeg ved kun betydet at memory-pointerne er gået fra 32 (eller faktisk 36) bit til 48 bit. Det er altså kun en forøgelse fra et OS perspektiv på 12 bit.
Pointere går per definition fra 32 til 64 bit ved et skift fra 32 bit til 64 bit.
Pointere indeholder virtuelle adresser. En virtuel adresse i et X bit OS er X bit.
x86 bruger 32 bit virtuelle adresser. x86-64 bruger 64 bit virtuelle adresser (i den forstand at det er hvad er x86-64 standard compliant program skal bruge, de nuværende CPU'er i arkitekturen bruger kun de laveste 48 bit, men det vil ændre sig i fremtiden).
Fysiske adresser kan have en anden størrelse end de virtuelle adresser.
x86 uden PAE bruger 32 bit fysiske adresser mens x86 med PAE bruger 36 bit fysiske adresser.
x86-64 bruger forskellige størrelse fysiske adresser. De nuværende CPU'er bruger 40 bit fysiske adresser, men fremtidige vil understøtte op til 52 bit fysiske adresser.
arne_v (22) skrev:
Talknusning i sig selv stiller ikke store krav til adresse rum.
Og funktionelle sprog heller ikke.
Jeg tror du misser en væsentlig pointe. 64 bit arkitekturen giver ikke kun et større adresserum, det giver også mulighed for at udføre mere arbejde ved en enkelt maskininstruktion, når der arbejdes med store tal, hvilket jo netop er tilfældet ved "talknusning".
Se fx http://gmplib.org/32vs64.html.
Coma (17) skrev:[quote=RTM (12)
Intels teknologi for 64bit på x86 processorer hedder så vidt jeg ved EM64T, som blandt andet bliver brugt i Core 2's og i5/i7.
AMDs variant af x86-64 hedder AMD64.
Husk nu på, at det er AMD der lavede X86-64, og Intels indførelse af deres (AMD´s) teknologi, kaldte de EMT64. Selv om de lånte AMD´s teknologi, så gav intel det, sit eget navn. [/quote]
Faktisk er det et af de mindste "tricks" der er lavet.
Intel lavede det fra 16 bit til 32 biti tifrerne morgen
MMX, SSE, AVX og så videre er mere revolutionrende end at fordoble(i bits) den adressebære hukommelse...specilet når man kigger på die space.
tez (25) skrev:Jeg tror du misser en væsentlig pointe. 64 bit arkitekturen giver ikke kun et større adresserum, det giver også mulighed for at udføre mere arbejde ved en enkelt maskininstruktion, når der arbejdes med store tal, hvilket jo netop er tilfældet ved "talknusning".
Se fx http://gmplib.org/32vs64.html.
Skift fra 32 bit til 64 bit giver mulighed for et 4.2 milliarder gange større virtuelt adresse rum og intet andet.
Det mudres bare lidt til af at de fleste skift fra 32 til 64 bit følges af små ændringer til instruktions sættet.
Skift fra x86 til x86-64 giver en lille smule forbedring på integer beregninger fordi man fordobler antal registre og en hel del forbedring på floating point beregninger fordi man skifter fra stak baseret registre til generelle registre.
Men udtalelsen i det du linker til:
If we instead would compare an Athlon XP and an Athlon 64, the latter would be almost 4 times faster.
er misvisende.
+5% for integer og +15% for floating point er mere realistisk for en tilfældig app.
Der er muligvis større fordele for 64 bit integer operationer, når man som man ofte gør skifter fra 32 til 64 bit registre, men 64 bit integer operationer er ikke ret meget brugte i almindelige apps.
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
- ⟨
- Nyheder
Gå til bund