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

 

Stopka forum

Powered by PunBB
© Copyright 2002–2005 Rickard Andersson
Możesz wyłączyć AdBlock — tu nie ma reklam ;-)