Diskuze: Vzorky Phenomu FX již v říjnu

Uživatel bez registrace

Level 1

16. 9. 2007 14:58

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

@Uživatel bez registrace To je právě problém...DNES ne. Ale než výjde 3GHz Phenom, tak už tu dávno budou 3,33GHz 45nm C2D a podobně taktované C2Q.
A pokud se podíváš na anandtech, tak k10 je v aplikacích pro desktop při stejném taktu jen asi o 5-20% rychlejší, než K8 . Tzn má ipc podobné jako Conroe, pokud budeme hodně optimističtí, tak jako wolfdale. A ten má startovat na frekvencích přes 3 GHz a ne se jen k nim pomalu propracovávat.
Když si to dáš dohromady, tak narozdíl od serveru, kde se k10 může lépe škálovat ve více procesorech než Conroe, v desktopu rozhodně nepřekoná intel a budeme rádi, pokud aspoň někde dorovná.
- ptipi

Uživatel bez registrace

Level 1

16. 9. 2007 15:37

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

@Uživatel bez registrace @ptipi: Samozřejmě ten nárůst výkonu proti K8 je větší u SSE instrukcí, kde byla stejně jako u Core 2 zdvojnásobená šířka na 128bitů. V tom serverovém testu na Anandtechu se to projevilo, nevím, proč ne v tom "desktopu" Asi tam nebyly žádné SSE kódy? WTF?
- Jan Olšan

Uživatel bez registrace

Level 1

17. 9. 2007 10:27

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

@Uživatel bez registrace @Jan Olšan: Deoptimalizovany kod pre non intel v Intel kompiltore je znama vec

Vyskon AMD versus Intel: Rozhoduje Kompilator!
http://www.hpcwire.com/hpc/1096734.html

Znizuje Intel's kompilator vykon aplikacie na AMD?
http://techreport.com/discussions.x/8547]

Intel kompilator: Je povolene znizovat vykon konkurencie?

Ako vidno patch na intel kompilator,ktory vyhodil z neho zistovanie ci je CPU 'GenuineIntel' nespozsobil zmenu vykonu na P4, ale zvysil vykon na Opteron-e o 10%. Ak bol kod skompilovany s volbou '-axW',tak potom Opteron doslova trpel : 'Simplex' test bez optimalizacie bol viac nez 2x pomalsi,kedze nemohol pouzit svoju vektorizaciu
http://www.swallowtail.org/naughty-intel.html

AMD obvinilo Intel,ze jeho kompilator umyselne generuje kod,pre AMD,ktory na AMD spadne
12.7.2005
http://www.theregister.co.uk/2005/07/12/amd_vs_intel_code/
http://blenderartists.org/forum/showthread.php?t=45903

Cize musi platit, povedz cin si to kompiloval a ja ti poviem, ako doveryhodne su vysledky.

AMD aktivne vyvyja gcc-ko
http://developer.amd.com/gcc.jsp
intel ma svoj kompilator..

- fotoba

Uživatel bez registrace

Level 1

16. 9. 2007 16:02

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

@Uživatel bez registrace @Jan Olšan: Hl2, DivX, oblivion...všechno používá SSE instrukce. to, že dojde ke zdvojnásobení šířky zpracování prostě neznamená ani zdaleka zdvojnásobení výkonu v normálním programu. i těch 20% je úspěch.
- ptipi

Uživatel bez registrace

Level 1

17. 9. 2007 14:47

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

@Uživatel bez registrace @fotoba: jenže v tom testu absolutně nešlo o porovnání intel vs AMD, ale AMD K8 vs AMD K10. Takže i kdyby intel kompilátor snižoval výkon amd procesorů, tak to v daném porovnání nehraje roli(záleželo jen na relativním výkonu těchto dvou procesorů vzhledem k sobě a ne na absolutních číslech).
- ptipi

Uživatel bez registrace

Level 1

16. 9. 2007 19:07

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

@Uživatel bez registrace @ptipi: Ale jo. Těch 20% je téměř v moci Barcelony bez rozšíření SSE. Právěže když je jádro programu (u kodeku ta část, která žere většinu času) napsaná v SSE, ta šířka se uplatní snadno, jak ukázalo Core 2. Ono to totiž třeba znamená, že 128bitová SSE se nedělá dva takty, ale jen jeden - což snadno může vést ke stoprocentnímu zlepšení.
- Jan Olšan

Uživatel bez registrace

Level 1

17. 9. 2007 16:14

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

@Uživatel bez registrace @ptipi: Q: I run the same program on a 486 and on a Pentium, and it's slower on a Pentium!

A: Beginning with version 2.95, GCC includes Pentium-specific optimizations. Be sure to use the -mcpu=pentium switch when you optimize for Pentium or better CPUs.

A program might sometimes run slower on a Pentium due to alignment problems in DJGPP. GCC makes assumptions about how GAS (the assembler) handles alignment, but GAS from Binutils 2.8.1 and earlier was configured to treat alignment in a way that's different from what GCC assumes. The outcome of this is that longs are word-aligned, doubles are dword-aligned, etc. Depending on the DJGPP version, link order, library differences, you might get lucky (or unlucky) with a 50/50 chance to get an improper alignment. Different CPUs have different penalties for unaligned accesses, which may explain differences in speed.
http://www.delorie.com/djgpp/v2faq/faq14_3.html
Staci takato drobnostka a defradujes vykon CPU- niekedy aj o 30%

Barcelona ma takeho zname spomalovace - reps. nevyuzitie potencialu

Performance Guidelines for Vectorized Floating-Point SSEx Code
While 128-bit floating-point execution units imply better performance for vectorized floating-point SSEx code, it is necessary to adhere to several performance guidelines to realize their full potential:
Avoid writing less than 128 bits of an XMM register when using certain initializing and non-initializing operations.
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/40546.pdf

Cize Barcelona moze byt vykonnejsie, nez sa javi z pohladu zle kompilovaneho kodu - pre K8 sa XMM musleo plnit na dva krat po 64 bit, K10 to tak nevyhovuje a spomaluje ju(odhadom o okolo 25%)

- fotoba