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

Julia vs. Python

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. Julia vs. Python

    Autor: glasen77 13.10.21 - 13:01

    Ja, Julia ist von der Syntax relativ ähnlich zu Python. Das Problem ist nur, dass Julia erst richtig schnell wird, wenn man die dynamische Typisierung wegwirft und alle Variablen statisch typisiert. Zusätzlich sollte man sich angewöhnen kleine Funktions/Methodenblöcke zu benutzen.

    Beides führt dazu, dass der Julia-Compiler den Code sehr stark optimieren kann. Erst dann kommt Julia an die Geschwindigkeit von C heran.

  2. Re: Julia vs. Python

    Autor: noname4you 13.10.21 - 13:24

    Zudem hinkt der Vergleich. Zeige mir auch nur einen einzigen "Data Scientist", der nicht mit numpy und numba arbeiten würde. Auch mit numba bewegt man sich auf C-Niveau in Sachen Geschwindigkeit. Und meist braucht man da auch nur ein @jit über die Funktion dekorieren. Der Autor reitet ein totes Pferd, wenn er sich über Geschwindigkeitsprobleme von Python auslässt. Wäre das nicht schon längst erledigt, wäre Python gerade in diesem Bereich nie so populär geworden.

  3. Re: Julia vs. Python

    Autor: Normaloit 13.10.21 - 13:39

    Also Julia klingt auf jeden Fall schöner 🥳

  4. Re: Julia vs. Python

    Autor: Dino13 13.10.21 - 13:55

    glasen77 schrieb:
    --------------------------------------------------------------------------------
    > Ja, Julia ist von der Syntax relativ ähnlich zu Python. Das Problem ist
    > nur, dass Julia erst richtig schnell wird, wenn man die dynamische
    > Typisierung wegwirft und alle Variablen statisch typisiert. Zusätzlich
    > sollte man sich angewöhnen kleine Funktions/Methodenblöcke zu benutzen.
    >
    > Beides führt dazu, dass der Julia-Compiler den Code sehr stark optimieren
    > kann. Erst dann kommt Julia an die Geschwindigkeit von C heran.

    Kleinere Methodenblöcke hört sich ja eigentlich sehr gut an, große Blöcke gibt es eh nur bei Faulheit oder schlechtem Design.

  5. Re: Julia vs. Python

    Autor: franzropen 13.10.21 - 13:59

    Anscheinend ist Julia aber dennoch schneller als Python + Numba
    https://blakeaw.github.io/2019-09-20-numba-vs-julia/
    Und selbst wenn nicht, was ist mit den Fällen in denen numba nicht verwendet werden kann, weil es z.B. um String-Operationen geht?

  6. Re: Julia vs. Python

    Autor: Trockenobst 13.10.21 - 14:00

    glasen77 schrieb:
    --------------------------------------------------------------------------------
    > Beides führt dazu, dass der Julia-Compiler den Code sehr stark optimieren
    > kann. Erst dann kommt Julia an die Geschwindigkeit von C heran.

    Das ist aber auch das Problem von Julia. Die Compiler Code/Generierung/Optimierung ist ein schwieriges Geschäft, CPUs ändern sich ständig. Ich finde Julia angenehm und ich würde es gerne statt Go für systemnahe Entwicklung nutzen. Aber die API gibt das noch nicht her. Die Optimierungen des Compilers stehen noch am Anfang, die Executable Größe etwa, Dead Code Optimierungen etc. Bei meinem letzten Einsatzversuch unter Windows gab es Instabilitäten.
    Das wirkt alles wie ein ewig laufender Beta. Auch ein Grund warum ich Kotlin momentan zur Seite gelegt habe.

  7. Re: Julia vs. Python

    Autor: Johannes321 13.10.21 - 14:30

    Es gibt ja auch noch mehr Projekte die Python Code mit type annotations zu C übersetzen. (Mypyc, Cython)

    Eine dynamisch typisierte Sprache teilweise zu kompilieren ist natürlich nicht ganz trivial, aber Python und Julia kochen hier mit genau dem gleichen Wasser. Dementsprechend ist auch eine ähnliche Performance zu erwarten.

    Dafür ist Python eine viel breiter einsetzbare Programmiersprache und es gibt viel mehr Pakete.

    Wo waren die Vorteile von Julia also noch mal?

  8. Re: Julia vs. Python

    Autor: lunarix 13.10.21 - 14:41

    Johannes321 schrieb:
    --------------------------------------------------------------------------------
    > Es gibt ja auch noch mehr Projekte die Python Code mit type annotations zu
    > C übersetzen. (Mypyc, Cython)
    >
    > Eine dynamisch typisierte Sprache teilweise zu kompilieren ist natürlich
    > nicht ganz trivial, aber Python und Julia kochen hier mit genau dem
    > gleichen Wasser. Dementsprechend ist auch eine ähnliche Performance zu
    > erwarten.

    Äh - naja, python gilt ja generell als eher langsame Sprache, davon abgesehen ist Julia deutlich schneller. Warum soll eine ähnliche Performance zu erwarten sein?

  9. Re: Julia vs. Python

    Autor: Johannes321 13.10.21 - 14:44

    Wenn du in Julia keine (statische) Typisierung verwendest ist es auch nicht schneller als Python.

    Wenn du statische Typisierung verwendest sind beide Sprachen ähnlich schnell, dann kannst du nämlich auch die Compiler für Python verwenden.

  10. Re: Julia vs. Python

    Autor: Johannes321 13.10.21 - 14:49

    Der JIT für Python selbst (ohne Zusatzprojekte wie Numba, Cython oder Mypyc) wurde ja auch schon angerissen: https://www.infoworld.com/article/3618691/pythons-creators-unveil-speedup-plans-for-python.html

  11. Re: Julia vs. Python

    Autor: Schattenwerk 13.10.21 - 15:09

    Naja, numba wurde mir auch vollmundig verkauft. Habe es dann mal getestet.

    Sobald man jedoch den Fehler macht und seinen Code in Klassen packt, dann kann man numba entweder vergessen oder sich auf ganz viel Arbeit einstellen, da dann aufwändige Kommentare für den Jit-Compiler geschrieben werden müssen.

    Also habe ich Code in eine Funktion gepackt, damit diese ohne viel Aufwand für numba genutzt werden kann.

    War auch nur bedingt hilfreich. Zwar war diese Funktion am Ende extrem schnell, so wie man es erwartet, jedoch hat der Transfer der Daten zwischen Python und C diesen Vorteil wieder anteilig sehr hoch zerstört.

    Nun bin ich jedoch auch keiner, der nur dumme Skripte schreibt, welche einmal einen linearen Strang mit vielen Schleifen etc. durchlaufen. Auch bin ich kein Freund davon, dass ich bei geteilten Parametern diese entweder immer allen Funktionen durchgeben zu müssen oder überall "global" zu nutzen. Das wäre bei meinem Anwendungsfall leider - für meinen Geschmack - zu viel schlechter Coding-Style im Tausch gegen Performance. Hat für mich auch einen sehr harten Vipe von C, wenn man nur noch Funktionen nutzt ;)

    Wenn numba es irgendwie besser hinbekommen würde, dass man Klassen auch nutzen könnte, wäre ich sofort dabei. Derzeit für mich jedoch eher eine Enttäuschung.

  12. Re: Julia vs. Python

    Autor: Johannes321 13.10.21 - 15:37

    Natürlich wird da noch viel entwickelt, Juilia ist ja auch nicht problemfrei.

    Ich hab aber mal einen kurzen Test mit mypyc gemacht. Die Problemstellung ist trivial und sinnfrei in eine Klasse gemurkst, aber es funktioniert mit mypyc ziemlich gut:

    class Fib:
    def __init__(self, number:int):
    self._number=number

    def value(self)->int:

    if(self._number==0):
    return 0
    elif(self._number==1):
    return 1
    else:
    self._n1=Fib(self._number-1)
    self._n2=Fib(self._number-2)
    return self._n1.value()+self._n2.value()

    print(Fib(27).value())
    [Kann man hier irgendwie Code sauber formatieren?]

    Zeit mit python 3.9: 1.77s
    Zeit mit mypyc: 0.19s

    Ist fast ein Faktor 10 an Zugewinn, obwohl das Problem eher schwer zu optimieren ist. (Ein JIT muss dafür Annahmen über das Klassenlayout treffen, diese Annahmen sind unter Python immer ganz besonders schwierig.)



    1 mal bearbeitet, zuletzt am 13.10.21 15:37 durch Johannes321.

  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. IT-Mitarbeiter (m/w/d) mit Schwerpunkt IT-Sicherheit
    NMI Reutlingen, Reutlingen
  2. Technischer Consultant - IT (m/w/d)
    Diamant Software GmbH, Bielefeld
  3. Product Owner (m/w/d) Subscription Billing Cloud
    nexnet GmbH, Berlin
  4. Web-Entwickler (m/w/d)
    artvera GmbH & Co. KG, Berlin-Charlottenburg

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote


Haben wir etwas übersehen?

E-Mail an news@golem.de


Hybrides Arbeiten bei d.velop: Training für die Arbeitswelt von morgen
Hybrides Arbeiten bei d.velop
Training für die Arbeitswelt von morgen

Es gibt nur wenige Firmen, die ihren Mitarbeitern schon jetzt die Entscheidung Büro oder Homeoffice selbst überlassen. Ein Erfahrungsbericht der d.velop AG.
Von Peter Ilg

  1. Boston Consulting Drei Viertel der IT-Fachleute offen für Jobwechsel
  2. In eigener Sache Wo ITler am besten arbeiten
  3. IT-Arbeitsmarkt Wie viele Jobwechsel verträgt ein Lebenslauf?

Discovery Staffel 4: Star Trek mit viel zu viel Pathos
Discovery Staffel 4
Star Trek mit viel zu viel Pathos

Die ersten beiden Folgen der neuen Staffel von Star Trek Discovery bieten zwar interessante Story-Ansätze, gehen aber in teils unerträglichen Gefühlsduseleien unter. Achtung, Spoiler!
Eine Rezension von Tobias Költzsch

  1. Pluto TV Star Trek Discovery kommt doch schon nach Deutschland
  2. Star Trek Discovery kommt nicht mehr auf Netflix

Ada & Zangemann: Das IT-Märchen, das wir brauchen
Ada & Zangemann
Das IT-Märchen, das wir brauchen

Das frisch erschienene Märchenbuch Ada & Zangemann erklärt, was Software-Freiheit ist. Eine schöne Grundlage, um Kinder - aber auch Erwachsene - an IT-Probleme und das Basteln heranzuführen.
Eine Rezension von Sebastian Grüner

  1. Koalitionsvertrag Ampelkoalition will Open Source in Verwaltung bevorzugen
  2. Open Source OBS erzürnt über Markenverletzung durch Logitech-Tochter
  3. Jailbreak Weitgehende DMCA-Ausnahmen für Open Source