Flash teljesítmény Linuxon, avagy a böngésző esete a gyorsítótárral

Little Susie

Állandó -teljesítménybeli- kritika tárgya a Linuxos Flash player,
de azt hiszem, olyan jelenségbe botlottam, ami azt mutatja,
hogy bizony a saját -linuxos- házunk táján sem árthat söprögetni...

Idősödő, egymagos, 2,4GHz P4 Celeron gépen tapasztaltam,
(új, még nem publikus Susie béta telepítés után),
hogy az egyébként villámgyors Google Chrome böngészőben a Flash plugin akadozva játszik le
egy szokványos (videa.hu) flash videót. (közel 100% CPU load)

Megnéztem ugyanazt a videót új Firefox segítségével, a load csökkent, 70-85% közé,
a videó így már nézhető lett, de még mindig akadozott néha.

Előszedtem kedvenc "állatorvosi lovam" (igen, az ominózus Firefox 1.5.0.10),
és lám, a videó nem szaggat, és a CPU load alig 40% fölött járt.

(Végső kísérletként -böngésző nélküli tiszta mérés- "standalone" flash player, az eredmény 30-33% load.)

Az első két tesztben látványosan jobb eredményre jutottam egy AMD Athlon 2400+-on,
és egy 2,4-es "telivér" P4-en is, ahol még tovább csökkent a szórás.

Természetesen nem az FF 1.5 tartalmaz valami ismeretlen varázsszert...
mindössze -feltételezhetően- kevésbé agresszív módon használja a CPU gyorsítótárát!
Tehát, a modern linuxos böngészők agresszív módon támaszkodnak az L2 cache-re,
és "elveszik" azt a flash player elől!
Amint olyan böngésző kerül a képbe, ami nem sajátítja ki a cache-t,
a flash player azonnal elfogadható értéken kezd működni...
(fenti CPU példákban az L2 mérete 128k, 512k, 512k...a processzorok nyers teljesítménye pedig nagyjából azonos)

Kíváncsi vagyok, hogy csak én futottam bele ebbe a jelenségbe, vagy esetleg egy általános linuxos problémát sikerült találni?
Köszönettel fogadnám, ha hasonló mérésekről eredményeket kapnék,
esetleg nem csak böngésző+flash, hanem egyéb "sebességbeli átok sújtotta" linuxos területről is!

( 3ri | 2010. 06. 26., szo – 03:50 )

Ezt egész biztos, hogy ez okozza? A modernebb böngészők agresszívebb cache használata?
Bevallom nincs sok tapasztalatom ezen a területen, de más lehetőségek esetleg amik processzort terhelnek nem lehetnek (esetleg több dolog együttese)?

Ha ez a helyzet igaz úgy lehetne pl. megnézni, hogy két teljesen azonos rendszer, és gépfelépítés, csak a processzor más a cache méretében.. de az órajel és a generáció megegyezik (csupán az egyikben le van tiltva a cache egy része)..
A 2 intel ebből a szempontból hova tartozott?

----
Dropbox tár: https://www.dropbox.com/referrals/NTY1ODc5OTQ5

Nem vagyok biztos a következtetésben, de más értelmes magyarázatot eddig még nem találtam.
A két intel két, szinte tök azonos HP D530 SFF gép volt, proci is azonos család,
mindössze az egyik Celeron, a másik nem.
(tehát 128k cache és 512k cache, más különbség szinte nincs, még a "bogomips" értékük is azonos)
-
"Attempting to crack SpeedLock can damage your sanity"

( eCaffee | 2010. 06. 26., szo – 04:02 )

Újabb mérés, ugyanazzal a videó tartalommal:
(a fenti szösszenetben szereplő AMD Athlon konfigon)

openSUSE 11.0, FF 3.5.5, Flash 10.0.r32 : CPU load 60-70% közt

openSUSE 11.0, FF 1.5.0.10, Flash 10.0.r32 : CPU load 30-40% közt

