sciencetalk

Mocht je toch willen proberen om C++ te gebruiken, dan heb je misschien iets aan deze links:

http://www.codeproject.com/Articles/228 ... -Using-JNI

http://en.wikipedia.org/wiki/Java_Native_Interface

Math-E-Mad-X schreef: ↑do 13 dec 2012, 15:21Ik heb het voor de zekerheid nog eens na gezocht, maar ook deze bron:

http://www.oracle.co...g-6-140523.html

bevestigd dat de verscheidene garbage collectors van sun wel degelijk allemaal gebruik maken van mark & sweep, en dus niet van reference counting.

Verhip, je hebt gelijk. I stand corrected. Toen ik leerde programmeren in Java (lang lang geleden) was het nog: "geen cyclische referenties want reference counting", dacht ik. Blijkbaar is dat in latere versies van Sun/Oracle opgelost: http://stackoverflow...erences-in-java

Edit: na even zoeken blijkt dit niet te kloppen, Java heeft altijd met cyclische referenties overweg gekunnen blijkbaar...

Landro schreef: ↑vr 14 dec 2012, 14:41Mocht je toch willen proberen om C++ te gebruiken, dan heb je misschien iets aan deze links:http://www.codeproje...rom-C-Using-JNI,http://en.wikipedia....ative_Interface

JNI zou ik afraden, het is niet eenvoudig, is vrij traag en eigenlijk is Java tegenwoordig niet bijzonder veel trager dan gemiddelde C++ code. De paar procenten gaan het niet maken. http://en.wikipedia....ative_Interface

Java zou moeten snel genoeg zijn. Ik weet dat het ooit anders was, maar de recentste JVM's slagen er al in om C++-applicaties te overklassen in sommige competities. Dit niet omdat er geen snellere C++-code mogelijk is, maar omdat men er niet in slaagt die C++-code te schrijven,

Ik heb een beetje zitten spelen met de jvmmonitor, maar ik word er niet echt veel wijzer van.

De functies waarvan al verwachtte dat ze het meeste tijd zouden vergen deden dat inderdaad ook, dus daar heb ik niet zoveel van geleerd.

Bovendien, wat ik daadwerkelijk zou willen weten is niet waarom bepaalde functies langzaam zijn, maar waarom ze steeds langzamer worden. Ik zie zo gauw niet hoe ik dat kan bepalen.

Zoals je kunt zien in dit plaatje gaat mijn algoritme inderdaad steeds meer Garbage Collection time vergen, naarmate de tijd verstrijkt. Alhoewel ik niet helemaal zeker weet hoe ik de schaal moet interpreteren.
Hier nogmaals een screenshot, ditmaal heb ik de schaalverdeling van de y-as van de Garbage Collection Time grafiek op "percentage" gezet. Zoals te zien schiet hij in één keer naar 100%.

Betekent dit dat vrijwel all tijd aan Garbage Collection besteed wordt? In dat geval zou mijn hypothese kloppen.

Die ene piek van 100% GC time zou geen probleem mogen zijn. Die milliseconde zal je wel niet merken. Het is enkel problematisch als de GC vaak en lang actief zou zijn, maar dat blijkt dus niet zo te zijn.

Volgens mij ligt het echt gewoon aan het geheugen gebruik. Is de heap nu zo groot mogelijk ingesteld?

Zoals 317070 al zei ga je als je veel geheugen gebruikt sowieso vertragingen krijgen.

Hebben je nodes geen ID ofzo? Dan kan je misschien het gevolgde pad tot een node bijhouden in de node zelf ipv de hele boom in het geheugen te houden.

Xenion schreef: ↑wo 19 dec 2012, 15:32
Die ene piek van 100% GC time zou geen probleem mogen zijn. Die milliseconde zal je wel niet merken. Het is enkel problematisch als de GC vaak en lang actief zou zijn, maar dat blijkt dus niet zo te zijn.

