Miért lassult le a Windows 10?

Microsoft Windows

Feltűnt a minap, hogy az újabb Windowsokon mennyire lelassultak a programjaim. Csináltam ezért egy kis tesztprogramot, aminek az idejét megmértem néhány rendszeren.

A tesztprogram beolvassa a Vonyó szótárt
(kb. 200 ezer szótári tétel),
felépít belőle egy hash táblát,
a hash táblán lineárisan végigmegy,  
minden kulcsra rákeres, és ellenőrzi a találatot.
A bejárást-ellenőrzést 100-szor megismétli.

A mérést i3-4330-as processzoron futó qemuval virtualizált rendszereken végeztem. A hardver minden esetben ugyanaz volt, kivéve a qemu hostot, amin szintén elvégeztem a mérést, és ahol a qemu questek 4G memóriájával szemben 16G állt rendelkezésre.

NetBSD-n gcc-vel, FreeBSD-n clang-gal, Linuxon és Windowson mindkettővel próbálkoztam, mindkét fordító nagyjából ugyanazokat az eredményeket produkálta. Windowsokon ugyanazt az exe-t hordoztam körbe.

Az eredmények:

qemu host        35 sec
NetBSD-8         31 sec
Arch Linux        36 sec
FreeBSD-12     48 sec  
win1709           75 sec
win1903         214 sec
win1909         220 sec

A méréseket sokszor megismételtem, itt az átlagok vannak feltüntetve. A két lassú Windows esetében feltűnő volt az eredmények nagy szórása.

Megállapítások:

Kis érdekesség, hogy a NetBSD a nyeri a versenyt.

El tudom fogadani, hogy a Arch Linux 2-szer gyorsabb, mint a Windows-1709. Ehhez szokva voltam, ennyivel jobb a Linux, na.

Ami miatt a méréshez egyáltalán hozzákezdtem: Hogy a fenébe lehet, hogy ugyanaz a program a Windows 10 újabb kiadásain a korábbihoz képest 3-szor lassabb. És így a Linux már 6-szoros fölényben van.

Elsőre azt gondolom, hogy a memóriakezelés hatékonyságában van különbség. Linuxon malloc, Windowson GlobalAlloc kezeli a memóriát. De akkor is, 3-szoros romlás? Tud valaki erre magyarázatot?

 

  • 1713 megtekintés

( pehsa | 2020. 01. 15., sze – 12:51 )

Hát így nagyon jó kérdés, hogy mi okozhatja az ilyen szintű lassulást.

 

Esetleg olyat nem tudnál csinálni, hogy a teszt programodba beépítesz néhány log-ot a lépések közé, hogy látszódjon egyes folyamatok mennyi ideig futottak. Például szótár betöltés elindulása, betöltés vége, stb...

"Errors are red
My screen in blue
Someone help me
I've deleted Sys32"

( mrev | 2020. 01. 15., sze – 13:01 )

A program 100-szor végigjárja a táblát, minden alkalommal kiír egy '.'-ot. Ebből látszik, hogy a beolvasás, hash építés azonnal megvan, utána egyenletes sebességgel jönnek a pontok.

Lógok a szeren (K. Frigyes)

Lógok az ereszen (Sz. József)

( ncc1701 | 2020. 01. 15., sze – 13:06 )

Az inteles cpu hibajavítások szépen benne lehetnek.

( kisbetu v | 2020. 01. 15., sze – 14:22 )

Azért, mert megszűnt a win7 támogatása, mindenki átállt 10-re, a mikorszoft meg nem bírja kiszolgálni az igényeket.

:Đ

"Normális ember már nem kommentel sehol." (c) Poli

( harlequin | 2020. 01. 15., sze – 14:35 )

A CPU speedel is szokott hülyéskedni a Win (bár virtualizációban nem tudom hogy ez hogy működik)

“Any book worth banning is a book worth reading.”

( AiRLAC v | 2020. 01. 15., sze – 14:46 )

Power management ki van Windows-on kapcsolva?

"After successfully ignoring Google, FAQ's, the board search and leaving a undecipherable post in the wrong sub-forum don't expect an intelligent reply."

( agostonl | 2020. 01. 15., sze – 15:14 )

Töltsd le az inSpectre progit és használd, majd utána is mérj!
https://www.grc.com/inspectre.htm

( •̀ᴗ•́)╭∩╮

"speciel a blockchain igenis hogy jó megoldás, ezért nagy erőkkel keressük hozzá a problémát"
"A picsat, az internet a porno es a macskas kepek tarolorandszere! : HJ"

