Cog Virtual Machine uvolněn jako open source

Eliot Miranda oznámil uvolnění doposud proprietárního virtuálního stroje Cog Virtual Machine s JIT kompilací pro Squeak Smalltalk pod licencí MIT. Oproti standardnímu virtuálnímu stroji dosahuje až patnáctinásobného zrychlení.

21.6.2010 14:37 | Pavel Křivánek | Nová verze

Komentáře

[Marek Bernát]

Nechcem znieť ako Jardík, ale ak dobre čítam ten odkazovaný článok, tak to nemá x86_64, čiže to asi neotestujem. Škoda. Rýchlosť bola totiž jedna z pár vecí, ktorá mi na Squeaku vždy vadila, takže by som to určite skúsil.

[Pavel Křivánek]

Nejjednodušší možností je si vyzkoušet předkompilovanou Win32 verzi ve Wine - http://squeakvm.org/win32/experimental/CogSqueak4.1.zip (obsahuje i image)

[Marek Bernát]

Vďaka, toto bolo fakt jednoduché

A vyzerá to moc dobre. Teda, aspoň subjektívne mám pocit, že je to responzívnejšie a aj blbostičky ako otáčanie okien mi už nevyťažujú procesor na 100%, ale dá sa s tým pracovať. Paráda. Možno ma chytí znova obdobie Smalltalku

[Pavel Křivánek]

Zkus se podívat ještě důkladněji na Smalltalk/X. Třeba některé argumenty odsune na druhou kolej - ten s rychlostí určitě

[imploder]

něco o rychlosti (smalltalk/X)

Both the earliest and the newest Smalltalk implementations use their own graphic drawing mechanism - they assume direct control over the displays pixel memory and perform all drawing on the pixel level.

There are good reasons for doing this - the old systems did it since there were no fancy graphic controllers and pixel graphics was a recent invention. The modern smalltalk implementation (i.e.: squeak) does this for flexibility - who else is able to let a 3d animated bunny hover above a browser window, rotating in the z-dimension around the x-axis ?

No to je teda super, ono je to předpokládá grafiku z roku 123, žádnou akceleraci. Dneska máme u okýnek kompozitory, indirect rendering (teda ti, co mají to štěstí a podporují jim to ovladače grafiky). Takže tuhle "flexibilitu" si můžou strčit za klobouk.

[Marek Bernát]

To nie je pekný pohľad na vec. Práve tá flexibilita je na Smalltalku to najlepšie. Je to svet sám o sebe. Interfacing so zbytkom systému je pochopiteľne náročný (z podobného dôvodu sú problémy s 3D akceleráciou vo VirtualBoxe). Ale za odmenu dostaneš úplne nový svet plný možností, ktoré sú obmedzené len tvojou fantáziou (aby som urobil trochu PR)

[imploder]

Píše se tam, že napojení grafiky na Xka nebo Win32 API (a s tím HW vykreslování) je jenom v komerčních verzích, free si všechno kreslí samy. Takže to vypadá, že to dělají schválně, aby si to někdo koupil, ne že by s tím byl technický problém.

[Marek Bernát]

Aha, to som nevedel. Ale aj tak dobre, open source tiež musí z niečoho žiť

[Pavel Křivánek]

Ono je to spíš tím, že komerční implementace to nezbytně potřebovaly a tak byly nuceny to vyvinout a udržovat. U nekomerčních se postupně vyrojila celá řada pokusů o podporu nativního GUI, ale žádné se zatím nepodařilo skutečně prorazit, protože sebou nesou nějaké omezení na platformu, většinou se jedná o one-man-show a kvůli vlastnímu vykreslování to není životně důležité. Buď to znamená mít vlastní toolkit a obsáhnout jím všechny platformy, což je dost komplikované a náročné na lidské zdroje a ani VisualWorks to nezvládají úplně bravurně, nebo použít nějakou vazbu na wxWidgets, Gtk apod., což se zatím nepodařilo prosadit.

Takže pokud jde o uživatelská rozhraní koncových aplikací, dnes se ty vytvářené ve Squeaku/Pharu spoléhají většinou webové rozhraní.

Dle mého názoru je ideální cesta v použití XULu či podobné technologie - aplikace vytváří obecný popis nativního uživatelského rozhraní a o jeho konkrétní zobrazení na dané platformě se postará specializovaný prohlížeč (XULRunner), komunikace pak může probíhat přes HTTP.

http://www.youtube.com/watch?v=pkfSh4pAbdM

[imploder]

Škoda, že se open-source implementace nesjednotí do jedné pořádné. Na tak málo používaný jazyk je implementací strašně moc.

[Pavel Křivánek]

Bohužel je tendence spíše opačná, viz forknutí Pharo od Squeaku

[GR]

