PyPy.js

[jens]

Vielleicht wird es durch "Webassembly" alles leichter:

...Webassembly (Wasm): ein portables, auf geringe Größe und kurze Ladezeiten optimiertes Binärformat samt Ausführungsmodell - ein Bytecode für das Web also.

-> http://www.golem.de/news/webassembly-br ... 14745.html

Wird auch schon diskutiert: https://github.com/pypyjs/pypyjs/issues/145


btw. Mit https://github.com/pypyjs/pypyjs.github ... 237a16a5e4 hab ich meinen "Packer" test code ein wenig aufgeräumt und einen richtigen Benchmark gemacht, der Markdown produziert.
pypy.vm.js + pypy.vm.js.mem mit allen Levels/Presets von zlib, bzip2 und lzma ist hier: https://gist.github.com/jedie/d650de636711aa786235



Eine andere Idee, ist noch das caching im localStorage, siehe: https://github.com/pypyjs/pypyjs.github.io/issues/8
Dabei wäre es vom Vorteil, wenn man vom Server komprimierte Dateien, statt http-gzip/deflate bekommt, weil man sie dann nicht per JS komprimieren müßte...



Eine weitere Idee bzw. Frage: Lohnt es sich die einzelnen Requests zusammen zu fassen? -> https://github.com/pypyjs/pypyjs.github.io/issues/7

Nicht nur pypy.vm.js + pypy.vm.js.mem sondern auch die späteren Requests die entstehen, wenn man python Module importiert... Denn z.B. ein "import platform" löst z.Z. 58 GET Requests aus

Sieht dann so aus:

[Kebap]

Vielleicht wird es durch "Webassembly" alles leichter. Wird auch schon diskutiert

Ich hab auch davon gehört. Klingt so, als wäre der Quellcode dann nicht mehr im Browser einsehbar? Das fände ich eher un-pythonisch ...

Ich weiß ja nicht, wie euch das geht, aber ich hoffe inständig, dass "WebAssembly" floppt. So doll wie möglich am besten. Verbrannte Erde wäre gut. So übel, am besten, dass nie wieder jemand was in die Richtung probiert.

ENDLICH sind wir weg von diesem Flash-Binärkack und von Binaries für irgendwelche speziellen Plattformen und haben Skriptsprachen für eine gemeinsame Plattform. Endlich kann man einfach Ctrl-U machen und sich angucken, was da passiert. Kaputte Skripte zur Not selber debuggen. Selbstgehackte DRM im Web ist endlich weg (abgesehen von diesem Chrome-Netflix-Zeugs).

Und was machen diese Schwachmaten da? Erfinden ein neues Binärformat fürs Web. Und sagen explizit an, dass das ein Compiler-Target sein soll. JA SUPER! Ich sage gleich mal an, dass es eine Industrie geben wird, die auf Basis davon DRM baut, die "Obfuscation"-Technologien verkaufen wird, und wir werden eine neue dunke Ära für geschlossenes Web einleuten. Und das alles so völlig ohne Not! Und dann werden wir wieder "works best in Internet Explorer" haben. Eine Frage der Zeit, bis Microsoft oder Apple spezielle proprietäre APIs für ihre "Web-Binaries" exportieren. DirectX für WebAssembly! Und am Ende haben wir dann ein verkapptes .NET für Arme im Browser. Hint: Hatten wir schon. Hieß Silverlight. Ist gefloppt.

[jens]

Ich hab auch davon gehört. Klingt so, als wäre der Quellcode dann nicht mehr im Browser einsehbar? Das fände ich eher un-pythonisch ...

Was PyPy.js anbelangt, bleibt es ja dabei, das Python Skripte ausgeführt werden. In diesem Fall ist es nur Einfach einen Python Interpreter in den Browser zu laden. Das ist alles...

Ich bin mir allerdings noch nicht ganz sicher, ob wasm es wirklich eine starke Beschleunigung sein wird. Denn die größe, des PyPy-Interpreter wird sich vermutlich nicht all zu stark ändern, wenn beide Varianten komprimiert zum Client kommen werden...
Aber natürlich fällt einiges an Umwandlung weg.

