Apple skrotter Intel: Er klar med egne ARM-chips i år

Illustration: Apple

Hjernen i Apples computere skal skiftes ud i løbet af i år. Sådan lød det fra Apples topchef Tim Cook på Apples egen udviklerkonference WWDC i aftes dansk tid.

Dermed er det snart slut med Intels x86-platform, som bliver erstattet af Apples egenudviklede chips, der bliver bygget på det japansk-ejede ARM-design. Apple bruger allerede i dag ARM-chips i sine iPads og iPhones, der kører på styresystemet iOS, og fremover vil Apple altså også bruge ARM-baserede chips til at afvikle macOS-styresystemet til Mac-computere.

Den første ARM-baserede Mac bliver tilgængelig ved udgangen af 2020, og Apple forventer, at overgangen fra Intel til egne ARM-chips kommer til at tage to år, og i den periode bliver Apple ved med at frigive Intel-baserede computere.

Det er kun tredje gang i Apples 36-årige historie, firmaet har skiftet processor-arkitektur. Første gange var i 1990’erne, da Apple gik fra Motorola-chips til PowerPC, og igen i 2005 da Apple overgik til Intels x86-platform.

Skiftet vil i følge Apple betyde længere batteritider, og en ensretning af Apples to styressystemer, iOS til smartphones og macOS til Mac-computere.

Op til i dag har markedet for processorer groft sagt været opdelt mellem Intels x86-arkitektur og ARM-arkitekturen. x86 har været kendt for en bedre ydeevne, mens ARM-processorer er mere energieffektive, og derfor har en bedre performance pr. forbrugt watt. Det første er vigtigt, når man skal afvikle store tunge programmer i et datacenter eller på kontor-computeren, mens energieffektivt er vigtigere, når enheden kører på et batteri, f.eks. en smartphone, en tablet eller en robot.

Energieffektiviteten i ARM-processorer skyldes blandt andet en mere simpelt instruktionssæt, færre transistorer og en langsommere klokfrekvens.

Det betyder også, at ARM-chips for det meste er billigere end Intels, og de senere år er ARM blevet standardvalget til mindre enheder, f.eks. tablets, smartphones og letvægtsbærbare som Googles Chromebooks. Også mindre bærbare computere kører i dag på ARM, blandt andet modeller fra Microsoft, Samsung og Lenovo.

Læs også: Apple vil bruge ARM-processor i MacBooks: Kan starte chip-revolution

Uklar overgang

Overgangen rejser en række spørgsmål til både eksisterende Mac-computere og til potentielle købere. Det er endnu uklart, hvor længe Apple vil fortsætte med at understøtte og opdatere styresystemet macOS til Intel-baserede Mac-computere. Apple lover indtil videre at understøtte og frigive opdateringer til macOS for Intel-baserede Macs »i årene fremover«, men uden at sætte dato og årstal på.

På Twitter forsøger den engelske softwareudvikler Shahid Ahmad at slå koldt vand i blodet. Han fortæller at han købte en Mac baseret på PowerPC-chips i 2003 og den fungerede fint frem til 2011, altså seks år efter Apple annoncerede skiftet til Intel.

Apple har i praksis været i gang med overgangen i flere år, uden åbent at bekræfte det. Det er blandt andet flere år siden de stoppede med at understøtte 32-bit apps, som ikke kompatible med ARM’s 64-bit arkitektur. Til trods for mandagens udmelding, fortsætter Apple den kommende tid med at sælge Mac-computere med Intel-processorer, og her er det også uklart, hvor længe de computere kan bruges fuldt.

Læs også: Open source når processorerne: Det lysner i chippens sorte boks

Savner klare sammenligninger

Det er langt fra alle der er lige overbeviste om den bløde overgang. Bekymringen er især fokuseret på om de nye ARM-chips er i stand til at afvikle de mange professionelle applikationer til eksempelvis videoredigering og grafik, som Apple er kendt for. ARM-arkitekturen er især udbredt til mindre enheder som smartphones og tablets med fokus på energieffektivitet.

På udviklerkonference På WWDC viste Apple en emulator, Rosetta 2, der gør det muligt at afvikle applikationer der er udviklet til Intels x86-platform på de nye ARM-baserede MAC-computere. Den emulator kan altså bruges hvis man gerne vil køre et program som ikke er ‘oversat’ til de kommende ARM-baserede MAC-computere. Det var dog ikke mange detaljer der kom frem om Rosetta.

»Det er svært for mig at forestille mig en smartphone-baset mikroprocessor erstatte en Mac Pro som du lige har købt for 10.000 dollars( 66.000 danske kroner, red.). Jeg ville ønske at de havde vist nogle performance-sammenligninger,« siger Patrick Moorhead, stifter af analysevirksomheden af Moor Insights & Strategy til Wired.

ARM er ejet af japanske Softbank, og producerer ikke selv sine egne chips som Intel, men licenserer blot chip-designet – instruktionssættet – som andre så kan modificere. Der findes også andre processor-løsninger, f.eks. AMD’s x64 til bærbare og IBM's Power til servere, men de har begge mindre markedsandele. I fremtiden bliver det Apple selv der udvikler og designer sine egne chips, og så er det taiwanesiske TSMC der skal fremstille de ARM-baserede chips for Apple.

Læs også: Kunstig intelligens kræver helt nyt chipdesign

Emner : Chips
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først

Som jeg læser det, så er det kun i de bærbare computere de udskiftes - så mon ikke understøttelsen af Intel fortsætter en del år endnu.

Men det gør det så nok sværer at køre windows på sin mac i fremtiden.

  • 0
  • 1

Nej, HELE produktlinjen erstattes over de kommende 2 år. Det er det Apple meldte tydeligt ud på deres keynote i går.

  • 1
  • 0

Der laves meget 3. parts software til mac. Jeg tror de kan få problemer med at få alle til at kaste penge efter at udvikle nye versioner til den nye hardware.

Allerede nu er der jo en del software som virker anderlededes/dårligere på mac end på windows. Jeg fik f.eks. lige et brev ind i min eboks om at min søn er optaget på HTX her i byen. De forlangte direkte at han skulle bruge windows. Det var ok at have mac hardware, men der skulle være ledig plads til en windows partition. Et skift af processor platform vil jo stikke en solid kæp i den mulighed.

På den anden side set så er Apple velsignet med alletiders mest trofaste fanskare. De er meget tålmodige.

  • 1
  • 0

