Re: [Python-de] select.epoll() vs async framework (PostgreSQL)
On 2018-01-16 10:38, Diez B. Roggisch <deets@web.de> wrote:
Sockets sind meiner Meinung nach ein viel besseres Abstraktionsniveau als meinen Quellcode überall mit diesem dämlichen async und await zu spicken.
Das einzige, was hier fehlt, wäre ein spezieller Typ von File-Deskriptor, der entsprechend in der Lage ist HTTP zu sprechen.
Du moechtest also einen HTTP-Server in den Kernel verlagern?
Gab es bei Linux schon.
Wo wir dabei sind, gleich noch ne RDBMS-engine?
War das nicht für Windows 2000 geplant? Strukturierte Files waren in den 70ern durchaus üblich. Unix war da mit seinem radikalen Minimalismus eher die Ausnahme.
*Kooperatives Multitasking ist einfach nur Schrott.* Ich habe mich neulich mit einem Mitt-Fünziger unterhalten, der asyncio in seinem neusten Projekt einsetzt, und habe ihn gefragt, wie er es findet und ob es sich irgendwie zu kooperativen Multitasking aus Mainframe-Zeiten (was bekanntlich aus der Mode gekommen ist) unterscheidet.
Er sagte folgendes:
naaa it’s the same thing .. like a loop u know .. marketing .. blah blah .. some technology went out from window .. and back from doors .. like something new *we call that progress* .. but is something like reinvent the wheel for sell something ;) ppl need “new” words, “new” languages .. to feel young :-)
“”” Alter Mann erklaert Technologie, die nach seiner eigenen Sturm-und-Drang-Phase entwickelt wurde, fuer ueberfluessig.
Eher umgekehrt. Alter Mann erkennt, dass die Technologie, die da als "neu entwickelt" angepriesen wird, schon in seiner Jugend nicht mehr neu war. hp -- _ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung: |_|_) | | Man feilt solange an seinen Text um, bis | | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr __/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
Hi, neben der Tatsache, daß ich die Umgangsformen auf dieser Liste immer wieder befremdlich finde, wundert es mich, wieviele Menschen scheinbar der Meinung sind, ihre kleine Welt wäre alles, was es da draußen gibt. Ja, ich finde async-Code auch nicht unbedingt schön. Aber das liegt auch im Problem begründet. Wenn ich die Funktionalität nutzen will, habe ich aber auch noch nichts eleganteres in Python gesehen. Ich mußte mal 80Mio eher kleine Files auf einer 64 Core Maschine mit dicker Leitung möglichst schnell von S3 runter laden. Mit der asyncio Version von botocore war das ziemlich wenig Code und kein Kollege kam auch nur annähernd an die Performance ran. Klar muß man asyncio dazu verstehen und vorher bißchen Doku lesen. ;-) In anderen Fällen bin ich SEHR großer Fan von ZeroMQ. Die Betonung liegt auf "anderen". Es hängt halt vom Anwendungsfall ab. Ich habe mir sagen lassen, daß es auch Menschen gibt, die mit "dickeren" Messagequeues gut fahren. Bei mir war das nie der Fall, was aber wohl an "meiner Welt" liegt. Deshalb sind die Produkte aber nicht automatisch scheiße. Und davon abgesehen ist auch die Entscheidung, ob man etwas selbst implementiert oder eine bestehende (neue hippe?) Lösung nimmt, nicht immer ganz soooo eindeutig. Ich bin großer Fan davon, immer den neuesten coolen Scheiß zu benutzen. Trotzdem weiß ich, daß es manchmal eine schlechte Idee ist. Nur um die Diskussion mal ein bißchen in die richtige Perspektive zu setzen! ;-) viele Grüße, Achim PS.: Um aber auch ein bißchen zu pauschalisieren: Die alten Typen, die alle neuen Technologien schon damals in den 80ern, 70ern, ... benutzt hatten, waren in meiner Welt bisher immer Klugscheißer, die zu faul waren, sich mit neuen Sachen zu beschäftigen.
On 16.01.2018 22:24, Achim Domma wrote:
In anderen Fällen bin ich SEHR großer Fan von ZeroMQ. Die Betonung liegt auf "anderen". Es hängt halt vom Anwendungsfall ab.
Ich hatte mich eine Weile, lange vor dem ganzen Tamtam um asyncio, mit ZeroMQ beschäftigt, um zu sehen, ob und wie wir es im produktiven Einsatz gebrauchen könnten. Leider ist es nie dazu gekommen. Wir bevorzugen eine einfache sowohl volative als auch persistente Job-Queue über PostgreSQL, damit kennen sich alle Entwickler bestens aus und man kommt einfach schneller ans gewünschte Ergebnis.
PS.: Um aber auch ein bißchen zu pauschalisieren: Die alten Typen, die alle neuen Technologien schon damals in den 80ern, 70ern, ... benutzt hatten, waren in meiner Welt bisher immer Klugscheißer, die zu faul waren, sich mit neuen Sachen zu beschäftigen.
Im Falle unseres italienischen Freundes hier, kann ich dem nicht so zustimmen. Wie gesagt, er setzt (mehr oder minder erfolgreich) asyncio ein. Das war auch der Grund meiner Nachfrage, ob es sich denn spürbar gegenüber dem "alten" kooperativen Multitasking verbessert hat.
Von meinem iPad gesendet
Am 16.01.2018 um 21:52 schrieb Peter J. Holzer <hjp-usenet3@hjp.at>:
On 2018-01-16 10:38, Diez B. Roggisch <deets@web.de> wrote:
Sockets sind meiner Meinung nach ein viel besseres Abstraktionsniveau als meinen Quellcode überall mit diesem dämlichen async und await zu spicken.
Das einzige, was hier fehlt, wäre ein spezieller Typ von File-Deskriptor, der entsprechend in der Lage ist HTTP zu sprechen.
Du moechtest also einen HTTP-Server in den Kernel verlagern?
Gab es bei Linux schon.
Und hat NGINX und Apache erfolgreich verdrängt wie wir jeden Tag sehen.
Wo wir dabei sind, gleich noch ne RDBMS-engine?
War das nicht für Windows 2000 geplant?
Weiß nicht genau was du meinst. Das nie erschienene WinFS für Longhorn? Das war jedenfalls eher eine Desktop-Suche wie Spotlight, und zumindest letzteres ist über Worker im Userspace implementiert.
Strukturierte Files waren in den 70ern durchaus üblich. Unix war da mit seinem radikalen Minimalismus eher die Ausnahme.
Haben die beliebige Abfragen und Aggregationen über ihre Felder erlaubt? Sonst finde ich den Vergleich etwas weit hergeholt.
*Kooperatives Multitasking ist einfach nur Schrott.* Ich habe mich neulich mit einem Mitt-Fünziger unterhalten, der asyncio in seinem neusten Projekt einsetzt, und habe ihn gefragt, wie er es findet und ob es sich irgendwie zu kooperativen Multitasking aus Mainframe-Zeiten (was bekanntlich aus der Mode gekommen ist) unterscheidet.
Er sagte folgendes:
naaa it’s the same thing .. like a loop u know .. marketing .. blah blah .. some technology went out from window .. and back from doors .. like something new *we call that progress* .. but is something like reinvent the wheel for sell something ;) ppl need “new” words, “new” languages .. to feel young :-)
“”” Alter Mann erklaert Technologie, die nach seiner eigenen Sturm-und-Drang-Phase entwickelt wurde, fuer ueberfluessig.
Eher umgekehrt. Alter Mann erkennt, dass die Technologie, die da als "neu entwickelt" angepriesen wird, schon in seiner Jugend nicht mehr neu war.
Wenn der alte Mann kooperatives Multitasking mit asynchroner Programmierung auf einem ansonsten immer noch präemptiven OS gleichsetzt, bleibe ich da eher bei meiner Sichtweise... Diez
hp
-- _ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung: |_|_) | | Man feilt solange an seinen Text um, bis | | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr __/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel _______________________________________________ python-de maillist - python-de@python.org https://mail.python.org/mailman/listinfo/python-de
On 16.01.2018 22:24, Diez B. Roggisch wrote:
Du moechtest also einen HTTP-Server in den Kernel verlagern?
Ich weiß nicht, ob ich das möchte. Ich möchte am liebsten mit Filedeskriptoren arbeiten. Die kann ich nämlich abholen und auf die kann ich draufschreiben, wenn ich es möchte. Wenn es dafür einen HTTP-Server im Kernel braucht, dann ist das halt so. Aber neben normalen Files hat sich das Web wohl leider durchgesetzt, auch wenn es viele immer noch nicht wahrhaben wollen. URLs dienen der Adressierung von Ressourcen und HTTP als Protokoll von Resourcen-Repräsentationen.
Wo wir dabei sind, gleich noch ne RDBMS-engine?
Hö? Entweder wir reden über verschiedene Dinge, aber ich kann PostgreSQL über einen UNIX-Socket ansprechen.
Wenn der alte Mann kooperatives Multitasking mit asynchroner Programmierung auf einem ansonsten immer noch präemptiven OS gleichsetzt, bleibe ich da eher bei meiner Sichtweise...
So richtig erklären, wo da jetzt der qualitative Gewinn ist, kannst du aber auch nicht. Kommt mir jedenfalls vor. Außer die üblichen Marketing-Begründungen (die auch beim reinrassigen kooperativen Multitasking ziehen), gehst du nicht wirklich auf die entscheidenden Punkte ein, die präemptives Multitasking zur dominierenden Technologie der letzten ?Dekade? gemacht haben: - Entwickler kann sich auf seine Domäne konzentrieren - Entwickler muss kein Betriebssystemler sein und Scheduling verstehen müssen - asyncio baut eine Parallelwelt auf, sieht aus wie eine fremde Programmiersprache - alle Bibliotheken, die IO tun, sind neu zu schreiben - Funktionen können nicht einfach mal gecallt werden, Loop muss selbst verwaltet werden - in Python: interaktiver Modus so gut wie unmöglich Sven
participants (4)
-
Achim Domma
-
Diez B. Roggisch
-
Peter J. Holzer
-
Sven R. Kunze