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

Když diskuse,
tak s Lopuchem

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: iakxmvh
[ 857 ] <Novější  <<<Nejnovější  Nejstarší>>>  Starší>  
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 ;)
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 :(

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

(c) 2001-2011 Lopuch.cz   
Kontakt