Moore's lov er bagud

Der kører en debat blandt visse klimaforskere for tiden, som nogenlunde kan koges ned til om der burde startes et internationalt projekt "på skala med CERN" for at komme et skridt videre med klimamodellers opløsningsevne.

Problemet er primært at der er så forbandet meget vand: 1.335 (±1%) mia kubikkilometer for at være præcis.

I den nuværende generation af klimamodeller bliver oceanerne modelleret "parametrisk" eller som, i forhold til energiindholdet, alt for store terninger.

Det er formodentlig en primære årsag til at klimamodellerne er ca. 10år for konservative, den slags vejr vi ser nu dukker først op i modellerne omkring 2030-ish.

Det er en klar forbedring, de plejede at være ca. 20 år for konservative.

Der er langt fra enighed om hvor store terningerne optimalt bør være, men ret meget enighed om at kubikkilometer er for stort til at nytte noget.

Hvis man tager samme filosofi som med CERN og siger at det overordnede mål er en forbedring med en faktor 10, får man, lidt afhængig af hvordan man regner mellem 13 og 40 milliarder terninger at holde styr på og ikke i nogen simpel geometri, f.eks ville mange danske fjorde skulle "minecraftes".

De nuværende TOP-500 supercomputere ligger og roder omkring 5-10 millioner CPU cores og de ville have svært ved at køre sådanne klimamodel hurtigt nok til at det ikke var både billigere, hurtigere og mere præcist at kigge ud af vinduet.

Hvis det nye projekt skal nytte noget, skal planlægningen begynde ved 100M CPU cores i første generation og 1 milliard cpu-cores indenfor 10-20 år.

Vi er naturligvis ude i chips der er designet til opgaven, ingen grund til at spilde plads på USB porte og andet gejl, men selv med de areal-reduktioner det måtte medføre er det stadig ufattelig mange kvadratmeter silicium vi taler om.

I tommelfingre kan man regne med 100 cores per kvadratcentimeter silicium og ca. 1000 sådanne chips per 45cm wafer, hvilket giver ca. 1 million "wafer-starts", hvilket er i omegnen af hvad et moderne "fab" kan klare på et år: ca. en wafer hvert 30. sekund.

Men det var kun CPU'erne, vi skal også bruge RAM: Her er båndbredden det altafgørende, så mindre end 16 8-lane chips kan dårligt gøre det per CPU-chip.

Der skal med andre ord bygges en "fab" dedikeret til projektet for der er overhovedet ikke ledig kapacitet i den størrelsesorden i markedet.

CERN brænder ca. 10 mia kroner af hvert år.

Så hvis vi laver et "CERN-størrelse" projekt går de første 10 år med at spare sammen til fabrikken der skal lave de nødvendige chips.

Dertil kommer så interconnects, printplader, metalsløjd, kabler og elregningen.

Så vi taler ikke om et projekt "på størrelse med CERN", men om et 10-15 gange større projekt.

... til en samlet pris i nabolaget af hvad denne måneds oversvømmelser ender med at koste.

phk

Kommentarer (39)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Glenn Møller-Holst

Hej Poul-Henning

Var det noget?:

21. apr 2021, ing.dk: Verdens største: Ny monsterchip med 2.600 milliarder transistorer: Citat: "... Glem alt om mikrochips og mobile processorer. Den amerikanske chipvirksomhed Cerebras har netop lanceret sin anden generation af chippen Wafer Scale Engine (WSE), og det betyder mere end en fordobling af antallet af transistorer - fra 1.200 milliarder til 2.600 milliarder - på samme fysiske wafer. I alt består chippen af 850.000 kerner. Til sammenligning har verdens største GPU, NVIDIA's nye Ampere-based A100 54,2 milliarder transistorer. ... Den nye gigantiske chip skal især bruges til High Performance Computing-klynger, bedre kendt som supercomputere, og Cerebras WSE-2-chippen er på vej i drift hos blandt andet amerikanbske Argonne National Lab, Edinburgh Parallel Computing Centre og Lawrence Livermore National Lab. Også medicinalproducenten GlaxoSmithKline bruger chippen. ..."

  • 0
  • 0
