Alacritty 0.3.0 (diskuse)

[Dvorak]

Ty jo, tak dnes už musí být i emulátor terminálu GPU akcelerovaný...

[cezz]

Musi alebo moze?

[_]

Zaplat panbu za kazdou akcelerovanou aplikaci, v soucasne ere javovych, electronovych a dalsich decelerovanych mrd*k.

[Harvie.CZ]

Snad si nemyslis, ze by ji museli akcelerovat, kdyby ji predtim nevodcelerovali

[Harvie.CZ]

Every day we stray further from god...

[Roman]

Je tam uz integrovany i Doom jako built-in? Kolik GB ma release?

[k3dAR]

Ja vidim 1.5MB deb...
Jinak neni treba mit blke kecy kdyz tomu nerozumis, sice $title nepouzivam, ale logicky, beznej terminal pri zpracovani programu/skriptu vypisujici do terminalu vystup tim muze byt brzden (staci si porovnat "time program" a "time program >/dev/null") v zavislosti da dalsich okolnostech to muze (pri nekoho) byt problem a tak uvita gpu akceleraci pro text vystup...

[Roman]

pri tom ficaku textoveho vypisu to nema sanci mozek zaznamenavat uz ani u klasickeho terminalu. Skoda jen, ze autor nezalozil startup a neziskal aspon par desitek $milionu :)

[BFU]

Ja tomu, jako BFU, asi taky nerozumim. Mohl by jsi mi prosim vysvetlit, jak to GPU to renderovani textu zrychli ?

Vzdycky jsem si tak nejak myslel, ze kdyz chci pomoci 3D GPU vyrenderovat nejaky text, tak to funguje zhruba takto:

- Jednou si udelam texturu A, do ni predrenderuju znaky co budu pouzivat (aby to melo GPU v RAM, uploadovat znaky pokazde by trvalo dlouho)

- Jednou si udelam texturu B, do ktere budu renderovat vysledek (taky v GPU RAM, a mozna/asi k dispozici pro scanout engine)

- Jakmile prijde nejaky string, CPU prepise znaky ve stringu na pozice znaku v texture A

- Pozice znaku se nasypou do nejakyho shader programu na tom GPU a necha se to vyrenderovat do textury B

- Textura B se blitne na obrazovku, bud scanout enginem primo na GPU nebo se downloadne z GPU a dale se s ni pracuje

Takze to vypada, ze 3D GPU bude mit vetsi latenci, protoze ten terminalovy emulator musi pripravit data pro GPU ve vhodnem formatu. Vyhodne to nejspise bude pouze pri nejakych vetsich davkach stringu a/nebo scrollovani, kdy se da pohybovat s celou texturou.

Kdyz Xlibove aplikace renderujou nejaky text, tak se vetsinou (*) pouziva hloupe memcpy(3) z nejakych predrenderovanych fontu, coz sice zatezuje CPU taky, ale muze mit mensi latenci. Pri scrollovani se daj memcpy(3)ovat cele radky taky, coz CPU s cachema docela umi.

Nakonec ten benefit GPU akcelerace vs. hloupe memcpy() asi hodne zalezi na tom, jestli uzivatel terminalem proleva obrovske mnozstvi textu nebo pouziva napr. nejaky interaktivni textovy nastroj. Nebo jsem prehlednul neco zjevneho ?

(*) popr. G2D, coz je vetsinou hodne specificke.

[cezz]

Myslim, ze ludia sa prilis sustreduju na cool features ako GPU akceleracia, ale ta "magia" v skutocnosti lezi inde. Vacsina rychlosti Alacritty nie je v GPU, ale v sposobe ako parsuje text a ako vyuziva zero cost abstraction ktoru Rust prinasa.

Co som pozeral, tak GPU je skor taka ceresnicka na torte, pretoze je relativne jednoduche to spravit. Ale aj to prinasa nejake tie benefity - ako napriklad ze nemusia riesit ciastocny upgrade obrazovky, lebo na GPU je rychlejsie proste vykreslit vsetko. Cize neriesis v CPU to co GPU aj tak vie robit efektivnejsie.

Nejake detaily su v dva roky starom blogu, ak ta to zaujima.

Vseobecne si nemyslim, ze pre koncoveho pouzivatela na modernom PC je toto zrovna aplikacia ktora kriticky potrebuje maximalny vykon, ale paci sa mi ze sa vyvija aplikacia s poziadavkou na vykon a ze benchmarking je jeden z testov v ramci release pipeline.

[xkucf03]

Pokud je to baví, tak nic proti :-) Ale mě osobně to přijde jako optimalizace na nepravém místě, zbytečnost. Větší efekt by mělo investovat ten čas to optimalizace GTK, Qt, Swingu atd. U terminálových aplikací jsem nikdy neměl problém s výkonem. Pokud jde o příliš velké množství vypisovaného textu, tak to je chybné použití – člověk to stejně nestíhá číst, takže není důvod to posílat na terminál – takové výpisy si nasměruji do souboru nebo do /dev/null. Případně jsou textové aplikace někdy pomalé kvůli extrémně pomalé a nespolehlivé síti, ale s tím lepší emulátor terminálu taky nepomůže.