openSUSE 11.0, standalone Flash 9 : 70%-os load
openSUSE 11.0, standalone Flash 10.1.53.64 : 40-50% közti load

-
"Attempting to crack SpeedLock can damage your sanity"

( answ | 2010. 06. 26., szo – 06:08 )

Érdekes felvetés, további vizsgálatot igényelne.

Sajnos a flash és a Linux két össze nem illő fogalom.
Az általános lassúságán kívül számomra sokkal borzasztóbb a hardveres videó gyorsítás hiánya és hogy a böngésző összeomlások 32%-át okozza.

Asztali gépemen (Q6600/GF6800/4GB ram) akadoznak a flash videók Linux alatt. Van egy régi Dothan magos 1.7-es Pentium M laptopom Geforce Go 6200-as osztott memóriás videokártyával és ezen Windows XP alatt ugyanez akadásmentes volt.

Igaz jelenleg még 8.04 LTS-t használok, most fogok csak 10.04 LTS-re állni. Kíváncsi leszek milyen változást hoz.

Egyébként az az érdekesség, hogy CPU-t nem használja ki, szimplán akad. Tehát biztosan csak szoftver probléma, hogy a videó időnként "beakad". Hasonlóval találkoztam egy nagyon régi laptopon Linux alatt (Debian) zenelejátszás közben. A zene megakadt egy-egy nagyobb képernyő művelet hatására. Hiába állítottam sudu-val nice-ot a legnagyobb prioritásra (-20), akkor is megakasztotta (csak ritkábban). Gondoltam valami real-time kernelt szedek le, de aztán nem volt időm vele foglalkozni, pedig most is kíváncsi vagyok segített-e volna. Talán majd nyáron..

Lásd:
http://www.adobe.com/devnet/flashplayer/articles/fplayer10.1_hardware_a…
http://blog.futtta.be/2010/05/04/but-how-unstable-is-flash-really/

Józan paraszti ésszel számolva, ha az öreg 2400+-os Athlon-on kb. 30-40%-ig javítható a böngésző+flash
okozta terhelés, akkor egy mai modern asztali gépen akár 5-10%-ig kellene hogy csökkenjen.
Ebben az esetben a lőtéri döglött kutyát sem érdekelné, hogy van-e GPU gyorsítás, vagy sem...
Megcsinálom a mérés-sorozatot kétmagos Athlon E4200-on, Firefox 1.5.0.10 + flash 10.0.r32 (vagy 10.1) mellett,
és hozom az eredményeket.
-
"Attempting to crack SpeedLock can damage your sanity"

"egy mai modern asztali gépen akár 5-10%-ig kellene hogy csökkenjen."
ez így is van...
phenom II x4 940, 3ghz (c'n'q-val), 4gb ram (3gb-t tud használni a win7 32 bit), virtualboxban: 3 mag, 1gb ram, ubuntu 10.04, xfce, firefox 3.6.3, adobe flash plugin 10.0 r45. vimea.hu max 15%. (de ha szeretnéd, elindíthatom a nem-virtualizált 64 bites bubuntut it és megnézhetem ott is.)

Mielőtt beírom, megmérem ugyanezt a jelenséget több gépen (egymagos, kétmagos, stb.),
de ez nem Chrome probléma, Firefox 2.0, 3.0.x, 3.5-3.6 szintén érintett,
illetve reggel mértem egy 10.x Operát is...szintén zenész.

Attól tartok, hogy megtaláltam a kulcsot a korábbi x264 HD vitához,
ahol a Firefox 1.5-tel egyidős régi mplayer jobb teljesítményt nyújtott,
mint az új.
Ha a gyorsítótár-stratégia okozza, akkor a gcc lehet a ludas.
Ha ez igaznak bizonyul, a fordító javítása megoldást nyújthatna
szinte az összes linuxos teljesítmény-problémára.
-
"Attempting to crack SpeedLock can damage your sanity"

