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

Náš Lopuch Vám
vytře zrak

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: qbspyvr
[ 857 ] <Novější  <<<Nejnovější  Nejstarší>>>  Starší>  
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.
bredy 8.3.2007 15:15  738
GumyshJo, ještě ho musím podrobit zátěžovým testům. Funguje to ale docela pekně a jě to malé, má to prakticky asi 6 souborů z toho 3x cpp a 3x h a tvoří to tři spolupracující třídy, z nichž jedna je definovaná jako interface.

Oproti jiným GC je to napsaný tak, že to vůbec neřeší alokace a dealokace, ale pouze pozná, zda nějaký objekt je nebo není referencován a pokud není, zavolá ti nějaký callback. Většinou tam budeš mít delete objekt, ale je zde prostor používat například vlastní alokátory a honit GC nad nimi.
gumysh 8.3.2007 15:11  737
Na ten garbage collector v C++ jsem celkem zvedavy.
bredy 8.3.2007 09:28  736
SeriálJen aby Céčkaři nepřehlédli

Efektivní alokátor malých objektů a tady druhý a třetí díl.

Dále chystám "Implementace Garbage Collectoru v C++" (opravdu fungující)
bredy 7.3.2007 19:52  735
decideOno to je ještě zamotanější. GetProcessTimes ve skutečnosti vrací součet všech čítačů, které jsou umístěné v TLS každého threadu. Funkce pouze projde všechny thready a patřící procesu a sečte jejich čítače. (Existuje i funkce GetThreadTimes.). A jak se čas běhu procesu/threadu počítá? Přijdete na to, že to není moc přesné. Kdykoliv je vláknu odebráno časové kvantum, započítá si na čítači jedničku. Děje se ale pouze v případě, že vlákno je přerušeno časovačem. Pokud je třeba přepnout z jiného důvodu, přepnutí se nezapočítá. Ten jiný důvod je například čekání na signalizační objekt, Sleep nebo SwitchToThread. Z toho důvodu je čas běhu vlákna, které začne čekat na událost, započítán do času vlákna, jenž, po zastavení čekajícího vlákna, pokračuje v běhu. Čas běhu vlákna je pak dáno počet přepnutí x doba časového kvanta

Jinak to co píšeš o frekvenci je trochu divné. Ano QueryPerformanceCounter skutečně může mít přesnost rovnou frekvenci procesoru, ale také nemusí. Záleží na implementaci. Každopádně je tato hodnota (frekvence čítače) je stejná bez ohledu na aktuální procesory. Microsoft ovšem píše, že v ovladačích bývají chyby a často způsob implementace vede k tomu, že každý procesor má jinou hodnotu v čítači.

Každopádně čas běhu procesu / threadu není odvozeno od frekvence.
decide 7.3.2007 13:06  734
CPUGetProcessTimes ve spolupráci s QueryPerformanceCuunt funguje pro jeden procesor dost podobně jako TaskM. Pro více jader je nutno QPC vynásobit poctem jader. Takto jednoduse to jde, za predpokladu, ze jadra/procesory maji stejnou frekvenci. Task manager ve skutecnosti cte udaje odnekud z registru, resp. neceho, co se tvari jako registry, ale me stacil ten GetProcessTimes.
kmet 6.3.2007 16:16  733
Já jsem stoprocentně s prologem úplně mimo, o tom asi netřeba diskutovat ;)

ale asi si špatně rozumíme, poslal bych ti komplet ten kód a asi bys to pochopil líp, tohle byl jen výsek. Já asi nějak tak očekával, že ten zbytek z něj bude jasný ... ;) Ale nerozmazával už bych to, je to jen semestrálka, kterou zítra odevzdám tak jak je a nechám se překvapit ;)

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

(c) 2001-2011 Lopuch.cz   
Kontakt