Bruce Eckel: Sådan bliver programmering i 2035

bruce eckel burde tage et kig på

http://newspeaklanguage.org/

Jeg tror godt Bruce er bekendt med Newspeek, eftersom
Gilad Bracha også er fra Java verdenen og kommer i de samme kredse (OOPSLA, JAOO osv.).

Bruce overser muligvis et aspekt, nemlig effektivitet. Ligesom vi i dag har decimale og float afh. af hvilken præcision man har brug for, tror jeg vi vil få mange flere muligheder for at skrue på effektivitetsknappen - også i kraft af den indeværende revolution inden for håndholdt/pervasive computing samt den stigende fokus på energieffektivitet.

det var nu også ment som et link til læsere af denne nyhed, tvivler på Eckel læser version2 på daglig basis ;)

Hvis man ser på, hvor lidt programmering har flyttet sig i de sidste 25 år (og de 25 år før da), så virker Eckels forudsigelser meget flyvske. Der er simpelthen for meget inerti i "systemet" til, at programmering kan ændre sig radikalt i løbet af "kun" 25 år. Faktisk er inertien større nu end tidligere, for der er et langt større korpus af eksisterende software, som man ikke vil skrive om til radikalt anderledes sprog eller maskiner.

Jo, der vil være mere parallelisme i fremtiden, men at tro, at alt automagisk vil skalere uden grænser og at tilgang til data over nettet kan gøres ligeså hurtig som lokal tilgang, er naivt.

Og Eckel har da heller ikke nogen løsning klar. Han opremser bare sine personlige kæpheste om dynamiske sprog, skyer og så videre, og lover (uden begrundelse), at de er løsningen på alt.

hvilket var derfor jeg nævnte newspeak, Gilad har nogle af de samme visioner, men arbejder på reelle løsningsforslag.

Der er godt nok meget bullshit i den smøre.

Jeg ved ikke hvad han havde forestillet sig, men nogen som i hvert fald ikke kan bruge denne automagiske verden er dem som skal bygge den.

Vi skal da nok se nogle nye smarte værktøjer, personligt tror jeg at vi vil se beskyttede miljøer hvor fremmed kode kan afvikles sikkert performe langt bedre end de gør i dag. Vi har allerede set hvordan JavaScript har fået et kæmpe boost i afviklingshastigheden.

De dynamiske sprog vil sikkert få lidt mere fodfæste, men det forbliver værktøjer til opgaver hvor performance ikke er alfa og omega.

... men indtil jer ser noget med lidt mere substans så vil jeg holde mig til at tro at det er et andet glasagtigt objekt end krystalkuglen Bruce Eckel har kigget dybt i.

Ingen tvivl om at fremtiden vil byde på programmeringssprog, der langt bedre tager højde for skalering, parallellisme, meget mere flydende datastrukturer og sikkerhed gennem virtualisering. Man vil nok også få mere avancerede værktøjer til kodeanalyse og test, og der vil nok også blive et mere flydende forhold mellem et programs grænseflade og dets indre processer.

Men for at disse ting kan blive almindeligt udbredte og til at bruge for almindelige programmører, der udfører den daglige rugbrødsprogrammering for virksomheder, der prioriterer lave omkostninger frem for høj kvalitet, kræver det nogle meget komplicerede, general-purpose abstraktionslag i sprogene og udviklingsværktøjerne. Det vil kunne betale sig, hvilket altid er det drivende aspekt, men det vil gøre alting langt mere kompliceret og kan i sidste ende medføre flere onder end med god og dydig klassisk programmering.

Disse abstraktionslag vil de aktører, der virkelig driver udviklingen og kommer til at servicere flest mennesker (fremtidens Google'er), desuden ikke være særligt interesserede i, fordi de hele tiden finder på helt nye måder at tænke på, hvilket er, hvad der giver dem deres succes. De vil ansætte verdens skarpeste hjerner, som snarere end at programmere vil bedrive datamæssig grundforskning.

I øvrigt tror jeg teknologier som PhotoSynth og Googles mange former for dataintegrering kun udgør de første spæde bud på en fremtid, hvor alt er semantisk og hvor data bliver sammenkørt og analyseret på måder, der vil afsløre helt nye dimensioner for menneskeheden. I det lys vil en oplagt feature for fremtidens programmering være bedre query-sprog. Med en bedre syntaks end SQL, det siger sig selv, men også langt mere "smarte" og automatiserede.

Han har glemt drag n' drop programmeringen, så var jeg helt solgt ;)

Hvem er Bruce Eckel og hvorfor skulle jeg tro på at han kan forudsige fremtiden?

Han skriver at alt det svære inden for datalogi forsvinder. Jeg tror han tager fejl.

Sådan bliver det ihvertfald ikke. Det er formentlig ganske klart. Så pointen ved at opstille udsigter som disse er vel, man kan diskutere, eller reflektere over, hvordan det så bliver - hvad man synes der er galt, og hvordan det kunne ændres. Måske dét gør en forskel. Det er science fiction. 2035 lokker nok bare mere end 2335 - for de almindelig dødelige.

Så tilbage til 2035 :)