Nu er Microsoft jo heller ikke længere så tæt gift med Intel som de har været. De har længe arbejdet på og releaset ARM versioner af Windows 10 og deres office pakke, så teknisk set så burde man kunne køre ARM Windows på Apple boksene.

At jeg så selv stadig er glad for Intel (well nok mest AMD) er en anden sag, men der er nok ikke megen tvivl om at begge kommer under mere og mere pres.

  • 0
  • 0

Nu er Microsoft jo heller ikke længere så tæt gift med Intel som de har været.

Ja det er rigtigt, men typisk ligger problemerne i meget specialiserede stykker software. MS har jo nok en officepakke til ARM, men spiller den med alle de pakker som findes til Intel platformen. Det kan også være fusion360 f.eks. eller andre ting som lige nu er x86 windows only. Mange af de store spillere i software branchen er da ligeglade med at der findes en ARM platform. Hvis du vil bruge deres værktøjer, så har du værsgo at købe en wintel PC.

  • 0
  • 0

Hvorfor skifte fra X86 til ARM - tag dog skridtet, og gå helt væk fra ehnhver hardwareafhængighed. Så kan man blive ved at bruge den software man har, og endda lave hot-swap af CPU'en til et andet indstruktionssæt og fabrikat mens computeren kører. Eller sætte en FPGA i og køre softwaren på den.

Jeg syntes det er tåbeligt, at vi bliver ved at softwaren skal oversættes til en bestemt hardware. I sin tid, der var det så forbudt at kende til hvordan at hardwaren var lavet, at det var umuligt på nogen måde at få sådanne indformationer ud af softwaren på en computer. Softwaren kørte fint alligevel - bortset fra nogle få programmer der ikke kunne eksekveres. Der var problemer med benchmark tests, fordi de aflæste computerens hastighed, og det var forbudt viden. Ved at ganske enkelt forbyde viden om hardwaren, så kunne programmeringssprogene ikke misbruges, og anvende eller låse sig fast til nogen form for hardware. Alt hardware kunne bruges, og ingen vidste, hvor mange bits computerne havde, hvor meget ram de havde, eller hvor meget de kunne addressere. For det var umuligt at udlæse af nogen form for software. Det betød, at alt kørte. Efter det, er udviklingen så gået baglands, og år for år er hastighederne gået ned, paralleliseringen fastlåst så den ikke sker automatisk, og hver gang man vil anvende en ny CPU eller tråd i CPU'en, så skal man kode det i softwaren, fordi at softwaren åbenbart nu, i forhold til tidligere, skal bestemme hvordan at hver eneste detalje skal gøres. Førhen, var detaljerne hemmelige overfor programmører, så de kunne ikke specificere noget, andet end hvordan at koden skulle fungere. Fra det gode gamle system, er vi overgået til software diktatur, hvor softwarefolket dikterer hvordan at hardwaren fungerer ned i hver enkelt detalje, og de skal vide antal bits, de skal vide antallet af kerner, og de skal vide dit og dat, for at kunnne styre det. Det totale gøgl, i forhold til den gang, hvor software var software, og hardware var hardware, og softwarefolk hverken kunne eller måtte vide om hardware, for den var klacificeret hemmeligt, så der var totalt afkobling mellem software og hardware laget af hensyn til matematikkens sikkerhed.

  • 0
  • 8

Re: Hardwareuafhængighed C2H5OH ? eller CH3OH??

Jeg forstår ikke rigtigt, hvordan at kemi hører hjemme indenfor datalogi.

Er pi en fysisk konstant eller er det en matematisk konstant? Er elektronens ladning en fysisk konstant, eller en matematisk konstant? Er lysets hastighed en fysisk konstant, eller en matematisk konstant? Er e en fysisk konstant, eller en matematisk konstant? Datalogi er matematik, og ikke fysisk eller elektronik. Fysiske konstante og kemi tilhører ikke datalogien. Er tiden en datalogisk konstant? Må vi kunne få at vide fra et program, hvor lang tid at de enkelte indstruktioner tager? Må vi kunne få at vide, hvordan de enkelte bits er kodet? Må vi kunne få at vide, hvordan de enkelte pointere er kodet? Nej, det må vi ikke, for dette er fysiske konstante (elektronik), og ikke matematiske konstante. Eksempel: Typisk laver vi en computer med en data CPU, der laver beregningerne, og styrer rækkefølgen at koden eksekveres ved hjælp af flag. Vi har også en addresseberegner, der udregner addresserne som hukommelsen anvendes. Denne kører selvstændig, på en anden CPU end data CPU'en. Fordelen er, at denne kan køre hurtig, og gøre data parat fra ram lager og cache i god tid, fordi den kører foran. Imidlertid, så er addresser gemt i denne CPU, mens data er gemt i data CPU'en. Og det betyder, at vi fra vores program kun har adgang til data CPU'en, og ikke kan læse pointer addresser. Disse kører ganske enkelt på en helt anden computer, der leverer addresserne til os, men dog får flag fra data CPU'en. Dette er en anden grund til, at vi ikke kan læse pointere fra software. Datalogi er en matematisk deciplin, og derfor må vi ikke kunne læse fysiske konstante som elektronens ladning, lysets hastighed, avogadros tal, kemi, programmets hastighed, eller data der vedrører elektronikken og den elektroniske realisering, der er under den fysiske / elektronikkens verden. Dette medfører at et program ikke kender hardwaren, og vi kan til enhver tid udskifte hardwaren og dens hastighed, uden at programmerne ændrer opførsel. Det er et krav, at et program er deterministisk, og at der ikke er uinitialiserede variable, som kan medføre at der sker noget tilfældigt, der måske kan skyldes hardware tendenser. Forsinkelser i CPU'en, i datapaths, i ledninger, i busser, og andre steder, må ikke kunne betyde noget for resultaterne, og de må ikke kunne måles i software. Dette gælder også, når det er parallelt. Er der shared memory, så er det ikke lovligt, at der er tilfældigheder i, hvem der kommer først. Dette skal være explicit, og må ikke afhænge af interne data i den fysiske verden, f.eks. længde af printbaner. Men, det er tilladt at tidsstemple data ved inputs, og tidstemple hvornår outputs skal skifte, og tidsstemplede data kan bruges til at beslutte hvem der kommer først. Det medfører, at forsinkelse i ledningerne, ikke betyder noget for nogen tidsstempling, og derfor fungerer computeren deterministisk, da tidsstemplingen sammen med indputtets prioritet enentydigt afgør i hvilken rækkefølge at shared memory bruges.

