🚀 go-pugleaf

On 30.10.2009, pakalk <pakalk@gmail.com> wroted:

>> Zapytaj kogoś, kto miał na studiach zajęcia ze struktur danych.
>> Podpowiedź: wydajność.
>
> Tylko, ze PHP nie ma wcale polaczonych list i hashy (map) w jednej
> strukturze. Posiada tablice asocjacyjne.

Sprawdź sobie, jak działa 'array'. Ze szczególnym uwzględnieniem
składni udającej listy.

>> > Eeee... Tablice asocjacyjne z PHP sa powszechnie chwalone
>>
>> Przez kogo konkretnie?
>
> Przez wiele osob.

A konkretnie? Kto i za co je chwali? Przejdź się na dowolny wydział
informatyki, zapytaj ludzi od struktur danych. Jeśli usłyszysz 
pochwały, daj znać -- to będą chyba pierwsze jakie PHP od nich
dostanie.

>> Decyzja o zrobieniu listy-i-hasza jako mapującej struktury danych
>> jest po prostu debilna.
>
> Nic takiego nie ma miejsca.

Sorki, ale nie masz pojęcia o czym mówisz. Sprawdź sobie jak jest
implementowane 'array' i zastanów się, dlaczego składniowo udaje 
również listę. 

[...]
>> Poza PHP robi to chyba tylko AWK. Dzięki temu masz strukturę
>> powolną jak diabli, ale za to pozbawioną zalet listy: jeśli po
>> usunięciu indeksu muszę używać funkcji żeby indeksy zachowały
>> ciągłość:
>>
>> $array = array_values($array);
>
> Pewnie dlatego, ze to nie jest tablica indeksowana 0..n tylko
> tablica asocjacyjna klucz=>wartosc - to, ze jest to lista, to juz
> Twoj wymysl.

Składniowo udaje listę, prawda? Normalny hasz nie pozwala na 
deklarowanie go np. jako '$array = array("a", "b", "c");'. 

> Dziwne by bylo tez, gdyby zachowywalo sie to inaczej
> dla roznych typow indeksow.

Dziwne to jest np. to dlaczego PHP nie ma list, tylko protezę 
w postaci specjalnego zachowania haszy. Chodzi w końcu o dość 
podstawowy typ danych. Zmuszanie ludzi do używanie kulawej 
pseudo-listy, ale za to powolnej, to jest dość typowy dla PHP
przypadek strzelania sobie w stopę.

>> to coś jest grubo nie tak. Kto konkretnie chwali te tablice i za
>> co, jeśli można wiedzieć?
>>
>> > a jesli chodzi o struktury danych...
>>
>> >http://www.php.net/manual/en/spl.datastructures.php
>>
>> To, że musisz sobie z czasem sztukować funkcjonalność
>> rozszerzeniami
>
> Jakie rozszwrzenie? Standard PHP Library - to sie tak nazywa.

Mhm. A ty oczywiście wiesz czym się różni _język_ od _standardowej
biblioteki_? I oczywiście ignorujesz przypadek skopanego int, które
trzeba obchodzić używając bcmath?

[...]
>> > Tak? Gdzie? Jak dla mnie to one dzialaja, jak pelnoprawne
>> > referencje.
>>
>> To są aliasy, nie referencje (w PHP poniżej 5).
>
> Czemu mamy rozmawiac o czyms, co juz nie jest nawet przez Zenda
> wspierane?! 

Ważne jest, że jest stosowane. Sprawdź sobie ile jeszcze masz
instalacji PHP4. 

> Moze pogadajmy o 'classic-style classes', albo pythonie
> 1.0? Taki doskonaly byl?

Możesz się zaperzać i wściekać, ale trudno ci będzie zmienić fakty.
Python, niezależnie od wersji, był zaprojektowanym przez fachowca
językiem ogólnego przeznaczenia, a nie powiązanym taśmą klejącą workiem 
funkcyjek do obróbki formularzy HTML.

[...]
>> >> OOP jako afterthought, ledwo doprowadzone do używalności w PHP
>> >> 5.
>>
>> > Prosze Cie..
>>
>> O co?
>
> Nie rozumiem krytyki OOP - moze konkrety?

Czego konkretnie nie rozumiesz? Że OOP zostało zgodnie z pehapową
tradycją bezmyślnie doklejone taśmą do którejś kolejnej wersji?
Po prostu sprawdź kiedy i w jaki sposób się pojawiło. Według ciebie
w wersjach poniżej 5 to coś było używalne?

GS
-- 
Grzegorz Staniak <gstaniak _at_ wp [dot] pl>
Nocturnal Infiltration and Accurate Killing

On Wed, 04 Nov 2009 13:18:02 -0000, pakalk <pakalk@gmail.com> wrote:

Ale przeciez nie warto stosowac funkcji zgodnie z ich przeznaczeniem,
tylko wymagac od nich urojonych wlasciwosci.

Urojonych? Nie przekonuje mnie takie fanbojowskie wyjaśnienie. Skoro się  
wysilili na tyle aby dodać obsługę roku przestępnego, to mogliby dodać też  
zwracanie null'a dla bezsensownych dat. Ty bardziej, że to częściowo  
działa! Słowem - to zachowanie jest niespójne i głupie. Co zresztą nie  
jest niczym nowym w pehapie.

Jak z tymi tablicami,
ktore nie chca domyslnie zachowywac sie jak lista.

Bo pehap nie ma list, ma tylko tablice asocjacyjne, lub inaczej nazywając:  
sorted hashmaps.

Więc trudno taki błąd wyłapać. Ani wyjątku ani warninga, ani notice,  
kompletnie nic. Faktycznie księgowa się może zdziwić. Nie tylko jak  
uważam, że PHP nie nadaje się do poważnych zastosowań. W nim roi się od  
takiego szeregu nonsensów.

Nonsensem jest uzywanie tej funkcji jako walidatora daty. Dobrze, by
bylo, gdyby dokonywala sprawdzen poprawnosci date, ale wymagac od niej
czegos, czego nie oferuje i nigdzie sie tym nie chwali jest smieszne.

Gdyby nikt nic nie wymagał to byś do dziś pisał w PHP3, lub wcześniejszej  
wersji. Po co komu funkcja, która akceptuje jedne bezsensowne daty, a inne  
- nie?  Przecież to nie ma sensu. Zero spójności i konsekwencji.

W sumie, ten i inne przykłady, pokazują, że pehap jest z pewnością  
językiem w którym łatwiej popełnić błąd i trudniej aplikację uczynić  
odporną na różne błędy. To jest bardzo poważna słabość tego języka. Bez  
wzgledu, na ilość miłości jaką byś miał do PHP, trudno ci nie zgodzić się  
przynajmniej z tym wnioskiem.

--
JZ http://blog.zabiello.com

On 4 Lis, 14:18, pakalk <pak...@gmail.com> wrote:
> > var_dump(strtotime('2003/02/32')); # => false
> > echo strftime("%Y/%m/%d", (strtotime('2003/02/32'))); # 1970/01/01
>
> > Nieprzewidywalność i zero intuicyjności to najwidocznie integralna cecha  
> > pehapa. W tym wypadku bezmyślnie zakłada że każdy miesiąc może mieć do 31  
> > dni.
>
> Widac wykonuje tylko podstawowe sprawdzenia, bo..
>
> "The function expects to be given a string containing a US English
> date format "
>
> Ale przeciez nie warto stosowac funkcji zgodnie z ich przeznaczeniem,
> tylko wymagac od nich urojonych wlasciwosci.

php > var_dump(date('Y-m-d', strtotime('February 30, 2009')));
string(10) "2009-03-02"
php > var_dump(date('Y-m-d', strtotime('2009/02/30')));
string(10) "2009-03-02"
php > var_dump(date('Y-m-d', strtotime('2009-02-30')));
string(10) "2009-03-02"

i kolejna ciekawostka: http://www.php.net/manual/en/function.strtotime.php#93898

marcin

On Nov 6, 10:53 am, Marcin Nowak <marcin.j.no...@gmail.com> wrote:
>
> i kolejna ciekawostka:http://www.php.net/manual/en/function.strtotime.php#93898
>

Akurat to jest calkiem poprawne (a przynajmniej przewidywalne)
zachowanie (przejscie z roku nieprzestepnego na przestepny dodaje
jeden dzien, a sprawdzenie w jakim roku sie znajdujemy najwyrazniej
odbywa sie w kontekscie daty wyjsciowej do obliczen).

--

Jak chcecie dobry przykład, to Wam podrzucę z dzisiaj: realpath().
Jeśli plik nie istnieje to zwraca false. Chcialem na przykladzie
pythona pokazac, ze rzeczywiscie jest lepszy, ale pierwsze co dostalem
to zgloszenia bugow z ta funkcja ;) :P W kazdym razie u mnie dziala
ona tak jak trzeba (choc nie wykrywa linku symbolicznego pod cygwinem
- nie wiem czy moze).

Jaroslaw Zabiello wrote:
> Albo może coś z unikodem?
> 
> #-*-* coding: utf-8 -*-
> x = u"zażółć gęślą jaźń"
> print x.upper() # ZAŻÓŁĆ GĘŚLĄ JAŹŃ

mb_internal_encoding('UTF-8');
$x = 'zażółć gęślą jaźń';
echo mb_strtoupper($x); // ZAŻÓŁĆ GĘŚLĄ JAŹŃ

Jaroslaw Zabiello powiada:
> On Wed, 18 Nov 2009 13:00:11 -0000, pakalk <pakalk@gmail.com> wrote:
>
>> forki masz
>
> Ale nie masz wątków. Nie jesteś w stanie napisać żadnej aplikacji 
> webowej pracującej w trybie serwletowym. Nie jesteś też w stanie 
> użyć pehapa do zautomatyzowania wielowątkowych zadań odpalanych 
> z konsoli (a utrzymywałeś że php nadaje się też do pisnia skryptów 
> shellowych, dosyć kiepsko się nadaje). 

No zaraz, akurat ,,wielowątkowe'' zadania odpalane z konsoli są 
AFAIK zaimplementowane (w bashu) właśnie forkami a nie threadami.
Poza tym nie wiem czemu się upierasz przy konkretnym środku - 
wątki nie są celem samym w sobie. Jeśli chcesz pisać program 
korzystujący ze współbieżności, to można ją zrealizować również 
procesami. Czasami fajnie mieć do wyboru inną opcję, ale pełnym 
wypasem nie są wątki tylko stacklessowe tasklety kontynuacyjne.

Piotr Sawicki

On Nov 19, 1:55 pm, Piotr Sawicki <ps171...@students.mimuw.edu.pl>
wrote:
> Jaroslaw Zabiello powiada:
>
> > On Wed, 18 Nov 2009 13:00:11 -0000, pakalk <pak...@gmail.com> wrote:
>
> >> forki masz
>
> > Ale nie masz wątków. Nie jesteś w stanie napisać żadnej aplikacji
> > webowej pracującej w trybie serwletowym. Nie jesteś też w stanie
> > użyć pehapa do zautomatyzowania wielowątkowych zadań odpalanych
> > z konsoli (a utrzymywałeś że php nadaje się też do pisnia skryptów
> > shellowych, dosyć kiepsko się nadaje).
>
> No zaraz, akurat ,,wielowątkowe'' zadania odpalane z konsoli są
> AFAIK zaimplementowane (w bashu) właśnie forkami a nie threadami.
Uhmm... what? Co to są zadania wielowątkowe w bashu? Shell "by design"
odpala procesy i łączy deskryptory.

