Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!

Ogłoszenie

Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundację Dzieciom „Zdążyć z Pomocą”.
Więcej informacji na dug.net.pl/pomagamy/.

#1 2017-09-04 20:26:26

admetus
Użytkownik
Zarejestrowany: 2014-07-09

Chrome w Chrome

Taka ciekawostka.
https://drive.google.com/file/d/0BwO8xuhb9OwrV1ZzT3 … w?usp=sharing

Dzięki JScriptowemu Qemu (F. Bellarda) obecnie są możliwe takie śmiesznostki. Oczywiście niezwykły jest rozwój JS-a w przeglądarkach. Niezaprzeczalnym liderem jest V8 Googla. Udostępniona wersja jscriptowa jest zaledwie wolniejsza od jegoż wersji w C o 37-42% (konkretnie ta wersja https://bellard.org/riscvemu/).

Maszyna host, to zaledwie CoreDuo 1.73GHz z 2006 roku. Pod x86 w emulatorze osiąga zaledwie 22-23MIPS (coś w okolicy 486 50MHz, w RISC-V - 33. Mowa oczywiście o Chrome, Firefox jest znacząco wolniejszy (~33%), webkit - szkoda czasu na uruchamianie.

Linux w emulatorze to 4.12, userspace zbuowany w oparciu o uClibc. Chrome uruchomiony z chroota. Żadna nowsza wersja od 31 raczej nie zadziała. Emulowany procesor wspiera jedynie cmov (i686), brak mmx, sse o sse2 nie mówiąc. Sam start przeglądarki, powiedziałbym błyskawiczny, coś zaledwie z 30 sekund. Wielkość chroot-a to 100MB z kompresją zlib. Gwoli wyjaśnienia, host laptop ma zaledwie 1GB RAM. Pod spodem ArchLinux (x86_64). Po włączeniu nagrywania pulpitu (ffmpeg), Chrome w emulatorze mocno zwolnił. W rzeczywistości działał o niebo lepiej.

Dużo oszczędniejszą w emulacji jest archtektura RISC-V 32-bit, a przeto znacząco szybsza w przeglądarce. Kilka skompilowanych pod nią aplikacji.
-minigzip https://drive.google.com/file/d/0BwO8xuhb9OwramNXaG … w?usp=sharing
Instalacja:
gzip -dc minigzip.riscv32.gz | tar xf - -C /

-tar https://drive.google.com/file/d/0BwO8xuhb9OwrWk9OcW … w?usp=sharing
minigzip -d -c tar-1.29.riscv32.tar.gz | tar xf - -C /

-Python 2.7.13 https://drive.google.com/file/d/0BwO8xuhb9OwrNTJlb2 … w?usp=sharing
minigzip -d -c python-2.7.13.riscv32.tar.gz | tar xf - -C /

-Tcl/Tk 8.6.7 https://drive.google.com/file/d/0BwO8xuhb9Owrc1dtNF … w?usp=sharing
https://drive.google.com/file/d/0BwO8xuhb9OwrS2ZFS0 … w?usp=sharing

-Dosbox https://drive.google.com/file/d/0BwO8xuhb9OwrZndQTW … w?usp=sharing
-Bash https://drive.google.com/file/d/0BwO8xuhb9OwrT1NyMX … w?usp=sharing
-Urxvt https://drive.google.com/file/d/0BwO8xuhb9OwrM1Y3LW … w?usp=sharing
-Xbord/Stockfish (Cfish) https://drive.google.com/open?id=0BwO8xuhb9OwrVU44TGhja3ZtVzA
uruchamianie: xboard -fUCI
-Perl 5.24.2 https://drive.google.com/file/d/0BwO8xuhb9OwrelZZMl … w?usp=sharing
-mawk https://drive.google.com/file/d/0BwO8xuhb9OwrdHpTOH … w?usp=sharing
-sed https://drive.google.com/file/d/0BwO8xuhb9OwrMzBSSD … w?usp=sharing

Benchmark pystone.py (riscv) na moim nieboraku:
This machine benchmarks at 674.695 pystones/second
Dla porównania na realnym - Amd K6-2 300MHz, to 5800.

Do pomiaru prędkości oraz wiarygodnej długości wykonywania należy posługiwać się wyłącznie wbudowanym 'vmtime' a nie 'time'.
vmtime sleep 5

Ostatnio edytowany przez admetus (2017-09-05 12:32:56)

Offline

 

#2 2017-09-06 16:17:40

admetus
Użytkownik
Zarejestrowany: 2014-07-09

Re: Chrome w Chrome

W najnowszym stabilnym wydaniu Chrome - 61.0.3163.79, pojawiła się wprost niewiarygodna regresja, JSLinux działa około 3x wolniej niż w poprzedniej stabilnej edycji. To co wcześniej zajmowało 30s obecnie zabiera 90. Zdecydowanie nie polecam tej wersji do tego zastosowania. W becie jest wszystko OK, spisuje się idealnie. Nomen omen dokładnie ten sam numer wydania, 61.0.3163.79.
Do diaska, na czym oni to testują? Na facebookowym chłamie? Rozumiem 2%-5%, dobra działa wolniej w wydaniu developerskim, becie, coś tam testujemy. Litości! 300%. Przeoczyć taki babol w stabilnym wydaniu. Może ja czegoś nie wiem, coś się zmieniło w domyślnych flagach lub trzeba cóś innego przestawić. Sprawdziłem na czyściutkim profilu - jest niestety tak samo źle. Nie wiem, trzeba to dokładniej zbadać.

Nowy, świeżutki pakiecik GNU Coreutils 8.28, częściowo zastępujący ułomne, mało funkcjonalne i w przeważającej większości wolniejsze Busyboxowe "perełki" (zostaje jeszcze util-linux do podmiany). Na dokładkę GNU grep, również od kilku do kilkunastu (pewnie i więcej, przy bardziej skomplikowanych regexpach) razy szybszy. Także GNU diffutils. Z Busybox-a tylko shell ash jest wart pozostawienia, nie odbiega niczym od dash-a, ale i tak na interaktywną powłokę polecam mksh. Oj! Budując coreutils w pośpiechu przeoczyłem dodać wsparcie ze strony openssl-a (--with-openssl), tak więc wszystkie md5sum, sha1sum, itd. są dużo wolniejsze niż mogłyby być. Te binarki nie są w żaden szczególny sposób przetestowane. Możliwość istnienia bugów, w tym krytycznych jest prawdopodobna. Są budowane ot tak, jedne lepiej drugie gorzej.

coreutils 8.28 https://drive.google.com/file/d/0BwO8xuhb9OwrZ1BLT1 … w?usp=sharing
diffutils 3.6 https://drive.google.com/file/d/0BwO8xuhb9OwrMmM0R2 … w?usp=sharing
grep 3.1 https://drive.google.com/file/d/0BwO8xuhb9OwrR0NJNn … w?usp=sharing
mksh R56 https://drive.google.com/file/d/0BwO8xuhb9OwrblJueG … w?usp=sharing

EDIT:
Sprawa z chrome się wyjaśniła, winę za spadek wydajności JSlinuxa ponosi ta zmiana.
https://chromium.googlesource.com/chromium/src/+/af … 52b%5E%21/#F0

Wystarczy w chrome://flags/#enable-asm-webassembly ustawić na 'disabled' i wszystko gra i buczy jak poprzednio.
Ewentualnie z linii poleceń dodać przy wywoływaniu chrome, --no-validate-asm lub --disable-features=validate-asm

coreutils 8.28 (inny build) https://drive.google.com/file/d/0BwO8xuhb9OwrSzh3UG … w?usp=sharing
curl 7.55.1 (static) https://drive.google.com/file/d/0BwO8xuhb9OwrNlZ5dW … w?usp=sharing
sqlite 3.20.1 (static) https://drive.google.com/file/d/0BwO8xuhb9OwrZEVNb0 … w?usp=sharing

Ostatnio edytowany przez admetus (2017-09-07 14:48:16)

Offline

 

#3 2017-09-08 11:56:02

admetus
Użytkownik
Zarejestrowany: 2014-07-09

Re: Chrome w Chrome

Da się w coś na riscv32 zagrać? https://bellard.org/jslinux  W dosowy Cybron Grand Slam Bridge :)
Emulator w emulatorze. To zawsze będzie porażka pod względem wydajności. Dosbox działa w okolicy AT 12MHz - 386SX-33 i to w trybie tekstowym. ZX Spectrum da radę. Zdecydowanie najszybszy emulator zx, to
spectemu 0.99.3 https://drive.google.com/open?id=0BwO8xuhb9OwrSHI3ZGxzUk5mOUk
i już można uruchamiać Tappera, Knight Lore, czy inne hity.
W co jeszcze da się pograć. Na przykład w całą masę gier pod Tcl/Tk (wish), karcianych :)- pasjanse, Hearts, itd. http://wiki.tcl.tk/13404
Stone Soup w wersji tekstowej może być nie do uciągnięcia. Z resztą wersja online jest od dawna dostępna. Podobie jak i archive udostępnia dostęp do dosowych klasyków. Z spectrumem pewnie jest tak samo. Nie w tym rzecz.

RISC-V, to nowa architektura, nie wszystko da się pod nią zbudować (szczególnie to wszystko co wymaga specjalnych procedur w assemblerze). Inna trudność to że z bibliotek podstawowych C, oficjalnie tylko glibc ją wspiera. Ten toolchain oparty jest o uClibc (ng), czasem może to powodować dodatkowe perturbacje. Nie udało mi się zbudować numpy, choć to jakiś drobiazg i dla speca pewnie z minuta kłopotu, ja straciłem cały dzień i się poddałem. Łatki od (z) Buildroota pod starą wersję uClibc nie mają tu zastosowania. Jeśli coś jeszcze nie ma oficjalnego wsparcia pod nią (architekturę), warto się rozejrzeć bo może już być takowe nieoficjalne. Tak jak choćby w przypadku OCaml.
https://github.com/nojb/riscv-ocaml
Z ciekawości spróbowałem zbudować. Pierwsza próba, porażka. Dymyślnie aplikuje symbole debugujące. Wychodzi z tego ponad 200MB do instalacji, większy niż cały root filesystem. Jak to wyłączyć? W PLD są łatki, usuwające. Niestety druga próba nic nie zmieniła.Sam ocaml działa, niestety uruchomienie ocamlopt, czyli kompilatora ocaml do kodu natywnego kończy się "Segmentation fault".

Programować zupełnie nie umiem, moje ulubione zajęcie to "benchmarkowanie". http://benchmarksgame.alioth.debian.org/u64q/ocaml.html
C - gcc-7.1.1
gcc -std=c99 -O2 -fprofile-arcs -o fannkuch.c.run fannkuch.c -lgcov
./fannkuch.c.run 5
gcc -std=c99 -O2 -fprofile-use -o fannkuch.c.run fannkuch.c
vmtime ./fannkuch.c.run 8
Real time: 0.248 s

Python 2.7.13
vmtime python2.7 fannkuch.py 8
Real time: 17.299 s

Perl 5.24.2
vmtime perl fannkuch.pl 8
Real time: 21.951 s

Lua 5.3.3
vmtime lua fannkuch.lua 8
Real time: 8.643 s
Dobra, C nie ma sensu porównywać z perlem, pythonem, lua. Wiem że pod risc-v działa java, golang (choć nie sprawdzałem czy ze wsparciem pod 32-bit, gcc-go raczej na pewno by działał).

Kompresja danych. Niezwykle istotny element, mający ogromny wpływ na ogólną wydajność systemu. Szczególnie taka biblioteka jak zlib. Czy tu w emulatorze się sprawdzi coś innego? Lz4 - można by rzec najodpowiedniejszy, zbyt niski stopień upakowania niestety wyklucza go z kompresowania "pakietów". Zstd, może i jest wydajny tam gdzie jest zoptymalizowany (x86_64) pod risc-v sromotnie przegrywa z zlib. Xz - zapotrzebowanie na dużą moc obliczeniową, tylko w przypadku dekompresji znajdzie tu zastosowanie. 3x wolniejszy pod tym względem od zlib (minigzip), to akceptowalne, zważywszy na bardzo wysoki stopień upakowania danych. Bzlib również (mało co tak dobrze kompresuje xml). Lzip nie testowałem, raczej nie wiele będzie odbiegał od xz. Generalnie zlib nie ma tu żadnej dobrej konkurencji.

bzip2 1.0.6 https://drive.google.com/open?id=0BwO8xuhb9OwrNGxyeWRnM0xneDA
xz 5.2.3 https://drive.google.com/file/d/0BwO8xuhb9OwrX0pGUl … w?usp=sharing
zstd 1.3.0 https://drive.google.com/file/d/0BwO8xuhb9OwrT2lEUV … w?usp=sharing

Offline

 

#4 2017-09-10 03:09:53

admetus
Użytkownik
Zarejestrowany: 2014-07-09

Re: Chrome w Chrome

Jak ktoś by się pytał czy pod JSlinuxem działa wine, to tak. W wersji x86, bo pod riscv trzeba by skorzystać dodatkowo z qemu.
https://drive.google.com/file/d/0BwO8xuhb9OwrODJwQm … w?usp=sharing

Spróbowałem odpalić demo Diablo I. Niestety zbyt stara wersja wine 1.4 (celowo z takiej korzystałem) w trybie pulpitu wywalała się z Memory Fault.
w inny jak ten się nie uruchomi (direct draw wymaga takiej rozdzielczości)
wine explorer /desktop=Diablo,640x480 "c:\Program Files\Diablo\diablo.exe"

EDIT:
Wersja riscv32 jest znacznie szybsza, ale nie należy się sugerować czasem trwania uruchamiania systemu. Różnica ta bierze się głównie wyłącznie z wielkości danych jakie musimy pobrać. Root filesystem x86 jest ponad 2,5x większy.  Sam start systemu mógłby być błyskawiczny, jakby / był wielkości 40MB. Oferuje całe mnóstwo preinstalowanych programów i narzędzi.

W tym chociażby Qemu i to ze wsparciem kvm (emulowanego). Jak wcześniej wspomniałem cpu obsługuje cmov oraz svm - rozszerzenie wirtualizacji amd. Czy ten kvm oferuje zbliżoną szybkość do cpu hosta? Nie wiem nie sprawdzałem dokładnie. Wystarczy wrzucić jakiś minimalny obraz freedosa, windows 95, 98, czy innego linuksa.
qemu-system-i386 -enable-kvm  -cpu 486 -m 32M -display fbdev -cdrom dos.img -boot order=d

Wyjście fbdev jest wolne. Sdl nie inicjalizuje się, choć wspiera go (czemu nie mam pojęcia). Ewentualnie, -nographic, -vnc (potrzebny klient). Wyjście z fbdev w razie kłopotów - Ctrl-Alt-2 - konsola qemu i komenda quit.

EDIT2:
Qemu z kvm działa, tak jakby tego kvm tam nie było (znaczy się jest emulowany). Próba uruchomienie Tiny Core Linuxa po 10 minutach została przerwana. Trwałoby to znacznie dłużej niż bootowanie win95 na apple watch (trwało to około 1h). Uruchamiałem na amd k6-2 300 pod qemu minimalistyczną wersję archlinuxa (x86_64) w wersji graficznej, zajmowało to jedynie ~17 minut.

Ostatnio edytowany przez admetus (2017-09-10 19:31:07)

Offline

 

#5 2017-09-12 00:47:14

admetus
Użytkownik
Zarejestrowany: 2014-07-09

Re: Chrome w Chrome

Chyba najmniej użyteczny program jaki udało mi się skompilować na riscv32 - perf.
https://drive.google.com/file/d/0BwO8xuhb9OwrWDJDQX … w?usp=sharing

Działa: perf help, perf test, perf stat sleep 4, już nie ;), o perf top na razie można pomarzyć.
Namordowałem się 6h żeby to ruszyło pod uclibc, finalna wersja z optymalizacją -O1 (domyślnie -O6).

