XCHAOS: já jsem ochotný přemýšlet maximálně jednou a dost - ver mi, to pro vetsinu lidi, co te znaji, neni zadna novinka 8)))

XCHAOS: nebaví mi programovat na platformě,kterou všichni za 5 let zahoděj - a timhle chces rict co? Jako kdybysme se bavili o javascript frameworkach na klienta, tak ok, tak je polocas rozpadu tak dva roky. Ale normalni jazyky? Namatkou: Python 2.0, 2000, Python 3.0 2008, Perl5 1994, PHP5 2004, Erlang 1986, Clojure 2007 (a pokud ji budu brat jako dialekt Lispu, tak motherfucking 1958 8)) ). Dokonce i ten Node.js je skoro deset let starej: 2009. Takze prosim, vysvetli mi, o jake "platforme, kterou vsichni za 5 let zahodej" mluvis?

XCHAOS: Tobe to bizarni neprijde? Nekolikrat jsi rikal, ze chces udelat neco, co bude plne vyuzivat vicejadrovy procesory. Fakt ti prijde naprosto v poradku, ze se pak omezujes jen na ten uplne nejtrivialnejsi zpusob multithreadingu (s tim, ze zjevne nechapes, ze i ten je slozitejsi, nez si myslis)? Opravdu opravdu opravdu ti to prijde normalni a v poradku? Nebo jsi proste zase jen tak nahodne neco placnul a kdyz jsem ti zacal ukazovat, ze to je blbost, tak ses proste sprajcnul a napises cokoliv, abysto nemusel uznat?

REDGUY: já jsem ochotný přemýšlet maximálně jednou a dost :-)

REDGUY: podívej, tebe by neuspokojilo nic...

já fakt nevím, jak to napsat, aby ti to nepřipadalo "bizarní". co takhle "nebaví mi programovat na platformě,kterou všichni za 5 let zahoděj... ale odhodlat se programovat přímo v čistým C jsem se mi nepodařilo ani po 15 letech snahy, takže hledám nějaký kompromis" ?

GIANT: přiznávám se, že je to částečně offtopic :-)

v mezicase si asi fakt prectu celou ANSI C specifikaci, jak mi tu kdosi kdysi doporucil :-D

ciwe dalsich 30 kilometrovejch postu. to nedam. az se na necem dohodnete, tak sepiste zavery, jestli k nejakm spolecnejm teda dojdete :-D

Ale hlavne, cela ten myslenkovej veletoc:

Udelam programovaci jazyk, jednim z jeho hlavnich cilu bude plne vyuziti vicejadrovych procesoru!!!!!

... ale co se multithreadingu tyce, "doporucenej pattern" bude jen paralelni zpracovani prvku nejake kolekce.

Neuveritelny bizarnosti jako tahle jsou presne ten duvod, proc me tak bavi "debaty" s tebou 8))

XCHAOS: a kromě toho... myslel jsem, že operátor ++ je atomický a převede se naprávě jednu instrukci CPU - tak to sis myslel blbe. Za prve, standard o atomicnosti nic nerika. Za druhe, ++ se na jednu instrukce prevest muze ale nemusi. A za treti, ani ta instrukce (by default a na x86) neni atomicka. Wow, tendlecten multithreading je cim dal tim slozitejsi, co? Muzes prosim odpovedet na moji otazku? Kolik nejak vyrazne multithreadovyho kodu uz jsi napsal?

ale featury jako semafory tam můžou samozřejmě bejt taky 8)))) Ty ses fakt designer jazyku. "Proste tydlecty featury, ty tam muzou bejt taky, no" 8))))

podstatný je, že spoustu věcí můžeš dělat paralelně bez velkýho přemýšlení (typicky ti třeba z jedné zpracovávané položky vznikne jiná položka - No, zjevne nemuzes. Resp, prave nazorne demonstrujes, ze to sice muzes udelat bez velkyho premysleni, ale je pak slusna sance, ze to udelas blbe. Prekvapko 8))))


