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:
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