Altså, en computer, ud fra et datalogisk synspunkt, må ikke kunne se, føle, eller opdage, hvordan at hardwaren fungerer. Den må ikke have kendskab til hardware konstante, f.eks. antallet af bits. Programmet specificerer hvilket område at en variabel anvendes, f.eks. fra -10.000.000.000 til +10.000.000.00, og der må ikke være nogle grænser for talområde, fordi at dette vil måske være en afsløring af hardwarens antal bits eller formåen.

Alle disse regler, er et udpluk af de regler som er for computere som fungerer.

Amerikanerne har dog haft meget svært ved at forstå dem, og dette har blandt andet medført at deres rumfærger er eksploderet. Indenfor datalogien, er altid ulovligt at kunne læse om der er data i en fifo, fordi at dette er et tilfældigt tal, der afslører i hvilken rækkefølge de interne tråde arbejder. Spørger man, er svaret altid, at der er data. Og hvis der så ikke er data, så schedulerer man arbejdsgangen, således at CPUens kraft anvendes på at frembringe data, fremfor at sige der ingen data er og knokle med det. Dette gør, at computeren bliver deterministisk, og ikke afhænger af dybde af fifoer. Det kan ganske enkelt bevises, at hardwaren fungerer uanset hvor dybt en fifo er dimmensioneret, men det er ikke altid at elastikken i softwaren er den samme. Det betyder intet for funktion, men kan betyde noget for, hvor hurtigt at kode afvikles. Hastigheden kan dog ikke måles i softwaren, da dette er ulovligt. Derimod kan tider specificeres, og hardwaren sikrer, at timingen opfyldes. At den opfyldes kan sikres ved at softwaren analyseres automatisk, før at den udføres.

Siden tidernes morgen, har computere og datalogi været abstrakt, og der har ikke været adgang til fysiske data i rigtige computere. Kun i mikrocomputere som oprindeligt var designet til spil, var det lovligt at kunne læse tilfældige data ud, der afhang af hvordan at computeren arbejde. Og i NASA's rumfærger, der brugte den offentliggjorte teknologi designet for spil.

  • 0
  • 6

Altså, en computer, ud fra et datalogisk synspunkt, må ikke kunne se, føle, eller opdage, hvordan at hardwaren fungerer.

Jeg tror den computer du tænker på er en Turing maskine. Den er anvendelig i abstrakt datalogisk tænkning men er ikke implementerbar og derfor heller ikke en god kandidat til at erstatte indmaden i fremtidige MacBooks.

Du lader til at blande begreber som registre og CPUer sammen så det er lidt svært at følge dit indlæg. En CPU har normalt både adresseregistre og dataregistre og har behov for at kunne beregne hvilke instruktioner der skal hentes og eksekveres. Der er ikke tale om separate CPUer.

Hvad er det for rumfærger du mener er eksploderet pga inflight computere?

  • 5
  • 0

Hastigheden kan dog ikke måles i softwaren, da dette er ulovligt. Derimod kan tider specificeres, og hardwaren sikrer, at timingen opfyldes. At den opfyldes kan sikres ved at softwaren analyseres automatisk, før at den udføres.

Det er, efter min overbevisning, i strid med halting-problemet som Allan Turing i 1936 beviste ikke kan løses med en Turing maskine.

Men igen, der er så mange fejl og misforståelser i det citerede indlæg at det nok er et af de mindste problemer.

  • 4
  • 0

Jeg tror den computer du tænker på er en Turing maskine. Den er anvendelig i abstrakt datalogisk tænkning men er ikke implementerbar og derfor heller ikke en god kandidat til at erstatte indmaden i fremtidige MacBooks.

Du lader til at blande begreber som registre og CPUer sammen så det er lidt svært at følge dit indlæg. En CPU har normalt både adresseregistre og dataregistre og har behov for at kunne beregne hvilke instruktioner der skal hentes og eksekveres. Der er ikke tale om separate CPUer.

Hvad er det for rumfærger du mener er eksploderet pga inflight computere?

Det som jeg argumenterer for, er at software og harwarelaget afkobles. Dette betyder, at du ikke fra softwarelaget må kunne se eller føle hardwarelaget. Og det betyder, at din kode altid fungerer, selvom hardwaren udskiftes. Som eksempel, må du ikke kunne finde ud af hvor hurtigt at CPU'en er, og skifter du din CPU ud med en hurtigere, så må programmet på ingen måde kunne ændre opførsel. Du må ikke kunne opdage hvor mange bits at computeren har - næste generation har måske færre bits, eller flere bits, og derfor må du ikke kunne se det fra din software. Og dit program skal kunne køre uanset hvor få, eller hvor mange bits din computer har. Du må ikke kunne måle eller opdage, hvor mange bits dine addresseregistre har. Der må ikke eksistere sådanne indstruktioner der gør det.

En afkobling mellem hardware og softwarelaget, således at software er abstrakt, medfører at de fleste programfejl udelukkes. Rigtigt mange fejl, specielt dem som der medfører ikke deterministisk opførsel, skyldes at der er fejl i datamaten. Vi kan tage et eksempel: I nogle sprog, kan du finde ud af at size of en pointer er 4. Dette er ulovligt. En sådan oplysning, må programmet ikke tilbyde kan udlæses. Det må ikke være muligt på nogen måde at spørge om, og ikke muligt at få svar på. For den er ikke 4 - jeg har nemligt lige fået et nyt datablad der siger den er 7.

Der gælder et sæt regler som skal være opfyldt, for at computere opfører sig deterministisk, og både er uafhængigt og kan bevises er uafhængigt af hardwaren, og er uafhængigt af de små interne forsinkelser som findes på computere. Disse regler, er utroligt vigtige, fordi at de er nødvendige, for at kunne lave robuste computere.

  1. januar 1986 eksploderer rumfærgen Challenger. Dette skyldes at man ikke brugte datalogiens regler for pålidelig hardware og kodning. Det medførte, at en fifo ikke var stor nok. Dette er umuligt, når man følger datalogiens regler. Uanset, at computerne bliver hurtigere, så er der taget hånd om alle problemerne. Der er garanteret 100% determinisme. Og det, at der ændres hastigheder, fifostørrelse, længde af printbaner, eller en klokfrekvens, betyder intet for determinismmen, og for at resultatet er korrekt. Bliver systemet mere sløvt, f.eks. nedsænkes en klokfrekvens, så kan det måske medføre at nogle data ikke kan komme ud til tiden. Derfor har man analyse programmer, der beviser at data kommer ud til det tidspunkt, som man har bedt om i sit program. Kan dette ikke bevises, så får man ikke lov at flyve.

