XCHAOS: To nema zadna z beznejch Cckovejch knihoven hashmap?

JANFROG: počkej... " vyssi programovaci jazyk preklada do C," ... tomu já říkám prekompilace :-)

každopádně já Javu prostě nerad - co k tomu mám dodat? V tomto klubu to snad není offtopic říct :-)

XCHAOS: Prekompilace...slepa vetev. Nas system se bootstrapuje tim ze vyssi programovaci jazyk preklada do C, ktere se pozdeji prelozi pomoci GCC/BCC/MSVC. Super technologie pred 25 lety. Dnes uz bych do toho nesel a to i za cenu toho, ze jinak bych musel opustit jednu z mych oblibenych featur soucasneho systemu (inline-C). Dnes bych vse nechal na JITu a pro bootstrap minimalniho systemu bych pouzil interpret AST, jedno jak pomalej.

Duvody jsou dva:
(i) stejne musis mit JIT pro rozumny vykon a inkrementalni vyvoj (pro me co nedovoluje vyvijet inkrementalne je nepouzitelne, jsem narocny :-)
(ii) pokud chces rychlost + GC + nejake pokrocile featurky jako reifikovatelny stack, kontinuace apod, tvrde narazis na to, ze kazdy C prekladac s kazdou verzi s kazdym jednotlivym prepinacem generuje jiny kod, nekdy invalidni, nekdy proste jen ignoruje/ruzne si vyklada volatile, inline apod. Nikdy nemas kontrolu nad tim, jak presne vypada frame na stacku, co v nem presne je, nikdy nevis co presne je v registrech a co v pameti. Tahle nejistota je zabijak...

Takze pokud prekompilovat, tak jedine do ASM a vypnout vsechny jeho "optimalizace" jako automaticke plneni delayslotu podobne legracky. Kompilovat do C je o neco snadnejsi na zacatku a obrovsky problem na konci. Takze tudy ne, alespon ne pro HLL.


DAVIDOWITCH: Tak u vsech modernich VM je se zasobnikovy bytekod pouziva spis proto, ze do nej pohodlne preklada a ze to je tradice. Stejne prvni co udelas je ze to dekompilujes zpet do AST a prelozis do strojaku...


PIGSTER: My jsme tam doiterovali a delame si vsechno sami (VM, knihovny, GUI, IDE, krom operacniho systemu :-) a ma to sve vyhody...

PIGSTER: asi preklad, "to delaji proto, ze neumeji"?

XCHAOS: hmm, rekl bych, ze lidi, co pouzivaji nejaky interpretovany jazyk (ruby treba) nebo nejaky GC VM jazyk (c# nebo java treba) to delaji pro to, ze neumeji programovat v C - dokonce bych si dovolil tvrdit, ze nekteri z nich jsou velmi dobre schopni vytvorit infrastrukturu, kterou pouzivaji, kdyby to bylo nutne - ale proc by to nekdo delal? Proc psat framework kdyz uz jich tu je cela rada velmi dobrych (zamerna paralela se soucasnou ceskou PHP komunitou)? Proc ztracet cas vymyslenim hranateho kola, kdyz ho je mozne vyuzit vyvojem automobilu (ktery pouziva jiz existujici kulata kola a evidentne je to plne vyhovujici reseni)?
Mimochodem, kdyby se to iterovalo o kousek dal, skoncis u psani nastroju, ktere vyviji firmy jako Cadence nebo Synopsys - abys to mel echt sobestacne :)

JANFROG: Mne se na cely tyhle veci stejne nejvic libi, ze VM jsou misto kde se fakt realne stale porad pouziva zasobnikovej (stack based) ASM. Protoze se to dekoduje rychlejc. (I kdyz, predpokladam ze v momente kdy nejak dopredu JITujes, tak to neni az tak podstatny jako kdyz se chroupaj instrukce po instrukci).

JANFROG: no, podle mě má smysl to, co člověk vymyslí, prohnat různými benchmarky. s tím, že já si rád nechám poradit, jaké benchmarky smysl mají a jaké ne.

