GIL
Facet ma point. W pracy zastanawiając się nad wyborem języka, stanęło na stackless pythonie, ale w pracy miałem systemy bardziej zbliżone do google'owych, gdzie wszyscy wiedzieli, że od razu trzeba pisać z myślą o maksymalnej skalowalności, bo drugiego podejścia nie będzie. Więc nikt się specjalnie nie obruszał, że nie będzie można pójść na łatwiznę z normalnymi wątkami.
Ale wątki to jest mainstream, a im dalej w czas, tym więcej systemów wieloprocesorowych na rynku. I jeśli python pozostanie poza mainstreamem, to może się to dla niego źle skończyć, a tego bym nie chciał.
Z drugiej strony, co potrafię dopiero docenić z perspektywy lat, python w dużej ilości sytuacji stara się być mądrzejszy od programisty i podsuwać mu pod nos najlepsze rozwiązanie, utrudniając korzystanie z innych. I może Guido ma rację zniechęcając do korzystania z wątków. A może nie. Na razie wygląda na to drugie.
10 IX 2007 o 19:54:34
Ja się raczej zgadzam z Guido. Poprawna pełna obsługa równoległych (w sensie bardziej fizycznym niż logicznym) wątków jest kosztowna. Teraz w Pythonie to jest piękne, że nie muszę się zastanawiać, czy coś innego modyfikuje moją listę, słownik czy jakiś nowy obiekt. Dzięki temu kod jest znacznie prostszy i łatwiejszy do „odpluskwiania”. Interpreter też nie musi się tym przejmować — może działać dużo wydajniej. To co mógłbym zyskać wykorzystując w jednym procesie kilku rdzeni CPU najprawdopodobniej straciłbym na dodatkowym thread-safety interpretera i na skomplikowaniu mojego kodu. Poza tym, straciłyby na tym też aplikacje jednowątkowe. Jeśli chodzi o wydajność, jedynym sensownym rozwiązaniem byłoby zduplikowanie wszystkich struktur, aby mieć wersje i wątko-bezpiecznie i nie. Domyślasz się jaki z tego byłby syf.
Właściwie główny problem wciąż jest z systemami operacyjnymi, które sobie kiepsko z procesami radzą. Znaczy się z Windows. Do Apache też dodano obsługę wątków (komplikując co nieco) głównie po to, żeby na Windows mógł konkurować z wielowątkowym IIS. Pod uniksami dalej najwydajniejsze serwery zwykle działają w wielu jednowątkowych procesach.
Są przypadki gdy wątki się przydają w programowaniu. Ale to raczej chodzi o logikę aplikacji, żeby nie trzeba było jawnie przerywać jednego potoku przetwarzania, żeby zrobić co innego, niż o wykorzystanie wielu rdzeni procesora, czy wielu procesorów.
No i ostatnia sprawa: trudno wiele „fizycznych” wątków rozproszyć na wiele maszyny. Z procesami nie ma takiego problemu. I popularne mechanizmy komunikacji międzyprocesowej ładnie się skalują na łącza sieciowe — dzielenie dużej części przestrzeni adresowej nigdy nie będzie się tak ładnie skalować.
10 IX 2007 o 20:02:18
Większość tych argumentów jest właśnie zbijana w artykule — racja, superskalowalności się nie osiąga przez wątki, ale to nie o superskalowalność chodzi, tylko o lepszą skalowalność osiąganą poprzez np. dwa równolegle się wykonujące wątki na dualcorze, czy czymś.
Co do wydajności, to jest coś, co nam się wydaje — w jvm jakoś zrobili, działa i jest wydajne, znaczy jednak się da.
Natomiast skomplikowanie kodu źródłowego, to tak jakby nie jest mój problem, tylko pythona. Tzn. jeśli twórcy nie potrafią zaoferować jakiejś popularnej funkcjonalności, bo jest to „za trudne w implementacji”, to w końcu skończy się na tym, że użytkownicy będą używać czegoś innego, robionego przez „mocniejszych” programistów.
Imho rozwiązaniem rzeczywiście byłby jakiś osobny moduł oferujący w ten, czy inny sposób rzeczywistą wielowątkowość. Nie dodawałoby to problemów ludziom, którzy lubią GIL-a, a dawało większe możliwości tym, którzy chcą.
10 IX 2007 o 20:18:09
Ale wielowątkowość w Pythonie jest rzeczywista (inaczej można by się kłócić, że typowy PC nie jest wielowątkowy, bo np. nie może pobrać z pamięci jednocześnie dwóch instrukcji, a więc nie wykonuje wszystkiego równolegle). Tylko z ograniczeniem, że dwie ‘podstawowe instrukcje’ nie mogą się wykonywać jednocześnie. Takie założenie, taka decyzja projektowa. Takie uproszczenie: zarówno dla developerów Pythona jak i dla programujących w tymże Pythonie (wiele razy GIL pozwolił mi bardzo uprościć kod, wielowątkowy rzecz jasna).
Też mnie czasem GIL denerwuje, ale często go doceniam. A pisząc oprogramowanie trzeba podejmować decyzje — jakby Guido chciał zadowolić wszystkich i wszystkie potrzeby, to pewnie nie zadowoliłby nikogo.
To że w Javie się udało… no to fajnie. Ale po pierwsze, nad Javą pracuje trochę więcej ludzi za trochę większe pieniądze. Po drugie, z tego co wiem, to problemy z obsługą wątków tam też wychodzą. A pisanie programów „wieloprocesowych” jest koszmarem (już samo wywołanie zewnętrznego procesu jest kłopotliwe, w standardowej bibliotece raczej nie znajdziesz niczego porównywalnego z Pythonowym „subprocess”).
Zarówno Python jak i Java to tylko narzędzie. I narzędzie to wybiera się nie tylko ze względu na składnie języka, czy bibliotekę standardową, ale też ze względu na różne inne cechy języka (często będące jakimś świadomym wyborem twórcy). Decyzje Guido nie podobają się „wątkowcom”, ale nie podobają się też miłośnikom statycznego typowania, czy przeciwnikom „znaczących białych znaków”. Ale oni zawsze mogą wybrać inny język, albo muszą się pogodzić z niektórymi „felerami”.
No i na pewno nie chciałbym teraz przepisania całego interpretera Pythona i połowy biblioteki standardowej od nowa tak, żeby zadowolić „wątkowców”. To by wymagało dużego przestoju w rozwoju (nowa implementacja, testowanie, odpluskwianie) i sporo niekompatybilności dla IMHO znikomego zysku.