mboost-dp1
unknown
Ikke for at være kværulant, men er det ikke også efterhånden på tide at pensionere x86 arkitekturen? Den er trods alt helt tilbage fra 1978. Selv Commodore 64 chippens arkitektur er af nyere dato!
Det lyder som om Intel pønser på noget meget spændende og jeg håber virkeligt, at der bliver tale om noget HELT nyt. Det trænger vi til.
EDIT : Jeg fandt lige ud af, at 64'erens MOS6502 faktisk er et par år ældre!
Det lyder som om Intel pønser på noget meget spændende og jeg håber virkeligt, at der bliver tale om noget HELT nyt. Det trænger vi til.
EDIT : Jeg fandt lige ud af, at 64'erens MOS6502 faktisk er et par år ældre!
bare så længe det bliver et standard design! ellers kommer vi jo til at se 2 forskellige windnows version... Oo
altså en til intel og en til amd
altså en til intel og en til amd
Lyder da som et rigtigt god initiativ af Intel endeligt gør noget for at komme videre og måske lave en seriøs konkurrent til Cell processoren. (Bare de kan køre samme programmer, så er jeg glad)
Det lyder lidt spøjst at Intel med software skal "genkompilere" eller oversætte alle x86 programmer med software, men forhåbentlig ved Intel hvad de har gang i :)
Det lyder lidt spøjst at Intel med software skal "genkompilere" eller oversætte alle x86 programmer med software, men forhåbentlig ved Intel hvad de har gang i :)
#2 Læs lige nyheden igen. Der er tale om transparent kompilering af x86 kode, udviklere vil ikke skulle skrive direkte til VLIW instruktionssættet. Al eksisterende software vil derfor fungere, men med den fleksibilitet, at Intel nu kan optimere, fejlrette og justere via software (a la gfx-drivere).
Med tiden vil x86 laget så måske falde bort, eftersom nye programmer skrives eksklusivt til VLIW. Det er sku smart.
Med tiden vil x86 laget så måske falde bort, eftersom nye programmer skrives eksklusivt til VLIW. Det er sku smart.
Hmm det er da altid noget de tænker i SÅ nye baner...
Men jeg troede ellers x86 arkitekturen havde fået et reelt makeover i 1995 da Intel lancerede P6 kernen som jo er RISC baseret og bruger et lag som oversætter x86 instruktionerne så de kan behandles...
Men det undrer mig da også at man ikke efterhånden er skiftet til at skrive softwaren direkte til RISC laget i morderne CPUer. - der er vel ik ret mange der har en gammel pentium eller 486 mere
#1 det passer så ikke - eferfølgeren til C64, Amiga bruger 68000 arkitekturen som er ca på alder med 8086 arkitekturen.
#2 når CPUen har et softwarelag som oversætter gamle instruktioner er det intet problem at køre gammel kode på de nye
Men jeg troede ellers x86 arkitekturen havde fået et reelt makeover i 1995 da Intel lancerede P6 kernen som jo er RISC baseret og bruger et lag som oversætter x86 instruktionerne så de kan behandles...
Men det undrer mig da også at man ikke efterhånden er skiftet til at skrive softwaren direkte til RISC laget i morderne CPUer. - der er vel ik ret mange der har en gammel pentium eller 486 mere
#1 det passer så ikke - eferfølgeren til C64, Amiga bruger 68000 arkitekturen som er ca på alder med 8086 arkitekturen.
#2 når CPUen har et softwarelag som oversætter gamle instruktioner er det intet problem at køre gammel kode på de nye
#6 LOL det er jo ikke det der sker!!!
Det vil være transparent for softwaren, så det betyder blot at CPUen selv oversætter x86 instruktionerne fra softwaren når den modtager dem, herefter laver den udregningerne og oversætter sender resultatet tilbage. - man indskyder så at sige en "tolk" imellem softwaren og selve "hjernen" (ALUen) i CPUen...
Det vil være transparent for softwaren, så det betyder blot at CPUen selv oversætter x86 instruktionerne fra softwaren når den modtager dem, herefter laver den udregningerne og oversætter sender resultatet tilbage. - man indskyder så at sige en "tolk" imellem softwaren og selve "hjernen" (ALUen) i CPUen...
#5 P7 (Pentium 4) bygger rigtig nok på P6 (Pentium Pro) og har en lynhurtig RISC engine dybt nede under CISC laget. Som jeg forstår artiklen, vil dette X86 decoder lag bliver elimineret, ligesom out-of-order schedualer og branch-predictor. Alle sammen nogle af de mest strømslugende kredsløb i P6 arkitekturen.
#7 Jeg tror #6 refererer til denne bemærkning i artiklen: "Once translated, the new binaries are saved to disc, they will run as native VLIW thereafter."
Så hans spørgsmål er nu slet ikke så dumt.
#7 Jeg tror #6 refererer til denne bemærkning i artiklen: "Once translated, the new binaries are saved to disc, they will run as native VLIW thereafter."
Så hans spørgsmål er nu slet ikke så dumt.
#9: Tjeah, der vil da i princippet kunne opstå et problem ifb. ens pladsforbrug, og iøvrigt også checksums i visse tilfælde - f.eks. programmer som detecter ændringer i ens system som chkrootkit og visse windows programmer som checker på den kørende process (som jo vil være den jit compilerede udgave) og på filen og igen ift. en db med en registrering af checksums etc. Den "frygt" er sådan set reel nok, og det bliver "sjovt" at se hvordan det bliver løst.
Var der ikke en anden nyhed på news.dk for kort tid siden?
Jeg mener konklusionen var, at det der med at lave flertrådede programmer, der udnyttede cpu'erne fuldt ud, var meget besværligt. Derfor skulle man ikke regne med, at PS3 og Xbox 360 blev så vilde, som deres specs sagde. Så kan jeg ikke rigtigt se, hvordan det skulle kunne udnyttes her?
Jeg mener konklusionen var, at det der med at lave flertrådede programmer, der udnyttede cpu'erne fuldt ud, var meget besværligt. Derfor skulle man ikke regne med, at PS3 og Xbox 360 blev så vilde, som deres specs sagde. Så kan jeg ikke rigtigt se, hvordan det skulle kunne udnyttes her?
Lad os håbe at den ny teknologi ikke bruger så meget strøm som den nuværende, vil være rart med et lavt strømforbrug...
Elselskaberne står nærmest i kø for at bejle til mig ^^
Elselskaberne står nærmest i kø for at bejle til mig ^^
#13:
Haha, der står nu i nyheden:
Så medmindre de bliver 4 gange hurtigere, så må de vel bruge mindre strøm. (Jeg ville selvfølgelig ikke have noget imod, de blev 4 gange hurtigere.)
Elselskaberne står nærmest i kø for at bejle til mig ^^
Haha, der står nu i nyheden:
Det nye design skal give 4 gange bedre performance pr. watt end nuværende CPU'er.
Så medmindre de bliver 4 gange hurtigere, så må de vel bruge mindre strøm. (Jeg ville selvfølgelig ikke have noget imod, de blev 4 gange hurtigere.)
#12 I første omgang, vil der nok heller ikke være tale om revolutionerende enkelttrådet hastighed fra CPU'en - som Blachford forudser, vil AMD stadig dominere dette område et par år endnu.
Men der er nok ingen tvivl om, at fremtiden handler om parallelkørsel eftersom GHz grænsen så småt synes at være nået. Hvis Intel tager boksehanskerne på og går i ringen med denne nye arkitektur, må man tage hatten af for deres innovation - selv om det måske ikke give pote i nuværende programmer.
Men der er nok ingen tvivl om, at fremtiden handler om parallelkørsel eftersom GHz grænsen så småt synes at være nået. Hvis Intel tager boksehanskerne på og går i ringen med denne nye arkitektur, må man tage hatten af for deres innovation - selv om det måske ikke give pote i nuværende programmer.
#12
Fordi de laver et abstraktionslag. Synes iøvrigt også det er noget pjat fra ps3 og xbox 360 udviklernes side, den gyldne regel i forbindelse med den her slags udvidelser er abstraktion, hvis du "bare" laver et abstraktionslag som optimerer koden så den bruger de rigtige enheder af cpu'en til de rigtige ting, så vil tabet bliver relativt beskedent (det er tvivlsomt at du kan bruge alle dele af cpu'en optimalt).
Den slags abstraktionslag er selvfølgelig sindsygt komplicerede, men når det først er lavet, så er resten af opgaven ikke sværere end tidligere, problemet er selvfølgelig, at hvis Sony/MS ikke selv leverer det er det sandsynligvis ikke eksisterende til når de første udviklere begynder at udvikle til PS3/Xbox 360.
Fordi de laver et abstraktionslag. Synes iøvrigt også det er noget pjat fra ps3 og xbox 360 udviklernes side, den gyldne regel i forbindelse med den her slags udvidelser er abstraktion, hvis du "bare" laver et abstraktionslag som optimerer koden så den bruger de rigtige enheder af cpu'en til de rigtige ting, så vil tabet bliver relativt beskedent (det er tvivlsomt at du kan bruge alle dele af cpu'en optimalt).
Den slags abstraktionslag er selvfølgelig sindsygt komplicerede, men når det først er lavet, så er resten af opgaven ikke sværere end tidligere, problemet er selvfølgelig, at hvis Sony/MS ikke selv leverer det er det sandsynligvis ikke eksisterende til når de første udviklere begynder at udvikle til PS3/Xbox 360.
ENDELIG!.
Rigtig nyudvikling istedet for resterne fra i går, tilsat en Bouillon terning... ;)
"Bare de kan køre samme programmer, så er jeg glad..."
Nej nej nej!!!...
For pokker det er jo den tankegang som gør, at vi stadig lægger og rodder rundt med en så gammel arkitektur... :( For hver gang man vil udvikle noget virkelig revolutionerende:
"Jamen kan mit gamle software så stadig køre?..."
En eller anden dag må Intel og AMDs ingeniører finde modet til at sige: "Nu skal vi fortælle jer, hvad i kan gøre med jeres gamle bras!..." Og bruge kræfterne på at lave noget gennembrydende... :)
Rigtig nyudvikling istedet for resterne fra i går, tilsat en Bouillon terning... ;)
"Bare de kan køre samme programmer, så er jeg glad..."
Nej nej nej!!!...
For pokker det er jo den tankegang som gør, at vi stadig lægger og rodder rundt med en så gammel arkitektur... :( For hver gang man vil udvikle noget virkelig revolutionerende:
"Jamen kan mit gamle software så stadig køre?..."
En eller anden dag må Intel og AMDs ingeniører finde modet til at sige: "Nu skal vi fortælle jer, hvad i kan gøre med jeres gamle bras!..." Og bruge kræfterne på at lave noget gennembrydende... :)
#18> Ah okay.
Nej selvfølgelig ikke, men jeg kunne ikke rette det igen, men der skulle have stået "#16".
Men det løser vel stadig ikke mit problem: Når jeg spiller Quake, så er det ikke interresant om jeg kan folde 1 milliard proteiner ved siden af, hvis jeg hellere vil bruge krafterne på frames. (Selvom det da ikke ville gøre mig noget at kunne folde 1 millard proteiner ved siden af.)
Nej selvfølgelig ikke, men jeg kunne ikke rette det igen, men der skulle have stået "#16".
Men det løser vel stadig ikke mit problem: Når jeg spiller Quake, så er det ikke interresant om jeg kan folde 1 milliard proteiner ved siden af, hvis jeg hellere vil bruge krafterne på frames. (Selvom det da ikke ville gøre mig noget at kunne folde 1 millard proteiner ved siden af.)
#17 Starter du et simpelt program som notepad, vil denne process blive tildelt et stykke tid på CPU'en, ligesom de andre programmer der kører. En sådan applikation siges derfor at være enkelttrådet. En process kan også starte en tråd mere til at behandle data mm., hvorfor programmet nu siges at være fler-trådet og får et stykke tid mere på CPU'en.
I Windows og Solaris verdenen er tråde og processer to forskellige ting. En tråd (letvæksprocess) ejes af en process og deler dennes adresseområde i hukommelsen samt dens input/output kø.
I Linix er det anderledes, Linix kernen skelner ikke imellem tråd og process, men behandler alt som en unik process der potentielt har delte data.
Da tråde (eller Linix processer med delt data) er tættere forbundet med hinanden end regulære processer, er det langt sværere at fordele arbejdet effektivt. Det er typisk 100 gange langsommere at synkronisere adgang til én ressource, frem for at gå enegang med processen. Det er derfor Valve's direktør har manet til besindighed mht. performance i den næste generation af spil.
I Windows og Solaris verdenen er tråde og processer to forskellige ting. En tråd (letvæksprocess) ejes af en process og deler dennes adresseområde i hukommelsen samt dens input/output kø.
I Linix er det anderledes, Linix kernen skelner ikke imellem tråd og process, men behandler alt som en unik process der potentielt har delte data.
Da tråde (eller Linix processer med delt data) er tættere forbundet med hinanden end regulære processer, er det langt sværere at fordele arbejdet effektivt. Det er typisk 100 gange langsommere at synkronisere adgang til én ressource, frem for at gå enegang med processen. Det er derfor Valve's direktør har manet til besindighed mht. performance i den næste generation af spil.
Intel har altid været innovative, men hvis de langt om længe kommer videre fra x86 arkitekturen, ja så ville jeg nok fejre det med at lade min næste CPU være noget andet end Celeron, bare for at støtte dem yderligere.
Jeg tror på at Intel om nogen, har drive til at tage et sådant skridt.
Jeg tror på at Intel om nogen, har drive til at tage et sådant skridt.
#28: Games er i sagens natur ret meget sværere at lave multi-threaded pga. timing og synkronisering af tingene. De fleste er jo lidt ligeglade med om tildeling af ressourcer og timing er præcist som den skal være når de skriver i word.
Man kunne jo godt køre doom under windows i gamle dage, men det var aldrig så godt som at køre direkte i dos'en.
Situationen er lidt anderledes idag hvor cpu'erne er meget bedre til at fordele ressourcer og multitaske/threade.
Man kunne jo godt køre doom under windows i gamle dage, men det var aldrig så godt som at køre direkte i dos'en.
Situationen er lidt anderledes idag hvor cpu'erne er meget bedre til at fordele ressourcer og multitaske/threade.
#26,
meningen er jo også at de bliver bagud kompetible, bare gennem at der sidder en software fortolker og oversætter din gamle x86 code.
Tag fx din nuværende CPU, for den er bagud-kompetible med en 8088-processor, har den primære bus et 20 bit adresse rum (som kan adressere op til 1MB ram), og en bus med 4 bit adresse rum, som blev tilføjed til 80286 modelen, så man kunne adressere 16 MB ram, og da man så skulle lave 80386 cpu'en, blev der tilføjet en 8 bit adresse bus mere, så man nu kunne adresserer 4GB ram.
Hver af disse tre busser, har deres egne kontrol busser, dvs. skal man adressere ram i en 80386 cpu skal man have kontrolbit til 20 bit busen, kontrol bit til 4 bit busen og kontrol bit til 8 bit busen.
Med et overhaul af arkitekturen kunne man nøjes med en enkelt 32 bit bus (kan stadig adressere 4GB ram), men man skulle så kun bruge en kontrolbus.
meningen er jo også at de bliver bagud kompetible, bare gennem at der sidder en software fortolker og oversætter din gamle x86 code.
Tag fx din nuværende CPU, for den er bagud-kompetible med en 8088-processor, har den primære bus et 20 bit adresse rum (som kan adressere op til 1MB ram), og en bus med 4 bit adresse rum, som blev tilføjed til 80286 modelen, så man kunne adressere 16 MB ram, og da man så skulle lave 80386 cpu'en, blev der tilføjet en 8 bit adresse bus mere, så man nu kunne adresserer 4GB ram.
Hver af disse tre busser, har deres egne kontrol busser, dvs. skal man adressere ram i en 80386 cpu skal man have kontrolbit til 20 bit busen, kontrol bit til 4 bit busen og kontrol bit til 8 bit busen.
Med et overhaul af arkitekturen kunne man nøjes med en enkelt 32 bit bus (kan stadig adressere 4GB ram), men man skulle så kun bruge en kontrolbus.
Heh. VLIW kerne med software-fortolker? Det lyder rigtignok meget som Transmetas processorer :)
Og Longrun er de vist også begyndt at bruge. Det undrer mig ikke at Transmeta begynder at vise overskud når et firma som Intel licenserer deres teknologier ;)
Og Longrun er de vist også begyndt at bruge. Det undrer mig ikke at Transmeta begynder at vise overskud når et firma som Intel licenserer deres teknologier ;)
#21
Det er faktisk ikke rigtigt. Korrekt at Unix varianter ikke oprindeligt ikke understøttede tråde og derfor ikke skelner mellem tråde og processer, men for Linux vedkommende passer det ikke. Og det har ikke passet i snart 10 år.
Der er betydelig forskel på at forke en process og starte en ny tråd i Linux. Når en process laver et 'fork'-kald, laves der en kopi af den kaldende tråd der får sit eget PID og variable. Og denne tråd kan hvis det ønskes køre fuldstændig uafhængigt af den oprindelige process.
Sådan er det ikke når du starter en tråd i Linux. Her får tråde godt nok sin egen stak men ikke sin egen hob ligesom en process ville gøre. Den deler også file descriptors, current directory state og signal handlers med sin process.
Det betyder altså at det er meget mindre ressoucekrævende at starte en tråd en and oprette en ny process. Og det er også væsentligt hurtigere at skifte mellem tråde da man ikke er nødt til at foretage et komplet kontekstsift.
Solaris og Windows er heller ikke helt i samme båd når det gælder tråde. Windows benytter kerneniveautråde hvor Solaris benytter en kobination af kerneniveautråde og brugeniveautråde.
Linux bruger en modificeret version IEER's POSIX standard, til at implementere tråde.
Det er faktisk ikke rigtigt. Korrekt at Unix varianter ikke oprindeligt ikke understøttede tråde og derfor ikke skelner mellem tråde og processer, men for Linux vedkommende passer det ikke. Og det har ikke passet i snart 10 år.
Der er betydelig forskel på at forke en process og starte en ny tråd i Linux. Når en process laver et 'fork'-kald, laves der en kopi af den kaldende tråd der får sit eget PID og variable. Og denne tråd kan hvis det ønskes køre fuldstændig uafhængigt af den oprindelige process.
Sådan er det ikke når du starter en tråd i Linux. Her får tråde godt nok sin egen stak men ikke sin egen hob ligesom en process ville gøre. Den deler også file descriptors, current directory state og signal handlers med sin process.
Det betyder altså at det er meget mindre ressoucekrævende at starte en tråd en and oprette en ny process. Og det er også væsentligt hurtigere at skifte mellem tråde da man ikke er nødt til at foretage et komplet kontekstsift.
Solaris og Windows er heller ikke helt i samme båd når det gælder tråde. Windows benytter kerneniveautråde hvor Solaris benytter en kobination af kerneniveautråde og brugeniveautråde.
Linux bruger en modificeret version IEER's POSIX standard, til at implementere tråde.
Jeg mener stadig en tråd i Linux verdenen er en abstraktion (modsat Windows), eftersom en "tråd" blot er en process med specificerede delte ressourcer, abstraheret af et vfork kald indeholdende noget lignende:
clone(CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND, 0)
Ovenstående vil jo få tildelt en task_struct med PID og blive behandlet fuldstændig som enhver anden process af kernen og derfor kan enumereres i en omgang.
I Windows foregår det derimod igennem CreateProcess() og CreateThread(), som modsat Linux, schedualeres forskelligt og heller ikke kan enumereres i en omgang.
clone(CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND, 0)
Ovenstående vil jo få tildelt en task_struct med PID og blive behandlet fuldstændig som enhver anden process af kernen og derfor kan enumereres i en omgang.
I Windows foregår det derimod igennem CreateProcess() og CreateThread(), som modsat Linux, schedualeres forskelligt og heller ikke kan enumereres i en omgang.
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