[python] zaporny systemovy cas

[superman]

> Nevim, jak to presne v pythonu je, ale obecne abstraktni syntakticky 
> strom je vstupem pro generator vnitrniho kodu, ktery by mel byt uz 
> snadneji optimalizovatelny.

Znovu opakuji, že optimalizace není sranda! Takový interpretr Javy 
napíšete odhadem na 20 tisíc řádků v C++ za měsíc práce. Ovšem skutečný 
interpretr Javy od Sunu, který skutečně optimalizuje a provádí JIT 
kompilaci má přes 3 milióny řádků!!! Navíc má usnadněnou práci s tím, že 
značná část kompilace je provedena už kompilátorem javac a intepretr jen 
interpretuje už částečně optimalizovanou binární formu.

> Presto ale nechci uverit tomu, ze python ve vysledku udela neco jako:
> 
>         mov cx, cislo
> 
>     L1:  <nacti dalsi 'i'>
>          loop L1

Ve výsledku to nejen tak je, ale bude ještě hůř. Protože rozhodnutí je 
změnit architekturu. Navíc co chcete, když se jedná o cyklus foreach? 
For cyklus v Pythonu neexistuje.

> Kazdopadne k jistym upravam by melo take dochazet na urovni procesoru.

K jakým? Procesor je prostě čím dál víc náchylnější na kód co se mu 
předhodí. Zkoušel jste někdy optimalizovat stroják na rychlost, nebo 
zkoumat co vyleze z Céčka? Stačí vzít a přehodit dvě instrukce a běží to 
klidně o 50% rychleji. Nebo napíšete podprogram ve stojáku, který je 
desetkrát větší, než Vaše první verze a on běží třeba třikrát rychleji! 
A přitom je to ten samý algoritmus. Zoptimalizovat tohle je věc, která 
jen v kompilátorech C/C++ dělá tým machrů řadu let!

Procesor čím dál víc spoléhá na to, že se mu předhodí již OPTIMÁLNÍ kód 
s tím, že jako z nouze ctnost provede i ten neoptimální, ale třeba 
dvacetkrát pomaleji. Je to jen z důvodů zpětné kompatibility, což je věc 
v pythonovské komunitě nevítaná :-) Na optimalizaci procesoru 
nespoléhejte, šíleně byste se spletl.

Miloslav Ponkrác