Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Ondřej Novák

Stran: 1 ... 33 34 [35] 36 37 38
511
Sítě / Řízení priority paketů v Ubuntu
« kdy: 08. 06. 2011, 22:03:36 »
Zdravím

nevíte někdo o nějakém inteligentním skriptu/aplikaci pro řízení trafiku na router pod ubuntu? Nechci žádný zpomalovače, protože mám hodně kolísavou kvalitu připojení (wifi), takže například nelze pevně určit šířku pásma.

Ale hodilo by se něco, co by paketům od uživatelů mající celkově velký trafik dával nižší prioritu.


512
Hardware / Re: HyperThreading vs dvě jádra
« kdy: 08. 06. 2011, 09:30:43 »
No, ono to bude spíš tak, že přednost bude mít UI a ten proces poběží v tom "zbytku" - co vím, tak plánovač ve windows dost výrazně upřednostňuje interaktivní procesy (tj UI). Tak jako tak to ale bude lepší, než kdyby tam bylo "obyčejné" jádro.

No já jsem tam psal "s vyšší prioritou". Plánovač Windows akorát dává threadu, který vlastní aktivní okno o stupeň vyšší prioritu, než je Normal. Je to pořád méně než Above Normal. Pokud se něco spustí s Above Normal, má to prioritu, před UIčkem.

Ale dobrý postřeh samozřejmě, dlouhé výpočty by měli běžet na Below Normal nebo Idle, krátké a časově kritické operace na Above Normal.

Mě šlo jen o to ukázat, že HT jádro může výrazně pomoci výkonu desktopu (v porovnání třeba s single CPU) v případě, kdy procesor musi obsloužit nějakou kritickou událost, že to nezpůsobí "zasekáváníů prostředí.

Já například mám 2x Core HT (čili čtyři jádra virtuálně). Honím na to virtuál se dvěma jádry, a i přesto, že tam pustím něco náročného, pořád jsou Windowsy použitelné.

513
Hardware / Re: HyperThreading vs dvě jádra
« kdy: 07. 06. 2011, 21:33:02 »
No z hlediska programování, pokud se tedy nejedná o programování na úrovni jádra, není rozdíl. Pokud máme úlohu, kterou nelze škálovat, pak počet jader nemá na výkon vliv. Škálovatelné úlohy poběží na HT pořád rychleji než na jednom procesoru, i když, jak bylo řečeno, žádné zázraky od toho čekat nelze. Nicméně jeden procesor s HT už může dost dobře zlepšit odezvu systemů (třeba Windows) a to i v případě, že trvale běží úloha v jednom vlákně s vysokou prioritou. UIčko má pořád k dispozici "druhou půlku" procesoru, byť s mizerným výkonem, na UIčko to kolikrát stačí.

514
Vývoj / Re: Váš nejlepší řádek kódu
« kdy: 02. 06. 2011, 22:14:40 »
Kód: [Vybrat]
inline int toInt( float fval ) {fval += (float)(3<<22); return ( (*(int *)&fval)&0x007fffff ) - 0x00400000;}

To není moje, ale děsně se mi to líbí. Ultra rychlý převod malých reálných čísel v rozsahu +/- 2^21 na integer


515
Vývoj / Re: Váš nejlepší řádek kódu
« kdy: 02. 06. 2011, 22:08:58 »
Kód: [Vybrat]
unsigned short c = (unsigned short)(((a & 0xF7DF) + (b & 0xF7DF))>>1)

Je to 50% mýchání dvou 16bitových barev RGB (RRRR RGGG GGGB BBBB). Zápis předpokládá 32-bitovou architekturu. Na 16bitové to nelze zapsat v C, protože je nutné využít 17bit carry pro uložení přetečení po sečtení. Tam se pak nepoužije SHR ale RCR.

Nevýhodou tohoto jednoduchého a rychlého zápisu je, že se lehce ztrácí přesnost na nejnižším bitu barev R a G. Použito na průhlednost v Branách Skeldalu




516
Sítě / Re: OpenVPN nepoužívá nastavené porty
« kdy: 24. 05. 2011, 10:52:09 »
Jen technická, nevím jak je to u OpenVPN ale obceně u UDP neplatí, že klient musí mít náhodný port. Ono u UDP neexistuje dělení na Server/Klient, protože není tam klasické schéma iniciace spojení... obě strany navíc mají schopnost rozlišit jednotlivé virtuální okruhy podle adresy s kým komunikují.

