Builder.cz - Informacni server o programovani

Jeste posledni vec, ten pomer w / c opravdu nemusi byt 0 az 1.

Jeste posledni vec, ten pomer w / c opravdu nemusi byt 0 az 1.

Citovat příspěvek

> > Podle me 99% cekani => 0.99
>
> To ale odporuje tomu ze
> + w / c je pomer doby mezi cekanim na IO a doby
> kdy se pocita (0 az 1).
> to by muselo vyjiy 99/1. Ale to je asi jen spatne
> vyjadreny.

Je to spatne napsane, nevim jak to spravne vyjadrit cesky. Asi pomer mezi cekanim a aktivnim vypoctem z celkove doby nutne k reseni?

> Nad nekteryma vecma co udelal J. Bloch krouti
> spousta lidi nevericne hlavou, vcetne jeho. Ale to
> je tim ze to delal nekdy v praveku. Nad tim co
> udelal D. Lee nekrouti hlavou nikdo, protoze tomu
> nikdo nerozumi.

:D

> > Nedoslo mi, ze kdyz mam 1000 tasku a bezi pro
> ne 1000 thread, tak se ty thready v behu
> "spravedlive" stridaji - cachedPool, zatimco kdyz
> pro ne mam jen 30 Thread - fixedPool, tak se tech
> 970 dostane ke slovu az po skonceni tech prvnich
> 30.
>
> Ted je vse jasny!

Presne tak, ted je mi to jasnejsi, diky vsem.

> > Podle me 99% cekani => 0.99 > > To ale odporuje tomu ze > + w / c je pomer doby mezi cekanim na IO a doby > kdy se pocita (0 az 1). > to by muselo vyjiy 99/1. Ale to je asi jen spatne > vyjadreny. Je to spatne napsane, nevim jak to spravne vyjadrit cesky. Asi pomer mezi cekanim a aktivnim vypoctem z celkove doby nutne k reseni? > Nad nekteryma vecma co udelal J. Bloch krouti > spousta lidi nevericne hlavou, vcetne jeho. Ale to > je tim ze to delal nekdy v praveku. Nad tim co > udelal D. Lee nekrouti hlavou nikdo, protoze tomu > nikdo nerozumi. :D > > Nedoslo mi, ze kdyz mam 1000 tasku a bezi pro > ne 1000 thread, tak se ty thready v behu > "spravedlive" stridaji - cachedPool, zatimco kdyz > pro ne mam jen 30 Thread - fixedPool, tak se tech > 970 dostane ke slovu az po skonceni tech prvnich > 30. > > Ted je vse jasny! Presne tak, ted je mi to jasnejsi, diky vsem.

Citovat příspěvek

> [ital]Podle me 99% cekani => 0.99[/ital]

To ale odporuje tomu ze
+ [ital]w / c je pomer doby mezi cekanim na IO a doby kdy se pocita (0 az 1).[/ital]
to by muselo vyjiy 99/1. Ale to je asi jen spatne vyjadreny.

> [ital]> Proc by mel byt put<=1?
Protoze nemuzes zatizit prosecor na vice nez 100%[/ital]

Ale muzu se o to pokusit a jak pise xyz3 ma to i smysl.

> [ital]Joshua Bloch (mj. autor Collections Frameworku) a Doug Lea (autor java.util.concurrent) mi neprijdou jako nejaci "konzultanti"[/ital]

Nad nekteryma vecma co udelal J. Bloch krouti spousta lidi nevericne hlavou, vcetne jeho. Ale to je tim ze to delal nekdy v praveku. Nad tim co udelal D. Lee nekrouti hlavou nikdo, protoze tomu nikdo nerozumi.

> [ital]Nedoslo mi, ze kdyz mam 1000 tasku a bezi pro ne 1000 thread, tak se ty thready v behu "spravedlive" stridaji - cachedPool, zatimco kdyz pro ne mam jen 30 Thread - fixedPool, tak se tech 970 dostane ke slovu az po skonceni tech prvnich 30.[/ital]

Ted je vse jasny!

PS: Vyse uvedeny neni mysleno jako kritika tech dvou.

> [ital]Podle me 99% cekani => 0.99[/ital] To ale odporuje tomu ze + [ital]w / c je pomer doby mezi cekanim na IO a doby kdy se pocita (0 az 1).[/ital] to by muselo vyjiy 99/1. Ale to je asi jen spatne vyjadreny. > [ital]> Proc by mel byt put<=1? Protoze nemuzes zatizit prosecor na vice nez 100%[/ital] Ale muzu se o to pokusit a jak pise xyz3 ma to i smysl. > [ital]Joshua Bloch (mj. autor Collections Frameworku) a Doug Lea (autor java.util.concurrent) mi neprijdou jako nejaci "konzultanti"[/ital] Nad nekteryma vecma co udelal J. Bloch krouti spousta lidi nevericne hlavou, vcetne jeho. Ale to je tim ze to delal nekdy v praveku. Nad tim co udelal D. Lee nekrouti hlavou nikdo, protoze tomu nikdo nerozumi. > [ital]Nedoslo mi, ze kdyz mam 1000 tasku a bezi pro ne 1000 thread, tak se ty thready v behu "spravedlive" stridaji - cachedPool, zatimco kdyz pro ne mam jen 30 Thread - fixedPool, tak se tech 970 dostane ke slovu az po skonceni tech prvnich 30.[/ital] Ted je vse jasny! PS: Vyse uvedeny neni mysleno jako kritika tech dvou.