Det, som jeg opfordrer til, er at man kasserer alle de deffekte akitekturer, som er i omløb i dag på grund af game-processor skandalen.

  • 0
  • 5

januar 1986 eksploderer rumfærgen Challenger. Dette skyldes at man ikke brugte datalogiens regler for pålidelig hardware og kodning.

Den holder altså ikke!

Citat: Det blev senere fastslået at ulykken skyldtes en defekt O-ring mellem to sektioner i en af faststofraketterne. Defekten opstod fordi O-ringen ikke kunne tåle frost. En stikflamme fra den defekte samling mellem faststofrakettens sektioner brændte hul i hovedbrændstoftanken og antændte brændstoffet heri.

Kilde: https://da.wikipedia.org/wiki/Challenger_(...

  • 6
  • 0

Det som jeg argumenterer for, er at software og harwarelaget afkobles. Dette betyder, at du ikke fra softwarelaget må kunne se eller føle hardwarelaget.

Og det er så i praksis umuligt med mindre du vælger, per lov, kunstigt at begrænse alt omkring hardwaren, som f.eks. hvor hurtigt den eksekverer koden, hvor megen hukommelse der er til rådighed, både intern og ekstern etc.

Det er (for andet end helt specifikke scenarier) totalt uladesiggøreligt, og vil i praksis sætte en stopper for udvikling af teknologi. Det kan så have andre fordele, men det er en anden diskussion.

Bytecode baseret kode som Java og .Net (men der har været mange andre) er et godt eksempel på et ønske om at abstrahere hardwaren væk. I virkeligheden så fungerer det ikke uden en hvis viden om hardwaren.

Eksempelvis, hvis du har masser af CPU kraft og saft, samt hukommelse, så behøver du ikke spekulere på at dine algoritmer måske kunne være lavet mere effektive. Men har du kun 1kb RAM i din hardware, så skal du godt nok tænke kreativt.

Jeg tror det ville gavne ungdommen at have oplevet 1970'erne og 1980'erne hvor de første computere som kunne købes af almindeligmand dukkede op. Da lærte man hvorfor der er de forskelle der er, og hvorfor hardware laget ikke er ligegyldigt.

Det svarer lidt til at sige... vi abstraherer underlaget vi bevæger os på, væk. Altså det er ligegyldigt om det er vand, asfalt, grus, is eller det tomme rum, min Insignia skal kunne transportere mig fuldstændigt ens fra A til B uanset underlaget.

  • 4
  • 0

Det er, efter min overbevisning, i strid med halting-problemet som Allan Turing i 1936 beviste ikke kan løses med en Turing maskine.

Men igen, der er så mange fejl og misforståelser i det citerede indlæg at det nok er et af de mindste problemer.

Både ja og nej. I visse tilfælde er det muligt at analysere. I nogle tilfælde er det ikke. Du kan godt kræve et bevis. Det som man gør, er at man regner på worst case. Jeg vil her skitsere en mulig simpel metode, men der findes mere komplekse, der er mere detaljerede. Det er meget lig den metode, som anvendes i programmeringssproget VHDL. Det kan også bruges i software. I princippet analyserer du koden, for at finde ud af, hvor lang tid den tager. Det er som regel nemt. Men, der kan være problemer - har du en løkke, og kender du ikke antallet af gange som den går igennem løkken, så kan man ikke sige hvor lang tid at løkken maksimalt tager. Derfor, så vil det medføre en fejl. Et program, hvor et maksimalt antal ikke kan findes, kan ikke analysers og oversættes.

Det er ikke korrekt, at der er misforståelser i mit indlæg. Men, du mangler sandsynligvis manglende viden om hvordan man laver stabile computere. I stedet for at læse bøger om computerteknik, vil jeg opfordre til, at du designer en computer selv, som ikke har problemer. Du skal leve op til følgende regler: 1. Du må ikke fra software kunne se hardwarens data eller oplysninger, for de er altid ukendte. Du må ikke kunne se antallet af paralelle processer. Dit program, skal fungere og din computer skal effektivt kunne anvende hardware resourcerne, uanset hardwarens konfiguration. CPU'ens hastighed, antallet af bits computeren anvender, antallet af CPU'er, indstruktionssæt, tråde, og addresserum må ikke på nogen måder kunne aflæses fra softwaren, for det fører til, at den ikke vil virke, da softwaren kan gøre computeren hardwareafhængig. Det er simpelthen et krav, at softwaren er deterministisk og fungerer, for så undgår vi at skulle føre beviserne der ellers skulle bevise disse ting. Du må ikke kunne lave en benchmark test. Alle indstruktioner tager, hvis der måles på dem ingen tid. 2. Softwaren skal være deterministisk, og må ikke afhænge af uinitialiserede variable eller andet tilfældigt. 3. Du skal sikre dig, at forsinkelser ikke kan medføre ikke deterministisk opførsel. Dette betyder meget i forbindelse med parallelisme. Parallelisme skal altid være deterministisk. Du må ikke kunne lave to tråde, og finde ud af, hvem der svarer først, da dette kan afhænge af interne forsinkelser og måder at hardwaren håndterer parallele tråde. Hvis du lærer om parallel programmering, så burde du lære noget om, at man aldrig må læse antallet af data i en kø, at det er ulovligt at kende køernes størrelse og længde, og at du ikke kan og må anvende data der kan afslører i hvilken rækkefølge, eller hvor hurtigt, at de parallele processor kører i forhold til hinanden. Du må ikke kunne lave to tråde, og afgøre hvilken der kommer først i hus.

Jeg kan ikke huske alle reglerne, men de spillecomputere vi får i dag, og som har været i handlen i mange år, har altid forsøgt at opnå det modsatte - at gøre det så fælt som muligt, at lave software der er i orden. Hele hardware og softwaremarkedet er en gang humor uden lige.

  • 0
  • 4

Og det er så i praksis umuligt med mindre du vælger, per lov, kunstigt at begrænse alt omkring hardwaren, som f.eks. hvor hurtigt den eksekverer koden, hvor megen hukommelse der er til rådighed, både intern og ekstern etc.

