PCTuning fórum

Ono je CPU-Z open source, ze kazdy muze derivovat sve mutace?

We have been contacted by GIGABYTE and they confirmed that the chat conversation and all the details are fake.

http://www.rumorpedia.net/exclusive-amd ... -gigabyte/

viz moje PS2, které jsem přidal ...ale nedělám si iluze, že neexistuje uzavřeně již CPU-Z 1.58....Třeba existuje i edice ROG, kterou "platí" ASUS, v tom ybch až takový problém neviděl. Oficálně dostupné ale co vím je nejnovější 1.57.3

Môze mi niekto povedat, ze superpi co zatazuje(ALU, FP, jedno jadro alebo multi), lebo doteraz v nom Intel vzdy viedol.

No ja ted zkusmo zkusil 2600K pri 4,5GHz a mam lehce pres 8s pri 1M.Takze o cem to vypovida?

ttxman píše:Vyssi IPC sem myslel, ze jsou potvrzeny par desitek stran zpatky. (nebo spis, ze nebude nizsi)

Me by jen zajimalo jak OS bez nejakyho patche pro bulldozer efektivne prideluje vlakna, prece jenom je to prvni architektura, kde jednotlivy "jadra" nejsou rovnoceny a jeste k tomu se mozny vykon dynamicky meni. Jak si s tim
Windows poradi fakt netusim, ale oblibena strategie je prehazovat vlakna po jadrech jak je napadne a to nekdy dost degraduje vykon.

Pokud maji problem se zaseknutym nizkym taktem jenom nektera jadra tak se tohle projevi jeste vic.

Ten problem se zmrsenym biosem mi pripada, ze je to naschval, Od bulldozeru se toho ceka strasne moc a tyhle uniky informaci tak nejak snizuji ocekavani. Vysledek by moh byt takovy, ze po uvedeni to bude "vetsi bomba nez se cekalo".
...

A navíc IPC nemusí být až o tolik vyšší. Rozdíl IPC mezi Core2 Duo a K8 je cca 5-10%, přesto jsou ty procesory jinde. Rozdíl je zejména v predikci větvení, v agresivnějším prefetch a o něco málo lepší L2 - a to jsou věci na které je SuperPí háklivé. Co se plánovače pro OS týče, stačilo by, kdyby se k lichým jádrům choval podobně jako u procesorů s HT.

A nakonec u testovacích CPU, které slouží k testování kompatibility, dokonce očekávám, že mají záměrně pomršený microcode. Stačí jemně pomršit vykonávání třeba RET instrukce a na výkon to musí mít slušný dopad.

Edit:

godlike píše:No ja ted zkusmo zkusil 2600K pri 4,5GHz a mam lehce pres 8s pri 1M.Takze o cem to vypovida?

Že SB sedne SuperPI jak pr..l na hrnec. V nehalemu se k tomu co jsem psal u c2d přidala lepší optimalizace smyček a zbytek se také jistě vylepšil. Možná přesně sedne vzor prefetche s tím, co procesor v zápětí potřebuje. Pochybuju že se tomu bulldozer přiblíží.

godlike píše:No ja ted zkusmo zkusil 2600K pri 4,5GHz a mam lehce pres 8s pri 1M.Takze o cem to vypovida?

tak ono to vyloženě není o tom, zda by čistou náhodou najednou AMD udělalo megaboost v superpi-zlepšení oproti PII lze očekávat (tak o 10-30% na takt). Naštěstí nás rychle Gigabyte vyvedl z omylu a potvrdil to jako fake. DOkonce se již přihlásil i tvůrce faku .
Mě spíš vytáčí, proč lidi dělají furt nějaké faky a co z toho mají .

flanker píše:Mě spíš vytáčí, proč lidi dělají furt nějaké faky a co z toho mají .

Srandu, nebo 5 min slávy, nebo obojí. Napadá mě ještě snaha donutit AMD a spol. aby něco nešikovně dementovala a nepřímo potvrdila, jak se věci mají. Vypouštět falešné informace a slajdy může být také snaha odhalit interní úniky. Méně pravděpodobná je snaha znemožnit konkurenci, časem se totiž setře odkud jaké informace jsou a pak je neprávem předhazováno "slibovali jste +70% výkon/5GHz/25W/240fps/pasivní chlazení" a nedodrželi. Příp že má zpoždění.

