NASA schrijft wedstrijd uit om oude Fortran-code sneller te laten lopen

NASA zoekt de hulp van het grote publiek om decennia-oude code sneller te laten werken. Het gaat om Fortran-code die is geschreven voor toepassingen op het gebied van onder andere stromingsleer en aerodynamica.

De ruimtevaartorganisatie heeft op zijn website uiteengezet waar zij naar op zoek is. Een ieder die bedreven is in het schrijven van code in Fortran wordt uitgenodigd om de broncode te downloaden en te analyseren op verbeterpunten. Omdat de code eigendom is van de Amerikaanse overheid kunnen alleen Amerikaanse staatsburgers de code inzien.

Volgens NASA is het de bedoeling dat de Fortran-code minimaal 10.000 keer sneller wordt gemaakt. Het is onderdeel van het Fun3D-programma, dat onder andere wordt ingezet voor onderzoek naar stromingsleer en aerodynamica. NASA draait het programma op zijn Pleiades-supercomputer, vanwege de complexiteit van de modellen waar berekeningen voor gedaan moeten worden.

Door de code sneller te maken moet het uiteindelijk lukken om nog complexere modellen te draaien op de supercomputer. Dat moet uiteindelijk helpen bij de ontwikkeling van nieuwe vliegtuigen en ruimteschepen. In totaal mogen de prijswinnaars van de uitdaging een bedrag van 55.000 dollar verdelen, wat omgerekend neerkomt op 50.000 euro.

Reacties (145)

[ToFast]

Minimaal 10.000x sneller ? Dan is de huidige code wel erg slecht geschreven. Dit kan ik mij haast niet voorstellen, want dan zou het ook vol zitten met bugs en dergelijke. Gelukkig zijn er slimme koppen die code goed kunnen optimaliseren, maar een factor 3-10x sneller voor algemene stukken lijkt mij aannemelijker (op dezelfde hardware) en max een factor 100 op lastige of echt slecht gecodeerde stukken.

[Reactie gewijzigd door ToFast op 23 juli 2024 11:20]

[Verwijderd]

Soms kan een beter algorithme heel veel uitmaken. Toen het basisprincipe "deel probleem op in 2 kleinere subproblkemen en reken die afzonderlijk uit, doe dat recursief" uitgewerkt werd en men i.p.v. recht toe recht aan een Fouriertransformatie te programmeren het Fast Fourier algorithme (FFT) ontwikkelde ging de executietijd op dezelfde hardware destijds terug van 2 weken naar 2 uur. Dat hakt erin.

Ik heb ooit nog eens voor een klant gezocht naar manieren om dat nog sneller te krijgen, en er bleken nog beter geoptimaliseerde algorithmen ontwikkeld te zijn die nog wat sneller waren, maar de grootste klapper was met FFT wel gemaakt te zijn.

[THA_ErAsEr]

2 weken -> 2 uur komt zelfs niet in de buurt van factor 10.000.
We hebben het dan over berekingen die normal 2uur 45 minuten duren, die dan op 1 seconde worden gedaan of een tijd besparing van 99.99%.

[slowdive]

Als de hardware beter geworden is kun je de code versnellen.
Een bekend voorbeeld is dat je meer geheugen gebruikt om tijd te winnen.
De berekening van de sinus (of een andere ingewikkelde functie) is daar een voorbeeld van. De berekening van één sinus-waarde kost veel tijd. Als je die waarden in een tabel opslaat hoef je ze alleen nog maar op te zoeken.

[sebastienbo]

50'000 is erg weinig voor zo een taak, nee?

[Dylan_R]

Ik vind het inderdaad een aardig klein bedrag voor zon groot project. Als je een programmeur full time inzet hiervoor zijn ze volgensmij meer kwijt.

[Verwijderd]

Tegenwoordig heb je toch een coprocessor voor goniometrische functies en logarithmen?

[Douweegbertje]

De code is oud. Vooral als het een decennia oude code is, is het relatief makkelijk om wat dingen aan te passen waar toendertijd nog helemaal niets over bekend was.
Er kunnen zelfs wiskundige berekeningen in zitten waar nu mooie algoritmes voor verzonnen zijn waardoor je zeker een factor 10.000 sneller kunt uitkomen.

Stel dat je een functie kunt "fixen" die er nu 10x sneller is, en die zou in een execute misschien wel 1000 iteraties krijgen.. dan ben je er haast al

[koelpasta]

Stel dat je een functie kunt "fixen" die er nu 10x sneller is, en die zou in een execute misschien wel 1000 iteraties krijgen.. dan ben je er haast al

Eeh. Nee.
Zelfs al zou de applicatie voor 100% uit deze routine bestaan dan ben je nog steeds max. 10x sneller. En als die routine minder dan 100% van de tijd vergt dan gaat je winst ook omlaag...

[graey]

Yep, maar kijk ook naar Douweegbertjes laatste zinnetje: als je in een bepaalde functie X winst kan boeken, en er is een andere functie die die functie dan weer in een loop uitvoert, wordt je winst opeens X keer het aantal iteraties. En dat kan zomaar eens van toepassing zijn bij simulatiecode.

[Squee]

Volgens mij moeten jullie Amdahl's Law even bestuderen . Als je een deel van je code een speedup van 10x kan geven, kan je nooit over het geheel een speedup van meer dan 10x behalen. Sterker nog, de speedup zal gedomineerd worden door het deel wat je niet 10x hebt kunnen optimaliseren.

[edit]: Overigens is Amdahl's Law toch wel naar mijn mening iets wat iedereen met een informatica opleiding of werkzaam als programmeur zou moeten kennen. Verplichte kost!

[Reactie gewijzigd door Squee op 23 juli 2024 11:20]

[JohnKarma]

Er staat trouwens bij dat dit alleen geld indien een deel van de uit te voeren processen niet parallel uit te voeren is.
Als dat wel zo is lijkt het mij logisch dat indien een stuk code wel parallel uit te voeren is, ten opzichte van een niet parallel te draaien code, het theoretisch zo is dat code die 100x langzamer is maar wel parallel uit te voeren op 1000 cores 10x sneller wordt.

[Reactie gewijzigd door JohnKarma op 23 juli 2024 11:20]

[Ayporos]

Laat ik het zo zeggen:

Ik ken 'Amdahl's Law' niet, maar wat jij zegt waar het voor staat klinkt mij niet meer dan logisch...
Als je 3 mensen aan elkaar bind, ze elk een emmer water geeft en je vertelt ze zo snel mogelijk 10km af te leggen naar een bestemming dan zal de langzaamste het tempo bepalen.
Als je 3 mensen (los) een emmer water geeft en ze vertelt zo snel mogelijk 10km af te leggen naar een bestemming dan is nog steeds de langzaamste die bepaald wanneer alle 3 de emmers hun bestemming bereikt hebben (parallel). Voordeel van tweede manier is echter wel dat er al sneller emmers aankomen op de bestemming.

Er zijn verschillende manieren om het issue van "3 emmers naar een punt dragen" te versnellen. Je kunt kijken of je je snelste renner niet 2 emmers mee kunt geven, je een na snelste 1 emmer en je langzaamste renner lekker op z'n gat laten zitten. Als je snelste renner >4x sneller is dan je langzaamste renner kun je natuurlijk ook ervoor kiezen om die snelste renner twee keer te laten lopen.

