Forum Övrigt Nyhetskommentarer Tråd Inlägg

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

4 5 6 7 8 9 10 11
Skriv svar
Permalänk
Inaktiv
●
Skrivet av pa1983:

Var det inte Ubisoft eller liknande som körde spel i ett VM som standard? I så fall hur påverkas sådana spel som kör antipiratskydd mm genom att hosta spelet i ett VM.
Virtualisering blir allt vanliga oavset.

Många vanliga processorer stödjer viritualisering, lustigt nog har intel primärt uteslutit K modellerna, dock inte alla tex min i7 3930K med C2 stepping är inte exkluderad dock är C0 steppigen det.

Gå till inlägget

Att använda virtualisering är idag ett måste för många, det finns dock containers och dockers räddar det från att fullständigt spåra ur. -Jag har polare som skulle behöva uppemot 1TB ram idag om det ej vore för containers och dockers.
Men ändå VM är så otroligt enkelt.

Jag funderar på att testa min 7700K om jag får tid, köra 2st VM på den en patchad och en opachad. Problemet är bara tidstiden att göra riktiga mätningar. Enkelt/snabbt är kanske att se på taskmanagern, även om detta suger.
-Själva 7700K, lär alltid vara opatchad, har man den skyddad från nätet så känns risken att den blir utsatt liten, speciellt när alla andra kommer att pactha.

Redigera
Citera flera Citera
Permalänk
Avstängd
●
Skrivet av anon200632:

Tror de inte skrattar då det verkar påverka de flesta cpuer inkl rycen om du läst tråden.

Gå till inlägget

Jag tolka det som att det påverka alla Intel's 64bits CPU men dom kanske menar alla 64bits CPU:er.

Visa signatur

Man är inte dum för att man har stavproblem.
Läs mer om min synfel Visual Snow
Om mig ----> #16970666

Redigera
Citera flera Citera
Permalänk
Inaktiv
●
Skrivet av anon200632:

Tror de inte skrattar då det verkar påverka de flesta cpuer inkl rycen om du läst tråden.

Gå till inlägget

Det finns spekulationer i att de kan dra alla över en kam, detta eftersom AMD är små. Men i vilket fall som helst, Intel kommer släppa fixade cpuer snart och dessa kommer självklart fixas så de kan köra snabbt.

Problemet med att det drabbar Intel är att i princip alla som gör något större har riktigt stora Intelsystem som kan bli riktigt lidande, man kan vara hur mycket AMD fanboy som helst, men man får ändå en rejäla problem.

Hade detta drabbat AMD, så har de inte lika stor marknad på serversidan. Men låt oss anta att de skulle ha haft fler, så är det frågan om AMD skulle överleva denna smällen? De har det så tufft på både cpu och gpu sidan och det behövs inte så mycket för dem för att ställa till problem.
Intel däremot, det är lite som när biltillverkare får återkalla bilar, visst inte bra, de större märkena kan dock jobba på som vidare och det märks ej så mycket. Ta volkswagen och dieselskandalen, visst katastrofalt, men har man cash tål man sånt.

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av pa1983:

Problemet med det testet som jag ser det är att dom kör 1080p eller 4K med Ultra settings och AA, alla som vet något om att testa CPU prestandan i spel vet att grafikkortet måste uteslutas som flaskhals.
Detta görs enklast genom att minska upplösningen till 720p, inställningar till lägsta (low) och av med AA och lyfta eventuella fps spärrar i spelet.
På så vis begränsar inte grafikkortet FPS'en i spelet utan processorn blir flaskhals, då kan man mäta skillnader mellan processorer eller i detta fall patchar som påverkar processorns prestanda.

Tyvärr säger det testat inget om vad CPU belastningen var före och efter patchen, kan vara så enkelt att processorn hinner med allt som begärs för att grafikkortet är flaskhalsen även efter patchen.
Men utan grafer över CPU användning så vet vi helt enkelt inte.

Tills någon gjort "riktiga" CPU tester under spel så får prestandaförlusten där nog vara osagd, men spel vad jag förstått gör färre systemanrop än databaser och annat servrar kör så man kanske inte behöver förvänta sig 30% lägre prestanda men 5% eller tom 10% skulle ju få AMD att se mer än likvärdig ut nu.

Har inte hittat någon på sweclockers eller andra forum som reagerat på hur felaktigt testen är gjorda, man testar inte CPU'n i spel på det viset det är grundläggande kunskap.

Gå till inlägget

Jag ser inte direkt problemet i att de testar under normala omständigheter? Vega64 och 8700k måste anses ändå vara bland de bästa de kan testa med? Så om det inte påverkas där så påverkas det inte normalt med den setupen. Det skulle dock vara bra om de testade med något lite mindre kraftfullare också för att se om problem uppstår med t.ex en 8100.

Givetvis går det inte att dra några generella slutsatser med säkerhet utifrån den data, såsom prestandan på windows 10 eller om CPU användningen har påverkats alls (t.ex som det som du säger om ökad processoranvändning utan ökad prestanda. Där vore ett test på t.ex BF1 intressantare eftersom det stressar mer, dock så saknar de möjligheten att köra det på Linux). Inte heller går det att dra slutsatser om att det gäller alla spel som du säger att vissa typer såsom onlinespel kan påverkas mera. Men om prestandan är som i vanliga fall så är den som i vanliga fall och det duger nog för mig.

Sedan går det förstås att fundera på vad ett CPU test är för spel. Vad är syftet med det? Det finns en rad exempel på personer som påstår att "Om man kör på 720p / 1x1 pixel så får man den riktiga prestandan om 10 år" , vilket gäller för dem spelen som man testar men behöver inte gälla generellt för spelen som släpps om 10 år. Det finns ingenting som säger att alla spel måste ha samma optimeringar om 10 år, och inte heller någon som säger att de inte måste ha det. Men nu handlar diskussionen om att benchmarka påverkan av CPU:n på prestandan i spelet vid olika upplösningar.

Här har jag två exempel på saker att ta hänsyn till:
1. Testning på 720p
Här är det som du säger. CPU:n påverkar mera under dessa omständigheter (en konsekvens av att tiden så går åt till rasterisering och postprocessing minskar (bara första bilden)) , men samtidigt så har även RAM en större roll (också en konsekvens av att GPU:n tar mindre tid på sig) så vad är det man benchmarkar då, RAM eller CPU? T.ex kan testning i 720p avslöja en riktig flaskhals i CPU prestanda i vissa spel. Ett exempel med crysis 3:
1800X https://www.youtube.com/watch?v=QPwdpCY4-l4
1800X SLI https://www.youtube.com/watch?v=enJA4ZmPl60
7700k https://www.youtube.com/watch?v=1LScXqoZRbg
7700k klarar inte av att hålla uppe prestandan med 1800X, trots att den har lägre settings (låg GPU användning är orsaken) . Det beror helt enkelt på att CPU:n inte hänger med (och skalar väl med DX12 och annat). Crysis är ett sånt fall där man kan se en skalning i 1080p där vi även ser en stor variation (som göms av AVG FPS).

