AMD normalizuje hardwarovou škálovatelnost softwaru

K tématu prosím

OMG tak chlape za takyto clanok sa mozes smelo hanbit, ved ty nemas ani paru o tom co pises! Vies ako daleko je bytecode (ci uz Java alebo .NET) a instrukcie procesora? Vies vobec PRECO vzniklo nieco ako JIT, CIL apod? Odporucam si nastudovat minimalne serial o .NET co bol tuna na zive.cz (inac pomerne dobry, chvalim autora), nieco malo o architekturach procesorov a az potom zacat pisat taketo zblebty.

Dobře, k tématu. Takže u této technologie jde o to, že AMD přidá do procesoru samostatnou hardwarovou jednotku, která bude moci sledovat ostatní části procesoru a shromažďovat data o jejich využití a to na úrovni jednotlivých programových vláken. K této jednotce pak budou moci programy přistupovat pomocí nových instrukcí, výhodou bude, že sledování bude prováděno hardwarově, takže bude jen minimálně snižovat výkon.

Co pak programy provedou s nasbíranými daty, to už je na autorech programu. Jednou z možností je třeba průběžná optimalizace kódu JIT compileru apod (tolik k Javě a .NET, na kterých tato technologie vůbec není závislá jak vy tvrdíte, nebo jak to aspoň vypadá z té příšerné věty uprostřed vašeho článku), ale rozhodně to není využití jediné.

Mam pocit že originální text není stejného významu

http://www.google.com/translate?u=http%3A%2F%2Fnews.mydrivers.com%2F1%2F89%2F89158.htm&langpair=zh%7Cen&hl=en&ie=UTF8

„AMD today announced a new set of norms "Light-Weight Profiling" (LWP), aimed at improving multi-core processors the efficiency and improve the parallel application software performance.

In the meantime, AMD had made "hardware scalable software parallelism" (HESP), prepared through a series of innovative technologies to improve the parallel application software, AMD's multi-core processors application performance.

As a processor level mechanism, LWP HESP plan is the first practical technology. It is located at the application layer software with Java,. NET Framework, such as run-time environment, using memory, planning code technology, dynamic, real-time processing code to the greatest extent optimized multi-threaded performance.

Clearly, LWP can greatly enhance multi-core system on Java,. NET type of proceedings of performance and efficiency, both for hardware or software development is of important significance.

AMD is also intend to invite Intel to join the program, but Intel spokesman said it had not received from AMD's official invitation. „

Strojovej překlad ve své plné kráse... už se nedivim těm žvástům v článku, je tam totálně zpřeházenej slovosled a tak ty věty mají úplně jiný význam než mají mít. Přečtěte si tu specifikaci od AMD (myslím to PDF).

Ano, ale to PDF není o snaze něco normalizovat a spolupracovat s Intelem, ale pouze o vlastních hardwarových krocích AMD, jak lépe následné normalizace využít.

Samotný článek je právě o snaze něco normalizovat, proto byl přizván i Intel. Jinak žádný slovosled v dotčené části přehozen nebyl.

Uvedl jsem i anglicky píšící server, ale má zjednodušenou verzi.

http://www.hardspell.com/english/doc/showcont.asp?news_id=1229

Pro ověření slovosledu si přeložte slovo po slovu

作为一项处理器层次的机制，LWP正是HESP计划的第一项实用技术。它位于软件应用层与

Slovník

http://www.google.com/translate_t?hl=en

Slovo po slovu to překládat nejde, protože čínština má jiný slovosled než angličtina a pokud neumíte čínsky tak můžete význam jen odhadovat.

Překladač má údajně přes 20 mld. slov a slovních spojení, nebál bych se tedy, že si neporadí ze slovosledem lépe než kdokoliv z nás, když překládá na úrovni celých vět, souvětí a větších slovních celků.

http://en.wikipedia.org/wiki/Google_translate

As a processor level mechanism, LWP HESP plan is the first practical technology. It is located at the application layer software with Java,. NET Framework, such as run-time environment, using memory, planning code technology, dynamic, real-time processing code to the greatest extent optimized multi-threaded performance.

