War euch R je zu langsam?

Interessantes ohne bestimmtes Thema!

Moderator: student

8ZRbP
Beiträge: 26
Registriert: Do Okt 13, 2016 11:56 am

War euch R je zu langsam?

Beitrag von 8ZRbP » Mi Nov 02, 2016 5:15 pm

Hi,

in der Wikipedia lese ich, ein Nachteil von R wäre die relative Langsamkeit:

https://de.wikipedia.org/wiki/R_(Progra ... #Rezeption

Zusammenfassung: R wurde von Statistikern entwickelt, nicht von Programmierern. Darum wurde nicht sonderlich auf die Schnelligkeit/Effizienz bei der Jobverarbeitung geachtet.

Als neuere, schnellere Entwicklung wurde u.a. Julia angepriesen. Offenbar wird es von den Entwicklern als Weiterentwicklung von R angesehen:

https://de.wikipedia.org/wiki/Julia_(Pr ... ersprache)


Ich hatte noch nie das Problem, dass mir R in der Jobausführung zu langsam war. Ich stelle mir die Frage, welche Arten von Statistiken jemand rechnet, und mit wie großen Datensätzen, dass dieses Problem auftritt. Hat jemand davon eine Vorstellung?

Benutzeravatar
student
Beiträge: 218
Registriert: Fr Okt 07, 2016 9:52 am

Re: War euch R je zu langsam?

Beitrag von student » Mi Nov 02, 2016 6:40 pm

In der Regel ist für meine Anwendungen die Ausführungsgeschwindigkeit von [R] hoch genug. Ich hatte mal ein Polynom x-ten Grades und dessen Anpassung (Spline) hat sich tatsächlich über mehrere Stunden hingezogen.

Eventuelle Wartezeiten haben mich bisher nicht überzeugt auf z. B. Julia (julia-0.3.1-win64) umzusteigen. Aufgrund der Benchmarks habe ich mich auch mal mit Julia beschäftigt, die Dame hat mich aber nicht überzeugt (bis jetzt) und bin bei [R] geblieben (und immer noch hoch zufrieden)! Julia beobachte ich zurzeit nicht intensiv, vor rund 2 Jahren wurde sie allerdings ziemlich - wie ich vermutet von Interessenvertretern - gepuscht...
Viele Grüße,
Student
-----------------------------------------------------------------------------------------------------------------------
faes.de, r-statistik.de und das Ad-Oculos-Projekt

Habe Mut, dich deines eigenen Verstandes zu bedienen! (Kant)

jogo
Beiträge: 888
Registriert: Fr Okt 07, 2016 8:25 am

Re: War euch R je zu langsam?

Beitrag von jogo » Mi Nov 02, 2016 7:40 pm

Bei mir gab es bisher keine Situation, in der R zu langsam war.

Sofern es um lineare Algebra oder auch gewöhnliche Differentialgleichungen geht, nutzt R die komplett durchgetesteten Bibliotheken von FORTRAN oder C - dies war eines der Designprinzipien bei der Entstehung von R. Die Programmiersprachen FORTRAN und C sind compilierte Sprachen, R ist eine interpretative Sprache. Dass interpretative Sprachen langsam sind gegenüber compilierten Sprachen (wenn man gleichartige Konstrukte miteinander vergleicht), ist seit den ersten Interpretern bekannt.
Insofern bezieht sich die erwähnte Langsamkeit von R auf genau diesen Teil (d.h. den Interpreter). Nun ist es aber so:
1. Wenn man kleine Probleme hat, spielt die Laufzeit ohnehin keine Rolle.
2. Wenn man halbwegs ordentliche Probleme hat, so sind die meisten wesentlichen Arbeitsschritte (eben die lineare Algebra o.ä.) bereits laufzeiteffizient gelöst in den vorhanden FORTRAN- und C-Bibliotheken. (Außer man programmiert die Funktionen der Bibliotheken nochmal in interpretiertem R nach.)
3. Wenn die Probleme wesentlich größer werden, muss man sich ohnehin für das ganze Drumherum einen Schlachtplan entwerfen. Oder man muss sich nach anderem Werkzeug umschauen oder, oder, oder ...

Natürlich kann man jedes Problem beliebig aufblasen, so dass bei Beibehaltung eines gegebenen Algorithmus dieser nicht mehr effizient bzw. durchführbar ist. Hier sollte man zuerst die Komplexität schätzen (z.B. wie verändert sich die Laufzeit bei Veränderung der Dimension n des Problems), dann kann man die Aufwand berechnen für den angezielten großen Wert von n.

Gruß, Jörg

Benutzeravatar
EDi
Beiträge: 622
Registriert: Sa Okt 08, 2016 3:39 pm

Re: War euch R je zu langsam?

