JANFROG: a to jsi ani nezminoval, ze nativni interface nebyva tak uplne stabilni. Cimz teda nechci nodejs pomlouvat...

REDGUY: Me zajima tady rozbirat konkretni pripady z praxe, kdy nekdo neco takovyho zkousel a jaky to melo uskali.. a co z toho zjistil, jaky to ma uskali, ktery na prvni pohled nejsou zjevny a tak.

tak se ptam na nejakej priklad z praxe z vyssich jazyku - a na to jsem ti odpovedel. Ale protoze zjevne google neni tvuj pritel, tak zkus treba kliknout na https://docs.python.org/3/library/ctypes.html
Podobny veci si umim najit taky, ale to je pro porad jeste obecny, jestli jsem neco neprehlidnul, tak tam nenajdu zadny mereni - cisla, benchmarky, to co by se tady melo resit.

RUTHAN: Jako jestli se ptas "existuje situace, ve ktere ma pro zvyseni rychlost smysl prepsat cast kodu z Pythonu/Javy/etc do C a da se to nejak merit", tak odpoved je samozrejme ano, ano. Ale to je snad dost zjevny, ne?
V realu zalezi na spouste veci. O kolik je ta C implementace rychlejsi? Jak rezii ma konkretni FFI v tvem jazyce? Kolikrat to budes volat? Jaky data a jakym zpusobem se predavaji mezi tema jazykama? Jakej celkovej impakt na vykonost ta prepsana cast ma? A v neposledni rade, u jakyhokoliv netrivialniho systemu se musis zeptat i "stoji mi zvysena slozitost za to?" Atd, atd, atd. Ver mi, k upresnovani je tam toho _fakt_ hodne 8)

tak se ptam na nejakej priklad z praxe z vyssich jazyku - a na to jsem ti odpovedel. Ale protoze zjevne google neni tvuj pritel, tak zkus treba kliknout na https://docs.python.org/3/library/ctypes.html .

REDGUY: Me to prijde dost konkretni, ze uz neni potreba nic upresnovat, mam pomalou funkci / metodu / proceduru, tak pouziju nejake wrapper pomoci kteryho ji muzu napsat v nejaky rychlejsim jazyce a pak to cely zalovam a zmerim si, jestli kolik a jestli jsem usetril.

Konkretne to smysl aplikovat uplne na vsechno - co je pomale a jsou penize (cas) na optimalizaci. Ja aby se hnusa diskuze, tak se ptam na nejakej priklad z praxe z vyssich jazyku.. abychom neresily inline ASM v C++ , to je taky rychlejsi, ale to uz je lowlevel, za very lowlevel a to se prey dneska ani moc nedela, to uz musi bejt neco fakt performance critical typu, vykreslovani algoritmy ve hrach na konzolich nebo tak neco... driv se to asi delalo pro kdejakyho svaba, ale dneska bych rek, ze si radsi nekdo koupi o dolar drazsi cip, kdyz aby platil tu optimalizaci.

Protoze pokud pouziju dostatecne rychle jazyk, tak tim vydelam vic, nez kdyz v puvodnim jazyce.. a optimalizace algoritmu muze nebo nemusi mit byt vcetne.
Jinak ono je fajn optimalizovat algoritmy, ale kdyz nekdo pise efektivne a vsechno je volani celkem jednoduchych levnych kusu kodu, tak tam proste neni, kde tolik usetrit na algoritmech, ale je potreba aby to "litalo"..

RUTHAN:
Nasledujici je muj pohled na vec, zcela jiste zatizeny (biased) (ne)zkusenostma s implementaci ruznych VM (a mnoha probdenyma nocema a vytrhanyma vlasama pri debugovani pro me nepochopitelnych bugu :-)

TL;DR: To se tezko zobecnuje. Zalezi na danem runtimu / VM a jeho designu. Rule of thumb je cim sofistikovanejsi runtime, tim mene se to vyplati (jinymi slovy, to co ti v (C)Pythonu pomuze, to se ti v Hospotu / J9 nevyplati). Jak rika KING, profiler je nejlepsi kamarad.

