🚀 go-pugleaf

Łukasz Rekucki wrote:
> On Nov 23, 5:27 pm, Bart Ogryczak <b.ogryc...@gmail.com> wrote:
>> On Nov 23, 4:59 pm, Marcin Nowak <marcin.j.no...@gmail.com> wrote:
>>
>>> On 23 Lis, 15:25, Bart Ogryczak <b.ogryc...@gmail.com> wrote:
>>>> On Nov 23, 8:25 am, Marcin Nowak <marcin.j.no...@gmail.com> wrote:
>>>>> Jesli chodzi o Python:
>>>>>   - wysoka wydajnosc
>>>> Co do ostatniego, to bez przesady. Bardzo słabo w porównaniu do
>>>> statycznych języków. Póki Python nie będzie miał JIT, póty nie ma co
>>>> mówić o wydajności.
> 
> Alternatywne implementacje:
>  * Jython - kilka razy szybszy od CPython, tylko trochę wolniejszy od
> zwykłej Javy

Ależ skąd.

>  * IronPython - python dla platformy .NET - podobnie jak wyżej

j.w. Był szybszy kiedy był mało zgodny z oryginałem. Teraz nie jest.

>  * Unladen Swallow - nieoficjalny zastępnik CPython'a dla wersji 3.x,
> na razie tylko trochę szybszy w porównaniu z 2.6

3.x??? Przecież to kod dla 2.6.x

> JIT-y:
>  * Psycho

Psyco nie Psycho. Owszem dużo przyspiesza. Stosuję.

>  * PyPy (robi też dużo więcej, np. funkcjonalności ze stackless
> pythona)

To się rozwija, wygląda obiecująco, ale jeszcze poziomu Psyco nie osiągnęło.

> Aha. I oczywiście, to czy język jest typowany statycznie, czy
> dynamicznie, nie ma dużego wpływu na wydajność. Np. Common Lisp po
> kompilacji ma wydajność jak C.

Po pierwsze w rzeczywistości to ta wydajność jest zbliżona do C, ale nie 
taka sama (jest tzw, porównywalna, czytaj jest zwykle/średnio ze 2x 
wolniej), po drugie kod musi być już przez programistę odpowiednio 
napisany (jawne typowanie parametrów, itd -- czyli explicite wycinanie 
dynamiczności tam gdzie miesza)

Są języki typowane dynamicznie i języki typowane dynamicznie. Była 
dopiero co długa dyskusja na comp.lang.python. CL jest we wrażliwych 
(wydajnościowo) miejscach dużo mniej dynamiczny (jak jest funkcja to nie 
zostanie łatwo, dynamicznie przenazwana na co innego, typy prymitywne są 
"niedziedziczalne", itd.). BTW zrobiono implementację Pythona jako 
(kros)kompilatora do Common Lispa -- kod wynikowy okazał się nie lepszy 
wydajnościowo niż interpretacja z CPythona.

http://common-lisp.net/project/clpython/
http://github.com/franzinc/cl-python/


Python ma parę bardzo trudno przyspieszalnych elementów:
odwołania do pól obiektów przez słowniki (sloty niewiele pomagają, bo w 
podklasie można zrobić po swojemu), możliwość przykrywania nazw funkcji,
rozbudowane wykonywanie operatorów na podstawie metod specjalnych 
(__metoda__), skomplikowany lookup w przypadku dziedziczenia (a 
zwłaszcza wielodziedziczenia).

\SK
-- 
"Never underestimate the power of human stupidity" -- L. Lang
-- 
http://www.tajga.org -- (some photos from my travels)