PCTuning fórum

Fakt je, ze posledni boxovany chladice co sem videl vypadaly celkem fajn (hlavne ten na x6). Ona uz i ta pasta co na to davaj neni takovej odpad jako kdysi

Netvrdim, ze vsechny, ale do ruk se mi dostalo asi 5 sestav z obchodaku (hold nektery pribuzny a znami nejde odmitnout) a 3 z nich se beznadejne prehrejvali. Rek bych ze obchodaky okupujou dost velky procento trhu s hotovejma sestavama.

I kdyz si to clovek vezme jako nehorsi mozny pripady, tak to CPU musi v tech podminkach vydrzet a melo by vydrzet po celou zarucni lhutu. A na to je Turbo v dnesni zeleny dobe idealni. CPU v jakejkoliv podminkach zere kolik ma i kdyz vykon se muze hejbat o slusnejch par procent.

Pro me je to celkem nevyuzitelna vlastnost mam lehce pretaktovanej procesor (s tim o kolik to dneska jde je to hrich nevyuzit) a pouzivam C&Q, takze v idle to nezere a kdyz to potrebuju tak si to holt zatopi (i kdyz asi ne moc). Ale jako marketingovaje tahak mi to porad pripada porad super a pro normalni uzivani PC taky, a navic i pro vyrobce ktery se tim muzou chlubit.

ještě něco k té sdílené FPU jednotce a AVX:

"Bulldozer 1 has one full 128-bit adder and one full 128 multiplier per module (shared between 2 of what AMD has chosen to call 'cores')."

Wrong. Completely wrong. Per John Freuhe:

"Per cycle each FMAC can do one FMUL or one FADD."

Additionally:

"Now, let’s be clear, there is no such thing as a 256-bit command. Single precision commands are 32-bit and double precision are 64-bit. With today’s standard 128-bit FPUs, you execute four single precision commands or two double precision commands in parallel per cycle. With AVX you can double that, executing eight 32-bit commands or four 64-bit commands per cycle – but only if your application supports AVX. If it doesn’t support AVX, then that flashy new 256-bit FPU only executes in 128-bit mode (half the throughput). That is, unless you have a Flex FP."

Bulldozer further benefits from having separate integer and FP schedulers, meaning you don't have to wait for the integer math to get done before using the FPU:

"Each Flex FP has its own scheduler; it does not rely on the integer scheduler to schedule FP commands, nor does it take integer resources to schedule 256-bit executions. This helps to ensure that the FP unit stays full as floating point commands occur."

"Worse, because Intel does not describe the HT thread as a core, Intel can claim that each AMD core is, in AVX, one 1/4 as fast as an Intel core."

This is absurd. First of all, the amount of AVX FP operations being done is going to be very limited for at least the next several years. AMD made a wise choice by saving die space not duplicating unnecessary parts. Secondly, Intel's two 256-bit FPUs can only do as much 128-bit math as ONE of AMD's Flex FPU. That means that non-AVX instructions are wasting half of those FPU resources. In the past, Intel's FPUs have been scheduled by a shared integer/FP scheduler... so if that remains the case, I'm betting that Bulldozer's FP performance might even exceed Intel's. Possibly even with AVX instructions.

But more importantly, Hyper Threading is not the same thing as a physical core. A single Bulldozer module is comprised of two physical cores, with a shared FPU that can operate as two FPUs if necessary. A thread on an Intel CPU is not a physical core. I'm not a fan of Hyper Threading because it really only benefits sloppy coding.

Dohromady to dává ve výsledku to, že Bulldozery jsou výkonější proti dnešním phenomům ve všech případech. Takže jenom zbejvá zjistit o kolik. A taky jak moc výkonější je nová FPU.[/quote]

JF píše:First of all, the amount of AVX FP operations being done is going to be very limited for at least the next several years.

Kdo vi, AVX neni zatim - zrejme - nijak vrele prijimano. Ale zase Intel muze zacit absurdne protlacovat AVX jen z marketingovych duvodu... kdyby chtel xD

To ja si zase myslim, ze nastup AVX bude velmi rychly, ale nebudou se moc pouzivat nove vlastnosti. Proste to vsichni vyrobci kodeku, enkoderu a vubec vsichni kdo intenzivne pouzivaji SSE proste rozsiri na sirsi registry. Algoritmy maji na paralelni zpracovani pripraveny, zasahy do kodu budou minimalni a zisk bude az 100% vykonu navic (teda pokud AVX instrukce budou provadene v 1 taktu)

an ten videoencoding to také vidím...
tam by mohla být nejsilnější praktická budoucnost AVX

Ja take, ale kdyz jsem se pred par mesici pidil po nejake zprave, treba od x264 tymu, tak jsem nasel akorat par zminek typu: "mozna, "uvidime", atd.

1 AVX/takt bude, dvojnasobna delka registru taky, takze teoreticky by pro typicky pripad "rozvinuti smycek" melo byt zrychleni na dvojnasobek.

Tak jsem trošku zagooglil a zjistil, že s těmi SSE to není zase tak jednoduché:

