Microsoft attól még önszorgalomból megjavíthatja, fő a biztonság!

[ Szerkesztve ]

Jó eséllyel a legtöbb rendszerDLL-ből egyetlen verziót fognak kiadni, két külön fordítás, vagy run-time futtatási útvonal nélkül, így az AMD-ket is (feleslegesen) lassítva.

pedig patch telepítésekor egy cpu_id ellenőrzéssel simán meg lehetne oldani hogy amd-re ne másszon fel...

Ennek ellenére most is megkapják majd a lassító patch-üket, ahogy eddig, kizárólag a versenyegyenlőség szellemében

Most látom, hogy pár hozzászólas MÁR ment a levesbe

[ Szerkesztve ]

megeszem a kalapomat, ha az inteles fixek amdn nem lassitottak semmit - akar erintettek voltak, akar nem.

Akár telepítéskor, akár futáskor. De nyilván kevésbé szeretnek két párhuzamos kódot fenntartani, és főleg tesztelni.

Ugye a Vista előtt volt külön egyCPU-s és többCPU-s kernel, de ez is csak arról szólt, hogy mire optimalizáltak. Ma már csak egy többmagos van, egyszerűen /favor:INTEL64-es optimalizálással fordítva, osztjóvan. A nagyon CPU specifikus dolgok vannak az intelppm.sys-ben, illetve amdppm.sys-ben. Mondjuk az össz. 200 kB-os méretéből sejthető, hogy mennyi.

"Az AMD hivatalosan is kiértékelte a hónap elején felfedezett, Spoiler névre keresztelt biztonsági rést,..."

Ha hivatalosan is kiértékelte, akkor erről lehetne egy hivatalos link, nem?

nem is kell 2 kódot fenntartani, csak a telepítőben ellenőrizni hogy intel procc van e a gépben, és ha igen akkor lefuttatni, ha nem akkor eldobni és kész, így nem kell 2 kódbázist fenntartani...

Nesze: [link]

A két párhuzamosan karbantartott forráskód (jelen esetre vonatkoztatva: egy Intel és egy AMD) azt jelenti, hogy mindkettőt karban kell tartani, és ellenőrizni. Egy gépen nyilván csak az egyik fog futni (és/vagy települni), de attól még mindkettővel foglalkozni kell, és külön-külön az adott CPU-n a megfelelőt tesztelni.

Ha más problémák miatt más okokból is van ilyen párhuzamosság (mint pl. voltak az egymagos-többmagos kernelek), a kombinációk száma kb. összeszorzódik (itt: Intel egymagos, Intel többmagos, AMD egymagos, AMD többmagos). Ettől kezdve pedig durván elszáll a tesztelendő konfigurációk száma - még ha nyilván nem is lehet az összes létező PC-n kipróbálni [még ha némelyik MS frissítés teszternek használ mindenkit ].

ez egy patchnel mukodik, ujra letrehozott kodnal nem - mert a hibakat figyelembe veve csinaljak. magyaran lassitani fog mindket helyen, nem fognak kulon optimalizalni az egyikre-masikra (foleg nem a kicsi amdre).

Szívesen.

/OFF

Azt úgy mondják helyesen: lemmígógülfórjúmájdírfrend

/ON

A mihez tartás végett, igen, lehetne ezekre speciálisan fordított rendszer binárisokat használni, de ezt annyira macerás lekezelni, hogy egyetlen épeszű OS/disztribúció sem teszi meg. (Igen, a Gentoo Linux ami a kernelt és minden vackot a /march:native-vel fordít nem számít fenntartható/épeszű megoldásnak.) A kernelben a Spectre és társaihoz tartozó egyedi kódok futásidőben vannak ki/be-kapcsolva, de ezek nem lassítják le szignifikánsan a gépet.

Egy x86 elágazás becslője 10-14 egymásba ágyazott elágazáson még triviálisan átlát, ha az nem változik. Egy szénné tuningolt binárisban egy sima for ciklusra is 3-4-5 változat generálódik: egy ha rövid a ciklus, egy ha pont 3 hosszú, egy ha néggyel osztható, egy AVX-es, egy több szálú... és futásidőben választódik ki, ami épp a legmegfelelőbb az adott ciklushosszhoz. PGO (Profile Guided Optimization) ezeket a tippeléseket tüntetni el.

A kernelben is van egy csomó architektúra specifikus választás egyes megoldások között, de ezek sosem változnak és az elágazás becslő baromi gyorsan megtanulja ezeket és utána nincs látható hatása. Akkor van baj, ha ezek futásidőben (gyakran) változnak, de a CPUID nemigen szokott változni (ha nem valami skizoid procit használtok).

De ez akkor komoly, hogy megint szívni fog az AMD az Intel miatt ha jön majd a javítás?
Vagy csak találgatások folynak még a fórumozók között is?

Mert ez így marha jó, hogy az Intel csinálja folyamatosan a gyors procikat amik "tele vannak hibával" de utána mikor javítják a dolgot, akkor a másik gyártó is meg van szivatva. Azaz ki jár/járt jól összeségében? A kékek.

Számomra még mindig az a szomorú, hogy hiába rakkott le az asztalra végre valamit az AMD is a Rizsákkal, mégis rengeteg "szakember" még most se ajánlja őket a kevésbé hozzáértő usereknek, magyarázat: "Csak a Zintel. " Az ÁÁEMDÉÉ fos, hőkazán"

Vannak különböző területek ahol megértem:
-nem hobbi játékosok világa (akik 144+ Hz-es monitoron játszanak és a minél több átlag, illetve minimum FPS a fontos, persze a brutál VGA ehhez alap h kell)
-olyan munkához használt program/eszköz ami sokkal inkább az Intellel megy jobban (pl Kinect késleltetése)

Vagy ha valaki pénztárcájának mindegy akkor is érhető valamilyen szinten.

[ Szerkesztve ]

Erre egy sokkal jobb es kevesbe lassito megoldas is van.
SZARNI KELL RA.
Senki sem fogja haszalni mivel napvilagra kerult.

Köszönjük eme, IT SEC szempontból mély szakmaiságot sugárzó (sicc!), hozzászólást!

[ Szerkesztve ]

Nem úgy volt hogy ezt a sebezhetőséget nem lehet szoftveres oldalon foltozni?

Ki lehet mérni a lassulást, megoldható lenne, hogy patchel és anélkül processzortól függően, Intel vagy AMD esetében van-e és milyen fokú a lassulás?
Igen.

Akkor találgatások helyett talán kérhetnénk egy tesztet inkább, nem???

[ Szerkesztve ]

Én kifejezetten 90%-ban játékra használom a gépemet 144hz g-sync-el, AMD-t vettem mert az Intel és az alaplap gyártók teljesen elvannak borulva árazás terén. 8700K helyett jött egy 1700 amit fel OC-ztam 3.8-ra, kb 10% hátrányom lehet az intelhez képest de így is akkora volt a spórolás ,hogy GTX 1080 jött a GTX 1070 helyére pontosan ugyanannyi lett volna a 1070 a Zintellel mint az AMD a 1080-al.... itt meg már nem kérdés ,hogy melyik fog több fps-t produkálni...