Den gratis kopiering sammen med beskyttelse af data, overtager i øvrigt funktionerne for en sædvanlig MMU. Den fleste MMU'er er blokorienterede, skrædersyede til en bestemt CPU, fungerer ikke genneralt med programmeringsprog som f.eks. C++, og de er ikke kompatible med andre typer, der er lavet på en anden måde. Ved at bruge kopieringsmaskiner med features til beskyttelse af data, så undgår man de producentafhængige fusker design.

Vil du skrive f.eks. en loop variabel til harddisk hver eneste gang den tæller op? Vil du gemme mellemresultater på harddisk? Registre og RAM er langt hurtigere end harddisk.

De unge ingeniører, kan ikke engang lave en flyttemaskine, så kopiering af data fra ram til harddisk, harddisk til ram, og ram til ram, eller harddisk til harddisk ikke tager tid men sker øjeblikkeligt.</p>
<p>Der er ikke noget som hedder øjeblikkeligt! Elektronens hastighed sætter en grænse. Det gør CPU'ens clockfrekvens også.

Da det gøres inde i CPU'en, i dens indre cacher, så går det utroligt hurtigt at kopiere og flyttte store datamængder. Mængden af data betyder ikke meget. Ved meget små mængder af data, har man ofte en "opryder" der optimerer tabellerne, ved at i baggrunden lave en fysisk flytning af data. Ved store mængder af data, vil det normalt ikke ske. Men er det få bytes som flyttes, vil de ofte kopieres fysisk på normal vis.

Hvis du ønsker et ram lager, så vil du normalt bare oprette en fil på harddisken, du kalder ramfil, datafil, swap eller noget andet. Nu kan du så kopiere data fra ethvert sted på harddisken ind i denne, uden det tager CPU tid.

Kopiering og flytning af data er en del af cpu'ens memory manegement system. Her er vigtigt, at den er designet til at gøre det bytevis, og ikke i blokke, for dels vil det ellers være producentafhængigt hvor store blokkene er, og derudover så arbejder programmerne ikke i blokke. Så faste blokstørrelser er inkompatible med alle programmeringssprog og bruges ikke. Der arbejdes enten bitvis, eller bytevis. Det betyder ikke meget hardwaremæssigt, om det er bits eller bytes.

Re: @#7</p>
<pre><code>Det var nemligt meget bedre - som jeg skrev før - dengang hvor CPU'ens registre lå på tape.
</code></pre>
<p>Ja, write-once, så kan vi få brugt noget papir!</p>
<pre><code>Når CPU'ens registre er direkte på harddisk eller tape, så undgås masser af flytterier.
</code></pre>
<p>Ok, for at skrive en byte på harddisk skal man først flytte læse-skrive hovedet, vente på at rette sektor er roteret på plads, læse hele sektoren (minimum 512 bytes), vente på at skiven roterer en hel omgang for så endelig at skrive sektoren tilbage. Det skal nok gå stærkt.</p>
<pre><code>Det er langt bedre, at CPU'en gemmer data der hvor de skal ende, end at skulle gemme dem i et register først, og så skal den så senere flytte det til ram'en og harddisk'en.
</code></pre>
<p>Vil du skrive f.eks. en loop variabel til harddisk hver eneste gang den tæller op? Vil du gemme mellemresultater på harddisk? Registre og RAM er langt hurtigere end harddisk.

Det går ikke ud over hastigheden. Tværtimod. Antag, at du skal hente store mængder data ind fra harddisken, f.eks. køre et meget stort program. Du skal nu ikke hente koden ind, men mapper programmet på harddisken til adresserummet. Dette tager ikke meget tid, da der ikke hentes data fra harddisken. Nu har du den pågældende fil i dit adresserum, uden at der er data i. Så snart CPU'en begynder at udføre programmet, så henter den de nødvendige data ind fra harddisken og udfører disse.

I forbindelse med cache, er også vigtigt at have styr på paralleliseringen. IBM begyndte for mange år siden, at parallelisere den del der styrede lager addresseringen væk fra CPU'en, så adresseringen skete lang tid før at CPU'en udførte opgaven. F.eks. ved udførsel af program, så var det en adskildt processor, der sørgede for, at hente programmet ind. Koden til den blev gennereret ud fra den kode som computeren udførte. Det samme kan man også gøre med andet end selve programudførsel. Compilere, og eventuelt dynamiske in-time compilere der fortolker et indstruktionsæt, laver mange programmer, og særlige programmer der styrer hentningen af data i god tid, før de bruges.