Az élet ott kezdődik, amikor rájössz, hogy szart sem kell bizonyítanod senkinek

Ha meg akarod nevettetni Istent, készíts tervet!

( mrev | 2020. 01. 15., sze – 15:40 )

Szerkesztve: 2020. 01. 15., sze – 15:45

Az összes hasonló felvetésre:

Sokat vacakoltam vele, hogy az msmpeng.exe és hasonlók ne fussanak. Ha ezek is futottak volna, még rosszabb lett volna az eredmény. Itt egymagos teljesítményről  van szó, és a processz végig 100%-ban futott egy magon. Tehát nem az van, hogy a tesztprogram helyett valami más futott, hanem, hogy nem tudott gyorsabban futni.

Külön kiemelem: Nem érdekel, milyen lassan fut. De magyarázza már meg valaki, hogy ugyanazon a hardveren, ugyanaz a program miért fut 3-szor lassabban.

win1709:   75 sec

win1903: 214 sec

Ezen vagyok kiakadva.

Lógok a szeren (K. Frigyes)

Lógok az ereszen (Sz. József)

( gelei v | 2020. 01. 15., sze – 15:45 )

Intel-VT support? Virtio driverek? Bus format? IO mode?

Ha VM-ben mersz teljesitmenyt, nem biztos, hogy arra a kerdesre kapsz valaszt, amit szeretnel. :)

Minden mérés ugyanazon a qemu-kvm virtualizált gépen volt. A Windowsoknak nem volt saját volt grafikus képernyőjük, hanem rdesktopban futottak, Az összes io 100 darab pont kiírása volt az stdout-ra, ami 0 másodpercet vett igénybe. A UNIX-ok ssh-n keresztül futottak, az ssh is 0 időt fogyasztott.

A 4330 CPU természetesen támogatja az Intel VT-t. Nem valószínű, hogy ezt a Windows  kikapcsolná, mert az emuláció még sokkal lassabb volna. De, ha azt mondod, hogy szándékos lassításról van szó, azt elhiszem.

Lógok a szeren (K. Frigyes)

Lógok az ereszen (Sz. József)

( zitev v | 2020. 01. 15., sze – 16:06 )

sub

"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

( azbest | 2020. 01. 15., sze – 23:32 )

Szerkesztve: 2020. 01. 15., sze – 23:50

Google azért ad pár tippet, 

ez például synology oldalán van problémaleírás arról, hogy miért rossz a teljesítmény a rendszerükön 1709-es utáni win-t virtualizálva. Túl régi verziók, amik nem kompatibilisek az újabb win-ekkel:
https://community.synology.com/enu/forum/1/post/125209

Ha jól értem újabb qemu / vmm verzió kell a megoldáshoz

Másik vonal, itt redhat bugriport arról, hogy 1803-mal nagy idle cpu terhelés van. Valami bugot találtak, amit frissítéssel lehet javítani. De ez itt lehet csak redhat-os csomagban, esetleg előfizetős módon megkapható... nem ismerem:
https://bugzilla.redhat.com/show_bug.cgi?id=1610461

Nem írtam eddig, de a qemu host egy Manjaro Linux, tehát a rajta levő qemu-kvm nem lehet nagyon régi. Ahogy látom, a vmm az valami windowsos dolog, nem ismerem, nem tudok vele mit kezdeni. Persze lehet qemu hiba a jelenség mögött, ehhez sajnos  nem értek.

Lógok a szeren (K. Frigyes)

Lógok az ereszen (Sz. József)

Virtual machine manager. Az első linken a Synology saját cuccáról van szó. Ha jól értem ez a gui, amin keresztül lehet kezelni a qemu alatt futó virtuális gépeket. Valószínűleg ott szimlán arról volt szó, hogy régi qemu verziót használ a synology. A redhat-os annyiból rosszabb, hogy minta az sokkal frisebb verzióról szólna, szintén teljesítmény probléma kapcsán.

A kommentek közt van ahol azt írják, hogy a hpet bekapcsolása segíthet (ha a host rendszer maga nem tiltja), alapból tiltja a qemu

https://forum.proxmox.com/threads/high-cpu-load-for-windows-10-guests-when-idle.44531/

( Sulc v | 2020. 01. 16., cs – 05:55 )

Ez elég érdekes, közreadod a tesztet, hogy más is futtathassa?