Sakra, a zrovna jsem sám sebe přesvědčil zanechat smalltalku a učit se python, přičemž pomalost byla jedním z argumentů. Nechte toho, jinak do toho zase spadnu. Ale vážně, smalltalk je geniální jazyk, ale nikde se nepožívá, proto jsem ho s těžkým srdcem prozatím opustil.

[xm]

Pokud vím tak na Smalltalku mají např. běžet některé bankovní systémy.

[imploder]

Pokud je možné 15-násobné zrychlení, pak to o rychlosti původního virtuálního stroje něco vypovídá Kdoví, jak na tom je ten nový...

[Pavel Křivánek]

Originální VM je čistý interpret bytekódu. Reálné zrychlení je někde kolem tří a je pořád zatím asi třikrát pomalejší než VisualWorks (porovnání s C++) nebo Smalltalk/X

[imploder]

Ty statistiky jsou zajímavé. Dost mě teda zklamal Python, naopak Java je hodně rychlá (ty vtipy už dneska zjevně neplatí). Cog VM by teda měl být rychlý podobně jako Python.

[Marek Bernát]

Tie štatistiky hlavne nie sú úplne relevantné, ako väčšina štatistík, aj keď aký taký obraz dajú. Za prvé sú to úplne umelé príklady, za druhé, kód občas nie je tak dobrý, ako by mohol byť. Ale to si asi zvážil

[Pavel Křivánek]

Když se dá vymyslet benchmark, kde je původní VM Squeaku rychlejší než Java...

[Marek Bernát]

Pekné Ale aj tak to niečo málo ilustruje. Exceptiony sa narvali do všetkých nových prehypovaných jazykov, ale jaksi to neni úplne ono bez rozumného prístupu k stacku (viď UNWIND-PROTECT a systém signálov a reštartov v CL) a zostane rozpačitý polotovar To by ma zaujímalo, jak to funguje v Smalltalku, ale tipujem, že stack si vždy môžem uložiť a zasa obnoviť, keďže všetko je objekt. Je to tak?

Ale ešte viac ma v tom blogu zaujalo to rádio a Horner. Vidím to dnes na príjemný večer v spoločnosti votrelcov

[Pavel Křivánek]

Práce se stackem se většinou liší v závislosti na implementaci. Volnost v manipulaci s ním se docela dobře pozná podle toho, jestli podporuje kontinuace, které fungují tak, jak popisuješ.

Cog VM je zatím nepodporuje, ale netváří se, že to bude problém, jen je zatím nepotřebovali.

Já takhle zase minulý týden zjistil o existenci Hornerova nového Karate Kida - slyším nějaké nové variace na klasické Hornerovy motivy, tak jsem se radši podíval, co to vlastně hrajou

http://www.youtube.com/watch?v=TqPsI-eJzMQ

[Marek Bernát]

Ach ták. Ja som myslel, že to bude nejako podchytené už v štandarde. Mal by som si ho niekedy prečítať

Hehe. Horner je fakt borec v tomto To napr. Williams AFAIK pracoval na viac filmoch než Horner, ale pritom sám seba nevykráda vôbec (samozrejme až na hexalógie typu SW ). Ale v podstate je mi to putna. Ja som schopný počúvať 10x dokola aj jednu a tú istú skladbu a variácia je bonus navyše

[Pavel Křivánek]

Já slyšel i nářky na sebevykrádání od Williamse a úplně malinkej nepatrnej ždibíček pravdy na tom je

Jsem zvědav, jak v tomto směru dopadne Giacchino. Jeho hudba mě příjemě překvapila už v dobách Medal of Honor, ale to jsem ještě nevěděl, že to jméno stojí za zapamatování K tomu mě přinutili až Lost a Airbone (který není moc známý).

http://www.youtube.com/watch?v=Yva83z25OUg, Paestum Landing, Wreckage of Nijmegen, Taking Out The Sighting Tower, Unblocking Utah....

Moc hezká kompilace pro klavír je

http://www.youtube.com/watch?v=3W8hKKwyjnE

[Marek Bernát]

No, tak ja nejaký motív tiež sem-tam zachytím, ale to môže byť kľudne náhoda. Rozhodne nemám tú istotu, čo pri Hornerovi

To meno nepoznám, ale Medal of Honor malo skvelú atmosférickú hudbu, ktorú som si už v pradávnych dobách vypreparoval z adresárovej štruktúry a mám to ako neoficiálny soundtrack Bohužiaľ, väčšina skladieb je tam príliš krátka. Treba pohľadať niečo oficiálnejšie. Dík za tip

[imploder]

No, jedna věc je asi jistá: dobře napsaný kód v jakémkoliv z těch jazyků bude rychlejší než kód napsaný v Baltíkovi 3, a to pro jakoukoliv úlohu