[luky]

Problem muze byt v generickem nastroji - napriklad buildovaci nastroj bitbake vypisuje pri buildu jednotlive kroky, coz je zbytecne pro balicky o jednom souboru, ale pro velke balicky to poskytuje uzivateli hodnotnou zpetnou vazbu.

Dale se rychly terminal muze hodit pri sledovani porna pres ASCII Art vystup. Zkuste telnet pornhub.com

[BFU]

On ten vystup z bitbake se neaktualizuje zas tak casto. Spise naopak, CPU musi krmit GPU tim, co ma GPU renderovat a bitbake je doslova navrzeny tak, aby to CPU vytizil co nejvic, takze vysledek bude takovy, ze GPU bude starvovat.

[cezz]

Ono pri klasickom vypise textu to asi veru moc zmysel nema. (Okrem teda pripadov kedy omylom spravis cat velkysubor a ono ti to potom na minutu vytazi CPU na 100% lebo to nechces zabit)

Ale v pripade nejakeho GUI uz to je dost poznat. Ani nie tak na prvy pohlad ako skor ked clovek s tym funguje nejaku dobu a zrazu prepne na nejaky pomaly terminal..

Ono vseobecne to je taky hobby projekt a asi aj dovod preco to niekto robi je ze je jednoduchsie optimalozovat terminal emulator ako nieco ine, ale alacritty pouziva niekolko zaujimavych externych projektov, ktore sa pouzivaju aj tam kde na vykone skutocne zalezi, cize ak pomozu vylepsit nieco v upstreame (rust crates su vsetky pochopitelne v dost rannom stadiu) tak to casom prebuble aj do projektov kde na vykone skutocne zalezi.

Plus, uprimne, ak niekedy potrebujes pouzivat Windows, toto je jeden z najlepsich terminal emulatorov pre platformu, vsetko ostatne co som skusal je bud priserne pomale alebo ma problem renderovat cokolvek zlozitejsie korektne, alebo oboje naraz..

[BFU]

Pokud je tvuj terminal pomaly, tak je chyba mozna nekde jinde. V prvni rade, co znamena pomaly ? Ze ma velkou latenci pri vstupu / vystupu ? Zkus k tomu pripojit perf(1) a nahrat si trace te pomalosti. Pak to muzes pomoci perf-report(1) analyzovat a zjistit, co je skutecne za problem.

Windows jsem uz dlouho nepouzival, ale hodi se vedet, ze to tam funguje.

[cezz]

Ja to tak nejak nemam chut riesit v praxi, preco je iny terminal pomaly, ked proste mozem pouzit nieco rychlejsie.

[BFU]

Ale kdyz prerenderujes pomoci GPU uplne vsechno, tak kopirujes obrovske mnozstvi pameti a navic je to energeticky neefektivni, coz BFUzivatel notebooku nema rad.

[k3dAR]

BFUzivatel nepotrebuje superrychlej terminal

[cezz]

Pokial to spravne chapem, tak len aktualizujes obsah obrazovky (v podstate "text") a nechas GPU aby to zrenderovalo, cize kopirujes minimum. Plus kopirovat taky blok pamati bude jednoduchsie ako riesit logiku co renderovat a co nie.

Ale neviem, GPU sa moc nerozumiem, mne skor pridu zaujimave tie optimalizacie v parsovani.

[BFU]

Obsah obrazovky je blok pameti v nejakem formatu, ktery ti scanout engine cte z pameti a posila na obrazovku. Ten blok pameti je vetsinou textura, do ktere GPU renderuje. Scanout engine a GPU muzou byt dva ruzne bloky (treba kdyz mas nejaky notebook s i915 a diskretni nvidii ; nebo nejaky embedded system s mem2mem GPU a uplne jinym scanout enginem), coz je asi pro uzivatele ta horsi varianta, protoze mu to ubira propustnost pameti. Kdyz budu uvazovat, ze CPU a GPU a scanout engine sdili jednu DRAM a ze mam 1920x1080x32bpp display a 60 Hz refresh, tak z pameti scanout engine precte 1920*1080*(32/8)*60 Byte/s , coz je ~500 MiB/s .

Ale aby byl ten obsah pro scanout engine k dispozici, tak ho GPU musi nejdriv vyrenderovat. A tady je problem, to GPU nema tolik cachi a texturovacich jednotek, aby si v sobe udrzelo uplne vsechno co potrebuje, aby seskladalo tu scenu -- obsah obrazovky. Takze to GPU musi ty ruzne male textury (ruzne hezke buttonky a labely a vsechno mozne) nejdrive nasamplovat z DRAM. Obcas je potreba si nejaky docasny vysledek, treba jedno cele okno, zapsat do DRAM. A nakonec je potreba to cele zase vsechno znova nacist z DRAM a vyrobit tu vyslednou texturu -- obsah obrazovky.

