Entgeltliche Optimierung eines Agent-based models

Wie rufe ich R-Funktionen auf, wie selektiere ich Daten, ich weiß nicht genau ....

Moderatoren: EDi, jogo

bigben
Beiträge: 2771
Registriert: Mi Okt 12, 2016 9:09 am

Re: Entgeltliche Optimierung eines Agent-based models

Beitrag von bigben »

Hi!

Ich muss zugeben, ich habe den Strang am Dienstrechner verfolgt und da habe ich kein ZIP-Programm, ich habe den Code von Anti also nicht gesehen. Ohne die Geschichte mit den Demen auf Papua Neuguinnea besser zu verstehen würde ich wahrscheinlich auch mit dem Code nichts anfangen können und mein Abstraktionsvermögen würde nicht reichen, ihn ohne Verständnis zu verbessern.
Weiter oben habe ich geschrieben
bigben hat geschrieben:Steile These, denn die, die ich anspreche, können das auch in R schnell. Aber würde die Schnelligkeit mit einer compilierten Sprache wie C++ oder Julia nicht viel einfacher kommen, viel weniger Hirnschmalz kosten?
Sind wir jetzt da angekommen?

Viele Grüße,
Bernhard
---
Programmiere stets so, dass die Maxime Deines Programmierstils Grundlage allgemeiner Gesetzgebung sein könnte
Benutzeravatar
EDi
Beiträge: 1599
Registriert: Sa Okt 08, 2016 3:39 pm

Re: Entgeltliche Optimierung eines Agent-based models

Beitrag von EDi »

Sind wir jetzt da angekommen?
Hab bisher nur den Strang hier gelesen,keinen Code.
Wenn man in jedem Durchlauf mehrere GB auf die Platte schreibt und liest, wird dir Julia oder C++ auch nicht weiterhelfen, da kommst du an andere Grenzen.

Wenn man riesen Data.frames mitschleppt und verändert kommt man mMn nicht an Data.table rum. Weil base-r unter Umständen bei Veränderung von Objekten das Objekt 2x kopiert .data.table macht das direkt.

Von dem was ich hier lese, wäre ein refactoring (egal in welcher Sprache) vermutlich schneller als eine Optimierung.

@Anti, hast du mal ein Profiling (z.b. rprof) von deinem Code gemacht um zu sehen wo die lahmen Stellen sind?
Bitte immer ein reproduzierbares Minimalbeispiel angeben. Meinungen gehören mir und geben nicht die meines Brötchengebers wieder.

Dieser Beitrag ist lizensiert unter einer CC BY 4.0 Lizenz
Bild.
Anti

Re: Entgeltliche Optimierung eines Agent-based models

Beitrag von Anti »

EDi hat geschrieben: Fr Nov 16, 2018 5:33 pm@Anti, hast du mal ein Profiling (z.b. rprof) von deinem Code gemacht um zu sehen wo die lahmen Stellen sind?
Kannte die Funktion bislang nicht. Werde sie aber mal laufen lassen. Danke für den Tipp!

Zum Schreiben der große Datenmengen auf die Festplatte: Das passiert ja erst am Ende eines Durchlaufs und im Vergleich zu einem Durchlauf ist die benötigte Zeit fürs Schreiben wohl nur ein Fliegenschiss ;) Aber klar, es frißt Zeit. Alternative könnte ich mir auch vorstellen, daß man nach jedem Run den Fit mit dem besten Fit bisher vergleicht und nur dann die Datei schreibt, wenn der aktuelle Lauf der Beste war.
jogo
Beiträge: 2085
Registriert: Fr Okt 07, 2016 8:25 am

Re: Entgeltliche Optimierung eines Agent-based models

Beitrag von jogo »