Jeg tror, at Bruce Eckel får ret i alt! En ting, har han dog glemt at få med: Det bliver GRATIS at kopiere!

Hvor det idag tager tid at kopiere en blok af data, eller delblok af data, så vil det i fremtiden blive "gratis", forstået sådan, at det ikke tager større tid, computerresourcer, eller energi. Det vil ske, ved en forbedret hardware, der understøtter kopiering.

Grunden til, at han ikke tager det med, er måske den store modstand - da mange konkluderer, at hvis det ikke koster tid - så koster det ingen penge. Og her, siger erhvervslivet stop.

Men idéelt set, så vil kopiering i 2035 ikke koste hverken computerresourcer, tid, eller penge!

Meget underholdende, men har han forestillet sig at programmeringssprog kommer ud af sig selv, og at hardware forsvinder.

Det skal såmænd nok komme nogle højniveau sprog, som gør at der kan laves en nyere form for programmering, men ligesom at man også kan kalde makroprogrammering i f.eks. Excel for programmering, så er der altså nødt til at lave et fundament før man kommer så vidt.

Og grundværktøjer og udviklingsværktøjer skal altså også programmeres ned mod hardware og/eller abstraktionslag, og fra abstraktionslaget og ned skal der også programmeres.

Skal alt dette bare komme som en slags hokus pokus?

/Christian

+1 for at levere dagens sorteste indlæg :-)

Han skriver at alt det svære inden for datalogi forsvinder. Jeg tror han tager fejl.

Jeg tror, at han mener det svære indenfor programmering. Indenfor datalogi, bliver det svære, men programmøren opdager ikke, at det underliggende operativsystem, compileren, og computerens hardware er blevet mere advanceret.

At sige, at alt det svære forsvinder indenfor programmering, er sandsynligvis også en overdrivelse. Men det er ikke usandsynligt, at programmering kan blive nemmere.

Det som sker, er at visse trivielle jobs, kan automatiseres bort, og jeg tror også, at det er det han mener. Som eksempel, nævnes at analysen af koden går fra statisk analyse, til dynamisk analyse. Dette muliggør en mere komplieret analyse. Altså, mere advanceret datalogi. Til gengæld - for håbentligt - en gevindst indenfor programmeringen, så den bliver enklere.

Paralleliseringen, og at problemerne "forsvinder" som dug fra solen, er måske lidt overdrevet - men i det store hele, tror jeg han får ret. I forhold til nutidens multitasking bestående af C kald til operativsystem, så bliver det meget enklere. Der er masser af faldgrupper, du kan falde i idag - og disse forsvinder. Som eksempel, vil koden blive deterministisk, og gøre som du beder om, selvom den er parallel - med mindre, du altså ønsker andet. Og det vil blive mere tydeligt af koden, hvad du ønsker. Idag, ønskes ofte en deterministisk funktion uden fejl - men der fås en tilfældig funktion, med fejl. Her vil det blive så at man decideret skal anstrenge sig, for at opnå ikke deterministisk funktion, så det fremgår direkte af koden, at det ønskes - og det vil blive sådan, at man relativt nemt kan søge på de pågældende steder i koden, så en eventuel random funktion kan fjernes. Tilfældigheder vil altså ikke opstå som bivirkning f.eks. ved parallelisme, men vil skulle kodes overlagt.

Diske forsvinder, får han sikkert også ret i - vi kan forestille os, hele verden som et "memory mapped" system. Det betyder, at hvis du begynder at udføre kode ude på nettet, så kan du begynde at udføre koden, fra første byte - uden at skulle overføre en samling af mange gigabytes først. Disse hentes, meddens programmet udføres. Jeg vil dog måske mere sige at ram'en forsvinder - og disk'en erstattes med f.eks. flash, eller anden solid state hukommelse. Men, i princippet, vil det svare til at alt er ram.

Med hensyn til testing, tror jeg også han får ret at det sker noget - men om det er muligt, at gøre alt automatisk tvivler jeg på. Det som sker, er at systemerne vil indeholde validering af testene, således der kan kræves et vist minimum, men at tests sættes ind som del af koden. Dog, vil det sandsynligvis være størstedelen af testene, der kan laves automatisk. Men det vil være nødvendigt - tror jeg - at kombinere med manuelle tests, for at få en tilstrækkelig coverage på f.eks. 100%. I visse tilfælde, vil der skulle intelligens til, for at lave en test. Men her vil det så kunne tjekkes om testingen er god nok udfra coverage. Så jeg tror, at det bliver en kombination af automatiseret testvektorgenerering, og manuel, samt måling på dækningsgraden for testen.

At forskellen mellem lokal, og sky forsvinder, tror jeg også - i stedet for at skrive programmer, der håndterer lokalt, og sky forskelligt, er naturligvis en fordel at de håndteres ens. Det, som håndteres ens, kan løses ens - og øger genbrug af kode.