ched píše: Rozdíl je zejména v predikci větvení, v agresivnějším prefetch a o něco málo lepší L2 - a to jsou věci na které je SuperPí háklivé.

Super pi pouziva Gauss–Legendre algoritmus tam by moc vetveni byt nemelo. Zrovna tak algoritmus by mel bez problemu sedet v L1. Pak potrebujes jenom data z minuly iterace a s tim by nemel bejt zadnej problem. Jediny problem by mohlo byt kodovani dlouhych cisel a o tom moc nevim.

ched píše: Co se plánovače pro OS týče, stačilo by, kdyby se k lichým jádrům choval podobně jako u procesorů s HT.

O to mi prave slo, ted aktualne budou mit testeri tezko upraveny windows s podporou Bulldozeru.

ched píše: A nakonec u testovacích CPU, které slouží k testování kompatibility, dokonce očekávám, že mají záměrně pomršený microcode. Stačí jemně pomršit vykonávání třeba RET instrukce a na výkon to musí mít slušný dopad.

Ja predpokladal zamerne zmrseny bios ale ono to vyjde nastejno

ttxman píše:... Jediny problem by mohlo byt kodovani dlouhych cisel a o tom moc nevim. ...

Nevim jak SuperPI, ale viděl jsem řadu programů, které počítaly s absolutní přesností a v nich jsou čísla uložená klasicky desítkově a veškeré operace se dělají ručně. Kouknul jsem se do jejich příslušných knihoven a těch podmínek jsou tam stovky a v samotné iteraci per číslo je jich asi 10, takže když se počet desetiných míst blíží k milionu procesor si užije. Vše to běží na ALU, FPU se nepoužívá.

Předpokládám, že u SuperPI to bude obdobně.

Edit: Ano, program se rozsahem nejspíš do L1 vejde, u K8 a derivátů určitě, u Bulldozeru asi také. Problém je s daty, těch je tolik, že se nevejdou ani do L3, takže nastupuje prefetch a záleží jak bude kráčet po datech. Možná u K8 a spol. fungoval nějak obzláště nešikovně pro algoritmus, který zpracovává předpokládám 3 proudy bytů.

...Super PI will use FFT arithmetic and Borwein's quartically-convergent algorithm
Super PI also uses x87 floating-point unit...

http://super-pi.softpedia.com/

Hm takže všecho je jinak ... Akorát mi neni jasný jestli používaj Borwein's quartically-convergent algorithm viz link yuri.cs nebo Gauss–Legendre algorithm viz ttxman ... oba to jsou algoritmy pro výpočet PI.

ched píše: Vše to běží na ALU, FPU se nepoužívá.

Jak kdy a jak kde. Ted sem se rozhlizel po netu a FPU se celkem pouziva, protoze i s korekci pripadne chyby je to rychlejsi nez to resit ciste softwarove na ALU.

ched píše: Edit: Ano, program se rozsahem nejspíš do L1 vejde, u K8 a derivátů určitě, u Bulldozeru asi také. Problém je s daty, těch je tolik, že se nevejdou ani do L3, takže nastupuje prefetch a záleží jak bude kráčet po datech. Možná u K8 a spol. fungoval nějak obzláště nešikovně pro algoritmus, který zpracovává předpokládám 3 proudy bytů.

podle http://www.boo.net/~jasonp/pipage.html existuje program na vypocet PI s velikosti 52bytu


1)Vime urcite, ze vsechna prace s cache algoritmy je u bulldozeru prekopana diky tomu, ze maji uplne jinou strukturu pameti.
2)1M desetinych mist by se do L3 vejit mohlo. Pokud by se jednalo o mista ve dvojkovy soustave je 1MB. V desitkovy soustave to bude zabirat maximalne kolem ln10/ln2 vic pameti: takze 3.322MB. Problem je ze to bude potreba asi vickrat, pokud se nepouziva neco jako aritmeticky kodovani.

ched: wikipedia o super pi tvrdi, ze Gauss–Legendre, a taky sem narazil na par referenci, ze to super pi fakt pouziva. Ale na 100% si jistej bejt nemuzu

Edit: tak super pi bere s 1M vypoctu 8388648B. Zajimavy by bylo udelat par pokusu na velikostech co se do L3 urcite vlezou cely (64K?) a jak by to ovlivnilo pomer mezi Phenom/SB.

