mboost-dp1
Intel 15th Gen CPUs to Get Rentable Units: Why Hyper-Threading is Going Away
Jeg læser det som en væsentligt mere avanceret udgave af netop hyper-threading hvor threads analyseres og scheduleres på forskellige typer cores. Men stadig en art hyper-treading, hvor threads fordeles dynamisk mellem processorressourcer.
Det forekommer modigt når man tænker på hvor mange side channel attacks hyper-threading har medført. Hvordan kan man sikre, at der ikke kan lækkes information fra de andre tråde i et endnu mere kompliceret system?
Mon man skal til at sætte en "vulnerable section" processor status bit der forbyder hyper-threading og andre optimeringer af en kode sektion, for kryptografi? Det er bare ikke en særlig god løsning, for der vil være uendelig meget legacy kode der ikke bruger sådan en bit, som vil være sårbar.
Det forekommer modigt når man tænker på hvor mange side channel attacks hyper-threading har medført. Hvordan kan man sikre, at der ikke kan lækkes information fra de andre tråde i et endnu mere kompliceret system?
Mon man skal til at sætte en "vulnerable section" processor status bit der forbyder hyper-threading og andre optimeringer af en kode sektion, for kryptografi? Det er bare ikke en særlig god løsning, for der vil være uendelig meget legacy kode der ikke bruger sådan en bit, som vil være sårbar.
#2
Med hensyn til HT er det grundliggende fænomen at det er dyrt at smide processer ud af CPU og hive dem tilbage igen og derfor er der performance fordele ved at have en tråd standby i CPU fremfor ude af CPU.
Og traditionel x86-64 HT er den milde variant. Hvis vi betragter det generelle tilfælde XsYcZt så er Z/Y = 2 for x86-64 med HT, men Z/Y = 8 på SPARC T4 og T5 - de var rigtigt gode til multithreaded web servere.
Teksten omkring RU er lidt svær at forstå. Ikke overraskende når det er baseret på en patent tekst.
Men jeg læser det som følger.
Vi har en tråd som skal have udført A, B, C of D og en anden tråd som skal have udført E og F.
Vi har 2 cores.
Uden RU:
core 1 - A, B, C , D
core 2 - E, F
Med RU:
core 1 - A, B, C
core 2 - E, F, D
En tråd låner en anden tråds core når den er ledig.
Det er ikke indlysende for mig hvorfor RU og HT er enten eller.
Og det valgte eksempel fra patentet antyder lidt at et af de problemer der skal løses er det selvskabte problem med to forskellige slags cores P og E.
Med hensyn til HT er det grundliggende fænomen at det er dyrt at smide processer ud af CPU og hive dem tilbage igen og derfor er der performance fordele ved at have en tråd standby i CPU fremfor ude af CPU.
Og traditionel x86-64 HT er den milde variant. Hvis vi betragter det generelle tilfælde XsYcZt så er Z/Y = 2 for x86-64 med HT, men Z/Y = 8 på SPARC T4 og T5 - de var rigtigt gode til multithreaded web servere.
Teksten omkring RU er lidt svær at forstå. Ikke overraskende når det er baseret på en patent tekst.
Men jeg læser det som følger.
Vi har en tråd som skal have udført A, B, C of D og en anden tråd som skal have udført E og F.
Vi har 2 cores.
Uden RU:
core 1 - A, B, C , D
core 2 - E, F
Med RU:
core 1 - A, B, C
core 2 - E, F, D
En tråd låner en anden tråds core når den er ledig.
Det er ikke indlysende for mig hvorfor RU og HT er enten eller.
Og det valgte eksempel fra patentet antyder lidt at et af de problemer der skal løses er det selvskabte problem med to forskellige slags cores P og E.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Tagwall
Gå til bund