Veta ako vysita z PR prirucky, s nulovou vypovednou hodnotou - takze ine procesory nepouzivaju veci ako pamat, predikciu kodu, dynamicky sa meniaci kod v realnom case s optimalizovanym multithreadingom, vsak?

Vidim, ze sudruhovia z AMD uspesne pokracuju vo svojej kampani, ktoru zacali s Powerpoint prezentaciami roka o Barcelone... ale takto tie dlhy velmi nesplatia!

Rozhodně se nechci AMD zastávat,

ale zdroj je čínského původu a nakolik přebrali slovník AMD nevím. Rovněž bych zde nehledal velkou odbornost, neboť jde spíše o seznámení, bez hlubšího odborného rozboru, ty podrobnější články jsou běžně 10 či 20 stránkové. Jen zde se někdo stále snažil něčeho konkrétního a dlouho zavedeného chytit, ale mám pocit, že zatím není čeho konkrétního a vše je ve stádiu úvah a počátečního návrhu, k tomuto závěru mne vede i to, že nemohli nabídnout Intelu hotovou věc a pak ji opravovat.

Ještě k tomu překladu, překladač má údajně přes 20 mld. Slov a slovních spojení a pokud jsou pochybnosti o slovosledu tak lze překládat po částech či slovech. Čeština však není a ani tak brzy asi nebude.

http://en.wikipedia.org/wiki/Google_translate

Jinak těm financím AMD je něco hned vedle

http://www.zive.cz/default.aspx?section=44&server=1&article=137698

Ta věta je totální kravina, nemá cenu se jí zabývat.

Souhlasím

Ale právě na této větě někteří položili základ diskuze, po té co ji sami ještě více zkomolili, aniž by tušili o čem článek je, že jde o snahu některé činnosti kolem víceprocesorových sestav znormalizovat. Aby to nedělal každý jinak, jak se děje nyní, a jednotlivé procesory se o práci efektivně dělili… Proto se snažili přizvat i Intel, ale to někteří ani nečetli. V tomto kontextu, pak tato věta nemá valného významu.

Má někdo srozumitelnější jednoduché vysvětlení? Snad jsem neměl použít to rutinní či nalézt vhodnější slovo pro vrstvu, což někteří zneužili k zavedení debaty zcela jinam.

„As a processor level mechanism, LWP HESP plan is the first practical technology. It is located at the application layer software“

„Mluví se o dvou technologiích - LWP (Light-Weight Profiling) a HESP (hardware scalable software parallelism). Obě jsou umístěné v aplikačním softwarovém rutinním prostředí“

Otevřete si to PDF od AMD a přečtěte si "1 Introduction" až "3 Overview", to by mělo stačit k pochopení toho k čemu tahle technologie je (narozdíl od toho překladu z čínštiny), můžete si přečíst i zbytek, ale pochybuju, že to k něčemu bude, protože dál už se pouze popisují jednotlivé instrukce a možné návratové hodnoty.

již jsem to jednou psal:

"Ano, ale to PDF není o snaze něco normalizovat a spolupracovat s Intelem, ale pouze o vlastních hardwarových krocích AMD, jak lépe následné normalizace využít.

Samotný článek je právě o snaze něco normalizovat, proto byl přizván i Intel. Jinak žádný slovosled v dotčené části přehozen nebyl.

Uvedl jsem i anglicky píšící server, ale má zjednodušenou verzi.

http://www.hardspell.com/english/doc/showcont.asp?news_id=1229"

ostatní již taky bylo uvedeno... kdyby to bylo o tom pdf, tak bych se nezdržoval čínským překladem

Nejdřív jsem byl z hloubi duše přesvědčen, že se jedná o jakousi provokaci, nebo zkoušku čtenářské všímavosti. Od lživě.cz se není ostatně čemu divit. Stejně tak jsem si to myslel ale i o panu Ulhánovi, což se taktéž ukázalo jako nepravda. A konečně pro vysvětlení:

http://www.federmann.wz.cz/

Nejlépe je v anonymitě vystupovat pod mnoha jmény a jen …“PíííP“.

Pošlete mi kvalitnější článek a já jej rád nechám zveřejnit

