hkultala sanoi:
Mistä tämä luku "950 wattia per prosessori" on peräisin?
Tuolla linkatussa Tom's Hardware jutussa.
Kiitos.
Mutta kun kyse on hyvin rinnakkaistuvista workloadeista, kannnattaa ottaa se energiatehokkain malli tuolta, eli 4.5 GHz @300W
Tosin itse tosiaan suhtaudun
hyvin epäilevästi noihin lukuihin.
Vähän kommenteja tompan artikkelista vielä
tomshardware.com sanoi:
He also re-emphasized that the Prodigy instruction set architecture can achieve a very high instruction level parallelism with software using so-called poison bits.
"very high" in-order-prossulle. Silti vain
lähestyy sitä mihin OoOE (käskyjen uudelleenjärjestely) pystyy, tietyissä tilanteissa joissa tuo mekanismi toimii. Ja niissä tilanteissa, missä tuo mekanismi ei toimi, OoOE kiertää kehää tuon ympärillä.
These cores run native code written and explicitly optimized for Prodigy (where VLIW architecture promises to shine)
Tähän asti vaan VLIW on aina sukannut CPU-käytössä, ollut ihan ok/hyvä signaalinkäpistelyssä. Lähimmäs käyttökelpoista on päässyt joku nVidian Denver. Ja nVidialla on ehkä tämän planeetan paras kääntäjätiimi.
as well as x86, Arm, and RISC-V binaries using software emulation and without performance degradation, according to the company.
Pelkkä binäärikäännös ei tähän riitä. Jos halutaan ajaa myös multisäikeistettyä softaa, niin hyvän suorituskyvyn saavuttamiseksi pitäisi käytännössä olla tuettuna vähintään yhtä tiukka konsistenttiusmalli kuin mitä kaikissa emuloitavissa arkkitehtuureissa (Applen macox Xää ajavissa ARMeissa on toimintamoodi jossa muistin konsistenttiusmalli on sama kuin x86ssa) jotta ei tarvi lisätä suurta määrää synkronointikäskyjä tietyissä tilanteissa.
Ja lisäksi pitää olla tuettuna sama virtuaalimuistin sivukoko jotta joku mmap()yms. jutut toimii (tässä Apple ottaa hiukan x86 emuloinnissa takkiin koska 4 kiB sivukoko on Applella kyllä tuettuna yhtensopivuussyistä mutta "toisen luokan kansalaisena" huonommalla suorituskyvyllä).
Ja jos se vuoden 1985 80386sta peräisin oleva 4kiB virtuaalimuistin sivukoko taas on "ensimmäisen luokan kansalainen" Prodigyssa aivan kuten moderneissa x86-64ssa, se laittaa rajoitteita L1D-välimuistille. (oleellinen syy, miksi AMDn ja Intelin L1D-kakut on paljon pienempiä kuin Applen)
Mutta pikaisesti en löytänyt dataa siitä, millainen tuon prodigyn muistin konsistenttiusmalli on ja millaisia virtuaalimuistisivukokoja se tukee.
The head of Tachyum admits that Qemu binary translation degrades performance by 30% to 40% (without disclosing any baselines) but hopes that real-world performance will still be high enough to be competitive. Meanwhile, some programs are already supported natively.
Oletan, että tämä pätee yhdellä säikeellä kun muistin konsistenttiudesta ei tarvi piitata. Sitten kun mennään moneen säikeeseen tilanne voi olla selvästi pahempi.
Ja oletus että 4-leveä VLIW voisi jotenkin haastaa OoOE-prossuja jossa 4-6 käskyä leveä frontend ja luokkaa 8-10 käskyä leveä backend on aika optimistinen, kun käytännössä nyky-OoOE-prossut on sekä leveämpiä että lisäksi OoOE mahdollistaa vielä käytännössä paljon paremman utilisaation. Ja tosiaan Intelillä, Applella ja AMDllä on aika paljon paremmat haarautumisenennustukset prossuissaan.
Radoslav Danilak sanoi:
"We are a CPU replacement and not an AI accelerator company, we are targeting cloud/hyperscalers and telcos," said Danilak. "Over time we plan to win some supercomputer customers, so we doubled the width of the vector/MAC units from 512 bits to 1,024 bits [which also brings in necessary data paths for the 4,096-bit matrix operations for artificial intelligence]."
Siinä, että samalla sekä hypetetään 5.7 GHz kellotaajuuksia (jotka siis vaikuttaa melko epärealistisilta sen perusteella mitä tuosta arkkitehtuurista tiedetään) että levennetään SIMD 1024 bittiin ja targetoidaan HPC-workloadeja haiskahtaa melkoinen suuruudenhulluus. 1024-bittinen SIMD on järkevä jossain <3 GHz taajuuksilla pyörivässä rinnakkaiseen laskentaan erikoistuneessa prossussa (kuten Fujitsu A64FX) mutta 5.7 GHz taajuuksiin kykenevä liukuhihna(*) ja energiatehokas rinnakkaislaskenta ei vaan (vielä tällä vuosikymmenellä) millään mahdu samaan ytimeen. Mitä enemmän liukuhihnavaiheita, sitä enemmän liukuhihnarekistereitä joihin pitää jokaisen käskyn suorittamiseksi kirjoittaa tilapäisdataa. Ja sitten kirjoitusten tiheys myös kasvaa kellotaajuuden mukana. Käytännössä liukuhihnaa pidentämällä liukuhihnarekisterien tehonkulutus kasvaa n. toiseen potenssiin kun kellotaajuus ja sen mukana suorituskyky kasvaa vain ensimmäiseen potenssiin.
Käytännössä (esim. sen julkaistun 7 kellojakson haarautumishutiviiveen pohjalta) vaikuttaa siltä, että tuon liukuhihna on liian pitkä siihen että sillä saavutettaisiin erinomaista energiatehokkuutta järeässä SIMD-laskennassa, mutta silti suhtaudun hyvin skeptisesti siihen että sillä voitaisiin saavuttaa tuota luvattua 5.7 GHz kellotaajuutta - liukuhihna ei silti meinaa olla tarpeeksi pitkä tuollaisiin taajuuksiin ja kriittisten polkujen optimointi tuollaisiin kelloihin on vaan hyvin vaikeaa ja AMDn ja Intelin insinöörit ovat tehneet hyvin paljon työtä että ovat sinne 5 GHz luokkaan päässeet.
(*) Toki siis joskus 10 vuoden päästä kun valmistustekniikat on kehittyneet ja 5.7 GHz voi saavuttaa lyhyemmällä liukuhihnalla, niin että silloin yhdistelmässä 1024-bittinen SIMD ja 5.7 GHz kello voikin olla jo jotain järkeä.
