Nenašel by se tu ostřílený programátor C, který by měl po večerech čas se přidat k hodně slibnému cybersecurity startupu? Kdyžtak pls pošta.

Konkrétně, skrz sys_clone:
linux kernel - What are parameters of sys_clone() system call and how to hook it in Ubuntu? - Stack Overflow
https://stackoverflow.com/...at-are-parameters-of-sys-clone-system-call-and-how-to-hook-it-in-ubuntu
Druhý parametr tohohle volání jádra je pointer na vlastní stack vlákna, bez kterého by spuštění vlákna bylo nebezpečné a skoro nepoužitelné.

(Bylo by to Linux specifické, ne POSIXové... a samozřejmě, když by se rozhodli to API mezi verzemi kernelu nějak změnit, tak se mi to celé sesype... ale mě se POSIXové thready nezamlouvají jako vhodný způsob myšlení o paralelizaci kódu)

(Uvažuju totiž o nějakém multithread frameworku, ale spíš než nastartovat si na začátku pool threadů a nějak ho úkolovat bych chtěl využít linux-specifickou vlastnost startu nového threadu ve stylu forku, konkrétně je to nějaký ARCH_FORK() a systémové volání clone(), pozor nikoliv ten clone() o level nad tím.. v zásadě jediné, co nové vlákno doopravdy nutně potřebuje, je vlastní stack, tak uvažuju místo poolu vláken na začátku alokovat pool stacků odpovídající max. počtu vláken které chci používat, a v místě startu nového vlákna si jen hlídat, zda jsem ten na začátku odhadnutý počet vláken nepřekročil... další mechanismy které mi napadají v místě, kde si můžu vybrat jestli paralelizace ano či ne, by např. kromě počtu aktivních vláken byl i počet mikrosekund od poslední paralelizace, aby se třeba zbytečně neparalelizovali velmi rychle probíhající cykly apod)

How to get the number of CPUs in Linux using C? - Stack Overflow
https://stackoverflow.com/questions/4586405/how-to-get-the-number-of-cpus-in-linux-using-c

XCHAOS: Děláme ve špatném odvětví...

2019's Fastest Growing Programming Language Was C, Says TIOBE - Slashdot
https://developers.slashdot.org/...32230/2019s-fastest-growing-programming-language-was-c-says-tiobe

(jo ten člověk byl pak známější jako autor Scramble, co jsem pochopil.. no pro mě byly 8bit hry v assembleru nedostižný mýtus, já matlal věci jen v Basicu... )

JANFROG: jsem tam ještě doklikal rozhovor s původním autorem toho bludiště a ten zní úplně normálně :-) prý měl proste bludiště, které nemělo žádný herní námět a předal jim ho a oni ho brutálně osekali, aby se k tomu vešla ještě hra.

stejně je to síla, psát programy u kterých se zapisje jen do pár bajtů. dnes jsou lidi šíleně zmlsaný...

K předchozímu: Regardless of which version of events is followed, it seems fair to say that some level
of intoxication was involved in the development of the maze algorithm.

No, aspoň tahle archeologie ukazuje, že Céčko bylo ve své době fakt high-level :))

Trocha opravdového assembleru z historie (i pro mě je tohle historie, já se poprvé setkal až se Z80 :-). link via Slashdot...
https://arxiv.org/ftp/arxiv/papers/1811/1811.02035.pdf

Lehce offtopic :-)

Cfluviurrh - Esolang
https://esolangs.org/wiki/Cfluviurrh
As science progresses, some systems that we might see able to correctly execute Cfluviurrh include
- a psychologically normal chimpanzee with an exceptional emotional range and an electronic computer, acting in concert

XCHAOS: No urcite. Akorat ze to, ze spousteni extra threadu ma rezii, kterou nemuzes ignorovat jsem ti rikal uz od zacatku. Ale pochopitelne, kdyz neco rika Redguy, je to to fuj fuj osklive off-topic trollovani, kterej potreba ignorovat nebo rovnou zabavnovat, zatimco ted, kdyz si idiot ted to samy konecne precetl nekde jinde, tak je to idiotova zasluha 8)))

REDGUY: no vida, konečně se mi diskusi podařilo stočit někam ontopic :-) tak jestli využiju tohle, můžu autorovi koupit koupit kafe, zdá se :-)

ANT_39: mno. takže řešení připravené rozparalelizovat _jakýkoliv_ cyklus by vlastně místo na trhu našlo... :-)

LUDO: zajímavé by bylo vyzkoušet, jak ta paralelizace dopadne v případě, že podmínka v tom cyklu je nějak složitější, než jen prosté počítadlo. každopádně dík za inspiraci, konečně sem někdo po několika týdenní flamewar vnesl nějaký ontopic :-)

XCHAOS: ti to mozem porovnat z hlavy, kedze OpenMP pracuje na urovni kompilatora, musel by si byt velmi velky maestro aby tvoj C kod bol rychlejsi

A ano, OpenMP to robi presne tak, pokial mu to parametrom povies.

LUDO: částečně máš pravdu, že vytvoření threadu má režii... neřeší tohleto právě ty go-routines?

tak mi napadá, že velká frajeřina by vlastně byla napsat v C kód, který recykluje již jednou vytvořená vlákna. normálně, po dokončení threadu by tehle thread nezanikl, neukončoval se - ale čekal by na nějakém semaforu, až se mu předá pointer na funkci, kterou má dále vykonat. takže by se nepracovalo přímo s phthreads, ale runtime by spravoval nějaký pool threadů (jako to dělá většina aplikací s podporou multihtreadingu, typu Apache)

začíná mi to do sebe v hlavě docela zapadat (stejně mi vycházelo, že ten můj highlevel zdrojový kód bude z řady důvodů překladač do C muset rozkrájet do řady automaticky generovaných funkcí, protože C prostě nemá nic jako anonymní funkce nemá... stejně tak všechny lokální proměnné budou ve strukturách, na které půjde předat pointer, apod.).

je pravda, že už se to celé začíná trochu podobat operačnímu systému :-) Jestli to OpenML dělá přesně takhle, tak je to dost zajímavé... ale v tom případě by stálo za to srovnat výkonost kódu který paralelizuje OpenML s tím mým :-)

LUDO: A v tom Pythonu, na kterej XChaos miri, samozrejme existuje ThreadPoolExecutor, kterej presne tohle dela.

K comu preboha generovat medzikod ked tam staci vlozit jednu direktivu preprocesora - protoze XChaos si vymyslel, ze generovat C jako mezikod je cool, tak ted hleda neco, na co by to pouzil. Ze to nedava smysl je irelevantni.