mboost-dp1
Intel
(Sandy Bridge 22nm hedder også Ivy Bridge)
#3 naa, om det er 2 eller 20 gør ikke den store forskel med de værktøjer der efterhånden er kommet frem som fx Grand Central Dispatch og Paralleles Extension. Som programmør skal man bare koncentrere sig om at opdele hvor man kan; så ordner systemet resten.
Desuden kan der jo køre 10 programmer på en maskine samtidig, som så hver kan bruge 5 kerner.
#3 naa, om det er 2 eller 20 gør ikke den store forskel med de værktøjer der efterhånden er kommet frem som fx Grand Central Dispatch og Paralleles Extension. Som programmør skal man bare koncentrere sig om at opdele hvor man kan; så ordner systemet resten.
Desuden kan der jo køre 10 programmer på en maskine samtidig, som så hver kan bruge 5 kerner.
kalash (3) skrev:Hvor mange programmer har egentligt lært at håndtere 4 kerne ?
Man er først lige begyndt at åbner øjne for at ens program kan understøtte 2 kerne -.-
bare rolig... fremtidens programmer skallerer meget bedre end hidtil. .NET (og især F#) er også begyndt med nye parallel-biblioteker...
som #4 er inde på, så er den tiltænkt servere... tænk bare på en webserver ! - hver eneste besøgende opretter opretter tråde når de henter en side som så lægges i en threadpool - jo flere kerner jo bedre er oplevelsen for alle besøgende.
#8 - hvis du gerne vil leve med UI som windows 95, ve my guest. Så kan du også gå tilbage og bruge IE 5 og word 2003.
Når jo, så skal du i øvrigt også kun surfe på HTML only websider, og du må maks have to sider åbne ad gangen. Din opløsning på skærmen hedder 800x600 og de spil du spiller er lemmings og tetris 2D! Hver gang du åbner et nyt program skal du lukke nogle andre.
Det er jo ikke producenternes skyld. Det er vores livsstil der har indrettet sig efter de mange resourcer. Og nej, maskinerne forbliver ikke ligeså langsomme. Det er vores krav der forøges.
Når jo, så skal du i øvrigt også kun surfe på HTML only websider, og du må maks have to sider åbne ad gangen. Din opløsning på skærmen hedder 800x600 og de spil du spiller er lemmings og tetris 2D! Hver gang du åbner et nyt program skal du lukke nogle andre.
Det er jo ikke producenternes skyld. Det er vores livsstil der har indrettet sig efter de mange resourcer. Og nej, maskinerne forbliver ikke ligeså langsomme. Det er vores krav der forøges.
Hack4Crack (2) skrev:om 20 år sidder vi med de der i vores mobiler... men lortet er stadig langsomt!
Det er faktisk en sjov ting. de sløvheder vi klager over på pc'er idag, er de samme som for mange år siden.
Er det fordi vi vænner os til hastigheden? eller måske fordi vores krav stiger ligeså hurtigt som hardwaren? eller omvendt...
#10
der er mange årsager, en af de mere interessante er alle de lag softwaren efterhånden har.
Engang blev programmer skrevet direkte til den hardware de kørte på og programmer skulle compiles forfra hvis de skulle flyttes fra en type system til et andet, der var reelt ikke noget der kunne kaldes et operativsystem og tingene var skrevet til at virkelig kunne udnytte den tilgængelige hardware. I dag kører folk en word processor i en virtuel maskine i en browser i et OS med 3D brugerflade etc. etc. etc. alle de abstraktionslag koster ydelse.
x86 arkitekturen er 32 bit. Der er ikke noget der hedder 86 bit. Der refereres sålede til x86 chipsene.
ufomekaniker (13) skrev:x86 arkitekturen er 32 bit. Der er ikke noget der hedder 86 bit. Der refereres sålede til x86 chipsene.
Jep, stammer fra Intels 8086'er :) tider
Hvorfor man kalder 64bit for x64 er mig en gåde.
#12 - det er en helt forkert måde at angribe det på :)
Vi snakker idag om to "hovedarkitekture" AMD's og intel's (kan sgu ikke lige huske de eksakte navne)
Det er de to arkitekture der hovedsageligt anvendes.
Den forskel der fokuseres på i dem, er at den ene arbejder med en 64bit bred adressebus, og den anden arbejde med en 32bit bred adressebus (reelt 36 så vidt jeg husker?).
den øgede busbredde gør at man kan adressere 2^64 bit i stedet for de omkring 4GB man kunne ved 32 bit.
Vi snakker idag om to "hovedarkitekture" AMD's og intel's (kan sgu ikke lige huske de eksakte navne)
Det er de to arkitekture der hovedsageligt anvendes.
Den forskel der fokuseres på i dem, er at den ene arbejder med en 64bit bred adressebus, og den anden arbejde med en 32bit bred adressebus (reelt 36 så vidt jeg husker?).
den øgede busbredde gør at man kan adressere 2^64 bit i stedet for de omkring 4GB man kunne ved 32 bit.
x86 arkitekturen er på en 16 bits arkitektur, som med tiden er blevet udstyret med en 32 bits udvidelse og en 64 bits udvidelse. At kalde det for en 32 bits arkitektur er lidt upræcist da man med rette lige så godt kunne kalde det for en 16 bits arkitektur eller for en 64 bits arkitektur.ufomekaniker (13) skrev:x86 arkitekturen er 32 bit. Der er ikke noget der hedder 86 bit. Der refereres sålede til x86 chipsene.
Navnet stammer fra 8086, som blev efterfulgt af 80186, 80286, 80386, 80486. I daglig tale unlod man som regel at sige det første 80. Og så var det naturligt at anvende x86 som en fællesbetegnelse.
8086 var navngivet på den måde fordi det var efterfølgeren til 8085, som var en 5 volts udgave af 8080. Det eneste 8086 havde til fælles med foregængeren var at sourcekode i store træk kunne oversættes til den nye uden ændringer. Men de var ikke binært kompatible.
Fordi så mange ikke forstod betydningen af x86. Den 64 bits arkitektur der i dag er kendt som x86 blev i en periode kaldt for AMD64. x86 navnet blev vist først opfundet efter Intel begyndte at lave AMD kompatible CPUer.SlettetBruger (14) skrev:Hvorfor man kalder 64bit for x64 er mig en gåde.
32 bits arkitekturen er Intels, og 64 bit arkitekturen er AMDs. Intel tillod oprindeligt AMD (og mange andre) at lave Intel kompatible CPUer efter pres fra IBM. Aftalen betød dog at Intel sidenhen kunne begynde at lave AMD kompatible 64 bits CPUer uden at skulle have ret meget tilladelse til det.buchi (15) skrev:Vi snakker idag om to "hovedarkitekture" AMD's og intel's (kan sgu ikke lige huske de eksakte navne)
Det er de to arkitekture der hovedsageligt anvendes.8086-80286 var 16 bits CPUer. Der var fra starten et hack som tillod at bruge en 20 bits bus på trods af at det kun var en 16 bits arkitektur. Med 80286 introduceredes protected mode, som betød at man rent faktisk kunne implementere seperation mellem processer gennem segmentering. Det var dog ikke særligt udnyttet, men da segmenteringen samtidig gav mulighed for at udnytte en 24 bits bus blev det brugt fordi det betød at man kunne have op til 16MB RAM.
Den forskel der fokuseres på i dem, er at den ene arbejder med en 64bit bred adressebus, og den anden arbejde med en 32bit bred adressebus (reelt 36 så vidt jeg husker?).
den øgede busbredde gør at man kan adressere 2^64 bit i stedet for de omkring 4GB man kunne ved 32 bit.
80386 og fremefter har en 32 bits protected mode som også inkluderer mulighed for at emulere den oprindelige 8086 16 bits mode. CPUen er stadigvæk i 16 bits mode når maskinen tændes men kan skiftes til 32 bits af BIOS eller operativsystem. Arkitekturen havde support for 32 bits data og adresse bus, men jeg ved ikke om der var 32 bits adresse bus fra starten. Omkring pentium introduceredes et nyt hack som gav mulighed for 36 bits adresse bus, men det kostede noget performance.
Da Intel prøvede at designe en ny 64 bits arkitektur fra grunden havde de ikke meget held med det. AMD valgte i stedet at lave en 64 bits arkitektur der var 100% bagudkompatibel, men som også havde en 64 bits mode som byggede på de gamle principper, og dog udelod nogle af de mere obskure features som primært eksisterede for bagudkompatibilitet. Denne arkitektur havde fra start af en begrænsning til 48 adresse bits, og man undgår det performance overhead som det gamle hack til 36 bits adresser medførte.
64 bits arkitekturen kan godt udvides til 64 bits adresser en gang i fremtiden. Det vil kræve ændringer i operativsystemet, men vil ikke kræve ændringer i applikationerne.
Det du giver udtryk for er en uheldig tankegang. Forhåbentlig er den mest udbredt blandt slutbrugere og ikke så meget blandt softwareudviklere.kalash (3) skrev:Hvor mange programmer har egentligt lært at håndtere 4 kerne ?
Man er først lige begyndt at åbner øjne for at ens program kan understøtte 2 kerne -.-
Hvis man designer software til 2 kerner, så er man på den gale vej. Når man tager skridtet fra en enkelt kerne til flere kerner, så skal man designe software så den er ligeglad med antal kerner.
Man kan dele arbejdet op i nok uafhængige enheder til at man kan lægge dem i en kø og så lade tråde tage en enhed ud af køen ad gangen og når den er færdig med at behandle den fortsætte til den næste.
Forestil dig at man skal rendere et billede på 1920x1200 pixels, så kunne man f.eks. dele det op i stykker af 240x240 pixels således at der er 40 krvadrater, der skal renderes. Har man to CPUer skal de håndtere ca. 20 hver (men hvis nogle områder er hurtigere end andre kan det godt ende med f.eks. at blive fordel med 15 komplekse områder til den ene og 25 simplere til den anden).
Hvis man kører det samme på en 50 core CPU kan 40 tråde tage et område hver, og de sidste 10 kan tage sig af andre opgaver. Det afgørende er dele opgaven op i tilstrækkeligt mange paralleliserbare dele. Selv hvis flere dele foretages sekventielt af en tråd så har man opnået fleksibilitet som gør at man kan undytte mange CPUer.
Der var engang at programmer var designet til en fast skærmopløsning. I dag er de fleste programmer designet til at kunne håndtere forskellige opløsninger. Og det tager vi efterhånden for givet. Hvor mange programmer kan du komme i tanke om som er designet til at håndtere to forskellige skærmopløsninger og ikke blot til at kunne håndtere alle dem som hardwaren giver mulighed for?
KasperD:
Det er noget af det mest interessante læsning jeg hidtil har set her. Tak fordi du tog dig tid til, at forklare det så grundigt.
Det er noget af det mest interessante læsning jeg hidtil har set her. Tak fordi du tog dig tid til, at forklare det så grundigt.
mee (11) skrev:Engang blev programmer skrevet direkte til den hardware de kørte på og programmer skulle compiles forfra hvis de skulle flyttes fra en type system til et andet,
De gør de fleste poplære desktop apps stadig.
mee (11) skrev:der var reelt ikke noget der kunne kaldes et operativsystem
Så skal du meget langt tilbage i tiden.
SlettetBruger (14) skrev:Hvorfor man kalder 64bit for x64 er mig en gåde.
kasperd (16) skrev:Fordi så mange ikke forstod betydningen af x86. Den 64 bits arkitektur der i dag er kendt som x86 blev i en periode kaldt for AMD64. x86 navnet blev vist først opfundet efter Intel begyndte at lave AMD kompatible CPUer.
AMD bruger navnet AMD64.
Intel har brugt forskellige navne IA-32e, EMT64T og Intel 64.
De fleste bruger x86-64 som en fælles betegnelse for arkitekturen.
Men et software firma fra Redmond har konsekvent brugt betegnelsen x64 fremfor x86-64.
http://www.microsoft.com/windowsxp/64bit/default.m...
http://support.microsoft.com/windowsserver2003x64
http://www.microsoft.com/windowsserver2008/en/us/6...
(der er også andre firmaer som har brugt x64 betegnelsen, men formentligt er der Microsoft som de fleste kender den fra)
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