[találgatás on]
Lehetőség szerint akár újra is forgathatnád a firefox-ot, a régit az új gcc-vel, az újat meg a firefox 1.5.x korabelivel.(bár ez gondolom elég macerás, már, ha egyáltalán lehetséges/?/) Elvileg így kimutatható lenne a gcc sara.(bár nem tudom, hogy az számít-e valamit, hogy a disztró mivel lett forgatva eredetileg)
[találgatás off]

Nem értek hozzá, csak puszta gondolat volt az újraforgatás. Mondjuk, az új firefoxot valószínű nem lehet ezer+1 éves gcc-vel fordítani, viszont fordítva talán van rá esély.

Ha az ff 1.5 friss gcc-vel fordítva magas load-ot mutatna, az perdöntő lenne.
Megpróbálom, "csak" szabadidő kérdése...:)

Szerk.:

részeredmény: friss Opera böngészőből létezik gcc4 és gcc3 verzió:
gcc4-es esetén: 80-90% load
gcc3-as Opera (gcc compat libek segítségével): 70% körüli load...

(a gép a lentebb említett 1GHz P3M, 512k L2 laptop)

a firefox fordítás még nem jött össze, időhiány miatt.
-
"Attempting to crack SpeedLock can damage your sanity"

( bambano | 2010. 06. 26., szo – 15:47 )

threadelés baja is lehet a flash lejátszásnak, mert amíg játszik, töltöget is. Nekem akkor akad csak, ha valamiért nem tud a netről tölteni. Ez akkor is megtörténik, ha egyébként a töltés előrébb jár, mint a lejátszás.

Valahol kb. 4-5000 bogomips felett a probléma látszólag megszűnik, a flash nem akad, de a terhelés továbbra is irreális marad,
viszont átlagos felhasználó számára -aki nem mér- nem feltűnő.
Ha a feltételezésem helyes, akkor az Athlon E4200-on kb. 10-15% terhelést kell kapnom,
Firefox 1.5.0.10 és Flash 10.0.r32 használata mellett.
(Chrome és FF3.x esetén pedig valahol 40-60% közt kell lennie)
Holnap megmérem, és hozom az eredményeket.

Szerk.:
Megmértem.
AMD Athlon 64 X2 Dual Core 4200+ (2x1800MHz, 512k L2)
(ja, és továbbra is 32 bites Linux)

új Google Chrome, új Flash player: 25-30% load
Firefox 1.5.0.10, új Flash player: 5-10% load!!!!

ugyanaz az ARÁNY mint a korábbi P4 és régi Athlon méréseknél.
-
"Attempting to crack SpeedLock can damage your sanity"

Még egy érdekes mérési eredmény:

Pentium 3 M 1GHz, 512k L2 (Compaq Evo N600c)

openSUSE 10.1, Firefox 1.5.0.3, Flash 10.0.r12 : 60% load
(simán illeszkedik a várt értékek közé)

Vissza fogom mérni ugyanezen a vason FF 3.x, illetve Chrome alatt is.

Szerk.:
ugyanezen a vason friss Chrome, friss Flash player : 85-100% load, akadozik...

Szerk.:
Firefox 3.5.7, friss Flash: 80-90% load...

-
"Attempting to crack SpeedLock can damage your sanity"

( XMI | 2010. 06. 26., szo – 15:57 )

Mielőtt bármi következtetést vonnánk le, talán mérjünk!

Erre való a linux perfcounters, kiolvas a CPU-ból mindenféle alacsonyszintű teljesítménymetrikát, pl cache találati arányt, instructions/clock arányt, elágazás előrejelző találati arányát, TLB találatokat stb.

Little Susie alatt nem tudom, hogy mi a csomag neve (van-e egyáltalán belőle csomag). Arch alatt perf-util-nak hívják.

Elég sok érdekes dolgot ki lehet mutatni vele. Egyik kedvenc demóm amit szoktam mutogatni a 7zip benchmark kimérése, amikor a CPU metrikákból egyértelműen látod, hogy mikor csinálja a betömörítést és mikor a kitömörítést. Eközben az OS ütemező szintjén végig egységesen csak 100% CPU terhelést látsz.

