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

Což takhle
dát si Lopuch?

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: qgxatrq
[ 857 ] <Novější  <<<Nejnovější  Nejstarší>>>  Starší>  
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.
kmet 4.3.2007 18:13  722
PrologMáte někdo v živé paměti Prolog? :)
gumysh 25.2.2007 15:56  721
Musis dodat handle k procesu - pro aktualni proces lze snadno pomoci funkce GetCurrentProcess(), pokud me pamet neklame (v tomto pripade je to pseudohandle, ktere neni nutne zavirat), pro ostatni procesy musis handle prvne otevrit (napr. pomoci OpenProcess()); k tomu ovsem take musis tusit, jaky proces chces otevrit a musis mit prislusna privilegia.
decide 24.2.2007 20:19  720
využití CPUNo díky za odezvy. Sice jsem se ptal na využití procesoru procesem(tim jsem myslel jedním), ale i tak dík. Ten GetProcessTimes mi ve w2k/delphi nefungoval, furt vracel neplatny handle (error code 6)
gumysh 24.2.2007 14:43  719
Vsechny hodnoty, ktere zobrazuje Task Manager (a podobne utility) jsou pocitany primo ze statistik kernelu (a mozna jeste nejak prepocitavane nejakou vrstvou ve Woknech). Kazdopadne dulezite system-wide informace jsou citelne z Registru - existuje je tam nejaka vetev dynamicky generovanych klicu a hodnot, ktere pri cteni poskytuji prave aktualni statistiky. Kdysi jsem delal takovy programek pro Windows 9x, tam to bylo celkem jednoduche; nanestesti ve Windows NT+ je to trosku jinak a neni to az tak jednoduche. Krome Registru existuji i funkce Win API (napr. zminene GetProcessTimes()), ktere dodaji nektere dalsi informace; minimalne se hodi funkce pro vylistovani seznamu procesu apod., pokud clovek chce zjistit, co vlastne bezi a k cemu ma hledat informace.

Tak ci onak, vse potrebne je k nalezeni v MSDN, staci zkusit neco jako "performance monitoring".

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

(c) 2001-2011 Lopuch.cz   
Kontakt