Citovat příspěvek

A ja prave pisu ze tito dva nejsou Java konzultanti, ale autori mnoha jejich casti vcetne baliku java.util.concurrent o kterem tu je rec.

S teorii operacnich systemu mate jiste pravdu. Ja jsem prave doufal, ze mi to nekdo vysvetli, coz se take z vetsi casti stalo. Na druhou stranu se tu pak na foru muzeme navzajem odkazovat na jednotlive monografie a forum jako takove nemusi existovat :)

A ja prave pisu ze tito dva nejsou Java konzultanti, ale autori mnoha jejich casti vcetne baliku java.util.concurrent o kterem tu je rec. S teorii operacnich systemu mate jiste pravdu. Ja jsem prave doufal, ze mi to nekdo vysvetli, coz se take z vetsi casti stalo. Na druhou stranu se tu pak na foru muzeme navzajem odkazovat na jednotlive monografie a forum jako takove nemusi existovat :)

Citovat příspěvek

Behnil Napsal:

> Joshua Bloch (mj. autor Collections Frameworku) a
> Doug Lea (autor java.util.concurrent) mi neprijdou
> jako nejaci "konzultanti"

Rekl bych, ze dulezite je to spojeni [b]Java konzultanti[/b] a jestli jsem xyz3 pochopil, tak tim chtel poukazat na to, ze teorii operacnich systemu se ucime z monografii na dane tema a teprve kdyz ji zvladame, tak ji konfrontujeme s tim, jak se odrazi v Jave...

Behnil Napsal: > Joshua Bloch (mj. autor Collections Frameworku) a > Doug Lea (autor java.util.concurrent) mi neprijdou > jako nejaci "konzultanti" Rekl bych, ze dulezite je to spojeni [b]Java konzultanti[/b] a jestli jsem xyz3 pochopil, tak tim chtel poukazat na to, ze teorii operacnich systemu se ucime z monografii na dane tema a teprve kdyz ji zvladame, tak ji konfrontujeme s tim, jak se odrazi v Jave...

Citovat příspěvek

> Pro by w/c melo byt 0 az 1? Kdo rika ze nemuzes
> stravit cekanim 99% casu?

Podle me 99% cekani => 0.99

> Proc by mel byt put<=1?

Protoze nemuzes zatizit prosecor na vice nez 100%

> Kdyz nevis kolik vlaken bude cekat tak ti zadny
> fixed pool nepomuze. To radsi vzit cached pool a
> riskovat ze jich pojede zbytecne moc a sezerou
> hafo pameti a nepojede to nejefektivneji, ale to
> furt muze byt mnohem lepsi nez fixed. K tomu ty
> deadlocky jak uz jsem psal.

To zni logicky

> To je proto že trávíš čas čtením produkce Java
> konzultantů a to nikam nevede, jak ses o tom
> přesvědčil osobně.

Joshua Bloch (mj. autor Collections Frameworku) a Doug Lea (autor java.util.concurrent) mi neprijdou jako nejaci "konzultanti"

> Z hardwarového hlediska podávají nejvyšší výkon
> dvě běžící vlákna na jádro, důkaz je na hodně
> dlouho, ale dá se to změřit a potvrdit empiricky.
> Pojmem běžící se myslí vlákno které něco dělá,
> nikoliv takové které na něco čeká. Na C2D jsou
> optimální cca 4 běžící vlákna, na C2Q cca 8
> běžících vláken, obecně počítej 2-12 vláken.
>
> Logicky z toho vyplývá pokud máš úlohy které na
> nic nečekají, použij něco co má frontu úkolů a ty
> to úkoly distribuuje mezi pevný počet vláken. To
> se nejvíc blíží tvému fixed thread pool.
>
> Situace se dále zesložiťuje s úlohami které na
> něco čekají, třeba na síť, protože jejich chování
> není jasně predikovatelné a předchozí řešení
> nefunguje správně. V takovém případě se vyplatí
> postupně spustit mnoho vláken klidně až 500,
> konkrétní maximální hodnota je závislá na
> konkrétní potřebě. To se nejvíc blíží tvému cached
> thread pool.
>
> Odpověď na tvojí otázku je nyní zřejmá, "cached
> thread pool" se použije tehdy, máš-li úlohy ve
> kterých se na něco dlouho čeká.

Uz v tom mam trochu jasneji. Diky moc. Zakladni problem byl asi v tom, ze jsem tak uplne nepochopil funkci ThreadPoolu jako takoveho. Nedoslo mi, ze kdyz mam 1000 tasku a bezi pro ne 1000 thread, tak se ty thready v behu "spravedlive" stridaji - cachedPool, zatimco kdyz pro ne mam jen 30 Thread - fixedPool, tak se tech 970 dostane ke slovu az po skonceni tech prvnich 30. Navic se ten cachedPool dokaze dynamicky zmensovat pri mensim zatizeni a neplytva zdroji.

