Vlákno názorů k článku PekWM od TomBA - Nerozumiem načo sa stale pušťaju ľudia do programovania...
-
TomBA (neregistrovaný)Nerozumiem načo sa stale pušťaju ľudia do programovania nových wm, cms,..... Osvedčené a v mnohom dokonalejšie projekty stoja, umieraju a opäť niekto vynachádza koleso.
Čo vie tento viac ako tie stovky pred nim?? NIČ.
Je rýchlejší? NIE JE. Je to wm, to znamena ze v celej tej reťazi služieb a aplikácii ktore sa spustia na to aby bol "systém klikací" je to len jeno kolečko.... Jeho zrýchlením alebo spomalením sa NIC nerieši.
Trápi niekoho rýchlosť klikacieho unixu? Asi nie. Ak ano tak treba ist celkom inou cestou. Odist od X-iek, kompletna prestavba systemu..... Graficke nadstavby musia prejst z userspace do systemu... Komunikacia s hardware musi ist cez menej vrstiev.... Je to cesta?? Mozno sa mierne zvysi rychlosť, ale co stabilita? Konfigurovateľnosť?
A vôbec kam sa všetci ponáhľate? Nie je jedno či sa aplikácia spustí za 10 alebo 15 sekund? Nemáte čas? Ak nemate čas, pri počítači ho nenájdete.... -
No diverzita je vyhodna, ale je pravda ze v pripade windowmanageru je to uz lehce prehnane ... specialne "lehkych" windowmanageru jsou opravdu mraky, pritom tak 10 by stacilo ...
Rychlejsi to sice je, ale jen pro nekoho - pokud si misto KDE pustite lehky windowmanager a pak v nem (tak jako autor) pustite KDE Kicker a KWrite, moc si nepomuzete (ale alespon mate cistejsi plochu).
Odejit od Xek k necemu lepsimu by urcite pomohlo, ale je to zatracene tezky ukol ... pravda, Apple to zkousi. Uvidime, jak to dopadne.
Grafiku do systemu NE. To je naprosto 110% BSOD. To uz radsi prejit z PC (a x86) na architekturu, u ktere nebude syscall tak drahy (taky by pomohlo snizeni ceny prepnuti procesu). Krome toho nemyslim, ze by zrovna tento bod tak zpomaloval. (Neco jineho je napr. podpora AGP v systemu.)
Komunikace s hardware by predevsim mela jit pres moderni rozhranni na principu OpenGL. Pouzivat neakcelerovany desktop s dnesnimi kartami je plytvani vykonem CPU. Jenze to by se HW firmy museli rozhoupat a zverejnit poradne specifikace ... -
peto (neregistrovaný)Absolutne nechapem co sa ti zda na syscalle drahe? Ved na to mas v novych procesoroch specialnu instrukciu ktoru vymysleli na to, aby nebol drahy. Task switch je urcite drahsi.
Ja mam napr. teraz problem v tom, ze sa neda namapovat len kusok pamate a to este s medzerami (okno). Pri pouziti priameho pristupu je napr. na mojom PC rozdiel vo vykone takmer o 25% a to maju Xka este moznost pouzit bitblit a podobne HW akcelerovane funkcie (to ma snad kazda karta...). -
co sa ti zda na syscalle drahe? Nahrani segmentovych registru :-). Ale je pravda, ze instrukce syscall a sysenter jsou superoptimalizovane a maji na to nejaky podraz ...
Namapovat kousek pameti jde, pokud je jeho velikost zaokrouhlena na 4KB :-). Fakt, ze nemuzes namapovat okno je vlastnost hardware (rika se ji nepritomnost akcelerace, respektive neexistence mapovani okna na texturu v graficke pameti) a tim ze vlepis GUI do OS ji opravdu neodstranis.
Ano, kazda dnesni karta je dneska ma ... ale bohuzel u poloviny to X server neumi vyuzit, protoze na to nema ovladac, a u druhe to nepouziva pro standartni funkce, protoze akcelerace je rozsireni a neni pouzivana automaticky. Nicmene, jsou akcelerovane windowmanagery (minimalne experimentalni) ktere prehazuji standartni okenni operace na funkce OpenGL, coz resi druhy problem. -
peto (neregistrovaný)No jasne ze maju na syscall nejaky podraz :-), aj ked casy ked som cital intel's developer optimization guide, ci ako sa to volalo su pri rychlosti chrlenia novych procesorov nenavratne prec a asi sa nielen ja budem musiet spolahnut na kompilator :-( .
Co sa tyka akceleracie, momentalne riesim problem, ako sa da z X servera vytiahnut ktore funkcie su HW akcelerove a ktore nie. Nevie to niekto? Co som zistoval, tak moja karta (trident v notebooku) by akcelerovana mala byt, ale asi vykonnostne bude nic moc.
Co sa tyka OpenGL, aj keby sa nanho preslo (nielen v rovine windomanagerov), asi by sa muselo nejaky cas ostat pri niecom ako je teraz X server. Dnesne "konzumne" OpenGL karty maju hrozne pomaly state switch (alebo ako sa to nazyva), pretoze su optimalizovane na hry, co je 1 OpenGL aplikacia beziaca sucasne. Toto sa da v GUI napodobnit jedine tak, ze bude bezat naraz 1 aplikacia pouzivajuca OpenGL sucasne, co je prirodzene server. Prinos by bol jedine akceleracii vsetkeho mozneho hardwarom. Ale stale je tu ten task switch. Ako dlho vlastne trva pri idealnych podmienkach (X server sa nascheduluje hned po aplikacii ktora kreslila)? A kolko trva syscall? Btw. to len ja mam tu skusenost, ze ked zamrzne X server, tak pomoze len reset? Z tohto pohladu je vyhoda mat X server ako samostatny proces o nicom. -
Jojo, koukal jsem se do manualu k amd64 a nic o timingu tam nebylo ...
Myslim ze X-Video Extension a OpenGL ... mozna i par dalsich, ale ty zakladni funkce asi ne.
Jinak ... jses si jisty, ze mas akcelerovany ovladac ?
nejen v rovine windowmanagerov - jde o to, ze windowmanager je ve specificke pozici, ktera mu umoznuje "vnutit" tu akceleraci vsem oknum. Pravda, je to uroven indirekce (a task switch) navic ... ale je bezpecnejsi testovat to ve windowmanageru nez v Xserveru.
Nemam poneti ... ale myslim, ze v idealnim pripade by to nemel byt problem. Tak me napada, mozna by se stejneho efektu na rychlost jako narvanim Xek do kernelu dalo dosahnout nejakym vylepsenim scheduleru ...
Jses si jisty ze zamrzne ? Obvykle kdyz spadne X-server, tak prestane fungovat klavesnice a obrazovka, coz vypada pro uzivatele napadne podobne, ale na stroj se lze stale dostat pres sit a nekdy i obnovit funkcnost bez restartu.
Na druhou stranu, pri pouzivani binarnich akcelerovanych ovladacu muze dojit i na tvrdy zasek. -
peto (neregistrovaný)No s tou akceleraciou, prave preto som chcel vediet, ako sa da zistit, ktore funkcie su akcelerovane (napr. rectfill a bitblit by mi stacil). Experimentujem teraz trochu z rychlostou X servera a potrebujem vediet, co vlastne testujem. Ci rychlost procesora alebo graf. karty. Ale zatial som zistil jednu vec: pri pouziti std. volani xlib a zavolani Sync to ide uplne paradne, az ked sa pouziju zazraky typu QT a GTK, tak to posobi pomaly (upozornujem, ze netestujem na A64 3800...). Inak ma medzitym napadlo, ako testovat latenciu, len nemam dost rychlu kameru :-). To vylepsenie scheduleru - co ja viem, podla mna by mal byt vseobecny.
K zamrzaniu - vzdy mam po ruke dalsi pocitac, aby som sa mohol pripojit cez telnet a nejako to vyriesit, nie? :-) S pohladu pouzivatela je to jedno, ci ide jadro alebo nie, proste pocitac sa dalej neda ovladat. Jadro windowsov tiez skoro nikdy nezamrza (aspon v w2k+), len system prestane reagovat :-) Proste na desktope je to jedno.
A aby som nieco pridal aj k clanku: ja pouzivam KDEcko aj s kwin a nemozem sa stazovat na pomalost kwin, jedine na to, ze kym sa to cele nakopne, uplynie peknych par minut (no dobre, menej ako jedna :-) ), ked pustim fluxbox alebo hocaky iny wm, nie je to ani lepsie ani horsie, vlaste, je to horsie, niektore veci ine wm nepodporuju a potom mam napr. desktop v okne... -
No pokud myslis funkce GTK nebo QT, tak ty akcelerovany nejsou (resp. tusim glut je GTK varianta OpenGL, ale normalni GTK akcelerovane neni a navic je zpomalovane tim ze je objektove)
Telnet je dneska zastaraly, ja kdyz mi zamrzne pocitac normalne nabootuju druhy nebo treti a pouziju ssh. Alternativne muzes mit v jadre zapnute magic sysrq, pak staci alt-sysrq-R na odblokovani klavesnice, prepnout (poslepu) na volny terminal, prihlasit se a (stale poslepu) pustit SVGATextMode nebo druha Xka, proste neco co znova zinicializuje obrazovku.
IMHO je velka chyba, ze vyvoj SVGATextMode skoncil ... a to jen proto, ze autor zacal pouzivat framebuffer.
Ja pouzivam fvwm2 s win95 lookem a nestezuju si ani na funkcnost, ani na rychlost, a to ani na beznych pocitacich, ani na AMD64 3000. Akorat firefox nebo acroread chvili trva nez nastartuje. -
ee, glut nemá s GTK absolutně nic společného. Jedná se o nadstavbu OpenGL, která přidává funkce na vytváření oken a práci s nimi (především). V podstatě poskytuje to samé, co SDL, Allegro, WinAPI atd...
Jinak OOP aplikace vůbec nezpomaluje, je to jenom styl programování, kterej se přeloží do úplně stejných nul a jedniček. To co zpomaluje především je návrh a implementace ;))) -
Pochopitelne samotne pouziti OOP jazyka aplikace nezpomaluje. Krome toho, GTK je napsane v C. Na druhou stranu, prilis obecne pouziti objektovych principu aplikaci zpomali. Napriklad pokud je v oknu aplikace 40 objektu (a to neni nijak mnoho), kazdy ma prumerne 5 predku (dtto) a vykreslovani se provadi tak, ze se zavola u kazdeho objeku jeho vykreslovaci funkce a v te se zavola vykreslovaci funkce predka, tak to znamena ze se vola 200 funkci. A bohuzel, vykreslovani napriklad v GTK je jeste slozitejsi, protoze se prepocitava poloha vsech prvku v okne.
Jasne, diky tehle objektovosti se to mnohem snaze programuje, ale opravdu to pak JE pomalejsi dokonce i v pripade, ze by to bylo jinak napsane efektivne, coz v pripade GTK neni.
O QT se vyjadrovat nebudu, nebot jsem s nim nic nedelal, ale IMHO to bude stejne ...
SDL ma 2D akceleraci. Glut je akcelerovany cely. Allegro je snad na zvuk, nebo ne ? WinAPI bude pod linuxem strasne pomale a zcela urcite bez akcelerace. Jaka cast (if any) GTK je akcelerovana nevis ?
