Názory k článku Volání subrutin naprogramovaných v assembleru z jazyka Python

Asi to nikdy nevyužiju, ale je to zajímavé.

Dá se říct, jak je takové řešení výkonnější oproti použití C. Nějaký benchmark?

Ježíši, z Pythonu jde spouštět nativní kód. Tady se místo klasického načítání libky spustí "ručně" namapovaný binární blob. Článek netvrdí, že to je v něčem lepší, jen ukazuje, že to jde. Jaký benchmark, co to je za dotaz?

Když nevíte, nemusíte odpovídat, přeci.

Můj dotaz je jednoduchý a jasný, ptám se na to, o kolik je to výkonnější oproti standardnímu použití C knihovny.

Samotné volání je úplně stejné podle stejného ABI, čas bude stejný.

Nahrání knihovny bude nevýznamně pomalejší kvůli porozumění jednotlivých segmentů (předpokládám, že funkce budou srovnatelně jednoduché, aby nevyžadovaly nějakou inicializaci). V případě poslední ukázky, kde se kód parsuje a překládá z hexa do binárního kódu - něco to může zabrat, ale asi míň, než další syscally na externí soubor. Ale je to zanedbatelná jednorázová věc - nějaké stovky CPU cyklů.

nacteni .dll/.so neni uplna trivka. Kvuli ladeni jsem to sledovat stracem a tech volani jadra je tam dost. Soubor se ruzne hleda, testuji jeho prava, otevira se (logicky), potom read a potom je tam nejaky resolvovani symbolu (tomu uz nerozumim ;)

Dneska jsou C prekladace tak dobre, ze sice jde rucne napsat lepsi asm kod, ale uz je to hodne tezke a malokdy se podari prekladac trumfnout. Tento postup je (IMHO) dobry pro skutecne kratke subrutiny, co treba nahrazuji 1-5 instrukci a pro ktere je bezny postup (dynamicka knihovna atd.) spis zdlouhavy.

Překladač lze trumfnout skoro vždycky. Problém ručně psaného assembleru není v tom, že by bylo nějak komplikované něco napsat líp než to vygeneruje překladač. Problém je v tom, že to je časově náročné (hlavně když potřebuju něco komplexnějšího, třeba 2-5k řádků v asm), takže budu psát asm jen když to je opravdu nutné a jinak to nejde.

Díky za článek.

Když jsem před 40 lety opouštěl assembler na Z80 směrem k Pascalu na XTčkách, tak jsem nečekal, že se s ním budu potkávat v mém oblíbeném Pythonu.

A co víc, že bych pro něm měl i reálné využití. V oblasti IoT, nebo výukových projektech.
Například s LEGO Mindstorm EV3, kde je procesor ARM926EJ-S na 300 MHz, jsme se studenty potřebovali zrychlit smyčku vyčítání dat z optického senzoru. Micro/Pythonovská verze byla cca 10x pomalejší, než jejich nativní.

Jak daleko jde s tímhle přístupem zajít?
Grafický výstup? Audio I/O? CUDA?
Nebo to v takových případech nemá moc efekt a je lepší sáhnout po specializovaných knihovnách?

Micropython nemá ctypes.

https://docs.micropython.org/en/latest/library/uctypes.html

To je přece něco úplně jiného. Ten uctypes je zjednodušený, statický modul určený pro nízkoúrovňový přístup k paměti v embedded systémech, kdežto ctypes je komplexní FFI rozhraní pro práci s C API v plném Pythonu. Proto uctypes neumí volat knihovny a nabízet ho jako alternativu ctypes k volání knihoven značí naprostou neznalost věci.

Graficky vystup by sel, to je docela i pro studenty zajimave (rekl bych). Myslim tim udelat si vlastni gfx library pekne "odspodu", tj. od kresleni pixelu pres rekneme usecky az po floodfill. Je to tak low level, ze minimalne ten putpixel by v assembleru mohli napsat.

Jinak MicroPython ma vlastni podporu assembleru, dost dobrou (a chtel bych to i v CPythonu, ale to asi je ve fazi "co si clovek neudela sam, to nema")

Zajímavé, ale přemýšlím, k čemu to bude prakticky využitelné. Nativní kód bude mít typicky nějaké závislosti mezi funkcemi, případně externí, inicializaci, apod, takže bude vyžadovat běžnou dynamickou knihovnu.

Spíš jsou tedy cílem možná JIT a podobné generátory?

PS: To násobení dvěma půjde zkrátit přes LEA :-)

Ajo LEA, jasne, diky za pripomenuti.

Ja to mam na par malickosti - detekce vlastnosti CPU pres CPUID a par AVX intrinsic. Na vetsi knihovny to neni, ale na pet-deset instrukci v ASM se mi nechce jit standardni cestou .asm/.s -> assembly -> linking -> potom nastaveni LD_LIBRARY_PATH a inicializace dyn.knihovny. Mam tam tu posledni variantu s listingem z NASMu.

Plan je udelat si nejakej generator ala stary TP, ale to je zatim jen v hlave ;)

Nebylo by lepší pro generování toho kódu použít něco na to určené? V C++ existuje třeba AsmJit, což je celkem mikro-knihovna na to co to všechno umí, no a v Pythonu mě napadá třeba PeachPy.

Ono pustit ten JIT kód na všem možném je celkem opruz. Dnes už RWX je celkem luxus, takže to je většinou přemapovávání stránek, atd... No a když někdo dělá JIT, kde se občas musí něco patchnout a systém umožní jen W^X a celé to běží multithreaded, to je peklo...

jj presne o PeachPy to bude priste ;) Ten projekt ma svoje nevyhody, ale prave pro kratsi veci postacuje