1. Některé SSE potřebují i podporu jádra OS, aby se korektně mohl CPU přepnout mezi režimy
2. Implementace SSE je vždy ruční záležistot programátora v assembleru. Když jsem instaloval Ubuntu, tak mne potěšilo, že v 64bit verzi používá implicitně pro FPU místo staré x87 rovnou SSE. Má radost ovšem trvala jen do doby než jsem zjistil, že se jedná o pouhé nahrazení skalární instrukce x87 za skalární SSE: tedy žádné využívání vektorů = žádné zrychlení. Navíc x87 je 80bit zatímco SSE je 64bit, takže i přesnost je menší Jediný kompiler, který umí trochu automaticky využívat vektorové SSE je jen od Intelu - ale jsou s tím problémy a využitelnost je horší než ruční implementace.
3. V SSE verzích je od SSE3 nahoru strašný chaos, myslím že už to tu zmiňoval Yuri.cs. Ovšem to jsem netušil, že až tak velký. Intel totiž uvedl s Core2 novou sadu SSSE3 (Supplemental SSE3, 32 nových instrukcí), pak s Core2 45nm SSE4.1 (47 nových) a konečně s Nehalemem SSE4.2 (7 nových). AMD nepodporuje SSSE3 vůbec a z 54 instrukcí SSE4 implementovalo pouhé 4 instrukce + dvě vlastní a nazvalo to SSE4a. Mám takový dojem, že tohle byl od AMD čistě marketingový tah (rozuměj ojeb na zákazníka) už jenom proto, že BD bude obsahovat jak SSSE, tak i full SSE4.1+2.
4. Z bodu 3 vyplývá, že mezi Intelem a AMD zuří válka na poli instrukčních sad. Intel využívá invenci na tomto poli k trvalé výhodě nad AMD. Využívá k tomu svůj kompiler a fakt, že AMD bude vždy o jednu generaci CPU pozadu s implementací SSE. Je jasné, že AMD se z této nevýhodné pasivity snažilo za pomocí SSE5 vymanit, nicméně se to opět nepovedlo a přinejlepším z toho bude plichta.

Tedy spíš než ze samožné AVX mám radost z toho, že AMD bude s BD korektně podporovat všechny předchozí instrukce. To přinese okamžitý boost, přičemž AVX může být příjemný bonus, protože pořádnou implementaci AVX mohou přinést za rok s BD 2. generace.

Jakto ze phenom2 nepodporuje vubec SSE3?Cpu-z mi ukazuje podporu SSE3...Jak to teda je?
CPU-Z teda keca?

HEAD píše:Jakto ze phenom2 nepodporuje vubec SSE3?Cpu-z mi ukazuje podporu SSE3...Jak to teda je?
CPU-Z teda keca?

SSE3 != SSSE3. Jsou to dvě odlišné instrukční sady. SSSE3 (se třemi S, neboli Supplemental Streaming SIMD Extensions) je čtvrtá verze SSE (Streaming SIMD Ext). Měla by se tedy správně jmenovat SSE4, nicméně byla pojmenována jako SSSE3. Nejspíš proto, že nepřináší tolik nových instrukcí jako následující sada, která byla pojmenována jako SSE4.

Zdroj: http://en.wikipedia.org/wiki/SSSE3

richie08 píše:2)Implementace SSE je vždy ruční záležistot programátora v assembleru.

Ono s SSE to zase neni tak tragicke, kdyz ho chces pouzit na zakladni operace. Bohuzel ne v kazdym jazyku a rozhodne bez assembleru nedokazes vyuzit vsechny moznosti.

Kdyz pouzivas Javu mas smulu. (nebo aspon o nicem nevim)

Kdyz pouzivas .NET, tak Mono obsahuje knihovny pro vektorove typy. Bohuzel vektorove vypocty probihaji jenom pokud je assembly spustena pod Monem, microsofti framework je neoptimalizuje a pocita normalne :/
Druha moznost pod .NET je Microsofti C++ a mixed mode assembly.

C/C++ obecne:
Inline assembler. Kod neni tak slozity, jelikoz je to vzdycky par radku na naplneni a vypocet v SSE a zbytek v C.
Navic se snad daji sehnat makra, ktera ASM kod obsahuje a pak je to jenom pouzivani funkci s parametry.

Microsoft C++ compiler. Celkem velka sada compiler specific typu a maker pro praci s SSE. Navic se zda, ze pro jdou zkompilovat i pod GCC (se zapnutou kompatibilitou), ale netusim jestli je to pak pocita vektorove.

Intel C++ ma automatickou vektorizaci, takze kod co chces pocitat vektorove staci psat jako operace cyklem na polich hodnot a ono je to automaticky provede prez SSE. (hlavne nepouzivat moc rucni optimalizace jinak to nepozna)

richie08 píše: Navíc x87 je 80bit zatímco SSE je 64bit, takže i přesnost je menší

Neni x86(7) CPU podporuji stadardem definovane typy pro 32 (single precision), 64 (double precision) a 80 (extended precision) bit cisla v plovouci carce. At provedes operaci na 64bit cisle v jakykoliv FPU tak podle standartu musi vyjit stejne. (ve IEEE754 jsou definovany i zpusoby zaokrouhlovani v pripade ztraty presnosti).

