Jakub Piotr Cłapa wrote:
Chodzi o to, że różnica w wydajności jest pomijalna.
20% bez wgłebiania się?
To jest pomijalnie mało, jeśli chodzi o program, za którego większość roboty wykonuje GTK+2, xft, freetype i serwer Xów. (zrób profile i sprawdź ile czasu program siedzieć będzie w kodzie Pythona, a ile w bibliotekach).
Po pierwsze dlatego, że programy okienkowe zazwyczaj nie wymagają dużo mocy obliczeniowej (nie na poziomie logiki programu --- jedynie na poziomie renderingu, który przecież i tak jest w C).
Właśnie piszę implementację trójwymiarowego automatu komórkowego z wizualizacją w OpenGLu. PyGL pewno by sie zakrztusił. Zresztą, nawet Word ze swoimi automatami sprawdzania gramatyki/ortografii/składni już teraz jest poważnym zżeraczem zasobów. O aplikacjach naukowych/obliczeniowych/dyskowych już nie wspomnę.
Aplikacje naukowe w strasznie dużej ilości są pisane w językach interpretowanych (python, lisp, java) z wykorzystaniem bibliotek, które optymalnie wykonują najtrudniejszą część pracy (napisanych w C lub np. w Pyrexie). Użycie C/C++ do całego programu to typowe premature optimization.
Co do Twojego automatu komórkowego --- nie wiem jak by on chodził w Pythonie, ale prawdopodobnie używając mieszanki Pythona i Pyrexa napisałbyś go 2 razy szybciej (i miałbyś z miejsca 40% mniej błędów alokacji pamięci i takich tam).
Oczywiste jest, że nie każdy język jest optymalny do każdego zadania, ale gdyby czysta wydajność była jedynym czynnikiem, który bierzemy pod uwagę, to wszyscy pisalibyśmy w assemblerze. (który nota bene potrafi stworzyć pliki wykonywalne jeszcze 5 razy mniejsze niż C i wymagające 10 razy mniej bibliotek ;).
Zresztą, rozmawiamy tutaj o instalatorze, od którego zapewne wymaga się
właśnie szybkości i platformy z jak najmniejszą ilością
maszyn/bibliotek.
Nie o taka szybkość nam chodzi. GUI instalatora musi chodzić jedynie znośnie szybko, a to spokojnie da się osiągnąć w Pythonie.
C i C++ jest nieoddzownym elementem każdego linuxa i na pewno 80% bibliotek potrzebnych ew. instalaorowi i tak będzie na płytce, żeby obsłużyć wszystkie programy, z których korzystać będzie rzeczony instalator, a python w tym momencie to novum i trzeba go osobno obsłużyć.
Nie takie straszne novum, a w intalatorze to akurat wszystko jedno, bo i tak dostarczasz całą płytkę z własnym softem. Większy problem jest akurat w programach standalone, które mają się wpasować w istniejący system (ale tu też nie byłbym taki pewien... większosć binarek w C jest statycznych, autoconf i automake mają wiele swoich problemów... C/C++ jest mniej uniwersalny i neutralny platformowo)
Druga rzecz --- w swoim programie w C++ też będziesz potrzebował często zaawansowanych bajerów i
wtedy będziesz musiał pół maszyny wirtualnej Pythona napisać od nowa
tylko dla swojego programu i nie sądze, żebyś dostał coś lepszego niż
oryginał.
Co to znaczy 'zaawansowanych bajerów'?? Zdecydowanie prace z listami/stringami są na pewno notacyjnie łatwiejsze niż w C++, ale z odpowiednimi bibliotekami też narzekać nie będę. Wszystko kwestia bibliotek szczerze mówiąc i niczego wiecej.
Oczywiście, ale Mozilla jest napisana w C++ z dużą ilością fajnych bibliotek. Działa nadal tak diabelnie szybko?
Nie ma zbytnio kompilowanych wersji programów w Pythonie.
Pyexe i na linuxa pewno też jest jakiś odpowiednik.
To nie jest kompilator. :) To jedynie program, który pakuje pliki Pythona, dllkę interpretera i jeszcze trochę śmieci, do jednego pliku.
Był kiedyś Python_C, który udowodnił, że zamiana kodu Pythona na kompilowane C nie ma sensu --- większość czasu tracone jest na dynamice języka (np. to, że każda klasa może być zmodyfikowana runtime).
Aplikacje GUI to programy zdecydowanie I/O bound a nie CPU bound, więc wydajność ma w nich drugorzędne znaczenie.
Słuchaj - prosta klikana przeglądarka do zdjęc dziewczyny z wakacji i brachola z psem pewno tak, ale w instalatorze na pewno wydajność się przyda.
Wydajność czego? Masz w instalatorze 20 ekraników, a całą trudną robotę robi za Ciebie poldek, rpm i bzip2. Prędkość języka w jakim zostanie napisane te 20 ekraników ma się nijak do prędkości instalatora. Ma się za to niesamowicie bardzo do tego, jak szybko ten instalator można napisać/poprawić.
Na wydajność systemu składają się wszystkie jego elementy. Strata wydajności na jednej prostej klikance w pythonie jest niewielka, ale jakby napisali KDE czy Gnome'a w pythonie, to już by zabolało.
Zresztą, EOT, bo ja z kolei zaczynam wypisywać tutaj jakieś teorie n/t programowania. Chcesz tak bardzo pythona - z tego co słyszałem, piszą jakiś system unix-like w pythonie, więc nie ma problemu. My tu gadu gadu o pierdołach, a chłopaki instalator piszą - POWODZENIA!! EOT.
Piszą, ale mało to UNIX-like a i moim zdaniem Python się do tego mało nadaje (za wiele ma wbudowane w siebie).
-- z wyrazami szacunku, Jakub Piotr Cłapa
_______________________________________________ pld-devel-pl mailing list [email protected] http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