Beitrag von EDi » Mi Nov 02, 2016 9:39 pm

Nö, bisher noch nicht.

data.table trägt viel dazu bei (in C geschrieben, auch RAM-effizient) - will ich nicht missen bei >100k Beobachtungen...
Rcpp ist auch eine gute Lösung fuer einfachere Probleme, für den Rest ich bin nicht C++ Ninja genug.
Ich hab ja auch Zeit oder
kann die Berechnungen auf einen Server auslagern und zwischenzeitlich was anderes Arbeiten oder
ueber Nacht laufen lassen...

Es kommt auch sehr drauf an wie man in R programmiert - man kann schnell und effizient schreiben oder langsam und speicherfressend... (dies gilt aber vermutlich fuer alle Sprachen).


Ich hab auch schon Modelle gehabt (Splines wie bei student) die mehrere Stunden gebraucht haben. Datengrösse war >50k Beobachtungen mit 2 random effects und einer Interaktion.
Ich bezweifle, dass man in irgendeiner anderen Sprache solche Modelle mit einem ready-to-go interface rechnen kann. Die Zeit die man beim programmieren mit R nämlich spart, sollte man nicht vergessen.
Julia hat mich bisher nicht ueberzeugt. Python hab ich schon mehrere Anläufe gegeben, aber bisher bin ich da auch nicht hängengeblieben.
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.

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

Re: War euch R je zu langsam?

Beitrag von bigben » Mi Nov 02, 2016 10:16 pm

Ja, sowas hatten wir im alten Forum öfters: Jemand denkt sich eine tolle Simulation oder einen tollen Algorithmus aus, implementiert ihn mit geschachtelten for-Schleifen und das Ganze läuft unerträglich langsam. Dann grübelt man erfolglos, wie das wohl zu vektorisieren wäre und befragt letztlich ein Forum. Wenn eine for- Schleife in R so schnell wäre wie in C++, dann würden die ganzen Vektorisierungsfragen wegfallen. Dann könnte man seine Schleifen einfach als Schleifen schreiben und wäre fertig.
Bootstrapping, Bayes mit mcmc und Simulationen sind im Kommen und Geschwindigkeit ist Trumpf. Würden wir uns für RCpp interessieren, wenn R so schnell wäre wie eine compilierte Sprache? Ich nicht.
R ist in vielerlei Hinsicht hervorragend, aber es ist zum Teil langsam und man verbringt doch immer mal wieder wertvolle Zeit und investiert Konzentration, sich in dem anderen Teil zu bewegen. Oft ist setDT() das Eingeständnis, dass normales R zu langsam ist.
Julia ist noch sehr jung, das muss man mal abwarten. Python ist i. d. R. ebenfalls interpretiert, so dass man wieder nur schnell ist, wenn man auf fertige Bausteine zugreift und sonst langsam.
Incanter fände ich spannend: Das ist Statistik mit Clojure: Eine compilierte Sprache aber mit REPL, schnell und vom Betriebssystem unabhängig weil Java, ein Lisp, also keine blöden Überraschungen mit der Syntax (ich erinnere an 1:n+1 in R) - eigentlich alles Siegereigenschaften. Man hört nur leider nichts davon. Scheint keine große Bewegung zu werden. Schade eigentlich.

Jetzt und heute ist R das Richtige und wenn mich etwas zu Python treiben würde, dann nicht die Geschwindigkeit. Mal sehen, wo Julia in fünf und in zehn Jahren steht.

LG,
Bernhard
---
Programmiere stets so, dass die Maxime Deines Programmierstils Grundlage allgemeiner Gesetzgebung sein könnte

8ZRbP
Beiträge: 26
Registriert: Do Okt 13, 2016 11:56 am

Re: War euch R je zu langsam?

Beitrag von 8ZRbP » Do Nov 03, 2016 10:24 am

Danke für Eure zahlreichen und ausführlichen Statements! :)

consuli
Beiträge: 342
Registriert: Mo Okt 10, 2016 8:18 pm

Re: War euch R je zu langsam?

Beitrag von consuli » Do Nov 03, 2016 9:52 pm

Hier auch noch meine 5 Cents.

