abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
dnes 16:22 | Nová verze

Byla vydána verze 2.2 svobodné federalizované platformy pro sledování a sdílení videí, alternativy YouTube s podporou P2P, PeerTube (Wikipedie). Přehled novinek i s náhledy v oficiálním oznámení. Přispět lze na vývoj verze 3. V plánu je například podpora živého přenosu (live streaming). Za vývojem PeerTube stojí nezisková organizace Framasoft snažící se mimo jiné nahradit svými svobodnými Frama službami služby společnosti Google (De-google-ify Internet). Bohužel ale musí některé své služby omezovat.

Ladislav Hagara | Komentářů: 0
dnes 07:00 | Komunita

Lenovo oznámilo, že bude certifikovat všechny své pracovní stanice řady ThinkStation a ThinkPad P pro Linux, konkrétně pro linuxové distribuce Red Hat Enterprise Linux a Ubuntu LTS. Doteď byly certifikovány pouze konkrétní modely.

Ladislav Hagara | Komentářů: 3
dnes 00:44 | Nová verze

Oficiálně byl vydán Devuan Beowulf 3.0.0. Přehled novinek v poznámkách k vydání. Kódové jméno Beowulf je podle planetky s katalogovým číslem 38086. Příští verze 4.0.0 bude Chimaera. Devuan (Wikipedie) je fork Debianu bez systemd.

Ladislav Hagara | Komentářů: 0
dnes 00:11 | Nová verze

Byla vydána verze 20.04 linuxové distribuce Greenie (Wikipedie). Nově s desktopovým prostředím KDE.

Ladislav Hagara | Komentářů: 2
včera 19:11 | Nová verze

Byla vydána nová verze 4.7 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl aktualizován na verzi 9.5. Thunderbird na verzi 68.8.0. Opraveno bylo několik bezpečnostních chyb.

Ladislav Hagara | Komentářů: 0
včera 16:22 | Nová verze

Byl vydán Mozilla Firefox 77.0. Přehled novinek v poznámkách k vydání a na stránce věnované vývojářům. Zmínit lze novou stránku "about:certificate". Řešeny jsou také bezpečnostní chyby. Nejnovější Firefox je již k dispozici také na Flathubu.

Ladislav Hagara | Komentářů: 0
včera 07:00 | Zajímavý článek

Raphaël Hertzog oznámil aktualizaci The Debian Administrator's Handbooku pro Debian 10 Buster. Vedle papírové verze a ebooku je k dispozici také online.

Ladislav Hagara | Komentářů: 0
1.6. 23:33 | IT novinky

Poslanecká sněmovna bude projednávat vládní návrh novely zákona č. 289/2005 Sb., o Vojenském zpravodajství, který by právě Vojenskému zpravodajství dal možnost sledovat síťový provoz a provádět aktivní zásahy v kyberprostoru. Okolnostmi předložení novely a kontroverzí v jejím obsahu rozebírá např. Jan Cibulka na iRozhlasu, a to včetně kritizované nedostatečné kontroly.

Fluttershy, yay! | Komentářů: 2
1.6. 22:00 | Nová verze

Byla vydána verze 2.27.0 distribuovaného systému správy verzí Git. Přispělo 71 vývojářů, z toho 19 nových. Přehled novinek v poznámkách k vydání.

Ladislav Hagara | Komentářů: 0
1.6. 16:22 | Upozornění

V rámci projektu ADAM (Advanced DNS Analytics and Measurements) uvádí Laboratoře CZ.NIC ve spolupráci s CSIRT.CZ do produkčního provozu nástroj DNS crawler. Záměrem je periodicky procházet všechny domény 2. úrovně pod TLD .cz, získávat o nich různá veřejně dostupná data a ta pak dále zpracovávat. I když to jeho jméno přímo nenapovídá, DNS crawler bude kromě sběru dat z DNS také komunikovat s webovým a e-mailovým serverem každé domény.

Ladislav Hagara | Komentářů: 10
Používáte některé open-source řešení [protokol] pro šifrovaný instant messaging?
 (38%)
 (17%)
 (7%)
 (15%)
 (10%)
 (7%)
 (17%)
 (18%)
Celkem 60 hlasů
 Komentářů: 1, poslední dnes 16:33
Rozcestník
Štítky: není přiřazen žádný štítek


Vložit další komentář
22.7.2009 20:03 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: Výjimečně drahé výjimky (C++)
clovece, jak tak ctu tvoje blogspoty, zacinam byl cim dal tim vic rad, ze pouzivam C a ne C++ ;-]
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
Jardík avatar 22.7.2009 21:33 Jardík | skóre: 40 | blog: jarda_bloguje
Rozbalit Rozbalit vše Re: Výjimečně drahé výjimky (C++)
Si ty dementní výjimky vypnu, když je nechci ...
Věřím v jednoho Boha.
Marek Bernát avatar 22.7.2009 22:27 Marek Bernát | skóre: 17 | blog: Arcadia
Rozbalit Rozbalit vše Re: Výjimečně drahé výjimky (C++)

Kiež by sa všetky dementné veci dali vypnúť :-)

physics.stackexchange.com -- Q&A stránky o fyzike v štýle StackOverflow.
23.7.2009 08:56 JB
Rozbalit Rozbalit vše Re: Výjimečně drahé výjimky (C++)

Kdyz uz nekdo vyjimku v programu generuje, tak  ji nelze vypnout, ale zachytit.Nebo cekat, ze ji nekdo "zvenku" zachyti za nas.

 

 

 

