Doporučuji benchmark třídění 1000000 32-bit int.
K čemu? Nikdo netvrdí, že dynamické, asynchronní, paralelizovatelné systémy jsou dobré na number crunching hrubou silou. To je samozřejmě dobré napsat v něčem jiném a s tím něčím jiným komunikovat vstupy a výstupy. Numpy i R funguje přesně takhle, je to jenom lepidlo a vlastní nuber crunching se dělá maximálně optimalizovaně. Proto je takový rozdíl použít v Rku for a apply
To jsem rád že jsme si to konečně ujasnili, tedy původní návrh s KayObject je dodnes z technických důvodů použitelný jen těžce.
To nevím, čím jsme si to ujasnili, ale nemám potřebu se hádat
Nutným předpokladem asynchronnosti je na sobě nezávislý paralelní běh asynchronních funkcí.
Zavolání funkce a nečekání na výsledek, s tím že dále to pokračuje přes callback nebo doručení zprávy je stále synchronní záležitost.
Zkusím to ještě jednou: Erlang VM má vlastní scheduler, který přepíná procesy, které běží naprosto nezávisle. Na jednojaderném stroji jsou samozřejmě ty procesy serializované, protože jaksi je tam prostě jenom jedno jádro. Ale "zevnitř" to člověk nepozná, funguje to pořád stejně ať je to jádro jedno nebo je jich 256.
Zjevně volně zaměňujete komunikaci mezi procesy a komunikaci uvnitř procesu. Při práci uvnitř procesu nepotřebuji hledat funkci podle názvu, protože znám její adresu rovnou. Při komunikaci mezi procesy to takhle není dost dobře možné, proto se funkce hledá podle názvu.
Nic nezaměňuju. Mluvím o tom, že existují systémy, které funkce vyhledávají v runtimu i pokud běží v jednom VM. Že to jde i jinak, o tom není sporu. Já jsem říkal, že pokud se to dělá
vždy takhle, dá se
vždy použít dynamický dispatch. Pokud se volání překládá na CALL, tak to samozřejmě nejde a žádný dynamický dispatch se nekoná, to je přesně ta pointa, nevím, kde je spor.
Tohle přesně uvnitř většího projektu nemá co dělat.
Existují lidi, kteří si myslí, že má. Beru na vědomí, že ty si to nemyslíš a jsem rád, že to vím
127 Odpovědí
84126 Zhlédnutí