Det er (for andet end helt specifikke scenarier) totalt uladesiggøreligt, og vil i praksis sætte en stopper for udvikling af teknologi. Det kan så have andre fordele, men det er en anden diskussion.

Bytecode baseret kode som Java og .Net (men der har været mange andre) er et godt eksempel på et ønske om at abstrahere hardwaren væk. I virkeligheden så fungerer det ikke uden en hvis viden om hardwaren.

Eksempelvis, hvis du har masser af CPU kraft og saft, samt hukommelse, så behøver du ikke spekulere på at dine algoritmer måske kunne være lavet mere effektive. Men har du kun 1kb RAM i din hardware, så skal du godt nok tænke kreativt.

Jeg tror det ville gavne ungdommen at have oplevet 1970'erne og 1980'erne hvor de første computere som kunne købes af almindeligmand dukkede op. Da lærte man hvorfor der er de forskelle der er, og hvorfor hardware laget ikke er ligegyldigt.

Det svarer lidt til at sige... vi abstraherer underlaget vi bevæger os på, væk. Altså det er ligegyldigt om det er vand, asfalt, grus, is eller det tomme rum, min Insignia skal kunne transportere mig fuldstændigt ens fra A til B uanset underlaget.

Og det viser præcist, at du ikke har lært datalogi.

Nej, du behøver ikke at begrænse noget.

En rusisk professor forklarede det sådan: De studerende spurgte, hvor meget man kunne i Rusland før murens fald. Han svarede, at det vidste man ikke. Havde man en opgave, så var det reelt millitæret som stod for at fremstille chippen, eller køre programmet. Man specificerede hvad man have brug for, og så fik man svaret. Så spurgte den studerende så, ja man så hvorfor ikke bruge alverdens hukommelse, og uendelig høj klokfrekvens. Jo, det turde man ikke forklarede professoren. Det var sådan, at for at få en opgave kørt, så kom man først i forhør. Og desto større krav man havde, desto længere tid blev man forhørt. Og, var kravene store, så kom man i flere forhør, og hver gang blev det bag flere lukkede døre, og med flere bevæbnede vagter. Og mere end tre forhør, havde ingen lyst til. Det var ikke et spørgsmål om hvad man kunne. Men hvad man turde. Der var ingen nedre linjebredde for chipsene, og ingen maksimal klokfrekvens. Måske, var det fordi, at man i sovjetunionen ikke massefremstillede, og han forklarede, at der gik så meget tabt, når det skulle massefremstilles, at det syntes man ikke var sjovt.

  • 0
  • 5

Og det viser præcist, at du ikke har lært datalogi.

Nej, du behøver ikke at begrænse noget.

Ok.. så siger vi det ;)

Jeg tror at der er nogen der har fordybet sig lidt for meget i teori, og glemt at denne helst skal kunne omsættes til praksis for at det rigtig batter noget.

Det er et fænomen jeg har set mange gange før.

Gæt på hvilke projekter der lykkes og hvilke der ikke gør? Dem der har forståelse for teori og omsættelse af denne i praksis, eller dem der affærdiger praksis med at den må indordne sig?

  • 6
  • 0

Det svarer lidt til at sige... vi abstraherer underlaget vi bevæger os på, væk. Altså det er ligegyldigt om det er vand, asfalt, grus, is eller det tomme rum, min Insignia skal kunne transportere mig fuldstændigt ens fra A til B uanset underlaget.

Ja, det kan vi godt. Og du kan til vis grad også oversætte C++. Men, du får problemer med benchmark tests. Og det er stort set alt, du ikke kan køre.

Årsagen til, at benchmark test ikke kan udføres, ligger i reglerne for parallelisme.

Hvis der sættes krav til timing, så vil man altid tidsstemple data ved indgangen. Altså ikke ved CPU'en, men der hvor at den fysiske virkelighed er. Og, du vil også altid tidsstemple ved udgangen. Har vi et interrupt signal, så tidsstemples den når den kommer fra den fysiske verden, ikke når den når CPU'en. Forsinkelser i computeren må intet betyde. Timinig inde i CPU'ens kerne eksisterer ikke. Alle indstruktioner virker som de tager 0ns. Spørger du hvad klokken er, vil svaret altid være det tidspunkt, som computeren blev opstartet eller rettere da reset signalet kom ind. Holder du f.eks. et sekunds pause, så vil der blive lagt et sekund til tidspunktet. Selve indstruktioner tager altid 0ns. Normalt vil man ikke have delays i et program, fordi at delays indsætter en pause i alle tråde der går gennem delayet når at et sekventielt program udføres parallelt, og det er normalt en ulempe, så man vil hellere lægge den på dataflowet, f.eks. tidsstemple output og tidsstemple input. Spørger du en interrupt drevet process om tidspunktet, vil det altid være det tidspunkt, hvor interruptet fra den fysiske verden blev stemplet. Har du shared memory, så er det tidsstemplingen der afgør, i hvilken rækkkefølge at adgangen til lageret er. Det er ikke tilfældigheder, i hverken printlængder eller fifostørrelser, eller forsinkelser.

Når man ikke kan aflæse hastigheden ved en benchmark test, ligger det i reglerne for parallelisme. De fordrer, at du siger hvornår du aflæser uret, for at kunne aflæse det, og så får du det svar du beder om.

Man anvender ikke typer som byte, word, bits og lign. Disse typer er typiske hardwaretyper. De giver ingen mening. I stedet angiver man det interval som en variabel bruges, og dette interval kan være vilkårligt - ingen minimum og ingen maksimum.

Man kan godt have definerede typer som bytes, bits og lign. Og man kan godt definere bitvis hvordan de er defineret. Men det er definerede typer i koden, og det har intet med hardwaren at gøre. Det kan ske der skal tusindvis af linjer til at håndtere sådan en defineret type. I stedet så skriver man hvilket interval der bruges, og hardwaren bestemmre selv, om den anvender binært talsystem, redundant talsystem, gemmer det analogt, residuetal, eller hvad den finder er bedst.

Store O funktionen har stadigt en betydning. Selvom vi ikke ved hvor lang tid at noget tager, og ikke kan måle hastigheden af det, så kan det have betydning for, om at computeren overlever opgaven. Og, vi vil jo helst ikke stå med en bunke rygende dioder bagefter, fordi vi har specificeret den skulle komme med data tidligere end var muligt. Der laves derfor også analyser på softwaren inden den køres. Det er lidt surt at stå med en flok rygende komponenter, fordi man bad om, at få data ud et nanosekund for tidligt.

  • 0
  • 4

