HW novinky: malé vysvětlení k velkému šoku z prvních testů Intel "Haswell"

1. 2. 2013 | David Ježek | Hardware | 5821×

Hlavním tématem tohoto dílu je upřesnění týkající se prvních objevivších se testů CPU rodiny Intel „Haswell“. Vedle toho se ale podíváme i na dva typy chystaných Xeonů generace „Ivy Bridge“, další přírůstek do rodiny XQD a nakonec též na jedno netradiční, ale pro budoucnost extrémně významné téma…

Obsah

• Intel "Haswell" změřen, oproti "Ivy Bridge" jen nepatrně rychlejší
• Intel Xeon „Ivy Bridge-EX“ přinese 15 CPU jader
• Lexar uvedl 64GB XQD s rychlostí 168 MB/s
• SW vsuvka: H.265 je schváleno, čekejme zařízení

Intel „Haswell“ změřen, oproti „Ivy Bridge“ jen nepatrně rychlejší

Obvykle se snažím nepsat zprávy, které plavou na vodě až příliš oproti těm zveřejněným na více důvěryhodných webech, ale tentokrát udělám výjimku. Důvod je prostý: od „Haswellu“ se čeká následující: zdali bude pokračovat v „Ivy Bridgem“ nastoupené cestě jen zcela minoritního nárůstu výkonu oproti předchozí generaci a zdali bude pokrok v efektivitě odpovídat přechodu od procesu 22nm TICK k 22nm TOCK, jaký by alespoň částečně odpovídal pokroku, který předvedl 32nm TOCK, tedy „Sandy Bridge“.

Ruský OCLab zveřejnil první syntetické testy blíže nespecifikovaného vzorku procesoru rodiny „Haswell“, konkrétně čtyřjádra taktovaného na 2,8 GHz. To bylo porovnáno s Core i7-3770K, tedy 3,5GHz „Ivy Bridge“, pro účely testu zpomaleným na shodných 2,8 GHz. Ostatní komponenty byly shodné.

Test proběhl na několika programech sloužících k výpočtu Ludolfova čísla. To je samo o sobě čistá syntetika, která toho moc nevypoví, ale náznak o efektivitě výkon/frekvence přeci jen řekne to potřebné, narozdíl třeba od testů, které budou využívat novějších instrukčních sad v „Haswellu“. Nebudu vás zatěžovat konkrétními čísly, pouze informací, že „Haswell“ byl ve výpočtech π rychlejší o zhruba 2 až 3 % než stejně taktovaný „Ivy Bridge“. A teď je ten správný moment si položit otázku, jestli je to z hlediska testů Super PI, PiFast a Wprime dostatečný pokrok.

Je jasné, že 2% nárůst výkonu v zaběhlých aplikacích používajících letité algoritmy, není dán využitím nových instrukčních sad. „Haswell“ je tedy o něco lépe vyladěnou architekturou. Navíc oproti předchozím generacím přidá balík instrukcí známý jako „Haswell New Instructions“ (HNI) zahrnující AVX2, gather, bit manipulation a FMA3 plus rozšíření instrukční sady x86 zvané „Transactional Synchronization Extensions“ (TSX), které přidává hardwarovou podporu pro transactional memory (žeby?). Na první benchmarky, které odhalí skutečnou sílu „Haswellu“, si tedy ještě počkáme. Teprve až se ukáží první aplikace efektivně využívající věcí jako AVX2 či FMA3, bude vhodný moment se bavit o výkonu „Haswellu“. Zatím je to spíše o tom, že mohou weby na základě testů OCLab.ru psát, že „Haswell“ není nic moc. Ale k pravdě to má daleko asi tak jako běžec na startu Badwater135 do cíle.

Intel Xeon „Ivy Bridge-EX“ přinese 15 CPU jader

Již máme na trhu Xeony s dvojciferným počtem jader, ale příští generace postavená na „Ivy Bridge“ ve variantě EX s ním pohne zase o kus dál. „Ivy Bridge-EX“ nabídne 15 procesorových jader, plus samozřejmě HyperThreading. Pro typický serverový stroj na bázi těchto CPU se tedy již bavme v desítkách CPU/HT jader.