Niestety po niewczasie dowiedziałem się że riscv jeszcze jego nie wspiera. Druga sprawa że jakby i wspierał to Bellard mógłby choćby i wyłączyć (HAVE_PERF_EVENTS).
https://github.com/riscv/riscv-linux/blob/riscv-4.1 … riscv/Kconfig

Offline

 

#6 2017-09-12 18:53:25

admetus
Użytkownik
Zarejestrowany: 2014-07-09

Re: Chrome w Chrome

Coś bez czego niektórzy nie potrafią funkcjonować w linuksowym terminalu - Midnight Commander - 4.8.14. Uproszczona konfiguracja, bez ncurses wide (domyślne locale jest bez UTF-a) i innych fajerwerków, starsza wersja ze względu na wcześniej skompilowany archaiczny glib-2.16.6 (najnowszy mc-4.8.19 wymaga glib-2.0 >= 2.26, a im on nowszy to bardziej kobylasty). Swoją drogą nie wiem czy nie łamię licencji upubliczniając taką binarkę ze statycznie linkowaną biblioteką glib2 (słabo się na tym znam), jeśli tak, to usunę link, zbuduję z glib-2.0 shared.
https://drive.google.com/file/d/0BwO8xuhb9OwrOUV0dm … w?usp=sharing

Nie to żebym zniechęcał do niego (bo i niby co komu do tego, co kto czego używa), ale umiejętność posługiwania się (przynajmniej w podstawowym zakresie) - ls, cp, mv, rm, chown, chmod, find, xargs, tar, vi, less, more, diff, itd. jest dużo ważniejsza, ba niezbędna. Po za tym operacje przeprowadzane narzędziami "niskiego poziomu" są duuuużo szybsze.
MC pod (z tą) konsolą bez X, ma ogromne kłopoty (głupieje). Najlepiej uruchamiać wyłącznie pod screenem, choć nie wygląda i tu bosko, to działa poprawnie. Dostęp do klawiszy funkcyjnych poprzez ESC i odpowiedni numer.
TERM=screen mc -Xsa

