Capstone talk: System Software in Jena
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Alternative Title |
| |
| Title of Series | ||
| Number of Parts | 6 | |
| Author | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/36322 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language | ||
| Production Place | Jena |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
System programmingSoftwareComputer programmingParallel portComputer configurationCybersexComputer hardwareRun time (program lifecycle phase)CompilerPrisoner's dilemmaMaizeBridging (networking)Google MapsNeuroinformatikStudent's t-testSynchronizationPersonal digital assistantGamma functionPrincipal idealWordHecke operatorNatural numberMereologyCartesian coordinate systemOnline helpComputational visualisticsMultiplication signNetwork topologyUniverse (mathematics)Video gameBitBoss CorporationSystem programmingPresentation of a groupMetreGroup actionFamilyForm (programming)AreaComputer hardwareAdventure gameComputer programmingSoftwareCompilation albumBuildingSystem softwareNeuroinformatikPrincipal idealProgramming languageRun-time system2 (number)Point (geometry)Office suiteComputer animationLecture/Conference
09:30
System programmingMachine visionElectric currentFood energyFocus (optics)ArchitectureCompilerAdaptive behaviorAbstractionRun time (program lifecycle phase)Resource allocationFunctional programmingProgramming languageCybersexCoordinate systemSystem programmingSoftwareComputer hardwareCASE <Informatik>Parallel portMultiplication signFault-tolerant systemView (database)BitSystem softwareGreen's functionSoftware bugTrailBridging (networking)Normal (geometry)CodeLine (geometry)Roundness (object)Tracing (software)Direction (geometry)Functional programmingObject-oriented programmingCompilation albumComputer programmingProblemorientierte ProgrammierspracheEnterprise architectureSequenceInformation securityWorkstation <Musikinstrument>Food energyProgramming languageVirtual machineAbstractionOperating systemProduct (business)Social classSoftware engineeringDifferent (Kate Ryan album)Run-time systemComputer scienceMoore's lawMoment (mathematics)State observerPortable communications deviceRight angleSingle-precision floating-point formatComputer animation
18:27
Compilation albumSystem programmingDifferent (Kate Ryan album)BitHacker (term)Level (video gaming)CubeRecursionPoisson-KlammerMatrix (mathematics)Single-precision floating-point formatVector spaceComplex (psychology)Programming languageFast Fourier transformRing (mathematics)DataflowParallel computingFunctional programmingComplex numberComputer programmingImplementationElement (mathematics)Pointer (computer programming)RootComputer architectureSpeech synthesisSemiconductor memoryParameter (computer programming)Dimensional analysisMultiplication signDivisorComputational visualisticsAxiom of choiceKey (cryptography)Instance (computer science)BefehlsprozessorOperator (mathematics)Line (geometry)Interpreter (computing)Object-oriented programmingArray data structureCode2 (number)Drop (liquid)EinheitswurzelEnterprise architectureSource codeLatent heatCASE <Informatik>Free variables and bound variablesAlgorithmSubject indexing1 (number)Position operatorSemantics (computer science)Optical disc driveType theoryComputer animation
27:25
Network-attached storageComplex (psychology)Fast Fourier transformAlgorithmImplementationCompilation albumSystem programmingSource codeCompilerBefehlsprozessorEnterprise architectureSoftwareSeries (mathematics)Cluster samplingCybersexRule of inferenceFunctional programmingGame theoryParallel portComputing platformTexture mappingAerodynamicsFrequencyParallel computingInformation securityFood energySoftware engineeringComputer hardwareSystem programmingCompilation albumCompiler constructionFast Fourier transformComputer scienceTouchscreenControl flowCASE <Informatik>Parallel computingSource codeSoftwareMulti-core processorCategory of beingOptimization problemData managementSeries (mathematics)Multiplication signProgrammer (hardware)Software engineeringPoint (geometry)Fraction (mathematics)Computational visualisticsGame controllerShared memoryFood energyCoprocessorCore dumpEnterprise architectureNumberArmBounded variationBenchmarkSuite (music)Hacker (term)CodeLine (geometry)Software frameworkComputer hardwareProgramming languageFrame problemCybersexUsabilityView (database)Distribution (mathematics)AlgorithmÄquivariante AbbildungDeadlockSocial classStudent's t-testCollaborationismRevision controlMappingResultantCartesian coordinate systemInstance (computer science)Scheduling (computing)Computer simulationObject-oriented programmingBitCodeStructural loadProjective planeComputer clusterLaptopDifferent (Kate Ryan album)CuboidElectronic mailing listComputer animationXML
36:22
CybersexSystem programmingFood energyInformation securitySoftware engineeringSoftwareComputer hardwareComponent-based software engineeringSystem identificationFlow separationFunction (mathematics)Functional programmingoutputProgramming languageEnterprise architectureProcess (computing)ArmGraphics processing unitComputer wormRow (database)Regular graphMessage passingModel theoryComputer-generated imageryEncryptionDecision theoryRing (mathematics)Problemorientierte ProgrammierspracheFingerprintCore dumpMultiplicationSpacetimeConstraint (mathematics)AerodynamicsMathematical optimizationHeuristicFluid staticsImplementationWeb pageBitNormal (geometry)Interactive televisionFrequencyDifferent (Kate Ryan album)Graph coloringDesign by contractMultiplication signSoftwareCuboidDataflowSource codeEnergy conversion efficiencyBlock (periodic table)Computational visualisticsAreaSoftware engineeringComputer configurationView (database)Object-oriented programmingLevel (video gaming)Parameter (computer programming)CodeCartesian coordinate systemComponent-based software engineeringState of matterInformationCybersexFood energySystem programmingComputer wormEncryptionMedical imagingCoordinate systemComputerMoore's lawArithmetic meanArtificial neural networkInstance (computer science)Parallel computingDecision support systemExecution unitBefehlsprozessorEnterprise architectureMereologyComputer hardwareBinary codeFunctional programmingMultiplicationoutputImplementationDynamical systemCategory of beingProgramming languageMessage passingInheritance (object-oriented programming)Compilation albumLatent heat2 (number)Core dumpGame controllerComputer animation
45:19
ImplementationEnterprise architectureData managementTwin primeMobile WebFood energyContinuum hypothesisCloud computingSystem programmingPoint cloudLimit (category theory)Multiplication signSound effectCodeSign (mathematics)Point (geometry)Frame problemBitGoodness of fitProgramming languageSemiconductor memoryLogical constantTheory of relativityCoordinate systemTuring testMachine visionSystem programmingPhysical systemDuality (mathematics)Component-based software engineeringDatabase normalizationModul <Datentyp>Adventure gameGame controllerBenchmarkModel theoryFood energyStudent's t-testOcean currentCybersexPhysicalismLatent heatOrder (biology)Computational visualisticsCartesian coordinate systemMathematical optimizationObject-oriented programmingDifferent (Kate Ryan album)Axiom of choiceCategory of beingComputer hardwareImplementationWordGreen's functionScheduling (computing)1 (number)Computer programmingDigitizingProduct (business)NumberSource code2 (number)CASE <Informatik>HorizonGroup actionZoom lensExpert systemPoint cloudSoftwareWindowPairwise comparisonProjective planeComputer animation
54:17
Computer animation
Transcript: English(auto-generated)
00:00
Okay, well, thank you very much. And I also decided to give the talk in English. I first thought I might be the odd one out, but when I wrecked the program, I saw that most talks are actually in English, so I don't have any good reason not to follow that example.
00:22
So thank you very much, and it's a pleasure to be here. Thanks for having me. It's first and foremost a great opportunity to introduce myself here in Jena. As you can see, although I didn't spare words in my title, there's nothing about AI, and there's nothing about data science in there. So this is slightly different for the talk, so I'm going to talk a bit more about myself
00:43
than I would usually do in a scientific presentation. So what about me? I'm, as Johan already mentioned, I'm the professor for systems software for exactly six weeks now. Well, I knew it a bit longer than that, but six weeks ago I arrived in Jena. That's barely enough to find this room, but I had another thing here, so last time I searched
01:04
long for it, and today I knew where to go. That's a good thing. The research group on systems software is, I would say, a group in the making. I have a form to apply for staff, and I have theoretical positions, so if you're interested, if you're a student, but I think most people here are not students, just looking at age,
01:23
my natural AI, no, that's just it, natural intelligence age classifier, I would say most of you are not students. So what is systems software? Actually, I've been, when I proudly talk to my former colleagues that I've become a professor for systems software, they ask me, well, what the heck is that?
01:43
And well, I could have looked at the advert from a couple of years ago, but for me, systems software is basically everything between the hardware and the application software that does all the funny things, all the fancy things that we have seen today so far. So it's about operating systems, programming languages, compilers that implement programming
02:02
languages, and runtime systems that are basically the dynamic part of implementing programming languages. Now, that's about what brought me here, so, but how did I get to Jena? How did I get here? I started my academic career in Kiel, which is around about here, for those who are not,
02:20
per se, born in Germany, as there might be a few here, that's up here in the north of Germany, close to the Baltic Sea, actually at the Baltic Sea, although it's more like a fjord, and I spent around about a decade in Kiel, I studied informatics and economics in Kiel, and later did my PhD in computer science, and I became a doctor, a lot of medicine,
02:43
so it's typical German misunderstanding, I can't help you with diseases, only with programming languages, maybe. At the time I was at Kiel, it was the topmost university in Germany in the 90s, later the government of Schleswig-Kolstad decided to found a new university in Flensburg, which is up here, so now Kiel is only second place in Germany.
03:04
That's what I did, spent 10 years, and then a little bit shorter, I went on south to the University of Lübeck, which is the other university in Schleswig-Kolstein, again at the Baltic Sea, or actually at a river this time, but also a port city. What did I do there? I, well, I did my postdoc time, basically, as a Wissenschaftlicher assistant, so I became
03:24
bämter for the first time. Lübeck is a very nice city, as you can see, old people might remember it from old German banknotes. You might have seen this on some two euro coins, it's probably the most fancy landmark
03:41
of Schleswig-Kolstein, so it made it to the, when you have these 16 coins representing the 16 federal states, this one made it for Schleswig-Kolstein, which is quite funny because it's about 800 years old, and it's only 80 years for Schleswig-Kolstein, because Lübeck only joined Schleswig-Kolstein in 1936 or 1937, under, let's say, non-democratic circumstances,
04:08
which is also the explanation why it seems to be like a small step from Kiel to Lübeck, there's still to present day neither a proper road in the two cities nor a proper railway line. That was my time in Schleswig-Kolstein, it was time to leave at some point to get some
04:23
international experience. So I move far, far to the west, to here, which is actually not London, it's almost London, it's as expensive as London, it's a place called the University of Hertfordshire, and Hertfordshire is about one of the counties here, and it's this area of England, which
04:43
is called the home counties, where everything looks like Harry Potter, so the movies are just all about right, the only thing you can't see is that in Harry Potter's dormitory there's no heating, and that's also what normal houses have, no heating, and my house had a brick stone wall about this thick, and no heating, well, it has heating, but not really working
05:03
heating. Anyhow, that was my adventure in Hatfield, in a little bit north of London, like 10 kilometres from the city centre of London, and this is what Hatfield looks like, the university is a modern university, not Cambridge or Oxford, not as famous as those, but there's a famous building in Hatfield, which is this one, and this is Hatfield House, and this is actually
05:25
where the chancellor of the university lives, or lived at the time, I'm not sure what's today, but in those days, and now you might think that academic salaries in the UK must be great, don't go there, they're not as great, because the chancellor of an English university
05:40
is not the boss of the university, it's more like an honorary title, the actually boss is the vice chancellor, so it's just the opposite of America, where's the president, who has to say, and the vice president who does nothing until the president is killed, which doesn't happen all the time, in England it's the other way round, just to fool the Americans, so there the chancellor has nothing to say, and the vice chancellor is the boss.
06:03
So this was the, I don't know, seventh, eighth, or ninth Marquis of Salisbury, who was living there for probably the last 300 years, more or less since it was built, I'm not sure if he has central heating, but well, at least he has more money for other things, what's important about that is actually the place where Queen Elizabeth grew up, you might think of Queen Elizabeth, wow, that's the girl who just died last year, no, Elizabeth the first,
06:26
she grew up there, in the 15th century, and she did not live here, because that was new, it's almost new, too new for Elizabeth at least, the first, she grew up here, which is basically 100 meters left of here, so it's the same garden, and this is a quite
06:41
nice place, so if you ever get to there, it's good, my family still lives there, you can only visit it when they like it to be visited, which is something like Tuesday afternoon for the East Garden, and Wednesday morning for the West Garden, and I didn't find a nice picture of that, that shows it for, let's say, the, that was royalty free, so I looked
07:03
for that, but actually has an alley, an avenue that goes towards this palace, which is four kilometers long, and it goes straight with the trees lined up left and right, and that's all his private property, and actually if anyone has seen this movie, there was a biopic of the life of Queen Elizabeth the first, a few years ago, called Elizabeth, and if
07:23
anyone sees it, that's actually shot here, on these premises, so where she lives, so of course it's England, so everything that was built 500 years ago is still there, and most of the country is that old, that was that, so I spent a few years there, first as research fellow, later as principal lecturer, which is something like, well, there's a lecturer,
07:41
then there's a senior lecturer, then there's a principal lecturer, and that's where I ended up with, and after three years, I found it was time to go back, so I went east this time, as further west is not that much, and I went, no, sorry, that was the wrong direction, no, it's not right, it's the right direction, so where I ended up in Amsterdam, at the University
08:01
of Amsterdam, so probably you know where Amsterdam is, now it's really Amsterdam and not something close to it, this is Amsterdam, I started as an assistant professor and later was promoted to associate professor to those who are my Amsterdam years, and these are actually more or less precisely 15 years that I spent in Amsterdam, so I got really a little bit attached to the country, so what needs to be said about the Netherlands, it's a very beautiful city,
08:26
this is the Rijksmuseum, because the Netherlands is a Rijk, so I was a Rijksamtenar, Rijsperamter, that sounds a bit strange for German ears, but that's how it is, because it's a Rijk, it's a kingdom, what else is interesting, my office was on the third floor, so much higher
08:44
than here, to the ground, but still it was just about sea level, because, well, it was reclaimed land, reclaimed about 250 years ago, so used for agriculture for many years and then our buildings were built there at the outskirts of Amsterdam, but the Dutch
09:00
are very good in engineering, let's say, dikes, and as you can see, Amsterdam is no longer at the sea, which you can hardly see here, maybe on the previous slide, if you go one back, so this used to be the South Sea of the Netherlands, that's why they called, that's what they called the South Sea, we think about the Pacific, they think about that, but there was a dike built already pretty early in the thirties, and half of the South Sea was reclaimed,
09:25
so this is all, all this land that you can see here, from here to here to here, is all fortified with just below sea level, you build a dike around, you pump it out, that's how it works, and you have to continuously pump out, otherwise it got drained in a few days.
09:41
That's the Netherlands, what else to say about the Netherlands, it's an interesting country, I think it's a different perspective, because it seems to be a small country, round about this, smaller than lower Saxony or Bavaria, but with much higher population, so it's very dense, so something like 10 million people live between Amsterdam and Rotterdam, in all kinds of relatively small cities, and it's a huge country, because the Netherlands is
10:05
the only European country that has a border with Venezuela, you know, you might think wow, how does that come, because there are some traces of the colonial empire still there, so the Netherlands owns five and a half islands in the Caribbean, and it's really five and a half islands, because they own five real islands, five islands, and half of one island,
10:25
this is called Sint Maarten, and the other side is called Saint Martin, it's owned by the French. So we also have a direct land border to France, this sometimes gives particular peculiar things, because on the one side of the border you pay in euros, because it's an overseas department
10:42
of the French Republic, and on the Dutch side you pay with the Entild's Gilder, which is the currency of the Dutch Caribbean, which is these five and a half islands. But yeah, it's quite interesting, because I never heard about these islands before, going there, and in the Netherlands everyone knows them, they are in the news, and these
11:03
islands are municipalities of the province, some of them, they have five and a half islands have three different legal statuses that it's very hard to keep track of, and they are very far down on this map. Right, that was my time in the Netherlands, and then I came here, Vienna, finally.
11:21
So that's in a short what brought me here. But now I've talked a lot about me and these countries, and so what about my research? Now I'm not working in data science, I'm working kind of in system software, and again what does system software do? It bridges the gap between hardware that you all want to use, or have to use, we don't
11:43
like to see the hardware details, but we have to use some anti-application software. But this is kind of difficult, so what can you research in this area? Because hardware evolves all the time, and there are hardware people, or technical computer science as it might be called here, and they continuously invent new things, and hardware
12:04
becomes more parallel, more heterogeneous, overall more diverse by the day. Now the question for me, that's the underlying question of my research, who is supposed to program all this? Where's the engineering productivity, where's time to market, where's cost in the software engineering, and also the fact that typical parallel heterogeneous systems are programmed
12:23
by hardcore ninja hackers, but there's a very limited supply of these hardcore ninja hackers, and in HPC, in high-performance computing, it was kind of normal that you spend four years of a PhD in optimizing ten lines of code directly for one machine, which was outdated by the time you made it, but for the normal, let's say, average, let's say, software market,
12:46
this is just not economically viable, but on the other hand, we also have to deal, many more people have to deal with these machines today than, for instance, ten years ago. Now system software to the rescue, what's my work here? I work on domain-specific languages, so languages that are closer to the actual domain that
13:04
they are, let's say, meant for, that have domain-specific abstractions, whatever domain means in this case, and I will show you some examples of that that I've worked on, but in principle domain-specific can be any domain, first of all. Then you need optimizing compilers that do static analysis, which is benefited by the
13:23
fact that the abstraction is closer to the domain, so you know more about the code than in the general-purpose language, generally, and then we have, of course, all the stuff that compilers cannot decide, because you cannot decide everything at compile time, some things actually pop up at runtime, so the flip side of the compiler is the runtime
13:41
system that basically gives you the dynamic support while executing your code, and all that targeting heterogeneous parallel architectures, and, what's very important, you typically have so-called non-functional requirements, or, let's say, objectives that you have with your code, and we kind of all have them, but normally, the main objective is that the code
14:02
is correct. That's, of course, a whole kind of community that looks into proving code correct against some specification, and that is the functional requirement, and I'm not working on that. I'm working on non-functional requirements. You might have speed, so, typically, software needs to be fast enough, but if you start using, let's say, parallel hardware, then the question is, of course, why would you
14:24
do that if you can't benefit from that hardware, and then it would be just cheaper to buy, if you can these days, of course, to buy, let's say, sequential hardware, but we have also other domains where it's important that you have an answer within a certain, let's say, timeframe, not eventually, or not just as the best effort thing, but in a guaranteed
14:42
way, and the quintessential example is always the airbag. You would like to have them explode in this case of an accident in time, and not just a minute later because you just changed the station of your radio at the moment you had the accident, which is quite likely, by the way, because if you fiddle around here, at least in my old car, I have to fiddle down there somewhere, and that's, of course, prone
15:03
to accidents, so, and then we have other things like robustness for tolerance. What about if your hardware is failing? What about if your software is failing in, let's say, unforeseen ways? Can we be robust against these things, and can we, for instance, use parallel hardware
15:22
that gives us more compute power to improve on the robustness and fault tolerance of our code, and here robustness and fault tolerance are just, would suggest that this is about hardware failure or software failure, but it could also be attacks, which basically are often, let's say, or make themselves similar in observation as hardware or software
15:46
failures. Right. This is what I'm doing, so I'm working on domain-specific programming abstractions, doesn't have to be a complete language, can also be just, well, tailor-made abstractions, optimizing compilers to data front-time systems for heterogeneous parallel system architectures.
16:03
And then there's a couple of cost-cutting issues, like how, for instance, do we achieve portability across hardware diversity, can we, for instance, program various classes of hardware, or perhaps all classes of hardware, with single abstractions, who does resource
16:22
management, the more complicated by systems the systems get, the question is who manages all these resources that I have, these sources, could be memory, could be cores, could be processors, and so doing all that manually over time is, well, is quite, let's say, labor-intensive to program all that, and it's, well, the opposite of productive software engineering.
16:44
Then we have this aspect of energy time, energy, mainly energy time, but I also have here security for historical reasons, awareness, can we make software that reflects itself on its timing and energy behavior? Then we have the fault attack tolerance that I mentioned already. And also, an interesting question is about comprehensibility, because that's what we
17:04
had in AI, it's great if your AI system tells you, well, this is the class A and this is class B, but you would also know how certain are you about that, and if it tells you 45%, then it's not so good. And it doesn't make a difference if your AI system is very, let's say, confident, or very
17:22
highly confident, or let's say, certain about the answer, or not that certain, if you can know about that, that's an asset, and it's the same here, do you know why your system basically needs certain requirements? This is what I'm going to do. I want to show you a few things today, as also mentioned in the title, and I want to
17:42
talk a little bit about this data parallel functional array language called SAC that I have been working on for quite a while, not just me, other people as well, that I will acknowledge later, and then I will go onto a language that is about coordination for cyber-physical systems, this is where we have these robustness aspects, or also
18:01
energy and timing aspects covered, and I want to end a little bit with a view on green computing, what that might be in the future. Right, so, this is not really about data science, my apologies for that, I hope it's still a little bit interesting to you, and it's also meant to see what the future brings, because
18:21
one thing that is also clear is that data science and AI are also cross-cutting themes that are very important also in systems software research, so we use AI more and more to actually solve the problems that we use to solve the heuristics, and this is also an interesting research topic, and perhaps other techniques could be used to implement AI or data science
18:42
problems. Let's see. So, what about this language? This language was basically originated, the question is, if we talk about parallel computing, we have a zillion of different architectures, it goes from simple multi-core systems to let's say a bit more complicated multi-socket multi-core systems, to clusters, to GPUs,
19:04
to multiple GPUs, and so on, and you can make it a bit more complicated than that. And the question was, can we basically come up with a language that could be used to program all these systems, while achieving, let's say, reasonable performance, not necessarily even ninja hacker performance, but let's say the better performance, the better the performance
19:26
than what you could get if you just did computer science, and not necessarily specifically courses on parallel computing. So if you want to cover all kinds of architectures, then one of the key design choices is that
19:40
you need to be completely target and resource agnostic, because once you start to program for one architecture and try to move it to another architecture, you're typically lost, because the user makes design choices specifically for that architecture. That's something that you can see for instance in OpenCL, where it's meant to be, it's advertised as being architecture agnostic, but in principle it's a GPU model, but you can also compile
20:04
to CPUs, because CPUs are less restricted than GPUs, that way around is easier than the other way around. That's what we wanted, and then basically take one source and compile that to many compilation target with, I would say, competitive performance, that means not outperform a ninja hacker,
20:22
that's not realistic at all, but use one source across a wide range of architectures. That was the general goal that we followed with that, and instead of going through a language definition, I just want to show you an example, and hopefully that's a little bit intuitive. So this is one-dimensional complex fast Fourier transform, and here I have sketched out a little bit the data flow that you can use, there are many algorithms for doing FFT, but
20:45
this is the one I chose here. So basically you start with a vector, in my case it has eight elements, and then you basically sort it into the, let's say, the ones that even index positions if you start counting at zero and odd index positions, you recursively apply FFT, of course until the vector becomes
21:01
too small when you have a direct solution. And then you do a little bit of arithmetic, so basically you could multiply the elements of this four-element vector to some pre-computed roots of unity, and then you do a little bit more arithmetic to get to these two vectors at the end, and then they are just concatenated to again form an eight-element vector, and this is how the recursion works, you put in
21:22
an eight-element vector, you recursively solve it for four-element vectors, and in the end you again have eight-element vectors to give back to the previous level of recursion. Now the question is how can you define this in single assignment C, and you see, well the syntax at first looks very familiar, there are just a few differences, it's a curly bracket language after all.
21:40
One thing we see here is that there's a complex type, okay you can define that, complex is a two-element array if you want, a vector with two elements, so this is new, so this is a vector of complex numbers, so this one dot suggests one dimension, so a vector, and I get a vector of complex numbers and a vector of roots of unity, and why this bracket has moved to this line I have no explanation for.
22:02
What we do here now is basically what we do is we have a very functional specification, so we apply operators to arguments, we do not have, say, object identities, we do not have arrays in memory, where these arrays are stored in memory, how they are stored, how long they are stored, this is all completely up to the system in this case, and so we do
22:23
here is basically we condense the argument vector v with a factor of two, so that means take every second element, and that gives me exactly this vector here, and then I can do the same trick again, but now I need a little bit of an offset, I want to drop every second element, but from the second element onwards, and I can do this with a drop operation,
22:41
so I drop one element of the vector of v, and then I again condense it with a factor of two, so I take every second element after I have reduced it to a seven element vector, and with that I, I guess we get all the odd indexed positions, then I recursively apply FFT, that looks now basically exactly the same as an FFT, and then I do another step
23:04
of, of, I condense my roots of unity to align them basically with the, with the size of the vectors, you see they're always half the size of the vector, so here I continue, yeah,
23:21
with the basically half the size, and then I do a little bit of final arithmetic on complex numbers, on vectors of complex numbers, so always operators can be overloaded in this language to any type you like, so complex is not a built-in type, complex is a defined type, so these are actually two element, two, two dimensional arrays, this is a vector of
23:41
two element arrays, so basically a matrix of, could be as long as possible, but with two, two rows, or the other way around, and eventually I concatenate the two elements, so what the essence of that is, is that you can, I can take a textbook specification of an algorithm, analyzing the data flow, and I can turn this more or less one-to-one into code, and I'm not dealing with memory allocations, deallocations, I'm not dealing with where
24:05
arrays are really materialized, the fact that I'm taking a drop, which could in other languages use an intermediate result, and then I, I process it further, that is up to the compiler to actually not do it, yeah, that was basically a little bit of a, of a code teaser, a little
24:26
bit of what is so special about this code, now I, I understand that functional programming is not, is not really something taught here, or it's not, not a big thing in Jena, I learned that in the last weeks, and so I understand that maybe I tell something to be functional,
24:42
doesn't ring much of a bell, so what is this about? So all the arrays are immutable values, so I'm not, I'm not changing an array, it's impossible, all array, all arrays are immutable, so I want to change one element, I have to copy the whole array, at least conceptually, all arrays, all fun, let's say, I only have values, that's why I don't have object identities,
25:05
because everything is a value, like in Java, integers, or floats, or booleans, or so obvious elementary types are values, and if you want to go beyond, you have to create objects, and now all of a sudden they go to the heap, and this is kind of very confusing, so here
25:21
everything is a value, if it's an integer, or if it's a big matrix of integers, or whatever, how many dimensions you can still imagine, is a value, so if I call this here, if I call FFT, and I call FFT again here, I transfer values, not pointers to something in memory.
25:41
What else? Well, all these array operations are not hardwired in this compiler, that would be easy for plus and times, but actually they are defined in the language themselves, but I don't want to show that, and if I have variables, then these are just placeholders for values, so I can basically give values names, and that's all I'm doing here, and if I would
26:02
write something like A and B, and A and B are two terabyte, let's say, arrays, then in many languages there would be a copy of two terabytes, and that is not so fast, and in this semantics it just means another name for the same value, so basically a pointer copy, in system speech. Right, that's this, and all the resources are automatically managed,
26:24
so there's nothing, there's no memory going on here, there are no cores, there's no, yeah, no computer architecture that I'm programming this for. And now if I want to extend this a bit to a three-dimensional FFT, then the idea of 3D FFT is basically you have this cube, and I interpret this cube as a matrix of vectors, like I do in this first direction,
26:45
I apply one D FFT to all these vectors here, I get another cube, and then I change the interpretation, and I say now, now it's basically a matrix of vectors that go from top to bottom, and I do another FFT, and then I have the third dimension, so I say now it's a matrix
27:02
of vectors that go this way, and I again apply FFT, and that is now my 3D FFT, and that can be written basically like this, I don't want to go into the details, what you see here is basically a three-liner, and we just do these different interpretations of my 3D array as a matrix of vectors across a certain dimension, and you see the dimension always changes,
27:22
it's this dot here, that's the dimension I'm interested in, and each time I apply FFT, which is the FFT I've shown on the previous slides, and now this 3D FFT is a kind of, say very FFT well-known benchmark from the NASA benchmark suite that is not particularly new, but so there's also a solution with that in FORTRAN, and this is the FORTRAN solution
27:44
for the same code, and as you can see two things here, it's not so easy to write this, it's not so easy to write this correct, but now we know that this is correct, this is the kind of ninja hacker version of doing things, also the fact that this actually does something that is like FFT can basically be seen because the sub-routine is called FFT,
28:04
and the rest I have to believe, and of course in the case of FFT I can check if the result is correct, but with many other software if you do simulations for instance that you don't know the result, that's why you do the simulation, and then you believe that, and then you draw perhaps interesting conclusion from that, from results.
28:21
Right, that's a little bit about SAC, it's just a bit of summary here, so it's basically the code is I would say relatively simple and concise compared to other languages, and it's 100% algorithmic, so you express an algorithm, and you can focus on the algorithm and not focus on all the, let's say managerial aspects, resource allocation, deallocation of the source
28:44
distribution and all that, that you normally have to do in imperative languages. There's no intertwining with management code, no intertwining with parallelisation code, this by the way was also sequential only, so if you want to do this parallel then you have to do write more code, alright.
29:03
And so the advantage of course with respect to parallelisation is that in parallelisation you can do all kinds of things wrong, you have race conditions, you have deadlocks and lifelocks and all kinds of whole bunch of new ways to make things wrong, and this all
29:20
goes away here because you basically write one code and if you're happy with the results you think it's correct, then you can just parallelise it by telling the compiler for what you want to parallelise it, that's the idea behind this. And that of course evades all these kind of problems. Right, and then it's a compilation challenge of course is to go from this to all kinds
29:43
of different architectures, what we have done is basically we have done these that I have here, so multi-core, multiple, multi-core processes, GPU to use, also Xeon Phi, okay no one knows this anymore, but it was an attempt of Intel to compete with Nvidia, we looked
30:03
into heterogeneous systems with different GPUs, we also had, okay this is also, really no one knows anymore, the ultra-spark series of some microsystem was interesting because it was the biggest shared memory system that I have seen, you could buy a box like this size you could put on the desk and it had 512 cores, or let's say hardware contexts,
30:22
and that was the, so far I think the biggest I have seen that supports a hardware shared memory, or hardware, yeah. And we had that as well. Right, so, move on, I don't want to take much about the detail, but it's one way to define a language, but you have now to show that it really works, that takes a lot
30:41
of time and effort, it's a huge compiler for academic standards, 350,000 lines of codes and all kinds of things, and we also as a side product of that to keep that manageable we also developed a compiler construction framework that I used later in my compiler classes and that I also want to introduce here, and in my compiler class in Amsterdam
31:03
that I used to teach, basically the students build with this framework and see a compiler for a non-trivial language that has, I don't know, typically the C-like, or C-like control flow elements, nested scopes, multi-dimensional arrays, and all that in seven weeks. So that's
31:22
proved to be kind of helpful, and there was a side product of this, I didn't do this alone, I did a small fraction of that, so my main collaborators are, well, oh, okay, this was not the right version of the slide, so the hardware share list has long died out,
31:43
it's okay, sorry. So my main collaborator now is, again in the Netherlands, in Nijmegen, or Nimwegen in German, in the east side of the country. We had quite some funding from the EU, FP7, it's not the latest funding, so this is a very long time ongoing process,
32:02
also national funding and loads of bachelor and master projects. Now that, I want to move on to something completely different, and to cyber-physical systems. So, why cyber-physical systems? Because cyber-physical systems rule the world. Actually there's an estimated, I don't know, 98% of all computing devices are used in cyber-physical systems, and not
32:23
on laptops and desktops, or HPC, HPC systems account for a tiny fraction of computing devices. So cyber-physical systems are everywhere, and what's a cyber-physical system? It's basically a system that consists of computing parts, that's a cyber part, and cyber is of course a very fancy term, but the main point is that the way the computer works controls things
32:45
in the real world, and if that goes wrong, it's much more annoying than the blue screen. For instance, if the pilot of this Airbus sees a blue screen while flying, that's not so great. You don't see it as a passenger, but you don't want that, for sure. So that's
33:03
why there are some other, let's say, concerns in this area, and these concerns that are non-functional properties are really very important, they're more diverse. So I would say with this work on SAC, the non-functional property was that we want to get as good performance as possible, so it's not so difficult to implement it, all these language features, if time is
33:21
no concern, if it can run arbitrarily slowly, then it's not so difficult to implement that. The difficulty is to implement it in such a way that you are in the same ballpark as let's say, averaged skilled programmers in C or Fortran. So here for these kinds of things, other things matter, mainly time, you need to have the answer in a certain time frame.
33:44
Energy matters because many devices are battery-powered, so the time that whatever you spend in energy directly affects the usability of the system. Again, it's easy to build a mobile phone that runs for 10 minutes with a given battery, but it's not very useful either, if you want to run it for hours, and so it matters what you do on the system and how you do it.
34:05
On the other hand, so the systems that are used in cyber-physical systems for a long time have been relatively, let's say, boring architectures, so fairly simple signal processors for which you can't do that much from a computer science point of view. And that has radically
34:21
changed in the last few years, and now this is kind of very common or very widespread architecture, basically these high-performance embedded computers, where you have typically an ARM architecture with two kinds of CPUs, you have some, in this case, I think it's
34:40
an A15 core, which is a relatively big core with, let's say, out-of-order execution, relatively powerful but also energy-consuming, and there's another kind of core called the little ones, and these are very, let's say, energy-efficient cores but not very computationally powerful. And this is typically bundled with a GPU, and there are a number of, let's say, system
35:02
integrators, like Odroid or NVIDIA Jetsons series, and there are all kinds of variations of that, how many cores you can afford, and so on. And this makes it interesting because parallel computing is back, that's my underlying theme, so these are interesting from a parallel computing point of view, but slightly different from, let's say, more of, let's say, eventually
35:21
HPC-oriented work, that I did before, because you want to map applications with the same properties on these architectures, on these different properties. And the question is now how do I run my application on such an architecture depending on the objectives that I have to phrase, so what's my objective? Perhaps meeting deadlines is a good objective,
35:43
but saving energy is also a good objective, and now I'm ending up with these multi-objective optimization problems. So here, scheduling and mapping matter, so the question is where do I run what, and how? And now, the question is how can I use these architectures to benefit my non-functional properties, and of course it's now application dependent, what is more
36:05
important than the other, I have to phrase that. Now the software engineering challenge, and here we go a little bit to software engineering again, is how can we manage all these, in this case, these four trade-offs, because they're really trade-offs, right? If I want to compute something fast to meet the deadline, I probably have to use the energy inefficient
36:23
core, right? That's no way around. Depends what's more important, right? So for the airbag example, I think it's more important that the airbag, let's say, reacts in time, than that I save a lot of energy while running my car, because it might be the last thing I'm doing, and then I can even not use the petrol in the car anymore. How can I do this?
36:44
Without completing a compute software mess, because if you think about programming all this typically in C, sometimes in C++, and you have all these options where you do not a priori know exactly how to do this, that creates pretty much a software mess. And that's where we devised this collation language called Teamplay, which basically means the treats,
37:06
or it's the idea of the treats, these properties, these non-functional properties that you hardly see normally in source code, as first-class citizens for software engineering. How does it work? It builds on the, let's say, this is not something we invented, this is a long-known concept of exogenous coordination. That means we have certainly identified certain
37:26
software components, and we explicitly model the interaction between these components. We have two levels in our application architecture. We have components that have a certain behavior on a certain hardware unit, and we have this interaction that we have to deal with. And
37:44
this is a bit of an example now, not as source code but as a kind of colorful box. So a component is a piece of software that has code, it has functional contracts, this is the input-output relation, which goes to functional correctness, because of course it depends where, what I want to compute. And now I also have non-functional contracts about that, and that means running
38:03
this code on a certain input data, what time, how much time does it take? On average, in the worst case, how much energy does it take? And this is of course, again, all relative to a given architecture. You cannot say this code runs in 5 milliseconds, you don't know, it depends on what you run it on. And even worse nowadays with dynamic voltage and frequency
38:24
scaling, it also depends on how you configure your hardware, how to use that. So this basically is defined at this level, and we have a few more things, we really love our components to be stateless. Stateless is great, because stateless means I can migrate them across
38:40
architecture, so that's what I want to do. Because if some core fails, for instance in the robustness case, I want to move the computation somewhere else, to some hardware unit that still works. And if that has a state that is embedded deeply in the code, I have no chance of doing that. That's why we like stateless. But not every component can be
39:00
phrased in a stateless way, so then we basically externalize the state, and that's what it's all about. So state per se is not bad, I just have to know about it. And the way we do this is that I can have so-called state ports, where this component sends out information to the right, but then it's just rewired to the input, and this way I make the state known to the system around. And in fact we can model stateful components.
39:26
What else do we have here? We have multi-version components, because often I have options to run a certain piece of code. This might be because I have hardware units that are not binary compatible, for instance in the GPU, I have to run different binary code than on the CPU, and if I have two different kinds of CPU cores, or more kinds of CPU cores,
39:46
I might also optimize, even if I can in principle run the same binary on all architectures, I might want to optimize it specifically for a given architecture. And if I don't know a priori where it's going to run, because that's part of the design process, it's very handy to have multiple components, you have multiple implementations with different non-functional
40:05
properties. And this can all be given to a system that makes best use of that. Then of course, not so surprising, we want to wire these components to a running system, where basically this is a data flow system, where data basically flows through the system, so these are basically sources that are connected to the outside world, we have this idea of
40:24
a cyber-physical system, so these basically connect us to sensors in the cyber-physical, in the physical world, then we have our cyber system that is of course supposed to be larger than four components, and then we have thin components like this one, which again, let's say controls actuators in the real world. That's the rough assumption of that. And then
40:44
on this level, we want to reason about our non-functional properties, not necessarily all at the same time, but depending on the application. I want to show you this again by an example that we did with our then-project partners in Denmark. Skywatch is a company in Aalborg that builds these drones, and the interesting thing about these drones, unlike
41:04
the propeller drones that you can buy sometimes at Lidl or Aldi, is that they are super energy efficient. So once they are up in the air, they can stay in the air for hours with almost no energy. And you can use them to patrol things, so this is the north coast of the island of Fun in Denmark, and this is basically a patrol area, and the interesting thing is
41:23
that they have basically two computer devices on that, one that keeps the thing in the air and actually makes sure it flies certain missions that are predefined, and that's you're not even allowed to mess up with, because otherwise your drone could be lost and that's still an expensive thing. But there's also a payload computing system and cameras, and the interesting
41:45
thing is that the payload compute system that looks a bit like what I've shown you before with this heterogeneous architecture, and these systems actually consume way more energy than keeping this thing in the air, if you actually use them. So that means if you use them wisely and if you map and schedule your application well to the underlying computing
42:06
architecture, you can stay longer in the air, and obviously that's an asset. And the idea here was that you can detect, for instance, lifeboats in a sea area completely automatically and raise alarms if you find a lifeboat that's not supposed to be there. So, okay, I'm towards
42:22
the end. This is how we can model this now in, let's say, nice colorful blocks. You can see here at the beginning we capture an image that's controlling the camera, and then we have certain, let's say, encryption component and object detector, which uses different kinds of neural networks that I could have, and they have, say, the more accuracy I want
42:43
in my neural network, of course, the more compute power I have to invest in that. And then there's a kind of decision-making tool that says, oh, there's a lifeboat that shouldn't be there, and then I raise some alarm. This is basically the high-level view of that, and if you specify that in this team player language, then this is all the code that you
43:02
have to write, and I know this is way too small. I don't want to go into the details. The message is that we can describe this entire application in basically, well, two pages of code, I would say. It fits the slide. Normally I would now zoom in, but I look a little bit at the time, and I also know that there are snacks, and that's the actual highlight of
43:22
the day, I guess. So I just briefly go through this. So the most interesting difference here is that you actually specify things that you hardly see in general purpose code, and this is in our application drone. We have here a deadline, and the deadline says two hertz, and we have a period that says 500 milliseconds, which is, by the way, the same. This is just
43:42
meant to show that you can define these in various, let's say, units, and that basically means that we specify that we want to run this every 500 milliseconds. That's basically the time I need to cover. You can easily compute it. Basically, if you fly at a certain altitude, your camera covers a certain area below you, and you fly at a certain speed, and then you
44:02
know basically how often you have to take a picture so that you don't miss potential lifeboats. You want to have a little bit of overlap, but not too much, and of course not less. And that's also the time when you should have computed your compute mission, completed your compute mission, because if not, then you see this, and this is before we, that's
44:22
what I talked a little bit about already. So this question is now, how do I map and schedule an application that is written in this style to a heterogeneous parallel architecture like that to make optimal use of my hardware? Now, that's this thing. Let's just move quickly
44:41
through this. This is our implementation architecture. This is more like a compiler toolbox, and the maybe interesting thing here is if you have a coordination file, that's the source code I've shown you, and then you have a non-functional properties file, because if I go back to my 500 milliseconds, then 500 milliseconds is an application specific deadline,
45:02
because that's, the application provides that. It's not something I dream. It's not like I want, well, one second is not enough, and 200 milliseconds I don't need. That's because of the application. But the hardware I'm running this on, so that needs to achieve this, it might be as a parameter of my model, and so I need to know how long my components take
45:23
on a specific hardware. That's why I need this non-functional properties file that tells me if I run this component on a little core, it takes that amount of time. If I run it on a big core, it takes that amount of time and that amount of energy. This is something I need to determine first. Okay, that's all I want to say about this. Now coming back
45:40
to the example, that's the original code that we got from Skywatch, and what you can see here is in a nutshell is two things. So basically we compute something like 1600 frames here, so it runs for quite a while. That's basically the mission time, the drawing can stay in the air. And what we can see here is most of the time we miss the deadline. So the deadline was, as you remember, 500 milliseconds, and, well, most of it now, actually most of the
46:03
time we just about make it, but very often I'm below the deadline, and that's bad, because what happens in the implementation was that, well, whenever I'm missing the deadline, I just continue to compute, because I don't want to miss frames. And that's why I have this ever-growing memory usage here, which is the red line, so memory usage goes up, and because I basically part, I queue frames before I process them, so I'm no longer real-time,
46:26
so I would delay raising alarms, and what's worse, if I don't have enough memory, and here it was just about enough, the drone didn't, I mean, I didn't lose frames, but I would, if I would fly the drone a bit longer, at some point I exhaust the memory resources, and then basically the whole system goes bust. Now we rewrote this with the Teamplay language,
46:45
and we applied our technology, and then about, what you might have guessed is, we managed that all frames are really below the 500 millisecond deadline, and that means also constant memory usage, which is what you want for an orderly system behavior in the long run. And we also
47:01
reduced the energy consumption from 3.8 joules per frame to 3.1 joules per frame, which is now the optimization capacity, so here we want to stay in the deadline, and then optimize for energy. That's here the objective, and that's a quite common objective. Alright, that's it, medium-term vision. Once you have specified an application in this exogenous
47:23
coordination model that we have, you can do lots of things with that. For instance, you can use it for robustness, and you have, my current PhD student is working on using that for robustness, so you can, for instance, say I want to run certain components in dual modular redundancy and triple modular redundancy, and so on. Or if a component has failed,
47:41
you want to restart it, which of course gives you the question, how often can you do this before you do not longer hit your deadline, and so on. We work with weakly hard real-time systems, whereas here weakly hard real-time systems are systems that can fail every now and then. You can say, well, I can fail twice out of five instances, five incarnations,
48:02
and then it's still fine, I'm not losing control of that. For instance, with this drone example would be, well, if I lose, say, one frame in five or so, I'm still covering the entire sea, I know that, and so I could be a little bit more fault-tolerant. The question is now, what do I do with that information in my system? And the idea is that eventually we have really
48:21
adaptively morphing embedded systems so far to the present day, adaptively, so these cyber physical systems, or let's say the cyber systems, these embedded systems that run on cyber physical systems are extremely static, so typically these components are really nailed to a certain execution unit, and you want to get away from that and make them more dynamic and more adaptive.
48:40
Right, that's about that. This was funded by two Horizon 2020 projects, this one has ended, this one is still going on, and also by Rosmo Strategic Partnership and the cost action in which I'm kind of active in this area. That's about that. This is my team in Amsterdam, just for the completeness, so as you can see, Zoom is very kind of, Zoom window is very
49:07
characteristic for our work because much of the work happened during lockdowns of various kinds, and in the Netherlands we really had a curfew where we were not allowed to leave your house after 8pm. A bit stricter than here, and other times it was more loose. Yeah, that's what I want
49:23
to say here. Now maybe a few words on green computing, I have probably zero time, oh yes, I have zero time, let's quickly go there, so why am I interested in energy? Well, first because of the battery power devices, but then of course also for environmental concerns, and now that's interesting because much of the software is running, for instance, these edge for cloud
49:41
systems where I can compute something at the edge or somewhere in the fog or in the cloud, and the question where to run what is an interesting scheduling question again, which is kind of similar to the ones we've addressed with these heterogeneous architectures, and so what's the best for energy saving and user experience here? And another example,
50:02
let's give that one, is basically could we move the computation to a place where energy is abundant? Because so far we always think about, let's reduce the energy consumption, but that's not necessary, right? If you have a sunny day with lots of wind, then particularly in the Netherlands, there's always offshore wind parks and lots of solar power like here, we have abundant energy, we cannot, we have to stop the production because we cannot get anywhere with it. And so the,
50:25
other days it's different. So maybe there is enough energy saving, it doesn't really pay, give you benefit. The question is where in a certain geographic area, for instance, EU, for instance, or Europe, is currently energy in abundance available, and you could move your
50:40
computation there if you have choice to do so. That's another interesting idea. And then maybe something completely different is something my project partners, one of these project did, and my project partners did a few years ago, they basically investigated how energy efficient are programming languages. You may say, well, what's a programming language? So they took basically 10 benchmarks from this computer language benchmarks game, which is an online
51:04
adventure where people write given specifications in whatever programming language they like. And the idea is that the expert of a programming language writes the code for this programming language. And that's how we have an interesting source of programs in all kinds of languages, do exactly the same thing. And now we can compare programming languages. So we did actually use
51:25
these 10 benchmarks that were implemented for a sufficient number of programming languages, let's say 27 in this case. And then basically it's a very simple thing, idea is you run the code, yes, I'm almost done. You run the code, and you see how much energy does it take. And the
51:40
end is right is probably interesting. So normalized, you can see we normalize it to C, which was the most energy efficient language. And that's probably not surprising. And of course, the second digit doesn't really count behind the decimal point. But what you see here, if you love Python or Perl, you're not doing well with energy. So running something in Python or Perl takes about 75 times the energy of doing the same in C. That's maybe an interesting insight.
52:07
So recently the Netherlands switched, normally the Netherlands, the speed limit in the Netherlands used to be 130 kilometers on highways. And they changed that because they had issues with meeting
52:21
their CO2 emission targets. And because they don't have a car industry like Germany, they do something about the traffic. So one very simple thing to do was to basically reduce the speed limit to 100 during day times from six to seven. So for 13 hours a day, the speed limit is now 100 kilometers. And for the reasons I don't really understand is they did not change these signs,
52:43
of which they have probably a few hundred on all border crossings. No, they changed these signs, they put these signs to all entry points to the Dutch freeway system. And this is quite a large number. So that's what you find. So it's now 100 between six and seven. And so the question,
53:02
what is that going to bring, is, so I didn't find any data about the Netherlands by googling for that. So it was supposed to meet, to have a big effect. But if I look, I found some data at the Humboldt-Bundesant in Germany. And so if I, if I, let's say, use this data and map it a bit to these
53:20
these speed limits, going from 130 to 100 saves probably around seven to 8% of CO2. That's good. But let's say if you would change Python to C, you could save 98% of the energy consumption. Now think about that. Who's programming Python still tomorrow? Oh, come on. You can drive 200
53:45
kilometers on the highway. It's not as energy unfriendly than using Python, as you see here. With that, I want to more or less conclude. That's my last slide, summary of my stuff. And while I'm new to Jena, I have no particular relations to Turing either. So if you're interested in DSLs
54:03
for your domain, because it's domain-specific and you bring the domain, I bring the L. Let's talk. Thank you very much.
Recommendations
Series of 6 media