Vyznam dual core

[THX]

lenze to je stale zle - lebo ty precitas, medzitym ti to niekto zmeni a potom zapises staru hodnotu. Ak chces data modifikovat, musis to mat zamknute cele v kuse. Naopak - ak chces data iba precitat a potom ich dalej nemodifikovat, staci ti overit, ci v momente citania ich nema niekto iny zamknute (zamykat nemusis).

[Fox!MURDER]

lenze to je stale zle - lebo ty precitas, medzitym ti to niekto zmeni a potom zapises staru hodnotu. Ak chces data modifikovat, musis to mat zamknute cele v kuse. Naopak - ak chces data iba precitat a potom ich dalej nemodifikovat, staci ti overit, ci v momente citania ich nema niekto iny zamknute (zamykat nemusis).

jenze tomu uz se vubec neda rikat lock-free. napr. tenhle kus kodu by pak bezel stejne dobre/spatne(+nejakej drobnej overhead na ty mutexy) na dc i sc ...

Edit: krom toho mi to fakt neprijde prilis prevratny ... v databazich se takovejhle pristup pouziva uz roky ...
navic dalsi vec je, ze kdyz pracujes s vetsima blokama dat, nebo napr. scenama tak pri cteni stejne musis zamknout proti zapisu celou scenu, protoze kdyz jen zkontrolujes, ze neni zamceno, muze te v nasledujicim taktu preemptnout jinej thread, zamknout a zapsat. ty uz mas zkontrolovano a tudiz vpohode ctes zmeneny data....

[THX]

jenze tomu uz se vubec neda rikat lock-free. napr. tenhle kus kodu by pak bezel stejne dobre/spatne(+nejakej drobnej overhead na ty mutexy) na dc i sc ...

tak tam daj tym threadom pocitat nejaku funkciu, napr. 10x sinus alebo nieco take a skus to pustit raz so zamkami a raz bez, ze o kolko sa to bude lisit v rychlosti

Edit: krom toho mi to fakt neprijde prilis prevratny ... v databazich se takovejhle pristup pouziva uz roky ...
navic dalsi vec je, ze kdyz pracujes s vetsima blokama dat, nebo napr. scenama tak pri cteni stejne musis zamknout proti zapisu celou scenu, protoze kdyz jen zkontrolujes, ze neni zamceno, muze te v nasledujicim taktu preemptnout jinej thread, zamknout a zapsat. ty uz mas zkontrolovano a tudiz vpohode ctes zmeneny data....

Kontrolu na lock a precitanie musis urobit atomicky. Alebo mozes spravit read-only lock. Teda ze sice je zamknute, ale citat moze kolko chce threadov naraz. V praxi thread, ktory chce menit data ich naprv zamkne, potom precita, potom nad nimi urobi nejaky vypocet (tento byva o dost dlhsi ako cas citania/zapisu) a nakoniec zapise vysledky. Preto "zapisovacie" locky trvaju omnoho dlhsie a teda dlhsiu dobu blokuju paralelizmus. Alebo - ak nevadi ze pocas vypoctu spracuvaju ostatne thready stare udaje, tak si na zaciatku moze data precitat aj z read-only locku a zamykat iba pri konecnom zapise.

[Fox!MURDER]

tak tam daj tym threadom pocitat nejaku funkciu, napr. 10x sinus alebo nieco take a skus to pustit raz so zamkami a raz bez, ze o kolko sa to bude lisit v rychlosti


Kontrolu na lock a precitanie musis urobit atomicky. Alebo mozes spravit read-only lock. Teda ze sice je zamknute, ale citat moze kolko chce threadov naraz.

to bych musel vymyslet nejakou mnohem slozitejsi konstrukci a nebo to merit v us ... coz se mi fakt moc nechce ... si hraj chvili ty ...

udelat atomicky fci, ktera nad 10MB scenou pocita napr. odlesky si dost dobre atomicky nedovedu predstavit.

[THX]

to bych musel vymyslet nejakou mnohem slozitejsi konstrukci a nebo to merit v us ... coz se mi fakt moc nechce ... si hraj chvili ty ...

udelat atomicky fci, ktera nad 10MB scenou pocita napr. odlesky si dost dobre atomicky nedovedu predstavit.

atomicky robis iba dvojicu (kontrola na lock + precitanie). A tiez samozrejme atomicky zamykas.

Zlozitejsiu konstrukciu robit vobec nemusis, staci ked das medzi citanie a zapis nejaku fuknciu, ktora dlho trva (napr. 100x spocitat sinus alebo nieco take), alebo snad aj sleep(1). Myslim ze v linuxe je nejaky prikaz time (alebo tak nejak), ktory vie zistit ako dlho bezal proces.

Ide len o to, zmerat aky velky overhead znamena zamykanie.

[Fox!MURDER]

atomicky robis iba dvojicu (kontrola na lock + precitanie). A tiez samozrejme atomicky zamykas.

Zlozitejsiu konstrukciu robit vobec nemusis, staci ked das medzi citanie a zapis nejaku fuknciu, ktora dlho trva (napr. 100x spocitat sinus alebo nieco take), alebo snad aj sleep(1). Myslim ze v linuxe je nejaky prikaz time (alebo tak nejak), ktory vie zistit ako dlho bezal proces.

Ide len o to, zmerat aky velky overhead znamena zamykanie.

JENZE! kdyz potrebujes konzistentni scenu, tak si bud musis udelat atomicky kopii xMB dat, coz te stoji cas a pamet, nebo udelat atomicky celej ten proces, nebo to proste zamknout.

[THX]

JENZE! kdyz potrebujes konzistentni scenu, tak si bud musis udelat atomicky kopii xMB dat, coz te stoji cas a pamet, nebo udelat atomicky celej ten proces, nebo to proste zamknout.

no ale to len ak by si tie odlesky pocital v jednej fukncii. Tiez by si to mohol spravit nejak tak (i ked neviem ako presne) ze by kazda fukncia pocitala iba odlesk jedneho objektu. Na zaciatku vsetky thready si nacitaju informacie o svojich objektoch, spocitaju paralelne a nakoniec zapisu pomocou zamkov. Ide len o to, ci to ma zmysel takto rozkladat - teda o kolko sa predlzi zapis koli zamykaniu oproti zrychleniu sposobenemu paralelnym vypoctom.

Nechajme to na kona - ten ma vacsiu hlavu. Alebo este na valve. Az bude vydana ta hra, tak uvidime. Ale myslim ze quaka sa im tiez do istej miery podarilo paralelizovat, tak by som netvrdil ze sa to valve nepodari tiez.