Die Haupteinschränkungen von R liegt imho nicht in der Geschwindigkeit. Hier kann man mit diversen Optimierungen noch einiges rausholden (vgl. Advanced R Buch). Die grösste statistische Haupteinschränkungen liegt m.E. in der Verarbeitung sehr grosser Daten (Big Data), insbesondere wenn diese noch nicht als sogenannter Flat-File vorliegen, sondern erst aus verschiedenen Datenbanktabellen aneinander gejoint werden müssen. Ein Fall aus der Versicherung. 1 Million Kunden, haben 5 Typen von Kfz-Deckungen (Haft, Teilkasko, Kollision, Parkschaden, Assistance), die wiederum aus 2 bis 11 Detaillleistungen bestehen. Für solche Joins ist R einfach nicht gemacht. Dann gibt es weitere programmiertechnische Einschränkungen, dass R keine strikt durchstruktierte objektorientierte Programmiersprache ist und keine GUI Programmierung zulässt.
Thanks to Steven for bringing up the best explanation for the existence and the origin of the universe, though. Especially for been a lighthouse of will-power still shining on, not only for disabled people, but any (beautiful minded) person.

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

Re: War euch R je zu langsam?

Beitrag von bigben » Fr Nov 04, 2016 10:20 am

Hallo consuli,

danke für den interessanten Beitrag. Kannst Du noch ein wenig genauer beschreiben, mit welcher Art von Datensatz Dein R da überfordert war? Ich gebe Dir natürlich Recht, dass R angelegt worden ist für typische Statistikprobleme (wir haben nur eine kleine Stichprobe untersucht und wollen trotzdem allgemeingültige Aussagen ableiten) und nicht für Big Data-Fragestellungen (wie werde ich all der Daten Herr und trenne wichtiges von unwichtigem).

Da ich selbst nie mit großen Datensätzen zu tun habe, muss ich nochmal nachfragen. Dein Beispiel mit 1 Mio Kunden, zu denen Daten aus zwei anderen Datenbanken gejoint werden müssen klingt erst einmal nicht sooo groß. Ich hätte jetzt gedacht, dass das R-eigene merge das hinkriegt und das draufgesetzte data.table darüber nur kurz lacht. Anscheinend ist Dein Beispiel aber komplexer oder umfangreicher als es in der Kurzdarstellung klingt?

Natürlich lautet die kanonische Antwort auf das Problem: Joins von Daten in DBMS lässt man das DBMS machen. Ich bin recht sicher, dass das auch die Antwort für den Hauptkonkurrenten Python, wahrscheinlich würde man das aber auch als C++-Programmierer am liebsten in SQL machen. So gesehen spricht es nicht gegen R als derzeit beste Statistiklösung.
consuli hat geschrieben:Dann gibt es weitere programmiertechnische Einschränkungen, dass R keine strikt durchstruktierte objektorientierte Programmiersprache ist
Das ist ein sehr guter Hinweis, weil das natürlich ein deutlicher Unterschied zum Hauptkonkurrenten Python ist. Objektiorientierung ist R ist sehr ungewöhnlich gelöst und dass es zwei bis drei verschiedene Objektorientierungssysteme gibt, ist nervig (hat Hadley Wickham eigentlich schon ein Objektsystem für R entwickelt? Vielleicht {tidy_obj}?). Python ist von Grund auf auf Objektorientierung ausgelegt und zieht das aus sehr schön durch, ohne übermäßig komplex zu werden. Vielleicht kommt mir das auch nur so vor, weil bei mir der Groschen zur Objektorientierung erst mit Python gefallen ist. Ich erinnere mich aber auch an Diskussionen, dass manchem Java-Fan die Objektorietierung von Python nicht strikt genug war (Encapsulation war da das Stichwort, IIRC, aber im Detail kriege ich das so schnell nicht mehr hin). Das deutet schon darauf hin, dass Objektorientierung auch eine Geschmacksfrage ist. Persönlich finde ich, dass man es mit der Objektorientierung auch schnell übertreiben kann und sie für Projekte geringer und mittlerer Komplexität nicht erforderlich ist, und wer schreibt schon wirklich umfangreiche Projekte in einer Statistiksprache?

und keine GUI Programmierung zulässt.
Und da stimme ich Dir voll zu. Man kann in R keine Programme schreiben, die für Otto-Normalnutzer aussehen, wie Programme in diesem Jahrhundert sonst aussehen. Ich denke, dass der Shiny-Hype etwas damit zu tun hat, dass man endlich was bewegtes Buntes präsentieren kann, was auf die Maus reagiert. Vielleicht unterschätze ich Shiny aber auch nur, weil ich mich noch nicht genügend damit beschäftigt habe. Jedenfalls sehe ich den Bonus von Python nicht in möglichen Geschwindigkeitsgewinnen sondern darin, dass es sowohl als general purpose Sprache als auch als Statistik- und Maschinenlernen-Sprache tauglich ist. Wenn irgendwas, dann könnte das mich irgendwann in diese Richtung ziehen. Derzeit zieht da aber noch nichts.

