Deutsches R-Forum

EDi hat geschrieben: ↑Mi Nov 07, 2018 4:06 pmEin Stunde amazon aws mit 72 Kernen und 140GB RAM kosten irgendwas um die 3 €.

Stimmt natürlich, dass Maschinenpower grundsätzlich billiger ist als Menschen. Und Denken tut bekanntlich weh. Die Rechnung geht so aber nur dann auf, wenn sich das Problem entsprechend auf 72 Kerne parallelisieren lässt. Das ist in nicht trivialen Fällen auch eher was für Programmierer mit schwarzem Gürtel. Zumal hier bestimmt einiges parallelisierbar ist, wenn ich es recht verstehe, vieles aber auch sequentiell als f(t+1) = g(f(t)).
Ich bleibe unschlüssig, was die optimale Herangehensweise ist.

LG,
Bernhard

Und Denken tut bekanntlich weh

Deswegen versuche ich das in der Regel zu vermeiden und wende diese Technik nur in äußersten Notfällen an

Ich glaube ja auch das eine Optimierung auf R level viel bringt. Ich find gerade den blog nicht der sehr elegant über Klassen IBMs in R implementiert hat...

R ist nicht lahm, es ist aber leider sehr einfach lahm zu programmieren
Vorallem das vektorisieren bringt sehr sehr viel, wird aber oft als schwerer empfunden als eine for-Schleife.
Dann kommen noch die Flaschenhälse in R hinzu, wie vorinitialisierung statt appending [stimmt das noch?] und das interne kopieren beim überschreiben [stimmt das noch?]

Ich kann auch in Julia langsamen Code schreiben und muss ich mich da mehr anstrengen

EDi hat geschrieben: ↑Mi Nov 07, 2018 8:11 pm Ich kann auch in Julia langsamen Code schreiben und muss ich mich da mehr anstrengen

Ja, genau das ist der Kern meiner Frage. In der Regel ist alles Gefasel über langsames R Quatsch, man muss aber trotzdem den Geist aufnahmebereit halten um den Moment nicht zu verpassen, wo es mal stimmt.
Wenn ich mal in so eine Situation käme würde ich ungern auf C++ zurückfallen, sondern würde gern auf ähnlich hohem Abstraktionsniveau weiterprogrammieren wie in R. Für die Auswertung der Simulation könnte man ja wieder auf R zurück greifen.

JMTC,
Bernhard

Ok Leute, ich habe mein Bestes getan, um die Struktur meines Codes zu verbessern. Aber alles in Allem löst das natürlich leider nicht mein Problem. Leider habe ich als Autodidakt nie gelernt, effizient zu programmieren (und brauchte es bislang auch nicht - dann habe ich halt ein paar Sekunden länger gewartet).

Aber gerade aus dem Grund, brauche ich nach wie vor Unterstützung. Ich biete Demjenigen, der mir hilft meinen Code so umzugestalten, daß dieser effizient, d. h. schnell läuft, eine Aufwandsentschädigung von 300 €.

Anm.: Da ich für die Finanzierung meiner Diss nebenher arbeiten muß, bin ich leider noch nicht dazu gekommen meinen Code fertig zu schreiben. Es fehlt also nach wie vor noch die Verpartnerung und die Nachkommens-Produktion der Agenten sowie final die Berechnung der Differenzen der simulierten und realen Ancestry-Schätzer.

Hallo Anti,

Anti hat geschrieben: ↑Do Nov 08, 2018 4:30 pm Ok Leute, ich habe mein Bestes getan, um die Struktur meines Codes zu verbessern. ... Leider habe ich als Autodidakt nie gelernt, effizient zu programmieren (und brauchte es bislang auch nicht - dann habe ich halt ein paar Sekunden länger gewartet).

dies gelesen habend dachte ich, Du würdest hier jetzt eine überarbeitet Version Deines Quelltextes präsentieren. Zum Beispiel indem Du statt der Spaltennummern die Spaltennamen schreibst. Gerade das Setzen der Spaltennummern anstelle der Namen macht man gelegentlich aus Effizienzgründen (wenn man meint, man spart viel Zeit, weil der Interpreter die Spaltennamen nicht in die passende Spaltennummer übersetzen muss) - leider geht dabei die Lesbarkeit verloren (und damit die zukünftige Möglichkeit für eine effiziente Bearbeitung des Codes). Zum zweiten dürfte die zusätzliche Zeit beim Interpreter bei dieser Datenmenge kaum den Ausschlag geben - soll heißen: die Verarbeitung der Daten macht bei weitem den größeren Arbeitsaufwand.
Ein erster Ansatz für das Verwenden der Spaltennamen könnte sein: So hat man jetzt eine bessere Übersicht über die Zugehörigkeiten von Spaltennamen und -nummern. Die Spaltennamen habe ich so verändert, dass man keine Probleme bei deren Verwendung bekommt.

Anm.: ..., bin ich leider noch nicht dazu gekommen meinen Code fertig zu schreiben. Es fehlt also nach wie vor noch die Verpartnerung und die Nachkommens-Produktion der Agenten sowie final die Berechnung der Differenzen der simulierten und realen Ancestry-Schätzer.

Ich möchte dringend empfehlen, dass zuerst die Lesbarkeit des Codes erhöht wird, bevor er in dem jetzigen Stil erweitert wird.

Gruß, Jörg

Hmm, ich dachte, ich hätte meinen Code bereits angefügt. Danke für den Hinweis. Hier ist er jetzt ...

Das sieht schon viel besser aus
Hier eine erste kleine Anregung: statt for (j in 1:length(migratables)) { besser in der Schleife wird dann aus jedem ...[migratables[j]] einfach ein ...[Mig]

Gruß, Jörg
p.s.:
Nachdem ich beim von-vorne-nach-hinten-Umstrukturieren stecken geblieben bin, sind jetzt die Inneren Schleifen dran.

jogo hat geschrieben: ↑Fr Nov 09, 2018 11:11 am Das sieht schon viel besser aus
Hier eine erste kleine Anregung: statt for (j in 1:length(migratables)) { besser

Code: Alles auswählen

for (Mig in migratables) { ...

in der Schleife wird dann aus jedem ...[migratables[j]] einfach ein ...[Mig]

Mille grazie! Werd ich beherzigen!

Wenn new.deme nicht im nächsten Schleifendurchlauf gebraucht wird, kannst Du wie folgt ändern: zu Auch kannst Du die Lesbarkeit weiter erhöhen, indem Du nicht in numerische Werte konvertierst: sondern einfach: das sind dann logical ... natürlich müssen dann auch die folgenden Vergleiche angepasst werden.

Gruß, Jörg

@Jörg,

nochmals vielen Dank vorweg! Ich werde Deine tollen Vorschläge heute Abend umsetzen und mich dann am WE an den restlichen Code machen. Dann melde ich mich wieder mit dem vollständigen Code.

Besten Dank nochmals
Anti