Python deterministický

23.7.2009 13:37 | Přečteno: 716× | Dev/Tech/Gnu

Python jakožto virtuální mašina není deterministický. Obvyklým zdrojem nahodilosti je plánování vláken, v Pythonu ale můžete mít korektní jednovláknový program, který vám dá pro jeden vstup pokaždé jiné výsledky. Může za to hashování, hash objektu může být odvozen od jeho adresy v paměti, což je (stejně jako rozvrhování vláken) neuchopitelná záležitost o kterou se stará operační systém.

Já jsem na tuhle vlastnost narazil v momentě, kdy jsem před sebou měl program, který jako klíč k hashovací tabulce používal objekt funkce. Na jiném místě program tabulku sekvenčně procházel, jenže pořadí položek se mezi jednotlivými běhy měnilo.

Existují implementace hash-tabulek, které tímto problémem netrpí. Bohužel, zmiňovaný program je tak velká a složitá bestie, že jsem musel zvolit alternativní přístup: upravit samotný interpret Pythonu.

Patch je to jednoduchý, brutální, ale funkční:

--- Python-2.4.4/Objects/object.c	2006-04-12 19:06:58.000000000 +0200
+++ /home/paskma/B/src/Python-2.4.4/Objects/object.c	2009-03-20 10:01:29.000000000 +0100
@@ -984,6 +984,8 @@
 long
 _Py_HashPointer(void *p)
 {
+	return 1;
+
 #if SIZEOF_LONG >= SIZEOF_VOID_P
 	return (long)p;
 #else

Pochopitelně tenhle hack může sabotovat výkon, v mém případě to ale program příliš nezpomalilo, tahle funkce se používá až když není zbytí.

       

Komentáře

[CEST]

Tak a ted uz jenom zajistit, aby tenhle python nepouzivalo nic jinyho, a aby pripadneho budouciho programatora toho programu vzdycky nekdo zaskolil, ze ma pred sebou pozmenenou verzi pythonu a tudiz se tohle nechova tak, jako original.

Tim samozrejme chci rict, ze se mi tohle nezda jako dobry reseni.

[paskma]

V případě, že by s tím měl pracovat ještě někdo jiný než já, by to už dobré řešení nebylo.

Ono ty výstupy jsou korektní v každém případě, jenom trochu jiné (liší se očíslování nějakých interních polí). Determiničnost jsem potřeboval jenom kvůli ladění.

[Tomáš]

To není dobrý nápad. Ohýbat kód interpretru kvůli ladění je fakt blbý nápad. Jak si můžeš být jistý, že to bude fungovat správně na jiné mašině se standardním Pythonem? Projdou Ti tam vůbec unittesty? Pokud potřebuješ deterministický výstup, tak si ty položky setřiď.

[paskma]

Máš špatný úhel pohledu. Byl to dobrý nápad, protože mi ušetřil spoustu práce. Prostě hack. Já neřeším udržovatelnost té obludy, používám ji jenom ke svým vlastním experimentům. Btw ano, funguje to i se standardním Pythonem, protože ta nedeterminističnost (to je slovo) se projeví jenom interním očíslováním nějakých položek.

Unittesty jsem nezkoušel (dobrý nápad), ale jelikož jsem neudělal nic jiného než že jsem "mírně" zhoršil vlastnost hashovací funkce, projít by to mělo.

[Michal Vyskočil]

Není jednodušší použít nějaký slovník s pořadím? Třeba Recipe 107747, nebo se podívat na stav PEP 0372? Případně si seznam klíčů před iterací, ve které na pořadí záleží, seřadit?

[extremni lama]

presne tak, kdyz to potrebuju prochazet v urcitym poradi tak si to predem seradim. Menit kvuli tomu interpreter je pekna zvrhlost...

[paskma]

Já myslel, že to bude z mého postu patrné. Pochopitelně existuje X čistších způsobů, jak dosáhnout cíle. Ale všechny jsou mnohem pracnější. Ten program má 90k řádek (v C by to bylo půl mega a je složitý jak cukrovar, než bych přišel na to, kde všude ten slovník vyměnit/kde všude seřadit, tak bych zešedivěl (na pár místech jsem to zkoušel, ale s nevalným úspěchem).

Je to hack, proto se zde tím chlubím

[zde]

A nebylo by lepší zvětšit PyObject o jeden const long inicializovný counterem, a ten pak použít jako hash value? Nebyl by to jednořádkový patch ale 3-řádkový, ale aspoň by nebyl problém s výkonem. To tvoje řešení mě bolí už když se na něj podívám.