Unix v Pascalu (diskuse)

[#Tom]

Pokud se nepletu, céčko vzniklo proto, aby do něj mohl být přepsán unix, takže ten byl původně napsán v něčem jiném, možná že v pascalu (ale netuším, jaká je skutečnost). Ten je sice dobrej a pěkně se v něm píše, jenže na něj jaksi není norma a staré dosové borlandské překladače jsou dnes už mimo mísu (slušně řečeno). Delphi je asi lepší, jenže se tam hodně věcí (hlavně objektových) dělá jinak, takže mě nezaujalo. Navíc je jen pro wokna, kylix se moc neujal.

Programy přeložené v BP jsou opravdu hříšně pomalé, třeba ukazatelová aritmetika, kterou jazyk moc nepodporuje, protože ji schovává za hrůzostrašné přetypování, zbrzdí program skoro o celý řád. Asemblerem se dá leccos zrychlit (ale taky podělat, když jsme u toho).

Fortran je prý rychlý při matematických výpočtech, v asembleru by to dalo asi hodně práce. Nicméně u některých nových šablonových knihoven se píše, že s ním mají srovnatelný výkon, takže programovací jazyk na vyšší úrovni umožňuje tvořit rychlý kód. Nicméně u překladu C++ na starším stroji se dá i usnout.

[Heron]

Nemýlím-li se, tak původní UNIX byl psán v assembleru a byl to vůbec první OS, který byl přepsán do vyššího jazyka (a to z důvodu snadné přenositelnosti na další stroje).

[Ladislav Thon]

Není pravda, že na Pascal není norma. Vizte ISO 7185:1990 (Pascal) a ISO/IEC 10206:1991 (Extended Pascal). Jak je to s dostupností překladačů netuším :) IMHO Object Pascal (z Delphi 6, poslední použitelná verze) je výborný jazyk (byť se spoustou ošklivých míst, kam naštěstí není nutno chodit), čert vem standardizaci.

[valeon]

K tomu přetypování - je to sice odporné, ale rozhodně ne pomalé. viz kód z delphi:

var Y: Integer; X: Pointer; begin Y:=5; // mov eax,$00000005 X:=Pointer(4); // mov ebx,$00000004 X:=Pointer(Integer(X)+Y); // add eax,ebx // mov ebx,eax

Ten konec mohl být lepší, ale v principu tam žádný problém nevidím. U BP je to trošku něco jiného, protože používal ukazatele typu Segment:Offset, ale ty musí v reálném režimu používat každý (i céčko). Celkem by mě zajímalo, jak se tohle řešilo právě v céčku. Nechtěl by mě někdo poučit? ;)

[unchallenger]

Takže

1. Toto je podle mne konverze, ne reinterpretace. Ale není to z toho vidět, vybral sis triviální příklad, kde se obě redukují na identitu.

2. Co to udělá na mašině s 32bitovými integery a 64bitovými pointery (to už je dnes skoro všechno)? Máš to pod kontrolou?

3. Pointery a integery jsou trivialita. Chci přetypování jedné struktury na jinou.

[Michal Kubeček]

Stará programátorská moudrost praví, že program se jednou překládá a mnohokrát spouští. Proto je rychlost překladače mnohem méně zajímavá než rychlost výsledného kódu.

[Michal Kubeček]

Navíc je na Pascalu hodně vidět, že jazyk byl navržen pro výuku a ne pro praxi. Když jsem po dlouhé době musel něco napsat v Pascalu, myslel jsem, že z toho vyrostu. Takže ta rychlejší kompilace by byla vyvážena podstatně pomalejším programováním.

[paskma]

A kdybys něco psal v Adě, taky bys z toho vyrostl? Já myslím, že jo, typová kontrola je tam ostrá jako břitva, kontroluje se tam kde co. Každého začátečníka překladač dokonale znechutí, furt nějaké erory.

Je to jazyk navržený pro profíky (DoD). Dělají se v tom kritické rozsáhlé aplikace (řízení raketoplánu, Westinghouse v tom dělá atomky). Přesto má pascalskou syntaxi.

Takže není Pascal jako Pascal.

[unchallenger]

Silná typová kontrola psaní věcí jako jádra OS dost kompilkuje. Jazyk jako C je ideální, protože když typovou kontrolu chceš, kompilátor tě umí varovat, ale když ji nechceš, předáváš klidně netypované kusy paměti a přetypuješ cokoli na cokoli.

[Ladislav Thon]

Silná typová kontrola psaní věcí jako jádra OS dost kompilkuje.

A věcí jako GNOME taky? :)

[unchallenger]

Gnome používá (v C) compile-time typovou kontrolu u primitivních typů, ale pokud jde o objekty, tak je plně dynamické a typová kontrola probíhá až run-time. Takže kterou máš přesně na mysli?

[Ladislav Thon]

Já bych statickou a dynamickou typovou kontrolu moc neodděloval, jedno bez druhého je jako pivo bez půllitru (i když se obvykle nadává spíš na tu statickou). Raději se nesnažím si představit, co museli GTK/GNOME hackeři provádět, aby v plain C implementovali plně dynamický objektový systém s typovou kontrolou, takže trochu jinak... myslíš, že by vývoj vysokoúrovňové aplikace typu GNOME byl při použití "nativně" silně typovaného jazyka komplikovanější, než při použití Céčka, kde si v případě potřeby (obvykle spíš ne/chuti) můžeš by definition zaprasit dle libosti?

[unchallenger]

Můžeš jmenovat nějaký běžně používaný silně a zároveň dynamicky typovaný jazyk?

Jinak ani C++ není dynamicky typované (např. nelze run-time vytvářet nativní nové třídy z ničeho), takže bys v něm stejně musel objektový systém částečně nebo úplně reimplementovat, a výsledkem by možná byl větší bordel než v jazyce, který nativní objekty nemá.

V čem to měli napsat, aby dosáhli:

1. stejné přenositelnosti,

2. stejné snadnosti psát bindingy pro všechny možné jazyky.

Ten druhý bod je velmi důležitý. Jelikož je Gtk+ v C, můžeš pohodlně objektově programovat v Gtk+ v Pythonu a o to, že je modul realizován backendem v C (jako řada dalších), se příliš nestarat. Naopak je to větší problém.

[Ladislav Thon]

Můžeš jmenovat nějaký běžně používaný silně a zároveň dynamicky typovaný jazyk?

Lisp.

V čem to měli napsat, aby dosáhli:

1. stejné přenositelnosti,

2. stejné snadnosti psát bindingy pro všechny možné jazyky.

V čemkoli, k čemu je k disposici překladač, který dovolí splnit obě zmíněné podmínky. To by, troufám si tvrdit, mohly být (skoro) všechny jazyky, k nimž existuje překladač v rámci projektu GCC -- generátor cílového kódu je totiž jeden a týž.

Ale to je jenom bohapustá teorie, klidně si ji nechám vyvrátit někým, kdo už něco takového vyzkoušel a nepochodil. Holt věčně zelený strom života... nejhorší na Céčku není to, že je tak strašné, ale že je tak rozšířené :)

[unchallenger]

Lisp.

A dokonce je to vhodný jazyk pro psaní grafických tookitů...

V čemkoli, k čemu je k disposici překladač, který dovolí splnit obě zmíněné podmínky. To by, troufám si tvrdit, mohly být (skoro) všechny jazyky, k nimž existuje překladač v rámci projektu GCC -- generátor cílového kódu je totiž jeden a týž.

Tak to si docela dost nerozumíme. C je ,lowest common denominator`, takže co napíšeš v C, lze použít ve většině jazyků -- v nejhorším případě s procedurálnějším API, než bys rád. Ale u ,lepších` jazyků je problém s převodem konceptů, takže buď jejich vlastnosti nevyužiješ, ale pak můžeš psát klidně v C, nebo je využiješ, a pak bych chtěl vidět, jak vypadá glue code umožňující používat LISPí knihovnu v C (samozřejmě tak, že to pak v C vypadá nativně, ne že se volá interpret LISPu).

[VícNežNic]

Můj počítač není tank a s DoD nemá nic společného

[Michal Kubeček]

Přísná typová kontrola mi nevadí, naopak třeba na PHP mi máloco vadí tolik jako (téměř) absence typové kontroly. Ale Pascal je příšerně "ukecaný" jazyk. Typické frameworky a knihovny v C++ třeba taky, ale existují tam aspoň prostředky, kterými to lze trochu zredukovat. V Pascalu ne. Ona absence preprocesoru nebo templates je problémem sama o sobě, když se ty hračky naučíte efektivně využívat, jsou k nezaplacení.

[unchallenger]

Parsování zabírá malou část času kompilace, zejména když optimalizuješ. Kromě toho bývají LR parsery efektivnější než LL -- ovšem téhož jazyka, když pro něj existuje LR i LL gramatika, při srovnání různých jazyků to není argument.

[paskma]

Nevidím na dno, ale něco mi říká, že když napíšu LR překladač něčeho, co je ve skutečnosti LL(1), tak to rychlé být může.

Tak proč je potom C tak pomalé, když je parsování jen malá část?

[unchallenger]

Který kompilátor C srovnáváš s kterým kompilátorem Pascalu, a proč si myslíš, že se z jejich srovnání něco dozvídáš o jazyku samém?

[paskma]

Všechny překladače C/++, které jsem potkal (Borland, MS, Gnu), zplácaly binárku _podstatně_ pomaleji než potkané překladače Pascalu (Borland, Freepascal, (Alsofťácký Flex).

A má teorie, že překladač jazyka s "náročnější" gramatikou je pomalejší, snad není až tak naivní.

Kdysi jsme o tom mocně diskutovali na konferencích cecko@pandora.cz a os@pandora.cz. Ty rozdíly jsou natolik obludné, že jediné pro mne přijatelné vysvětlení je dáno matematickou podstatou (složitostí).

[unchallenger]

Rozdíly mohou být čistě implmentační. Kupříkladu překladače Pascalu jsou obvykle monolity, kdežto překlad C má tradičně několik fází.

$ strace -ff fpc z.pas 2>&1 | grep -c execve
3
$ strace -ff gcc -o z z.c 2>&1 | grep -c execve
13

[paskma]

Tak to bych napsal monolitické céčko a vydělal miliardy dolarů

[David Jaša]

A co tcc? Někdo s ním dokonce překládal jádro v rámci Lila a viděl jsem v tom dokonce nějaký skript, takže to musí překládat opravdu rychle.

[Ladislav Thon]

Tak proč je potom C tak pomalé, když je parsování jen malá část?

Optimalizátory. Někdo vymyslel, že Céčko bude nejrychlejší jazyk a hordy matematiků a programátorů se předhánějí v počtu optimalizačních průchodů Céčkových překladačů :) A pak pochopitelně #include :)

[Bubak]

A ja myslel, ze jsem jen ja starej nespokojenec, kdyz jsem pomahal segre loni psat praci na konec skolniho roku.

[lukas.ramlich]

Proč je pascal LL a céčko LR? Proč je v céčku include. Proč vůbec vznikly další vyšší jazyky, když napsat překladač pro ně je naprosté utrpení?

Protože je práce programátora násobně dražší než strojový čas. Takže čím efektivněji a rychleji dokáže napsat "bezchybnou" aplikaci, tím lépe. Doby rychlosti kompilace, a dokonce rychlost běhu programu jsou už druhotné záležitosti. Kdyby kriticky záleželo na výkonu, nikdy nevznikly jazyky s GC kde není třeba paměť ručně alokovat (velký zdroj chyb), ale má to hrozné výkonové důsledky.

U gentoo vzniká ale zajímavý paradox. Práce programátorů je vlastně zadarmo, zatímco strojový čas desetitisíců "kompilovačů" je opravdu hodně drahý.

Navrhuji přepsat gentoo do assembleru. Programátoři to nějak zvládnou a kompilace, ta bude rychlá jako blesk.

[Michal Kubeček]

Netroufám si odhadnout, co by to udělalo s rychlostí stahování těch zdrojáků… :-)

[unchallenger]

To je otázka komprese. Přepsáním do assembleru se množství informace nezvětší.

[Michal]

To je ponekud odvazne tvrzeni. Kus kodu v C muzu prepsat do assembleru mnoha zpusoby s ekvivalentni funkcnosti. Pokud mezi temito zpusoby nevolim nahodne nybrz nejak cilene tak zcela evidentne snizuju entropii a tedy zvysuju mnozstvi informace.

[unchallenger]

Přepsat do assembleru je u mě přepsat do assembleru, nikoli reimplementovat v assembleru jinak[*]. Tj. víceméně výstup gcc -S. Bez optimalizací obsahuje oproti C dost málo (je nejspíš algoritimicky převeditelný zpět na preprocesovaný zdroják v C), s optimalizacemi obsahuje informaci z kompilátoru, což je aditivní konstanta.

[*] I tak platí, že délka minimálních implementací algoritmů v různých (stejně sliných) jazycích se liší jen multiplikativní konstantou. A u reálných jazyků jsou ty ukecanější kompresibilnější.

[paskma]

Práce programátora je drahá a proto na rychlosti překladu záleží. Kdo dělal na netriviálním projektu v C/++, tak ví. To je taky jeden důvod, proč se rozmáhají věci jako Python.

[unchallenger]

Za překlad platíš při spuštění. Netriviální projekty v Pythonu (Perlu...) se spouštějí pěkně pomalu. Sice je to rychlejší než klasická kompilace, ale ty časy rozhodně nejsou zanedbatelné.

[Luboš Doležel (Doli)]

Už ses někdy zkusil podívat na EXE stvořené Delphi v nějakém disassembleru? To bys koukal, kolik šíleného humusu a balastu to s sebou nosí. Mohli by vytvořit i "Delphi Super", kde by program nesl s sebou celý reimplementovaný operační systém (kromě kernel space).

[valeon]

Já jsem se díval a nic tak hrozného jsem neviděl, ale asi jsem se jakožto zaujatý prodelphista díval na běžný program :)

[---]

Uvede nekdo priklad jak by vypadal zdrojak ?
Jsem dosti zvedavy.