1. Foren
  2. Kommentare
  3. OpenSource-Forum
  4. Alle Kommentare zum Artikel
  5. › Programmiersprache Julia: Wie…

Hat mal jemand den Benchmark getestet?

Neue Foren im Freiraum! Raumfahrt und freie Software haben jetzt einen Platz, die Games tummeln sich jetzt alle in einem Forum.
  1. Thema

Neues Thema Ansicht wechseln


  1. Hat mal jemand den Benchmark getestet?

    Autor: Frittenjay 13.10.21 - 14:59

    Ich habe gerade mal aus Spaß den Python-Benchmark mehrfach laufen lassen und komme da auf 25-26 Sekunden je nach Durchlauf. Aber auf einem uralten Intel Q8400 und etlichen anderen geöffneten Programmen. Ich habe da schon im "Idle" ca. 20% Prozessorlast. Irgendwie kommen mir da die 22 Sekunden auf einem 2600X komisch vor oder ist der wirklich so langsam?

  2. Re: Hat mal jemand den Benchmark getestet?

    Autor: rslz 13.10.21 - 15:34

    Bei mir auf dem Ryzen 3900X, Ubuntu 24.02.3 LTS

    - Python 3.9.7: 6.85s
    - Julia 1.6.1: 0.13s

  3. Re: Hat mal jemand den Benchmark getestet?

    Autor: AndyK70 13.10.21 - 15:40

    AMD Ryzen 5 3600, 32GB RAM, Windows 10 21H1

    Mit laufendem Hintergrundprogramm, welches ständig 84% Auslastung (10/12 Threads) macht:
    C:\Users\icke\Downloads\bubblesort-golem>bubblesort-python-golem.py
    Duration: 10.0260000229

    Ohne dieses und CPU im Idle:
    C:\Users\icke\Downloads\bubblesort-golem>bubblesort-python-golem.py
    Duration: 8.9240000248

    julia habe ich nicht installiert
    keine Ahnung wieso bei ihm das 22s dauern sollte.

  4. Re: Hat mal jemand den Benchmark getestet?

    Autor: Miroslav-Stimac 13.10.21 - 21:32

    Danke für Deine Benchmarksergebnisse, AndyK70!

    Ich bin erstaunt, dass mein Ryzen 2600 mehr als 20 Sekunden für den Python-Benchmark benötigt und Dein Ryzen 3600 nur etwa 9 Sekunden. So große Unterschiede hätte ich nicht erwartet.

    Ich habe den Benchmark bei mir mehrmals wiederholt und komme auf etwa 21 bis 22 Sekunden. Dabei spielt es keine Rolle, ob ich den Benchmark von Spyder aus oder direkt mit python.exe vom Command Prompt aus ausführe. Meine erste Vermutung war, dass etwas im BIOS nicht richtig eingestellt ist. Also habe ich diverse CPU- und RAM-Settings von Auto auf Standard gesetzt und die Unterstützung für Virtualisierung deaktiviert, weil ich vor langer Zeit bei einem alten Mainboard schon einmal massive Performanceprobleme mit aktivierter Virtualisierung hatte. Leider brachte das keine nennenswerten Verbesserungen der Benchmarkergebnisse.

    Als nächstes habe ich den Python-Benchmark mit dem Betriebssystem GhostBSD 21.09.29 statt Windows 10 ausgeführt, wobei ich jedoch GhostBSD in einer VM mit Windows 10 als Host verwendet habe. Auch das brachte keine nennenswerten Verbesserungen der Benchmarkergebnisse.
    Leider habe ich keine physische Installation eines anderen Betriebssystems auf meinem Computer um sicher ausschließen zu können, dass es nicht ein Problem mit meiner Windowsinstallation gibt. Jedoch führte ich zwei andere Benchmarks von Drittherstellern aus, die nichts mit Python zu tun haben, und meine Benchmarkergebnisse entsprechen in etwa den normalen Werten eines Ryzen 2600.

    Wenn ich mir die Ergebnisse von Dir, rslz und Frittenjay ansehe, dann habe ich die Vermutung, dass mein Computer ein Problem hat oder es ein spezielles Problem beim Ryzen 2600 ist. Es ist jedoch ungewöhnlich, dass dies anscheinend nur den Python-Benchmark und nicht die zwei Benchmarks der Dritthersteller und auch nicht den Julia-Benchmark betrifft.

    Wie dem auch sei, etwas habe ich festgestellt. Auf meinem Windows-System läuft der Python-Benchmark in 16 statt 22 Sekunden, wenn ich Python Version 3.9.5 statt Python Version 3.8.12 verwende. Im Artikel benutzte ich die Python Version 3.8.11. Also die neue Version scheint bei dem Benchmark deutlich schneller zu sein, aber erklärt den Unterschied zwischen meinem Ryzen 2600 und Deinem Ryzen 3600 aus meiner Sicht noch nicht ganz.

    Welche Python-Version hast Du verwendet?

    Hat hier im Forum zufällig jemand mit einem Ryzen 2600 den Python-Benchmark ausgeführt?
    Falls ja, mit welcher Python-Version?

    Schöne Grüße,
    Miroslav

  5. Re: Hat mal jemand den Benchmark getestet?

    Autor: 0x8100 13.10.21 - 22:48

    R7 3700X

    PS > python.exe --version
    Python 3.9.6
    PS > python.exe .\bubblesort-python-golem.py
    Duration: 6.992835521697998

    PS > .\pypy3.exe --version
    Python 3.7.10 (77787b8f4c49, May 15 2021, 11:51:36)
    [PyPy 7.3.5 with MSC v.1927 64 bit (AMD64)]
    PS > .\pypy3.exe .\bubblesort-python-golem.py
    Duration: 0.2620668411254883

    ist ja nicht so, als ob man python nicht auch kompilieren könnte.



    1 mal bearbeitet, zuletzt am 13.10.21 22:49 durch 0x8100.

  6. Re: Hat mal jemand den Benchmark getestet?

    Autor: devhd 13.10.21 - 23:15

    Python kann man kompilieren, deswegen ist so ein Vergleich mit Julia fraglich.

    Beim Interpretieren von Bubblesort liefern bei mir Python 3.6, 3.7, 3.8 und 3.9 ähnliche Ergebnisse.
    Python 3.10 ist 10% schneller.
    Python 3.11 ist 40% schneller.



    1 mal bearbeitet, zuletzt am 13.10.21 23:17 durch devhd.

  7. Re: Hat mal jemand den Benchmark getestet?

    Autor: AndyK70 13.10.21 - 23:22

    Miroslav-Stimac schrieb:
    --------------------------------------------------------------------------------
    > Danke für Deine Benchmarksergebnisse, AndyK70!
    >
    > Welche Python-Version hast Du verwendet?
    Interessanterweise lief der Benchmark bei mir auf Version 2.7.18, durch einen kleinen Config-Bug bei meiner Dual-Installation.
    Die Extension .py war noch auf den 2.7er verknüpft. Hätte ich in den Prompt "py bubblesort-python-golem.py" geschrieben, wäre er mit Version 3.9.2 gelaufen

    Also erneut mit V2.7.18 (mittlerer Wert von drei Läufen):
    C:\Users\icke\Downloads\bubblesort-golem>bubblesort-python-golem.py
    Duration: 8.99000000954

    Habe dann auf 3.9.7 upgedated und Default auf Version 3.9.7 gelegt.
    Erneut ausgeführt (mittlerer Wert von drei Läufen):
    C:\Users\icke\Downloads\bubblesort-golem>bubblesort-python-golem.py
    Duration: 7.320825815200806

    Nun auf die aktuellste Version 3.10.0 upgedated und noch einmal (mittlerer Wert von drei Läufen):
    C:\Users\icke\Downloads\bubblesort-golem>bubblesort-python-golem.py
    Duration: 9.878823518753052


    ich glaub, ich geh wieder zurück auf 3.9.7 :D

    PS:
    ich hab auch noch mal eben pypy geholt und getestet:

    C:\Users\icke\Downloads\bubblesort-golem>c:\pypy\pypy3.exe --version
    Python 3.7.10 (77787b8f4c49, May 15 2021, 11:51:36)
    [PyPy 7.3.5 with MSC v.1927 64 bit (AMD64)]

    C:\Users\icke\Downloads\bubblesort-golem>c:\pypy\pypy3.exe bubblesort-python-golem.py
    Duration: 0.2860879898071289



    1 mal bearbeitet, zuletzt am 13.10.21 23:35 durch AndyK70.

  8. Re: Hat mal jemand den Benchmark getestet?

    Autor: AndyK70 14.10.21 - 00:31

    Und um auch den Aufruf und die Compile-Zeit mit einzubeziehen, habe ich mal mittels der Powershell die gesamte Ausführungszeit messen lassen.
    py -2 = V2.7.18
    py -3 = V3.10.0
    pypy = V3.7.10

    PS C:\Users\icke\Downloads\bubblesort-golem> for($i=0; $i -lt 3; $i++){ Measure-Command {py -2 .\bubblesort-python-golem.py} | Select-Object Count, TotalSeconds }

    Count TotalSeconds
    ----- ------------
    8,8428778
    8,8842537
    8,89962


    PS C:\Users\icke\Downloads\bubblesort-golem> for($i=0; $i -lt 3; $i++){ Measure-Command {py -3 .\bubblesort-python-golem.py} | Select-Object TotalSeconds }

    TotalSeconds
    ------------
    9,8396427
    9,9194617
    9,8746319


    PS C:\Users\icke\Downloads\bubblesort-golem> for($i=0; $i -lt 3; $i++){ Measure-Command {C:\pypy\pypy3.exe .\bubblesort-python-golem.py} | Select-Object TotalSeconds }

    TotalSeconds
    ------------
    0,3912708
    0,3933007
    0,3877716

  9. Re: Hat mal jemand den Benchmark getestet?

    Autor: Miroslav-Stimac 14.10.21 - 08:01

    Danke für Deine Benchmarkergebnisse!
    Mit pypy 3.7.5 erreiche ich 0,37 Sekunden. Nun ist mein PC mit Ryzen 2600 sogar ein wenig schneller als Dein PC mit dem Ryzen 3600, aber das kann viele mögliche Ursachen haben wie zum Beispiel laufende Prozesse im Hintergrund. Die Ergebnisse klingen plausibel.

    Somit ist mein Computer nur mit python.exe viel langsamer, nämlich mehr als doppelt so langsam, wie Dein Computer.
    Einen so großen Unterschied zwischen Ryzen 2600 und Ryzen 3600 hätte ich nicht erwartet.
    Laut cpu-monkey.com ist der CPU-Takt eines Ryzen 3600 mit 3,6 GHz um 200 MHz höher als der eines Ryzen 2600 mit 3,4 GHz. Beim Turbo 1 Core Mode sind es 4,2 GHz im Vergleich zu 3,9 GHz. Das sind Unterschiede von weniger als 10 Prozent und können nicht erklären, wieso mein PC beim Ausführen des Benchmarks mit python.exe so lahm ist.

    Jedoch hat, laut cpu-monkey.com, der Ryzen 3600 mit 32 MB einen doppelt so großen third level cache wie der Ryzen 2600 mit 16 MB third level cache. Im Windows Task Manager sehe ich, dass der Python.exe Prozess etwa 5 MB Speicher verwendet. Zusammen mit dem Console Windows Host und dem Anaconda Prompt sind es dann etwa 7 bis 8 MB. Im Hintergrund laufen natürlich noch diverse andere Prozesse, auch jene des Betriebssystems.
    Ich könnte mir vorstellen, dass bei Deinem Ryzen 3600 python.exe und der Benchmark dann vielleicht im third level cache sind und dementsprechend die Speicherzugriffe schneller sind als bei meinem Ryzen 2600, bei dem vielleicht der Benchmark teilweise auf den RAM zugreifen muss.

    Schöne Grüße,
    Miroslav

  10. Der Benchmark ist blöd!

    Autor: mfeldt 14.10.21 - 10:46

    Klar sind Schleifen langsam, besonders geschachtelte. Deshalb wurden ja Programmiersprachen der sog. 4. Generation entwickelt, die schleifenfreie Array-Operationen erlauben.

    Wenn also Wissenschaftler komplexe Simulationen schreiben lohnt es immer genau zu schauen, ob man nicht eine Schleife durch einen Array-Operation ersetzen kann. Und insofern wäre der einzig gültige Benchmark-code random_numbers.sort() bzw. das entsprechende Julia-Pendant.

  11. Re: Der Benchmark ist blöd!

    Autor: Johannes321 14.10.21 - 11:40

    Ähm... nein? Es gibt auch Problemfelder die sich nicht mit Matrizen ausdrücken lassen ;-)

    Beispiel: Das Scrapen einer Website per bs4 verursacht in Python schon einiges an Rechenaufwand, weil bs4 halt komplett in Python geschrieben ist.

    Kann auch ein paar Werte beisteuern:

    Python3.9: 9.8s
    Mypyc: 3s
    Pypy: 0.37s
    (Ryzen 1700X)

    Da die Mächtigkeiten von Julia und Python ziemlich gleich sind gehe ich mal davon aus, dass die in ein paar Jahren gleichauf liegen werden. Dann ist Python aber immer noch die bessere General Purpose Language, und daher wird es sich durchsetzen.

    Aber wenn wir aus der Vergangenheit eins gelernt haben, dann, dass Konkurrenz das Geschäft belebt. So ist der Druck bei Python da auch was für die Leistung zu tun.
    Was mich in diesem Kontext ebenfalls nervt ist, dass es bei Python mit den Type Annotations nicht so recht vorwärts geht.

  12. Re: Hat mal jemand den Benchmark getestet?

    Autor: fabiwanne 14.10.21 - 13:07

    ich habe auf nem 7 Jahre älteren vorvorvorgänger FX-8370 und DDR3-RAM gebenchmarkt. Der Müsste laut passmark Single-Core halb so schnell sein... Trotdem komme ich nicht ansatzweise an die 22s. Der Benchmark ist erstunken und erlogen.

  13. Re: Der Benchmark ist blöd!

    Autor: Wasserflasche 14.10.21 - 14:10

    Ja, und gerade beim Iterieren über Werte in Dataframes und Matrizen wird es dann mit NumPy oder Pandas auch nochmal deutlich schneller.

  14. Re: Hat mal jemand den Benchmark getestet?

    Autor: rldml2 15.10.21 - 08:25

    Erstunken und erlogen vielleicht nicht, aber dieser Thread beweist, wie abhängig Benchmarkergebnisse von der verwendeten Umgebung sind.

    Relevant kann daher eigentlich immer nur das Verhältnis der Benchmarks zueinander sein (in diesem Fall Python vs. Julia).

    Da man Python-Scripte allerdings auch kompilieren kann (sofern ich das hier im Thread hoffentlich richtig aufgeschnappt habe) stellt sich mir schon ein wenig die Frage, ob man diese Fähigkeit in Julia als Alleinstellungsmerkmal hervorheben sollte...

  15. Re: Hat mal jemand den Benchmark getestet?

    Autor: Miroslav-Stimac 16.10.21 - 19:09

    Hallo rldml2,

    ja, man kann Python kompilieren. Einer der bekanntesten Compiler ist PyPy, der ein JIT-Compiler ist. Jedoch unterstützt er nicht die neusten Python-Versionen. Aktuell unterstützt er Python 3.7.10. Dagegen ist die neuste Python-Version aktuell 3.9.10, welche vom CPython unterstützt wird. CPython ist die Referenzimplementierung von Python. Wenn Du Python von python.org verwendest, dann ist es CPython. CPython ist relativ langsam, weil es Python zwar im ersten Schritt schon kompiliert, aber nur in einen Bytecode, der dann interpretiert wird. Der bytecode ist nicht maschinennah und somit nicht so schnell ausführbar.

    PyPy kompiliert Python in einen maschinennäheren Code als CPython und deshalb ist PyPy auch viel schneller als CPython. Jedoch, wie schon gesagt, ist PyPy nicht die Referenzimplementierung von Python und dementsprechend werden die neusten Version von Python nicht unterstützt.
    Außerdem unterstützt PyPy manche Libraries für Python nicht oder schlecht, insbesondere wenn die Libraries teilweise in C programmiert wurden. Dies trifft insbesondere auf viele schnelle Libraries von Python zu, die dank C so schnell sind und oft mit Cython entwickelt wurden. Wenn Dich Cython interessiert, lies bei cython.org.
    Cython und CPython sind zwei unterschiedliche Dinge, auch wenn sie vom Namen her ähnlich klingen.

    Also es gibt den Compiler PyPy für Python, aber er ist eingeschränkt, weil er nicht alle Python-Versionen und nicht alle Libraries unterstützt. Es können diverse Kompatibilitätsprobleme auftreten.

    Bei Julia ist halt der Just-Ahead-Of-Time-Compiler der Standard und deshalb ist Julia bei der Programmausführung schnell. Bei Python ist CPython der Standard, der halt bei der Programmausführung langsam ist, weil er Bytecode interpretiert.
    Das bedeutet aber nicht, dass Python immer langsamer als Julia ist. Es hängt vom Anwendungszweck ab. Wenn ich ad-hoc-Datenanalyse mache und dabei unterschiedliche Libraries ausprobiere und den Prozess oft beende und neu starte, verwende ich lieber Python, weil der Just-Ahead-Of-Time-Compiler von Julia bei jedem neuen Starten des Julia-Prozesses mein Programm kompilieren muss und das benötigt viel Zeit.

    Ich möchte nicht behaupten, dass Julia besser als Python oder Python besser als Julia ist. Aus meiner Sicht haben beide Programmiersprachen ihre Daseinsberechtigung.

    Schöne Grüße,
    Miroslav

  16. Re: Hat mal jemand den Benchmark getestet?

    Autor: fabiwanne 17.10.21 - 23:54

    >Erstunken und erlogen vielleicht nicht, aber dieser Thread beweist, wie abhängig Benchmarkergebnisse von der verwendeten Umgebung sind.
    > Relevant kann daher eigentlich immer nur das Verhältnis der Benchmarks zueinander
    Naja: Ich komme mit CPython auf den Faktor 10-25. Auf 2 unterschiedlichen Rechnern. Hier im Forum gab es die 20-30 hatten. Aber der Autor kommt auf den Faktor 100. (Ohne den Interpreter zu nennen)
    Dann gibt es nen Haufen leute, die etwa auf die gleiche 1 kommen, weil sie nicht CPython sondern pypi genommen haben. Schreibe ich nach Cython um bin ich sogar schneller als das Julia-Programm.
    Selbst wenn der Autor ohne es zu nennen absichtlich den langsamsten Interpreter genommen hat, ist da halt ein extremer Unterschied der sich so einfach nicht erklären lässt.
    Dazu kommt, dass das Benchmark offensichtlich absichtlich unfair war:
    Beim Python-Programm, wird die Interpretierzeit mit gerechnet. Beim Julia-Programm nicht.
    Das Python Programm, ist mit DOS-Zeilenumbrüchen geschrieben (die Python ausbremsen) das Julia-Programm nicht. Python wird interpretiert Julia compiled...

  17. Re: Hat mal jemand den Benchmark getestet?

    Autor: fabiwanne 18.10.21 - 00:01

    > werden die neusten Version von Python nicht unterstützt.
    Julia gibt es noch gar nicht in der Version 3. Die 30 Jahre Entwicklungszeit von denen du unbedingt auch die letzten paar Monate mitnehmen willst, kann Julia nicht im Ansatz vorweisen. Klarer Punkt für pypy.
    > Außerdem unterstützt PyPy manche Libraries für Python nicht oder schlecht
    Trotzdem ein Vielfaches von dem, was es für Julia gibt. Auch das ist ein klarer Punkt für Pypy
    > Referenzimplementierung von Python
    Und C hat gar keine Referenzimplementirung. Die für MP3 ist absolut scheiße. Ist deswegen MP3 absolut scheiße und C unvergleichbar? Das ist doch Humbug.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. SAP-ABAP-Entwickler (m/w/d) SAP PP und PP/DS (APO) - Produktionsplanung und Supply Chain
    MTU Aero Engines AG, München
  2. Anwendungsberater / Experte (m/w/d) für M365
    Mainova AG, Frankfurt am Main
  3. Firmware-Entwickler / Device-Integration Software Engineer (m/w/d)
    PTW FREIBURG Physikalisch-Technische Werkstätten Dr. Pychlau GmbH, Freiburg im Breisgau
  4. (Junior) Integration Developer (m/w/d)
    Frankfurter Allgemeine Zeitung GmbH (F.A.Z.), Frankfurt am Main

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. 16,99€ (Bestpreis)
  2. (u.a. Cyberpunk 2077 16,99€)
  3. 189,90€ (Bestpreis)
  4. 79,99€ (Bestpreis)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Digitale Souveränität: Die gefährliche Idee des Schlandnet neu aufgelegt
