Rychlost CogVM

29.3.2012 09:24 | Přečteno: 1790× |

Před léty se říkalo, že VisualWorks Smalltalk je přibližně 10x pomalejší než C a Squeak je 10x pomalejší než VisualWorks. To dnes již zdaleka neplatí. Od příchodu CogVM se na těchto poměrech hodně změnilo.

CogVM je nový virtuální stroj pro otevřené implementace Smalltalku Squeak, Pharo a odvozené, který implementuje JIT, mapování kontextů na zásobník a podobné optimalizační funkce. Navíc přinesl například plnohodnotné uzávěry. Chtěl jsem si ověřit, jak si tedy dnes vlastně stojí v porovnání s ostatními virtuálními stroji pro Smalltalk i dalšími programovacími jazyky. Proto jsem provedl pár testů vycházejících z klasické Computer Language Benchmarks Game.

Do žádného velkého propracovaného testování jsem se ale nepouštěl, takže jen shrnu výsledky, které, prosím, berte s jistou rezervou. Pharo na CogVM v testech vycházelo cca 1,4 - 2 krát pomalejší než VisualWorks 7.8, přičemž horších výsledků dosahovalo v testech zaměřených na aritmetiku.

Provedl jsem i krátké srovnání se Smalltalk/X, z něhož plyne, že dnes jsou Squeak/Pharo a Smalltalk/X rychlostně srovnatelné. Přesněji řečeno, v aritmetických testech CogVM cca o 15% zaostává, v jiných je zase o 30% rychlejší. Je to zajímavý výsledek, když uvážíme, že díky optimalizacím Smalltalk/X například nepodporuje kontinuace. Když jsem se Smalltalkem/X porovnával před drahně měsíci první verze CogVM, vycházel Cog ještě asi 3x pomalejší.

Jak si současné implementace Smalltalku vedou v porovnání s ostatními programovacími jazyky? Že Smalltalk není žádný kvapník, je obecně známo. Na druhou stranu jeho výsledky tragické určitě také nejsou. Ve zmiňované Computer Language Benchmarks Game vychází VisualWorks přibližně 15x pomalejší než C. Squeak v testech nefiguruje, přestože tam kdysi byl, ale autor této "hry" se snaží omezovat množství porovnávaných jazyků a implementací, takže případná měření je nutné provést na vlastní pěst. Z výše zmíněného vyplývá, že by CogVM měl být přibližně 20x-30x pomalejší než C, čemuž odpovídají i experimentální výsledky. V pro Smalltalk nejpřívětivějším testu binary-trees byl Cog 13x pomalejší než céčkovská verze kompilovaná na O3. Testoval jsem na 64 bitech.

Samozřejmě porovnávané programy v C/C++ a Smalltalku nejsou zcela ekvivalentní. Aby byly, musel by program v Céčku hlídat přerušení programu uživatelským vstupem z klávesnice, shromažďovat ladící informace, aby byl schopen zobrazit v debuggeru aktuální stav výpočtu v kontextu zdrojových kódů, umožnit ladícímu programu upravovat hodnoty proměnných, vyjmenovávat všechny instance libovolné třídy, serializovat aktuální stav výpočtu a být schopen v něm pokračovat i na jiné platformě atd. To vše něco stojí. V tomto světle nevypadají výsledky Smalltalku vůbec špatně. Ale ve Smalltalku je to pevná složka ceny.

       

Komentáře

[Bystroushaak]

Hm. Smalltalk se mi docela líbí jako jazyk, projížděl jsem si i nějaké ty tutoriály. Čeho jsem se však nemohl zbavit je dojem totální nepraktičnosti/nepoužitelnosti. Prostě si neumím představit, že bych v něm něco napsal a pak to distribuoval, nebo to nějak prakticky používal. Ten koncept image paměti je divný až moc a přijde mi, že zabíjí využitelnost.

[kralyk z abclinuxu]

No, kvůli tomu vzniklo Objective-C, ne?

[Bystroushaak]

Vzniklo? :) Přiznám se že netuším, znám trochu historii smalltalku, ale o objC vím tak leda to, že ho používá apple.

