Communicatiebewuste plaatsing van data in een gedistribueerd rekensysteem

Het uitgangspunt van dit doctoraatsproefschrift is de vaststelling dat communicatie cruciaal is in gedistribueerde rekensystemen. Door de evolutie naar een steeds groeiend aantal rekenkernen op één enkele chip, wordt communicatie tussen die kernen steeds belangrijker. Binnen een dergelijk gedistribueerd rekensysteem verloopt de communicatie op verschillende niveaus, elk met hun eigen karakteristieke prestatiekenmerken. Draden die op dezelfde kern worden uitgevoerd, kunnen communiceren via gedeeld geheugen in een cache of in een extern geheugen dat enkel via het netwerk bereikt kan worden. Draden die op verschillende kernen uitgevoerd worden, kunnen enkel informatie uitwisselen via een relatief trage netwerkverbinding. De verhouding tussen interne en externe communicatie heeft een fundamentele impact op de uiteindelijke prestaties wanneer een programma wordt opgesplitst over de verschillende rekenkernen in het systeem. Een geschikte verdeling van zowel de berekeningen als de data over de verschillende rekenkernen, is dan ook uitermate belangrijk om tot een efficiënt resultaat te komen. Communicatie optimaliseren begint met communicatie opmeten. Om een goed beeld te krijgen van hoeveel communicatie er nodig is, heb ik een profileerder ontwikkeld die communicatieprofielen opmeet van Java-programma's. Daarin wordt de informatie over datastromen in het programma gecombineerd met de dynamische oproepgraaf van het programma. Hierbij wordt een onderscheid gemaakt tussen twee types communicatieprofielen: een eerste dat enkel de inherente communicatie bevat tussen methodes in het programma zonder rekening te houden met de datastructuren die daarvoor gebruikt worden en een tweede profiel dat expliciet de communicatie opmeet tussen methodes en datastructuren. Beide profielen hebben hun eigen specifieke toepassingen. Het eerste communicatieprofiel kan door de ontwerper gebruikt worden als aanzet voor de partitionering van functionaliteit van programma's over meerdere rekenkernen of parallelle draden. De communicatie in een systeem is immers onafhankelijk van de specifieke implementatie en de inherente communicatie opgemeten in de geprofileerde, initiële implementatie, is dan ook een goede maat voor de communicatie in de uiteindelijke implementatie op een gedistribueerd rekensysteem. Het tweede communicatieprofiel meet de communicatie van en naar datastructuren in Java. Het levert een goed beeld op van het gebruik van Java-objecten doorheen het programma en geeft dus meer informatie over concrete optimalisaties van de datalayout. Dit profiel vormt de basis voor mijn zelflerende algoritme om de plaatsing van objecten te optimaliseren. Profileren brengt onvermijdelijk een vertraging met zich mee. Zeker voor het opmeten van het eerste type communicatieprofiel is de toename van de uitvoeringstijd enorm omdat er een grote boekhouding moet worden bijgehouden van alle lees- en schrijfoperaties en van een schaduwobject voor elk object in het geheugen. De profilering kan fors versneld worden door gebruik te maken van bemonstering, maar dat kan dan weer nadelig zijn voor de kwaliteit van het opgemeten communicatieprofiel. In dit proefschrift gebruik ik met succes een bemonsteringstechniek uit de oude doos, reservoir sampling}, om de overlast van het profileren te reduceren met een factor 9, met behoud van een aanvaardbare, en vooraf statistisch vastgelegde, nauwkeurigheid. Dit resultaat werd gevalideerd aan de hand van een hele reeks benchmarkprogramma's uit de SPECjvm benchmark suite. De communicatieprofielen vormen de basis voor een communicatiebewuste partitionering van de functionaliteit van programma's waarbij de verhouding tussen interne en externe communicatie als eerste criterium wordt gebruikt. Hierbij focus ik op een specifieke vorm van partitionering, met name het identificeren van delen van de functionaliteit van een systeem die geschikt zijn om ze af te zonderen van de kern van het systeem. Dit wordt uitgewerkt in het kader van de hardwareversnelde JVM waarbij een klassieke processor de initiële, hoofdpartitie, voor zijn rekening neemt en één of meerdere hardwareversnellers op een FPGA als co-processor de afgezonderde partities voor hun rekening nemen. Faes et al toonden immers aan dat een dergelijke aanpak voor de samenwerking tussen hardware en software interessante resultaten oplevert in de context van Java en de hardwareversnelde JVM. Ik heb twee methodes uitgewerkt om programma's functioneel te partitioneren op basis van de opgemeten communicatieprofielen: statische partitionering en dynamische partitionering. Beide types hebben hun duidelijke voor- en nadelen en hun specifieke toepassingen. Statische partitionering is bedoeld als ondersteuning voor een ontwerper die met de hand een programma partitioneert. In de oproepgraaf selecteert men een aantal methodes die geschikt zijn voor hardwareversnelling, bijvoorbeeld omdat ze veel intern parallellisme bevatten, en een aantal methodes die absoluut niet op de hardware uitgevoerd mogen worden, bijvoorbeeld omdat ze complexe controlestructuren bevatten. De statische partitionering gaat dan incrementeel op zoek naar een communicatiebewuste partitionering die een geschikte grens tussen hardware en software vastlegt. Typisch worden dan niet enkel de aangeduide methodes overgeheveld naar de co-processor, maar worden ook enkele omliggende methodes mee verplaatst. Wanneer die omliggende methodes zeer veel data uitwisselen met de hardwareversnelde methodes, is het immers beter dat die communicatie volledig op de co-processor kan gebeuren. Dynamische partitionering is een uitbreiding van het statische algoritme voor gebruik in de hardwareversnelde JVM. De JIT-compilatie in deze JVM opent immers perspectieven om hardwareversnelling te beschouwen als een bijkomende stap in het compilatieproces. Dit heeft een aantal voordelen. Zo is in een aantal toepassingen en voor een aantal methodes de verhouding tussen berekeningen en communicatie invoerafhankelijk. Een dynamische aanpak kan hier adequaat op reageren en in de ene uitvoering een concrete methode wel en in de andere uitvoering niet afleiden naar de co-processor op de FPGA. Transparant hardware/software co-ontwerp. De hardwareversnelde JVM maakt het mogelijk om op een transparante manier aan hardware/software co-ontwerp te doen op een gemengd platform met een generieke processor en hardwareversnellers op FPGA als co-processor. Om de prestaties te verbeteren beschikken zowel de hoofdprocessor als de hardwareversneller over hun eigen lokale geheugen. Beide fysieke geheugens zijn verenigd in het gedeelde-geheugenmodel van de JVM. Deze transparante hardwareversnelde JVM beheert de toegang tot alle objecten in het geheugen, ongeacht hun fysieke locatie. De hardwareversneller is meestal via een relatief traag communicatiemedium verbonden met de hoofdprocessor en het hoofdgeheugen. Daarom worden geheugentoegangen naar 'het andere geheugen' erg duur. Die moeten dus zo veel mogelijk vermeden worden. Een belangrijke taak van de JVM is het zoeken van de meest geschikte geheugenlocatie van elk object in de gedistribueerde Java heap. De objecten zitten best in het geheugen dat het dichtst staat bij de processor (of versneller) die de data het vaakst gebruikt. Gegevens die enkel binnen een draad gebruikt worden, zullen zich dan steeds in het lokale geheugen bevinden met een minimalisatie van de externe communicatie tot gevolg. Voor data die gedeeld wordt tussen uitvoeringsdraden wordt gestreefd naar een communicatiebewuste geheugenallocatie. Ik heb verschillende technieken voorgesteld om communicatiebewust geheugen toe te wijzen. Dynamisch bepaalt de JVM voor elk Java-object, de optimale geheugenlocatie. Mijn zelflerende aanpak probeert de gebruikspatronen voor elk object te schatten op basis van gemeten patronen voor objecten die eerder werden toegewezen. Op basis hiervan kan het object geplaatst worden in het meest geschikte geheugen. Mijn strategieën voor het plaatsen van data in de geheugens leiden tot een vermindering van de hoeveelheid externe geheugentoegangen tot 86% (49% gemiddeld) voor de SPECjvm en DaCapo benchmarks