- yoursoft blogja
- A hozzászóláshoz be kell jelentkezni
Hozzászólások
Annyira azért nem kell sírni, tekinthetjük ezt egyfajta időutazásnak, visszarepültünk 5 évet sebességben...
-------------------------
Dropbox refer - mert kell a hely: https://db.tt/V3RtXWLl
neut @ présház
- A hozzászóláshoz be kell jelentkezni
Na ja, de közbe a szoftver lassabb lett, mondván, hogy "vegyé jobb hardvert, hülye gyerek!". :D
Sok helyen hanyagolják az optimizációt ilyen nézetek miatt. :/
- A hozzászóláshoz be kell jelentkezni
Szerintem az Intel még örül is ennek a hibának. Hiszen kívánt teljesítmény eléréséhez mostantól jóval több processzort adhat el.
Vagyis az egészből jól csak az járt akinek a hibát köszönhetjük.
- A hozzászóláshoz be kell jelentkezni
Tizenötöt. Öt éve az akkori i5-2520m semmivel sem volt lassúbb, mint most az i5-6300u, patch nélkül.
Felhasználói élmény tekintetében most közelebb járok a core2duohoz. :(
- A hozzászóláshoz be kell jelentkezni
Én meg i7-2620M-en észre sem veszem, hogy lassabb lenne a foltokkal, teljesen átleg felhasználás mellett. Igaz én nem fejlesztek, nem szervert üzemeltetek, meg nem adatbázisozok. Azért ne túlozzunk, a C2D szinthez nagyon sokat kéne visszaesni.
„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek…” Aron1988@PH Fórum
- A hozzászóláshoz be kell jelentkezni
Nem mondom, hogy nincs benne költői túlzás, de én nem érzem a C2D gépem lassúbbnak, amíg a neten böngészek vagy épp valami IDE-t futtatva turkálok python kódban. Talán a fullHD videók lejátszásánál lenne látható, de notebookon az i5 integrált procija van, a C2D mellett meg valami akkor bikának számító nvidia, ami úgy vettem észre, ebben sokat segít.
- A hozzászóláshoz be kell jelentkezni
Kernel verzio?
Mi drasztikusan pocsek eredmenyeket latunk HWE kernellel. A standard kernel viszonylag jol teljesit.
Bar en elsosorban meltdown utani allapotot vizsgalom, hogy ott mi a legjobb.
- A hozzászóláshoz be kell jelentkezni
Ez van:
4.4.0-112-generic
- A hozzászóláshoz be kell jelentkezni
Mentem vissza 109 ala, mert esett kelt a gep 112 alatt.
Nem intel, oreg vas nem baratolja ezt a javitast ahogy latom.
CPU Lx cache akarmiket emleget a panicban.
http://karikasostor.hu - Az autentikus zajforrás.
- A hozzászóláshoz be kell jelentkezni
elkérhetném a panic teljes szövegét? virtuális gépről van szó?
szerk. 'öreg vas', szóval a második kérdésem érvénytelen.
----------------------------------
szélsőségesen idealista, fősodratú hozzászólás
- A hozzászóláshoz be kell jelentkezni
Január elején írtam egy szintetikus tesztet C-ben, amely kernelhívásokkal terhelte a rendszert.
Ebben a szélsőséges tesztben volt proci, ahol tizedére esett a teljesítmény a régi és Meltdown javítást tartalmazó kernel között.
Ekkor megörültem, hogy annó a C-ben írt teljesítményorientált programoknál jól döntöttem:
- I/O buffering az alkalmazáson belül, ezáltal ritkább read/write kernelhívás.
- ahol lehetett mmap() a read/write helyett.
- ...
Így ezeknél a programoknál megúsztam néhány százalékos teljesítménycsökkenéssel.
Az egészben tényleg azt kell látni, hogy maga a kernelhívás lassult le. Amíg az alkalmazáson belül tud futni a kódod, addig a proci maradt ugyanolyan gyors.
- A hozzászóláshoz be kell jelentkezni
Rendszer hivasok szamanak minimilizalasa, mindig jo otlet.
En a `javitas elott` is draganak talaltam.
mmap sajnos nem fog megmenti ebben az esetben,
ha lap hianyzik a kitoltesehez/bevesesehez szinten contex switch kell.
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
Próbáljátok ki 4.15.2-es kernellel. Abban van mindhárom sebezhetőségre tisztán szoftveres javítás (Spectre1 ellen user pointer sanitization, Spectre2 ellen full generic retpoline, Meltdown ellen PTI), ami sokkal kisebb mértékben lassít, mint a mikrokód alapú javítás. Plusz a retpoline-on és a PTI-n csiszoltak teljesítményügyileg is, meg egy csomó új optimalizáció bejött (a Phoronix írt róla, este teszek be linket), ami ellensúlyozza ezeknek a foltoknak a hatását, a 4.16-os ágból vannak ezek visszaportolva 4.15.2-re.
Plusz szerveren nyugodtan ki lehet ezeket a javításokat kapcsolni a nopti, noretpoline, meg gondolom az sanitization is letiltható kernelparaméterrel. Szerveren (meg mondjuk fejlesztésre használt virtuális gépen) ugyanis nem böngésztek, meg csak ellenőrzött kód kerül fel, így nincs ami kihasználja a sérülékenységet, ezek a spekulatív végrehajtást érintő rések nem használhatók ki távolról, csak a helyi gépre felkerülve és futtatva. Desktop felhasználónál fontos, aki minden szutykot futtat a gépén meg a fene tudja milyen oldalakat látogat és ott milyen szkriptek futnak le.
„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek…” Aron1988@PH Fórum
- A hozzászóláshoz be kell jelentkezni