[Miloslav Ponkrác]

Když vznikl programovací jazyk C, několik týmů ho chtělo doplnit o objekty.

Vznikly v zásadě dvě větve. Jedna doplnila C o něco jako smalltalkovské pojetí objektů a nazvalo se to Objective C. Druhá doplnila o simulovské pojetí objektů a nazvalo se to C++.

U Objective C se toho asi o 8 let později chytil Jobs a od té doby je to plné proprietárního vývoje, různých proprietárních licencí, atd. Dodnes ten jazyk nemá normu, některé jeho knihovny mají copyright, atd.

U C++ se naopak vše dalo volně k dispozici, vznikla postupně ISO norma, a nikdo nebyl omezován v tom udělat vlastní kompilátor.

Objective C je zabitý jazyk a Apple only. Sice existuje jeho implementace v gcc kompilátoru. Některé další kompilátory Objective C se dokonce přiblížily Smalltalku víc, než Applovské Objective C. Z důvodů licence a toho, že je závislý na Applovských manýrech není Objective C nic, do čeho bych investoval čas, pokud nechci vyvíjet pouze pro Apple.

Přijde mi jako lepší varianta Ruby, ve které je Smalltalk taky dost cítit. I když to není kompilátor.

[Vskutečnosti Saýc]

To je smutne, hlavne proto, ze mi (pri zbeznem proletnuti) prislo ObjC mnohem pratelstejsi nez C++.

[Miloslav Ponkrác]

Smalltalk je jazyk, který většina lidí co v něm dělala miluje. Ovšem neujal se v první řadě proto, že licence byla drahá. Druhak proto, že Smalltalk je opravdu pomalý a na starším hw to hrálo velkou roli. A třeťjak proto, že Smalltalk nikdy neměl být programovací jazyk, ale operační systém. A když jako operační systém nedosáhl úspěchu (na rozdíl třeba od LISP mašin), tak se z něj narychlo udělal programovací jazyk.

Proto také Smalltalk funguje tak jak funguje, na svém image a dělá si vše sám. To je dědictví toho být operačním systémem.

Ale mimochodem, před 20 lety jsem měl takovou disketu 1,44 MB, která obsahovala Smalltalk i s bootem – a skutečně to jako operančí systém fungovalo. Všechno se tam vešlo včetně GUI a bylo to velmi luxusní. Požadovalo to 286.

Ale zpět – cílem Objective C bylo NĚJAK do C doplnit objekty a pokud možno ho co nejmíň zasáhnout do C. Cílem C++ bylo doplnit do C objekty a udělat z něj rychlostního marathona pro rychlý vývoj a maximálně rychlé binárky.

Smalltalk zasáhl do mnoha jazyků a pokud se Vám koncept Smalltalku líbí, nebude pro Vás velký rozdíl, zda děláte v Ruby, Pythonu apod. I když pravda, Smalltalk byl jednoduchý a čistý koncept, asi nejčistější OOP a přitom jednoduché a lidské.

Škoda, že ty licence na začátku.

[luky]

Smalltalk je jazyk, který většina lidí co v něm dělala miluje.

Ja bych to videl tak, ze vetsinu lidi to zprudi a pouze par lidi si to zamiluje. Jako jazyk tak spatny neni, ale vsechno ostatni je hruza - nastroje pro kolaborativni vyvoj jsou naprosto tragicke, vyvojova prostredi jsou zaostala a mizerne se to ovlada klavesnici (alespon squeek a to prostredi pro stx).

[Miloslav Ponkrác]

Smalltalk frčel v době, kdy dnešní kolaborativní vývoj neexistoval ani ve sci-fi.

Tehdy prostě dva lidi si sedli a za chvíli napsali unix. Nebo si jeden na pár měsíců sedl a napsal kompilátor Céčka.

Smalltalk na splupráci moc není. Je to jazyk, který dovoluje klidně i přehodit význam false a true, když mu budete chtít škodit. Nemá absolutně žádnou ochranu před programátorem.