třeba insert do databáze je atomický tak nějak z principu, i když se o něj pokusí víc vláken současně - aaaaaargh. Vis co znamena slovo "atomicky"? Slysel jsi nekdy o transakcich a k cemu slouzi?

REDGUY: ale featury jako semafory tam můžou samozřejmě bejt taky (a kromě toho... myslel jsem, že operátor ++ je atomický a převede se naprávě jednu instrukci CPU?)

podstatný je, že spoustu věcí můžeš dělat paralelně bez velkýho přemýšlení (typicky ti třeba z jedné zpracovávané položky vznikne jiná položka... a třeba insert do databáze je atomický tak nějak z principu, i když se o něj pokusí víc vláken současně... i když zrovna s libmysql jsem zatím pokusy s multithreadingem pravda nedělal)

(částečně je to i o tom, že já všechny tyhle pokusy chci dělat, ale potřebuju mít nějakou záminku, proč je dělat - směřovat někam, dělat to v rámci něčeho...)

XCHAOS: můj způsob alokace byl natolik geniální, že ty si ho vůbec nepochopil - LOOOOL. No urcite. Uplne stejne jako jsem nechopil genialni zpusob, kterym jsi chtel diky technologickemu naskoku vyhrat SunTrip. Prosim, pripomen mi, jak to nakonec dopadlo? 8)))

XCHAOS: ehm, serverový aplikace běžně sahají na sdílené prvky, že ... třeba když čtou výsledek databázového dotazu, který sahá na databázový cluster? nebo když sahají na diskové pole? - jezismarja. Ty proste fakt vubec netusis. Vubec se nemusime bavit o nejakejch databazich. Co kdyz chces spocitat, kolik prvku nejakyho pole splnuje nejakou podminku? Mas nejakej spolecnej counter, spustis n threadu, ty zacnou koukat na jednotlivy prvky pole a pokud prvek splnuje podminku, tak inkrementes counter. Akorat ze ten inkrement musis delat atomicky, takze co? Aha, semafory, zamykani ktery udajne nejsou potreba. Ten sdilenej zdroj nemusi bejt nejakej server, ale ciste jen ta jedna spolecna promena. Plus samozrejme takovy detaily, ze na moderni architekture muze bejt jeden thread, co frci skrz pole, mnohonasobne rychlejsi nez x threadu, ktery si to pole mezi sebe nejakej rozebiraji (protoze rezie threadu a hlavne kouzla na urovni procesoru a pristupu k pameti).

A btw, co jsi prosim chtel rict tou citovanou veci? Ze serverovy aplikace NESAHAJI na sdileny prvky jako databaze? To jako vazne?

Proste zase: tvoje predstava ze "kdyz se omezim na paralelni zpracovani prvku pole, nepotrebuju zamykani a semafory" je neuveritelne naivni.

(btw, myslím jsem jeden čas směřoval k triku, že jsem forcnul aby parametr makra v C, aby to musela být LValue :-) čímž se zabránilo double evaluation. ale uznávám, že to asi není way to go :-)

REDGUY: popravdě, můj způsob alokace byl natolik geniální, že ty si ho vůbec nepochopil, podle mě. (ale připouštím, že si mě zastavil v jiných zajímavých bodech, např. problém s double-evaluation parametrů makra, apod.)

no, vlastně si nejsem jistý, jestli je víc bambilion nebo bazilion

REDGUY: ehm, serverový aplikace běžně sahají na sdílené prvky, že ... třeba když čtou výsledek databázového dotazu, který sahá na databázový cluster? nebo když sahají na diskové pole?

podívej, já prostě občas počítám nějaká "big data" (tedy typicky, bambilion příliš často logovaných nesmyslů za X let provozu něčeho) a s každým jednotlivým prvkem dělám něco. zažil jsem ale data mining, kdy skripty běžely celou noc a přepisovaly se kvůli tomu do céčka (tedy, ne v mojí firmě).

