Stockfish.

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).

arena

screenshot_2017-02-12-01-41-14

Dalej kiepsko mi idzie, ale chyba mam kolejne hobby…

CROOK-5 w EM400 pod Windows.

crook5windows

Dziś z ciekawości skompilowałem EM400 w MSYS2 pod Windows.

Aby uruchomić.

Wersja 0.3.0-1-g0b5b497, aktualizacja 5.08.2016:

  1. Instalujemy MSYS2 w wersji x86_64.
  2. Pobieramy i rozpakowujemy archiwum zip z EM400. Znajdziemy w nim też cross-assemblery, linker, plik konfiguracyjny i inne narzędzia, ale obraz crook5 oraz EEPROM pamięci Mega trzeba pobrać ze strony mera400.pl.
  3. Odpalamy Msys2 Shell z menu Windows. W shell-u wchodzimy do katalogu gdzie rozpakowaliśmy em400.zip i obraz systemu CROOK. MSYS2 jest środowiskiem uniksopodobnym, więc dyski z Windows mapowane są np. na /c/jakiś/katalog.
  4. Uruchamiamy emulator: ./em400.exe -c em400.cfg
  5. Odpalamy jeszcze jeden Msys2 Shell, telnet 127.0.0.1 32000
  6. Wpisujemy run w debuggerze.

fib_on_crook

Miłej zabawy Mera400 (MX-16) i CROOK-5.

AspeQt dla Windows.

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:

AspeQt_WindowsBinarka dla Windows z wymaganymi bibliotekami tutaj.

winandroidlinux

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.

Msys2 – toolchain idealny.

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.

msys2
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.

Cython – kompilacja programów w Pythonie mingw-w64 dla Windows.

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 ;(.

aconv

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.