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