Vlákno názorů k článku Techniky zvýšení výpočetního výkonu počítačů od Vuk - Jazyk occaml neexistuje. Existují OCaml nebo occam, tady...
-
Vuk (neregistrovaný)Jazyk occaml neexistuje. Existují OCaml nebo occam, tady jde zjevně o ten druhý.
Čekal bych, že zažije (occam či nějaký příbuzný jazyk) docela renesanci, až se zjistí, že už na multicore standardní jazyky (C++, Java) docela selhávají - běžně používané techniky synchronizace mezi thready najednou nestačí; Java sice nabízí prostředky, jak to řešit, jenže jsou zoufale neobratné a mají hroznou režii. Soudím, že to je v základech jazyka, že tady žádné flikování bez podstatné změny principu nepomůže. -
Pavel TišnovskýZlatý podporovatelAno, jde o occam, omlouvam se za mateni. Mozna az kdyz se skutecne vice zacnou pouzivat multicore (treba vic jak ctyri, osm jader), tak by podobny jazyk zacal byt skutecne uzitecny (prozatim se to da na dvou jadrech resit "rucne"). Ale jde o to, zda se occam prosadi sam o sobe, nebo se podobna technika prida do mainstreamovych jazyku, za kterymi stoji zastupy vyvojaru. Jinak PCcko jako takove je flikovane od zacatku, takze by to nebyla zadna novinka :-( -
Ondrej 'SanTiago' Zajicek (neregistrovaný)Osobne si myslim, ze (minimalne blizka) budoucnost patri rozdelovani ulohy na tak hrube casti, aby se minimalizovala nutna komunikace mezi thready (nebo procesy). Nejenze tim odpadaji problemy se synchronizaci, ale je to i rychlejsi (odpada vzajemne invalidovani si cachelines mezi procesory).
-
Vuk (neregistrovaný)Přesně tak. Z toho mi ale právě vychází to, co říkám - například v Javě něco takového dělat jde, ale je to hrozně neobratné a nepohodlné, a nezdá se mi, že to lze opravit přidáním nějaké nové jazykové konstrukce či nového nástroje. Mimochodem - neplyne z toho taky postupné opuštění threadů a pokorný návrat zpět k procesům?
(A k funkcionálním jazykům - těm patřila i minulost a přítomnost, akorát mainstream si toho ještě nevšiml :) )