dnes jsou sice počítače zase o něco rychlejší, ale zase se shromažďuje ještě více dat, za ještě více let... a nástroje, které se používají, jsou také zase o něco více bloated.

každopádně, představa, že chci něco spočítat přes bazilion databázových záznamů, a každý ten výpočet pro jeden záznam kupodivu chvíli trvá, a mě se na počítači fláká 8 jader, a jediná alternativa, kterou mí nabídne python, je pustit 8 procesů současně ručně na ručně vymezené intervaly dat... tako jako říkej si co chceš, ale mě můj požadavek přijde příčetný

ad to, že jsem přišel na to, jak se něco dělá - no, takže když na něco nepřijdu, tak jsem idiot, a když na to přijdu, tak je to facepalm? že já se vůbec snažím... podstatné je, že dneska je multithreading zbytečně složitý, některé platformy se mu důsledně vyhýbají.. a já přitom myslím, že by to mělo být tak průzračně jasné, jako bylo programování v Basicu na ZX spectru :-)

jak říkají lidi co objevili Python.. že je programování najednou zase začalo bavit...

doporučeným pattern-designem bude právě pouštět je pro více prvky nějaké datové struktury, protože pak nemusíš řešit žádné zamykání, protože je jasně dané, že na jeden prvek si pustil jedno vlákno. dokonce si myslím, že tenhle design patter by mohl slušně řešit většinu věcí typu zamykání - max. pokud následně budeš chtít s prvky dělat něco jiného, dáš si na konci toho rozvětvení něco jako "wait all", což počká na doběhnutí všech spuštěných threadů... a nemusíš řešit semafory, zamykání, nic. - HAHAHAHAHAHAHA. Ach boze. Za prve, pitomost, protoze v okamziku, kdy funkce, zpracovajici jeden prvek sahne na nejakej sdilenej zdroj, tak samozrejme ty "semafory, zamykani" musis resit. Za druhe, tvuj jazyk, kterej explicitne vymejslis za ucelem lepsiho vyuziti vicejadrovejch systemu, bude v multithreadingu poradne podporovat ciste jen paralelni zpracovani prvku nejakyho pole? BUAHAHAHAHAHA 8))

představ si to tak, že můj code generátor nebude proměnné mateřského jazyka implementovat jako lokální C proměnné, ale vždy pro každý scope vygeneruje strukturu místních proměnných, která vždy půjde předat jakékoliv funkci - /facepalm. Jo, to je opravdu uzasnej trik a zcela originalni napad. Teda, akorat ze to je normalni zpusob, jak se to dela, zejmena v situaci, kdy potrebujes closure, takze alokovat lokalni promeny na stacku neprichazi v uvahu.

Jak rikam, _PRECTI_ _SI_ _O_ _TOM_ _NECO_.

REDGUY: určitě nejde o to, jak se jmenuje jaká podstatná věc. moje cíle nejsou tak vysoké, jaké má Go a Rust - naopak, sázím na to, že C nepřestane existovat, a že zpětná kompatibilita s C mi zajistí existenci (ostatní cílové platformy pak jsou určeny spíše než co jiného "na hraní" - benchmarkování, flamewary spříznivci těchto cílových platforem, a taky přenositelnost na místa, kde nemůžu přeložit nebo i jen deploynout binárku,...taková místa pokud vím stále existují...)

nicméně, tím že z toho půjde vygenerovat binárka, a že to bude mít nějakou podporu i pro uvažování z hlediska threadů, tím skutečně cílím _trochu_ tam, kam cílí Go a Rust. jenomže nemám tak velké ambice a na příkladu, který jsem uvedl, je vidět, že za nejobvyklejší využití threadů pokládám prostě paralení zpracování prvků nějaké sbírky/kontejneru.... naopak, kdybych tam měl strukturu, která _garantuje_ paralelní spuštění kódu, tak si tím znemožním využití třeba webového PHP jako cílové plaformy!