Marek Bernát avatar 23.7.2009 10:04 Marek Bernát | skóre: 17 | blog: Arcadia
Rozbalit Rozbalit vše Re: Výjimečně drahé výjimky (C++)

Ledaže by sa kompilátoru dalo pomocou nejakého flagu povedať, aby všetok kód pre výnimky ignoroval ;-)

physics.stackexchange.com -- Q&A stránky o fyzike v štýle StackOverflow.
limit_false avatar 23.7.2009 00:49 limit_false | skóre: 23 | blog: limit_false
Rozbalit Rozbalit vše Re: Výjimečně drahé výjimky (C++)

IMHO vubec nejde o jazyk, specialni situace nastanou, at je to C, C++, Java, Python nebo Erlang. Staci par milionu radek kodu, nekolik 3rd-party knihoven a ono to uz pak jde samo.

Specialne kdyz to pak dostanou do ruky uzivatele, to teprve koukame pri nejakem demu, jake psi kusy s tim delaji. Nevychazime z uzasu, ze to funguje a nepada ;-)

When people want prime order group, give them prime order group.
Jardík avatar 22.7.2009 21:30 Jardík | skóre: 40 | blog: jarda_bloguje
Rozbalit Rozbalit vše Re: Výjimečně drahé výjimky (C++)
A teď si vemte takový program v javě. Voláte tam třeba 1000x jednu metodu (např. zapisšdosouboru). Pokaždé! se kontrolují vstupní parametry, když jsou špatně, vyhodí se výjimka, když nejsou, tak se konečně uráčí zavolat opravdový zápis do souboru, kde operační systém či ovladač filesystému či co ještě jednou zkontrolujou vstupní parametry a pak to provedou. Proč? Pak to nemá být pomalý. Např. swing je tím prolezlej od shora dolů. Nebo takový Gtk#, zase se jak u dementů kontroluje každá blbost, než se ta funkce zavolá. Ještě navíc je tam samý "maršálování" stringů na nativní a zpět, je neustále alokována/dealokována další paměť znovu a znovu a nakonec jsou z toho pomalý šmejďárny typu Netbeans, Eclipse, Monodevelop a jánevímcoještě.
Věřím v jednoho Boha.
22.7.2009 22:49 Miloslav Ponkrác | blog: miloslavponkrac
Rozbalit Rozbalit vše Re: Výjimečně drahé výjimky (C++)

Výjimky nejsou tak pomalé. To je celý vtip.

22.7.2009 23:29 Ladicek | skóre: 28 | blog: variace | Havlíčkův brod
Rozbalit Rozbalit vše Re: Výjimečně drahé výjimky (C++)
Pokaždé! se kontrolují vstupní parametry
Slyšel jsi někdy o bezpečnosti, robustnosti, spolehlivosti a strukturovaném programování? Kontrola chybových stavů je jedním ze základních stavebních kamenů kvalitního softwaru, a jestli jí přisuzuješ řádový výkonnostní propad, pak ti doporučuju vrátit maturitu a nechat si na základní škole detailně vysvětlit význam slova výjimka.

Mimochodem, kdysi jsem kdesi zaslechl, že třeba kontrola mezí polí je na x86 jedna instrukce procesoru. To jistě vyrábí takový overhead, o kterém mluvíš? :-)
Ještě na tom nejsem tak špatně, abych četl Viewegha.
Jardík avatar 23.7.2009 01:59 Jardík | skóre: 40 | blog: jarda_bloguje
Rozbalit Rozbalit vše Re: Výjimečně drahé výjimky (C++)
Pořád nechápu, proč to kontroluje java ... vždyť to kontroluje systém ještě jednou po ní. Ať se snaží o výjimku, až systém vyplivne nepovedlo se a nastaví errno. Rozhodně je míň instrukcí
if (!zapiš)
{
  vyhoď výjimku
}
než
if (size <= 0)
{
  vyplivniVýjimku
}

if (data == null)
{
  vyplivniVýjimku
}

if (data.length < size)
{
  vyplivniVýjimku
}

if (!zapiš)
{
  vyhoď výjimku
}
Věřím v jednoho Boha.
Integral avatar 23.7.2009 02:11 Integral | blog: devnull
Rozbalit Rozbalit vše Re: Výjimečně drahé výjimky (C++)
no, sice je to min instrukci, ale vysoka rezie je hlavne v kodu "vyhod vyjimku". takove to testovani (data == null; apod.) je vcelku rychle, takze imho oba dva kody jsou na tom s vykonem hodne podobne...

23.7.2009 07:28 Milan
Rozbalit Rozbalit vše Re: Výjimečně drahé výjimky (C++)

Systemove volani (open, write, ...) je drahe. Oproti tomu testovani na data.length je nepatrne...

23.7.2009 08:38 Ladicek | skóre: 28 | blog: variace | Havlíčkův brod
Rozbalit Rozbalit vše Re: Výjimečně drahé výjimky (C++)
No, víš, to je taková zásada, že software nevěří tomu, co dostane na vstupu, vždycky si to zkontroluje, a pokud něco není v pořádku, okamžitě selže (nebo něco vhodnějšího, pokud lze). To není výsada Javy, ale defenzivního programování jako takového.

Uvnitř důvěryhodného kódu se pak vyplatí používat asserty, ty se dají odstranit z výsledného kódu podle potřeby.
Ještě na tom nejsem tak špatně, abych četl Viewegha.
23.7.2009 11:38 Miloslav Ponkrác | blog: miloslavponkrac
Rozbalit Rozbalit vše Re: Výjimečně drahé výjimky (C++)