Jeg er som sådan ikke uenig i en del af din teori ud fra en filosofisk diskussion.

Men det kan, for nuværende, kun være en filosofisk diskussion, da det ikke vil give mening at min Insignia skal udvikles til at kunne agere lige så perfekt i det tomme rum som den gør på asfalten idag.

Derfor kommer virkeligheden ind i billedet. Der er en omkostning ved at abstrahere virkeligheden væk. Jo mere du vil abstrahere den væk jo større vil omkostningen være.

Den omkostning er der noget eller nogen der skal være villig til at "betale". Og det er der hvor virkeligheden ender med at slå teorien.

  • 2
  • 0

Jeg syntes det er tåbeligt, at vi bliver ved at softwaren skal oversættes til en bestemt hardware. I sin tid, der var det så forbudt at kende til hvordan at hardwaren var lavet, at det var umuligt på nogen måde at få sådanne indformationer ud af softwaren på en computer. Softwaren kørte fint alligevel - bortset fra nogle få programmer der ikke kunne eksekveres. Der var problemer med benchmark tests, fordi de aflæste computerens hastighed, og det var forbudt viden. Ved at ganske enkelt forbyde viden om hardwaren, så kunne programmeringssprogene ikke misbruges, og anvende eller låse sig fast til nogen form for hardware. Alt hardware kunne bruges, og ingen vidste, hvor mange bits computerne havde, hvor meget ram de havde, eller hvor meget de kunne addressere. For det var umuligt at udlæse af nogen form for software. Det betød, at alt kørte. Efter det, er udviklingen så gået baglands, og år for år er hastighederne gået ned, paralleliseringen fastlåst så den ikke sker automatisk, og hver gang man vil anvende en ny CPU eller tråd i CPU'en, så skal man kode det i softwaren, fordi at softwaren åbenbart nu, i forhold til tidligere, skal bestemme hvordan at hver eneste detalje skal gøres. Førhen, var detaljerne hemmelige overfor programmører, så de kunne ikke specificere noget, andet end hvordan at koden skulle fungere. Fra det gode gamle system, er vi overgået til software diktatur, hvor softwarefolket dikterer hvordan at hardwaren fungerer ned i hver enkelt detalje, og de skal vide antal bits, de skal vide antallet af kerner, og de skal vide dit og dat, for at kunnne styre det. Det totale gøgl, i forhold til den gang, hvor software var software, og hardware var hardware, og softwarefolk hverken kunne eller måtte vide om hardware, for den var klacificeret hemmeligt, så der var totalt afkobling mellem software og hardware laget af hensyn til matematikkens sikkerhed.

Kan du give eksempler på hvilke systemer du tænker på og hvilke problemer de løste?

  • 4
  • 0

Gæt på hvilke projekter der lykkes og hvilke der ikke gør? Dem der har forståelse for teori og omsættelse af denne i praksis, eller dem der affærdiger praksis med at den må indordne sig?

De projekter der lykkedes bedst, er dem der har forståelse for teori, og omsættelse af denne til praksis. At udvikle computerne, så du ikke kan se hardwarens specifikationer fra softwaren, er et eksmpel på sådan en opgave. Desto bedre det skal gøres, desto sværre er opgaven - f.eks. skal du kunne udskifte hardwaren med enhver anden, endda når computeren kører. Og du skal kunne sætte flere CPU moduler i, endda af forskellig fabrikat og med forskellig indstruktionssæt, og den skal automatisk parallelisere dit software, og finde den hardware, som koden kører bedst på. Dette er ikke en simpel opgave. At parallelisere opgaverne er en del af det, at løse programmerne gøres ofte samtidigt, og hvis du f.eks. beder computeren udregne summen af alle tal fra 1 til 2 i 2048 får du svar på meget kort tid. Efter en opgave er paralleliseret, bliver den placeret i den pågældende hardware og denne mapning er svær. Det kræver analyse af, hvilke parallele opgaver der er mest vigtigt at få udført, blandt andet med henblik på at øge parallelismen, men også ud fra, hvad at det er behov for prioritetsmæssigt og tidsmæssigt. Normalt, vil man sætte forskellige prioriteter på enheder der er tilkoblet,f.eks. vil en brugerterminal have større prioritet end en printer, da at brugeren sidder og venter, men først venter på en udskift, når der bedes om den. Og så opprioriteres printer processen.

Det, som er problemet, er alle dem der bare indordner sig med praksis. Det er på tide, at vi gør oprør.

  • 0
  • 3

Kan du give eksempler på hvilke systemer du tænker på og hvilke problemer de løste?

Det problem som løses, er at du ikke risikerer at noget ikke fungerer, eller ændrer opførsel, hvis du øger en CPU's hastighed, øger mængden af ram, øger antallet af bits der kan addresseres, eller på andre måder øger computerens specifikationer. Du sikrer også, at den arbejder deterministisk, og at et program ikke pludseligt går død. Der tages højde om bufferstørrelser, og du risikerer ikke, at løbe ud af buffer. Alt er altid deterministisk. Alle muligheder, der kan medføre indeterminisme er umulige.

Som eksempel har du ingen volatile problem i C++. Og der er ikke problemer med, at du kan "glemme" noget, som så medfører ustabil kode. Der findes ingen ustabile interrupt rutiner, selvom interrupts ikke er et problem, og betragtes som en tidsaktiveret eller dataaktiveret parallel process. Ustabil kode, kan ganske enkelt ikke oversættes. Du kan ikke risikere, at gemme data af forskellige typer ovenpå hinanden. Og du kan ikke risikere, at der opstår problemer, fordi at din hardware laver word allign.

Simpelthen alle problemer, der på en eller anden måde skyldes timing problemer, hardware ændringer, eller andet er umuligt at udføre.

Selvom man ikke har en CPU der er designet til at være sikker, så er det meget godt at kunne teknikkerne, f.eks. indenfor parallel programmering. Designer vi en database, og har mulighed for, at flere kan få adgang til samme data, så risikerer vi at det er tilfældigt, hvem der først får adgang ved skrivning. Derfor, så skal vi ikke få adgang til shared memory, uden at det tidsstemples ved input på tastaturet. På den måde, så er resultatet deterministisk bestemt, ud fra rækkefølgen som det tidsmæssigt er indtastet, også selvom computerne er på hver sin side af kloden. Der findes ganske enkelt ingen tilfældigheder, med mindre man sætter computeren til game-mode, og beder om at få adgang til tilfældighedsgenerator.

  • 0
  • 4

