Schleifeninhalte auf mehrere CPUs zu verteilen
Am 06.04.2016 um 21:06 schrieb Dr. Volker Jaenisch:
Servus Thomas!
...
Ich mache seit mehr als 20 Jahren Performance-Optimierung von Code in Python.
Das genannte Beispiel
connection = get_db_connection() for item in my_iterator: push_item_to_db(item, connection)und der Vorschlag wegen der Rechenzeit für das teure Öffnen der DB-Connection die Syntax des Interpreters ändern zu wollen ist absurd. Es mag ja wenige akademische Spezialfälle geben in denen so etwas evtl. weniger Rechenzeit benötigt. In "real world" Szenarien hat man sowieso nicht eine DB-Verbindung sondern einen Pool von DB-Verbindungen, da wirkliche Performance heutzutage nur mit Parallelisierung erreichbar ist. Es ist also viel interessanter eine Schleife und deren Inhalte auf mehrere CPUs zu verteilen als Corner-Cases am Anfang der Schleife zu optimieren.
Du hast Recht. Die Schleifeninhalte auf mehrere CPUs zu verteilen ist eine geniale Sache.
zwei Fragen:
1. Wie wünscht du dir die Syntax für Otto-Normal-Programmieren?
2. Wie könnte die Implementierung aussehen?
Gruß, Thomas
Servus Thomas!
Am 07.04.2016 um 15:48 schrieb Thomas Güttler:
Wie wünscht du dir die Syntax für Otto-Normal-Programmieren?
Wie könnte die Implementierung aussehen?
Ich gehe mal davon aus, dass Du nicht die Parallelisierung meinst. Die bekommst Du z.B. mit PyPy http://doc.pypy.org/en/latest/stm.html#transaction-transactionqueue und müssen daher nicht neu erfunden werden oder die Syntax erweitert werden.
Wenn Du also Deine Idee mit einer Syntax-Erweiterung für die For-Schleife meinst: * Jede Syntax-Erweiterung erhöht für z.B. das PyPy-Projekt den Aufwand Optimierungen für Python zu programmieren. Jede Erweiterung hat einen Preis und es sollte weise abgewogen werden ob die Community bereit ist diesen Preis zu entrichten. Denn wie Sven schon richtig anmerkte ist die Semantik wichtig für die Optimierung. Von daher sollte man wenn man Optimierungen für Python machen möchte, zunächst die Leute fragen, welche sich damit wirklich befassen, oder? Damit meine ich nicht mich, sondern die PyPy, Jython, Cython Leute. * Jede Syntax-Erweiterung birgt die Gefahr die Orthogonalität der Sprache aufzuweichen. Auch Python schrammt mit den Inline-Schleifen an einer Orthogonalitäts-Verletzung. * Jede Syntax-Erweiterung schafft neue Probleme und ist gerade für den Anfänger eine zusätzliche Hürde. Wie schon Stefan Schwarzer anmerkte hat Python jetzt schon einige solche nicht intuitiven Pitfalls. Seiner Liste mag ich Try, Except, Else anfügen, welches nicht so arbeitet wie man intuitiv erwartet.
Daher spreche ich mich gegen jede Syntax-Erweiterung aus, für die es nicht einen wirklich wichtigen Grund gibt. Corner-Cases wie Du sie anführst sind kein solch wichtiger Grund und das ist nicht nur meine Meinung :
""" Special cases aren't special enough to break the rules. """
https://www.python.org/dev/peps/pep-0020/
Beste Grüße
Volker
Am 07.04.2016 um 17:16 schrieb Dr. Volker Jaenisch:
Servus Thomas!
Am 07.04.2016 um 15:48 schrieb Thomas Güttler:
Wie wünscht du dir die Syntax für Otto-Normal-Programmieren?
Wie könnte die Implementierung aussehen?
Ich gehe mal davon aus, dass Du nicht die Parallelisierung meinst. Die bekommst Du z.B. mit PyPy http://doc.pypy.org/en/latest/stm.html#transaction-transactionqueue und müssen daher nicht neu erfunden werden oder die Syntax erweitert werden.
... halt. Die Idee Schleifeninhalte auf mehrere CPUs zu verteilen war nicht von mir. Das war deine Idee. Mich interessiert das was du damit meinst.
Wie soll das konkret aussehen?
Gruß, Thomas
Servus Thomas!
Am 07.04.2016 um 17:25 schrieb Thomas Güttler:
gehe mal davon aus, dass Du nicht die Parallelisierung meinst. Die
bekommst Du z.B. mit PyPy http://doc.pypy.org/en/latest/stm.html#transaction-transactionqueue und müssen daher nicht neu erfunden werden oder die Syntax erweitert werden.
... halt. Die Idee Schleifeninhalte auf mehrere CPUs zu verteilen war nicht von mir. Das war deine Idee. Mich interessiert das was du damit meinst.
Wie soll das konkret aussehen?
Siehe link.
Wenn PyPy STM produktionstauglich ist, wird es möglich sein Schleifen (welche gewisse Kriterien erfüllen) auf mehrere parallel CPUs zu verteilen. Dann interessieren solceh Corner-Cases wie Du sie lösen willst niemanden mehr. Daher mein Vorschlag, lieber die Energie in solche Optimierungs-Projekte zu stecken, die wirklich revolutionär sind.
Beste Grüße
Volker
Am 07.04.2016 um 17:29 schrieb Dr. Volker Jaenisch:
Servus Thomas!
Am 07.04.2016 um 17:25 schrieb Thomas Güttler:
gehe mal davon aus, dass Du nicht die Parallelisierung meinst. Die
bekommst Du z.B. mit PyPy http://doc.pypy.org/en/latest/stm.html#transaction-transactionqueue und müssen daher nicht neu erfunden werden oder die Syntax erweitert werden.
... halt. Die Idee Schleifeninhalte auf mehrere CPUs zu verteilen war nicht von mir. Das war deine Idee. Mich interessiert das was du damit meinst.
Wie soll das konkret aussehen?
Siehe link.
Wenn PyPy STM produktionstauglich ist, wird es möglich sein Schleifen (welche gewisse Kriterien erfüllen) auf mehrere parallel CPUs zu verteilen. Dann interessieren solceh Corner-Cases wie Du sie lösen willst niemanden mehr. Daher mein Vorschlag, lieber die Energie in solche Optimierungs-Projekte zu stecken, die wirklich revolutionär sind.
"Software Transactional Memory" .. klingt interessant.
Mir geht es nicht wirklich um die Optimierung.
Mir geht es um eine klare Syntax.
Die genannten Fälle (on-empty, on-break, pre-first) bei Schleifen gibt es immer wieder.
Dieser Spruch aus Zen-of-Python gefällt mir:
There should be one-- and preferably only one --obvious way to do it.
Mir geht es um sofort verständlichen Code.
Gruß, Thomas
participants (2)
-
Dr. Volker Jaenisch -
Thomas Güttler