richie08 píše: 3,4)

Podle me proste vyvoj K10 trval tak dlouho a nabral takovy zpozdeni, ze zacal v dobe kdy se o SSE4 moc neuvazovalo (ani puvodni Intel CORE je neumelo). U K10.5 bylo nutne pracovni sily zamerit uplne jinam. Kvuli novim instrukcim by bylo nutne prekopat ALU/FPU a sebrali by se inzenyri z vyvoje ty monstrozni FPU co bude v Bulldozeru.

Takze proste sepsali co slo udelat v mikrokodu a udelali SSE4a

tak nejaku podporu pre vektoriyaciu kodu pre SSE ma aj GCC. http://gcc.gnu.org/projects/tree-ssa/vectorization.html

Intel zneuziva svoj prekladac na znevihodnenie konkurenice. Vid zmena ID na VIA procesoroch ktore zapricinili zvysenie vykonu puhim zmenenim ID procesora. ICC pouziva SSE instrukcie iba ak bezi na Intel procesoroch. inak pouziva genericky i386 kod. je to aj vidiet ze na Linuxe su rozdiely medzi AMD a Intelom mensie ako na Windows. je to tym ze kopec SW je na Windows kompilovany s ICC kym na linuxe je to vetsinou GCC.

richie08 píše:Tedy spíš než ze samožné AVX mám radost z toho, že AMD bude s BD korektně podporovat všechny předchozí instrukce. To přinese okamžitý boost, přičemž AVX může být příjemný bonus, protože pořádnou implementaci AVX mohou přinést za rok s BD 2. generace.

Ano, taky to tak vidim. Okamzite dohnani Intelu co se tyce podporovanych ins sad a AVX jakozto polo-podporovana featura -> "plna" podpora az pozdeji.

ICC zarucene rozvyji smycky, ze i GCC, to je zajimave

no právě že Zambezi má více podporovaných instrukcí než SB (tolik jich bude mít u Intelu až Haswel). Určitě nějaký vývoj víceúčelových softwarů AMD taky podporuje...Pokud je AMD spolupráce s Applem a dalšími firmami, nevidím důvod, proč by si při finálním vývoji Bulldozeru nepolepšili i u softwarových společností

Je to tak, BD ma navic napr. XOP a FMA4. Panuji pochyby ohledne rychlosti adaptace sw na AVX sadu, ktera je pro oba vyrobce spolecna. Takze moc realne nevidim rychlou implemtnaci "AMD only" ins sad :/

stejnak zas se bude tetsovat klasika: pov ray, Cinebench, Blender, wmw, TMPG nebo XVID, hry, Adobe a nějaký audio převod

flanker píše:stejnak zas se bude tetsovat klasika

muze byt; Ovsem pak jsou tranzistory pouzite na podporu idlujicich instrukci utraceny naprosto zbytecne -> mohly byt vyuzity prospesneni, popr. uspora nakladu...

možná pár webů něco z podpory otetsuje, případně AMD upozoní na čem spolupracuje....ale z počátku to bude asi jako letos u Intelu a AES...

ttxman> S tím 80-bit FP máš recht, v C/C++ to tak opravdu je: float(32), double(64), long double (80bit). Alespoň jsem si trošku připoměl datové typy v céčku, když už jsem v něm celé věky nic nepsal. No ale protože mi vrtalo hlavou proč v tom článku psali o ořezávání 80-bit na 64-bit, jal jsem se tedy zjistit jak to je tedy doopravdy. Týká se to tedy Javy, kde je možné přepnout virtuální stroj tak, aby interně pracoval 80-bit a pak zpětně ořezával instrukce do typu float nebo double.

SSE v Javě>Jinak co se týká využití SSE v Javě, tak ta skutečně implicitně neumí využívat SSE. Explicitně ji ale lze vnutit metody napsané v C/C++. Tam už jde použít vše co HW nabízí, takže lze použít i SSE a Java může být zatraceně rychlá. Samozřejme trochu se tím ztrácí kouzlo nezávislosti na platformě.

Tak to tak vypadá, že procesory Zambezi tu budou skutečně brzy
http://news.ati-forum.de/index.php/news ... menden-apu

Podívejte se na leaknuté slajdy. Procesory Zambezi (nový AM3+ socket pouze!) by měly přijít v 2Q 2011, dle tohoto slajdu to vypadá na průběh dubna či květen! Informace o taktech apod jsou však stále tajné. Můžete si však ještě všimnout, že nativní podpora 1866 MHz DDR3 je pravdivá (Thuban má 1333 MHz, SB také 1333 MHz nativně).
http://news.ati-forum.de/images/stories ... oadmap.jpg

http://news.ati-forum.de/images/stories ... oadmap.jpg

Naopak Llano tu bude až v Q3 2011, něco mi však říká, že realita bude jiná a Llana se dočkáme možná ještě v Q2

To vypada slibne - 8c BD na zacatku Q2 11.

Llano tedy skutecne az pozdeji. btw stale se nikde neobjevil info o deskach s AM3+ ani FM1, zrovna na ten socket FM1 jsem zvedav