PyPy.js

[Sirius3]

@jens: die Dateien werden doch sowieso standardmäßig gzipt. Damit haben sie fast die gleiche Größe.

[jens]

Jain.

Selbst wenn gzip vom Server zum Zuge kommt, ist lzma effizienter.

Ich habe Tests gemacht, dabei pypy.vm.js und pypy.vm.js.mem genommen. Das sind die beiden "init" Dateien, die 19,2MB groß sind.

Mit gzip und der höchsten Kompressionsstufe bekommt man beide Dateien auf 3,83 MB gequetscht.
Wenn ich lzma mit dem preset 3 bzw. 4 wähle, komme ich auf ähnliche Kompressionszeiten, aber kleineren Dateien: zusammen 2,6MB
Nicht die Welt, aber immerhin 1,23 MB zusätzlich eingespart.

Wenn ich dann noch die lzma preset 9 wähle, sind es statt 2,6MB nur 2,44 MB... Also 1,39 MB weniger... Allerdings ist hier dann auch die Kompressionszeit bei mehreren Sekunden.

Ich vermute auch, das gzip bei einer Standard-Server-Konfiguration nicht mit der höchsten Kompressionsstufe betrieben wird.

Wäre IMHO gut, wenn Server und Browser mal lzma unterstützen würden. Den Standard gibt es nun auch schon seid zig Jahren. In Python gibt es den auch erst seid v3.3...

Das dekomprimieren per JavaScript mit https://github.com/nmrugg/LZMA-JS dauert natürlich auch ein paar Sekunden. Dabei habe ich lzma preset=3 gewählt.
Ist natürlich die Frage, ab welcher Download-Geschwindigkeit das ein oder andere besser ist :K

[jens]

Nochmal eine Rückmeldung...

Wie sich gezeigt hat, ist LZMA-JS doch zu langsam.
Auf meinem Arbeitsrechner mit I7-4790K ist das dekomprimieren zwar in 3-4Sek fertig. Aber auf einen älteren Rechner braucht es um die 13Sek. Siehe: https://github.com/pypyjs/pypyjs.github ... -111549828

Ich hab einen recht umfangreichen benchmark für Packer gefunden: https://quixdb.github.io/squash-benchmark/
Dort kann man neben einer Fetten Xeon E3-1225 Maschine auch den RaspberryPi2 und Beagleboard-XM nutzten.

Interessant sind IMHO die Packer:

• doboz
• lzham
• zlib:deflat
• lzo

Leider gibt es aber "doboz" und "lzham" nicht als JavaScript implementierung.
Von LZO hab ich nur "miniLZO" in JavaScript gefunden: https://github.com/abraidwood/minilzo-js

Deswegen hab ich mit mal zlib:deflat angesehen: https://github.com/imaya/zlib.js
Eine Beispiel hab ich fertig: https://github.com/pypyjs/pypyjs.github ... 87f378e9fb

