Názory k článku Vývoj PHP 6

BOM - tazko povedat. strlen() a spol, tam staci spravne nastavit len locales, a jediny jediny problem co vidim je normalizacia retazcov.

Kvůli překládání EVAL rozhodně odbourávat nemusíte. ;-) Možná by se v něm něco muselo omezit, kompilovat jazyk s evalem ovšem principielně rozhodně možné je. Ale zrovna miniruntime z toho nebude. ;-)

Nikdy jsem si nemyslel, že se budu na novém rootu registrovat, ale tady Petr Zvěřina z Václaváku alias Mr. Jelito, si prostě nedá pokoj s těmi prasárnami.

Teď si zkus něco poslat pod mojí "novou identitou", opičáku :-)))

Dík :-)))

Právě jsi nám všem předložil důkaz, že tady píšeš pod jinými nicky. Obrázek si udělá z tohoto threadu každý sám...

Příště používej hlavu, docela jsi mě překvapil. Myslel jsem, že nenaletíš. Přecenil jsem tě, jelito...

Nikdy jsem si nemyslel, - a na co sis myslel ze ta registrace je ? To ti to musel nekdo predvest, aby ti to doslo ?

Ty lambdy z Pythonu bohužel zase useknou... ;-)

To jsem ani nevedel. Hmm, takze to zase bude jazyk pro pojidace kolacu :-))) A me se pritom lambda kalkul opravdu libi, minimalne od dob prednasek prof. Hrusky.

Ehm...to jsem byl já. ;-)

Because Python is beautiful and ripe?

Nebo protože Python má vlastní projekty, na kterých se podílí IMHO celkem dost lidí? Nic ve zlém, ale Ruby potřebuje nějaký ten performance boost v tuhle chvíli o dost víc a taky nějaké ty lidi, kteří by se nad tím zamysleli. To už byste rovnou mohl tvrdit, že by byl dobrý nápad začít psát nový a lepší kompilátor Cčka. ;-)

Kromě toho jsem reagoval na to, že panu Tišnovskému se bude v Pythonu stýskat po lambdách. Pokud někdo chce lambdy, tak mu zkrátka nepomůže, že Python je hezký, když i ta současná limitovaná konstrukce je de facto deprecated.

http://wiki.cs.uiuc.edu/VisualWorks/How+to+get+rid+of+Objects+in+Smalltalk

:-D

Úžasný :-)
Potom ještě z Lispu konečně odstranit naprosto zbytečné seznamy snadno nahraditelné páry, to pak nahradit lambda kalkulem a pak jen s blaženým úsměvem sledovat, how David and Vassili get rid of this Universe ;-)

No moment. Já žil v domnění, že všechno, co existuje, je jen funkce jedné proměnné... :-D

:-D

Ahoj Pavle,

takova "uprava" Lispu uz existuje a jmenuje se Unlambda - http://www.madore.org/~david/programs/unlambda/

Pravda, kod byva trosku necitelny, ale zato je to osekane o vsechny zbytecne jazykove konstrukce :-)))

tak trochu míchání pojmů, ne?

call-with-current-continuation je zase lepší než pouhý setjmp a longjmp, protože i uloží/obnoví stack, takže můřu skákat i úplně mimo aktuální funkci, a dokonce i níže a napříč a můžu se do volané funkce vrátit i zpětně. ;-)

Pokud je GOTO omezene pouze v ramci jedne funkce/metody (+ dalsi omezeni, ktera se tykaji smycek), tak je implementovano stejnym zpusobem jako smycky, akorat tam jsou misto relativnich kratkych skoku typu "jnc", "jz" apod. short jumpy.

Ja vsak nejsem v zadnem pripade zastancem GOTO a ani breaku pres vice smycek - GOTO jsem nepouzil uz peknou radku let a break pres vice smycek stejne neni v C-cku podporovany a v Jave, kdyz na podobnou konstrukci narazim, pouziju Forthovskou zasadu "rozdel a panuj" :-)

Naproti tomu predcasny vyskok z jedne smycky se pouziva dost casto, protoze to nahrazuje vlozene podminky a slozitejsi testy na zacatku/konci.