Pořád nechápu, proč to kontroluje java ... vždyť to kontroluje systém ještě jednou po ní. Ať se snaží o výjimku, až systém vyplivne nepovedlo se a nastaví errno. Rozhodně je míň instrukc

Až na to, že systémové volání potřebuje jenom na přechod do kernel módu přes tisíc strojových instrukcí. A na návrat zpět rovněž.

Takže otestovat to a vyhnout se případnému systémovému volání ušetří tisícovky instrukcí.

Vy si vůbec neuvědomujete, jak moc drahé je volná API systému. Proto také Java, ani C/C++ nevolají funkcí zapiš systémové volání. Většina volání funkcí zapiš ve skutečnosti jen uloží data do bufferu a systémové volání provede až v případě, že je potřeba zapsat dostatečně velký blok. Tudíž stejně to musí Java, nebo C/C++ zkontrolovat.

Zkuste si sám volat přímo API systému pro krátké zápisy a budete překvapen jak moc program zpomalíte, zvláště když budete zapisovat třeba po jednom bajtu.

Druhá věc je, že testovat vstupní parametry je povinnost a nevěřit ničemu rovněž.

23.7.2009 13:05 R
Rozbalit Rozbalit vše Re: Výjimečně drahé výjimky (C++)
Aky zmysel ma vyhybat sa systemovemu volaniu pri zapise do suboru? Alebo sa benchmarky robia tak, ze sa mera rychlost volania zapisu do suboru s nezmyselnymi parametrami?
23.7.2009 13:45 Miloslav Ponkrác | blog: miloslavponkrac
Rozbalit Rozbalit vše Re: Výjimečně drahé výjimky (C++)

Každé systémové volání je drahé a sežere spoustu času. Systémová část běhu procesu je také drahá, kernel ho musí ošetřovat za úplně jiných podmínek a s úplně jinými parametry, než uživatelskou část běhu procesu. A samotné přepnutí mezi uživatelskou a systémovou částí běhu tam i zpět také není zadarmo.

Vezměte si obyčejnou libc a uvidíte, že se tam většina funkcí vyhýbá volání systému co to jenom jde, jako kdyby to bylo něco prašivého.

Třeba fread a fwrite bufferuje a snaží se minimalizovat počet volání systému pro čtení a zápis. Ve skutečnosti jen menšina volání funkce fread, nebo fwrite způsobí také volání operačního systému, naprostá většina se většinou vyřídí jen uvnitř v bufferech.

Nebo malloc / free také jede jako buffer. Nevolá funkce operačního systému na přidělení paměti, pokud je to jenom trochu možné. Namísto toho si od systému nechá přidělit větší blok paměti (tedy jedno volání systému) a ten pak drobí a kouskuje jen aby nemusel systém volat.

Systémové volání je prostě drahé, drahé, drahé.

23.7.2009 13:56 Miloslav Ponkrác | blog: miloslavponkrac
Rozbalit Rozbalit vše Re: Výjimečně drahé výjimky (C++)

Ještě je třeba dodat, že většina operačních systému penalizuje procesy, které stráví příliš mnoho času v systémové části běhu. A do toho se počítají samozřejmě i hojná volání systémových funkcí jenom proto, co si proces mohl otestovat sám daleko levněji.

Pokud strávíte mnoho času v systémovém běhu, pak hodně operačních systémů procesu myšleně snižuje prioritu a plánovač ho odsouvá do pozadí.

23.7.2009 14:26 Ivan
Rozbalit Rozbalit vše Re: Výjimečně drahé výjimky (C++)

A co byste rekl na takovyhle priklad: mam vlakno ktere je dedikovane na to aby cekalo v poll-u, kdyz jsou k dispozici nejaka data na nejakem fd tak poslete zpravu. Cele je to hezky zapouzdrene v knihovne glib. Shodou okolnosti se stane ze jedno z TCP spojeni protistrana uzavre. Nejake jine vlakno to odchyti a osetri. Vlakno ktere ceka v pollu se rozebehne - poll skoncil s chybou(POLLNVAL invalid fd). A co ted budete delat?  Samozrejme ze mate errno - jste uvnitr knihovny(glib) a nevite nic o nadrazene aplikaci(evolution). Ted mate vyber:

1. Vratit chybu, ale API vam to neumoznuje

2. Vyhodit vyjimku a osetrit ji ve vyssi vrtstve

3. Precist 0 bajtu z fd stderr a zavolat poll jeste jednou(ten samorzejme okamzite skonci s chybou).

Ivan

 

PS: c je spravne.

 

 

23.7.2009 15:03 Miloslav Ponkrác | blog: miloslavponkrac
Rozbalit Rozbalit vše Re: Výjimečně drahé výjimky (C++)

Já myslím, že

a) možností je daleko více, než 3

b) správná odpověď závisí na správném návrhu aplikace

c) já jsem neřekl, že systémové volání je fuj, jen, že by se nemělo volat zbytečně Volat systém je samozřejmě potřeba. Není třeba všechno házet do extrému. V programování můžete dělat cokoli, když víte co děláte, jaké důsledky bude mít to co děláte, a řešení splňuje vše, co je potřeba.

V zásadě v programování existuje spousta škodlivých dogmat, které je dobré, aby se jich drželi začátečníci (neboť potřebují získat dobré návyky), ale později je třeba je opustit. Například zbytečná dogmata:

„goto je špatné“

„budu ďábelsky šetřit jednu pikosekundu (analogicky instrukci) a myslím si, že to má smysl“

„myslím ve strojáku a lžu sám sobě, že umím programovat ve vyšším programovacím jazyce (častý jev u Céčkarů)“

„teorie je zbytečná“