Im Vergleich zu lzg ist zlib:deflat super schnell! Auf dem Rechner, des für lzg rund 13Sek gebraucht hat, ist die zlib:deflat nach 204ms und 157ms fertig! (Für pypy.vm.js_level9.deflate und pypy.vm.js.mem_level9.deflate

[BlackJack]

@jens: Der zlib:deflate-Algorithmus ist doch genau der den `gzip` verwendet, also etwas das sowieso jeder normale Browser schon ohne irgendwelche zusätzlichen JavaScript-Geschichten für Dateien unterstützt. Da spart man sich vielleicht ein paar Bytes für den GZIP-Header, aber dafür würde ich mir doch keine JavaScript-Bibliothek zusätzlich ins Boot holen.

[jens]

Da hast du recht. Wenn es denn auch aktiv ist. Dann auch die Frage, welcher Kompressions-Level ist Standard?

Es ist auch nicht die erste Wahl. Aber es gibt halt nicht so viele Packer in JavaScript.

Im Idealfall wäre es ein Packer der gut komprimiert (ruhig auch dafür lange braucht) aber schnell im Browser de-komprimiert.

Wobei die Frage ist, wie schnell ist ausreichend?!?
Ist aber kompliziert: Weil es von der Internet-Geschwindigkeit und dem verwendeten System abhängt:
Bsp.:

• Langsamer Rechner an 100MBit Leitung
• Schneller Rechner an 768 DSL

Am vernünftigsten erscheint es mit, sich an den Langsamen Rechner zu orientieren. Deswegen auch https://quixdb.github.io/squash-benchmark/ so eingestellt:

• dataset ->"Tarred source code of Samba 2-2.3"
• platform -> "raspberry-pi-2"

Wenn man die unbedeutenden Packer weg lässt kommt das dabei raus:


Also wie schon geschrieben, die interessanten:

• doboz: tick besser als zlib, aber viel schneller
• lzham: komprimiert deutlich besser, schneller als lzma, aber Geschwindigkeit ausreichend?!?

[Sirius3]

@jens: zlib ist immer viel schneller, weil es schon im Browser integriert ist. Bleibt noch lzham oder brotli, weil sie viel besser komprimieren, aber dann auch um Faktoren langsamer dekomprimieren.

[jens]

@jens: zlib ist immer viel schneller, weil es schon im Browser integriert ist. Bleibt noch lzham oder brotli, weil sie viel besser komprimieren, aber dann auch um Faktoren langsamer dekomprimieren.

Natürlich. Aber ich hab halt erstmal nur zlib als JavaScript Implementation...

Auf jeden Fall ist das schon viel mal besser als nicht komprimiert:

6.6M pypy.vm.js.mem
1.9M pypy.vm.js.mem.gz
1.93M pypy.vm.js.mem_level9.deflate
2.6M pypy.vm.js.mem.lz4
2.0M pypy.vm.js.mem.lz4.gz

und die pypy.vm.js ist noch größer:

12.68 MB pypy.vm.js
1.88 MB pypy.vm.js_level9.deflate

Macht schon einen Unterschied statt run 20 MB nur 3,8 MB ziehen zu müßen. Da machen die rund 350ms entpackzeit nichts aus.
Bzw. wie schnell muß die Leitung sein, das die zusätzlichen 350ms das ganze "verlangsamen"?!?

[BlackJack]

@jens: Was heisst Du hast nur `zlib` als JavaScript-Implementation? Der Browser hat deflate schon in C oder C++ implementiert und benutzt das zum entpacken wenn die Datei entsprechend gekennzeichnet `gzip`-komprimiert ausgeliefert wird. Darum sehe ich den Sinn von einem `zlib` in JavaScript in dieser Situation einfach nicht.

[snafu]

Macht schon einen Unterschied statt run 20 MB nur 3,8 MB ziehen zu müßen. Da machen die rund 350ms entpackzeit nichts aus.
Bzw. wie schnell muß die Leitung sein, das die zusätzlichen 350ms das ganze "verlangsamen"?!?

Also 0,3 Sekunden können in diesem Zusammenhang wohl vernachlässigt werden.

[jens]

@jens: Was heisst Du hast nur `zlib` als JavaScript-Implementation? Der Browser hat deflate schon in C oder C++ implementiert und benutzt das zum entpacken wenn die Datei entsprechend gekennzeichnet `gzip`-komprimiert ausgeliefert wird. Darum sehe ich den Sinn von einem `zlib` in JavaScript in dieser Situation einfach nicht.

Schon klar... Wenn der Server auch wirklich komprimiert. Aber das war das Ursprüngliche Problem von https://github.com/pypyjs/pypyjs.github.io/issues/4

Die Datei pypy.vm.js.mem endet auf .mem und in der Standarteinstellung vom github.io hat man deswegen kein caching und keine Komprimierung. Deswegen ist z.Z. die Seiten http://pypyjs.org/ ziemlich langsam. Insbesondere der Editor http://pypyjs.org/editor.html

Nun kann man den Server wechseln, damit man es selbst unter Kontrolle hat oder die Datei Endung auf irgendwas "normales" ändern, damit sie per application/octet-stream + caching header + gzip Kompression ausgeliefert wird...

Tritte Möglichkeit: einen CDN Service nutzten, den man entsprechend einstellen kann...

Vierte Möglichkeit: Dateien manuell komprimieren und im Browser per JS entpacken. Theoretisch wäre das die flexibelste Möglichkeit. Wobei auch hier eine Dateiendung gut wäre, die mit "application/octet-stream + caching header + gzip Kompression" ausgeliefert wird...

[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