> Poza tym nie wiem czemu się upierasz przy konkretnym środku -
> wątki nie są celem samym w sobie. Jeśli chcesz pisać program
> korzystający ze współbieżności, to można ją zrealizować również
> procesami.
Tak, ale czasami jest to niepotrzebnie skomplikowane i wolniejsze.
Procesy nie dzielą pamięci, więc wymiana informacji musi się odbywać
przez PIPE lub mechanizmy IPC. To jeszcze nie byłoby takie złe, gdyby
nie fakt, że nie dzielą INTERPRETERA. Więc każdy obiekt musisz
serializować zanim przekażesz go do drugiego interpretera. To dużo
większy narzut niż po prostu korzystanie z tego samego adresu w
pamięci. No i oczywiście w ten sposób masz już 2 GC, a nie jeden. Dla
tego procesy są dobre tylko dla luźno powiązanych zadań.

>
> Piotr Sawicki

Łukasz Rekucki powiada:
>> >> forki masz
>>
>> > Ale nie masz wątków. Nie jesteś w stanie napisać żadnej aplikacji
>> > webowej pracującej w trybie serwletowym. Nie jesteś też w stanie
>> > użyć pehapa do zautomatyzowania wielowątkowych zadań odpalanych
>> > z konsoli (a utrzymywałeś że php nadaje się też do pisnia skryptów
>> > shellowych, dosyć kiepsko się nadaje).
>>
>> No zaraz, akurat ,,wielowątkowe'' zadania odpalane z konsoli są
>> AFAIK zaimplementowane (w bashu) właśnie forkami a nie threadami.
> Uhmm... what? Co to są zadania wielowątkowe w bashu? Shell "by design"
> odpala procesy i łączy deskryptory.

To właśnie napisałem...

>> Poza tym nie wiem czemu się upierasz przy konkretnym środku -
>> wątki nie są celem samym w sobie. Jeśli chcesz pisać program
>> korzystający ze współbieżności, to można ją zrealizować również
>> procesami.
> Tak, ale czasami jest to niepotrzebnie skomplikowane i wolniejsze.

Komplikacja zależy od systemu operacyjnego, generalnie wraz 
z przyspieszaniem sprzętu context switching robi się pomijalny 
czasowo (w php/pythonie nikt się nie będzie bił o mikrosekundy).

> Procesy nie dzielą pamięci, więc wymiana informacji musi 
> się odbywać przez PIPE lub mechanizmy IPC. 

A jednym z mechanizmów IPC jest właśnie współdzielenie pamięci. 

> To jeszcze nie byłoby takie złe, gdyby nie fakt, 
> że nie dzielą INTERPRETERA. 

Jego kod mogą dzielić, nie dzielą danych - no i bardzo dobrze,
z punktu widzenia niezawodności i bezpieczeństwa to zaleta.

> Więc każdy obiekt musisz serializować zanim 
> przekażesz go do drugiego interpretera. 

Da się to schować za biblioteką/transformatorem/dekoratorem/proxy.

> pamięci. No i oczywiście w ten sposób masz już 2 GC, a nie jeden. 

Oba mają połowę roboty, obciążenie się lepiej rozkłada.

> Dla tego procesy są dobre tylko dla luźno powiązanych zadań.

Powiązanie zadań to w dużym stopniu cecha wybranej implementacji,
zawsze można inaczej pokroić na procesy (a nie odzwierciedlać wątki). 

Piotr Sawicki

On 19 Lis, 17:24, Piotr Sawicki <ps171...@students.mimuw.edu.pl>
wrote:
> Łukasz Rekucki powiada:
>
> >> >> forki masz
>
> >> > Ale nie masz wątków. Nie jesteś w stanie napisać żadnej aplikacji
> >> > webowej pracującej w trybie serwletowym. Nie jesteś też w stanie
> >> > użyć pehapa do zautomatyzowania wielowątkowych zadań odpalanych
> >> > z konsoli (a utrzymywałeś że php nadaje się też do pisnia skryptów
> >> > shellowych, dosyć kiepsko się nadaje).
>
> >> No zaraz, akurat ,,wielowątkowe'' zadania odpalane z konsoli są
> >> AFAIK zaimplementowane (w bashu) właśnie forkami a nie threadami.
> > Uhmm... what? Co to są zadania wielowątkowe w bashu? Shell "by design"
> > odpala procesy i łączy deskryptory.
>
> To właśnie napisałem...
>
> >> Poza tym nie wiem czemu się upierasz przy konkretnym środku -
> >> wątki nie są celem samym w sobie. Jeśli chcesz pisać program
> >> korzystający ze współbieżności, to można ją zrealizować również
> >> procesami.
> > Tak, ale czasami jest to niepotrzebnie skomplikowane i wolniejsze.
>
> Komplikacja zależy od systemu operacyjnego, generalnie wraz
> z przyspieszaniem sprzętu context switching robi się pomijalny
> czasowo (w php/pythonie nikt się nie będzie bił o mikrosekundy).
Nie chodziło mi o context switching. Patrz niżej.

>
> > Procesy nie dzielą pamięci, więc wymiana informacji musi
> > się odbywać przez PIPE lub mechanizmy IPC.
>
> A jednym z mechanizmów IPC jest właśnie współdzielenie pamięci.
Dlatego o tym wspomniałem, ale jak dalej pisze:
>
> > To jeszcze nie byłoby takie złe, gdyby nie fakt,
> > że nie dzielą INTERPRETERA.
>
> Jego kod mogą dzielić, nie dzielą danych - no i bardzo dobrze,
> z punktu widzenia niezawodności i bezpieczeństwa to zaleta.
Brak dzielenia danych => Niezależnie od tego czy użyjesz SHM czy
kolejek, to i tak musisz robić serializację wszystkich obiektów, które
mają być dostępne w obu procesach.

