performantie verbeteren

[dodona-edu]

performantie verbeteren

[niknetniko]

Nieuwe tijdsmetingen met de ideeën van hierboven. De tabellen tonen eerst de lotto-oefening (zelfde als hierboven, eerste twee metingen zijn dan ook die van hierboven). Daarna volgt een echo-oefening, waarbij geen custom evaluator gebruikt wordt (deze is enkel in de huidige implementatie getest). Beschrijvingen van de modi staan onder de tabellen. In het vet de uiteindelijke uitvoeringstijden, zoals ze gebruikt worden door de judge in Dodona.

Java

		1 thread	4 threads
LOTTO	volledig	48s	36s
	partieel	46s	25s
	verbeterd	14s	10s
ECHO	verbeterd	8s	5s

Python

		1 thread	4 threads
LOTTO	volledig	13s	9s
	partieel	9s	6s
	verbeterd	8s	6s
ECHO	verbeterd	5s	3s

Beschrijving

• Volledig: elke context afzonderlijk gecompileerd en uitgevoerd.
• Partieel: gemeenschappelijke code een keer gecompileerd,
  elke context afzonderlijk gecompileerd en uitgevoerd.
• Verbeterd: alle code een keer gecompileerd, elke context
  afzonderlijk uitgevoerd.

Bij de verbeterde modus is het idee om custom evaluatoren in Python met exec uit te voeren nog niet geïmplementeerd. Dit idee kan het verschil tussen de lotto- en echo-oefening misschien een beetje kleiner maken.

[niknetniko]

Volgende zaken zijn geïmplementeerd:

• Parallelle uitvoering van de contexten
• Mogelijkheid tot compilatie van gemeenschappelijke code

Voor de momenteel geïmplementeerde talen is het als volgt geïmplementeerd:

• Python
  • Submission & serialisatie worden op voorhand gecompileerd naar pyc-bestanden, die dan naar de contextmap gekopieerd worden
  • Per context wordt de code gewoon uitgevoerd, met het idee dat het hier niet nuttig is om eerst te compileren.
• Java
  • Submisson & serialisatie worden op voorhand gecompileerd naar class-bestanden, die naar de contextmap gekopieerd worden
  • Per context wordt de rest van de code gecompileerd en dan uitgevoerd
• Haskell
  • Submission & serialisatie worden op voorhand gecompileerd, maar het resultaat wordt nog niet herbruikt
  • Per context wordt de code uitgevoerd met runhaskell. Op termijn is het misschien een idee om aan de hand van bv. de maximale uitvoeringstijd voor de oefening over te gaan op compilatie.

[pdawyndt]

@niknetniko hoe groot is de tijdswinst door parallellisatie en recup van compilatie voor Python en Java? grosso modo is OK

[niknetniko]

@pdawyndt Deze tests zijn uitgevoerd met de lotto-oefening.

Legenda
Bij de kolom threads staat V voor volledig en P voor partieel (i.e. zonder en met precompilatie van gemeenschappelijke code)

Python

Threads*	Tijd (s)	Percentage
1V	13	100%
4V	9	69%
1P	9	69%
4P	6	46%

Java

Threads*	Tijd (s)	Percentage
1V	48	100%
4V	36	75%
1P	46	95%
4P	27	56%

Merk op dat ze niet uitgevoerd zijn in Dodona, maar manueel (uitvoeren in Dodona voegt nog wat overhead toe).

[pdawyndt]

@niknetniko de duur van alle testen blijft toch nog behoorlijk lang :-(

ter mijner info: gebruik je bij het testen een custom judge die de uitvoering meerdere keren doet om ook te kunnen testen of alle mogelijkheden gekozen worden, of is dit nog een testplan waarbij de custom judge enkel de correctheid van één enkele uitvoering van elke function call beoordeelt?

omdat de custom judge natuurlijk ook nog een overhead heeft, zou het misschien ook interessant zijn om eens timings te doen van een oefening zonder custom judge, bv. echo want die heeft qua uitvoer van de studentencode natuurlijk weinig overhead

[niknetniko]

de duur van alle testen blijft toch nog behoorlijk lang :-(

Helaas wel 😞

Dit is met een custom judge, maar er wordt wel maar 1 keer uitgevoerd.

Een idee waar ik nu naar kijk is om te proberen geen compilatiestap te moeten doen bij elke context, door alle code voor alle contexten in één bestand te genereren. Dat zou dan 1 keer gecompileerd worden, en "at runtime" zou dan de juiste code geselecteerd worden (concreet door het nummer van de context mee te geven als parameter). Dit zou vooral voor Java nuttig zijn denk ik.

Anderzijds is er waarschijnlijk ook nog mogelijkheid tot optimaliseren bij de custom judges, aangezien ik daar nog niets heb geoptimaliseerd.

Ik zal kijken om eens een tijdsmeeting te doen met een echo-oefening om de impact van de custom judge te zien.

[pdawyndt]

Verschil tussen single en multithreaded uitvoer is niet zo groot. Is dat omdat de "compilatiefase" het grootste deel van de tijd inneemt, en die stap inherent sequentieel is. Misschien de moeite om die twee fasen eens afzonderlijk te timen.

[pdawyndt]

Custom evaluatoren kunenn in principe ook al op voorhand gecompileerd worden, dus één keer per wijziging aan de oefeningen, in plaats van telkens opnieuw per ingediende oplossing.

[niknetniko]

Ik heb toekomstige dingen opgenomen als future work, ik denk niet dat hier nog dingen te doen zijn.