C:\Users\WDAGUtilityAccount\Desktop\bench>s

time(ms):       0
....................................................................................................
amnesic  amnΘzißs, emlΘkezetΘt vesztett
while [waIl]  id⌡, r÷vid id⌡, fßradozßs, mφg, mialatt, noha, bßr, amφg csak
so [s@U]  olyan, ilyen, annyira, ennyire, φgy, ·gy, hasonl≤kΘppen, akkΘnt, ha, feltΘve hogy, tehßt, ·gyhogy
AAA  American Automobile Association, Amateur Athletic Association
hell [hel]  pokol, fene, jßtΘkbarlang, kßrtyabarlang
to look [lUk]  nΘz, tekint, lßtszik, tekintetΘvel kifejez vmt, megnΘz, tekintetΘvel kifejez, t√nik

time(ms):  68,250
time: 1min 9sec

 

i5-9600K+32GB ram, 17% cpu usage, windows sandboxban futtatva win 10.0.19035.1

~ubuntu, raspbian, os x~

( render_elek v | 2020. 01. 16., cs – 10:10 )

Host gépen kikapcsolt HT esetén is van ekkora eltérés?

( bekesh44 | 2020. 01. 16., cs – 14:42 )

Háromszor futtattam, hasonló eredménnyel.

Core i5-7500 16GB RAM 30-31% cpu usage.

winver 1909

____________________________________________________________________________________________________

time(ms):       0
....................................................................................................
amnesic  amnÚzißs, emlÚkezetÚt vesztett
while [waIl]  id§, r÷vid id§, fßradozßs, mÝg, mialatt, noha, bßr, amÝg csak
so [s@U]  olyan, ilyen, annyira, ennyire, Ýgy, ˙gy, hasonlˇkÚppen, akkÚnt, ha, feltÚve hogy, tehßt, ˙gyhogy
AAA  American Automobile Association, Amateur Athletic Association
hell [hel]  pokol, fene, jßtÚkbarlang, kßrtyabarlang
to look [lUk]  nÚz, tekint, lßtszik, tekintetÚvel kifejez vmt, megnÚz, tekintetÚvel kifejez, tűnik

time(ms): 162,969
time: 2min 43sec

____________________________________________________________________________________________________

( elod v | 2020. 01. 16., cs – 16:24 )

Core i5-5300U, 16GB RAM, de fut egy csomó minden és zabálta a memóriát a Firefox és Chrome is:

C:\Users\...\Downloads\bench>s

time(ms):       0
....................................................................................................
amnesic  amnΘzißs, emlΘkezetΘt vesztett
while [waIl]  id⌡, r÷vid id⌡, fßradozßs, mφg, mialatt, noha, bßr, amφg csak
so [s@U]  olyan, ilyen, annyira, ennyire, φgy, ·gy, hasonl≤kΘppen, akkΘnt, ha, feltΘve hogy, tehßt, ·gyhogy
AAA  American Automobile Association, Amateur Athletic Association
hell [hel]  pokol, fene, jßtΘkbarlang, kßrtyabarlang
to look [lUk]  nΘz, tekint, lßtszik, tekintetΘvel kifejez vmt, megnΘz, tekintetΘvel kifejez, t√nik

time(ms): 230,750
time: 3min 52sec

( uid_16313 | 2020. 01. 16., cs – 17:48 )

Ahogy egyre biztonságosabb a rendszer, úgy egyre használhatatlanabb. Mondhatnánk úgy is, hogy tákolmány.

( Raynes v | 2020. 01. 17., p – 16:51 )

Ebben nincs semmi meglepő, külön méregetés nélkül is megmondta volna itt neked akárki, hogy a NetBSD jelenleg a létező legsoványabb (azért is ajánlottam már hajbazernek), íaztán a FreeBSD, a Win10 meg a legbloatabb, a többiek, főleg a Linux, a kettő között, attól függően, hogy mennyire bloat disztró, meg mennyire van optimalizálva. A Clear Linux és a Fedora még az egyébként villámgyors Archnál is gyorsabb, mert LTO-t használnak fordításkor, meg agresszív, O3-as optimalizációval fordítanak, igaz az meg csak modern procikon hoz gyorsulást, ahol sok a cache.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( kbalint v | 2020. 01. 20., h – 14:01 )

enberek! nézzétek már meg a windows sandbox-szal is, hogy ti is olyan eredményeket kaptok-e, mint én: 2x gyorsulást.

~ubuntu, raspbian, os x~