Det var nemligt meget bedre - som jeg skrev før - dengang hvor CPU'ens registre lå på tape.

Ja, write-once, så kan vi få brugt noget papir!

Når CPU'ens registre er direkte på harddisk eller tape, så undgås masser af flytterier.

Ok, for at skrive en byte på harddisk skal man først flytte læse-skrive hovedet, vente på at rette sektor er roteret på plads, læse hele sektoren (minimum 512 bytes), vente på at skiven roterer en hel omgang for så endelig at skrive sektoren tilbage. Det skal nok gå stærkt.

Det er langt bedre, at CPU'en gemmer data der hvor de skal ende, end at skulle gemme dem i et register først, og så skal den så senere flytte det til ram'en og harddisk'en.

Vil du skrive f.eks. en loop variabel til harddisk hver eneste gang den tæller op? Vil du gemme mellemresultater på harddisk? Registre og RAM er langt hurtigere end harddisk.

De unge ingeniører, kan ikke engang lave en flyttemaskine, så kopiering af data fra ram til harddisk, harddisk til ram, og ram til ram, eller harddisk til harddisk ikke tager tid men sker øjeblikkeligt.

Der er ikke noget som hedder øjeblikkeligt! Elektronens hastighed sætter en grænse. Det gør CPU'ens clockfrekvens også.

Nogle af os er hardwareuddannede og kan også godt gennemskue rablerierne.

Du drømmer, som ofte før, hvilket får mig til at tro at du er hardware-uddannet. Nogle af os har ikke dette handicap og kan derfor gennemskue eventuelle rablerier.

Nogle af os er hardwareuddannede og kan også godt gennemskue rablerierne.

Jeg har i hvert fald særdeles svært ved at genkende den - undskyld - gammel sur mand-beskrivelse af nutidens hardware/software.

Er du helt sikker på, at du kender og forstår andet en NexGen (CISC->RISC).

Der findes ikke mange (Apples M1 xyz + IBM Zxy), mange kan ikke engang gennemskue, at AMD's x86 serier lever højt på "dobbelt størrelse L1" caches!

Men OK, lidt GSM er der af og til i rablerierne;-) (se #9)

Er du helt sikker på, at det ikke blot handler om, at verden har overhalet dig Jens?

Jeg har i hvert fald særdeles svært ved at genkende den - undskyld - gammel sur mand-beskrivelse af nutidens hardware/software.

Mange tror desværre at digitalisering er "kattens pyjamas"; skønt der er andre og vigtigere ting i livet og samfundet.

Men, jeg forstår ikke, at man hele tiden skal gøre det om og om igen, og ofte er det endda ikke engang bedre, når det gøres om. F.eks. NemID der så skal være MitID. Det er kun spild af tid og resourcer at lave alt om uden det er en forbedring, og årsag til det. Som om, at version 2 er bedre end version 1. Det er den sjældent.

Indenfor både software og hardware mangler en del - ikke mindst forståelse hos dem der udvikler. Når computerne ikke bare kører programmerne slavisk, så er nødvendigt de kan arbejde med koden, og det kræver determinisme, for ellers er der ingen der ved hvad der sker. Det skal gerne være usynligt for programmøren hvad der foregår, så computeren kan gøre det den vil for at forbedre og parallelisere koden, og løse koden, også mens den udføres. Det kræver at programmeringssprogene er deterministiske. Samtidigt medfører de fleste inkonsistenser og fejl i programmeringssprogene indeterminisme, f.eks. pointere der peger på forkerte data. Det er umuligt, i programmeringssprog der er designet til determinisme. Der er styr på pointerne, for ellers er det ikke determinisme. Og det er heller ikke muligt, at f.eks. addere noget til en pointer, så den står uden for det data område, som den skulle pege på. Det styres af compileren, f.eks. ved at pointerne har erklærede strukturer, der gør compileren ved hvad de gør.

Når der automatisk paralleliseres, så vil IO kunne komme ud af synk med hinanden - derfor sættes de op, således det ikke sker. En gruppe af IO's har samme tidslinje, mens andre IO's har andre tidslinjer, og de kan være ude af synk med hinanden, f.eks. kan printeren blive bagefter når den har sin egen tidslinje. En tidslinje behøver ikke at have noget med tiden at gøre, men der kan også være tidslinjer der er låst fast til tiden, således de ved IO bliver synkroniseret til den fysiske tid - realtids eller fasttids IO. Det er ikke tilladt at forbinde IOs der har forskellig tidslinje, da det fører til ikke determinisme, så det kan man ikke. Nogle IO's er kø-baseret - køer, kræver ikke tidsinformationer, men det er ulovligt at aflæse hvorvidt der er data i en kø eller ikke, da det er et tilfælde ved parallelisme og derfor ikke kan aflæses - beder man om det, vil man i stedet typisk få et tilfældigt tal, da det er nemmere at administrere. Jeg savner, at dem der udvikler computere og programmeringssprog, har kendskab til både fordelene ved determinisme, men også kan udvikle deterministiske programmeringssprog. Men, det vigtigste er, at de kan finde alle steder et programmeringssprog er ikke deterministisk. Indenfor hardware mangler også meget - f.eks. er der mange, som ikke ved, hvordan man laver processorer der kører væsentligt hurtigere, end registre og ram'er kan fungere.

Dire Straits, Your Latest Trick

Tilsyneladende står vi med et erhvervsliv, der består af folk, der ikke ved noget om det de arbejder med, og har arbejdet med gennem mange årtier. Det er en katastrofe af dimmensioner.

Du bliver så kategorisk;), men konklusionen behøver vi (desværre) ikke diskutere.

