Sie scheinen viele der gleichen Eigenschaften zu teilen, aber soweit ich das beurteilen kann, ist Python 2.5 um einiges schneller als 1.8.7.Warum ist Python schneller als Ruby?
Gibt es einen tieferen Grund dahinter?
Ein Grund ist, dass Python in Bytecode kompiliert wird, der dann von einer hochoptimierten VM ausgeführt wird. AFAIK Ruby funktioniert in 1.8 und früher nicht so - sondern interpretiert die Bäume im laufenden Betrieb.
Betrachten Sie es auf diese Weise:
Python:
Rubin (vor bis 1,9):
Ohne ich zu sehr ins Detail, Schritt 2 in der alten Ruby-Interpretieren hat viele Wiederholungen, weil sie „verstehen“ die Äste muss jedes Mal, wenn es sie sieht (was in einer inneren Schleife ist viel). Python "versteht" die ASTs nur einmal, und dann führt die VM den Bytecode so schnell wie möglich aus (was sich grundsätzlich nicht von der Funktionsweise der Java- und .NET-VMs unterscheidet).
Ruby 1.9 wurde zu YARV verschoben, was ebenfalls ein VM-basierter Ansatz ist. Ruby 1.9 is faster than 1.8. Hier ist eine quote from the creator of YARV, Koichi Sasada:
Zunächst ist YARV einfache Stapelmaschine die Pseudo-sequentielle Anweisungen auszuführen. Alter Interpreter (matzruby) Traversen abstrakte Syntax Baum (AST) naiv. Offensichtlich ist es langsam. YARV kompilieren, dass AST zu YARV Bytecode und führen Sie es aus.
Ein interessanter Punkt zu beachten ist, dass die Python VM auch Stack-basiert ist, genau wie YARV.
Gibt es tatsächlich Nicht-Stack-basierte VMs? – helpermethod
@Helper: natürlich. Parrot ist registerbasiert, zum Beispiel –
@Helper Methode: die Dalvik VM auf Android, die Lua VM seit 5.0, die Tinypy Python VM, die Tinyrb und RubyGoLightly Ruby VMs, und, wie @Eli Bendersky bereits erwähnt hat, die Parrot VM nur einige Beispiele für registerbasierte VMs. –
Weil Ruby 1.8 nicht wirklich auf Leistung ausgerichtet war, während Python mehr optimiert wurde. Insbesondere hat Ruby 1.8 eine echte Interpretation durchgeführt, anstatt für eine virtuelle Maschine zu kompilieren, wie die meisten Sprachen heutzutage. Ruby 1.9 (mit der YARV VM) ist ungefähr so schnell wie Python 3 (vielleicht ein bisschen langsamer, aber viel näher), und andere Implementierungen sind noch schneller.
Rubin 1.9 ist 2x langsamer als Python, 1,8 war 4x langsamer, siehe unten http://StackOverflow.com/Questions/3252568#3262523 –
@Nas Banov: Die Frage war nicht speziell über die Leistung in der Alioth Spiel, so präsentiert, dass als * die * kanonische Antwort ist bestenfalls trügerisch. 2x für eine Reihe von hoch spezialisierten Benchmarks (die sich selbst als "fehlerhaft" bezeichnen) ist ziemlich nah. – Chuck
Ich habe keine andere ** zuverlässige ** Quelle zum Vergleich. Das * Language Shootout * ist sicherlich zuverlässiger und weniger voreingenommen als entweder ich oder du allein, da mehrere Leute beitragen - es ist offen und wenn du denkst, dass ein Teil des Codes Ruby nicht gerecht wird, kannst du es beheben und verbessern Ergebnis ... wie Leute vor dir haben - genau wie Wikipedia gebaut ist. –
Nichts tief, ich bin mir ziemlich sicher - es ist ausschließlich eine Frage der Implementierung Entscheidungen und Reife. Python war vor nicht allzu langer Zeit in mancherlei Hinsicht ein wenig langsamer! Betrachten Sie zum Beispiel:
$ py24 -mtimeit '[i+i for i in xrange(55)]'
100000 loops, best of 3: 10.8 usec per loop
$ py25 -mtimeit '[i+i for i in xrange(55)]'
100000 loops, best of 3: 9.83 usec per loop
$ py26 -mtimeit '[i+i for i in xrange(55)]'
100000 loops, best of 3: 8.12 usec per loop
$ py27 -mtimeit '[i+i for i in xrange(55)]'
100000 loops, best of 3: 6.35 usec per loop
Ja, alle auf der gleichen Maschine (Macbook Pro, 2,4 GHz Intel Core 2 Duo, OSX 10.5), die alle "offiziellen" Mac veröffentlicht von Python.org (neueste von jedem x in der Serie). Ich habe keine 2.3 um zu überprüfen, aber ich würde erwarten, dass es ein bisschen langsamer als 2.4 ist.
Dies ist nur die Art von Beschleunigung, die viele liebevolle, mühsame Arbeit zwischen aufeinanderfolgenden Releases von fast der gleichen zugrunde liegenden Architektur erreichen kann. Nicht so auffällig wie das Hinzufügen von feechurz, aber oft erheblich nützlicher in der realen Welt! -)
Ich bin mir ziemlich sicher, dass Ruby kann auch auf eine solide, performance-robuste zugrunde liegende Architektur zu stabilisieren, dann beginnen zu bekommen Im Laufe der Jahre hat sich ein stetiger Strom von Leistungsverbesserungen entwickelt, um (z. B.) die 40% oder mehr weitere Verbesserungen zu erzielen, die wir in den letzten Jahren (zumindest in einigen Teilen) von Python beobachten konnten.
Immer mehr Leute arbeiten seit Jahren an der Python-Entwicklung, so dass mehr Optimierungen vorgenommen wurden. Die Sprachen sind ähnlich flexibel und ausdrucksstark, daher sollte ihre Leistung konvergieren, da alle guten Optimierungsideen in beiden verwendet werden. Wie bereits erwähnt, verringert Ruby 1.9 die Performance-Lücke mit Python erheblich.
Ich lese die Antworten und ich sehe die meisten Leute sagen "Oh, Sie sollten nicht mit Ruby 1.8 vergleichen, sollten Sie mit 1,9 gehen, es ist viel schneller". Ok, warum nicht einfach ein paar Benchmarks anschauen?
Also hier ist, wie Ruby 1.9 (YARV) Tarife gegen Ruby 1.8 (MRT): http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=yarv&lang2=ruby
Und hier ist, wie Ruby 1.9 im Vergleich zu Python 2.x: http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=yarv&lang2=python
Zur Erinnerung, Rubin 1.9 ist etwa 2x schneller als Ruby 1.8 - aber immer noch langsamer - 2x langsamer - als Python.
PS. Ich denke, ich muss nach Chucks Einwänden klären: Ich sehe nicht die Computer Language Shootout als die endgültige Antwort auf die Fragen von Life, the Universe and Everything. Weit davon entfernt. Ich würde mich freuen, auf andere objektive Quellen verwiesen zu werden.
Ich würde mich auch freuen, informelle/subjektive Ergebnisse von Menschen hier auf S/O zu hören, vorausgesetzt, sie haben an über 50 Diskussionen über Python oder Ruby teilgenommen und ihre Ruby/Python Bias ist innerhalb +/- 5dB (Ruby/Python Ratio berechnet als RPR = 10 * log10 (numTags ('Ruby')/numTags ('Python')) dB, also für User Chuck das wäre 10 * log10 (225/13) = 12dB, meins ist -10 - we beide können nicht auf unvoreingenommene Meinung verlassen werden) :-)
Die Benchmarks sind interessant, aber Sie lesen zu viel in sie. Du meinst "Ruby lässt eine Handvoll sehr ungewöhnlicher Programme etwa halb so schnell laufen wie Python." Das Alioth-Shootout-Spiel ist nützlich, um eine ungefähre Vorstellung von den Eigenschaften der verschiedenen Sprachen zu bekommen, aber sie sind kaum gut genug, um einen präzisen Hinweis zu geben, wie "Ruby 1.9 ist 2x langsamer als Python" Sie werden sehen, ob Ihr Programm, wenn Sie es verwenden. Ich glaube, dass Ruby 1.9 noch langsamer als Python ist, aber sich nur auf einen relativ kleinen Unterschied im Shootout-Spiel zu verlassen, ist eine fehlerhafte Methode. – Chuck
@Chuck - "etwa 2x schneller" und "2x langsamer" scheinen, als ob sie von Nas Banov als Annäherungen präsentiert werden, nicht "eine genaue Angabe", wie Sie vorschlagen möchten. – igouy
Irgendwelche Gründe, warum Sie 1.8.7 wählen, wenn 1.9.1 das beständige und empfohlene ist? 1.9-Serie eingeführt YARV: http://en.wikipedia.org/wiki/YARV –
War nicht versucht, einen flamewar oder so etwas. Probieren Sie es aus, was bereits auf meinem System installiert war, nämlich Ruby 1.8.7. – cduruk
Nur pedantisch hier sein. Es sind nicht die Sprachen, die langsamer oder schneller sind als die Interpreter (d. H. Die Implementierung). Sie sprechen speziell über den CPython-Interpreter Version 2.5 gegenüber dem MRT-Interpreter Version 1.8.7. Die Auftritte wären für (sagen wir) Jruby und Jython oder IronRuby und IronPython oder Rubinius und PyPy sehr unterschiedlich. –