Takze souhlasite, ze goto je pro nektere ucely omezeno prilis a implementace setjmp a longjmp byla nutna ?

Kdyz uz tak mavate tim assemblerem, zkuste se podivat, co vam to vase Forthovske "rozdel a panuj" vygeneruje za obludnosti na tema predavani argumentu do funkce. Forth je na to delany (snad), ale C proste NE. V C obcas musite obetovat trochu teoreticke cistoty kodu tomu, aby to nebylo line jak mrcha. Docela by me zajimalo, jak si s tim poradi Java JIT ...

Oproti tomu break pres vic smycek nahrazuje houf naprosto zbytecnych testu nasledujicich vnitrni smycku.

"zkuste se podivat, co vam to vase Forthovske "rozdel a panuj" vygeneruje za obludnosti na tema predavani argumentu do funkce"

...que? Viděl jste Forth aspoň z rychlíku? Kdyby totiž ano, pak bystě těžko něco takového mohl napsat. Režie Forthu na předání parametrů je nulová, režie návratu z funkce (slova) taky.

Co to ocitovat cele ? zkuste se podivat, co vam to vase Forthovske "rozdel a panuj" vygeneruje za obludnosti na tema predavani argumentu do funkce. Forth je na to delany (snad), ale C proste NE.

Pro pripad ze by vam to nebylo jasne, napisu to jeste jednou: zkuste se podivat, co vam to vase Forthovske "rozdel a panuj" vygeneruje v ostatnich jazycich (nez je Forth) za obludnosti na tema predavani argumentu do funkce. Rikal jste, ze ho pouzivate v Jave misto vicenasobneho breaku a mel jsem podezreni, ze by jste ho doporucil i v dalsich jazycich, treba v C misto goto.

Cože? Já že používám něco v Javě místo vícenásobného breaku? Jak jste na to přišel? Já v první řadě nepoužívám Javu. :-D I přesto si drze dovolím domnívat se, že bát se občasného použití zapouzdření smyčky do funkce je krásný příklad naprosto nesmyslné předčasné optimalizace.

Mate pravdu, to byl Pavel Tišnovský kdo to pouzival ... ale na principu to nic nemeni, proste o Forthu jsem nemluvil.

Bat se zapouzdrani mozna ano, ale zapouzdrovat pokazde, kdyz chcete pouzit dvojity break, ne. Tedy, jak je u optimalizace obvykle, zalezi na dalsich okolnostech - konkretne treba na poctu argumentu. Osobne me sice nenapada pripad, kdy by zapouzdreni bylo rychlejsi, ale verim ze takovy existuje. Krome toho pokud je vnitrni funkce static inline, muzete spolehat na to, ze ji prekladac vlozi zpatky a tim ziskate "cistci" kod za cenu trochu casu pri prekladu (tedy levne).

A vůbec, ten return taky nahradí vyskočení z vnitřní smyčky. Volání té funkce i návrat z ní jsou jednorázové a já bych se nesmírně divil, kdyby reálný vliv na výkon byl víc než nula celá nula nula nula mravenec.

Co kdyz cela ta smycka je jeste v jedne smycce (ktera je uz v jine funkci nebo z ni alespon nechcete vyskakovat) ?

Tomu trošku nerozumím. Ten return mě přece vyhodí přesně z toho bloku, který chci vynechat a proto jsem ho zapouzdřil do funkce. Vnější smyčka volající funkci nebude dotčena. V Cčku je trošku problém s absencí lexikálních uzávěrů, hodily by se i anonymní funkce, takže obcházení goro přes návrat ze samostatné funkce může být někdy trošku tricky...hmm, další důvody, proč k psaní větších aplikací nepoužívat jazyk navržený především k psaní Unixů... :-D

Nicméně, právě proto v dnešních jazycích goto je. Myslím si totiž, že snaha za každou cenu obcházet goto v jazyku, který není nijak extra čistý ani v jiných směrech je bláznovství. Co třeba tohle?

