Memory leaks in training

[lenerd]

Die backpropagation Funktion leakt Speicher. Es werden zum Beispiel immer neue Netze erstellt, die alten aber nicht wieder freigegeben. Mir ist gerade beim Testen der Speicher vollgelaufen ...

[TheEimer]

Hast du die Version auf Master oder auf Training probiert? Jedenfalls stimmen die Indizes teilweise nicht, das weiß ich auch, das muss ich nochmal überarbeiten.

[Incand]

Kurzes update, was ich gerade so mache: Da wir uns jetzt für die deutlich sinnvollere backpropagation als lern-algorithmus entschieden haben, mache ich gerade ein neues Modul mit dem Namen newneuralnet (subject to change). Hier pack ich gerade fein säuberlich alles rein, was wir bisher haben und nutzen können. Genetic_algorithm brauchen wir ja vom Ding her gar nicht mehr und können die Methode für backpropagation ja auch in das Modul des neuronalen Netzes schreiben. Guckt euch mal den branch "armins_branch" an. Ich würde gerade Lennart darum bitten cmake Anweisungen zu updaten, die eventuell nötig sind dank dem neuen header util.h und der Verschiebung von math_ext.h sowie .c Sonst sieht es bisher sehr gut aus, der code ist wunderbar leserlich, die Dokumentation mache ich auf jeden Fall noch. On Jul 6, 2015 17:21, TedAndTheBear notifications@github.com wrote:Hast du die Version auf Master oder auf Training probiert? Jedenfalls stimmen die Indizes teilweise nicht, das weiß ich auch, das muss ich nochmal überarbeiten.

—Reply to this email directly or view it on GitHub.

[TheEimer]

Ich dachte wir machen beides? Oder hab ich da was falsch verstanden? Mit backpropagation allein bringen wir die Netze zumindest schlecht zum Spielen...

[Incand]

Achso... Ja, das stimmt natürlich. Da hab ich wohl was falsch verstanden. Aber das sollte auch kein Problem sein. On Jul 6, 2015 18:06, TedAndTheBear notifications@github.com wrote:Ich dachte wir machen beides? Oder hab ich da was falsch verstanden? Mit backpropagation allein bringen wir die Netze zumindest schlecht zum Spielen...

—Reply to this email directly or view it on GitHub.

[lenerd]

Hast du die Version auf Master oder auf Training probiert? Jedenfalls stimmen die Indizes teilweise nicht, das weiß ich auch, das muss ich nochmal überarbeiten.

War auf go-scores und dort auf dem selben Stand, wie master, was das training Modul betrifft. Indizes waren auch nicht das direkte Problem. In training.c:119 (branch training) wird in jeder Iteration der Schleife ein neues neuralnet_t erstellt. Die Buffer des vorherigen werden jedoch nie freigegeben. So wie ich das sehe, ist das erneute erstellen eines Netzes auch unnötig, da sowieso nur die alte Konfiguration wieder übergeben wird (edges zeigt auf den edge_buf). Weiterhin wird in jeder Iteration der Schleife Speicher für delta und edge_errors allokiert und nicht wieder freigegeben. Zu jedem [cm]alloc sollte es ein passendes free geben. Da es dazu einen Test gibt und ich einfach alle über ctest gestartet habe, sind meine 8 GiB RAM innerhalb kurzer Zeit vollgelaufen und das System hat angefangen zu swappen. War nicht sehr schön.

[lenerd]

Ich würde gerade Lennart darum bitten cmake Anweisungen zu updaten, die eventuell nötig sind dank dem neuen header util.h und der Verschiebung von math_ext.h sowie .c

Es müssten nur die Variable PROJECT_SOURCES in der src/CMakeLists.txt entsprechen angepasst werden.

[Incand]

Okay, das kann ich auch selbst tun. On Jul 7, 2015 00:22, Lennart Braun notifications@github.com wrote: Ich würde gerade Lennart darum bitten cmake Anweisungen zu updaten, die eventuell nötig sind dank dem neuen header util.h und der Verschiebung von math_ext.h sowie .c

