Vlákno názorů k článku Volání subrutin naprogramovaných v assembleru z jazyka Python od Noris - Asi to nikdy nevyužiju, ale je to zajímavé. Dá...

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.