PCTuning fórum

Můj názor je zcela opačný

1. Brzká rozšiřitelnost díky levným upgrade
2. Stejné ovládání Metra v DT, tablet, mobil (WP8 vypadá bombasticky)
3. Parádní spolupráce kancelář a přenosná zařízení i pomocí Cloud
4. už nevím a jdu spát

Silno pochybujem že nieco ako Metro bude v desktope slavit uspech, je to tam k hovnu. Apropo nejako mi v tom Metre unika ta optimalizacia programov na HW ked sa vsetko bude tvorit pre univerzalnu vrstvu. Ved tam potom bude optimalizacia na HW= 0 a vsetko bude sprasene. Tu placeme ze sa nevyuzivaju rozsirene instrukcne sady CPU a metro je cisty zabijak nejakej optimalizacie programov na CPU aj ked je to prostredie pre mobilne zariadenia aj tam sa iste hodi nejaka ta optimalizacia. vychadza mi to teda tak že ako bolo povedane ma to byt 99% programov tak 99% programov bude proste sprasených.

Ano přesně tak.

Úspěch cloud řešení visí v tom jestli bude ňákej epic fail nebo ne. Protože data v cloudu.... tam člověk v nešifrované podobě může mít tak akorát data které může vidět kdokoliv. Je toto řešení pro mě? Ne. Je toto řešení pro firmy? Ne. Zde se jen sází na to že všíchni budou pohodlní, cloud je totiž pohodlnej, pokud je připojení k netu, jsou data na dosah ruky (alespoň malá data, dokumenty, atd.). Ale cloud může kdykoliv failnout po vrozu megauploadu, stačí když se znelíbíte někomu nahoře, nebo jak říkám dojde k epic failu a ke ztrátě dat, případně ještě hůře k leaku dat. A pak ti nikdy nezálohující nikdy v nebezpečí nevěřící BFU najednou vybouchnou, ta věc ztratí důvěru a je po všem. Já už totiž vidim většinu lidí si nechávat čistá nešifrovaná data jen v cloudu a vůbec to nemít pravidelně zálohované na lokálních úložištích, to včetně důležitejch firemních dat a dokumentů. V takovém případě je jen otázkou času než dojde k ňákému epic failu.

zumpar1234 & DOC_ZENITH:

Jsem sice OT, ono to ale s těma optimalizacema kódu je trochu jinak. Pokusím se to trochu a zjednodušeně objasnit.

Když vytvoříš (naprogramuješ) aplikaci, ta bude "předkompilována" do MSIL(Microsoft intermediate language) nikoliv do binárního kódu. MSIL je předkompilovaný kód, který je nezávislý na daném cpu a HW.

O následné kompilaci do binárního kódu (který je kompilován přímo native code daného cpu a HW) se starají JIT kompilátory (just-in-time). Tyto JIT kompilátory jsou uloženy na dané platformě a prostě přeloží MSIL kód přímo pro daný systém (x86, ARM) v době spuštění programu. Prakticky o veškeré optimalizace se postarají právě JIT kompilátory automaticky (pokud v direktivě pro kompiler neurčíš jinak), jsou instalovány na dané platformě a v době kompilace mají všechny informace o HW na kterém aplikace bude běžet.

Na rozdíl od klasické binární kompilace do native code cpu (třeba v C++), kde programátor nemá ani potuchy o tom, na jakém HW vybavení bude aplikace spuštěna.

Šikovné, že? Vše závisí na "chytrosti" a rychlosti JIT kompilátoru (jak je inteligentní a jak co nejlépe využije daný HW - SSE, AVX, FMA ...). Takhle nějak se v budoucnu mohou využít výpočty na gpu, aniž by programátor vůbec věděl, že programuje gpgpu - prostě JIT v době kompilace ví jaký HW (v tomto případě gpu) a jeho schopnosti může využít

Proto si myslím (a jsem o tom přesvědčen), že pokud píšeš aplikaci v Managed code pro Metro, zkompilovaný soubor je stejný jak pro x86, x64 tak pro ARM, a tyto aplikace jsou optimalizované většinou lépe, než bys to udělal ty (tedy pokud člověk není opravdu odborník).

Pokud programátor neví pro jaký HW kó píše, nikdy optimalizovaný nebude. To je naprostá utopie a praxe nám ukazuje že to tak nefunguje. Na to na co v době kdy se SW psal pořádně stačil 200Mhz procesor dnes potřebujem 10x tolik výkonu. Tomu říkam cesta do sraček (už tam jsme) ne pokrok.

Nevěřim v žádnej zázračnej kompilátor kterej by vše optimalizoval sám.