RAM har även en påverkan vid 1080p, i vissa fall upp till 20% på genomsnittlig FPS. (källor https://www.youtube.com/watch?v=S6yp7Pi39Z8 https://www.youtube.com/watch?v=p--iuQhujqI ). Alltså borde högre presterande RAM ge en bättre bild av CPU:ns prestanda , ännu bättre i kombination med låga grafikinställningar i spel.

2. Testning vid 4K
Ja, i 99 fall av 100 är det värdelöst för att mäta CPU:ns prestanda. Men i vissa fall (DOOM) så används uttnyttjas GPU:ns prestanda till endast en liten del i 720p och har problem med att hålla FPS vid 200FPS på 2 lägre klockade Xeon processorer (8 kärnor vardera, 16 kärnor totalt) med lågt klockat RAM. I 4K däremot så var det en annorlunda situation där de presterade bättre än de som var grymma i 720p när GPU användningens relevans ökade. Då har vi ett fall då en CPU som är sämre i 720p är bättre i 4K och det är någonting som de som kör i 4K vill veta.
(Sedan är förstås 2x xeons mycket sämre i 720p, då FPS skulle öka för 1800X och 7700k eftersom DOOM har en 200 FPS spärr. Det är inte helt exakt lika gameplay, men de håller 109-152 FPS vs 90-132 FPS och 97-132 FPS).

Så där har vi några aspekter på varför det kan vara bra att testa båda upplösningar för att mäta CPU:ns prestanda i olika fall. Sedan sa jag ju:

Skrivet av Radolov:

Men verkar som prestandan i spel inte påverkas?

Gå till inlägget

Hittar någon något fel någonstans så ge gärna bevis och förklaring. Notera även att jag inte säger att du har fel, bara att det finns lite andra infallsvinklar på det hela där det kan vara intressant att veta både resultaten i 720p och 4k och att uteslutning av grafikkortet inte nödvändigtvis utesluter RAM från CPU:ns påverkan.

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av Yoshman:

Tror du blandat ihop ett par distinkta koncept här.

Gå till inlägget

Inte alls. Jag håller med om hela beskrivningen du gjorde i den här artikeln - och tack för att du skrev det så jag slapp - men det är en punkt där Intel har en flaskhals som de talat väldigt tyst om. Men låt mig peta lite i detaljerna nedan.

Citat:

Dispatch
Nästa steg i processen är avkodning där instruktionerna bryts upp i interna "micro-ops", detta görs numera även på ARM. Dessa interna instruktioner är väldigt lika oavsett om det är x86, ARM eller något annat. I huvudsak delar man upp instruktioner i minnesoperationer, heltalsoperationer samt flyttalsoperationer. Här kan Apples A10 skicka iväg sex micro-op per cykel, AMDs Zen har också en kapacitet på sex micro-ops. För Core skiljer det igen mellan Core2-Broadwell som kan skicka iväg fyra micro-ops. För Skylake beror det vilka instruktioner det handlar om, är sex micro-ops vid träff i micro-op cache annars är det fem micro-ops. Alla dessa är som vanligt "upp till".

Håller med, men vill lägga till att Zen bara kan plocka dessa 6 micro-ops (uops) från 4 olika x86-instruktioner. För att komma upp i 6, måste det således vara två instruktioner som genererar två uops. Intel kan å sin sida bara hantera komplexa x86-instruktioner (som resulterar i mer än en uop) i en dekoder, så de klarar inte mer än en sådan åt gång. I nästan alla fall är detta inte relevant, men Apple's design är lite mer generell här, eftersom ARM är så mycket lättare att koda av en x86.

Citat:

ROB
Sedan kommer ROB (ReOrder Buffer) in i matchen. Här är också där man går från in-order till att köra saker spekulativt, verkar vara just den spekulativa delen där buggen ligger i (återkommer till det). Storleken på ROB avgör hur många instruktioner som kan vara "in-flight", ju större ROB ju större chans är det att fullt ut kunna nyttja alla beräkningsenheter. ROB är 192 stor i Apples A10 (det taget från Apples LLVM beskrivning av A10, har ingen info för A11). Även Zen har en ROB på 192 platser.

För Core har ROB ändrats väldigt många gånger. Core2 (Conroe) har en ROB på 96, Nehalem/Westmere 128, Sandy/Ivy Bridge 168, Haswell/Broadwell 192 och Skylake har 224 platser i sin ROB.

ROB är en förutsättning för den s.k. Tomasulo tillståndsmaskinen som är metoden man använder för att köra saker "out-of-order" men ändå säkerställa att den externt observerade effekten är som-om man körde allt i sin korrekta sekvens.

Det är här Intel har en flaskhals som de andra inte har. Intel kan hantera 4 instruktioner per cykel i den här fasen, medan de andra kan hantera 6 (AMD kan bara hantera 4 flyttalsinstruktioner här, men det beror på andra grejer längre ner och spelar inte så stor roll i vilket fall. De hanterar 6 heltalsinstruktioner, eller 4+2). Undantaget i Intel's fall är att de har micro-op fusion, där de kan ta två speciella micro-ops och hantera dem som om de vore en den här fasen och i schedulern lite längre ner. Detta fungerar dock bara i ett fåtal fall när två micro-ops skall gå igenom samma exekveringsenhet och jobbar på samma data. Detta är en flaskhals i Skylake.

Det är inte så relevant i Haswell, som bara klarar att få fram 5 uops ur cachen eller 4 ur dekodern, men Skylake gjorde denna bredare. Det är därför jag tror att Intel kommer att behöva göra denna bredare med Ice Lake.

Citat:

Execute
När en instruktion som ligger i ROB har all indata kan den exekveras. Apples A10 kan påbörja upp till nio instruktioner per cykel (4 heltal, 2 minnesoperationer samt 3 flyttal/NEON). Inte helt säker på Zen här (hittar ingen info), men om det inte finns några begränsningar jag missat borde det vara upp till 12(!) instruktioner (som måste bestå av 4 heltal, 2 minnesoperationer samt 4 flyttal). För Core är det Haswell som är vattendelaren för ovanlighets skull. Innan Haswell är det max sex instruktioner (3 heltal/flyttal med valfri mix samt 3 minnesoperationer) medan Haswell och framåt är det åtta instruktioner (4 heltal/flyttal med valfri mix samt 4 minnesoperationer).

AMD är inte så öppna här, men om jag minns rätt är det max 10 på Zen.

OBS också att Intel är väldigt begränsade i exakt vilka instruktioner som kan gå tillsammans (exekveringsportarna), men nu kommer i in på alltför petiga detaljer.

Citat:

Retire
Sista steget är "retire". Tanken (och häri ligger buggen, tanken håller inte riktigt) är att "retire" steget säkerställer att den externt observerbara effekten blir som-om allt kördes in-order hela vägen. Apples A10/A11 kan "retire" 6 micro-ops per cykel, Zen 4 micro-ops per CPU-tråd (så totalt åtta per kärna). För Core är åter igen Skylake annorlunda, är 4 micro-ops (per kärna/tråd) fram till Broadwell medan det är 4 per tråd / 8 totalt per kärna i Skylake.

Lite OT men ändå väldigt intressant: sett över hela pipeline är Apples A10/A11 väsentligt bredare

Också OT: Zen och Apple's designer är ganska lika varandra, åtminstone bakänden. Jim Keller har designat bägge.

Citat:

Buggen
Måste säga direkt: vet inte exakt vad buggen är, den informationen är inte släppt än. Dock sa nog AMD-ingenjören lite mer än vad han egentligen fick i sin förklaring till varför Zen inte har problemet. Han nämnde spekulativ exekvering av kod som ligger på kärnans priviligeringsnivå (ring 0) när man fortfarande befinner sig i en applikation (ring 3). Detta gör det möjligt att göra en rätt kvalificerad gissning.

Hela poängen med ROB är att kunna köra saker i en annan ordning än den sekvens instruktioner faktiskt har. Vidare kan man "gömma" latens genom att "gissa", spekulativt, köra saker. Så länge man inte gör "retire" ändras inget av de tillstånd man normalt kan observera, är därför möjligt att spekulativ köra saker.

Den stora skillnaden mellan "big-core" designer som Core, Zen och Apples ARM och mindre kärnor är till stor del storlek på olika buffertar vilket bl.a. avgör hur mycket spekulativ exekvering som kan göras.

Vad Intel verkar göra och andra inte verkar göra är att spekulativt köra saker även om man spekulativt kör något som befinner sig på en högre priviligeringsnivå än vad man faktiskt befinner sig på.

Covert channel
Åter igen, jag gissar. Men är rätt 100 % säker på att buggen inte är att detta direkt låter "vanliga" applikationer läsa minne som tillhör kärnan. Men om nu spekulativ exekvering av kernel-kod händer när man fortfarande befinner sig i user-space kan det leda till indirekta effekter som kan observeras även om de inte går till "retire".

T.ex. så måste spekulativa läsningar/skrivningar läggas in i cachen. Man "ser" inte dessa innan de verkligen händer, d.v.s. "retire" körs, men bara det faktum att man slänger ut något som redan ligger där påverkar prestanda på ett sätt som kan mätas (kan blir cache-miss som inte skulle hända om den spekulativa koden inte gjorts)!

En sak man kan använda detta till är att få en bild av hur kärnans virtuella adressrymd ser ut. Om man får CPUn att spekulativt läsa en virtuell adress som inte är mappad i kärnan så kommer det inte påverka cache då en sådan access kommer generera ett undantag (ett page-fault som inte kan lösas då minnet faktiskt inte är mappat). Omvänt så kommer en virtuell adress som är mappad i MMU samt ligger i TLB (Translation Lookaside Buffer, cache för virtuellt-till-fysiskt minne) att i vissa fall orsaka en effekt som eventuellt kan observeras redan innan man når kärnan, operationen kanske inte ens händer i praktiken då effekten kommer av spekulativ exekvering.

Den här artikeln tyder på att det kan ha gått till ungefär som du beskriver:

https://cyber.wtf/2017/07/28/negative-result-reading-kernel-m...

Visa signatur

5900X | 6700XT

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

Vet ej om någon postat detta i kommentarsfältet men här är intels svar på det https://newsroom.intel.com/news/intel-responds-to-security-re...

Visa signatur

9800X3D || Gigabyte Aourous Master RTX 5080 || Phanteks Enthoo Pro 2 || Seasonic Prime TX 1000W || 32GB CL30 600MHZ DDR5 || Asus PG27VQ ||

Redigera
Citera flera Citera
Permalänk
Hedersmedlem ★
●
Skrivet av roo:

Vet ej om någon postat detta i kommentarsfältet men här är intels svar på det https://newsroom.intel.com/news/intel-responds-to-security-re...

Gå till inlägget

Intressant och potentiellt missledande uttryckt av Intel:

Citat:

Recent reports that these exploits are caused by a “bug” or a “flaw” and are unique to Intel products are incorrect. Based on the analysis to date, many types of computing devices — with many different vendors’ processors and operating systems — are susceptible to these exploits.

Det ser ut som skrivet av en jurist där det går ifrån att handla om ett specifikt säkerhetsproblem till att övergå till en generell kommentar om diverse svagheter som upptäcks i hård- och mjukvara. Det kanske är jag som feltolkar det, men för mig framstår det som ett klassiskt exempel på FUD.

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

30% prestandaminskning av vad? Från 0.5 sekunder till 0.65 sekunder att öppna en hemsida, oj vad jag är brydd om det... not.

Skrivet av dannesthlm:

Saker känns lite förvirrande som "ovetande" då vissa hävdar att bristen bara kan "utnyttjas" på datorer med virtualisering, medan andra hävdar att t.ex. javascript i en webbläsare skulle kunna utnyttja buggen för genom "buffer overflow".

Tycker att fria tider (om informationen i artikeln nu stämmer) för övrigt lyckades prestera en betydligt bättre och mer förklarande artikel än sweclockers vilket man nu också kan tycka vara konstigt.

http://www.friatider.se/snart-kan-din-dator-bli-h-lften-s-sna...

Gå till inlägget

Håller med om att de förklarar på ett bättre sätt vad det handlar om.

Skrivet av mpat:

Det finns uppenbarligen en exploit som är praktisk att använda mot moln-leverantörer, men jag skulle inte vara så säker på att vi kan blåsa faran över för övriga. Själva grundproblemet, att man kan läcka information från kerneln till icke-privilegierade program, går t.o.m att göra i Javascript.

Gå till inlägget

Men kan man inte genom Antivirusprogram skapa skydd om detta då, det finns väl javascript virus?

Visa signatur

An application program (sometimes shortened to application) is any program designed to perform a specific function directly for the user or, in some cases, for another application program.
https://www.userbenchmark.com/ Talar om vad du har!

Redigera
Citera flera Citera
Permalänk
Inaktiv
●
Skrivet av roo:

Vet ej om någon postat detta i kommentarsfältet men här är intels svar på det https://newsroom.intel.com/news/intel-responds-to-security-re...

Gå till inlägget

https://newsroom.intel.com/news/intel-responds-to-security-re...

for the average computer user, should not be significant and will be mitigated over time
Bertil och Agda 108 år pustar ut, säkerligen även gamers.

Intel is committed to product and customer security and is working closely with many other technology companies, including AMD, ARM Holdings and several operating system vendors, to develop an industry-wide approach to resolve this issue promptly and constructively.

Så Amd som har släppt en helt ny arciture som garanterat har säkerhetshål som får detta likna en droppe i havet, men Intel när de är så extremt stora har så väldigt mycket folk som testar dem. Samma problem lider windows av, visst det har stora brister. Men användarantalet gör att små brister kommer fram.

Senast redigerat
Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av Radolov:

Jag ser inte direkt problemet i att de testar under normala omständigheter? Vega64 och 8700k måste anses ändå vara bland de bästa de kan testa med? Så om det inte påverkas där så påverkas det inte normalt med den setupen. Det skulle dock vara bra om de testade med något lite mindre kraftfullare också för att se om problem uppstår med t.ex en 8100.

Givetvis går det inte att dra några generella slutsatser med säkerhet utifrån den data, såsom prestandan på windows 10 eller om CPU användningen har påverkats alls (t.ex som det som du säger om ökad processoranvändning utan ökad prestanda. Där vore ett test på t.ex BF1 intressantare eftersom det stressar mer, dock så saknar de möjligheten att köra det på Linux). Inte heller går det att dra slutsatser om att det gäller alla spel som du säger att vissa typer såsom onlinespel kan påverkas mera. Men om prestandan är som i vanliga fall så är den som i vanliga fall och det duger nog för mig.

Sedan går det förstås att fundera på vad ett CPU test är för spel. Vad är syftet med det? Det finns en rad exempel på personer som påstår att "Om man kör på 720p / 1x1 pixel så får man den riktiga prestandan om 10 år" , vilket gäller för dem spelen som man testar men behöver inte gälla generellt för spelen som släpps om 10 år. Det finns ingenting som säger att alla spel måste ha samma optimeringar om 10 år, och inte heller någon som säger att de inte måste ha det. Men nu handlar diskussionen om att benchmarka påverkan av CPU:n på prestandan i spelet vid olika upplösningar.

Här har jag två exempel på saker att ta hänsyn till:
1. Testning på 720p
Här är det som du säger. CPU:n påverkar mera under dessa omständigheter (en konsekvens av att tiden så går åt till rasterisering och postprocessing minskar (bara första bilden)) , men samtidigt så har även RAM en större roll (också en konsekvens av att GPU:n tar mindre tid på sig) så vad är det man benchmarkar då, RAM eller CPU? T.ex kan testning i 720p avslöja en riktig flaskhals i CPU prestanda i vissa spel. Ett exempel med crysis 3:
1800X https://www.youtube.com/watch?v=QPwdpCY4-l4
1800X SLI https://www.youtube.com/watch?v=enJA4ZmPl60
7700k https://www.youtube.com/watch?v=1LScXqoZRbg
7700k klarar inte av att hålla uppe prestandan med 1800X, trots att den har lägre settings (låg GPU användning är orsaken) . Det beror helt enkelt på att CPU:n inte hänger med (och skalar väl med DX12 och annat). Crysis är ett sånt fall där man kan se en skalning i 1080p där vi även ser en stor variation (som göms av AVG FPS).

RAM har även en påverkan vid 1080p, i vissa fall upp till 20% på genomsnittlig FPS. (källor https://www.youtube.com/watch?v=S6yp7Pi39Z8 https://www.youtube.com/watch?v=p--iuQhujqI ). Alltså borde högre presterande RAM ge en bättre bild av CPU:ns prestanda , ännu bättre i kombination med låga grafikinställningar i spel.

2. Testning vid 4K
Ja, i 99 fall av 100 är det värdelöst för att mäta CPU:ns prestanda. Men i vissa fall (DOOM) så används uttnyttjas GPU:ns prestanda till endast en liten del i 720p och har problem med att hålla FPS vid 200FPS på 2 lägre klockade Xeon processorer (8 kärnor vardera, 16 kärnor totalt) med lågt klockat RAM. I 4K däremot så var det en annorlunda situation där de presterade bättre än de som var grymma i 720p när GPU användningens relevans ökade. Då har vi ett fall då en CPU som är sämre i 720p är bättre i 4K och det är någonting som de som kör i 4K vill veta.
(Sedan är förstås 2x xeons mycket sämre i 720p, då FPS skulle öka för 1800X och 7700k eftersom DOOM har en 200 FPS spärr. Det är inte helt exakt lika gameplay, men de håller 109-152 FPS vs 90-132 FPS och 97-132 FPS).

Så där har vi några aspekter på varför det kan vara bra att testa båda upplösningar för att mäta CPU:ns prestanda i olika fall. Sedan sa jag ju:
Hittar någon något fel någonstans så ge gärna bevis och förklaring. Notera även att jag inte säger att du har fel, bara att det finns lite andra infallsvinklar på det hela där det kan vara intressant att veta både resultaten i 720p och 4k och att uteslutning av grafikkortet inte nödvändigtvis utesluter RAM från CPU:ns påverkan.

Gå till inlägget

Att jämföra olika videos känns ju inte som ett dåligt sätt att dra för stora slutsatser ifrån, räcker med att de är på olika delar av banan/ olika windows versioner/ olika spelversioner/ olika inställningar osv för att det hela skall fallera.

Skickades från m.sweclockers.com

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av KimTjik:

Intressant och potentiellt missledande uttryckt av Intel:
Det ser ut som skrivet av en jurist där det går ifrån att handla om ett specifikt säkerhetsproblem till att övergå till en generell kommentar om diverse svagheter som upptäcks i hård- och mjukvara. Det kanske är jag som feltolkar det, men för mig framstår det som ett klassiskt exempel på FUD.

Gå till inlägget

Ganska intressant att se anser att de inte är ensamma med buggen medans AMD säger mot.

Visa signatur

Arch - Makepkg, not war -||- Gigabyte X570 Aorus Master -||- GSkill 64GiB DDR4 14-14-15-35-1T 3600Mhz -||- AMD 5900x-||- Gigabyte RX6900XT -||- 2x Adata XPG sx8200 Pro 1TB -||- EVGA G2 750W -||- Corsair 570x -||- O2+ODAC-||- Sennheiser HD-650 -|| Boycott EA,2K,Activision,Ubisoft,WB,EGS
Arch Linux, one hell of a distribution.

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av KimTjik:

Intressant och potentiellt missledande uttryckt av Intel:
Det ser ut som skrivet av en jurist där det går ifrån att handla om ett specifikt säkerhetsproblem till att övergå till en generell kommentar om diverse svagheter som upptäcks i hård- och mjukvara. Det kanske är jag som feltolkar det, men för mig framstår det som ett klassiskt exempel på FUD.

Gå till inlägget
Skrivet av Commander:

Ganska intressant att se anser att de inte är ensamma med buggen medans AMD säger mot.

Gå till inlägget

Har för mig att jag läste någonstans att man även patchar för arm-processorer? I så fall är det inte direkt vilseledande...kan dock inte ta gift på att jag minns rätt och orkar inte leta upp någon källa, så ta mitt påstående med en viss nypa salt

Edit: googlade lite snabbt och hitta detta som första träff:

https://seekingalpha.com/news/3321030-arm-holdings-working-in...

och detta lite längre ner:

https://www.extremetech.com/computing/261364-massive-intel-cp...

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

Jag har åkt på den roliga uppgiften att testa delar av de mjukvaror vi utvecklar på jobbet, för att se om vi får en prestandatapp. Det som gör det än mer roligt är att våra grejer bygger väldigt mycket på olika typer av IO (stora databaser, läs- och skrivaccesser mot disk, nätverk, samt kommunikation mellan processer) där vi även har krav om vite ifall vi inte uppfyller tillräcklig prestanda ute hos kund. Som om man inte hade nog med grejer att göra redan..

Det jag är lite orolig över är hur det fungerar i ett scenario där man kör virtualisering och patchar både underliggande hypervisor/OS samt gäst-OS. Kommer detta då innebära ackumulerade prestandaförluster för båda nivåer eller endast en? Nästa vecka så lär vi nog få reda på det..

Skrivet av pa1983:

Många vanliga processorer stödjer viritualisering, lustigt nog har intel primärt uteslutit K modellerna, dock inte alla tex min i7 3930K med C2 stepping är inte exkluderad dock är C0 steppigen det.

Gå till inlägget

Virtualisering kan man köra även om hårdvarustöd ej finns, dock med begränsningar. Till exempel körde jag med virtualisering på min gamla P4 som saknar det. Hårdvarustödet för virtualisering finns dock på nära på alla, om inte alla, K-modeller (det som Intel kallar VT-x).

Däremot har Intel varit restriktiva med att inkludera support för IOMMU (det som Intel kallar VT-d) vilket krävs för att kunna köra "device passthrough", t.ex. att tilldela ett grafikkort till en VM. Sedan Skylake verkar det dock som att de har börjat ge support för det även på K-modeller.

Ingen kritik riktad mot dig utan ville mest förtydliga vad som gäller så inte andra missuppfattar det som att virtualisering ej fungerar på (deras) K-modeller.

Senast redigerat
Visa signatur

Efter att ni har läst det här har ni insett att det inte gav något.

Redigera
Citera flera Citera
Permalänk
Datavetare ★
●
Skrivet av mpat:

Inte alls. Jag håller med om hela beskrivningen du gjorde i den här artikeln - och tack för att du skrev det så jag slapp - men det är en punkt där Intel har en flaskhals som de talat väldigt tyst om. Men låt mig peta lite i detaljerna nedan.

Håller med, men vill lägga till att Zen bara kan plocka dessa 6 micro-ops (uops) från 4 olika x86-instruktioner. För att komma upp i 6, måste det således vara två instruktioner som genererar två uops. Intel kan å sin sida bara hantera komplexa x86-instruktioner (som resulterar i mer än en uop) i en dekoder, så de klarar inte mer än en sådan åt gång. I nästan alla fall är detta inte relevant, men Apple's design är lite mer generell här, eftersom ARM är så mycket lättare att koda av en x86.

Det är här Intel har en flaskhals som de andra inte har. Intel kan hantera 4 instruktioner per cykel i den här fasen, medan de andra kan hantera 6 (AMD kan bara hantera 4 flyttalsinstruktioner här, men det beror på andra grejer längre ner och spelar inte så stor roll i vilket fall. De hanterar 6 heltalsinstruktioner, eller 4+2). Undantaget i Intel's fall är att de har micro-op fusion, där de kan ta två speciella micro-ops och hantera dem som om de vore en den här fasen och i schedulern lite längre ner. Detta fungerar dock bara i ett fåtal fall när två micro-ops skall gå igenom samma exekveringsenhet och jobbar på samma data. Detta är en flaskhals i Skylake.

Det är inte så relevant i Haswell, som bara klarar att få fram 5 uops ur cachen eller 4 ur dekodern, men Skylake gjorde denna bredare. Det är därför jag tror att Intel kommer att behöva göra denna bredare med Ice Lake.

AMD är inte så öppna här, men om jag minns rätt är det max 10 på Zen.

OBS också att Intel är väldigt begränsade i exakt vilka instruktioner som kan gå tillsammans (exekveringsportarna), men nu kommer i in på alltför petiga detaljer.

Också OT: Zen och Apple's designer är ganska lika varandra, åtminstone bakänden. Jim Keller har designat bägge.

Den här artikeln tyder på att det kan ha gått till ungefär som du beskriver:

https://cyber.wtf/2017/07/28/negative-result-reading-kernel-m...

Gå till inlägget

Back-end i Zen var initialt tänkt till att både används för just Zen (x86) men också K12 (ARMv8). Så inte alls förvånande att back-end liknar "big-core" ARM, den ligger rätt mycket mitt emellan Cortex A57/A75 och Apples design.

I de flesta fall spelar det väldigt liten roll om front-end är x86 eller ARM, men antal pipelines för minnesoperationer i Zen känns mer ARM än x86 (CISC-rötterna gör minnesoperationer vanligare för x86 än för ARM, men dagens kompilatorer gör sitt bästa för att minska denna skillnad, se nedan).

x86 och ARM har också väldigt olika minneskonsistensmodell, ARMv8 har en i det närmaste optimal design för multitrådad C11/C11++ kod (x86 är onödigt strikt vilket försämrar vissa optimeringsmöjligheter, så ARMv8 har något bättre teoretisk möjlighet att hantera många kärnor)! Så nog inte helt enkelt att göra en back-end som fungerar optimalt för både x86 och ARM...

Räknar man micro-op fusion (slå ihop en jämförelse samt ett hopp villkorat på den jämförelsen) ökar antal x86 instruktioner som Core kan hantera med en. Är fyra x86 för Core2 till Broadwell, fem vid micro-op fusion.

Ja, är helt sant att det bara finns en "komplex" decoder. Men åter igen, är kompilatorer och inte människor som skriver maskinkod idag -> finns en väldigt bra orsak varför Intel inte "fixar" denna begränsning: det är inte en begränsning i praktiken då man helst vill hålla saker i register och när saker ligger i register blir alla "normala" instruktioner även en enda micro-op.

Sedan genererar relativt "komplexa" instruktioner faktiskt bara en micro-op. T.ex.

add reg, DWORD PTR[reg]

Rent tekniskt är detta load+add (typisk CISC, RISC kan bara göra aritmetik mot register), men blir ändå bara en micro-op. Det omvända genererar dock två micro-op

add DWORD PTR[reg], reg

Detta är rent tekniskt load+add+store.

Ett lackmustest här: om det vore en signifikant flaskhals att bara ha en "complex" decoder, hur kommer det sig då att Skylake ökade sin IPC rätt mycket över Broadwell för vanlig heltalskod (t.ex. spel)? Är ju samma bredd på back-end, men högre "retire" samt "front-end" rate. Att öka "retire-rate" från fyra till fyra per tråd hade varit meningslöst om man inte kan generera fler än fyra micro-ops i front-end tillräckligt ofta. Den "komplexa" avkodaren klarar bara 4 micro-ops, efter det måste den ta till microkod.

Är helt sant att Zen har mer generella heltals-pipeliens. Men då måste man även ta in en annan "detalj" i ekvationen. Zen använder sig av en distribuerad instruktionsschemaläggare, så finns inte en stor kö utan många rätt små (14 steg) där man redan vid "dispatch" måste gissa vilken pipeline som är optimal.

Intel har en central instruktionsschemaläggare, d.v.s. dispatch-steget stoppar bara in instruktionerna i en stor central back-end kö där man sedan först vid execute behöver välja vilken port som hanterar instruktionen. Är t.ex. en port som i praktiken bara kan hantera enkla aritmetiska operationer, shift samt hopp. Givet att var 4:e till 5:e x86 instruktion i genomsnitt är ett hopp så är en sådan begränsning rätt irrelevant när man har en central instruktionsschemaläggare, framförallt när den centrala kön man kan välja ur är ~100 instruktioner stor (är inte hela ROB).

Detta är en rätt gigantiskt "detalj"...

Vidare, att back-end är "bredare" än front-end är ett sätt att dels hantera asymmetri i exekveringsportar men också så att man kan "jobba ikapp" efter en pipe-line stall (som t.ex. TLB-miss eller annan cache-miss). Finns ju ett par till köer som jag utelämnade, dessa börjar fyllas upp om man t.ex. får en cache-miss. När denna är klar finns då potentiellt väldigt många instruktioner som har all indata under en väldigt kort tid.

Huvudpoängerna var ändå: ROB har förändrats radikalt från Core2 till Skylake, det vid varje "tock".
ROB möjliggör bl.a. spekulativ exekvering, verkar vara just spekulativ exekvering som är root till problemet som beskrivs i artikeln.

En bi-poäng: tror inte AMD är så jätteglada över detta, Intel är så dominerande på x86 så detta kommer påverka alla x86-designer mer eller mindre. Om någon sitter och tvår sina händer just nu är det nog Qualcomm och Cavium. Måste vara mumma för deras just lanserade ARMv8 server-kretsar!

En stor fördel med ARM över x86 är att sannolikheten för buggar är mindre i ARM då det är en långt enklare ISA -> betydligt enklare att validera!

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Redigera
Citera flera Citera
Permalänk
Hjälpsam ★
●
Skrivet av roo:

Vet ej om någon postat detta i kommentarsfältet men här är intels svar på det https://newsroom.intel.com/news/intel-responds-to-security-re...

Gå till inlägget

Låter som att Intel är inne i full "Damage controll mode".
Nej, det är bara Intel som har buggen.
AMD skulle inte gått ut så hårt med att de inte har den, om det inte stämt.
Allt är under NDA nu, vi får veta mer nästa vecka.

https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/c...

Senast redigerat
Visa signatur

AMD Ryzen 7 5700X | Saphire RX 5700 Pulse XT (Silent Mode) | 64 GB Kingston ECC | https://valid.x86.fr/51gntq | Stockkylaren | Bitfenix Whisper M 750W.
AMD Ryzen 9 5900X | AMD RX 5700 | 64 GB Micron ECC | https://valid.x86.fr/gwcxfs
HTPC | https://valid.x86.fr/gqtxws |

Redigera
Citera flera Citera
Permalänk
Hedersmedlem ★
●

@Commander
@Frispel

Kanske är det å ena sidan ett generellt problem, kanske inte, jag vet inte. Jag reagerade bara på formuleringen. Det kan ju också vara så att Intel och AMD valt att hantera vetskapen om arkitekturens svagheten olika, i meningen att ja, det drabbar på sätt och vis även AMD, utan att Intel för den skull erkänner i sitt uttalande att det inte kräver en sådan bestraffande lösning. Spekulation ifrån min sida och inget värt pixlarna i vikt.

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av Frispel:

Har för mig att jag läste någonstans att man även patchar för arm-processorer? I så fall är det inte direkt vilseledande...kan dock inte ta gift på att jag minns rätt och orkar inte leta upp någon källa, så ta mitt påstående med en viss nypa salt

Edit: googlade lite snabbt och hitta detta som första träff:

https://seekingalpha.com/news/3321030-arm-holdings-working-in...

och detta lite längre ner:

https://www.extremetech.com/computing/261364-massive-intel-cp...

Gå till inlägget
Skrivet av KimTjik:

@Commander
@Frispel

Kanske är det å ena sidan ett generellt problem, kanske inte, jag vet inte. Jag reagerade bara på formuleringen. Det kan ju också vara så att Intel och AMD valt att hantera vetskapen om arkitekturens svagheten olika, i meningen att ja, det drabbar på sätt och vis även AMD, utan att Intel för den skull erkänner i sitt uttalande att det inte kräver en sådan bestraffande lösning. Spekulation ifrån min sida och inget värt pixlarna i vikt.

Gå till inlägget

Jag tror den artikeln behandlar två buggar. Separationen av userspace och kernelspace har varit på snack länge. Sen har vi den andra som tar upp att Intel i sig förmodligen inte checkar permission vid prediction. Men för Linux skull kräver senare bug en fortsättning av första fixes.

Visa signatur

Arch - Makepkg, not war -||- Gigabyte X570 Aorus Master -||- GSkill 64GiB DDR4 14-14-15-35-1T 3600Mhz -||- AMD 5900x-||- Gigabyte RX6900XT -||- 2x Adata XPG sx8200 Pro 1TB -||- EVGA G2 750W -||- Corsair 570x -||- O2+ODAC-||- Sennheiser HD-650 -|| Boycott EA,2K,Activision,Ubisoft,WB,EGS
Arch Linux, one hell of a distribution.

Redigera
Citera flera Citera
Permalänk
Medlem
●

Har en orolig vän som oroar att den säkerhetsuppdatering som Microsoft kommer släppa på tisdag kommer förstöra hans windows dator, dvs göra den extremt extremt långsam.

Nu har jag inte hängt med här men om den uppdateringen kommer, kommer datorerna med Intel och windows bli sämre eller stoppar den bara en säkerhetshål??

Redigera
Citera flera Citera
Permalänk
Hjälpsam ★
●
Skrivet av TheCazz:

Har en liten orolig vän som oroar att den säkerhetsuppdatering som Microsoft kommer släppa på tisdag kommer förstöra hans windows dator, dvs göra den extremt extremt långsam.

Nu har jag inte hängt med här men om den uppdateringen kommer, kommer datorerna med Intel och windows bli sämre eller stoppar den bara en säkerhetshål??

Gå till inlägget

Din lille oroliga vän, behöver inte oroa sig.
Prestanda för de program, som vi vanligtvis använder (tex spel), påverkas minimalt.
Då är det mycket mer obehagligt om datorn hackas, så att patcha på Tisdag är det enda vettiga.

Visa signatur

AMD Ryzen 7 5700X | Saphire RX 5700 Pulse XT (Silent Mode) | 64 GB Kingston ECC | https://valid.x86.fr/51gntq | Stockkylaren | Bitfenix Whisper M 750W.
AMD Ryzen 9 5900X | AMD RX 5700 | 64 GB Micron ECC | https://valid.x86.fr/gwcxfs
HTPC | https://valid.x86.fr/gqtxws |

Redigera
Citera flera Citera
Permalänk
Inaktiv
●
Skrivet av TheCazz:

Har en liten orolig vän som oroar att den säkerhetsuppdatering som Microsoft kommer släppa på tisdag kommer förstöra hans windows dator, dvs göra den extremt extremt långsam.

Nu har jag inte hängt med här men om den uppdateringen kommer, kommer datorerna med Intel och windows bli sämre eller stoppar den bara en säkerhetshål??

Gå till inlägget

Som det är nu så verkade det typ vara så att de som blir lidande vet om det, personer som är osäkra tillhör nog skaran som inte gör något krävande vid datorn förutom spel.
Så säg åt din vän att han inte behöver vara det minsta oroliga, vad två dårar i andra länder tävlar om vem som har störst kärnvapenknapp är snarare det man behöver oroa sig mer för.

Angående orolighet inför tisdag så kommer alla som gör något större att inte köra in denna utan att först se vad andra säger, därefter kan man överväga om man kan köra in dem. Säkerligen kommer det först en uppdatering som inte är bra, där det senare kommer en bättre.-Paniklösningar blir inte alltid de bästa.

För min egen del så kommer jag nog inte tillåta denna uppdatering, men sedan kommer min snabbaste Intel inte heller få ha tillgång till internet längre så.. Jag vet många kunder som kör med gamla system alla 12 kärnorna ligger i runt 90% belastning i medel, jag tror typ ingen av dessa är så förtjust.

Samtidigt vet jag ett megastort företag som har en produktionsdator som kör windows 2003, går den ner så går produktionen i fabriken ner. Men det kostar att uppgradera... Gissa om vad såna företag gör med dessa uppdateringar?

*edit*
Står man i valet om man installerar patchen går systemet ner och blir obrukbart, inga användare kan använda det. Och om man ej installerar så får man ett extra säkerhetsval som får hantera på något sätt, så väljer nog många det sista. Där bra hantering att isolering och köpa in mer datakraft som kan ta ett halvår att få beroende på lösning. (kör man virtualiserat EXSI så har man framtidstänk, men många har än idag installerat direkt på värdoperativsystemet. Även om detta håller på att bli exotisk, såvida man inte gör något väldigt litet.

Senast redigerat
Redigera
Citera flera Citera
Permalänk
Medlem ★
●

Inlägg från Google Security Blog

Visa signatur

Assembly är ett högnivåspråk.

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av roo:

Vet ej om någon postat detta i kommentarsfältet men här är intels svar på det https://newsroom.intel.com/news/intel-responds-to-security-re...

Gå till inlägget

"Intel believes its products are the most secure in the world..."

Ja, men att man tror man gör de säkraste produkterna i världen och sedan har två rätt stora saker som en enorm mängd processorer är drabbade av dyka upp inom någon månad från varandra kanske vittnar om att de inte bara borde "tro" detta.

Visa signatur

Huvudriggen är en Gigabyte Aorus Xtreme | 96gb DDR5 6000 | Ryzen 9950X3D | 5090
Utöver det är det för många datorer, boxar och servar för att lista :P

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av Punnisher:

30% prestandaminskning av vad? Från 0.5 sekunder till 0.65 sekunder att öppna en hemsida, oj vad jag är brydd om det... not.

Håller med om att de förklarar på ett bättre sätt vad det handlar om.
Men kan man inte genom Antivirusprogram skapa skydd om detta då, det finns väl javascript virus?

Gå till inlägget

Först borstar du bort problemet med något som inte är direkt relevant. Vilkem hemsida, för vem laddar denna sida på 0.5 sekunder? Vad sker på servern under dessa 0.5 sekunderna för att kunna serva sidan? Hur mycket är I/O som i allra högsta grad kan påverkas och med ökad trafik få servern att slå i taket mycket tidigare än innan. Sedan säger du att Fria Tider förklarar bra men verkar som sagt inte riktigt satt dig in i problematiken. Saker runt om i världen (som påverkar allt möjligt du interagerar med) kan drabbas. Har du läst igenom kommentarerna i tråden? Om inte så rekommenderar jag det då många ger väldigt bra teknisk information om de faktiska problemet.

Visa signatur

Huvudriggen är en Gigabyte Aorus Xtreme | 96gb DDR5 6000 | Ryzen 9950X3D | 5090
Utöver det är det för många datorer, boxar och servar för att lista :P

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

Papers:
https://meltdownattack.com/meltdown.pdf
https://spectreattack.com/spectre.pdf

Visa signatur

Assembly är ett högnivåspråk.

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av TheCazz:

Har en orolig vän som oroar att den säkerhetsuppdatering som Microsoft kommer släppa på tisdag kommer förstöra hans windows dator, dvs göra den extremt extremt långsam.

Nu har jag inte hängt med här men om den uppdateringen kommer, kommer datorerna med Intel och windows bli sämre eller stoppar den bara en säkerhetshål??

Gå till inlägget

Om din kompis endast spelar på sin dator osv så komemr han/hon förmodligen inte märka någonting. Om kompisen kör virtuella maskiner, utvecklar, pillar databaser osv så kan det bli tydligare dock.

Visa signatur

Huvudriggen är en Gigabyte Aorus Xtreme | 96gb DDR5 6000 | Ryzen 9950X3D | 5090
Utöver det är det för många datorer, boxar och servar för att lista :P

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

Spännande. Verkar vara två olika attacker de tar upp där "Meltdown" verkar ha påverkat Intel men inte AMD och ARM. "Spectre" verkar alla vara sårbara inför dock.

"We also tried to reproduce the Meltdown bug on several
ARM and AMD CPUs. However, we did not manage
to successfully leak kernel memory with the attack de-
scribed in Section 5, neither on ARM nor on AMD."

"Unlike Meltdown, the Spectre attack works on non-
Intel processors, including AMD and ARM processors.
Furthermore, the KAISER patch, which has been
widely applied as a mitigation to the Meltdown attack,
does not protect against Spectre."

Så om jag förstår det rätt så drabbas AMD inte av Meltdown och den patch som skyddar (Intel?) ifrån Meltdown hjälper inte emot Spectre så där är alla drabbade.

Visa signatur

Huvudriggen är en Gigabyte Aorus Xtreme | 96gb DDR5 6000 | Ryzen 9950X3D | 5090
Utöver det är det för många datorer, boxar och servar för att lista :P

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

Tänk på att Google nämner i länken längre upp att webbläsare också specifikt är drabbade av i princip samma typ av sårbarhet, det skall vara patchat from Chrome 64.0

Och Android har fixen i säkerhetspatchen för 5e Januari, som ingen bör ha fått ännu, men man får hoppas att de olika tillverkarna snabbar sig på att pusha ut den.

Mer läsning om buggen/konstruktionsfelet från Wired:

https://www.wired.com/story/critical-intel-flaw-breaks-basic-...

Visa signatur

9950X3D X870E HERO 96/6400c30/2200 RTX5090 Gaming OC || 7950X B650 Gaming Plus WIFI 32/6000c30 RTX5080 TUF OC(450w) UBUNTU || 12900KF Z690 Tomahawk WIFI 64/3600c16 Gear1 RTX4080 Ventus 3X OC(400W) || 5900X(B2) B550-F 32/3800c18 RTX3080 TUF OC V2 || 5800X3D CH VIII EXT. 32/3800c18 RTX3080 Gaming OC || 3700X X570 HERO 32/3000c16 RTX3070 FTW3 Ultra || Thinkpad P16s G2 PRO7840U 32/6400

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

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.

Skrivet av Yoshman:

Räknar man micro-op fusion (slå ihop en jämförelse samt ett hopp villkorat på den jämförelsen) ökar antal x86 instruktioner som Core kan hantera med en. Är fyra x86 för Core2 till Broadwell, fem vid micro-op fusion.

Gå till inlägget

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å.)

Citat:

Ja, är helt sant att det bara finns en "komplex" decoder. Men åter igen, är kompilatorer och inte människor som skriver maskinkod idag -> finns en väldigt bra orsak varför Intel inte "fixar" denna begränsning: det är inte en begränsning i praktiken då man helst vill hålla saker i register och när saker ligger i register blir alla "normala" instruktioner även en enda micro-op.

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.

Citat:

Ett lackmustest här: om det vore en signifikant flaskhals att bara ha en "complex" decoder, hur kommer det sig då att Skylake ökade sin IPC rätt mycket över Broadwell för vanlig heltalskod (t.ex. spel)?

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

Citat:

Är ju samma bredd på back-end, men högre "retire" samt "front-end" rate. Att öka "retire-rate" från fyra till fyra per tråd hade varit meningslöst om man inte kan generera fler än fyra micro-ops i front-end tillräckligt ofta. Den "komplexa" avkodaren klarar bara 4 micro-ops, efter det måste den ta till microkod.

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.

Citat:

Huvudpoängerna var ändå: ROB har förändrats radikalt från Core2 till Skylake, det vid varje "tock".
ROB möjliggör bl.a. spekulativ exekvering, verkar vara just spekulativ exekvering som är root till problemet som beskrivs i artikeln.

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.

Citat:

En bi-poäng: tror inte AMD är så jätteglada över detta, Intel är så dominerande på x86 så detta kommer påverka alla x86-designer mer eller mindre. Om någon sitter och tvår sina händer just nu är det nog Qualcomm och Cavium. Måste vara mumma för deras just lanserade ARMv8 server-kretsar!

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.

Visa signatur

5900X | 6700XT

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

Så Meltdown fungerar så här, enkelt uttryckt: Ett attackprogram 1 skapar en array av data inte är cachad, och startar sedan program 2. Program 2 ser till att ett visst värde som det vill ha reda på läses in av kerneln till ett register A. Programmet läser sedan detta register A och kopierar det till register B, och börjar sedan läsa minnesadresser baserat på resultatet av det registret. Om innehållet i registret är 5, så läser det från plats 5 inom den stora arrayen som program 1 skapade. Så snart den första instruktionen har gått igenom hela processen och är framme vid retire, så upptäcks det att program 2 försökte läsa något som det inte får. Kerneln avslutar omedelbart program 2. Program 1 provar nu att läsa olika delar av sin array. När det kommer till plats 5, upptäcker det att det får svaret snabbare än förväntat. Alltså har plats 5 nyligen lästs av program 2, och den hemliga datan är 5.

I praktiken är det snabbast om man bara skickar en bit åt gången - dvs, program 2 tittar på en enda bit av sin hemliga data, och laddar en känd adress om den biten är 1. Program 1 startar bara en ny utgåva av program 2 och plockar nästa bit och fortsätter så.

Senast redigerat
Visa signatur

5900X | 6700XT

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av Elektron:

Att jämföra olika videos känns ju inte som ett dåligt sätt att dra för stora slutsatser ifrån, räcker med att de är på olika delar av banan/ olika windows versioner/ olika spelversioner/ olika inställningar osv för att det hela skall fallera.

Skickades från m.sweclockers.com

Gå till inlägget

Jag håller med, dock är det det bästa som man har då dessa tester ej är vanliga. I crysis så finns kompletterande information med samma sekvens i länken från digital foundry (de har också gjort tester där de jämför 8700k och 7700k och ser samma mönster). Crysis jämförelsen var helt och hållet till 7700k:s fördel (1800X tappade t.ex 100 FPS från low till very high i början och dessutom med en högre upplösning) .

DOOM är svårare att jämföra (2x xeons tester i 720p är inte så vanliga, om ens några såna andra tester finns?) där var som sagt intervallen följande:
2 Xeons: 109-152 FPS
7700k: 90-132 FPS
1800X: 97-132 FPS
Det är inte lika vetenskapligt som jag vill ha det, men den håller även ett högre AVG. I DOOM vid grafikkortet som huvudsaklig flaskhals så spelar scenen mest roll (AI:n not so much, har testat själv). Då känns ett rent sammanträffande att den både har en 10 FPS högre MIN, 20FPS högre MAX, högre AVG rätt så osannolik att ha orsakats av slumpen.

Sedan så ska tekniskt sett 2x xeons hamna efter, vilket den gör i alla andra tester vid 4k i samma video. Att de ens hamnar i närheten beror HELT på Vulkan https://youtu.be/-242kHW5fKA?t=60 .
Jag hittade nyss ett exempel med liknande setup (fast 1080 istället för 1080ti) med ECC 1333mhz RAM (från kommentarerna). Men den verkar hamna på liknande siffror som i 4k testet (dock verkar det bli en stor prestandförlust när han utför glory kills). Det går inte att dra alltför stora slutsatser från det, annat än att den är helt CPU begränsad (IDtech6 profiler i övre högra hörnet).
Det fanns också en annan som sammanfattade värdena han fick (2x 2690 1080ti och 1866mhz minne) som landade på 110 FPS i 4k. Svårt att dra slutsatser då han inte visar gameplay från det tillfället. Men GPU frametimes från 1080p visar han ibland (och de ser faktiskt rätt så bra ut, det är endast de som spelar någon roll när man går över till 4k, då CPU förblir detsamma).

Det var allt som jag kunde hitta som var i närheten. Men om du hittar en i5, i7, i9 , r5 , r7 som kör doom på ungefär samma ställe i 4k med vilket grafikkort som helst och får högre FPS så vill jag gärna se det då jag letat rätt så länge efter det.

Redigera
Citera flera Citera
4 5 6 7 8 9 10 11
Skriv svar