Es müssten nur die Variable PROJECT_SOURCES in der src/CMakeLists.txt entsprechen angepasst werden.

—Reply to this email directly or view it on GitHub.

[lenerd]

mache ich gerade ein neues Modul mit dem Namen newneuralnet (subject to change). Hier pack ich gerade fein säuberlich alles rein, was wir bisher haben und nutzen können. ... Sonst sieht es bisher sehr gut aus, der code ist wunderbar leserlich, die Dokumentation mache ich auf jeden Fall noch

Habe den Code mal kurz überflogen: Es ist grundsätzlich keine schlechte Idee, Code in kleinere Funktionen aufzuteilen. Aber werden z.B. die initialize_*_weights_random irgendwann mal unabhängig voneinander verwendet? Außerdem werden überall mal kleine, unzusammenhängende Buffer allokiert. Dabei kann leicht mal das freigeben vergessen werden und es sind das eine Menge an Syscalls. Das einfache Kopieren von Netzen und das Verwenden als Genom ist in der Form nicht mehr möglich.

Die buffer Deklarationen finde ich sehr ungewöhnlich/verwirrend.

float* input_weights[][];
float* hidden_layer_weights[][][];
float* output_weights[][];

Wozu das Allokieren von einelementigen Buffern?

Was das SAFE_[CM]ALLOC Macro angeht: Es wird da immer nur geprüft, ob net != NULL ist.

Abschließend für heute: Kompiliert das?

[Incand]

Ich arbeite gerade noch daran. Viele der Sachen, die du gerade genannt hast hab ich schon gefixt, an anderen arbeite ich noch. Gleich bin ich fertig mit der backpropagation und werde das zum compilen bringen. Eigentlich habe ich immer darauf geachtet, dass ich für jeden alloc auch einen free habe, aber klar, das kann immer Probleme machen. Das mit dem Genom und allem müssten wir dann anpassen, also fast nur copy-pasten eigentlich.. Ich wollte mich erstmal auch backpropagation konzentrieren, sodass wir am Mittwoch zeigen können, wie effektiv unser Netzwerk lernt. Das der Makro stress macht war fast klar. Ich kümmere mich darum. On Jul 7, 2015 00:41, Lennart Braun notifications@github.com wrote: mache ich gerade ein neues Modul mit dem Namen newneuralnet (subject to change). Hier pack ich gerade fein säuberlich alles rein, was wir bisher haben und nutzen können. ... Sonst sieht es bisher sehr gut aus, der code ist wunderbar leserlich, die Dokumentation mache ich auf jeden Fall noch

Habe den Code mal kurz überflogen: Es ist grundsätzlich keine schlechte Idee, Code in kleinere Funktionen aufzuteilen. Aber werden z.B. die initialize_*_weights_random irgendwann mal unabhängig voneinander verwendet? Außerdem werden überall mal kleine, unzusammenhängende Buffer allokiert. Dabei kann leicht mal das freigeben vergessen werden und es sind das eine Menge an Syscalls. Das einfache Kopieren von Netzen und das Verwenden als Genom ist in der Form nicht mehr möglich.

Die buffer Deklarationen finde ich sehr ungewöhnlich/verwirrend.

float* input_weights[][]; float* hidden_layer_weights[][][]; float* output_weights[][];

Wozu das Allokieren von einelementigen Buffern?

Was das SAFE_[CM]ALLOC Macro angeht: Es wird da immer nur geprüft, ob net != NULL ist.

Abschließend für heute: Kompiliert das?

—Reply to this email directly or view it on GitHub.

[lenerd]

Zum eigentlichen Thema dieses Issues: Habe (auf dem master) fürs erste den training Test aus dem Build genommen (In der CMakeLists.txt auskommentiert.).

[Incand]

