Dosbox.

Dosbox. Ciekawe pomimo, że jest to emulator, uruchamiając programy x86 na x86 nie mam takiego wrażenia. Inna sprawa, że jest sporo programów użytkowych, które działają tylko w MSDOS i pod Windows w cmd się nie uruchomią. BTW, ja to chyba lubię MSDOS-a. Dzięki niemu nauczyłem się używać linii komend i odkryłem Linuksa…

Zdecydowanie największym szokiem jest instalacja w Dosbox Windows 3.1. Po pierwsze, żal że to było tak dawno temu :(. Po drugie, całkiem fajny ten Windows, wizualnie jak na 1992 Windows 3.1 było super. Po trzecie: to śmiga!

Na szczególną uwagę zasługuje ostatni obrazek: Python2.4 w Windows 3.1 :).

Dosbox.

Fs-uae.

Kolejny świetny emulator dołączył do moich ulubionych: FS-UAE, czyli marzenie sprzed lat, działa świetnie na 7-mio letnim laptopie (R61i z T5250). Fs-uae-launcher to nakładka graficzna (w pyqt) pozwalająca na współpracę emulatora z oagd.net (Open Amiga Games Database).

Nie byłbym sobą gdybym nie spróbował na Amidze Pythona. Jak widać dostępne są dwie wersje: 1.4 (oficjalny, bardzo stary instalator znaleziony na ftp.python.org) i 2.3 (Amiga Python) (w tym drugim jest już prawie wszystko co lubię w Pythonie).

Fs-uae.

Workbench 3.1 na MIST (Minimig-AGA).

Pierwszy raz od czasów szkolnych poklikałem w Workbench (testuję rdzeń Minimig AGA dla MIST).
DSC_0861Biorąc pod uwagę rok wydania, czuję jakiś niedosyt. Jest kilka fajnych ficzerów (micro-emacs w standardzie, wypasiony shell, automounter) a jak widać zajmuje to niecałe 3MB dysku twardego, z drugiej strony, look&feel jest praktycznie taki sam jak w wersji 2.0 z 1990 roku…

Workbench 3.1 na MIST (Minimig-AGA).

Django: migrations.

Bardzo mi odpowiada ewolucja Django od czasu kiedy ostatni raz coś w nim robiłem, a było to kilka lat temu. Krótko mówiąc, nadal mam wrażenie jakby to były spodnie szyte na miarę lub śrubokręt, który idealnie leży w łapie i odkręci każdą śrubkę ;). Nie mam uczucia ewolucyjnego zagubienia. To tylko dobrze świadczy o projekcie, bo to co było kiedyś, nie zostało w ciągu tych kilku lat przepisane, najlepiej od zera. Mogło się tak stać tylko dlatego, że już na etapie 1.0-1.4, kiedy poznawałem ten framework, wszystko było zrobione jak należy.

Dziś trafiłem na prezentację o Django Migrations wygłoszoną podczas tegorocznego Pycon. Piękna sprawa:

Django: migrations.

Printf() pod Windows.

Printf() pod Windows okazuje się sporo wolniejszy niż pod Linuksem.

printf_windowsParadoksalnie, jak widać powyżej, pythonowy print() jest ~3x szybszy od printf() z biblioteki standardowej Mingw-w64. Pod Linuksem na odwrót, 4x wolniejszy względem tego z libc.stdio:

print_linux


Poczytałem stdio.h i doszedłem do tego, że gdy  -D__USE_MINGW_ANSI_STDIO=1 używana jest funkcja printf() z Mingw (ponad 11 razy wolniejsza od printf() pod Linuksem) i tak jest „by default”.

Jeśli do gcc dodam  -D__USE_MINGW_ANSI_STDIO=0, używana jest wersja printf() z msvcrt.dll. Mimo, że ta funkcja ma swoje braki, różnica jest dość znaczna:

$ time ./fib_mingw_printf.exe 300000 > /dev/null

real 0m5.513s
user 0m0.000s
sys 0m0.031s

$ time ./fib_msvcrt_printf.exe 300000 > /dev/null

real 0m1.081s
user 0m0.015s
sys 0m0.000s


Jeszcze jedna ciekawostka: przekierowanie do /dev/null w MSYS2 (które jest prawdopodobnie mapowane na NUL) pod Windows jest powolne. Przekierowanie do pliku jest ~2x szybsze:

$ time ./fib_msvcrt_printf.exe 300000 > output.txt

real 0m0.562s
user 0m0.000s
sys 0m0.015s

(Pod Linuksem bez różnicy).


Na szczęście %timeit pozwala się przekonać, że kod generowany w tej samej wersji gcc pod Windows i pod Linuksem jest niemal tak samo wydajny.

Printf() pod Windows.

Msys2/Mingw-w64, Cython i Ipython Notebook.

Ipython Notebook z Mingw-w64-gcc/MSYS2 działa ładnie pod Windows.

cython_notebook Zeromq, jinja2 i sqlite są w repo MSYS2 więc można je zainstalować pacmanem. pyzmq, tornado i pysegments instaluje się przez pip, który jest w paczce mingw-w64-i686-python3-pip.

Super sprawa do testów Cythona i Pythona. W oficjalnym Pythonie nie udało mi się zmusić mingw-w64-gcc do kompilowania Cythona, choć wszystkie zależności notepada instalują się ładnie z pip.

Msys2/Mingw-w64, Cython i Ipython Notebook.

Python vs Cython vs PyPy.

Moich tendencyjnych eksperymentów ciąg dalszy. Zrezygnowałem z Numpy i jestem pod wrażeniem memoryviews w Cythonie. Poniższe to tak na prawdę test wydajności adresowania tablic jednowymiarowych.

Python:

import sys
import random

def fib(n):
    a, b = 0, 1
    for i in range(n):
        a, b = b, a + b
    return a

def showfib(n):
    r = []
    for i in range(n):
        t = fib(random.randint(0,49))
        r.append(t)
        print(t, end=" ")
    print()

if __name__ == '__main__':
    n=int(sys.argv[1])
    showfib(n)

Cython:

#cython: language_level=3, boundscheck=False

import sys
from libc.stdio cimport printf
from libc.stdlib cimport rand, srand
from cython.view cimport array
from time import time

cdef unsigned int fib(int m) nogil:
    cdef unsigned int a, b, i
    a, b = 0, 1
    for i in range(m):
        a, b = b, a + b
    return a

cdef showfib(n):
    cdef r = array(shape=(n,), itemsize=sizeof(unsigned int), format="I")
    cdef unsigned int [:] rv = r

    cdef int i
    cdef unsigned int t
    for i in range(n):
        t = fib(rand()%49)
        rv[i] = t
        printf("%u ", t)
    printf("\n")

if __name__ == '__main__':
    n=int(sys.argv[1])
    srand(int(time()))
    showfib(n)

Python-3.4.2:
$ time python fib.py 300000 > /dev/null
real 0m7.564s
user 0m7.543s
sys 0m0.013s

PyPy3-2.4 (portable):
$ time pypy fib.py 300000 > /dev/null
real 0m1.838s
user 0m1.813s
sys 0m0.020s

Cython-0.21.1:
$ time ./fib 300000 > /dev/null
real 0m0.189s
user 0m0.190s
sys 0m0.000s

Cython vs Python: 40,02 x szybciej.
Pypy vs Python: 4,11 x szybciej.
Cython vs PyPy: 9,72 x szybciej.

Python vs Cython vs PyPy.