517
Vývoj / Re: C++ a ukazatel na objekt
« kdy: 20. 05. 2011, 16:04:39 »
cast na void * myslím nic nepočítá.

Ale jestli to umíš udělat, tak to zabal do nějaký funkce a že to v tý knihovně šíli Ti může bejt jedno, ne? Nicméně tu šílenost bych rád viděl :-).

No to není věc knihovny, ale hlavičkových souborů. A to je horší. A v zásadě to vypadá tak, že se deklaruje šablona IsPrimitiveType<T>, které se lze zeptat, zda T je primitivní typ (třeba int, short), pak je tam šablona IsPointer<T> a IsReference<T>. Jakmile se vyloučí tyhle typy, pak se řeší, zda je IsPolymorphic<T>, ten se dělá tak, že se původní typ podědí a přidá se mu virtuální destruktor a měří se velikost výsledného objektu. Pokud se liší od objektu původního typu, znamená to, že původní typ nebyl polymorfní (přidáním virtuálního destruktoru se založila tabulka virtuálních adres). No a na konci téhle anabáze lze rozdělit cast na void na případ, kdy se udělá reinterpret_cast a dynamic_cast. Z toho jsem schopen zjistit adresu objektu, a offset mezi dodaným ukazatelem a skutečným začátkem objektu v paměti.

Vyhodnocení dělá překladač, ve výsledném kódu je pro polymorfní typy dynamic_cast a pro nepolymorfní typy nic (cast se nepřekládá). Vyhodnocení všech šablon dost protahuje překlad kódu.

518
Vývoj / Re: C++ a ukazatel na objekt
« kdy: 20. 05. 2011, 13:44:50 »
Mimochodem, nevíte někdo náhodou, jestli C style cast na (void *) u polymorfních objektů uděla dynamic_cast<void *>()

Nebo bych potřeboval nějaký univerzální castovač na void *. Hodí se to, pokud chce člověk zjistit base adresu objektu. U polymorfních objektů lze právě použít dynamic_cast<void *> ale pokud se nejedná o polymorfní objekt, tak to selže na chybě překladu. Dosti komplikovaným způsobem přes několik desítek šablon lze udělat to, že poznám primitivní typ, poznam polymorfní typ a na základě toho zvolím castovač, ale je to opruz.

519
Vývoj / Re: C++ a ukazatel na objekt
« kdy: 20. 05. 2011, 13:40:43 »

Nebo se překladače nechovaj dle normy?

Nevím, upřímě normu neznám zpaměti a doposud jsem C style cast na pointer považoval automaticky za reinterpret_cast

520
Vývoj / Re: c++ ukazovatel na objekt
« kdy: 20. 05. 2011, 12:47:30 »
Proč tak složitě? Stačí
Kód: [Vybrat]
((bar*)(obj))->b();

Protože to není totéž. static_cast umí zařídit i patřičný offset u vícenásobné dědičnosti:


Citace: Aleš Janda
V tomto případě bych použil dynamic_cast - ten je přesně na toto dělaný. Za běhu zkontroluje typ (je tedy o trochu pomalejší než static_cast) a pokud by neseděl (tj. jeden objekt by nebyl potomkem druhého), vrátí NULL.

dynamic_cast je dobré používat tam, kde opravdu nemám jistotu, že to co mi přilezlo ukazatelem je skutečně objekt, který očekávám. dynamic_cast má tyto nevýhody
  • Lze použít pouze na objekty, které mají nějaké virtuální funkce (stačí destruktor)
  • Nelze jej použít jako reinterpret_cast, tedy objekt opravdu musí být tím, co očekáváme (někdy se hodí umět to přetypovat navzdory)
  • Vyžaduje akci v runtime. Zatímco všechny XXX_cast operátory vyhodnocuje překladač, dynamic_cast se vyhodnocuje za běhu. A není to zrovna levná záležitost.

Většinou se to řeší tak, že v tabulce virtuálních metod je přibalen ukazatel na záznam o třídě objektu a ten obsahuje odkaz na tabulku všech tříd, které dědí a to i tranzitivně. Operátor pak projde tabulku a nalezne v ní třídu ukazatele a cílovou třídu a spočítá transformaci výsledného pointeru... tedy spočítá jeho offset. Jako klíč do tabulky bývá zakódované jméno třídy (porovnávají se řetězce) - Microsoft, případně nějaké GUID třídy (COM+, prý to používá i gcc)