http://www.cprogramming.com/tutorial/goto.html
http://www.exim.org/mail-archives/exim-dev/2005-August/msg00003.html
http://youngbloods.org/essays/argument_for_goto.html

Chtel jsem rict ze kdyz cela ta smycka je jeste v jedne smycce tak se to nula celá nula nula nula mravenec muze nascitat podle hesla stokrat nic umorilo osla.

Ano, Ccko je jazyk jineho typu nez forth a obchazet v nem goto je nesmysl. Pro vetsi aplikace je to jazyk dobry, ale nikoliv vyborny. Bohuzel obecny vyborny jazyk zatim neexistuje - tim myslim, ze zatimco pro nektere projekty je vybornym jazykem Java nebo C++, pro mnohe je stale nejlepsi C i se svymi nevyhodami.

Uvedena situace je snad docasna a lze ji zmenit vylepsenim java JIT a C++ kompileru.

O Jave jsem mluvil ja a ne Jakub, takze to pada na mou hlavu :-)

Jak uz jsem psal v prispevku nize, predavani parametru je v TECHTO PRIPADECH reseno i v C-cku primitivne pres registry, ve skutecnosti se totiz pouzije inline funkce a dopad na vykonnost to nema zadny. JIT take pouzije inline funkce, takze se zadne casove ani prostorove narocne predavani parametru nekona.

Jinak cecko preklada na ruzne architektury, u nichs se napriklad takove obludnosti, jako je stack-frame ani nedaji rozume pouzit, takze slozitym predavanim parametru (ala x86) se neda argumentovat.

Mozna mate takovy prekladac, ale na linuxu na x86 se defaultne (podle defaultniho ABI) vse preklada se zasobnikovou volaci konvenci (a kdyz to prepnete (mregparm), neprilinkujete libc). x86 sice neni architektura jedina, ale je nejrozsirenejsi. Jak jsem rikal, pokud je funkce static inline, muzete dosahnout toho ze ji prekladac presune zpatky - ale spolehnout se na to nemuzete.

Pri prekladu napriklad GCCckem s parametrem -O3 nebo (pro psavce) -finline-functions se i ve standardnim cecku (tedy zadna pluska ani GNU rozsireni) budou inline funkce hledat a take tak prekladat. Samozrejme, ze bez optimalizaci se na to prekladac vyflakne, ale potom stoji za uvazeni, proc vlastne to cecko pouzivat (flame), kdyz to i v te pitome Jave s JITem pobezi rychleji (a to za me JITko dela i takove "malickosti", jako kontrolu mezi poli apod.).

Ja jsem byl po dlouhou dobu zastancem cecka, alespon co se tyce programu s naroky na rychlost, ale posledni verze JIT ("server" verze) me presvedcuji o tom, ze preklad s analyzou behu programu je pro mnoho veci vyhodnejsi - holt se az za behu zjisti veci, ktere prekladac pri kompilaci "statickeho" zdrojaku nemuze vedet :-)

Pravda, i bez static muze prekladac funkci inlineovat (a nechat jednu neinlineovanou kopii). Nejak doufam, ze to v tom pripade dela jen pro mensi funkce (aby neplytval mistem), ale netestoval jsem.

Posledni CVS verzi Sun Javy jsem netestoval, ale IMHO stale plati, ze zatimco po delsim behu uz je program zoptimalizovany (kontroly mezi poli vyhazene na zaklade zjisteni, ze k prekroceni mezi nedojde a podobne), pri spousteni noveho kodu je porad rezie Javy dost vyrazna. Ano, pro mnoho velkych projektu to nevadi, protoze se to v celkove dobe behu ztrati ... ale obecne to neplati.

On tu neinlineovanou kopii ponechat nemusi, protoze z kontextu vi, ze se ta funkce nikde jinde nepouzije (to samozrejme plati pouze pro funkce deklarovane jako inline nebo static). I funkce nadeklarovane "inline", ktere se prekladaci nelibi, se nemusi linkovat primo do kodu - to ostatne rika i norma. Vzhledem k tomu, ze se mi zatim darilo jako inline funkce delat opravdu kratke kody (klasicke jsou settery a gettery), tak to GCCcko vzdycky prelozilo tak, jak jsem potreboval.

