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

Zelený je lopuch,
fotbal to je hra...

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: qffzpgt
[ 857 ] <Novější  <<<Nejnovější  Nejstarší>>>  Starší>  
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 ;)
bredy 6.3.2007 14:28  732
TessienNo jestli se ti video kompressí rychleji než disk stíhá zapisovat, tak to máš opravdu pěkný dělo. U mne komprese filmu na DVD velikost trvá něco přes 16 hodin a spíš než swapování počítá a počítá a disk si jen tak občas blikne :-)
ender Ender 6.3.2007 13:54  731
kmetOno je to celé nějaké pofidérní. Buď je to nějaká podivná mutace prologu, nebo jsem totálně mimo a nebo (a teď se neuraž) jsi mimo ty a pokoušíš se na prolog naroubovat klasické sekvenční & procedurální programování.

- pocitac nemá žádné parametry, takže o nějakém jejich pattern matchingu nemůže být moc řeč.
- těžko z něho dostaneš nějaký výsledek (upravené haldy), když na to nepoužiješ nějaké volné parametry
- to samé s retract, pokud teda má něco udělat s tou heap.
- nikde nemáš vnitřní reprezentaci heap(X,Y), ale třeba to nikde nepotřebuješ a chceš na tom jen ilustrovat princip.
tessien Tessien Of course slavery is the worst thing - that ever happened. But maybe... 6.3.2007 09:17  730
Bredy [728]: (ad posledni odstavec) - a to je presne ten duvod, proc to pousteni kompreseni videa na pozadi je vetsinou na houno :)
Zatim vsechny opruzy s pomalosti pri prepinani cehokoli ve Windows, co jsem zazil, byly kvuli swapovani a ne kvuli procesorovymu casu :(
Navic ve Win je problem s tim, ze kdyz ta aplikace na pozadi bude hodna pracovat s diskem (jako treba ta prace s videem :), tak si Windowsy budou krasne zvetsovat diskovou cache a na jeji ukor odswapujou postupne vsechny neaktivni programy, takze kdyz pak prepnes okno z Visual studia na Firefox, tak si pockas 2 minuty :(
kdokoliv Kdokoliv Nevidím důvod dělat cokoliv bezdůvodně. - http://kkl2401.wz.cz 6.3.2007 09:14  729
Bredy [728]: Ja netvrdim, ze to zpomaleni je vyrazne nebo ze je neprijemne, tvrdim, ze je znatelne, ze si ho proste vsimnes.
bredy 6.3.2007 01:40  728
KdokolivVětšina aplikací reagující na uživatele běží v Normal. Pokud uživatel cokoliv udělá myší nebo klávesnicí, Windows navíc zařazují priority boost, kdy aplikace, jíž se to týká může dostat dočasně vyšší prioritu, než ostatní. Aplikace na popředí (jenž má aktivované aspoň jedno okno) navíc má prioritu 9 (Normal = 8). Každopádně jsem chtěl říct, že odezvu dělají aplikace, které když něco uděláš, téměř okamžitě přeruší vše co je Below normal a níže. Priority totiž ve Win2000 a výše jsou skutečně priority, ne stupeň přidělení procesoru (jako ve Win98). Pokud běží něco souvisle na nějaké prioritě, vlákna na nižších prioritách by se teoreticky nedostali nikdy ke slovu. Ano, můžeme tedy uvažovat, že hodně idle procesů může ovlivnit odezvu, protože Win2000 sem tam provedou náhodný výběr procesu s nižší prioritou, aby nedošlo k úplnému vyhladovění.

PS: Video kompresím na Idle běžně a žádné zpomalení nepozoruji. Naopak je super, že prostě video je schopno se kompresit i teď, mezi jednotlivými stisky kláves.

Mimochodem, pozor u Win2000+, na IO. Taková aplikace v Idle prioritě může dost ovlivnit odezvu, pokud přetíží I/O (disk, file cache, atd). Procesy s vyššími prioritami pak mají smůlu, musí na I/O čekat, bez ohledu na jejich prioritu. Navíc čekání na zámky a události nemají prioritní fronty. V takových případech je priorita naprosto k ničemu, a celý systém jde do háje jen díky nějakému blbému procesu na pozadí (například Indexing service, nebo AVG).
kmet 5.3.2007 10:52  727
Jsou pevne dane tri hromadky, napriklad heap(1,3). heap(2,5). heap(3,9), kde prvni cislo je cislo hromadky a druhe cislo je pocet prvku v ni.

Pocitac ma delat to, ze kdyz nastane stav, ze je v jedne hromadce 1 prvek, v dalsi zadny prvek a v posledni N prvku (cili tech 6 moznosti), tak "vynuluje" tu hromadku s N prvky...
ender Ender 5.3.2007 00:30  726
Celkem by pomohlo, kdybys ještě pospal, co to jako má dělat, co si mám představit pod heap(X,Y), retract(_), ... atd.

Možná mi něco nedochází, ale vážně netuším, co se to vlastně snažíš udělat a jakých 6 variant máš namysli. Čísla v (heap(1,N), heap(2,0), heap(3,1)) dokážu zpermutovat rozhodně více než šesti způsoby.
kmet 4.3.2007 22:30  725
Řekněme, že mám definované tři hlady heap(X, Y) a potom nějaké takové pravidlo

pocitac :-
(heap(1,0), heap(2,1), heap(3,N)),
retract(heap(3,N)),
asserta(heap(3,0)).

pocitac :-
(heap(1,N), heap(2,0), heap(3,1)),
retract(heap(1,N)),
asserta(heap(1,0)).

... atd, takhle všech 6 variant (kombinací), napadá někoho jak to nějak chytře přepsat do jednoho pravidla, ať trošku zkrátím zdroják?
mach 4.3.2007 20:21  724
Jj.
ender Ender 4.3.2007 20:02  723
Máme.

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

(c) 2001-2011 Lopuch.cz   
Kontakt