Cau vsem,
narazili jsme v praci na zajimavej problem. Pri pouziti knihovny logging
se ukazalo, ze se nam predbihaji casy. Receno jinak, rozdil dvou po sobe
jdoucich casu je zaporny. Podle vseho se to deje jen v Pythonu.
Pouzivame balicek pythonu 2.4, ale to stejne se deje ve zkompilovanem
Martin Blazik wrote:
> Cau vsem,
> narazili jsme v praci na zajimavej problem. Pri pouziti knihovny logging
> se ukazalo, ze se nam predbihaji casy. Receno jinak, rozdil dvou po sobe
> jdoucich casu je zaporny. Podle vseho se to deje jen v Pythonu.
> Pouzivame balicek pythonu 2.4, ale to stejne
Takze jeste dodam, ze mam i dalsi masinu, kde je jediny procesor AMD64 a
tam se tato chyba tez nevyskytuje ;-)
lachtan
Leos Pol napsal(a):
> Martin Blazik wrote:
>
>>Cau vsem,
>>narazili jsme v praci na zajimavej problem. Pri pouziti knihovny logging
>>se ukazalo, ze se nam predbihaji casy.
Tak jsem to zkusil
OS Linux (CentOS 4.4), python 2.3.4, dva procesory Athlon 64 Dual Core a chyba
se neobjevila ... po jak dlouhe dobe se objevuje (stopnul jsem to za cca 10
sekund)?
--
best regards
Michal Vyskocil
___
Python mailing list
> Vystup je napr nasledujci:
> 42066 -0.240935087204
> 25838 -0.24276804924
> 74945 -0.238132953644
> 51000 -0.240145921707
Helejte a není divné, že se to posune pořád o stejný rozdíl? Nejdená se
o nějaké zaokrouhlovací chyby. Možná, že timer funguje s určitou
přesností a zbytek přesnosti se
A jak se to chová, když se tam místo randint()
použije konstanta natvrdo? Třeba
high = 5
Ten test by se měl zjednodušit, aby byl
opakovatelný. Možná se při tom objeví
něco jiného.
Možná by se místo pass mělo použít něco
jiného, co se nemůže při optimalizaci
vyhodit.
Martin Blazik
>
> Možná by se místo pass mělo použít něco
> jiného, co se nemůže při optimalizaci
> vyhodit.
python a optimalizace? opravdu?
___
Python mailing list
[email protected]
http://www.py.cz/mailman/listinfo/python
superman
> > Možná by se místo pass mělo použít něco
> > jiného, co se nemůže při optimalizaci
> > vyhodit.
>
> python a optimalizace? opravdu?
Opravdu!
A na jakou optimalizaci konkrétně se ptáš?
Bral jsem to spíš obecně. Ale rád se nechám
poučit, co přesně se děje při provádění pass.
Další
Zkousel jsem tam davat i nejakej konkretni vypocet v plovouci carce. Ta
nahodna hodnota tam je prave kvuli tomu, ze nevim presne, kdy k te
situaci dojde. Tim simuluju ruzne prodlevy v realnem programu. Napsal
jsem si ted podobnej testik do Javy a upravil koleguv test v cecku a
chybe dochazi na
> A na jakou optimalizaci konkrétně se ptáš?
> Bral jsem to spíš obecně. Ale rád se nechám
> poučit, co přesně se děje při provádění pass.
Haha. Vzhledem k tomu, že GvR dělá problém pouhá implementace některých
příkazů, a snaží se je v pythonu 3000 vyhodit, přičemž se tímto důvodem
vůbec
Vetsinou tak do 20 sekund. Kdyz se pouzije zjednoduseny kod, tak to trva
vetsinou dyl. Taky jsem empiricky zjistil, ze docela zalezi na zatzi
daneho stroje. Pokud ho zatizim tak, aby oba cesory bezely naplno,
k chybe dochazi po mnohem vetsich intervalech.
Mozna je jeste treba rict, ze k chybe
Martin Blazik napsal(a):
> Vetsinou tak do 20 sekund. Kdyz se pouzije zjednoduseny kod, tak to trva
> vetsinou dyl. Taky jsem empiricky zjistil, ze docela zalezi na zatzi
> daneho stroje. Pokud ho zatizim tak, aby oba cesory bezely naplno,
> k chybe dochazi po mnohem vetsich intervalech.
>
superman wrote:
>> A na jakou optimalizaci konkrétně se ptáš?
>> Bral jsem to spíš obecně. Ale rád se nechám
>> poučit, co přesně se děje při provádění pass.
>>
>
> Haha. Vzhledem k tomu, že GvR dělá problém pouhá implementace některých
> příkazů, a snaží se je v pythonu 3000 vyhodit,
> 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.
superman
> Haha. Vzhledem k tomu, že GvR dělá problém pouhá
> implementace některých příkazů, a snaží se je v
> pythonu 3000 vyhodit, přičemž se tímto důvodem
> vůbec netají, pak čekáte subtilnější věci jako je
> optimalizace?
GvR nikomu nebrání vytvořit mnohem dokonalejší
odnož Pythonu. Čeká jen
Omlouvam se, ze zasahuji do slibne se vyvijejiciho flame ohledne
optimalizace Pythonu. Problem vyresily parametry kernelu
clock=pit notsc
pokud by to nekomu nekdy pomohlo :)
Celkovy popis parametru je napr zde
http://www.mjmwired.net/kernel/Documentation/kernel-parameters.txt
lachtan
> GvR nikomu nebrání vytvořit mnohem dokonalejší
> odnož Pythonu. Čeká jen na tebe.
Existuje několik odnoží Pythonu, například JPython, ten od GvR je z nich
nejpomalejší.
> Pokud jakákoliv konstrukce větvení nebo cyklu
> neprovádí testy a jiné příkazy způsobem, který
> by mohl mít za následek
superman wrote:
> Proč se třeba nepoužije generátor parserů a gramatiky a
> namísto si GvR lepí svůj, samozřejmě horší, nechápu.
V cem je "GvR slepeny generator parseru a gramatiky" horsi nez
neuvedena_vec, zrejme nejaky yacc/flex/bison/...?
Hezky den,
-j.
--
cd /local/pub && more beer >
> V cem je "GvR slepeny generator parseru a gramatiky" horsi nez
> neuvedena_vec, zrejme nejaky yacc/flex/bison/...?
V tom, že GvR dělá to, co za něj udělají jiné programy a on pak nemá čas
soutředit se na další věci. Představte si, že GvR má 24 hodinový den,
musí se věnovat práci, rodině,
Dne úterý 28 listopad 2006 17:15 Jan Kundrát napsal(a):
> superman wrote:
> > Proč se třeba nepoužije generátor parserů a gramatiky a
> > namísto si GvR lepí svůj, samozřejmě horší, nechápu.
>
> V cem je "GvR slepeny generator parseru a gramatiky" horsi nez
> neuvedena_vec, zrejme nejaky
> Ad GvR, nemyslim, ze by byly programatorske schopnosti GvR nejvetsi prekazkou
> pro (ne)optimalizaci v Pythonu. Jak je mozne zjistit z
> http://docs.python.org/whatsnew/whatsnew25.html, tak je uveden jako
> (spolu)implementator jen u http://docs.python.org/whatsnew/pep-343.html - PEP
> 343.
> Konkretne python icona lze nalezt timhle:
>
> >>> import win32api
> >>> import win32con
> >>> key = win32api.RegQueryValue(win32con.HKEY_CLASSES_ROOT, '.py')
> >>> win32api.RegQueryValue(win32con.HKEY_CLASSES_ROOT,
> '%s\DefaultIcon' % key)
>
> Ad GvR, nemyslim, ze by byly programatorske schopnosti GvR nejvetsi prekazkou
> pro (ne)optimalizaci v Pythonu. Jak je mozne zjistit z
> http://docs.python.org/whatsnew/whatsnew25.html, tak je uveden jako
> (spolu)implementator jen u http://docs.python.org/whatsnew/pep-343.html - PEP
> 343.
> V cem je "GvR slepeny generator parseru a gramatiky" horsi nez
> neuvedena_vec, zrejme nejaky yacc/flex/bison/...?
V tom, že GvR dělá to, co za něj udělají jiné programy a on pak nemá čas
soutředit se na další věci. Představte si, že GvR má 24 hodinový den,
musí se věnovat práci, rodině, světe
superman wrote:
>> V cem je "GvR slepeny generator parseru a gramatiky" horsi nez
>> neuvedena_vec, zrejme nejaky yacc/flex/bison/...?
>
> V tom, že GvR dělá to, co za něj udělají jiné programy a on pak nemá čas
> soutředit se na další věci.
To IMHO ukazuje na pro Guida neefektivne zvoleny
25 matches
Mail list logo