Hallo Bernhard,
bigben hat geschrieben: Fr Nov 16, 2018 4:46 pm Ich muss zugeben, ich habe den Strang am Dienstrechner verfolgt und da habe ich kein ZIP-Programm, ich habe den Code von Anti also nicht gesehen. Ohne die Geschichte mit den Demen auf Papua Neuguinnea besser zu verstehen würde ich wahrscheinlich auch mit dem Code nichts anfangen können und mein Abstraktionsvermögen würde nicht reichen, ihn ohne Verständnis zu verbessern.
Weiter oben habe ich geschrieben
bigben hat geschrieben:Steile These, denn die, die ich anspreche, können das auch in R schnell. Aber würde die Schnelligkeit mit einer compilierten Sprache wie C++ oder Julia nicht viel einfacher kommen, viel weniger Hirnschmalz kosten?
Sind wir jetzt da angekommen?
nein, das ist ein völlig anderes Thema. Dazu müsstest Du den gleichen Quelltext nehmen (auf einer der Maschinen in den 80-er Jahren hatten wir einen C-Interpreter); aber dann wird die Frage trivial. Natürlich ist compilierter Code schneller als interpretierter. Weiß eigentlich jemand, ob der R-Interpreter einen Puffer verwendet und/oder Zwischencode erzeugt (wie BASIC und PASCAL)?
Anti hat sich bei der Implementierung nicht mal an die Struktur der vorhandenen Java-Lösung gehalten, sondern er hat den R-Quelltext entwickelt auf der Grundlage der Beschreibung des Algorithmus. Ich vermute, er hat wenig Programmiererfahrung insgesamt und zwangsläufig noch weniger Erfahrung in der Programmierung mit R. Man kann auch verschiedenen Programmierparadigmen (die auch alle gut und richtig sind) aufsitzen und diese falsch interpretieren. So kann man sehr schnell echt unterirdischen Code produzieren. Berhard, wir brauchen doch nur mal unsere ersten Quelltexte anschauen (wir können uns dabei auch auf unsere ersten R-Quelltexte beschränken). Versuche doch mal selber einzuschätzen (oder vielleicht lässt Du den Code auch nochmal laufen), um wieviel effektiver der Code ist, den wir heute mit entsprechender Erfahrung schreiben.
Dann kommt noch dazu, wie willst Du die Effizienz zwischen verschiedenen Programmiersprachen beurteilen? Soll man dann in R genau auf die Techniken verzichten, die den Interpreteroverhead reduzieren? Wenn Du die simple Anweisung nimmst:

Code: Alles auswählen

x[i] <- ....
dann reduziert sich der Interpretationsoverhead entsprechend der Anzahl der Elemente in dem Index i; zudem wird auf der rechten Seite vektorisiert gerechnet und führt im Fall von linearer Algebra zu compiliertem Code ...
- Das ist meiner Meinung nach der Kern der Vektorisierung (außerhalb von loop-hiding) und die große Stärke von R.

Interpreter haben Vorteile bei der Entwicklung von Code. Meiner Meinung nach wird dieser Vorteil langsam kollektiv vergessen, weil wir uns so sehr an die Vorteile gewöhnt haben.

So, jetzt nochmal zurück zum Thema des Threads zurück:
Meine Gesamtsicht ist folgende: Anti hat einen R-Code entworfen, der langsam ist. Aus dem Artikel weiß er, dass die von den Autoren mit ihrer Software 2 min benötigen für das, wofür sein Code sehr viel länger benötigt. Er hat sich bei der Entwicklung des Codes nicht an die Struktur der vorhandenen Lösung gehalten und ist voller Hoffnung, dass irgend jemand jetzt seinen Code auf die gleiche Geschwindigkeit bringen könnte durch etwas Überarbeitung (300€ für eine Steigerung der Effizienz um den Faktor 200000).
Ich gehe jede beliebige Wette ein, dass das Datenhandling in der vorhandenen Java-Lösung völlig anders ist als in dem Code von Anti. Deshalb lässt sich die gewünschte Effizienzsteigerung auch nicht durch Kosmetik erreichen. Die Existenz einer vorhandenen Softwarelösung, aus der sich die gewünschte Laufzeit ableitet, hatte Anti bis vor Kurzem nicht erwähnt. Ich bin deswegen ziemlich angefressen, weil ich die Zeit, in der ich an der Verbesserung des Codes gearbeitet habe, als vergeudete Zeit ansehe.
Und jetzt wieder zum Thema Vergleich der Programmiersprachen: dies Thema lässt sich nicht an dem Code von Anti behandeln.

Viele Grüße, Jörg
Antworten