Portál AbcLinuxu, 27. července 2025 08:58
4.12.2008 11:39
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
Docela by mě zajímalo, za kolik let bude P3x používanější než P2x.
To je jednoduché, až bude v Debianu stable 
Tak to je ještě čas
Copak Debian. Ten na Pythonu tak nevisí, jinde to budou mít horší, takže tohle je možná trochu mimo.
Snad nebude problem mit v systemu jak 2.x, tak 3.x. A aplikace se budou postupne migrovat...
Proč není ještě v Debianu unstable:To je jednoduché, až bude v Debianu stable
Python 3.0 has many bugs which results in corrupted data. It should never ever hit unstable. Most bugs should be fixed in 3.0.1 It will be useful to have it in experimental to port packages to python3k. But it would also be nice to have python2.6 so we can do some preporting work with `python2.6 -3 myscript.py` (would also close bug 502235)
pred casem jsem musel neco maleho v pythonu napsat a neco tak divneho jsem uz dlouho nevidel (i kdyz na visual basic to porad nema) tak doufam, ze ty nejvetsi hruzy uz odstranili... a taky trosku pohnuli s vykonem... treba jsem totalne nepochopil, proc je map rychlejsi nez for-each, atp.
To by me zajimalo, muzes byt konkretnejsi?
ted uz si na to moc presne napamatuju... ale vim, ze me hodne vytocilo volani: set("123"), ktere dela trochu neco jineho nez by si clovek predstavoval
jinak, kdyz jsem zacal resit vykon, tak jsem nejdriv myslel, ze oficialni ,,performance tips'' si ze me delaji srandu.
o for-each vs. map jsem uz psal... takze bych zminil kapitoly typu Avoiding dots..., Local Variables (Python accesses local variables much more efficiently than global variables. -- pristup ke globalnim promennym jde prekvapive resit v konstantnim docela kratkem case ;-]). a pak v nejake pozdejsi kapitole: Function call overhead in Python is relatively high -- coz povazuju u programovaciho jazyka za docela podstatnou vadu.
pristup ke globalnim promennym jde prekvapive resit v konstantnim docela kratkem case ;-]Asi ze sebe udělám pitomce, ale to zas tak nevadí: za jakých podmínek je tohle možné? Teď mne (po pár pivech a jednom Jamesonovi) napadá, že snad pouze v případě, že obory platnosti jsou v daném jazyce lexikální (což je dneska snad vždycky) a nelze je zvenčí měnit (což v dynamických jazycích v principu zajistit nelze). Ale protože jsi schemař (dynamický jazyk s lexikálními obory platnosti), mohl by ses podělit o, ehm, detaily
finta je to prosta... je teda z me hlavy, ale divil bych se kdyby to nekdo nepublikoval uz predemnou. budu to demonstrovat na optimalizaci cteni symbolu z nejvyssiho prostredi a bude fungovat za predpokladu, ze nektere z prostredi nebude prekryvat symbol z tohoto prostredi.
ma se to asi takto. predpokladejme, ze mame jednotlive prostredi e_0, ..., e_n definovane takto: e_i = [parent: e_(i-1), bindings: {[s_1, o_1], ..., [s_n, o_n]}, collision_bit: false], kde e_0 je pocatecni prestredi, e_n je aktualni prostredi, [s_i, o_i] predstavuji vazbu symbol-objekt v danem prostredi. to jenom pro ujasneni pojmu (nekde se pojem prostredi definuje trochu jinak).
pak tu mame priznak collision_bit, ktery je nastaveny na true, tehdy a jen tehdy pokud aktualni prostredi nebo jeho nadrazane obsahuje vazbu na symbol, ktery je obsazeny i v nejvyssim prostredi e_0.
predpokladejme, ze mame program a v nem chceme vyhodnocovat promenne. takovou promennou muzeme vnitrne reprezentovat jako treba foo = [symbol: "foo"; global_binding: null].
muze nastat nekolik situaci:
toto je ta nejhrubsi varianta. ma nektere neduhy... pokud lokalni prostredi prekryje jeden symbol z globalni tabulky symbolu, prestanou fungovat zrychleni i pro ostatni symboly. algoritmus jde dal zjemnovat... treba misto priznaku jde pouzit seznam kolidujicich symbolu, atd. dal to jde zobecnit i pro vazby, ktere nejsou v globalnim prostredi... ale to by ten popis byl jeste delsi.
vyborne to odpovida schemu, kde plati, ze (az na top-level prostredi) nejde do prostredi (po jeho vytvoreni) pridavat dalsi symboly. a jedina zrudnost je spec. forma set!... jenomze s tou jsme se uz vyporadali tak, ze jsme do global_binding ulozili odkaz na celou vazbu, takze se vlastne meni hodnota globalne. dalsi peknou vlastnosti je, ze to BUNR (bez ujmy na rychlosti), dovoluje predefinovavat i zakladni konstrukty jako define, if, atp.
se semantikou pythonu nejsem zase tak velky kamarad, ale podle me by to melo fugovat taky. ted si nejsem 100% jisty, jak to dopadne s moznosti pridavat si lokalni symboly dle libosti. to by v nejhorsim pripade, mohlo znamenat, prepocitat si collision_bit pri kazdem zavolani funkce. coz by asi nebyla zas tak velka hruza, protoze to jde udelat spolecne s vyhodnocenim prvniho globalniho symbolu.
bude fungovat za predpokladu, ze nektere z prostredi nebude prekryvat symbol z tohoto prostrediCož je právě ten průšvih, ne?
Ale to by mělo jít zjistit už při překladu… Jinak s tím příznakem kolize je to hezký nápad, díky.
Což je právě ten průšvih, ne?ani ne. prekryvat lokalne globalni hodnoty se povazuju docela casto za ,,bad practise''. takze ve vetsine funkci na tento mezni pripad nedojde. a pokud dojde, tak se to redukuje na puvodni zpusob, coz zase neni takova hruza. navic da se tem kolizim vyhnout alfa-konverzi, ale to ja treba z predchoziho duvodu neresim. :-]
Navíc překrývání globálních (nebo "superglobálních") symbolů se leckdy bere jako způsob uživatelské změny "zabudovaných" konstruktů… ale je fakt, že to nebude častý případ.
Tak jsem si to precetl a nic zvlastniho na tom nevidim. To ze je rychlejsi prohledavat pouze lokalni prostor nez lokalni prostor a potom nadrazeny prostor je vcelku logicke, ne? Tohle je u dynamickych jazyku normalni, uplne stejne si takto urychluju javascript nebo PHP.
Proc je map rychlejsi nevim, tipuji ze je to funkce implementovana v C, ktere interpret preda data a ona mu vrati vysledky, kdezto prikaz for bezi interpretovane v ramci virtualniho stroje.
Ze je volani funkci drahe je u dynamickeho jazyka opet bezne, vzdyt je s tim spojena spousta prace, za prve se musi najit v lokalnim nebo nejakem nadrazenem prostoru, za druhe je potreba zajistit funkcni introspekci. Obavam se, ze pro tebe bude divny kazdy interpretovany jazyk .
Tak jsem si to precetl a nic zvlastniho na tom nevidim. To ze je rychlejsi prohledavat pouze lokalni prostor nez lokalni prostor a potom nadrazeny prostor je vcelku logicke, ne? Tohle je u dynamickych jazyku normalni, uplne stejne si takto urychluju javascript nebo PHP.viz vyse
Proc je map rychlejsi nevim, tipuji ze je to funkce implementovana v C, ktere interpret preda data a ona mu vrati vysledky, kdezto prikaz for bezi interpretovane v ramci virtualniho stroje.to je to, co nechapu... kdyz map je funkce, proc to nemuzou udelat analogicky pro for... pripadne pro for, kde to jde bezpecne prevest (coz je drtiva vetsina pripadu)
Ze je volani funkci drahe je u dynamickeho jazyka opet bezne, vzdyt je s tim spojena spousta prace, za prve se musi najit v lokalnim nebo nejakem nadrazenem prostoru, za druhe je potreba zajistit funkcni introspekci.predstav si, ze jsi vyjmenoval ty nejpohodovejsi veci na reseni. ;-] mnohem vetsi sranda je treba s vytvorenim lokalniho prostredi. ;-] a predstav si, ze jsou i dynamicke jazyky, ktere poradne nemaji ani to for a misto cyklu pouzivaji rekurzivni _volani_ a presto maji rychlejsi interpretery nez python. takovy gauche scheme s prehledem strci python do kapsy a s SBCL to radsi nebudu ani srovnavat. ;-]
Obavam se, ze pro tebe bude divny kazdy interpretovany jazyk:-]]] z cehoz plyne, ze asi sam budu cely divny... ale aspon se dobre bavim... kdybys tak vedel, za co me (mimojine) strycek sam plati... ;-]
No, a muzes treba u map() delat treba veci jako break a continue? Ja myslim ze map() je hodne specifiky pripad a flexibilite for se nevyrovna. Na druhou stranu pak for musi bezet interpretovane a tedy pomaleji. Tudiz, mas-li tento specificky pripad, pouzij map() ci spise jeste radsi generator, ktery k operacim tohoto typu slouzi.
Mozna gauche scheme a SBCL strci rychlosti Python do kapsy, ale zase se prakticky nepouzivaji, ono je to vzdycky neco za neco. Ano, Python sam o sobe kod bere a provadi jak je. Podle meho rychle, ale tobe asi vadi, ze ho neoptimalizuje, optimalizace zustva na programatorovi. Prekladac ti tedy sam od sebe jednoduchy for rychlejsim generatorem nenahradi, musis ty sam. Pokud chces optimalizaci, pak doporucuji pouzivat Psyco, je-li to mozne.
No, a muzes treba u map() delat treba veci jako break a continue?proc, ne? zijeme ve svobodne zemi! ;-] neni problem nahradit continue a break... jde to resit returnem znacici vyskoceni z iterace (funkce), podle navratove hodnoty toho ,,returnu'' vnitrni funkce (neco na zpusob map) pozna, jestli ma pokracovat dalsi iteraci nebo cyklus ukoncit.
gauche scheme a SBCL strci rychlosti Python do kapsy, ale zase se prakticky nepouzivajito by ses divil, jak se prakticky nepouzivaji. kazdopadne ja jsem to tady uvadel jako priklad ,,dynamickych jazyku'', kde jdou delat veci rychle. na druhou stranu, prave proto se divim takovemu uspechu pythonu i pres vazne problemy s rychlosti.
optimalizace zustva na programatorovia to je ten duvod proc remcam... tohle by bud nemelo byt treba nebo by to za me mel delat pocitac.
Pokud u interpretovaného jazyka řešíš rychlost i jinak než na úrovni složitosti tvých algoritmů, asi je tvůj problém někde úplně jinde než v samotném jazyce. Koneckonců, můžeš si dopsat modul v C/C++
Řekněte mi ještě, že PyQT4 s tím funguje na 100% a je nějaké skvělé IDE jako QT Creator a hurá do toho! 
PyQT4 s Pythonem3 samozřejmě nefunguje.
Jestli to je ironie, tak se omlouvám, ale v py nedělám a nenašel jsem nikde nic, že to vpohodě funguje ...
Ironie to není, ono to vážně nefunguje. Si to zkuste.
5.12.2008 08:00
David Watzke | skóre: 74
| blog: Blog...
| Praha
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
4.12.2008 11:37
4.12.2008 13:36
4.12.2008 20:21
4.12.2008 22:09
5.12.2008 08:39