> Pro by w/c melo byt 0 az 1? Kdo rika ze nemuzes > stravit cekanim 99% casu? Podle me 99% cekani => 0.99 > Proc by mel byt put<=1? Protoze nemuzes zatizit prosecor na vice nez 100% > Kdyz nevis kolik vlaken bude cekat tak ti zadny > fixed pool nepomuze. To radsi vzit cached pool a > riskovat ze jich pojede zbytecne moc a sezerou > hafo pameti a nepojede to nejefektivneji, ale to > furt muze byt mnohem lepsi nez fixed. K tomu ty > deadlocky jak uz jsem psal. To zni logicky > To je proto že trávíš čas čtením produkce Java > konzultantů a to nikam nevede, jak ses o tom > přesvědčil osobně. Joshua Bloch (mj. autor Collections Frameworku) a Doug Lea (autor java.util.concurrent) mi neprijdou jako nejaci "konzultanti" > Z hardwarového hlediska podávají nejvyšší výkon > dvě běžící vlákna na jádro, důkaz je na hodně > dlouho, ale dá se to změřit a potvrdit empiricky. > Pojmem běžící se myslí vlákno které něco dělá, > nikoliv takové které na něco čeká. Na C2D jsou > optimální cca 4 běžící vlákna, na C2Q cca 8 > běžících vláken, obecně počítej 2-12 vláken. > > Logicky z toho vyplývá pokud máš úlohy které na > nic nečekají, použij něco co má frontu úkolů a ty > to úkoly distribuuje mezi pevný počet vláken. To > se nejvíc blíží tvému fixed thread pool. > > Situace se dále zesložiťuje s úlohami které na > něco čekají, třeba na síť, protože jejich chování > není jasně predikovatelné a předchozí řešení > nefunguje správně. V takovém případě se vyplatí > postupně spustit mnoho vláken klidně až 500, > konkrétní maximální hodnota je závislá na > konkrétní potřebě. To se nejvíc blíží tvému cached > thread pool. > > Odpověď na tvojí otázku je nyní zřejmá, "cached > thread pool" se použije tehdy, máš-li úlohy ve > kterých se na něco dlouho čeká. Uz v tom mam trochu jasneji. Diky moc. Zakladni problem byl asi v tom, ze jsem tak uplne nepochopil funkci ThreadPoolu jako takoveho. Nedoslo mi, ze kdyz mam 1000 tasku a bezi pro ne 1000 thread, tak se ty thready v behu "spravedlive" stridaji - cachedPool, zatimco kdyz pro ne mam jen 30 Thread - fixedPool, tak se tech 970 dostane ke slovu az po skonceni tech prvnich 30. Navic se ten cachedPool dokaze dynamicky zmensovat pri mensim zatizeni a neplytva zdroji.

Citovat příspěvek

Jo, divam se na jinou stranku, ale to je jedno, nic takovyho nevidim ani na jedny z nich. Naopak tohle vypada jako dost low level (viz treba "The callback function can perform a long wait. This flag helps the system to decide if it should create a new thread.").

Jo, divam se na jinou stranku, ale to je jedno, nic takovyho nevidim ani na jedny z nich. Naopak tohle vypada jako dost low level (viz treba "The callback function can perform a long wait. This flag helps the system to decide if it should create a new thread.").

Citovat příspěvek

> a to rozhodne neni ono.

Patrně se díváš na jinou stránku, je to zde: http://msdn.microsoft.com/en-us/library/ms684957(v=vs.85).aspx

> a to rozhodne neni ono. Patrně se díváš na jinou stránku, je to zde: http://msdn.microsoft.com/en-us/library/ms684957(v=vs.85).aspx

Citovat příspěvek

Pisou tam "The method executes when a thread pool thread becomes available." a to rozhodne neni ono.

Pisou tam "The method executes when a thread pool thread becomes available." a to rozhodne neni ono.

Citovat příspěvek

> Nevim jestli jsem to psal, ale ja bych nejradsi pool ktery vytvori novy vlakno
> kdykoliv ma pro nej praci a nejaky jadro se flaka. Ale nic takovyho bohuzel
> neexistuje.

Samozřejmě to existuje, ve Windows je to hotovo od W2K QueueUserWorkItem, ale nevím jestli už to někdo napsal do Javy.

> Nevim jestli jsem to psal, ale ja bych nejradsi pool ktery vytvori novy vlakno > kdykoliv ma pro nej praci a nejaky jadro se flaka. Ale nic takovyho bohuzel > neexistuje. Samozřejmě to existuje, ve Windows je to hotovo od W2K QueueUserWorkItem, ale nevím jestli už to někdo napsal do Javy.

Citovat příspěvek

> Proto mi nebylo vubec jasny k cemu je cachedPool dobrej.

To je proto že trávíš čas čtením produkce Java konzultantů a to nikam nevede, jak ses o tom přesvědčil osobně.

Z hardwarového hlediska podávají nejvyšší výkon dvě běžící vlákna na jádro, důkaz je na hodně dlouho, ale dá se to změřit a potvrdit empiricky. Pojmem běžící se myslí vlákno které něco dělá, nikoliv takové které na něco čeká. Na C2D jsou optimální cca 4 běžící vlákna, na C2Q cca 8 běžících vláken, obecně počítej 2-12 vláken.

Logicky z toho vyplývá pokud máš úlohy které na nic nečekají, použij něco co má frontu úkolů a ty to úkoly distribuuje mezi pevný počet vláken. To se nejvíc blíží tvému fixed thread pool.