Elsőre kicsit pilótavizsgás használni, a tool rengeteg mindent tud, de az egész profiling témakörben nem úszható meg, hogy előtte megértenénk, hogy pontosan mi is van a háttérben. Itt van pl egy leírás hozzá: http://anton.ozlabs.org/blog/2009/09/04/using-performance-counters-for-linux/, de ez csak egy kis ízelítő, hogy el tudjunk indulni. A teljes doksija a linux kernelfában van a linux-$version/tools/perf/Documentation alatt. Én is csak egy kis részét használtam ki annak, amit tud.
---
Internet Memetikai Tanszék

Oprofile (System Wide Profiler for Linux Systems) lesz ebből, az opensuse repókból ezt lehet beszerezni, de még utánanézek.
(Susie alatt a teljes opensuse választék elérhető, teljes a kompatibilitás, körülnézek profiler ügyben)
-
"Attempting to crack SpeedLock can damage your sanity"

( log69 | 2010. 06. 26., szo – 15:57 )

érdekes amit mondasz, kíváncsian várom a fejleményeket :)

( ihrwein | 2010. 06. 26., szo – 20:24 )

Én linux párti vagyok, de a flashünk az tényleg sz... Még quake liveozni is alig lehet, mert szaggat. Windows 7 alatt szuperül ment...

Root-Tech

A quake live nem kötődik a flashhez, mivel a játék a Quake3 OpenGL motorját használja, csak "ablak" módban a böngészőbe van épülve. Ez csakis a videókártyán múlik, hogy mekkora teljesítményt tud hozni viszonyításképp windowshoz (pl. nálam int. Ati HD 4200-on ugyanazon grafikai beállításokkal egész játszható, nem sokkal rosszabb mint windowson, de érdekes bugokba futottam, windows alatt is, ez már csak az új drivernek tudható be (mellékes))

( gergov | 2010. 06. 27., v – 00:43 )

Csak érdekességképp jegyezném meg, hogy ugyan 64 biten vagyok, de én youtube-ot 30-45% load között tudok nézni bekapcsolt compiz mellett, miközben a CPU az energiagarázdálkodás miatt 800Mhz-en üzemel. A processzor egy C2D T7500.
Ez az érték nincs túlságosan távol attól, amit nálam a flash windowson produkál.

Tudom. De ha el van szúrva a cache kezelése, godolom, még ekkora méretnél is jelentkeznie kellene a problémának, már ha a 64bites utasításokkal létezik egyáltalán.
Egyébként meg bennem felmerül a kérdés, mi a jó. Ne használják ki a gyorsítótárat a programok, mert ha igen, a régi gépeken rosszabbul futnak, vagy használják ki, mert ha nem, akkor az újakon futnak rosszul?
(Mellesleg, én ehhez már túl fiatal vagyok, nem vagyok tisztában ilyesmikkel. A program írójának - nem magas szinten, hanem mondjuk asm-ben - mennyire van arra ráhatása, hogy mi kerüljön bele a cache-be, és mi ne? Ez nem az adott CPU magánügye?)

( vl v | 2010. 06. 27., v – 02:29 )

Természetesen nem az FF 1.5 tartalmaz valami ismeretlen varázsszert...
mindössze -feltételezhetően- kevésbé agresszív módon használja a CPU gyorsítótárát!
Tehát, a modern linuxos böngészők agresszív módon támaszkodnak az L2 cache-re,
és "elveszik" azt a flash player elől!
Amint olyan böngésző kerül a képbe, ami nem sajátítja ki a cache-t,
a flash player azonnal elfogadható értéken kezd működni...
(fenti CPU példákban az L2 mérete 128k, 512k, 512k...a processzorok nyers teljesítménye pedig nagyjából azonos)

Nem bántásból, de.

A gondolatmeneted - SZVSZ - nettó baromság.