To byl naprosto nechutně pomalý interpret (na GHz procesoru s vytížením 99 % max. několik tisíc příkazů za sekundu), programuje se v tom až na pár úzce specializovaných věcí typu "čarování", "animované předměty", "oblasti na obrazovce", většinou max. tak vysokoúrovňově jako v C, některé věci nejdou udělat + syntaxe příkazů je pro každý příkaz jiná (pak se těžko chápe, že např. nějaký jazyk *nemá* jako svou nedílnou součást grafické příkazy a přesto není problém v něm grafické aplikace programovat) + není modularita (pak je hodně inteligentní v tom na ZŠ zadat "týmové projekty") + není plno jiných věcí, jinde samozřejmé postupy neexistují (vstup/výstup přes polling atd. - humus, ale jediná možnost) + zdroják je binární blob (zobrazí se v IDE jako ikonky a tahají se myší - to je hlavní výhoda, kterou to celé má).

Jasně, je to pro děcka, ale výkonnostně prostě naprosto zoufalé. No a v takovém jazyce se dá vyrobit bitmapový grafický editor. Samozřejmě nesmí ve skutečnosti pokud možno na žádnou bitmapu šahat, musí to různě ochcávat (kreslit na obrazovku a pak si ji speciálním příkazem fotit atd.), podle toho, co Baltík nabízí. A nebo různé hry (samozřejmě využívající sprity o max. velikosti 39x29 px, 16 barev). Zní to absurdně, ale je to tak.

Ty testy asi nejlíp ukazují, jak rychlé by ty jazyky byly, kdyby se v nich programovalo co nejvíc nízkoúrovňově. Protože třeba na GUI mají API na binární knihovny, které jsou udělané třeba v C/C++ a jsou rychlé, tak GUI v Pythonu nebude 30x pomalejší než v C, i když nějaký výpočet třeba bude. Podobně to, že v Baltíkovi mi může celkem rychle lítat animovaná kachna, vůbec nic nevypovídá o tom, jak je Baltík nechutně pomalý.

Doufám, že jsem nikoho v SGP tímhle neurazil, je to jen pro ilustraci, vaše cílová skupina tenhle web stejně na 99 % nečte

[Marek Bernát]

Jéj, Baltík, to som niekde videl, ale už neviem kde My sme zasa na gympli mali Comenius Logo, prostredie pre LOGO a tam si kreslil pomocou korytnačky Vtedy som to považoval za strašne dementné. Až podstatne neskôr som zistil, že je to dosť zaujímavý funkcionálny jazyk. Ale tou korytnačkou to fakt zabili. Radšej keby nás rovno na gympli učili funkcionálne programovanie poriadne

[imploder]

Stáhl jsem si to, pod wine to funguje. Vypadá to jako KAREL, akorát ten jazyk je nějaký divný... Na baltíkovi jsou nejlepší ty ikonky, není potřeba skoro nic psát a jak se s nima dá experimentovat. CLI je moc hardcore, ale asi jsem zaujatý

Nevím, no, jestli učit se hned funkcionální jazyk je nejlepší nápad. Funkcionální jazyky nejsou moc oblíbené. Jsou hodně abstraktní, nedá se na ně použít přirovnání z imperativního programování "program je jako návod, co dělat, např. jak nakoupit rohlíky" - napsat seznam kroků je intuitivnější než vymýšlet jakýsi vzorec. Zatím jsem četl tutoriál o haskellu - ne že by to bylo nějak nepochopitelné, prostě z toho není moc jasné jak se v tom vlastně programuje. Chápu, že pro verifikaci se přísné oddělení vstupu/výstupu hodí, ale začátečník to ve svojem jednoduchém prográmku stejně nevyužije, spíš bude zmatený jako já.

P.S.: Zkusím to pak někdy pořádně s Real World Haskell.

[Marek Bernát]

Podľa mňa neexistuje dôvod, prečo vyučovať zrovna imperatívny spôsob a nie nejaký iný. Funkcionálne programovanie, keď sa dobre vysvetlí, tak môže byť podobne intuitívne. Že je väčšina tutoriálov na úrovni abstraktnej matematiky, to je už druhá vec

Ten tutoriál som zbežne pozrel a na môj vkus sa to príliš zaoberá nepodstatnými detailami Haskellu. Dôležitejšie by bolo ilustrovať hneď od začiatku výhody funkcionálneho programovania. Real World Haskell je v tomto trochu lepší, ale tiež prvé kapitoly prechádzajú prakticky celú syntax, čo v Haskelle je a až neskôr sa dostaneš k zaujímavým aplikáciám. Tradične kvalitný úvod do (nielen) funkcionálneho programovania je SICP. Je to síce pre Scheme, ale ten má syntax úplne minimálnu, takže nestráviš 90% učením toho, jak sa konvertuje v danom jazyku string na int, ale rovno sa dostaneš k tomu podstatnému. Pozri na to, ak sa ti bude chcieť.

[imploder]

Dík. Je to sice Lisp (teda vlastně Scheme), ale vypadá to zajímavě.