Napodobne, tiez neverim ze nejaka automatika optimalizuje vsetko perfektne sama.

Takze budeme vsechno psat v ASM nebo radsi MC? Vzdyt ty kompilatory jsou tak zle!

Obcas mi pripada ze tu nekteri jedinci v zivote nic nenapsali vic nez hellowordy... Bez vyssich jazyku je nemozno dosahnout rozumnou produktivitu prace a o te to tak nejak je.

Neni toho OT trochu moc?

Je, vraťte se raději k tématu, ať to tu nemusíme s Flank3rem celé promazat

Dnes se u AMD, resp. v posledních dnech objevila newska

20-jádro STeamroller zvaný "Boulder" se objeví někdy v roce 2014. Jedná se o procesor určený do serverů a pasujícího do nového socketu GC36. Mezi pár dalších více či méně dostupných informací jsou 12MB L3 cache, v případě slepence procesoru to bude až 24MB. Procesor by snad mohl mít podporu DDR4 (3200 MHz) i DDR3 LV (DDR3 2133 MHz nativně), integrovanou PCIe 3.0 a HT 4.0 (až 16GT/s v obou směrech!)
http://tweakers.net/nieuws/82803/amd-vo ... cores.html

Kaveri "odlozeno" na 2H 2013 - mezeru vyplni Trinity 2.0.

Dalo se to cekat. V kompilerech zrejme neni jedina zminka o 'bdver3', 'srver1' nebo 'vfver1'. Nebyl prezentovan ES Kaveri, tak jako bylo predstavovano Llano a Trinity dlouho pred vydanim.

http://www.semiaccurate.com/2012/08/06/ ... inity-2-0/

Kruci, zrovna dnešní novinka...No je to naprd, teoreticky přece Steamroller musí být už hotov?!

Tapeout a vyrobene vzorky jsou zrejme 1-2 roky pred dostupnosti. Treba Barcelone to trvalo 1 rok.

No hurá, Hotchips nás jen utvrdil, že Steamroller je rozpracovaný. A stále tak nějak doufám, že se objeví i serverový derivát jako desktop procesor.

FP se zdá pozměněný (zmenšený), MMX jednotky jsou jinde a i dekodér. Také by mohly být sníženy latecne. Měl by být tedy zvýšen i single thread výkon (jde ale o kolik).



Zvětšení L1 cache by také mělo přinést mírné zvýšení výkonu a snížení latencí. Jak to ovlivní změnu L1-D, toť otázka.

Změny z L1 komunikaci do L2 by měly taky přinést další nárůst výkonu. Zajímavé je takzvaná dynamická L2 cache, která s epřizpůsobí dle vytížení a má smysl nejvíce v notebook segmentu, kde napomůže efektivnější spotřebě. S L3 se však nečekají žádné podstatné změny


http://www.anandtech.com/show/6201/amd- ... chitecture

Dá se říct, že je (opět) kladen důraz hlavně na integrer výkon na úkor FPU výkonu. Jedna MMX pipe úplně zmizela , žádné nové 256 bit FMAC pipelines se nekonají, počet 128 bit FMAC pipes zůstal nezměněn ( takže 2 cykly pro 256 bit AVX ) , není znám počet load/store jednotek. Malá L1 Data Cache bohužel zůstala.... Dva dekodéry se očekávaly (slabé místo BD architektury), Zdá se že zapracovali na latencích a Cache policy. Celkem překopaný Front-End + obdoba Sandy Bridge micro-Op cache. Důraz na silnější single-thread. K nějakému výraznějšímu nárustu výkonu by tedy mohlo dojít, bohužel FPU je výkonem stále pozadu za Intelem, takže na hry to nebude


btw z uvedeného schématu mi pořád není jasné, v čem spočívá ten "greater parallelism" ??? Jádro nemá ani více INT jednotek, ani více FMAC pipelines, nic co by odpovídalo názvu. Takže v čem je zakopaný pes ???


PS: ještě tohle je zajímavé :

This one falls into the reasons-we-bought-ATI column: future AMD CPU architectures will employ higher levels of design automation and new high density cell libraries, both heavily influenced by AMD’s GPU group. Automated place and route is already commonplace in AMD CPU designs, but AMD is going even further with this approach.

The methodology comes from AMD’s work in designing graphics cores, and we’ve already seen some of it used in AMD’s ‘cat cores (e.g. Bobcat). As an example, AMD demonstrated a 30% reduction in area and power consumption when these new automated procedures with high density libraries were applied to a 32nm Bulldozer FPU:
The power savings comes from not having to route clocks and signals as far, while the area savings are a result of the computer automated transistor placement/routing and higher density gate/logic libraries.