A linux nem desktop os, itt egyszerre fut 5-10 program, akkor is, ha éppen csak egy browsert használsz, és ezek mind ugyanazt a cpu-t, és benne ugyanazt a cache-t használják. Már pusztán csak a Firefox által használt shared libeknek is simán nagyobb a footprintje, mint az L2 cache mérete bármelyik jelenkori Intel CPU-ban, esélytelen vagy, hogy az egész cache-ből működhessen.

Egy Athlont, egy P4-et, meg egy Celeront "nyers teljesítménye nagyjából azonos" sommás mondattal illetni, ez viszont már fájdalmas. Abszolúte irreálisnak érzem, hogy ilyen szinten össze tudjál hasonlítani cpu-kat. Ahhoz ennél sokkal jobban kéne ezekhez a dolgokhoz érteni.

És hogy mit csinál a flash player, amikor éppen eszi a cpu-t, miközben az alkalmazás benne nem akar semmit se? Az én tippem szerint kb. a "while (1);" ciklusmagra épülhet a kódjuk... hogy ez az adobe hülyesége, vagy a netscape plugin interfész szar, arra azért lehet következtetni abból, hogy browser nélkül a standalone lejátszó mit tud.

Te egyáltalán elolvastad azt, amihez hozzászóltál?
Sehol sem írtam azt, hogy az EGÉSZ program bármikor is elférhetne a cache-ben...
a találati arány romlása viszont drasztikus módon befolyásolja a működést,
elméletileg 90% cache-hit alatt már nem lehet gazdaságos üzemről beszélni.
Lehet úgy programokat írni és fordítani, hogy jól kihasználják a gyorsítótárat,
és létezik ennek az ellenkezője is.
Az optimalizálás szélsőséges esetében -és az L2 méretétől függően- előfordulhat,
hogy egy child process már nem fogja tudni az L2 áldásait hasznosítani,
és lelassul az egész folyamat, mert a processzor gyorsítótárazási stratégiája
nem tud kellő találati arányt produkálni.

A példában szereplő P4 és P4 Celeron szinte hajszálra azonos,
mindössze a cache mérete különböző. (512k L2 és 128k L2).
A példában szereplő Athlon XP 2400+ teljesítménye nagyjából megfelel az idézett P4-nek.

A standalon flash player által okozott terhelés csak tájékoztató érték volt részemről,
mivel a lényeg a browser+flash összefüggésen volt.
Az emberek többsége a böngészőben "használ" flash playert,
méghozzá elég gyakran.

-
"Attempting to crack SpeedLock can damage your sanity"

Sehol sem írtam azt, hogy az EGÉSZ program bármikor is elférhetne a cache-ben...

Én sem :)

Nem az egész programnak kell beférnie, hanem annak a kódnak, ami a megjelenítéshez szükséges (már amennyiben teljesen cache-ből szeretnénk futtatni).
Ez nem egy program, hanem minimum három független alkalmazás (X, browser, flash player), meg egy marék shared lib. Ezekből az, ami akár csak az egyszeri kirajzoláshoz kell, sem fér el a cache-ben, tehát illúzió az az elképzelés, hogy van olyan méretű L2 cache, amiben "ez az egész" elférhetne.

a találati arány romlása viszont drasztikus módon befolyásolja a működést,
elméletileg 90% cache-hit alatt már nem lehet gazdaságos üzemről beszélni.

Persze. De honnan tudod, hogy mennyi a cache-hit rate?
Meg aztán, honnan tudod, hogy a cache duplázása mennyivel javítaná ezt?

Lehet úgy programokat írni és fordítani, hogy jól kihasználják a gyorsítótárat,
és létezik ennek az ellenkezője is.
Az optimalizálás szélsőséges esetében -és az L2 méretétől függően- előfordulhat,
hogy egy child process már nem fogja tudni az L2 áldásait hasznosítani,
és lelassul az egész folyamat, mert a processzor gyorsítótárazási stratégiája
nem tud kellő találati arányt produkálni.

Általánosságban persze, lehet így.
De hogy a konkrét esetben mi hogy van, azt honnan a fenéből tudod?