Long story:
C# neni ani lepsi, ani horsi nez ostatni. Moznost volat externi kod ma kazdy runtime/VM, (Java, vesmozne Smalltalky, LISPy, Python...), bez toho to totiz moc nejde. Java take mela od zacatku JNI. Uvaha ze
> C# to ma asi udelany dobre protoze tenhle unsafe C mod je tam od zacatku officialne
je, z meho pohledi, mimo.

Pri designu FFI jsi omezen designem runtimu / VM. Napriklad pokud VM pouziva svuj vlastni
stack pro managed kod, musis prepinat stack. Pokud pouziva jinou volaci konvenci, musis -ukladat registry (a toho nemusi byt malo, napr na POWER architekture ma 32 GPRs, 32 FPRs, 8 CCRs, 64 128bit VSRs...). Dalsi vec co musis resit je jak pristupovat k parametrum, co vsechno je treba udelat zalezi dost na designu memory manageru (moving / non-moving, write-barrier / read-barier / both). Java (JNI) je v tomhle extremni monstrum, protoze GC je implementation defined takze JNI musi pocitat se vsema variantama takze je indirekce na vsechno -> ma to svou rezii - a dost jinych jazyku je ale jeste horsi, protoze to neresi vubec takze se to programuje stytem "udelej to takhle, protoze tenhle runtime je primitivini a muzes si to dovolit" a pak to skonci na tom, ze nemuzes udelat nic lepsiho, protoze to rozbije veskery existujici kod. Hello, Ruby :-)

Ve zbylem prostoru v zasade vice ci mene vedome volis bod v intervalu

RUTHAN: jasne, nesmi se to delat kvuli nejakym predpokladum ktere muzou byt (a casto jsou) chybne. Prave proto jsem zminoval ten profiler ktery se pak samozrejme opet pusti na vyslednou hybridni implementaci aby se overilo, zda je efekt skutecny

KING: Jako ono to dava smysl, ale chce to nejaky cisla jaka je rezije a tak. Odecist nejaky 2 timestampy pro nativni a C implementaci a zaplat je to pole a jednou za cas hodit do logu, by nemela byt velka prace..

RUTHAN: parkrat jsem pouzil osobne Python + nejaky kompilovany jazyk pro kriticke casti a obecne se to pouziva hodne. At uz C (velka cast std knihovny je v C), cython, nebo nove Rust. Za me je to idealni kombinace - rychle si neco napisu v "pomalem" jazyce, pustim si na to profiler abych zjistitl co je nejhorsi cast a tu prehodim do "rychleho" jazyka (spis idealne se podivam po knihovne ktera uz tohle resi).

Ma nekdo zkusenost s tim, ze proste vezme neco v pomaly jazyce a pouzije C++ wrapper pro nejaky pomaly funkce a vola to pres nej jaka je rezije toho wrapperu, jak moc se to vyplati?

C# to ma asi udelany dobre protoze tenhle unsafe C mod je tam od zacatku officialne.. ale treba Java, Python etc tam to asi takova sranda nebude.
Jinak pouziva se to i opacne co jsem se bavil s kamaradem, jak rozjed neco v C++ na Androidu, tak tam se opacne prida je nejaka Java obaleni.. a pak pouzije svuj multiplatformni C++ kod. Nicmene tam taky bude nejaka rezije, bud jen pro samotny spusteni.. nebo i pro ten runtime.

WOODMAKER: Ty Python je jeste daleko pomalejsi nez Java, takze vsechno je zlepseni.. Jinak to spusteni Javy - jak mate nastavenou JVM (min, max mem a tak), to muze mit vliv.

JANFROG: zatim to je ten posledni problem. Ale diky za tipy.

WOODMAKER: > Ale spousteni netrva 2 sekundy, ale pul minuty
A co pouzivate za VM, hotspot? Muzes zkusit J9, pokud vas ta pul minuta stve, startup time se da zredukovat pouzitim AOT).

MARASAN: tak koukám od benchmarků jsme rychle postoupili k optimalizacím a to rovnou k optimalizacím skrz paralelizovatelnost :-) ok, to je fakt už "vyšší dívčí", tam asi hraje roli podíl toho, kolik je fakt počítání (takže se použije více threadů v procesoru) a kolik třeba přístupy do paměti (kde je úzke hrdlo sběrnice)