1. Foren
  2. Kommentare
  3. Software-Entwicklung-Forum
  4. Alle Kommentare zum Artikel
  5. › Programmierung…

Relevanz

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

Neues Thema


  1. Relevanz

    Autor: slax 13.05.22 - 11:35

    Ich benutze privat wie beruflich python.
    Performancerelevante Teilprobleme werden in einer kompilierten Sprache erstellt.
    Somit gibt es für mich keine Performanceprobleme mit python.
    Welche Szenarien gibt es?

  2. Re: Relevanz

    Autor: ralfh 13.05.22 - 11:52

    Die Antwort ist die gleiche, wie der Grund warum es PHP-GTK gibt. Der Bauer isst nur, was er kennt.

  3. Re: Relevanz

    Autor: katze_sonne 13.05.22 - 11:53

    slax schrieb:
    --------------------------------------------------------------------------------
    > Ich benutze privat wie beruflich python.
    > Performancerelevante Teilprobleme werden in einer kompilierten Sprache
    > erstellt.
    > Somit gibt es für mich keine Performanceprobleme mit python.
    > Welche Szenarien gibt es?

    Wenn du wirklich beruflich programmierst, solltest du wissen, wofür Threads gut sind. Nicht jedes Teilproblem ist es wert, loszurennen und komplilierten Code zu schreiben (die Programmiersprache muss man ja auch erstmal können) und dann den Aufwand zu betreiben, den Code in Python zu integrieren.

    Im Prinzip sagst du: Du hast kein Problem mit Performance in Python, weil du bei sowas Python nicht nutzt, weil es ein Problem mit der Performance gibt. Merkst du?

  4. Re: Relevanz

    Autor: ashahaghdsa 13.05.22 - 11:55

    *edit* Ich glaube das war nicht ganz richtig.



    1 mal bearbeitet, zuletzt am 13.05.22 11:57 durch ashahaghdsa.

  5. Re: Relevanz

    Autor: Proctrap 13.05.22 - 11:57

    Weil es ein Bruch ist und je nach Aufgabe ein sehr Großer jedes mal native Aufrufe zu machen.

    Klar ist python auch singlethreaded nicht besonders schnell, aber es wäre doch toll wenn man sogenannte peinlich parallelen Programme direkt mit Threads umsetzen könnte. Aktuell ist der Hack dafür einfach neue Python-Intanzen zu spawnen und die Parameter hin und her zu schicken, denn dann gibt es keinen GIL. Das wäre also schon mal weg.

    Und wenn man dann tatsächlich so viel Notwendigkeit für Performance hat dass man mehr singlethreaded perfomance will, dann kann man das nativ schreiben. (Es gibt allerdings einige sehr fähige python -> "c" -> nativ transpiler, auch hier lohnt es sich wenn man das in python vorher testen kann.)

    TLDR: Nur weil es threads nutzen soll die auch für echte Berechnungen genutzt werden (und nicht als IO handler), heißt es nicht dass man gleich wieder C-Bindings auspacken will und alle seine Daten hin und her serialisieren.

  6. Re: Relevanz

    Autor: Proctrap 13.05.22 - 11:58

    die nächste stufe wäre wir schaffen threads überall außer C ab, C darf dass dann übernehmen..

    Java hatte auch sicherlich threads bevor es so extrem schnell geworden ist, wie es heute üblich ist. Nur da war man sicherlich froh nicht mit threading bis dahin gewartet zu haben.

  7. Re: Relevanz

    Autor: slax 13.05.22 - 11:59

    Die Lücke zu kompilierten Sprachen ist so groß, dass es sich aus meiner Sicht nicht lohnt am GIL anzusetzen.

    Das binding an C++ ist übrigens ziemlich easy. Und mit einer Programmiersprache kommt man im Jahr 2022 sowieso nicht mehr weit.

  8. Re: Relevanz

    Autor: LH 13.05.22 - 12:04

    katze_sonne schrieb:
    --------------------------------------------------------------------------------
    > Im Prinzip sagst du: Du hast kein Problem mit Performance in Python, weil
    > du bei sowas Python nicht nutzt, weil es ein Problem mit der Performance
    > gibt. Merkst du?

    Auch wenn ich nicht der angesprochene bin: Aber was ich bemerke ist der Umstand, dass du wohl glaubst, dass der GIL das einzige Problem in Bezug auf Pythons Performance ist. Dem ist aber nicht so.

  9. Re: Relevanz

    Autor: rslz 13.05.22 - 12:05

    slax schrieb:
    --------------------------------------------------------------------------------
    > Ich benutze privat wie beruflich python.
    > Performancerelevante Teilprobleme werden in einer kompilierten Sprache
    > erstellt.
    > Somit gibt es für mich keine Performanceprobleme mit python.
    > Welche Szenarien gibt es?

    Ein Beispiel mit dem ich persönlich zu tun habe ist explorative Datenanalyse mit Pandas. Das transformieren von großen DataFrames ist sehr langsam, da single-threaded. Notgedrungen muss man bei größeren Tabellen auf das Drittprojekte wie modin.pandas ausweichen, die die Parallelisierung durch multiprocessing lösen.

  10. Re: Relevanz

    Autor: ralfh 13.05.22 - 12:07

    Das ist doch exakt der Punkt vom TS. Dann ist Python vermutlich die falsche Programmiersprache für dich.

  11. Re: Relevanz

    Autor: katze_sonne 13.05.22 - 12:37

    LH schrieb:
    --------------------------------------------------------------------------------
    > katze_sonne schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Im Prinzip sagst du: Du hast kein Problem mit Performance in Python,
    > weil
    > > du bei sowas Python nicht nutzt, weil es ein Problem mit der Performance
    > > gibt. Merkst du?
    >
    > Auch wenn ich nicht der angesprochene bin: Aber was ich bemerke ist der
    > Umstand, dass du wohl glaubst, dass der GIL das einzige Problem in Bezug
    > auf Pythons Performance ist. Dem ist aber nicht so.

    Nein, natürlich nicht. Es ging mir rein um Nebenläufigkeit, die in Python nunmal aktuell nur per Multiprocessing und nicht per Multithreading möglich ist. Am Ende kann man per Multithreading in Python einen CPU-Kern auslasten und nicht mehr. Das ist verdammt unschön und nicht mehr zeitgemäß in Zeiten, wo es immer mehr Kerne gibt.

    Dass Python auch sonst nicht unbedingt "die schnellste Sprache" ist, ist mir bewusst. Dynamic typing usw. sind natürlich ein riesiger Overhead. Python als Sprache ist nicht dafür optimiert, besonders effizient interpretiert werden zu können. Aber hey: Egal. In den allermeisten Fällen ist das auch gar nicht notwendig und Python schlichtweg schnell genug. Wenn man nämlich Pandas, NumPy und Co. verwendet, kann man viele tatsächlich rechenintensive Operationen halt auch auf nativen Code auslagern und ist trotzdem weiterhin in Python unterwegs und muss keine Zeile C anfassen. Ich kann C (konnte C? Schon lange nicht mehr angefasst), aber muss sagen, ich muss jetzt nicht unbedingt zurück. Und wenn ich der Meinung wäre, einen Programmteil in C statt in Python implementieren zu müssen, würde ich das auch machen. Hatte den Fall bisher halt nur nicht (außer bei Verwendung einer bestehenden C-Library). Ist je nach App halt seltener als viele das Darstellen. Die meisten Programme führen halt nur ein bisschen Logik aus, aber haben selten wirklich rechenintensive Tasks, die es rechtfertigen würden, den Teil in C zu implementieren.

  12. Re: Relevanz

    Autor: katze_sonne 13.05.22 - 12:39

    Proctrap schrieb:
    --------------------------------------------------------------------------------
    > Und wenn man dann tatsächlich so viel Notwendigkeit für Performance hat
    > dass man mehr singlethreaded perfomance will, dann kann man das nativ
    > schreiben. (Es gibt allerdings einige sehr fähige python -> "c" -> nativ
    > transpiler, auch hier lohnt es sich wenn man das in python vorher testen
    > kann.)

    Stichwort Cython. Haben wir damals mal im Studium mit rumgespielt und ein paar Performance-Vergleiche gemacht. Damit kann man tatsächlich einiges rausholen. Ist aber schon viel zu lange her, als das ich mich noch an genaue Ergebnisse erinnern könnte :)

    > TLDR: Nur weil es threads nutzen soll die auch für echte Berechnungen
    > genutzt werden (und nicht als IO handler), heißt es nicht dass man gleich
    > wieder C-Bindings auspacken will und alle seine Daten hin und her
    > serialisieren.

    Genau!

  13. Re: Relevanz

    Autor: Schattenwerk 13.05.22 - 12:40

    slax schrieb:
    --------------------------------------------------------------------------------
    > Ich benutze privat wie beruflich python.
    > Performancerelevante Teilprobleme werden in einer kompilierten Sprache
    > erstellt.
    > Somit gibt es für mich keine Performanceprobleme mit python.

    Die Logik ist immer wieder zuckersüß.

    Alternativ könnte man genau so sagen: Das ist das Paradebeispiel weswegen der GIL in Python weg muss, da es bis zu diesem Zeitpunkt genau die richtige Sprache war.

  14. Re: Relevanz

    Autor: katze_sonne 13.05.22 - 12:41

    slax schrieb:
    --------------------------------------------------------------------------------
    > Die Lücke zu kompilierten Sprachen ist so groß, dass es sich aus meiner
    > Sicht nicht lohnt am GIL anzusetzen.
    >
    > Das binding an C++ ist übrigens ziemlich easy. Und mit einer
    > Programmiersprache kommt man im Jahr 2022 sowieso nicht mehr weit.

    Schalte golem mal auf die Baumansicht - du hast dir selber geantwortet. So weiß niemand, auf den du jetzt wirklich geantwortet hast.

    Alles in allem klingt deine Einstellung nach "eigentlich könnte man Python auch direkt abschaffen".

  15. Re: Relevanz

    Autor: katze_sonne 13.05.22 - 12:46

    ralfh schrieb:
    --------------------------------------------------------------------------------
    > Das ist doch exakt der Punkt vom TS. Dann ist Python vermutlich die falsche
    > Programmiersprache für dich.

    Viel Spaß, wenn du das Handling solcher Datenstrukturen in C implementieren willst. Es fehlen die Libraries, die sowas einfach zugänglich machen und wenn du schon mal mit Pandas gearbeitet hättest, wüsstest du, dass es durchaus Gründe gibt, damit in Python zu arbeiten.

    Wenn die Entfernung des GIL das Problem lösen würde, wäre das sogar Argument gegen OP. Weil es komplett schwachsinnig ist, dafür auf ne andere Programmiersprache zu wechseln, wenn man das viel effizienter in Python runtercoden kann. Lange nicht jedes Projekt wird in Production genutzt und hat viele Ausführungen. Oft sind das Simulationen o.ä., die oft nur ein paar Mal wirklich ausgeführt werden. Da ist langes Warten langweilig - aber das in C zu coden dauert fünfmal so lange wie man auf die Ausführung länger warten muss.

  16. Re: Relevanz

    Autor: slax 13.05.22 - 13:09

    katze_sonne schrieb:
    --------------------------------------------------------------------------------
    > Alles in allem klingt deine Einstellung nach "eigentlich könnte man Python
    > auch direkt abschaffen".

    Nö python ist ne tolle Sprache und ich benutze sie gerne und viele Sachen gehen ganz leicht. Aber Python ist jetzt 30 Jahre alt, da ist eine Sprache so weit abgehangen, dass man keine großen Performancesprünge erwarten kann.
    Zumal der GIL ja nur ein Problem darstellt.

  17. Re: Relevanz

    Autor: Schattenwerk 13.05.22 - 14:19

    Was hat die Sprachspezifikation mit dem Interpreter oder Compiler zutun?

  18. Re: Relevanz

    Autor: Proctrap 13.05.22 - 14:31

    Du verschätzt dich damit glücklicherweise erheblich, um es mal mit Guido Van Rossums Worten zu sagen: der python interpreter ist stupide einfach und optimiert nicht*.

    Es gibt da so einige Projekt, wie bspw https://rustpython.github.io/ die hier noch viel Performance heraus holen können. Ich sag mal ganz platt: solange der GIL da war, und die Frameworks alle sync + singlethreaded, gab es wenig Anreiz hier viel zu ändern. Vor allem solange man dadurch die Convenience von Python mit Geschwindigkeit tauschen musste, dafür gibts genug andere sprachen (rust,go,nim,java,c) die einem das bieten.

    * ob das noch so 100% stimmt sei mal dahin gestellt

  19. Re: Relevanz

    Autor: LH 13.05.22 - 14:38

    Schattenwerk schrieb:
    --------------------------------------------------------------------------------
    > Was hat die Sprachspezifikation mit dem Interpreter oder Compiler zutun?

    Nicht sonderlich viel. Aber die Standardlib schon.

  20. Re: Relevanz

    Autor: Proctrap 13.05.22 - 14:44

    katze_sonne schrieb:
    --------------------------------------------------------------------------------
    > wenn du schon mal mit Pandas gearbeitet hättest, wüsstest du, dass es durchaus Gründe gibt, damit in Python zu arbeiten.

    Ich denke das Stichwort ist rapid Prototyping, du wirst hier mit Python viel schneller die eigentliche Logik umsetzen können für die du gerade bezahlt wirst, statt dich mit C-Probleme, Bindings und Serialisierung zu beschäftigen. Nur wenn python dann zu langsam ist um die Simulation durch zu testen, wird es wieder nutzlos.

    Nutze python nur für one-off scripts, finde async in python sehr "schwierig" und code meistens in Rust. Aber ich kann das hier einfach keinem absprechen wie einfach es ist damit rapid Prototyping zu betreiben und wie mächtig gerade die ML, Science und Number libs sind. Und sollte Python mal echt threaded werden, gibt es einen Grund mehr es zu verwenden.

  1. Thema
  1. 1
  2. 2

Neues Thema


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. Senior Problemmanager Automotive - Infotainment / Connectivity (m/w/d)
    Bertrandt Ingenieurbüro GmbH München, München
  2. Bachelor of Science - Informatik (w/m/d)
    Karlsruher Institut für Technologie (KIT) Campus Nord, Eggenstein-Leopoldshafen
  3. Softwareentwickler Angular (w/m/d)
    freenet DLS GmbH, Büdelsdorf
  4. Mitarbeiter* Technischer Support / After Sales
    LISTAN GmbH, Glinde

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. 499,99€
  2. (u. a. Ryzen 5 5600X 358,03€)
  3. (u. a. Ryzen 7 5800X für 469€)


Haben wir etwas übersehen?

E-Mail an news@golem.de