Re: Kleiner Vergleich der Geschwindigkeit von R vs julia
Verfasst: So Nov 01, 2020 2:37 pm
Die "Wort für Wort"-Übersetzung ist wahrlich eine Krux, wenn es Algorithmen betrifft, die mit Vektoroperationen geschrieben werden können und in der Ausgangssprache elementweise umgesetzt wurden.
Wenn man in R vektorbasiert arbeitet, dann ist dieser Teil so schnell wie kompilierter C-Code, denn dieser Teil ist kompilierter Code (C oder FORTRAN). Nur das Drumherum ist R - und damit interpretierter Code. Interpreter sind langsam, weil sie Zeile für Zeile abarbeiten müssen - das liegt also in der Natur der Sache.
Nun bilden oftmals aber gerade die Vektoroperationen den Kern dessen ab, was an Arbeit zu erledigen ist. Wenn man diesen Teil elementweise ausführt, gerät man in die Interpreterfalle (siehe oben - jede einzelne Zeile muss interpretiert werden).
Wenn man Vektoroperationen nutzt, dann kann der Unterschied zu C oder FORTRAN oder was auch immer nur im function-call-Overhead bzw. normalen Interpretationsoverhead bestehen - diese Overheads sollten nicht der Grund sein, weshalb man von einer zu einer anderen Programmiersprache wechseln sollte.
Es gibt sehr verschiedenen Programmiersprachen; und jede hat ihre Stärken und Schwächen. Z.B. kann man den Gaußschen Algorithmus für die Lösung eines linearen Gleichungssystems auch in PROLOG zu programmieren (das habe ich mit einem Freund zusammen in der Studienzeit wirklich gemacht - der Code sieht auch elegant aus), aber die Geschwindigkeit ist total grottig. Wenn man dagegen ein wissensbasiertes System mit vielen logischen Regeln in C (oder einer an deren 3G-Programmiersprache oder bei z.B. C++ einer 3,5-G-Sprache) implementieren wollte, hätte man sicher arge Probleme, um die Grundstruktur der Problematik zu implementieren (vielleicht gibt es dafür inzwischen Bibliotheken in C oder spezielle Klassen in C++).
Deswegen ist es bei dem Geschwindigkeitvergleich zwischen R und anderen Programmiersprachen wichtig, dass bei der Imprementation in R die R-eigenen Mittel gut ausgenutzt werden. Klar ist dann aber auch, dass nicht viel Spielraum für andere ähnliche Sprachen übrig bleibt (nur Interpretations- und function-call-Overhead).
Klar ist aber auch, dass bei Nichtnutzung der Vektoroperation der Geschwindigkeitsvergleich klar zugunsten von fast jeder kompilierenden Sprache ausfällt.
(zusätzliche Anmerkung: Ob eine Sprache interpretierend oder kompilierend ist, hängt weitestgehend nicht von der Sprache ab, sondern von den üblichen Umgebungen, die diese Sprachen bereitstellen - während des Studiums hatte ich es auch einmal mit einem C-Interpreter zu tun.)
Gruß, Jörg
Wenn man in R vektorbasiert arbeitet, dann ist dieser Teil so schnell wie kompilierter C-Code, denn dieser Teil ist kompilierter Code (C oder FORTRAN). Nur das Drumherum ist R - und damit interpretierter Code. Interpreter sind langsam, weil sie Zeile für Zeile abarbeiten müssen - das liegt also in der Natur der Sache.
Nun bilden oftmals aber gerade die Vektoroperationen den Kern dessen ab, was an Arbeit zu erledigen ist. Wenn man diesen Teil elementweise ausführt, gerät man in die Interpreterfalle (siehe oben - jede einzelne Zeile muss interpretiert werden).
Wenn man Vektoroperationen nutzt, dann kann der Unterschied zu C oder FORTRAN oder was auch immer nur im function-call-Overhead bzw. normalen Interpretationsoverhead bestehen - diese Overheads sollten nicht der Grund sein, weshalb man von einer zu einer anderen Programmiersprache wechseln sollte.
Es gibt sehr verschiedenen Programmiersprachen; und jede hat ihre Stärken und Schwächen. Z.B. kann man den Gaußschen Algorithmus für die Lösung eines linearen Gleichungssystems auch in PROLOG zu programmieren (das habe ich mit einem Freund zusammen in der Studienzeit wirklich gemacht - der Code sieht auch elegant aus), aber die Geschwindigkeit ist total grottig. Wenn man dagegen ein wissensbasiertes System mit vielen logischen Regeln in C (oder einer an deren 3G-Programmiersprache oder bei z.B. C++ einer 3,5-G-Sprache) implementieren wollte, hätte man sicher arge Probleme, um die Grundstruktur der Problematik zu implementieren (vielleicht gibt es dafür inzwischen Bibliotheken in C oder spezielle Klassen in C++).
Deswegen ist es bei dem Geschwindigkeitvergleich zwischen R und anderen Programmiersprachen wichtig, dass bei der Imprementation in R die R-eigenen Mittel gut ausgenutzt werden. Klar ist dann aber auch, dass nicht viel Spielraum für andere ähnliche Sprachen übrig bleibt (nur Interpretations- und function-call-Overhead).
Klar ist aber auch, dass bei Nichtnutzung der Vektoroperation der Geschwindigkeitsvergleich klar zugunsten von fast jeder kompilierenden Sprache ausfällt.
(zusätzliche Anmerkung: Ob eine Sprache interpretierend oder kompilierend ist, hängt weitestgehend nicht von der Sprache ab, sondern von den üblichen Umgebungen, die diese Sprachen bereitstellen - während des Studiums hatte ich es auch einmal mit einem C-Interpreter zu tun.)
Gruß, Jörg
?
): 
!?