Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
"Skutečně si nelze představovat, že pánové v..."
A přesto si podobné nesmysly zřejmě myslí spousta diskutujících. Nebo to tak občas vypadá. Vzpomeňte na Intel, jak údajně nic roky nedělal a kasíroval;-)
Ty víš jak to funguje ve velkém korporátu?
Podobně jak ve státní správě!
I na viditelných pozicích se skrývají neschopné slibotechny. Například Raja Koduri.
Natož někde hluboko v týmu.
Teda Koduri je velmi schopná slibotechna.
Ale snad pochopíte jak to myslím.
V Intelu v té době vývoj v podstatě nemohl moc dělat - neměl k dispozici informace o funkčním výrobním procesu. Respektive to, co měl k dispozici, nebyly informace, ale zbožná přání.
Jakmile se proces trochu otřepal, měl vývoj připravené celkem schopné nové jádro.
To, ze vyrobny proces nie je funkcny neznamena, ze vyvojovy tim sedi na zadku a pije kavu. Podla tejto logiky by to fungovalo tak, ze by sa s vyvojom navrhu cakalo az kym bude proces hotovy. Takze by sa defakto vonku vypustal generaciu stary proces (pretoze navrh a testovanie nieco trva, takze ked sa na trh dostane prvy produkt na procese X, fab uz ma proces X+1 "takmer hotovy").
Nie, to vyvojovy tim pre architekturu dostane na stol nejake predpokladane parametre v datasheete procesu a na tie sa to navrhne s predpokladom, ze v case, ked bude treba realizovat aspon overovacie prototypy uz bude proces v stadiu, ze dokaze vyrobit aspon nieco, hoc s mizernymi taktami a vytaznostou. Pretoze na overovacie prototypy to staci.
Preto mal Intel v sufliku pripravene nejake architektury na 10nm proces, ktory v podstate nikdy nebol vydany v podobe, v ktorej sa na zaciatku planoval do masovej produkcie. Lenze architektury v sufliku zastarali, takze ak by si pockali na 10nm, uz by s ohladom na novu situaciu na trhu neboli konkurencieschopne. Tak ich prerobili s ohladom na datasheet dostupneho procesu ktory mali. Tak vznikol daktoryLake. Nevoslo sa im to do TDP, tak z toho odhryzli nejake tie jadra. A pre 10nm proces potom navrhli novsie jadra.
Chybu, ktoru v Inteli (ale tusim predtym aj v AMD) spravili bolo to, ze cakali, ze proces pride. A on neprisiel. Tak cakali viac. AMD otvorene priznala, ze sa z toho poucili a nenavrhuju architektury "na krv" a nespoliehaju sa na to, ze im novy proces prinesie nejake benefity "zadarmo".
"Druhý set bylo možné využít jen v rámci co-issue, tedy ne vždy, ale jen za určitých příznivých okolností."
Takovéto vlastnosti vedou k tomu, že výkon se liší při opakování stejné úlohy.
Těžko se hledá vysvětlení a je pak náročné se s tím smířit a zachovat si duševní zdraví.
Podobně jak v CPU intelu bude nějaký "scheduler" co bude určovat, že jsou okolnosti příznivé?
Takové polovičaté řešení nechci!
> Takovéto vlastnosti vedou k tomu, že výkon se liší při opakování stejné úlohy.
AFAICT, nevedou. Jestli spravne ctu clanek, co-issue je podminen tim, ze nejsou vytizene celociselne jednotky (= "priznive okolnosti"). To znamena bud instruction scheduling v case kompilace, nebo dynamicky za behu, ale v obou pripadech stejny kod pobezi stejne. Tj nejedna se o nedeterministicky beh jako treba HyperThreading. Pokud o tom vite vic, sem s tim.
Bohužel víc o tom nevím.
Jistě že v laboratorních podmínkách, když poběží jen jeden proces, budou výsledky vždy stejné.
Ale obávám se že v reálném světě "dynamicky za behu", kde je spuštěno mnoho aplikací, nebudou vždy "priznive okolnosti".
Když něco vytíží celočíselné jednotky,nebo něco usoudí že je potřebuje, tak logicky klesne výkon FP32.
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.