„jsem dobrý programátor, protože umím nazpaměť všechna volání knihoven i bez dokumentace (častá iluze u programátorů bez talentu)“

„ošetřování chyb návratovou hodnotou, nebo přes errno je efektivnější, než přes výjimky“

„když něco o programování říká známá osoba XY, která toho hodně naprogramovala, tak to musí být pravda (asi největší z omylů)“

a řada dalších

Přičemž některé z výše uvedených jsou za jistých okolností i pravdivé, ale za jiných okolností zcela mylné.

23.7.2009 21:26 eoj
Rozbalit Rozbalit vše Re: Výjimečně drahé výjimky (C++)
Často se vyplatí ověřit parametry a v případě špatných hodnot se vyhnout nesmyslnému systémovému volání. Potom ten systém toho až tolik nekontroluje a hlavně neví nic o javě a až v případě chyby dohledávat její příčiny už bývá pozdě, takže bývá lepší (a někdy nutné) to ohlídat předem.
23.7.2009 21:29 eoj
Rozbalit Rozbalit vše Re: Výjimečně drahé výjimky (C++)
A to co napsal pan Ponkrác o něco výše raději vůbec nečti, ten člověk vždycky kolem jedné rozumné věci napíše tolik blábolů až to hezké není (asi hodně čte, ale moc tomu nerozumí).
23.7.2009 21:30 eoj
Rozbalit Rozbalit vše Re: Výjimečně drahé výjimky (C++)
A to o něco níže jsou už skutečné perly. No, nezabili byste ho? :)
Jardík avatar 23.7.2009 22:15 Jardík | skóre: 40 | blog: jarda_bloguje
Rozbalit Rozbalit vše Re: Výjimečně drahé výjimky (C++)
Tak se to tu hezky rozjelo, koukám, co jsem zase vypustil do světa za sračku a to, že to bylo ve 2 ráno mě nezachrání :-)
Věřím v jednoho Boha.
25.7.2009 02:21 Andrej | skóre: 47 | blog: Republic of Mordor | Zürich
Rozbalit Rozbalit vše Re: Výjimečně drahé výjimky (C++)
Pořád nechápu, proč to kontroluje java ... vždyť to kontroluje systém ještě jednou po ní. Ať se snaží o výjimku, až systém vyplivne nepovedlo se a nastaví errno. Rozhodně je míň instrukcí

Java běží na cca 10 různých operačních systémech. Každý z nich se chová trochu odlišně. Java musí garantovat, že z pohledu aplikací bude chování virtuálního stroje všude stejné a že budou vynucována stejná omezení.

ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
23.7.2009 11:15 Sinuhet | skóre: 31
Rozbalit Rozbalit vše Re: Výjimečně drahé výjimky (C++)
Vzhledem k tomu, ze pristup k poli je take na jednu instrukci, tak nam z toho leze overhead minimalne 50 %, coz je docela dost.
23.7.2009 11:21 Ladicek | skóre: 28 | blog: variace | Havlíčkův brod
Rozbalit Rozbalit vše Re: Výjimečně drahé výjimky (C++)
Na počet instrukcí? Fakt děsivé :-) A to neuvažuju optimalizující překladače, které mohou leckteré kontroly vyhodit (třeba u toho přístupu k prvkům pole v cyklu to jde docela snadno).
Ještě na tom nejsem tak špatně, abych četl Viewegha.
23.7.2009 11:32 Miloslav Ponkrác | blog: miloslavponkrac
Rozbalit Rozbalit vše Re: Výjimečně drahé výjimky (C++)

Zase jeden co si myslí, že kompilátor musí do strojáku přeložit doslova vše co je ve zdrojáku. :-)

Zase jeden co si myslí, že počet instrukcí nějak určuje, jak rychlé to bude. :-)

Oba předpoklady jsou totální bludy.

Ještě Vám prozradím jedno sladké tajemství. Test na null se dá udělat zcela bez overheadu a bez jakékoli instrukce právě pomocí výjimek. Takhle testuje třeba kernel Windows, aby to bylo rychlejší. Prostě na null adrese není platná stránka a kdykoli procesor najde instrukci, která míří na null adresu, pak není třeba nic testovat. Prostě na null adresu přistoupí, procesor to zjistí a vyhodí výjimku procesoru (hw přerušení). Aplikace, nebo kernel jen výjimku chytne a rozluští odkud to bylo. Máte test na null a nulovým overheadem bez jakékoli instrukce.

Test na hranici polí, nebo jiná čísla v mezi se dá udělat jedinou instrukcí bound. Žádné if nenásleduje, protože v případě mezí mimo rozsah procesor vyhodí výjimku (přerušení číslo 4) a opět viz předchozí odstavec.

Právě výjimky umožňují neuvěřitelně zefektivnit obsluhu chybových stavů. Dobře udělaný kód s výjimkami bude běžet výrazně rychleji, než kód, kde se testují chyby pomocí errno. Jenže to nepochopí nikdo, kdo s chybně myslí, že kompilátor je blbec, který otrocky překládá do strojáku. Kompilátor má dnes výkonnou optimalizační jednotku, která tvoří 99% kódu kompilátoru – a u některých kompilátorů je tak dobrá, že předstihne 999 assembleristů z tisíce. Pro jistotu: nemluvím o gcc.

xkucf03 avatar 23.7.2009 13:47 xkucf03 | skóre: 49 | blog: xkucf03
Rozbalit Rozbalit vše Re: Výjimečně drahé výjimky (C++)
a u některých kompilátorů je tak dobrá, že předstihne 999 assembleristů z tisíce.

To rád slyším :-)

nemluvím o gcc.