Tak po přečtení odkazovaných originálních článků opravdu nevím o čem to autor psal, zcela určitě musí zapracovat na své angličtině, protože to co vyplodil jsou opravdu neskutečné bludy a s podstatou popisované technologie to má pramálo společné. A ještě ty příspěvky v diskusi... no comment.

Este mi tu chyba vyjadrenie nasho univerzalneho AMD experta fotoba... ten nas urcite zavali desiatkami linkov od AMD PR pocnuc, Hectorom konciac.. a autorovi, uz to tolko nehul

Jenom doplním, aby to někdo nepochopil jinak, současný instrukční soubor x86, by měl být doplněn o některé funkce Javy a NET Frameworku, tudíž by je procesor uměl vykonávat, bez nutnosti instalace obou programů …

Vite vubec co to je Java Virtual Machine a .NET Framework a jak a proc funguji (jako ze pouzivaji nejakou JIT atp.) a co je jejich smyslem ? Vy jste zase nestudoval, ze ? Posadit, za 5 !

"současný instrukční soubor x86, by měl být doplněn o některé funkce Javy a NET Frameworku, tudíž by je procesor uměl vykonávat, bez nutnosti instalace obou programů"

Předpokládám, že se s námi podělíte o zdroj těchto informací, protože jinak má toto tvrzení nulovou váhu.

AMD's proposal doesn't even directly apply to most computer users, they'll likely never use these instructions. What AMD is proposing is to our knowledge a first for the x86 instruction set: a set of instructions solely for developers.

http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=3065

napsal jsem "AMD zřejmě míří k", uvedl jsem jen některé odkazy, není problém najít další, ale vyčkal bych až se aktéři dohodnou či nedohodnou.

je to jen první oficiální krok o němž jsem pouze informoval. Nechtějte abych dopředu věděl nakolik se budou instrukční soubory měnit a co vlastně budou umět, až to AMD vydá rád o tom napíší, ale zatím je to jen v oblasti spekulací.

Vazeny pan Federmann,

pisete take bludy, ze sa mi az rozum zastavuje. Vas interpretacia povodneho anglickeho textu je nepresna a vase domnienky su smiesne. Neviete o com pisete, asi ste ani nikdy neprogramovali.

Za tento clanok sa mozete len hanbit. Neviem ci by ste mali pokracovat v pisani "odbornych" clankov.

odkazů nahoře je mnohem víc ... a každý text říká ...

a vsechny rikaji to same - ze AMD procesory poskytnou zpetnou vazbu (realizovanou pomoci nekolika malo novych instrukci) o efektivite prave beziciho programu. Z toho muzou nejvic tezit systemy, ktere provadeji runtime (realtime, just-in-time [JIT]) kompilaci (jako napr. Java nebo .NET) a muzou se tedy ihned prizpusobit. Uz chapete ?

AMD zřejmě míří k x86 instrukčnímu souboru, který by podporoval paralelní výpočty, a byl by výhradně pro vývojáře.

Jen některé z mnoha souvisejících článků:

http://www.hardspell.com/english/doc/showcont.asp?news_id=1229

http://www.hpcwire.com/hpc/1725751.html

http://techreport.com/onearticle.x/13053

http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=3065

http://news.softpedia.com/news/AMD-And-The-Parallel-Computing-62811.shtml

http://blogs.zdnet.com/Berlind/?p=725

http://www.technologynewsdaily.com/node/7740

http://www.tgdaily.com/content/view/33346/118/

Informace v jednotlivých článcích se někdy rozchází, ale zřejmě se dočkáme nového standardu x86,

jinak na „PF“ nemá smysl reagovat a zavádět diskuzi jinam.

Melete naproste nesmysly a "PF" ma naprostou pravdu. Chlape, proboha, jak muzete takhle tvrdohlave "vysvetlovat" neco o cem nemate sebemensi paru ?!? Mozna trochu rozumite elektrice, ale kolik jste toho naprogramoval ? Vzdyt to jsou totalni bludy...