Jeg har været efter ydeevneproblematikken (YEP) siden 2. g (73/74), hvor jeg igen mødte en "programmerbar" HP-bordcalculator, men der har ikke været den store interesse (for YEP) her i landet siden 1992.

Gennembrudet kom i 1995, hvor MSc og PhD studerende var mere lydhøre og jeg fandt det "svar" jeg søgte i et ulønnet research; i min studietid fik jeg lov at gøre lidt nytte som TA (teaching assistant) 2007-2014 ca 20 ECTS-point om året-

Jeg havde en vis succes med at coache HW-folk i fieldservice i det gamle firma ('83-93) og tog en BSc i software teknologi i 2004-2011, da økonomien var til det.

Mange tror desværre at digitalisering er "kattens pyjamas"; skønt der er andre og vigtigere ting i livet og samfundet.

Alt det snak ændre ikke på at skrevet kode kører mellem 10 og 100+ gange hurtigere end (selv) nutidig compileret kode. (Jeg tester jævnligt og vi taler ikke om "vendor-benchmarks", men om programmer, der producerer resultater.;)

Indenfor software (programmeringssprog), mangler der også stadigt forståelse for, hvorfor at hardware og software skal være så adskilt som muligt, og at det er nødvendigt, for at lave en effektiv oversætter. En af mine opgaver, som jeg giver til C og C++ programmører, er at de skal finde alle fejl i sproget, som gør at de ikke er deterministiske. Simpelthen lave en liste over alt i sproget der kan medføre, at de ikke gør som det er hensigten, og det som gør, at de kan give tilfældige tal fra sig, uden at der bruges en funktion der har det til hensigten. Softwarefolk har totalt mangel på forståelse for datalogi, og de fleste klarer ikke opgaven. En af opgaverne er f.eks. at forklare, hvad der er for en fejl præcist som gør, at benchmark test giver tilfældige tal, og angive præcist hvordan man laver programmeringssprog, hvor det ikke kan ske. Og, hvis man ønsker de skal kunne udføre en benchmark test, hvordan det så gøres, ved at indføre random funktioner, der giver et tilfældigt tal, så tilfældigheder ikke opstår ved et tilfælde.

Tager vi et sprog som VHDL så har dem der har lavet sproget haft en større viden end mange - f.eks. har de forstået, at for at lave deterministisk parallelisme, hvor der ikke anvendes køer, men anvendes shared memory, så skal der eksistere en ordningsrelation, der gør at der er styr på rækkefølgen som data henholdsvis skrives og læses, for at opnå determinisme. Derfor er der to typer variable i sproget - der er variable, der fungerer som ikke shared variable, og ikke indeholder nogen ordningsfunktion. Og der er variable, der er shared, og som indeholder ekstra informationer, herunder informationer således at brugen af dem kan ske deterministisk. Det er også vigtigt at forstå hvordan at man kan anvende sådan viden, når man laver et programmeringssprog. Dette giver også viden om, hvordan man skal lave realtidsprogrammering, og at det vigtige ved realtidsprogrammering ikke kun er at CPU'en er hurtig nok, men også at det også virker selvom CPU'en er uendelig hurtig, og at timing altid skal gå via tidsstempling på IO's. Dette skyldes, at IO's er volatile (altså shared variable), og derfor ikke kan fungere uden en ordningsrelation, her anvendes typisk tid. Ellers kan ikke laves deterministisk software.

Der mangler med andre ord, total forståelse for datalogi, og datalogisk viden, ikke kun indenfor programmører, men også dem der laver CPU'er kan heller ikke noget.

Noget af det som er væsentligt i hardware, er f.eks. at forstå at der kun findes cache. I den sidste ende, kan ske at der måske er harddisk eller tape. Dette gælder selv registre. Det er væsentligt, for at forstå, at når vi arbejder internt i CPU'en på registre, så arbejder vi direkte på harddisken. Det gør dataflow langt mere effektivt, både når data gemmes i ram'en, og på harddisk. Og, det gør også, at harddisk og ram bliver det samme, anvender samme beskyttelsesmetoder, og at når du kopierer data fra ram til ram, eller fra ram til harddisk, og til ram igen, at så tager det ingen tid, fordi at CPU'en har indbygget en indbygget hardware kopieringsmaskine, der ikke flytter data, men holder styr på hvor de er. Det kan vises, at det er noget, som er stort set umuligt at implementere effektivt i software, uden at hardware hjælper med. Det kan til dels implementeres i MMU'en, og normalt er det her man vil implementere det, hvis CPU'en ikke understøtter kopiering af data.

Tilsyneladende står vi med et erhvervsliv, der består af folk, der ikke ved noget om det de arbejder med, og har arbejdet med gennem mange årtier. Det er en katastrofe af dimmensioner.

Ja, det er helt korrekt. I "gamle dage", var en simpel basic kerne ofte hurtigere end maskinkode, fordi at basic kernen kunne ligge i den inderste cache (feritkernelageret), og de antal data der skulle ind og ud var derved langt mindre. Og netop det eksterne lager (harddisken) var meget sløv.

en simpel basic kerne ofte hurtigere end maskinkode

Mon dog, men lad det nu ligge...

Der var engang, hvor cache var lille, delt og i eksterne chips (har kun set ferritkerner på museet). Jeg taler om "moderne" fortolkere i modsætning til JIT (just in time) compilering; hvor en ekstra proces (compileren) konkurrerer om cache-linjerne.

Moderne OS'er består af mange flere "konkurrenter", hvor "vi" ryger ud af cachen for et godt ord. Bortset fra Z-systemerne (med 4 lag) er det meste cache idag "on-wafer" i 3-lag; hvoraf det inderste "Level-1" er splittet i to til hhv. instruktioner og data. De ydre (lidt [meget] langsommere er delt (større)), men stadig meget, meget hurtigere end DRAM, SSD og HDD;)

Grunden til EP er at alle instruktion skal læser fra RAM (første gang), mens kun hver 3-5 inst læser data (fra RAM). Det er rigtigt, at det er en rigtig god idé at gemme opdaterede variable lokalt, indtil paralleliserede behandlinger merger tilbage til hvorfra de var spawned. Men her er vi ude i Tordenskjold-frisurer (langhåret).

Alt det snak ændre ikke på at skrevet kode kører mellem 10 og 100+ gange hurtigere end (selv) nutidig compileret kode. (Jeg tester jævnligt og vi taler ikke om "vendor-benchmarks", men om programmer, der producerer resultater.;)

Du kommer her tæt på, hvad jeg kalder "emulatorparadokset" - når fortolkerkoden er stram nok kan kan den fortolkede "kode" opfattes som "data" (for fortolkeren) - derved kan fortolkeren afvikles fra en nærmere cache (hurtigere) og da alle instruktioner også skal "læses" fra lageret køre hurtigere; medens det fortolkede program skubbes til en langsommere (og større) cache.

Hvis vi udfører en fortolker i dag, som fortolker nogle data, så kan det i dag betale sig, at betragte de data som fortolkes som read-only, også selvom vi ikke ved om de bliver modificeret. Vi antager de er read-only i første omgang, og holder styr på, hvor ofte data modificeres, når vi skal vurdere, om det betaler sig, at betragte dem som read-only. Er de read-only, så kan en fortolkerkode udfoldes af en dynamisk oversætter, og de data der er read-only fra lageret, indsættes direkte i koden. Herefter kan vi optimere koden i den dynamiske oversætter. Nu sker det sjove - vores fortolker optimeres væk, og vi har kun den oversatte kode tilbage. Det betyder, at med en dynamisk oversætter som grundlæggende indmad i vores operativsystem, så kører programmer ligehurtigt, uanset om vi kører rå maskinkode, eller om vi kører en fortolker, der kører emuleret maskinkode. Fortolkeren optimeres væk, af den dynamiske oversætter. Dynamiske oversættere, kan i nogle tilfælde optimere og parallelisere kode, som en statisk oversætter umuligt kan klare. Indeholder koden imidlertid ikke sådan noget kode, og er et godt oversat og optimeret program med en statisk oversætter, så er ikke sikkert at en dynamisk optimerende oversætter giver meget. Ved parallelisme, så er de f.eks. i stand til at håndtere problemer, hvor vi først er i stand til at kunne opsplitte i disjunkt memory og disjunkte processer når værdier i koden er kendt. Har vi som eksempel en array, der sorteres i to halvdele, så kan det paralleliseres, men vi skal først vide at de to dele er disjunkte, og kan håndteres enkeltvis. Det ses nemmere af en dynamisk oversætter. Ofte, kan vi først parallelisere en opgave, når der er regnet lidt på den - her har en dynamisk oversætter, der laver paralleliseringen og optimeringen, sine fordele.

For komme til sagen; parallelisering kan udføres fornuftigt med compiler paradigmer og omtanke, så intercore trafikken ikke bliver en flaskehals.

Det som er min pointe er, at vi faktisk ikke skal tænke over paralleliseringen selv. Det er compileren og operativsystemets opgave. Vi kan vælge, at beskrive vores opgave parallelt, hvis vi ønsker det, men for computeren er der ingen forskel på en sekventiel og en parallel beskrivelse. Problemet vi har her, er alle de dårlige programmeringssprog, som er svært at analysere - og som, som jeg ser det, reelt ikke kan oversættes. I et programmeringssprog, må der ikke være hardwarestørrelser som f.eks. sizeof(pointer) = 4, eller andet. Der bør hellerikke være words, hvor intervallet afhænger af hardwarens databus. Derimod bør det være muligt at definere mitinterval = -1234..1234 og f.eks. x er af typen mitinterval, uanset hvor stort mit interval er. På den måde, så er det uafhængigt af hardware, da -1234 kan være uendeligt lavt, og 1234 kan være uendeligt højt. Hardwaren må ikke kunne ses fra sproget. Så snart man laver noget humbug i et programmeringssprog, hvor vi kan sætte en pointer til en vilkårlig værdi, og modificere eller læse værdien af denne ram adresse, så går det galt med enhver analyse, og programmet kan reelt ikke forstås af computeren, og derfor ikke oversættes. At man så kan lave nogle tilstandsmaskiner, der kan klaske noget maskinkode ud, som kan udføres, har i mine øjne intet med oversættelse at gøre. Sprog som C og C++ kan simpelthen ikke oversættes.

Jeg tror vi er enige i, at det ikke er programmørens opgave, at side og opfinde paralellisering, og at denne del er compilerens og operativsystemets opgave. Det er også operativsystemet og compileren, der skal prioritere alle de mange parallele tråde der herved opstår, således at sekventiel kode ikke mere reelt andet end opfattes og er beskrevet sekventielt, men ikke udføres sekventielt. Det udføres efter de prioriteter, der er vigtigt at løse først. Det giver langt bedre mulighed for at anvende hardwaren og cache effektiv.

Vi kan i meget høj grad automatisk parallelisere opgaverne, og det kan gøres automatisk langt mere effektivt end noget menneske kan præstere.

Alle de HW-tricks, der kan afhjælpe kompleksitet kommer med en pris i form af ekstra arbejde for HW - og/eller ekstra HW med tilhørende kode:)

