Új hozzászólás Aktív témák
-
#07746304
törölt tag
-
Looserke
őstag
válasz
westlake
#175
üzenetére
Ha nagyon szeretnéd, akkor rakok be 6 képet, mert többször is lefuttattam a tesztet és mindig ugyanazt kaptam... De szerintem értelmetlen lenne. És igen az átlag FPS ugyan az, de a hirtelen FPS drop megszűnt, ami elég zavaró tud lenni. Mások le tudták szűrni a lényeget, neked nem jött össze...
Közben Battlefield V multiban is tesztelem és itt is ugyanaz, megszünteti az indokolatlan FPS dropot, ha kikapcsolt patchekkel játszok. Erről nincs benchmark kép se 1 se 3, aki akarja elhiszi nekem... 😉
-
#178
SchumiBácsi
őstag
westlake
#177
válasz
westlake
#177
üzenetére
A szóban forgó játékomnál nem tapasztaltam jelentős gyorsulást OC módban sem, de a hirtelen drasztikus beszaggatások megszűntek. Ha egy órát veszek akkor van kb. fél perc amikor 30fps helyett 50-el megy, minden más helyen 70-80 között. Nagyon ritka a kiugró fps, de az OC nélkül is megvan ha csak az eget nézem. Ha annak is adok fél percet, akkor se ezen a két paraméteren múlik az átlag hanem abban az 59 percben ahol amennyivel egyébként fut a játék.
-
#177
westlake
félisten
SchumiBácsi
#176
westlake
félisten
válasz
SchumiBácsi
#176
üzenetére
Átlagról beszélünk! Ha az átlag azonos, akkor az alacsonyabb érték mellett kell lennie egy magasabb értéknek is, hogy azonos legyen az átlag, nem? Vagy csak az a fontos, hogy van egy érték, ami alacsonyabb? Az nem, hogy van egy érték, ami magasabb? Pontosan erre gondoltam, amikor azt írtam, hogy mérési hiba.
-
#176
SchumiBácsi
őstag
westlake
#175
válasz
westlake
#175
üzenetére
Attól hogy az átlag fps közel azonos, lehet a minimum fps-ben drasztikus eltérés.
Van olyan játékom ami alap órajelen beesik 30fps-re a jelenlegi rendszeren, húzott állapotban meg 45fps körül van. A problémamentes helyeken viszont nem változott alapvetően a sebesség, de a hirtelen bekarcolások enyhültek/megszűntek.
Mivel ez nagyon rövid ideig tart, simán lehet 62/62fps úgy is, hogy az egyik állapotban 30fps-re lassul időnként, másik állapotban meg csak 50fps-re.
-
westlake
félisten
válasz
Looserke
#171
üzenetére
Average FPS: 62 vs. Average FPS: 62
Elképesztő!Gondolom olyanról még nem hallottatok, hogy mérési hiba, ugye? Egy hiteles összehasonlítás nálam ott kezdődik, hogy minimum háromszor futtatok le egy tesztet, aminek az eredményeit átlagolom. Vagy tudtok olyan tesztet mutatni, ami minden futtatás után pontosan ugyanazt az eredményt adja? Nem hiszem.
Ráadásul ilyen tesztet olyan rendszeren érdemes futtatni, ahol a CPU már limitálja a GPU-t, nem? Hiszen ha nincs limit, akkor egy erősebb CPU esetleges lassulása nem lehet kihatással a GPU teljesítményére, mivel a az adott (alacsonyabb) CPU teljesítmény még mindig elegendő egy bizonyos FPS fenntartásához.
-
Looserke
őstag
egy sima i7 3770 procit ami 4100-re van húzva így fog meg a spectre és a meltdown patch. Win10 64bit, legfrissebb build:
Shadow of the Tomb Raider benchmark DX12
Patchek bekapcsolva:
Patchek kikapcsolva inSpectre programmal:
Mint látszik főleg a min FPS-re van jelentős hatása, ezt Battlefield V 64fős multiplayerben is tapasztaltam, akinek ilyen régebbi procija van azt tanácsolom, hogy amíg fut a játék előtte kapcsolja ki a patcheket az inSpectre appal és utána indítsa újra a gépet. Játék után meg vissza ugyanígy.
-
-
#07746304
törölt tag
Az elméleted logikus, de van vele egy gond: Az AMD a Ryzen, TR-t megelőző években olyannyira a csőd szélén táncolt, hogy rendszeresen jelentek meg olyan cikkek, amikben azt firtattak, talán ez lesz az utolsó olyan év, amikor még van az Intelnek riválisa. A CPU-ik védettek voltak, csak éppen gyengék voltak teljesítményben. Akkor kellett volna bedobniuk igazán.
-
t72killer
titán
Általában ehhez nekik valamilyen brute force eszköz kell, amiből látni fogod, hogy feltörtek (faltörő kos...), vagy simán írnak egy levelet, hogy xy adatokat szolgáltass be, ha nem akarsz ülni. Ezt a SAJÁT ORSZÁGOMBAN ILLETÉKES hatóság gond nélkül megteheti, VISZONT itt az a különbség, hogy a backdoorok ismerői szabadon és észlelhetetlenül kukkolhatnak az egész világon. Teszik is lelkesen, pl az amcsikról is kiderült, hogy a nagy megfigyelősdiben szépen gyűjtögették európai vállalatok ipari titkait. (ugye ezen a szinten nem az az érdekes infó, hogy két alaszkai honpolgár hogyan csinálja a kiseszkimót - persze aberrált munkatársakból sehol sincs hiány, nyilván ennek is megvan a megfelelő polca).
-
DonToni
aktív tag
Nekem ez az egész úgy bűzlik, ahogy van... mi a biztosíték arra, hogy ezeket a réseket eddig nem használta ki senki? Az, hogy csak mostanában jöttek a felszínre és terjedtek el, még egyáltalán nem jelenti azt, hogy eddig ne lettek volna olyan kártevők, amik ne monitorozták volna a usereket...!
Az nem gyanús senkinek, hogy az egyetlen nagy riválisa az Intelnek pont védett 90%-ban minden ilyesmi ellen?! Tudatosan építették úgy a hardvert, vagy netán ők generálták ezt az egészet?!
Mondom, ez csak az én teóriám, de azért érdemes rajta elgondolkodni kicsit...Jelenleg is még Win7-et használok és a szokott oldalakon kívül nem nagyon látogatok semmi mást... munka, játék és annyi. Az megoldás lehet, ha pl. egy másik ssd-n van egy up to date Win10-es rendszerem?
Mondjuk elég banális lenne, ha pl. játszanék, akkor rebbot és egyik ssd+Win7, ha dolgoznék vagy neteznék, akkor rebbot és másik ssd+Win10....?! Két külön gépet csak ezért nyilván nem fogok építeni, de szerintem más sem... -
válasz
t72killer
#160
üzenetére
Igen, csak egy ilyen tesztnek kb annyi ertelme van, mint deszkaba vert elhajlott szoget strandpapucsnak nevezni. Vegulis, valamennyire meg hasonlit is, kis erolkodessel vegulis meg hasznalni is lehet, csak epp ertelme annyi van, mint hasmenesre a chillisbabnak.
Ertsd: Nem fix, hogy van-e valtozas a teljesitmenyben, es ha igen, akkor mennyi. Egy ertelmesebb teszt a temakorben ugy nezne ki, hogy minimum egy haswell, sandy meg egy coffee lake i7, kikapcsolt meg bekapcsolt HT mellett, legalabb 20 tesztprogramban megmerve webservertol az altalanos benchmarkon at a renderelesig. Nameg valami 2-3 random jatek, mert a csapat 90%-a felvonul a budai var ala, ha nincs egy tesztben gta...
-
#160
t72killer
titán
SchumiBácsi
#158
t72killer
titán
válasz
SchumiBácsi
#158
üzenetére
Én is erre gondoltam, de manapság az ujságírás célja sajnos nem a tömegtájékoztatás, hanem a klikkvadászat. Mennyi időbe is telt volna egy gyorsteszt a témában? Kb 5perc, amiből 2perc a megfelelő registrymódosítás a patch deaktiválására, 1perc egy tesztprogi (pl Aida64) letöltése és 1-1perc aktivált/deaktivált patchel a teszt lefuttatása. És lett volna némi érdemi infó a népnek, 2db konkrét screenshottal.
-
#158
SchumiBácsi
őstag
"Értelmetlenné teszi a Hyper-Threadinget a Spectre v2 javítása"
Nem azért van benne hogy ellensúlyozza a javítás lassító hatását?
HT nélkül még lassabb lenne nem?
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
pengwin
addikt
válasz
csaba951
#153
üzenetére
Minden hír szerint évek óta tisztában voltak vele, hogy kihasználható biztonsági rések voltak a termékeikben, és tudatos döntésként nem javították hardveresen.
Ez nem gyártósor kérdése, mert gyártástechnológiában így is szépen mentek előre a Nehalem óta 45-32-22-14nm-re, viszont magát az architektúrát nem merték komolyan változtatni (javítani), mert azon a téren nem tudtak komoly előrelépést elérni.
Hiába lenne most 10nm-es CPU-juk, ha azzal se tudtak volna architektúrálisan előre lépni. Pl. SB-IB és Haswell-Broadwell között se volt sok különbség, pedig ezeknél is volt komoly csíkszélesség-csökkentés. Persze ez még a tik-tak-korszak volt, ugyanakkor SB-Haswell és Haswell-Skylake között se volt komoly különbség, pedig ezeknél már volt tik (csíkszélesség-csökkentés) és tak (architekturális fejlesztés) is. -
csaba951
veterán
-
pengwin
addikt
válasz
t72killer
#29
üzenetére
Azt hiszem ez így az elmúlt éveket "fejlődését" figyelembe véve nem egy nagy rejtély: Ha javítják hardveresen, akkor az megette volna az IB-Haswell óta nyert teljesítményt teljes egészében, és simán előfordulhatott volna, hogy a már javított generáció akár kicsit lassabb is lett volna a közvetlen elődjénél.
Hiába voltak olyan sokkal az AMD előtt, ha egy ilyet meglépnek az egy PR-öngyilkosság lett volna.
Meg mostmár így a negyedszerre kiadott Skylake kapcsán látszik, hogy nagyon nem volt semmi az Intel tarsolyában az ínséges időkre.
-
s.bala31
őstag
Nekem sincs HT de van egy kis lassulás. Kb -100-130 pont 3Dmark Timespyban amit mértem patch-el. Játékokban nem vettem észre szinte semmi lassulást mert kb mínusz pár fps lehet a különbség bekapcsolt védelemmel. Aminél jelentősebb a sebesség vesztés az az ACreed: Origins itt 7-8 fps a mínusz, bár ez nem biztos hogy a Win10 miatt van lehet a játék legújabb update-e is bekavart plusz az újabb Nv driver is ludas lehet.
-
t72killer
titán
válasz
Geller72
#147
üzenetére
Elvileg windowsra is van megoldás, nem tudom ez fennáll-e még:
"Windows allows you to disable the Meltdown and Spectre protection after installing the patch, making your system vulnerable to these dangerous attacks but eliminating the performance penalty that comes with the fix."
-
Geller72
veterán
válasz
t72killer
#146
üzenetére
..tehát kijelenthetjük, hogy a probléma igazából csak az MS OS-re korlátozódik, mert Linuxból manuálisan mellőzhető. Más kérdés, hogy ez a 4.20-as kernel megjelenésével hogyan változik. (Változik?).
Ez azokra vonatkozik főképp, akiket érint vagy egyáltalán érdekel a sebezhetőség a teljesítmény kárára. Én nem bánnám, ha ez a továbbiakban is választható lenne. -
-
Kansas
addikt
Igen, az Nvidiának nem lett volna mindegy, viszont az AMD és az Intel keresztbelicenszeli egymásnak az x86-ot és az AMD64(x86-64)-et, így ilyen gond nincs. De ez licenszelési kérdés, nem architekturális, egy mai Intel-kompatibilis CPU-nak szüksége van mindkét licenszre(ill. csomagra) és nem tűnik úgy, hogy bármelyik cég szakítani akarna ezzel ez örökséggel, hogy megpróbálkozzon egy teljesen új architektúrával.
Úgy tudom(innen), jelenleg minden Intel és AMD proci natív 64-bites szóhosszúságot használó hardveren futtatja a 32-bites utasításkészleteket is, mivel hardveresen kompatibilis, csak 64-biten minden 2x annyi bit hosszú(regiszterek, memóriacímek, miegymás).
Nem látom, mi szükség lenne bármilyen emulációra vagy fix 32-bites részegységre, amit esetleg utólag ki lehetne hagyni a képletből."illetve több helyről is hallottam már, hogy az x86 kompatibilitás miatt igen sok extra tranzisztort kell feláldozni egy cpuban, és az x64 nélküle is működne" - citation needed -> én még nem hallottam ilyesmiről, és ebből sem az látszik(ha a cikk írója hallott volna ilyenről, tutira beleírja a cikkbe)
Úgy az Microsoft mint a MIT cikk alapján nekem az jön le, hogy a 64-bites és 32-bites architektúra közötti egyetlen különbség a szóhossz, ami a regiszterek és ebből fakadóan a kezelt memóriacímek méretében manifesztálódik, illetve az elnevezések is innen erednek(a Winsows-os API-kat - x86, UWP - most ne keverjük ide), az alap utasításkészletek azonosak. Vannak persze még a spéci utasításkészletek(SSEx, 3DNow, AVX, stb) de azoknak nincs direkt köze az architektúrához azon túl, hogy extra trükköket tartalmaznak hozzá.
-
t72killer
titán
válasz
Geller72
#140
üzenetére
A kis úti laposom szerencsére nem renderel a 15W-os pici procijával, és 14"-ba nem is paszíroznék bele 4c procit. De azért r=1 használat mellett sem örülnék neki, ha az Atomok szintjére lassulna.
"maximum tovább tart az adott process végrehajtása." - azaz mégiscsak meglesz az akksigyilkolás, ha elveszünk a teljesítményből, akkor később tér vissza idle-be a processzor, sőt, lehet a VGA is...
-
Geller72
veterán
válasz
t72killer
#139
üzenetére
"Ráadásul a lebénított proci feladatot kapva valszleg erőlködne, ahogy csak tud, jócskán megdobva a fogyasztást - gyilkolva az akksit."
-Nagyon nem így működnek. Mindegyik esetben (ha van patch, ha nincs) ugyanúgy padlón megy a proci, ha azt adtad meg, és ugyanannyit fogyaszt, maximum tovább tart az adott process végrehajtása. 2c/4th helyett eleve jobb választás a tisztán 4c.
. Gondolom renderelünk, Vincent. (?) . Jó az i7 is, HT nélkül notiban pl. Nekem megy a HT a 4800MQ-ban, de 2 ghz-en van limitálva a max freki. . -
t72killer
titán
10%-ot nagyban lesz.rnék, de itt elvileg sokkal többről van szó. 30-40%-ot egy olyan procinál, ami amúgysem túl combos (15W-os ULV 2c/4t) nagyon nem szívesen nyelnék be, ennyi már a mindennapi böngészésben-office-olásban is feltűnne. Ráadásul a lebénított proci feladatot kapva valszleg erőlködne, ahogy csak tud, jócskán megdobva a fogyasztást - gyilkolva az akksit.
#136: olyan procija már nem sok embernek van. Skylake-től kezdve viszont elég sokat nyúznak, pl Ivy laptopprocink a cégnél is van egy elég combos mobil munkaállomásban, Haswellből is többtucattal találkozik az ember...
-
-
t72killer
titán
Kéne egy jó nagy teszt, HT-s és anélküli procik kb Sandy-tól mostanáig. Tartok tőle, hogy az eddig szerény fogyasztása ellenére is szuperjól muzsikáló céges laposom (i7 5600u van benne) is durva pofont kapott, mielőtt patchelném, lefuttatok majd pár tesztet.
Arra is kíváncsi lennék, hogy a win10 1809-et lehet-e turbózni, azaz a már benne lévő foltot lehet-e deaktiválni
? -
DraXoN
addikt
volt olyan cpu koncepció (azt hiszem pont nvidia esetében), hogy a cpu csak az x64 részeket tudja hardveresen az x86 részek csak "emulálva" lettek volna, de intelnek nem tetszett az utóbbi se így nem lett belőle semmi ... legalábbis pletykált termék, pletykált meg nem jelenése ez... (akár fantázia is lehet).
elvileg ott is azért lett volna így mert intel x86ot nem adja, de amd adta volna az x64et (jó pénzért)..hogy tényleg terveztek-e ilyesmit, és tényleg intel tett-e keresztbe, teljesítményben milyen lett volna, semmit se tudni hivatalosan.. csak az biztos, a pletykák most már jó pár éve "elhaltak" ...
illetve több helyről is hallottam már, hogy az x86 kompatibilitás miatt igen sok extra tranzisztort kell feláldozni egy cpuban, és az x64 nélküle is működne (talán némi kiegészítéssel).. már ha az operációs rendszer is fel van rá készítve (mert jelenleg is használ a windows pár régebbi meghívást a kompatibilitás biztosítása miatt).
-
Kansas
addikt
"cpukból az x86 részleges eldobása" - ez csak nekem hangzik butaságnak? Nem vagyok akkora guru a procik felépítése kapcsán(amikor én arról tanultam, még nem volt 64-bit, csak Itaniumon), hogy definitíve cáfoljam, de kétlem hogy bármelyik prociban lennének hardveresen 32-bites részegységek(regiszterek, stb) a kompatibilitás miatt. Ha jól tudom, annyi az egész, hogy végre tudja a hardver hajtani a 32-bites utasításokat is, max a regiszterek egyik felében nincs semmi.
Valaki hozzáértőbb megerősíthetné vagy cáfolhatná...
p.s. kicsit utána jártam, úgy tűnik, az Itanium procikban van fizikai 32-bites mag, de azok úgyis az utolsókat rúgják, nem lesz belőlük már a mostaninál újabb generáció.
Másrészt mivel a Microsoft fenn akarja tartani a kompatibilitást az x86 API-s alkalmazásokkal, enterprise oldalon biztosan, ezért kétlem, hogy ez olyan simán menne... plusz nem sokan vennének olyan procit, amin nem futnak a kedvenc programjaik(pl a régebbi játékok túlnyomó többsége) -
A guru3d-n azt írják, hogy a kiadott KB4465065 patch a Spectre V3a, V4 és L1TF ellen véd, de a V4 ellen nem lesz aktív a védelem, azt még külön be kell kapcsolni a registry-ben.
-
DraXoN
addikt
nem mondtam, hogy nem lehet, csak x86 vonalon még nem volt példa a többre, kérdéses, hogy az architektúra és programok hogy viszonyulnak ehhez...
pl. elrugaszkodva, lehetne akár big-little féle koncepciót is csinálni pl. sok egyszerűbb "általános" mag, és pár kigyúrt mag ami erős FPU/AVX résszel rendelkezik ... de nem lesz (egyhamar) mert se az oprendszerek, se a programok nem áll(ná)nak rá készen (jelenleg). Elvileg az AMDnél a korábbi APU sorozat is erre az irányba ment a GPUk beköltöztetésével és általános számításra való "elérhetővé tételével" ... a gond csak a kivitelezés (más nyelv, külön meghívásokkal), emiatt nem terjed jelentősen csak egyes területeken a "használata" ezen "vegyes rendszereknek" ... de azok meg többnyire a sima diszkrét vga-kból is profitálnak, nem sok előnye van így a közös memória területnek... anno pl. a JAVA fejlesztői ígérték, hogy közös felületre elérhetővé teszik a 2 egység elérését (1 nyelv) ... de amikor ígérték még a JAVA 6 volt (épp alfa vagy beta teszten volt a JAVA 7).. és akkor a JAVA 9 be ígérték ezt be ... csak nem olyan régen jelent meg a JAVA 8, jó pár évre előre ígértek, így tudhatták, hogy nem kis meló "egységesíteni" a dolgot...
Közös nyelv jó lenne, ebből a szempontból előnyből indult anno a Larabee féle felépítés intelnél ... de abból se lett semmi. Úgy néz ki nem volt elég hatékony, mert hullaszag van a projekt körül.
De egy másik "érdekes" irány lehetne a cpukból az x86 részleges eldobása (sokkal egyszerűbbé tehetné a magot).
mondjuk csak 2-4 cpumag ami hardveresen x86 képes, a többi csak "emulálva", és fixen x64magok lennének x86 részek nélkül (ha még is x86 futna rajtuk azokat csak emulálná.. ha kell) ... a lényeg, a legtöbb x86 program és rendszer úgy se kezeli túl jól a többmagos rendszereket, ami igen az meg már úgy is modernebb nyelven íródik.
Ez utóbbi érdekes koncepció volna.. de nem hallottam ilyenről és nem tudom csinál-e valaki ezzel kapcsolatosan kutatásokat.. ugyan utóbbinál is gond lenne a feladat kiosztás bizonyos magokra operációs rendszer támogatás nélkül, de itt csak specifikusan kellene optimalizálni (kisebb a gond mint a big-little esetén, és nincs 2 nyelv mint a GPU használatakor).
Az utóbbival a fő gond, hogy 2 külön magot kéne tervezni, ami nem kis munka.. illetve kérdés, hogy a jelenlegi felépítésekben mennyire központi elem az x86rész, külön lehet-e választani "egyszerűen". -
-
Geller72
veterán
W10 Pro 64. 1803.17134.407
Up to date a két patchen kívül. Azt a fenti módszerrel "kikapcsoltam". Nekem kell a kraft és a HT is. Ha játszanék, biztos hogy nem vennék 8600K-nál komolyabb procit. 6 mag HT nélkül bőven több mint elég.
Szerintem a 8400 talán a best buy azoknak, akik játszanak. Ja nem, a 8500, mert látom az árakat és a legtöbb helyen olcsóbb a 8400-nál is..
-
dSERiES
senior tag
Igen, én pl. bios-t nem frissítettem (mert nincs erre a szarra
). De már régóta ezt írja az inspectre.
A mikrokód frissítést sztem rád tolja a M$ mindegy hogy milyen build-en vagy és milyen biosod van (régi v új), a windows update-en keresztül, pl. az egyik.
Max nem boot-nál tölti be hanem Win indításkor (de most lehet hogy hülyeséget mondok).
Sztem ez is erre vonatkozik, mármint hogy magadnak is frissíthetsz microcode-ot. -
#07746304
törölt tag
-
carl18
addikt
válasz
#07746304
#107
üzenetére
Én is belenéztem a videódba és rettentően tébolyos, amúgy ezek alatt már használtad a fent említett V2 javítást? vagy csak unatkoztál és felraktál egy videót. Aki akarja meg nézni, a zene is borzalmas, inkább valami grafikon hozzá csaphattál volna. Ennek így semmi értelme szerintem, vagy is én nekem a videó élvezhetetlen volt.
Grafikont a népnek ha már tesztelsz Minden esetre CPU_z alatt én nem éreztem olyan nagynak azt a sebesség vissza esést. Kíváncsi lennék játékok alatt egy Crysis alatt mennyit esne vissza a teljesítmény.
-
jokeph
nagyúr
Hát igen, a HT használhatósága erősen program (ozás) függő.
Aggódni nem kell, amíg a 10 éves XEON X5677 kis OC-val használható a mai napig játszani, ennek a 6 magos variánsai meg pláne.
Most nézem, te is X58-as platfromon nyomatod a 6 magot.
Ezek az öreg vasak addig mennek amíg alaplap lesz alájuk, illetve amíg nem támaszkodik jelentősen az adott alkalmazás olyan utasításkészletre, ami ezekben nincs meg, pl. AVX és társai.
De a jeéenlegi és múltbéli ütemet tekintve nem eszik olyan forrón a kását.
-
-
#99
jokeph
nagyúr
Plazmacucci
#91
jokeph
nagyúr
válasz
Plazmacucci
#91
üzenetére
Érdekes párosítás, meg kell hagyni.
Egyébként le lehet a BIOS-ban tiltani a HT-t.
Advanced fül, CPU setup, HT tecnology Enabled/Disabled. Beállítás Disabledre.
A K430-ban így van, nem hiszem hogy túlvariálták a K450-ben.
-
core i7
addikt
Ha tegyük fel Sapphire Rappids-nál csinálnak egy hatalmas teljesítménybeli ugrást ennek ellenére is őket fogják választani még ha drágább is lesz. Jövőbe pedig senki nem lát ,hogy majd ott is elkövetnek e hasonló bakit mint a Nehalem alapúnál (Remélhetőleg már több figyelmet szentelnek ezek után ennek az egésznek). Az adott pillanatban ha kicsivel is de az lesz a jobb és akkor már az a gamer CPU
Hál Istennek ,hogy az AMD versenyképes lett már a valós magok számát is feltornázták 6-8 magra. Így ez a HT már nem annyira életbe vágó. Vesz az ember egy sima 8 magos intelt ami még olcsóbb is ezért a HT hülyeségért pedig nem ad ki + pénzt tényleg azok szívtak legnagyobbat vele akiknek 2-4 magjuk van és ott jól jönne néha napján az a kis HT. Nem hiba mondták mindig a totyikokban valós mag többet ér
-
carl18
addikt
Igen tudom az Sandy Bridge után vissza vettek a a sebbeségből és csak foltozgatták éveken át a processzorokat. Úgy látszik az intel jövőre se viszi túlzásba a dolgot,és mindent ki akar hozni a 14 nanoból.
Igen én is úgy gondolom a Sapphire Rapids talán hozhat valami nagy előrelépést 7 nanométeren, és ha ott ezek a sebezhetőségek természetesen ki is lesznek javítva hardveresen. Itt szimplán az a nagy baj hogy az intel szinte bármekkora hibát csinálhat nincs semmi következménye mert az emberek ugyan úgy megveszik a termékeiket. "Ha most szándékosan ki iktatják az összes régebbi processzorból a Hypet Treadingot" Az emberek nagy része egy része ugyan úgy megveszi az intelt mert hát az a jobb.
Más felől ez a szándékos butítás nem tűnik hülyeségnek, mert így hamarabb rá tudja venni a régebbi felhasználókat a cserére. MInden esetre már ezért a lépésért nem is érdemli meg az intel hogy ezek után valaki mégegyszer őket válassza.
-
Redneck
nagyúr
Ez az egész Intel biztonsággal kapcsolatos kérdéskör kezd egy gagyi kabaré szintjére süllyedni. Remélem az AMD lenyomja őket és kénytelenek lesznek belemenni egy árversenybe. Egyébként meg elég volt az egész PC-s bohóckodásból, szerencse hogy nekem nem melóra kell.
Ha arra kellett volna és a HT menne a levesbe, kicsit idegesebb lennék a kék gyártóra, így csak szimplán megvetem őket és nem veszek tőlük semmit a közeljövőben.
-
core i7
addikt
Mivel még mindig a Nehalem alapokra építenek (ezért is generációknak nevezik) így persze,hogy időt állóak egyedül a csíkszél váltás 32-22-14 nm (alacsonyabb fogyasztás/magasabb órajel) és a DDR4 hozott érdemi teljesítmény (habár DDR3-hoz képest még ez se nagyon
).IPC is Sandy Haswell Skylaknel nőtt valamennyit inkább
Én már kivárom a teljesen uj archot a Sapphire Rappidset az első genes Nehalemmel
Nem is nagyon értettem ezeket a 1-2-3 genenkénti CPU vásárlásokat alig hozott konyhára talán csúcs Nvi kártyáknál
-
#91
Plazmacucci
félisten
jokeph
#90
-
#90
jokeph
nagyúr
T0mBd1gg3R
#87
jokeph
nagyúr
válasz
T0mBd1gg3R
#87
üzenetére
Csak saját tapsztalattal rendelkezem, ezek a következők:
Esetemben a játék az az SC2... őskövület játékmotor, DX9-et használ és a minél erősebb egyszálas teljesítményű CPU-t szereti.
Látom a különbséget játék közben, az MSI AB+Riveturner párossal ki van iratva real-timeban minden fontosabb info.
2 progival néztem a HT On/Off difit:
CPU-Z ben (tudom, nem egy overkill cucc, azért viszonyításnak megteszi) - a multicore csökkent, a single-core teljesítmény meg nőtt (ezt veszi észre az SC2 jobban).
LinX szintetikus benchmark alatt a Gflops teljesítményt a virtuális szál nem befolyásolta se az i3-n
ál, se a XEON-nál (gyakorlatilag i7-nek felel meg a 4C/8T miatt), ellenben a CPU HT ON-al való tesztelésekor a hőfokok meglépték a 90 fokot is (jól szellőző házban, ideális külső körülmények között), HT OFF-al meg megálltak 70 fok magasságában.A hőfokokat ellenőriztem HWINFO64-el, coretemp-el és AIDA64-el is.
Az OS W10 x64 1607 - i3 7350k (4,2@4,5 GHZ) illetve W10 x64 1709 - XEON X5677 (3,47@4,33 GHZ)
Úgy vélem 2 magos CPU-nál a HT letiltása csak a régebbi, max 2 magot használó játékoknál ad kézzelfogható előnyt, egy mostani modern játék, pl BF1 igényli a fizikai 4 magot, vagy játék függvényében többet is.
(#89) Plazmacucci:
Annyira le van butítva a BIOS ? 
Na ne már.. milyen deszka ? -
#89
Plazmacucci
félisten
jokeph
#85
-
#88
carl18
addikt
T0mBd1gg3R
#86
carl18
addikt
válasz
T0mBd1gg3R
#86
üzenetére
Azonnali kérdések topikban tedd fel a kérdésed.
Ne itt ... -
#87
T0mBd1gg3R
veterán
jokeph
#85
-
#86
T0mBd1gg3R
veterán
Sziasztok!
Egész Spectre és Meltdown témában teljesen szűz vagyok, 3 paragrafusnál hosszabb cikkre rá sem néztem ezügyben. Asrock Fatal1ty Z77 Performance lapom van és i7-2600K procim, dual boot 8.1 és 10.
Mi a teendőm, mire számíthatok? Bios frissítés, windows frissítés, teljesítményvesztés? -
jokeph
nagyúr
Én eddig is HT OFF-al közlekedtem... mondjuk nem véletlenül, az s1366-os XEON X5677-en és a core i3 7350k-n is ki van lőve, mert:
régi játékot nyomatok, ami nem profitál a HT-ből... sőt, kikapcsolt HT látványosan dob rajta.
a kikapcsolt HT hozományaként valamennyit csökkent a fogyasztás, s jelentősen csökkent a CPU hőmérséklete-ez főleg az i3 7350k-nál jelentkezik, ráférne egy delid...
az s1366-os CPU-k még normálisan össze vannak rakva, ezáltal azokat le is lehet hűteni rendesen.
az i5 6600k-nál meg okafogyott a dolog, mert abban meg nincs HT.
Hogy mennyi lesz a teljesítmény-vesztés ?
Ki kell benchmarkolni be és kikapcsolt HT-val, aztán az eredmény fényében eldől a követendő megoldás.
-
carl18
addikt
Most akkor remek az intel új javítása, milyen jó hogy fizettél a Hyper Treading miatt de intel bácsi gondol egyet és egyik napról a másik elveszi. "Úgy se kell az neked"
Egy I7-4790K-ból magyarán az új javítást I5-4690K-t csinál? Elég undorító ez a helyzet ami itt kialakul.Itt az I9-9900K papíron 8/16 szálas akkor ö is elveszíti a Hyper Treadingot?
Akkor jobban megéri 9700K-t vásárolni és ott nem fizetsz a semiért mert az simán 8/8 szálas.Talán az intel is rájött hogy az új processzorjait nem veszik mert túlságosan is időt álloak, valahogy el kell venni az I7-2600K erejét ne akarjon már senki se még éveken át játszani vele
-
-
XMI
csendes tag
Jajjdejo, a hozzaszolasok kozott ott van az az 1995os doksi amiben leirjak ezt a fajta serulekenyseget.
Ez egy meglehetősen erős csúsztatás.
- ötlet szinten bedobják a Cache és TLB időzítés rejtett csatornaként történő használatát (3.10-es fejezet) - konkrét eredményről nem számolnak be
- kicsit részletesebben leírnak egy FPU időzítés és interruptkezelésre épülő rejtett csatorna lehetőséget, ami két kooperáló folyamat esetén használható (3.1 fejezet), kb annyi rokonságot mutat a mostani 2018-as Lazy FPU restore buggal, hogy ez is FPU végrehajtás időzítést használ
- ötlet szinten bedobják, hogy elméletileg lehetséges lehet FPU kivételkezelésre is rejtett csatornát építeni (3.2-es fejezet) - konkrét eredményről nem számolnak be. Ez lenne az ami a mostani Lazy FPU restore bugban előkerül, csak éppen 23 évig senki nem jött rá vagy nem foglalkozott vele komolyan, hogy lehet megvalósítani.A lényeg, hogy van egy jelentős eltérés aközött, hogy valaki bedob egy ötletet és hogy konkrétan demonstrál egy működő megoldást.
A másik, hogy ezt a cikket Spectre-Meltdown kontextusban emlegették, amihez max annyi köze van, hogy a 3.10-esben emlegetett cache timing covert channel, mint eszköz, fel van használva bennük (mint ahogy kb 100 másik korábbi sebezhetőségben is) - de alapvetően a problémát nem ez okozza. Továbbá a Spectre-Meltdown tényleges kihasználhatóságához a spekulatív végrehajtáson kívül soron kívüli végrehajtás is kell, a cikkben - az évet tekintve nem meglepő módón - 386, 486 és Pentium kerül elő, amik mind in-order végrehajtást használtak - ez az egész akkoriban még elvileg sem működhetett.
-
Geller72
veterán
OC-t (eddig) nem érintette. Lebegőpontosban nálam ~15-20% a mínusz. Ez gammákban is kb ennyi, vagy még lehet nagyobb cumi is akár. Azért nem érzed, mert nem 35 vs 30 fps közt kell nézned. Ott észrevennéd.
Akit komolyabban érdekel és nem lusta, az rengeted grafikon talál ez ügyben a neten. (Nem kimondottan rád értem..)Egy kis Yt vid, egy adott szemszögből, before-after jelleggel.
Hogy mennyi is az annyi..
Akiknek nincs idejük végigolvasni a kommenteket. 
De gondolom, akkor erre sem lesz. . Pedig fent azt is leírtam, hogyan kell kikapcsolni. Muszáj lesz olvasgatni.. 
-
dSERiES
senior tag
Na erre kíváncsi leszek a 4790k-val. Én se tudom már követni ki-mit merre frissít és hogy MS melyik mikrokódot teszi bele..
Én nem vettem észre számottevő változást otthoni felhasználással + játékokban sem, OC is maradt szépen.
De ha jól gondolom, 2560x1440-ben annyira nincs meghajtva a proci hogy nagyon érződjön a telj.csökkenés, inkább ha a teljesítménye maximuma közelében jár, akkor észlelhető jobban? -
joysefke
veterán
Nem késett el ez a cikk egy kicsit?
Jobb későn mint soha. A vége az lesz, hogy dinamikusan, menet közben aktiválhatóvá/deaktiválhatóvá teszik a patchet a kritikus kódrészletek védelme érdekében..
Azóta már új fejlemények vannak:
Windows 10: Neuer Intel-Microcode gegen Spectre V3a, V4 & L1TFMost már kezd teljesen átláthatatlanná válni, hogy melyik processzoron mi ellen van már már patch, mi ellen nincs illetve ezek mennyi teljesítménybe kerülnek...
-
Geller72
veterán
válasz
#07746304
#26
üzenetére
Saját progival, amivel "dolgozom". Saját bench. Ennél szerintem durvább eltérés is lehet, de szvsz. aida bench is megmutatja simán. Bár nekem a majd 20% mínusz is már több, mint amit a tolerancia szintem elvisel. Ahogy írtam is, nem szeretnék 8700 helyett egy 8600-at, mert nem annyit és nem azért fizettem. Így a fent látható módon én deaktiváltam a patcheket. Teljesen mindegy milyen W10-ed van, az update-el "lejön" mind.
-
DanD88
tag
válasz
#07746304
#57
üzenetére
Igen, ezért is nevezték spectre-nek (magyarul kisértet), mivel még kisérteni fog évekig.
Az alternatíva hogy maradsz a régi harvernél, amiben valószinű szintén benne van az újonnan felfedezett biztonsági rés is, csak cserébe lehet hogy patcheket már nem adnak ki rá vagy csak késéssel.
Ezt mondtam: "ez nem lesz fájdalommentes".
-
#07746304
törölt tag
"Ami engem illet, én minden elérhető és javasolt update-et feltennék, azután jöhet az olyan proci vásárlása ami lassulás után is elég lesz, pár év múlva meg olyan proci amiben ezek (vagy legalábbis nagy részük) harveresen vannak foltozva."
Amikről majd megint kiderül(het), hogy van bennünk komoly biztonsági rés.
-
DanD88
tag
Persze jó lenne egy ilyen, de ahogy észrevettem még az igazi szakik is kicsit sötétben tapogatolóznak.
Az pedig megmondani hogy mennyi az esély, ezt nem tudni előre, hogy mikor ki fog milyen, ezeket a sebezhetőségeket kihasználó kártékony kódot előállítani, és azzal milyen platformokat céloz meg, mennyire terjed el, mennyire lesz megfékezhető, melyik processzorokat/processzorcsaládot célozza meg stb - ez kb. egy Drake-formula...
Amúgy meg mi vigasztalna meg? Ha azt mondanák hogy használj win7-et mert 75% hogy semmi bajod nem származik belőle? Vagy 90? 99? 99.99...?
A wannacry-ra sem készült senki, a windows update megvolt hozzá már fél éve, csak sokan nem telepítették, és még csak rossz dologra sem kellett kattintani a neten hogy megkapjad - egy szóval nem fogjuk tudni egészen addig amíg nem fogjuk tudni hogy biztos baj van.
Ami engem illet, én minden elérhető és javasolt update-et feltennék, azután jöhet az olyan proci vásárlása ami lassulás után is elég lesz, pár év múlva meg olyan proci amiben ezek (vagy legalábbis nagy részük) harveresen vannak foltozva.
Igen, ez nem lesz fájdalommentes.
-
S_x96x_S
addikt
>Meg valaki írja már meg, hogy milyen esélyei vannak egy intel+win7. vagy amd+win7
>vagy intel+win10 vagy amd+win10, stb. kombinációknak a támadásra....Szerintem a Win10 - az amit fejlesztenek és tunningolnak - optimalizálnak.
A Win7-re nem megy akkora fejlesztői erőforrás. Ott csak a nagyon gáz dolgokat javítják, azokat se igazán optimalizálják.Vagyis szerintem win10 -et érdemes használni biztonsági okok miatt.
Ha a legutolsó - mindennel patchelt Win10 - fentvan, akkor a legtöbb dolog ellen védve vagy.Az AMD (ZEN1) picivel jobb hardveres védelme viszont a jelenleg nem ismert dolgok ellen is ad valami biztonsági övet. ( elméletben , - de ezt csak 4-5 év múlva tudjuk meg igazán)
Viszont ha most Intel HEDT - vonalon ülsz, akkor csak annyit tehetsz,hogy feltelepíted a legutolsó patcheket
és bizonyos programokat óvatosan - szeparáltan futtatsz.
Például web böngészőt / e-mailt - virtuális gépen , hogy valami kártékony webes kód ne tudjon átterjedni.
Ha munkára és játékra is használod, akkor csinálj 2 szeparált környezetet ( 2 külön disk-el , hogy az egyik ne lássa a másikat ) - és ezzel megint minimalizáltad a lehetséges problémákat.
Persze az igazi védelem a 2 különböző gép. -
Lacika112
aktív tag
Amdt eddig is csak elméleti síkon lehetett támadni
Intel még a kövi genben sem foltozza be a hardveres tervezési hibát mert akkora sebességveszteséggel járna hogy a bulldózerek elvernék NAGYON!Marad a szoftveres gányolás ami meg kinyírja amúgy is a teljesítményüket szóval válogass hogy x sebességet akarsz biztonságosan olcsón vagy, x sebességet dugig biztonsági résekkel drágán.
Mindenkinek szíve joga eldönteni mire van szüksége.
-
-
#51
Polllen
félisten
Plazmacucci
#44
Polllen
félisten
válasz
Plazmacucci
#44
üzenetére
Nem lesznek ezentúl aranyáron a használt piacon.
-
Cs1csó
titán
Elvileg a 1803-esben is benne kellene lenni mivel ez egy biztonsági frissítés. Tehát ha akad akkor más miatt. A 1809-es funkciófrissítés ennyivel több a 1803-asnál.
Valamilyen CPU benchmark futtatással tudnád lebuktatni a rendszert ott az elért pontszám ténylegesen megmutatja 2 build közötti sebességkülönbséget.
-
S_x96x_S
addikt
válasz
#26681856
#45
üzenetére
>Az amd is tolja ám kifele a mikrokód frissítéseket, azokra amik nem is érintik őket...
Több is érinti az AMD-t ,( "Spectre V1, AMD Retpoline IBPB for Spectre V2, and speculative store bypass disable (SSBD) for Spectre V4" )
és ezek nem titkosak, publikusak, az AMD is elismeri.>A 4.19-ben az amd epyc prociknál 5% sebesség csökkenést észleltek.
Azért vegyes a kép.
pontosabb teszt 4.19 -re: Intel + AMD + ARM + POWER ... teszt
És a jól látom a 4.19-es javítások is jobban érintették az Intelt , mint az AMD-t.The Performance Cost Of Spectre / Meltdown / Foreshadow Mitigations On Linux 4.19
https://www.phoronix.com/scan.php?page=article&item=linux-419-mitigations&num=3A 4.20-as tesztet meg majd pár hét múlva megudjuk.
-
#44
Plazmacucci
félisten
Geller72
#13
-
DigitXT
félisten
Van az a felhasználás, aminél ki lehet használni. Más kérdés, hogy ha csak nem
biztonságos módon és/vagy a hatékonyság teljes szanálásával, akkor mennyit ér.Ui: miniszerverünkben, cégnél 2 olyasmi proci van, mint nekem. Az összesen 12
fizikai mag, de a HT miatt 24-nek látja a rendszer. Meg lehet dögleszteni szépen!
(Ha a számítási kapacitást fájl-feldolgozásnál csúcsra járatod, nem bírja a RAID.) -
-
DigitXT
félisten
szívás lesz a játékok, és a videó szerkesztők stb
Nekem konkrétan AVC kódolásnál a HT-vel hibázott a proci anno. Szóval OFF,
és gond letudva: eddig is volt szívás azzal, hogy gyors, de szar. Játékoknál pl.
kifejezetten lassítani tudott, szóval régen is inkább jobb volt kikapcsolni...
Tulajdonképpen most is ezt javasolja a cikk, mint legegyszerűbb megoldás.core i7: neked is hatmagos procid van. Szerinted mi használ ki 12 szálat?
-
wwenigma
Jómunkásember
Jajjdejo, a hozzaszolasok kozott ott van az az 1995os doksi amiben leirjak ezt a fajta serulekenyseget. Regebben kerestem de nem talaltam, koszi. Viszont gyorsabb a proci igy meg egy hatso ajto jol jon az NSA-nak is.
-
troviko
senior tag
válasz
t72killer
#29
üzenetére
Jogos kérdések. Az első kérdésre az én véleményem szerint az a válasz, hogy "valószínűleg szándékos volt, és tudták". Még egyszer mondom, ez az én privát véleményem. Abból indulok ki, hogy ha valaki valamit tervez, az alapoktól, akkor annak ismeri a hatásmechanizmusát. Lehet, hogy a tervezés pillanatában azzal nem voltak tisztában, hogy ezt a hibát később ki fogják használni, de azzal tisztában kellett lenniük, hogy kihasználHATJÁK, ha rájönnek. Nyilván bízhattak a tervezők abban, hogy ilyen mélyre sose mennek le a hackerek, biztonsági szakértők, stb, de felelőtlenség így gondolkozni.
Nyilván egy tervezési kérés előtt álltak. "Legyen a dolog nagyon biztonságos, vagy legyen gyors?"
"Áh, ilyen támadást még soha senki nem követett el, úgy se tudja rajtunk kívül senki, hogy működnek ezek, inkább legyen gyors, mint hogy egy esetleges, soha be nem következett támadástól féljünk."Kicsit olyan ez számomra, mintha egy autógyártó elkezdené az autókat 1 fékkörrel gyártani. Mert megspórolnak a 2. fékkör kihagyásával 100 dollárt, és 15 kilót, mennyivel olcsóbb lesz a kocsit gyártani, és egy picit gyorsabb is lesz. Ráadásul, amíg nincs baj a fékrendszerrel, fel sem tűnik a 2. kör hiánya.
Azt feltételezni, hogy az egész felnőtt életükben ezzel foglalkozó, valószínűleg nagyon sokat kereső, vérprofi szakemberek nem tudták ennek az elméleti hátrányait, az számomra elképzelhetetlen. Ha mégis így volt, akkor szerint ezek az emberek már munka nélkül kéne, hogy legyenek.
Inkább arról van szó szerintem, hogy az Intel (szándékosan) olyan microachitectúrát tervezett, amiben biztonságot áldoztak fel, a plusz sebességért. Persze mivel sem korábban, sem azóta nem történt bizonyítottan ezt a rést kihasználó támadás, így talán picit érthető volt a hozzáállásuk, de azt hiszem, egy ekkora cég nem lehet ilyen felelőtlen.
Mert engem speciel nem érdekel, ha a gépem vírusos lesz, de ugyanezek a processzorok irányíthatnak akár kórházakat, kritikus infrastruktúrákat is.A második kérdésre valószínűleg az a válasz, hogy már nem tudták időben módosítani a terveket (a chiptervezés nem két napos meló, bármilyen módosítás évekig elhúzódhat, attól függően, hogy milyen mélyen kell belenyúlni az architektúrába). A kérdés számomra inkább az, hogy miért nem érzi úgy az intel, hogy kárpótolnia kell az átvert felhasználókat.
(És hogy miért nincsenek rommá büntetve, mint a VW csoport a csaló dízelek miatt. Tudtommal még csak eljárás sem folyik az ügyben). -
#07746304
törölt tag
válasz
t72killer
#29
üzenetére
Mert akkor kiderült volna, hogy nem járnak annyira az AMD előtt teljesítményben?
Más kérdés, hogy előkerülhet olyan sérülékenység is, ami kifejezetten az AMD-t érinti érzékenyen.Hogy jött volna az ki, ha nem adnak ki évente egy új generációt, mert éppen tervezés alatt van? Vagy az, ha az új generációt sikerül összehozni, ami biztonságosabb hardveres szempontból mint az elődje, csak éppen lassabb. Ezt a hibát nem kellett volna nyilvánosságra hozni, hanem szépen a gyártót rávenni (mind a kettőt, mert az AMD sem 100%-ig makulátlan, hogy szépen csendben kezdjenek tervezni), a már kiadott CPU-khoz elkészíteni a frissített BIOS-okat és microkódokat, de csak akkor bedobni, ha a szervezett bűnőzi oldal fedezi fel.
-
S_x96x_S
addikt
>Nem késett el ez a cikk egy kicsit?
>"As covered yesterday, there is improved STIBP code ..."Latest:
25 November 2018
"STIBP Patches Updated One Last Time Before Heading To Linux 4.20"
https://www.phoronix.com/scan.php?page=news_item&px=STIBP-Patches-Linux-4.20-V2"Long story short, the patches clear up that very dramatic performance drop saw earlier in the Linux 4.20 cycle. STIBP had been back-ported to existing supported stable series, but has already been reverted due to the performance tax while these new patches may eventually work their way into those LTS trees.
With the second version of the patches sent out today, there were changes to address review comments, renaming of the command-line option to spectre_v2_user=, the options for conditional STIBP and IBPB always modes, and other minor code changes. The V2 patches can be found on the kernel mailing list. Linus Torvalds is already calling for some documentation changes with this issue having caused him some grief with the performance hit not having been properly communicated back during the Linux 4.20 merge window.
Gleixner anticipates these V2 patches to be "hopefully the final version", so ideally in the week ahead we'll see the code merged in time for Linux 4.20-rc5, which still gives it a few weeks of time for testing before the stable Linux 4.20 debut in late December or early January."
majd meg látjuk - mi lesz végül.
-
t72killer
titán
CPU-teljesítmény ügyben főleg HEDT topikokban mozgok, ott nemigen sz.rta le senki se a "patchek" hatását, a nulladik perctől számítva. A játékok persze teljesen más téma.
Egyébként kéne már egy kis átfogó felhomályosítás, hogy az átlag otthon videókat-képeket reszelő júzert a valóságban mennyire fenyegeti az armageddon, ha csakazért is marad 2016-os BIOS-on és a problémás mikrokódot az OS-ből is kiszedi/nem hagyja bele települni. Persze tudom, azt is meg lehet lépni, hogy az ember a munkagépet teljesen leválasztja a netről és felrakja rá a melóhoz ideális OS-buildet mindenféle kacat frissítés nélkül.
-
-
Cifu
félisten
Igen, de az Intelt jobban.
A Phoronix néhány tesztjében az AMD meg tudta előzni a teszt 4.20-as kernel alatt a az Intel procit, míg korábbi kernelekkel ott probléma nélkül megverte az Intel. Csakhogy az STIBP az AMD-nek is teljesítményveszteséget jelent, ezért az AMD sem javasolja a beépítését.
Ahogy pedig az #1-es hsz.-ben szó volt róla, pár nappal ezelőtt az STIBP ki lett véve a 4.20-as kernelből is, mert úton van egy kevesebb erőforrást lefogó változat.
-
#14
Alogonomus
őstag
Alogonomus
őstag
Intelnek nagyon visszaütött idén a minőség helyett a mennyiség hajszolása, amit az elmúlt 10+ évben követtek.
AMD ráadásul az őt érintő néhány hibát már hardveresen javította is az új már piacon levő termékeiben, míg az Intel a hírek szerint még a tervezés alatt álló következő generációs termékeiben is csak néhány hibát lesz képes elvileg hardveresen javítani, a többi még évekig csak a szoftveres lefojtással lesz kezelhető.Persze egy ideig lehet direkt nem váltani az új javított BIOS-ra, meg lehet direkt nem alkalmazni az operációs rendszerek egyes javításait, de az új alaplapok már eleve a javított BIOS-t tartalmazzák majd, ahogy szoftveresen is idővel tarthatatlanná válik, hogy két külön patchelési hozzáállással kell számolni a rendszerek fejlesztésénél.
A Spectre/Meltdown/Foreshadow hármas az becsődölt 10 nm-es terveikkel együtt akár az Intel "őszödjét" is elhozhatja...
-
Geller72
veterán
Csak szólok. Ha az update be van kapcsolva, már rég települt a gépedre.
Nem kérdezik meg, hogy akarod e.Csak saját felelősségre, no meg akit ez az egész nem érdekel, mert pl:csak játszik a gépén:
-CMD adminként elindít.
-Első lépésben:reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverride /t REG_DWORD /d 3 /f-Enter.
-Második lépésben:
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverrideMask /t REG_DWORD /d 3 /f-Enter.
Exit.
Újraindítás.Nekem az i7-8700-at így fogta meg:
Before:
After:
Azé' köszi.
15679 integer MIPS 17487 helyett. Ez nálam pont egy proci különbség, mert a patchnek hála lett (volna) egy 8600K-m a 8700 helyett. #köszdenem. Viszont szerver szinten rátolnám simán a szart az Intelre és benyújtanék egy szép számlát nekik
PS:
Az AMD-s tulajoknak 22.-én ment egy "csomag", amiben nekik volt meglepi. Az egy 13.-i patch elvileg. -
westlake
félisten
Elárulok egy titkot: a Windows-ban is van Intel mikrokód, ahogy a BIOS-ban is. Elárulok egy másik titkot is: ha az Intel kiad egy frissített mikrokódot, akkor azt előbb-utóbb beépíti a Microsoft a Windows-ba.
A Microsoftot nem érdekli, hogy melyik CPU teljesítménye mennyivel esik vissza. Nem az ő dolga. Az ő dolga az, hogy az operációs rendszerükbe NE legyen biztonsági rés! -
#07746304
törölt tag
Ameddig Windowsnál nem vezetik be kötelezően, nem izgat. Linuxot nem használok. Viszont ha Windows-nál is benyomják akkor szívás lesz a játékok, és a videó szerkesztők stb miatt. Windows servernél sem zörget, csak Windows 10 Home és PRO-nál ne legyen. A cím meg clickbait, mert ha az lenne, hogy szívás van Linuxon, akkor kb a felhasználók döntő többsége nem is kattintana
-
CPT.Pirk
Jómunkásember
Nem késett el ez a cikk egy kicsit?
"As covered yesterday, there is improved STIBP code on the way for Linux 4.20 that by default just apply STIBP to SECCOMP threads and processes requesting it via prctl() but otherwise is off by default (that behavior can also be changed via kernel parameters). Once that code is ready to go for Linux 4.20, we may see it then back-ported to these stable trees." [link]
Per pillanat a 4.19 és 4.14 LTS kernelekben már ki is van kapcsolva az STIBP, a kódrészletek el vannak távolítva. Készül javított STIBP kiadás ami kevesebb teljesítményveszteséget fog okozni, de alapból ki lesz kapcsolva.
*szerk: a cím meg egy kissé félrevezető.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
. Gondolom renderelünk, Vincent. (?) 
?
Ne itt ...
De gondolom, akkor erre sem lesz. 
Új hozzászólás Aktív témák
- Apple iPhone 14 Plus 256GB / AKKU 100% / 12 hónap jótállás
- Xiaomi 14T Pro 512GB, Kártyafüggetlen, 1 Év Garanciával
- Bomba ár! Dell Latitude 5420 - i5-1145G7 I 16GB I 256SSD I HDMI I 14" FHD I Cam I W11 I Garancia!
- GYÖNYÖRŰ iPhone 12 mini 64GB Black -1 ÉV GARANCIA - Kártyafüggetlen, MS2954
- Újra Akcióban!!! Ducky One 2 Mini és SF billentyűzetek a bolti ár töredékéért! Számla+Gari
Állásajánlatok
Cég: FOTC
Város: Budapest