Každopádně nás čeká nová patice, s tou z „Westmere-EX“ (32nm CPU uvedená v dubnu 2011) se již z pochopitelných důvodů nepočítá. Nové „Ivy Bridge-EX“ procesory budou označeny Xeon E7 V2.

Dále tu máme upřesnění: chystají se i CPU „Ivy Bridge-EP“, což jsou maximálně 10jádrové procesory, které ponesou označení Xeon E5. V obou případech půjde o stejnou patici, prozatím značenou FC-LGA12A. Uvidíme, kolik nakonec bude mít pinů.

Lexar uvedl 64GB XQD s rychlostí 168 MB/s

Debatu, jestli byla/o dřív slepice, nebo vejce, si můžeme vztáhnout i na formát paměťových karet XQD. Ty byly představeny zhruba ve stejné době, kdy šeptanda pomalu protlačila na povrch zrcadlovku Nikon D4, první přístroj s jejich podporou. Tomu je již řada měsíců a kolem XQD je stále ticho po pěšině. Výrobci karet moc nepřibývají (u ohlášení byl vedle Nikonu a Sony již jen Sandisk, loni oznámil svůj úmysl připojit se Lexar), výrobci zrcadlovek s podporou též ne (Nikon D4 je dosud jediný).

Lexar je významnou hi-end značkou mezi paměťovými kartami, však také za ním stojí samotný Micron, přední výrobce NAND flash čipů. Nyní Lexar představil své XQD karty, v kapacitě 32 a 64 GB a s rychlostním koeficientem 1 100 ×. To volně přeloženo znamená rychlost čtení až 168 MB/s, k čemu má dopomoci i nově ohlášení čtečky XQD→USB3.0, ale o rychlosti zápisu ani slovo. Skoro by měl Lexar na balení karty napsat „Shame on us“, protože neuvádět tento údaj o profi produktu té nejvyšší třídy je zcela neomluvitelné.

Jinak na 32GB kartu si připravte 300 dolarů, na 64GB pak 580 dolarů a na čtečku 45 dolarů. Ale kdo by řešil takové drobné, když Nikon D4 stojí 140 000 Kč, že?

SW vsuvka: H.265 je schváleno, čekejme zařízení

Na závěr mi dovolte významnou vsuvku, která má povahu spíše softwarovou, ale vyústí i v praktické hardwarové aplikace. Organizace ITU a ISO/IEC totiž po letech vývoje schválily standard nástupce téměř 10 let starého formátu H.264 (ano, deset let, to není překlep).

H.265 (též známé jako High Efficiency Video Coding – HEVC) je zde a díky pokročilejším kompresním technikám má nabídnout potenciál až 2× menšího datového toku při stejné kvalitě obrazu oproti H.264. Záměrně píši potenciál, protože mít specifikaci je jedna věc, ale na všeobecně dostupnou kvalitní implementaci je třeba si teprve počkat. Jsou zde, resp. budou zde samozřejmě komerční produkty již pár let vyvíjené pod pokličkou, ale my čekáme na nějaké to x265 – to co pod tímto řetezcem momentálně vygooglíte, nelze srovnávat s vyzrálostí a technickou kvalitou projektu x264, přičemž sami tvůrci x264 hovoří o tom, že podobnost je zde tak malá, že nelze jednoduše vzít x264 a „trochu ho překopat“ a mít první implementaci x265.

Já sám jsem zvědav, kdy bude tento kompresní formát nasazen v místech, kde se s ním logicky musíme setkávat nejběžněji, tedy například na YouTube, v různých flashových video přehrávačích, případně jako implementace pro HTML5 video v rámci webových prohlížečů. Jsme na počátku vývoje, ale konečně se bavíme nad finální verzí formátu.

       

Komentáře

[Ovocníček]

Podle tohoto ještě H.265 schválené není. ITU jakoby odobrila ten draft, tj. řekli si "Fajn, tuhle verzi pošleme k schválení standardizačním orgánům". Během samotné standardizace se snad dokonce ještě můžeou udělat nějaké drobné změny, i když asi nikde nerozbijí kompatibilitu, bych čekal.

[Ovocníček]

Jinak je to ale celé pravda, skutečnou sílu to ukáže až během několika let, až/pokud někdo napíše ekvivalent x264. Zatím se k tomu nikdo nemá (byť na ML byl nabízen sponzoring - je to zkrátka hodně práce a potřebuje to mozky a zkušenosti).

