Vlákno názorů k článku Příběhy z vývoje nejrychlejšího virtuálního stroje na světě od Marek Knápek - Zajímavá technologie. Díky za článek. Pár poznámek: - Proč...
-
Zajímavá technologie. Díky za článek. Pár poznámek:
- Proč je v benchmarku požita zvláštní třída, jejímž jediným účelem je zvětšit číslo o jedničku? To mi přijde trochu overkill.
- Spojový seznam? Opravdu? Chtěl bych vidět, jaký by byl výkon benchmarku v C++ za použití std:: vector<int> namísto spojového seznamu. Respektive pro C také existuje implementace dynamicky rostoucího pole. Nejspíše v knihovně gLibC.
- Ten interpretr je napsaný v Javě. Proč byl zvolen tento jazyk? Jaké to má výhody / nevýhody oproti třeba C++?
Marek. -
n (neregistrovaný)
A neni tohle vsechno jedno? Ze to jde napsat ve vetsine tech jazyku i jinak, pravdepodobne lip, je samozrejme pravda, ale o tom tahle vec prece vubec neni.
Ze ten clanek je prinejmensim napsany stylem, ktery by si zaslouzil nahore nalepku "reklama" je pravda taky, ale narozdil od jine reklamy kde na me neco rve ruzne barevna animovana kreatura jsem skoro pripraven to nekdy, az nebudu mit nic lepsiho na praci, zkusit na nejake nasi vlastni korporatni prasarne kde taky nikdo uz nic nikdy mikrooptimalizovat nebude protoze na to uz nikdy nikdo nesezene budget a radsi rekneme ze silnejsi HW. -
Děkuji.
Ta speciální třída
Naturalumožňuje propojení dvou jazyků. Lze ji totiž naimplementovat ruby a pak použít v javascriptu.Je to samozřejmě hnané do extrému, ale ukazuje to, co GraalVM dokáže. Přestože je pro každé přičítání jedničky volá do jiného jazyka, je to stejně rychlé, jako když člověk v Cčku napíše
i++. -
Proč Java?
Tak snad nejdříve technická část: To, co kompilátory zpracovávají se nazývá moře uzlů (see of nodes) a jedná se vlastně o prohledávání grafů reprezentujících strukturu programu za účelem jejich změny a zrychlení. Taková struktura se mnohem lépe udržuje v jazyce s garbage kolektorem. V Céčku člověk skončí s tím, že si takovou automatickou správu paměti musí napsat sám. A to je opravdu trochu zbytečné. Viz. úvod k přednášce, kde autor současného C2 překladače (napsaného v C++), říká, že už by jej znovu v Céčku nepsal.
Nyní osobní část: myslíme si, že nástroje pro programování v Javě jsou mnohem pokročilejší než pro jiné jazyky. Dvacet let rivality mezi třemi vývojovými prostředími, jež jsem se měl tu čest účastnit, dostalo Javu úplně jinam, než ostatní jazyky. Navíc je pohodlné používat ty samé nástroje (jako debugger) pro psaní vlastního kódu a zkoumání toho, co kompilátor vlastně dělá. Vezmete si zdrojáky Graal překladače, dáte si někam breakpoint a pustíte svůj Java program, tak jak jste zvyklí. A hle, překlad se zastaví a lze zkoumat, co se tam děje. Podrobnější popis opět v Chrisově přednášce.
Na závěr historická část: GraalVM je založena na výzkumu MaxineVM, což je Java VM v Javě, prováděného v SunLabs kolem roku 2005. Je vcelku přirozené, že Sun upřednostňoval Javu před jinými systémy. Když jsem to tehdy poprvé zaslechl, tak jsem si myslel, že to je pěkná blbost, ale zdá se, že nám to začíná vcelku pěkně fungovat.
-
Jakub Valenta (neregistrovaný)
Neoptimální kód mi naopak přijde celkem realistický. Málokdo má v reálu čas ladit každý detail, stačí když to nějak funguje. Ani implementace v ostatních jazycích nevyužívá standardní nebo další knihovny, takže pro porovnání to není problém. Spíš mi přijde trochu nesmyslné porovnávat s C programem bez zapnutých optimalizací.
$ make
$ ./sieve
Hundred thousand prime numbers in 66 ms$ gcc -std=c99 -O3 main.c -lm
$ ./a.out
Hundred thousand prime numbers in 47 ms
