Zobrazit předchozí téma :: Zobrazit následující téma |
Autor |
Zpráva |
Mantharis
Založen: 28. 07. 2007 Příspěvky: 39
|
Zaslal: 17. prosinec 2009, 00:00:14 Předmět: |
|
|
citace: |
Jak chces aby ti kompiler zoptimalizoval pristupy do pameti pres dva pointery ? Z hlediska L2 cache to bude dost hruza. |
Ted sem na tenkym lede tak se nechci hadat, ale mam pocit ze
pristup na pole[i][m] a pak na pole[i][m+1]
a
pole[i*size+m] a pak pole[i*size+m+1]
z hlediska cache miss i ostatnich veci vyjde na stejno, nebo pokud ne tak proc? _________________ If the God gave us the source code we could bug the world. |
|
Návrat nahoru |
|
 |
Matasx
Založen: 17. 08. 2008 Příspěvky: 258
|
Zaslal: 17. prosinec 2009, 00:12:56 Předmět: |
|
|
Kompiler GCC. Vyzkoušel jsem různe optimalizace, snad všechny kombinace všeho (i SSE 2) a stejně je maximum jaký z toho vydojim 160 ms. |
|
Návrat nahoru |
|
 |
Marek

Založen: 28. 07. 2007 Příspěvky: 1782 Bydliště: Velká Morava
|
Zaslal: 17. prosinec 2009, 00:14:14 Předmět: |
|
|
Čím víc dereferencování, tím hůř.
int p[64][64]; //rychlý přístup
int p[63][63]; //trochu pomalejší, ale stále dost rychlý
int **p; // dvojnásobná dereference, velká šance na L2 cache miss.
Ten tvůj test jsem tady zkusil a dává mi to 3.5ms, takže máš blbě nastavenej projekt.
EDIT: Včetně -O3 ? Je to 64bit GCC? Zkus použít gettimeofday, clock není tak přesný. _________________ AMD Open Source Graphics Driver Developer |
|
Návrat nahoru |
|
 |
wozembouch
Založen: 03. 09. 2007 Příspěvky: 31
|
Zaslal: 17. prosinec 2009, 00:24:28 Předmět: |
|
|
K tomu kodu ...
... nedochazi tam nahodou k "Floating point overflow" ? |
|
Návrat nahoru |
|
 |
Matasx
Založen: 17. 08. 2008 Příspěvky: 258
|
Zaslal: 17. prosinec 2009, 00:29:16 Předmět: |
|
|
Eosie napsal: |
int p[64][64]; //rychlý přístup
int p[63][63]; //trochu pomalejší, ale stále dost rychlý
|
Asi jsem slepý ale nevidím rozdíl.
wozembouch: asi jo, ale až po nějaké době, o to nejde. |
|
Návrat nahoru |
|
 |
wozembouch
Založen: 03. 09. 2007 Příspěvky: 31
|
Zaslal: 17. prosinec 2009, 00:30:46 Předmět: |
|
|
mne to vychazi po 4 pruchodech ...
6:18:108
1944:209952:408146688
85691213438976:3,49745849558191E22:2,9970146243887E36
1,04819342594515E59:3,1414510267457E95:3,29284831416348E154 |
|
Návrat nahoru |
|
 |
Matasx
Založen: 17. 08. 2008 Příspěvky: 258
|
Zaslal: 17. prosinec 2009, 00:36:12 Předmět: |
|
|
wozembouch: aha tak jsi na to kápl. Změnil jsem inicializaci na (0.1, 0.5, 0.9) a už to dává 4 ms. Tak ale nechápu co má i7 za problémy s tím přetečením :-/ Díky. |
|
Návrat nahoru |
|
 |
Matasx
Založen: 17. 08. 2008 Příspěvky: 258
|
Zaslal: 17. prosinec 2009, 00:39:23 Předmět: |
|
|
Takže teď jsem na 2000*2000*3*27 = 324 000 000 operacich za vterinu na pulce jadra. Tak to už zní líp. |
|
Návrat nahoru |
|
 |
wozembouch
Založen: 03. 09. 2007 Příspěvky: 31
|
Zaslal: 17. prosinec 2009, 00:44:50 Předmět: |
|
|
... jinak mne to dela pri 1680x1050 cca 40fps
(pod Delphi na lehce obstaroznim Athlonu 4800) |
|
Návrat nahoru |
|
 |
Matasx
Založen: 17. 08. 2008 Příspěvky: 258
|
Zaslal: 17. prosinec 2009, 00:59:11 Předmět: |
|
|
No ještě dodám že pod C#
kód: |
for (int i = 0; i != width; i++)
{
for (int j = 0; j != height; j++)
{
array[i, j].a = array[i, j].c * array[i, j].b;
array[i, j].b = array[i, j].a * array[i, j].c;
array[i, j].c = array[i, j].a * array[i, j].b;
}
}
|
=> 56 fps
kód: |
Col* arrayPtr = null;
for (int i = 0; i != width; i++)
{
fixed (Col* ptr = &array[i, 0])
{
arrayPtr = ptr;
for (int j = 0; j != height; j++)
{
arrayPtr->a = (arrayPtr->b) * (arrayPtr->c);
arrayPtr->b = (arrayPtr->a) * (arrayPtr->c);
arrayPtr->c = (arrayPtr->a) * (arrayPtr->b);
arrayPtr++;
}
}
}
|
=> 250 fps |
|
Návrat nahoru |
|
 |
Deluxe

Založen: 31. 07. 2007 Příspěvky: 235 Bydliště: Oslavany
|
Zaslal: 17. prosinec 2009, 08:41:09 Předmět: |
|
|
Takze jsem to projel AMD CodeAnalystem, ten zakladni kod.
S tou L2 cache to asi nebude tak horky:
kód: |
for (int j = 0; j != height; j++)
{
arrayPtr->a = (arrayPtr->b) * (arrayPtr->c); // Tady bylo z 8136 L2 requestu 348 L2 misses
arrayPtr->b = (arrayPtr->a) * (arrayPtr->c); // 121 / 17
arrayPtr->c = (arrayPtr->a) * (arrayPtr->b); // 115 / 4
arrayPtr++;
}
|
Casove nejak takhle:
kód: |
for (int j = 0; j != height; j++)
{
arrayPtr->a = (arrayPtr->b) * (arrayPtr->c); // 17,16 % samplu
arrayPtr->b = (arrayPtr->a) * (arrayPtr->c); // 33,7 %
arrayPtr->c = (arrayPtr->a) * (arrayPtr->b); // 31,76 %
arrayPtr++;
}
|
V ASM to vypada asi takhle (VS 2008 - Zakladni Konzolovej projekt - DEBUG)
kód: |
arrayPtr->a = (arrayPtr->b) * (arrayPtr->c);
Ret inst L2 fill/write L2 requests L2 misses
mov eax,[ebp-5ch] 860 138 0 0
fld dword [eax+04h] 229 148 3 0
mov ecx,[ebp-5ch] 2658 802 461 253
fmul dword [ecx+08h] 1064 120 1684 0
mov edx,[ebp-5ch] 15233 1280 5986 94
fstp dword [edx] 486 96 2 1
|
|
|
Návrat nahoru |
|
 |
Ladis

Založen: 18. 09. 2007 Příspěvky: 1537 Bydliště: u Prahy
|
|
Návrat nahoru |
|
 |
nou

Založen: 28. 07. 2007 Příspěvky: 1050
|
|
Návrat nahoru |
|
 |
Matasx
Založen: 17. 08. 2008 Příspěvky: 258
|
Zaslal: 17. prosinec 2009, 11:19:26 Předmět: |
|
|
ladis: koukal jsem na video na youtube a nezdá se mi to kdoví jak pěkný... http://www.youtube.com/watch?v=Y5GteH4q47s Ale možná je to volbou materiálů, anebo optimalizacema (nic moc se tam neleskne, stínů je tam taky poskromnu a vypadá to prázdně).
nou: už jsem byl poučen, že obecný raytracer na GPU napsat nelze (a jaktože ani takhle malá scéna není vyladělá, aby to šlo plynule?) |
|
Návrat nahoru |
|
 |
Mantharis
Založen: 28. 07. 2007 Příspěvky: 39
|
Zaslal: 17. prosinec 2009, 14:26:32 Předmět: |
|
|
citace: |
jaktože ani takhle malá scéna není vyladělá, aby to šlo plynule? |
Kdyz sem koukal na to video tak je tam videt i kaustika u ty skleneny koule...to znamena krome vlastniho ray-tracingu pocitat i path/light tracing coz jsou v obecnym pripade jeste o rad narocnejsi tracingy...takze jestli to bezi na par snimkach za vterinu s kaustikama (a nejsou nejak smeleny...coz dost mozna jsou ) tak bez nich by to mohlo bezet real-time. _________________ If the God gave us the source code we could bug the world. |
|
Návrat nahoru |
|
 |
|