Det er noget om, at kode skal sikres om er sikkert inden det udføres - vi kan sige at jo tidligere vi ved der er en fejl, desto bedre. Computeren, skal faktisk helst afslå et program ved indstallationen, hvis det ikke er sikkert. Så tidligt som muigt - jo bedre. Det skal være på allerede compilieringstidspunktet, om muligt - eller måske endog allerede indtastningstidspunktet så cursoren indikerer fejl i indtastning af ord, og hvad der ellers kan analyseres. Efter compileringen, er der måske noget linking hvor fejltestingen holdes op mod f.eks. linkede rutiner. Næste niveau, efter compileringen, er måske indstallationstidspunktet hvor det holdes op mod computer, og dens resourcer. Næste niveau herefter, er run-time tidspunktet, hvor det holdes op mod computer, resourcer, inputs osv. der måtte kun eksistere og være muligt at have kendskab til run-time. Så genneralt - fejlbeskeder gives så tidligt som overhovedet muligt.

Søgning - ja, glem alt om at du skal vide noget om kompleksiteter og rød-sort træer... Du angiver bare i programmeringssproget hvad du vil søge i - og compileren finder den optimale algorithme. Du behøver ikke, at selv implementere søgninger, heaps, og andre datalogiske strukturer.

Jeg tror, at pointere vil forsvinde lidt - som vi kender dem. Det er vigtigt for compileren, at vide noget om, hvor data ligger i lageret, for at den kan analysere koden godt. Og derfor, vil en "rå" pointer ikke give mening. Pointere, vil eksistere indenfor et område, f.eks. et array, som indexeret variabel. Og de vil også kunne eksistere indenfor en struktur. Men som "rå" pointer, der kan pege på langtbortistand, vil de forsvinde. Sådanne pointere, gør koden svært at analysere, både med hensyn til parallelisering, og med hensyn til prioritering af kode, samt automatisk omskrivning til eventdrevet kode. Eventdrevet kode, og parallelisering, har meget med hinanden at gøre, da fremtidens computer - og compiler - vil have begreb om hvordan aktiveringen af koden hænger sammen, og dermed kan såvel omprioritere afviklingen af koden, som gøre den eventdrevet og opprioritere en kode, når der kommer interrupt, eller handling fra tastatur og mus. Rutiner, der står og laver det samme hele tiden, vil i forhold til kode der sker afvekslende, prioriteres ned - og f.eks. bugs med uendelige løkker betyde mindre. Gøres det samme igen, og igen, bliver computeren "træt" og nedprioritere det pågældende, meddens afvekslende ting prioriteres op.

Naturligvis, bliver skalleringsproblemerne løst. Og det vil være muligt, at flytte kode, til enhver anden hardware platform, selvom der anvendes en ny processor, med nye features, større grad af parallelisme og andet indstruktionssæt. Trods ændret hardware, så vil den gamle kode stadigt fungere - operativsystemet "oversætter" simpelthen den gamle kode til nyt. Kun den statiske oversætning vil høre under compileren - den dynamiske, hører under operativsystemet, og tager højde for computerens natur og hardware når den udføres - dette betyder, at koden bliver mindre, hurtigere, bruger mindre strøm osv. fordi at den tilpasses hardwaren direkte - idag er koden ofte med bunker af "forbehold", fordi den skal fungere på mange platforme. Når operativsystemet oversætter koden en ekstra gang, inden udførsel, så tilpasses den hardware ved denne oversættelse. I princippet - når compilerne bliver dygtige nok - kan måske dele lægges i FPGA'er, og andre dele i parallel processorer. Programmøren, laver bare sin normale kode - og automatikken optimerer den til computerens CPU, eller processorer, samt de pågældende processoreres features og funktioner. Den del, af en compilering, som skyldes computerens arkitektur, flyttes altså fra compiler til operativsystemet, og sker dynamisk, når programmet starter.

Så jeg tror, at Bruce Eckel får ret. Dog, har han glemt problematikken omkring gratis kopiering. Og det er nok gjort bevidst.

Jens Madsen: Du er godt klar over at nogle af dine forestillinger forudsætter at fysikerne sætter hastigheden på lyset op, ikke?

Jeg forstår ikke hvorfor man ikke sætter sig ned og undersøger hvordan virkeligheden hænger sammen, før man begynder at forfatte en så lang omgang vrøvl.

Det er fint at Bruce drømmer som han plejer.
Blot skal sværvægtere bag (Oracle, IBM, Microsoft) følge med, ligesom de firmaer som aftager deres ydelser (ITB og det offenlige Danmark f.eks.).
Det er der vist ingen udsigt til foreløbig - de kan ikke engang finde ud af at Java er en dinosaur af et sprog.
Desuden skal vi jo altså have en masse på rigtig mange mio. udviklere flyttet - til nye smartere platforme, og den vej er særdeles tung.
En stor bevægelse er hvis man kan flytte sig fra udtrykke sig imperativt henimod at udtrykke sig declarativt (læs: drop Ant og brug Maven et. al.).

