Taky už sem četl, že se nemá rozhodně jednat o nepovedená čtyřjádra, zajímalo by mě, jak to tedy je.

p.s. naplácejte šotkovi, v posledním odstavci vám tam pleskl hrubku. ....mohli stát...

trijadra se delaj proto, ze se da na wafer nafrkat jich vic vedle sebe.

Slavo> To uz radsej 1x CPU+ 2xGPU v crossfire :-)

WIFT: Mozna naopak ve výtěžnost své vlastní 65nm technologie neveri a trijadrove procesory budou vedlejsi efekt vyroby dvoujadrovych, ktere se normalne budou delat tak ze se vyrobi trijadro a to nejmene povedene jadro se vypne :-)

Podporuju to vobec dnesne OS? Teda neparny pocet vypocetnych jadier.

V podstatě prodávají "zmetky" a ještě s tím udělají díru do světa:-)))))))) Dovedete si tohle představit v jiném odvětví? Třeba se nepovede auto a bude z něj tříkolka:-)))))))))))

V tomto clanku sa zabudli zmienit o jednom dolezitom fakte - a to ze trojjadra budu (ak budu) stvorjadrove procesory s vypnutym jednym jadrom. Cast procesorov bude mat to jadro vypnute kvoli tomu ze bude nefunkcne a cast z nich pravdepodobne podla toho aky bude zaujem o troj-jadrove procesory.

Inu AMD potrebuje vyuzit svoje vyrobne kapacity na maximum a u stvorjadroveho procesora je celkom vysoka pravdepodobnot ze sa jedno jadro nevydari. No a vyhadzovat takeho procesory ako nepouzitelne by bolo mrhanie prave vyrobnymi kapacitami.

Wolfsteen : však ono to v jiných odvětvích tak dělá a nikomu to nevadí. Vem si třeba, kdyby ses narodil bez ... no prostě bez. Tak je z tebe ženská.

2 Wolfsteen: U aut to tak taky funguje - Folksvagen třeba rozpulí šestivál na dva tříválce nebo když má malej odbyt osmiválců, spojí dva do jednoho W16 a dva motory pak prodá v jednom autě. Dělaj auta jako stavebnici z LEGA :))

to sdf:

Každý člověk byl jednou ženou, poté rozhodují o výsledném vývoji pohlaví chromozomy (XX žena, XY muž). Nějaké vady při vývoji už mohou způsobit deformaci periferií, ale ne úplně jejich absenci. Může se stát, že vývoj zůstane stát na mrtvém bodě, ale to je jen pro 1 jedince z miliónu.

Bright: Sice je to silně OT, ale nedá mi, abych nezareagoval. O výsledném vývoji pohlaví nerozhodují žádné chromozomy, nýbrž geny (a to je rozdíl, jak ukážu dále), ještě přesněji bílkoviny, které ty geny generují. Tvar a vzhled pohlavních orgánů ovšem neurčuje, jestli je člověk muž nebo žena, to právě určují ty chromozomy. Takže muž je od počátku mužem, protože už v jednobuněčném stavu má kombinaci XY, bez ohledu na to, jaké pohlavní orgány se mu ve finále vyvinou, což obdobně platí i pro ženy. Oni totiž např. existují jedinci bez chromozomu Y (tedy XX - ženy), kteří mají mutaci genu na chromozomu X takovou, že vypadají (nejenom v rozkroku) a hlavně fungují jako muži.

OMG, Federmanne:

Spustit programy z X-Boxu 360 rozhodne nepujdou, protoze ten nema x86 kompatibilni CPU a ani nic jineho. Pocet jader je to posledni, v cem by byl problem :).
Co se tyce tech jinych trojic, tak treba zrovna RGB neni ten nejlepsi priklad, protoze to je vetsinou ulozeno jako RGBA nebo RGB0 a kdyz ne, tak je pristup k datum trochu komplikovanejsi a pomalejsi (ale zase se treba usetri bandwidth nebo misto).

happymaster23: dovolim si oponovat, udelat natvrdo optimalizaci pro 2 jadra je hloupost, napr. na databazich (uznavam, to neni typicka desktop aplikace) se vetsina procesu, ktere jdou bud zparalelizovat, nebo rozdelit mezi vice jader/cpu, typicky rozdeluji podle poctu jader/cpu v systemu (minimalne u nas v praci). je s tim problem, da to vice prace, ale vysledek stoji za to. u desktopovych aplikaci (treba u her), to bude zrejme versi problem, nicmene i to se da vyresit

Na to jste přišli jak, že se Celerony dělají z Core 2 Duo? CPUID jaksi nesedí a asociativita L2 cache taky ne. Tak si to opravte.
A proč by to Intel neuměl? Když může dělat dvoujádra tak, že vezme dva dvoujádrové čipy a na každém vypne jedno jádro a zachová celou 4 MB L2 cache pro jedno jádro (tj. má dvoujádro s 2x 4 MB L2 cache), tak proč by nezvládl tohle? Možná by měli problémy s rozdílnou asociativitou, ale oni by si v nejhorším nějak poradili.

