Anders Jensen Skrevet 6. oktober 2016 Del Skrevet 6. oktober 2016 (endret) Det som har kommet etter IA64 er stort sett ISA for throughput/watt optimalisering. Power er definitivt optimalisert for thread strength, men det er og blir et serielt ISA. Be explicit about your dependencies som vi sier innen mikrotjenester, det tror jeg i høyeste grad burde vært fokuset inne ISA design også. Ikke mellom metoder men mellom instruksjoner. Det er tross alt modellert som en DAG i kompilator og denne informasjonen forsvinner før den så blir gjenoppdaget i CPU til svært høy kost i både forsinkelse og effektforbruk. Jeg tolker deg som at du mener IA64 var spesielt optimal for thread strength. Men konkurrentene på den tiden hadde minst like bra resultater på single thread integerytelse. De hadde også 1-2 CMOS generasjoner fordel. Det var typisk 30-40% fordel per generasjon på den tiden. Men for all del, mye kunne vært bedre med IA64. Spesielt på integer ytelse. En av fordelene med til eksempel RISC-V er jo at support for ISA er modulær slik at en kan lage et design som kun supporterer det som skal til for nettopp integer. Det gir gode optimaliserings muligheter. less is more gjelder typisk når en gjør HW design. og det er jo litt av ulempen med FPGA, der er alle muligheter i prinsipp åpne, så effektiviteten blir deretter; laber kontra ASIC. Endret 6. oktober 2016 av Anders Jensen Lenke til kommentar
Anders Jensen Skrevet 6. oktober 2016 Del Skrevet 6. oktober 2016 (endret) Så bare for å konkretisere budskapet så kort som mulig;1) Jeg mener big.LITTLE er en mye bedre strategi enn akseleratorer. Om akseleratorene er bygd i FPGA eller ASIC er egentlig underordnet.2) Kode er instruksjoner og koblinger mellom de, gjerne representert som en DAG i kompilator. De fleste ISA (med unntak av EPIC, VLIW og EDGE, så langt jeg kjenner til) dropper mye informasjon om avhengighetene, ved serialisering, og det er et stort problem for å bygge "big" kjernene i big.LITTLE arkitekturen som skal optimalisere for "thread strength".LITTLE kjernene er typisk de som vil utføre det du ellers ville implementert i akseleratorer. Dette ser vi jo mange eksempler på ved bruk av GPU i HPC. Endret 6. oktober 2016 av Anders Jensen Lenke til kommentar
Anders Jensen Skrevet 13. oktober 2016 Del Skrevet 13. oktober 2016 Tidenes krystallkule rapport. Veldig kul lesing for en hw-nerd. https://www.informatik.uni-augsburg.de/en/chairs/sik/research/running/el4hpc/disruptive_tech/disruptive_tech_report.pdf 1 Lenke til kommentar
Anbefalte innlegg
Opprett en konto eller logg inn for å kommentere
Du må være et medlem for å kunne skrive en kommentar
Opprett konto
Det er enkelt å melde seg inn for å starte en ny konto!
Start en kontoLogg inn
Har du allerede en konto? Logg inn her.
Logg inn nå