Úžasné: "Instrukční soubor, který je výhradně pro vývojáře." A jak, prosím pěkně, vypadá "instrukční soubor, který není jen pro vývojáře"? Mí kolegové v práci píší kompilátory, těch se to nepochybně dotkne, stejně jako autorů operačních systémů (kvůli context switchům a ukládání stavu vlákna), ale většinu vývojářů to zajímat nebude. Je docela důležité umět rozlišit marketingový a novinářský hype (ano, i ten váš) a technickou realitu. Ten váš "nový standard x86" jsou momentálně dvě nové instrukce. Architekturou nadále zůstává AMD64. V posledních několika letech byly k procesorům inkrementálně přidávány nové vlastnosti a přesto nikdo nepocítil potřebu výsledek označit za "novou architekturu", na rozdíl od faktického odstranění segmentace, změny velikosti a počtu GPR registrů a jiných razantních změn.

BTW: "jinak na „PF“ nemá smysl reagovat a zavádět diskuzi jinam." Ubohý pokus.

Oprava: "na rozdíl od faktického odstranění segmentace, změny velikosti a počtu GPR registrů a jiných razantních změn" - tady chybělo "...které definují architekturu AMD64".

NO pamatuju si jeden počítač, který taky nepoužíval jen procesor, ale i zákaznické obvody, pro dělbu práce. Taky díky tomu i s tak slabým procesorem dokázali konkurova počítačům s mnohem silnějším procesorem. Samozřejmě nešlo jen o hardware, ale i poměrně specifický software.

Teda prelozit "runtime environments" jako "rutinni prostredi" by bylo k smichu, kdyby to nebylo k placi...

pan autor mel zrejme rum-time, kdyz to psal

Nehledejte doslovný překlad, rutina je jinými slovy řečený program, který má své vlastnosti …

Rutinní, tedy složeno s jednotlivých samostatných částí (rutin), nikoliv s jednoho nekonečného vlákna, kde se každá část zpracovává jako samostatný celek. Ale to by jste pochopili hned po prostudování AMD originálu…

vy jste pane toho asi moc nenaprogramoval. jinak byste vedel, ze rutiny (nebo taky funkce, procedury, podprogramy) jsou soucasti kazdeho vyssiho jazyka. ciste linearne se da programovat snad jen v assembleru, a to jeste s nutnou velkou davkou masochismu. takze omlouvat chyby v prekladu slovy 'vzdyt tak nejak to zdroj mohl myslet' je prinejmensim scestne. tot vse.

Podstatou, je možnost spuštění několika rutin současně, každá na jiném procesoru, bez ztráty návaznosti a priorit původního programu.

Samozřejmě program musí běžet na různém počtu procesorů, včetně běhu na jednom procesoru. Nelze tedy mluvit o klasické kompilaci či překladu programu do Javy a NET Frameworku, jehož rutiny se používají. Celé se to musí dít dynamicky i staticky.

Dynamicky myšleno, nepřiřazovat priority jednotlivým procesorům předem, který procesor je volný začne pracovat. Dopředu se neví na kolikaprocesorovém systému program poběží, ani jaký bude výkon jednotlivých procesorů… Staticky myšleno, neztratit původní návaznosti a priority programu, jak se děje u HT Intelu …

A to úžasné „runtime“ spíše RUN-TIME, něco jako trvale běžící, a „environments“ tedy vývojové. Bylo právě v této části zbytečné překládat, neboť tomu byly věnované zcela jiné části.

...a „environments“ tedy vývojové.

Proboha

Musim citovat: "Nevim cim jste vyucen, ci v jakem oboru vyskolen. Ale s cistym svedomim Vam mohu doporucit, abyste se venoval praci jakekoli, ale jine."