Desto bedre det skal gøres, desto sværre er opgaven - f.eks. skal du kunne udskifte hardwaren med enhver anden, endda når computeren kører.

Vi er enige om første sætning, men 2. sætning er hvor kæden hopper af. For at blive i bil analogi verdenen, så svarer det til at du har en bunden opgave, at fragte en maskine på 100tons i et stykke fra A til B på en given tid. Hardwaren er fragt mekanismen.

Så kommer der en som synes det giver mega megen mening, at udskifte den eksisterende dyre hardware (som kan håndtere fragten) med en 2CV hardvare.

Så er dit ønske at de 100tons skal fragtes lige så elegant fra A til B med en 2CV?

Den fuldstændige abstrahering kan IKKE lade sig gøre i verden som den er i dag, og mange år frem.

Du kan godt vælge at abstrahere nogle ting væk... f.eks... hjulene... Det er ligegyldigt om det er et rødt eller et blåt hjul der sidder på fragthardwaren, sålænge at det overholder visse specs, hvorimod det nok ikke er smart at forsøge at abstrahere chasiet væk, således et hvert andet chasi kan plugges ind. Det vil give noget ekstra arbejde til erstatnings advokater.

Og du skal kunne sætte flere CPU moduler i, endda af forskellig fabrikat og med forskellig indstruktionssæt,

Det gøres allerede idag... det hedder at afvikle vores gøjemøj i skyen.

og den skal automatisk parallelisere dit software, og finde den hardware, som koden kører bedst på.

Paralleliseringen er jo noget som der er forsket enormt meget i. Det er jo ikke fordi det ignoreres. Men det er bare fantastisk svært at automatisere noget uden at sætte en hulens masse regler op omkring det. Derfor der findes programmerings metodikker hvor udvikleren giver hints til compiler etc. hvad der kan paralleliseres og hvordan.

Dette er ikke en simpel opgave.

Det har du netop helt ret i. Det er faktisk en rigtig svær opgave, specielt når det er mennesker der bestemmer hvad noget kode skal kunne. Det stiller nemlig krav til fuldstændig forståelse ikke kun af koden, men også af formålet med koden. Så der er et godt stykke vej før vi er der. Vi når nok virtuelle AI præsidenter først, det kræver trods alt ikke så store intelligens mæssige resourcer.

Det, som er problemet, er alle dem der bare indordner sig med praksis. Det er på tide, at vi gør oprør.

Du kan lave alt det oprør du vil. Det ændrer ikke på virkeligheden. Virkeligheden er at der har været forsket (og bliver forsket) enormt meget i computer assisteret og computer automatiseret programmering. Virkeligheden er også at det, bortset fra forholdsvis simple ting, stiller store krav til problem forståelse, og lige netop der er AI ikke fantastisk langt. Vil det ske en dag?... formentlig, men jeg er nu ikke sikker på at resultatet nødvendigvis bliver exponentielt bedre end hvad mennesker laver idag. Tværtimod kunne jeg godt forestille mig at det bliver yderst vanskeligt for et menneske at gennemskue den, af computeren, valgte kode generering, hvilket forekommer mig at være en særdeles ubehagelig trussel.

  • 2
  • 0

Så er dit ønske at de 100tons skal fragtes lige så elegant fra A til B med en 2CV?

Den fuldstændige abstrahering kan IKKE lade sig gøre i verden som den er i dag, og mange år frem.

Programmets funktion kan godt være den samme, men det er korrekt, at hastigheden kan være forskelligt. Sættes derfor krav til hastigheden, er ikke sikkert at det er muligt.

I dag er også problemer, når vores CPU'er bliver hurtigere, og hukommelserne større, og her kan vi gøre noget for at undgå det kan give problemer. Mest sikkert, er at softwaren ikke ved hardwaren skiftes. Det giver alligevel ingen mening at softwaren skal kende hardwaren.

Under alle omstændigheder, er det et problem, at vores computere - og ikke mindst mange programmeringssprog - ikke er designet med henblik på determinisme og uafhængighed af computerens konfiguration.

Jeg frygter, at ændringen fra x86 til ARM kan give problemer for softwaren, uanset at ARM processoren måske er hurtigere. Og sådan behøvede det ikke at være. Vi burde kunne vælge CPU som vi vil, forudsat at den er hurtig nok til at løse opgaven, og vi burde kunne blive forsikret, at f.eks. et regnearksprogram arbejder deterministisk, og ikke laver et kreativt bogholderi.

  • 0
  • 3

Så kommer der en som synes det giver mega megen mening, at udskifte den eksisterende dyre hardware (som kan håndtere fragten) med en 2CV hardvare.

Så er dit ønske at de 100tons skal fragtes lige så elegant fra A til B med en 2CV?

Hvis der i koden ikke er specificeret nogen timing, så vil det fungerer, men måske køre langsommere. Dette vil dog ikke medføre nogen fejl, hvis koden ikke kræver at en deadline opfyldes.

Er softwaren elegant, så fragtes 100 tons måske også ligeså elegant med en 2CV. Indenfor software, findes mange trix, så fragten reelt ikke fragtes, men man kun fragter fragtpapiret.

  • 0
  • 2

Hvis der i koden ikke er specificeret nogen timing, så vil det fungerer, men måske køre langsommere. Dette vil dog ikke medføre nogen fejl, hvis koden ikke kræver at en deadline opfyldes.

For en hel del applikationer er det mindre vigtigt om det tager 1 sekund eller 10 sekunder at udføre en opgave. Men for mange andre er tidsfaktoren yderst kritisk.

For andre applikationer gør det heller ikke noget om der kun er 1GB RAM eller 32GB RAM for de bruger aldrig mere end få MB, men for andre er det helt essentielt at der er storage nok (ekstern og intern) til at processere et stort datasæt.

I sådanne scenarier HAR hardwaren en signifikant indflydelse.

I dele af spil branchen er man yderst vel orienterede omkring hvordan man vrider den sidste performance ud af den nyeste tilgængelige hardware. Der går man fra tid til anden så tæt på hardwaren som man kan for at opnå den maksimale ydelse. Andre spil er fuldstændig ligeglade om hvor mange abstraktionslag der måtte være mellem dem og de pixels der vises på skærmen.