...ale třeba jen benchamrky na měření zdánlivých banalit jako rychlost řetězení stringů nebo výkon asociativních polí si lze vycucat z prstu snadno... a lze srovnat něco s něčím (tedy stejný kód v různých jazycích, navíc běžících pod různými interpretery...)

Ruby je pěkná hračka :-) ale prakticky používat bych to nechtěl. Ale jeden z vedlejších myšlenkových proudů se u mě týká pre-compileru nějakého vyššího objektového jazyka do C (skrze polymorfní ANSI-C objekty). Kdybych do toho šel, tak se asi volně inspiruji u Pythonu i Ruby - hlavně se mi líbí myšlenka, že IF i OR jsou jen operátory, jejichž parametry z jedné i druhé strany jsou volitelné, a liší se jen směrem vyhodnocování svých argumentů :-)

Interpretace mě tolik nebere - možná je to ambiciózní intelektuální výzva... zvlášť existující interpretery Ruby neoplývají rychlostí... ale prostě já osobně sázím na pre-kompilaci (nevím proč, prostě mi to nějak sedne). Spousta toho, co jsem v posledních letech napsal, jsou tak jako tak různé parsery a pre-compilery různých jiných formátů - ať už HTML nebo iptables nebo čehokoliv. V programu, který sám píše jiný program, je cosi kosmologicky mystického :-)

XCHAOS: No shodou okolnosti se vyvojem virtualnich stroju pro vyssi programovaci jazyky jiz nejakou dobu zabyvam (v zasade je to zdroj me obzivy)
a muzu Ti rici, ze bez zakladnich znalosti procesoru a ASM to nejde. A to C ktere se pouziva je take o dost jine nez kdyz pises "normalni" programy (napriklad if je zabijak vykonu, pouzivat goto a podobne perly).

Premyslet jak jsou napsane nema smysl, muzes se na to podivat. Pokud chces pochopit, jak to funguje, pak 1) nejakou VM si napis a __pouzivej__ a 2) podivaj se, jak to delaji jini. Pro zacatek doporucuji kurz a knihu "Structure and Interpretation of Computer Programs".
Cokoliv jineho je ztrata casu/mentalni rozcvicka, nic vic. Ver mi, tohle uz mam za sebou :-)

Opet ciste nahodou jsem delal/delam na prekladaci Ruby a ted delam na vlastni implementaci JVM a muzu Ti rici, ze ja osobne to povazuji za velmi, velmi ambiciozni
(i kdyz...mozna si jen fandim, mozna je to trivka kdyz se to dari i diletantum jako jsem ja a mi kolegove :-) Udelat rychlou VM je celkem umeni...

DAVIDOWITCH: To me minulo. Ach jo, tak to pridam na seznam neprectenych veci, poradove cislo 332432 :-(

JANFROG: Tohle uz tu prolitlo, ale kdyby te to nahodou minulo:
www.akkadia.org/drepper/cpumemory.pdf

XCHAOS:

REDGUY: sám si vyjmenoval, že pokud vezmeme v úvahu všechny kombinace, tak šlo o vzorek minimálně osmi ovcí.

XCHAOS: 8)))) No tak jo. V jednom konkretnim programu u ne vice nez dvou ruznych verzi prekladace se branch predictor na 32bitu neprojevil. Tudiz... ach jo. Jako obvykle. (btw, v kontextu tveho rozpraveni o "vzorku o jedne ovci" v jinem foru je tahle tvoje zprava extre legracni).

XCHAOS: To je problem 32b verze prekladace, ne chybejici branch prediction jednotky. Don't jump to conclusions.

A je sikovny vedet co se deje pod a nad tim kde travis vetsinu casu. Treba ze existujou branch predictory, nebo jak cca funguje virtualni pamet. Pak te min prekvapej threading hnusy. (pochopitelne, se svym volnym casem si delej co chces, ja toho vyuzil a rovnou koupil tu Computer Architecture, Fifth Ed., at mam co cist v autobuse)