Was das ablösen von JavaScript im allgemeinen anbelangt: Las uns das lieber im separaten Thread diskutieren!

-> http://www.python-forum.de/viewtopic.php?f=5&t=36532

[jens]

Kurzer Zwischenstand...

Hab noch https://github.com/kripken/emscripten/issues/3589 eröffnet und dort generell das Kompressions-Thema vorgestellt. Dort sind quasi die aktuelle Erkenntnisse zum Thema gesammelt.


Mit https://github.com/jedie/pypyjs.github. ... a9dd641cdd läuft nun die erste Implementierung für https://github.com/pypyjs/pypyjs.github.io/issues/7
Also das zusammenfassen von .py Dateien in einem Archiv.

z.Z. ist es so, das bei einem import jeweils eine .py Datei nacheinander per GET gezogen werden. Wenn man z.B. ein import platform macht, zieht das 58 GET Requests nach. (Siehe Bild oben, bei http://www.python-forum.de/viewtopic.ph ... 68#p278668 )


Ein "import platform" kann man aktuell direkt vergleichen:

• [1] http://jedie.github.io/pypyjs.github.io/editor.html - Run in 1.1sec.
• [2] http://pypyjs.org/editor.html - Run in 15sec.

Allerdings geht bei meiner Variante [1] nur ein "import platform", weil z.Z. nur die Datei "platform.zip" hoch geladen ist: https://github.com/jedie/pypyjs.github. ... s/download

Meine Variante [1] kann man eigentlich zwei Sachen sehen:

• Die Initialisierung ist schneller, weil "pypy.vm.js" und "pypy.vm.js.mem" zu "./download/pypyjs.zip" zusammen gefasst werden, siehe: https://github.com/pypyjs/pypyjs.github.io/issues/4
• "import platform" ist schneller, s. oben

Nun frage ich mich allerdings, welchen Unterschied es wohl machen wird, wenn man statt eine "platform.zip" eine "platform.json" erzeugen würde?!?
In diesem Fall würde man nicht die Server/Browser gzip Kompression umgehen (sofern eingeschaltet)... Das Parsen vom .json würde der Browser auch direkt unterstützen...

[jens]

Nun frage ich mich allerdings, welchen Unterschied es wohl machen wird, wenn man statt eine "platform.zip" eine "platform.json" erzeugen würde?!?
In diesem Fall würde man nicht die Server/Browser gzip Kompression umgehen (sofern eingeschaltet)... Das Parsen vom .json würde der Browser auch direkt unterstützen...

Wenn ich so näher darüber nachdenke...

Mit JSON würde man die Dateigröße ein wenig Aufblasen. Gerade dann, wenn ich Binärdatei pypy.vm.js.mem mit base64 einbinden wollen würde...

Würde es dennoch unterm Strich schneller sein, als die aktuelle .zip Lösung, die komplett per JavaScript geparst/dekomprimiert wird?

Man könnte auch noch überlegen, was anderes als .json zu nutzten. z.B.: binär formate wie:

• http://msgpack.org
• http://ubjson.org

Dann würde man allerdings wieder im Browser selbst parsen müssen.
Außerdem wieder die Frage, welche Dateiendung out-of-the-box mit gzip vom server komprimiert werden würde...


Ich denke als erstes, werde ich einfach mal eine einfache .json Version bauen. Denn das dürfte auch am schnellsten machbar sein

[jens]

Hab mit https://github.com/jedie/pypyjs.github. ... 0253b16255 eine plain-.json test fertig.

Einfach auf den "run" button klicken, zum Vergleich auf diesen beiden Seiten:

• https://jedie.github.io/pypyjs.github.io/editor.html (läd 'platform' als .zip)
• https://jedie.github.io/pypyjs.github.io/json_test.html (läd 'platform' als .json)

Eigentlich sind hier zwei Dinge unterschiedlich:
* Bei der .zip Variante wird in JavaScript geparst und dekomprimiert
* Beim .json passiert parsen und dekomprimieren komplett im Browser

Die .zip Variante ist allerdings um einiges schneller :

Mit leerem browser cache:

• .zip -> Run in 1.7sec.
• .json -> Run in 5.5sec.

Mit vollem Browser cache (dazu einfach nochmal auf die "run" Schaltfläche klicken:

• .zip -> Run in ~250ms
• .json -> Run in ~2.5sec.

Mit diesem Ergebnis hätte ich nicht gerechnet. Gut das "platform.json" ist 1,3MB groß. Aber so langsam sollte es nicht sein, oder?
Vielleicht hab ich, wider besseren JS Wissens, eine Bremse eingebaut?



Das Komprimieren ist zwar schlechter, aber ganz ok:

Original 'platform.json': ist 1.3MB groß
Mit python komprimierte .zip: 328.7KB
Von github gesendete Daten: 351,5 KB (In Firebug abgelesen)

[Daikoku]

Sorry, aber ich verstehe erstens die ganze Euphorie hier nicht, und zweitens was soll das Ziel des Projektes sein ?

Eine Console für Python in einen Browser zur Verfügung zu stellen und ein paar Python-Berechnungen in einem Browser zu rendern ?

Oder reden wir hier endlich einmal über eine zeitgemäße Front-End-Entwicklung mit Python im Browser mit all seinen Möglichkeiten, welche ich heute schon mit AngularJS2 bereits umsetzen kann ?

[jens]

die ganze Euphorie

Wo soll die sein?!?

Ist erstmal nur ein Spaß Projekt.
Der Hintergedanken ist natürlich schon, das man es auch praktisch nutzten kann. Aber ob das wirklich jemals was wird, ist fraglich...

[jens]

...was soll das Ziel des Projektes sein ?

Eine Console für Python in einen Browser zur Verfügung zu stellen und ein paar Python-Berechnungen in einem Browser zu rendern ?

Oder reden wir hier endlich einmal über eine zeitgemäße Front-End-Entwicklung mit Python im Browser mit all seinen Möglichkeiten, welche ich heute schon mit AngularJS2 bereits umsetzen kann ?

Das ist natürlich eine gute Frage. Wenn man es mal ernster sieht, als "ein Spaß Projekt"...

Ich kann dazu das schon erwähnte Video von der PyCon empfehlen: https://www.youtube.com/watch?v=PiBfOFqDIAI

Das erster Ziel, wäre es, erstmal eine praktischere Nutzbarkeit zu schaffen. z.Z. sind die Ladezeiten und damit die "Initialisierungs-Zeit" einfach zu lang.
Wie weiter oben schon geschrieben: Es müssen erst mal 20 MB Daten geladen werden. Gut, alleine mit dem Packen, bekommt man die auf rund 4MB...
Dann ziehen Python Modul Importe jede Menge Requests nach.

Diese Beiden Punkte untersuche ich ja gerade, mit:

• https://github.com/pypyjs/pypyjs.github.io/issues/4
• https://github.com/pypyjs/pypyjs.github.io/issues/7

Evtl. bring das schon erwähnte WebAssembly eine ganze Menge, siehe: https://github.com/pypyjs/pypyjs/issues/145


Aber gehen wir mal davon aus, das Lade-/Init-Zeiten kein Problem wären:

Natürlich kannst du erstmal ziemlich das selbe in JavaScript machen. Von daher ist das alles Sinnlos...
Aber wäre es nicht richtig Spannend eine "Gescheite" Sprache wie Python zu haben?
Trotz allem Fortschritt mit JavaScript, finde ich, das Python dennoch einige Vorteile hat.

[jens]

Talk Python To Me Podcast - Episode #32: PyPy.js - PyPy Python in Your Browser
Published Tues, Nov 3, 2015, recorded Wed, Sep 30, 2015.

-> http://talkpython.fm/episodes/show/32/p ... ur-browser