The tradeoff is peak frequency. These heavily automated designs won’t be able to clock as high as the older hand drawn designs. AMD believes the sacrifice is worth it however because in power constrained environments (e.g. a notebook) you won’t hit max frequency regardless, and you’ll instead see a 15 - 30% energy reduction per operation. AMD equates this with the power savings you’d get from a full process node improvement.

We won’t see these new libraries and automated designs in Steamroller, but rather its successor in 2014: Excavator.

FPU mi moc nevonia ale aspon silna IGP v APU to vykonpenzuje
Vykon v int porastie, FPU , ale nevyzera to ruzovo. Ja to vidim asi az na Excavator, ale mozno tam bude len 1Fmac a 1MMX Na druhu stranu tieto slajdy pochadzaju z legendarne babrackeho AMD marketingu, takze ja to vidim este na zopar odlisnych prezentacii ved do uvedenia maju casu dost.

edit: fakt zaujimava citacia, ta uspora by bola uzitocna v notebookoch, desktop bude uz asi mimo ak nizsie frekvencie nebudu kompenzovat pomocou IPC aj ked nemal by byt Excavator vyrobeny pomocou 20nm technologie?

THANATOS píše:FPU mi moc nevonia ale aspon silna IGP v APU to vykonpenzuje
Vykon v int porastie, FPU , ale nevyzera to ruzovo. Ja to vidim asi az na Excavator, ale mozno tam bude len 1Fmac a 1MMX Na druhu stranu tieto slajdy pochadzaju z legendarne babrackeho AMD marketingu, takze ja to vidim este na zopar odlisnych prezentacii ved do uvedenia maju casu dost.

spíš tam bude jedna 256 bit FMAC se sdílenou MMX unit



\\ Leda že by tu FPU konečně nahradili nějakým GCN2 SIMD ekvivalentem ....

\\\ Počkej, za chvíli sem přijde Zenith a ten ti vysvětlí že to nepůjde

del42sa to by bola nocna mora
Je mozne, ze nieco bude vediet spracovat GCN2. Nechajme sa prekvapit s cim nas prekvapia

del42sa píše:

THANATOS píše:FPU mi moc nevonia ale aspon silna IGP v APU to vykonpenzuje
Vykon v int porastie, FPU , ale nevyzera to ruzovo. Ja to vidim asi az na Excavator, ale mozno tam bude len 1Fmac a 1MMX Na druhu stranu tieto slajdy pochadzaju z legendarne babrackeho AMD marketingu, takze ja to vidim este na zopar odlisnych prezentacii ved do uvedenia maju casu dost.

spíš tam bude jedna 256 bit FMAC se sdílenou MMX unit



\\ Leda že by tu FPU konečně nahradili nějakým GCN2 SIMD ekvivalentem ....

\\\ Počkej, za chvíli sem přijde Zenith a ten ti vysvětlí že to nepůjde

Moc to nevysvětlim protože opravdu nejsem CPU architecture engineer... nevim jak by se taková věc realizovala, z toho mála co vím snad jen to, že u FPU je klíčové aby byla nelatentní a výpočetní jádra GPU jsou poměrně latentní. Pokud by GPU šlo použít pro FPU x87 výpočty už by to tu dávno bylo a náš výkon v tomto ohledu x-násobnej.


Jinak ty změny vypadaj jako nula od nuly pojde. Zvětšešní L1 je k víte čemu když je pořád write-trough. FPU výkon by mohl i klesnout.... prostě P4 made by AMD. Vyvíjí se to velice obodbně. Co se toho "ultimátního paraelizmu", kterej tam nikde nevidíš týče, tak to je jen marketing AMD, vždyť oni tvrdili že Buldozer je ideální herní CPU.... teda tvrdili to před vydáním a před recenzemi....

Steamroller bude mat vylepsenia, ale vykonom bude stale pozadu, takze predaje bude tahat integrovana grafika.
Osobne som zvedavy na AMD jaguar popripade co prinesie haswell v roku 2013.

P.S. Je mozne, ze 1MMX bude rozdelena medzi tie 3 ostatne Pipelines, ale to je len spekulacia. Tak ci tak FPU vykon je v AMD na vedlajsej kolaji.

edit: zaujimave by bolo porovnanie 4C Jaguar vs 2M/4C SR na rovnakej frekvencii hlavne v FPU testoch.
http://semiaccurate.com/forums/showpost ... tcount=218

Těžko odhadnout,ještě nás vlastně čekají tři bulldozery,nyní Vishera,pak Steamroller a pak Excavator,az pak může skončit éra BULDOZERU.TEN multi thread však bude u bulldozeru stále asi hnací silou.