Vyznam dual core

[Eagle]

2 THX: Fakt mám čím dál tím víc pocit, že jsi nikdy nic neprogramoval. Poukazování na to, že zápis = zamčeno, je neskutečná hloupost. Kdyby šlo jen o čtení, tak se jedná o zcela nezávislé záležitosti, u kterých by se žádná synchronizace nemusela řešit, a tedy by nebyl potřeba žádný zámek. Takových situací ale jistě nebude mnoho. Protože kdyby bylo, tak je multithreading legrace.

A k té reakci na PiTa - už tady kolikrát zaznělo, že AI, fyzika a rendering jsou čistě sériové záležitosti, neboť nemůžeš renderovat něco, o čem nevíš, jak se bude pohybovat. Pokud to někdo dělá nezávisle, tak to vede ke zhoršení výstupní kvality. Hodláš-li operovat se slovy typu "Valve to zvladli", tak laskavě dokaž, jak si to zvládnutí představuješ reálně provedené tak, aby to nebyla z nouze ctnost. Řeknu ti to samé co Petrikovi - pokud chceš, abychom se nadále nad tímto tématem bavili, přednes tady konkrétní programátorská řešení, jak bys to udělal. Kecy stažené z webu mě nezajímají, protože programátoři by samozřejmě nikdy veřejně nepřiznali, že jimi provedený multithreading je za cenu snížení kvality - u kodeku H.264 to taky běžně neříkají, protože to není věc, kterou by se mohli chlubit.


Uff, mám pocit, že jedině Fox!MURDER tady ví, o co kráčí.


PS: Samozřejmě, že mě zajímá to, co je výhodné pro mě. Co je dobré pro tebe, je mi úplně fuk. Tohle je kapitalismus, společnost preferující individualismus a vlastní užitek.

[THX]

2 THX: Fakt mám čím dál tím víc pocit, že jsi nikdy nic neprogramoval. Poukazování na to, že zápis = zamčeno, je neskutečná hloupost. Kdyby šlo jen o čtení, tak se jedná o zcela nezávislé záležitosti, u kterých by se žádná synchronizace nemusela řešit, a tedy by nebyl potřeba žádný zámek. Takových situací ale jistě nebude mnoho. Protože kdyby bylo, tak je multithreading legrace.

Ale ved tam ti prave ludia od valve pisu, ze takychto situacii, kedy sa len cita je 95% a zamykanie (a teda nemoznost paralelneho spracovania) nastava iba v 5% pripadov.

A k té reakci na PiTa - už tady kolikrát zaznělo, že AI, fyzika a rendering jsou čistě sériové záležitosti, neboť nemůžeš renderovat něco, o čem nevíš, jak se bude pohybovat. Pokud to někdo dělá nezávisle, tak to vede ke zhoršení výstupní kvality.

pozri - valve dokaze pri renderingu paralelne pocitat pohlady z roznych kamier, efekty atd. A nie nemam ti to ako dokazat, pretoze k zdrojakom sa asi v zivote nedostanem. Snad ked vyjde ta hra, tak si ju budes moct obenchmarkovat na jednom a na viacerych jadrach.

Hodláš-li operovat se slovy typu "Valve to zvladli", tak laskavě dokaž, jak si to zvládnutí představuješ reálně provedené tak, aby to nebyla z nouze ctnost.

ty si tu prezentoval jeden nazor (zalozeny na nespravnom pochopeni, ze locking nepouzivaju a teda u nich dochadza k strate integrity dat) a prezentujes ho ako spravny. Dokaz mi, ze to valve robi prave tak ako si napisal. Pozri si ten clanok znova - tam je dost do podrobna napisane, ako to spravili, ako a preco ktore veci paralelizovali.

Řeknu ti to samé co Petrikovi - pokud chceš, abychom se nadále nad tímto tématem bavili, přednes tady konkrétní programátorská řešení, jak bys to udělal. Kecy stažené z webu mě nezajímají, protože programátoři by samozřejmě nikdy veřejně nepřiznali, že jimi provedený multithreading je za cenu snížení kvality - u kodeku H.264 to taky běžně neříkají, protože to není věc, kterou by se mohli chlubit.