Samozrejme, ne vsechny okna potrebujou 60fps update, takze tam se proste vezme predchozi textura celeho okna. Proto se taky spatne pocita, kolik to GPU skutecne spotrebuje celkove propustnosti pameti. Nicmene pokud uvazuju, ze mam fullscreen terminal a pres nej mi scrolluje nahodny text, tak to GPU bude musel nasamplovat nejake ty fonty (male cteni z DRAM) a zapsat do DRAM novy obsah obrazovky, coz je nejakych 500 MiB/s. Ten vysledek se pak postoupi scanout enginu, ktery to zobrazi.

Nakonec zalezi na tom, jestli tech >500 MiB/s read a 500 MiB/s write zpusobi BFUzivateli nejake komplikace. Podle toho co ma za DRAM to muze ublizovat docela dost, detaily viz Drepper cpumemory.pdf kapitola 2.2 .

[xkucf03]

Nemůžu si pomoct, ale přijde mi poněkud úsměvné :-) tohle všechno dělat kvůli terminálovým aplikacím, které normálně běhají i na sériové konsoli s rychlostí třeba 9 600 bitů za vteřinu.

Také jsem si vzpomněl na Jurský park z roku 1993 a slavnou scénu „Tohle je Unix systém, tohle znám. Odtud se dá ovládat celej park.“ – kde už tehdy měli 3D správce souborů, takže to malá Lex nemusela klovat do textového okna. Na druhou stranu v Matrixu by ten akcelerovaný terminál asi užili – na sledování těch nekonečných zelených výpisů.

[BFU]

Povazujes SLIP za terminalovou aplikaci? Pokud jo, tak tech 9600 Bdps zacne byt docela opruz

fsn a eaglemode jsou oba super.

[cezz]

Ono nie kazdy je limitovany tymi 9600bps, niektori pouzivaju terminal lokalne alebo vyuzivaju nieco ine ako modem.

Plus ak terminal vykresli obsah za 4ms a zvysok casu moze CPU robit nieco rozumne, tak preco to neurobit?

[k3dAR]

tolik teorie a ted praxe i7+IntelHD3000(+SSD): "ls -R /"

4s - >/dev/null
15.5s - alacritty
19.6s - xfce4-terminal (kompozitor on)

[666]

+1

tak snad to zavre hubu tem uplakankum a bojovnikum za ucelne vynalozenou energii v diskuzi

[BFU]

Zajistil jsi, ze mas vzdy stejne podminky mereni a mereni nekolikrat opakoval, aby jsi mel jistotu, ze jsi do nej nezatahl chyby ?

Uz jenom ls -R do mereni zanasi ruzne nedeterministicke prostroje zpusobene pristupem na FS. Zkus tim protocit nejaky blok textu, co mas nacachovany v tmpfs (RAM), mozna tomu terminalu dat maximalni prioritu scheduleru a pripichnout ho na jedine CPU. To by mohlo zacit davat nejake pouzitelne vysledky.

[xkucf03]

Vytvořil jsem si textový soubor obsahující 10 MB náhodných dat (/dev/urandom + base64). Poslat tenhle soubor do /dev/null trvá cca 8 ms. Vypsat ho v Konsoli (KDE 5.44.0) trvá cca 1 vteřinu. Tzn. propustnost řádově 80 Mbps.

Schválně zkuste někdo porovnat různé terminály včetně toho Alacritty. Ale mně i ten výkon Konsole přijde dostatečný.

P.S. A to jsem to pouštěl na CPU z roku 2012 :-)

[k3dAR]

dd if=/dev/urandom bs=1M count=10 | base64 >/dev/shm/test.b64

a "cat /dev/shm/test.b64" (vsechny terminaly vyska 61znaku)

0.009 - >/dev/null
0.460 - Alacritty 0.3.0
2.170 - xfce4-terminal 0.8.7.4
7.700 - xterm 330 

testy sem 10x provadel na stejnem stroji(T420s s i7-2640M, Xubuntu 18.04.2+HWE), napreskacku, v "nulove" zatezi...

[k3dAR]

$ ls /dev/shm/test.b64
-rw-rw-r-- 1 k3dar k3dar 14164977 dub 11 21:04 /dev/shm/test.b64

[BFU]

Nice

[xkucf03]

Zkusil jsem ještě xfce4-terminal – to bylo cca o 20 % horší než Konsole. Zajímavý byl xterm – když bylo okno roztažené na tři čtvrtiny šířky obrazovky nebo méně, tak to trvalo cca 3,3 vteřiny, ale když jsem okno roztáhl na celou šířku obrazovky (2560×1080), tak to bylo najednou 25 vteřin.

[cezz]

Tak nejak mam pocit ze popisujes problem iGPU a zdielanej RAM, co je ale problem bez ohladu na to ci renderujes terminal softwarovo alebo nie.

Jediny rozdiel vidim v tom, ze v pripade alacritty musis v GPU pamati drzat atlas texture s renderovanymi znakmi, ale to uz dnes absolutne nie je problem aj na iGPU.

Ale mozno sa mylim, ja viem o GPU v podstate nic. V praxi je alacritty rychlejsie a to je jedine co ma zaujima.