Situace se dále zesložiťuje s úlohami které na něco čekají, třeba na síť, protože jejich chování není jasně predikovatelné a předchozí řešení nefunguje správně. V takovém případě se vyplatí postupně spustit mnoho vláken klidně až 500, konkrétní maximální hodnota je závislá na konkrétní potřebě. To se nejvíc blíží tvému cached thread pool.

Odpověď na tvojí otázku je nyní zřejmá, "cached thread pool" se použije tehdy, máš-li úlohy ve kterých se na něco dlouho čeká.

A samozřejmě že v praxi to bývá ještě složitější, protože téměř vždy jsou úlohy namixovány, takže se použije jenom jeden univerzální thread pool, parametrem se specifikuje o jakou úlohu se jedná a thread pool se s tím pak musí nějak poprat.

> Proto mi nebylo vubec jasny k cemu je cachedPool dobrej. To je proto že trávíš čas čtením produkce Java konzultantů a to nikam nevede, jak ses o tom přesvědčil osobně. Z hardwarového hlediska podávají nejvyšší výkon dvě běžící vlákna na jádro, důkaz je na hodně dlouho, ale dá se to změřit a potvrdit empiricky. Pojmem běžící se myslí vlákno které něco dělá, nikoliv takové které na něco čeká. Na C2D jsou optimální cca 4 běžící vlákna, na C2Q cca 8 běžících vláken, obecně počítej 2-12 vláken. Logicky z toho vyplývá pokud máš úlohy které na nic nečekají, použij něco co má frontu úkolů a ty to úkoly distribuuje mezi pevný počet vláken. To se nejvíc blíží tvému fixed thread pool. Situace se dále zesložiťuje s úlohami které na něco čekají, třeba na síť, protože jejich chování není jasně predikovatelné a předchozí řešení nefunguje správně. V takovém případě se vyplatí postupně spustit mnoho vláken klidně až 500, konkrétní maximální hodnota je závislá na konkrétní potřebě. To se nejvíc blíží tvému cached thread pool. Odpověď na tvojí otázku je nyní zřejmá, "cached thread pool" se použije tehdy, máš-li úlohy ve kterých se na něco dlouho čeká. A samozřejmě že v praxi to bývá ještě složitější, protože téměř vždy jsou úlohy namixovány, takže se použije jenom jeden univerzální thread pool, parametrem se specifikuje o jakou úlohu se jedná a thread pool se s tím pak musí nějak poprat.

Citovat příspěvek

Behnil Napsal:
-------------------------------------------------------
> Ja zadnou ulohu nemam, takze nemuzu nic zmerit.
> Nejde mi o konkretni pripad ale o teorii.
>
> V knize Java Concurrency in Practice se pise, ze
> vyssi pocet vytvorenych vlaken nez np * put * (1 +
> (w/c)) nema moc vyznam, jelikoz to uz nicemu
> nepomuze. np je pocet jader, put je cilova mira
> zatizeni systemu (0 az 1), w / c je pomer doby
> mezi cekanim na IO a doby kdy se pocita (0 az 1).
> Proto mi nebylo vubec jasny k cemu je cachedPool
> dobrej.
>
> Ale dobra, spokojim se s tim, ze je to hodne
> individualni a je treba merit.

No ta rovnice je jasna, ale ty nemas zadnou ulohu a tim padem nemas ani nic v ruce, co by rikalo, ze cachedPool je blbost, protoze by to skoncilo az prilis velkym poctem vlaken. Proste ty do ty rovnice vubec nedosazujes a pritom delas zavery. To je chyba. Teoretizovani je pekny, ale pak se to musi podporit experimentem ;)

Behnil Napsal: ------------------------------------------------------- > Ja zadnou ulohu nemam, takze nemuzu nic zmerit. > Nejde mi o konkretni pripad ale o teorii. > > V knize Java Concurrency in Practice se pise, ze > vyssi pocet vytvorenych vlaken nez np * put * (1 + > (w/c)) nema moc vyznam, jelikoz to uz nicemu > nepomuze. np je pocet jader, put je cilova mira > zatizeni systemu (0 az 1), w / c je pomer doby > mezi cekanim na IO a doby kdy se pocita (0 az 1). > Proto mi nebylo vubec jasny k cemu je cachedPool > dobrej. > > Ale dobra, spokojim se s tim, ze je to hodne > individualni a je treba merit. No ta rovnice je jasna, ale ty nemas zadnou ulohu a tim padem nemas ani nic v ruce, co by rikalo, ze cachedPool je blbost, protoze by to skoncilo az prilis velkym poctem vlaken. Proste ty do ty rovnice vubec nedosazujes a pritom delas zavery. To je chyba. Teoretizovani je pekny, ale pak se to musi podporit experimentem ;)

Citovat příspěvek

Pro by w/c melo byt 0 az 1? Kdo rika ze nemuzes stravit cekanim 99% casu?

Proc by mel byt put<=1? Ja si takhle s necim hral co skoro furt pocitalo a vyjimecne cekalo, a osvedcilo se mi odstartovat 6-8 vlaken na 4-jadre, protoze to cekani se semtam sejde a pak je procak zbytecne idle, lepsi bylo ho trochu pretizit.

Takovydle vzorecky jsou tak na dve veci... selskym rozumem je jasny jaky bude vytizeni pri n vlaknech kdy kazdy jede na p procent a z toho se to odvodi. A hned po odvozeni nejlepe ihned zapomene.

Kdyz nevis kolik vlaken bude cekat tak ti zadny fixed pool nepomuze. To radsi vzit cached pool a riskovat ze jich pojede zbytecne moc a sezerou hafo pameti a nepojede to nejefektivneji, ale to furt muze byt mnohem lepsi nez fixed. K tomu ty deadlocky jak uz jsem psal.

Nevim jestli jsem to psal, ale ja bych nejradsi pool ktery vytvori novy vlakno kdykoliv ma pro nej praci a nejaky jadro se flaka. Ale nic takovyho bohuzel neexistuje.

Pro by w/c melo byt 0 az 1? Kdo rika ze nemuzes stravit cekanim 99% casu? Proc by mel byt put<=1? Ja si takhle s necim hral co skoro furt pocitalo a vyjimecne cekalo, a osvedcilo se mi odstartovat 6-8 vlaken na 4-jadre, protoze to cekani se semtam sejde a pak je procak zbytecne idle, lepsi bylo ho trochu pretizit. Takovydle vzorecky jsou tak na dve veci... selskym rozumem je jasny jaky bude vytizeni pri n vlaknech kdy kazdy jede na p procent a z toho se to odvodi. A hned po odvozeni nejlepe ihned zapomene. Kdyz nevis kolik vlaken bude cekat tak ti zadny fixed pool nepomuze. To radsi vzit cached pool a riskovat ze jich pojede zbytecne moc a sezerou hafo pameti a nepojede to nejefektivneji, ale to furt muze byt mnohem lepsi nez fixed. K tomu ty deadlocky jak uz jsem psal. Nevim jestli jsem to psal, ale ja bych nejradsi pool ktery vytvori novy vlakno kdykoliv ma pro nej praci a nejaky jadro se flaka. Ale nic takovyho bohuzel neexistuje.

Citovat příspěvek

Ja zadnou ulohu nemam, takze nemuzu nic zmerit. Nejde mi o konkretni pripad ale o teorii.

V knize Java Concurrency in Practice se pise, ze vyssi pocet vytvorenych vlaken nez [bold]np * put * (1 + (w/c))[/bold] nema moc vyznam, jelikoz to uz nicemu nepomuze. np je pocet jader, put je cilova mira zatizeni systemu (0 az 1), w / c je pomer doby mezi cekanim na IO a doby kdy se pocita (0 az 1). Proto mi nebylo vubec jasny k cemu je cachedPool dobrej.

Ale dobra, spokojim se s tim, ze je to hodne individualni a je treba merit.

Ja zadnou ulohu nemam, takze nemuzu nic zmerit. Nejde mi o konkretni pripad ale o teorii. V knize Java Concurrency in Practice se pise, ze vyssi pocet vytvorenych vlaken nez [bold]np * put * (1 + (w/c))[/bold] nema moc vyznam, jelikoz to uz nicemu nepomuze. np je pocet jader, put je cilova mira zatizeni systemu (0 az 1), w / c je pomer doby mezi cekanim na IO a doby kdy se pocita (0 az 1). Proto mi nebylo vubec jasny k cemu je cachedPool dobrej. Ale dobra, spokojim se s tim, ze je to hodne individualni a je treba merit.

Citovat příspěvek

Čoveče tak si to přečti znova! Vždyť je to jasný jak facka. Když počet těch úloh převyšuje počet vláken v poolu, tak prostě a jasně budou ty další úlohy čekat až se uvolní vlákno - to může trvat i několik sekund v záv. na typu úlohy. To je tak těžký to pochopit? V tom druhým případě se dynamicky pool rozšíří a čekání odpadá. Ten pool i tak pořád znovupoužívá existující vlákna a v případě, že jich je zbytečně moc tak je odstraňuje.

Pokud tvrdíš, že to nepoběží rychleji, tak je to v tvým případě možný (je třeba napsat test a dokázat to), ale teoreticky je celá řada úloh kde to bude rychlejší právě s cachedThreadPoolem.

Je třeba něco vědět, průměrný počty úloh za sekundu, průměrný doby zpracování, jestli je nějaká špička atd., hardware atd. Pak můžeš dojít k závěru, že je pro tebe lepší to zafixovat, ale taky to může dopadnout jinak. Odborník nebude kafrat a radši napíše test, kde je to černý na bílý. Výstupem může být i třeba graf jak pool roste atd.

Jestli máš nějakou šlupku a předpokládáš tisíce vláken, tak ANO zapomeň na to. Můžeš ale klidně dospět k tomu, že s cachedPoolem to bude o X minut rychlejší s tím, že vel. poolu bude nějak oscilovat stylem: 30, 31, 30, 33, 32, 33, 29, ... atd.

Čoveče tak si to přečti znova! Vždyť je to jasný jak facka. Když počet těch úloh převyšuje počet vláken v poolu, tak prostě a jasně budou ty další úlohy čekat až se uvolní vlákno - to může trvat i několik sekund v záv. na typu úlohy. To je tak těžký to pochopit? V tom druhým případě se dynamicky pool rozšíří a čekání odpadá. Ten pool i tak pořád znovupoužívá existující vlákna a v případě, že jich je zbytečně moc tak je odstraňuje. Pokud tvrdíš, že to nepoběží rychleji, tak je to v tvým případě možný (je třeba napsat test a dokázat to), ale teoreticky je celá řada úloh kde to bude rychlejší právě s cachedThreadPoolem. Je třeba něco vědět, průměrný počty úloh za sekundu, průměrný doby zpracování, jestli je nějaká špička atd., hardware atd. Pak můžeš dojít k závěru, že je pro tebe lepší to zafixovat, ale taky to může dopadnout jinak. Odborník nebude kafrat a radši napíše test, kde je to černý na bílý. Výstupem může být i třeba graf jak pool roste atd. Jestli máš nějakou šlupku a předpokládáš tisíce vláken, tak ANO zapomeň na to. Můžeš ale klidně dospět k tomu, že s cachedPoolem to bude o X minut rychlejší s tím, že vel. poolu bude nějak oscilovat stylem: 30, 31, 30, 33, 32, 33, 29, ... atd.

Citovat příspěvek

Nestaci, jinak bych se neptal na foru. Rozdil mezi chachedPool a fixedPool chapu. Co nechapu je, kdy ktery pouzit. Viz

> Ale porad mi bohuzel neni moc jasne, proc bych mel zvolit cachedThreadPool misto > fixedThreadPool s velikosti treba 20(30, 40...). Nepobezi to rychleji, navic je to > pametove narocnejsi a navic tisic Thread souperi o CPU a tim se zpomaluje planovac, > zvetsuje se rezie pro prepinani kontextu atd. (i kdyz treba nepatrne).

Nestaci, jinak bych se neptal na foru. Rozdil mezi chachedPool a fixedPool chapu. Co nechapu je, kdy ktery pouzit. Viz > Ale porad mi bohuzel neni moc jasne, proc bych mel zvolit cachedThreadPool misto > fixedThreadPool s velikosti treba 20(30, 40...). Nepobezi to rychleji, navic je to > pametove narocnejsi a navic tisic Thread souperi o CPU a tim se zpomaluje planovac, > zvetsuje se rezie pro prepinani kontextu atd. (i kdyz treba nepatrne).

Citovat příspěvek

JavaDoc na pochopeni nestaci? :)

Creates a thread pool that creates new threads as needed, but will reuse previously constructed threads when they are available. These pools will typically improve the performance of programs that execute many short-lived asynchronous tasks. Calls to execute will reuse previously constructed threads if available. If no existing thread is available, a new thread will be created and added to the pool. Threads that have not been used for sixty seconds are terminated and removed from the cache. Thus, a pool that remains idle for long enough will not consume any resources. Note that pools with similar properties but different details (for example, timeout parameters) may be created using ThreadPoolExecutor constructors.


V pripade fixedThreadPoolu muze dojit k situaci, ze volne vlakno neni a ceskas.
v pripade cachedThreadPoolu se vytvori novy vlakno a cekat se tak nemusi.

JavaDoc na pochopeni nestaci? :) Creates a thread pool that creates new threads as needed, but will reuse previously constructed threads when they are available. These pools will typically improve the performance of programs that execute many short-lived asynchronous tasks. Calls to execute will reuse previously constructed threads if available. If no existing thread is available, a new thread will be created and added to the pool. Threads that have not been used for sixty seconds are terminated and removed from the cache. Thus, a pool that remains idle for long enough will not consume any resources. Note that pools with similar properties but different details (for example, timeout parameters) may be created using ThreadPoolExecutor constructors. V pripade fixedThreadPoolu muze dojit k situaci, ze volne vlakno neni a ceskas. v pripade cachedThreadPoolu se vytvori novy vlakno a cekat se tak nemusi.

Citovat příspěvek

> Jde o to, že více vláken nemá sloužit jenom k
> tomu, aby se výkon rozdělil mezi těch pár
> procesorů/jader, které máš k dispozici, ale aby se
> také zjednodušilo naprogramování celé aplikace.

Jasne, s tim se neda nez souhlasit. Ja take nerikam, ze bych tech tisic aut nevytvoril jako tisic tasku. Ale porad mi bohuzel neni moc jasne, proc bych mel zvolit cachedThreadPool misto fixedThreadPool s velikosti treba 20(30, 40...). Nepobezi to rychleji, navic je to pametove narocnejsi a navic tisic Thread souperi o CPU a tim se zpomaluje planovac, zvetsuje se rezie pro prepinani kontextu atd. (i kdyz treba nepatrne).

> Jde o to, že více vláken nemá sloužit jenom k > tomu, aby se výkon rozdělil mezi těch pár > procesorů/jader, které máš k dispozici, ale aby se > také zjednodušilo naprogramování celé aplikace. Jasne, s tim se neda nez souhlasit. Ja take nerikam, ze bych tech tisic aut nevytvoril jako tisic tasku. Ale porad mi bohuzel neni moc jasne, proc bych mel zvolit cachedThreadPool misto fixedThreadPool s velikosti treba 20(30, 40...). Nepobezi to rychleji, navic je to pametove narocnejsi a navic tisic Thread souperi o CPU a tim se zpomaluje planovac, zvetsuje se rezie pro prepinani kontextu atd. (i kdyz treba nepatrne).

Citovat příspěvek

> [ital]Kdyz na dany problem pouziju fixedPool omezeny cca na 10 vlaken tak preci dosahnu cca stejne efektivity, navic s mensi pametovou narocnosti.[/ital]

Az tech 10 aut bude cekat az jinych 10 projede a ty budou cekat na volny vlakno, taxe ti fixed pool prestane libit.

Pro tohle by byl idelani pool co by daval rekneme 10 neblokovanych vlaken pro ty 4 jadra. To aby bylo s rezervou porad co delat a aby to zbytecne moc nezralo.

> [ital]Potřebuješ-li simulovat provoz ve městě s tisíci aut, musíš k tomu mít příslušně vybavený počítač.[/ital]

Ja bych rekl ze 1000 aut nic neni a ze by to melo jet na kazdy stary herce. Pokud se ovsem rozhodnes pouzit pro kazdy z nich vlastni vlakno, tak to muze byt problem - nevim kolik pameti si sezere kazdy z nich a nevim jaky to ma jinak overhead ale mohlo by to byt prilis.

Navic 1000 aut nic neni, to je vetsi vesnice. Skoro bych doporucil resit to jinak, ale to uz je OT.

> [ital]Kdyz na dany problem pouziju fixedPool omezeny cca na 10 vlaken tak preci dosahnu cca stejne efektivity, navic s mensi pametovou narocnosti.[/ital] Az tech 10 aut bude cekat az jinych 10 projede a ty budou cekat na volny vlakno, taxe ti fixed pool prestane libit. Pro tohle by byl idelani pool co by daval rekneme 10 neblokovanych vlaken pro ty 4 jadra. To aby bylo s rezervou porad co delat a aby to zbytecne moc nezralo. > [ital]Potřebuješ-li simulovat provoz ve městě s tisíci aut, musíš k tomu mít příslušně vybavený počítač.[/ital] Ja bych rekl ze 1000 aut nic neni a ze by to melo jet na kazdy stary herce. Pokud se ovsem rozhodnes pouzit pro kazdy z nich vlastni vlakno, tak to muze byt problem - nevim kolik pameti si sezere kazdy z nich a nevim jaky to ma jinak overhead ale mohlo by to byt prilis. Navic 1000 aut nic neni, to je vetsi vesnice. Skoro bych doporucil resit to jinak, ale to uz je OT.

Citovat příspěvek

Potřebuješ-li simulovat provoz ve městě s tisíci aut, musíš k tomu mít příslušně vybavený počítač.

Jde o to, že více vláken nemá sloužit jenom k tomu, aby se výkon rozdělil mezi těch pár procesorů/jader, které máš k dispozici, ale aby se také zjednodušilo naprogramování celé aplikace.

Budeš-li řešit zmíněnou simulaci, bylo by asi zbytečně složité navrhovat, kdy bude které jádro řešit další chování toho kterého auta. V řadě případů bývá jednodušší definovat Jednoduchý program specifikující obecné chování jednoho účastníka a pak ten program spustit paralelně v tolika vláknech, kolik je účastníků. Musíš jenom správně ošetřit vzájemné interakce a sdílení zdrojů.

Virtuální stroj pak bude mít na starosti, jak ta vlákna spouštět na jednotlivých procesorech/jádrech, která máš právě k dispozici. Ty se přitom při definici programu vůbec nemusíš starat, kolik jich bude mít počítač, na němž to poběží. Když to bude dobře naprogramované, poběží to stejně dobře na jednoprocesorovém nebo tisíciprocesorovém stroji.

Pro jistotu, aby nevznikl omyl: stejně dobře neznamená stejně rychle.

Potřebuješ-li simulovat provoz ve městě s tisíci aut, musíš k tomu mít příslušně vybavený počítač. Jde o to, že více vláken nemá sloužit jenom k tomu, aby se výkon rozdělil mezi těch pár procesorů/jader, které máš k dispozici, ale aby se také zjednodušilo naprogramování celé aplikace. Budeš-li řešit zmíněnou simulaci, bylo by asi zbytečně složité navrhovat, kdy bude které jádro řešit další chování toho kterého auta. V řadě případů bývá jednodušší definovat Jednoduchý program specifikující obecné chování jednoho účastníka a pak ten program spustit paralelně v tolika vláknech, kolik je účastníků. Musíš jenom správně ošetřit vzájemné interakce a sdílení zdrojů. Virtuální stroj pak bude mít na starosti, jak ta vlákna spouštět na jednotlivých procesorech/jádrech, která máš právě k dispozici. Ty se přitom při definici programu vůbec nemusíš starat, kolik jich bude mít počítač, na němž to poběží. Když to bude dobře naprogramované, poběží to stejně dobře na jednoprocesorovém nebo tisíciprocesorovém stroji. Pro jistotu, aby nevznikl omyl: stejně dobře neznamená stejně rychle.

Citovat příspěvek

Hmm, ale co kdyz tech aut muze byt radove stovky az tisice. K cemu mi bude pouziti cachedPoolu kdyz mam 4 jadra? I kdyby se casto cekalo na IO, tak se muze (vcetne cekani na IO) obsluhovat jen par vlaken soucasne. Navic prepinami kontextu take neco sezere. Z hlediska efektivity mi pouziti cachedPool neni vubec jasne. Kdyz na dany problem pouziju fixedPool omezeny cca na 10 vlaken tak preci dosahnu cca stejne efektivity, navic s mensi pametovou narocnosti.

Hmm, ale co kdyz tech aut muze byt radove stovky az tisice. K cemu mi bude pouziti cachedPoolu kdyz mam 4 jadra? I kdyby se casto cekalo na IO, tak se muze (vcetne cekani na IO) obsluhovat jen par vlaken soucasne. Navic prepinami kontextu take neco sezere. Z hlediska efektivity mi pouziti cachedPool neni vubec jasne. Kdyz na dany problem pouziju fixedPool omezeny cca na 10 vlaken tak preci dosahnu cca stejne efektivity, navic s mensi pametovou narocnosti.

Citovat příspěvek

Neomezovaný počet vláken se používá tehdy, pokud daná aplikace vysloveně potřebuje, aby všechny vlákna běžela současně a přitom je z nějakých vnějších omezení jisté, že se počet vláken uklidní v nějakém dynamicky rovnovážném stavu.

Takové situace nastane např. když simuluješ provoz ve městě a v tvém programu je každé auto reprezentované vlastním vláknem. Nemůžeš dopředu odhadnout, kolik aut v daném okamžiku ve městě bude, ale je předem jasné, že se jich tam víc než nějaký počet nevejde. Každé auto, které přijíždí do města nafasuje vlastní vlákno, které odevzdá při opuštění města, aby je nafasoval jiný příchozí.

Výhoda je, že nemusíš přemýšlet nad tím, kolik bys měl dovolit současně spuštěných vláken. Navíc bys pak musel počítat i se stavem, kdy se vše zacpe a z tvého města se stane jedno velké parkoviště. Při dynamicky vytvářených vláknech víš, že se zabere právě tolik paměti, kolik jí bude doopravdy potřeba.

Staticky nastavovaný počet vláken zvolíš tehdy, pokud buď dopředu přesně víš, kolik vláken bude potřeba, anebo pokud nebude moc vadit, když nějaký proces bude muset chvíli počkat, než se pro něj uvolní vlákno, v němž pak bude běžet a spotřeba paměti je pro tebe v danou chvíli důležitější než ono čekání na uvolnění vlákna.

Neomezovaný počet vláken se používá tehdy, pokud daná aplikace vysloveně potřebuje, aby všechny vlákna běžela současně a přitom je z nějakých vnějších omezení jisté, že se počet vláken uklidní v nějakém dynamicky rovnovážném stavu. Takové situace nastane např. když simuluješ provoz ve městě a v tvém programu je každé auto reprezentované vlastním vláknem. Nemůžeš dopředu odhadnout, kolik aut v daném okamžiku ve městě bude, ale je předem jasné, že se jich tam víc než nějaký počet nevejde. Každé auto, které přijíždí do města nafasuje vlastní vlákno, které odevzdá při opuštění města, aby je nafasoval jiný příchozí. Výhoda je, že nemusíš přemýšlet nad tím, kolik bys měl dovolit současně spuštěných vláken. Navíc bys pak musel počítat i se stavem, kdy se vše zacpe a z tvého města se stane jedno velké parkoviště. Při dynamicky vytvářených vláknech víš, že se zabere právě tolik paměti, kolik jí bude doopravdy potřeba. Staticky nastavovaný počet vláken zvolíš tehdy, pokud buď dopředu přesně víš, kolik vláken bude potřeba, anebo pokud nebude moc vadit, když nějaký proces bude muset chvíli počkat, než se pro něj uvolní vlákno, v němž pak bude běžet a spotřeba paměti je pro tebe v danou chvíli důležitější než ono čekání na uvolnění vlákna.

Citovat příspěvek

Pokud cekaji na IO, a procesor se flaka, tak pokud je co pocitat tak se i vyrazne vic vlaken uzivi. Ale pokud hlavni brzda je IO, tak nepomuzou.

Pokud cekaji na IO, a procesor se flaka, tak pokud je co pocitat tak se i vyrazne vic vlaken uzivi. Ale pokud hlavni brzda je IO, tak nepomuzou.

Citovat příspěvek

Ahoj, mohl by mi prosim nekdo rici proc (a pripadne kdy) pouzit cached thread pool misto fixed thread pool? Oba thread pooly jsou vytvareny statickymi metodami ve tride java.util.concurrent.Executors.

Pokud mam napr. 4 jadra, tak i kdyby vetsi cas vypoctu stravila vlakna cekanim na IO, je mi vytvareni cca 9 a vice Thread k nicemu, protoze se tim vypocet stejne nezefektivni ne?

Ahoj, mohl by mi prosim nekdo rici proc (a pripadne kdy) pouzit cached thread pool misto fixed thread pool? Oba thread pooly jsou vytvareny statickymi metodami ve tride java.util.concurrent.Executors. Pokud mam napr. 4 jadra, tak i kdyby vetsi cas vypoctu stravila vlakna cekanim na IO, je mi vytvareni cca 9 a vice Thread k nicemu, protoze se tim vypocet stejne nezefektivni ne?

Citovat příspěvek