Nová generace jazyka C++

Jiste :). Derny stitek prezije radiaci a magnetickou bouri po vyubuchu atomove pumy. Feritova pamet je zase nevolatilni - vypnes pocitac, a rano zapnes, a v pameti mas vse, co tam vcera bylo. Neni to krasne? :)

neuveritelny ;-) mmch, ted jsem slysel o takovy horky novince - http://en.wikipedia.org/wiki/Flash_memory, ktera je taky nevolatilni... ale uznavam, je to tu jen par let a nevypada to tak hezky jako kolecka a dratky...

Ta tva horka novinka sice nevolatilni je, ale ma drobny problem. Neda se do ni zapisovat bez predchoziho vymazu stranky. A co kdyz chci zmenit jen jeden byte? Musim si tu stranku nekam celou schovat, tam to zmenit a pak to zas zapsat. Do RAMky to nestaci, co kdyz se odpoji napajeni zrovna kdyz to vymazu?
Tenhle problem u feritove pameti neni.

FLASH i FRAM se delaji nejen s blokovym zapisem, ale i byte po bytu cteni/zapis. Nejsou tolik rozsirene, ale casto se pouzivaji pro BIOS klasickych desek, hlavne teda FLASH.

Doplnte si prosim znalosti, nez zacnete povidat nesmysly. To ze flash disky pouzivani nejaky konkretni typy technologie FLASH jeste neznamena, ze nic jneho uz neexistuje:)...

Derny stitky se porad pouzivaj na katalogizaci mikrofisu, ty chytrej jak radio: http://en.wikipedia.org/wiki/Microfilm

Takze asi tak casto jako assembler ;-)

Assembler se pouziva casto - v podstate kdykoliv nektery z tvych oblibenych vyssich jazyku zacne delat, co nema. A nebo kdykoli je treba napsat neco opravdu systemoveho a low-level, narozdil od klikaciho formulare pro bankovni urednici :P.

Takovym, co si mysli, jak se assembler nepouziva, by nejvice prospelo, kdyby veskere casti assemblerem optimalizovaneho softwaru co pouzivaji byly nahrazeny nejakym produktem kompilatoru. Skoda, ze to nejde udelat.

No, zaplatpambu - vsak take vetsina vazne minenych projektu pouziva z C++ jen urcity velmi uzky subset - v podstate na zapouzdreni imperativnich neobjektovych funkcnich bloku. Tj. je to cecko, s C++ obalem az kdesi vysoko - tak, ak by to melo byt (bohuzel ne vzdy je).

V samotnem jazyce svoboda je (sice svoboda nepouzivat to je divna svoboda, ale budiz) - ale, jak jsem psal vys, ve feature se shledne nejaky manazer, nebo aktivni novacek - a uz se tim zdrojove texty plni, a uz se zabredava do problemu, a aplikace roste a zpomaluje...

Prusvih je, ze nekdo s objekty zacinal, a chybi mu predstava, co z toho asi tak vznikne,a jak se to bude chovat - a takovihle lide, misto aby se starali jak to funguje, naopak ochotne nasavaji a prijimaji kazdou novou feature. V tom je pricina problemu...

Jinak samozrejme, jsou mnohem horsi veci nez C++, indeed :)

Dovolim si odpovedet byt dotaz nebyl urcen me... ale s kolegou se me nazory v podstate stotoznuji.

V C++ sem toho napsal rozhodne vice nez C. Ovsem kdykoli slo o optimalizaci kodu.. protote nejaka operace se proste provadi klidne tisickrat za vterinu.... tak nejaky objekty ze standardni knihovny ala string a podobne proste nemeli sanci. A proc ? Protoze proste lecky je jednodussi a hlavne rychlejsi napast si malinkatou rychlou funkci sam, nez volat objekt ktery zavola hromadu obsluznych method.

OOP je uzasna vec, ale pouze v pripade ze ma smysl. Kdo si toto neuvedomuje, je programator zelenac, protoze evidentne nezazil dostatecny pocet situaci, ve kterych je proste strukurovany program (nebo cast kodu) lepsi.

Zrovna nedavno jsem debugoval prave tenhle skvely objekt, konkretne mi bylo zahadou, proc aplikace pri konci pada - zavolalo se totiz free nad blokem v .data, protoze refeence u empty_rep sklouzla pod nulu, a POD tim uvolnila (nemeli osetreny race pri manipulaci s referenci!)

Jen propracovat se od copy-konstruktoru k tomuto mistu bylo na cca 8 vnoreni... tedy jakou efektivitu mate na mysli? Slo konkretne o statickou libstdc++, tak, jak je soucasti debianu (coz verim, ze je -O2)

Dovolim si nesouhlasit. Nedavno sem psal softik, ktery ve vlaknech provadel nejake operace, a dost casto vyuzival textove promene. Nahrazeni stringu charem, a pouziti ceckovych funkci na zjisteni delky, pripadne realokaci vetsiho bloku, atd. me praci jednoho vlakna zrychlilo o 5 vterin (z puvodnich 12ti). techto 5 vterin muze byt v nekterych situacich velmi kritickych... zvlast, kdyz soft nedela prakticky nic jineho... pri 100vce vlaken, ktere bezi non-stop.. ono to je velmi znat. To same plati pro vector (i pro jeho "light" verzi jako je napr list).

Jen upresnim, tech 5 vterin prave proto, ze jedno vlakno zavolalo hned i 1000 alokaci a dealokaci takove textove promene + nejaka prace okolo.

Pokud pouzivate funkce jako strlen, strcat atd, tak jsem si 100% jist, ze by vas kod sel jeste o dalsich 100% zrychlit.

STL ala libstdc++??? :)

Myslite tu hruzu, co se menila behem kazde major-release, je prolezla chybami, ma neosetrene pocitane reference u POD objektu, neosetreme meze u introsortu, a je v podstate zabijakem stability a binarni kompatibility kazde aplikace, ktera mela tu drzost ji pouzit? :)

btw. http://www.trilithium.com/johan/2005/06/static-libstdc/ :)

GNU STL je bohuzel chybova/pomala a binarne nekompatibilni, a to NOTORICKY. Nektere projekty, jako treba wxWidgets, ji dokonce zakazuji - viz zde: http://www.wxwidgets.org/develop/standard.htm . Pritom je povazovana za jeden z piliru C++. Muze byt potom C++ povazovano za pouzitelny nastroj?

"spatny kompilator" pro ASM je co - vetsina jich ma jen regularni prekladovou gramatiku (tabulku nad lexikalnim analyzatorem), a tedy preklad je pomerne primocary, navic 1:1 - snadno overitelny.
ano, znam nejaky spatny, treba nasm0.98, ktery chyboval v podminenych skocich, kde bezduvodne pouzival dlouhe 386kove verze i na kratke vzdalenosti, etc. Ale tam to resi jedina teckova direktiva, nebo dalsi verze. Bugovost STL uz se tahne nekolik let.

Vybral jsem si je proto, ze jsou prenositelne, a open-source. Tj. najdu chybu a mohu ji rovnou opravit, coz v pripade proprietarnich prekladacu nemohu, a na tom bych skoncil. A doslo by zase na hexaeditor, respektive __asm__ nebo db...

GNU-g++ je skareda zena, ale kazdy muze byt plastickym chirurgem. MSVC je nalestena kraska, ale neni jiste, jak se kdy zachova, a hlavne, jak si s tim pak poradit.

Ale jdete, je za nimi jen snaha vytvorit protizavazi dnesni hloupe dobe, propagujici nabalovani bloatu pred efektivitou. Ze svych tvrzeni jste nedokazal nic, jen to, nakolik dokazete byt hlasnou troubou soudobych trendu - zrejme jste byl assemblerista jen povolanim, nikoli ze zajmu a nadseni pro vec...

Dobrý kód není žádnou záhadou. Dobrý kód je takový, který buď dělá nějakou činnost co nejrychleji, nebo je co nejkratší a pokud není specifikováno, tak pracuje co nejrychleji při co nejmenších prostorových nárocích. Jsou dokonce situace, kdy dobrý kód jinak nežli v Assembleru ani nejde napsat, protože se to pro daný problém ve vyšším jazyce stává neřešitelné (nedávno jsem řešil přesně takový problém na DSP, kdy použití C by vůbec nedovolovalo daný typ DSP v dané aplikaci použít a žádný optimalizátor na světě by takový kód nebyl schopen vygenerovat, prostě proto, že bylo nutné za určitý počet taktů udělat nějakou věc a bylo třeba tomu podřídit sémantiku té věci, aby se to vůbec dalo zrealizovat).

Kód, který se nevejde na pár obrazovek (v tom nejhorším případě!), je špatný už z principu. Je to jen jasný doklad špatné dekompozice a faktorizace problému. Pokud je problém dekomponován správně, tak nikdy nestojíme před situací, kdy je nutné se hrabat v kódu přes několik stránek! Pokud píšu v C, tak žádný zdroják u mě nikdy neměl víc než několik desítek, max. stovek řádků. Pokud by se té hranice začal dotýkat, je to jasným znakem dekompoziční chyby a raději to celé rozdělím a přepíšu do smysluplnější formy. Jen jednou v životě jsem se kvůli jedné chybě musel přehrabovat takřka v celém kódu, než jsem přišel na to, že se jedná o chybu v kompilátoru.

To je ale chyba v návrhu procesoru! Produkty firmy Intel jsou od modelu 8086 prakticky prokleté - hrůza se střídá s ještě větší hrůzou! To, co píšete, platí jen pro špatné procesory. U dobrého procesoru nic takového neplatí. Nepotřebujete žádný fascikl pojednávající o optimalizaci, pokud píšete pro ARM, 68K nebo pro většinu DSP či věcí jako AVR, PIC a podobně. Složitý procesor = špatný procesor.

To souhlas, jenže žádný učený z nebe nespad. Pokud se někdo něco odmítá naučit nebo na to nemá se to naučit, tak je to jiná věc. Ale to není důvod k odsouzení Assembleru jako nevhodného nástroje, ale k odsouzení toho dotyčného jako nevhodného programátora.

Namakané možná ano, pokud vezmete Intel překladač a pustíte ho na Intel procesor a on tam začne využívat všechny ty koncepčně nesmyslné serepetičky. Ale vemte si nějaký dobře navržený procesor, v němž kvůli optimalizaci nemusíte mít přístup do mikrokódové paměti, a porovnávejte. Tam teprve uvidíte kvality nebo spíš hranice kompilátoru. A pro ten Intel vám akorát vyplyne, že to znamená, že by se pro něj ručně dal napsat ještě daleko efektivnější kód než to, co vyplivnul překladač. Překladač totiž skutečně je jen "inteligentní" slovník - TO se řekne TAK. Ale hlavu nemá, aby danou věc řekl kulantněji nebo ji celou přeformuloval když vidí, že to není ono.

Presne tak.
Doma pro zabavu prgam PICka - to je tak primitivni architektura, az je radost na to vymyslet triky. A kdyz pak porovnavam s vyplody Ccka, je to jen jedna velka tragedie. Napr. okolo rutiny preruseni od casovace mi zbyva jediny takt na "veci okolo", tj. staci naprosto cokoli navic, a uz bych se nevesel a musel bych pouzit vyssi takt (mel jsem to na digitalkovem krystalu :), a tim zvysit spotrebu a uz bych se vezl... :(

Tak to by vás mohlo zajímat třeba toto:

http://www.rickard.gunee.com/projects/video/pic/gamesys.php

Tomu já říkám opravdu umět programovat v Assembleru.

Jo, to znam, uz asi pred rokem jsme s kamaradem studovali, jak ma vtipne udelany v te pokrocilejsi verzi barevny koder do NTSC - stihal generovat i barvonosnou (misto sinu poposunute schody, ale TV to bral :).

Jinak tohle je moje (design zarizeni, ne ty stranky): www.divide.cz - dal jsem tam 8kB flashky a bastah :). a co se tam podarilo doted nacpat (i kdyz vyvojari systemu mi nemuzou prijit na jmeno:).

To je možné, ale jediný důvod je ten, že Intel dělá prasecky navržené procesory, pro něž psát v Assembleru efektivní kód začíná být nemožné. Chtěl bych vidět třeba kód pro ARM architekturu nebo 68K. Garantuji vám, že žádným blahem bych přitom neslintal. Použití kompilátoru je vždycky kompromis. Assembleru se to nemůže rovnat nikdy.

Z MSVC mi zase jednou vylezlo

PUSH ECX
MOV [ESP],ECX

--- že by obsesivně-kompulsivní porucha? Ba ne, spíš tím prvním pushem si chtěl alokovat 4-bytové místo na zásobníku a pak tam tím movem chtěl něco uložit.

Je sice pravda, ze ne kazdy assemblerista skutecne dokaze vyprodukovat kvalitnejsi kod nez C++ kompilator, ale ty podnapile nebo pod vlivem psychotropnik latek jsem nepocital.

Umet perfektne assembler (= znat procesor a instrukce) jeste neznamena umet sestavit perfektni rutinu. Nicmene, uz samotne C je semanticky impotentni, a ZADNY z triku, zalozenych napr. na propagaci carry, vicenasobnem pouziti registru, pouzici specializovane instrukce, nebo pouziti jedne instrukce k nekolika ucelum (takovy "simd":) nedovede uspokojive popsat. A obratem, kompilator tyto triky nedovede ze zdrojoveho textu vydedukovat.

Je pravdou, ze cim novejsi procesor od Intelu, tim lepe na nem bezel "brainless" kod, kdy vse vrcholilo na PentiuIV, kde uzke dvouportove hrdlo registerfile v podstate zadusilo jakoukoli rutinu, rozepsanou s ohledem na rozlozeni datovych zavislosti. Coz ale neni chyba assembleristu, ani genialita kompilatoru ("jee, on ten hnusny kod najednou bezi docela pekne, a tamta rutina je pomala"), jen hruba chyba v koncepci procesoru (kolikata uz). Nastesti s Core2 se situace lepsi, a opet plati, ze kvalitni kod dokaze procesor vyuzit (ze je Core2 prokvetle vic nez 100vkou jinych budu nechme stranou, userspace se moc netykaji).

Jsem hluboce presvedcen o tom, ze lide, kteri tvrdi, ze HLL kompilatory produkuji kvalitni kod, tak cini z jedineho duvodu - ze NETUSI, jak kvalitni strojova rutina vypada. Coz bude patrne i Vas pripad.

No, assemblerem se denodenne zabyvam zhruba 15 let, prednasel jej na katedre pocitacu, a je to muj celozivotni konicek jeste z osmibitove demosceny, tak snad mohu mit na vec trosku kritictejsi nazor, nebo ne?

Problem kompilatoru NENI v tom, ze by nedovedl seskladat instrukce tak, aby prosly hladce konkretni pipeline konkretniho modelu - to LZE skutecne uspesne brute-forcnout. Problem je, ze uz ta primitiva, ktera do optimalizatoru vstupuji, jsou vybrana nekvalitne - jaksi dnesni x86 neni RISCovy (navenek), a mapovani konkretni semantiky na optimalni sled instrukci je druh umeni, a rozhodne ne algoritmicky jednoduse zvladnutelny problem.

V podstate ZADNY figl, krom tech nejprimitivnejsich, kompilator aplikovat nedovede. Jeho "optimalizace" totiz nejsou optimalizacemi ve smyslu vypilovani kodu, jak je zna assemblerovsky koder - spis je to jakesi "zametani kompilacniho balastu" - tj. vylozenych redundanci, tak, jak vypadly z prekladove gramatiky HLL, a ktere by assemblerista do kodu ani nikdy nevlozil.

Je pravda, ze dnes, kdy se instrukce prekladaji do vnitrnich mikroinstrukci, a kdy je pojem "registr" v podstate totez, co lokace v radku cache, muzeme i x86 povazovat za risc, a pristupy na stack za rovnocenne registrum. Ale i tak - uz jen nabobtnalost kodu, adresujiciho zbytecne na stack, znamena neustale zasekavani pipe na hranici radku cache, kdy se "dotahuje" dalsi varka kodu k dekodovani - cim bloatovejsi kod, tim castejsi load.

Result? Jeste dnes je rucni optimalizace pro vnitrni smycky smysluplna.

Pokud je aplikovat dokaze, tak jej k tomu donutte - a nebasnete ody :).

Jinymi slovy, dam vam optimalni asm rutinu, a vasim ukolem bude donutit kompilator k tomu, aby vyprodukoval stejne kvalitni kod :))). A zacneme u neceho zcela trivialniho - velikostni optimalizace funkce, co napr. prevadi nibble 0-15 na ASCII reprezentaci 0...9,A..F.

AL=0..15, vystul AL=ASCII. Donutite kompilator k tomuto?

cmp al,0ah
sbb al,69h
das

? :))) Dovede bozske -Os toto rozpoznat? :) Samozrejme ze je to jen takovy vtipek pro ilustraci - v realu budete rad, kdyz z kompilatoru vymackene tabulku nebo klasiku

cmp al,0ah
jc digit
add al,'A'-'0'
digit:
add al,'0'

:>>>

Prevod nibble na ASCII hexareprezentaci povazujete za neobvykly, nerealny, v aplikacich se nevyskytujici problem? :) Pokud kompilator zvlada optimalizace tak skvele, jak tvrdite, tato trivialita pro nej bude hrackou :).

Pouzival jste printf s %x, v zajmu "rychlosti"? :) No, pambu potes. A co ze jste vlastne programoval, kdyz jste za 18 let praxe assembleristy ani jednou nepotreboval vypsat hexadecimalni hodnotu cehokoli, probuh?

Jinak, ta rutina z DAS je obdobou rutiny z i8080, kde byly jeste pouzity dve DAA po sobe - je k videni napr. v monitoru z ROM PMD-85 :). Tak doufejme, ze se ty skvele kompilatory, optimalizovane pro x86, o pozoruhodnych vlastnostech BCD-korekci uz take dozvedely, a velikostne zaoptimalizuji kazdy takovy snippet levou zadni - vzdyt maji globalni povedomi o semantice celeho bloku kodu - tak z tech 7 instrukci snad nebudou delat problem, ne? :)

Nedela, printf() je znamy bottleneck, okolo parsingu formatovaciho stringu ztracime tisice taktu vnivec. namrskat vlastni vypisovaci rutinou data do bloku pameti, a ten pak "tisknout" naraz jako string, nebo zapsat do souboru, urychli vypis klidne hned na dvojnasobek...

Hodnotu nevypisuje kernel, preci - printf je klasicka funkce z libc, tj. v userspace se v ni uklohni vysledny tetezec, a ten se pak praskne do nabufferovaneho stdout (stale v userspace), a ten se pripadne flushne skrz syscall 4 do realneho FD 0. Teziste te rezie skutecne visi v printf, protoze dalsi zpracovani je uz vzdy po daleko vetsich blocich (~ sektor, stranka, prinejhorsim radek).

A ja myslel, ze mam oponenta na urovni, co mi konecne blaho toho C++ objasnui :(( A zase nic.

To jo, ale to se dela jednou za "uherak", navic je to opet bufferovane. Je to zhuba rezie umerna nekolika printfum, ale volana vzdy az po nekolika stovkach printfu, jednoduse receno.

Vystup na terminal, pokud jde o virtualni konzoli, je v dusledku jen placnuti retezce bytu na misto ve vram nebo stinovem bufferu, prolozenem atributy (=nic), u serioveho terminalu nastrkani znaku do bufferu obsluhy IRQ z COm portu, tj. opet zadna extra rezie na 1 byte... x-terminal zase nekresli vsechno - refreshuje svym tempem aktualni "snapshot" obrazovky, takze tez nic hrozneho.

preklad pameti je transparentni, procesor diky TLB nevnima, ze hrabe "jinam", zamena adresy stranky za jinou je pro konkretni adresar stranek po prvnim pouziti nacachovana a dal nijak nezdrzuje.

suma sumarum, zkuste si ten cyklicky volany printf nahradit, a uvidite :-P

Ja pracuju jako profesionalni programator a tenhle prevod nibble potrebuju kazdou chvili.

Ten das pustí tolik mikrokódu, že bude mnohem pomalejší než cokoli jiného.

Ale bohužel, ani ten druhý případ s jedním skokem gcc ani icc vygenerovat nedokáže, oba kompilátory tam dají skoky dva :-(

Nejrychleji (bez mikrokódu ani bez flushnutí pipeliny při skoku) by se to řešilo asi přes cmov nebo setc.

skok tam nemusi byt vubec zadny, mame preci SUBB r,r - nadheru, konvertujici carry na 00000000/FFFFFFFF.

tj. ve stylu

cmp al,0ah
sbb bl,bl
add al,'A'
and bl,'A'-'0'
sub al,bl
...


a tak vubec :>

Jenže SBB (i ADC) je na Intelu plnej mikrokódu (na AMD ne, tam je přímo v ALU za jeden tik). Místo SBB asi spíš použít SETC nebo SALC.

To plati predevsim pro PRISERNE PentiumIV, kde podezrivam designery,ze cilem bylo provest co nejrychleji nejaky kompilovany brainless-benchmark-code, za kazdou cenu.

U Core2 uz to neni zdaleka tak strasne (puze 2uops) - a btw. Agner tez tvrdi, ze Core2 ma 3-port regfile... ted jsem na to zrovna mrknul.

V assembleru se napriklad deleni 255 u skladani dvou alfa kanalovych obrazku da napsat o tik rychlejc, protoze hodnoty 65026-65535 do toho deleni nikdy nevstupuji. Kdyz se alfakanaluji dva obrazky 1024x1024 pixelu, tak to usetri 3145728 tiku.

Da se v C nadefinovat int a /* 0-65025 only */? Neda. Takze C kompilator plive rutinu co deli od 0-65535 a je zbytecne pomala.

Ten dvouportový register file má core2 (a pentium pro/2/3). Pentium 4 má 128 obecných registrů, přístupných snad bez omezení. Ale Pentium 4 má zas spoustu jiných nevýhod (např. velká trace cache => malá datová cache).

Taky mě fascinuje, že core2 zvládne 4 mikrointrukce za tik, ale jen dva přístupy k permanentním registrům za tik.

To neni pravda, core2 ma uz 3 porty, mnohokrat overeno. PentiumIV pouze dva, takze kod vpodstate musi byt psan stylem neustalych referenci pres [EBP], nebo k "recently computed" vysledkum, jinak se instrukce v onom 2-port bottlenecku "potkaji" a je konec.

Core2 = 3-portovy regfile
PIV = 2-port

overeno, mel jsem tu 'cest' optimalizovat pro oboje a takto se to skutecne chova.

A jak jsi to testoval?

Zkus tohle:

movl %%eax, %%edx
movl %%ebx, %%ecx
movl (%%esi), %%edi

--- tohle (provedené opakovaně ve dlouhé sekvenci) na Pentiu 4 má propustnost 3 instrukce/tik a na Core 2 dvě instrukce za tik. (pokud tam dáš movl (%%ebp,%%esi), %%edi, bude to mít na Core2 propustnost ještě nižší, 1.5 instr/tik --- nevím proč --- zatímco na P4 to budou pořád 3 instr/tik).

Pokud to (%%esi) zaměníme za konstantu, bude to i na Core2 mít propustnost 3 instr/tik.

Další pokus:

movl %%eax, %%edx
movl %%eax, %%ecx
movl %%eax, %%ebx

---- P4 i Core2 udělají 3 instr/tik.

movl %%eax, %%edx
movl %%esi, %%ecx
movl %%edi, %%ebx

--- P4 udělá 3 instr/tik, Core2 udělá 2 instr/tik.

BTW. Pentium Pro/2/3/Core2 má propustnost permanentního register filu 2 registry/tik, takže v rámci jednoho tiku můžeš číst nejvýše dva registry, které jsi dlouho nemodifikoval. Registry, které jsi před pár instrukcemi modifikoval, můžeš číst kolikrát chceš, protože ty se z permanentního register file nečtou (viz. ty Agnerovy dokumenty).

Jiste, Agnera Foga jsem take pouzival...

ale tve sekvence nejsou akuratni, protoze si nejsem jist, jestli se to nezahazuje jeste nekde daleko pred writeback - protoze ty tu hodnotu, aniz bys ji nejak pouzil, znovu prepises. Coz spolu s register-renamingem muze delat docela divy, protoze pak pujde o to, kde se bude rychleji ten rename-index "tocit".

Zkus nejaky priklad, kde toto mozne nebude, tj. kde je datova zavislost, co renaming v tom samem flowu zblokuje. Ja to zkousel, a na Core2 vysledky odpovidaly 3-portovemu regfile, na PentiuIV a Mobile 2-portovemu.

Stáhl jsem poslední verze Agnerových dokumentů a tam se píše, že Core2 má 2 porty na datové registry a jeden port na index registr. Ale nasimulovat se mi 3reg/tik nedaří stále, asi narážím ještě na něco jiného.

Operacni systemy se nepisi v ASM z duvodu portability, nikoli kvality kodu. A pokud jde o ty nejvnitrnejsi casti kodu, jsou casto usmevne - zhruba na urovni studenta, milovnika HLL, co zkousel moznosti GASu (mluvim o Linuxovem jadre).

Obcas jde ve zdrojacich najit i vylozene humorne useky, namatkou napr. cut-paste z bsetup.s, realmodovy presun kernelu nad prvni stranku (kde se pak spusti deflate co ho hodi na 0x10000):

do_move:
movw %ax, %es # destination segment
incb %ah # instead of add ax,#0x100
movw %bx, %ds # source segment
addw $0x100, %bx
subw %di, %di
subw %si, %si
movw $0x800, %cx
rep
...

Kvalita kodu je skutecne neco jako "kvalita hudby". Nekdo si pousti Beethovena, a neci hudebni naroky uspokoji i Maxim Turbulenc. Ano, oboji "je hudba", ale...

nepisi -> pisi of coz..

Nebrani mi nic, mam vlastni live-linux, s vlastnim upravenym kernelem... bezi na vsem od 486sx8/4MB, mimochodem :)
Kdyby byly systemy psane v assembleru, vejdou se nam jeste dnes na disketu. Pokud kompilatory nezvladaji kvalitne rychlostni optimalizaci, tak velikostni nezvladaji uz VUBEC - a zbytecne rozbredly kod = zbytecne vypadky stranek = zbytecne plneni bufferu, zbytecne vymyvani cache... a jsme zase doma.

Zkratka , porovnavat assembler s HLL je jako porovnavat stetec a paletu s omalovankou. Ano, vetsina lidi s omalovankou docili lepsich vysledku nez bez ni, protoze neumi malovat. Ale tim kvality omalovanky konci. A C++, zejmena s STL, takove kodove omalovanky byly, jsou, a bohuzel budou.

386sx of coz :>.
ale stop flame, kdo se assemblerem dopravdu do hloubky zabyval, musi vedet o kvalitach HLL svoje... a zpravy o novych "vylepsenich" C++ bere spis jako cernou kroniku, nez prislib svetlych IT zitrku.

Dokazovat musite Vy - kvalitnim asm rutin Vam poskytnu ja nebo Mr,. Google kupu - a Vy ukazte, ze skvely moderni kompilator vyprodukuje kod stejne kvality. Ja vim, ze ne, a vy se to po vikendovem zonglovani s prepinaci dozvite take :)

Dejte mi ICQ nebo mail, dam Vam nejake resources (ktere tu nechci trousit).

Ten jazyk voli z ciste pragmatickych duvodu, nikoli proto, zaby vznikl kvalitnejsi, kratsi, hezci kod.
Vy extrapolujete z uceloveho rozhodnuti neexistujici kvality - jako kdyby nekdo, kdo se rozhodl pro umely vanocni stromecek, tvrdil, ze voni lepe nez ten pravy...

Z vlastni zkusenosti vim, jak po masazi kompilovanymi ohavnostmi clovek rychle (a ochotne) zapomina, jak vlastne kvalitni kod vypada - bohuzel :(.

Ehm, slyšel jste někdy jméno Chuck Moore? Tohle mne vždycky strašně baví, jak někdo z vlastní neschopnosti vyvozuje obecné závěry o nemožnosti něčeho. Na základě diskuse, kterou tu vedete, si o vás nemyslím, že byste byl bůhví jak dobrý assemblerista, naopak si myslím, že vaše kódy jsou v lepším případě průměr. Jinak by totiž vaše zkušenosti musely být úplně jiné.

C++ bylo vyvijeno s ohledem na omezeni kolizi vice programatoru na 1 projektu - proto privatni metody, protected metody, namespaces... o rychlosti nebylo ani slovo. Nehlede k tomu, ze prvni stroustrupovy kompilatory produkovaly jako vysledek - obycejne cecko, ktere se muselo jeste kompilovat obycejnym C kompilatorem :)

A tvrdit, ze neco takoveho je rychlejsi, je jako tvrdit, ze kdyz do auta posadim prdelatou tchyni, vyjedu s nim vyssi kopec :P

To, ze se při návrhu C++ nehledělo na rychlost je pěkny kec: viz klíčove slůvko virtual, pokud ho nepoužijete NEPLATÍTE za to. Tedy ne jako v jiných "obj." jazycích.
Pravdou je, ze C++ bylo mimojiné navrhováno, aby způsobovalo minimalní zpomalení oproti kódu C: pokud je tedy rychlost vyžadována a programátor tomu přizpůsobí styl práce.

Mimo jiné o tom "prvním C++" co hovoříte, máte asi na mysli C with classes? To ale není C++. C++ je zcela samostatný jazyk.

Jinak dopředu přiznávám, že ASM nerozumím. Proto jsem ochoten připustit, že ASM bude oproti C++ rychlejší. Ale chtěl bych vás a vám podobné vidět psát projekt typu KDE v ASM:) Takže se nad vaším příspěvkem pouze pousměji, asi jako když se student podívá do učebnice Dějepisu a tam vidí obrázky od Zdeňka Buriana.

Jinak se držím pravidla, že o kvalitě příspěvku mimo jiné napoví, zda se pod něj autor podepíše a nebo napíše jen debilní přezdívku. Tedy nejenom proto u mě Miloslav Ponkrác vede!

Tak znovu - prvni kompilatory C++, vznikle po navrhu, "kompilovaly" opet co C source, ktery se znovu prekladal beznym kompilatorem Cecka. V dusledku pribyla ve zdrojaku halda balastu, zbytecne dedenim nabobtnalych struktur, a zbytecnych inicializacnich funkci (jaksi objektovy pristup neuznava bzero() nad polem, ale nejapne vola konstruktor nad kazdym prvkem, etc.). Takze na pomalost nemusime mit virtualni metody, ta s objektovym pristupem souvisi z vice duvodu.

Pokud nerozumite assembleru, divim se, kde berete odvahu vubec posuzovat kvalitu kodu - jste jako zednik, co neumi namichat maltu. Predstavovat se nemusim, google Vam napovi.

"Jinak problém je, že 4 KB spustitelná binárka většinou nedělá nic tak užitečného, aby byla k něčemu dobrá. Hodí se prakticky jen jako ukázky, že to jde - a sem tam možná někdy jako jednoúčelová málo používaná utilitka."

Na ZX spectru se do 4KB vešel celý disassembler. A do 10KB assembler nebo kompilátor basicu.

A někteří (jehož jsem jmenoval výše), dokážou na pár desítek KB udělat program pro návrh VLSI obvodů, který dokonce dokáže simulace dějů na úrovni PN přechodů provádět věrohodněji, než jeho stovkyMBoví kolegové. Holt kdo umí, ten umí. A kdo neumí, ten jen hloupě kecá o tom, jak něco není možné.

Ale jdete, zase povysujete singularity datovych zavislosti na obecny jev. Tvrzeni "třeba maximální rychlost nikdy nevzniká u nejkratšího kódu" si dejte za ramecek - je to nesmysl. Ale mozna jste mel na mysli "ne kazdy nejkratsi kod je nutne nejrychklejsi" - s tim uz se da polemizovat.

Nicmene, nic to nemeni na tom, ze produkt kompilatoru nebude ani kratsi, nez ASM rutina, ani rychlejsi. Optimalizace kodu nejsou sachy, aby tam existovala univerzalni pocetni postup, dovolujici protocit vsechny varianty (a i tam zatim mozek zdatne konkuruje nejmodernejsim strojum). Priklad s neobvyklym pouzitim DAS Vam mel ukazat, co je to napr. velikostne ooptimalizovany usek kodu, a co je to impotence kompilatoru sestavit totez.

Mejte, clovece, trosku ucty k lidske napaditosti, a nepovysujte tupy optimalizacni pruchod nad neco, nad cim hloubal mozek :).

To neni tak docela pravda. Mene instrukci se uz z principu stihne drive. Pripadna disproporce mezi delkou a rychlosti vznika az diky nevhodnemu poskladani kodu do pipe, coz ma pricinu (drive) v datovych zavislostech, a (nyni) v paralelnim pristupu do registroveho bloku. Ale i tak, toto jsou spis kurioznui priklady, obecne lze sestavit vzdy rychla a kratka rutina (ktera se vyhne dnes pomalym zalezitostem, jako mixovani byte/word pristupu do registru, pouzivani reliktu jako XLAT a podobnych, drive velmi efektnich technik)

Priklad na 3 instrukce jsem sem daval s ohledem na povahu fora - chcete snad zdrojaky cele hry, kompresoru, syntezatoru, a podobne? :) Muze byt (ale kdo to ma pak cist). Souhlasim, ze lidskam invence to ma v IT stale tezsi, ale v pripade assemblerovske optimalizace jste hodil flintu do zita hooodne predcasne :)

Mene instrukci se _stihne_ drive, pokud nepouzivame ty, ktere vyrobce dodatecne zprznil (a pred 30 lety s velkou slavou uvadel). Skutecne, nestavme vec tak, ze delsi kod je vzdy lepsi, protoze je delsi z duvodu optimalizace rozvijenim cyklu etc. - to je demagogie, temer vzdy jsou duvody nabobtnalosti jine, a vysledna rychlost je take horsi nez u kratsi promyslene rutiny.

Vyvoj v IT vede ke snadnejsimu vytvareni mene efektivnich aplikaci, to je fakt, ktery je vylozene zhoubne lakovat takto naruzovo...

Ale jiste - kompilator urychluje tak skvelymi technikami, jako je rozvijeni cyklu - to by skutecne assembleristu "nenapadlo", ze :). pro kodera je tov az posledni moznost, kudy z louze ven - ze spacha misto zavinute rutiny rozlozeny "strudl" instrukci...

Stojim si za tim, ze ooptimalizacni genialita dnesnich kompilatoru je na urovni cvicene opice - z dane mnoziny instrukci dovedou sestavit nejrychlejsi permutaci a odstranit redundance - ale jaksi, uz z prekladove gramatiky tato mnozina vysla NEVHODNA, to je ten for.

"Mene instrukci se uz z principu stihne drive. Pripadna disproporce mezi delkou a rychlosti vznika az diky nevhodnemu poskladani kodu do pipe"

Problémy u komplikovaných instrukcí většinou nejsou s pipou (procesor si scheduluje instrukce sám), ale s mikrokódem.

Na 8086 byla úzkým hrdlem paměť, takže návrháři udělali instrukční sadu co nejvíc košatou, aby se kód dal velmi dobře zmenšit (čímž dojde ke čtení méně bytů z paměti). Postupem času to přestalo být tak moc důležité, protože se stejně kód čte z L1 cache a neblokuje současný přístup k datům --- a kvůli zjednodušení jádra procesoru se začaly málo používané instrukce mikrokódovat. Třeba instrukce

ENTER, řetězcové instrukce (vyjma dvou zadrátovaných případů "REP MOVSD" a "REP STOSD"), DAS, PUSHA, LOOP, JECXZ ... apod.

jsou pomalejší než kdybys je rozepsal na jednoduché instrukce. U výše popsaných se musí sahat do mikrokódové ROM, zatímco u obyčejných instrukcí ne.

O to nejde, vsak jsem psal, ze uvazujeme pripad, kdy se rutina temto instrukcim vyhne - tj. bude pouzivat primitivni instrukce, ktere se nerozkladaji do mikroinstrukci.

Ostatne to, ze si je Intel dovolil beztrestne nahradit pomalymi variantami, je z velke miry dano tim, ze se v tupem kompilovanem kodu ani predtim prilis nevyskytovaly...

Ano, muze vzniknout bud spatny, nebo jeste horsi kod, moznosti nam dava objektovy pristup spoustu. :)

Aby bylo rozumeno - samotne C++ neni spatne, ale spatni jsou programatori, kteri ho spatne pouzivaji, a takovych je vetsina. Protoze ti dobri, narozdil od nichm, nejake C++ nepotrebuji. To je ten vtip.