PyPy bei Uberspace?

[jens]

Hat es schon jemand dort probiert?

Wollte ich gerade machen, nach Anleitung von http://wiki.python-forum.de/PyPy

Leider scheitert das starten des Interpreters:

Code: Alles auswählen

$ pypy-c-jit-65876-9d4bbb3734b2-linux64/bin/pypy --version
pypy-c-jit-65876-9d4bbb3734b2-linux64/bin/pypy: error while loading shared libraries: libbz2.so.1.0: cannot open shared object file: No such file or directory

Dazu habe ich das gefunden: http://mail.python.org/pipermail/pypy-d ... 06588.html

Zur Info:

Code: Alles auswählen

$ ls /lib64/libbz2* -la
lrwxrwxrwx. 1 root root    15  5. Sep 2012  /lib64/libbz2.so.1 -> libbz2.so.1.0.4
-rwxr-xr-x  1 root root 69976 25. Jun 2011  /lib64/libbz2.so.1.0.4

Ideen?

EDIT: Habe mal https://bitbucket.org/pypy/pypy/downloa ... 64.tar.bz2 versucht:

Code: Alles auswählen

$ pypy-2.1/bin/pypy --version
pypy-2.1/bin/pypy: error while loading shared libraries: libffi.so.6: cannot open shared object file: No such file or directory

$ ls /usr/lib64/libffi.so* -la
lrwxrwxrwx  1 root root    15  9. Apr 17:53 /usr/lib64/libffi.so -> libffi.so.5.0.6
lrwxrwxrwx. 1 root root    15  5. Sep 2012  /usr/lib64/libffi.so.5 -> libffi.so.5.0.6
-rwxr-xr-x. 1 root root 31720 11. Nov 2010  /usr/lib64/libffi.so.5.0.6

[Leonidas]

Ja, du kannst nicht einfach X-beliebige Binaries verwenden, die müssen schon zu der Version deiner Libraries passen. Und libffi5 ist nun mal was anderes als libffi6.

Ich nehme aber an das libbz2 ausreichend kompatibel ist, leg dir doch nen Symlink von libbz2.so.1 auf libbz2.so.1.0 an, dann sollte pypy das auch finden.

[jens]

Selbst übersetzten habe ich auch Probiert. Läuft aber nicht durch. Soll laut http://doc.pypy.org/en/latest/getting-s ... ython.html auch 45Min auf sehr schnellen Maschinen dauern.

Das Übersetzten endet irgendwann, mitten im Mandelbrot einfach nur mit "Beendet" Sonst keine weiteren Informationen

Das mit dem Symlink habe ich auch probiert. Einmal mit ln -s /lib64/libbz2.so.1.0.4 ~/bin/libbz2.so.1.0 und einmal direkt in pypy-c-jit-65937-81d4a31242a6-linux64/bin
Dennoch bleibt es beim selben Fehler. Ich weiß nicht wo pypy nach der Datei überall sucht, aber offensichtlich nicht da wo ich einen symlink erstellt hab.

[BlackJack]

@jens: Es gibt da so eine Umgebungsvariable ``LD_LIBRARY_PATH`` und das was in ``/etc/ldconfig.conf`` steht.

[lunar]

@jens Uhm, "~/bin/libbz2.so.1.0"?! Was in Gottes Namen bringt Dich zu der (irrigen) Annahme, Linux würde in "~/bin" nach Bibliotheken suchen?

Du musst mindestens "LD_LIBRARY_PATH" setzen, wenn Du Bibliotheken außerhalb der Standardverzeichnisse verwenden willst. Einfach mal so wild herumzulinken, wird Dich nicht weiterbringen.

Was den Übersetzungsvorgang angeht, so hat der Kernel diesen wahrscheinlich beendet, weil er zu viel Zeit oder zu viel Speicher benötigt hat.

[jens]

Weil "~/bin" ist in PATH...

Hab nun in meiner .bash_profile mal das eingetragen:

Code: Alles auswählen

LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$HOME/lib64
export LD_LIBRARY_PATH

Und symlinks nach ~/lib64/ erstellt.
Geht nun ein Stückchen weiter, aber läuft dennoch nicht:

Code: Alles auswählen