Dnešní kolaborativní spolupráce je o tom, že co dřív udělal jeden člověk za měsíc, dnes udělá tým lidí za dva roky. To jen jako poznámka. Jednak proto, že tehdy každý programátor byl teoreticky nabušený způsobem, že to prudce urychlovalo vývoj. A druhak proto, že jednoduše tvořil a taky proto, že neexistovalo OOP – zejména ne impotentní OOP v Java stylu a návrhové vzory šité na Javu.

Squeak jsem moc v ruce neměl, takže nevím.

Nicméně vývoj v týmu a Smalltalk to nejde moc dohromady. Ten jazyk je napsán sám v sobě. Kromě velmi jednoduchého engine je i základ Smalltalku psát sám ve Smalltalku a je tedy libovolně přístupný i programátorovi.

Smalltalk nemůžete chápat jako programovací jazyk, Smalltalk je v podstatě permanentní objektová databáze, nad kterou máte jazyk zvaný Smalltalk pro operaci s databází. To je ve skutečnosti Smalltalk. Když si řeknete, že Smalltalk je nejlepší objektová databáze, která existuje (pokud nechcete rychlost) nad kterou můžete psát aplikace – je to přesnější definice toho co je Smalltalk.

Ohledně nástrojů – podívejte se jaké nástroje dostanete s PHP. Kulové, nedostanete ani ten debugger – a to ani řádkový. Nulové IDE, nic. A přesto to nikomu v masovém užívání nevadí.

Smalltalk je především do důsledku dotažené OOP. Nejjednodušší a nejčistější, které existuje. Doporučuji minimálně jako zkušenost.

Jinak Squeak bohužel dojíždí na svou nenávist k C. Nejsou schopní napsat ani slušný engine, protože nenávidí C, a tak to píšou v nějaké Smalltalkové podobě a podle toho to vypadá.

[kralyk z abclinuxu]

Jednak proto, že tehdy každý programátor byl teoreticky nabušený způsobem, že to prudce urychlovalo vývoj. A druhak proto, že jednoduše tvořil a taky proto, že neexistovalo OOP – zejména ne impotentní OOP v Java stylu a návrhové vzory šité na Javu.

Imho to je hlavně proto, že dneska jsou ty systémy řádově složitější... Způsob, jakým se interaguje s OS, s uživatelem, se sítí, se vším možným, multithreading, přenositelnost,... Je toho opravdu hodně... Jinak nabušení programátoři určitě existují i dnes a Javovské OOP se taky necpe všude, naštěstí.

[Miloslav Ponkrác]

„Imho to je hlavně proto, že dneska jsou ty systémy řádově složitější...“

To jsou.

---

„Způsob, jakým se interaguje s OS, s uživatelem, se sítí, se vším možným, multithreading, přenositelnost,... Je toho opravdu hodně...“

Možná Vás to překvapí, ale už jsem tu na abclinuxu několikrát psal, že před 20 lety byly programovací jazyky složitější. Oproti dnešním vykuchancům, které pokud možno neumí nic a vše dohánějí knihovnami – bylo poměrně standardem, že jazyk hodně věcí uměl sám o sobě. Často to byl multithreading, daleko vymakanější, než dnes, který byl součástí řady jazyků. Přenositelnost byla obecně větší rovněž – tak heterogenní operační systémy i různé počítačové sítě, jako byly tehdy už dnes nejsou.

Já programuji cca 25 let. Moc si dnešní dobu idealizujete. Dříve se dělaly praktické věci, dnes se dělají ideologicky přípustné věci – v mnoha programovacích jazycích, či způsobech práce systémového inženýrství se dnes spíše hodnotí, zda je to politicky a ideologicky vhodné, než praktické.

Ono je to spíše tak, že se svět vrací k tomu, co bylo před 20 lety – a já jsem od té doby nepoznal moc nového v sw světě. V pohodě si vystačím jen s tím, že „aha to už jsem zažil před 15-20 lety, teď to jenom někdo znovu objevil“.

I proto dělám astrologii, i proto studuji psychologii – protože to jsou na rozdíl od IT progresívní obory, kde se aspoň objevuje něco nového a nějaká progrese. A můžete si o mě myslet co chcete, třeba že jsem blbec.