ačkoliv ty thready u mě půjde odstartovat za jakýmkoliv účelem, tak doporučeným pattern-designem bude právě pouštět je pro více prvky nějaké datové struktury, protože pak nemusíš řešit žádné zamykání, protože je jasně dané, že na jeden prvek si pustil jedno vlákno. dokonce si myslím, že tenhle design patter by mohl slušně řešit většinu věcí typu zamykání - max. pokud následně budeš chtít s prvky dělat něco jiného, dáš si na konci toho rozvětvení něco jako "wait all", což počká na doběhnutí všech spuštěných threadů... a nemusíš řešit semafory, zamykání, nic.

je to vlastně moje typický uvažování o těhle složitých věcech, kdy často univerzální nástroje jsou moc lowlevel a postrádají úplně základní intuitivní infrastrukturu (typicky "pusť tohle jako nový thread, pokud jich ale teda už neběží moc současně")

nicméně je třeba připustit, že část své několikaleté debaty si vyhrál, protože některé z těhle věcí si už fakt nedovedu představit, že bych jednoduše zapouzdřit do C knihovních funkcí a maker, aby to bylo fakt user friendly.

je dokonce možný, že abych z mnou požadovaných konstrukcí mohl jednoduše generovat C kód, tak budu muset všechny místní proměnné deklarovat uvnitř nějakých struktur, a to, co u mě budou anonymní funkce, bude v mezikódu definované jako funkce a budu tam muset předávat pointery na strukturu s proměnnými nadřazeného scope... tahle věc mi mimochodem vyřeší nejen thready, ale taky by mi docela elegantně vyřešila otázku dealokace paměti alokované uvnitř scope.

představ si to tak, že můj code generátor nebude proměnné mateřského jazyka implementovat jako lokální C proměnné, ale vždy pro každý scope vygeneruje strukturu místních proměnných, která vždy půjde předat jakékoliv funkci (protože mi všechny funkce faky vygeneruje code generátor, tak můžu pustit z hlavy délku zápisu). je to něco jako objektové programování, ale každý scope se takhle vlastně stává scope, do kterého můžou nahlížet funkce, které z něj zavoláš (trochu jako vypadalo programování v Pascalu, takže mi to umožní definice "lokálních funkcí", které uvidí do proměnných scope uvnitř kterého funkci defunuješ, ale hlavně mi to umožní generovat v mezikódu C funkci pro všechno,co bude v nadřazeném jazyce anonymní funkce (viz deklarace function() v Javascriptu), současně mi to umožní generovat mezikód bez globálních proměnných...

(asi už jsem tu kdysi psal psal o tom, že mi vzdáleně podobný trik kdysi v 90kách ukazovali v jedné francouzské firmě, která licencovala Arachne browser, s tím, že tam nepoužívání globálních používali jako trik nejen k "thread k safety", ale i možnosti poslepovat jakékoliv fragmenty kódu do jediné programu... každám main() funkce pak má strukturu s vlastními globálními proměnnými... oni ale pouze trvali na tom, aby se místo globálních proměnných používala prostě struktura, na kterou jde předat pointer. tuším stejně to řeší i transcompilery z C do C++...)

trik, kdy proměnné každé funkce se automaticky stávají objektem, na který jde předat pointer, se mi popravdě líbí, akorát znamená overhead tam, kde to není potřeba... a zase: od toho máme generátor kódu, který se může podívat, jestli to bude někde v překládaném zdrojáku potřeba a může tuhle feature zapnout jen pro ty scopes, ve ktrerých se vyskytne potřeba, aby to tak bylo! dtto alokace paměti - když překladač uvidí, že na alokovanou paměť žádná reference vůbec nemá šanci vzniknout, použije daleko tupější alokační strategii, než pro složitější kód, nebo stejně tak může v nadřazeném jazyce být zápis operací pro pole fixní délky a pro pole proměnné délky stejný - ale v mezikódu se můžou použít naprosto struktury...