@Jens Madsen
Tror du COBOL er død i 2035?
Tror du C.. (C/C++, C#) og Java er døde i 2035?
Tror du local storage er død i 2035?
Tror du local storage overhaler RAM i hastighed?

SQL lever i dag (1974 - 36 år)
Pascal lever i dag (1970 - 40 år)
Fortran lever i dag (1957 - 53 år)
Ada lever i dag (1983 - 27 år)
C lever i dag (1972 - 38 år)
C++ lever i dag (1983 - 27 år)

Perl lever i dag (1987 - 23 år)
Python lever i dag (1991 - 19 år)
Ruby lever i dag (1995 - 15 år)
Java lever i dag (1995 - 15 år)
C# lever i dag (2001 - 9 år)

Så hvad er det der gør at vi skulle begynde at gøre tingene anderledes? Vi hænger jo stadig fast i de object orienteret/procedurale sprog, selvom der er masser af tiltag til at gøre tingene anderledes med god mening?

Bare testområdet kunne revolutioneres, ved inførelse af best practices.
Oftest skal udviklingsteams rette sig efter laveste fællesnævner med hensyn til kompetencer, når de sammensættes, hvilket er en stor hindring for fremskridt for alle videns- og kompetencemæssigt.

Det er fantastisk, at Bruce har fundet "the silver bullet", så må vi bare håbe, at han ikke som alle andre, der troede de havde fundet, måtte konstatere, at den var af poleret bly.

Jens Madsen: Du er godt klar over at nogle af dine forestillinger forudsætter at fysikerne sætter hastigheden på lyset op, ikke?

Tværtimod. Det er tale om dynamiske analysemetoder, der kører meddens programmet udføres - altså en slags advanceret in-time compilering. Det, som af compileringen kan gøres statisk, gøres dog naturligvis først.

Det med gratis kopiering af data, kan i nogle tilfælde også løses ved compileringen. Vi kender alle muligheden for, at kopiering af en stor mængde data der ikke ændrer sig, kan løses ved at bruge pegere, og pege til samme data.

Der er dog visse problemstillinger, der ikke løses så nemt på denne måde - vi kan tage eksemplet, at vi har en meget stor tekst liggende i en stor streng (måske en hel tekstfil) - og gerne vil indsætte et bogstav. Her er svært at gøre det, uden teksten flyttes fysisk, da vi ikke kan bruge pointere. Imidlertid, findes datalogiske løsninger på problemet, og ved supplering med hardware, er det muligt at gøre på ganske kort tid, der ikke afhænger væsentligt at tekstens størrelse.

Det er også muligt, at lave hurtige søgninger i en streng (pos funktionen), men det er noget mere kompliceret, da teksten så skal "indexeres" først. Dette kan ske, når data gemmes i strengen, men gør gemmefunktionen en smule langsommere - dog vil det ikke påvirke store O funktionen for denne. Kun for søgningen (pos) påvirkes store O funktionen til at gå ned. Imidlertid, så bruges en del ekstra ram, plus der bruges ekstra tid på at gemme data. Derfor, vil det ikke genneralt være en fordel, at lave en pos funktion på den måde.

Som eksempel, vil koden blive deterministisk, og gøre som du beder om

Jeg har ikke brugt et sprog, der havde nondeterministiske kontrolstrukturer siden Trine ( http://www.daimi.au.dk/~steffen/mesterdatalogen/trine.html ), så alle de sprog, jeg bruger i dag gør præcis, hvad jeg beder dem om.

Det sker blot alt for ofte, at jeg beder dem om det forkerte :-(

Jeg har ikke brugt et sprog, der havde nondeterministiske kontrolstrukturer siden Trine ( http://www.daimi.au.dk/~steffen/mes... ), så alle de sprog, jeg bruger i dag gør præcis, hvad jeg beder dem om.

Det som ofte sker, er i forbindelse med parallelisme - er at funktionen afhænger af, i hvilken rækkefølge at processerne udføres, og så er resultatet ikke deterministisk. Dette sker, for blandt andet C++, når det anvendes sammen med Windows til parallel programmering.

Der findes også mange andre eksempler på ikke deterministisk opførsel. Selvom C og C++, i princippet er deterministisk deffinerede, så er de i praksis ikke, f.eks. på grund af ikke initialiserede variable ol. Skal sproget være deterministisk, skal altid ske det samme, trods programmøren har begået fejl. Det må ikke være muligt, at lave noget kode der er ikke deterministisk - med mindre det er tydeligt declared i programmet, at det ønskes tilfældig funktion. Dette betyder, at det eksempelvis ikke må være adgang til steder i lageret med ukendt indhold, at variable ikke må have ukendt indhold osv. og at programmeringssproget, altid skal give fejlbesked således funktionen er deterministisk (samme inputs, samme resultat).

Som andre problematikker, kan nævnes hardware. Forestil dig, at du har en løkke, der f.eks. kan afbrydes af en tast - er denne deterministisk? Nej, det er den ikke - så det må ikke være mulgt. En funktion som returnerer en boolean værdi, afhængigt af om en tast er tastet, er i princippet ulovligt, i et deterministisk sprog. Det kan give en række problemer, så visse typer opgaver, er svært at kode - men det viser sig, at disse typer problemer ofte er af optimeringsart, og at de kan løses automatisk, så det faktisk ikke er nødvendigt at kode. I andre tilfælde, kan det løses med komponenter der løser problematikkerne, og hvor komponenterne er manuelt gennemgået, så det er sikret de fungerer perfekt. Sådanne komponenter, kan være en fast del af programmets bibliotek, eller de kan være manuelt "godkendt". Det er en fordel, hvis sådanne tilfældigheder, fremgår tydeligt af programmet, således der kræves bestemte indstruktioner for dette, der så også viser, at her foregår noget der altid medfører noget ikke deterministisk, men dog i visse tilfælde ikke får betydning for resultat, eller får ønsket betydning for resultat.

Et andet eksempel, er fælles tilgange til variable, ved multitasking. Selvom du har låsebits osv, så er det i princippet ikke deterministisk. Dog, vil det ofte kunne godkendes, hvis det låses mv. efter kunstens regler, men det skal altid overvejes, hvad indeterminismen medfører, og sikres at det fungerer som ønsket, uanset rækkefølgen. Det er om at undgå den type adgange mest muligt, og dette er en af fordelene ved actor modellen. Ikke deterministiske modeller, skal kun bruges hvor det er absolut nødvendigt. Og sproget skal motivere programmøren, til at programmere på en måde det er deterministisk. Ellers, bliver resultatet uoverskueligt, og i 99% af alle tilfælde, fungerer det ikke. Determinisme er nødvendigt - og kun, hvis man reelt har flere brugere, der har adgang til samme fil eller datagruppe, er nødvendigt med ikke deterministiske metoder. Det ikke deterministiske består i, at resultatet afhænger af rækkefølgen, som de to samtidige brugere agerer.

Den ulovlige "indstruktion" i parallel sammenhæng, er at kunne teste på mængden af data på en datastrøm mellem processer. Det er ikke lovligt, at få at vide om der er noget på en input stream - uanset om den kommer fra tastatur (som test på key pressed), eller om den kommer fra en anden process. I stedet, skal udførslen standse af processen der behøver inputtet, og computerens resourcer omdirigeres til det som leverer inputtet, således at programmet kan fortsætte hurtigt. I princippet, ved vi ikke noget om antallet af data på en datastrøm mellem to processer, og funktionen er uafhængigt af dette - det betyder også, at der opstår en form for "elastik", så processerne kan køre asynkront, hvis der er fifo plads.

Skriver du eksempelvis noget ud på skærmen, så placeres det i en stream, inden det går til udskrifts processen. Hvor mange data, der er gemt i fifoen, er i princippet ligegyldigt for funktionen. Men, hvis fifoen er stor, giver det mulighed for "elastik" i udførslen, da udskrifts processen, så kan foregå når det er belejliget.

Selvom der er sådanne elastikker i udførslen, så er det ikke noget som er synligt fra programmøren - og derfor er den overordnede funktion helt deterministisk. Elastikkerne, kan også være med til at udskubbe dele af en funktion, hvis noget andet er vigtigt - specificerer du eksempelvis, at et svar på et interrupt, eller et input fra omverdenen, skal besvares inden en bestemt tid, så vil resourcerne kunne omorganiseres, således dele først udregnes senere, og buffes i en fifo. Selvom det underliggende er tilfældigt, i hvilken rækkefølge at koden udføres, så er funktionen deterministisk. Den underliggende tilfældighed, kan være med til at låse op for flaskehalse i koden. Og enda, kan det medføre, at uendelige løkker, ikke medfører låsning. I nogle tilfælde, bruges funktioner som tjek på tast er trykket, til at optimere koden, så der kan udføres noget, hvis tasten ikke er trykket. Dette er ikke nødvendigt, da at den underliggende mulighed for at udføre programmet ude af rækkefølge, gør at dels andre processer kan udføres, og at programmet kan fortsætte, efter et sted den nærmest "hænger". Hvis et resultat, af hængeriet ikke behøves kendt, så fortsætter funktionen - og når resultatet kendes, så tages action på dette. Det vil derfor fungere eventdrevet, så de dele af kode, der påvirkes af hændelsen, automatisk aktiveres.

Direkte uendelige løkker, vil ofte prioriteres ned - det betyder dog ikke, at de ikke udføres, men kun at processorens kraft fortrinsvis bruges til andet, således at de uendelige løkker kun reelt optager idle tiden. I nogle tilfælde, hvor det er tydeligt at en løkke er uendeligt, kan compileren automatisk erstatte koden med en "halt", eller uendelig "wait" således der ikke bruges resourcer. Går nogle variable, datastrømme, eller noget interrupt aktiveret ind i en sådan nedprioriteret løkke, kan en ændring i disse data, medføre "fornyet energi", til løkken.

Når den underliggende kode, ikke mere udføres deterministisk - og det kun er funktionen som er deterministisk - så tillader det mange optimeringer i svartid. Det betyder, at funktionen f.eks. kan optimeres, således at der svares hurtigt på et input, såsom resultat på skærm, af at der trykkes på tast, flyttes med mus, eller klikkes. Hvorimod, at mere ligegyldige funktioner, kan træde i baggrunden. Det kan f.eks. være beregninger, der er udført i længere tid. Programmeringssproget, kan tilbyde at timing angives, f.eks. imellem input og outputs, og afviklingen kan foregå, således at timingen opfyldes.

I mange tilfælde, medfører dette at brugeren får en bedre oplevelse, og programmet virker hurtigere. Det svarer lidt til, at du har en række paralle tasks, såsom at bygge huse. Du bygger lidt på hver hus, skifter til næste, og bliver færdig med alle samtidigt. Dette er en langsom måde, at løse opgaven. Tager du hvert hus, hver for sig, så bliver du i middel dobbelt så hurtig færdig. De første, bliver hurtig færdig, meddens sidste bliver ligeså langsom, som alle før tog, da det blev gjort lidt af gangen på alle. Sorteres, således at små tasks, får større prioritet, så opnås at den typiske svartid er langt bedre, og vælges en god optimering, så giver det brugeren bedre oplevelse.

I nogle tilfælde, er dele af koden, der kan optimeres helt væk - f.eks. kan det være et ur, der er scrollet udenfor skærmen. De pågældende tasks, har ikke direkte nogen grund til at blive udført, da ingen har behov for dem, hvis de kun bruges af skærmen, og den pågældende del er udenfor vinduet. Her, kan compileren vælge, at skære koden helt væk, og fjerne eventuelle interrupts til det pågældende, indtil at de bliver nødvendige igen, f.eks. ved at det pågældende scrolles ind på skærmen. En anden mulighed, er at der senere kommer f.eks. en CLS ordre (slet skærmen), og da koden fortsætter hurtigere end den egentligt kører da det hele er out-of-order, så vil en sådan CLS, hvis der ikke er pauser først, medføre at alt før er borte. Koden, kan derved fjernes, før den er udført.

Delays, er i den sammenhæng lidt specielt. Det er en meget dårlig ordre i programmeringssammenhæng, fordi den i princippet forsinker alt. Det er bedre, at forsinke en variabel - eller et output. Som eksempel, kan eventuelle outputs - f.eks. til skærm, eller til I/O enhed, have tid på de data der sendes til enheden. Og enheder der modtager data, kan tidsstemple dem ved indgangen. At indføre forsinkelse, ved at lægge dem på data, f.eks. at sige at noget først skal udskrives på et bestemt tidspunkt, er en langt bedre måde, end at stoppe alt, med en delay indstruktion. Hvis man endeligt har en delay indstruktion, så tvinges en rækkefølge imellem disse, så det er med til at forhindre out-of order execution, da delays funktionsmæssigt skal udføres i rækkefølge, med mindre de tilknyttes data.

Normalt, vil det være muligt, at tilknytte delays til enheden de skal fungere på - hvis f.eks. der vises en film på skærmen, så vil delays være tilknyttet skærmen. En delay, kan i princippet "flyttes" og placeres mange steder i koden, men placeres den så tæt på det fysiske medie som muligt, så vil data blive regnet ud på forhånd, og klokket ud til tiden. Antages, at compilerens kode er hurtig nok - f.eks. optimeret til garanteret svartid, bliver timingen derfor eksakt. I princippet, kan det som styrer at tingene sendes ud til tiden, placeres i selve I/O controleren, f.eks. en FPGA, eller i videokortet. Derved kan sikres, at timingen der er defineret i koden, styres eksakt, ned til nøjagtigheder på langt under 1ns, afhængigt af hardwaren.

Specielt, når der laves styresystemer, der fungerer sammen med hardware, så kan eksakt timing være nødvendigt. Dette er uanset, om du skal lave en robot der går på line, eller et rumskib, hvor eksakt timing styring af motoren, betyder noget. Ved at tilknytte delays og tidsstempling til data, og at lade den aktuelle forsikelse ske på udgangen, og tidsstemple data præcist på indgangen, så er muligt at opnå eksakt og perfekt timing.

Det sker blot alt for ofte, at jeg beder dem om det forkerte :-(

I really hate this damn machine,
I wish that they would sell it.
It never does quite what I want,
But only what I tell it.

[i]anonymous[/i]

Det som ofte sker, er i forbindelse med parallelisme - er at funktionen afhænger af, i hvilken rækkefølge at processerne udføres, og så er resultatet ikke deterministisk. Dette sker, for blandt andet C++, når det anvendes sammen med Windows til parallel programmering.

At du anvender parallisme gør ikke dit resultat indeterministisk. Systemet opfører sig stadig fuldstændig som det har fået besked på - men du skal selvfølgelig forstå konsekvenserne af parallisme.

Det grundlæggende problem er at alt for mange kaster sig ud i paralliserede applikationer i de her multi-core tider, uden at have læst op på lektion og med en gammeldags liniær tankegang i baghovedet og så er det ikke så pokkers underligt at resultaterne virker indeterministiske.

Og det har iøvrigt intet med C++ eller Windows at gøre, de tilbyder blot ikke ret meget hjælp - du skal selv tænke.

Nogle nyere sprog forsøger at udnytte parallisme uden at udvikleren behøver at kende til detaljerne eller behøver at vide at det sker. Det kan som sådan være fint nok, men sandsynligheden er at du alligevel vil rende i problemer før eller siden hvis du ikke forstår hvordan dit program opfører sig. Jeg bryder mig generelt ikke om den her tankegang med at vi skal pakke udviklere ind i vat og beskytte dem imod sig selv. Det virker fint på overfladen, men hvis compileren laver "magi" for dig, så vil du få et problem når du render ind i en case hvor "magien" fejler. Hvis du kun forstår hvordan din kode virker på high-level niveau og ikke hvordan det reelt afvikles af operativsystemet og hardwaren, så vil du få problemer når du leger med samtidighed.

Vi skal selvfølgelig have nogle bedrer værktøjer til at opbygge og debugge ultra-parallele applikationer og de skal også nok komme - mange er allerede på vej. Men de vil gøre meget mere gavn i hænderne på en programmør der forstår samtidighed og ved hvordan tingene afvikles på både OS og hardware-niveau end i hænderne på en ignorant udvikler.

Problemet er at der er en stor gruppe af udviklere som ser parallisme som noget "ultranørdet" og noget der sikkert bare giver problemer med race-conditions eller deadlocks og som derfor sætter deres lid til at Microsoft, Intel eller en af de andre store spillere nok løser problemet for dem på sigt (måske i 2035?), så de ikke behøver at sætte sig ind i det.

Det gør det selvfølgelig heller ikke bedrer at prominente personer i branchen nærmest fører skræmme-kampagne og erklærer at parallisme ikke er noget almindelige dødelige kan forstå.

Tag bare Bruce Eckel:

The problem is that currently, parallelism is virtually impossible to get right (I won't re-argue this here, I've done it elsewhere). While it's theoretically possible that a handful of experts exist that can deal with some level of concurrent complexity, there is always a limit to what those people can manage. And they are rare, and parallelism is becoming common.

Med den beskrivelse, hvem tør så give sig i kast med at sætte sig ind i det - det er jo tydeligvis kun noget for nogle få langhårede eksperter på verdensplan !?

Det er klart at det er et svært emne, men det er også et yderst spændende, interessant og uhyre relevant emne.
Hvis man ikke vil ende på B-holdet når det gælder fremtidens mange-core systemer, så er der ingen let genvej - så kræver det at man studerer, prøver sig frem og opbygger erfaring og ikke bare sidder tilbagelænet og håber på at nogle andre løser alle problemerne for en, så man slipper for selv at tænke.

Det grundlæggende problem er at alt for mange kaster sig ud i paralliserede applikationer i de her multi-core tider, uden at have læst op på lektion og med en gammeldags liniær tankegang i baghovedet og så er det ikke så pokkers underligt at resultaterne virker indeterministiske.

Du har hellerikke læst på lektien, da du tydeligvis ikke ved hvad parallelisme er. Parallelisme har intet med at gøre hvordan computeren fungerer. Når du i softwaresammenhæng har processer, der udføres i tilfældigt rækkefølge, så skyldes det at den tid de tager at udføre ikke er deterministisk. Din parallele process, har ikke som for hardware en forsinkelse der er eksakt eller indenfor et interval, men en tilfældig forsinkelse der afhænger af rækkefølgen som processerne afvikles i - og denne er tilfældig og kan afhænge af fugtigheden og temperatur af printet. Forsinkelsen er altså tilfældigt - og alt, som afhænger af forsinkelsen, bliver følgeligt tilfældigt! Det samme gælder i hardware - her har vi ofte en minimum og maximum tid for processerne, og det er tilfældigt hvor stor forsinkelsen er - men den er indenfor dette interval.

Om din computer udfører indstruktioner i rækkefølge, og gør det deterministisk, er ikke relevant. Som eksempel, er tidspunktet hvor tick-interruptet kommer tilfældigt, og den laves af en anden klokke end CPU'en - en smule støj, gør at du ikke kan spå om resultatet.

Og det har iøvrigt intet med C++ eller Windows at gøre, de tilbyder blot ikke ret meget hjælp - du skal selv tænke.

Der findes ikke parallelisme i C++ og Windows. Der findes en stokastisk parallelisme, hvor processerne tager tilfældig tid, og hvor at funktionen gøres afhængigt af denne tid, ved at tillade metoder, hvor resultatet afhænger af rækkefølgen for udførsel af processerne. Dermed kan resultatet afhænge af, om du puster på printpladen. Det kan måske flytte tidspunktet for et interrupt, og dermed resultatet. Du vil også se, at hvis du opstarter computeren, behøver svaret ikke at være det samme - selvom du indlægger dit program i start gruppen, og skriver resultatet ud på skærmen.
Skal du "simulere" PC-parallelisme, så skal du betragte processerne som havende tilfældig delay.

Nogle nyere sprog forsøger at udnytte parallisme uden at udvikleren behøver at kende til detaljerne eller behøver at vide at det sker.

Parallelisme har intet at gøre med PC'er, og deres kluntede afvikling af koden. Hvis du begynder at fortælle udviklerne "hvordan det sker", og gør at de skal tage højde for dette, når de koder - så kan du ikke lave om på, hvordan det sker. Du låser det fast, så du måske ikke kan sætte to reelt fysiske parallele processer til at udføre det, fordi at du har sagt til programmøren, at han skal da vide hvordan det fungerer, og det fungerer ved et tick der skifter process osv. Derfor er det netop en betingelse, at programmøren ikke skal behøve at vide dette - og den pågældende viden, må ikke kunne få programmet til at svare andet. For så vil det ikke være muligt at skifte hardwareplatform, og at scalere op.

Det er vigtigt, at programmørerne ikke behøver at vide et hak om hardware - for så kan vi ikke lave en ny CPU, der fungerer bedre. Hver gang, at du siger til en programmør, at han skal sætte sig ind i skidtet - så forhindrer du, at noget kan gøres bedre end nu. Du forhindrer, at dem der laver CPU'en, kan lave en ny, der fungerer bedre. Derfor, må programmører helst intet vide - for de forstår så lidt. Og lærer du dem noget - så lærer de det udenad, og tror at "det er parallelisme". Og det er det altså ikke. Det kan være farligt, at fortælle en programmør, at en CPU har registre - får så tror de vitterligt på det. Og det er ikke noget, som er mere forkert. De tager sku resultatet når det hænger i luften. Forsøger du så, at forklare dette, så forstår de ikke spor. Det er da noget, der hedder register transfer level. Gisp.

Hvis du kun forstår hvordan din kode virker på high-level niveau og ikke hvordan det reelt afvikles af operativsystemet og hardwaren, så vil du få problemer når du leger med samtidighed.

Nej! Kun, hvis du bliver påtvunget problemer, når du leger med samtidighed. Det er præcis som ved hardware - det afhænger af forsinkelsen gennem komponenten. Og, det man gør, er at gøre resultatet uafhængigt af forsinkelserne, - så virker det, selvom du skifter en komponent ud. Lavede vi HW så resultatet afhang af forsinkelserne i transistorerne, så vil resultatet blive meget dårligt. Man laver det sådan, at det enten er helt uafhængigt af forsikelserne, og har metoder dertil - eller man sikrer, at resultatet er det samme, og ikke tilfældigt, såfremt at forsinkelserne ligger indenfor bestemte intervaller, der kan garanteres for komponenten. Disse data, kan afhænge af spændinger, komponenttollerancer og meget andet. Men filosofien er, at man har metoder, så resultatet er identisk hver gang, og har deterministisk funktion. Uanset, vi ikke kender indholdet af chipsene. Jeg skal ikke vide indholdet af en black-box, for at kunne bruge den.

Hvis du har et programmeringssprog, hvor man skal læse om operativsystemet, og CPU'ens indmad, så er sproget godt nok langt ude. Fundementalt set, må man aldrig kende indholdet af en black box, og du skal kunne udskifte den, med en anden black box, der har andre egenskaber - såfremt de holder sig indenfor det som er specificeret for kassen.

Netop her, er der problem med parallel programmeringen som den sker i C++ under Windows. Resultatet afhænger af en uforudsigelig black-box karakteristika, der er forsinkelsen for den sorte kasse, og som afhænger af uforudsigelige forhold. Fordi at resultatet afhænger af noget uforudsigeligt, så er resultatet et resultat af det uforudsigelige, og dermed uforudsigeligt.

På computere, hvor "tick" interruptet blev lavet med samme klokke som CPU'en, og hvor alt blev resat ordentligt ved reset, vil man måske kunne opnå at tingene skete ens. Men, det vil ske forskelligt, hvis du udvider med mere cache, eller sætter en ny CPU i. Resultatet vil afhænge af hardware, og det må det per deffination ikke. Hvis det gør, deffinerer programmet simpelthen ikke funktionen. Og den giver ikke fejlmelding om, at den ikke er defineret.

For at et programmeringssprog er deterministisk, så må dens resultat ikke kunne afhænge af uforudsigelige informationer. Som eksempel på disse, kan nævnes indholdet i ram ved opdstart, CPU'en, hardware, ram størrelse, forskelle i krystal frekvenser, harddiskens opstartstid osv. Når at udførslen af processerne, afhænger af sådanne størrelser, så er det tilfældigt.

Det er ikke bare et spørgsmål om, at programmøren "bare" skal sætte sig ind i hvordan det fungerer. Det er et spørgsmål om, at dette vil udelukke hardwareingeniøren, kan lave sin processor om, og f.eks. øge cachen, eller lave om på måden den læses.

Software skal være 100% deterministisk. Og, det må ikke være muligt at skrive noget, der afhænger af tilfældige forhold.

Eneste tilfældige forhold, vi kan acceptere, er to uafhængige brugere, som har adgang til samme fil. Her, kan vi betragte det som ok, hvis resultatet afhænger af, hvem der får indtastet noget først.

OK jeg overgiver mig - jeg magter simpelthen ikke at svare igen på dit indlæg, jeg nøjes med at konkludere at vi vist kommer fra 2 forskellige planeter :-)