Doposud jste na mě působil jako docela rozumný člověk. Ale tohle, nezlobte se, patří spíš do nějakého ženského časopisu. Vždyť vy tu melete naprosté koniny! Celá ta technologie se motá kolem hardwarove-assisted profileru s nízkým overheadem a s překladem čehokoli do čehokoli to nemá vůbec nic společného! Specifikace LWP se týká pouze dodatečného hardwaru a rozhraní pro práci s ním na úrovni strojového kódu a architektury počítače, nijak neurčuje, co bude operační systém, aplikační runtime nebo sama aplikace s naměřenými daty provádět. Jak chcete něco takového "umístit do aplikačního softwarového rutinního prostředí s Javou a .NET Frameworkem."? A o žádném "HESP" není na stránkách AMD ani zmínka. Zjevně to celé slouží k tomu, aby software měl feedback o reálné náročnosti jednotlivých podúloh prováděného výpočtu a mohl je lépe plánovat. Pak by to možná mohlo pomoci i autorům JITů a kompilátorů s profile-based optimalizacemi, aby jejich výtvory generovaly rychlejší kód, protože je čím dál tím obtížnější deterministicky odhadnout počet cyklů potřebných k provedení určité sekvence instrukcí a navíc se mohou výsledky lišit model od modelu (procesoru). Nicméně to už je čistě na autorech softwaru a AMD s tím nemá absolutně nic společného, kromě toho, že jim poskytuje hardwarový ring buffer. (Lživě.cz - redefining reality... )

boze muj, nekdo by vam mel zakazat psat o vecech kterym nerozumite. navic pokud neumite sam anglicky, sotva muzete nekoho odkazovat na anglicky zdroj. par prikladu: a. runtime (nebo run-time) neznamena trvale bezici, ale pouziva se ve smyslu 'starajici se o beh'. b. environment neznamena 'vyvojovy', ale 'prostredi'. tedy v plnem kontextu prostredi zajistujici beh aplikace. c. podstatou neni moznost spoustet nekolik funkci soucasne, o to se prave stara rte (tedy prave zminovane java re nebo .net fw) a os, ale prave hw asistovane rozdelovani zateze mezi vice jader nebo cpu. d. jiste ze se jedna o klasicke kompilovani, jinak by to ani neslo. e. staticky mysleno (to je taky pekna kravina) funkce ktera ztrati vazby a kontext je nesmysl, protoze by nefungovala. rozdil mezi ht a tou novou technologii je v tom, ze intel ht se snazi vytizit nevyuzite casti jednoho jadra, zatimco tohle pomaha rozdelovat zatez dynamicky mezi vice jader. takze srovnavate hrusky a jablka. z toho komentare je citit jasna zaujatost proti technologii intel, co je intel je spatne, ale jakykoliv teoreticky slint co vypusti amd je naprosto genialni a prevratna novinka. nic proti amd, ale resit tyhle veci na urovni hw je sice zajimavej napad, ale imho nebude moc ucinnej a rozhodne nic prevratnyho. dokud se nezmeni filozofie programovani a mysleni programatoru, vic jader bude pro beznou praci vicemene zbytecnych. a vam bych doporucoval prestat psat o vecech kterym nerozumite.

"dokud se nezmeni filozofie programovani a mysleni programatoru..."

Obávám se, že to se nestane, dokud ze světa nezmizí věci jako C++ a Java...nebo přinejmenším dokud se C++ nepřesune jen hluboko do runtimu (kam se ostatně docela hodí). Ten nejlepší způsob, jak programovat SW pro desítky až stovky jader, ukazují jazyky, jako je Erlang nebo Haskell. Jenže taková razantní změna myšlení by spoustu programátorů zasáhla asi podobně, jako změna pohlaví.

mas 100% pravdu. v tomje jedna z nevyhod rostouci kapacity a vykonu hw - programatori nemaji motivaci optimalizovat a vynalezat => zadna zmena mysleni. prasackej nafouknutej kod pc sezere a diky nasobne vyssimu vykonu zpracuje mozna i o neco rychleji nez driv. pak se nesmime divit ze 1 gb ram je malo a blbej ovladac k tiskarne ma pomalu 50 mega. (jako krasnej priklad muzu uvest treba utorrent, kterej ma necejch 500kB a zvlada uplne to samy co jiny baliky >20MB ale rychlejc, ale to uz je tak trochu offt.)

No jo, ale to neni routine, ale runtime (jako run-time). Otrocky prelozeno ZA BEHU, cele mozna "behove prostredi" nebo tak nejak. Z zadnymi rutinami to nema co delat