mboost-dp1
unknown
Spændende - dette må vel anses som værende det største skridt siden i processorbranchen siden skiftet fra 486DX-modellerne til Pentium-arkitekturen.
Det giver også Intels Extreme Edition processorer et større fortrin fremfor deres mere konventionelle consumer-modeller, hvilket vel må siges at være tiltrængt, da langt de fleste applikationer ikke har vist de store ydelsesmæssige forbedring ved Extreme Edition processorerne... og pris/ydelses-forholdet har dermed været utroligt ringe for nævnte...
Så må vi bare vente på de 2 vitale ting - nemlig tests/benchmarks (syntetisk såvel som "real life") samt at de kommer i butikkerne herhjemme! :)
Det giver også Intels Extreme Edition processorer et større fortrin fremfor deres mere konventionelle consumer-modeller, hvilket vel må siges at være tiltrængt, da langt de fleste applikationer ikke har vist de store ydelsesmæssige forbedring ved Extreme Edition processorerne... og pris/ydelses-forholdet har dermed været utroligt ringe for nævnte...
Så må vi bare vente på de 2 vitale ting - nemlig tests/benchmarks (syntetisk såvel som "real life") samt at de kommer i butikkerne herhjemme! :)
#2
Hvis du ikke har set, den test der blev omtalt newz.dk, så vil jeg da anbefale den. Syntes selv den havde nogle glimrende vurderinger af fx Single vs. Dual Core.
testen omtalt på newz.dk
Hvis du ikke har set, den test der blev omtalt newz.dk, så vil jeg da anbefale den. Syntes selv den havde nogle glimrende vurderinger af fx Single vs. Dual Core.
testen omtalt på newz.dk
Mon ikke vi om 1-2 uger kan læse om en vaskeægte dual kamp imellem AMD og Intel, det bliver så første test man kan bruge til noget objektivt pt. eftersom mainstream software ikke er dual-parat endnu.
#8 Hvorfor er x86-64/EMT64 ikke rigtig 64bit? Adresseområdet er udvidet til 256 tebibytes og nye 64bit registre med tilhørende OPkode. Det er samme udvidelse vi så med 386'en til 32bit og 8086'en til 16bit.
IA64 er ikke mere "rigtig" 64bit end x86-64/EMT64, forskellen er i design hvor førstnævnte ikke længere er en videreudvikling af x86 arkitekturen.
IA64 er ikke mere "rigtig" 64bit end x86-64/EMT64, forskellen er i design hvor førstnævnte ikke længere er en videreudvikling af x86 arkitekturen.
2. del af AnandTech's preview
http://anandtech.com/cpuchipsets/showdoc.aspx?i=23...
bla kan man se at den bruger 244 watt, i forhold til Athlon 64 3500+'s 143 watt :)
http://anandtech.com/cpuchipsets/showdoc.aspx?i=23...
bla kan man se at den bruger 244 watt, i forhold til Athlon 64 3500+'s 143 watt :)
#10 Dén test måler TOTAL power consumption af systemet! Men interesant at AMD's 3500+ kræver mindre strøm ved fuld load end Intel D som laver ingenting.
Intel D CPU'en kommer vist til at ligge på omkring de 95W og jeg forventer bestemt AMD's vil ligge lidt under dette.
Intel D CPU'en kommer vist til at ligge på omkring de 95W og jeg forventer bestemt AMD's vil ligge lidt under dette.
#12 Hvis du tænker på størrelsen på operationskoderne, ja så forbliver de 32bit. Men det er vel heller ikke nødvendigt med mere eftersom du med 32bit kan repræsentere 4.3 mia unikke processor instruktioner.
At kunne gange/dividere osv. 64bit tal med hinanden er vel også noget vigtigere end at instruktionen skal fylde 8byte!
At kunne gange/dividere osv. 64bit tal med hinanden er vel også noget vigtigere end at instruktionen skal fylde 8byte!
Jeg vil gerne se nogle benchmarks der f.eks. viser hvor hurtigt firefox er om at åbne et nyt vindue, med mencoder kørende i baggrunden og den slags. Altså hvor man virkelig kan se hvor meget de 2 kerner betyder for brugerens oplevelse af multitasking.
Og også noget om hvor mange watt maskinen bruger, både under fuld load og når den, bare står hele natten og idler og agerer webserver.
Og også noget om hvor mange watt maskinen bruger, både under fuld load og når den, bare står hele natten og idler og agerer webserver.
#13 nu er det jo ikke antallet af forskellige instruktioner som er det primære mål med at udvide instruktionslængden...
det er et spørgsmål om, at jo flere data hver instruktion indeholder, jo færre instruktioner behøver man. Hvis man f.eks. har en jump instruktion, kan man ofte være nødt til at bruge en ekstra instruktion til at angive destinationsadressen...
det er et spørgsmål om, at jo flere data hver instruktion indeholder, jo færre instruktioner behøver man. Hvis man f.eks. har en jump instruktion, kan man ofte være nødt til at bruge en ekstra instruktion til at angive destinationsadressen...
#15 Man hopper ikke bare rundt i hukummelsen, men bruger code-segment:offset adressering. I tilfældet med 32bit x86 ser et "FAR JMP" sådan ud:
|11101010|offset-low|offset-high|seg-low|seg-high|
Bemærk at det allerede ikke kan "være i en 32bit instruktion".
De eneste instruktioner der fylder mere på x86-64 er dem som berører stakken, dvs. push, pop og call.
Kilde: "IBM PC Assembly Language and Programming" samt http://www.tortall.net/projects/yasm/wiki/AMD64
http://en.wikipedia.org/wiki/X86-64
|11101010|offset-low|offset-high|seg-low|seg-high|
Bemærk at det allerede ikke kan "være i en 32bit instruktion".
De eneste instruktioner der fylder mere på x86-64 er dem som berører stakken, dvs. push, pop og call.
Kilde: "IBM PC Assembly Language and Programming" samt http://www.tortall.net/projects/yasm/wiki/AMD64
http://en.wikipedia.org/wiki/X86-64
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