Men prøv at overbevis 3D shooter spillere om at det er ok, at der lige er et par msecs ekstra lag. Til gengæld kan de også afvikle spillet på en anden CPU arkitektur, uden at udvikleren af spillet behøver at rekompilere det.

Jeg kan garantere at slutbrugeren ikke vil være tilfreds. Om så spillet skal skrives fuldstændigt om for at kunne køre på en anden platform, så er det det brugeren vil kræve, for at opnå den bedst mulige udnyttelse af sin hardware.

Brugere af simulerings software af enhver slags, vil ofte ikke have den store lyst til at skulle have alt for mange abstraktionslag. De vil have det fint med at der er et vist abstraionsniveau, men ikke at alt er abstraheret helt væk, da performance også har en værdi for dem.

Det er muligt der kommer et tidspunkt hvor computerne er så afsindigt hurtige og har storts et ubegrænsede storage muligheder, hvor man derefter overhovedet ikke skænker optimering en tanke.

Jeg tror bare det kommer til at ligge meget langt ude i fremtiden.

Selvom super computere i perioden 1960ish til 2020 er blevet ca. 1 trillion gange hurtigere (500Kflops til 537Pflops), så er vi stadig istand til at bruge al deres computerkraft, og hungrer stadig efter mere.

Det samme gælder storage, omend jeg tror vi trodsalt kommer tættere og tættere på et mætningspunkt i forhold til behovet for transient storage.

  • 0
  • 0

For en hel del applikationer er det mindre vigtigt om det tager 1 sekund eller 10 sekunder at udføre en opgave. Men for mange andre er tidsfaktoren yderst kritisk.

For andre applikationer gør det heller ikke noget om der kun er 1GB RAM eller 32GB RAM for de bruger aldrig mere end få MB, men for andre er det helt essentielt at der er storage nok (ekstern og intern) til at processere et stort datasæt.

I sådanne scenarier HAR hardwaren en signifikant indflydelse.

Vi er helt enige, og det du skriver går ikke imod det som jeg skriver. Hvis der er specificeret en timing, og kan denne ikke opfyldes, så er risiko for, at programmet må afvises at køre. Du bliver derfor nød til, at have en computer der er kraftig nok, for at kunne opfylde den timing som er specificeret. Dette betydder dog ikke, at du fra computerens side, er i stand til at kunne få oplysninger om hardwaren ud af din kode. At hardwaren har en siginfikant indflydelse, betyder ikke at du i dit program skal kunne læse dette. Din kode skal gerne være fremtidssikker, og kunne køre på fremtidige arkitekturer, og du ved intet om hvordan at disse fungerer, eller gemmer dataene. Du kan sætte krav til timing, og måske vil dit software blive afvist, hvis det du kræver ikke opfyldes af computeren. Du ved ikke hvad hardwaren kan eller hvordan den fungerer, men desto større krav du stiller, desto større er risikoen for, at din kode bliver afvist.

  • 0
  • 3

Det er muligt der kommer et tidspunkt hvor computerne er så afsindigt hurtige og har storts et ubegrænsede storage muligheder, hvor man derefter overhovedet ikke skænker optimering en tanke.

Og der er også muligt, at en del af optimeringen flyttes til hardwareabstraktionslaget. Fremtidens computere, vil ikke kun sørge for at parallelisere opgaverne i dette lag, og at sekventialisere de paralleliserede opgaver, men også at behandle dem, så at koden optimeres. Måske vil fremtidens computere selv reducere store O funktionerne ned, så de bliver langt mindre. Et godt eksempel, er eksemplet hvor vi finder summen af alle tal fra 1 til 2 i 2048. Her kan man f.eks. skrive det som en række løkker, der gennemløbes to gange, inde i hinanden. Og opgaven løses nemt indefra. Da algorithmerne er i familie med balanceringen af paralleliseringen, så er det nemt at implementere. Fremtidens computere, skal vi se som problem løsere, ved at de løser programmer, og ikke computere der udfører kode, med et eller andet cycles for en indstruktion. En anden ting, der har betydning for hvor optimal at koden bliver, er den måde som compilerne fungerer. Stiller compileren funktionaliteter til rådighed, der løser typiske opgaver optimalt, så er det langt nemmere at sikre sig, at koden er optimal. Desto højere niveau, at programmeringen fungerer, og desto mindre vi skal specificere i detaljer, desto mere nemt er det, at bruge faste optimale metoder, som vi ved ikke kan gøres bedre. Eller, at behandle koden, og optimere den. I dag gør man ofte det, at man forsøger at indse hvad at kode gør, ved at analysere den, og så slå det op i store kataloger over hvordan problemerne løses, hvordan at opgaven løses optimalt. Gængse konstruktioner, der almindeligvis kodes åndsvagt, bliver derved hurtigt kodet optimalt. Nogle gange, kan man blive overrasket over, at tåbeligt og dårligt optimeret kode går hurtigere, end ens egen optimale, fordi at computeren eller compileren finder ud af hvad koden laver. Er det en gængs måde at kode tåbeligt, så står den i kataloget.

  • 0
  • 4

Et godt eksempel, er eksemplet hvor vi finder summen af alle tal fra 1 til 2 i 2048. Her kan man f.eks. skrive det som en række løkker, der gennemløbes to gange, inde i hinanden.

Man kan også tænke sig en smule om og erindre hvad allerede Gauss vidste:

a=2**2048; print(a*(a+1)//2)

522194440706576253345876355358312191289982124523691890192116741641976953985778728424413405967498779170445053357219631418993786719092896803631618043925682638972978488271854999170180795067191859157214035005927973113188159419698856372836167342172293308748403954352901852035642024370059304557233988891799014503343469488440893892973452815095130470299789726716411734651513348221529512507986199933857107770846917779942645743159118957217248367043905936319748237550094520674504208530837546834166925275516486044134775384991808184705966507606898412918594045916828375610659246423184062775112999150206172392431297837246097308511919411459658460916516275128388139287031639186433706843172649681552765665167176485407416810390904144294236366434040516739738455036275051236444679629608791186852451880823546275470766576036962084586009663349889486777984897170803007721972358521389546088941763660385929677807264976523178693594619299151020033656115128594915199395160328438284015166484040013151289690978936900875065247697241542565934354230159918183452136337095790645261574579360261746238075035455059100025373721570856630568171033987937658200940804173551819277637011822685739542270608413789928313531108409313472180603783050108319194119218680280975731375210496

  • 4
  • 0
Bidrag med din viden – log ind og deltag i debatten