Registrace nového uživatele     Návod     Kluby     Archív  Lopuchu     Lopuch.cz  

Diskuze na Lopuchu,
pohlazení na duchu

Lopuch.cz

Jméno:
Heslo:
Podpora LCD:
 
Klub Programování [ŽP: neomezená] (kategorie Programování) moderuje tvx.
Archiv
  Nastavení klubu     Nastavení práv     Homepage     Anketa     Přítomní     Oblíbené     Lopuch     Kategorie  
autor: 
text: 
vyplnit a 
Help
 Titulek, text příspěvku  
Opište pozpátku následující text bez prostředního znaku: qpbjykl
[ 857 ] <Novější  <<<Nejnovější  Nejstarší>>>  Starší>  
pavel_p 17.4.2007 21:38  755
Potřeboval bych pomoci s jedním začátečnickým problémem v C#. U minulého programu určeného pro Windows jsem si normálně ve Wind. forms vytvořil timer a v programu jsem si ho normálně pouštěl pomocí třeba Timer.Start(); Ted dělám nový program pro Win CE (nevím jestli to s tím souvisí a "Start", "Stop" a jiné vůbec nemám k dispozici. Prostě ho to nezná. Co s tím?
operator304 5.4.2007 13:28  754
Vsem, co potrebujou delat nejake vizualizace v jave, nebo programovat nejake gui, eventuelne s mat. operacemi, ci napojenim na Matlab, doporucuju toto . Jednoduche a vysoce funkcni.
decide 12.3.2007 12:47  752
BredyAno můj koeficient je vlastně opravou frekvence, až na to, že jednu sekundu nedokážu přesně změřit, takže ten koeficient určuju jak jsem psal a toleruju jednou za čas synchronizaci. Funguje to docela pěkně, dělal jsem s tím různé pokusy (např jsem v tvrdém cyklu psal do logu přesný čas a to rozlišení odpovídalo frekvenci)
bredy 12.3.2007 02:37  750
DecideProcessTimes sice má údaje ve stovkách nanosekund, ale kdo ví jestli to není jen přepočtený. Ale dává to šanci, že třeba to v budoucnu změní. Ale aby to mělo tuhle přesnost, to jsem docela skeptický.

Jojo, QueryPerformanceCounter je dobrá věc, na měření krátkých úseků. Přesnost je tam relativní :-) Tady je asi opravdu lepší si změřit, kolik trvá reálná sekunda. Pak stačí podle mne upřesnit frekvenci.
decide 12.3.2007 00:36  749
BredyTo co uvádíš jako nejsprávnější se mi zdá taky nejsprávnější. Chtěl jsem to tak nějak udělat, ale nepřišel jsem na to, jak zjistit čas nečinných procesů. Tak díky.

GetTickCount má větší granularitu než ProcessTimes (to má být ve stovkách nanosekund).

Ten sleep(100) jsem tam dal jen pro "zjednodušení", ve skutečnosti tam mám timer tikající po asi 100ms. Ale to je jedno, chtěl jsem chytit špičky vytížení CPU do grafu a celkem se to povedlo - škůdce byl odhalen a napraven.

Ještě ke QueryPerformanceCounteru: Před časem jsem psal program ve kterém jsem potřeboval hodiny (opravdu hodiny, ne jen měření nějakých krátkých úseků) s rozlišením alespoň 1/20000 tak jsem je udělal pomocí QPC. Pochopitelně se rozcházejí se systémovými hodinami. Tudíž jsem tam doplnil sledování průměrné odchylky a synchronizaci s hodinami a opravný koeficient (když zjistím moc velkou odyhcylku, o polovinu to doženu opravou offsetu a o polovinu opravou koeficientu), který by měl vyjadřovat o kolik se to relativně rozchází. Běží to na dvou pc. Na jednom se synchronizuje přibližně 3x častěji než na druhém (je to cca 1 za týden). Ten koeficient konverguje k něčemu jako 1E-5. Až budu mít možnost se podívat na program zjistím to přesněji, běží už tak 4 měsíce, tak by mohl být výsledek celkem zajímavý.
bredy 10.3.2007 09:40  748
decideMno, věřím Ti, že nejspíš funguje. Jen je otázkou, jestli nejdeš s kanónem na vrabce. Co se ze zdrojáků dá vyčíst je, že tam vlastně ověřuješ, zda sleep(100) skutečně trval 100ms. To chápu. sleep má někdy granualitu kolem 10ms-15ms. Ale tahle granualita je odvozena od plánovače úloh. Ten taky má nějakou podobnou granualitu. Proto mám trochu problém se sleep(100ms), neboť je to příliš krátky čas na měření (na Windows Server může trvat timeslice i 120ms). Pak se může stát, že se měřená aplikace během tak krátke doby nedostane ke slovu.

Pokud bys měřil 1000ms (sekundu), pak si myslím, že měření přes QueryPerformanceCounter je opravdu kanón a navíc nezajišťuje dobrou přesnost (vysvětlím níže). Úplně by postačil GetTickCount a nebo použít GetSystemTime. Nicméně.