Ja jsem JITko testoval na verzich 1.4 a 1.5, ta jedna-petka mela aplikovane nejake bug-fixy, ale urcite to neni nejnovejsi vec, spis tak o rok pozadu. Ano, ta rezie je opravdu velka, takze pro mensi utility, ktere se casto pousti, se to nehodi (to je jedna z veci, ktera mi na cele platforme Javy hodne vadi). Na druhou stranu napriklad TomCat nebo JBoss spousti Javovske servlety rychleji, nez Apache Perlovske skripty :-).

BTW, vzdycky jsem povazoval kod vylezly z cecka za "neprenositelny" v tom smyslu, ze cecko je vlastne urceno k tomu, aby se mezi platformami prenasely zdrojaky a ne binarky, u kterych se preklad provadi tak, ze se zvoli "nejmensi spolecny jmenovatel" vsech cilovych platforem. Protoze preklad binarky pro predem nezname platformy prakticky vzdy vyprodukuje neefektivni kod, napriklad dnes je porad popularni preklad pro i386, dnesni procesory toho umi podstatne vice (MMX, SSE2, pipelining atd.). Takze distribuce binarky, pokud to tedy neni osetreno nejakymi testy a vyberem spravne vetve kodu podle procesoru (objemova neefektivita), to cecko strasnym zpusobem degraduje, nehlede na to, ze nektere veci nejdou na i386 vubec napsat (napriklad multiprocessing ma podporu v jedne instrukci az i486, ale ten se stejne na platforme PC moc neujal). Z toho vyplyva, ze duraz na efektivitu prelozeneho kodu je na uzivateli (resp. jeho spravci), ktery by mel preklad provest tak, aby to bezelo co nejrychleji (-O3, -march atd. atd.).

Nebo se na celou efektivitu muzeme vyflaknout a pouzivat moderni i lety osvedcene dynamicke jazyky, ve kterych se aplikace pisou mnohem rychleji nez v cecku a nehrozi pritom to, ze jsem zrovna nedavno objevil v jedne bezne prodavane aplikaci za cca 120 000 Kc dosti usmevny memory leak.

"zkuste se podivat, co vam to vase Forthovske "rozdel a panuj" vygeneruje za obludnosti na tema predavani argumentu do funkce"

...que? Viděl jste Forth aspoň z rychlíku? Kdyby totiž ano, pak bystě těžko něco takového mohl napsat. Režie Forthu na předání parametrů je nulová, režie návratu z funkce (slova) taky.

Jasne, goto je v C-cku omezene a je to tak dobre, o tom se snad nehadame :-) Implementace v assembleru je velmi podobna smyckam a podminkam, takze zadne "prasarny" navic se nekonaji, v tomto by taky nemel byt problem.

V C-cku je predavani parametru v _TECHTO_PRIPADECH_ stejne jako ve Forthu, alespon u slusnych prekladacu. Jde o to, ze ty volane procedury/funkce jsou v 99% tak primitivni, ze se stejne vsechno preda v registrech a vlastne o predavani nemuze byt rec, protoze se prelozi jako inline.

Opravdu jde pouze o cistotu kodu, vsechnu spinavou praci nechame na prekladaci ci JIT.

Kdyz jsem u toho JIT: zrovna pred cca dvema tydny jsem neco podobneho zkousel kvuli porovnani rychlosti Javovskeho a C-ckovskeho kodu. Vypadalo to asi takto:

for (int j=0; j!=10000; j++)
    for (int i=0; i!=10000; i++)
        for (int k=0; k!=10000; k++)
             volejfunkci(i,j,k);
// sorry za ty !=, maji tam byt mensitka, ale Root to zdrbe

C bez inline funkci bylo samozrejme neskutecne pomale, ovsem s inline funkcemi se rychlost ceckoveho a Javovskeho kodu uplne srovnala (rozdily cca 5%), takze JIT uz automaticky inline funkce rozezna, a to bez jakychkoli modifikatoru (zadne final ani static).