To mi pride ako keby sa tajilo, ze audio/video kodeky su stratovou kompresiou. Stoji ta strata kvality za to? Ano, stoji to zrychlenie enkodingu za to, ano.

Tiez by som mohol napisat:
Kecy nejakeho eagla stazene z webu (napr. tvoje recenzie), alebo z fora nemusia tiez kazdeho zaujimat, protože eagle by samozřejmě nikdy veřejně nepřiznal, že se mohl mylit.

A co sa tyka dokazov - urobme to naopak. Ty mi dokaz, ze niektore veci NIE JE MOZNE multithreadovat.

PS: Samozřejmě, že mě zajímá to, co je výhodné pro mě. Co je dobré pro tebe, je mi úplně fuk. Tohle je kapitalismus, společnost preferující individualismus a vlastní užitek.

Mozno ta prekvapim, ale tohne neni kapitalizmus, toto je overclocker a enthusiast diskusne forum, kde tvoje prispevky citaju aj iny ludia ako ty, a niekedy niektorych nemusi zaujimat iba ze pre teba je DC na hovno, a ze v tvojich programoch to nejde dobre vyuzit a ze ty si ekonom a kapitalista atd.
Prave diskusia (a prispevky do nej) by mala byt taka, aby citatel ziskal po precitani nove informacie (a nie iba niecie osobne nazory a postoje).

[Eagle]

Ale ved tam ti prave ludia od valve pisu, ze takychto situacii, kedy sa len cita je 95% a zamykanie (a teda nemoznost paralelneho spracovania) nastava iba v 5% pripadov.

95 nezávislých + 5 závislých situací != 100 situací s 5% pravděpodobností závislosti

pozri - valve dokaze pri renderingu paralelne pocitat pohlady z roznych kamier, efekty atd.

To možná ano, ale na to už potřebuješ mít hotovou fyziku, která je sériová.

si ju budes moct obenchmarkovat na jednom a na viacerych jadrach.

Benchmark ti řekne jen výkon. Pokud tento není za jinak stejných okolností (což třeba u WinRARu není), pak je výsledek zavádějící.

To mi pride ako keby sa tajilo, ze audio/video kodeky su stratovou kompresiou. Stoji ta strata kvality za to? Ano, stoji to zrychlenie enkodingu za to, ano.

Mně ne, já vždycky preferuju co nejvyšší kvalitu. Proto mám třeba hardware takový, jaký mám - novější totiž obsahuje více chyb, což mi za ten dodatečný výkon nestojí. Až je vychytají, bude upgrade. Do té doby nic.

A co sa tyka dokazov - urobme to naopak. Ty mi dokaz, ze niektore veci NIE JE MOZNE multithreadovat.

Už jsem ti tady uváděl příklad s fyzikou ve hře. Logickou posloupnost akcí v tomto případě nelze změnit (... protože je to podobné jako priorita operátorů v matematickém příkladě).

kapitalista atd.

Nejsem kapitalista. To jen na okraj.

Prave diskusia (a prispevky do nej) by mala byt taka, aby citatel ziskal po precitani nove informacie (a nie iba niecie osobne nazory a postoje).

Ano, to získal. Ale ne od vás, protože vy se jen oháníte větami typu "jde to, támhle Pepa to umí". Už ale nedokážete zdůvodnit, jak je to možné. Jen názory převzaté z webu, ale logická posloupnost vesměs žádná. Nikdo tady nebyl schopen zodpovědět, jak by bylo možné počítat fyziku ve hře paralelně s renderingem scény.

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.

S tím se dá jakž takž souhlasit (ty odlesky by nesměly ovlivňovat jeden druhý, což ale asi nelze zaručit - např. odlesk postavy o vodní hladinu na skleněnou zeď, na kterou svítí ještě něco), ale bohužel tohle není paralelismus, který by ti přinesl nějaké obrovské množství výkonu navíc. Jenom kdybys měl hodně objektů, mohlo by ti to něco dát, ale to řádově tak pár desítek procent navíc IMHO. Mimochodem, není tohle náhodou věc, kterou dělá grafická karta?

