-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
performantie verbeteren #15
Comments
Volgende zaken zijn geïmplementeerd:
Voor de momenteel geïmplementeerde talen is het als volgt geïmplementeerd:
|
@niknetniko hoe groot is de tijdswinst door parallellisatie en recup van compilatie voor Python en Java? grosso modo is OK |
@pdawyndt Deze tests zijn uitgevoerd met de lotto-oefening. Legenda Python
Java
Merk op dat ze niet uitgevoerd zijn in Dodona, maar manueel (uitvoeren in Dodona voegt nog wat overhead toe). |
@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 |
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. |
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
Python
Beschrijving
Bij de verbeterde modus is het idee om custom evaluatoren in Python met |
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. |
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. |
Ik heb toekomstige dingen opgenomen als future work, ik denk niet dat hier nog dingen te doen zijn. |
Enkele ideeën:
The text was updated successfully, but these errors were encountered: