Vlákno názorů k článku
Nová generace jazyka C++
od Zilog - Kazdy, kdo jen trochu zna kouzlo optimalizovaneho strojoveho...
-
Zilog (neregistrovaný)Kazdy, kdo jen trochu zna kouzlo optimalizovaneho strojoveho kodu, asi tusi, co je v dusledku C++ - nastroj, kterym jde velice snadno a elegantne (lec v mnohych pripadech ta elegance znacne kulha) sestavit naprosto hruzny, rozvlekly a zvrhly kod.
Vzdy je na povazenou, kdyz nejaka vec stavi na neexistujicim rysu zakladnim - a objektovost, umele naroubovana na klasicky imperativni jazyk, bezici bez vyjimky na imperativnich vypocetnich modelech, je presne tento pripad. A neefektivita vysledneho C++ kodu je jen "ovocem" tohoto abstrahovani od faktu, jak veci "pod poklickou" funguji. Pametove kapacity jsou zrejme nafukovaci, a rychlost hardwaru nekonecna... jen pan Stroustrup je (bohuzel) ve sve snaze priblizit programovani lamerum neunavitelny.
Cim mene C++ a STL, tim efektivnejsi kod. Tak proc, proboha, jeste dalsi inkarnace tohoto zloradu? -
Zilog (neregistrovaný)Jeste upresnim - ano, jako assemblerista to nemusim pouzivat. Na existenci dalsi alternativy neni obecne nic spatneho...
Jenze, vsechny tyto frikulinske novinky se prosazuji pomerne nechutnym zpusobem - vetsinou se v nich zhledne uplny zacatecnik, a nebo veci neznaly manazer, a tak i ti, kteri jejich nasazovani brali s rezervou a strizlive, jsou posleze nuceni koukat a babrat se s kodem, kde je nekdo schopen napr. tvorit class pixel s virtualnimi metodami (to aby se ten framebuffer lepe plnil), a podobne zvrhlosti.
Kvalita jazyka je primo umerna vedomostnimu backgroundu komunity, ktera jej podporuje a pouziva. Coz pro produkt pane Stroustrupa vyzniva pomerne nelichotive. -
S krasou strojoveho optimalizovaneho kodu se dneska muzeme jit zahrabat. Podstatna je slusna davka abstrakce a k tomu povazuji za zcela nezbytne mit take k dispozici opravdu objektovy jazyk. (Dobre, objektovost C++ je pomerne pofiderni, ale to je vec druha.) Ostatne kdo dneska pise v assembleru? Vyjma specialnich vyuziti to moc lidi neni a i ti, co to jsou, to delaji tak maximalne ze zajmu, pro penize fakt tezko. -
Zilog (neregistrovaný)Podle meho uz sam assembler je urcita abstrakce, a tou slusnou davkou bylo, je (a doufejme, ze bude) prave Cecko, bez bloatovych serepeticek pane Stroustrupa. Objektovost sama o sobe je naprosto umely rys, ktery nema s cinnosti pocitace pranic spolecneho. Jeji umele vnucovani v naivni vire, ze usnadni programovani a zkvalitni aplikace, vedlo akorat k narustu pomeru pocetni narocnosti aplikaci vuci realne vykonane praci, a naprostemu oddaleni semantiky zdrojoveho textu od semantiky vysledneho kodu, coz je radost hlavne pri debugovani takove aplikace - 10x vice 3x pomalejsiho kodu dela neco, a dela to spatne., a ted babo rad, kde kompilator pri sezvykavani platformovanych uchylnosti pochybil, a hlavne, jak to cele prepsat, aby k tomu priste nedochazelo.
Nasazovani objektu tam, kde nemaji co delat (tj. v 90% mist, kde dnes jsou), je primou pricinou nesmyslne vysokych naroku soucasnych aplikaci na hardware. A jazyk, ktery toto svou filozofii umoznil a prosadil, je proto kontraproduktivni (resp. oslovil hlavne tu cast programatorske verejnosti, ktera nemela potrebny background, aby se jej chopila efektivne). -
Clock (neregistrovaný)Jo asembler abstrakce je.
Napr. Z80 nemel instrukci nastav n-ty bit registru A kde n je ulozeno v registru C. Ale pomoci strojaku se dala udelat - to n totiz bylo ulozeno v opcodu jako bitove pole, takze stacilo hodnotu z C vzit, omaskovat, shiftnout, priornout opcode, pouknout tesne pred PC a prevalcovat ji exekuci - a uz to ficelo. Bez znalosti strojaku by se to muselo delat smyckou, coz je jednak podstatne pomalejsi, a jednak delka exekuce zavisi na hodnote C, coz rozbije napr. casovani kdy si clovek pocita jednotlive tiky. -
krtek (neregistrovaný)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...
-
kokes (neregistrovaný)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. -
Marek Pavlu (neregistrovaný)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:)... -
Clock (neregistrovaný)Derny stitky se porad pouzivaj na katalogizaci mikrofisu, ty chytrej jak radio: http://en.wikipedia.org/wiki/Microfilm
-
Clock (neregistrovaný)C++ nepouzivam. C++ programy nemam rad protoze se kompiluji odhadem 3x tak dlouho jako normalni a casteji pri kompilaci zhavaruji na nejaky error nez C programy. Lidi taky casto C++ pouzivaj jako kanon na vrabce, jako nahrazku vlastni programatorske nekompetence, takze to ze program je v C++ mi automaticky naznacuje, ze to bude asi pekny shit.
V Linksu objekty mame, ale C++ jsme nepouzili, protoze generuje zbytecne pomaly nabobtnaly kod a je to prekomplikovana koncepcni slatanina v ktere se tezko orientuje.
Virtualni metoda==pointer na funkci
Tabulka virtualnich metod==struktura s pointery na funkce
Dedicnost==pretypovani struktur
objekt==struktura
metoda==funkce
this==kontext predany funkci
sablona==#define (viz dither.c) #definy sice nejsou asi turingovsky kompletni, ale na ten Links to staci - tam je potreba vygenerovat pro kazdou pametovou organizaci extra ditherovaci funkci, aby to bylo rychly.
Vyhoda tohohle pristupu ze ta objektovost se pouziva pouze v nezbytne nutnych pripadech a ne porad, takze to zbytecne nezpomaluje. -
Atom321 (neregistrovaný)To, že v C++ často píší blbci neznamená, že každý program v C++ je shit a něco jiného v C bude nutně perfektní. Už jsem viděl hromady blbých kódů v několika jazycích a nikdy za to nemohl jazyk jako takový.
Objektovost v C++ se samozřejmě rovněž dá používat pouze v nezbytně nutných případech - od toho jsou tu statické metody a proměnné. Rozdělení logických částí do tříd v C++ navíc dokáže velmi dobře zpřehlednit celý kód.
Psaním objektových věcí v C se akorát více nadřete, protože musíte psát spoustu věcí, které překladač C++ udělá za vás. Žádnou výhodu to nepřináší. Pokud píšete dobře v C i v C++, přeložený kód je téměř stejný. Holé C ve spojení s ASM je dobré na malé utility, bootloadery, jádra OS a podobné věci. Na rozsáhlé aplikace s klikacím GUI je to akorát prostředek ke zpomalení vývoje a dokázání "že to taky jde". -
__dark__ (neregistrovaný)C++ je nastroj k tomu, aby byl spravovany kod mensi a udrzitelny. Ja jam pouzivam mix jazyka C a C++ a nekdy asm a opravdu nemuzu rict, ze by C++ generoval vetsi kod. Ono totiz zalezi, jak umite v C++ programovat. Pokud pouzijete naprosto nesmyslne sablony tak vam prekladac udela vzdycky velikou binarku. Pokud nepouzijete STL, vyjimky a RTTI, nemuze vam C++ udelat vetsi binarku.
Dost dobre si dovedu predstavit, ze zrovna dithering by byl pomoci sablon mnohem lepsi a efektivnejsi nez ten vas v C pomoci #maker. -
Marek Pavlu (neregistrovaný)//Virtualni metoda==pointer na funkci
To je pravda, ale copak se pointery na funkci nikdy v C nepouzivaji?
Odpovezte si a zjsitite, ze docela casto.
Velmi casti prave na obycejnych pripadech jako zavolani fprintf pro stream a podobne, protoze ten vystup muze byt bud do seriovky, souboru a nebo jinam a pokazdy projit seznam funkci a ten tok takto smerovat pres if je proste hovadina, kdyz se da volat konkretni funkce pro dany smer primo.
A potom, kazda dobra kniha k C++ problem virtualnich metod vysvetluje...
//Tabulka virtualnich metod==struktura s pointery na funkce
Viz predchozi...
//Dedicnost==pretypovani struktur
Hmm, chytre, jenze ta dedicnost je ponekud bezpecnejsi.
C++ cloveka nenecha pretypovat objekt jen tak na cokoliv...
//objekt==struktura
Kdyz, tak alespon takt: struktura + metody + pristupova prava
A porad je to i tak nepresne:).
//metoda==funkce
Objev roku:).
//sablona==#define (viz dither.c) #definy sice nejsou asi turingovsky
Tak na tohle uz nemam nervy, prosim, jdete a otevrete si knizku o C++ a potom tu hazejte rozumy!
Nazdar! -
McBig (neregistrovaný)"Kvalita jazyka je primo umerna vedomostnimu backgroundu komunity, ktera jej podporuje a pouziva."
Ja mel vzdy pocit, ze plati ze kvalita kodu programu napsaneho v libovolnem jazyku je primo umerna programatorovych znalosti a jeho kultury psat nejaky kod.
Tedy ne ze by se tyto dve teze nejak vylucovali, spise naopak. Ale postavil sem je proti sobe aby bylo lepe videt, na cem stoji kameny onoho vysledneho programu. To ze mate jazyk, ve kterem krasne vypadajici kod je pak hnus, ktery provadi procesor je jedna vec, ovsem to ze mate moznost, tento hnus do jiste miry ovlivnit... vlastne temer uplne to je jedno ?
Uprime receno... nevim proc zrovna "assembleristi" rypaji do toho jak jazyk, ktery je o 2 tridy vyse, vypada ? Tedy... ano chtel bych aby to co napisu v c++ aby bylo dostatecne optimalizovane, ovsem to je otazka prace kompilatoru, nikoli prece navrhu jazyka. Vzdyt v libovolnem jazyku lze napsat libovona zrudnost stejne jako velmi cisty a prehledny kod. Implementace je jen neco... co muze zvysit moznosti uzivatele (programatora). -
Zilog (neregistrovaný)To u vyssich jazyku neplati, protoze moznosti, jak ovlivnit vysledny kod, jsou velmi omezene. Takze lze jen posuzovat, nakolik se dany zdrojovy text trefuje do predpokladane filozofie jazyka. A to jsem mel presne na mysli - jazyk se spatnou filozofii si nikdy neziska na svou stranu programatory, kteri jeho pomocna kolecka nikdy nepotrebovali, a vnimaji je jako obtezujici zbytecnost.
Milovnici vyssich jazyku (a hlavne ti, co assembler neznaji, natoz optimalizacni triky a figle) se casto zaklinaji tim, jak vsemocny kompilator vse udela za ne, a spravne. Pritom staci jediny pohled do objdump -d, a vidime, jak je tomu doopravdu, i v pripade -Obuhvikolik. Bohuzel, hardware je realny, a ma nejake vlastnosti, a dobry jazyk je ten, ktery je dovede vyuzivat. A je nabiledni, ze zbytecne abstraktni slataniny pane Stroustrupa, naroubovane na puvodni pakticky koncept Cecka, to jaksi bohuzel (nebo spis bohudik) nejsou...
Kod vykonava procesor, a zde je klic k chovani vysledne aplikace. Posuzovat krasu zdrojove formy s tim, ze to "kompilator uz nejak udela" je cesta do pekel - neudela, a nebo udela spatne. -
McBig (neregistrovaný)To samozrejme ano... s tim rozhodne souhlasim, jen ale me pripada krapet zbytecny delat takovy humbuk prave okolo c++, ktere je narozdil od ostatnich z5tne kompatibilni v podstate az k tomu assemleru... tj.. neni problem tyto veci ruzne michat. Proto libovolna abstrakce nad C me pride porad svobodna. Ano pokud sem lama a blbecek, kterej si mysli ze zna uplne vsechno... a pouzivam to... moje blbost... ale pokud pokorne vim... ze neni vsechno zlato co se trpiti, a snazim se cas od casu i optimalizovat ..(a lze to i bez assembleru) a hlavne mam k tomu tu moznost tak je vec uuuplne jina. Jde me prave o to.. ze neni problem napsat uzasny objektovy kod a v nem pouzit rychle ceckove funknce.
Navic C++ je svou rychlosti porad jeste relativni nizkourovnovy jazyk narozdil od jinych objektovych kras ze :) -
Zilog (neregistrovaný)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 :) -
Mám jen dotaz pane nejchytřejší, kolik jste toho v C++ napsal?
Většina dnešních projektů toho používá s C++ dost - už jen proto, že používají standardní knihovnu a ta zasahuje do dost značné části C++ možností.
Jestli máte mindráky vůči objektům, které jen tak mimochodem nijak nesnižují efektivitu a rychlost výsledného kódu, je to Vás problém. -
McBig (neregistrovaný)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. -
C++ je jazyk, kde si můžete zvolit co chcete. Úroveň abstrakce, způsob programování. Co chcete. Můžete v něm napsat kód stejně rychlý jako v asm, a nebo využít maximum abstrakce a vyleze kód o několik procent pomalejší, které naprosto nikoho netrápí.
OOP není a neříká nic o rychlosti. Objekty nejsou pomalé a nezdržují vykonávání kódu - to píšu proto, aby bylo jasno. Vždy záleží co je za tím, samotný fakt, že se používá OOP neznamená, že to nemusí být rychlostně srovnatelné s asm. Mnohé operační systémy obsahují v samotném kernelu C++ objekty a je to superrychlé - namátkou třeba Symbian, L4, a další.
Samotné objekty se standardní knihovny C++ nejsou pomalé - pokud chcete superrychlost, stačí si uvědomit, že jediné co zdržuje je alokace a realokace paměti. Zbytek je v šablonách, které se rozvinou jako makra - dokonce ani ty metody se nevolají, ale inlajnují. Protože návrháři jazyka C++ byli vesměs nejlepší programátoři z celého světa - a protože si dali za cíl maximální rychlost - pamatovali i na toto. Takže v okamžiku, kdy chcete vyždímat max. rychlost z objektu třeba string - nahraďte si objekt alokátoru třeba nějakým, který nealokuje paměť na heapu, ale používá třeba statické pole. Rázem máte komfort objektu string a nadzvukovou rychlost.
Problém právě je, že někteří lidé propagují lžívá klišé ve smyslu OOP = pomalost.
Mě právě fascinuje, že mluvíte o objektu string a o volání hromady obslužných metod, tato souvislost mi uniká. Právě v objektu string se skoro nic nevolá, vše se rozvine pomocí šablon tak, že volání metody ve výsledném kódu abyste hledal lucernou a pomocí soukromého detektiva.
Jinak souhlasím, že programátor zelenáč dokáže leccos. -
Zilog (neregistrovaný)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) -
1) gcc není kvalitní kompilátor
2) to, že existuje nekvalitní knihovna neříká nic o C++ obecně
Zbytek viz můj jiný příspěvek.
Jinak nechápu, proč onanujete o asm v článku o C++? Jinak Vám doporučuji osvětu o tom, že asm je nejlepší - přesvědčte o tom sw firmy ať vše programují v asm. A nebo ještě lépe, založte takovou firmu a zbohatněte jako Bill Gates a dokažte nám jaký jste borec. Je v tom nějaký problém? -
McBig (neregistrovaný)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. -
Zilog (neregistrovaný)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/ :) -
A jak to jako souvisí s C++?
Myslíte jako, že pro třeba neexistuje špatný asm kompilátor? Že neexistují špatné a špatně neošetřené knihovny pro asm? Znamená to tedy, když najdu jednu špatně udělanou knihovnu pro asm, že z toho učiním závěr, že asm je špatné a mělo by se vymýtit pokud možno ohněm a mečem?
Vážený pane, v každém jazyce najdete špatné kompilátory, ale i ty dobré. V každém jazyce najdete špatně napsané knihovny, ale i ty dobré.
Závěr nechť si každý udělá sám. -
Zilog (neregistrovaný)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. -
No a co, že je GNU STL pomalá? Tak si vyberte jinou implmentaci STL, je jich snad málo? Mě už doslova štve, jak dáváte rovnítko mezi C++ a gcc+GNU STL. Jestli budete stejně postupovat v životě, tak si vyberete nejškaredější ženskou a budete všude vyprávět, že všechny ženské jsou na zvracení.
Existuje mnoho jiných kompilátorů a mnoho jiných implementací STL. To, že trváte na špatných věcech není problém C++, ani STL, ale jen pouze Vaše blbost. Nic jiného se tím nedokazuje. -
Zilog (neregistrovaný)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. -
Zilog (neregistrovaný)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...
-
Ale no tak. Co jste dokázal ze svých tvrzení Vy? Naprosto nic!
Assembler jsem používal, ale takový nadšenec, abych bastlil kód, který můžu mít hotový den v C++ namísto toho tři měsíce v asm skutečně už dnes nejsem. Najmě, když z toho C++ kompilátoru to vyjde stejně rychlé a kvalitní. Takže nadšenec jen pro nadšení to už dnes opravdu nejsem. I když býval jsem takový. -
anonymníTohle přece nemůže myslet vážně nikdo, kdo do dané problematiky opravdu vidí. Kód generovaný překladačem z C++ nikdy není a nebude tak dobrý, jako dobře napsaný kód v Assembleru. A to je ten velmi podstatný rozdíl - lze napsat špatný a neefektivní kód v Assembleru stejně dobře, jako v C++ - a začátečník v Assembleru takové programy ze začátku pravděpodobně bude plodit v drtivé většině. Ale obráceně to už neplatí - i když napíšu dobrý kód v C++, výsledek se nebude nikdy blížit dobře napsanému kódu v Assembleru. Vždycky mě zvedá ze židle, když někdo říká, jak ty dnešní kompilátory už jsou namakané a jak je jejich výsledek srovnatelný, ne-li lepší, s ručně psaným Assemblerem. Já na to říkám - ani náhodou! Takový člověk v tom případě dobře napsaný assemblerský program v životě neviděl. Netvrdím, že by se měl na vše používat Assembler, ale že by se jednotlivé nástroje měly používat s rozumem. A pokud dotyčný jede pouze v tom svém jazyku, protože jiný neumí, tak by měl raději zvážit jinou profesi, třeba něco manuálního, jak nám říkávali při cvičení z matematické analýzy, pokud byl někdo dřevo.
-
Ano, v zásadě s Vámi souhlasím. Je tu ovšem několik ale.
Pominu v zásadě to, že jste nekorektní v tom, že jste napsal _dobrý_ kód. CO toje dobrý kód? Nejkratší, nejrychlejší, nejefektnější, nebo jak to myslíte?
Teoreticky vždy lze v asm napsat lepší kód, než co vyleze z dobrého C++ kompilátoru. Problém je, že pokud se nebudeme bavit o nějakých primitivních rutinách na pár obrazovek, prakticky bude C++ kompilátor skoro vždycky lepší. (zkusme si předem ujasnit, že gcc není dobrý C++ kompilátor).
Problém je ten, že dnešní procesory jsou tak složité a optimalizace pro ně ve strojáku tak náročná, že pokud opravdu tvrdě nestudujete a neustále si nedoplňujete znalosti z rozsáhlých optimalizačních menuálů, nemáte šanci. A problém je, že napíšete nejlepší asm kód pro model procesoru A a abyste ho při vydání dalšího procesoru zase přepsal, protože pro Pentium dalšího modelu už zase nejlepší nebude.
Je totiž obrovský rozdíl psát v asm - a psát v asm super optimálně. A je jen velmi málo lidí, kteří to dokážou - a naproti tomu je obrovská armáda lidí, kteří v asm umějí psát.
Takže ano, vždy jde napsat v asm líp, než to udělá kompilátor. Ale prakticky je to v 99,999% případech jen čistá teorie. Protože dnešní kompilátory skutečně namakané jsou, pokud je udělá firma, které na to záleží. -
Biktop (neregistrovaný)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. -
Zilog (neregistrovaný)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... :( -
Biktop (neregistrovaný)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. -
Zilog (neregistrovaný)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:). -
On gcc je dost špatný kompilátor, pokud se týká optimalizace. Na to je jednoduchá odpověď, můžete si vybrat:
1) Nebude Vám to vadit, protože prostě chcete používat gcc a smíříte se s tím, že je horší a nějaká pikosenda navíc v provádění kódu Vás netrápí.
2) Přejdete na dobře optimalizující kompilátor - většinou podle platformy. Například na Microsoft Visual C/C++, Intel kompilátor, Digital Mars apod.. Tam mi věřte, že z toho poleze strojový kód, že i fanatický assemblerista bude slintat blahem. -
Biktop (neregistrovaný)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.
-
Ano z hlediska Intelu souhlasím. Jinak co se týká ARM architektury, ta architektura je prostě tak čistá, že se tam chytají velmi dobře i optimalizátory kompilátorů. Takže třeba to co leze z MSVC kompilátoru pro ARM je velmi kvalitní - programoval jsem pro ARM i v asm, i v C/C++ a celkem nebyl problém. ARM architektura je prostě tak čistá a jednoznačná, že trikování tam zdaleka nemá zdaleka takovou váhu jako na x86 architektuře. To architektura 68K, na té ještě trochu víc trikovat jde, takže možná.
-
Ono také platí, že jen naprosté minimum assembleristů (odhadem tak 0,1% z těch co se asm zaklínajíú dokáže vyprodukovat kvalitnější a rychlejší kód, než dobře optimalizující C/C++ kompilátor.
Umím perfektně asm, dokonce jsem se jím nějaký čas živil, ale přesto cokoli můžu dělám v C++. Znám optimalizační triky a fígle, ale ty samé optimalizační triky zná i C++ kompilátor. A zaplaťpámbů za ty abstrakce v C++, velmi zrychlují vývoj, snižují počet chyb a přitom z toho leze velmi efektivní kód ve strojáku, který jak říkám nedokáže rychlostí provádění více, než 99% assembleristů překonat.
Vaše tvrzení, že kompilátor to udělá špatně jste ničím nepodložil - prostě lžete. Proč myslíte, že se operační systémy nepíší kompletně v asm? Odpověď je jednoduchá - protože by se tím nic nezískalo, jen ztratilo. Napíše se v asm jen nejnutnější jádra a pak tradá větší zbytek ve vyšším programovacím jazyce. Protože dnešní kompilátory plivou ven strojový kód, který je velmi dobrý. -
Zilog (neregistrovaný)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. -
Ale no tak, Vaše seběvědomí je trochu vysoko. Zkuste si to někdy, prosím. Jako člověk, který se assemblerem dlouhá léta živil vím co povídám. Přečtěte si optimalizační manuály k procesorům a zjistíte, že je to obrovská dřina zoptimalizovat něco na rychlost, a že k tomu potřebujete asi tak 1000x více znalostí, než jen k tomu, abyste psal v asm.
Problém asm je ten, že sice můžete trikovat, ale schopnosti lidského mozku jsou poněkud omezené a těžko třeba udržíte v paměti všechny detaily řekněme 200 KB zdrojáku v asm. Pro optimalizátor C++ ale tohle není vůbec problém a on dokáže trikovat na obrovském množství kódu, které jsou nad lidské možnosti.
Já znovu říkám, že HLL kompilátory jsou velmi velmi kvalitní a znovu říkám, že jsem psal několik let v asm ty nejnáčnočnější věci, kde záleželo na každé nanosekundě. Dělal jsem ve firmě, kde byli ty nejlepší assembleristé a velmi se divili jaká kvalita leze z dobrého kompilátoru.
Dnes je jen velmi málo oblastí, kde by se vůbec vyplatilo používat asm, protože za poslední léta se kompilátory tak zkvalitnili, že to co leze z KVALITNÍHO C/C++ kompilátoru (tedy tím vylučuji gcc, které tu kvalitu nemá, aby bylo jasno) se dá klidně používat jako učebnice asm kódu. -
Zilog (neregistrovaný)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. -
Můžete mít samozřejmě kritičtější názor. Já jen z odstupu vidím, že Váš názor jsou klapky na očích.
Proč by kompilátor nedokázal aplikovat jiné fígly kromě těch nejprimitivnějších? Na to jste přišel jak? To je totiž lež jako věž. Právě, že kompilátor dokáže aplikovat i velmi fikané fígly - a hlavně je dokáže aplikovat na tak rozsáhlém kousku kódu, které jsou zcela mimo možnosti lidského mozku. Vaše kecy o redundancích jsou jen kecy s prominutím - sice chápu, že jste mohl tento dojem získat z nekvalitního C++ kompilátoru (např. z gcc), ale jsou to jen lži.
No a co, že vytvoření optimálního sledu instrukcí není jednoduše zvládnutelný problém? On taky optimalizátor kvalitního C++ kompilátoru je velmi složitá záležitost, ale není důvod proč by to neměl zvládnout.
Result: Pro kvalitní C++ kompilátor není optimalizace vnitřní smyčky potřeba - spíše naopak. Tím, že to zoptimalizujete třeba v asm pro vnitřní smyčku berete C++ optimalizátoru možnost optimalizovat v daleko širším kontextu, než je jen ta vnitřní smyčka. -
Zilog (neregistrovaný)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'
:>>> -
Zilog (neregistrovaný)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? :) -
Vážený pane, většina lidí nepotřebuje výstupy v hexa. Věřte mi, že většina lidí by se zděsila, kdyby jim třeba na docházkovém zařízení vyskočil údaj v hexa. Nezažil jsem žádné lidmi používané zařízení, kde by někdo kdy chtěl hexa výstup. To jen abych Vás vrátil do reálu.
A i kdyby to bylo potřeba, tak bych klidně použil printf, nebo jinou funkci, protože jak už jsem psal, rychlost výpisu dělá stejně operační systém, nebo vypisovací rutina, pokud jste u zařízení bez operačního systému, a ta rutina je vždy mnohem pomalejší, než nějaké printf. Víte Vy vůbec, co všechno udělá kernel, než vypíše nějakou hodnotu? Jestli ne, tak Vás ujišťuji, že toho není málo. -
Zilog (neregistrovaný)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. -
Ale jasně, že printf je docela složitá věc. Otázkou je, jestli to někoho trápí. Protože stále není nejpomalejší v tom řetězci výpisu.
Dobrá, z libc se z ní uklohní řetězec. Ten se práskne do stdout - tedy z hlediska kernelu do souboru. Pak se zavolá API systému a ten musí přepnout do systémového režimu (tisíce instrukcí strojového kódu). V systémovém režimu se po shlédnutí systémových tabulek předá požadavek příslušnému ovladači, ten cosi udělá - třeba zabufferuje, pokud je to skutečný soubor, nebo přenese řetězec přes terminál, nebo předá emulátoru terminálu, který za pomoci složitých grafických funkcí jej příslušným fontem vykreslí - prostě dle situace. Pak se provede návrat ze systémového režimu (další tisíce instrukcí) a vrátí se řízení libc. A to jsem ještě zapomněl na překlad paměti a další drobnosti, kterými zde nebudu zatěžovat. -
Zilog (neregistrovaný)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 -
No, takový výstup do znakového zařízení třeba není bufferován vůbec. Takže půjdete do všech těch režií systémů po každém printf.
Výstup na znakový terminál stylu VGA je rychlovka, stejně tak jako na COM port, ale není dnes už moc častý. Nicméně ani tak se nevyhnete veškeré té režii kolem volání systému a dalším věcem.
Překlad paměti je transparentní, akorát, že se musí stránkování přepnout, takže TLB se stejně vysype, ale to jen tak mimochodem.
Jinak taktéž upozorňuji, že jsou i jiné architektury, než x86 a PC.
Jinak dnes už tady nebudu, takže mi to můžete nandat a já Vám nebudu protiargumentovat. Nashle. -
BLEK. (neregistrovaný)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. -
Guru C++ (neregistrovaný)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. -
Clock (neregistrovaný)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. -
BLEK. (neregistrovaný)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. -
Guru C++ (neregistrovaný)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. -
BLEK. (neregistrovaný)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). -
Guru C++ (neregistrovaný)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. -
Zilog (neregistrovaný)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... -
Ale nikoli, i neportabilní operační systémy se píší ve vyšším programovacím jazyce. Je to proto, že asm tak nic moc nepřináší. Není dnes problém vkládat v případě potřeby kusy asm do vyšších programovacích jazyků a tak bohatě stačí, když operační systém obsahuje méně, než 1% asm.
Jinak Vás zcela ujišťuji, že operační systém psaný ve vyšším jazyce bude vždy kvalitnější, než v asm. Schválně, kolik znáte použitelných operačních systémů psaných v asm? Já osobně ani jeden (i když samozřejmě někde hodně vzadu mohou existovat) a to o něčem také svědčí.
Jinak Vás ujišťuji, že běžný projekt (třeba operační systém) o desítkách miliónech řádků zcela přirozeně bude obsahovat i kusy kódu menší kvality, prostě jsme jenom lidi. Jinak co Vám brání se přihlásit mezi vývojáře kernelu a začít vylepšovat? -
Zilog (neregistrovaný)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. -
Ano a Váš vlastní Linux má všechny drivery psané v asm na všechen dnešní existující hw. :-)
Zkrátka pane, který dnes _používaný_ operační systém je psán plně v asm? Žádný. To je důkaz a ten o něčem svědčí. Zbytek jsou kecy.
Jinak velikost neříká nic o rychlosti. Klidně 5x rozsáhlejší rutina v asm může být značně rychlejší, než 5x kratší rutina. To je totiž o tom, že rychlost v asm je úplně někde jinde, než o velikosti.
Jinak zajímavé je, že spousta lidí zvládající asm a umějící malovat jako Picasso - obrazně řečeno, velmi ráda volí vyšší jazyk. Znovu připomínám, mám zkušenosti s nejlepšími světovými assembleristy, kteří se tím živí a znám realitu. Ono totiž se dá velmi dobře malovat nádherně i s vyšším jazykem. Je to o osobnosti programátora a o jeho znalostech, schopnostech a zkušenostech - zdaleka ne jen o jazyku. -
Zilog (neregistrovaný)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 :(. -
Problém je, že nevíte co mluvíte. Třeba maximální rychlost nikdy nevzniká u nejkratšího kódu. Tudíž vždycky si musíte zvolit co chcete. Chcete kratší kód? Ok, smiřte se s tím že poběží několikanásobně pomaleji. Chcete rychlý kód? Ano, ale smiřte se s tím, že bude mít několikanásobnou velikost. Jinak to nejde.
Zbytek jsou jak říkám jen Vaše prázdné, ničím nepodložené řeči. Prostě milujete asm, nesnášíte vyšší jazyky. Ok, je to Vaše volba, ale proč to neřeknete rovnou? Proč namísto toho plníte tuto doskusi podřadnými vylhanými argumenty? Jděte si někam programovat prostě ve svém asm a nikdo Vám v tom nebude bránit. -
anonymnímate pravdu - rychlejsi varianta vypsani textu bude mit 50 bajtu, zatimco ta mensi bude mit 30 bajtu, ale bude rychlejsi.
nehovorite ale doufam o tom, ze 4kB spustitelne soubory jsou jiste velice pomale, narozdil od tech XXXkB sracek, co jsou tak strasne rychle? to bylo mysleno doufam jen jako vtip... -
Varianta týkající se vypsání textu má jednu drobnost - stejně jakýkoli výpis jde přes API operačního systému, kde to projde desítkami tisíc instrukcí ve strojovém kódu, než to skutečně něco vypíše. Takže rychlost výpisu textu je stejně prakticky rovná rychlosti implmentace výpisu v operačním systému - a samotný kód už to moc neovlivní.
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.
Jinak lidi, kteří skutečně nějaký použitelný program v asm napsali většinou vědí, jak to je s asm a vyššími jazyky. Jen tak pro informaci, používal jsem třeba na Windows resource editor kompletně psaný v asm (binárka 186 KB), nebo debugger GoDebug (také stovky KB, nevím přesně). -
Biktop (neregistrovaný)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é.
-
Ne, nejsem bůhvíjak dobrý assemblerista. A ani to o sobě netvrdím.
Ale na druhou stranu se mi nelíbí, když někdo lže o C++ - nejsměšnější na tom je, že celé C++ bylo a je vyvíjeno s ohledem na maximální rychlost. Spousta věcí v C++ by mohla být udělaná lépe, ale tvůrci prostě dali vždy přednost rychlosti.
Totéž u Fortranu. Když IBM vyvíjelo první kompilátor Fortranu, dalo si velmi záležet na optimalizaci, protože jak tvrdilo "nikdo by přeci nepoužíval nějaký Fortran, kdyby z něho lezlo něco horší, než se dá napsat v asm".
Ale abych Vás uklidnil, v asm lze VŽDY napsat lepší kód, než co vyjde z (dobře optimalizujícího) kompilátoru. Bohužel tato možnost prakticky na 99,999% je jenom teoretická.
Ano, existují vynikající assmebleristi, kteří zvládnou o nějaké procento rychlejší kód napsat v asm, ale jednak je jich málo a vyvažují se zlatem a jednak to napíšou třeba za 10000x násobek času co běžný člověk ve vyšším jazyce. -
Zilog (neregistrovaný)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 -
Jiri Bartos (neregistrovaný)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! -
Zilog (neregistrovaný)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. -
BLEK. (neregistrovaný)"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. -
Biktop (neregistrovaný)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é.
-
Zilog (neregistrovaný)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 :). -
ad 1) odstavec - to je bohužel u x86 a x64 kódu pravda - maximální rychlost nerovná se nejkratší kód (pořád se bavím o něčem užitečném, ne o ukázkách na 3 instrukce). to už je vlastnost instrukční sady. třeba u ARM procesoru je to jinak, nebo u Power PC, ale předpokládám, že o tom nemluvíme
ad 2) odstavec. Produkt kompilátoru nebude kratší - už proto že má v sobě univerzální startovací rutiny. ale s rychlostí určitě bude zdatným soupeřem asm programům. (znovu říkám, bavím se o reálných užitečných programech, ne o něčem na 3 instrukce). Ale nijak jsem si nevšimnul, že by někomu pár desítek KB navíc v délce programu vadilo.
Ale no tak - lidskou nápaditost beru, ale optimalizátory jí tvrdě šlapou na paty. Jestli si chcete skutečně užít lidské nápadistosti - jděte do umění, malujte, tvořte hudbu, tančete - to skutečně nic strojového nenahradí. Ale cokoli co se týká binárních povalů - tam jsou sw stroje čím dál lepší a prostor pro lidskou nápadistost čím dál zkracují. -
Zilog (neregistrovaný)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 :) -
Ale to není pravda, že méně instrukcí stihne dříve. Dne už procesory vůbec nevykonávají instrkce, překládají si je do mikro, nebo nano instrukcí. Na některé instrukce výrobci procesorů kašlou a procesor je vykonává hrozně pomalu - a neoptimalizovaně, zatímco některé jiné instrukce jsou v procesoru perfektně optimalizovány. Kromě toho se leccos v procesoru dělá paralelně.
V zásadě problém asm je i ten, že pomalu pro každý model procesoru je potřeba rychlou rutinu napsat mírně jinak. To co nejrychlejší na modelu A není nejrychlejší na modelu B apod..
Z hlediska tří instrukcí jsem chtěl říct, že je to k ničemu. Nikdo nepoužívá program na 3 instrukce. Jinak já Vás opravím, z hlediska asm optimalizace jsem nehodil flintu do žita, ale pro mě účel světí prostředky. Souhlasím, že čistě teoreticky má být program v asm nejrychlejší, ale čistě prakticky tomu tak bývá jen zřídkakdy.
Ekonomicky prostě asm proti vyšším jazykům prohrává - a bohužel ani rychlostně nemá moc co nabídnout oproti řekněme Fortranu, C, C++, atd.. Stále ještě existují případy, kdy je asm občas potřeba, ale je jich mizivé množství. Co nadělám, takový je život. -
Zilog (neregistrovaný)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... -
To není pravda, že méne instrukcí se stihne dříve. Jak píšete, některé výrobce zprznil. I když nebudeme uvažovat ty, tak některé proudy instrukcí dokáže procesor provádět paralelně, jiné jen postupně. Kromě toho záleží i na dalších situacích. Napsat nejrychlejší rutinu znamená dost velké know how, které je zcela mimo možnosti této diskuse. Na x86 a x64 mohu prohlásit, že nejkratší rutina snad nikdy není nejrychlejší (pomíjím ukázky na 3 instrukce, beru něco normální problém řešícího).
Jinak s tím, že vývoj v IT vede k vytváření méně efektivních apliakcí souhlasím - je to prostě ekonomika. Ale C++ je to poslední, co by za to mohlo, protože v něm vznikají ještě docela efektivní věci. Ale máte tu Javu, .NET, Python, Ruby, atd..
Kromě toho jsou dnešní aplikace plné dost pomalých protokolů - XML, SOAP, atd..
Ale to je o ekonomice a tu já celkem chápu. -
Zilog (neregistrovaný)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. -
BLEK. (neregistrovaný)"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. -
Guru C++ (neregistrovaný)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... -
Marek Pavlu (neregistrovaný)//To u vyssich jazyku neplati, protoze moznosti, jak ovlivnit
//vyslednykod, jsou velmi omezene...
Pokud prave rozumite tomu, jak se objekty vyrabi nad asm, tak prave mate moznost vhodnym objektovym popisem cinnosti dosahnout dosti rozmanitych vysledku vzhledem k optimalizaci...
MP -
Guru C++ (neregistrovaný)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. -
Marek Pavlu (neregistrovaný)Jezisi a Maria, Vy mate asi nejaky potize s frikulinama, ci co? :).
Ale vazne, nejzu ani specialista ani lama, delal jsem v asembleru deset let dokonce i na tom ZILOGU!
Pak i na jinych jako PIC a eZ8.
Teprve pak jsem pokracoval s C, C++ a dalsimi jazyky, takze se nepovazuji za frikulina, ktery jen v zachvatu hormonu presel na C++...
Navic uz na frikulina ani nemam roky, ale presto se drzim vyssich jazyku.
Osobne Vas tipuji na jednoho z tech, kdo z frustrace ze slozitejsich pravdiel objektoveho jazyka utekli zpet k asm.
Osobne uz v ASM nedelam NIC, prestalo mne bavit delat porad to samy dokola jak blbec. V ramci malych procesoru s ASM je kod nepouzitelny za necelych pet let, protoze proste neni zelezo, je neco novejsiho nebo vyhodnejsi uziti s jinym procesorem jinyho vyobce a clovek najednou zjisti, ze je v riti i z botickama:(.
Kdezto naopak dneska uz neni snad vyrobce procesoru, ktery by nepodporoval vyssi jazyk a primarne to vede na C a asi Vam uberu naladu, protoze se objevuji uz i C++:).
A chcete mi tvrdit, ze komunita okolo malych provesoru ma nedostatecny vedomostni background? Prosiiiim, to asi ne, ze?
Osobne sleduji konfery, kde se resi prave veci okolo malych procesoru a mikrokontroleru a za poslednich pet let konvertovali k C od ASM mnozi:).
MP -
Guru C++ (neregistrovaný)Ne, jen s lidmi, co sami sobe praci ulehcuji (neznaji OOP a pouzivaji ho, protoze doufaji, ze je to konecne jazyk, ktery za ne vyresi vlastni myslenkovou impotenci) - a nekdo pak musi zajistit, aby to doopravdy fungovalo. Kompilator to NENI, ten zajisti leda to, ze je vysledek 2x tak dlouhy a 2x tak pomaly, nez by byt mohl.
Omlouvam se za zlucovitou demagogii, ale miska vah se nebezpecne naklani na stranu obhajcu jazyku, co abstrahuji od faktu, jak jednotlive platformy ve skutecnosti funguji - je to jen o podrezavani si vetve, na ktere programator sedi. Asi jako kdyby pradlena jednoho dne prohlasila, ze uz si nebude machat ruce ve vode, ze bude pouzivat jen prasek, protoze ji vzdy tak krasne pomohl a vsude je na nej reklama.
pc
