Forum Debian Users Gang

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/0BwO8xuhb9OwrZ1BLT1B4X3BrS1U/view?usp=sharing
diffutils 3.6 https://drive.google.com/file/d/0BwO8xuhb9OwrMmM0R2RMdE1SQ3c/view?usp=sharing
grep 3.1 https://drive.google.com/file/d/0BwO8xuhb9OwrR0NJNnY1Z3NJTHM/view?usp=sharing
mksh R56 https://drive.google.com/file/d/0BwO8xuhb9OwrblJueGh5Ymp6T1U/view?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/+/af4d42685a7b406d167276ce54a19daedb3d152b%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/0BwO8xuhb9OwrSzh3UGtpZk5FRTg/view?usp=sharing
curl 7.55.1 (static) https://drive.google.com/file/d/0BwO8xuhb9OwrNlZ5dWlCOExva0k/view?usp=sharing
sqlite 3.20.1 (static) https://drive.google.com/file/d/0BwO8xuhb9OwrZEVNb0M3STBNbWs/view?usp=sharing

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

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/0BwO8xuhb9OwrODJwQmpYU3c2Y2s/view?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)

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/0BwO8xuhb9OwrOUV0dmNoanpqWlk/view?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/0BwO8xuhb9OwrOXhCRU1xRlNfcms/view?usp=sharing
file-5.32 https://drive.google.com/file/d/0BwO8xuhb9OwrTGNlY3pTQ3VYcVE/view?usp=sharing
procps-ng-3.3.12 https://drive.google.com/file/d/0BwO8xuhb9OwrOExOdlk3aUY3WXM/view?usp=sharing
findutils-4.6.0 https://drive.google.com/file/d/0BwO8xuhb9OwrWTNjcHA2RGFSemc/view?usp=sharing
mpg123-1.25.6 https://drive.google.com/file/d/0BwO8xuhb9OwrTDdVT3hjdjk5SWs/view?usp=sharing
Do czego? Wyłącznie aby sprawdzić wydajność dekodowania mp3 pod RISC-V.

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

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&url=https://bellard.org/jslinux/buildroot-riscv32-xwin.cfg&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/0BwO8xuhb9OwrZ1pMMU43MjlDdEU/view?usp=sharing
gnumeric-1.10.15.tar.gz https://drive.google.com/file/d/0BwO8xuhb9OwrYUU1NmVmbWplNW8/view?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/0BwO8xuhb9OwrT0laRmd3bGV5WDQ/view?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/0BwO8xuhb9OwrMnVWQnpWdE1fUnc/view?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)

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/0BwO8xuhb9OwrejJad2wtMUd6am8/view?usp=sharing
jslinux-riscv-addon https://drive.google.com/file/d/0BwO8xuhb9OwrZ1pMMU43MjlDdEU/view?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/0BwO8xuhb9OwreHZWTjZDLUIxRWc/view?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/0BwO8xuhb9OwrT3FKT2tOeVk3Nkk/view?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/thread/46de866b/7082/attachment/sodipodi-0.34-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)

mupdf-1.11.riscv32.tar.gz.1        https://drive.google.com/file/d/0BwO8xuhb9Owrb3ladXh1YkZ6dzg/view?usp=sharing
mupdf-1.11.riscv32.tar.gz.2        https://drive.google.com/file/d/0BwO8xuhb9OwrUmlVLWVUWnVpemc/view?usp=sharing
mupdf-1.11-tool.riscv32.tar.gz.1   https://drive.google.com/file/d/0BwO8xuhb9OwrZ2ZSUW5zYzh0c0k/view?usp=sharing
mupdf-1.11-tool.riscv32.tar.gz.2   https://drive.google.com/file/d/0BwO8xuhb9OwrOVZCeHVtN1M4YkU/view?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/0BwO8xuhb9Owrak1rV0t0QVB6ZE0/view?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

i3-4.10.4.riscv32.tar.gz https://drive.google.com/file/d/0BwO8xuhb9OwrVGFKVEhVSGlnQWs/view?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/0BwO8xuhb9OwrSTNDZUY1czNLVkU/view?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/0BwO8xuhb9OwrMks3ZjRQVUlyeEk/view?usp=sharing
dmenu-4.5.riscv32.tar.gz (bez xft) https://drive.google.com/file/d/0BwO8xuhb9OwrMS1tWW5yRjhLOUU/view?usp=sharing
dmenu-4.6.riscv32.tar.gz (z xft) https://drive.google.com/file/d/0BwO8xuhb9Owrc0tnNGdUSHpKd3c/view?usp=sharing
ruby-2.2.5.riscv32.tar.gz https://drive.google.com/file/d/0BwO8xuhb9OwremNucmh2Z3R3UEk/view?usp=sharing
Zawiera: gdbm-1.13 (w wersji statycznej).
libarchive-3.3.1.riscv32.tar.gz https://drive.google.com/file/d/0BwO8xuhb9OwraW1qWlptb0JYTDQ/view?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/0BwO8xuhb9OwrSmJ2X29LdkNpSmc/view?usp=sharing
Zawiera: libarchive, lzo, bzip2, xz (wersje statyczne).

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

ffmpeg-3.3.4_mplayer-svn.riscv32.tar.gz https://drive.google.com/file/d/0BwO8xuhb9OwranE4ajlza2JWQVE/view?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)