Z tą konsolą nie radzi sobie również tmux, choć działa, to nie może na niej nic wyświetlić. O dziwo wyświetla uruchamiany z pod screen-a, dtach (ale to absurdalne aby go wywoływać w taki sposób).

MC pod xterm-em, rxvt działa i wygląda dobrze. Nic poza dobraniem odpowiedniego wyglądu (może mc46) i własną konfiguracją jest gotowy do użytku po wydaniu komendy w terminalu, po porostu - mc.

Na dokładkę gzip, niestety jest wolniejszy od minigzipa przy dekompresji o blisko 30%.
gzip-1.8 https://drive.google.com/file/d/0BwO8xuhb9OwrOXhCRU … w?usp=sharing
file-5.32 https://drive.google.com/file/d/0BwO8xuhb9OwrTGNlY3 … w?usp=sharing
procps-ng-3.3.12 https://drive.google.com/file/d/0BwO8xuhb9OwrOExOdl … w?usp=sharing
findutils-4.6.0 https://drive.google.com/file/d/0BwO8xuhb9OwrWTNjcH … w?usp=sharing
mpg123-1.25.6 https://drive.google.com/file/d/0BwO8xuhb9OwrTDdVT3 … w?usp=sharing
Do czego? Wyłącznie aby sprawdzić wydajność dekodowania mp3 pod RISC-V.

Ostatnio edytowany przez admetus (2017-09-13 13:49:23)

Offline

 

#7 2017-09-14 01:00:44

admetus
Użytkownik
Zarejestrowany: 2014-07-09

Re: Chrome w Chrome

pari-2.9.3 https://drive.google.com/file/d/0BwO8xuhb9OwrTU1SUD … w?usp=sharing
Głównie dedykowany matematykom z krwi i kości. Matematyczne osiołki takie jak ja, mogą ekscytować się obliczaniem przez niego silni z bardzo dużych liczb i cieszyć się widokiem (podanym pełnym wynikiem a nie stosując zapis skrócony) doprawdy ekstremalnie wielkich liczb. Spokojnie można spróbować z 300000 i pod przeglądarką, choć to już może potrwać "chwilę". Nie znam drugiego tak dobrego programu obliczającego silnię tak piekielnie efektywnie przy zużyciu naprawdę minimalnych zasobów. Algorytmów jest kilka.
http://rosettacode.org/wiki/Factorial#PARI.2FGP
Oczywiście potrafi on duuuużo więcej.
http://rosettacode.org/wiki/PARI/GP

shine-3.1.1 https://drive.google.com/file/d/0BwO8xuhb9OwrN19NOG … w?usp=sharing
Najszybszy znany mi enkoder mp3 na świecie. Czy jest w stanie poradzić z kodowaniem w czasie rzeczywistym (1x), tak o ile ktoś dysponuje mocą rzędu 100-110 MIPS w emulatorze (ewentualnie połową tego w przypadku kodowania mono). Czysta wersja JScriptowa (taka oczywiście istnieje) jest o niebo szybsza (narzut samego emulatora jest jednak duży).

Offline

 

#8 2017-09-19 11:11:12

admetus
Użytkownik
Zarejestrowany: 2014-07-09

Re: Chrome w Chrome

Gnumeric online, jako alternatywa dla Google Sheets? Czemu by nie. Wystarczy fantastyczny emulator Bellarda i działający w nim linuks.

Trochę czasochłonnej dłubaniny i urodziły się istotne komponenty w tym Gtk+2 oraz rzeczona aplikacja - gnumeric pod Linuksa w architekturze RISC-V 32bit. Do uruchamiania w JScriptowym emulatorze F. Bellarda. Gnumeric, czyli coś typowo desktopowego. Oczywiście nie z myślą o jego użytkowaniu (kto wie co przyniesie przyszłość) na razie raczej jedynie testowym uruchamianiu. Wszystko kompilowane pod uzyskanie stosunkowo jak najmniejszego kodu wynikowego, choć nie zubożone całkowicie (gdzieś po środku). Moc uzyskiwana pod emulatorem jest jeszcze stanowczo zbyt mała aby duże aplikacje działały wystarczająco znośnie. Tak mogłoby być jeśli uruchamiałoby się pod nim jedynie kod źródłowy z lat 1991-1998 tworzony z zamiarem uruchamiania pod "pentium 30-200MHz", gdy taki sprzęt był w codziennym działaniu. Oczywiście jest duża szansa że w niedługim czasie część będzie mogła działać poza emulatorem (już działają), dzięki Emscripten, WebAssembly lub GNU toolchain for WebAssembly. Choć jednak swoboda pełnego systemu jest wprost nieporównywalna z ograniczeniami jakie one narzucają aplikacjom. Działają interpretery perla, pythona, lua, stockfish, itd.