WIFTa bych nenazýval zaslepeným, naopak je podle mě neutrálním a nepodléhá fanatismu "přetaktím Core 2 Duo o 1 GHz a natřu to všem AMDčkům".

BTW, vypadá to, že AMD trošku hrálo falešně s revizemi. Věc se má tak, že jsou v zásadě tři revize, o kterých se mluví:
DR-B1: CPUID 100F21h (stepping 1)
DR-BA: CPUID 100F2Ah (stepping A)
DR-B2: CPUID 100F22h (stepping 2)
 
Někteří testeři (např. tecChannel) dostali DR-B1 (http://www.tecchannel.de/_misc/img/detailoriginal.cfm?pk=360904&fk=1...), zatímco například Anandtech dostal DR-B2 (http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=3092&p=2). A teď ta zajímavá část. DR-B1 měla údajně nějaké potíže, které měly být vyřešeny v DR-BA, což by měla být DR-B1 s minoritními úpravami. DR-BA je produkční revize a jde do prodeje (aspoň to tvrdí AMD Compare - http://products.amd.com/en-us/OpteronCPUFilter.aspx).
Naproti tomu DR-B2 je novější revize, která opravuje některé chyby (podle Revision Guide - http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/...). Mezi opravenými chybami by měla být i chyba číslo 281 (... která zatím v onom PDF není zveřejněna), která by měla zvyšovat výkon paměťového řadiče, a proto obecně zvyšovat výkon v programech - taková zmínka se objevila na XtremeSystems od uživatele AMD FAE - http://www.xtremesystems.org/forums/showpost.php?p=2423416&postcount.... To by znamenalo, že testy provedené s revizí DR-B2 vycházejí lépe, než co dostanou zákazníci do rukou.
 
Mimochodem, docela zajímavá je chyba číslo 244, která říká, že pokud v programu v těsném závěsu následuje několik operací dělení, pak může dojít k chybnému výpočtu. Má se to řešit pomocí microcode update, ale to AMD nějak v posledních letech zanedbávalo, takže je vůbec otázkou, nakolik to výrobci základních desek implementují. A vyvinout procesor s takovým bugem, to už opravdu zavání, že vývoj byl trošku urychlený (mimochodem, Intel trpí podobným problémem, který ale není ošetřen v microcode update a Intel sám radí aplikovat do kódu tři NOPy, což je totální blbost a žádný kompilátor to neudělá - viz chyba AI20 v http://www.intel.com/design/processor/specupdt/313279.htm). Nějak nám ti výrobci poslední dobou produkují čím dál tím větší bastl.

2happymaster23: A co kdyby sis napřed něco nastudoval? NOP je zkratka pro No Operation. Žádný programátor s IQ větší než tykve a obdobně žádný kompilátor nebude dávat do svého kódu NOPy jen tak pro zábavu. Tím by tak akorát zasvinil RAM, cache a zaplácnul bandwidth. Prostě se to Intelu s tímhle bugem nepovedlo (taktně řečeno) a nemá se k jeho řešení. Až revize G0 to opravuje, ale všichni majitelé těch starších jsou nahraní. A ono taky další věc je, co udělat s kódem, který už je jen jako binárka - manuálně to tam asi nikdo kvůli neschopnosti Intelu dodávat nebude. BTW, Visual C++ má jeden z nejlepších (nejrychlejších a nejspolehlivějších) kompilátorů na trhu. Microsoft ve Visual C++ vytvořil špičkový programovací nástroj.
Jinak to, že tvůj 2.4 GHz C2D překoná všechna AMDčka, je více než úsměvné. AMD je pořád v FPU mnohem rychlejší (a kdo to myslí s kvalitou videa a audia vážně, ten jede jedině přes 80bit FPU a ne přes 64bit SSE) a taky ono AMD má za velmi dobré ceny dost vysoké frekvence... a frekvence je základ výkonu. Kde aplikaci nelze dobře paralelizovat (... což není tak neobvyklé), tam se hraje výhradně na instrukční latenci a frekvenci.

happymaster23: Problém je, že gcc má flagy a leccos, ale v optimalizaci kódu je mnoheonásobně slabší a horší, než Microsofský překladač bez těchto obezliček. To je takový malý problém. Co se týká vymáčknutí max. výkonu z hw, pak první krok je nepoužívat a nepustit k tomu gcc, neboť gcc je v optimalizaci kódu jeden z těch nejhorších a nejméně povedených překladačů z těch běžně používaných.

Já osobně bych mnohem spíše důvěřovat tomu, že Microsoft Visual C++ udělá výrazně rychlejší kód a vymáčkne z hw výrazně více a to i bez jakéhokoli většího nastaování, zatímco s gcc i když si pohrajete, tak výsledek bude mnohem horší - o vymáčknutí max. výkonu z hw u gcc nemůže být ani řeči. Měl jsem skoro pocit, že s gcc vtipkujete, když jsem Vás četl.

happymaster23: gcc (mimo jiné) i Microsoft překladač existuje obojí existuje pro Windows - těžko můžete srovnávat výkon Microsoft překladače pro Linux, když tam Microsoft neoperuje. A Microsoft překladač je opravdu špičkový kus softwaru.

Výkon operačního systému bych do toho netahal - ono totiž vůbec není jisté, jestli je Linux kernel vždy rychlejší a lepší za všech okolností, než Windows kernel. Já osobně o tom vůbec nejsem přesvědčen, i když se to obecně tvrdí. Používám oba systémy.

2happymaster23: Nějak ti (opět) došly argumenty, viď? Napřed že GCC je super a najednou, když se provalí, že je to jen průměr, couváš. To samé s NOPy - je zřejmé, že jsi vůbec nevěděl, o co se jedná, protože tvoje programátorská zkušenost je vesměs nulová. A proto dosud nechápeš, že nikdo nebude takový blbec, aby si prznil svůj kód NOPy kvůli tomu, že zrovna Intel neumí vyvinout procesor, který by neměl vážné chyby. NOPy nedělají nic jiného, než že snižují výkon. A když to ostatní procesory zvládají, tak proč se přizpůsobovat něčí chybě a snižovat výkon všem? Není důvod.

Když už se tu zakoplo o ty kompilátory, vylovil jsem pár testů zaměřených spíš na výkon. Jsou sice trošku out of date, ale je vidět, že Microsoftí kompilátory nejsou ořezávátka.

http://www.osnews.com/story.php/5602/Nine-Language-Performance-Round-up-...

http://biolpc22.york.ac.uk/wx/wxhatch/wxMSW_Compiler_choice.html

Tento je spíš na JIT ale VC++ se tam taky mihne
http://www.shudo.net/jit/perf/

Eagle_not_registered: NOPy se samozrejme pouzivaji a samozrejme mohou vykon i zvysit, napriklad tehdy pokud vlozenim NOPu dosahnes toho ze neco bude zarovnane na 64bitu. Optimalizovat kod pro moderni procesory je dost fuska a jen zridka plati, ze nejkratsi kod je zaroven nejrychlejsi.

Jednim z duvodu, proc je tezsi optimalizovat v GCC nez v Micro$oftim compileru je to, ze M$C (teda vcc nebo jak se zkracuje) ma optimalizaci natvrdo na x86, zatimco GCC ma vetsinu kodu spolecnou pro vsechny procesory, tedy i SPARCy, PowerPC (stary Mac) a radu jeste exotictejsich architektur.

fotoba: Takze antivirus mi pri skenovani bude nejen vrtet diskem, ale jeste roztacet vetrak na grafice. No pekne dekuju...

hkmaly: To s tou optimalizací Microsoft kompilátoru natvrdo na x86 je něco, co jste asi pronesl ve stavu silné opilosti. Před několika měsíci jsem třeba kompiloval Microsoftím kompilátorem pro ARM procesor.

Nehledě na to, že před nějakým časem dokonce Microsoftí kompilátor kompiloval pro Alfu, PowerPC, MIPS zcela určitě, ale dnešní stav ohledně těchto procesorů neznám.

Závěry nechť si čtenář udělá sám, raději no comment.

Miloslav Ponkrác: A to jako crosscompilace, nebo na tech architekturach bezi windows ?

Jsem schopny se mylit i strizlivy. Zvlast pri diskuzi na tema programu, ktery jsem na vlastni oci jeste nevidel. Druhou polovinou tvrzeni (ze optimalizace gcc se pise hure nez by mohla kvuli sdileni kodu mezi platformami) jsem si jistejsi.

hkmalý: Uf, omlouvám se za ten tón mého minulého příspěvku.

To pro ARM byla crosskompilace, to pro ty další procesory bylo nativní. Jinak Windows samozřejmě na ARM procesorech běží, stejně tak jako některé předchozí verze Windows běžely na nejrůznějších švábech.

Jen jsem chtěl naznačit, že Microsoft kompilátor je schopen kompilovat a optimalizovat pro řadu relativně rozličných procesorových architektur. A Microsoft dobře ví, proč to dělá, protože mít kompilátor, který je tohoto schopen je v podstatě nutná podmínka pro expanzi Windows (a nejen Windows) na různé trhy. Vezměte si, že Microsoft různé deriváty svých Windows honí na leččems - na PC, na herních boxech, v kapesních počítačích, v mobilech, v serverech - opravdu si myslíte, že všude je x86/x64 architektura?

P.S.: Ten kód co lezl ve strojáku pro ARM z toho MS kompilátoru byl velmi pěkný a velmi dobře optimalizovaný, opravdu radost pohledět. Takže i tam si dávají záležet.