[swarm]

Mno....koukám, že vás to tu ještě stále nepustilo...někteří z vás (většina?) si tu představuje programování her asi jako Hurvínek válku, tak si myslim, že ta diskuze je úplně bezpředmětná. Nebo tu snad někdo programoval nějakou hru? Klidně se přihlašte. Tady vám nikdo hlavu neutrhne .

Popravdě jsem myslel, že horší diskuze než když se baví vývojáři o sexu už být nemůže. Ale když se baví nadšenci do overclockingu o programování her, tak je to možná ještě slabší .

[Fox!MURDER]

Mno....koukám, že vás to tu ještě stále nepustilo...někteří z vás (většina?) si tu představuje programování her asi jako Hurvínek válku, tak si myslim, že ta diskuze je úplně bezpředmětná. Nebo tu snad někdo programoval nějakou hru? Klidně se přihlašte. Tady vám nikdo hlavu neutrhne .

Popravdě jsem myslel, že horší diskuze než když se baví vývojáři o sexu už být nemůže. Ale když se baví nadšenci do overclockingu o programování her, tak je to možná ještě slabší .

buhuheheh dobrej postreh ...

nahodou, ja ted budu do skoly programovat damu. a just to napisu multithreadove

[MadCap]

buhuheheh dobrej postreh ...

nahodou, ja ted budu do skoly programovat damu. a just to napisu multithreadove

pozor aby si to s tym AI neprehnal a nemusel si na to potom pouzivat quad core procesor! Jedno jadro by to predsa nemohlo zvladnut popri vsetkom co k tomu patri (DX10 grafika je snad samozrejma nie?)

[Anduril]

pozor aby si to s tym AI neprehnal a nemusel si na to potom pouzivat quad core procesor! Jedno jadro by to predsa nemohlo zvladnut popri vsetkom co k tomu patri (DX10 grafika je snad samozrejma nie?)

Ja bych mel spise strach, aby hraci vubec hru dokoncili tak, jak maji. Zvlaste kdyby kazdy hrac mel jedno vlakno >:} By pak jeden hrac mohl skakat pres jineho, ale ten uz by tam nebyl. Ale jinak tady vidim idealni vyuziti dualcore - co hrac, to vlakno. Na clovece nezlob se v plnem obsazeni uz to chce quad core

[Fox!MURDER]

pozor aby si to s tym AI neprehnal a nemusel si na to potom pouzivat quad core procesor! Jedno jadro by to predsa nemohlo zvladnut popri vsetkom co k tomu patri (DX10 grafika je snad samozrejma nie?)

no, nevim, jesli java umi DX10 a stejnak grafiku dela nekdo jinej. ja mam nastarosti to AI ...

MadCap: vsak AI by melo bejt 'tunable' ... a je fakt, ze s damou by nemel bejt problem vytizit klidne 10 jader ...

Anduril: a co teprv model 'co kamen, to jadro' nebo 'co policko na hraci desce, to jadro'

[swarm]

nahodou, ja ted budu do skoly programovat damu. a just to napisu multithreadove

No, minulý semestr jsem měl do jednoho předmětu taky hru (C, OpenGL) a využít jednoho jádra na procesoru a jednoho na grafický kartě myslim zrovna úplně stačilo .

[Petrik]

No jisteee, napsal jsem tetris v textovym rezimu v turbo pascalu Mimochodem, co si o tom pripravovanym valve engine myslis ty?

Mno....koukám, že vás to tu ještě stále nepustilo...někteří z vás (většina?) si tu představuje programování her asi jako Hurvínek válku, tak si myslim, že ta diskuze je úplně bezpředmětná. Nebo tu snad někdo programoval nějakou hru? Klidně se přihlašte. Tady vám nikdo hlavu neutrhne .

Popravdě jsem myslel, že horší diskuze než když se baví vývojáři o sexu už být nemůže. Ale když se baví nadšenci do overclockingu o programování her, tak je to možná ještě slabší .

[swarm]

Mimochodem, co si o tom pripravovanym valve engine myslis ty?

Mno, já jsem teda nic kolem toho nečetl (ani momentálně na to nemám nějak čas) a tento thread jsem si prolítl dost rychle. Četl jsem o tom jenom tu novinku na cdr. Nevim jestli to bylo překladem a nebo z toho novinkář něco vytratil, ale takhle mi to připomělo svou vypovídací hodnotou marketingový kecy na PR slajdech nVidie.

[Rainbow]

O tych hrach (a o sexe ) by bolo vhodne zalozit novy thread.
Uz je tu poriadny bordel a rozdelit to poriadne nejde, tak aby sa to nemuselo zamknut.

[THX]

Tak v suvislosti s hernymi enginami ma napada pouzit pipelining podobne ako u procesorov. Napr. ak mam dvojjadrovy procesor, tak pustim herny engine 2x, jeden pocita parne, jeden neparne snimky.
Niekedy priblizne v polke vypoctu a renderingu prveho snimku by sa precital vstup od usera pre druhy snimok, ktory by spocitalo (a dalo renderovat) druhe jadro. Ked by bolo toto druhe jadro priblizne v polke vypoctu, prve uz dokoncilo cely snimok a moze znova nacitat vstup a zacat kreslit dalsi frame.

[swarm]

Tak jsem nadhodil téma i jinde, na jistě úrodnější půdě...

http://www.ceskehry.cz/forum/viewtopic.php?t=4791

[šaman]

To možná ano, ale na to už potřebuješ mít hotovou fyziku, která je sériová.

Mohl by mi nekdo vysvetlit, proc se tu po několikáté "fyzika" uvažuje jako nevhodná k paralelizování?
Podle mych informaci leží budoucnost (a vlastně už i současnost-Havoc,Ageia) simulace mechaniky (i te herni) v MBS(MultiBodySystem). A MBS je problematika,pro jejiz reseni je paralelizace velmi vyhodna.

[PiT]

THX:

Ten clanok som si cital, nemusis mi to tu prekladat. Kecy su to pekne ale jedina ukazka su tam tie videa. Pekne to tam okecavaju ale to je asi tak vsetko. Preco tam neukazali nieco realne? Ved ta hra ma vyjst o dva mesiace, gold musi byt o par tyzdnov skor...

Ak mi niekto povie, ze AI v HL2 je dobra, tak sa len zasmejem. Kvalitu nahradzali kvantitou, vsetky tie coop postavy boli naskriptovani blbci. Q3 obdobne, v D3 vylepsene, no stale obdobne. Slusna AI je imho v UnrealTournamente.

Fyziku mal HL2 dobru, ale tu som nespominal.

Ako chces paralelizovat koliznu scenu? Bez lockov velmi tazko. Jedine, ze by vymysleli nejake algoritmy, ktore rychlo pred vypoctom odhadnu nejaky kluc, na zaklade ktoreho by rozdelili scenu - a to dost pochybujem, pretoze by to sice mozno v 90% pripadov bolo rychlejsie, no v 10%ach by sa to bud rozsypalo alebo to bolo vyrazne pomalsie ako na SC... Pripadne by ani zdaleka nebolo vyuzitych viac jadier.

[edit]

Kamerovy pohlad tej istej sceny spolahlivo neparalelizujes pokial nebude kazde jadro pocitat cast udajov 2x. (a hadaj ktoru - prave koliznu, ktora zabera drvivu vacsinu casu aj na SC)

[THX]

THX:
Ten clanok som si cital, nemusis mi to tu prekladat. Kecy su to pekne ale jedina ukazka su tam tie videa. Pekne to tam okecavaju ale to je asi tak vsetko. Preco tam neukazali nieco realne? Ved ta hra ma vyjst o dva mesiace, gold musi byt o par tyzdnov skor...

Ja myslim ze nechceli ukazovat viac z hry pred vydanim. Ak su tak skoro k dokonceniu, tiez by si mohol nadavat, ze preco este nevyslo demo.

Ak mi niekto povie, ze AI v HL2 je dobra, tak sa len zasmejem. Kvalitu nahradzali kvantitou, vsetky tie coop postavy boli naskriptovani blbci. Q3 obdobne, v D3 vylepsene, no stale obdobne. Slusna AI je imho v UnrealTournamente.

ja len tvrdim, ze AI je v hl2 "gro hry". V q3 nejaka ai skoro vobec nebola, lebo hra bola viac multiplayerovo zamerana. Snad teraz ked bude k dispozicii vyssi vykon pre AI (vdaka paralelizacii a dalsim jadram) sa to zlepsi. Inac single player hry prave koli nizkej AI velmi nehram. Tych blbeckov z HL2 co blokuju chodby som vzdy okamzite postrielal nech nezavadzaju (teda - ak to v danom mieste dovoloval skript ich pozabijat).

Ako chces paralelizovat koliznu scenu? Bez lockov velmi tazko. Jedine, ze by vymysleli nejake algoritmy, ktore rychlo pred vypoctom odhadnu nejaky kluc, na zaklade ktoreho by rozdelili scenu - a to dost pochybujem, pretoze by to sice mozno v 90% pripadov bolo rychlejsie, no v 10%ach by sa to bud rozsypalo alebo to bolo vyrazne pomalsie ako na SC... Pripadne by ani zdaleka nebolo vyuzitych viac jadier.

ale ved predsa oni zamykanie pouzivaju...

[edit]
Kamerovy pohlad tej istej sceny spolahlivo neparalelizujes pokial nebude kazde jadro pocitat cast udajov 2x. (a hadaj ktoru - prave koliznu, ktora zabera drvivu vacsinu casu aj na SC)

Povedal by som, ze pohlad z kamery je vec, ktora nejak velmi nemodifikuje objekty na ktore sa pozera. Prave preto si viem predstavit ze dva rozne jadra pocitaju pohlady z dvoch roznych kamier. Ak by si tie jadra nemal dva, tak single core by ti tak ci tak muselo spocitat pohlad z tej druhej kamery.

[PiT]

Ja myslim ze nechceli ukazovat viac z hry pred vydanim. Ak su tak skoro k dokonceniu, tiez by si mohol nadavat, ze preco este nevyslo demo.

Skor si myslim, ze je to preto, lebo tu ich dokonalu paralelizaciu poznas v novej hre len vdaka efektom ako ten dazd a ked to portujes na HL2 a EP1, tak tam bude narast podobny ako u Q4 = max 10-25%, imho skor este mensi.

ja len tvrdim, ze AI je v hl2 "gro hry".

A to je imho to, co bez odrbov neparalelizujes. Odrby = naskriptovanost. Naskriptovanost != AI.

Snad teraz ked bude k dispozicii vyssi vykon pre AI (vdaka paralelizacii a dalsim jadram) sa to zlepsi. Inac single player hry prave koli nizkej AI velmi nehram. Tych blbeckov z HL2 co blokuju chodby som vzdy okamzite postrielal nech nezavadzaju (teda - ak to v danom mieste dovoloval skript ich pozabijat).

jj, AI tam takmer nebola... a ta, co bola, tu imho neparalelizujes

ale ved predsa oni zamykanie pouzivaju...

hej, ale prave to zamykanie ti z principu spravi z vyhody viacerych threadov nevyhodu, lebo bude vypocty predlzovat a zvysne jadra sa budu flakat. Tych 95% lock-free pripadov moze snad nastat iba v pripade, ze hovoria cisto o ich "skript-AI".

Povedal by som, ze pohlad z kamery je vec, ktora nejak velmi nemodifikuje objekty na ktore sa pozera. Prave preto si viem predstavit ze dva rozne jadra pocitaju pohlady z dvoch roznych kamier. Ak by si tie jadra nemal dva, tak single core by ti tak ci tak muselo spocitat pohlad z tej druhej kamery.

Ak ma kamera ukazovat to, co sa deje na scene, tak musi pred tym nasledovat vypocet koliznej sceny, ktory ti zaberie drvivu vacsinu vypocetneho casu, a ktory imho spolahlivo neparalelizujes, nakolko by si musel pri tej paralelizacii bud urcit presne hranice objektov alebo sa Ti moze lahko stat, ze cez seba dva objekty na scene preletia. Ak to chces pocitat poctivo, tak proste 80-100% narast vykonu s dvoma a viac jadrami nedosiahnes, preto som napisal, ze su to pekne okecavacky.

[THX]

No ale este moze nastat situacia, ze tie dve kamery nevidia tu istu scenu a pre tu druhu mozno teda pocitat kolizie paralelne.

[PiT]

No ale este moze nastat situacia, ze tie dve kamery nevidia tu istu scenu a pre tu druhu mozno teda pocitat kolizie paralelne.

....

... ale sa snazia paralelizovat a tym urychlit veci, ktore tam pridavaju - len niektore efekty (dazd, obrazovky na scene a pod). O AI a pod. su tam iba "vzrusene" dristy, ziadne dokazy (a prave AI je jedna z veci, kde ma Valve imho velke rezervy).

[Fox!MURDER]

Uff, mám pocit, že jedině Fox!MURDER tady ví, o co kráčí.

Zas me prilis neprecenuj. S threadama mam zkusenosti jen minimalni (v C a par skriptovacich jazycich - napr. perl) a hru jsem taky zadnou nenapsal. Spis se na to snazim koukat 'selskym rozumem' a vnest do toho trochu vlastni invence.
Zrovna ted mi vrta hlavou jak by byly realizovatelny ty transakce (hlavne transakcni izolace) na pametovy urovni.


THX: vis ten problem s tema zamkama je trosku jinej. ono totiz nepotrebujes zamky jen pri zapisu. pokud mas scenar takovej ze mas napr. dva thready, ktery posouvaj bod po obrazovce, muze nastat nasledujici situace

#include <stdio.h>
#include <pthread.h>
#include <stdlib.h>
int a=0;
int b=0;
pthread_mutex_t mut_a = PTHREAD_MUTEX_INITIALIZER;
pthread_mutex_t mut_b = PTHREAD_MUTEX_INITIALIZER;

void *f_thread1(void *);
void *f_thread2(void *);
int main(void)
{
     pthread_t thread1, thread2;
     int  iret1, iret2;
     int  i1=1,i2=2;
     iret1 = pthread_create( &thread1, NULL, f_thread1, (void*) i1 );
     iret2 = pthread_create( &thread2, NULL, f_thread2, (void*) i2 ) ;
     pthread_join( thread1, NULL);
     pthread_join( thread2, NULL);

     printf("a = %d\n",a);
     printf("b = %d\n",b);
     exit(0);
}


void *f_thread1(void *q){
 int x=0;
 for(x=0;x<65535;x++)
 {
        int temp1, temp2;
        {
#ifdef WHOLELOCK
                pthread_mutex_lock(&mut_a);
                pthread_mutex_lock(&mut_b);
#endif
                temp1=a+1;
                temp2=b+1;
#ifndef WHOLELOCK
                pthread_mutex_lock( &mut_b);
#endif
                b=temp2;
#ifndef WHOLELOCK
                pthread_mutex_unlock(&mut_b);
                pthread_mutex_lock(&mut_a);
#endif
                a=temp1;
#ifndef WHOLELOCK
                pthread_mutex_unlock(&mut_a);
#endif
#ifdef WHOLELOCK
                pthread_mutex_unlock(&mut_a);
                pthread_mutex_unlock(&mut_b);
#endif
        }
 }
}
void *f_thread2(void *q){
 int x=0;
 for(x=0;x<65535;x++)
 {
        int temp1, temp2;
        {
#ifdef WHOLELOCK
                pthread_mutex_lock(&mut_a);
                pthread_mutex_lock(&mut_b);
#endif
                temp1=a-1;
                temp2=b-1;
#ifndef WHOLELOCK
                pthread_mutex_lock( &mut_b);
#endif
                b=temp2;
#ifndef WHOLELOCK
                pthread_mutex_unlock(&mut_b);
                pthread_mutex_lock(&mut_a);
#endif
                a=temp1;
#ifndef WHOLELOCK
                pthread_mutex_unlock(&mut_a);
#endif
#ifdef WHOLELOCK
                pthread_mutex_unlock(&mut_a);
                pthread_mutex_unlock(&mut_b);
#endif
         }
 }
}

livecd ~ # gcc -pthread threadtest.c -DWHOLELOCK -o tt-wholelock
livecd ~ # gcc -pthread threadtest.c -o tt-nowholelock
livecd ~ # ./tt-nowholelock
a = 429
b = 702
livecd ~ # ./tt-wholelock
a = 0
b = 0
livecd ~ # ./tt-wholelock
a = 0
b = 0
livecd ~ # ./tt-wholelock
a = 0
b = 0
livecd ~ # ./tt-wholelock
a = 0
b = 0
livecd ~ # ./tt-wholelock
a = 0
b = 0
livecd ~ # ./tt-nowholelock
a = 181
b = 73
livecd ~ # ./tt-nowholelock
a = 340
b = -61
livecd ~ # ./tt-nowholelock
a = -4862
b = 333
livecd ~ # ./tt-nowholelock
a = 588
b = 257
livecd ~ #

tj. jeden thread posouva ten bod (klidne to muze bejt v pripade 3D treba kvadr, nebo neco jinyho) o 1 doprava a o 1 nahoru, druhej posouva bod o 1 doleva a o 1 dolu. kazdej z nich to udela 65536krat. tj. bod by mel ve vysledku skoncit na miste, kde zacal (pravej dolni roh napr.) jenze, kdyz zamykam jen pri zapisu, ejhle ... ono to skonci na uplne nepredvidanym miste.


a jeste dodam, ze to samozrejme dosti podobne kravi i na singlecore
(testuju na C2D E6300 a CeleronuD 325, oboje Gentoo s nptl a gcc 4.1)


kdyby nekdo mel problem s pochopenim toho C kodu, tak dejte vedet, ja to vysvetlim...

jooo a vim ze by to asi slo napsat jednodusejs a prehlednejs, ale a) jsem prase, b) nemam cas si s tim tak moc hrat

[PiT]

Fox!MURDER:

Teraz som zvedavy ako by pomohlo to optimalizovanie kompileru, ktore THX navrhoval par stran dozadu

[Fox!MURDER]

Fox!MURDER:

Teraz som zvedavy ako by pomohlo to optimalizovanie kompileru, ktore THX navrhoval par stran dozadu

no, v tomhle ohledu si pockame, s cim intel prijde treba vytahnou neco, ze nam vsem padne celist, treba ne ...

[THX]

pit - ten kompiler ma optimalizovat iba rychlost, teda ma hladat v kode "paralelizovatelne" casti a tie sa snazit pustat naraz - neopravuje chyby v programe

Fox: vsetky locky/unlocky mas v ifndef, teda ked nedas WHOLELOCK, tak nezamykas vobec - ani pri zapise. Navyse - niekedy zamykas/odomykas znova uz zamknutu/odomknutu vec (snad to nevadi, ale nemalo by sa )

[Fox!MURDER]

pit - ten kompiler ma optimalizovat iba rychlost, teda ma hladat v kode "paralelizovatelne" casti a tie sa snazit pustat naraz - neopravuje chyby v programe

Fox: vsetky locky/unlocky mas v ifndef, teda ked nedas WHOLELOCK, tak nezamykas vobec - ani pri zapise. Navyse - niekedy zamykas/odomykas znova uz zamknutu/odomknutu vec (snad to nevadi, ale nemalo by sa )

jsou tam ifdef a ifndef ... zcela spravne a zcela umyslne ...