Maar natuurlijk kun je ook gewoon je renners ontslaan, een raket bouwen en die afschieten en de emmers water laten bezorgen.

Het mooie van complexe software is dat er altijd wel een 'alternatieve' manier te bedenken is om dingen te doen, die zomaar eens significant sneller/efficiënter kan zijn. Iemand echter die al 5 jaar bezig is geweest om een bestaande codebase te optimaliseren zit veelal in een bepaalde richting te zoeken met oogkappen op en is niet zo snel bereid om een grote gedeelte van de code te scrappen en herschrijven. Daarom dat dit soort "gooi een stel nieuwe mensen tegen het probleem aan in de hoop dat er één met een innovatieve verbetering komt" aanpakken best geoorloofd zijn.

Overigens is het idee van nieuw 'vers' inzicht ergens tegenaan gooien niet alleen (potentieel) effectief in de IT sector maar eigenlijk in alle sectoren wel. Hell, je hebt zelfs speciale "fixer" mensen die ingehuurd worden door bedrijven om hun processen te bekijken en advies te geven over hoe deze geoptimaliseerd kunnen worden.

[Reactie gewijzigd door Ayporos op 23 juli 2024 11:20]

[MrFax]

Als je 3 mensen (los) een emmer water geeft en ze vertelt zo snel mogelijk 10km af te leggen naar een bestemming dan is nog steeds de langzaamste die bepaald wanneer alle 3 de emmers hun bestemming bereikt hebben (parallel). Voordeel van tweede manier is echter wel dat er al sneller emmers aankomen op de bestemming.

Het grote voordeel hiervan is dat je dan alvast een 4e persoon kan sturen met een 4e emmer water, terwijl de andere twee nog aan het rennen zijn.

Maar ja, je hebt ook code waarbij de 3 personen los zijn, maar de andere 2 cruciaal zijn om te weten hoeveel water je hebt, waardoor je ook alsnog moet wachten voordat je de volgende 3 stuurt, omdat je niet genoeg renbanen(threads) meer over hebt.

[Reactie gewijzigd door MrFax op 23 juli 2024 11:20]

[MrMonkE]

Amdahls wet hoef je niet te kennen vind ik maar als je dit werk doet zou je toch wel moeten kunnen beredeneren dat de claim van 10000x niet klopt. Het is geen complexe logica om tot die conclusie te komen als je even 2 tellen na denkt.

[mxcreep]

Tenzij ze bedoelen originele code op origineel platform moet 10.000 keer sneller draaien met optimale code + nieuw platform.

[MrMonkE]

alleen als de functie die je aanpast de enige functie in de app is

[WonnaPlay]

Ook al heb je in deze discussie gelijk, het is niet helemaal zeker dat Amdahl's Law hiervoor geldt.

Als men de (verbeterde) systemen gaat gebruiken om veel grotere datasets te verwerken zal er op dat gedeelte een grotere winst kunnen zijn dan Amdahl's wet toelaat.

Is Gustafson's Law niet een betere om hiervoor te gebruiken?

[GekkePrutser]

Maar juist in die tijd waren ze heel erg goed in het schrijven van efficiënte en snelle code. Juist omdat computers in die tijd zo enorm veel langzamer waren.

Ik vraag me ook af of er zo veel te versnellen valt.

[_Pussycat_]

Destijds was vaak het geheugen de beperkende factor, terwijl tegenwoordig vaak de CPU-snelheid limiteert. Dat zorgt ervoor dat je nu eventueel andere oplossingen kunt kiezen, met bijvoorbeeld enorme lookup tables die toen niet in het geheugen gepast hadden.

[Goderic]

Net omgekeerd, veel toepassingen zijn nu meer geheugen- dan cpu-gelimiteerd. Over de jaren is de snelheid van cpu's ongezien toegenomen, maar de snelheid van geheugen is in vergelijking amper toegenomen.

Waar het vroeger langer duurde om een berekening te maken en het sneller was om een waarde uit het geheugen op te halen, is het nu vaker sneller om de berekening opnieuw op de cpu te doen dan ze uit het geheugen te halen.

[cdwave]

Sterker nog, momenteel is geheugen een van de traagste componenten geworden. RAM access kost belachelijk veel cycles als je de cache mist... Het maakt dat de lookup-tabel soms tot tragere uitvoering leidt dan telkens opnieuw uitrekenen.

[_Pussycat_]

@Goderic en @cdwave
Wat ik bedoelde is dat vroeger (jaren 70 vroeger dus) je vaak erg spaarzaam met geheugen om moet gaan omdat het snel vol was. Dat is nu niet meer zo.

Inderdaad is de toegangstijd naar het geheugen (vooral buiten cache) relatief gezien een stuk langzamer geworden. Het thema Cache-misses is inderdaad in de anderer richting veranderd.

Hoe dan ook beide thema's die ik bedoelde. "in die tijd waren ze heel erg goed in het schrijven van efficiënte en snelle code" klopt - maar code die goed optimaal was, kan nu op de foute punten nadruk leggen.

[necessaryevil]

Misschien is het niet de code an sich maar om de manier waarop die in een moderne applicatie is verwerkt. Als dat door de jaren heen allerlei lagen zijn opgestapeld die via emulatie/virtualisatie met elkaar communiceren dan wordt het op den duur gewoon een traag, wankel geheel.

Ik zie voor me dat het lastig is te herprogrammeren, omdat het veel is, of omdat de achterliggende algoritmen complex zijn. En daar zit ook nog een mogelijk probleem: is het geschreven door programmeurs die wat van wetenschap weten, of is het geschreven door wetenschappers die een beetje kunnen programmeren? ... Juist.

[blobber]

True, alleen heb je nu hardware versnelling tot je beschikking waardoor bijvoorbeeld wiskundige functies een enorme boost kunnen krijgen.Destijds had je alleen cpu + geheugen tot je beschikking.

[laptopleon]

Ik ben niet bekend met Fortran maar net als aan wiskunde, verandert er in de loop der jaren meestal niet zo veel aan de fundamenten van programmeertalen. Ik ben daarom sceptisch over de winst qua sneller functies.

Het lijkt me dat de hardware wél dramatisch sneller is geworden intussen.

Je zou verder hopen dat er intussen fundamenteel andere / betere rekenmodellen zijn dan 20 jaar of langer geleden.

En OK, ik hap Een stukje wat 10 x sneller wordt en dat 1000x itereren maakt de het geheel nog steeds hooguit 10x zo snel, niet 10.000 keer.

[real[B]art]

Ik zou me voor kunnen stellen dat de code nog niet geoptimaliseerd is voor de hardware waar het nu op draait. Optimalisatie kan een enorme performance winst opleveren.

[SuperDre]

Dan zou je dus de interpreter/compiler moeten aanpassen, de code (fortran) zelf is in principe hardware onafhankelijk.

[indigo79]

