| Zobrazit předchozí téma :: Zobrazit následující téma |
| Autor |
Zpráva |
Matasx
Založen: 17. 08. 2008
Příspěvky: 258
|
 Zaslal: 16. prosinec 2009, 20:45:58 Předmět: C# - rychlost |
 |
|
Zdravím všechny. Udělal jsem si takový malý test v C#. Dvourozměrné pole se strukturou (float,float,float). Procházím všechny prvky a nad každou strukturou provedu 3 FPU operace (např. 3 vynásobení dvou čísel). Při "rozlišení" 800x600 se dostanu na 5 průchodů celým polem za vteřinu (5fps). Z toho mi (ať počítám jak počítám) vychází: 800*600*3*5 = 7 200 000 (?FLOPS?). Samozřejmě jsou mezitím nějaké režijní operace (nějaký ten mov, add, inc a bůh ví co tam .NET ještě nabastlí). - Toto na i7 pouze na jednom jádru. Někde na netu sem našel že i7 extreme na 3.2GHz má 70 GFLOPS. Proto se mi to zdá trochu málo. A nebo je to ok?
Ještě přiložím kód.
| kód: |
Col[,] array = new Col[width, height];
...
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++;
}
}
}
...
struct Col
{
public float a;
public float b;
public float c;
public Col(float a, float b, float c)
{
this.a = a;
this.b = b;
this.c = c;
}
}
|
Naposledy upravil Matasx dne 16. prosinec 2009, 21:34:27, celkově upraveno 1 krát |
|
| Návrat nahoru |
|
 |
Deluxe
Založen: 31. 07. 2007
Příspěvky: 235
Bydliště: Oslavany
|
| Zaslal: 16. prosinec 2009, 21:22:17 Předmět: |
|
|
| Ja myslim ze se to takhle neda rict, tech 70 GFLOPS bude urcite teoretickej vypocetni vykon. Tady ti muze system napr. pozastavit vlakno nebo dalsich 1000 veci. Spis bych to porovnaval se stejnym kodem v C/C++ nebo jinym nativnim jazykem. |
|
| Návrat nahoru |
|
|
Marek
Založen: 28. 07. 2007
Příspěvky: 1782
Bydliště: Velká Morava
|
| Zaslal: 16. prosinec 2009, 21:40:31 Předmět: |
|
|
Yep, zkus to samý napsat v C/C++.
Do teoretického výkonu se může počítat využití všech jader a všech dostupných instrukčních sad (zejména poslední verze SSE).
_________________
AMD Open Source Graphics Driver Developer |
|
| Návrat nahoru |
|
|
Matasx
Založen: 17. 08. 2008
Příspěvky: 258
|
| Zaslal: 16. prosinec 2009, 21:51:06 Předmět: |
|
|
No takže výsledky (1 440 000 operací):
C# - 192 až 200 ms
C - 190 až 197 ms
Takže rozdíl žádný. A není těch 7 200 000 operací opravdu nějak málo?  |
|
| Návrat nahoru |
|
|
JohnyDog
Založen: 17. 08. 2007
Příspěvky: 66
|
| Zaslal: 16. prosinec 2009, 22:30:18 Předmět: |
|
|
| Matasx napsal: |
No takže výsledky (1 440 000 operací):
C# - 192 až 200 ms
C - 190 až 197 ms
Takže rozdíl žádný. A není těch 7 200 000 operací opravdu nějak málo? |
Tak to ukaz ten C kod, takovy pruchod polem by mel byt podstatne rychlejsi. Samozrejme optimalizace jsou zaklad, misto dvourozmerneho pole pointeru pouzij jednorozmerne pole a indexuj do nej, misto floatu double atd.
_________________
 |
|
| Návrat nahoru |
|
|
Matasx
Založen: 17. 08. 2008
Příspěvky: 258
|
|
| Návrat nahoru |
|
|
Mantharis
Založen: 28. 07. 2007
Příspěvky: 39
|
| Zaslal: 16. prosinec 2009, 22:48:10 Předmět: |
|
|
Jedno nebo vice rozmerny pole pointru je imho irelevantni co se vlivu na vykon tyka...prekladac ty pole optimalizuje ze to vyjde ve vysledku na stejno a naopak tim ze se pouzije "pruhlednejsi" zdrojak tam tim spis nad tim prekladac vymysli nejakou "hezkou" optimalizaci
_________________
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: 16. prosinec 2009, 22:59:51 Předmět: |
|
|
Jednorozměrný / dvourozměrný, float / double - to je bezpředmětný. To na výkon vliv nemá. A přepisem do čistýho ASM bude výsledek IMHO taky stejnej.
No proč to vlastně řeším. - Stále sem nepustil z hlavy ten raytraincing (jestli si někdo třeba ještě matně vzpomíná). Tak TEORETICKY, když přídám ještě 3 jádra, dostanu 20fps. A stále to znamená že barvu pixelu musím získat nanejvýš pomocí tří  FPU operací. A to se tu vůbec nebavím o nějakém vykreslování toho pole na obrazovku. Takže buďto je celá tahle úvaha uplně špatně (čili mám tam něco uplně špatně) - což asi jo a nebo nejde napsat realtime raytracer (800x600) pro i7  A nebo ten počet operací pro získání barvy pixelu stačí (a to pochybuju).
EDIT: taková drobnost, kterou jsem přehlídl ... mam na i7 zaplý HT (tedy virtuálně 8 jader), zatížení 13% odpovídá vytížení půljádra tím pádem. (nejspíš). |
|
| Návrat nahoru |
|
|
JohnyDog
Založen: 17. 08. 2007
Příspěvky: 66
|
| Zaslal: 16. prosinec 2009, 23:10:04 Předmět: |
|
|
u me jeden pruchod te while() smycky trva <1msec (okolo 4 msec bez zapnutych optimalizaci)
_________________
|
|
| Návrat nahoru |
|
|
Matasx
Založen: 17. 08. 2008
Příspěvky: 258
|
| Zaslal: 16. prosinec 2009, 23:12:09 Předmět: |
|
|
Co znamenají optimalizace?
A C nebo C# ?
Všiml jsem si že když dám pryč ten cyklus tak poprvé se to provede za 4ms a pak už kolem těch 200ms ... nechápu. |
|
| Návrat nahoru |
|
|
JohnyDog
Založen: 17. 08. 2007
Příspěvky: 66
|
| Zaslal: 16. prosinec 2009, 23:15:30 Předmět: |
|
|
| Mantharis napsal: |
| Jedno nebo vice rozmerny pole pointru je imho irelevantni co se vlivu na vykon tyka...prekladac ty pole optimalizuje ze to vyjde ve vysledku na stejno a naopak tim ze se pouzije "pruhlednejsi" zdrojak tam tim spis nad tim prekladac vymysli nejakou "hezkou" optimalizaci |
Jak chces aby ti kompiler zoptimalizoval pristupy do pameti pres dva pointery ? Z hlediska L2 cache to bude dost hruza.
| citace: |
Co znamenají optimalizace?
A C nebo C# ?
Všiml jsem si že když dám pryč ten cyklus tak poprvé se to provede za 4ms a pak už kolem těch 200ms ... nechápu. |
C. Mozna bude problem v mereni pres clock(), pokud mas cpu ktere ti dynamicky meni frekvenci tak bych pouzil spis gettimeofday() (nebo nejaky windows ekvivalent pokud neni, queryperformancecounter atd.)
_________________
|
|
| Návrat nahoru |
|
|
Matasx
Založen: 17. 08. 2008
Příspěvky: 258
|
| Zaslal: 16. prosinec 2009, 23:20:03 Předmět: |
|
|
| Jo vidíš, to mě nenapadlo, po pár cyklech se "zařadí další převod"... ale to neřeším, těch 200 ms je i v C vzhledem k frekvenci výpisu odpovídající. |
|
| Návrat nahoru |
|
|
JohnyDog
Založen: 17. 08. 2007
Příspěvky: 66
|
| Zaslal: 16. prosinec 2009, 23:27:03 Předmět: |
|
|
| Matasx napsal: |
| Jo vidíš, to mě nenapadlo, po pár cyklech se "zařadí další převod"... ale to neřeším, těch 200 ms je i v C vzhledem k frekvenci výpisu odpovídající. |
Co je to za kompiler ?
Dalsi veci co me napada je ze tam porad nasobis, takze behem par cyklu se dostanes na +Infinity u vsech prvku, ale to by nemelo mit vliv.
_________________
|
|
| Návrat nahoru |
|
|
Matasx
Založen: 17. 08. 2008
Příspěvky: 258
|
| Zaslal: 16. prosinec 2009, 23:30:52 Předmět: |
|
|
V kompileru to taky není. Poslal jsem exe zkompilované u mě kámošovi a ten na zastaralém AMD hlásí 16 nebo 32... tak už mě napadá jen problém zvaný Vista.
EDIT: a nebo vypnout swap.
EDIT2: swapem to taky není. Uvidím až vyměním OS za W7 - pokud do té doby nezjistím čím to je. |
|
| Návrat nahoru |
|
|
Marek
Založen: 28. 07. 2007
Příspěvky: 1782
Bydliště: Velká Morava
|
| Zaslal: 16. prosinec 2009, 23:47:18 Předmět: |
|
|
Jak jsi to kompiloval? Tj: Jaká byla konfigurace projektu? Jaké jsi použil optimalizace kompilátoru? Link-time code generation? Bez SSE nebo s SSE1/2? Máš zapnutý frame pointer? Co třeba Buffer Security Check a použitý Floating Point Model?
Bez těchto informací je celý test k ničemu. Základní konfigurace projektu (Debug) může klidně dát 10x pomalejší kód.
Clock nepoužívej, použij performance counter.
_________________
AMD Open Source Graphics Driver Developer |
|
| Návrat nahoru |
|
|
|
Hlavní strana
FAQ
Test
Hledat
Seznam uživatelů
Uživatelské skupiny
Registrace
Ke Stažení
Nastavení
Přihlášení
Calendar