1M číslo se do 8M L3 vejde, ale v těch algoritmech se pracuje s více operandy a možná se tam bude per iterace alokovat nová paměť pro výsledky, pokud si program všechnu potřebnou paměť nezabere hned ze začátku. A už jsem pochopil tu referenci na FFT, oni ta čísla mají rozložená na pole čísel (jinak než čistě číselný řetězec), přes ty vzájemě iterují a pak provedou inverzní FFT pro výsledky zpět. To pole čísel bude možná rozsáhlejší než skutečný datový obsah.

To by mi ještě lépe vysvětlovalo proč prefetch bude chybovat, čísla jsou rozložená do nějakého pro procesor nesmyslného vzoru v paměti a on neodhaduje odkud se bude v následující chvíli číst.

Tak jako tak, podmínek a cyklů tam bude opravdu hodně, paměti to zabere také dost. Ověřit si to ale nemůžu, nikde nemám v dosahu windows ... kolik bere SuperPI v poslední iteraci paměti?

Edit: diky, čekal jsem víc, takže u bulldozeru pokud je L2 a L3 exkluzivní, tak se to pravděpodobně vejde. Takže problém budou cykly a podmínky.

Edit2:
Btw k tomu FPU, větsinou se setkávám se servery, kde FPU se moc nepoužívá - databáze, aplikační servery, web (alespoň navenek se nepoužívá) Před 10 lety jsem na školení AS/400 jednomu programátorovi z IPB vysvětloval rozdíl mezi čísly s pohyblivou a pevnou řádovou čárkou. Oni používají jen pevné čárky a i obecně jen blázen by ve finančnictví použil double.

Super pi pise na zacatku kolik si alokuje pameti, takze nejaky dynamicky alokace moc nehrozej. Pro FFT se taky vdycky alokujou buffery predem, jelikoz vis kolik budes potrebovat. (K nasobeni to nepouzivam, ale na zpracovani signalu jo)

ched: neco mi rika ze to pole bude o hodne vetsi

Flegy píše:ched: neco mi rika ze to pole bude o hodne vetsi

nebude

Ttxman píše:Edit: tak super pi bere s 1M vypoctu 8388648B.

Mate nekdo pristup k i7 a phenomu? Sem si s pouzitim GMP a .NET frameworku 3.5 napsal vlastni program na vypocet PI pod 64bit (Gauss-Legendre.. jako super PI pocty iteraci mi vychazej stejny). A zkompiloval sem si GMP na ruzny architektury, bylo by fajn to zkusit na phenomu a SB, ja mam jen athlonII X4 640 a notebook s Core i5 M480.

Kdyz nic tak je to urcite zajimavy a zjistilo by se jak moc super pi nadrzuje intelu.
vysledky z X4:
PI 1M digits unoptimalized library
00:00:00:06.964
PI 1M digits K8 optimalized library
00:00:00:03.0
PI 1M digits K10 optimalized library
00:00:00:03.29 ............ ze by se projevila absence L3?
PI 1M digits CORE2 optimalized library
00:00:00:03.337
PI 1M digits Nehalem optimalized library
00:00:00:03.229

vysledky z i5
PI 1M digits unoptimalized library
00:00:00:07.628
PI 1M digits K8 optimalized library
00:00:00:04.568
PI 1M digits K10 optimalized library
00:00:00:04.604
PI 1M digits CORE2 optimalized library
00:00:00:03.385
PI 1M digits Nehalem optimalized library
00:00:00:03.359

EDIT:
link k programu: http://www.mediafire.com/?1ndfj802oz09zd3

Tak k Phenomu mám určitě přístup, ovšem k i7/i5 ne

Tak se nahodil ten program na mediafire. muzete zkusit
http://www.mediafire.com/?1ndfj802oz09zd3
Spustejte bat soubory. Asi nejlip calc_run_ALL.bat at je videt co delaj optimalizace.

OK Zkusím to otestovat a napíšu Ten tvůj Athlon X4 běžel na defaultním taktu?

// Mám to Phenom II X4 @ 3.8GHz:
PI 1M digits unoptimalized library
00:00:00:05.90
PI 1M digits K8 optimalized library
00:00:00:01.973
PI 1M digits K10 optimalized library
00:00:00:01.965
PI 1M digits CORE2 optimalized library
00:00:00:02.246
PI 1M digits Nehalem optimalized library
00:00:00:02.204

Jo default takty, mam to postaveny na relativni ticho tak taktuju jenom kdyz fakt potrebuju z neceho vytahnout vteriny navic