O čem tedy?

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
23.7.2009 14:02 Miloslav Ponkrác | blog: miloslavponkrac
Rozbalit Rozbalit vše Re: Výjimečně drahé výjimky (C++)

O Intelu, který je špičkou. Trochu o Microsoftu, který  je sice o hodně za Intelem, ale taky se to dá.

gcc byl špičkou před deseti a více lety. Ale mám pocit, že právě obrovská multiplatformovost působí, že není tolik času na to dotáhnout optimalizace do excelentního stavu.

Kdysi tomu také bránil použitý vnitřní model pro popis optimalizace, tuším že na řadu případů v dnešních strojáku trochu drhnul. Ale jak je to dnes netuším, protože detaily jsem přestal sledovat.

Neříkám, že gcc špatný kompilátor, jen na abclinuxu.cz to zdůrazňuji, protože je tu přehršel blogpostů, komentářů atd., na kterém je jasně vidět, že si lidé plotou C/C++ s gcc a mají pocit, že je to jedno a totéž. A když něco gcc udělá špatně, tak píšou „C/C++ je špatné“ namísto toho aby obvili open source projekt gcc. Takže někdy to zdůrazňuji přespříliš.

23.7.2009 14:37 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: Výjimečně drahé výjimky (C++)
O Intelu, který je špičkou. Trochu o Microsoftu, který je sice o hodně za Intelem, ale taky se to dá.
ma te nejake benchmarky, ktere to ukazuji? nebo jsou to zase nepotvrzene domenky?

moje zkusenost je prave opacna, tj. v pripade cisteho C GCC netrhne ICC prdel bez vetsi namahy. (a nezavisle mi to potvrdili i dalsi lidi)
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
23.7.2009 14:40 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: Výjimečně drahé výjimky (C++)
ma te -> mate; netrhne -> natrhne. (sakra, takhle brzo poranu bych nemel psat do diskuzi) ;-]
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
23.7.2009 15:10 Miloslav Ponkrác | blog: miloslavponkrac
Rozbalit Rozbalit vše Re: Výjimečně drahé výjimky (C++)

mate nejake benchmarky

nemám, respektive je nechci hledat

v pripade cisteho C GCC netrhne ICC prdel bez vetsi namahy

vimu natrhne prdel (z hlediska výkonu, tedy efektivity práce) bez větší námahy i nejblbější plain text editor (třeba notepad ve windows), pokud u něj sedí neschopný začátečník

pokud u vimu sedí profík, je to právě naopak

a stejné je to s icc. icc je profi nástroj, který velmi tvrdě reaguje na options a nastavení kompilátoru. daleko citlivěji a s daleko většími efekty a důsledky na optimalitu programu, než je tomu u gcc

defaultně se nepřekládá na max. optimalizaci, to se dělá až u release verze. defaultně se překládá na slušnou rychlost překladu

23.7.2009 15:30 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: Výjimečně drahé výjimky (C++)
a stejné je to s icc. icc je profi nástroj, který velmi tvrdě reaguje na options a nastavení kompilátoru. daleko citlivěji a s daleko většími efekty a důsledky na optimalitu programu, než je tomu u gcc
muzete to opet nejak dolozit?
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
23.7.2009 16:08 Miloslav Ponkrác | blog: miloslavponkrac
Rozbalit Rozbalit vše Re: Výjimečně drahé výjimky (C++)

Můžete si to bez problémů ověřit. Stejně jako naprosto každý člověk.

23.7.2009 17:17 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: Výjimečně drahé výjimky (C++)
prave, ze me zkusenosti vasim tvrzenim moc neodpovidaji... i.e., ICC ani ruzne prepinace nejak moc nepomohly...
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
23.7.2009 16:22 Sinuhet | skóre: 31
Rozbalit Rozbalit vše Re: Výjimečně drahé výjimky (C++)

Cece, pane Ponkraci, musim vam podekovat za ten uvod do prekladacu, assembleru a optimalizaci, doted jsem v tom tapal.

Nevim, proc mluvite o testu na null, zde se vede debata o kontrole rozsahu poli. A kdyz se trochu zamyslite, tak zjistite, ze v tomhle pripade je vam zachytavani pristupu na nepridelenou pamet k hovnu.

Kdyz uz tady chcete machrovat s boundem, tak byste mel vedet, ze vyvola preruseni cislo pet, nikoliv ctyri, a hlavne na starsich pentiich (nevim jak je to ted) to spotrebovalo vic cyklu, nez kdyz jste ta porovnani rozepsal na jednotlive instrukce, takze se v realu moc neuchytil.

Puvodni vyrok kolegy Ladicka byl samozrejme dementni v mnoha smerech, presto jsem se rozhodl sahodlouze nevysvetlovat co vsechno je v jeho predpokladu spatne a misto toho rozcechral jeho nevedomost o neco mene dementnim rozvinutim jeho uvahy.

23.7.2009 17:01 Ladicek | skóre: 28 | blog: variace | Havlíčkův brod
Rozbalit Rozbalit vše Re: Výjimečně drahé výjimky (C++)
Dneska se tu s kolegy smějeme nad XKCD, ale tohle mne rozesmálo ještě víc, děkuju :-D
Ještě na tom nejsem tak špatně, abych četl Viewegha.
23.7.2009 17:15 Sinuhet | skóre: 31
Rozbalit Rozbalit vše Re: Výjimečně drahé výjimky (C++)
No vidite, vy jste zase rozveselil me. Jestli se bavi i pan Ponkrac, tak kratka diskuze prinesla stesti trem lidem a to je v dnesni nelehke situaci myslim pozitivni vec.
xkucf03 avatar 23.7.2009 23:06 xkucf03 | skóre: 49 | blog: xkucf03
Rozbalit Rozbalit vše Java

