mboost-dp1
unknown
Hvad havde de regnet med, og hvorfor skulle outlook blive hurtigere? så du kan skrive hurtigere mails? fjollet...
Det tyder på kun de allermest nødvendige API'er er opdateret. Man har nok ikke gidet rekompileret applikationer fordi det ej var besværet værd; med andre ord, et 64bit kompatibelt OS men absolut ikke mere end det. Lidt skuffende og ifølge artiklen "...only early adopters and those running 64-bit software should give Windows XP Professional x64 a try!".
Det er da klart at der er ikke nogen apps til 64-bits cpu'er. Endnu. Der er jo ingen der vil lave noget software hvis der ikke noget marked for det, eller hvis udstyr til at benytte softwaren koster en bondegård.
#5 De begynder nok at komme nu, når windows er kommet i en 64 bit version. Før denne udgivelse var der jo ikke så meget pointe i at sende 64 bit programmer på markedet til windows PC'er. Det er gået stærkt med at der er kommet noget 64 bit software på markedet efter de fleste linux-distributioner er kommet i 64-bit udgaver, men her er det selvfølgelig også lettere at kompilere en 64-bit udgave selv.
"men det vil ressourcekrævende brugere som f.eks. folk, der arbejder med 3D."
øøøøh ARBEJDER med 3D... .hører spil ind under dette?
Og hvad med folk der laver videoencoding eller pakker meget i RAR og lign.?
Det siger jo sig selv at folk som brugere deres PC som en skrive/maile/surfe maskine, ikke vil få noget ud af en hurtigere CPU og et hurtigere OS, tingene kører jo smooth i forvejen
øøøøh ARBEJDER med 3D... .hører spil ind under dette?
Og hvad med folk der laver videoencoding eller pakker meget i RAR og lign.?
Det siger jo sig selv at folk som brugere deres PC som en skrive/maile/surfe maskine, ikke vil få noget ud af en hurtigere CPU og et hurtigere OS, tingene kører jo smooth i forvejen
Lyder som om man godt kan vente et halvt års tid endnu før der er noget at hente ved en opgradering.
#10
Som du kan se i artiklen er der ikke meget at vinde ved at bruge 64-bit Windows på 32-bit programmer, i et enkelte tilfælde er det faktisk langsommere.
Men det er jo primært seriøse programmer der er/bliver udviklet til 64-bit. Det er godt nok kun et spørgsmål om tid, selvfølgelig.
#11
Ja, det er også det jeg ser som essensen af anmeldelsen.
Som du kan se i artiklen er der ikke meget at vinde ved at bruge 64-bit Windows på 32-bit programmer, i et enkelte tilfælde er det faktisk langsommere.
Men det er jo primært seriøse programmer der er/bliver udviklet til 64-bit. Det er godt nok kun et spørgsmål om tid, selvfølgelig.
#11
Ja, det er også det jeg ser som essensen af anmeldelsen.
#3
De marginale performance forbedringer man kunne få på de sansynligvis meget få 64bit beregninger der potentielt forefindes i outlook express eller windows update (media player er lidt mere interessant, alt efter om man kan bruge 64 bit codecs med et 32 bit program eller ej - på den anden side så har jeg endnu ikke mødt noget video der ikke kunne afspilles med en 3200+ 32bit CPU).
Og hvad angår registrene så er der heller ingen garanti for at flere registre giver noget, det afhænger i høj grad hvilke typer beregninger programmet laver, og jeg tvivler ærligt talt på at outlook express eller windows update laver noget der kunne anvende flere registre med nævneværdig(om nogen overhovedet) fordel.
Og sidst, men ikke mindst som nogen pointerede en gang for nogle år tilbage så kan det vel være ligemeget hvor hurtigt word venter på dig - eller sagt med andre ord hvis der ikke er nogen ventetid for dig i brugen af programmet (i hvert fald ingen som ikke skyldes I/O) så kan det vel være uendeligt ligyldigt om det er 64, 32 eller 8 bit for sags skyld.
De marginale performance forbedringer man kunne få på de sansynligvis meget få 64bit beregninger der potentielt forefindes i outlook express eller windows update (media player er lidt mere interessant, alt efter om man kan bruge 64 bit codecs med et 32 bit program eller ej - på den anden side så har jeg endnu ikke mødt noget video der ikke kunne afspilles med en 3200+ 32bit CPU).
Og hvad angår registrene så er der heller ingen garanti for at flere registre giver noget, det afhænger i høj grad hvilke typer beregninger programmet laver, og jeg tvivler ærligt talt på at outlook express eller windows update laver noget der kunne anvende flere registre med nævneværdig(om nogen overhovedet) fordel.
Og sidst, men ikke mindst som nogen pointerede en gang for nogle år tilbage så kan det vel være ligemeget hvor hurtigt word venter på dig - eller sagt med andre ord hvis der ikke er nogen ventetid for dig i brugen af programmet (i hvert fald ingen som ikke skyldes I/O) så kan det vel være uendeligt ligyldigt om det er 64, 32 eller 8 bit for sags skyld.
Til normal brug (browsing, email, brevskrivning) 64 nytter INGEN ting... måske 1% får man mere ud af det...
Hvis applikationer skrevet dedikeret til 64 bit, så vil man få mærkbare performance i 3D, Video, Lyd, Encoding, Compression/Decompression.
Det gælder ikke hvor hurtigt et program starter og slutter.. det gælder hvor meget response tid programmet har når man arbejder med det og presser til at gennemføre nogle hårde funktoner. Feks. rendering af sekvenser i 3D, real timer filter i audio/video. Det kræver dog også nogle hurtige diske til at gennemfør opgaven. Hele systemet skal være optimeret for at få den fulde udnytte af 64 bit, dvs. ren 64 bit hele vejen og ingen tilbage kompatibilitet til 32bit, ellers er den ikke værd.
Ret, hvis jeg tager fejl!
Hvis applikationer skrevet dedikeret til 64 bit, så vil man få mærkbare performance i 3D, Video, Lyd, Encoding, Compression/Decompression.
Det gælder ikke hvor hurtigt et program starter og slutter.. det gælder hvor meget response tid programmet har når man arbejder med det og presser til at gennemføre nogle hårde funktoner. Feks. rendering af sekvenser i 3D, real timer filter i audio/video. Det kræver dog også nogle hurtige diske til at gennemfør opgaven. Hele systemet skal være optimeret for at få den fulde udnytte af 64 bit, dvs. ren 64 bit hele vejen og ingen tilbage kompatibilitet til 32bit, ellers er den ikke værd.
Ret, hvis jeg tager fejl!
Hvorfor i alverden skulle de da også straks komme med en 64 bits udgave af alle gamle programmer. Pointen med AMD64 designet var jo netop, at man kunne blive ved med at bruge eksisterende 32 bits kode sammen med den nye 64 bits kode. Mange programmer fungerer fint i en 32 bits udgave, og lad dog dem blive ved med at køre 32 bits et stykke tid endnu. Og brug så i første omgang 64 bits der hvor det batter.
De har sikkert ret i konklusionen om, at det i første omgang er interessant for udviklere. Men det betyder nok, at vi om et par år begynder at se programmer, der kun kommer i en 64 bits udgave. Og til den tid begynder hjemmecomputerne nok også at have de 4GB eller mere, hvor 64 bits bliver en nødvendighed. (Jeg ved godt, at man kan udnytte op til 64GB fysisk RAM med PAE. Men jeg tror faktisk at en sammenligning af 32 bits programmer på hhv en 32 bits kerne med PAE support og samme program på en kerne til AMD64 ville falde ud til AMD64s fordel).
Det sidste RAM modul jeg købte var et 1GB modul til 800kr. Der er plads til tre af dem på mit bundkort (som er det billigste jeg kunne finde for et år siden). Så 4GB RAM er altså ikke ret langt væk.
#12 The-Lone-Gunman
De har sikkert ret i konklusionen om, at det i første omgang er interessant for udviklere. Men det betyder nok, at vi om et par år begynder at se programmer, der kun kommer i en 64 bits udgave. Og til den tid begynder hjemmecomputerne nok også at have de 4GB eller mere, hvor 64 bits bliver en nødvendighed. (Jeg ved godt, at man kan udnytte op til 64GB fysisk RAM med PAE. Men jeg tror faktisk at en sammenligning af 32 bits programmer på hhv en 32 bits kerne med PAE support og samme program på en kerne til AMD64 ville falde ud til AMD64s fordel).
Det sidste RAM modul jeg købte var et 1GB modul til 800kr. Der er plads til tre af dem på mit bundkort (som er det billigste jeg kunne finde for et år siden). Så 4GB RAM er altså ikke ret langt væk.
#12 The-Lone-Gunman
Som du kan se i artiklen er der ikke meget at vinde ved at bruge 64-bit Windows på 32-bit programmer, i et enkelte tilfælde er det faktisk langsommere.Du mener 32-bit programmer på 64-bit Windows. Lidt underligt at det skulle blive langsommere, men de målinger, de har i artiklen viser, at der er stort set ingen forskel. En recompileret udgave der udnytter 64 bits og de ekstra registre ville nok vise sig at være målbart hurtigere end 32 bits udgaven.
#16 Simm
Men de ændringer Microsoft varslede, da de introducerede Windows 95 var langt mere omfattende end et skift fra 16 bits til 32 bits. Det var et komplet redesign af systemet. Da der så viste sig ikke helt at være hold i de løfter kunne de bruges et par gange mere. Det var vist først med introduktionen af XP at gennemsnitsbrugeren reelt slap af med DOS.
Skiftet fra en 32 bits XP til en 64 bits XP har intet at gøre med et komplet redesign af operativsystemet. Godt nok kom 64 bits (ligesom 32 bits) flere år for sent, men den her gang har man ikke også et forældet design, der skal udskiftes.
Det her minder mig om diskussionen, da man gik fra 16-bit systemer til 32Min første computer var en Amiga, så jeg har faktisk aldrig ejet en 16 bits computer. Så jeg kan altså heller ikke huske diskussionen om skiftet fra 16 til 32 særlig godt. Jeg kan til gengæld huske lidt om 286 arkitekturen, et 16 bits system designet da det stod klart for enhver, at 16 bits var forældet. Selv en 8086 var udstyret med en lappeløsning for at kunne bruge mere end de 64KB RAM, der kunne adresseres med 16 bits. Så 32 bits PCen kom nok ca. 10 år for sent.
Men de ændringer Microsoft varslede, da de introducerede Windows 95 var langt mere omfattende end et skift fra 16 bits til 32 bits. Det var et komplet redesign af systemet. Da der så viste sig ikke helt at være hold i de løfter kunne de bruges et par gange mere. Det var vist først med introduktionen af XP at gennemsnitsbrugeren reelt slap af med DOS.
Skiftet fra en 32 bits XP til en 64 bits XP har intet at gøre med et komplet redesign af operativsystemet. Godt nok kom 64 bits (ligesom 32 bits) flere år for sent, men den her gang har man ikke også et forældet design, der skal udskiftes.
#14 Det kan du måske have ret i, men den her version af XP er så første skridt mod det mål.
Windows 95 var også i stand til at køre 32 bits programmer selvom store dele af systemet stadig var 16 bit.
Du har ikke ret i at det vil være bedre at lave en CPU der ikke er bagudkompatibel med 32 bit. En sådan CPU vil aldrig kunne sælges. Der er ikke nødvendigvis noget tab ved at beholde bagudkompatibiliteten.
Windows 95 var også i stand til at køre 32 bits programmer selvom store dele af systemet stadig var 16 bit.
Du har ikke ret i at det vil være bedre at lave en CPU der ikke er bagudkompatibel med 32 bit. En sådan CPU vil aldrig kunne sælges. Der er ikke nødvendigvis noget tab ved at beholde bagudkompatibiliteten.
Synes det er underligt at mediaplayer ikke er blevet konverteret. Det er sådanset det eneste userspace program i Windows, hvor jeg kunne forestille der ville blive en performance forøgelse, der ville være besværet værd.
Kan 32 bit programmer iøvrigt køre på en 64 bit kernel, med over 4 gb RAM?
Kan 32 bit programmer iøvrigt køre på en 64 bit kernel, med over 4 gb RAM?
Hvis man opgraderer (For det skal jo i så fald være inden July 31, 2005.) bliver ens 32bit version deaktiveret, eller hvon' fungerer denne update? Jeg har ikke lige lyst til at prøve mig frem... men er alligevel nysgerrig.
Jeg kom også så langt at jeg indtastede mit COA nummer, hvilket den også godkendte.
Da jeg så indtastede min adresse og leverings info osv, så ville dne ikke godkende det og smed en fejl om at jeg skulle kontakte microsoft...
Tjaa, det er vel godt det samme, lyder umiddelbart ikke som om at den vil være andet end mere besværlig lige her i starten.
Da jeg så indtastede min adresse og leverings info osv, så ville dne ikke godkende det og smed en fejl om at jeg skulle kontakte microsoft...
Tjaa, det er vel godt det samme, lyder umiddelbart ikke som om at den vil være andet end mere besværlig lige her i starten.
Angående performanceboost så prøvede jeg, for at se hvad 32 vs. 64 bit reelt giver, at installere to gentoo (chroot-jail) sat til henholdsvis 32 bit og 64 med tilhørende 32 og 64 bit kerner. I de to jails satte jeg host systemet til henholdsvis athlon og amd64 (uden yderlige optimerede flags) og kompilede base-systemet og blender med disse indstillinger.
En simpel render-test viste (på mit sys) at 64 bit gav ca. 15% extra. Hvor meget der kunne presses ud af systemet med compiler flags ved jeg ikke... endnu :-)
Hvis nogen skulle være interesseret i hvordan man gør det findes der en bunke guides til det :-)
En simpel render-test viste (på mit sys) at 64 bit gav ca. 15% extra. Hvor meget der kunne presses ud af systemet med compiler flags ved jeg ikke... endnu :-)
Hvis nogen skulle være interesseret i hvordan man gør det findes der en bunke guides til det :-)
#4 Hehe skulle udstyret koste en bondegård?? Har du lige misset hele denne diskussion og en lille ting der hedder Athlon 64 som er katalysatoren for Windows 64 XP????
#16 Du har aldrig ejet en 16-bits computer skriver du og så skriver du at din første computer var en Amiga....hmmm ;-) Lidt selvmodsigende ikk?
#16 Du har aldrig ejet en 16-bits computer skriver du og så skriver du at din første computer var en Amiga....hmmm ;-) Lidt selvmodsigende ikk?
Amiga var en 16-bit computer. Det var en af dens stærkeste salgs-argumenter overfor Commodores tidligere populære hjemmecomputer : Commodore 64 som jo bekendt var en 8-bits computer.... Så svaret er et rungende JA! ;-)
Amigaens CPU var en Motorola 68000 som var en "ren" 16-bit cpu uden noget legacy support af 8-bit.
Amigaens CPU var en Motorola 68000 som var en "ren" 16-bit cpu uden noget legacy support af 8-bit.
#22 Fafler
#28 Trentors
Kan 32 bit programmer iøvrigt køre på en 64 bit kernel, med over 4 gb RAM?Ja, du kan sagtens køre 32 bit programmer på en computer med over 4GB RAM. Du er bare begrænset til 4GB pr. program. Det er en forbedring i forhold til en 32 bit kerne, hvor kernen typisk selv bruger 1-2GB af adresserummet og derfor ikke efterlader mere end 2-3GB til hvert program.
#28 Trentors
Amiga var en 16-bit computer. Det var en af dens stærkeste salgs-argumenter overfor Commodores tidligere populære hjemmecomputer : Commodore 64 som jo bekendt var en 8-bits computer....De tal du giver er databusbredderne, den slags er softwaren fuldstændig ligeglad med. Amigaen har altid haft 32 bit registre, og AmigaOS var lige fra den første udgave et 32 bit OS. Og den begrænsede busbredde gjalt kun for de små Amiga modeller. 1200, 3000 og 4000 modellerne har så vidt jeg ved 32 bit databus. Jeg ved ikke så meget om 64'eren, men jeg dog at den har 16 bit adresser.
#26-30 http://en.wikipedia.org/wiki/Motorola_68000
Men alt det her med hvormange bits en processor er på kan også være forvirrende. For hvad er det lige der bestemmer hvormange bits den er på ?
Blev PS (eller PS2?) ikke også lanceret som en 128bits cpu på et tidspunkt?
Men alt det her med hvormange bits en processor er på kan også være forvirrende. For hvad er det lige der bestemmer hvormange bits den er på ?
Blev PS (eller PS2?) ikke også lanceret som en 128bits cpu på et tidspunkt?
#31 dub
Og det var i øvrigt en ganske glimrende gennemgang af m68000, du linkede til.
For hvad er det lige der bestemmer hvormange bits den er på ?Det er jo et godt spørgsmål, men når nu diskussionen går på software design, så giver det kun mening at måle på parametre, der har inflydelse på softwaren. Nogle personer i den her tråd er begyndt at måle på databusen. Jeg mener at den oprindelige pentium havde en 64 bits databus, men der er jo ingen, der kalder DOS for et 64 bits OS af den grund. Jeg ledte lidt på nettet efter yderligere oplysninger og fandt den her side, som siger at Pentium II har en 64 bits databus.
Og det var i øvrigt en ganske glimrende gennemgang af m68000, du linkede til.
Blev PS (eller PS2?) ikke også lanceret som en 128bits cpu på et tidspunkt?Jeg kan godt huske, at en eller anden spilmaskine blev lanceret som en 128 bits maskine, men jeg kan ikke huske hvilken. Set med mine øjne er størrelsen af general purpose registrene (som normalt også matcher størrelsen af det virtuelle adresserum) det bedste mål.
#29
Nopes. De blev kun købt af garvede Amiga tilhængere og så har det næppe været hans første computer. Desuden var den en hamrende fiasko så chancen er vel 0,01 procent for han ikke havde en Amiga 500, 600, 1000 eller 2000.
#30
Nej jeg mente nu at maskinens ALU dikterer hvad den er. Det er sandt at 68000 var en underlig hybrid med 32-bit adresering men dens ALU og databus var i Amiga 500's tilfælde 16-bit. Og ja de senere modeller som Commodore beskrev som 32-bit computere havde 32-bit hele vejen igennem. Commodore betegnede den selv som 16-bit og de senere versioner skrev de også pænt 32-bit over det hele på for at vise udviklingen.
#32
Jo Emotion Engine er en ret unik sag og en slags forløber for Cell. Den ER 128bit og er baseret på parallelism - hvilket forklarer dens performance når man tænker på den kun kører ca. 300 mhz. De andre konsoller er ikke 128bit fordi de er baseret på mere traditionelle teknologier som egentligt ikke er egnet til konsoller...især X-Boxens :-S
Nopes. De blev kun købt af garvede Amiga tilhængere og så har det næppe været hans første computer. Desuden var den en hamrende fiasko så chancen er vel 0,01 procent for han ikke havde en Amiga 500, 600, 1000 eller 2000.
#30
Nej jeg mente nu at maskinens ALU dikterer hvad den er. Det er sandt at 68000 var en underlig hybrid med 32-bit adresering men dens ALU og databus var i Amiga 500's tilfælde 16-bit. Og ja de senere modeller som Commodore beskrev som 32-bit computere havde 32-bit hele vejen igennem. Commodore betegnede den selv som 16-bit og de senere versioner skrev de også pænt 32-bit over det hele på for at vise udviklingen.
#32
Jo Emotion Engine er en ret unik sag og en slags forløber for Cell. Den ER 128bit og er baseret på parallelism - hvilket forklarer dens performance når man tænker på den kun kører ca. 300 mhz. De andre konsoller er ikke 128bit fordi de er baseret på mere traditionelle teknologier som egentligt ikke er egnet til konsoller...især X-Boxens :-S
#30
Du tager fejl. Trentors har ret. Amigaen har ikke altid været en 32 bit chip. Alle Amiga-modeller op til 2500 familien havde 16bit ordlængde. Og Commodore 64 havde (... har.. jeg har en stående en halv meter væk) 8bit ordlængde.
Edit:
#33
Well jeg ved i hvert fald at både Amiga 500 og 1000 benyttede sig af 16bit ordlængde i CPUen og også til at adressere hukommelse. Kan ikke huske specifikt om de senre modeller.
Du tager fejl. Trentors har ret. Amigaen har ikke altid været en 32 bit chip. Alle Amiga-modeller op til 2500 familien havde 16bit ordlængde. Og Commodore 64 havde (... har.. jeg har en stående en halv meter væk) 8bit ordlængde.
Edit:
#33
Well jeg ved i hvert fald at både Amiga 500 og 1000 benyttede sig af 16bit ordlængde i CPUen og også til at adressere hukommelse. Kan ikke huske specifikt om de senre modeller.
#33 Fair argument, men du kan stadig ikke vide. Pointen var at en Amiga ikke ER 16-bit, det er noget vås at sige. Som du også selv skriver kan det vel diskuteres hvad man skal kalde en MC68000 (32 eller 16-bit). Når han siger at han ikke har haft en 16-bit Amiga så må man jo tro på at han har haft en 32-bit model, eller skal jeg bare kalde ham en løgner ligesom Trentor gør og ignorere at der eksisterer Amiga-modeller der ikke er 16-bit? Jeg vælger at stole på manden om han så ejer en model der er mere populær end A3000 ;)
#30 I øvrigt kan en 32 bit pentium II og frem godt adressere mere end 4 GB hukommelse. Man så begrænsningen med de 4 GB meget tidligt og gjorde den i stand til at addressere ram på to måder. Den ene med et 32 bits registre som ganske rigtigt begrænser størrelsen til 4 GB og det andet med 32 bit adresse og en 16 bits pointer til et offset sådan at en pentium kan adressere 48 bit hukommelse (16500 gange de 4 GB).
At Windows ikke understøtter den måde at adressere hukommelse på er en anden sag. OS/2 gjorde og linux kan (selvom det normalt er slået fra i den prækompilerede kerne kan man normalt også hente en hvor det er slået til).
At Windows ikke understøtter den måde at adressere hukommelse på er en anden sag. OS/2 gjorde og linux kan (selvom det normalt er slået fra i den prækompilerede kerne kan man normalt også hente en hvor det er slået til).
Det er ligegyldigt hvilken Amiga model vi snakker om, set fra softwarens synspunkt er de alle 32 bits maskiner. Hvis nogen skulle være interesseret, så har jeg haft en 500+ og har nu en 1200.
#37 mathiass
Med PAE kunne man altså have 64GB fysisk RAM, men stadigvæk kun 4GB logisk adresserum. Det blev typisk til 1GB til kernen og 3GB til hver process. Selv med segmentering var man begrænset af de 32 bits. En 16+32 bits adresse blev af segmenteringen afbilledet til en 32 bits adresse som efterfølgende af PAE page tabellen blev afbilledet til en 36 bits adresse.
Nøjagtigt det samme gælder stadigt for AMD64, bortset lige fra, at en 64 bits kerne kan ligge udenfor de første 4GB adresserum og dermed giver 32 bits programmer adgang til de fulde 4GB. De kan stadigt ikke bruge mere end det heller ikke med segmentering. I 64 bits mode har AMD truffet den (efter min mening gode) beslutning at ikke understøttet segmentering.
#37 mathiass
det andet med 32 bit adresse og en 16 bits pointer til et offset sådan at en pentium kan adressere 48 bit hukommelseDu har ikke forstået hvordan det fungerer. Ja man kan godt bruge segment+offset adressering, men da adressen alligevel efterfølgende mappes ned i et 32 bits adresserum, så ændrer det ikke på 4GB begrænsningen. Hvis du laver flere segmenter på 3GB hver, så kommer de nødvendigvis til at overlappe.
OS/2 gjordeOS/2 blev designet til 286. Dengang var segmentering den eneste måde at nå ud over 64KB, og kun i protected mode kunne segmentering nå ud over 1088KB. 286 protected mode understøttede op til 16MB RAM. Der kom senere en 32 bits udgave af OS/2 til CPUer som havde en begrænsning på 4GB.
linux kan (selvom det normalt er slået fra i den prækompilerede kerne kan man normalt også hente en hvor det er slået til).Jeg går ud fra, at det er PAE du tænker på. PAE udvider de fysiske adresser til 36 bits, men de logiske adresser er stdigt kun 32 bits. PAE fungerer ved at udnytte nogle af de overskydende bits i page tabellen, som tidligere skulle sættes til nul af operativsystemet.
Med PAE kunne man altså have 64GB fysisk RAM, men stadigvæk kun 4GB logisk adresserum. Det blev typisk til 1GB til kernen og 3GB til hver process. Selv med segmentering var man begrænset af de 32 bits. En 16+32 bits adresse blev af segmenteringen afbilledet til en 32 bits adresse som efterfølgende af PAE page tabellen blev afbilledet til en 36 bits adresse.
Nøjagtigt det samme gælder stadigt for AMD64, bortset lige fra, at en 64 bits kerne kan ligge udenfor de første 4GB adresserum og dermed giver 32 bits programmer adgang til de fulde 4GB. De kan stadigt ikke bruge mere end det heller ikke med segmentering. I 64 bits mode har AMD truffet den (efter min mening gode) beslutning at ikke understøttet segmentering.
Som, det allerede er sagt så gør det jo ikke det store at de basale windows programmer ikke er 64-bit. Det vigtigste er at programudviklerne nu har en windows platform hvor de kan skrive 64-bit programmer til.
Mon ikke efteråret byder på en A64x2 R520/G70 opgradering :P
Mon ikke efteråret byder på en A64x2 R520/G70 opgradering :P
#33 #35 'Amigas CD-baserede konsol som fik navnet CD32 så folk virkelig fattede at nu kørte vi 32-bit'
nej - grunden til at konsolen hed cd32, var fordi den skulle paa et markede hvor 16bit konsoler med cartridges dominerede - det har intet at goere med, at amiga nu var 32bit, for det har den, set fra ethvert praktisk synspunkt, altid vaeret.
/daniel
nej - grunden til at konsolen hed cd32, var fordi den skulle paa et markede hvor 16bit konsoler med cartridges dominerede - det har intet at goere med, at amiga nu var 32bit, for det har den, set fra ethvert praktisk synspunkt, altid vaeret.
/daniel
#38 og #40
Kig her -------> http://www.machine-room.org/computers/92/
Der står CPU Word Length 16-bits og det er velkendt faktum at databussen var 16-bit og ALU'en (og dens betydning skal vel ikke forklares) var 16-bit på Amiga 500. Ja 68000 havde 32-bit adressering men den var begrænset af Amigaens databus og kunne kun arbejde internt med 16-bit i dens ALU. Så man kan sige det var en 16-bit CPU der understøttede 32-bit men med en 16-bit CPU's performance! Så det øldelægger lidt det "praktiske" synspunkt da den praktiskse performance var og er 16-bit på en Amiga 500.
#36
Ann O.Nym du tager fejl. Han havde en Amiga 500 - har tjekket med ham. Har aldrig kaldt ham en løgner men tak fordi du påstår dette - hvilket i øvrigt er let at se da vi er på et SKRIFTLIG forum hvor man kan se hvad de andre har skrevet i diskussionen... ;-) Så jeg havde ret i at sandsyngligheden for at det var ikke var en 68020-Amiga var ret stor.
Kig her -------> http://www.machine-room.org/computers/92/
Der står CPU Word Length 16-bits og det er velkendt faktum at databussen var 16-bit og ALU'en (og dens betydning skal vel ikke forklares) var 16-bit på Amiga 500. Ja 68000 havde 32-bit adressering men den var begrænset af Amigaens databus og kunne kun arbejde internt med 16-bit i dens ALU. Så man kan sige det var en 16-bit CPU der understøttede 32-bit men med en 16-bit CPU's performance! Så det øldelægger lidt det "praktiske" synspunkt da den praktiskse performance var og er 16-bit på en Amiga 500.
#36
Ann O.Nym du tager fejl. Han havde en Amiga 500 - har tjekket med ham. Har aldrig kaldt ham en løgner men tak fordi du påstår dette - hvilket i øvrigt er let at se da vi er på et SKRIFTLIG forum hvor man kan se hvad de andre har skrevet i diskussionen... ;-) Så jeg havde ret i at sandsyngligheden for at det var ikke var en 68020-Amiga var ret stor.
#41 Trentors
Og hvis du havde bygget en 16 bits ISA ovenpå m68000s mikroarkitektur, så skal du nok regne med at performance var blevet dårligere af det. Dermed mener jeg at 16 bits operationer ville nok være ca. lige hurtige på hvv 16 og 32 bits ISA. Men 32 bits operationer ville være væsentligt hurtigere på en 32 bits ISA, fordi det kan udføres med en enkelt instruktion, og dermed kun kræver en enkelt ordredekodning. Hvorimod en tilsvarende operation på en 16 bits ISA ville kræve mindst to ordrer.
Der kan ikke være nogen tvivl om at ISA på m68000 var 32 bits. Og det er det eneste, der betyder noget, når man skriver OS.
performance var og er 16-bitDet giver altså ikke mening at snakke om 16 bits performance, da der kan være stor forskel på performance af 16 bits CPUer, selv hvis de kører ved samme clockfrekvens. Man kan da også bare se på udviklingen fra dengang hvor en CPU brugte 4-40 clockcycles per instruktion til i dag hvor en CPU kan udføre langt de flest instruktioner på færre clockcycles og i ekstreme tilfælde to instruktioner per clockcycle. Der er altså også stor forskel på performance af 386, Celeron, Athlon og Xeon selvom de alle er 32 bits CPUer.
Og hvis du havde bygget en 16 bits ISA ovenpå m68000s mikroarkitektur, så skal du nok regne med at performance var blevet dårligere af det. Dermed mener jeg at 16 bits operationer ville nok være ca. lige hurtige på hvv 16 og 32 bits ISA. Men 32 bits operationer ville være væsentligt hurtigere på en 32 bits ISA, fordi det kan udføres med en enkelt instruktion, og dermed kun kræver en enkelt ordredekodning. Hvorimod en tilsvarende operation på en 16 bits ISA ville kræve mindst to ordrer.
Der kan ikke være nogen tvivl om at ISA på m68000 var 32 bits. Og det er det eneste, der betyder noget, når man skriver OS.
#41 Jeg går ud fra at du kan tåle det. Du ved forhåbentlig hvad jeg mente, nemlig at du sagde at han havde en 16-bit maskine, mens han selv sagde at han havde en 32-bit. Hvis det har stået her på fora at han havde en Amiga 500 har jeg da overset det, men normalt stoler jeg på folk der snakker om ting kun de kan vide. Vi kan jo også diskutere om en 68000 er en 32-bit CPU (det mener jeg nu heller ikke at den kan kaldes).
den skal lige med..
Og et link til dem der ikke har hørt den før (HER).
Det er faktisk anden gang på meget kort tid at denne sang bliver nævnt på newz.dk.. i to forskellige sammenhæng.
den skal lige med..
C64 var egentlig ret fedt et sted
der var - der var - der var bare for få bits at fedte med, så jeg skred
over til Amiga for at finde gejsten
der var en del flere bits - der var faktisk 16.
Og et link til dem der ikke har hørt den før (HER).
Det er faktisk anden gang på meget kort tid at denne sang bliver nævnt på newz.dk.. i to forskellige sammenhæng.
#42
Kind of stating the obvious there, kasperd. Det er selvfølgelig inde for samme arktitektur at jeg mener der er forskel på 16-bit og 32-bit. Og da ALU'en på 68000 kører 16-bit og den ikke har nogen FPU så vil den altså skulle bruge dobbelt så mange clocks for at klare den samme instruktion som de senere 68020+ da de havde en 32-bit ALU. Ergo er dens performance 16-bit i min bog. Den kan ikke udfører nogen instruktion overhovedet i 32-bit men den kan afvikle dem i 16-bit. Den er altså kompatibelt med 32-bit ISA'en men den kræver dobbelt så mange clocks for at kunne udføre dem. Deraf 16-bit performance.
#43
Hehe ja. Men han havde altså en god gammel Amiga 500 som de fleste andre - en god maskine BTW og dens arkitektur er stadig genial.
Den gode gamle klassiker du henviser til siger det hele :-D
Kind of stating the obvious there, kasperd. Det er selvfølgelig inde for samme arktitektur at jeg mener der er forskel på 16-bit og 32-bit. Og da ALU'en på 68000 kører 16-bit og den ikke har nogen FPU så vil den altså skulle bruge dobbelt så mange clocks for at klare den samme instruktion som de senere 68020+ da de havde en 32-bit ALU. Ergo er dens performance 16-bit i min bog. Den kan ikke udfører nogen instruktion overhovedet i 32-bit men den kan afvikle dem i 16-bit. Den er altså kompatibelt med 32-bit ISA'en men den kræver dobbelt så mange clocks for at kunne udføre dem. Deraf 16-bit performance.
#43
Hehe ja. Men han havde altså en god gammel Amiga 500 som de fleste andre - en god maskine BTW og dens arkitektur er stadig genial.
Den gode gamle klassiker du henviser til siger det hele :-D
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