newneunet.c kompiliert, aber es gibt seg faults und memory leaks. Ich bin mit gdb und valgrind rüber gegangen, aber irgendwie find ich nichts. Ich guck mir das jetzt nochmal an, aber vielleicht findet ihr da auch was. On Jul 7, 2015 22:04, Lennart Braun notifications@github.com wrote:Zum eigentlichen Thema dieses Issues: Habe (auf dem master) fürs erste den training Test aus dem Build genommen (In der CMakeLists.txt auskommentiert.).

—Reply to this email directly or view it on GitHub.

[TheEimer]

Hi!

Also was bei mir Probleme macht ist calculate_output_new, da gibt es einen Segfault, weil input from von komischen Adressen ausgelesen werden soll (0x1 zum Beispiel...). Warum genau ist mir allerdings auch nicht klar. Er tritt gleich bei der ersten Benutzung auf, vorher wird nur allokiert:

float* calculate_output_new(const neuralnet_t* net, const float* input){

...

for(uint32_t to = 0; to < net->neurons_per_hidden_layer; ++to){ current_result_2[to] = 0.0f; for(uint32_t from = 0; from < net->input_count; ++from){ current_result_2[to] += input[from] * net->input_weights[to][from]; }

...

Dadurch wird einfach immer 0 als Output ausgegeben, relativ unpraktisch.

Außerdem ist in Zeile 219 das memcpy nicht in Ordnung, valgrind sagt invalid read of size 2, allerdings versteh ich den Code nicht gut genug um da was zu machen. Im Prinzip ist es wohl ähnlich wie oben, dass es Probleme mit dem Input gibt oder aber die allokation des full_outputs klappt nicht, hast du das mal getestet?

Ich hab jedenfalls angefangen eine Testdatei für newneunet zu schreiben, wie sie eben auch für den Rest existiert. Ich pushe die auch gleich, nur zum gründlichen Testen hab ich im Moment noch zu wenig Überblick, ich muss mich den Code noch ein bisschen genauer anschauen.

Bis später!

LG Theresa

Am 08.07.2015 um 01:05 schrieb Armin Schaare:

newneunet.c kompiliert, aber es gibt seg faults und memory leaks. Ich bin mit gdb und valgrind rüber gegangen, aber irgendwie find ich nichts. Ich guck mir das jetzt nochmal an, aber vielleicht findet ihr da auch was. On Jul 7, 2015 22:04, Lennart Braun notifications@github.com wrote:Zum eigentlichen Thema dieses Issues: Habe (auf dem master) fürs erste den training Test aus dem Build genommen (In der CMakeLists.txt auskommentiert.).

—Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/lenerd/papo-project/issues/1#issuecomment-119370063.

[Incand]

Öh shit. Ich hab die Uhrzeit verpeilt und werde zu spät kommen. Versucht mal, dass wir erst am Ende vorstellen. On Jul 8, 2015 14:16, TedAndTheBear notifications@github.com wrote:Hi!

Also was bei mir Probleme macht ist calculate_output_new, da gibt es einen Segfault, weil input from von komischen Adressen ausgelesen werden soll (0x1 zum Beispiel...). Warum genau ist mir allerdings auch nicht klar. Er tritt gleich bei der ersten Benutzung auf, vorher wird nur allokiert:

float* calculate_output_new(const neuralnet_t* net, const float* input){

...

for(uint32_t to = 0; to < net->neurons_per_hidden_layer; ++to){ current_result_2[to] = 0.0f; for(uint32_t from = 0; from < net->input_count; ++from){ current_result_2[to] += input[from] * net->input_weights[to][from]; }

...

Dadurch wird einfach immer 0 als Output ausgegeben, relativ unpraktisch.

Außerdem ist in Zeile 219 das memcpy nicht in Ordnung, valgrind sagt invalid read of size 2, allerdings versteh ich den Code nicht gut genug um da was zu machen. Im Prinzip ist es wohl ähnlich wie oben, dass es Probleme mit dem Input gibt oder aber die allokation des full_outputs klappt nicht, hast du das mal getestet?

Ich hab jedenfalls angefangen eine Testdatei für newneunet zu schreiben, wie sie eben auch für den Rest existiert. Ich pushe die auch gleich, nur zum gründlichen Testen hab ich im Moment noch zu wenig Überblick, ich muss mich den Code noch ein bisschen genauer anschauen.

Bis später!

LG Theresa

Am 08.07.2015 um 01:05 schrieb Armin Schaare:

newneunet.c kompiliert, aber es gibt seg faults und memory leaks. Ich bin mit gdb und valgrind rüber gegangen, aber irgendwie find ich nichts. Ich guck mir das jetzt nochmal an, aber vielleicht findet ihr da auch was. On Jul 7, 2015 22:04, Lennart Braun notifications@github.com wrote:Zum eigentlichen Thema dieses Issues: Habe (auf dem master) fürs erste den training Test aus dem Build genommen (In der CMakeLists.txt auskommentiert.).

—Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/lenerd/papo-project/issues/1#issuecomment-119370063.

—Reply to this email directly or view it on GitHub.

[Incand]

Ey shit. Die Bahn fährt nicht. Ich war an der Station und die S-Bahn steht da schon seid 45 Minuten. Weil ich gerade in veddel bin, komm ich hier anderweitig nicht gut weg. Macht die Präsentation ohne mich. Nochmal zu den Fehlern. Die memory leaks hab ich beseitigt und viele der uninitialized variable Fehler von valgrind liegen daran, dass die swap_buffer Funktionen aus util.c nicht funktionieren. Komischer weise klappt es, wenn ich den Körper der Funktion einfach an die stelle in newneunet.c schreibe. Keine Ahnung, was da los ist. Tut mir auf jeden Fall nochmal leid, dass ich das hier verplant gäbe und jetzt nicht mehr kommen kann. Ich mach das wieder gut. On Jul 8, 2015 14:16, TedAndTheBear notifications@github.com wrote:Hi!

Also was bei mir Probleme macht ist calculate_output_new, da gibt es einen Segfault, weil input from von komischen Adressen ausgelesen werden soll (0x1 zum Beispiel...). Warum genau ist mir allerdings auch nicht klar. Er tritt gleich bei der ersten Benutzung auf, vorher wird nur allokiert:

float* calculate_output_new(const neuralnet_t* net, const float* input){

...

for(uint32_t to = 0; to < net->neurons_per_hidden_layer; ++to){ current_result_2[to] = 0.0f; for(uint32_t from = 0; from < net->input_count; ++from){ current_result_2[to] += input[from] * net->input_weights[to][from]; }

...

Dadurch wird einfach immer 0 als Output ausgegeben, relativ unpraktisch.

Außerdem ist in Zeile 219 das memcpy nicht in Ordnung, valgrind sagt invalid read of size 2, allerdings versteh ich den Code nicht gut genug um da was zu machen. Im Prinzip ist es wohl ähnlich wie oben, dass es Probleme mit dem Input gibt oder aber die allokation des full_outputs klappt nicht, hast du das mal getestet?

Ich hab jedenfalls angefangen eine Testdatei für newneunet zu schreiben, wie sie eben auch für den Rest existiert. Ich pushe die auch gleich, nur zum gründlichen Testen hab ich im Moment noch zu wenig Überblick, ich muss mich den Code noch ein bisschen genauer anschauen.

Bis später!

LG Theresa

Am 08.07.2015 um 01:05 schrieb Armin Schaare:

newneunet.c kompiliert, aber es gibt seg faults und memory leaks. Ich bin mit gdb und valgrind rüber gegangen, aber irgendwie find ich nichts. Ich guck mir das jetzt nochmal an, aber vielleicht findet ihr da auch was. On Jul 7, 2015 22:04, Lennart Braun notifications@github.com wrote:Zum eigentlichen Thema dieses Issues: Habe (auf dem master) fürs erste den training Test aus dem Build genommen (In der CMakeLists.txt auskommentiert.).

—Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/lenerd/papo-project/issues/1#issuecomment-119370063.

—Reply to this email directly or view it on GitHub.