Probleemstelling:
Naarmate automatisering en de vraag naar software functionaliteit toeneemt, hebben programmeurs steeds minder tijd om stil te staan bij performantie. Het gevolg is dat software steeds gulziger CPU cycles en geheugen verbruikt. In een conflicterende tendens wordt verwacht dat de software steeds grotere hoeveelheden gegevens verwerkt, binnen een redelijke tijd.
Beide tendensen worden gedeeltelijk gecompenseerd door ontwikkelingen op het gebied van hardware en geoptimaliseerde compilatie. Zij leveren winsten op met een vaste factor: x 2, x 10, x 100, ... Die winsten verbleken echter snel bij verliezen door naief geschreven software. Niet alleen verbetering op het gebied van constante factoren is mogelijk, maar ook een meer fundamentele winst op het gebied van complexiteit: die verbeteringen kunnen het verwerken van grotere hoeveelheden gegevens mogelijk maken. Ter illustratie: het opzoeken van het n-de element in een gelinkte lijst heeft complexiteit O(n). Met een verbetering van factor 100 zou het 1,000-ste element bijvoorbeeld in 10 s gevonden kunnen worden in plaats van in 1,000 s. Het
1,000,000-ste element opzoeken kost dan echter nog steeds ongeveer 20 minuten. Met een
complexiteitsverbetering, door arrays te gebruiken, kost de operatie O(1) tijd, of bijvoorbeeld 5 s onafhankelijk van de positie.
Nochtans bieden de meeste programmeertalen uitgebreide datastructuurbibliotheken (bv. C STL, C++ Boost, Java STL, ...) aan en zijn handboeken (bv. [1]) die adviseren over het gebruik van datastructuren veelvuldig voorhanden. Programmeurs zijn hier echter vaak niet van op de hoogte of hebben geen tijd om stil te staan bij een betere keuze. Voor compilers is deze informatie en de nodige keuzes van een te hoog niveau: ze laten de beslissingen hierover dan ook over aan de programmeur.
Doelstelling:
Het is de bedoeling van dit project om de programmeur de verantwoordelijkheid voor de keuze van een efficiente datastructuur uit handen te nemen. De programmeur mag zijn programma's schrijven en daarbij datastructuren kiezen in functie van eenvoud, snelle ontwikkeling en makkelijke aanpassing aan bijkomende functionaliteit.
Wij willen methodes ontwikkelen die voor deze hoog-niveau programma's automatisch in kaart brengen welke datastructuren gebruikt worden, welke operaties hierop toegepast worden en in welke volgorde. Op basis van dit profiel worden dan alternatieve datastructuren voorgesteld die betere performantiekarakteristieken hebben.
Vervolgens zal het programma automatisch getransformeerd worden om de voorgestelde datastructuren te gebruiken in plaats van deze die opgegeven zijn door de programmeur. Ten slotte zullen testmetingen
(profiling) terugkoppeling geven over de resulterende performantie. Deze pratijkinformatie wordt gebruikt om een accurater profiel op te stellen en geschiktere datastructuren voor te stellen.
Uitwerking:
Binnen dit project willen we een framework ontwikkelen dat verschillende methodes bundelt om de doelstelling te realiseren. We bespreken nu in meer detail deze methodes, de componenten waaruit ze opgebouwd zijn en de context waarbinnen ze verwezenlijkt zullen worden.
Methodes: We denken in eerste instantie aan de volgende drie methodes:
1. De programmeur beschikt over een abstract data type (ADT) met een uitgebreide en veelzijdige interface waarvan de implementatie niet gespecificeerd is. Daardoor moet hij geen keuzen maken op basis van implementatie of aangeboden operaties.
Automatische analyse zal nagaan worden welke operaties effectief gebruikt worden binnen het programma en op welke manier. Met deze informatie kan een concrete datastructuur gekozen worden. Deze moet niet de uitgebreide waaier aan operaties aanbieden, maar slechts deze die effectief gebruikt worden. Automatische transformatie heeft een beperkte impact op het programma dankzij de modulariteit van ADTs. Enkel de operaties die concrete datastructuren aanmaken moeten ingevuld worden. De namen van de andere operaties zijn dezelfde als die voor het ADT.
2. De programmeur maakt gebruik van een concreet datatype, bijvoorbeeld een gelinkte lijst, waarvan de implementatie niet afgeschermd is. Hierbij denken we vooral aan datastructuren die in bibliotheken aangeboden worden, maar we willen ook onderzoeken in welke mate dit mogelijk is voor nieuwe datastructuur die door de gebruiker zelf gedefinieerd zijn.
Gelijklopend aan de vorige aanpak stelt automatische programma-analyse hiervan een profiel op en concludeert
dat een andere datastructuur geschikter is. De programmatransformatie om deze nieuwe datastructuur in te voeren is nu aanzienlijk ingewikkelder. Niet alleen de code die de datastructuur aanmaakt moet vervangen worden, maar ook alle code die de eigenlijke representatie direct manipuleert.
3. De programmeur maakt gebruik van algemene datastructuren uit bibliotheken, maar automatische analyse stelt vast dat deze te algemeen zijn voor het effectieve gebruik. Algemeenheid brengt aanzienlijke overhead met zich mee. Bijkomende data worden bijgehouden om extra functionaliteit aan te bieden die in de applicatie overbodig is. Bepaalde organisatiekeuzes binnen de algemene datastructuur kunnen ook willekeurig zijn. Met behulp van applicatiespecifieke informatie kunnen we beter dan een algemene bibliotheek aangeven welke organisatie we verkiezen.
We benadrukken dat er een duidelijke wisselwerking is tussen de verschillende aanpakken: de datastructuren in 1) en 2) worden gespecialiseerd worden in 3).
Componenten: Concreet zullen we daarom de volgende componenten opbouwen:
– Programma-analyses voor gebruiksgerelateerde aspecten van de datastructuren.
Alias-analyse [13], complexiteitsanalyse [14], control-flow analyse (bv. abstract interpretation [17]), geheugen- analyses (bv. region analyse [16]) en automatische herkenning van algoritmes algoritmes [7] brengen zonder tussenkomst van de programmeur in kaart hoe datastructuren in tijd en ruimte gebruikt worden.
- Transformaties van datastructuren die toelaten om ze aan te passen aan het programma. Het bestaande werk is relatief beperkt, en situeert zich voornamelijk in de context van array herorganisaties [9]. We kunnen ons echter ook inspireren op technieken voor code-transformatie zoals program calculation [10], partial evaluation [11] en refactoring [12]. Bv. dead code wordt dead field eliminatie, code fusion wordt data structure fusion, loop
unfolding wordt recursive data structure unfolding [15], ...
- Programmatransformaties om bestaande code aan te passen aan de nieuwe datastructuren van 2) en 3). Deze transformaties gaan verder dan het rechttoe rechtaan vervangen van bepaalde code-patronen door andere. Ofwel voldoet de huidige code-structuur niet aan de voorwaarden om de nieuwe datastructuur te mogen gebruiken, ofwel levert ze op zich niet de gewenste performantieresultaten op. Daarom moeten aanvullende transformaties uitgevoerd worden.
- ADTs met bijhorende concrete instanties voor 1). Hiervoor kunnen we beroep doen op bestaande concrete implementaties, al zullen sommige operaties veralgemeend moeten worden of in zijn geheel toegevoegd worden.
- Veralgemeningen van efficiente datastructuren zodat ze makkelijk minder efficiente structuren kunnen vervangen voor 2) en gespecialiseerd worden voor 3).
- De aanpassingen aan de runtime environment, voornamelijk de geheugenallocatie van programmeertalen, om de overschakeling op efficiente data structuren te vergemakkelijken. We denken daarbij bijvoorbeeld aan de omzetting van de allocatie van een gelinkte lijst naar de incrementele allocatie van een array in aaneengesloten geheugenposities. Een flexibelere vorm van memory regions [12] komt hier van pas.
- De instrumentatie van code en de runtime environment met code om profilingdata te verzamelen over het gebruik van datastructuren.
Context: De eerste bijdragen zullen geleverd worden in de context van een eenvoudige eerste-orde functionele programmeertaal (FP)(een subset van ML of Haskell). Enerzijds is dit een dankbare context voor programma- analyse: de control-flow van programma's is makkelijk af te leiden en de bewegingsruimte om datastructuren te gebruik is beperkt (read-only). Bovendien is er reeds veel basiswerk voor de noodzakelijke analyses gebeurd in deze context. Anderzijds is er voor FP talen veel te winnen: het zijn hoog-niveau talen die vaak gebruikt worden voor rapid prototyping en rapid application design. Hierbij programmeert men bijna uitsluitend in functie van eenvoudige datastructuren zoals lijsten en tupels. Veel efficiente datastructuren zijn ook helemaal niet uit te drukken in deze talen, namelijk deze waar in-place updates en O(1) geindexeerde toegang nodig zijn (bv.
arrays). Bij compilatie kunnen we zulke efficiente datastructuren wel invoeren.
In een later stadium gaan we over naar de meest verspreide klasse van hoog-niveau programmeertalen: object- georienteerde (OO) talen. Deze bemoeilijken omwille van hun imperatief (in-place updates) en dynamisch (dynamic binding) karakter accurate analyse, maar de reikwijdte van de ontwikkelde methodes is hier veel groter. Bovendien is het concept van ADTs en modulariteit een van de hoekstenen van het OO paradigma [6].
Hierdoor kunnen we met onze automatische concretisatie van ADTs goed inspelen op de gangbare
programmeerstijl.
Inpassing in de onderzoekseenheid:
De onderzoekseenheid DTAI heeft reeds vele jaren ervaring met programma-analyse en -transformatie, zowel op het gebied van declaratieve talen als multimedia-toepassingen in C. In het bijzonder is er gewerkt rond compile-time garbage collection in de context van Mercury [3] en Constraint Handling Rules [4]. Dit project bouwt verder op deze resultaten en de studie over de complexiteitsverhouding tussen RAM machines en declaratieve talen [5].
1. T. Cormen, C. Leiserson, R. Rivest, Introduction to Algorithms, MIT Press, 1990.
3. N. Mazur, Compile-time garbage collection for the declarative language Mercury, Ph.D. Thesis, Department of Computer Science, K.U.Leuven, 2004.
4. J. Sneyers, T. Schrijvers, and B. Demoen, Memory reuse for CHR, Logic Programming, vol 4079, Lecture Notes in Computer Science, pp. 72-86, 2006.
5. J. Sneyers, T. Schrijvers, and B. Demoen, The Computational Power and Complexity of Constraint Handling Rules, TOPLAS, 2007, submitted.
6. D. Parnas, J. Shore, and D. Weiss, Abstract Types Defined as Classes of Variables, Conference on Data: Abstraction, Definition and Structure, ACM Press, 1976.
7. R. Metzger, and Z. Wen, Automatic Algorithm Recognition and Replacement - A New Approach to Program Optimization, MIT Press, 2000.
9. K. Van Oudheusden, EASYMAP: A semi-automatic and correct-by-construction abstract data type refinement tool for pointer- intensive applications, Ph.D. Thesis, IMEC, 2006.
10. R. Bird, A Calculus of Functions for Program Derivation, Res. Top. in Func. Prog., A-W, 1990.
11. N. Jones, C. Gomard and P. Sestoft, Partial evaluation and automatic program generation, Prentice Hall international series in computer science, 1993.
12. M. Fowler et al., Refactoring: Improving the design of existing code, Addision-Wesley, 1999.
13. W.Landi, and B.Ryder, A safe approximate algorithm for inter-procedural pointer aliasing, ACM SIGPLAN Conference on Programing language Design and Implementation, 1992.
14. M. Rosendahl, Automatic complexity analysis, FP languages and architecture, ACM Press, 1989.
15. Z. Shao, J. Reppy, and A. Appel, Unrolling lists, ACM SIGPLAN Lisp Pointers, 1994.
16. M. Tofte, and J. Talpin, Region-based Memory Management, Information and Computation, AP, 1997.
17. P. Cousot, and R. Cousot, Abstract Interpretation, ACM Computing Surveys, 1996.
Uw wetenschappelijke publicaties met opgave van titel, auteurs en bibliografische gegevens ingedeeld als volgt : - boeken waarvan u auteur of co-auteur bent
- publicaties in tijdschriften of boeken met leescomité - publicaties in tijdschriften of boeken zonder leescomité - werken waarvan u wetenschappelijk uitgever bent - abstracts van lezingen
- recensies
- bijdragen in encyclopedieën, woordenboeken en vulgariserende publicaties - interne verslagen
Indien nog niet werkelijk gepubliceerd : vermeld of het werk ter perse is, aangeboden ter publicatie of slechts in voorbereiding.
(Deze publicaties dienen het FWO NIET toegestuurd te worden)
CCHR: De snelste CHR Implementatie
Titel licentiaatverhandeling of eindwerk. (Deze dient het FWO NIET te worden toegestuurd.)