#2 Poul-Henning Kamp Blogger

Var det noget?:

Det er et meget, meget gammelt koncept og selvom det har mange attraktive aspekter har det endnu aldrig lykkedes nogen at få det til at virke i praksis, herunder økonomisk.

For det første er der yield problemet: Sandsynligheden for produktionsdefekter skalerer lineært med arealet af chippen og det er meget, meget sjældent at en wafer har 100% "yield".

Det er bla. derfor AMD sparker Intels røv for tiden: Deres små "chiplets" har meget bedre yield end Intels store integrerede klodser og for det ikke skal være løgn kan AMD stadig sælge dem til konsummarkedet, selvom op til ca. 55% af arealet ikke virker.

Dengang jeg var i Bay Area var der kun firmaet "Wafer Scale Integration" tilbage, vist nok fordi de havde en masse patenter som investorene stadig håbede ville blive The Next Big Thing.

En af de presentationer jeg så, handlede om at lave små metalbroer således at man kunne stakke hele wafers og få en "3D-grid". Direkte adspurgt indrømmede han at deres yield var "noget under 50%".

Det næste problem er power & køling, herunder at defekte processorer skal kobles ud, således at eventuelle kortslutninger i dem ikke suger energi.

Det forudsætter at power-routingen på chippen først lægges ned efter tests, hvilket igen betyder at power-rail per definition skal ligge øverst. Det er som et minimum ret uøkonomisk.

Med typisk op til 10-15% af processorene der ikke virker, må arkitekturen af en WSI computer må derfor enten have noget temmelig komplex routing-logik for at kunne kompensere for de ubrugelige processorer, eller også skal højniveau arkitekturen kunne arbejde uden om dem.

Der blev forsket meget i den slags med InMos's Transputere, men man havnede nærmest per definition i de allerede kendte problemer med pakke-routing i almindelige computernetværk. (Cascading overload osv.)

Så ja, lidt ligesom fusionsenergi ville det være fantastisk hvis WSI "bare virkede" men det er der ikke mange der tror på længere.

  • 18
  • 0
#3 Morten Nissen

Selvom modellerne bliver mere nøjagtige er der vel ingen tegn på at noget vil sige: puha vi har ikke er problem.

Mig bekendt er der stadig bred enighed om problemer. Det eneste vi kan diskutere er hvor hurtigt og hvor slemt.

Tror ærligt ikke klimaet har brug for eb super computer men mere handling.

  • 18
  • 0
#5 Nis Schmidt

10 års Moore's lov er godt 100x (OK 101,125).

AMD har dobbelt så meget L1$, det kunne også forklare lidt? IBM's z-serie kører med dobbelt så meget igen, men til lidt andre priser.

Så hvis programmørene nu vidste hvordan man skriver kode, der kører 100 gange hurtiger?

  • 1
  • 0
#7 Poul-Henning Kamp Blogger

Det er mig bekendt kun en enkelt rusisk model der giver gode resultater.

Hvis det er den model jeg tænker på, siger det ret meget om hvad du mener med "gode resultater" :-/

Klimamodellerne gør det objektivt fantastisk godt, hvad du personligt kan eller ikke kan lide af resultater er helt ligegyldigt.

At de gør det så godt som de gør, skyldes utvivlvomt at der er en masse stabiliserende negative feed-back mekanismer i biosfæren, sikkert også mange vi ikke kender endnu.

Men det er absolut ingen undskyldning for at lave uoprettelige experimenter med life support delen af det eneste rumskib vi har.

  • 31
  • 3
#8 Casey M.

Mig bekendt tager man gennemsnittet af temperaturprognoserne fra samtlige klimamodeller, og det rammer nogenlunde rigtigt. Men modellerne hver især pisser ved siden af, kort sagt, og efter sigende er det ikke er optimalt bare at tage gennemsnittet af samtlige klimamodellers output.

"Men det er absolut ingen undskyldning for at lave uoprettelige experimenter med life support delen af det eneste rumskib vi har."

Der er heller ingen undskyldning for at prøve at løse et problem der ikke er der eller er stærkt overdrevet, og i det forsøg at gøre det hele meget værre.

  • 4
  • 26
