Z pohledu turingovské rychlosti patří jazyk R k těm pomalejším. Také jeho dynamické vlastnosti jsou poněkud divočejší (nejen, že při vyhodnocování a + b člověk nezná typ a a b, ale zjišťování hodnoty a prý může změnit i význam +!). Ale je vcelku populární a matematici a statistici v něm dokáží divy.
Takže to většinou funguje nějak takhle: skupina statistiků si sedne a sepíše funkce/rovnice v Rku a ověří je na nějakých testovacích datech. Pak se to zkusí pustit na celém balíku dat a GnuR to nedopočítá. Přijde banda programátorů a přepíší části toho algoritmu do Cčka. Pak už GnuR počítá jakžtakž snesitelně.
Naším cílem však je ten přepis úplně odstranit. Máme jednoho interního zákazníka, který udělal přesně to, co popisuji. Nakonec jim ten systém počítal tři dny. Spojili se s námi. My jsme vzali tu jejich původní verzi bez Cčkových částí, doimplementovali, co nefunguvalo, a pustili to na GraalVM. Dopočítalo to za osmnáct hodin.
aha, diky za zajimavou odpoved. Rko nemam tak dobre prozkousene, takze me tenhle problem Rka prekvapuje.
Osobne jedu v GNU Octave, a tam jsem malokdy ziskal prepisem do C vyznamne urcyhleni (ne natolik, aby to opodstatnilo cas straveny prepisem do C). ale taky to je dano oblasti kterou pouzivam, znam jine skripty, ktere v matlabu jedou radove rychleji nez v Octave, takze by prepis Octave do C asi dost pomohl (a zase znam jine, ktere jedou v Octave rychleji nez v Matlabu).