Du drømmer, som ofte før, hvilket får mig til at tro at du er hardware-uddannet. Nogle af os har ikke dette handicap og kan derfor gennemskue eventuelle rablerier.

Det ville også gavne, hvis du benyttede afsnit i dine tekstblokke.

For komme til sagen; parallelisering kan udføres fornuftigt med compiler paradigmer og omtanke, så intercore trafikken ikke bliver en flaskehals.

Den bedste måde vi i dag kan håndtere hardwareafhængige sprog på, er dynamisk oversættelse, hvor man søger at reoversætte koden, hvis den kommer ud i noget som compileren antager er noget vås, men det er kompleks, og kan gøre udførslen langsom når det pludseligt skal genoversættes.

Du kommer her tæt på, hvad jeg kalder "emulatorparadokset" - når fortolkerkoden er stram nok kan kan den fortolkede "kode" opfattes som "data" (for fortolkeren) - derved kan fortolkeren afvikles fra en nærmere cache (hurtigere) og da alle instruktioner også skal "læses" fra lageret køre hurtigere; medens det fortolkede program skubbes til en langsommere (og større) cache.

Det vigtigste i et højniveau sprog, er at opgaven er 100% korrekt defineret, uden at hardwareting kan have betydning for koden, for disse hardwareting gør analysen inkomplet, og umuliggør ofte oversættelse af koden til vilkårlig hardware, f.eks. parallelt hardware.

