Allvarligt säkerhetshål upptäckt i Intels processorer

Oavsett vad så drabbas även AMD vilket inlägget som jag kommenterade gav intrycket av att enbart INTEL drabbas vilket ej var sant..Själv har jag lärt mig genom åren att inte vara för snabb med uttalanden likt det jag kommenterade.Sen vet ju vi inte med säkerhet hur mycket prestanda intel tappar gentemot AMD..Sånt spelar ju in det med.
Så hur korrekt är då inlägget..Står inget om vilket av dom det gällde Meltdown eller Spectre i nyheten.Eller är jag helt blind?

A *competent* CPU engineer would fix this by making sure speculation
doesn't happen across protection domains. Maybe even a L1 I$ that is
keyed by CPL.

I think somebody inside of Intel needs to really take a long hard look
at their CPU's, and actually admit that they have issues instead of
writing PR blurbs that say that everything works as designed.

.. and that really means that all these mitigation patches should be
written with "not all CPU's are crap" in mind.

Or is Intel basically saying "we are committed to selling you shit
forever and ever, and never fixing anything"?

Because if that's the case, maybe we should start looking towards the
ARM64 people more.

Please talk to management. Because I really see exactly two possibibilities:

- Intel never intends to fix anything

OR

- these workarounds should have a way to disable them.

Which of the two is it?

Linus

Intressant diskussion det här! Håller med om det allra mesta du skriver, men jag måste påpeka de ställen där jag inte håller med.

Nej, nu är det du som blandar ihop två termer. Det du beskriver ovan är macro-op fusion: det gör att man kan slå ihop två instruktioner (en test-instruktion eller en beräkning och en villkorad branch) innan avkodningen och köra dessa två genom en dekoder (numer går det genom vilken dekoder som helst). På så sätt kan man alltså få igenom fem x86-instruktioner genom dekodern från Conroe till Broadwell, och sex i Haswell. Detta kom i Conroe för ett enda par instruktioner, och expanderades till något mycket mer generellt i Nehalem. Skylake förbättrade funktionen ytterligare något. Jag ignorerade det i genomgången, för vi talade inte så mycket om x86-instruktionerna.

Micro-op fusion är äldre. Det kom i Pentium M. Poängen är att de enkla dekodrarna under vissa sammanhang kan ta en instruktion som blir två micro-ops, koda av dessa, låta de passera OoOE-maskinen som en instruktion för att sedan sprängas i schedulern och skickas ut till två olika exekveringsenheter. Detta fungerar på två typer av instruktioner: en instruktion som både beräknar en adress och sedan lagrar data till den, och en instruktion som först laddar data och sedan modiferar den. Detta var en smart detalj i Pentium M eftersom det gjorde att den enda komplexa dekodern inte blev överlastad. Det har blivit relevant igen beroende på att det också sparar bandbredd i ROBben. Denna kan bara hantera fyra micro-ops per cykel, men två "fused" (ihopklistrade?) micro-ops räknas som en i det här läget. Enda sättet att få sex micro-ops per cykel fram till schedulern är att fyra av dem är ihopklistrade i två par. Jag har svårt att tro att Intel lade till en extra dekoder i Skylake om det bara är i det specialfallet som det faktiskt gör någon nytta. Därför tror jag att de jobbar på att öka bandbredden i ROBben till sex micro-ops i nästa design.

(OK, den extra dekodern hjälper till med annat. Den gör att man kan fylla på micro-op cachen i högre tempo än den kan tömmas - i medeltal - vilket gör att man snabbare kan stänga av hela det energikrävande dekoderblocket, och använda den energin till något mer värdefullt. Om mixen är att det ofta är enbart enkla x86-instruktioner så lönar det sig nog. Men ändå.)

Det är riktigt. Ännu viktigare är att micro-op cachen täcker in väldigt många fall, och då behöver man inte köra dekodern alls efter det första varvet igenom. Nämnde det mest för att belysa att optimeringarna för AMD och Intel är olika - AMD vill gärna ha lite mer komplexa x86-instruktioner.

Mycket och mycket, 5-7% tror jag att det stannade på.

Intel har sakta ökat bredden på sin design steg för steg. Den här gången tog de dekodrarna och retire rate (fast var den verkligen bara 4 i Haswell? Orkar inte kolla, du har säkert rätt), vilket gör reorder till flaskhalsen i Skylake. Därför tror jag att det är nästa sak de tittar på att göra bredare.

Jag vet inte om vi talar förbi varandra. När jag säger bandbredden i ROB så menar jag själva bredden på rename. Skylake kan döpa om 4 register per cykel, vilket är flaskhalsen. Detta har varit konstant sen Conroe. Under samma tid har vi fått fler exekveringsportar (från 6 till 8), fler dekodrar (4 till 5), större PRF, bredare vektorenheter, bredare vägar för att förse dem med data, mer bandbredd från cachen, HT, etc... Allt detta gör att konstruktionen blir bredare, och det är dags att uppgradera den enda biten som inte blivit bredare på tio år.

Håller med här, AMD vet nog inte om de skall skratta eller gråta. Om Intel nu löser problemet i Ice Lake så är det säkert helt OK för dem, då kommer folk att optimera som innan och be kunderna att byta processorer om de vill ha mer prestanda, men om de inte kan göra det, och vi får vänta till nästa tock (som jag tror heter Sapphire Rapids), då är det mycket smolk i bägaren för AMD.