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?
Hozzászólások
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"
"Például szótár betöltés elindulása, betöltés vége, stb...": pont ez lehet az a pont ahol egy víruskereső megfogja a fájlt. És az egyiken ilyen NOD32 van, a másikon olyan AVAST. Pl.
Nem fut a víruskereső.
Lógok a szeren (K. Frigyes)
Lógok az ereszen (Sz. József)
windows defender sem? meglepne
~ubuntu, raspbian, os x~
Az sem.
Lógok a szeren (K. Frigyes)
Lógok az ereszen (Sz. József)
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)
Az inteles cpu hibajavítások szépen benne lehetnek.
Na de ennyire?
Ennyire nem hiszem, de simán -50%. Eleve intelnél a ht-t már érdemes sokak szerint tiltani.
Ennyire.
Egyébként meg: https://support.microsoft.com/en-us/help/4072698/windows-server-speculative-execution-side-channel-vulnerabilities
Amikor a fejlesztésben nyers erő helyett jön a hókuszpókusz...
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
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
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.”
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."
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 ö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)
Ugyanazon a "vason" mérve..! Egy fejlettebb oprendszer "természetesen" több erőforrást használ, (használna,) - ha lenne. Ezt pedig így demonstrálják (v. szimulálják,) is. - A hardvergyártók örömére.
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)
"szándékos lassításról.." - - Ugyan.., csak az akkumulátorod elöregedése miatt életed és testi épségedet védik. - Az Apple mobiljaihoz hasonlatosan... :(
sub
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
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/
Ez elég érdekes, közreadod a tesztet, hogy más is futtathassa?
Az jó lenne ...
+1 (sub)
Itt van:
http://comfirm.hu/pub/bench.zip
64 bites, mingw64-gcc-vel fordított exe
mellékelve a mingw dll-ek
mellékelve a CCC források
Lógok a szeren (K. Frigyes)
Lógok az ereszen (Sz. József)
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~
RAW windowson futtatva pedig
time(ms): 172,453
time: 2min 53sec
:D:D
WTF!
~ubuntu, raspbian, os x~
1809-es verzió
I5-2500 és 8 gb ram
2m33s = 153 sec
Valószínű a verzió miatt gyorsabban futott le, mint egy i5-9600K-n.
Ryzen 5-2600/16G DDR4-3000 dual channel: 108.8sec, win10-1909, host gépen. Kár, hogy a 12 szál helyett csak 1-et használ.
Nekem az avg elkapta és beküldte átvizsgálásra! :D
Host gépen kikapcsolt HT esetén is van ekkora eltérés?
Kipróbáltam, HT nélkül is ugyanaz a helyzet.
Lógok a szeren (K. Frigyes)
Lógok az ereszen (Sz. József)
tm.exe-t megfogta a symantec...
Hazaérek, kipróbálom AMD-n....
Megelőztelek :)
Athlon II x4 645 (1909)
125,735 ms
2min 7s
27% CPU
A10-5750M (1909)
176,734
2 min 58 s
40-60% CPU
FX 6100 (win7)
219,103 ms
3 min 39 s
16% CPU
R7 1700 fix 3.6 Ghz, letiltott smt, 16GB (2933) ram, win10 1909 nativ
time(ms): 113,969
time: 1min 54sec
HUP te Zsiga !
2600X, 16GB ram, Win10 latest:
1min 24sec
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
____________________________________________________________________________________________________
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
És így mi értelme volt mérni?
Én is így mértem, ment egy fhd yt videó is. De másik szálon. :)
Ahogy egyre biztonságosabb a rendszer, úgy egyre használhatatlanabb. Mondhatnánk úgy is, hogy tákolmány.
Vagy csak egy qemu bug, ahogy már linkeltem
https://hup.hu/comment/2426623#comment-2426623
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.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
Hát én nem mernék ilyen generális kijelentést tenni, sem sorrend, sem legek terén...
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~