Dette problem klares i dag ved at det compilerede program indeholder kode til forskelligt HW og valget (af HW) træffes på runtime-tidspunktet ud fra indholdet af systemregistre, der beskriver HW's faktiske kapabiliteter. Herved vokser executables ganske vist, men kun den anvendte HW-funktionalitet kommer til at fylde i cachen.

(Jeg) Beklager, du ikke havde glæde af Clapton-citatet;)

Sammen med en BSD.kollega draftede jeg i firserne et af de første 80x86-multiprocessor-systemer. HW-folkene ventede dog et par processorgenerationer med at bygge dem. De kom dog til at køre et System-V (5) OS, men det er en anden historie.

Han foreslår i stedet at fokusere på parallelisering af regnekraft, som netop Nvidias grafikkort i vid udstrækning anvendes til i dag.

Vi kan i meget høj grad automatisk parallelisere opgaverne, og det kan gøres automatisk langt mere effektivt end noget menneske kan præstere. Så det er ikke noget der ændrer den måde som vi programmerer. Når man laver et program, skal man ikke tænke på hardwaren - hardwaren har intet med software at gøre, ej heller parallelisering. Dette klares af dels compiler, dynamisk compiler, og af hardware. Vi skal helst ikke kunne hverken måle, eller detektere hvilken hardware der anvendes fra softwaren. På den måde, så er softwaren faktisk i stand til at kunne parallelisere og optimere koden bedst - det er de steder i koden, hvor noget er "hardwarenært" at det går galt. Har vi et program, og er der range check på alt, så er muligt at parallelisere bedre, end i C++ hvor range check i nogle tilfælde er svært eller umuligt. Problemet er, at den manglende range check gør koden afhængigt af hvordan at processoren arbejder, når pointere eller index's kommer uden for det gyldige område, og der ikke findes en måde at man kan se hvorvidt det er korrekt eller en fuser. Det vigtigste i et højniveau sprog, er at opgaven er 100% korrekt defineret, uden at hardwareting kan have betydning for koden, for disse hardwareting gør analysen inkomplet, og umuliggør ofte oversættelse af koden til vilkårlig hardware, f.eks. parallelt hardware. Den bedste måde vi i dag kan håndtere hardwareafhængige sprog på, er dynamisk oversættelse, hvor man søger at reoversætte koden, hvis den kommer ud i noget som compileren antager er noget vås, men det er kompleks, og kan gøre udførslen langsom når det pludseligt skal genoversættes. Samtidigt er svært for en dynamisk compiler, at få overblik over store bunker kode. I visse tilfælde, kan dynamiske compilere dog løse optimerings og paralelleiseringsproblemer som statiske compilere ikke kan. Som et eksempel, kan de ofte løse problemer hvor et program fortolker kode, fordi de håndterer hukommelse som konstant, indtil der forekommer hyppige modifikationer til hukommelsen. Dette betyder, at de kan indsætte variable direkte i koden, og optimere koden derefter, hvor den selv finder ud af om de er konstante, eller modificeres. En typisk fortolker vil derfor kunne køre ligeså hurtig, som oversat kode.

Let IT grow, let IT grow, let IT blossom, let IT flow.

Let it grow

Og der var dengang Tordenskjold havde hår ...