Laborujeme tu se dvěmi až třemi hodinami. Pokud použijeme GetSystemTime, nemáme jistotu, že reálná sekunda trvá stejnou dobu jako procesorová sekunda. A v současné době nemáme ani jistotu, že sekunda plánovače úloh trvá stejnou dobu jako sekunda QueryPerformanceCounter. Co se dá možná porovnat je sekunda plánovače úloh a sekunda GetTickCount, protože jsou odvozeny od stejného časovače.

Podívejme se na implementaci QueryPerformanceCounteru. Dneska se používají všelijaké čítače uvnitř procesoru, čímž se dosáhne lepší přesnosti, avšak starší varianta této funkce četla hodnotu z registrů legendárního obvodu 8253/54, který je dodnes emulován v chipsetu desky. Ten má pevnou frekvenci 1193180Hz. Od něho je odvozena frekvence plánovače úloh. Na starších počítačích lze tedy odvodit, že sekunda QueryPerformanceCounteru je stejná jako sekunda plánovače úloh. Ale v současné době už to nelze porovnat. Kdo ti dá jistotu, že Windows znají frekvenci procesoru přesně?

Úplně nejsprávnější řešení by bylo sečíst ProcessTimes všech běžících procesů a touto hodnotou podělit ProcessTimes procesu, který nás zajímá (protože i nečinnost procesoru je považováno za běh procesu s PID 0). Provádět to můžeme v libovolném kroku a nemusíme měřit čas. Ale chápu, že to není tak jednoduché. Jednodušší řešení je odvodit čas od GetTickCount, který je spojen s plánovačem úloh a používá stejný časovač.
decide 10.3.2007 01:48  747
oprava 100 nsk=1E7
decide 10.3.2007 01:46  746
BredyQueryPerformanceCounter používám k určení doby po kterou sleduju ProcessTimes abych mohl určit spotřebovaná procenta. Dělám přibližně toto:
k=1E8 (asi, uz si to nepamatuju, ale ProcessTimes je asi ve stovkách nanosekund)
q0=QueryPerformanceCounter/QueryPerformanceFrequncy*k
t0=ProcessTimes
sleep(100)
q1=QueryPerformanceCounter/QueryPerformanceFrequncy*k
t1=ProcessTimes
cpu_pct=100*(t1-t0)/(q1-q0)/pocet_procesoru
bredy 9.3.2007 11:05  745
GarbageCollector v C++, prototyp

Něco jsem sepsal, jsou u toho i zdrojáky. Jedná se o prototyp, tj. s ostrým nasazením bych váhal. Ale jako demonstrace fungování postačí.
tessien Tessien Of course slavery is the worst thing - that ever happened. But maybe... 8.3.2007 23:18  744
No, v Jave GC zastavi vlakna jen v jedne z asi 3 fazi sveho behu..
bredy 8.3.2007 23:15  743
GumyshPerformance bude vždycky problém. U jakéhokoliv GC. Stejně tak režie na paměť (správa databáze něco stojí). MultiThreading problém není. Vstupy do GC můžeš zamknout jednorázově. Ano může to zdržet jiná vlákna, pokud náhodou jedno alokuje a v druhem se provádí sweep, tak ten sweep obecně trvá trochu déle a druhé vlákno čeká na alokaci. Nicméně v Javě GC při spuštění nejprve zastaví všechna vlákna. Což třeba já nedělám, neboť k tomu prostě není důvod.
gumysh 8.3.2007 16:27  742
Jsem zvedav na performance. A na snadnost pouzivani. Hadam take, ze stale zustava problem s multithreadingem (no, s nim je to v C++ vubec bida bidouci).
bredy 8.3.2007 15:40  741
Nic v tom neni. Chytry pointer co bonzuje odkud kam je propojeno, databaze, ktera udrzuje informace o dvojicich a nejaky index aby se v tom dobre hledalo, to vsechno postaveno pouze nad STL. A pak je tam funkce "dej mi seznam vsech objektu, ktere referencuji _tenhle_ objekt" a pak nejaky transitivni uzaver, ktery nakonec zodpovi na otazku "existuje nejaky externi link na _tenhle_ objekt?" A pokud zodpovi NE, zavola na nej callback. To se samozrejme provadi obcas, treba pokazde, kdyz se něco alokuje, nebo to je tam funkce, kterou musis cas od casu zavolat, treba pri casovaci, nebo v jinem vlakne.
gumysh 8.3.2007 15:29  740
Napinas! :o) Uz se tesim. Btw. jak jsi na toto prisel?
bredy 8.3.2007 15:16  739
Gumyshmalý dodatek, nejedná se o počítání referencí, ale o variantu metody mark and sweep, takže to vyřeší i cyklické reference

snad ten článek brzo dám do kupy.

[ 857 ] <Novější  <<<Nejnovější  Nejstarší>>>  Starší>  

(c) 2001-2011 Lopuch.cz   
Kontakt