>
> > Więc każdy obiekt musisz serializować zanim
> > przekażesz go do drugiego interpretera.
>
> Da się to schować za biblioteką/transformatorem/dekoratorem/proxy.
No tak (done: http://docs.python.org/library/multiprocessing.html)
tylko, że serializacja KOSZTUJE.

>
> > pamięci. No i oczywiście w ten sposób masz już 2 GC, a nie jeden.
>
> Oba mają połowę roboty, obciążenie się lepiej rozkłada.
Skąd wniosek, że mają połowę roboty ? Bo na każdy dzielony fragment
pamięci przypadają 2 elementy proxy. Każdy element, który dodasz do
Queue będzie istniał u obu procesów. No i trzeba jeszcze zarządzać
pamięcią dzieloną...

>
> > Dla tego procesy są dobre tylko dla luźno powiązanych zadań.
>
> Powiązanie zadań to w dużym stopniu cecha wybranej implementacji,
> zawsze można inaczej pokroić na procesy (a nie odzwierciedlać wątki).
Jak zmniejszyć ilość przekazywanych danych w schemacie z dzielonym
stanem (typowy przypadek - aplikacja z GUI) dzieląc inaczej na
"procesy" ? Może są jakieś magiczne sztuczki, których nie znam.

>
> Piotr Sawicki
>

Przemek Rekucki powiada:

>> >> również procesami.
>> > Tak, ale czasami jest to niepotrzebnie skomplikowane i wolniejsze.
>>
>> Komplikacja zależy od systemu operacyjnego, generalnie wraz
>> z przyspieszaniem sprzętu context switching robi się pomijalny
>> czasowo (w php/pythonie nikt się nie będzie bił o mikrosekundy).
> Nie chodziło mi o context switching. Patrz niżej.

Jak pominiemy context switching, to procesy nie są wolniejsze od wątków.

> Brak dzielenia danych => Niezależnie od tego czy użyjesz SHM czy
> kolejek, to i tak musisz robić serializację wszystkich obiektów, 
> które mają być dostępne w obu procesach.

Dla współdostępnych obiektów dane trzymasz w pamięci dzielonej,
a operacji oba procesy dokonują tam przez własne proxy.

>> > pamięci. No i oczywiście w ten sposób masz już 2 GC, a nie jeden.
>>
>> Oba mają połowę roboty, obciążenie się lepiej rozkłada.
> Skąd wniosek, że mają połowę roboty ? Bo na każdy dzielony 
> fragment pamięci przypadają 2 elementy proxy. 

Z którymi GC nie ma nic do roboty. Jeśli między procesami miałyby
krążyć miriady ciągle powstających i sprzątanych obiektów, to problem 
leży w kompozycji programu a nie mechanizmie wieloprocesowości.

>> Powiązanie zadań to w dużym stopniu cecha wybranej implementacji,
>> zawsze można inaczej pokroić na procesy (a nie odzwierciedlać wątki).
> Jak zmniejszyć ilość przekazywanych danych w schemacie z dzielonym
> stanem (typowy przypadek - aplikacja z GUI) dzieląc inaczej na
> "procesy" ? Może są jakieś magiczne sztuczki, których nie znam.

Schemat z sekwencjami imperatywów dłubiących w globalnym stanie to 
inne określenie na technikę realizowania współbieżności poprzez wątki.
Skoro pytanie brzmi jak zaprogramować wątki bez wątków, to ja się 
zgodzę, że zawiedziony będzie każdy kto liczył na zastąpienie forkami 
wywołań create_thread i dalsze dłubanie w globalnym stanie. Natomiast
można bez wątków programować współbieżnie używając innej metodologii 
- skoro nalegasz to możemy taką umiejętność nazywać magiczną sztuczką.


Piotr Sawicki

On Nov 20, 2:15 pm, Piotr Sawicki <ps171...@students.mimuw.edu.pl>
wrote:
> Przemek Rekucki powiada:
>
> >> >> również procesami.
> >> > Tak, ale czasami jest to niepotrzebnie skomplikowane i wolniejsze.
>
> >> Komplikacja zależy od systemu operacyjnego, generalnie wraz
> >> z przyspieszaniem sprzętu context switching robi się pomijalny
> >> czasowo (w php/pythonie nikt się nie będzie bił o mikrosekundy).
> > Nie chodziło mi o context switching. Patrz niżej.
>
> Jak pominiemy context switching, to procesy nie są wolniejsze od wątków.

Wątki nie eliminują przełączania kontekstu. Przynajmniej pthreads,
chyba że mowa o taskletach ze Stackless.

Bart Ogryczak powiada:

>> > Nie chodziło mi o context switching. Patrz niżej.
>>
>> Jak pominiemy context switching, to procesy nie są wolniejsze od wątków.
>
> Wątki nie eliminują przełączania kontekstu. Przynajmniej pthreads,

Ta konkretna implementacja linuksowa. 
No i nie zmienia to prawdziwości implikacji.

Piotr Sawicki

Dnia 20-11-2009 o 18:59:09 pakalk <pakalk@gmail.com> wybełkotał:


> Stek bzdur wypisujecie o PHP, bez zadnych przykladow

[...]

Dalej już nie chce mi się czytać. Szkoda dalszego czasu dla na dyskusję z  
takim idiotą. Idź się bawić do innej piaskownicy.

-- 
JZ http://blog.zabiello.com

You can't fix PHP. The only hope is to nuke it from orbit.

PHP cannot be fixed. I've said it before and I'll say it again: its  
developers don't have a clue about language design, have no interest in  
whatever happened in the last 40 years of language design, and have no  
concept of security. It's a kitchen-sink-and-your-mom sort of language  
like VB6, with no architecture, no philosophy, and no concept of what  
constitutes good programming practices.

If I may refer to some examples, look at what PHP's creator, Rasmus  
Lerdof, considers to be good code.

The syntax is brain-dead and unfixable. It looks ugly to the eye and  
unorganized. Functions don't follow any convention on order parameters or  
naming. Classes are a hack that try to take from Java, possibly the worst  
option available. There is no metaprogramming to speak of.

Vide: http://www.reddit.com/r/programming/comments/a6ffj/php_vs_python/

-- 
JZ http://blog.zabiello.com

On Nov 21, 3:11 pm, "Jaroslaw Zabiello" <use...@onet.eu> wrote:
> Dnia 20-11-2009 o 18:59:09 pakalk <pak...@gmail.com> wybełkotał:
>
> > Stek bzdur wypisujecie o PHP, bez zadnych przykladow
>
> [...]
>
> Dalej już nie chce mi się czytać. Szkoda dalszego czasu dla na dyskusję z  
> takim idiotą. Idź się bawić do innej piaskownicy.
>

Jeszcze tylko...

Poza tym, ze to obelga, to ma jakies podstawy? Ja jasno wymienilem
dlaczego Wasze wypowiedzi sa idiotyczne. A moje? Czemu? W ktorym
miejscu np. sklamalem?


Aha i widze, ze nauczyles sie rzucac linkami. No, musisz troche
potrenowac, bo link do komentarza o tworcy PHP/FI jest srednim
argumentem przemawiajacym za czymkolwiek. Inaczej: dalej wrzucasz
subiektywne argumenty.

>  * Jython - kilka razy szybszy od CPython, tylko trochę wolniejszy od
> zwykłej Javy

To jest zwyczajna nieprawda, przynajmniej w ogólności. Robiłem parę
prostych benchmarków (dla kodu "algorytmicznego") i Jython był znacznie
*wolniejszy* od CPythona. Przykładowo, kawałek skryptu liczącego liczby
pierwsze sitem jest na jythonie sześć razy wolniejszy:

$ time python pierwsze.py
Jest 348514 liczb pierwszych mniejszych od 5000000

real	0m1.521s
user	0m1.464s
sys	0m0.032s

$ time jython pierwsze.py
Jest 348514 liczb pierwszych mniejszych od 5000000

real	0m9.596s
user	0m10.441s
sys	0m0.256s

$ python
Python 2.6.4 (r264:75706, Nov  2 2009, 14:38:03) 
[GCC 4.4.1] on linux2

$ jython
Jython 2.5.1 (Release_2_5_1:6813, Sep 26 2009, 13:47:54) 
[Java HotSpot(TM) Server VM (Sun Microsystems Inc.)] on java1.6.0_16

Skrypt (przypadkowy skrawek z okołoprojecteulerowych zabaw):

---------------------------------------------------------------
# -*- coding: utf-8 -*-

from math import sqrt, ceil, log
from itertools import cycle

def primes_up_to_sieve_odd(maximum):
    """
    Minimalne kółko - sprawdzamy tylko 2t+1 i skaczemy o 2
    """
    # is_prime[h] to charakterystyka 2h+1
    is_prime = [True for h in xrange(0, maximum/2 + 1)]
    x = 3
    while x * x <= maximum:
        if is_prime[(x-1)/2]:
            for y in xrange(x*x, maximum+1, 2*x):
                #print "Clearing %d/%d for %d" % (y,(y-1)/2, x)
                is_prime[(y-1)/2] = False
        x += 2
    return [2] + [ 2*h + 1 for h in xrange(1,maximum/2) if is_prime[h] ]

MAX = 5000000
primes = primes_up_to_sieve_odd(MAX)
print "Jest %d liczb pierwszych mniejszych od %d" % (len(primes), MAX)
---------------------------------------------------------------

On Tue, 24 Nov 2009 10:08:49 -0000, Marcin Kasperski  
<Marcin.Kasperski@mekk.waw.pl> wrote:

>>  * Jython - kilka razy szybszy od CPython, tylko trochę wolniejszy od
>> zwykłej Javy
>
> To jest zwyczajna nieprawda, przynajmniej w ogólności. Robiłem parę
> prostych benchmarków (dla kodu "algorytmicznego") i Jython był znacznie
> *wolniejszy* od CPythona. Przykładowo, kawałek skryptu liczącego liczby
> pierwsze sitem jest na jythonie sześć razy wolniejszy:
>
> $ time python pierwsze.py
> Jest 348514 liczb pierwszych mniejszych od 5000000
>
> real	0m1.521s
> user	0m1.464s
> sys	0m0.032s
>
> $ time jython pierwsze.py
> Jest 348514 liczb pierwszych mniejszych od 5000000
>
> real	0m9.596s
> user	0m10.441s
> sys	0m0.256s
>
> $ python
> Python 2.6.4 (r264:75706, Nov  2 2009, 14:38:03)
> [GCC 4.4.1] on linux2
>
> $ jython
> Jython 2.5.1 (Release_2_5_1:6813, Sep 26 2009, 13:47:54)
> [Java HotSpot(TM) Server VM (Sun Microsystems Inc.)] on java1.6.0_16

Doliczyłeś start JVM, i nawet nie rozgrzałeś HotSpota. Takie testowanie to  
o kant dupy potłuc.

Odpaliłem to samo na MacPro zwiększając tylko ilość iteracji i dodałem  
wew. pętlę aby dać szansę się rozgrzać HotSpotowi. Zobacz jak przyśpiesza  
w kolejnych wywołaniach.

[...]
import time.time
MAX = 10000000
for i in range(10):
     t = time.time()
     primes = primes_up_to_sieve_odd(MAX)
     czas = time.time() - t
     print("Jest %d liczb pierwszych mniejszych od %d" % (len(primes),  
MAX), " czas: %s" % czas)

$ python
Python 2.6.4 (r264:75706, Nov 13 2009, 09:31:24)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin


$ jython
Jython 2.5.1+ (trunk:6949, lis 24 2009, 11:11:03)
[Java HotSpot(TM) 64-Bit Server VM (Apple Inc.)] on java1.6.0_15

$ python prime.py
('Jest 664579 liczb pierwszych mniejszych od 10000000', ' czas:  
2.79573392868')
('Jest 664579 liczb pierwszych mniejszych od 10000000', ' czas:  
2.81609916687')
('Jest 664579 liczb pierwszych mniejszych od 10000000', ' czas:  
2.79001808167')
('Jest 664579 liczb pierwszych mniejszych od 10000000', ' czas:  
2.77355098724')
('Jest 664579 liczb pierwszych mniejszych od 10000000', ' czas:  
2.78277993202')
('Jest 664579 liczb pierwszych mniejszych od 10000000', ' czas:  
2.7743229866')
('Jest 664579 liczb pierwszych mniejszych od 10000000', ' czas:  
2.83567595482')
('Jest 664579 liczb pierwszych mniejszych od 10000000', ' czas:  
2.77783703804')
('Jest 664579 liczb pierwszych mniejszych od 10000000', ' czas: 2.921875')
('Jest 664579 liczb pierwszych mniejszych od 10000000', ' czas:  
2.79439401627')

$ jython -J-server prime.py
('Jest 664579 liczb pierwszych mniejszych od 10000000', ' czas:  
10.7590000629')
('Jest 664579 liczb pierwszych mniejszych od 10000000', ' czas:  
8.79200005531')
('Jest 664579 liczb pierwszych mniejszych od 10000000', ' czas:  
2.95500016212')
('Jest 664579 liczb pierwszych mniejszych od 10000000', ' czas:  
3.8710000515')
('Jest 664579 liczb pierwszych mniejszych od 10000000', ' czas:  
3.31699991226')
('Jest 664579 liczb pierwszych mniejszych od 10000000', ' czas:  
3.40400004387')
('Jest 664579 liczb pierwszych mniejszych od 10000000', ' czas:  
3.56200003624')
('Jest 664579 liczb pierwszych mniejszych od 10000000', ' czas:  
3.48500013351')
('Jest 664579 liczb pierwszych mniejszych od 10000000', ' czas:  
3.32299995422')
('Jest 664579 liczb pierwszych mniejszych od 10000000', ' czas:  
3.4279999733')

CPython jest w tym mikrobenchmarku szybszy, ale niedużo. Pewnie w innych  
będzie szybszy. A to jeszcze nie wszystko na co stać Jythona! Po  
pierwsze,  nie jest jeszcze porządnie zoptymalizowany, to wciąż wersja  
rozwojowa a nie stabilna. Po drugie, JDK7 powinno dać mu dodatkowego kopa,  
bo wprowadza optymalizacje dla języków dynamicznych.

-- 
JZ http://blog.zabiello.com

Dla odmiany inny prosty mikrobenchmark. Liczenie ciągu Fibonacciego. Tym  
razem CPython przegrywa z Jythonem.


# -*- coding: utf-8 -*-
 from timeit import time

def fib(n):
   if n <= 1: return n
   return fib(n - 1) + fib(n - 2)
for i in range(10):
   t = time.time()
   fib(35)
   print(time.time()-t)


$ python fibonacci.py
5.6540749073
5.64278578758
5.63702011108
5.62101387978
5.63334298134
5.647179842
5.62858891487
5.63060092926
5.62489700317
5.64799690247

$ jython -J-server fibonacci.py
4.79199981689
4.03499984741
4.03300023079
4.02399992943
3.99699997902
4.00100016594
3.99699997902
3.99900007248
4.00200009346
3.99799990654


On Tue, 24 Nov 2009 11:34:22 -0000, Jaroslaw Zabiello <usenet@onet.eu>  
wrote:

> On Tue, 24 Nov 2009 10:08:49 -0000, Marcin Kasperski  
> <Marcin.Kasperski@mekk.waw.pl> wrote:
>
>>>  * Jython - kilka razy szybszy od CPython, tylko trochę wolniejszy od
>>> zwykłej Javy
>>
>> To jest zwyczajna nieprawda, przynajmniej w ogólności. Robiłem parę
>> prostych benchmarków (dla kodu "algorytmicznego") i Jython był znacznie
>> *wolniejszy* od CPythona. Przykładowo, kawałek skryptu liczącego liczby
>> pierwsze sitem jest na jythonie sześć razy wolniejszy:
>>
>> $ time python pierwsze.py
>> Jest 348514 liczb pierwszych mniejszych od 5000000
>>
>> real	0m1.521s
>> user	0m1.464s
>> sys	0m0.032s
>>
>> $ time jython pierwsze.py
>> Jest 348514 liczb pierwszych mniejszych od 5000000
>>
>> real	0m9.596s
>> user	0m10.441s
>> sys	0m0.256s
>>
>> $ python
>> Python 2.6.4 (r264:75706, Nov  2 2009, 14:38:03)
>> [GCC 4.4.1] on linux2
>>
>> $ jython
>> Jython 2.5.1 (Release_2_5_1:6813, Sep 26 2009, 13:47:54)
>> [Java HotSpot(TM) Server VM (Sun Microsystems Inc.)] on java1.6.0_16
>
> Doliczyłeś start JVM, i nawet nie rozgrzałeś HotSpota. Takie testowanie  
> to o kant dupy potłuc.
>
> Odpaliłem to samo na MacPro zwiększając tylko ilość iteracji i dodałem  
> wew. pętlę aby dać szansę się rozgrzać HotSpotowi. Zobacz jak  
> przyśpiesza w kolejnych wywołaniach.
>
> [...]
> import time.time
> MAX = 10000000
> for i in range(10):
>      t = time.time()
>      primes = primes_up_to_sieve_odd(MAX)
>      czas = time.time() - t
>      print("Jest %d liczb pierwszych mniejszych od %d" % (len(primes),  
> MAX), " czas: %s" % czas)
>
> $ python
> Python 2.6.4 (r264:75706, Nov 13 2009, 09:31:24)
> [GCC 4.2.1 (Apple Inc. build 5646)] on darwin
>
>
> $ jython
> Jython 2.5.1+ (trunk:6949, lis 24 2009, 11:11:03)
> [Java HotSpot(TM) 64-Bit Server VM (Apple Inc.)] on java1.6.0_15
>
> $ python prime.py
> ('Jest 664579 liczb pierwszych mniejszych od 10000000', ' czas:  
> 2.79573392868')
> ('Jest 664579 liczb pierwszych mniejszych od 10000000', ' czas:  
> 2.81609916687')
> ('Jest 664579 liczb pierwszych mniejszych od 10000000', ' czas:  
> 2.79001808167')
> ('Jest 664579 liczb pierwszych mniejszych od 10000000', ' czas:  
> 2.77355098724')
> ('Jest 664579 liczb pierwszych mniejszych od 10000000', ' czas:  
> 2.78277993202')
> ('Jest 664579 liczb pierwszych mniejszych od 10000000', ' czas:  
> 2.7743229866')
> ('Jest 664579 liczb pierwszych mniejszych od 10000000', ' czas:  
> 2.83567595482')
> ('Jest 664579 liczb pierwszych mniejszych od 10000000', ' czas:  
> 2.77783703804')
> ('Jest 664579 liczb pierwszych mniejszych od 10000000', ' czas:  
> 2.921875')
> ('Jest 664579 liczb pierwszych mniejszych od 10000000', ' czas:  
> 2.79439401627')
>
> $ jython -J-server prime.py
> ('Jest 664579 liczb pierwszych mniejszych od 10000000', ' czas:  
> 10.7590000629')
> ('Jest 664579 liczb pierwszych mniejszych od 10000000', ' czas:  
> 8.79200005531')
> ('Jest 664579 liczb pierwszych mniejszych od 10000000', ' czas:  
> 2.95500016212')
> ('Jest 664579 liczb pierwszych mniejszych od 10000000', ' czas:  
> 3.8710000515')
> ('Jest 664579 liczb pierwszych mniejszych od 10000000', ' czas:  
> 3.31699991226')
> ('Jest 664579 liczb pierwszych mniejszych od 10000000', ' czas:  
> 3.40400004387')
> ('Jest 664579 liczb pierwszych mniejszych od 10000000', ' czas:  
> 3.56200003624')
> ('Jest 664579 liczb pierwszych mniejszych od 10000000', ' czas:  
> 3.48500013351')
> ('Jest 664579 liczb pierwszych mniejszych od 10000000', ' czas:  
> 3.32299995422')
> ('Jest 664579 liczb pierwszych mniejszych od 10000000', ' czas:  
> 3.4279999733')
>
> CPython jest w tym mikrobenchmarku szybszy, ale niedużo. Pewnie w innych  
> będzie szybszy. A to jeszcze nie wszystko na co stać Jythona! Po  
> pierwsze,  nie jest jeszcze porządnie zoptymalizowany, to wciąż wersja  
> rozwojowa a nie stabilna. Po drugie, JDK7 powinno dać mu dodatkowego  
> kopa, bo wprowadza optymalizacje dla języków dynamicznych.
>


-- 
JZ http://blog.zabiello.com

>>>  * Jython - kilka razy szybszy od CPython, tylko trochę wolniejszy od
>>> zwykłej Javy
>>
>> To jest zwyczajna nieprawda, (...)

> Doliczyłeś start JVM, i nawet nie rozgrzałeś HotSpota. 

Start CPythona też doliczyłem :-P 
Może trzeba dodefiniować pojęcie "szybszy" ale dla mnie nie jest
ono synonimem pojęcia "szybszy począwszy od tysięcznego powtórzenia
tego samego kodu"...

Tak czy siak, z Twojego benchmarku równie pięknie wychodzi, że
twierdzenie jakoby Jython był "kilka razy szybszy od CPython" jest
zdecydowanie fałszywe.

Co do potencjału, to poczekajmy czy/kiedy się ziści (a czekając
pamiętajmy ile lat jython stał na 2.2). Na razie Wierzbicki odszedł z
Suna i za rozwój Jythona nikt już nie płaci.

"Jaroslaw Zabiello" <usenet@onet.eu> writes:

> Dla odmiany inny prosty mikrobenchmark. Liczenie ciągu
> Fibonacciego. (...)
>
> def fib(n):
>   if n <= 1: return n
>   return fib(n - 1) + fib(n - 2)

To jest atak na przepełnienie stosu a nie mikrobenchmark. Porównujmy
jednak jakieś realne przykłady.

Dla następującego kodu:

from timeit import time

def fib(n):
  if n <= 1: return n
  a, b = 0, 1
  for k in range(1,n):
      a, b = b, a+b
  return b

for i in range(10):
  t = time.time()
  fib(35000)
  print(time.time()-t)

Mam:

$ python fibo_ja.py
0.0581130981445
0.0577919483185
0.0577850341797
0.0576169490814
0.0577661991119
0.0577838420868
0.0576441287994
0.057590007782
0.0577690601349
0.0581040382385

$ jython -J-server fibo_ja.py
0.406999826431
0.238000154495
0.110000133514
0.128999948502
0.111999988556
0.106999874115
0.103999853134
0.0949997901917
0.148000001907
0.0880000591278


PS Realnych przykładów zastosowań, w których jython wypadłby lepiej,
szukałbym w programach wielowątkowych

Aha, jeszcze jedno. Zaadaptowałem lekko Twój benchmark (morderstwo na
stosie) dodając psyco (oczywiście tylko przy cpythonie). Wynik w tym wypadku:

$ python fibo_zabiello.py 
0.51163816452
0.495419979095
0.494167089462
0.494843006134
0.492959022522
0.494037866592
0.511044025421
0.495035886765
0.495697975159
0.495857954025

$ jython -J-server fibo_zabiello.py 
8.29499983788
7.11400008202
7.17999982834
7.15900015831
7.18099999428
7.09899997711
7.16899991035
7.18099999428
7.14699983597
7.09300017357

Jak widać hotspoty hotspotami, psyco ma przy obliczeniach większy
potencjał.

PS Kod:

from timeit import time

try:
	import psyco
	psyco.full()
except ImportError:
	pass

def fib(n):
  if n <= 1: return n
  return fib(n - 1) + fib(n - 2)
for i in range(10):
  t = time.time()
  fib(35)
  print(time.time()-t)

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

On Tue, 24 Nov 2009 12:17:28 -0000, Marcin Kasperski  
<Marcin.Kasperski@mekk.waw.pl> wrote:

>> Dla odmiany inny prosty mikrobenchmark. Liczenie ciągu
>> Fibonacciego. (...)
>>
>> def fib(n):
>>   if n <= 1: return n
>>   return fib(n - 1) + fib(n - 2)
>
> To jest atak na przepełnienie stosu a nie mikrobenchmark.

Ja użyłem 35 wywołań rekorencyjnych, to nie było żadne przepełnienie stosu.

> PS Realnych przykładów zastosowań, w których jython wypadłby lepiej,
> szukałbym w programach wielowątkowych

To na pewno. Aczkolwiek, Jython jest jeszcze bardzo słabo zoptymalizowany,  
bo podobny kod odpalony na JRuby działa o wiele szybciej.


def fib(n)
   return n if n <= 1
   fib(n - 1) + fib(n - 2)
end
require "benchmark"
Benchmark.bm do |make|
   10.times do
     make.report do
       fib(35)
     end
   end
end

$ jruby -v
jruby 1.4.0 (ruby 1.8.7 patchlevel 174) (2009-11-12 6586) (Java  
HotSpot(TM) 64-Bit Server VM 1.6.0_15) [x86_64-java]

$ jruby -J-server -J-Djruby.compile.fastest=true fibonacci.rb
       user     system      total        real
   1.235000   0.000000   1.235000 (  1.206000)
   1.011000   0.000000   1.011000 (  1.011000)
   1.024000   0.000000   1.024000 (  1.024000)
   1.005000   0.000000   1.005000 (  1.005000)
   1.008000   0.000000   1.008000 (  1.008000)
   1.004000   0.000000   1.004000 (  1.004000)
   1.005000   0.000000   1.005000 (  1.005000)
   1.006000   0.000000   1.006000 (  1.006000)
   1.004000   0.000000   1.004000 (  1.003000)
   1.004000   0.000000   1.004000 (  1.005000)


$ jython -J-server fibonacci.py
5.2389998436
4.52499985695
4.5150001049
4.50999999046
4.5039999485
4.46400022507
4.45699977875
4.46099996567
4.46300005913
4.45899987221


-- 
JZ http://blog.zabiello.com

On Tue, 24 Nov 2009 12:21:02 -0000, Marcin Kasperski  
<Marcin.Kasperski@mekk.waw.pl> wrote:

> Jak widać hotspoty hotspotami, psyco ma przy obliczeniach większy
> potencjał.

Po pierwsze, Psyco jest bezużyteczne na systemach 64-bitowych. Ja już nie  
mam żadnego kompa na 32 bitach. Mój pecet śmiga na 64bit Win7, a MBP na  
64bit Snow Leopardzie. Przesiądziesz się na 64bity i po Psyco.

Po drugie, jak już wspominałem, Jython jeszcze przyśpieszy jak zostanie  
bardziej zoptymalizowany. Docelowo powinien być szybszy od JRuby, bo  
Python jest prostszym językiem (czyli łatwiej go optymalizować).

Po trzecie, JDK7 powinna znacznie przyśpieszyć wykonywanie bytecodu z  
języków dynamicznych.


Ogólnie, uważam, że dynamiczna kompilacja HotSpota ma znacznie większy  
potencjał niż kompilacja statyczna. HotSpot może adaptacyjnie dostosowywać  
się do kodu w locie i dokonywać dalszych optymalizacji dawno po tym jak  
program został uruchomiony. Zaś kod skompilowany statycznie (czyli  
wszystkie implemenatcje w C/C++) wszystko to, co miały do powiedzenia już  
powiedziały. Wszystko to, co był w stanie zoptymalizować, już zrobił przy  
kompilacji.

Jako ciekawostkę odpaliłem test z ciągiem Fibonacciego na MagLev'ie,  
smalltalkowej implementacji Ruby'go (pracuje na wirtualnej maszynie  
Smalltalka - GemStone) Dodam tylko. że to jest jeszcze kod alpha. MagLev  
jest szybszy od JRuby i deklasuje Jythona (bz Psyco).

$ maglev-ruby fibonacci.rb
       user     system      total        real
   0,770000   0,000000   0,770000 (  0,761437)
   0,760000   0,000000   0,760000 (  0,761376)
   0,760000   0,000000   0,760000 (  0,761401)
   0,760000   0,000000   0,760000 (  0,761282)
   0,760000   0,000000   0,760000 (  0,761309)
   0,760000   0,000000   0,760000 (  0,761423)
   0,760000   0,000000   0,760000 (  0,761418)
   0,770000   0,000000   0,770000 (  0,761349)
   0,760000   0,000000   0,760000 (  0,761353)
   0,760000   0,000000   0,760000 (  0,761390)

Dla ciekawych: http://www.infoq.com/news/2009/11/maglev-public-alpha. W  
końcu Ruby doczekał się dobrej bazy obiektowej. :) GemStone jest używany  
komercyjnie i optymalizowany od ponad 20 lat. Pomoć Smalltalk jest jakieś  
10x szybszy od Pythona. MagLev ma ambicję osiągnąć docelowo podobną  
wydajność.

-- 
JZ http://blog.zabiello.com

On Tue, 24 Nov 2009 12:07:38 -0000, Marcin Kasperski  
<Marcin.Kasperski@mekk.waw.pl> wrote:

>> Doliczyłeś start JVM, i nawet nie rozgrzałeś HotSpota.
>
> Start CPythona też doliczyłem :-P

Mógbyś się nie kompromitować. Start JVM jest nieporównywalnie dłuższy od  
startu jakiejkolwiek aplikacji napisanej w C. Poza tym, rozgrzanie  
HotSpota jest kluczowe bo pełną wydajność osiąga gdzieś po przekroczeniu 5  
iteracji.

> Tak czy siak, z Twojego benchmarku równie pięknie wychodzi, że
> twierdzenie jakoby Jython był "kilka razy szybszy od CPython" jest
> zdecydowanie fałszywe.

Ja tego nie napisałem. Z tego co widzę, to Jython jest czasem wolniejszy,  
czasem szybszy. Docelowo jednak na pewno będzie szybszy od CPythona z  
powodów które wyłuszczałem. Wystarczy zobaczyć analogiczną sytuacją CRuby  
vs JRuby. JRuby też był na początku sporo wolniejszy od CRuby, teraz go  
pokonuje z łatwością. I, jak mówiłem to jeszcze mnie koniec. JRUby  
przyśpiesza z każdą kolejną wersją JVM. A nowa Java 7 będzie dosyć  
kluczowa, bo zostanie dodana optymalizacja dla języków dynamicznych.  
Wszystkie automatycznie przyśpieszą. Z Jythonem włącznie. Nie mowię o  
przyśpieszeniu na wątkach, bo to jest oczywiste.

-- 
JZ http://blog.zabiello.com

Benchmark JVM'a na ścisłych pętlach z arytmetyką, to chyba
nieporozumienie (a już na pewno mierzenie czasu startu - to tak jakby
wliczać czas startu systemu operacyjnego do prędkości twojej
przeglądarki WWW). Prawda jest taka, że nikt nie prowadzi ścisłych
benchmarków na ten temat. Fakt, Jython 2.5 mocno zwolnił by dogonić ze
zmianami w języku, co nie zmienia faktu, że może być szybciej nawet
jeśli targetem jest JVM

Czy któryś z was zastanowił się, że autorzy CPython mając dużo więcej
swobody, a nic z tego nie wynika? Interpreter Ruby 1.9 już dawno
prześcignął CPythona, dlatego Google, które jest jednym z największych
użytkowników (o ile nie największym) pythona pracuję nad Unladen
Swallow:

>>  * 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

Co by tu zacytować.. może np.: http://lwn.net/Articles/332038/

"""
Still, Winter said, the team does keep in close contact with Python
designer Guido van Rossum (himself a Google employee) and other
members of the CPython team. "In our discussions with Guido and others
about how and where to merge our changes back into CPython, the idea
has been proposed that Unladen Swallow should merge into 3.x. 3.x is
the future of the language, and if 3.x is significantly faster than
2.x, that's an obvious incentive to port applications and libraries to
3.x. None of that is set in stone, and Guido may well change his
mind."
"""
Tak, to jest implementacja 2.6, bo zaspokaja to żywotne interesy
Google. Jednak nie od dziś słyszy się, że Guido rozważa uznanie US
jako nowej implementacji referencyjnej dla 3.x; Jak ktoś myślał, że to
moratorium to tylko dla zabawy, to niech się jeszcze zastanowi.

---

Co do "powolności" języków dynamicznych, proponuję poczytać i
potestować PyPy. I czy się to komuś podoba czy nie, to języki z
*opcjonalnym* typowaniem są przyszłością dla języków *ogólnego
przeznaczenia*.

>>> Doliczyłeś start JVM, i nawet nie rozgrzałeś HotSpota.
>>
>> Start CPythona też doliczyłem :-P
>
> Mógbyś się nie kompromitować. Start JVM jest nieporównywalnie dłuższy
> od startu jakiejkolwiek aplikacji napisanej w C.

.... i jest to istotna wada rozwiązań działających na JVM, którą w
dyskusjach o "szybkości" języka jak najbardziej można podnosić. Ot, jest
to np. powód dla którego JVMowe narzecza nie nadają się do pisania
skryptów, słabiej wypadają w programach które nie realizują w kółko
tych samych operacji (choćby - desktopowych) itd.

>> Tak czy siak, z Twojego benchmarku równie pięknie wychodzi, że
>> twierdzenie jakoby Jython był "kilka razy szybszy od CPython" jest
>> zdecydowanie fałszywe.
>
> Ja tego nie napisałem. 

Dobre i to ;-) 

> Z tego co widzę, to Jython jest czasem
> wolniejszy, czasem szybszy. 

To jeszcze pewnie sprawa OS-a, na moim Linuksie szybszy właściwie nie
bywa - możliwe, że linuksowy JVM jest gorzej zoptymalizowany od tego na
Mac i Win.

> Docelowo jednak na pewno będzie szybszy od CPythona z powodów które
> wyłuszczałem.

Pożyjemy - zobaczymy. Może będzie szybszy, może w ogóle go nie będzie bo
już nikt go nie będzie rozwijał, może unladden swallow połknie go na
śniadanie, może powstanie jakaś nowa genialna implementacja interpretera
która zmieni wszystko... Na dziś lepiej dyskutować o tym, co jest, nie o
tym, co być może będzie. 

Jeśli Tobie (albo komuś z czytających grupę) się chce, można by 
pociągnąć trochę sprawę konstruktywnie - próbując wymyśleć bardziej
różnorodny pakiet benchmarków.

--
Marcin Kasperski
http://notatnik.mekk.waw.pl

On Tue, 24 Nov 2009 16:10:53 -0000, Sebastian Kaliszewski  
<s.bez_spamu@remove.this.informa.and.that.pl> wrote:

>>> Jak widać hotspoty hotspotami, psyco ma przy obliczeniach większy
>>> potencjał.
>>  Po pierwsze, Psyco jest bezużyteczne na systemach 64-bitowych. Ja już  
>> nie mam żadnego kompa na 32 bitach. Mój pecet śmiga na 64bit Win7, a  
>> MBP na 64bit Snow Leopardzie. Przesiądziesz się na 64bity i po Psyco.
>
> Ależ skąd. I na Win7 i na Snow Leopardzie można odpalić soft 32bitowy.

Ale nie Psyco. Nie instaluje sie z MacPortów. A nawet jak uda ci się jakoś  
zainstalować, to mija to się z celem, bo Psyco nie działa na systemach  
64bitowych. Nic więc nie zostanie przyśpieszone.

> To nie tak. Common Lisp jest bardziej skomplikowany od obu

Żartujesz. Lisp jest bardziej skompilowany od Pythona czy Ruby?  
Niemożliwe. Lisp jest przecież bardzo prosty. Prawie nie ma w ogóle  
składni. Albo źle cię zrozumiałem.

> A Psyco to kompilacja statyczna?

Nie znam bebechów, ale to chyab potrafi optymalizować tylko raz. A HotSpot  
dokonuje dynamicznych optymalizacji długo potem.

>> HotSpot może adaptacyjnie dostosowywać się do kodu w locie i dokonywać  
>> dalszych optymalizacji dawno po tym jak program został uruchomiony. Zaś  
>> kod skompilowany statycznie (czyli wszystkie implemenatcje w C/C++)
>
> Ależ nie wszystkie. Patrz choćby LLVM.

Mogę się mylić, ale to chyba nie działa tak jak HotSpot. Nie sądzę aby  
potrafił dokonywać takich optymalizacji jak HotSpot.

>> wszystko to, co miały do powiedzenia już powiedziały. Wszystko to, co  
>> był w stanie zoptymalizować, już zrobił przy kompilacji.
>
> Co nie przeszkadza w kompilowaniu na podstawioe danych z profilowania  
> (profile guided optimizations). W dodatku nie ma narzutu na profilowanie  
> i kompilację w locie.

Czyli jednak jest tak jak się domyślalem. Staje na rzęsach aby  
zoptymalizować kod lecz tylko przed jego uruchomieniem. HotSpot nie ma  
tych ograniczeń. Potrafi dostosować się do zmiennych zachowań programu.  
Ten "narzut" do przewaga kompilacji dynamicznej, a nie jej wada.

-- 
JZ http://blog.zabiello.com

Jaroslaw Zabiello wrote:
> On Tue, 24 Nov 2009 12:21:02 -0000, Marcin Kasperski 
> <Marcin.Kasperski@mekk.waw.pl> wrote:
> 
>> Jak widać hotspoty hotspotami, psyco ma przy obliczeniach większy
>> potencjał.
> 
> Po pierwsze, Psyco jest bezużyteczne na systemach 64-bitowych. Ja już 
> nie mam żadnego kompa na 32 bitach. Mój pecet śmiga na 64bit Win7, a MBP 
> na 64bit Snow Leopardzie. Przesiądziesz się na 64bity i po Psyco.

Ależ skąd. I na Win7 i na Snow Leopardzie można odpalić soft 32bitowy.

> Po drugie, jak już wspominałem, Jython jeszcze przyśpieszy jak zostanie 
> bardziej zoptymalizowany. Docelowo powinien być szybszy od JRuby, bo 
> Python jest prostszym językiem (czyli łatwiej go optymalizować).

To nie tak. Common Lisp jest bardziej skomplikowany od obu, a można go 
skompilować do szybkiego kodu. Tyle że w nim jest parę ułatwień 
(programista podpowiada kompilatorowi) i parę wrażliwych rzeczy ma 
dynamizm pod kontrolą (nie "dziedziczalne" typy prymitywne, panowanie 
nad podeinianiem funkcji, itd...)

> 
> Po trzecie, JDK7 powinna znacznie przyśpieszyć wykonywanie bytecodu z 
> języków dynamicznych.

To się okaże jak ta powinność przeniesie się do praktyki. Czy 
przypadkiem nie będzie to coś jak wsparcie w .Net dla języków 
dynamicznych które mało wniosło.

> 
> 
> Ogólnie, uważam, że dynamiczna kompilacja HotSpota ma znacznie większy 
> potencjał niż kompilacja statyczna.

A Psyco to kompilacja statyczna?

> HotSpot może adaptacyjnie 
> dostosowywać się do kodu w locie i dokonywać dalszych optymalizacji 
> dawno po tym jak program został uruchomiony. Zaś kod skompilowany 
> statycznie (czyli wszystkie implemenatcje w C/C++)

Ależ nie wszystkie. Patrz choćby LLVM.

> wszystko to, co miały 
> do powiedzenia już powiedziały. Wszystko to, co był w stanie 
> zoptymalizować, już zrobił przy kompilacji.

Co nie przeszkadza w kompilowaniu na podstawioe danych z profilowania 
(profile guided optimizations). W dodatku nie ma narzutu na profilowanie 
i kompilację w locie.


> [...]

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

Łukasz Rekucki wrote:
> Benchmark JVM'a na ścisłych pętlach z arytmetyką, to chyba
> nieporozumienie (a już na pewno mierzenie czasu startu - to tak jakby
> wliczać czas startu systemu operacyjnego do prędkości twojej
> przeglądarki WWW).

Ale nawet na tych ścisłych pętlach wypada gorzej od CPythona.

> Prawda jest taka, że nikt nie prowadzi ścisłych
> benchmarków na ten temat. Fakt, Jython 2.5 mocno zwolnił by dogonić ze
> zmianami w języku, co nie zmienia faktu, że może być szybciej nawet
> jeśli targetem jest JVM
> 
> Czy któryś z was zastanowił się, że autorzy CPython mając dużo więcej
> swobody, a nic z tego nie wynika?

Nikt się specjalnie nie zajmował poważniejszą optymalizacją wydajności 
CPythona -- poprawiano rózne drobiazgi tu i tam.

> Interpreter Ruby 1.9 już dawno
> prześcignął CPythona, dlatego Google, które jest jednym z największych
> użytkowników (o ile nie największym) pythona pracuję nad Unladen
> Swallow:

To nie Google pracuje, tylko 2 pracowników Google. Unladen Swallow nie 
jest projektem Google.

>>>  * 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
> 
> Co by tu zacytować.. może np.: http://lwn.net/Articles/332038/
> 
> """
> Still, Winter said, the team does keep in close contact with Python
> designer Guido van Rossum (himself a Google employee) and other
> members of the CPython team. "In our discussions with Guido and others
> about how and where to merge our changes back into CPython, the idea
> has been proposed that Unladen Swallow should merge into 3.x. 3.x is
> the future of the language, and if 3.x is significantly faster than
> 2.x, that's an obvious incentive to port applications and libraries to
> 3.x. None of that is set in stone, and Guido may well change his
> mind."
> """
> Tak, to jest implementacja 2.6, bo zaspokaja to żywotne interesy
> Google. Jednak nie od dziś słyszy się, że Guido rozważa uznanie US
> jako nowej implementacji referencyjnej dla 3.x; Jak ktoś myślał, że to
> moratorium to tylko dla zabawy, to niech się jeszcze zastanowi.

Chyba nieco nadinterpretujesz...


> Co do "powolności" języków dynamicznych, proponuję poczytać i
> potestować PyPy.

Nic specjalnego -- jeszcze mu wydajności dobrych implementacji Lispa czy 
Smalltalka nieco brakuje.


> I czy się to komuś podoba czy nie, to języki z
> *opcjonalnym* typowaniem są przyszłością dla języków *ogólnego
> przeznaczenia*.

Nie jestem taki pewien. Balans języków dynamicznych i statycznych 
utrzymuje się od wielu lat na zbliżonym poziomie.

Opcjonalne typowanie nie realizuje głównej zalety języków statycznie 
typowanych -- weryfikacji poprawności typologicznej (czyli istotnej 
części poprawności programu) jeszcze przed jego uruchomieniem.

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

Jaroslaw Zabiello wrote:
> On Tue, 24 Nov 2009 12:07:38 -0000, Marcin Kasperski 
> <Marcin.Kasperski@mekk.waw.pl> wrote:
> 
>>> Doliczyłeś start JVM, i nawet nie rozgrzałeś HotSpota.
>>
>> Start CPythona też doliczyłem :-P
> 
> Mógbyś się nie kompromitować. Start JVM jest nieporównywalnie dłuższy od 
> startu jakiejkolwiek aplikacji napisanej w C.

Mógłbyś się nie kompromitować. JVM to niby w czym jest napisany? :)

Start CPythona to nie tylko sam start apliacji napisanej w C [*], ale i 
kompilacja źródła samego programu w Pythonie a przede wszystkim 
wczytanie i wykonianie kodu inicjalizacyjnego runtime języka.


[*] Patrząc na czas startu paru aplikacji z KDE myślę że JVM startuje 
wielokrotnie szybciej.

> Poza tym, rozgrzanie 
> HotSpota jest kluczowe bo pełną wydajność osiąga gdzieś po przekroczeniu 
> 5 iteracji.

To już sobie z palca ssiesz. BTW w wielu przypadkach program coś liczący 
wykonywany jest raz.


> [...]

pzdr
\SK


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

On Tue, 24 Nov 2009 15:30:59 -0000, Marcin Kasperski  
<Marcin.Kasperski@mekk.waw.pl> wrote:

>> Mógbyś się nie kompromitować. Start JVM jest nieporównywalnie dłuższy
>> od startu jakiejkolwiek aplikacji napisanej w C.
>
> .... i jest to istotna wada rozwiązań działających na JVM, którą w
> dyskusjach o "szybkości" języka jak najbardziej można podnosić. Ot, jest
> to np. powód dla którego JVMowe narzecza nie nadają się do pisania
> skryptów,

O Nailgunie słyszał? Niweluje do zera narzut na start JVM.

> słabiej wypadają w programach które nie realizują w kółko
> tych samych operacji (choćby - desktopowych) itd.

Ta, akurat. A słyszał o Eclipse, Netbeans czy IntelliJ IDEA? Myślisz, że  
przepisanie na C++ coś by tu pomogło?

-- 
JZ http://blog.zabiello.com

On Tue, 24 Nov 2009 16:28:49 -0000, Sebastian Kaliszewski  
<s.bez_spamu@remove.this.informa.and.that.pl> wrote:

>>>> Doliczyłeś start JVM, i nawet nie rozgrzałeś HotSpota.
>>>
>>> Start CPythona też doliczyłem :-P
>>  Mógbyś się nie kompromitować. Start JVM jest nieporównywalnie dłuższy  
>> od startu jakiejkolwiek aplikacji napisanej w C.
>
> Mógłbyś się nie kompromitować. JVM to niby w czym jest napisany? :)

A kto testuje wykonanie kodu wliczając do tego odpalenie całego systemu  
operacyjnego? Bo ty dokładnie to zrobiłeś. Dla JAvy uwzględniłeś odpalenie  
systemu, a dla C - nie. Weź odpal sobie taką Vistę od zera i to dodaj do  
czasu wykonania programu. Wyjdzie na to samo albo nawet i gorzej. Bo  
narzut startu JVM można zlikwidować Nailgunem. A narzutu startu Windowsów,  
czy Linuksa nie zlikwidujesz w żaden sposób.

>> Poza tym, rozgrzanie HotSpota jest kluczowe bo pełną wydajność osiąga  
>> gdzieś po przekroczeniu 5 iteracji.
>
> To już sobie z palca ssiesz

A ty to ślepy jesteś? Weź odpal ten sam kod z -J-server i bez. Widać gołym  
okiem różnice jak wykonanie kolejnych pętl jest coraz szybsze.

> BTW w wielu przypadkach program coś liczący wykonywany jest raz.

Wtedy nie będzie tego efektu, zgoda. Dlatego JVM rządzi na serwerach.

-- 
JZ http://blog.zabiello.com

On Tue, 24 Nov 2009 18:25:06 -0000, Sebastian Kaliszewski  
<s.bez_spamu@remove.this.informa.and.that.pl> wrote:

>> Weź odpal sobie taką Vistę od zera i to dodaj do czasu wykonania  
>> programu. Wyjdzie na to samo albo nawet i gorzej. Bo narzut startu JVM  
>> można zlikwidować Nailgunem. A narzutu startu Windowsów, czy Linuksa  
>> nie zlikwidujesz w żaden sposób.
>
> O czy ty tu?!?

Owszem. Zapoznaj się z terminem: Nailgun.

> Nie odpalami Windowsów ani Linuksa tylko zwykły rantajm języka wraz z  
> jego maszyną wirtualną. I to w obu wypadkach (i Javy i Pythona).
>
>
>>>> Poza tym, rozgrzanie HotSpota jest kluczowe bo pełną wydajność osiąga  
>>>> gdzieś po przekroczeniu 5 iteracji.
>>>
>>> To już sobie z palca ssiesz
>>  A ty to ślepy jesteś? Weź odpal ten sam kod z -J-server i bez. Widać  
>> gołym okiem różnice jak wykonanie kolejnych pętl jest coraz szybsze.
>
> Ssiesz z palca, że akurat 5 iteracji. To zależy od kodu.

To czepiasz się tylko liczby 5? LOL. Dobra, nie będę się przy niej  
upierał, jeśli ci tylko o to chodzi. Natomiast będę się upierał, że   
odpalanie nie rozgrzanego HotSpota jak i odpalanie za każdym razem JVM bez  
Nailguna (skoro się upierasz żeby za każdym razem ładować całe środowisko  
Javy) i używanie takiej metody do pokazywania "jaka ta java jest wolna"  
jest po prostu głupie.

>>> BTW w wielu przypadkach program coś liczący wykonywany jest raz.
>>  Wtedy nie będzie tego efektu, zgoda. Dlatego JVM rządzi na serwerach.
>
> Zwłaszcza jak na serwerze (a raczej wielu równolegle pracujących  
> serwerach) chodzi np. interfejs webowy banku -- ot 1000 formatek, z  
> czego wiele używanych z rzadka. Potem zdziwienie, że kod w jakimś tam  
> Perlu działa zdecydowanie szybciej (mniej pamięci żre, klientom się  
> szybciej wyświetla).

Jak aplikacja jest źle napisana, to nic jej nie pomoże. Java pracując  
serwletowo jest dużo szybsza od serwerków pracujących w trybie cgi.  
Oczywiście serwletowo pracujący Python też będzie szybszy niż analogiczny  
PHP który niszczy i tworzy wszystkie obiekty za każdym requestem. Różnica  
będzie tym większa im większy kod.

-- 
JZ http://blog.zabiello.com

Jaroslaw Zabiello wrote:
> On Tue, 24 Nov 2009 16:10:53 -0000, Sebastian Kaliszewski 
> <s.bez_spamu@remove.this.informa.and.that.pl> wrote:
> 
>>>> Jak widać hotspoty hotspotami, psyco ma przy obliczeniach większy
>>>> potencjał.
>>>  Po pierwsze, Psyco jest bezużyteczne na systemach 64-bitowych. Ja 
>>> już nie mam żadnego kompa na 32 bitach. Mój pecet śmiga na 64bit 
>>> Win7, a MBP na 64bit Snow Leopardzie. Przesiądziesz się na 64bity i 
>>> po Psyco.
>>
>> Ależ skąd. I na Win7 i na Snow Leopardzie można odpalić soft 32bitowy.
> 
> Ale nie Psyco. Nie instaluje sie z MacPortów.

Musisz mieć po pierwsze 32bit Pythona wraz z wszystkimi potrzebnymi 
CPython-API bibliotekami.

> A nawet jak uda ci się 
> jakoś zainstalować, to mija to się z celem, bo Psyco nie działa na 
> systemach 64bitowych.

Działa.

> Nic więc nie zostanie przyśpieszone.

Oczywiście że zostanie. Kod 32bit na systemach 64bit też może być 
szybki, ba bywa że jest szybszy niż kod 64bit (mniejsze wskaźniki == 
mniejsza presja na cache)

>> To nie tak. Common Lisp jest bardziej skomplikowany od obu
> 
> Żartujesz. 

Bynajmniej.

> Lisp jest bardziej skompilowany od Pythona czy Ruby? 

Oczywiście. Pod względem skomplikowania może śmiało konkurować z C++.

> Niemożliwe. Lisp jest przecież bardzo prosty.

Był. 50 lat temu. Jak myślisz, czymu powstał Scheme (i to już 
kilkanaście lat po powstaniu Lispa, Common Lispa to wtedy jeszcze nie 
było)?

> Prawie nie ma w ogóle 
> składni.

Ale składnia to jest pikuś, to i tak znika zaraz po sparsowaniu. 
Znaczenie ma tkwiąca pod tą składnią semantyka. Zobacz sobie ile w tym 
Lispie jest sposobów samego tworzenia zmiennych (ot choćby dynamic 
scoping) przekazywania wartości itd.

> Albo źle cię zrozumiałem.

Tu nie ma wiele do rozumienia. Common Lisp to bardzo skomplikowany język.


> 
>> A Psyco to kompilacja statyczna?
> 
> Nie znam bebechów, ale to chyab potrafi optymalizować tylko raz.


To po prostu generuje kod maszynowy, gdy dojdzie do wniosku, że dany 
fragment należy skonwertować. To stosunkowo proste koncepcyjnie 
narzędzie (w końcu jedne człowiek toto napisał).

> A 
> HotSpot dokonuje dynamicznych optymalizacji długo potem.

HotSpot ma zaledwie parę poziomów optymalizacji -- najpierw tak jak 
Psyco (tylko określenie warunków kiedy tego dokonać jest bardziej 
rozbudowane) decyduje o wygenerowaniu prostego kodu maszynowego, potem 
przy bardziej ostrych warunkach podejmuje decyzję o ponownej kompilacji 
tego kodu przy włączeniu większej liczby optymalizacji. Tych stopnie 
jest mało (kilka i to małe kilka). To jest koncepcyjnie to co Psyco 
tylko włąśnie więcej stopniowe.

Niektóre JITy potrafią (ale wcale nie jestem pewien czy akurat HotSpot 
potrafi) zauważyć, że zmienił się charakter danych obsługiwanych przez 
dany kod i go przekompilować z innymi optymalzacjami. Problem taki, że 
takie sprawdzanie samo w sobie kosztuje i to sporo, zwykle sprowadza się 
do tego, że pewien procent przebiegów kodu jest interpretowany, lub w 
najlepszym razie wykonywany w wersji maszynowej bez optymalizacji, za to 
z włożoną instrumentacją dla pomiarów -- przy czym taki kod jest 
kilka-kilkanaście razy wolniejszy od zoptymalizowanego "do końca" ("do 
końca" czyli tak jak dany JIT potrafi) więc nawet zastąpienie tylko na 
1% przebiegów powoduje kilku-kilkunasto procentowe spowolnienie (co się 
często zaczyna mijać z celem).

> 
>>> HotSpot może adaptacyjnie dostosowywać się do kodu w locie i 
>>> dokonywać dalszych optymalizacji dawno po tym jak program został 
>>> uruchomiony. Zaś kod skompilowany statycznie (czyli wszystkie 
>>> implemenatcje w C/C++)
>>
>> Ależ nie wszystkie. Patrz choćby LLVM.
> 
> Mogę się mylić, ale to chyba nie działa tak jak HotSpot. Nie sądzę aby 
> potrafił dokonywać takich optymalizacji jak HotSpot.

LLVM AFAIR też ma kilka (co najmniej 2 ponad interpreter) poziomów 
optymalizacji. Oczywiście to nie jest to samo co HotSpot i optymalizacje 
są inne i sam kod pośredni (bajtkod) inny.

> 
>>> wszystko to, co miały do powiedzenia już powiedziały. Wszystko to, co 
>>> był w stanie zoptymalizować, już zrobił przy kompilacji.
>>
>> Co nie przeszkadza w kompilowaniu na podstawioe danych z profilowania 
>> (profile guided optimizations). W dodatku nie ma narzutu na 
>> profilowanie i kompilację w locie.
> 
> Czyli jednak jest tak jak się domyślalem. Staje na rzęsach aby 
> zoptymalizować kod lecz tylko przed jego uruchomieniem.

Ale tu nie chodzi o LLVM tylko o zwykły kompilator.

> HotSpot nie ma 
> tych ograniczeń. Potrafi dostosować się do zmiennych zachowań programu. 
> Ten "narzut" do przewaga kompilacji dynamicznej, a nie jej wada.

Zależnie od sytuacji on jest zaletą lub wadą. Najwydajniejszy kod dziś 
generuje, jak najbardziej statyczny, optymalizujący backend z zestawu 
kompilatorów Intela, kod ten generowany jest ze źródeł w C, C++ lub 
Fortranie (zależnie od frontendu kompilatora). HotSpoty i inne mu nie są 
w stanie podskoczyć. W odróżnieniu od HotSpota taki backend ma dużo 
mniejszą presję czasową -- jako że wiele problemów występujących podczas 
optymalizacji kodu jest NP-trudna (tj. odpowiadające im problemy 
decyzyjne są NP-zupełne) lub PSpace-trudna, to mała presja czasowa ma 
poważne znaczenie (można zastosować pełne a nie przybliżone rozwiązanie 
dla większych fragmentów kodu, można zastosować powolniejsze ale bliższe 
optimum heurystyki dla większych fragmentów).

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

Jaroslaw Zabiello wrote:
> On Tue, 24 Nov 2009 16:28:49 -0000, Sebastian Kaliszewski 
> <s.bez_spamu@remove.this.informa.and.that.pl> wrote:
> 
>>>>> Doliczyłeś start JVM, i nawet nie rozgrzałeś HotSpota.
>>>>
>>>> Start CPythona też doliczyłem :-P
>>>  Mógbyś się nie kompromitować. Start JVM jest nieporównywalnie 
>>> dłuższy od startu jakiejkolwiek aplikacji napisanej w C.
>>
>> Mógłbyś się nie kompromitować. JVM to niby w czym jest napisany? :)
> 
> A kto testuje wykonanie kodu wliczając do tego odpalenie całego systemu 
> operacyjnego?

Nikt systemu operacyjnego nie wlicza.

> Bo ty dokładnie to zrobiłeś.

Nie. JVM to nie system operacyjny tylko rantajm języka. A że jest 
potwornie ciężki... Cóż taki design.

> Dla JAvy uwzględniłeś 
> odpalenie systemu, a dla C - nie.

Oczywiście że tak. Czym może jest odpalenie skryptu pythonowego jak nie 
uruchomieniem całego rantajmu (maszyny wirtualnej) Pythona. Tu też masz 
nawet bajtkod, też masz wczytanie i wykonanie wszelkich startowych pakietów.

> Weź odpal sobie taką Vistę od zera i 
> to dodaj do czasu wykonania programu. Wyjdzie na to samo albo nawet i 
> gorzej. Bo narzut startu JVM można zlikwidować Nailgunem. A narzutu 
> startu Windowsów, czy Linuksa nie zlikwidujesz w żaden sposób.

O czy ty tu?!?

Nie odpalami Windowsów ani Linuksa tylko zwykły rantajm języka wraz z 
jego maszyną wirtualną. I to w obu wypadkach (i Javy i Pythona).


>>> Poza tym, rozgrzanie HotSpota jest kluczowe bo pełną wydajność osiąga 
>>> gdzieś po przekroczeniu 5 iteracji.
>>
>> To już sobie z palca ssiesz
> 
> A ty to ślepy jesteś? Weź odpal ten sam kod z -J-server i bez. Widać 
> gołym okiem różnice jak wykonanie kolejnych pętl jest coraz szybsze.

Ssiesz z palca, że akurat 5 iteracji. To zależy od kodu.


>> BTW w wielu przypadkach program coś liczący wykonywany jest raz.
> 
> Wtedy nie będzie tego efektu, zgoda. Dlatego JVM rządzi na serwerach.

Zwłaszcza jak na serwerze (a raczej wielu równolegle pracujących 
serwerach) chodzi np. interfejs webowy banku -- ot 1000 formatek, z 
czego wiele używanych z rzadka. Potem zdziwienie, że kod w jakimś tam 
Perlu działa zdecydowanie szybciej (mniej pamięci żre, klientom się 
szybciej wyświetla).

pzdr

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

Łukasz Rekucki <lrekucki@gmail.com> writes:

[...]

> Czy któryś z was zastanowił się, że autorzy CPython mając dużo więcej
> swobody, a nic z tego nie wynika? 

Nie wynika? Mając ograniczoną pulę zasobów można ją poświęcić niestety
tylko na zadania najważniejsze. Oczywiście każdy pod tym pojęciem
rozumie coś innego i dogodzić wszystkim się nie da.
Jednak imho filozofia Pythona brzmi mniej więcej tak:
"Implementacja Pythona ma być wystarczająco szybka, a zlokalizowane
wąskie gardła powinny być zastąpione rozszerzeniami w językach niższego
poziomu".
I faktycznie w rzeczywistych projektach (nie wydumanych benchmarkach)
tandem CPython + Cython jest właśnie _wystarczająco_ szybki.
Natomiast dostępne zasoby są kierowane na odcinki rozwoju samego języka
i bibliotek. Osobiście cieszę się, że ludzie pokroju Hettingera czy
Lundha tworzą użyteczne biblioteki, a nie tracą czas na podniecanie 
się mikrobenchmarkami.

> Interpreter Ruby 1.9 już dawno
> prześcignął CPythona, 

Zapewne prześcignął wielokrotnie, podobnie jak Jython CPythona, prawda?

> dlatego Google, które jest jednym z największych
> użytkowników (o ile nie największym) pythona pracuję nad Unladen
> Swallow:
>

Nad tym pracuje trzech łebskich facetów pracujących w Google,
a to duża różnica. Nie, to nie jest to samo co Sun i JVM.

>>>  * 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
>
> Co by tu zacytować.. może np.: http://lwn.net/Articles/332038/
>
> """
> Still, Winter said, the team does keep in close contact with Python
> designer Guido van Rossum (himself a Google employee) and other
> members of the CPython team. "In our discussions with Guido and others
> about how and where to merge our changes back into CPython, the idea
> has been proposed that Unladen Swallow should merge into 3.x. 3.x is
> the future of the language, and if 3.x is significantly faster than
> 2.x, that's an obvious incentive to port applications and libraries to
> 3.x. None of that is set in stone, and Guido may well change his
> mind."
> """
> Tak, to jest implementacja 2.6, bo zaspokaja to żywotne interesy
> Google. 

I chyba 90% wszystkich użytkowników Pythona póki co. To nie jest
żaden spisek, ale portowanie milionów linii kodu wymaga wiele
czasu, wysiłku i przede wszystkim motywacji.

> Jednak nie od dziś słyszy się, że Guido rozważa uznanie US
> jako nowej implementacji referencyjnej dla 3.x; 

Szczerze wątpię. Faza tego projektu jest zupełnie przedwczesna 
do takich deklaracji. Mógłbyś przytoczyć jakiś cytat?

> Jak ktoś myślał, że to
> moratorium to tylko dla zabawy, to niech się jeszcze zastanowi.

Zupełnie nie dla zabawy. Skorzystają na tym wszystkie implementacje,
a nie tylko US.

>
> ---
>
> Co do "powolności" języków dynamicznych, proponuję poczytać i
> potestować PyPy. I czy się to komuś podoba czy nie, to języki z
> *opcjonalnym* typowaniem są przyszłością dla języków *ogólnego
> przeznaczenia*.

No i tu bym się zgodził, jeśli mowa o wydajności zbliżonej do C.

RW

Jaroslaw Zabiello wrote:
>>> Weź odpal sobie taką Vistę od zera i to dodaj do czasu wykonania 
>>> programu. Wyjdzie na to samo albo nawet i gorzej. Bo narzut startu 
>>> JVM można zlikwidować Nailgunem. A narzutu startu Windowsów, czy 
>>> Linuksa nie zlikwidujesz w żaden sposób.
>>
>> O czy ty tu?!?
> 
> Owszem. Zapoznaj się z terminem: Nailgun.

No i? Co ma JVM do Windowsów czy Linuksa?

Czemu sam go nie użyłeś prezentując swój microbenchmark?

Poza tym, widzę że nadal ignorujesz fakt że w przypadku Pythona też masz 
koszt załadowania i uruchomienia "całego środowiska Pythona").

To nie moja wina, że Sun zrobił (spieprzył) Javę w ten sposób, że jej 
środowisko waży tony.

BTW. zdążyłem już zauważyć, że podniecasz się "terminami" bez zgłębienia 
sprawy. Ot, taka obserwacja na boku.



>> Nie odpalami Windowsów ani Linuksa tylko zwykły rantajm języka wraz z 
>> jego maszyną wirtualną. I to w obu wypadkach (i Javy i Pythona).
>>
>>
>>>>> Poza tym, rozgrzanie HotSpota jest kluczowe bo pełną wydajność 
>>>>> osiąga gdzieś po przekroczeniu 5 iteracji.
>>>>
>>>> To już sobie z palca ssiesz
>>>  A ty to ślepy jesteś? Weź odpal ten sam kod z -J-server i bez. Widać 
>>> gołym okiem różnice jak wykonanie kolejnych pętl jest coraz szybsze.
>>
>> Ssiesz z palca, że akurat 5 iteracji. To zależy od kodu.
> 
> To czepiasz się tylko liczby 5? LOL. Dobra, nie będę się przy niej 
> upierał, jeśli ci tylko o to chodzi. Natomiast będę się upierał, że  
> odpalanie nie rozgrzanego HotSpota jak i odpalanie za każdym razem JVM 
> bez Nailguna (skoro się upierasz żeby za każdym razem ładować całe 
> środowisko Javy) i używanie takiej metody do pokazywania "jaka ta java 
> jest wolna" jest po prostu głupie.

Co mi po rozgrzanym hotspocie, jeśli w real life nie będzie rozgrzany?
I owszem w real-life często nie jest rozhgrzany. W sofcie serwerowym też.

Po co mi piąty raz liczenie od zero pierwszych 35000 liczb fibonnaciego?

> 
>>>> BTW w wielu przypadkach program coś liczący wykonywany jest raz.
>>>  Wtedy nie będzie tego efektu, zgoda. Dlatego JVM rządzi na serwerach.
>>
>> Zwłaszcza jak na serwerze (a raczej wielu równolegle pracujących 
>> serwerach) chodzi np. interfejs webowy banku -- ot 1000 formatek, z 
>> czego wiele używanych z rzadka. Potem zdziwienie, że kod w jakimś tam 
>> Perlu działa zdecydowanie szybciej (mniej pamięci żre, klientom się 
>> szybciej wyświetla).

Widzę że nie dotarło.

Podkręcam jasność:

Jak masz 1000 różnych formatek z czego wiele rzadko używanych to efekt 
jest taki, że HotSpot ich nie będzie kompilował tylko zostawi 
interpretowane. W efekcie czego użytkownik będzie odczuwał paskudną 
ślamazarność serwisu w mniej używanych jego fragmentach.

> 
> Jak aplikacja jest źle napisana, to nic jej nie pomoże.

Przyjmij, że jest dobrze napisana.

> Java pracując 
> serwletowo jest dużo szybsza od serwerków pracujących w trybie cgi. 

Co ma do tego wszystkiego CGI?

> Oczywiście serwletowo pracujący Python też będzie szybszy niż 
> analogiczny PHP który niszczy i tworzy wszystkie obiekty za każdym 
> requestem. Różnica będzie tym większa im większy kod.
> 

Co to ma do tego o czym napisałem?

pzdr
\SK

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

Jaroslaw Zabiello wrote:
> On Tue, 24 Nov 2009 15:30:59 -0000, Marcin Kasperski 
> <Marcin.Kasperski@mekk.waw.pl> wrote:
> 
>>> Mógbyś się nie kompromitować. Start JVM jest nieporównywalnie dłuższy
>>> od startu jakiejkolwiek aplikacji napisanej w C.
>>
>> .... i jest to istotna wada rozwiązań działających na JVM, którą w
>> dyskusjach o "szybkości" języka jak najbardziej można podnosić. Ot, jest
>> to np. powód dla którego JVMowe narzecza nie nadają się do pisania
>> skryptów,
> 
> O Nailgunie słyszał? Niweluje do zera narzut na start JVM.
> 
>> słabiej wypadają w programach które nie realizują w kółko
>> tych samych operacji (choćby - desktopowych) itd.
> 
> Ta, akurat. A słyszał o Eclipse, Netbeans czy IntelliJ IDEA?

I jak to działa? Ach, niezbyt szybko... i żre przy tym pamięci jakby tam 
nie wiadomo co edytowano.

A i tak porobiono tam niezłą rzeźbę, typu natywne widgety (czytaj 
zrealizowane w C czy C++ i połączone z Javą).

> Myślisz, że 
> przepisanie na C++ coś by tu pomogło?

Jak widać już samo zrealizowanie widgetów w C++ pomogło.

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

On Oct 30, 9:14 am, Grzegorz Staniak <gstan...@wp.pl> wrote:
> On 30.10.2009, pakalk <pak...@gmail.com> wroted:
>
> >> Zapytaj kogoś, kto miał na studiach zajęcia ze struktur danych.
> >> Podpowiedź: wydajność.
>
> > Tylko, ze PHP nie ma wcale polaczonych list i hashy (map) w jednej
> > strukturze. Posiada tablice asocjacyjne.
>
> Sprawdź sobie, jak działa 'array'. Ze szczególnym uwzględnieniem
> składni udającej listy.
>
> >> > Eeee... Tablice asocjacyjne z PHP sa powszechnie chwalone
>
> >> Przez kogo konkretnie?
>
> > Przez wiele osob.
>
> A konkretnie? Kto i za co je chwali? Przejdź się na dowolny wydział
> informatyki, zapytaj ludzi od struktur danych. Jeśli usłyszysz
> pochwały, daj znać -- to będą chyba pierwsze jakie PHP od nich
> dostanie.
>
> >> Decyzja o zrobieniu listy-i-hasza jako mapującej struktury danych
> >> jest po prostu debilna.
>
> > Nic takiego nie ma miejsca.
>
> Sorki, ale nie masz pojęcia o czym mówisz. Sprawdź sobie jak jest
> implementowane 'array' i zastanów się, dlaczego składniowo udaje
> również listę.
>
> [...]
>
> >> Poza PHP robi to chyba tylko AWK. Dzięki temu masz strukturę
> >> powolną jak diabli, ale za to pozbawioną zalet listy: jeśli po
> >> usunięciu indeksu muszę używać funkcji żeby indeksy zachowały
> >> ciągłość:
>
> >> $array = array_values($array);
>
> > Pewnie dlatego, ze to nie jest tablica indeksowana 0..n tylko
> > tablica asocjacyjna klucz=>wartosc - to, ze jest to lista, to juz
> > Twoj wymysl.
>
> Składniowo udaje listę, prawda? Normalny hasz nie pozwala na
> deklarowanie go np. jako '$array = array("a", "b", "c");'.
>
> > Dziwne by bylo tez, gdyby zachowywalo sie to inaczej
> > dla roznych typow indeksow.
>
> Dziwne to jest np. to dlaczego PHP nie ma list, tylko protezę
> w postaci specjalnego zachowania haszy. Chodzi w końcu o dość
> podstawowy typ danych. Zmuszanie ludzi do używanie kulawej
> pseudo-listy, ale za to powolnej, to jest dość typowy dla PHP
> przypadek strzelania sobie w stopę.

To przy okazji zagadka:

Jeśli $a == $b oraz $a i $ b są tego samego typu, to co można
powiedzieć o relacji między $array[$a] i $array[$b]?

<spoiler space>
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

<?php
$array = array('0' => 'a', '00' => 'b');
$a = '0'; $b = '00';
var_dump($a == $b);
var_dump($array[$a]);
var_dump($array[$b]);
?>

bool(true)
string(1) "a"
string(1) "b"

Bart Ogryczak pisze:

> Jeśli $a == $b oraz $a i $ b są tego samego typu, to co można
> powiedzieć o relacji między $array[$a] i $array[$b]?
> 
[8<]
> 
> <?php
> $array = array('0' => 'a', '00' => 'b');
> $a = '0'; $b = '00';
> var_dump($a == $b);
> var_dump($array[$a]);
> var_dump($array[$b]);
> ?>
> 
> bool(true)
> string(1) "a"
> string(1) "b"

Masz błąd w kodzie. Powinno być:

var_dump($a === $b);
var_dump($array[$a]);
var_dump($array[$b]);

Poznaj PHP.

Pozdr
Exe Very Cute

Exe Very Cute <kshksh@poczta.Xonet.pl> wrote:

> var_dump($a === $b);

A jest w php $a ==== $b? :)

Exe Very Cute:
>> <?php
>> $array = array('0' => 'a', '00' => 'b');
>> $a = '0'; $b = '00';
>> var_dump($a == $b);
>> var_dump($array[$a]);
>> var_dump($array[$b]);
>> 
>> bool(true)
>> string(1) "a"
>> string(1) "b"
> 
> Masz błąd w kodzie. Powinno być:

To nie chodzi o to, czy w kodzie jest błąd, tylko o przykre niespodzianki, 
które niesie ze sobą PHP.

.pk.

Wojciech Muła pisze:
> Exe Very Cute <kshksh@poczta.Xonet.pl> wrote:
> 
>> var_dump($a === $b);
> 
> A jest w php $a ==== $b? :)

Ja wiem, że to jest bez sensu. Ale taka składnię ma ten język i jeśli 
ktoś chce w nim programować lub wykazać jakieś jego błędy, to warto by 
było żeby ta składnię znać.

Komuś się różnie dobrze może nie podobać &, && i and ;-]

Pozdr
Exe Very Cute

Piotr Keplicz pisze:
> To nie chodzi o to, czy w kodzie jest błąd, tylko o przykre niespodzianki, 
> które niesie ze sobą PHP.

Wiem przecież. Jest to jeden z powodów dla których właśnie porzucam PHP 
na rzecz Pythona.

BTW, uczyć się 2.6 czy raczej 3.1? Bo w tej chwili mam zainstalowane oba 
i mam rozdwojenie jaźni. Tak samo nie wiem czy mod_python (chyba nie ma 
3?) czy mod_wsgi. Za dużo opcji ;>

Pozdr
Exe Very Cute

On Nov 25, 10:26 pm, Exe Very Cute <ksh...@poczta.Xonet.pl> wrote:
> Wojciech Muła pisze:
>
> > Exe Very Cute <ksh...@poczta.Xonet.pl> wrote:
>
> >> var_dump($a === $b);
>
> > A jest w php $a ==== $b? :)
>
> Ja wiem, że to jest bez sensu. Ale taka składnię ma ten język i jeśli
> ktoś chce w nim programować lub wykazać jakieś jego błędy, to warto by
> było żeby ta składnię znać.

Ty nie znasz, bo nie wiesz co znaczy ===.

On Nov 25, 10:30 pm, Exe Very Cute <ksh...@poczta.Xonet.pl> wrote:

> BTW, uczyć się 2.6 czy raczej 3.1?

2.6, albo wręcz 2.5

> Bo w tej chwili mam zainstalowane oba
> i mam rozdwojenie jaźni. Tak samo nie wiem czy mod_python (chyba nie ma
> 3?) czy mod_wsgi. Za dużo opcji ;>

WSGI. Tylko po cholerę w ogóle Apache?

Bart Ogryczak pisze:
> On Nov 25, 10:26 pm, Exe Very Cute <ksh...@poczta.Xonet.pl> wrote:
>> Wojciech Muła pisze:
>>
>>> Exe Very Cute <ksh...@poczta.Xonet.pl> wrote:
>>>> var_dump($a === $b);
>>> A jest w php $a ==== $b? :)
>> Ja wiem, że to jest bez sensu. Ale taka składnię ma ten język i jeśli
>> ktoś chce w nim programować lub wykazać jakieś jego błędy, to warto by
>> było żeby ta składnię znać.
> 
> Ty nie znasz, bo nie wiesz co znaczy ===.

Hahahah. Serio, dzięki za poprawę humoru.
A teraz pozwól że zakończymy tę dyskusję.

Pozdr
Exe Very Cute

Bart Ogryczak pisze:
>> Bo w tej chwili mam zainstalowane oba
>> i mam rozdwojenie jaźni. Tak samo nie wiem czy mod_python (chyba nie ma
>> 3?) czy mod_wsgi. Za dużo opcji ;>
> 
> WSGI. Tylko po cholerę w ogóle Apache?

Bo mam takie a nie inne środowisko do pracy.

Pozdr
Exe Very Cute

On Nov 26, 6:43 pm, Exe Very Cute <ksh...@poczta.Xonet.pl> wrote:
> Bart Ogryczak pisze:
>
> > On Nov 25, 10:26 pm, Exe Very Cute <ksh...@poczta.Xonet.pl> wrote:
> >> Wojciech Muła pisze:
>
> >>> Exe Very Cute <ksh...@poczta.Xonet.pl> wrote:
> >>>> var_dump($a === $b);
> >>> A jest w php $a ==== $b? :)
> >> Ja wiem, że to jest bez sensu. Ale taka składnię ma ten język i jeśli
> >> ktoś chce w nim programować lub wykazać jakieś jego błędy, to warto by
> >> było żeby ta składnię znać.
>
> > Ty nie znasz, bo nie wiesz co znaczy ===.
>
> Hahahah. Serio, dzięki za poprawę humoru.

No mówię, nie wiesz co znaczy. Wiesz jak działa.

$a == $b  	Equal  	TRUE if $a is equal to $b.
$a === $b 	Identical 	TRUE if $a is equal to $b, and they are of the
same type.