A példában szereplő Athlon XP 2400+ teljesítménye nagyjából megfelel az idézett P4-nek.

Általánosságban. Te meg konkrét alkalmazás konkrét futását nézegetted.

Az AMD és az Intel cpu-k - bármily meglepő - nem ugyanolyan felépítésűek, és noha ugyanazokat az utasításokat hajtják végre, egyiken ez gyorsabb, másikon meg amaz. Sommás az a kijelentés, hogy "nagyjából megfelel", mert konkrét utasítássorozatot jelentősen eltérő sebességgel (mondjuk 30-50% különbség simán előfordulhat) tudnak végrehajtani. Mivel nem ismered a konkrét kódot, így bárminemű következtetés levonása = spekuláció. A korrekt következtetés az lenne, hogy "nem tudjuk, hogy mi van".

A standalon flash player által okozott terhelés csak tájékoztató érték volt részemről,
mivel a lényeg a browser+flash összefüggésen volt.

Pedig pont itt van a lényeg: a standalone pl. ehet azért kevesebb cpu-t, mert nincs neki egy kolonc a nyakán, amit cipelnie kéne. A browser gondoskodik a plugin megjelenítéséről, így pl. minden rajzolás a browser kódján keresztül történik. Ez önmagában simán okozhat akkora különbséget, mint amit láttál, különösképpen, ha még szarul is van megírva a kód.

Eljutottál ugyanarra a végkövetkeztetésre, amiért a topik létrejött...
hogy simán lehetséges, hogy nem a linuxos flash player rossz minőségű,
hanem a mai linuxos browserek, a libek, és maga a gcc is.
Ehhez én azt a feltételezést vetettem fel, hogy szerintem a gcc olyan kódot állít elő,
ami rossz cache-hit arányt eredményez, és csak nagyon nagy méretű gyorsítótárral működik jól,
de akkor sem gazdaságosan.
Ezt sem tényként írtam, csak mint lehetséges okot.
Több szem többet lát, utánajárhatsz te is!
-
"Attempting to crack SpeedLock can damage your sanity"

( uid_18247 | 2010. 07. 05., h – 22:43 )

Ebben történt valami előrelépés? GCC-ék biztos örülnének egy bejelentésnek. (vagy csúnyán lemaradtam)

----------------
(Működésképtelen) processzorokat gyűjtök. Ha van, msg me!

Sajnos, nem. (az utolsó biztos nyom az volt, hogy a legfrissebb Opera gcc3/gcc4 verziói közt jól mérhető sebesség-különbség van,
azonos vason, flash használat közben.)
Családi okok miatt átmenetileg jegelnem kell ezt a témát, meg a Susie release körüli összes munkát is...
Remélem, néhány hét szünet után újra gőzerővel tudok majd a projekten dolgozni.
-
"Attempting to crack SpeedLock can damage your sanity"

( zolpet | 2010. 08. 02., h – 20:58 )

Beleolvasgattam a topikba, érdekes, amit írtok... a cache-sel kapcsolatban... Nálam is rosszul megy a flash ( nem tudok konkrét adatot írni, mert flash-se válogatja nálam, hogy mi hogy megy vagy nem megy ). Athlon X2 4 magos cpu-m van, 2,6 ghz-es, viszont csak 512 K a cache magonként. Még nem tudtam rájönni, hogy mitól függ, hogy csak 1 vagy 4 magot használ a lejátszó, de ha 1 magot használ, általában nem megy a flash... 64 bites Mint van fent.

Ami még érdekes számomra : a memtest kb. 4 gigabájt / sec savszélt ír a memóriámra, de pl. Win 7 alatt a Sisoft Sandra 10 gigabájt / sec-et... Nem tudom, egy 2 generációval régebbi cpu-nak milyen gyors a cache-e...

Úgy rémlik, mintha a P4-es celeronomban ennl lassabb lett volna... Mármint a cache.

( balintdavid | 2010. 10. 10., v – 22:06 )