Jak to uruchomić. Odpalamy emulator.
https://bellard.org/jslinux/vm.html?cpu=riscv32& … amp;graphic=1

Możemy zwiększyć ilość przydzielonej pamięci, rozmiar pulpitu, itd. Wszystko jest wyjaśnione w FAQ. Linuksowi z Gnumeric wystarczy spokojnie 24MB do działania. Linuks to nie Windowś.
Uploadujemy wcześniej pobrane pliki (↑).
jslinux-riscv-addon.1.tar.gz https://drive.google.com/file/d/0BwO8xuhb9OwrZ1pMMU … w?usp=sharing
gnumeric-1.10.15.tar.gz https://drive.google.com/file/d/0BwO8xuhb9OwrYUU1Nm … w?usp=sharing

Uruchamiamy terminal. Rozpakowujemy i instalujemy archiwum.
gzip -dc jslinux-riscv-addon.1.tar.gz | tar xf - -C/
oraz
gzip -dc gnumeric-1.10.15.tar.gz | tar xf - -C/

odpalamy aplikacje
gtkperf 2>/dev/null&
gnumeric 2>/dev/null&

Gnumeric działa bardzo znośnie, powiedziałbym nad oczekiwanie dobrze.
Nie wiem czy ten kernel jest z CONFIG_SHMEM=y, komunikaty nie krytycznych błędów lepiej schować. Nie obsługuje on również tmpfs, `cat /proc/filesystems', więc nic nie pomoże próba samodzielnego podmontowania. Sto iteracji to stanowczo za dużo. Proponuję zmniejszyć. Wydajność podsystemu graficznego jest niestety bardzo, bardzo niska, a to ona ma zdecydowany wpływ na komfort użytkowania aplikacji graficznych.

Jak ktoś ma ochotę zobaczyć i przekonać się jak wyglądał Linuksowy Desktop w 2000 roku, Gimp w wersji 1.0.4, to proponuję pobrać ten obraz iso i uruchomić w dowolnym wirtualnym środowisku.
Demo Linux 2.0 Live CD https://drive.google.com/file/d/0BwO8xuhb9OwrT0laRm … w?usp=sharing

Mała przerwa i będę kompilował dalej pod RISC-V, czas na Gimp 2.8.22, ROX-Filer, GVim, gtk+-engines i wiele innych.

EDIT:
Cała paczka jslinux-riscv-addon.1.tar.gz  zawiera następujące komponenty: atk-2.15.1, cairo-1.14.10, gdk-pixbuf-2.33.1, glib-2.45.2, harfbuzz-1.5.0, libXcomposite-0.4.4, pango-1.36.8, gtk+-2.24.31, gtkperf-0.40, libgsf-1.14.41, libxml2-2.9.4, xz-5.2.3, goffice-0.8.17, libcroco-0.6.12, librsvg-2.40.18, shared-mime-info-1.7, coreutils-8.28, grep-3.1, findutils-4.6.0, procps-ng-3.3.12, tar-1.29, gzip-1.8.

rox-filer-2.11.riscv32.tar.gz https://drive.google.com/file/d/0BwO8xuhb9OwrMnVWQn … w?usp=sharing
ROX-Filer - jeden z najszybszych graficznych najmniej zasobożernych file managerów.
gzip -dc rox-filer-2.11.riscv32.tar.gz | tar xf - -C/
rox 2>/dev/null&

Ostatnio edytowany przez admetus (2017-09-19 15:43:37)

Offline

 

#9 2017-09-20 21:30:51

admetus
Użytkownik
Zarejestrowany: 2014-07-09

Re: Chrome w Chrome

vim-8.0.1127.riscv32.tar.gz https://drive.google.com/file/d/0BwO8xuhb9OwrYi0xQn … w?usp=sharing

Dokładniej to gVIM w wersji huge (a moźe raczej light), ale jedynie z interpreterem Lua + do niego plugin neocomplete.
Generalnie polecam start taki ;)
vim -u NONE --noplugins
gvim -u NONE --noplugins

Nad lżejszą konfiguracją trzeba by popracować, bo obecna jest zbyt ciężka. Robi się to stosunkowo łatwo. Mi się już nie chciało biedzić nad tym. Wystarczy wystartować vim-a w taki sposób:
vim --cmd 'profile start profile.log' --cmd 'profile func *' --cmd 'profile file *' -c 'profdel func *' -c 'profdel file *' -c 'qa!'
i sprawdzić w profile.log co najbardziej zwalnia start.

Co można jeszcze uruchomić - tetrisa. Po naciśnięciu sekwencji ',te'.
Między buforami (plikami) przeskakujemu < > zaś zamykamy ,DEL.

EDIT:
Wymaga również instalacji odpowiednich bibliotek, czyli trzeba też zainstalować plik jslinux-riscv-addon.1.tar.gz.
Obecnie to i vim stał się z lekka ociężały. Wersja 6.8 lub 6.9 z gtk1 na amd k6-2-300 śmigała jak szalona.
Dobrze byłoby gdyby developerzy testowali swój kod na sprzęcie 40x wolniejszym od tego który używają (mają zbyt szybkie).

Wyszperany komentarz w sieci oddaje to idealnie.
"If you want to make a fast program, use a slow computer.
Developers care more about performance if it's slow on their computers too".

Ostatnio edytowany przez admetus (2017-09-21 00:06:32)

Offline

 

#10 2017-09-23 19:58:18

admetus
Użytkownik
Zarejestrowany: 2014-07-09

Re: Chrome w Chrome

Gimp w przeglądarce, dodatkowo pod architekturą riscv32. Nie wersja 1.0 tylko najnowsza stabilna 2.8.22. Głównie do uruchamiania w emulatorze JSLinux. Naprawdę robi to piorunujące wrażenie, polecam uruchomić. Gęba sama się śmieje. Jak go odpalić, tak jak porzednie wymagające biblioteki gtk+2 oraz kilku innych. Pobrać pliki:
gimp-2.8.22 https://drive.google.com/file/d/0BwO8xuhb9OwrejJad2 … w?usp=sharing
jslinux-riscv-addon https://drive.google.com/file/d/0BwO8xuhb9OwrZ1pMMU … w?usp=sharing
W terminalu:
gzip -dc jslinux-riscv-addon.1.tar.gz | tar xf - -C/
i
gzip -dc gimp-2.8.22.riscv32.tar.gz | tar xf - -C/
gimp 2>/dev/null&

Dużo szybsza metoda instalacji, to skorzystanie z minigzip-a i gnu tar-a. Wrzucić do emulatora te pliki: minigzip.riscv32.tar.gz, tar-1.29.riscv32.tar.gz, jslinux-riscv-addon.1.tar.gz, gimp-2.8.22.riscv32.tar.gz oraz plik install o zawartości:
gzip -dc minigzip.riscv32.tar.gz | tar xf - -C/
minigzip -d -c tar-1.29.riscv32.tar.gz | tar xf - -C/
tar xf jslinux-riscv-addon.1.tar.gz -Iminigzip -C/
tar xf gimp-2.8.22.riscv32.tar.gz -Iminigzip -C/
W terminalu pozostaje tylko wklepać:
sh install
gimp 2>/dev/null&

Jak ktoś ma taką potrzebę (ja nie mam), może sobie stworzyć samorozpakowujące się shellowe archiwum (proste zadanie).
https://github.com/megastep/makeself

Można też stworzyć konto pod https://vfsync.org. Wszystkie wrzucone tam pliki będą w katalogu użytkownika stale obecne, zawsze dostępne od razu po zalogowaniu. Uwaga nie dotyczy to plików z /, wyłącznie z katalogu usera. Eksportować nową ścieżkę do binarek i bibliotek.
export PATH="/home/ziut/addon/bin:/home/ziut/addon/usr/bin:$PATH"
export LD_LIBRARY_PATH=/home/ziut/addon/usr/lib
/etc kopiować (z konta root, su -), podobnie postąpić z /usr/share, tam są również bardzo istotne pliki. Czyli albo je kopiować, albo z co zasobiniejszych katalogów tworzyć linki lub bindować (mount). Kwestii bezpieczeństwa takiego rozwiązania zupełnie nie rozpatruję. Praktycznie nie korzystam z tego z uwagi na 1GB RAM-u w laptopie (trzymam tam tylko mały "niezbędnik"). Cała zawartość emulowanego filesystemu gościa oraz używana przez emulator pamięć jest odwzorowana (zamapowana) naturalnie w systemie hosta za pośrednictwem przeglądarki. Im więcej filesystem gościa będzie zużywał miejsca i im więcej będzie zjadał pamięci to i host jednocześnie to odczuje. Jak bym chciał wrzucić to co do tej pory zbudowałem, to byłoby tego dużo za dużo.

Start gimpa jest porażająco wolny, należy zachować cierpliwość (później jest troszkę lepiej). Sam już nie wiem, może coś namieszałem w konfiguracji, wydawało się że pierwszy i drugi start był szybszy. Chrome w przeglądarce startował z osiem razy szybciej. Na moim archaicznym sprzęcie gimp się ślimaczy, ale ktoś może mieć coś dużo nowszego i szybszego, ot coś z 3-4.5GHz, wtedy powinien działać bardziej znośnie (przynajmniej 4-7x szybciej, prawdę mówiąc trudno mi to dokładnie oszacować, ilość rdzeni szczególnego znaczenia nie ma, emulator okupuje jeden). Linux, Gimp z otwartym plikiem jpg, Xorg, fluxbox, xterm zjadają razem coś z około 64MB. Przydzielone standardowe 128 w zupełności powinno wystarczyć.
Jest coś lżejszego od Gimpa? Gimp w wersji 2.4 z jakąś lekką wersją biblioteki gtk+ 2.4, 2.6, 2.8. Czemu w tej wersji. Posiadał już wtedy dość dużo opcji i był szybki. Są naturalnie inne programy jak grafx2, czy mtpaint (ten może działać i z gtk+1). Choć oba przeznaczone do dużo mniej skomplikowanych celów i zadań.

W skład archiwum gimp-2.8.22.riscv32.tar.gz wchodzi: babl-0.1.10, gegl-0.2.0, libwebp-git oraz wtyczka webp do gimpa - gimp-webp-0.1.1.

EDIT:
Zmniejszenie rozmiaru fontu gtk zauważalnie poprawia poruszanie się po wszelkich menu. Wystarczy wyedytować .gtkrc-2.0.
sed -i "s#Liberation Sans 9#Liberation Sans 8#" .gtkrc-2.0
Opcje sposobu renderowania Xft można zmienić w pliku .Xdefaults.
Wyłączyć animacje wszelkich selektorów. Wyłączyć splash (-s). Dużą część przy starcie zabiera script-fu, ale jego już na tym etapie nie da się wyłączyć.
Część pluginów korzystająca z niedostępnego tu shm, będzie działać bardzo wolno.

EDIT2:
Dla równowagi aplikacja super lekka.
sodipodi-0.34.riscv32.tar.gz https://drive.google.com/file/d/0BwO8xuhb9OwreHZWTj … w?usp=sharing
Bazuje na gtk+2, czyli wymaga również jslinux-riscv-addon.1.tar.gz.

Sodipodi jeden z pierwszych programów do grafiki wektorowej (SVG) pod linuksem, interfejsem troszkę przypomina gimpa. Ostatnia jego wersja z 2004 roku. Później nadszedł czas Inkscape, który zaczynał początkowo jako fork sodipodi. Inkscape do najlżejszych nie należy. Ostania jego wersja używalna na komputerowych złomach to 0.46. Choć i przy niej Sodipodi to piórko. Oczywiście nie wszystkie pliki svg już sodipodi otworzy poprawnie, czasem czegoś może brakować coś się nie wyświetlać tak jak powinno. Chyba nawet nie miał zamiaru być zgodny w całości ze specyfikacją svg. Inkscape posiada opcję zapisz w zgodności z sodipodi. Objawia się tu niestety z mało sympatycznym felerem, znacznik na skali bruździ i pozostawi za sobą ślady. W skład sodipodi-0.34.riscv32.tar.gz, wchodzi również libart_lgpl-2.3.21.
Problem brudzącego wskaźnika znajduje się po stronie gtk. W wolnej chwili sprawdzę to na innych motywach.
https://sourceforge.net/p/sodipodi/bugs/88/

EDIT4:
gtk-engines-2.20.2.riscv32.tar.gz https://drive.google.com/file/d/0BwO8xuhb9OwrT3FKT2 … w?usp=sharing
Schemat innej skórki można wskazać przed wywołaniem programu (każdy program może mieć inną), globalnie eksportując zmienną systemową GTK2_RC_FILES lub wskazując bezpośrednio w pliku .gtkrc-2.0.

Nie doszedłem z jakiego powodu w sodipodi na skali znacznik zostawia ślad i akurat w tamtym miejscu używa bitmapowego fontu. Czyżby na skali korzystał ze schematu ikon X-ów?
EDIT5:
Nie znalazłem na ten feler rozwiązania. Dowiedziałem się jak ten bitmapowy font znajduje się w aplikacji Gtk. Otóż za sprawą GdkFont.
https://developer.gnome.org/gdk2/stable/gdk2-Fonts.html
Zbudowałem sodipodi natywnie na x86_64, ale przy uruchamianiu wywalał się komplentie. Ciekawie, działa pod riscv a na amd64 krzaczy. Na tą bolączkę akurat jest łatka.
https://sourceforge.net/p/sodipodi/patches/_discuss … 4-amd64.patch
Pod archlinuxem wskaźnik brudzi tak samo, tyle że robi to znacznie szybciej ;)

Ostatnio edytowany przez admetus (2017-09-25 08:07:50)

Offline

 

#11 2017-09-26 20:06:07

admetus
Użytkownik
Zarejestrowany: 2014-07-09

Re: Chrome w Chrome

Czas na prawdziwie oldskulowego linuksa. Ktoś powie przecież fluxbox też doń się zalicza. Owszem bo ta bellardowa konfiguracja ma na celu oszczędzenie w miarę możliwości każdego taktu i cyklu emulowanego procesora. Z tego powodu brak i tu wygenerowanego locale z UTF-8, itd.
Powrót do aplikacji z końca lat 90 i połowy 2000 roku, kiedy były bardzo, bardzo proste i lekkie oraz całkiem fajne.

vim-7.2.444
Jako że Vim w najnowszej wersji z Gtk+2 stawia zbyt duże wymagania postanowiłem cofnąć się w czasie i zbudować starszą korzystającą z Gtk+1. Czyli poniekąd wrócić do lat 90. Owszem niektórzy krzywią się widząc tak ascetyczny interfejs, czy bitmapowe fonty (gtk+1 mógł korzystać z xft, były łatki, ale to sztukowanie na siłę). Vim 7.2 to ostatnia wersja mogąca działać z gtk+1 (to z tej wersji korzystałem na amd k6-2, a nie z 6.{8,9} - skleroza). Różnica pomiędzy najnowszą a tą względem wydajności jest kolosalna. Ta jest w mojej ocenie całkowicie używalna w emulatorze. Vim 7.2 wymiata.
Jak już zbudowałem gtk1 wypadałoby ją wykorzystać jeszcze do czegoś. Firefox 2.0.20 lub 1.5, to zbyt długa kompilacja, może innym razem (zbudować na 90% da się).

mtpaint-3.40
Pewnie znaczną część odrzuci tak siermiężny wygląd. Ja nie mam z nim problemów. Bardzo udana, minimalistyczna aplikacja, niezwykle szybka. Nie ma nic lepszego na pentium mmx 166MHz. Ktoś takiego używa :) Kilka osób czasem wygrzebuje w piwnicy na strychu.

xmms-1.2.11 (prawdziwa perełka)
Winamp pod linuksa. Powstał w kilka miesięcy po nim. Pod koniec 1997 roku. Tu ostatnia jego wersja. Jak go uruchomiłem i zobaczyłem znowu po może 16 latach, dosłownie dostałem opadu szczęki. Jest po prost the best, te skórki, wizualizery (choć bez opengl, na moim 3dfx banshee szalał). Skórka Ultrafina - Linux Digital Audio :) Co za czasy. Ahh.

jslinux-riscv-addon.2.tar.gz https://drive.google.com/file/d/0BwO8xuhb9OwrVXl3VH … w?usp=sharing

Zawiera: glib-1.2.10, gtk+-1.2.10, giflib-5.1.4, mtpaint-3.40, xmms-1.2.11, libogg-1.3.2, libvorbis-1.3.5, alsa-lib-1.0.18, vim-7.2.444, gohufont-2.1. Alsa oczywiście do niczego nie jest tu potrzebna, tyle że bez niej nie da się zbudować xmms. Ten kernel nie ma obsługi nawet alsa dummy. Choć mógłby akurat.

Instalacja:
gzip -dc jslinux-riscv-addon.2.tar.gz | tar xf - -C/
oraz
xset +fp /usr/share/fonts/X11/misc    #(gohfont to jeden z najczytelniejszych, polecam go)

xmms 2>/dev/null&
gvim 2>/dev/null&
mtpaint 2>/dev/null&

Offline

 

#12 2017-09-28 15:11:38

admetus
Użytkownik
Zarejestrowany: 2014-07-09

Re: Chrome w Chrome

mupdf-1.11.riscv32.tar.gz.1        https://drive.google.com/file/d/0BwO8xuhb9Owrb3ladX … w?usp=sharing
mupdf-1.11.riscv32.tar.gz.2        https://drive.google.com/file/d/0BwO8xuhb9OwrUmlVLW … w?usp=sharing
mupdf-1.11-tool.riscv32.tar.gz.1   https://drive.google.com/file/d/0BwO8xuhb9OwrZ2ZSUW … w?usp=sharing
mupdf-1.11-tool.riscv32.tar.gz.2   https://drive.google.com/file/d/0BwO8xuhb9OwrOVZCeH … w?usp=sharing

Co prawda czytnik pdf jest już i nawet zintegrowany z przeglądarką. W chrome korzystający z NaCl, czyli w kodzie natywnym C, C++, całkiem szybki i bezpieczny, ale. Ze świecą szukać tak dobrze zoptymalizowanego jak mupdf. Nie mogło zabraknąć i na JSLinuksie. Posiada użyteczny dodatek mutool ze sporą ilością funkcji, create, draw, clean, info, merge, extract, poster, convert a także zintegrowany interpreter JS.
https://mupdf.com/docs/manual-mutool-run.html
Przy większych OCR-owanych kobyłach z archive.org "troszkę" staje tu dębem. Aplikacja rozmiarem jest duża ze względu na wbudowane fonty (między innymi Noto) z kodowaniem chińskim, japońskim, arabskim, indyjskim, itd. Musiała zostać podzielona na dwie części z uwagi na obowiązujący limit na przesyłane pliki pod emulatorem. Można skompresować z użyciem lzma - xz, wtedy się zmieści.
Instalacja:
cat mupdf-1.11.riscv32.tar.gz.1 mupdf-1.11.riscv32.tar.gz.2 | gzip -dc | tar xf - -C/

nbench-byte-2.2.3.riscv32.tar.gz   https://drive.google.com/file/d/0BwO8xuhb9Owrak1rV0 … w?usp=sharing
Stareńki benchmark. Pasujący tu jak ulał. Na moim złomku Intel Core2 @1.73GHz pod Chrome 61 (validate-asm disabled):

/usr/bin/nbench

----------------------------------------------------------------------------
BYTEmark* Native Mode Benchmark ver. 2 (10/95)
Index-split by Andrew D. Balsa (11/97)
Linux/Unix* port by Uwe F. Mayer (12/96,11/97)

TEST                : Iterations/sec.  : Old Index   : New Index
                    :                               : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT:          18.592  :          0.48  :       0.16
STRING SORT   :         0.76307  :         0.34  :       0.05
BITFIELD            :      3.9706e+06  :     0.68  :       0.14
FP EMULATION :           2.916  :          1.40  :       0.32
FOURIER            :          52.067  :         0.06  :       0.03
ASSIGNMENT    :         0.38835  :         1.48  :       0.38
IDEA                   :          50.117  :          0.77  :       0.23
HUFFMAN          :          29.994  :          0.83  :       0.27
NEURAL NET     :        0.061275  :       0.10  :       0.04
LU DECOMPOSITION :  2.4483  :       0.13  :       0.09
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX       : 0.760
FLOATING-POINT INDEX: 0.090
Baseline (MSDOS*)   : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
CPU                 :
L2 Cache            :
OS                  : Linux 4.12.0-rc6-g48ec1f0-dirty
C compiler          : gcc version 7.1.1 20170509 (GCC)
libc                :
MEMORY INDEX        : 0.142
INTEGER INDEX       : 0.235
FLOATING-POINT INDEX: 0.050
Baseline (LINUX)    : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
* Trademarks are property of their respective holder.

Pod Firefox-em 55 wynik gorszy o równe 33%, ale google szykuje następną niespodziankę w beta i devel (62,63). Obie są wolniejsze od stable o 72% (o w mordę, znowu przeglądać git log z 20000 zmian w poszukiwaniu tej jednej właściwej, jeśli się nie odnajdzie to chyba będzie trzeba przeprosić się z firefoxem na potrzeby JSLinuxa).

Zawartość archiwum listuje się tak (a może ktoś nie wie):
tar tvf archiwum.tar.gz                 #gnu tar
gzip -dc archiwum.tar.gz | tar tvf -    #busybox tar

Offline

 

#13 2017-09-30 20:14:52

admetus
Użytkownik
Zarejestrowany: 2014-07-09

Re: Chrome w Chrome

openttd-1.7.1.riscv32.tar.gz https://drive.google.com/file/d/0BwO8xuhb9OwrWW5TYT … w?usp=sharing
Chyba większość o tej grze słyszała. U mnie w emulatorze ledwo co człapie (było to do przewidzenia), ale działa prawidłowo. Odpalałem ją tak:
openttd -s null -m null -r 800x600 -b 8bpp-optimized

Na amd k6-2@300 starsza wersja może 1.1, 1.2 działała wyśmienicie (ale tu mam ledwie pentium 40Mhz).
Zbudowałem też inny hit, Supertux 0.1.3, tyle że "segment faultuje". Uruchamia się i jakby miała problem z wejściem do odpowiedniego trybu graficznego. Sam strace nic nie mówi na ten temat, a gdb brak. Choć wersja z sdl nie miałaby szans działać lepiej jak 2 klatki na sekundę, na k6-2 z 3dfx banshee i w wersji z opengl chodził z 40-60fps przy 640x480.

EDIT:
supertux-0.1.3.riscv32.tar.gz https://drive.google.com/file/d/0BwO8xuhb9OwrcTd5eG … w?usp=sharing
supertux --disable-sound --disable-music --sdl

aterm-1.0.1.riscv32.tar.gz https://drive.google.com/file/d/0BwO8xuhb9OwrckFyZk … w?usp=sharing

Ostatnio edytowany przez admetus (2017-10-01 19:00:46)

Offline

 

#14 2017-10-05 18:40:59

admetus
Użytkownik
Zarejestrowany: 2014-07-09

Re: Chrome w Chrome

i3-4.10.4.riscv32.tar.gz https://drive.google.com/file/d/0BwO8xuhb9OwrVGFKVE … w?usp=sharing

Starsza wersja bez cairo i pango. Malutka i zwinna. Gotowa do działania po:
gzip -dc i3-4.10.4.riscv32.tar.gz | tar xf - -C/
Prawoklik na pulpicie. Z menu fluxboxa -> restart. Następnie:
startx

Klawiszem modyfikatorem jest lewy alt (można zmienić jeśli będzie kolidował), czyli alt-enter - uruchomi terminal aterm, alt-d - dmenu. Cała domyślna klawiszologia jest zawarta w pliku /etc/i3/config.
Zawiera: aterm-1.0.1, mksh-R56, libev-4.24, dmenu-4.5, i3status-2.9, startup-notification-0.12, confuse-3.0, libxkbcommon-0.7.1, xcb-util-0.3.8, xcb-util-cursor-0.1.1, xcb-util-image-0.3.9, xcb-util-keysyms-0.3.9, xcb-util-renderutil-0.3.8, xcb-util-wm-0.3.9, xcb-util-xrm-1.2, yajl-2.0.4, gohufont-2.1.

i3-4.13.riscv32.tar.gz https://drive.google.com/file/d/0BwO8xuhb9OwrSTNDZU … w?usp=sharing
Z cairo i pango. Do działania potrzebuje wszystkich bibliotek z wersji i3-4.10.4, czyli xcb-util-*, startup-notification, libxkbcommon i dodatkowo glib2, cairo, pango, harfbuzz (znajdują się one w jslinux-riscv-addon.1.tar.gz). Plus dodatki jak dmenu, i3status, czy rxvt-unicode. Wymaga konfiguracji własnej.

i3status-2.9.riscv32.tar.gz https://drive.google.com/file/d/0BwO8xuhb9OwrMks3Zj … w?usp=sharing
dmenu-4.5.riscv32.tar.gz (bez xft) https://drive.google.com/file/d/0BwO8xuhb9OwrMS1tWW … w?usp=sharing
dmenu-4.6.riscv32.tar.gz (z xft) https://drive.google.com/file/d/0BwO8xuhb9Owrc0tnNG … w?usp=sharing
ruby-2.2.5.riscv32.tar.gz https://drive.google.com/file/d/0BwO8xuhb9OwremNucm … w?usp=sharing
Zawiera: gdbm-1.13 (w wersji statycznej).
libarchive-3.3.1.riscv32.tar.gz https://drive.google.com/file/d/0BwO8xuhb9OwraW1qWl … w?usp=sharing
Zawiera: lzo-2.10, bzip2-1.0.6, xz-5.2.3 (wersje statyczne).
cmake-2.8.12.2.riscv32.tar.gz https://drive.google.com/file/d/0BwO8xuhb9OwrSmJ2X2 … w?usp=sharing
Zawiera: libarchive, lzo, bzip2, xz (wersje statyczne).

Ostatnio edytowany przez admetus (2017-10-05 22:37:39)

Offline

 

#15 2017-10-08 16:05:53

admetus
Użytkownik
Zarejestrowany: 2014-07-09

Re: Chrome w Chrome

lzo-2.10 lzop-1.04.riscv32.tar.gz https://drive.google.com/file/d/0BwO8xuhb9OwrZFR0Tl … w?usp=sharing
brotli-1.0.1.riscv32.tar.gz https://drive.google.com/file/d/0BwO8xuhb9OwrS1VtWW … w?usp=sharing
lz4-1.8.0.riscv32.tar.gz https://drive.google.com/file/d/0BwO8xuhb9OwrUFpsc1 … w?usp=sharing
snappy-1.1.6-snzip.riscv32.tar.gz https://drive.google.com/open?id=0BwO8xuhb9OwrQjlDekpya3FHem8
Reszta linków do kompresorów u góry.

vmtime lzop -dc perl-5.24.2.riscv32.tar.lzo >/dev/null
Real time: 15.303 s     14757709 (-9)
vmtime snzip -dc perl-5.24.2.riscv32.tar.sz >/dev/null  #snappy
Real time: 21.416 s     19938561
vmtime lz4 -dc perl-5.24.2.riscv32.tar.lz4 > /dev/null
Real time: 25.535 s     15350828 (-9)
vmtime minigzip -d -c perl-5.24.2.riscv32.tar.gz >/dev/null
Real time: 26.320 s     11795058 (zopfli --i120)
vmtime brotli -dc perl-5.24.2.riscv32.tar.br >/dev/null
Real time: 35.248 s     8462605 (-Z)
vmtime gzip -dc perl-5.24.2.riscv32.tar.gz >/dev/null   #GNU gzip
Real time: 39.974 s     11795058 (zopfli --i120)
vmtime zstd -dcq perl-5.24.2.riscv32.tar.zst >/dev/null
Real time: 53.157 s     9167800 (-19)
vmtime xz -dc perl-5.24.2.riscv32.tar.xz >/dev/null
Real time: 82.557 s     7611724 (-9e)
vmtime bzip2 -dc perl-5.24.2.riscv32.tar.bz2 >/dev/null
Real time: 167.479 s    10778397 (-9)

Wybrałem się w poszukiwanie optymalnego kompresora, czyli takiego który oferuje najlepszą wydajność dekompresji przy możliwie największym współczynniku kompresji. Zwracam uwagę głównie na dekompresję jako że tą operację wykonuję 50 razy częściej.

Brotli wyrasta na prawdziwą nową gwiazdę w kompresji (oczywiście w pewnym wycinku jej zastosowań). Stopień kompresji na poziomie zbliżonym do LZMA, zaś szybkość dekompresji do zlib (deflate). Rewelacja. W przeciwieństwie do zstd nie kiepści się straszliwie pod RISC-V acz działa równie dobrze co na x86_64 (zachowując proporcje). Do ideału jeszcze brakuje, główny mankament - bardzo wolna maksymalna kompresja (-Z). Najwięksi przegrani pod riscv, to bzip2 (makabra), zstd i lz4, którzy nie błyszczą tu tak dobrze jak na x86_64. Zstd przy maksymalnej kompresji -22 --ultra, oferuje jeszcze dużo niższą wydajność przy rozpakowywaniu.

Oczywiście starzy wyjadacze jak lzo, zlib (minigzip - król) zupełnie nie zawodzą, fantastyczne wyniki w dekompresji.

Ostatnio edytowany przez admetus (2017-10-08 17:10:00)

Offline

 

#16 2017-10-12 17:44:14

admetus
Użytkownik
Zarejestrowany: 2014-07-09

Re: Chrome w Chrome

ffmpeg-3.3.4_mplayer-svn.riscv32.tar.gz https://drive.google.com/file/d/0BwO8xuhb9OwranE4aj … w?usp=sharing

FFmpeg-3.3.4
Tego dziecka Franicsa Bellarda nie może zabraknąć pod JSLinux-em, obok Qemu jest najbardziej rozpoznawalne. Umieściłbym ją w TOP5 najważniejszych bibliotek (wliczając tylko te o dużym stopniu złożoności). Wykorzystywana jest dosłownie wszędzie, dostępna pod dziesiątki architektur i OS-ów. Korzystają z niej wszyscy codziennie za sprawą Firefoxa, Chrome, czy też dużej liczby różnych wideo odtwarzaczy (też takich twórców którzy łamią jej licencję) a także w całej gamie innych projektów.

Żaden programista czy większa grupa nie jest już w stanie stworzyć dekoderów (tym bardziej enkoderów) w takiej ilości i na tak wysokim poziomie optymalizacji. Po wielokroć (nie przy każdej operacji) z wykorzystaniem dostępnych dodatkowych rozkazów procesorów od mmx, sse po avx2, neon, msa… czy z GPU - CUDA/CUVID, VAAPI, VDPAU, itd.
https://trac.ffmpeg.org/wiki/HWAccelIntro
W przypadku enkodowania często wykorzystuje się również bardzo zaawansowane zewnętrzne dzieła - libx26[45], libvpx,… czy audio libfdk_aac, libopus/vorbis, itp. Choć sam ffmpeg posiada bardzo dużo enkoderów własnych i co rusz przybywają nowe (GSoC) - aac, flac, opus, itd.

Kilka testowych nieskomplikowanych operacji.
ffmpeg -codecs
ffmpeg -f lavfi -i "anoisesrc=d=10:c=brown:r=44100:a=0.5" -c:a pcm_s16le test.wav
ffmpeg -f lavfi -i "sine=frequency=1000:sample_rate=44100:duration=5" -ac 1 -c:a flac tone.flac
ffmpeg -i tone.flac -af volumedetect -f null -
ffmpeg -v quiet -f x11grab -video_size 1024x600 -framerate 5 -i :0.0 -c:v ffvhuff out.avi
ffmpeg -benchmark -i inputfile.mp4 -f null -
ffmpeg -i test.mp4 -vf 'select=between(n\,1\,30)' -an -vsync 0 frame1_%03d.png
feh *.png
ffmpeg -skip_frame nokey -i test.mp4 -vf 'scale=128:72,tile=8x8' -an -vsync 0 keyframes%03d.png

MPlayer (r37992-snapshot)
Współtworzony w sporej części przez to samo grono developerów co ffmpeg. Równie fantastyczne dzieło (nie mogące działać bez ffmpeg). Swój wkład w rozwój mplayera miał choćby tak nietuzinkowy programista jak Rich Felker, twórca biblioteki podstawowej C - musl. Ma różne forki, które w przypadku mojej konfiguracji sprzętowej nie oferują mi nic ponadto. Mplayer2, to jakaś drobnica zmian, mpv - troszkę większe w tym wykastrowanie dużej ilości wyjść video, dodanie kilku rzeczy, próba zmiany licencji (och). Mplayer to rewelacyjny postprocessing, niezwykle wydajne skalery, ogrom przeróżnych przydatnych filtrów oraz precyzyjna kontrola każdej dostępnej opcji. Całe spektrum możliwości, których nie sposób opisać w kilku zdaniach. Player którego używam prawie codziennie od 15 lat.

Warto przetestować na czymś. Trochę testowych sampli (różnorakie kodeki) znajduje się tu https://samples.mplayerhq.hu/.
youtube-dl -f17,36 'https://www.youtube.com/watch?v=9bZkp7q19f0'

Generalnie są tu dwa wyjścia video (-vo help) x11 i fbdev. Oba bez skalowania. Fbdev jest sporo szybsze ale "brudzi" pulpit pod fluxboxem (pod i3-wm jest znacznie lepiej z nim, a najlepiej na konsoli  bez X-ów).
vmtime mplayer -vo null -endpos 00:00:30 -nosound -benchmark psy.17.3gp
vmtime mplayer -vo fbdev -endpos 00:00:30 -nosound -benchmark -fs -quiet psy.3gp
mplayer -really-quiet -vo x11 -vf scale=1024:-2,unsharp=l3x3:1.1:c3x3:1.1 test.x264.mkv
mplayer -identify -frames 1 -vo null -ao null -sub-fuzziness 0 -really-quiet Ikari_and_Rei_in_the_hospital-Shadowcry.avi
mplayer -really-quiet -vo fbdev -fs Ikari_and_Rei_in_the_hospital-Shadowcry.avi

Ostatnio edytowany przez admetus (2017-10-12 19:21:07)

Offline

 

#17 2017-10-15 12:32:02

admetus
Użytkownik
Zarejestrowany: 2014-07-09

Re: Chrome w Chrome

angband-3.5.0.riscv32.tar.gz https://drive.google.com/file/d/0BwO8xuhb9OwrbU9veD … w?usp=sharing

LC_ALL=en.UTF-8 angband    #najlepiej wyłącznie pod urxvt który potrafi korzystać z ttf - Libre Mono

Jeśli ktoś jest zainteresowany samodzielnym budowaniem pod RISC-V, to polecam Qemu w trybie User Mode. Zachęcam. Z takich doświadczeń czerpie się dużo korzyści.
https://github.com/riscv/riscv-qemu
Należy zbudować w pełni statyczne qemu (--target-list=riscv32-linux-user). Generalnie potrzebne do tego są biblioteki glib2 i pcre w wersji statycznej. Naturalnie nie ma potrzeby statycznego linkowania wszystkich binarek qemu jak qemu-nbd, qemu-img, wyłącznie qemu-riscv32.
Wykorzystać binfmt_misc.
Z='\x00\x00\x00\x00\x00\x00\x00'; echo ':riscv32:M::\x7f\x45\x4c\x46'$Z$Z'\xf3\x00:\xff\xff\xff\xff'$Z$Z'\xff\xff:/usr/bin/qemu-riscv32:' >/proc/sys/fs/binfmt_misc/register

Wykonać backup JSLinuxa tar-em bez /sys /proc, itp. Pobrać stworzone archiwum, rozpakować w dowolnym katalogu i chrootować się (chroot ~/riscv32-jslinux /bin/sh), kopiując również statyczną binarkę qemu do /usr/bin pod root-filesystem riscv32. Dzięki temu nie emuluje się całego systemu, a następuje wyłącznie translacja z riscv na x86_64 samego kodu binarnego. Jak to wygląda w praktyce. Bardzo dobrze :). Od ~12-36x szybciej niż pod javascriptowym qemu. Niektóre binarki z małą ilością wywołań systemowych działają zaledwie ~2.6-3x (!!) wolniej niż natywnie pod x86_64. Można też cały system budowania przenieść gdzieś do chmury pod dockera na dużo szybszy sprzęt.

Cała architektura jest jeszcze w trybie rozwoju i o całkowitą stabilność jak i zgodność wywołań systemowych może być jeszcze trudno. Binarki na potrzeby jslinuxa budowałem bez obsługi dużych plików, co w przypadku coreutils objawia się nie działającym ls, rm, mkdir na sytemie plików przekraczającym 2GB. Należy się liczyć z tym że w trybie qemu-riscv32 user-mode nie wszystkie wywołania będą zaimplementowane. Przykładowy błąd (który nie występuje w przypadku pełnej emulacji):
qemu: Unsupported syscall: -151000436
m4: ../sysdeps/unix/sysv/linux/spawni.c:360: __spawnix: Assertion `ec >= 0' failed.
/usr/bin/m4: internal error detected; please report this bug to <bug-m4@gnu.org>: Aborted

https://github.com/sorear/fedora-riscv-useremu
https://wiki.debian.org/QemuUserEmulation

Ostatnio edytowany przez admetus (2017-10-15 23:13:43)

Offline

 

Stopka forum

Powered by PunBB
© Copyright 2002–2005 Rickard Andersson
Nas ludzie lubią po prostu, a nie klikając w przyciski ;-)