Het is mij dus niet duidelijk hoe ik die piek moet interpreteren, want zo te zien is het niet geen piek, maar een plotselinge stap naar 100% die niet meer omlaag gaat. Ik snap sowieso niet wat het percentage betekent.

Als hij op tijdstip x 100% aangeeft, betekent dat dan dat hij in totaal tussen tijdstippen 0 en x 100% van zijn tijd aan de GC heeft besteed? Of betekent het dat hij op tijdstip x 100% van de tijd aan GC besteedt?

Xenion schreef: ↑wo 19 dec 2012, 15:32
Volgens mij ligt het echt gewoon aan het geheugen gebruik. Is de heap nu zo groot mogelijk ingesteld?

Zoals 317070 al zei ga je als je veel geheugen gebruikt sowieso vertragingen krijgen.

Heb mijn heap op 2GB gezet. Mijn computer heeft 8GB aan geheugen.

Zijn er, behalve het vergroten van de heap nog andere methoden om te voorkomen dat je vertragingen krijgt? (en afgezien van het optimaliseren van je algoritme, want in mijn geval heb ik nou eenmaal sowieso veel geheugen nodig)

Xenion schreef: ↑wo 19 dec 2012, 15:32
Hebben je nodes geen ID ofzo? Dan kan je misschien het gevolgde pad tot een node bijhouden in de node zelf ipv de hele boom in het geheugen te houden.

Nee, ik heb echt de hele boom nodig. Het is een soort A* -achtig algoritme. Het gaat me een beetje ver om mijn algoritme helemaal uit te gaan leggen hier, maar mochten mensen het interessant vinden, dan kun je op mijn website een paar artikelen hierover vinden:

http://www.iiia.csic.es/~davedejonge

onder published articles.

Wanneer wordt je programma eigenlijk merkbaar trager, wanneer de heap vol zit? En krijg je geen out of memory exceptions ofzo?

Ook: run je het programma via de debugger of in 'release mode'? Ik denk niet dat het in Java zo heet, maar je begrijpt waarschijnlijk wel wat ik bedoel. Je moet zeker eens zonder debugger proberen.

Weet je waar die plotselinge sprong in de grafieken op 14:54:00 vandaan komt? Wat je bij zoekalgorithmen ziet, is dat het geheugen langzaam vol loopt, omdat je nu eenmaal voortdurend dezelfde code uitvoert. In A* algorithmen zit er vaak een soort van update stap, die ervoor zorgt dat de afstand tot de beginstand wordt bijgewerkt: is dit misschien het moment waarop dingen uit de hand lopen?

Heb mijn heap op 2GB gezet.

Volgens je screenshots gebruikt je programma 1800MB aan geheugen: dan gaat je GC inderdaad veel tijd innemen. Hij heeft dan minder dan 10% om mee te spelen, dat is veel te weinig...

Vergelijk het met een gewone RAM. Als je 95% van je RAM gebruikt, gaat je computer ook erg vertragen...

Hier nogmaals een screenshot, ditmaal heb ik de schaalverdeling van de y-as van de Garbage Collection Time grafiek op "percentage" gezet. Zoals te zien schiet hij in één keer naar 100%.

Is het niet eerder dat gewoon eventjes veel tijd aan GC besteed wordt en dat hij dan weer naar 0 gaat? Hoe kan hij 1,6GB aan data creëren als je programma alleen GC doet?

Hoi allemaal, hartstikke bedankt voor jullie hulp, ik heb her en der de code wat efficienter gemaakt wat betreft geheugen gebruik en dat heeft een hele hoop geholpen. Ik zie nu geen duidelijke vertraging meer.

Toch zou ik graag nog wel iets meer willen weten over de manier waarop java met geheugen omgaat. Ik heb zoals hierboven aangegeven wel gezocht op 'virtueel geheugen' en 'paging', maar kom eigenlijk alleen maar hele vage high-level beschrijvingen tegen.

Heeft iemand een goede link waar uitgelegd wordt wanneer java bijvoorbeeld van de harde schijf gebruikt maakt om objecten op te slaan? En hoe je dit kunt voorkomen?