#9 Poul-Henning Kamp Blogger

Mig bekendt tager man gennemsnittet af temperaturprognoserne fra samtlige klimamodeller, og det rammer nogenlunde rigtigt.

Det er lidt mere indviklet end som så og generelt fokuserer man på medianen frem for gennemsnittet, men ja: Ved at køre mange kørsler med mange modeller, håber man at få et bedre billede af hvad der sker.

Det forandrer dog ikke på at det overordnede billede stadig er at klimamodellerne "er bagud" i den forstand at fænomener vi ser i real-tid først dukker up med årtiers forsinkelse i modellernes kørsler.

Specielt er "ekstremværdistatistik" hård ved deres evner. (se evt: https://ing.dk/blog/et-extremt-guldkorn-122964)

  • 12
  • 3
#11 Poul-Henning Kamp Blogger

Og hvad vil hele den indsats betyde af udledt CO2, der angiveligt forværrer det man vil regne på?

Meget, meget lidt.

I forhold til mange andre ting vi har bygget vil det stadig være i småtingsafdelingen.

Overvej en rundtur på en moderne bilfabrik næste gang du har chancen og prøv så at estimere hvor mange 19"-racks du kunne have på den plads :-)

Men hvis man lavede et projekt af den kaliber, og med det formål, er det næsten 100% sikkert at det ville blive placeret på Island hvor man kunne drive det med geotermisk energi og lave frikøling.

  • 9
  • 1
#12 Chris Bagge

det ville blive placeret på Island hvor man kunne drive det med geotermisk energi og lave frikøling.

Der er store geotermiske anlæg på Island, men de rigtigt store energianlæg er vandkraft. Det er der de store aluminimumsanlæg får deres strøm fra. Det vand der kommer op fra en geotermisk boring er ganske korrosivt og indeholder store mængder silica. Ja, energien er der, men er der vil nok være et voldsomt slid på et sådant anlæg. Anlægget "Blue Lagoon" er oprindeligt bare spildevandsdammen for et geotermisk anlæg der især leverer fjernvarme ti Reykjavik.

  • 4
  • 0
#14 Jari Wiklund

Umiddelbart kan jeg kun se to politiske motivationer: beslutningsudsættelse (vi må vente på >CERN krystalkuglen er klar, før vi kan beslutte noget på et tilstrækkeligt oplyst grundlag) Eller et strategisk tech/suverænitets fremstød ved at bygge en 100mia fab i Europa. Jeg er bange for at politikerne i bund og grund ikke magter en så stor opgave som rette op på systemisk kulbrinteafhængighed.

  • 2
  • 0
#17 Nis Schmidt

Det videnskabelige princip tilsiger at eksperimentet skal kunne gentages af andre.

"Bagsiden af en kuvert regnestykker" og de tilhørende tankeeksperimenter er altid spændende- Her starter vi med 100M cores på et areal, der 10 år senere (afhængig af fortolkning af Moore's lov) kan rumme mellem 3000 og flere mia cores.

Men faktisk synger Moore's lov på sidste vers og scenen vil i nær fremtid være overtaget af bedre programmering. MIT-kursus 6.172 = Software Performance Engineering eller se artikel her fra sidste år (vistnok), som beskriver indholdet af kursets lektion 1: "forskere kører standard program 60000 gange hurtigere".

I 2004 udtalte en tidligere DTU-professor af forskellen på langsom oh hurtig kode kunne være op til 4000 gange. Det er 17 år siden og flere speeds up er blevet nulige på den tid. Moore's lov er blevet overhalet siden da. Selvom der er grænser for hvor små "features" kan blive, i de nukendte teknologier!

Men indenfor 10 år vil man kunne bygge lige så hurtige mskiner, der fylder 30 gange mindre. Det er ikke et videnskaveligt princip, at hvem som helst skal kunne gentage et eksperiment i morgen.

  • 5
  • 2
#19 Poul-Henning Kamp Blogger

"forskere kører standard program 60000 gange hurtigere"

En mere korrekt titel ville være: "Forsker eliminerer en masse unødvendigt crap og derfor kører koden hurtigere."

Der er ingen "silver bullet" der får alting til at køre tusindfold hurtigere, specielt ikke kode der i forvejen er skrevet godt/optimeret hårdt.

De store klimamodeller er bestemt i den klasse og "smartere programmering" får den ikke til at køre blot 20% hurtigere.

  • 10
  • 2
#20 Nis Schmidt

Fra 15, juni 2020:

Udviklere vælger for nemme løsninger: Ydelse kan øges 60.000 gange ved at omskrive kode

Link

De store klimamodeller er bestemt i den klasse og "smartere programmering" får den ikke til at køre blot 20% hurtigere.

Det troede jeg også i november 1995; efter at have testen et utal af switches i de to C-compilere (MS og GNU) , men så...

Matrixmultiplikaion. (OCW.MIT.EDU: MIT kursus 6.172 SPE)

A x B = C

hvor A, B og C erkvadratiske mactricer; tranponer B og multiplicer rækker med rækker elementvis: 1000% hurtigere. Prøv det på 10k^2 float-matricer, som for store til cachen.

Som Charles siger: "Your mileage may vary." - ikke to problemer er ens.

Husk at "matmul" bare er et eksempel på virkningen af avendt matematik i kombination med cache-effekt!

  • 2
  • 1
#21 Baldur Norddahl

Jeg tror ikke der er nogen der argumenterer for kun at have en model ?

Som du siger, så skal det gerne være hurtigere end at kigge ud af vinduet. Hvis vi siger at det tager 1 år at køre en model der forudsiger de næste 10 år, så skal den næste kørsel startes med det samme som den bliver færdig. Virkeligheden ændres hele tiden så vi kan ikke bruge gamle kørsler til noget.

Det levner ikke plads til andre modeller medmindre du vil gange prisen op med antal af modeller der skal køres.

  • 1
  • 1
#22 Jens D Madsen

Desto flere beregninger der udføres, desto mindre behøver præcisionen at være... Tages hensyn til det, så bliver opgaven mindre kompliceret, og kræver færre kerner. Efter kort tids beregning, så har vi en usikkerhed uanset computeren størrelse, som gør at større regnekraft ikke ændrer resultatet.

Der er masser af opgaver, hvor vi har behov for stor regnekraft. Men klimamodeller er ikke en af dem. Problemet er ikke beregningerne, men at vi ikke har adgang til viden nok om naturen. Der hvor vi primært har behov for stor regnekraft, er indenfor teoretisk forskning, hvor vi ikke behøver præcis kendskab til naturen. Det kan f.eks. være når vi skal finde løsningen på et veldefineret matematisk problem.

  • 2
  • 2
#23 Jens D Madsen

En mere korrekt titel ville være: "Forsker eliminerer en masse unødvendigt crap og derfor kører koden hurtigere."

Der er ingen "silver bullet" der får alting til at køre tusindfold hurtigere, specielt ikke kode der i forvejen er skrevet godt/optimeret hårdt.

De store klimamodeller er bestemt i den klasse og "smartere programmering" får den ikke til at køre blot 20% hurtigere.

Ved fysiske beregninger, og beregninger på naturen, vil jeg altid tage hensyn til usikkerhedsberegninger (min/max analyser), således at der er styr på, at en yderligere beregning faktisk giver mening, og ikke kan betragtes som "unødvendigt crap". Det er ikke en kunst, at lave mange beregninger. Kunsten er, at skære unødvendigt crap fra.

Jeg blev netop mindet om det, da jeg kørte mit "Hello World" program compileret med c++. Den fyldte 300 kbytes crap, selvom den kun udskriver til konsollen, og indeholder en enkelt printf sætning. Uanset, hvor effektive at compilerne er blevet, evner de stadigt ikke, at sortere unødvendigt crap fra.

  • 3
  • 2
#24 Nis Schmidt

Jeg blev netop mindet om det, da jeg kørte mit "Hello World" program compileret med c++. Den fyldte 300 kbytes crap, selvom den kun udskriver til konsollen, og indeholder en enkelt printf sætning. Uanset, hvor effektive at compilerne er blevet, evner de stadigt ikke, at sortere unødvendigt crap fra.

Jeg trillede lige turen i MS/VSCC (Visual Studio C Community) 2019. Der fylder "HelloWorld" kun 10 kB crap (Release x86). Til x64 12 kB.

Men 48 kB (crap) med Debug x86/x64.

Testede også om det gjorde en forskel at huske:

using std::cout;

Det gjorde det ikke! Så måske er compilere faktisk blevet bedre til at luge ud i crap?

30 gange

(Ja ja, jeg ved godt der sikkert findes smartere compilere, men jeg har ikke nogle af dem (GNU-C, LLVM/CLANG) installeret for tiden.)

  • 1
  • 0
#25 Martin M. S. Pedersen

Jeg blev netop mindet om det, da jeg kørte mit "Hello World" program compileret med c++. Den fyldte 300 kbytes crap, selvom den kun udskriver til konsollen, og indeholder en enkelt printf sætning. Uanset, hvor effektive at compilerne er blevet, evner de stadigt ikke, at sortere unødvendigt crap fra.

Mystisk. Det er en meget dårlig compiler, som du har brugt. Hvilken?

include <iostream>  
   
int main() {  
    printf("Hello world\n");  
    return 0;  
}

Giver 16416 bytes binær-fil på min maskine. Efter strip er størrelsen nede på 14424 bytes. Jeg brugte GCC v11.1.0

  • 1
  • 0
#27 Jens D Madsen

Giver 16416 bytes binær-fil på min maskine. Efter strip er størrelsen nede på 14424 bytes. Jeg brugte GCC v11.1.0

Jeg bruger en ældre version af GCC - husker ikke hvilken, så det er nok på tide at få den opdateret! Tror versionen er cirka det halve. 14-16K er indenfor det rimelige, selvom det nok kan gøres bedre. Teoretisk kan det måske gøres med 20 bytes i maskinkode, men printf anvender stdio der svarer til at åbne en fil, plus der er udskriftshåndtering og håndtering af strenge, og derfor optager det lidt mere plads end en ren udskrift i maskinkode. Skrives til en fil, så bliver der ikke så stor forskel på et maskinkode program og C++.

  • 0
  • 0
#29 Poul-Henning Kamp Blogger

Ved fysiske beregninger, og beregninger på naturen, vil jeg altid tage hensyn til usikkerhedsberegninger (min/max analyser)

I princippet burde man altid behandle virkeligheden som "uncertain numbers" [1], men det er meget tungt at arbejde med og i praksis totalt urealistisk for så store mængder tal som en klimamodel indeholder.

Yderligere er det slet ikke indlysende præcis hvad usikkerhedsbegrebet faktisk betyder, når man kører under Monte-Carlo-lignende omstændigheder.

Men som jeg skrev ovenfor, er der ingen tvivl om at det udelukkende skyldes de stærke negative feedbacks i biosfæren og atmosfæren at det overhovedet konvergerer til at begynde med.

[1] Jeg kan varmt anbefale Sandia rapporten "Sensitivity in Risk Analyses with Uncertain Numbers" https://digital.library.unt.edu/ark:/67531/metadc874250/m2/1/high_res_d/...

  • 5
  • 0
#30 Jonathan Andersn

Scientific computing er en special disciplin i software engineering.

Det foregår overordnet i 3 udviklingslag over tid. 1. Algoritme udvikling, 2. Software udvikling, 3. Hardware udvikling.

  1. Algoritme: Algoritmen udvikles til at løse et specifikt domain problem. Der kan bruges udviklingstid på at afsøge for bedre algoritmer eller forbedre fit af den udvalgte algoritmes fit til domain problemet.
  2. Software udvikling: Algoritmen udtrykkes i et applikations sprog, der typisk udvælges udfra algoritmens krav til præcision, evne til parralelisering og segmentering, decentraliseringsmuligheder, samt faser i algoritmen. Samt performance af det valgte sprog på det valgte hardware. Nok allervigtigst hvilke eksisterende library sproget har til at understøtte algoritmen. (Der bliver lavet mange dybe tallerkner)
  3. Hardware: I og med scientific computing er 'meget af det samme, på kortest mulig tid' vælges der hardware hvor der igen ud fra algoritmen analyseres hvilke bottlenecks kandidater af hardware har. Det er et krav, at den påkrævede præcision overholdes i de tilgængelig libraries under afvikling på det specifikke hardware.

Nogen gange er der spring i udviklingen på de enkelte pinde. En algoritme bliver forfinet, et library til bedre understøttelse af lige nøjagtig den operation algoritmen benytter i en matrix operation. Eller bottleneck var måske IOPS mellem RAM og CPU der blev forbedret. De største spring sker næsten altid, når der sker udvikling på algoritme området. Som foreksempel en præcisering af spørgsmålet, eller store del-elementer af problemet der kan generaliseres, lineariseres eller forsimples beregningsmæssigt inden for det konkrete problems arbejdsområde. (En 13 til 42 leds differentialligning med 2 cm's præcision over hele jordkloden, 5 km ned og 25 km op fra havoverfladen, pr sekund over en 10 årig periode, giver en del beregninger.), der skal også lige nævnes optimering af datastrukturer. Et hurtigt overslag giver varmere middeltemperatur i år 2031 end 2021 i Danmark.

Nu var det lige Moores lov i kontekst af en klimamodel. Det er hvist noget med en fordobling af performance pr 18 mdr. uden lige at give en reference.

Vil mistænke, i et CERN størrelse projekt med (konservativt tal fra 2016) 2500 * 1.5 årsværk arbejde, samt et mindre budget på en 15 milliarder, man godt kunne flytte klimamodeller i Europa et stykke. Inden for Moores lov, mht. at leverer en klima simulering, med samme eller bedre præcision end de nuværende klima modellers køretid, samt måske også med et bedre konfidensinterval på den endelige simulation. (Køretid defineret som: hvor mange sekunder-minutter-timer-dage tager det for applikation at give et endeligt resultat)

Man kan selvfølgelig vælge, som normalt, at bruge de 12 milliarder på lobbyisme, fundrasing/kommunikation, administrative lønninger, etc. Og de resterende 3 milliarder på den konkrete hardware og udvikling med forskere, udviklere, driftsfolk. Tænker det er en anden snak.

Scientific computing er lidt specielt, da det giver mening løbende over tid at evaluere hver pinds indflydelse på performance i forhold til andre software discipliner. Det er alle 3 ting der skal gå op i højere endhed for den endelige performance for scientific computing.

Arbejder til hverdag med software udvikling af sagsbehandlingssysemter. Så det ovenstående er baseret af dovenskab og mangel på reference, på absolut ingenting.

  • 2
  • 1
#32 Jens D Madsen

I princippet burde man altid behandle virkeligheden som "uncertain numbers" [1], men det er meget tungt at arbejde med og i praksis totalt urealistisk for så store mængder tal som en klimamodel indeholder.

Hvis det er urealistisk, er det fordi at klimamodellen er useriøs. Det skal simpelthen gøres. Ellers er der afgjort et troværdighedsproblem. Man kan jo ikke stå og slynge om sig med usande tal, og bruge det til noget.

Tal, der ikke er beregnet præcist nok, er rent tilfældige, og kan kun bruges i politik, sammen med procenter og andet, at politikere ikke forstår. Det er ikke noget at bruge regnekraft på. Så er de givet bedre på bitcoins.

Jeg har altid ment, at usikkerhedsberegninger burde være en indbygget del i enhver floating point unit, så den simpelthen ikke kan afgive resultater, den ikke redegør for præcisionen på.

Videnskaben har afgjort et problem, hvis den anvender resultater der er beregnet med for lav præcision, og der angives større præcision end beregnet. Så er det ikke videnskab! En fysiker, vil aldrig angive en fysisk konstant, med større præcison, end den reelt har - så er bedre, at angive den med dårligere. Og en matematiker vil heller ikke angive en matematisk konstant forkert.

  • 0
  • 11
#34 Jens D Madsen

Re: Argumenter for?

Hvis det er urealistisk, er det fordi at klimamodellen er useriøs.

Jamen så går du bare igang ?

Det er desværre noget andet jeg har gang i lige nu - som der nok ikke er nær så mange penge i...

Men, jeg kan kun opfordre til, at alle dem der laver floating point units, laver dem så de altid udregner præcisionen, og ikke giver flere digits end resultaterne holder.

  • 0
  • 6
#36 Nis Schmidt

Og hvordan forestiller du dig at floating-point units skal vide hvor mange betydende ciffre der er når jeg giver den tallet 0x1.9333333333333p+2 ?

@JDM: Pas på ræven. Floting point i hex notation!

Hvordan repræsentere computere tal som sqrt(2) og "pi", der er reelle tal (som ikke findes i computere)? Sidste ? Bruger du stige eller faldskærm for at komme ned fra den høje hest - uden knoglebrud?

  • 3
  • 0
#37 Henrik Eriksen

Så vi taler ikke om et projekt "på størrelse med CERN", men om et 10-15 gange større projekt.

Du beskriver bygningen af en sindssygt avanceret computer som det vil tage årtier at få fremstillet og bygget, for at vi kan få [mere] præcise resultater.

Det gav i hvert fald mig en øjeblikkelig association, og jeg er forbaset over at ingen endnu har foreslået at den efter endt beregning vil give resultatet: "42"

  • 4
  • 0
#38 Frithiof Andreas Jensen

De største spring sker næsten altid, når der sker udvikling på algoritme området.

Jeg har efterhånden set en del papers hvor man sætter "Deep Learning" algoritmer til at "lære" tunge numeriske algoritmer med, som forskerne siger, overraskende bedre resultater end man burde forvente.

Man kunne måske spare en hel masse CPU'er (og undgå at politikerne beslutter at trække tiden ud med at bygge en mega-computer "for at træffe vigtige beslutninger på et bedre grundlag") ved lade de kendte og velprøvede numeriske algoritmer beregne "grænserne" på hver kasse og anvende "Deep Learning" til at estimere datapunkterne inde i kassen?

  • 1
  • 0
#39 Nis Schmidt

Man kunne måske spare en hel masse CPU'er (og undgå at politikerne beslutter at trække tiden ud med at bygge en mega-computer "for at træffe vigtige beslutninger på et bedre grundlag") ved lade de kendte og velprøvede numeriske algoritmer beregne "grænserne" på hver kasse og anvende "Deep Learning" til at estimere datapunkterne inde i kassen?

Politikere (på godt og ondt) har det med at træffe beslutninger på det for dem "oplyste" grundlag; ganske som nærværende blogger gladeligt udtaler sig nedladende om det han ikke forstår eller ikke gider sætte sig ind i.

Er det så politikerne eller de såkaldte eksperter de læner sig op ad, vi (med rette) bør kritisere? Eller er det bare formidlerne (journalisterne) vi bør korrigere, når de står på for tynd is?

For 38 år siden nåede jeg frem til at søgning på 2D-kasser i kortdata var bedre end at lade en klip-algoritme skære det færdiggenererede kort- billede til . til sidst. Først for 28 år siden fandt man i Danmark (og skiftede til) et andet GIS-system (ESRI/Arc View), som havde kassesøgning indbygget. De (ESRI) havde også valgt at "denormalisere" chain-data, så linjer var i en "containerklasse" i stedet for i en kæde af enkelte punkter.

Ud over bekræftigelse af det gamle mundheld: "En profet er lident agtet i sit fædreland" - (med mindre han er død); hvad kan man så lære af den historie?

Ikke noget! Det er vigtigere (her til lands) "at få ret" end "at have ret".

Derfor slipper "en blogger" af sted med at kalde en (ca) 60000 gange forvedring af køretid for "crap removal" - Performance Engineering of Software Systems, Lektion 1

I virkeligheden er nævnte MIT-kursus 6.172 en forsmag på et undeergraduate kursus i performance (ydeevne) om den valuta (currency) ydeevne er og hvordan den kan bruges på at "gøre ting lettere" eller hvordan valg af programmeringssprog og udnyttelse af maskinegenskaber kan gøre samme arbejde på kortere tid.

  • 1
  • 1
Log ind eller Opret konto for at kommentere