---

„Jinak nabušení programátoři určitě existují i dnes a Javovské OOP se taky necpe všude, naštěstí.“

Ale pořád si všimněte, že komunitně dělaný Linux dlouhou dobu dohání v zásadě více individuálněji dělané BSD. Ještě zajímavější by bylo důsledně porovnat počet člověkoroků vražených do vývoje BSD a do vývoje Linuxu – zde se ukáže daleko jasněji, jak to s efektivitou jedinec versus tým je.

Nebo jednoho Knutha, který napsal TeX – a kolik lidí týmově vedle něj napsali podobně kvalitních sázecích systémů a kolik takových systémů bylo?

Javovské OOP se cpe všude, protože Java ovlivnila velmi mnoho moderních dogmat o OOP, která nejsou vždy úplně pravdivá. A tato dogmata se používají i tam, kde Java není a kde jsou možnosti větší. Ale to je jedno. Na tom nesejde.

---

Principem jsem chtěl jenom říct, že Smalltalk je prostě originál, protože to je jiný koncept. Není to C-like (jako C/C++/Java/C#/...). Stejně tak jako je třeba originál LISP, nebo je originál Ada, nebo je originálem leccos dalšího. Zrovna tu Adu doporučuji jako studiem, jak vysoce může být jazyk přenositelný, včetně jeho podpory multithreadingu přímo v jazyce (a dost netradičně pojatého, ale účinného). Mimochodem, třeba LISP svého času byl koncept pro paralení mašiny, protože byl na to fakt dobrej a je dobrej. Atd.

Dnes se všude prosadil tandem C-like jazyky + unix-like operační systémy. A je to leckde i na škodu, protože je mnoho velmi dobrých konceptů. A je inspiratvní si je zkusit.

[Pavel Křivánek]

nastroje pro kolaborativni vyvoj jsou naprosto tragicke, vyvojova prostredi jsou zaostala a mizerne se to ovlada klavesnici (alespon squeek a to prostredi pro stx).

Ovládat to bez myši skutečně bohužel prakticky nejde. Kreslítek UI a všemožných wizzardů si také člověk mnoho neužije, ale jinak bych si dovolil nesouhlasit. Monticello je jako verzovací systém solidně použitelné a nic nikomu nebrání použít třeba Git, chce-li. Unit testing, refaktorovací nástroje, kontrola kvality kódů... to vše je vysoké úrovni. Jako build server se používá klasika - Jenkins (viz https://ci.lille.inria.fr/pharo/). Osobně si často říkám, že bych dal za vděk spíše stařičkému původnímu xeroxáckému Smalltalku-80 než mnohým dneším IDE.

A pokud člověku něco přece jen chybí, je většinou velice snadné si to dopsat. Tuhle jsem například chtěl zjistit pokrytí určité třídy unit testem. To se ve Smalltalku napíše třeba takto:

| class test trace classTrace result  |

class := Time.
test := TimeTest.

trace := Dictionary new.

thisContext runSimulated: [test suite run]  contextAtEachStep: [ :current |
       | cls sel methods bytecodes |
       cls := current method methodClass.
       sel := current method selector.
       methods := trace at: cls ifAbsentPut: Dictionary new.
       bytecodes := methods at: sel ifAbsentPut: Set new.
       bytecodes add: current pc.].

result := String streamContents: [:s |

classTrace := trace at: class ifAbsent: nil.
classTrace
       ifNil: [
               s nextPutAll: 'Class ', class name, ' not called'; cr. ]
       ifNotNil: [
               s nextPutAll: class name; cr.
               class selectorsDo: [:sel |
                       | m usedBytecodes allBytecodes |
                       m := class >> sel.
                       usedBytecodes := (classTrace at: sel ifAbsent: Set new) size.
                       allBytecodes := 0.
                       m symbolicLinesDo: [:pc :lineForPC | allBytecodes := allBytecodes + 1 ]..
                       s tab; nextPutAll: sel; nextPutAll: ' - '; nextPutAll:
(usedBytecodes  /  allBytecodes * 100) asFloat asString; nextPutAll:
'%'; cr. ]].
].
result.

Zobrazit zdrojový kód metody se zvýrazněním nepokrytých částí také není nic složitého

class := Time.
selector := #print24:showSeconds:on:.
m := class >> selector.
usedBytecodes := ((trace at: class) at: selector ifAbsent: Set new).
allBytecodes := Set new.
m symbolicLinesDo: [:pc :lineForPC | allBytecodes add: pc ].
unusedBytecodes := allBytecodes copyWithoutAll: usedBytecodes.

dm := m debuggerMap.
source := (class sourceCodeAt: selector) asText.
unusedBytecodes do: [:pc |
       range := dm rangeForPC: pc contextIsActiveContext: false.
       source makeBoldFrom: range first to: range last.].
source asMorph openInWindow.

[Pavel Křivánek]

Můžete brát image jen jako bonus. Pokud použijete malou image bez GUI a nástrojů, jen s překladačem a základními knihovnami, pak se Smalltalk v používání nijak neliší od Ruby nebo Pythonu.

Smalltalk nechápe program jako soubor zdrojových kódů, ale jako systém vzájemně komunikujích objektů.

[Bystroushaak]

Smalltalk nechápe program jako soubor zdrojových kódů, ale jako systém vzájemně komunikujích objektů.

To je to co se mi na něm právě líbí a proč mi přijde, že má budoucnost.

[Miloslav Ponkrác]

Pokud chápete objektové paradigma jako jedině správné a jediné, které by mělo existovat, pak ano.

Ale myslím si, že je to jinak.

[Bystroushaak]

:). To jsem přeci nepsal. Osobně vnímám objektové paradigma jako dost životaschopné, ale není to žádné náboženství a nedělá mi problémy zabřednout do jiných konceptů, jako je třeba rebol, jenž studuji poslední dobou..

Jde o to, že jednoho dne budou počítače s lidmi provázané o hodně více, než jak je to dneska. Stále ještě interagujem s HW, což jednou zmizí a bude probíhat interakce prakticky jen se SW. Jsem zvědavý, co budeme používat za jazyky v době, kdy padne 2D omezení monitoru, nebude rozdíl mezi pevným diskem a RAM pamětí, internetové připojení bude všudypřítomné a programovací jazyky budou od HW vzdáleny jak čistá matematika. V té době imho bude smalltalk stále užitečný.

[kralyk z abclinuxu]

To je to co se mi na něm právě líbí a proč mi přijde, že má budoucnost.

Je to hezké, ale pro budoucnost jazyka to určitě není podmínka postačující...

[Miloslav Ponkrác]

Děkuji za článek. Také je vidět vzácná snaha o serióznost a je v něm plno užitečných informací.

Smalltalk mám jako jazyk rád.

Jediné co je slabší je poslední odstavec.

[blizzz]

chcel by som si skusit nejaky pure objektovy jazyk message passingom najlepsie na vyvoj web apps. tak som si stiahol Seaside, to IDE alebo co to je vyzera, uplne inak ako bezne vyvojove nastroje na ktore som zvyknuty, absolutne som v tom strateny neviete niekto poradit nejake screencasty / tutorialy?

[Pavel Křivánek]

Kniha Pharo by Example.

Kniha Development with Seaside

Pharocast

atd...

[Ales Hakl]

Ze ST/X neumi kontinuace neni ani tak o optimalizacich, ktere provadi JIT, ale o celkove implementacni strategii toho VM. Velka cast toho systemu je kompilovana pomoci stc, coz je ahead of time kompilator z ST do C, ktery produkuje temer normalni (a prekvapive vcelku citelny) C kod a tak je potreba, aby volaci konvence pouzivana uvnitr VM byla alespon trochu obdobna C, coz vede na pouzivani Cckoveho stacku primo, coz by v pripade implementace kontinuaci vedlo na kopirovani obrovskych bloku pameti sem a tam (coz je mimochodem zpusob, jak kontinuace implementuje MRI, takze to neni uplne mimo misu, ale stejne me to prijde jako vcelku spatny napad).