Ja en nee. Je kan de code inderdaad op moderne hardware compileren, maar dat wil niet zeggen dat hij optimaal gebruik maakt van je architectuur (bijvoorbeeld je cache geheugen). Als je naar een (geoptimaliseerde) BLAS en LAPACK kijkt, zie je dat die vector- en matrixbewerkingen in blokken verdeeld worden om optimaal gebruik te maken van je verschillende memory caches (en de rekentijd voor dit soort simulatiesoftware bastaat typisch voor een zeer groot deel uit dergelijke matrixbewerkingen).
Dat gezegd zijnde, dateert BLAS dacht ik (zo even uit het hoofd, niet nagekeken) van eind de jaren 70 en LAPACK van begin de jaren 90 (en z'n voorlopers LINPACK en EISPACK van begin jaren 80) en zijn zeker van BLAS en LAPACK versies beschikbaar die geoptimaliseerd zijn voor moderne architecturen, waardoor ik vermoed dat ze die verbeteringen in de loop der jaren wel al meegepakt hebben (een geoptimaliseerde BLAS en LAPACK is iets dat op elk systeem bedoeld voor simulaties aanwezig is omdat zeer veel simulatiesoftware daar gebruik van maakt) en zullen de verbeteringen waar ze naar op zoek zijn voor een niet onbelangrijk deel te vinden zijn in efficiëntere algoritmes.

[boels069]

Het zit hem in de CALL's (aanroepen van functies). Bij elke CALL moet er data weggeschreven worden (PUSH) en opgehaald (POP); dat kost tijd.
Bij voldoende werkgeheugen zou de code van de CALL opgenomen kunnen worden in de "code stream" (in assembler kan dat met een macro) en dan kan elke (tussen)variabele als GLOBAL gedeclareerd worden (dan ben je van PUSH/POP van de variabelen af).
In mijn assembler-tijd (bijna 40 jaar geleden) telde ik met een programmaatje het aantal T-states van de processor om een optimale snelheid te realiseren.
PS: In die tijd was het ook lonend (verwerkingssnelheid) om geen goniofuncties, maar LOOKUP-tabellen te gebruiken. Ook de LOG of LN functie was op deze manier te omzeilen (logaritmetafel).

[Reactie gewijzigd door boels069 op 23 juli 2024 11:20]

[Verwijderd]

Ik ben niet bekend met Fortran maar net als aan wiskunde, verandert er in de loop der jaren meestal niet zo veel aan de fundamenten van programmeertalen.

Klopt maar wbt (keuze van) algoritmen is er behoorlijk wat veranderd

[Verwijderd]

nou , kijk naar powershell 1 vs powershell 5 .

door de enorme integratie met .net, heb je nu poeershell parallel workflow. hiermee haal ik nu sinds ps 4.0 tijds reducties van 30 dagen terug naar 20 uur op de zelfde hardware.

puur door het feit dat je nu rustig 40+ threads kunt draaien zonder complexe code toe te voegen. dit is een versnelling van factor 30 in een functie. ik neem aan dat zij aardig wat functies hebben.

ik denk ook dat men met die 10000 alle sub componenten samen bedoelt. je kan 1 code niet zoveel sneller maken. dan zou je code die 10000 dagen over doet in 1 dag moeten runnen. als je dat kan kun je geld verdienen meer dan die 50k.

[Barsonax]

Als je een ander algoritme die beter schaalt kan gebruiken dan is dat best mogelijk.

Vroeger was dit misschien niet praktisch omdat de problemen niet zo complex waren dat dit winst gaf. Stel je hebt bijv een algoritme die een flinke constante factor erin heeft zitten maar wel goed schaalt zou je dit kunnen hebben.

[Zaffo]

10.000x keer sneller best mogelijk? Dat betekend dat je een programma dat een dag moet draaien om tot een oplossing te komen, optimaliseert om hetzelfde werk binnen 9 seconde te doen. (60*60*24/10.000=8.64)

Dan heeft het wel iemand heel erg zitten slapen bij het programmeren van de niet geoptimaliseerde code.

[Barsonax]

Je vergeet alleen dat die code is geoptimaliseerd voor de situatie die ze toen hadden. Als je weet dat je programma nooit een super complexe simulatie hoeft te draaien omdat dat toen gewoon niet kon op die computers dan hoef je daar ook niet voor de optimaliseren. Daarnaast heb je ook nog optimalisaties voor hedendaagse hardware en dat moet je ook echt niet onderschatten.

[Zaffo]

Zeker, echter is een programma meer dan een algoritme en zijn er meerdere routines. Als je een routine die 50% van de tijd in beslag neemt zodanig optimaliseert dat deze oneindig veel sneller is, is het gehele programma nog maar 2x zo snel.

Natuurlijk kunnen de simulaties nu veel gedetailleerder zijn, met meer tijdstappen, meer details, etc. Waardoor er ook veel meer meer iteraties zijn. Een manier waarop ik zie dat een programma veel sneller kan is door bepaalde veelgebruikte dingen in het geheugen te houden, ipv iedere iteratie weer in te laden. Dit is iets waar ik zelf tegenaan gelopen ben met code van iemand anders.

[Reactie gewijzigd door Zaffo op 23 juli 2024 11:20]

[Barsonax]

Of wellicht in dit geval zelfs andersom. Vroeger was het geheugen relatief tot de cpu een stuk sneller. Misschien word er op dit moment caching toegepast die juist langzamer zou zijn op hedendaagse hardware dan het gewoon uit te rekenen.

Het kan allemaal want er komen zoveel details bij optimalisaties kijken.

Zelfs in C# heb ik een functie omgeschreven met zo'n 250x performance boost tot gevolg (interfaces bijv zijn leuk totdat je op dat stuk echt performance nodig hebt omdat je anders iedere keer de cpu cache mist). Lijkt mij dat er in een low level taal veel meer te halen valt vanwege de extra controle die je hebt.

[Gomez12]

De grote vraag is imho voornamelijk of de compiler goed is bijgehouden...

Als de compiler goed is bijgehouden dan zie ik wel een uitdaging in het 10.000x sneller maken.
Maar als de compiler achterloopt dan wordt het opeens een relatief makkie, maak gebruik van level 1 en level 2 cache + een zooitje geoptimaliseerde cpu-instructies die toendertijd nog niet bestond en je hebt zonder grote moeite al een factor 100 tot 1000 te pakken.

[indigo79]

Dan heeft het wel iemand heel erg zitten slapen bij het programmeren van de niet geoptimaliseerde code.

30 of 40 jaar geleden hadden we totaal andere CPU architecturen (zowel op niveau van de core/CPU en het gebruik van meerdere cores/CPUs in een systeem), totaal andere memory-architecturen (cache en dergelijke), veel minder geheugen, geen (GP)GPUs, andere verhoudingen tussen de snelheid van geheugen, permanente opslag en communicatie tussen cores/CPUs/systemen...

Gegeven de beperkte rekenkracht in die tijd, is die code waarschijnlijk zeer goed geoptimaliseerd voor de toenmalige hardware. De compiler kon dat toen niet, dus alle optimalisaties zitten in de source code en maken het lastig tot onmogelijk om alle moderne compileroptimalisaties toe te passen op de code in zijn huidige vorm.

[JJ White]

Ik ben geen expert op dit gebied, maar ik kan me voorstellen dat deze code geen gebruik maakt van allerlei moderne technieken omdat deze uit de vorige eeuw stamt. Als men deze code gebruik kan laten maken van nieuwe instructie sets, low level CPU cache, en wie weet GPU acceleratie, dan kan ik me wel voorstellen dat en ordergroottes aan versnelling gemaakt kunnen worden.

[ToFast]

Daar had ik niet aan gedacht. Als dat ook mogelijk is dan kan dat samen met optimalisering van de gewone code heel wat schelen inderdaad.

[Squee]

Ik ben geen expert op dit gebied, maar ik kan me voorstellen dat deze code geen gebruik maakt van allerlei moderne technieken omdat deze uit de vorige eeuw stamt. Als men deze code gebruik kan laten maken van nieuwe instructie sets, low level CPU cache, en wie weet GPU acceleratie, dan kan ik me wel voorstellen dat en ordergroottes aan versnelling gemaakt kunnen worden.

Daar heb je als het goed is je compiler voor om daar zo veel mogelijk voor te optimaliseren, behalve het GPU punt want je aanhaalt waar je wel expliciet je code voor zal moeten aanpassen. Natuurlijk kan het zo zijn dat je code op een dergelijke manier is geschreven dat de compiler sommige optimalisaties niet kan doen; en dat je door herstructureren bijvoorbeeld wel gebruik kan maken van nieuwere instructies. Het is altijd een beetje een samenspel; maar zolang je wel opnieuw kan compileren zal de performance van je code minder achter lopen dan wanneer je nog steeds een binary van 20 a 30 jaar geleden wil draaien bijvoorbeeld. Dingen zoals instructie scheduling, loop unrolling, en prefetching kunnen het beste door de compiler weer opnieuw worden afgestemd op een specifieke processor.

[SuperDre]

Tja probleem is alleen dat het niet duidelijk (uit het artikel) naar voren komt hoe de optimalisatie moet plaats vinden. Alleen door de interpreter/compiler sneller te maken, of puur de code zelf te optimaliseren of door de boel te herschrijven in een 'nieuwe' taal.
Fortan op zich is niet een probleem, maar bij dit soort dingen komt ook sterke domeinkennis om de hoek kijken, en dat zal nog wel het grootste probleem zijn.

[ATS]

De computers van nu hebben andere beperkingen dan oude machines. Zo zijn cpu's nu veel en veel sneller, maar het geheugen heeft die enorme versnelling niet meegekregen. Geheugen is dus relatief veel langzamer geworden, en caches zijn veel belangrijker geworden. Dat zorgt dat op moderne machines andere algoritmes wellicht sneller zijn dan wat gebruikt is in de code die geschreven is voor een oudere generatie.

[scsirob]

Je hebt een punt, maar geheugen is wel degelijk sneller geworden. DRAM van de jaren '80 (4116 16kbit DRAM bijvoorbeeld) had access tijden van 120 - 250ns. Dat is een factor 100 verbeterd.

[ATS]

Zeker, maar lang niet zoveel sneller als cpu's. Vroeger was geheugen ongeveer even snel als cpu's. Je kon dus in één of enkele kloktikken data er uit halen. Nu ben je zo'n 400 cycles verder voor je je data vanuit je ram in je cpu hebt.

[JohnKarma]

In de begeleidende video van NASA wordt ook gewoon 10- ,100- of 1000x snellere code genoemd als wens. Ook bij targets wordt 10-1000x genoemd.

[scsirob]

In het verleden wisten programmeurs nog tot in detail hoeveel resources hun code nodig had. Zo rot zal die code niet zijn.

Wat waarschijnijk een betere aanpak is, is niet zo zeer de Fortran code aanpassen, maar de compiler. Wellicht dat een optimale compiler de code veel beter parallel schaalbaar kan maken, waardoor je veel optimaler op die supercomputer aan de slag kan.

[Verwijderd]

Ik denk ook dat het onmogelijk is om de software 10;000x sneller te laten draaien door alleen de code aan te passen.

Die 10,000x zou je wel kunnen halen door de meest kritieke algoritmen te herschrijven en te draaien op een FPGA.

[g4wx3]

Mag ik de code omzetten naar VHDL ?? ik zal die 10000 keer makkelijk overtreffen

dit is echt voor slimme koppen met sterke achtergrond in wiskunde,fysica aerodynamica

[jjeggink]

Ach, je moet de lat toch ergens leggen? En 10.000x klinkt gewoon uitdagender dan 2x.
En uitdaging is wel nodig om mensen er warm voor te krijgen dit te doen. Er ontstaat hier op Tweakers al een discussie of dit doel überhaupt wel haalbaar is, dat zal op veel meer plekken gebeuren. Daarmee worden toch wel mensen gekieteld aan te tonen dat het kan. Het is dus ook gewoon een vorm van reclame maken.

[MSalters]

Minimaal 10.000x sneller ?

T.net " journalist". In de link staat toch echt 10x tot 10.000x.

[Verwijderd]

Dat lijkt me een fout in het bovenstaande artikel, uit:

https://fun3d.larc.nasa.gov/chapter-1.html#requirements

Haal ik:

NASA is seeking proposals for improving the performance of the NASA FUN3D software running on the NASA Pleiades supercomputer. The desired outcome is any approach that can accelerate calculations by a factor of 10-1000x without any decrease in accuracy and while utilizing the existing hardware platform.

[MacFreek]

De snelheidswinst als gevolg van snellere hardware en de snelheidswinst als gevolg van betere algoritmes zijn ongeveer gelijk, volgens welingelichte bronnen die me dat onafhankelijk van elkaar verteld hebben (een hoogleraar toegepaste wiskunde, en de beheerder van een supercomputer).

In 20 jaar zijn supercomputers ca. 10000x sneller geworden, en algoritmes ook. De kunst is denk ik iemand vinden die zowel kennis van Fortran heeft, alsmede kennis van moderne algoritmes heeft, maar de beloning van max. USD 55.000,- kan helpen die persoon te vinden.

full disclosure: ik ben werkzaam bij SURFsara, waar de nationale supercomputer staat. Ik heb echter beperkt verstand van algoritmes, en ben in mijn studententijd maar 1x met FORTRAN in aanraking gekomen. Ik voel weinig behoefte om die kennismaking te hernieuwen

[Reactie gewijzigd door MacFreek op 23 juli 2024 11:20]

[cdwave]

Nah, antwoord is simpelweg dat Bauke zijn koffie nog niet op had ofzo:

so it runs ten to 10,000 times faster

Minimaal tien keer sneller dus.

Waarom ze niet meer dan 10,000 willen is mij dan wel weer een raadsel, 't kan nooit te snel zijn toch?

[bl0m5t3r]

vraag mij af waar die 10.000 vandaan komt. Als je op de bronnen kijkt, zowel in de tekst als in het filmpje van NASA, gaat het over 10 tot 1000 keer sneller. Dat is wel heel wat anders dan wat tweakers er van heeft gemaakt met zijn "minimaal 10.000".

[Rob_03]

https://www.nasa.gov/aero...up-its-supercomputer-code

"who can manipulate the agency’s FUN3D design software so it runs ten to 10,000 times faster on the Pleiades supercomputer without any decrease in accuracy."

Waarbij ik ook wel moet opmerken dat men het over de software heeft niet over de code. Daar zit een enorm verschil tussen.

Heeft de software een print opdracht die over 100.000.000 jaar zal moeten worden afgedrukt waarop de super computer 100.000.000 jaar moet wachten, en verander je dat naar over 1 seconden waarbij in de tussentijd de super computer nog iets anders kan gaan doen. Kan je stellen dat de print een stuk sneller uit de printer komt en dus is de software xx keer sneller.

Al lijkt het gewoon een "marketing" tekst waarbij je iets moet aangeven wat ongeveer de uitdaging / verwachting is.

[bl0m5t3r]

Allereerst is "10 tot 10.000" nog steeds iets anders dan "minimaal 10.000", maar het is in ieder geval duidelijk waar het getal vandaan komt.

Ik was zelf aan het lezen op de pagina van de challenge zelf: https://herox.com/HPFCC
Hier wordt meerdere malen in de tekst en het filmpje gerefereerd aan 10 to 1000x. Ik denk dan ook dat ze een eerste kleine fout hebben gemaakt bij het opstellen van het artikel op de algemene site van NASA en tweakers daar overheen het nog een keer heeft opgeblazen.

Grappig om te zien hoe "nieuws" in 2 stappen van "10 tot 1000x" naar "minimaal 10.000x" gaat.

[Rob_03]

"Puntjes moderatie binnen discussies zou leuk zijn geweest" Dan maar zo +2.

Of het echt een foutje is tja. Het is met veel marketing verhalen en ik maak ze dagelijks mee. De snelste, de goedkoopste, setup in 5 min enz, mensen prikkelen werkt beter dan echt duidelijk de waarheid verkondigen en soms werkt het ook wel om gewoon wat onzin er in te gooien.

Ik denk niet dat er veel animo is als je gaat roepen.

Nou een uitdaging maak ons systeem 0,00000012% sneller door hele oude code te optimaliseren voor een systeem wat ooit de naam super computer mocht dragen. Het is ons in de afgelopen 5 jaar niet gelukt dus nu maak jij kans op mogelijk een $50K voor de ultieme oplossing enz enz enz.

En dit is natuurlijk ook een beetje koffiedik kijken maar eerlijk gezegd. Dit lijkt me op dit niveau toch wel een mooie goedkope "recruitment campagne" voor de ehh America first gedachte.

[Pieter van Ras]

"Omdat de code eigendom is van de Amerikaanse overheid kunnen alleen Amerikaanse staatsburgers de code inzien."

En het is vast ondenkbaar dat een Amerikaan de code download en op internet gooit Of wordt je dan tig jaar de gevangenis ingegooid vanwege het openbaar maken van staatsgeheimen?

Verder vraag ik me af: als die code al decennia oud is en klaarblijkelijk op de hardware van destijds (= dus ook decennia oud) kon draaien, dan moet een complexer model op de huidige hardware toch ook wel kunnen draaien? Zelfs met een inefficiente code, de hardware is echt tig keer sneller geworden.

Dit gaat blijkbaar om een CFD programma, zulke programma's zijn echt behoorlijk complex en het aantal regels code zal ook niet mals zijn. Om dat te optimaliseren kost echt enorm veel tijd, uberhaupt het doorgronden van de structuur etc. gaat je al aardig wat weken kosten. Ik weet niet wat een goede, ervaren programmeur in de VS verdient maar 55k lijkt me nog niet eens zo'n overdreven geldbedrag als ik zo bekijk hoeveel tijd en expertise hiervoor nodig zijn in combinatie met hun hoge eisen.

En bovenal: waarom in godsnaam een antiek programma afstoffen en herprogrammeren? Er zijn voldoende CFD paketten beschikbaar die afgelopen decennia wel onderhouden zijn en efficient geprogrammeerd. Er zal vast ook wel een Amerikaanse leverancier te vinden zijn (America First, Trump ook weer tevreden). Nu zal NASA wel specifieke mogelijkheden willen hebben, maar vaak kan je die met user subroutines etc vrij gemakkelijk toevoegen.
Zelfs van scratch beginnen met een team van ervaren programmeurs lijkt me nog een betere optie.

[GeroldM]

[Advocaat.Duivel.Modus -on]
Het is software die ze al hebben en waar ze op kunnen vertrouwen dat de gegenereerde uitkomsten kloppen met de werkelijkheid. Zulk soort 1 op 1 verhoudingen zijn schaars...zeer schaars.

Als je kijkt naar Formule 1, dan gebruikt men daar deze nieuwe CFD paketten dag in en dag uit, spenderen zoveel mogelijk tijd in windtunnels als de regels toelaten en betaalt men miloenen US Dollars per jaar voor die privileges. Maar die 1 op 1 verhouding is er niet, aangezien al wat ze bedacht hebben niet goed werkt, wanneer de Formule 1 auto daadwerkelijk aan het racen is.

Alle goede wil ten spijt, wanneer je uiteindelijke product niet of niet volledig functioneert zoals je software het heeft berekend, ben je veruit te laat en heb je flink wat geld "verloren".

Het zou mij niet verbazen dat NASA flink wat praktijk testen heeft uitgevoerd in het verleden voor die 1 op 1 verhouding,tussen praktijk en software. Dat heeft een gigantisch fortuin gekost.

Maar jij wil dat weggooien en opnieuw beginnen met onervaren programmeurs (die misschien wel verstand hebben van CFD, maar niet van ruimtevaart in de praktijk) in een computertaal die zich nog niet bewezen heeft, omdat dit beter in jouw straatje past...

Dat is vernietiging van serieus kapitaal.

Waarom denk je dat veel banken ook nog steeds blijven doorontwikkelen met hun Fortran mainframes? Omdat nieuwe talen en programmeurs het qua kosten/baten/ervaring het nog steeds afleggen tegen die oude bakken en hun software, gemaakt door slimme programmeurs met (heel) veel relevante praktijk ervaring.

[/Advocaat.Duivel.Modus -off]

Van je post leid ik af dat je van mening bent dat nu alles beter was dan vroeger, dat men tegenwoordig slimmer is dan vroeger, dat alles efficiënter is dan vroeger.

Dat mag misschien zo lijken, maar ook toen liepen er mensen rond met een groter intellect dan dan het mijne en jouwe bij elkaar opgeteld. Hun nadeel was het aantal resources waarover ze koneden beschikken en hoe ze hun gedachten/ideëen/theoriën voor latere generaties konden bewaren.

Maar om dat nu tegen hen te gebruiken...dan doe je hen, en daarbij ook jezelf, toch echt veel te kort.

[Verwijderd]

Ik denk dat de NASA geen betere CFD oplossingen heeft dan de moderne.

http://www.claymath.org/m...r%E2%80%93stokes-equation

CFD oplossingen zijn gebaseerd op de Navier Stokes vergelijkingen en tot op heden weet niemand of deze daadwerkelijk kloppen. Ze lijken te kloppen, omdat waarnemingen in veel situaties (maar niet alle!) passen, maar er is nog steeds geen wiskundig bewijs voor.

Bijvoorbeeld, tot op heden heeft men nog geen enkel flauw idee waarom bij een bepaalde snelheid een luchtstroom stabiel is langs een voorwerp en waarom bij een verhoging van 1 km/h de luchtstroom ineens destabiliseert en er turbulentie etc. optreedt.
De meest moderne (commercieel en dus veelal gesloten) CFD pakketten kunnen hier nog steeds niet mee overweg, ondanks toenemend begrip van Navier Stokes en simulatie rekenkracht.
Het is daarom bijzonder onaannemelijk dat NASA betere CFD oplossingen heeft (in Fortran).
Het is ontwikkeld in het publieke domein met publiek geld en in de wetenschap betekent dat dat wetenschappelijke doorbraken -zoals de Navier Stokes bewijzen- gemeld en beschikbaar gesteld worden aan een ieder die daar gebruik van wilt maken.
Dus als NASA betere oplossingen zou hebben, dan zou die te vinden moeten zijn.
Er is voor NASA geen reden om ontdekkingen van dergelijke significantie achter zich te houden.

[Basjuh84]

Wat een bizar verhaal. Ik snap er daadwerkelijk niets van. Ik snap ook niet dat dit zoveel positive reviews krijgt. Ik lees: Wij zijn ouder: wij weten hoe de wereld werkt: wij bepalen de waarheid: jeugd, doe geen moeite, wij senioren weten allang doe het werkt.

-excuus: ik moet niet weer reageren als ik teveel bier op heb

[Reactie gewijzigd door Basjuh84 op 23 juli 2024 11:20]

[MrFax]

Ja dat legt zeker uit hoe de meeste senioren niet eens weten hoe ze een computer moeten opstarten

[iceblink]

"aangezien al wat ze bedacht hebben niet goed werkt" -> ik denk dat dat reuze meevalt. Grootste probleem zal niet zijn foutjes in de software, maar constructies bedenken die niet alleen goed werken onder de aannamen die voor de simulatie gedaan worden, maar ook in werkelijkheid.
Voorbeeld: de simulatie laat winst zien bij lucht die exact van voor naar achteren stroomt. In werkelijkheid kan er zijwind wijn, of turbulentie van de voorligger, waardoor de resultaten van de simulatie niet daadwerkelijk in winst kunnen worden omgezet.
Nog een voorbeeld: iemand bedenkt een spoiler die doorbuigt bij hogere snelheid en dan minder weerstand heeft. Zeer slim bedacht. In werkelijkheid kan de spoiler door hobbels in de weg gaan staan vibreren en de wagen langzamer maken.
Natuurlijk moet je oppassen dat er geen nieuwe fouten worden geïntroduceerd door wijzigingen in de software, maar over het algemeen zal dat niet het grote probleem zijn.

[pizzafried]

kleine kans van niet....Trump doesn't care....

[MSalters]

"Omdat de code eigendom is van de Amerikaanse overheid kunnen alleen Amerikaanse staatsburgers de code inzien."

En het is vast ondenkbaar dat een Amerikaan de code download en op internet gooit Of wordt je dan tig jaar de gevangenis ingegooid vanwege het openbaar maken van staatsgeheimen?

Raketsystemen zijn "dual-use" met militaire toepassingen. Noord Korea zou dit graag hebben. Dus ja, reken op 30 jaar cel.

[MenN]

Kan iemand mij uitleggen waarom ze dit niet gewoon compleet herschrijven met moderne technieken?

NASA is looking for qualified people who can download the FUN3D code, analyze the performance bottlenecks, and identify possible modifications that might lead to reducing overall computational time.

Examples of modifications would be simplifying a single subroutine so that it runs a few milliseconds faster. If this subroutine is called millions of times, this one change could dramatically speed up the entire program’s runtime.

Of zou een rewrite niet veel sneller gaan worden?

[blorf]

Ik heb me er niet verder in verdiept maar als dat niet zou kunnen zou dat min of meer bewijzen dat Fortran in prestatie op bepaalde vlakken superieur is aan andere, meer gangbare hoge talen. (Er vanuitgaande dat het te complex is om het op een lager niveau in Assembly of C oid te herschrijven.)
Maar het zal wel Fortran moeten blijven als voorwaarde, vermoed ik.

[Rinzwind]

Fortran is een vrij low level taal. Eerst gepositioneerd als een alternatief voor Assembler.

"The computer scientists who bash physicists for using Fortran fail to realize that Fortran remains uniquely suited for doing what it was named for – FOrmula TRANslation, or converting physics formulas into code."

http://www.moreisdifferen...sicsts-still-use-fortran/

https://www.fortran.com/p...ompiler-suite-commercial/

[indigo79]

Fortran is een vrij low level taal. Eerst gepositioneerd als een alternatief voor Assembler.

Wat kort door de bocht volgens mij. Ja het is naar de huidige normal een low-level taal en ja, in 1952 werd het gepositioneerd als een alternatief voor assembly maar dat was omdat het in 1952 vrij standaard was om in assembly te programmeren en niet omdat het low-level was (naar 1952 normen was het een behoorlijk high-level taal).

[svennd]

Ongetwijfeld zal een from scratch veel langer duren, en om daarvoor mensen te vinden voor die 55k $ zal al helemaal niks zijn. Als je nu bij wijze low-hanging fruit ziet en je kunt er iets mee verdienen, dan is de kans wel dat je die PR´t maar als je alles moet herschrijven ... (ik vermoed dat de codebase significant groot is )

[Durandal]

Omdat de code eigendom is van de Amerikaanse overheid kunnen alleen Amerikaanse staatsburgers de code inzien.

Ik begrijp dat resultaat van belastinggeld alleen voor de Amerikanen moet zijn, maar je kan er van uitgaan dat de hele wereld de code kan inzien (zal inmiddels wel op torrents staan). Aangezien alleen Amerikanen kunnen meehelpen (en niet de andere 90% vd programmeurs op de wereld) is dit duidelijk een burocratische regel waarbij de regel het doel tegenwerkt.
Dom.

[flippy]

NASA is een overheidsinstelling. zulke eisen stellen wij ook in nederland aan veel functies.

[Durandal]

Dat klopt, en ook een hoop niet waar het wel zou moeten (resultaten van EU gesponsord onderzoek in het wereld-publiek domein); er moet dus per situatie over beslist worden ipv bot de regels uit te voeren.

[flippy]

er word een lijn getrokken voor een reden. per situatie ergens naar kijken betekent dat je daarvoor mensen moet inhuren. dat is een oplossing creeren voor een probleem dat er niet is.

[laptopleon]

Geen gebrek aan problemen op dit gebied hoor. Als ik zie wat voor eisen er gesteld worden aan alleen al degene die mee willen dingen naar de aanbesteding van 'de ontwikkeling' van een nieuw logo voor een gemeente, dan denk ik dat iedereen het er over eens zal zijn dat de regels op dit gebied totaal doorgeschoten zijn.

Alleen al het controleren van alle voorwaarden door iemand van de gemeente kost dagen arbeid.

Eén van de voorwaarden is dat het bedrijf een ruime ervaring moet hebben met dergelijk werk (logisch) voor gemeenten (kolder). Andere voorwaarde is o.a. dat je een x aantal mensen in dienst hebt. Kortom maar een paar bedrijven in Nederland mogen uberhaupt meedingen.. Hierdoor creeërt de overheid een kunstmatige, extreem kleine markt waar ze zichzelf in dwingt

En inderdaad, u raadt het al, met als resultaat dat een kleine huisstijl voor onze plattelandsgemeente van 40.000 inwoners anderhalve ton heeft gekost.

[oef!]

Gemeenten gaan soms niet al te efficiënt van werk. Vaak vanwege moeizame inspraak over te veel schijven, over-the-top eisen en een gebrek aan actuele kennis of intern tegenstrijdige belangen. Het kan overigens ook soepel verlopen.

Het is echter niet zo dat er in de overheids-IT sector een gebrek aan concurrentie is. Naast de dinosauriërs Centric en PinkRoccade zijn er tientallen softwarehuizen actief, vaak geen kleine clubs. Met rond de 350 gemeenten, samenenwerkingsverbanden, de staat zelf en allerlei semi-overheid is het ook bepaald geen kleine markt.

[Reactie gewijzigd door oef! op 23 juli 2024 11:20]

[jordees]

Nasa is geen overheidsinstelling, vanwaar heb je die nonsense? Het is een door de overheid gesubsidieerde commerciële instelling.

[flippy]

nasa is 100% overheid. echter hun resultaten zijn publieklijk inzichtelijk. dat maakt het nog niet commercieel.

[DrSnuggles]

Misschien voorziet de NASA elke pull van een fingerprint, eentje die verbonden is aan het social security number? Nouja, on second thought, dat gaat natuurlijk lastig, zo niet onmogelijk.

[Noxious]

Dat gaat stiekem erg makkelijk, bijv. fingerprinting in de whitespace van documenten (tabs/spaties/regels) heeft geen invloed op de code - en komt vaker voor.

[DrSnuggles]

Ja, in die richting dacht ik eerst ook. Alleen leek fingerprinting op die manier me ook vrij makkelijk ongedaan te maken; scramble door je gefingerprinte code wat tabs/spaties/regels heen?

Ik weet hier vrij weinig over, dus wijs me er vooral op als ik de klok enkel heb horen luiden.

[Noxious]

Klopt, is met andere tooltjes best ongedaan te maken - maar niet iedereen zal er aan denken

[DrSnuggles]

Zeker! Maar het primaire doel van NASA is volgens mij om te voorkomen dat mensen het buiten de VS verspreiden, niet zozeer de hieraan "schuldige" burgers te herleiden. Mag ik hopen.


Nou ja, het is hoe dan duidelijk dat dit een maatregel voor de bühne is. Anderzijds weet NASA ook heus wel dat niet-Amerikaanse FORTRAN liefhebbers er mee aan de slag gaan. Uiteindelijk levert dit ze dit waarschijnlijk verse code op, zonder die 55k onder te veel mensen te moeten verdelen.

[alienfruit]

Eigenlijk is dit best normaal hoor. Ik werk zelf in Engeland bij enkele projecten mag ik alleen adviseren maar er niet actief aan meewerken omdat ik geen UK staatsburgerschap heb.

[Rinzwind]

Het is normaal, maar het is niet normaal in een moderne wereld.

[SuperDre]

We leven in de moderne wereld en dus is dit ook normaal. Dat jij het niet normaal vindt is een andere zaak.

[frickY]

Je vind het normaal omdat je het gewent bent.
Dat maakt het voor anderen niet ook normaal.

[stresstak]

Dat maakt het voor anderen niet ook normaal.

Het is voor die anderen niet normaal omdat ze dat niet gewend zijn. Dat willen ze zo houden en dat is niet normaal. Wel gebruikelijk, niet wenselijk.

[Sharkoon]

Het is ook nooit goed he. Toch mooi dat americanen het alleenrecht krijgen geeft hun dus meer kans om als americaan het probleem op te lossen. Tuurlijk is het leuker als de rest van de wereld er ook aan kan werken maar dat is niet zo. Dus niet zo zeuren, wees blij dat ze het openstellen voor verbetering.

[Annihlator]

Dus het is nu ipv closed- nu not-so-open-source geworden? Of hoe kun je dat wel zien?

Had dit niet een heel geschikt project kunnen zijn om ook de andere ruimtevaartorganisaties bij te betrekken? Iedereen zou daar toch vruchten van kunnen plukken lijkt mij.

[Reactie gewijzigd door Annihlator op 23 juli 2024 11:20]

[Stroper]

Open Source wil niet alleen zeggen dat je kon de code kan inkijken, maar ook dat je die mag aanpassen en hergebruiken(afhankelijk van de licentie zijn er wel beperkingen mogelijk bv. aanpassingen moeten wel/niet open source zijn).

Het is perfect mogelijk om een closed source programma te maken en de code publiekelijk te zetten, met daarbij een waarschuwing dat je het niet mag hergebruiken. Microsoft heeft bv. de broncode publiek gezet van een van de eerste versies van MS-DOS, je mag die inkijken maar niet hergebruiken. Ook hier is de NASA code dus closed source zelfs al kan je hem (als Amerikaan) bekijken.

[Reactie gewijzigd door Stroper op 23 juli 2024 11:20]

[HerrPino]

Feitelijk geldt voor ieder open source project dat je de code kunt aanpassen en hergebruiken (eigen gebruik) dat geldt zelfs voor de meest beperkende vorm. Of je het zomaar mag herdistrubteren is iets anders. Er zijn maar weinig echt vrije opensource licenties, ik meen MIT. GPL iig niet, dat is een virus en besmet je applicatie. Fijn als je meerdere stukken hebt met allen een net even andere vorm.

[smitae]

Om die reden kost het een bedrijf als Red Hat heel veel tijd om aangekochte code/tools/apps die niet vanuit de basis open Source naar echt Open Source om te zetten. Dat is namelijk wat ze doen als ze iets kopen/overnemen.
Ze moeten alle code door en kijken if er niet ergens wat code inzit die niet zomaar Open Source mag worden.

Want ze kunnen niet het risico lopen dat ze per ongeluk iets open Source maken wat mogelijk een stukje closed Source in zich heeft, dat kan een heel duur grapje worden.
Maar ja, dan kan het zo maar een jaar kosten voor het als Open Source naar de community kan. En dat is best jammer.

[SuperDre]

Uhm, opensource betekent wel degelijk dat je de code mag inkijken, en afhankelijk van de gebruikte licentie mag je deze ook zelf gebruiken/aanpassen en of distributeren, dus open source betekent niet automatisch dat je er mee mag doen wat jij wilt.

[Annihlator]

Bedankt voor de verduidelijking met een mooi voorbeeld!

[kaasboer09]

10.000 maal sneller, en daar slechts $55k tegenover stellen. De licentie van een goed CFD programma kost per jaar al gauw de helft daarvan.

Ik vermoed dat de echte high-level professionals (die je hiervoor nodig hebt) hier niet warm voor zullen lopen. Hoogstens de "enthousiasts" (aan de andere kant zijn de high level experts ook vaak dezelfde enthusiasts)

[Daniel_Elessar]

Ik denk juist wél dat die high pro's hier warm voor lopen. Alleen niet voor het geld. Als bekend is dat jij dit gedaan hebt is dat heel erg goed voor je portfolio en toekomstige klanten. Het is zeg maar een investering en als je het wint dan krijg je er 'iets' voor terug. Ook voor die jongens is 50K extra een leuk zakcentje. Maar de naam die je maakt is veel meer waard.

[Thekilldevilhil]

Zo kun je aan de gang blijven. "Het is voor je CV" en "Je krijgt er betere naamsbekendheid door". Maar laten we eerlijk zijn, dat is ook voor een deel een placeholder voor "we hebben eigenlijk niet zo veel zin om hier geld voor neer te leggen". Loon naar werk mag van mij wel weer een belangrijkere positie krijgen. Anders eindigt de IT net als de research, geld problemen, lage lonen en zo'n focus op naamsbekendheid dat de kwaliteit van het onderzoek onder druk komt te staan. En wat dacht je van al die onbetaalde stages. Die investering betaalt zich nou niet echt uit als je in een 1800 euro/maand PhD rolt.

Van mij mag je voor zulke hoge eisen ook wel een fatsoenlijk budget neerleggen.

[SuperDre]

Alleen is NASA een overheidsinstelling en kunnen dus niet zomaar een 'hoog' bedrag noemen, het moet binnen een beperkt budget wat ze ter beschikking hebben. En waarom zou IT anders zijn dan welk ander onderzoeksector. Naamsbekendheid/CV is voor later wel degelijk interessant. En niet iedereen doet het voor het geld.
En tja loon naar werk is natuurlijk in the eye of the beholder.

[Thekilldevilhil]

Ik doe het dus automatisch ook niet voor het geld. Ik heb immers zelfs de keuze gemaakt om in het relatief slecht betaalde onderzoeksveld te gaan werken. Je hoeft mij niet uit te leggen dat je werk ook om andere redenen kan gaan doen...

Maar niet met grote bedragen kunnen smijten omdat het een overheidsinstelling is...? Die smijten continu met grote bedragen, zeker de nasa. Als dit echt zo'n belangrijk model is zou dit in dit geval ook gewoon moeten kunnen. Zeker omdat niet alleen de nasa hier baat bij heeft.

[smitae]

Waarom moet er altijd geld tegen over staan?

Veel Open Source community members doen het vaak ook niet voor het geld. Uiteindelijk zijn bijdragen aan dit soort dingen juist erg goed voor je carrière en veel doen het ook vaak nog eens naast een meer reguliere job. Is voor veel mensen gewoon een leuke uitdaging.

Belangrijkste is toch nog steeds uitdaging en lol in je werk, althans voor mij. En ja, dat is dus niet altijd het grote geld, maar voldoende om van te leven en plezier in wat je doet.

[Thekilldevilhil]

Je lijkt aan te nemen alsof ik werk voor geld. Ik haal research niet voor niets aan.

[Daniel_Elessar]

Ja, het zou iets meer mogen zijn. Maar ook voor veel van die pro's is dit toch een 25%-50% van hun jaarinkomen. Dat is niet mis om hiervoor te krijgen. Natuurlijk zou je zeggen dat hun eigen IT mensen dit ook moeten kunnen.

Alles op je CV is eigenlijk placeholder zoals je het zegt maar het kan wel dingen aantonen. Zeker als je dit erbij kunt zetten. Dat zegt wel iets over jou/je team. En dat is veel waard.

Research is inderdaad minder goed betaald dan zou moeten/kunnen. Maar alsnog is 1800 (netto) niet echt slecht. Er zijn er veel die minder verdienen en het is ook meer dat je dat doet uit roeping.

[Luno]

Zo'n 40 jaar geleden heb ik veel gewerkt met een Pr1me computer. Het OS (Pr1mos IV) was geschreven in een Fortran compiler die van de NASA kwam. In alle jaren daarna ben ik niet een compiler tegengekomen die efficiëntere coding leverde
Een paar % winst door instructies die er toen niet waren zou ik kunnen begrijpen.
Snelheidswinst door parallel rekenen zou zou ook nog kunnen, maar dat kun je toenmalige computres niet niet aanrekenen.
Maar meer dan een paar % winst lijkt me whisfull thinking.

[Crack]

[...]
Maar meer dan een paar % winst lijkt me whisfull thinking.

De Pr1me waar ik destijds Fortran77 op draaide had een Moterola68000 processor: 8 Mhz en 64 VT100-terminals .
Ik neem aan, dat momenteel de oude hardware geëmuleerd wordt. Bovendien ligt het bij stromingsleer voor de hand dat parallelle verwerking veel winst kan opleveren.
Een Fortran-compiler die toegespitst is op de mogelijkheden van de in gebruik zijnde supercomputer zou mijns inziens een enorme snelheidswinst op moeten leveren.

Edit: @Luno hieronder: Misschien herinner ik het me niet meer juist: Is ook wel erg lang geleden

[Reactie gewijzigd door Crack op 23 juli 2024 11:20]

[Luno]

De Pr1me waar ik op werkte had een Z80 CPU als 1ste opstart. Na de opstart had Pr1me een eigen CPU. Niks geen Motorola processor. Die hebben ze nooit gehad. Ooit rond 1990 hebben ze even een soortement Unix workstations gehad, maar ook op Intel '86 gebaseerd.
En het OS was (in 1978) geschreven in Fortran-IV cq Fortran66. Zonder character vars etc, ook geen IF-THEN-ELSE Allemaal vreselijk basic, maar wel verrekte snel.
We (waar ik werkte) hadden de eerste Pr1me 400, en in die tijd kreeg je source coding OS er nog bij. Omdat wij die rechten hadden hebben we ook jaren later nog steeds de source coding van het OS gekregen, ook toen ze alles naar PL1 (in hun termen (PLP/SPL) omgezet hadden.
Voor Pr1me kan ik zeggen dat we eerste waren die een P400 aanschaften (1978), en helaas voor hen de eersten die in 1990 de P9750 vervingen door een Sun386i.
Die motorola lijkt me sterk. In elk geval niet een systeem dat ik tot 1990 heb meegemaakt. Maar daarna (1990) heb ik het niet gevolgd.

[MSalters]

Ik neem aan, dat momenteel de oude hardware geëmuleerd wordt.

Welnee. Waarom zou je? NASA heeft de source code nog. Dat compileer je gewoon voor de x86. Emulatie is nog te doen voor domme software die staat te wachten op gebruiker input of I/O, maar voor numerieke code is het desastreus.

[jpsch]

Stromingsleer, aerodynamica zou er in die tientallen jaren voor andere toepassingen niet gelijksoortige verbeterde software zijn geschreven? Voor auto's, waterkeringen, weervoorspellingen, windtunnels, vliegtuigen?

[divvid]

Pas nog zo'n project tegen gekomen. Het eerste dat moest gebeuren was gfortran installeren. Bijna alle reken libs waren en zijn nog in Fortran geschreven, veelal met een c-sausje er overheen om de boel aan elkaar te knopen.

[Bitmaster]

Je kunt op de website van NASA een aanvraag doen voor de FUN3D software, maar zoals gezegd krijg je dan helaas de melding dat de software alleen voor U.S. citizens beschikbaar is. Om toch een aanvraag te doen voor de software, kun je proberen een email te sturen naar [e-mail].

[Reactie gewijzigd door Bitmaster op 23 juli 2024 11:20]

[bierschuit]

Heeft u toestemming verkregen op deze manier?

[Bitmaster]

Nee helaas, vergeet het emailen maar weer... Ik dacht in de eerste instantie bijvoorbeeld dat werknemers van een Amerikaans bedrijf gewoon toestemming konden krijgen, en dat ze voor de High Performance Fast Computing Challenge participants niet zo moeilijk zouden doen. Maar ze blijken toch streng te zijn. Zelfs Amerikaanse werknemers van Amerikaanse bedrijven mogen de software niet gebruiken als ze zich buiten U.S. territory bevinden. Jammer dus, dat we niet zomaar mee kunnen doen.

[bierschuit]

Het is eigenlijk ook wel deels logisch. Domestic know-how als ik het zo mag benoemen. Hetgeen betekend dat ze willlen dat alle knappe koppen Amerikaans zijn (het liefst nog met geboren voorvaderen op het continent) en zich binnen de landsgrenzen bevinden. Patriotisme