Nicméně, pokud vím, že mi do nějaké funkce může přilézt objekt jen určitého potomka k danému rozhraní, nebo základní třídy, tak používám static_cast, je to rychlejší. Je však dobré dynamic_cast ověřit aspoň pomocí _assertu v testovací verzi.

PS: Nevýhoda static_castu: nedá se použít na virtuální dědičnost.

521
Vývoj / Re: c++ ukazovatel na objekt
« kdy: 19. 05. 2011, 16:43:16 »
static_cast je v tomto případě asi nejčištší workaround. Dá se použít v C++, pokud potomek nemá žádné členské proměnné ani virtuální funkce...  Tedy ono se to dá použít i tak, ale volaná funkce nesmí pracovat s membery deklarované v potomkovi a při volání virtuálních metod nesmí člověk být překvapen, že se zavolá předek. Virtuální metody nově deklarované v potomkovi se volat nesmí.

Používám tenhle hack, pokud se potřebuju z nějakých důvodů dostat k proměnným deklarovaným "protected:" u knihoven třetích stran. Sám ve všech třídách používám výhradně deklaraci "protected:" abych si tuhle cestu rozšiřování v budoucnosti neuzavřel.

522
Vývoj / Re: RTTI abstrkatnej triedy C++
« kdy: 04. 05. 2011, 21:13:09 »
Jde o to, že v jazyce IDL se interface používá. V zásadě ty opravdu plnohodnotně definované interfacy v COM+ se dají pochopit i jako předpis IDL, takže se deklarace nemusí psát víckrát.

Když se podíváte na nějakou takovou definici, tak obsahuje spoustu divných klíčových slov, které jsou ale v C++ deklarovaná jako prázdná makra .

523
Vývoj / Re: Serializácia a deserializácia C++
« kdy: 03. 05. 2011, 02:30:05 »
Serializaci má (podle mě) velice hezky vyřešenou fox toolkit. Nejen že používá serializační konstruktory, ale přetěžuje i operátory tříd datových proudů, takže stačí otevřít serializační soubor a pomocí operátorů << >> serializaci provést. Navíc samotná serializace konkrétních objektů se implemetuje přetížením metod load( ) a save( ) u všech potomků třídy FXObject, a mělo by být teoreticky možné využít k realizaci těchto metod místo přetížených operátorů streamů. Někomu se však může zdát jako nevýhoda, že celý tento mechanizmus je řešen pomocí klasických maker.   

No nevím, přečti si můj seriál, mou zvolená metoda má prostě opodstatnění. A není to žádný ad-hoc řešení. První verze serializátoru vznikla někdy v roce 2002 a byť se od toho posledního návrhu velice liší, ten vývoj byl celkem bouřlivý. Úspěšně jsem to nasadil například v některých částech fulltextu (v Seznamu), Lištička to používá pro serializaci zpráv mezi okny prohlížeče IE, později jsem napsal i vlastní RPC protokol, nebo serializaci do XML streamu.

524
Vývoj / Re: Serializácia a deserializácia C++
« kdy: 02. 05. 2011, 10:02:42 »
Serializační konstruktor je celkem jednoduchý na napsání (je nutné dát pozor na věci, co se musí vyplnit už v konstruktoru, aby byly serializovány ve stejném pořadí, v jakém je konstruktor vytáhne) ...

Ano, a to je přesně o tom. Totiž, pokud chci využit deserializační konstruktor, musí i member proměnné (a to tedy všechny) používat deserializační konstruktory, musí být ve správném pořadí (a nejsem si jist, jestli pořadí inicializace je v normě C++ zaručeno), nebo v druhé variantě se ti to rozpadne na dvě části, což jsi ukázal v příkladu.
 - konstrukce ve výchozím stavu
 - deserializace, která stav změní.

Není to až tak velká výhoda, aby se vyplatilo zahazovat oboustrannost serializace ... "i zvenku" (z API ... vlastně máš tady dvě metody místo jedné, byť vnitřně se z druhé volá první)

525
Vývoj / Re: Serializácia a deserializácia C++
« kdy: 02. 05. 2011, 00:32:14 »
Původního tazatele bych možná odkázal na mou teoretickou (bohužel nedokončenou) práci na téma Serializace v C++ ve formě seriálu:

http://bredy.novacisko.cz/?g=main&kat=59

Stran: 1 ... 33 34 [35] 36 37 38