Kicsit off, de találtam egy szerintem igen hasznos "flash render quality" nevű extensiont Google chromiumhoz.
Annyit csinál, hogy a flash videók minőségét high helyet alapértelmezetten low-ra/medium-re állítja.
Notebookosoknak musthave, akkuidőn elég sokat dob.
-------------------------
$ killall npviewer.bin

( eCaffee | 2010. 10. 11., h – 23:51 )

Újabb részeredményeim vannak.
A tervezett Firefox 3.6 gcc3 projekt kilátástalannak látszik,
ráérő időm mellett egyedül képtelen vagyok workaroundolni, mert annyi a fordítási hiba,
de azért nem adom fel, lehet, hogy csak a fától nem láttam már az erdőt. :)

Ami viszont sikerült: lefordítottam a rókát gcc4.3-mal, de 256K L2-re, és egyéb cache-hit javításokkal optimalizálva.
A "gyári" Firefox a tesztgépen, az adott flash tesztvideóval 66-83% közötti hullámzó load-ot produkál,
a 256K cache optimalizált verzió stabil 66%-ot.

Összehasonlítás: Google Chrome ugyanitt 83-100% load,
kedvenc állatorvosi lovam, a Firefox 1.5-ös 40% load körül teljesít
és az öreg Konqueror 3.5.9 az eddigi rekorder 33%-kal.
-
"Attempting to crack SpeedLock can damage your sanity"

( turul16 v | 2010. 10. 12., k – 08:38 )

Tobb koze lehett annek ehhoz, hogy flash egyfajta sandbocban lehet, mivel egyebkent crash eseten a bongoszot is vinne magaval.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Nem igazán sandbox, csak több szálon fut a böngésző,
például a Chrome és az új FF is.

Lehet benne valami, de ennek ellenére a cache-optimalizált fordítás
mintegy 16% terhelést faragott le.

Megnézem azt is, hogy mennyi az X szerver vesztesége ebből
a maradék 66% load-ból.

-
"Attempting to crack SpeedLock can damage your sanity"

( thebeast | 2011. 03. 04., p – 16:09 )

Történt ez ügyben valami előrelépés?

Ráéreztem, hogy történt valami ezen a régi fórumszálon. :)
Az újabb Chrome verziók úgy fest, hogy lassan csiszolódnak
a kellő teljesítmény irányába, ami nem lenne hátrány,
mert nagyon szeretném az új, openSUSE 11.3 műszaki alapokra épülő
Little Susie kiadást alapértelmezetten a Google Chrome-mal kiadni.
(sok tekintetben gyorsabb mint a tűzróka, és a KDE integrációja
is mérföldekkel előrébb jár, nem kell tákolni ahhoz, hogy kinézzen valahogy,
és a kellő alkalmazásokkal meg is nyisson mindent amire a rendszer képes...
a Firefox pedig elérhető maradna a csomagkezelőből)

A gcc mérésekkel nem jutottam előrébb, ez ügyben jól jönne a segítség,
mert nyakig ér a munka, éppen egy kamion mennyiségű gépre toljuk fel
a Susie telepítő különböző igények szerint bővített változatait,
egy teljes magyar kistérség online intézményeinek teljes rendszer-megújítása
van folyamatban. (nyertünk pályázaton, végre lecserélhetjük a roncsok nagy részét,
amit szinte kizárólag a Susie és a lelkesedés tartott működésben eddig)

Egy biztos: próbáltam közben többször régebbi gcc-vel új Firefoxot fordítani,
de annyi volt a hiba, mint égen a csillag...egyedül workaroundolni lehetetlen.
-
"Attempting to crack SpeedLock can damage your sanity"

Kipróbáltam ubuntu 10.10 alatt az új Adobe Flash Player Incubator 11.0.0.58-at, chromiumban. Eddig elég selejt volt számomra a teljes képernyős honfoglaló, pörgött a ventillátorom mint az őrült, nagy volt a load, és cserébe még szaggatott is, mint a fene (Intel T2130 + 2gb 533 RAM, nyílt ati driver), viszont ezzel az újjal gyakorlatilag élvezhetővé vált a minősége. Szerintem megér egy próbát! (eddig hibát sem tapasztaltam)

