Intel har lige indrømmet at de heller ikke kan få deres 7 nanometer halvlederproduktion til at virke.
Vi er nogle der ikke er overraskede, Intel kunne heller ikke få deres 10 nanometer process til at virke og de fleste af de chips de langer over disken idag er stadig 14 nanometer teknologi.
(Der er nogle fodnoter omkring præcis hvad "X nanometer" betyder, som varierer lidt mellem de forskellige "fabs", men det ser vi lige bort fra et sekund.)
Intels indrømmelse betyder at state-of-the-art halvlederproduktion idag er et monopol-foretagende: Det er kun TSMC der kan finde ud af det.
De relevante TSMC fabs ligger alle i Taiwan eller Kina.
TSMC's 20 største aktionærer er alle kapitalfondsgribbe.
Jeg har ingen grund til at forvente at min næste CPU bliver hverken hurtigere eller billigere end min nuværende.
phk
Jeg har ingen grund til at forvente at min næste CPU bliver hverken hurtigere eller billigere end min nuværende.
Jeg har en 8 år gammel CPU i både arbejdsstation, laptop og server og jeg mangler ikke performance eller batterilevetid. Strømforbrugsdifferencen overstiger ikke på nogen måde investeringen i noget nyt, heller ikke set over 20 år. Der er ikke sket noget groundbreaking som jeg ville få gavn af.
Hvor meget gavn ville du have af en hurtigere CPU? Af en billigere?
Det er mere end ti år siden, at CPU-kerner stort set holdt op med at blive hurtigere. Det skyldes, at strømforbruget ikke længere var konstant per kvadratmillimeter, når man skrumpede teknologien, sådan at man, når man skrumpede til det halve areal, kunne skrue op for frekvensen uden at de samlede forbrug steg. Det kaldes "Dennard scaling".
Da det ikke længere galdt (ca. 2006), holdt frekvensen op med at stige (faktisk droslede man lidt ned), men antallet af kerner steg. Før 2006 var enkeltkerneprocessorer normen, men nu er der 4-16 kerner i de fleste processorer.
Vejen til mere performance i fremtiden er derfor mange flere kerner, men simplere kerner for at holde strømforbruget nede. Ekstremet findes i dag i grafikprocessorer, men flere general purpose kerner i en CPU kommer også.
Fujitsus nye supercomputer bruger f.eks. CPUer med 48 ARM kerner og ingen grafikprocessorer.
Jeg må indrømme at jeg opfatter den teknologiske begrænsning som langt mindre bekymrende end udsigten til et monopol.
Så vidt jeg har forstået, er AMD igen konkurrencedygtig, specielt indenfor server processorer, men deres chips er da 7 nanometer. Hvem laver dem ?
Sådan som jeg har forstået det, så bliver produktions systemerne dyrerere og dyrerer når transistor størrelsen går ned. Derfor er det naturligt at produktionen koncdentreres på færre og færre producenter. Monopoler er altid farlige ..... uanset om deres ejere er kapitalfonde eller ikke ....
...tillade mig at køre let over monopolproblematikken så er TSMC reelt set eneste store chip producent ud over Intel, alle andre er uden større betydning?
Samsung er nu også med på 7nm og har også 5nm klart snart (primo næste år). Mit indtryk er de nok er lidt bagud efter TSMC - men ikke meget. Så lidt konkurrence er der.
Som PHK siger, så er der lidt forskel i hvad "nanometer" er for de forskellige fabs. Historisk set har TSMC nok pyntet sig med lidt låne fjer og været "en bagud" i.f.t. navnet. F.eks. TSMC 14 nm svarer nok mere til Intel 22 nm, og det har givet Intel lidt puterum. Men nu er Intel efterhånden så langt bagud det virkelig bliver svært.
Lidt recap: Intel's 14 nm kom oprindeligt i 2014, men det var i en lidt lavere performende udgave til laptops, så den egentlige launch af en interessant CPU til desktop/servere var i 2015 (Skylake).
Intel har siden releaset 10nm, men ikke i nogen high performance-udgave. Den har en fin "instructions per clock" men grundet problemer med 10nm-processen er det ikke lykkedes at få klokfrekvensen op. Klokfrekvensen er lav (2 GHz eller lavere) så den er ikke konkurrence-dygtigt på desktop/servere... Så siden 2015 og til nu er det 14 nm der har trukket læsset på desktop/servere, og kun pga. af Inte's kæmpe forspring er det lykkedes at holde showet kørende. Intel har mere eller mindre indrømmet at 10 nm nok aldrig kommer i en performende udgave til desktop/servere. Og nu var den også forsinket så meget at Intel's 7nm kom tæt på. 7nm processen er - ifølge Intel - forskellig fra 10nm og er baseret på Ekstrem UV (ligesom TSMC etc. forventer at bruge på 5nm) og er derfor ikke ramt af 10nm processens problemer. Den kunne derfor overtage læsset, og forventningen var den kunne være klar slut-2021. Bestemt ikke fantastisk i.f.t. TSMC (som allerede har 7nm og formentlig 5nm senere i år), men dog med et lys forenden af tunnellen.
Gårsdagens melding er imidlertid noget nedslående, idet 7nm nu også er ramt af problemer og forventes tidligt klart slut-2022 eller start-2023. Når man tager i betragtning hvor meget Intel har skudt ved siden af, skal man nok ikke forvente det bliver før 2023.
Hos TSMC er status at man har leveret 7nm-processerer i 2 år, og forventer at være klar med 5nm processorer slut i år. Så i 2022 er det snarere 3nm processorer som Intel's 7nm processorer skal konkurrere med.
Det bliver en interessant tid. Men endnu mere interessant er det, at Intel's problemer har forhindret Intel i at frigive nye arkitekturer (undtagen til low-power laptops etc.). Køber man en ny Intel CPU i dag er det samme arkitektur som for 5 år siden - hverken i den interne implementation eller i form af features (ingen nye instruktioner, smarte features, krypto eller lignende etc.). Intel har udviklet en ny arkitektur (Icelake) som giver visse forbedringer, men den er bundet til 10nm, og de kan derfor ikke få den ud på mrkedet pga. problemerne i denne proces. Imellemtiden sprøjter AMD nye arkitekturer ud, senere i år forventes Zen3 til desktop på markedet.
Hvis Samsung stadig er relevante, er det vel ikke helt et monopol endnu? Så vidt jeg kan se på Wikipedia er de vist stadig med; er det bevidst I ser bort fra dem?
(Heh, slået med 7 minutter…)
Mht. titlen så er det jo ikke så meget Moore's forbandelse... for hvis udviklingen virkelig var fortsat efter Moore's lov, med fordoblinger hvert 2. år (eller endda hver 18. måned) som det var i 80'erne og 90'erne, så ville Intel jo være håbløst bagud. Et 2015-produkt ville så være minimum 5-6 gange dårligere end konkurrenternes, det vil sige håbløst forældet. Selvom AMD/TSMC kører med klatten sammenlignet med Intel, leverer de kun forbedringer på måske 10-15% per år, langt fra hvad vi har været vant til. Som Torben nævner sker noget af udviklingen dog også ved at der kommer flere cores, men det kan slet ikke hamle op med fortidens hastighed. Dels er det langtfra i alle workloads (og slet ikke desktop) der har glæde af flere cores, dels er selv denne udvikling langsom. Det er 10 år siden der kom mainstream processorer med 4 kerner. I dag er 8 måske normen i samme prisklasse, hvis overhovedet det.
Mht. titlen så er det jo ikke så meget Moore's forbandelse... for hvis udviklingen virkelig var fortsat efter Moore's lov, med fordoblinger hvert 2. år (eller endda hver 18. måned) som det var i 80'erne og 90'erne, så ville Intel jo være håbløst bagud. Et 2015-produkt ville så være minimum 5-6 gange dårligere end konkurrenternes, det vil sige håbløst forældet. Selvom AMD/TSMC kører med klatten sammenlignet med Intel, leverer de kun forbedringer på måske 10-15% per år, langt fra hvad vi har været vant til. Som Torben nævner sker noget af udviklingen dog også ved at der kommer flere cores, men det kan slet ikke hamle op med fortidens hastighed. Dels er det langtfra i alle workloads (og slet ikke desktop) der har glæde af flere cores, dels er selv denne udvikling langsom. Det er 10 år siden der kom mainstream processorer med 4 kerner. I dag er 8 måske normen i samme prisklasse, hvis overhovedet det.
Fremtiden er at automatisk parallelisere tasks, således at programmørerne ikke bruger tid på at parallelisere.
En mellemting er VLIW. Dette er utroligt nemt at håndtere, og det er meget nemt at lave computere, der tager et traditionelt instruktionssæt og in-time oversætter til et andet VLIW instruktionssæt. Branch instruktioner på en VLIW computer, vil normalt have en eller to VLIW instruktioner som parameter, der virker som jump tilpasning. Det ligner lidt delayed jump, men instruktionerne i delayed feltet udføres kun ved jump. Fidusen er, at man derved har mulighed for at tilpasse koden, til hoppet. Ved VLIW udføres mange instruktioner samtidigt, og et hop vil normalt ske ind midt i en VLIW instruktion. Derfor er nødvendigt med et jump tilpasnings blok. Denne laves f.eks. som en eller to instruktioner efter branch, og udføres kun i tilfælde af hoppet. I nogle tilfælde, sætter man et flag på, så man kan bestemme om de pågældende instruktioner skal udføres, eller skippes, afhængigt af flaget som der hoppes på. Ved at anvende en tilpasningsblok er muligt, at tilpasse koden, til at hoppe ind midt i en VLIW blok.
Selve VLIW computere, laves ved at man anveder særlige CPU'er, der arbejder med 3 tilstande: Høj, Lav, og nulstillet (intet). Man starter med at nulstille ALU'en, således der ikke kommer data ud. Når der udføres et antal instruktioner, så er også muligt med afhængigheder mellem disse. For hver instruktion, kan de tages som output fra de forrige. Det er derfor ikke et problem med afhængigheder mellem instruktioner. ALU blokken starter med at resettes, og efterhånden som de enkelte bits svarer høj eller lav, så kendes resultatet. Når alle bits har svaret, så har man svaret på den samlede blok. Det som er fidusen er, at delay er væsentligt mindre, end når der laves analyser af afhængighederne på blok niveau. Bit dybden af afhængigheder er ofte mindre.Forestiller vi os eksmpelvis at vi laver en or med 0FFH, eller and med 0H, så vil det på blok give anledning til en forsinkelse, mens det på bit niveau, ikke giver forsinkelse. Ser man på bit forsinkelsen ved flere instruktioner udført efter hinanden, så er den væsentligt mindre, end den forsinkelse som svarer til antallet af blokke der afhænger af hinandens data.
Desværre tager det lidt tid at nulstille en ALU. Men, det er ikke slemt - for vi anvender som regel mindst to ALU'er på skift, så den ene nulstiller, mens de andre arbejder. Som regel har vi flere på skift, og er er altid to aktive samtidigt, så data fra en ALU går videre til den næste direkte uden forsinkelse. Det svarer til, at vi har en latch imellem, der er transparrent. Udføres på skift tre instruktioner, så vil en ALU i 1/3 af tiden nulstilles, i 1/3 af tiden direkte forbindes til den forrige alu, og få data fra den, og i 1/3 af tiden levere data til den efterfølgende ALU, når dataene ankommer. Der kan også bruges flere ALU'er der skiftes til at arbejde. Derfor betyder intet, at det tager tid at nulstille ALU'erne, da andre ALU'er udfører de pågældende instruktioner i stedet. Vi kan sammenligne det lidt med skifteholdsarbejde, hvor at man skftes til at slappe af. Sammenlignes med et skifteholdsarbejde, så kan vi sige at man er på arbejde i 16 timer, og slapper af i 8 timer. De første 8 timer man er på arbejde, er man på job sammen med det forrige hold, som stadigt arbejder på informationerne, og man får dem direkte fra dem, så snart de er færdige uden at skulle vente på klok signaler. I den anden halvdel af tiden man er på arbejde, går det første hold hjem, og det efterfølgende hold kommer, og her leverer man data direkte til dem, når man er færdige med dem. Og efter 16 timer slapper man af, og "oplader" til næste dags arbejde. Instruktionerne flyder af sted, og det kan gøres uden anden klok, end ved at se på hvornår data er færdige. Som regel er dog nødvendigt, at også tage hensyn til hukommelsens hastighed, og hvis de arbejder synkront, så kan være en klok til hukommelsen, og når der hentes data fra hukommelse, så må synkroniseres med den. Som regel vil man dog have en cache foran, så at hukommelsesadgang ikke tager stor tid, og synkroniseringen kan være efter cache.
Når man laver VLIW koden, så er den simpleste måde, at man forwarder i software. Det kan også gøres i hardware. Ved forward menes her, at man opsætter en indgang på en ALU til den VLIW udgang, som data kommer fra. ALU'erne minder mere om FPGA'er, fordi at det er et netværk hvor de er trådet til hinanden, og vi ved programmeringen styrer dette netværk.
Har vi f.eks. noget intel kode, så laver vi vores CPU så den er egnet til at simulere det - og for den sags skyld også simulere alle andre CPU'er.
Det er vigtigt, at tænke på MMU problematikken, og ikke mindst er nødvendigt med en kopimaskine i MMU'en. Det kan vises, at netop det at kopiere data hurtigt, bedst klares af en on-chip kopimaskine. On-chip kopimaskinen virker ved assoicering, så der er som regel ikke fysiske data de flyttes - heller ikke på harddisken. Kun små datablokke flyttes, for at reducere kopibeskrivelsestabellers størrelse.
Vi har normalt aldrig ram lager, men kun cache, til en harddisk. Det betyder, at hele harddisken virker memory mapped, bortset fra, at der kun er adgang til åbne filer af hensyn til sikkerhed, og at ikke spilde addresseringsplads. I princippet er ingen grænser for størrelse på harddisken, og det har vi ofte på vores pointere, derfor kan vi ikke have alle filer i verden åben samtidgt.
Når vi har brug for ram plads, så åbner vi en fil på harddisken og bruger den til at læse og skrive.
Harddiskens måde at gemme data på, er lavet så den også indeholder strukturer der holder øje med kopiering af data. Og kopierer vi data på harddisken, så tager det ikke plads, fordi at den arbejder sammen med chippens MMU's kopimaskine. Der er ingen forskel på harddisk og ram, og kopimaskinen er derfor reelt en harddisk kopimaskine. Der gemmes data på harddisken, der husker kopieringen, da store mængde data normalt ikke fysisk kopieres. Der er ingen grund til at fysisk kopiere data.
Ovenstående er et eksempel, på en meget lille maskine, der dog kan udføre instruktioner utroligt hurtigt, også selvom der er dataafhængigheder.
Da at softwaren kun emulerer andre CPU'ers instruktionssæt, så kan vi i emulatoren bygge matematik ind, der restrukturerer koden, således at afhængighederne reduceres.
Vi kan også tage skridtet fuldt ud, og forsøge at lave noget der helt parallelisere softwaren. Dette er dog svært.
Så alt i alt - instruktionssæt betyder ikke noget. Det er mere vigtigt, at have en hardwarekopimaskine på chippen, end at bruge chip areal på at få indstruktionssæts til at passe. Hardware kopimaskinen gør, at det hverken tager tid at kopiere data på harddisk, eller fra harddisk til computerens lager. Så snart at instruktionen er udført, så er data kopieret, men det kan måske tage lidt tid inden de er læst ind i cachen - her er det også vigtigt, at man har noget logik, der forudser hvilke data der er hensigtsmæssigt at læse ind i cachen på forhånd.
Normalt har man en ram-cache på mange gigabytes, så selvom at alt er data på harddisken, så er det ligeså hurtigt, som at udføre data i ram - endda hurtigere, da det er hurtigere at hente data fra harddisk til ram. Det tager meget lang tid på almindelige PC'er, fordi at data først hentes fra harddisk til ram, og her swappes de tilbage til harddisken, og så hentes de igen ind i ram inden de bruges. Der bruges masser af tid på disse undøvendige kopieringer, specielt når der ikke er en hardware kopimaskine der håndterer det.
Normalt har man en ram-cache på mange gigabytes, så selvom at alt er data på harddisken, så er det ligeså hurtigt, som at udføre data i ram - endda hurtigere, da det er hurtigere at hente data fra harddisk til ram. Det tager meget lang tid på almindelige PC'er, fordi at data først hentes fra harddisk til ram, og her swappes de tilbage til harddisken, og så hentes de igen ind i ram inden de bruges. Der bruges masser af tid på disse undøvendige kopieringer, specielt når der ikke er en hardware kopimaskine der håndterer det.
Måske skal jeg lige nævne, at en hardwarekopimaskine ikke er det som de fleste forstår ved DMA. DMA'en er nok nærmere en cover-up, for at skjule idéen om hardwarekopimaskiner.
En kopimaskine i hardware kopierer ikke reelt data, men de bliver liggende på deres plads. Ofte laves det både i hardware og software kombineret, afhængigt af hvilket lag at kopimaskinen er. Fordelen ved at anbringe den i hardware, er at det kan gøres så det ikke tager tid - den kan pipelines, og det er muligt at håndtere et nærmest uendeligt antal kopierede områder samtidigt, uden det reducerer ydelsen. Med en hardwarekopimaskine tager f.eks. kopiering af blok, både med rep mov og med DMA, kun en enkelt cycle, hvis det tager tid. Det udføres jo reelt parallelt med koden, så det tager ikke tid. Problemet er, at det i software er relativ kompleks, men når man kommer til de sløve niveauer, hvor det gemmes på harddisk, så vil det ofte være kode implementeret, enten i CPU'en, eller i en special CPU til harddisken. Kopierede data fylder ikke på harddisken, når de laves med rep mov, DMA, eller harddisk kopiering.
Fremtiden er at automatisk parallelisere tasks, således at programmørerne ikke bruger tid på at parallelisere.
Det har folk talt om lige siden STRETCH og der er i realiteten absolut intet sket i den forbindelse.
Det nærmeste vi nogensinde kom, forudsatte en computerarkitetktur der imellemtiden er gået i glemmebogen (Transputeren).
VLIW har været prøvet før flere gange. Både af Intel (Itanium) og andre (Transmets Crusoe, og andre). I første tilfælde var der tale om et forsøg med en ny arkitektur, i andet tilfælde dynamisk oversættelse og optimering til VLIW. Ingen af forsøgene var ret overbevisende og ydelsen kunne ikke hamle op med alm x86. Bl.a. er det et problem at kompilere til VLIW og desuden giver de lange instruktionsord også ulemper. Unasrt hvad er det den samme parallelisme der er i spil som ved moderne CPUer med out-of-order execution som jo også kan drage fordel af dynamisk information tilgængelig på runtime.
lyder som data dedublikering. min holdning er det er på app og brugerniveau man skla undgå unødvendige kopieringer. Fx symbolske links i stedet for en kopiering af en fil. Og mit indtryl er da heller ikke der er mange overflødige kopieringer. men noget skal jo kopieres. Fx fra disk til RAM. Det skal jo op til et sted hvor CPUen hsr hurtig adgsng og der er ikke plads til alt hele tiden. Alle lagre i maskinen kan ses som forskellige dele af er cache hierarki og kna ikke se hvordan kopiering på tværs kan undgås.
Har været prøvet... VLIW har været prøvet før flere gange. Både af Intel (Itanium) og andre (Transmets Crusoe, og andre). I første tilfælde var der tale om et forsøg med en ny arkitektur, i andet tilfælde dynamisk oversættelse og optimering til VLIW. Ingen af forsøgene var ret overbevisende og ydelsen kunne ikke hamle op med alm x86. Bl.a. er det et problem at kompilere til VLIW og desuden giver de lange instruktionsord også ulemper. Unasrt hvad er det den samme parallelisme der er i spil som ved moderne CPUer med out-of-order execution som jo også kan drage fordel af dynamisk information tilgængelig på runtime.
Der er så meget der har været prøvet før - de fleste forsøg med henblik på det ikke fungere. Indbyggede kopimaskiner har været prøvet før - DMA - forkert lavet, og totalt misforstået at det hjælper på ydelsen. Et cover-up forsøg, der skal vise at den måde som man gør det på når det gøres korrekt, er forkert. VLIW - også gjort forkert. Dem der har gjort det, vidste ikke hvad de lavede, og hvad formålet var. Parallelisering - jo, det er også totalt misforstået. Det er helt ufatteligt, hvad man laver af demmonstrationer, for at bevise at de metoder som fungerer og er gode ikke virker. Alt sammen, forsøg på at hemmeligholde teknologier der fungerer godt.
Jeg beskrev hvordan VLIW skal gøres. Du anvender ALU'er, hvor mange indstruktioner sendes til på en gang - og de klarer også afhængigheder mellem instruktionerne. Du kan f.eks. bruge et register og lægge et tal til, og anvende registeret i næste VLIW instruktion i samme instruktionsord. Der er et felt, der angiver om du vil hente data fra registersæt eller fra tidligere instruktioner bagud. I nogle tilfælde regner man det ud automatisk, hvilke tidligere instruktioner output skal tages fra, ved at sammenligne registre der anvendes. Denne metode forhindrer også hazard, når alle instruktioner anvender samme registersæt. Det svarer til forwarding. Forwarding forhindrer også hazard, fordi du når du læser fra et register, læser fra de forwardede registre, og ikke fra lageret, og derfor er der afstand mellem læsning og skrivning til samme celle. Det samme gælder VLIW. Der opnås ikke hazard. Samtidigt så giver forwardingen ikke anledning til væsentlig forsinkelse. Instruktionerne kan udføres næsten ligeså hurtigt, trods det er afhængigheder, fordi det er på bit niveau, og ikke blok niveau.
DMA - totalt forkert måde at lave en kopimaskine på. Man laver kopimaskinen i CPU'er uden at flytte data.
Og i mange år, har man forsøgt at latterliggøre computere, der var uden ram, og kørte direkte på harddisken. Alle vidste det var muligt. Bill-gate nægtede det kunne gøres.
Og parallelisering - ja, det problem, har man bare ikke gidet at gøre godt. Det som alle kender som parallelt, og parallel programmering er en stor misforståelse. Det er læren om parallel programmering, der ikke fungerer.
Det hele er et cover-up.
Også mores lov - læren om, hvad folket må vide er muligt. Alt sammen fra en tid, hvor det man skulle var, at sætte grænser for, hvad vi må kunne, hvad vi må vide, og hvad vi må tro er muligt, og hvor uddannelsens væsentligste opgaver, er at uddanne eksperter, der formår at begrænse deres kunnen.
Mill har et helt andet bud på hvordan man får reel single-thread performance ud af moderne transistorbudgetter.
Jeg tør ikke begive mig ud i at beskrive arkitekturen her, men der er mere information på https://millcomputing.com/ og på nyhedsgruppen comp.arch fra tid til anden.
En af udfordringerne er at arkitekturen ligger meget langt væk fra det man kender. Den kan helt fundamentalt ikke køre alm. Unix eller Windows, for den har ikke traditionel virtuel hukommelse. Dvs. udover at Mill skal udvikle selve CPU'en og en (ret drastisk anderledes) compiler-backend, så skal de også opfinde et operativsystem.
Til gengæld er der ikke nogen "spekulation" i arkitekturen, og det har indtil nu gjort den immun mod Meltdown og Spectre og alle de andre moderne CPU-angreb.
Potentialet er der til i al fald en fordobling af single-thread integer performance ift. markedets bedste, og teoretisk set meget mere. Om det så nogensinde bliver til et rigtigt produkt, det er jeg noget i tvivl om.
Jeg har også læst lidt om Mill computing for lang tid sidne. Det at der er gået så lang tid tyder ikke for godt. Mit umiddelbare take er, at det blot er en ny udgave af VLIW. Det er også til at få øje på ulemperne (kæmpe instruktionsord). Og igen, det handler om at den udnytter parallellisme indenfor en enkelt tråd, og det er moderne out-of-order CPU'er ret gode til og kan have hundredevis af instruktioner in-flight. Kan Mill gører det bedre? Jeg ville højst forvente den måske kunne gøre det med lavere strømforbrug, men ikke nødvendigvis højere ydelse absolut.
Det er kun ved at realisere designet, at det er muligt at se om fordelene opvejer ulemperne.
Mht. at den ikke kan køre Unix og Windows pga. mangel på virtuel memory, så vil det være et enormt handicap. Virtuel memory har jo også en funktion så et evt. replacement operatingsystem skal jo så løse det på andre måder. Det undrer mig dog også det skulle være tilfælde - virtuel memory kommer jo kun i spil ved tilgant til lageret. I en del arkitekturer har det endda være implementeret på en separat chip, helt separat fra den primære CPU. Så det ville være mærkeligt Mill ikke kunne understøtte det. Eneste forklaring jeg kan komme på er hvis penalty'en for Mill er højere ved et TLB-miss, hvis hele instruktionsordet så skal afvente blot fordi én delinstruktion forårsager TLB-miss. Men det er jo så en ulempe ved hele Mill-idéen, at det er laveste fællesnævner der sætter takten. I mange workloads er TLB-miss dog neglicerbart, så det ville stadig undre mig det var et problem.
Jeg har også læst lidt om Mill computing for lang tid sidne. Det at der er gået så lang tid tyder ikke for godt. Mit umiddelbare take er, at det blot er en ny udgave af VLIW. Det er også til at få øje på ulemperne (kæmpe instruktionsord). Og igen, det handler om at den udnytter parallellisme indenfor en enkelt tråd, og det er moderne out-of-order CPU'er ret gode til og kan have hundredevis af instruktioner in-flight. Kan Mill gører det bedre? Jeg ville højst forvente den måske kunne gøre det med lavere strømforbrug, men ikke nødvendigvis højere ydelse absolut.
Her er du inde på noget af det rigtige. Vi kan opdele parallelisme problemer i to typer - der er den, hvor de parallele processor kører helt adskildt af hinanden, med sin egen hastighed, og så er der den type parallelisme, hvor at de paralllele processer er stærkt knyttet sammen, og udfører instruktionerne i samme hastighed, eventuelt samtidigt. Når vi har en dataflow graf, så er en af opgaverne at analysere dette, og dele de parallele processer op i de to typer. Dem, der kører uafhængigt, skal have deres egen CPU kerne. Og dem, der kører afhængigt, kører faktisk bedst på en VLIW akitektur. Dette er en meget svær analyse - og den simple måde som jeg beskrev tidligere, er ikke i stand til dette. Det er faktisk - hvis man skal være ærlig - nemmere at gøre i en compiler, end i in-time oversætteren. Dog kan det gøres. Den parallelisme der sker synkront, er som du skriver kun indenfor en enkelt tråd. I nogle tilfælde kan man ændre på programmet automatisk, og øge antallet af paralle processer, men dette er altså svært. Dog, er det netop det, som jeg har skrevet mest om tidligere - men, når det drejer sig om CPU'en, så er det ikke særligt relevant. Det relevante er at forstå, at dataflow grafer/programmer, altid ender op i disse to typer af parallelisme. Og, derfor er problemet med at kunne parallelisere en enkelt tråd, hvor task'ene sker synkront, og styres af sin egen kode, også utroligt vigtigt. Vi kan simpelthen ikke undgå at en del af koden fungerer sådan. Derfor, er VLIW vigtigt. Men, det er også vigtigt at forstå, at det er vigtigt med en stærk tilknytning mellem ALU¨'erne, og ikke mindst, at vi skal kunne forwarde dataene hurtigt imellem dem. Det gør nemligt, at VLIW instruktionerne ikke behøver at være parallele - de kan også være sekventielle, og tage data fra hinanden. Dette sløver naturligvis den tid ned, som det tager at udføre en VLIW instruktion. Udføres 128 instruktioner i et huk, så er den typiske dybde af afhængigheder kun 8 - og vi kan reducere den, ved at ordne vores instruktioner først.
Med den akitektur som jeg beskriver, der laver vi vores CPU så den nemt kan emulere andre CPU'er. Vi laver den også med memory mangement, og ikke mindst mulighed for at kopiere store mængder data hurtigt. Det er ikke noget problem.
Selve det at lave VLIW programmet gøres af in-time oversætteren. Den virker ved at den har flere addresse områder - der er en med de oprindelige data og kode, hvor at koden læses fra, når den skal oversættes. Der er et område, der addressemæssigt er som på vores emulerede computer, men instruktionerne er jump og restart/call instruktioner, der udfører compileren, når der mødes en instruktion der ikke er oversat. Og så er der et hukommelsesområde, med vores oversatte kode. Alle hukommelsesområderne er del af harddisken, så når først et program en gang er kørt, så husker den oversættelsen til næste gang den udføres, med mindre det er meget lang tid siden, og at harddisken har overskrevet det (det er reelt konfigureret som lavere kvalitet af data på harddisken, altså cache, der kan tages i brug til andre ting, hvis det er lang tid siden det er brugt. På harddisken har man forskellige kvaliteter af data, f.eks. til cache, og til ting der altid nulstilles/fjernes efter computeren nulstilles. Når computeren starter op, så indeholder addresseområdet der svarer til den simulerede computer kun single-byte call instruktioner til compileren. Det første, når et program kører, er at der udføres en call til oversætteren og programmet oversættes i et stykke fra den pågældende addresse. Størrelsen af dette stykke, svarer til antallet af sammenhængende instruktioner, indtil næste programudfletning. Det vil sige, fra branch til branch, eller til andre typer der ændrer addressen, afhængigt af en betingelse, f.eks. et register - jump register, og return, afslutter således også det pågældende bid. Jeg plejer at kalde sådan et stykke, for en godbid. Compileren kan nu overskue parallelismen indenfor sådan et godbid, og arrangere instruktionerne effektivt i VLIW format, og tage hensyn til dybden, og reducere den så meget som muligt, så at VLIW instruktionen får så få afhængigheder som muligt, og derfor udføres så hurtigt som muligt. Selvom der er afhængigheder, så går det dog hurtigt, fordi de er på bit-niveau, og ikke blok-niveau, og trods der er 128 afhængigheder med 128 ALU'er (hvilket sjælden sker i praksis), så er den typiske afhængighed på bit-niveau kun 7-8. Når et godbid er oversat, så udføres det, og programmet havner i noget kode igen, som ikke er oversat, og hvor at compileren kaldes. Og så oversættes næste kode.Når først en del af programmet er oversat, så oversættes den ikke igen, fordi at den hukommelse med call instruktionerne til compileren, erstattes med jump instruktioner til den oversatte kode. Selvom ovenstående lyder ekstremt simpelt, så er det lidt svært - for vi har også jmp reg, og push reg efterfulgt af return, samt load sp, som vi skal håndtere. Men, det er muligt. Og så er der også selvmodificerende kode. Gemmer vi data i et kodeområde, hvor koden er oversat, så skal vi gå ind og markere denne oversatte kode som ugyldig, således at den pågældende oversatte blok ikke mere anvendes, og bliver genoversat næste gang den udføres. Inden man går i gang med at udvikle en CPU, så er det en god idé, at starte med at sætte sig ind i hvordan man laver sådan en in-time compiler der kan emulere andre processorer, og akitekturer. De features, som vi opdager vi får brug for, viser sig ofte at være features der er universielle...
Vi har så vores VLIW ALU. Denne ALU er lavet til, at udføre stærkt knyttede parallele processer, og at være særlig hurtig, til at forwarde data imellem dem. Er der således afhængighed mellem to instruktioner, så er den utrolig hurtig, til at udføre de to instruktioner i et huk. I praksis, så består den af en række registre, der dog ikke er rigtige registre, men memory lokationer, der er placeret i registre. Vi har flere registersæt, der svarer til addresser i lageret/harddisken. Egentligt, er der ikke CPU registre. Alle registre er på harddisk,, men de er cached, så de er ligeså hurtige som rigtige registre. Vi kan forestille os det sådan, at selve VLIW alu'erne er i bunden, og over dem, er der en stor ram med parallel port adgang til alle registrene. Disse registre er placeret ude i siden. Selve registrene ude i siden, hentes ind fra lageret for hver instruktion. Og dette sker i flere memory banker. Som minimum har man 4 memory banker, men der er helst mindst 8. Det er effektivt, fordi vi arbejder direkte på hukommelsen, og vi skal ikke have overflødige load og move instruktioner, for at lave tåbelige flytninger. Samtidigt, er det ligeså hurtigt som registre, da det er registre vi skriver til, men vi udskifter bare alle i et huk, fra det som står i cache. Registrene kan også betragtes som en level-nul cache, der udskiftes for hver blok der udføres af instruktioner,f.eks. 128 instruktioner samtidigt. Man anvender en lidt speciel måde ved adgang til cachen - normalt, så slår vi op på en bestemt addresse. Her, har vi også en start addresse, og n addresser fremad. Det betyder, at vi helt frit kan styre vores start addresse. I praksis sker det ved, at vores cache er opdelt i lige og ulige words, hvor at words kan være mange bytes.Skal vi læse n bytes, der følger efter hinanden, og er første addresse i en lige word, så starter vi i den lige word, og fortsætter ind i den ulige word addresse. Starter vores addresse derimod i den ulige word addresse, så forstætter vi ind i den lige wordaddresse plus en. Altså, med andre ord, så læser vi altid to addresser samtidigt, der enten er addr, og addr, eller addr+1 og addr, afhængigt af om vores addr slår op i den lige eller ulige word addresse. Der kan så lægges shifters ind, så vi starter i den pågældende addresse, men det lader vi normalt vores VLIW compiler klare. Så undgås de. Men, alle lagerområder er delt i to, så de også kan starte i lige addresse +1 og ulige addresse. Dette gør, at vi arbejder over et hukommelsesområder, som vi kan skubbe i lageret. Alle registre er et vindue til harddisken, der kan flyttes.
Endeligt har vi vores memory manegement. Dette er ikke et problem. Den har også indbygget kopiering, og det betyder at kopiering af store mængde data er en O(1) operation, og ikke O(n) operation. Det viser sig, at denne opgave bedst klares med hjælp fra hardware. Ofte indeholder programmer mange af dataflytninger, og de er endda oftest overflødige. I stedet for at optimere dette, så er det nemmere at gøre flytningerne hurtigere. Da vi ikke har et rigtigt ram lager, men kun cache, så er vores flytninger altid fra harddisk til harddisk position, men det virker også som flytninger i ram, hvis vi åbner en fil vi kalder ram. Vi kan også kopiere til denne ram fil, uden det tager tid. Der kan flyttes et uendeligt antal data i kun en CPU-cycle. Men, ja så skulle det som sagt covers med DMA.
Ovenstående CPU akitektur, er også det underliggende, når vi har mange parallele processer der kører uafhængigt - men så er en fordel, at placere dem på forskellige kerner, da vi ikke har brug for så stærk knytning mellem dem. Her kører processerne med forskellige hastigheder, og nogle står måske stille, så det er ikke vigtigt, at de overlevere data så hurtigt mellem hinanden, som dem der kører synkront, og arbejder på samme datasæt. Derfor, er vores CPU lavet til, at håndtere begge typer af opgaver. Parallele, der deles ud på forskellige kerner, og parallele der kun er paralleliseringer af de enkelte tråde, og laves som VLIW.
Har vi en loop, så vil vores compiler folde den ud, så vi kan i en enkelt VLIW instruktion, godt udføre 128 gennemløb i en loop, hvis der er 128 ALU'er. Disse har måske afhængigheder, men hvis de kan lægges i en enkelt instruktion betyder det ikke noget. Afhængighederne på bit-niveau, er som nævnt ofte mindre. Og den stærke knytning gør også, at direkte trådning mellem ALU'erne, medfører en større hastighed på instruktioner der udføres med afhængigheder, end den der kan opnås, hvis der er en klokcycle mellem udførslen. Hvor hurtigt at hastigheden på instruktioner med afhængigheder er, afhænger ikke mere af den mulige klokfrekvens, men af den hastighed, som vores bølge bevæger sig igennem ALU'erne. Altså, den afhænger kun af komponenternes hastighed. Dette er vigtigt, fordi vi som jeg beskrev tidligere, har ALU'er der slapper af imellem hver instruktion, for at nulstille dem. CPU'ens hastighed er derfor relativ lav - men den ser høj ud. Vi behøver egentligt ikke at have en klok, for vi kan se hvornår at instruktionerne er færdigt udførte, og gå til næste cycle. Det betyder, at f.eks. en blok med instruktioner uden afhængigheder, går hurtigere end en med afhængigheder. Derfor er vigtigt, at vores compiler arbejder lidt med organiseringen, for at opnå stor hastighed. Det smarte - i forhold til Intels metode hvor at oversættelsen sker i hardware - er at vi kan have langt bedre og mere advancerede metoder, og at der ikke er stort strømforbrug. Oversættelsen huskes fra gang til gang, og tager reelt kun tid første gang et program udføres. I de fleste tilfælde, er den pågældende overhead ikke større, end når koden læses fra harddisken. Endeligt, så tager vi meget større godbidder af gangen, end Intel gør i deres hardware - vi tager i princippet fra branch til branch, eller til andre instruktioner der ligner branch. Jump ændrer ikke programflowet, så de tager ikke tid. De fjernes bare.
Ved ikke om jeg har forklaret det godt nok. Men, min holdning er, at alle de CPU akitekturer vi får kastet i hovedet, og også en god del af den undervisning vi får, er med henblik på "cover-up", og at disinformere os om, hvordan opgaven løses. Og det er IKKE kun indenfor CPU akitekturer. Det er måden man styrer hvad vi skal vide indenfor naturvidenskab. Og, måske er det ikke tosset. Der er ting, som det er fornuftigt at ikke vide.
Har set ganske lidt på mill akitekturen, og det ser ud til, at de har fat i noget af det rigtige. Jeg har dog ikke læst så meget, at jeg kan se om de har gjort det korrekt. Det, som jeg beskriver er hvordan man også laver en processor, der kan køre med almindelige instruktionssæt, væsentligt hurtigere end normale CPU'er.
Selve det, at lave asynkrone VLIW processorer, altså processorer hvor at den tid der tager at udfører VLIW instruktionsordet afhænger af tiden som operationen faktisk tager på bitniveauet er ikke nyt. Vi lærte om det på uddannelsen for ca. 25 år siden. Jeg regnede på det for mange år siden, og kom til at instruktioner der blev udført i rækkefølge, kunne udføres ligeså hurtigt som cirka den dobbelte forsinkelse af en inverter. Jeg havde faktisk en artikel dengang om det på nettet. Det svarer altså til, at indstruktioner med afhængigheder kan udføres med mange gigahertz. Samtidigt, så er det kun forsikelsen der betyder noget - ikke den fysiske klok frekvens. Mit eksempel, var med en række VLIW moduler, med afhængigheder mellem instruktionerne, der var arrangeret i blokke, så forskellige CPU blokke blev udført på skift, og at data således flød konstant, og CPU'en blev automatisk klokket, når at en blok var udført. Så det er meget nemt - find ud af hvor stor at forsinkelsen er for et par invertere. Det er den tid, at en instruktion må tage, hvis der er afhængigheder. Er der ingen afhængigheder, nop instruktioner, jump instruktioner osv. så er det ikke problemer. Branch instruktioner kan give problemer, hvis de er i den retning, de ikke normalt udføres. Men i f.eks løkke tilfældet, tager branch aldrig tid. Løkker udfoldes, så selve branch'en ikke tager tid.
Så er det så bare lige at bygge intel/arm kompatibilitet på, og forsyne med en indbygget kopimaskine, og at sikre sig at alle registre er på harddisk. Det eneste som ikke har en harddisk allokering, er forwardingen der tages fra de forrige alu'er. I min artikel, tilførte jeg en fifo, så det var muligt at hente data også fra forrige udførte instruktioner.
men det er bekymrende i yderste potens når monopolet ligger i Kina.
God pointe. Jeg har en fornemmelse af at der er nogle steder (men måske specielt Kina) hvor nationalpolitiske interesser kommer først og videnskab senere, og hvor det ville være mere sandsynligt at man eksempelvis holder inde med eksport af produkter/viden.
Den kolde cyber-krig?
Re: Ethvert monopol er bekymrende God pointe. Jeg har en fornemmelse af at der er nogle steder (men måske specielt Kina) hvor nationalpolitiske interesser kommer først og videnskab senere, og hvor det ville være mere sandsynligt at man eksempelvis holder inde med eksport af produkter/viden.
Den kolde cyber-krig?
Hvad skyldes amerikanernes dominans, indenfor processorudviklingen? Er det evner? Eller bruger de taktik?
lyder som data dedublikering. min holdning er det er på app og brugerniveau man skla undgå unødvendige kopieringer. Fx symbolske links i stedet for en kopiering af en fil. Og mit indtryl er da heller ikke der er mange overflødige kopieringer. men noget skal jo kopieres. Fx fra disk til RAM. Det skal jo op til et sted hvor CPUen hsr hurtig adgsng og der er ikke plads til alt hele tiden. Alle lagre i maskinen kan ses som forskellige dele af er cache hierarki og kna ikke se hvordan kopiering på tværs kan undgås.
Nej, kopiering må ikke tage tid. Så enkelt er det. Du kan ikke på nogen måder kode dig ud af det. Hardwaren håndterer det, og holder styr på, hvor at de kopierede data skal hentes fra. Ellers udsætter du programmørerne for bunker af overvejelser og opgaver, de i sidste ende alligevel ikke kan løse fornuftigt. Forestil dig, at en bruger kopierer data på harddisken. Må det tage tid? Nej, det må det ikke. Og præcist det samme gælder med de indbyggede kopieringsfeatures, som f.eks. REP MOVSW, og lign. Og kopieringer via DMA. Antag som eksempel, at du kopierer en stor blok. Det kan du klare i software ved hjælp af referencer. Nu ændrer du en byte, i den kopierede blok. Det er enkelt for hardware. Resultatet er, at programmørerne ikke kan. Og det giver ingen mening at de gør det. Har man brug for at kopiere data, så kopiere man bare hele blokken. Det tager ikke tid, og koster ikke plads. Ændres en byte, holder hardwaren styr på det, og det samme hvis der ændres flere bytes, både samlet eller flere steder. Hardwaren ryder også automatisk op i beskrivelserne af de kopierede data, men i det store hele betaler det sig ikke at ryde op. Man foretrækker, da data så vidt muligt står som kopieret, hvor det er muligt. Ryder man op, så kopierer man de blokke først, hvor det er færrest data som skal kopieres. Som regel, så vil kopiering af få data altid kopieres direkte, fordi det optager mindre plads, end kopibeskrivelsen. Det kan skrives i kopibeskrivelsen først, og de datamængder der er små, kan så kopieres når der er tid.
Når du har kopimaskinen indbygget i hardware, så kan du f.eks. indsætte en byte midt i en text fil på harddisken. Du kopierer bare filen, og indsætter en byte. Det koster ikke tid. Hardwaren holder styr på det, når den læser dataene ind mellem cachelagene. Og dens maskine håndterer også en fysisk kopiering i den inderste cache, eller laver en cache miss, så data hentes ind igen korrekt.
Re: Mht. Moore... lyder som data dedublikering. min holdning er det er på app og brugerniveau man skla undgå unødvendige kopieringer. Fx symbolske links i stedet for en kopiering af en fil. Og mit indtryl er da heller ikke der er mange overflødige kopieringer. men noget skal jo kopieres. Fx fra disk til RAM. Det skal jo op til et sted hvor CPUen hsr hurtig adgsng og der er ikke plads til alt hele tiden. Alle lagre i maskinen kan ses som forskellige dele af er cache hierarki og kna ikke se hvordan kopiering på tværs kan undgås.
Når kopieringen sker i hardwaren, står dataene som kopieret. Der sker ingen fysisk kopiering. Men dataene ser ud til at være kopieret fra softwarens side. Hardwaren kan også håndtere at tage nettet med, så du i princippet kan kopiere en side fra netværket til harddisken uden det tager tid i software. Dataene hentes så ind, når de bruges, så at harddisken fungerer som cache. Har computeren (harddisken) ledigt tid, kan den også hente dataene ind på harddisken før data bruges. En af fordelene er, at vi i kopibeskrivelserne der står på harddisken i princippet også kan skrive ophav. Laver du f.eks. cut/paste af data som du finder på nettet, og tager fra en browser, så kan det stå i kopibeskrivelsen, hvor at datas ophav er. Det behøver ikke at være en del af softwaren - faktisk vil(skal?) softwarefolkene helst ikke vide det... Det har specielt betydning indenfor sikker programmering, hvor vi sætter krav til, at man ikke må anvende kode, som er skrevet af ikke godkendte personer. Ved sikker programmering, er strenge krav til, at programmørerne skal kunne godkendes, og der er også krav til, hvilke personer de må kende, om de må møde hinanden, og om programmørene må kende hinanden, og have kendskab til hinandens eksistens. Der sættes ofte krav til matematisk uafhængighed mellem koderne (og derfor også programmørerne) ved sikker programmering.
En af fordelene ved at kopiere i hardware, er at det for det første er nemt, at programmørerne kan finde ud af det, du kan meget nemt ændre i kopierede data uden det tager tid, og du har ikke et mareridt af problemer at overveje. Vil du indsætte en byte, så fylder det et par pladser i kopibeskrivelsen, at du har to blokke, og en eller flere bytes som er lagt ind.
Når man designer computere, og programmeringssprog, så er det også væsentligt at udvikle teknologien, så at det ikke bliver enormt kompliceret for programmørerne at lave kode til simple ting - det er spild af folks tid. Vi vil gerne spilde konkurenternes tid. Men ikke vores egnes. Så det deler hardwaren og programmeringssprogen op i to - dem, der er for alle, om dem der kun er for vores, og som ikke er designet til "spise hjerner", ved at overdynge programmører og andre med nyopfundne metoder, der gør det hele mere vanskeligt.
Præcis hvorledes ville det være bedre hvis monopolet lå i USA, EU, Rusland eller Israel ?
I en situationen hvor regeringer har en klar indflydelse på branchen vil jeg trods helst have monopolet i et land hvor regeringen kan skiftes ud. Her er Rusland og Kina trods alt værre end alternativerne du nævner.
Men egentlig så jeg helst at regeringerne brugte deres mandat til at opbryde monopoler, regulere markeds dominans og forhindre karteldannelse. Det er jo ikke fordi vi mangler lovgivning på området og IT branchen har en lang plettet historie, hvor dette ikke er undgået. Det er ikke fordi magt monopolet slet ikke har forsøgt, men resultatet er jo bare ikke særligt tilfredsstillende (for mit vedkommende).
Jeg har også læst lidt om Mill computing for lang tid sidne. Det at der er gået så lang tid tyder ikke for godt. Mit umiddelbare take er, at det blot er en ny udgave af VLIW. Det er også til at få øje på ulemperne (kæmpe instruktionsord). Og igen, det handler om at den udnytter parallellisme indenfor en enkelt tråd, og det er moderne out-of-order CPU'er ret gode til og kan have hundredevis af instruktioner in-flight. Kan Mill gører det bedre? Jeg ville højst forvente den måske kunne gøre det med lavere strømforbrug, men ikke nødvendigvis højere ydelse absolut.
Mill er meget langt fra en ny udgave a VLIW. F.eks. lider Mill ikke af at skulle encode en masse NOP'er hvis man tilfældigvis ikke kan fylde et VLIW ud med brugbare instruktioner.
Moderne CPU'er har en effektiv IPC på omkring 3. Drømmen med Mill er at komme langt højere op. Helst op til mindst 10.
Det kan den sandsynligvis bedst på loops. Meningen er at den skal kunne køre mange iterationer af et loop parallelt, uden at compileren skal have besværet med at gøre det manuelt, og uden den pris i cache og loop-opsætning som loop-unrolling koster på traditionelle CPU'er.
Men om det virker i praksis, det ved vi først lidt om når der engang kommer mindst en emulator.
Mill er meget langt fra en ny udgave a VLIW. F.eks. lider Mill ikke af at skulle encode en masse NOP'er hvis man tilfældigvis ikke kan fylde et VLIW ud med brugbare instruktioner.
Så vidt jeg kan se ligner mill meget den arkitektur jeg beskrev på min hjemmeside for ca. 25 år siden. Og det er helt korrekt, at en NOP instruktion ikke har afhængigheder og derfor ikke tager tid. Dog, så kan den godt optage plads, og det betyder at du måske kunne udføre en anden instruktion i stedet, så det gik lidt hurtigere. Derfor er bedst - som jeg tidligere har skrevet - at analysere koden inden den lægges ind i cachen, så at NOP som eksempel fjernes. Det er ikke kun NOP som ikke tager tid. F.eks. tager jump heller ikke tid. Og branch tager kun tid, hvis den skifter retning til en uforudset.
Jeg ansøgte dengang om at få lov at udvikle processoren, men fik afslag med følgende begrundelser: 1. Din arkitektur indeholder intet nyt. VLIW er prøvet før. 2. Processoren er ikke det kritiske i en computer. 3. Et projekt er ikke noget du skal tilbyde, men noget du skal tilbydes. Jeg skulle ikke komme med et projekt, det var lærene som skulle komme med projekt til mig. Ellers kunne jeg jo have lavet projektet på forhånd, og så kunne man ikke give karakter.
Det kan den sandsynligvis bedst på loops. Meningen er at den skal kunne køre mange iterationer af et loop parallelt, uden at compileren skal have besværet med at gøre det manuelt, og uden den pris i cache og loop-opsætning som loop-unrolling koster på traditionelle CPU'er.
Hvis den er lavet som min, så er der en slags loop-unrolling inden den lægges ind i cachen. Altså, en løkke foldes ud, og de instruktioner der er der, lægges samlet i et stort VLIW ord. Mine jumps havde et jump felt, hvor de udrullede instruktioner var lagt ind. Min krævede ikke loops, og kunne køre ligeså effektivt i rækkefølge. Men, hvis man f.eks. arbejdede med hukommelsen, så var den pågældende del af hukommelsen, lagt ind som registre, der udgjorde et vindue til den pågældende del. Der kunne være flere vinduer samtidigt. Derudover, så var der mulighed for at hente data fra n instruktioner tilbage, der dels kom direkte fra forwardingen mellem VLIW instruktionerne, og derudover fra pipeliningen fra forrige VLIW instruktioner. Denne forwarding kunne eventuelt regnes ud automatisk, i enten hardware, i compileren, eller i lagene mellem cacherne. Den computer som jeg beskrev på internettet var en "neddroslet" version, der primært havde VLIW delen, pipelining, og var designet til algoritmer. Jeg syntes, at det at bygge MMU, cacher osv. vil blive en for stor opgave i et enkelt projekt. Jeg vil dengang hellere koncentrere mig om hastighed i forward mellem instruktionernes data, så at instruktioner med afhængigheder blev udført hurtigst muligt. Det var her jeg kom til, at to inverteres forsinkelse var tilstrækkeligt, til at udregne enhver instruktion, dog ikke mult/div ol.
Det var her jeg kom til, at to inverteres forsinkelse var tilstrækkeligt, til at udregne enhver instruktion, dog ikke mult/div ol.
Det skal her nævnes, at det var worst-case, og kun ved afhængigheder. En anden fordel, var som jeg tidligere har nævnt, at den blokmæssige dybde er en anden end den bit-mæssige dybde, og det betyder, at selvom man tror at der er 8 instruktioner der bruger data fra hinanden, så kan dybden være mindre.
Min processor anvendte teknologi fra asynkrone processorer med VLIW instruktionssæt, og forwarding mellem VLIW instruktionerne. Denne forwarding var lavet så at hver ALU havde en anden foretrukken ALU at forwarde til, så instruktioner der afhang af hinanden, blev placeret på de positioner, hvor at afstanden var hurtigst.
Jeg har endnu ikke haft tid til at læse om mill computeren, så jeg kan ikke vurdere den. Min anvendte ikke carry-lookahead teknologi, fordi jeg kom til, at det sløvede den ned. Det var hurtigere, at lade der være en lille delay imellem de enkelte bits, end at anvende carry-lookahead. Jeg er dog i tvivl, om det kunne optimeres så det var hurtigt nok, og overvejede andre former for lookahead, men kom til, at man kunne ordne instruktionerne i software i stedet, og opnå et mere effektivt hardware design (mindre plads, mindre strømforbrug).