Ansonsten leidet R unter der Last seines Alters. Es hat sich viel Müll angesammelt. Eine frische, junge, neu zu erstellende Sprache könnte in der Syntax einiges aufräumen (heißt es na.rm = TRUE oder omit.na = TRUE oder method = "rm.na" oder...). Anstelle von Vereinheitlichung und Vereinfachung geht der Trend in R aber in eine andere Richtung. Hadley Wickham überredet gerade die Community, dass die kleinste sinnvolle Datenform nicht der Vector sondern der Dataframe sind, dass Funktionen als erstes Argument immer den zu bearbeitenden Dataframe haben müssen, weil dann alles so schön zur Pipe passt, die die Leute jetzt auch in Vignetten zu ihren Paketen verwenden, wo sie gar nicht hin gehört und man produziert eine Reihe von Coding Styles, die einander klar widersprechen und sich großteils nicht am früheren allgemeinen Gebrauch orientieren (der Punkt in Variablen- und Funktionsnamen ist extrem verbreitet in alten Funktionen und Argumenten, jetzt soll er durch den Unterstrich ersetzt werden, weil Menschen mit C++, Java- und Python-Hintergrund sonst verwirrt werden, weil es für die objektorientiert aussieht? Kleiner Tipp: Diese Leute können gar nicht früh genug lernen, dass Objektorientierung in R anders aussieht.)

In der Summe gewinnt R für mich derzeit ganz klar. Wie jogo schon schrieb: Kombination aus schneller Programmierung in R und schnellem Rechnen in den Teilen, die in FORTRAN und C implementiert sind.

LG,
Bernhard
---
Programmiere stets so, dass die Maxime Deines Programmierstils Grundlage allgemeiner Gesetzgebung sein könnte

consuli
Beiträge: 342
Registriert: Mo Okt 10, 2016 8:18 pm

Re: War euch R je zu langsam?

Beitrag von consuli » Mo Nov 07, 2016 1:24 pm

bigben hat geschrieben:Ich hätte jetzt gedacht, dass das R-eigene merge das hinkriegt und das draufgesetzte data.table darüber nur kurz lacht. Anscheinend ist Dein Beispiel aber komplexer oder umfangreicher als es in der Kurzdarstellung klingt? Natürlich lautet die kanonische Antwort auf das Problem: Joins von Daten in DBMS lässt man das DBMS machen.
Ja, es ist komplexer. Zum einen hängen an den 1 Million Kunden schon 125 Datenfelder dran und an den anderen Tabellen auch noch mal 50. Die gesamten Tabellendaten können schon in den zweistelligen Gigabyte bereich gehen. Weiterhin werden bei einer Versicherung laufend neue (mutmasslich margenstarke) Zusatzdeckungen erfunden, die von der Informatik von der Informatik oft unter grösstem Zeitdruck bis zum halbjährlichen Release Termin quick-and-dirty eingeflickt werden. Auf die Schnelle werden dann neue dirty Deckungs- und Leistungsschlüssel eingeführt werden, damit die neuen Zusatzdeckungen in der alten (erweiterteten) Programmlogik weiter laufen können. Im Ergebnis kann man die Datenbanktabellen dann nicht mehr mit einem Inner/ Outer Join verbinden, sondern muss erstmal einen Full Join machen, und dann die richtigen Datenzeilen rauspuzzeln. Full-Join == Jede Datenzeile der ersten Tabelle mit jeder Datenzeile der zweiten Tabelle. Die Anzahl der Datenzeilen potenziert sich während der Verarbeitung also nach der Formel m x n ! Ausserdem würden solche Full-Joins auf grossen Transaktionsdatenbanken auch 2 bis 3 Tage laufen. Die Aussendienstler könnnten in dieser Zeit dann aus Performance/ Verfügbarkeitsgründen keine Geschäfte abschliessen, was nicht akzeptabel ist. Eben aus diesem Grund setzen grosse Firmen so gerne SAS ein, weil es als "Data Middleware" performant auch grösste Datenbanktabellen aneinander joinen kann. Wenn R das auch könnte, würde es SAS gar nicht mehr geben.
So gesehen spricht es nicht gegen R als derzeit beste Statistiklösung.
Ja, nur mit der Einschränkung, dass man bereits zusammengejointe Flatfiles hat, was wohl der häufigere Statisiker/ Data Scientist Alltag sein dürfte.
Thanks to Steven for bringing up the best explanation for the existence and the origin of the universe, though. Especially for been a lighthouse of will-power still shining on, not only for disabled people, but any (beautiful minded) person.

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

Re: War euch R je zu langsam?

Beitrag von bigben » Mo Nov 07, 2016 3:52 pm

Aha, danke für die Erklärungen! Ja, ich glaube an sowas hatten die Erfinder von S weiland in den 70ern nicht gedacht...
---
Programmiere stets so, dass die Maxime Deines Programmierstils Grundlage allgemeiner Gesetzgebung sein könnte

Antworten

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast