Zpět na článek

Diskuze: Technologie: Fully Buffered FB-DIMM

Nejsi přihlášený(á)

Pro psaní a hodnocení komentářů se prosím přihlas ke svému účtu nebo si jej vytvoř.

Rychlé přihlášení přes:

tomasjerry
tomasjerry
Level Level
19. 5. 2004 16:34

Komentáře tohoto uživatele máš zablokované.

Vas "pohovor" bol v celku zaujimavy, konecne bolo co citat, ale kto dnes vyuziva klasicke C++? To by ma zaujimalo !

tief
tief
Level Level
16. 5. 2004 14:55

Komentáře tohoto uživatele máš zablokované.

"Me je uplne jedno cim si dela AMD reklamu" - ??? O jaké reklamě to mluvíš? Já tvrdím, že AMD vstupuje do oficiálních statistik uznávaných průmyslových benchmarků s kódem optimalizovaným konkurenčním Intel C++ Compiler, který optimalizuje pro procesory Intel. I v tomto případě tento kompilátor optimalizující pro jiné procesory je schopen vyprodukovat jeden z nejlepších kódů pro AMD.

"dobre je to videt na koderech videa kde jeden program jede rychle­ na intelu a pomalu na amd a druhy program kde je to opacne !" - Tak to bohužel není. Procesory jsou si v mnoha ohledech velmi podobné a rozdíly výkonu jsou často dány pouze hrubým výpočetním výkonem - velikost a rychlost cache, organizace pipeline, podporovaný typ vektorizování, rychlost pamětí... Už jsem několik věcí zkompiloval, abych mohl s klidem prohlásit, že Intel C++ Compiler produkuje perfektní kód nejen pro Intel procesory, ale i pro AMD. Kdyby byla pravda, že procesory jsou zcela jiné, výsledkem by byl naopak pokles výkonu pro procesory AMD.

"jenom si podle me ne­ma cenu hrat s kazdou instrukci, mnohem ucinnejsi je vymyslet optimalne­jsi algoritmus" - absolutní nesmysl. Správné řazení instrukcí je jeden z klíčových faktorů výkonu moderních superskalárních procesorů. Často je mnohem rychlejší vykonat paralelizovně více výpočtů než méně na sobě závislých. To samé platí pro threading a vektorizování (čtyřnásobná SIMD operace je mnohem rychlejší než čtyřikrát x86). Dnes nelze programovat způsobem, jak se to dělalo pro 486ky. A jen pro zajímavost - Itanium 2 je silně vázáno na optimalizace kompilátoru, protože kompilátor u tohoto procesoru je určujícím prvkem paralelizace v rámci výpočetních jednotek.

tief
tief
Level Level
15. 5. 2004 22:03

Komentáře tohoto uživatele máš zablokované.

Zajímavé, že AMD vstupuje do oficiálních statistik průmyslových testů s kódem kompilovaným pomocí Intel C++ Compiler. A taky zvláštní, že i u jiných zdrojáků produkuje Intel C++ Compiler nejrychlejší kód ze všech kompilátorů i v případě AMD. Něco na té optimalizaci asi bude...

"takove to reseni a optimalizovani­ na dve veci, vime ?" - zjevně nevíš.

PetrProchy
PetrProchy
Level Level
14. 5. 2004 23:04

Komentáře tohoto uživatele máš zablokované.

Mit SW fimu, tak te beru vsema deseti, ty se rozhodne vyplatis;-):-D...

tief
tief
Level Level
14. 5. 2004 15:44

Komentáře tohoto uživatele máš zablokované.

Dobrá, přejdeme k tykání.

Ad PHP - zvláštní, že řada diskuzních fór, které nejsou zrovna nenáročné (např. fórum na PCtuning zatěžuje procesor asi 2x víc než časopis jako takový), pořád jede na PHP a o přechodu jinam se neuvažuje.

Solidní programátor musí udělat program, který vytvoří rychle, ale nebude přemrštěně náročný na hardware a bude spolehlivý. Jestli ty programuješ jinak, neznamená to, že každý se drží tohohle (Což mi připomíná našeho učitele na programování, který je zděšen odchovanci PHP, kteří mu v kursu C++ ani neumí udělat while cyklus... holt ne všichni umí při programování myslet).

"stejne kdyz to neni pole houby vis kde to v pameti je" - moc si toho evidentně nenaprogramoval, protože kdyby jo, věděl bys, že céčkový kompilátor (např. Visual C++) dává statické proměnné na stejné úrovni kódu (globální, funkčně lokální) v paměti ihned vedle sebe a to bez ohledu na to, zda je to pole nebo ne. Jestli nevěříš, tak se povídej na adresy pointerů. Nevím, jak bys chtěl data optimalizovat na velikost nebo rychlost. Optimalizuje se uspořádání a typ instrukcí, inlining funkcí, vektorování, uspořádání dat v paměti.

"a co kolik trva cyklu­ bych neresil vubec" - naštěstí v Microsoftu i Intelu tohle řeší, takže jejich kompilátory produkují s každou verzí vždy o něco rychlejší kód.

tief
tief
Level Level
14. 5. 2004 14:51

Komentáře tohoto uživatele máš zablokované.

Tak to je opravdu vtipné - nepoužívají se z pohodlnosti. Možná v nějakém amatérském klubu, ale aspoň trochu solidní programátor volí proměnné podle toho, co do nich bude potřebovat dát. Síla A64 nespočívá jenom v 64bit proměnných, ale především ve více registrech. Ostatně násobení 64bit čísel trvá 4 cykly, kdežto 32bit čísel jenom tři cykly. Jenom blb by používal všude proměnné největších velikostí. Osobně jsem 64bit integer potřeboval jen málokdy, nevím, proč bych ho měl cpát všude. A k dynamickým proměnným - to si vážně myslíte, že vytvoření a následná destrukce dynamické proměnné je stejně paměťově náročná jako u statických?

tief
tief
Level Level
14. 5. 2004 13:14

Komentáře tohoto uživatele máš zablokované.

A co třeba typová kontrola? To není potřeba? Když s proměnnými zacházíte jako s dynamickými, máte obrovský performance hit, protože procesory tahají celé bloky dat a ne jednotlivé proměnné. Jenže dynamické proměnné jsou roztroušeny po paměti, kdežto statické jsou pěkně u sebe. Pro přístup k dynamickým proměnným je potřeba mnohem více výpočetních zdrojů. Toť k efektivitě PHP.

Ad potřeba RAM - Vám zase nedošlo, že 64bit CPU umí pracovat i s 8bit, 16bit a 32bit proměnnými a že zaplácnuté místo závisí na použitém typu proměnných. Větší paměť je potřeba na pointery, to uznávám.

PS: Autor má rád jazyky jako C++.

zdeneksoft
zdeneksoft
Level Level
11. 5. 2004 12:50

Komentáře tohoto uživatele máš zablokované.

Popis nové technologie se Vám skutečně povedl. Jen tak dál.

Rafan
Rafan
Level Level
11. 5. 2004 10:51

Komentáře tohoto uživatele máš zablokované.

Teda musím říci že se překonáváte ale mám obavu že v článcích tohoto ražení se běžný fanda začne už pomalu ztrácet, včetně mě.Některé části článku jsem musel číst 2x protože mi nebylo úplně jasné co to vlastně čtu :-)Ale třeba jsem pomaleji chápající a tak to berte s rezervou :-)))

Reklama
Reklama