Amúgy hogy állsz a 11.3-ra épülő verzióval? A 11.1-et ma próbáltam ki, csak sajnos abban elég öreg a kernel, és nincs benne az új nyílt radeon driver 3d támogatása, ennek ellenére a 3d-t nem kívánó dolgok nagyon szépen mentek, attól eltekintve, hogy ext4-es particiót live módban nem tudtam felcsatolni, de ez lehet, hogy az én hülyeségem :)

A Flash is fejlődik lassan Linuxon, meg a Chrome is...be fog ez érni.

A 11.3-alapú Susie szépen lassan halad, kezd kiadásra érett lenni.
Van vele egy-két gondom még, leginkább elvi mint műszaki...:)
(mi menjen a levesbe a KDE4 mellé...pulse, az új bt stack,
nouveau, firefox, stb kidobása...nem egyszerű döntések)
Egy kis designolás van még hátra, meg az OSDM beszélő cucc legalapvetőbb
elemei, mármint hogy elkészüljön, és bele lehessen tenni.
Közben rengeteget (már ahogy időm engedi) vagyok itt is,
de főleg a Susie / (open)SuSE fórumon...support, és állandó közösségszervezés.
Közben tanítok, már nem csak élőben mint régen, hanem a PC-WORLD
linux tanfolyam rovatát is írom, és igyekszem úgy készíteni,
hogy bármilyen linuxon hasznát vegyék az olvasók.
(a linux és a Susie disztribúció állandó reklámja
a cikkírói munkám ellenértéke, meg is van az eredménye,
kb. 50000 telepítő kering az országban lemezen,
plusz a letöltések, amit már nem is számolok)

Ami hátráltat a 11.3 kapcsán még: rengeteg a munka, szakadásig dolgozom
a régi 11.1 kiadással is, terjesztés, support,
csőstül jönnek az emberek linuxot rakatni a gépükre,
és utána általában a második gépükre is, ha van nekik...
meg még sok minden egyéb munka is van, ami szintén IT terület,
ott van még a régi kis alap kisvállalkozásom,
és mindezek után, ha hazaérek, a családdal, a gyerekekkel is törődni kell...
de hála az égnek, nem nagyon ülök ölbe tett kézzel az év eleji uborkaszezon idején.
:)
Félre ne értse senki, ez a pár sor nem panasz volt, inkább öröm.

-
"Attempting to crack SpeedLock can damage your sanity"

Ahhoz én sem vagyok eléggé fasza gyerek, hogy egyedül a végére járjak ennek az egésznek, lefordítsam az összes böngészőt az összes gcc verzióval, és egyedül megoldjam az egész kérdéskört. :)
Én egyszerűen csak találtam egy érdekes jelenséget, kételkedni kezdtem valamiben, közzétettem, elvégeztem jónéhány mérést, néhány böngésző-fordítást, és bízom benne, hogy a közösség bevonásával már megoldódik a rejtély többi darabja is.
Óriási haladást jelentene, ha a gcc-t érintő gyanú beigazolódna, mert ez "szinte ingyen" szabadíthatna fel egy nagyon komoly teljesítmény-többletet.

-
"Attempting to crack SpeedLock can damage your sanity"

Nem jelentettem, de telekürtöltem vele a fórumokat,
hogy mindenki gondolkodhasson rajta.
Rengetegen olvasták, és ennyi ember között már nem vész el az információ.
A Susie fejlesztés közben próbálom minden adandó alkalommal
tovább tesztelni a dolgot, hátha egyértelműen kiderül a miértje,
vagy egyszerűen csak további bizonyítékokat sikerül találni.

(a bugreportokban már régóta nem hiszek, sok helyen évekig sem válaszolnak,
bár lehet, hogy megérne egy próbát)

-
"Attempting to crack SpeedLock can damage your sanity"