A já se nemůžu dívat jak se tu hádáte a jdu radši psát svůj program v Javě :-D

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
23.7.2009 18:11 Miloslav Ponkrác | blog: miloslavponkrac
Rozbalit Rozbalit vše Re: Výjimečně drahé výjimky (C++)

Čéče, skvělý!!!

Konečně jsem se zasmál. Osvěžující styl!

Ohledně testu na null, zkuste trochu prohlédnout vlákno diskusí, než zareagujete. Viz úryvek zdrojáku, na který jsem reagoval:

if (size <= 0)
{
  vyplivniVýjimku
}

if (data == null)
{
  vyplivniVýjimku
}

Ohledně bound: Procesory se vyvíjejí a závislosti rychlostí rovněž. Například hodně staré procesory nebyly příliš náchylné na zpomalování při skocích. Dnešní procesory skoky dost penalizují, zejména pokud to neodhadnou. A možná byste mohl všimnout, že bound neobsahuje instrukci skoku, což zase hodně zvýhodňuje.

Procesorové cykly už jsou také nezajímavé, protože při paralelním zpracování, které je dnes v procesorech je pouhé číslo procesorových cyklů nezajímavých a fakticky téměř nic nevypovídajících. Paralelní zpracování je v procesor už trochu déle, mohl byste si toho všimnout.

Hlavním problémem bound, nicméně dříve fakticky nevadícím je fakt, že v 64 bitovém módu nejde použít.

 

26.7.2009 19:15 Sinuhet | skóre: 31
Rozbalit Rozbalit vše Re: Výjimečně drahé výjimky (C++)

Na to jste sice reagoval, ale ve vedlejsim vlakne, ktere sice vychazi ze stejneho rodice, ale resi uplne jiny problem. Takze bych poprosil, abyste nam v tom hezkem stromovem grafu nedelal bordel zavadenim cyklu.

Bound neobsahuje instrukci skoku? Muj ty Tondo kolenatej... A jak se asi procesor dostane na tu obsluhu preruseni? Teleportuje se tam pres dimenzi X?

No jestli jsou nezajimave cylkly, tak stejne pase jsou i instrukce a nechapu proc se tu prsite, ze bound je jedna instrukce. Mohl byste si vsimnout, ze procesor umi paralelne zpracovavat nejen nekolik mikro-ops z jedne komplexni instrukce, ale dokaze najednou vykonat mikro-ops z nekolika ruznych instrukci. Takze se vam muze stat, ze v jednom taktu se provedou dve pricteni a tri presuny v registrech, tj dohromady pet instrukci. Pocet cyklu nam rika, ze jeden mov neni pro procesor stejne narocny jako bound nebo fsincos.

No vidite, to jsem ani nevedel. Asi tu pomalost bound neopravili ani pozdeji a nikdo to nepouzival, az ji nakonec AMD z 64 bitu vyrazilo uplne.

hajma avatar 23.7.2009 00:14 hajma | skóre: 27 | blog: hajma | Říčany
Rozbalit Rozbalit vše Re: Výjimečně drahé výjimky (C++)

takze budeme radeji verit programatorum, ze vedi, co delaji? dekuji nechci, takovych je tak promile

21 promarněných znaků
multi avatar 7.8.2009 08:58 multi | skóre: 38 | blog: JaNejsemOdsut
Rozbalit Rozbalit vše Re: Výjimečně drahé výjimky (C++)
predpokladam, ze ty programujes pouze v assembleru, akorad nevim jestli je tvuj kood stejne tak vykony jako kdyby si to napsal treba v C nebo to proste jen zbastlis a seres na to
22.7.2009 22:48 Miloslav Ponkrác | blog: miloslavponkrac
Rozbalit Rozbalit vše Re: Výjimečně drahé výjimky (C++)

To je cena za multiplatformovost. Pokud napíšete kompilátor na x procesorových architektur, pak to zkrátka nebude tak efektivní.

1) Cena za výjimku je věc, která velmi závisí na kompilátoru. Rozdíly mohou být velmi drastické – používejte dobrý kompilátor.

2) Cena za výjimku je věc, která může záviset i na operačním systému. Například Windows mají podporu výjimek přímo v jádře a modrá obrazovka smrti není nic jiného, než informace o neobsloužené výjimce v kernelu. Pro znalého člověka je v ní obrovské množství informací.

3) Cena za výjimku je věc, kterou rapidně ovlivňuje programátor v obrovských mezích. Je rozdíl zda výjimku vyhodíte pointerem, referencí, objektem, i čím jí chytíte. Dále je obrovský rozdíl podle toho co typ výjimky obsahuje. I zde se dají měnit hodnoty o stovky procent v rychlosti.

4) Nešikovně udělané výjimky ve sdílených knihovnách musí postupovat podle nejpesimističtější varianty a tudíž jsou pomalé. Proto já v C++ projektu vše, co má házet výjimky zkompiluji svou verzí kompilátoru a stejnými optiony.

limit_false avatar 23.7.2009 00:39 limit_false | skóre: 23 | blog: limit_false
Rozbalit Rozbalit vše Re: Výjimečně drahé výjimky (C++)

1) Multiplaformnost je soucast specifikace dane aplikace (musi to bezet na ruznych distribucich Linuxu, taky na Win XP a Vista). Jenom pro porovnani, stejny testcase na Win XP prelozen s msvc 7.1 bezi stejne rychle jako ten na CentOS 5.