Ono vůbec, ta "poloviční bitrate při stejné kvalitě" je blbost. Kompresibilita je různá video od videa, a mění se i s bitrate, kterou chcete. V nízkých datových tocích bude mít h.265 největší zisky, ve vysokých to až takový rozdíl nebude (dominantní objem dat ej residuál a tedy šum), například.

[Rovano]

Z MPEG4 na H264 to technicky defakto nebyl zase takový skok. Tohle je větší.

[Ovocníček]

MPEG4 ASP ("xvid") na MPEG4 AVC (H.264) to je pane skok jako blázen. A podpořený ještě tím, že nejlepší enkodéry pro ASP nejsou nic moc, zatímco x264 je dost slušné. Je to prakticky první enkodér, co fakt dokáže udělat transparentní obraz (tj., bez dramatičtější degradace od originálu), když mu dáte dost bitrate. To není taková samozřejmost, jak se zdá (že, VP8?).

[Rovano]

S tím souhlasím. Špatně jsem se vyjádřil. Co jsem četl o vývoji, tak to nebyl takovej skok. Kvalitativně však ano. Sám jsem si testoval, co to umí oproti ASP a paráda.

[Ovocníček]

Ono také ASP mělo různé špatné vlastnosti, například zprzněné bframes, které omezovaly jejich užitečnost. Dále neexaktní DCT, jediný referenční snímek, znatelně horší intra predikce, a pak samozřejmě slabší entropy coder (CABAC je zkrátka CABAC). Určitě by tam byla spousta další komárů, které toho slona zabijí. V scénách s kolísajícím osvětlením je také nedocenitelná weighted prediction (bez ní v podstatě stmívačky a rozetmívačky vypadají ohavně, který kodek to nemá, ten v nich docela hnusně selhává), a tu právě mpeg4 asp nemá.

[Michal Kubeček]

Ruský OCLab zveřejnil první syntetické testy blíže nespecifikovaného vzorku procesoru rodiny „Haswell“

Názvy testů SuperPi, FastPi a wPrime mi neznějí moc synteticky.

[Petr]

Ví se, o kolik Haswell při tom testu žral méně proti Ivy? Pokud byl rychlejší o 2% a zároveň měl o 30% menší spotřebu, je to pěkný, pokud byla i spotřeba +- stejná, je to pro mě zklamání. Nové instrukce moc neřeším, nebude moc programů, které to využijí nebo které budu mít já.

[radix]

Jj, obzvlast kdyz bude i vice taktovatelny. Krom IPC je vice moznosti, jak zvysit vykon ...

[Rovano]

Přesně tak. Měl by mít menší spotřebu. Například v nízkospotřebových zařízeních z 5W na 1W apod. Což rozhodně není zanedbatelné.

[Ovocníček]

Neví. Spotřebu neměřili/nezveřejnili. Kromě toho to byl ES na předprodukční desce, takže by to stejně nebylo úplně košer.

[Tomáš Bžatek]

Tak papirove asi nebylo koser ani zverejneni testu (i ES se muzou ladit), ale Rusko je Rusko

[Ovocníček]

Myslel jsem košer ve smyslu, že by to neodpovídalo spotřebě finálních kusů.

[lertimir]

V podstatě nějaké velké zrychlení na jednom procesoru se nedá očekávat. Podle mne rozsah paralelizace na jednom jádře už je v současnosti takový, že zásadní zlepšení se tam už nedá dostat. Samozřejmě pár jednotek procent asi ano.

[Ovocníček]

Ono to bude záležet od kódu. Tyhle úlohy jsou v podstatě všechno FPU aritmetika, pokud vím (nemám tucha, do jaké míry je to SIMD, SuperPI je snad dokonce x87). Třeba přidaná ALU v Haswellu zde moc nepomůže.

[xm]

Google už od roku 2011 pracuje na formátu videa VP9, který má za cíl mít obdobnou kvalitu při stejném bitrate jako H.265 (respektive poloviční bitrate oproti VP8). A hlavně stejně jako VP8 nebude zatížené patentovými poplatky. Dost pochybuji, že by na YouTube zaváděli H.265, které bude mít v moci patentový troll MPEG LA (btw. americké ministerstvo spravedlnosti začalo MPEG LA vyšetřovat pro podezření z nekalého konkurenčního boje kvůli jeho výhružkám na adresu VP8/WebM).

