sebesség

kami911 képe

Sebesség tekintetében is a mezőny élére áll a Firefox?

Az elmúlt években a Mozilla hatalmas mennyiségű erőforrást biztosított arra, hogy a Firefox böngészőjük ne csak személyes szféra védelmében járjon élen, hanem a lehető leggyorsabb legyen a böngészők közül a legkisebb memóriafogyasztás mellett. Persze ez a két utóbbi cél gyakran egymással szemben áll, és nehéz őket összehangolni. A Firefox egy régi architektúra volt, hiszen sok dolgot a nagy elődtől, a Netscape Navigatortól örökölt a Gecko motor révén. A Mozilla célja volt az állandó megújítás volt, hogy fel tudja venni az újabb böngészőkkel, amelyek alapját modernebb kialakítás jellemzi. Ezeknek a fejlesztéseknek a gyökere egészen 2012-ig vezethető vissza, amikor megjelent a Servo projekt, amelyet én 2013-ben láttam, akkor még erősen fejlesztési változatban. A fejlesztéseket az a felismerés vezette, hogy a Firefox böngészőmotorja elavulttá vált, mert nem támogatja megfelelően a modern többmagos processzorokat. A Gecko motor tehát a Firefox réges-régi jellemzője, amelyet még a Netscape időkből hozott magával: 

kami911 képe

Landolt a Linux 6.0-ban a „Dummy Wait” problémát javító AMD sebességnövelő javítás

2002 óta, amikor a kernel ACPI-támogatással bővült, egy felesleges várakozási - „dummy wait” művelet került be a kernelbe. Történt ez mindazért, mert akkoriban néhány chipkészletnél az STPCLK# nem volt időben érvényesítve a kernelben az üresjárat során. A dummy I/O olvasás késlelteti a további utasításfeldolgozást, amíg a CPU teljesen le nem áll. Az AMD egyik mérnöke azonban nemrégiben észrevette, hogy ezt a viselkedést a modern AMD Zen 3 hardvereken is alkalmazzák, és megállapította, hogy ez teljesítményproblémákhoz vezethet az terhelt és üresjárati fázisok között gyorsan váltó munkaterheléseknél, és különösen a nagyobb magszámú rendszerek, például a Ryzen Threadripper és EPYC platformok esetében.

K Prateek Nayak, az AMD mérnöke, kimutatta, hogy a hibás megoldása milyen jelentős hatással lehet a teljesítményre a modern hardverekre az AMD rendszereken. Az Intel CPU-k eközben nem használják ezt a kódutat a modern hardverekhez, így nem érinti őket ez a teljesítményvesztés. Az adott tesztben a minimum adatátviteli értékek 1390.52 százalékkal növekedtek és az átlagos adatátvitel is 50.85 százalékkal emelkedett.

Eredetileg az AMD egy javítást végzett itt, majd Dave Hansen, az Intel mérnöke tisztította és egyszerűsítette ezt a kódot. Ez utóbbi javítás egyszerűen nem alkalmazza ezt a "dummy wait" megoldást, kivéve a régebbi (Nehalem előtti) Intel rendszereket. Mostantól tehát az AMD rendszerek is kihagyják ezt a műveletet, amely a modern rendszereken ronthatja a teljesítményt. Mivel ez főként az leterhelt és az üresjárati állapotok között gyakran váltó munkaterhelésekre van hatással, valamint a nagyobb magszámú rendszereknél jobban észrevehető, az AMD EPYC szerver teljesítménye ezzel a javítással meglehetősen érdekes lehet, különösen a webszerver / adatbázis-munkaterhelések és más típusú gyors tesztek esetében.

Feliratkozás RSS - sebesség csatornájára