2) Tady je videt, ze rozdil dela glibc, nikoli kompilator (ten je stejnej).

3) Tyhle vyjimky se chytaji referenci, aby se predeslo zbytecnemu kopirovani. Vyjimka obsahuje kratky std::string (cca 20 znaku) a jeden int. V mereni profileru konstrukce a destrukce tech vyjimek padne pod 0.03 procenta.

4) Ta prvni veta mi vubec nedava smysl, muzete to nejak objasnit? "svou verzi kompilatoru" = vlastni kompilator/patchnuty kompilator?

When people want prime order group, give them prime order group.
23.7.2009 11:16 Miloslav Ponkrác | blog: miloslavponkrac
Rozbalit Rozbalit vše Re: Výjimečně drahé výjimky (C++)

Ad 1) a Ad 4) Cena za výjimku je tvrdě závislá na nastavení kompilátoru. Kompilátor se rozhoduje, jak moc pesimisticky bude ošetřovat výjimky. Je to podobné jako v databázích, v db existují 4 isolation levels podle toho jak moc chcete oddělit transakci od okolního světa. Pokud pojedete v db na nejvyšší stupeň, pak sice máte dokonalé transakce ale naprosto mizerný db výkon. A podobné je to s výjimkami.

Kompilátor se rozhoduje, jak moc důkladně musí výjimku ošetřovat. V nejpesimičtějším případě předpokládá, že každá strojová instrukce může vyhodit výjimku (tedy cokoli v kódu, kdekoli a nečekaně), dále tvrdě předpokládá mnoho seznamů pro ukončovací akce (důsledek RAII konceptu, rušení lokálních objektů), a tvrdě projíždí mnoho seznamů.

Každý (dobře optimalizující) kompilátor se snaží zbavit tvrdých předpokladů na nutnost ošetření výjimky a detekovat místa, kde to nemusí dělat tak tvrdě a bez následků. Jakmile mu do kódu zavedete nečekaný kód třetí strany (knihovnu, kterou nepřeložil sám ve stejném režimu a nemá od ní informace), pak musí předpokládat nejpesimičtější variantu, čímž výjimky saktra zpomalí.

Výše uvedené údaje jsem velmi zjednodušil až na hranici polopravdy, ale nechce se mi to celé vypisovat. Podstata je jasná.

limit_false avatar 23.7.2009 16:41 limit_false | skóre: 23 | blog: limit_false
Rozbalit Rozbalit vše Re: Výjimečně drahé výjimky (C++)

 

Kompilátor se rozhoduje, jak moc důkladně musí výjimku ošetřovat. V nejpesimičtějším případě předpokládá, že každá strojová instrukce může vyhodit výjimku (tedy cokoli v kódu, kdekoli a nečekaně) [...]

 

Každý (dobře optimalizující) kompilátor se snaží zbavit tvrdých předpokladů na nutnost ošetření výjimky a detekovat místa, kde to nemusí dělat tak tvrdě a bez následků. Jakmile mu do kódu zavedete nečekaný kód třetí strany (knihovnu, kterou nepřeložil sám ve stejném režimu a nemá od ní informace), pak musí předpokládat nejpesimičtější variantu, čímž výjimky saktra zpomalí.

Nepletete tady dohromady vyjimku procesoru s vyjimkou jazyka C++? Prekladac vi, kde ma na zasobniku udelat exception context (klauzule catch, nebo throw() specifikator).

Navic u C++ kompilator az na nejtrivialnejsi pripady nemuze vedet co vyhodi vyjimku (proto se ani specifikator throw() nejak moc nepouziva). Pri vyjimkach pres hranice knihoven je dulezite, aby kod v knihovne, ktera odchytava, mel dostatecne typove informace o vyjimce, co je hozena (musi byt viditelna pres hranice dll atd). V tomhle ale i tak problem nebyl (hazelo se pres "nase" knihovny skompilovane stejnym kompilatorem se stejnymi parametry). Viz komentar o binutils nize.

When people want prime order group, give them prime order group.
23.7.2009 18:47 Miloslav Ponkrác | blog: miloslavponkrac
Rozbalit Rozbalit vše Re: Výjimečně drahé výjimky (C++)

Moc nerozumím, jak moc to souvisí s tím co jsem napsal.

C++ výjimky jsou na úrovni C++ primitivní, ale implementačně musí kompilátor hodně pracovat. Pokud by udělal kompilátor opravdu vše na 100%, pak by byly výjimky hodně pomalé a datové struktury kolem výjimek by zabíraly podstatnou část programu. A tak to také bylo u prvních kompilátorů, a z nadávek na první implementace v této prehistorické době dodnes čerpají argumenty zarytí odpůrci výjimek.

Například Symbian se díky prvním neefektivním implementacím rozhodl výjimky nepoužít a nahradit je svým mechanismem zvaným „leaving“, což myslím spolu s dalšími náhradami mu láme vaz. Programování pro Symbian je nechutně složité a náhrady nemají (dnes) žádné opodstatnění.

Proto trvalo mnoho let a mnoho pokusů a nápadů, než se podařilo implementovat výjimky v C++ efektivně. Byla to dlouhá cesta. Na úrovni C++ syntaxe se vůbec nic nezměnilo, implementačně ve strojáku výsledného kódu je to zcela jinak.

Základním pravidlem C/C++ kompilátoru je: Nemusím vykonat co je ve zdrojáku, ale musím zajistit, aby výsledek celé akce byl stejný, jako je ve zdrojáku. U výjimek kompilátor hodně šidí – tedy optimalizuje, co vše lze vypustit. A není toho málo. Pokud by měl dělat vše na 100%, je to sice výrazně efektivnější, než v dřevních dobách, ale přeci jenom dost pomaleji, než když může optimalizovat.