Digitale Souveränität
Die gefährliche Idee des Schlandnet neu aufgelegt

Mit dem Schlagwort Digitale Souveränität gehen Provider nun gegen Apples Private Relay vor. Das Internet Chinas sollte hierzulande aber kein Vorbild sein.
Ein IMHO von Sebastian Grüner und Moritz Tremmel

  1. Lieferengpässe Ist es moralisch okay, eine PS5 auf Ebay zu kaufen?
  2. Samsung Falt-Smartphones sind noch nichts für den Massenmarkt
  3. Corona Der digitale Impfpass ist Security-Theater mit Ansage

PSD2: Open Banking wird unsicherer und unübersichtlicher
PSD2
Open Banking wird unsicherer und unübersichtlicher

Das Buzzword Open Banking sorgt für Goldgräberstimmung in der Finanzbranche. Doch für die Kunden entstehen dabei etliche Probleme.
Eine Analyse von Erik Bärwaldt


    Aus dem Verlag: Golem-PC mit Geforce RTX 3060 Ti und Core i5-12400
    Aus dem Verlag
    Golem-PC mit Geforce RTX 3060 Ti und Core i5-12400

    Sechs flotte CPU-Kerne dank Alder Lake und eine schnelle Raytracing-Grafikkarte: Der Golem Allround Plus v2 liefert eine hohe Leistung.

    1. Aus dem Verlag Golem-PC mit Radeon RX 6900 XT und Core i7-12700K
    2. Aus dem Verlag Golem-PC mit Geforce RTX 3080 und Core i9-12900K
    3. Aus dem Verlag Golem-PC mit Geforce RTX 3070 und Core i5-12600KF