./pypy: /usr/lib64/libssl.so.1.0.0: no version information available (required by ./pypy)
./pypy: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by ./pypy)
./pypy: /lib64/libc.so.6: version `GLIBC_2.15' not found (required by ./pypy)
./pypy: /usr/lib64/libcrypto.so.1.0.0: no version information available (required by ./pypy)

btw. ist CentOS 6.4 ... dafür sind die Binaries wohl nicht ausgelegt.
Könnte natürlich lokal in einer VM ein CentOS 6.4 installieren. Dann PyPy selbst übersetzten und kopieren... Weiß nicht ob der Aufwand es Wert ist.

Eigentlich wollte ich nur mal Testen ob Django mit MySQL brauchbar laufen würde. Selbst wenn PyPy laufen würde, ist die Frage ob man MySQLdb ans laufen bekommt.

[lunar]

Weil "~/bin" ist in PATH...

Uhm, "PATH" hat nichts mit Bibliotheken zu tun…

[jens]

Uhm, "PATH" hat nichts mit Bibliotheken zu tun…

Das weiß ich dank euch jetzt auch

Hab mal eine CentOS VM angelegt. Ist aber ein bischen störrisch Aber pypy compiler läuft... Dumm das der leider nur einen CPU-Kern nutzt.

[Leonidas]

btw. ist CentOS 6.4 ... dafür sind die Binaries wohl nicht ausgelegt.

Ja, die scheinen wirklich zu neu zu sein.

Könnte natürlich lokal in einer VM ein CentOS 6.4 installieren. Dann PyPy selbst übersetzten und kopieren... Weiß nicht ob der Aufwand es Wert ist.

Vermutlich nicht. Aber machen kann man das natürlich schon.

Eigentlich wollte ich nur mal Testen ob Django mit MySQL brauchbar laufen würde. Selbst wenn PyPy laufen würde, ist die Frage ob man MySQLdb ans laufen bekommt.

Du kannst das doch einfach bei dir lokal testen? Ich gehe stark davon aus dass Django recht brauchbar mit MySQL läuft, ist schließlich die populärste Datenbank.

[jens]

Die Frage ist nicht Django<-> MySQL, sondern PyPy<->MySQL...

Weiß nicht ob https://bitbucket.org/pypy/compatibilit ... sql-python noch aktuell ist und man MySQLdb patchen muß oder nicht.

Was den Übersetzungsvorgang angeht, so hat der Kernel diesen wahrscheinlich beendet, weil er zu viel Zeit oder zu viel Speicher benötigt hat.

Ich vermute zu viel RAM.
Ich versuche es nochmal mit --opt=mem ... mal sehen...

EDIT: Läuft auch nicht durch.

[Leonidas]

Ich kann mir aber auch vorstellen dass PyPy auf Uberspace genauso gekillt wird, weil der JIT etwas mehr Speicher braucht.

[DasIch]

Was den Übersetzungsvorgang angeht, so hat der Kernel diesen wahrscheinlich beendet, weil er zu viel Zeit oder zu viel Speicher benötigt hat.

Ich vermute zu viel RAM.
Ich versuche es nochmal mit --opt=mem ... mal sehen...

Das dürfte sich nur auf den Speicherverbrauch des Interpreters beziehen. Zum kompilieren brauchst du min. 4GB und 30min Zeit, wenn du ein aktuelles System nutzt, auf älteren Systemen kann es auch schonmal ein paar Stunden dauern.

Abgesehen davon solltest du Bedenken dass deine Web Anwendung von PyPy erst dann profitiert wenn der JIT warm ist (etwa nach 1000 Requests), vorher dürfte die Anwendung mit PyPy (wesentlich) langsamer als mit CPython sein.

[jens]

4GB und 30min Zeit, wenn du ein aktuelles System nutzt, auf älteren Systemen kann es auch schonmal ein paar Stunden dauern.

Weißt du zufällig, was es für ein Unterschied macht, ob man mit CPython oder mit PyPy selbst compiliert?

Hab gesehen, es gibt auch alte Versionen als .rpm Pakete.
z.B. pypy-2.0.2-1.el6.x86_64.rpm, siehe: http://pkgs.org/search/?keyword=PyPy&se ... &distro=82

Abgesehen davon solltest du Bedenken dass deine Web Anwendung von PyPy erst dann profitiert wenn der JIT warm ist (etwa nach 1000 Requests), vorher dürfte die Anwendung mit PyPy (wesentlich) langsamer als mit CPython sein.

Hab mal mit django-processinfo nachgesehen.
1000 Requests kann nach knapp 2 Std. zusammen kommen. Der längste laufende Prozess bisher, hatte nach 18Std. rund 10.000 Requests verarbeitet.

Aber du hast recht. Denn nach http://speed.pypy.org zu Urteilen ist Django ohne JIT langsamer. Siehe: http://speed.pypy.org/comparison/?exe=6 ... ormal+bars

Klar, kann der JIT erst nach ein paar Durchläufen optimieren. Die Frage ist, wie viele Request sind wohl notwendig damit es sich lohnt.
Frage mich, wie viele requests bei speed.pypy.org durchgeführt werden.

EDIT: Ach, nach https://bitbucket.org/pypy/benchmarks/s ... _django.py zu Urteilen, wird ja nur die Django-Template Engine genutzt

EDIT2: Hab tests von 2011 gefunden, demnach wird PyPy nach ca. 100-200 Requests schneller: http://mail.python.org/pipermail/pypy-d ... 08499.html

Btw. könnte der JIT nicht auch "Optimierungs Ergebnisse" speichern. Ähnlich eines .pyc Datei?
EDIT3: Ist wohl nicht so einfach, siehe: http://doc.pypy.org/en/latest/faq.html# ... chine-code Wobei es überlegungen dazu gibt, siehe Blogpost von 11.2011: http://morepypy.blogspot.de/2011/11/got ... eport.html

[apollo13]

4GB und 30min Zeit, wenn du ein aktuelles System nutzt, auf älteren Systemen kann es auch schonmal ein paar Stunden dauern.

Weißt du zufällig, was es für ein Unterschied macht, ob man mit CPython oder mit PyPy selbst compiliert?

PyPy kompiliert sich selbst schneller, also alte binary ziehen und dann aktuelles PyPy mit sich selbst kompilieren…

[jens]

Lese gerade das:

It is recommended to use PyPy to do translations, instead of using CPython, because it is twice as fast.

von http://pypy.org/download.html#building-from-source


Egal. Mit CPython ist es nun auch endlich fertig... Nun versuche ich ein Paket zu schnüren, wie bei http://pypy.org/download.html#packaging beschrieben:

Code: Alles auswählen

cd ./pypy/pypy/tool/release/
python package.py ../../.. pypy-my-own-package-name

Leider läuft es nicht durch. Offensichtlich fehlen noch ein paar Pakete. z.B. sqlite-devel, tk-devel
Leider finde ich keine Liste der benötigten Pakete. Eine Idee?

EDIT: Die beiden Pakete waren wohl alles...

[jens]

Hab ein Paket fertig und es läuft auf Uberspace.de...

Wer es downloaden will -> http://www.jensdiemer.de/de/Blog/2013/0 ... e-nutzten/

[jens]

Hab mal auf Uberspace einen Test-Account eingerichtet.
Dann mein fertiges PyPy Paket genommen und mal PyLucid installiert.

Beim installieren von MySQLdb über pip erscheint allerdings diese Meldungen:

Code: Alles auswählen

Installing collected packages: MySQL-python
  Running setup.py install for MySQL-python
    building '_mysql' extension
    cc -O2 -fPIC -Wimplicit -Dversion_info=(1,2,4,'final',1) -D__version__=1.2.4 -I/usr/include/mysql -I/home/pypy/PyLucid_env/include -c _mysql.c -o build/temp.linux-x86_64-2.7/_mysql.o -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-strict-aliasing -fwrapv -fPIC -DUNIV_LINUX -DUNIV_LINUX
    _mysql.c: In Funktion »_mysql_ConnectionObject_getattr«:
    _mysql.c:2646: Warnung: Übergabe des Arguments 1 von »PyMember_GetOne« von inkompatiblem Zeigertyp
    /home/pypy/PyLucid_env/include/pypy_decl.h:228: Anmerkung: expected »struct PyObject *« but argument is of type »char *«
    _mysql.c: In Funktion »_mysql_ResultObject_getattr«:
    _mysql.c:2674: Warnung: Übergabe des Arguments 1 von »PyMember_GetOne« von inkompatiblem Zeigertyp
    /home/pypy/PyLucid_env/include/pypy_decl.h:228: Anmerkung: expected »struct PyObject *« but argument is of type »char *«
    _mysql.c: In Funktion »_mysql_ConnectionObject_setattr«:
    _mysql.c:2700: Warnung: Übergabe des Arguments 1 von »PyMember_SetOne« von inkompatiblem Zeigertyp
    /home/pypy/PyLucid_env/include/pypy_decl.h:229: Anmerkung: expected »struct PyObject *« but argument is of type »char *«
    _mysql.c: In Funktion »_mysql_ResultObject_setattr«:
    _mysql.c:2725: Warnung: Übergabe des Arguments 1 von »PyMember_SetOne« von inkompatiblem Zeigertyp
    /home/pypy/PyLucid_env/include/pypy_decl.h:229: Anmerkung: expected »struct PyObject *« but argument is of type »char *«
    cc -shared build/temp.linux-x86_64-2.7/_mysql.o -L/usr/lib64/mysql -lmysqlclient_r -lz -lpthread -lcrypt -lnsl -lm -lpthread -lssl -lcrypto -o build/lib.linux-x86_64-2.7/_mysql.pypy-21.so
    
Successfully installed MySQL-python

Funktioniert auf den ersten Blick aber ganz gut.

Läuft mit MySQL und fastCGI: http://pypy.mensa.uberspace.de

Ich werde es mal eine weile laufen lassen und dann wieder löschen.

Wer will, kann sich einloggen und rumschnüffeln: Benutzer admin und passwort 12345678