Ostatně zajímavá je i ta typová informace. I ta musí mít nějakou implementaci. Pomíjím možnosti, že třída moje_vyjimka může mít v modulu A jinou definici a podobu, než v modulu B, to se totiž také může stát. A i typová implementace může být efektivní i neefektivní.

Ono se za výjimkami ve výsledném kódu děje hodně, mechanismus výjimek je hodně vysoká abstrakce z hlediska C++ zdrojáku. Navíc to musí být rychlé. A v pozadí se toho děje hodně moc, více, než se jeví z pohledu syntaxe C++.

23.7.2009 09:28 Michal Vyskočil | skóre: 60 | blog: miblog | Praha
Rozbalit Rozbalit vše Re: Výjimečně drahé výjimky (C++)
2) Cena za výjimku je věc, která může záviset i na operačním systému. Například Windows mají podporu výjimek přímo v jádře a modrá obrazovka smrti není nic jiného, než informace o neobsloužené výjimce v kernelu. Pro znalého člověka je v ní obrovské množství informací.
Moc tomu nerozumím, ale není SEH ve Windows něco trošku jiného? Nebo ses tím dí skutečně pracovat jako s normální C++ výjimkou?
When your hammer is C++, everything begins to look like a thumb.
23.7.2009 11:08 Miloslav Ponkrác | blog: miloslavponkrac
Rozbalit Rozbalit vše Re: Výjimečně drahé výjimky (C++)

V MSVC jsou všechny výjimky včetně C++ postaveny nad SEHem. SEH umožňuje propašovat libovolná data jako součást výjimky a MSVC toho patřičně využívá. Proto nezachycená výjimka v C++ programu je zachycena systémem Windows.

Implementačně v MSVC je C++ vnitřně postavena jako SEH výjimka.

SEH je univerzálnější, než C++ výjimka, proto se SEHem nedá pracovat jako s C++ výjimkou, ale C++ výjimka je postavena jako jedna z možností SEHu.

Ale třeba MSVC umožňuje automaticky SEH výjimku konvertovat na libovolnou C++ výjimku vlastní třídy, kterou si vyrobím.

Ovšem jak to dělá gcc na Windows netuším a vzhledem k nižší kvalitě kódu lezoucí na Windows z gcc jsem to moc nerozebíral.

23.7.2009 14:34 Michal Vyskočil | skóre: 60 | blog: miblog | Praha
Rozbalit Rozbalit vše Re: Výjimečně drahé výjimky (C++)
To dává smysl. Díky za odpověď.
When your hammer is C++, everything begins to look like a thumb.
limit_false avatar 23.7.2009 13:09 limit_false | skóre: 23 | blog: limit_false
Rozbalit Rozbalit vše Problém vyřešen!

Tak jsem udělal ještě jeden pokus. Klíčem byl update binutils.

Na CentOS 4 jsem nainstaloval binutils-2.18 (skompilované z vanilla zdrojáků). Původně jsem chtěl ověřit, jestli aplikace přeložena na CentOS 4 bude stejně pomalá jako ta předtím, ale ta samá binárka rychlá na CentOS 5 když použiju linker flag hash-style=both (glibc na CentOS 4 použije sysv-style .hash sekci ELF souborů, protože .gnu.hash nezná; glibc na CentOS 5 by pak použila gnu-style .gnu.hash sekci ELF souborů). Tak jsem celou aplikaci vycleanoval, opět přeložil a slinkoval.

Výsledek je překvapivě ještě lepší - s použitím binutils-2.18 je to stejně rychlé jak na CentOS 4, tak i CentOS 5. Nevím co ty starý binutils dělaly...

When people want prime order group, give them prime order group.
23.7.2009 13:47 Miloslav Ponkrác | blog: miloslavponkrac
Rozbalit Rozbalit vše Re: Problém vyřešen!

Donutily kompilátor uvažovat pesimisticky při správě výjimek.

limit_false avatar 23.7.2009 16:26 limit_false | skóre: 23 | blog: limit_false
Rozbalit Rozbalit vše Re: Problém vyřešen!

Kompilator byl v obou pripadech (CentOS 4, CentOS 5) stejny - gcc 4.1.2. Co se zmenilo, byl pouze linker (z novych binutils), ktery nejspis postavil hash tabulku symbolu (sekci .hash v ELFech) jinak, tim padem je vyhledavani rychlejsi. Prokazuje to i nove mereni profilerem, kde je videt ze zpusob volani _Unwind_RaiseException, _Unwind_Find_FDE a dl_iterate_phdr se nezmenilo, jenom callback funkce volana pres dl_iterate_phdr se "zlevnila" (a ta callback funkce je ze stejne libgcc_s.so jako v problematickem pripade).

When people want prime order group, give them prime order group.
limit_false avatar 23.7.2009 15:58 limit_false | skóre: 23 | blog: limit_false
Rozbalit Rozbalit vše Re: Problém vyřešen!

Update:

pokud se ta aplikace preklada a linkuje na CentOS 4 (systemu, ktereho glibc nepodporuje gnu hash-style) s temi novymi binutils, je potreba pouzit linker flag hash-style=sysv. Jinak to nejak spatne vygeneruje tu .gnu.hash sekci v ELFu a pak binarka na systemech podporujicich .gnu.hash hazi "undefined symbol". S tim hash-style=sysv je to OK, i zrychleni proti starym binutils zustava.

When people want prime order group, give them prime order group.

Založit nové vláknoNahoru

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.