Zawsze chciałem zacząć grać w szachy, ale jakoś nie mogłem znaleźć wystarczająco cierpliwego nauczyciela ;). Niedawno odkryłem silnik nie z tego świata Stockfish i dwa programy: Arena dla Linuksa i Droidfish dla Androida (mój ulubiony).
Dalej kiepsko mi idzie, ale chyba mam kolejne hobby…
Dziś z ciekawości skompilowałem EM400 w MSYS2 pod Windows.
Aby uruchomić (snapshot git b4794ce, aktualizacja z 24.04.2017):
Miłej zabawy Mera400 (MX-16) i CROOK-5.
Piętnaście emulowanych napędów w AspeQt to było dla mnie zdecydowanie za dużo 🙂 więc „zandroidyzowałem” plik projektu z repo dla Androida i wydzieliłem co androidowe, dzięki czemu mój fork AspeQt dla Antka kompiluje się też pod Windows i pod Linuksem. Obsługa portu odbywa się wtedy przez standardowy moduł serialport-{win32,linux}.cpp. Przy okazji poprawiłem kodowanie znaków, które w AspeQt pod Windows było skopane od dawna:
Binarka dla Windows z wymaganymi bibliotekami tutaj.
Printf() pod Windows okazuje się sporo wolniejszy niż pod Linuksem.
Paradoksalnie, 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:
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.
Idąc jak po nitce do kłębka, w końcu trafiłem na Msys2, czyli minimalny zestaw narzędzi systemowych, oparty o narzędzia uniksowe (głównie GNU) dla Windows.
Co się najbardziej rzuca w oczy w tym zrzucie? 🙂 Ano pacman. Tak, ten sam pacman co w Arch Linuksie, którego używam na co dzień. Co za tym idzie? Wszystkie pakiety (kompilator, biblioteki, python, narzędzia) i kompletne środowisko GNU, są w repo projektu, więc aktualizacja (pod Windows!) to standardowe: pacman -Suy, a przebudowanie pakietu wg własnego uznania to edycja prostych, jak konstrukcja przysłowiowego cepa plików PKGBUILD.
Dla mnie Msys2 to brakujący element systemów Windowsowych.
Dawno nie miałem takiej motywacji do programowania. Cztery dni poszukiwań, grzebania w strzępkach dokumentacji i przykładach. W końcu się udało. Ale od początku. Postanowiłem trochę odświeżyć wiadomości o Pythonie i natrafiłem na Cythona, który mnie zafascynował, ale miałem problem z kodowaniem argumentów programów (sys.argv) do obiektów unikodowych pod Windows (argv w Windows jest w UTF-16, wchar_t **). W żaden sposób nie dało się ich dekodować do Unicode, a binarki dla Linuksa działały bez problemu. Pal licho argv ale to samo dotyczyło kodowania nazw plików. Przetestowałem kilkadziesiąt funkcji C-API Pythona i nic. Skonwertowanie windowsowych szerokich argumentow (wchar_t **) argv z UTF-16 do UTF-8 wydawało się niemożliwe. Aż w jakimś archiwum ircowym trafiłem na wzmiankę, że bez flagi -municode mingw-gcc nie obsługuje pod Windows poprawnie kodowania linii cmd.
Co ciekawe, od początku wydawało mi się celowe generowanie entrypoint-a przez Cythona dla Windows jako:
int wmain(int argc, wchar_t **argv)
Okazuje się, że po dodaniu -municode do gcc mingw-w64 jako entrypoint traktuje właśnie wmain() i używa odpowiednich wersji funkcji z obsługą unicode. Niestety w mingw-gcc 4.8.1 nie ma opcji -municode i wiele osób pewnie z tego powodu ma problemy. W gcc-4.8.1 z mingw-w64 działa jak należy, jest nawet o tym informacja na stronie projektu:
http://sourceforge.net/p/mingw-w64/wiki2/Unicode%20apps/
Szkoda, że wcześniej tego nie znalazłem ;(.
Przykładowa konwersja i kompilacja wygląda tak, w Windows w MSYS:
/c/Python34/Scripts/cython.exe -3 --embed aconv.py gcc aconv.c -I /c/mingw/python/include/python3.4m -L /c/mingw/python/lib/ -lpyth on3.4m -municode -o aconv
Podsumowując. Bardzo mnie to cieszy. W Cythonie, poza niemal pełną zgodnością z Pythonem można includować nagłówki z bibliotek w C i bezpośrednio z nich korzystać w modułach pythonowych, z całą dobrocią typów C a pozwala na przyspieszenie kluczowych fragmentów kodu i kompilację nawet całych programów skonwertowanych do C. A w składni wygląda to jak Python.
Pełen respect dla twórców Cythona.
greblus.pl 