V prosinci 2012 byl VP9 už dokonce zařadili do Chromia.

[Ovocníček]

Najděte si definici toho, co je patentový troll. Aktivisti to sice na adresu MPEG-LA pořád řvou, ale rozhodně to není pravda.

[Ovocníček]

Jinak VP9 nevypadá beznadějně, i když kolem a kolem bude asi teoretická efektivita zase o něco nižší než u H.265 (například pořád to nemá bframes, pokud vím).

Kvalita videa bude hlavně záležet od kvalit konkrétního enkodéru - tj. lepší bude ten, kdo první od x264 úspěšně okopíruje jejich implementaci psychovizuálního RDO (a nezbabrá zbytek enkodéru). Někteří lidi pracující na VP8 a VP9 zanjí a komunikují s lidmi z x264, jenže to nemusí nutně znamenat úspěch - protože za Boha živého, proč tedy ještě není PsyRDO v libvpx? Kvalitě VP8 by tolik pomohlo...

[Ovocníček]

Jo, sorry za to stálý doublepostování, ale to, že VP9 je v Chromiu nic neznamená, je to jen experimentální feature. Formát VP9 ještě není uzavřený, v budoucnu se asi ještě bude měnit. Čili zatím skutečně ne pro reálné nasazení (pokud nemáte plnou kontrolu nad dekodérem u klienta).

Pokud vím, VP9 se zřejmě bude ucházet o standardizaci v rámci IETF. A to znamená relativně dlouhý proces, do jehož završení pořád nebude formát finalizován. Čili situace je stejná jako s kodekem Celt/OPUS, který byl také ratifikován a uzavřen relativně nedávno, i když se v různých nasazeních (např. Gaikai) více či méně vhodně objevoval léta před tím.

Dokud není bitstream zmražený, je kodek v podstatě nepoužitelný.

[Ondra]

Xiph.org spolu s Mozillou zase pracuji na daala.

trochu to na me pusobi, jakoze se Google s Mozillou moc nemusi, a kazdy si radsi hraje na vlastnim pisecku a radsi si konkuruji; zminil bych protipoly Firefox vs Chrome, Rust vs Go, daala vs VP9,...

[Ovocníček]

Daala je mnohem progresivnější návrh, ale taky není zdaleka hotová, ještě se pracuje na intra predikci, inter predikce zatím není vyřešená, lidé na tom makají příležitostně ve volném čase. Takže má šanci být technicky o dost lepší než VP9, ale také bude asi náročnější.

Vývojáři založili v IETF skupinu pro specifikaci "internetového kodeku" a techniky z Daala tam prezentují jako drafty. Je ale otázka, zda se v té skupině nakonec neprosadí spíš VP9, protože je blízko dokončení, popdorované korporací a má jakous takous šanci se dostat do hardwaru.

VP9 (a vlastně i H.265) jsou narozdíl od Daala (pozor, je to jen dočasné jméno) dost konvenční kodeky na bázi DCT...

[Petr Ježek]

Cokoli, co umožňuje podstatně snížit objem datových toků při stejné nebo lepší kvalitě je rozumné, u videa to platí dvojnásob. Co se týče nových kodeků, obávám se, že Mozilla na to sama ani náhodou nestačí... O Haswellu bude mít cenu se bavit až u prvních produkčních desek s ním.

[Ovocníček]

Ono je to Mozilla a Xiph, plus jako 'konzultanty' mají lidi z ffmpegu a x264, mimo jiného. Takže intelektuálně/erudovaností na to podle mě mají možná i víc než Google (protože bych řekl, že lidi z On2 toho s VP8 moc nepředvedli - formát je obšlehlé H.264, ale enkodér je špatný). Ale rozdíl je pochopitelně v rozpočtu a dostupných člověkohodinách.

Ale jinak ta koncepce je o dost jiná (například intra predikce je zdá se trénovaná genetickým algoritmem pro co nejvyšší efektivitu), takže pokud se jim to povede dotáhnout (a neosekají to nebo nezprzní kvůli různým kompromisům), tak to možná bude kvalitativně spíš konkurence pro VP10 :D