🚀 go-pugleaf

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)