Ahoj, czy napisanie przeglądarki internetowej w języku programowania takim jak C#, Java, Scala, Kotlin, Clojure, Groovy, Python[na GraalVM, JVM], Ruby[na GraalVM, JVM], który działa na maszynie wirtualnej, nie przyspieszyło by pracy programistów o jakieś 50%? Nie trzeba będzie tworzyć osobnych kompilacji na różne platformy, piszesz jeden i ten sam kod na różne systemy na których działa maszyna wirtualna.
0
1
Tak, to się nazywa Javascript.
0
rolecoster napisał(a):
Ahoj, czy napisanie przeglądarki internetowej w języku programowania takim jak C#, Java, Scala, Kotlin, Clojure, Groovy, Python[na GraalVM, JVM], Ruby[na GraalJVM, JVM], który działa na maszynie wirtualnej, nie przyspieszyło by pracy programistów o jakieś 50%? Nie trzeba będzie tworzyć osobnych kompilacji na różne platformy, piszesz jeden i ten sam kod na różne systemy na których działa maszyna wirtualna.
Czy znane ci są technologie takie jak Docker czy WebAssembly?
0
Pracy programistów może i tak, ale użytkowników już nie.
0
rolecoster napisał(a):
Ahoj, czy napisanie przeglądarki internetowej w języku programowania takim jak C#, Java, Scala, Kotlin, Clojure, Groovy, Python[na GraalVM, JVM], Ruby[na GraalVM, JVM], który działa na maszynie wirtualnej, nie przyspieszyło by pracy programistów o jakieś 50%? Nie trzeba będzie tworzyć osobnych kompilacji na różne platformy, piszesz jeden i ten sam kod na różne systemy na których działa maszyna wirtualna.
jest już silnik do javascriptu napisany w javie: https://github.com/oracle/graaljs (co prawda github pokazuje, że większość tego repozytorium to c, c++, itd, ale to dlatego, że do tego repozytorium oracle wdupił chyba prawie całego node.jsa (tzn. pewnie bez chrome v8, który jest zastąpiony graal jitem), który dominuje to repozytorium). graalvm (na którym oparty jest graaljs) obsługuje też webassembly i mnóstwo innych języków.
graaljs to jednak zdecydowanie za mało, żeby stworzyć przeglądarkę. brakuje implementacji renderowania html (włączając w to css, dom itp), renderowania grafiki w ogólności (włączając wszelki api do rysowania, renderowanie svg i wiele innych), wielu api webowych, szerokiej obsługi multimediów, obsługi rozszerzeń itd
2
@rolecoster: proponuje aby ktoś chętny napisał przeglądarkę a jak będzie lepsza to będziemy jej używać :)
obecny status quo raczej nie motywuje do zmian bo wszystkim pasuje aktualny stan
2
Marius.Maximus napisał(a):
@rolecoster: proponuje aby ktoś chętny napisał przeglądarkę a jak będzie lepsza to będziemy jej używać :)
obecny status quo raczej nie motywuje do zmian bo wszystkim pasuje aktualny stan
Oczywiście na własnym silniku a nie na chromium jak noob.
2
rolecoster napisał(a):
Ahoj, czy napisanie przeglądarki internetowej w języku programowania takim jak C#, Java, Scala, Kotlin, Clojure, Groovy, Python[na GraalVM, JVM], Ruby[na GraalVM, JVM], który działa na maszynie wirtualnej, nie przyspieszyło by pracy programistów o jakieś 50%? Nie trzeba będzie tworzyć osobnych kompilacji na różne platformy, piszesz jeden i ten sam kod na różne systemy na których działa maszyna wirtualna.
Nie wiem czy wiesz jak działa bytecode np. w JVM, ale włączając w to zagadnienia przeglądania internetu - działa on dokładnie jak opisałeś. Piszesz jeden kod, pakujesz do przenaszalnego jara/wara i działa na różnych systemach.
3
Ogólnie ten wątek to trochę jak pomysł z gatunku ciekawych (maszyny wirtualne są ciekawe), ale mam wrażenie, że autor nie zadał sobie trudu, żeby się dowiedzieć, co już jest albo w jaki sposób można uprościć problem.
Plus ten wątek jest trochę w stylu wymyślę rozwiązanie na czuja, a potem poszukam problemu, jaki mógłbym rozwiązać.
0
rolecoster napisał(a):
Nie trzeba będzie tworzyć osobnych kompilacji na różne platformy, piszesz jeden i ten sam kod na różne systemy na których działa maszyna wirtualna.
Bez sensu, dodatkowa warstwa abstrakcji, ChatGPT rozwiązał ten problem ładniej i przyjemniej.
0
Piszesz jeden kod, pakujesz do przenaszalnego jara/wara i działa na różnych systemach.
Prawie każda książka o tym mówi i nawet działa na akademickich przykładach. W praktyce jednak nie działa to za dobrze przy poważniejszych systemach i mało kto próbuje. Oczywiście, są systemy na JVM które działają na wielu platformach, ale to dlatego, że deweloperzy systemu dołożyli pracy by tak właśnie było, przenaszalność raz skompilowanego kodu jeden do jednego między systemi do mit.
(edit)
Chętnie zaktualizowałbym swoją wiedzę i poczytałbym o przykładzie, który przeczy temu co napisałem wyżej.
0
Czyli tak wirtualna maszyna javy, która odpala wirtualna maszynę javascript, jeśli java AOT kompilacja jakimś gralem to pewnie jeszcze jako tako by była używalna ta przeglądarka.
Ale jak JIT, to pewnie byśmy sobie trochę poczekali, aż się uruchomi przeglądarka, wiadomo JIT może cachować więc przy następnym uruchomieniu już nie musi wszystkiego od nowa robić.
Normalny użytkownik w ogóle nie buduje przeglądarki, a ręczna kompilacja trochę trwa.
Więc nikomu to nie przyspieszy pracy, a ci co robią development i tak mają CI/CD z testami e2e, a każdy programista lubi mieć wszystko zautomatyzowane więc nie ma tu żadnego boosta, bo nikt tego ręcznie nie robi.
Dodatkowo można uruchomić przeglądarkę w przeglądarce jest taki projekt Kasm workspace, ale performance jest naprawdę beznadziejny, ale za to można wiele desktop aplikacji uruchomić.
Z takim niskim czasem reakcji to tylko frustracji człowiek dostanie i demotywacji do pracy, bo ciągle będzie tracił fokus.
2
several napisał(a):
Piszesz jeden kod, pakujesz do przenaszalnego jara/wara i działa na różnych systemach.
Prawie każda książka o tym mówi i nawet działa na akademickich przykładach. W praktyce jednak nie działa to za dobrze przy poważniejszych systemach i mało kto próbuje. Oczywiście, są systemy na JVM które działają na wielu platformach, ale to dlatego, że deweloperzy systemu dołożyli pracy by tak właśnie było, przenaszalność raz skompilowanego kodu jeden do jednego między systemi do mit.
(edit)
Chętnie zaktualizowałbym swoją wiedzę i poczytałbym o przykładzie, który przeczy temu co napisałem wyżej.
Jeśli piszesz cały system faktycznie jako jeden wielki program java, to java jest całkiem dobrze przenośne i korzysta się z tego nagiminnie.
Np. w bankach to normalka, że całkiem duże systemy developerzy programują i debugują na laptpokach z windowsem, a potem leci to na linuxa, cloud itp., i rzadko kiedy wychodzi problem (ze 20 lat temu czasem pałowaliśmy się z TimeZonami i Charsetem, ale mniej więcej obecnie wiadomo co robić żeby nie miec problemów).
W kategorii takiej jak GUI jest gorzej:
- Swing zasadniczo odpali się "na wszystkim", czasem będzie wyglądał jak wypluty, znowu zjedzony i znowu wyrzygany, ale apka będzie chodzić.
- JavaFX za to nie odpali się nawet zwykle na komputerze kolegi, który ma taki sam OS i tą samą wersję javy (to porypana technologia).
W praktyce duże systemy składają się z wielu komponentów, gdzie java to tylko mały kawałek (dochodzą bazy danych, skrypty i inne kupy) - więc faktycznie przenośność bywa problemem. Choćby przygotowanie start-this-application.sh to już problem, nie mówiąc o tym, że niektórzy mogą chcieć start-this-application.bat.
0
jarekr000000 napisał(a):
Jeśli piszesz cały system faktycznie jako jeden wielki program java, to java jest całkiem dobrze przenośne i korzysta się z tego nagiminnie.
Np. w bankach to normalka, że całkiem duże systemy developerzy programują i debugują na laptpokach z windowsem, a potem leci to na linuxa, cloud itp., i rzadko kiedy wychodzi problem
A banki to już mają jakieś większe klastry na ARM czy od dekad wszystko ładnie śmiga na x86/x64 od sprawdzonych dostawców?
2
loza_prowizoryczna napisał(a):
A banki to już mają jakieś większe klastry na ARM czy od dekad wszystko ładnie śmiga na x86/x64 od sprawdzonych dostawców?
Nie wiem czy kiedykolwiek widziałem ARM w banku ( mogłem nie być świadomy, że coś jest odpalane na ARM - mimo to wątpie). Ostatnie lata to x86/64. Za to dawniej miałem nieprzyjemność dotykać różnych dziwactw typu AIX/ AS 400, a bardzo dawno temu Solarisów.
Z tym, że faktycznie IBMowa java na IBMowym serwerze faktycznie zwykle oznaczała problemy => wydajnościowe.
1
jarekr000000 napisał(a):
loza_prowizoryczna napisał(a):
A banki to już mają jakieś większe klastry na ARM czy od dekad wszystko ładnie śmiga na x86/x64 od sprawdzonych dostawców?
Nie wiem czy kiedykolwiek widziałem ARM w banku ( mogłem nie być świadomy, że coś jest odpalane na ARM - mimo to wątpie). Ostatnie lata to x86/64. Za to dawniej miałem nieprzyjemność dotykać różnych dziwactw typu AIX/ AS 400, a bardzo dawno temu Solarisów.
Z tym, że faktycznie IBMowa java na IBMowym serwerze faktycznie zwykle oznaczała problemy => wydajnościowe.
Trzeba uważać ze skrótami bo można się odrobinę machnąć - ARM gdzieniegdzie to Azure Resource Manager - i spotkasz teamy które "wrzucają coś do chmury korzystając z ARMa"
https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/overview
0
jarekr000000 napisał(a):
Nie wiem czy kiedykolwiek widziałem ARM w banku ( mogłem nie być świadomy, że coś jest odpalane na ARM - mimo to wątpie). Ostatnie lata to x86/64.
Czyli ta wirtualna maszyna to w sumie sprowadza się w sumie do takiego gorszego LXC z rekompilacją na bazowym poziomie (czyli bez SSE/AVX,NX)? Podobieństwa przyciągają podobieństwa - dziwnym trafem architektura hierarchii w każdym większym korpo wygląda podobnie (niewielka góra, rozbuchana warstwa menedżmentu pomiędzy i nieoptymalnie wykorzystany dół odwalający całą robotę). Przypadek?
3
loza_prowizoryczna napisał(a):
Czyli ta wirtualna maszyna to w sumie sprowadza się w sumie do takiego gorszego LXC z rekompilacją na bazowym poziomie (czyli bez SSE/AVX,NX)?
Skąd takie wnioski? W przypadku JVM akurat nie ma problemu, bo JIT sobie kompiluje zgodnie z tym co dany hardware oferuje (nieważne na czym był originał przygotowany).
I korzysta na pewno z SSE/AVX - aczkolwiek jakoś tego korzystania jest często dość słaba.
Podobieństwa przyciągają podobieństwa - dziwnym trafem architektura hierarchii w każdym większym korpo wygląda podobnie (niewielka góra, rozbuchana warstwa menedżmentu pomiędzy i nieoptymalnie wykorzystany dół odwalający całą robotę). Przypadek?
Nie jestem na odpowiednim poziomie, aby odpowiedzeć na to pytanie - w marcu przyszłego roku wznawiam sezon chlania, może wrócę do tego punktu.
0
jarekr000000 napisał(a):
Skąd takie wnioski? W przypadku JVM akurat nie ma problemu, bo JIT sobie kompiluje zgodnie z tym co dany hardware oferuje (nieważne na czym był originał przygotowany).
I korzysta na pewno z SSE/AVX - aczkolwiek jakoś tego korzystania jest często dość słaba.
No ale LLVM również - przy czym LLVM wspiera pewnie z bazylion więcej egzotycznych frontendów dla brainfucków niż JVM kiedykolwiek będzie. Więc po cholerę nam dynamiczny JVM z jego narzutem skoro 90%+ architektury na którym to chula to stary dobry x86/x64. Może w epoce kiedy korpa migrowały z jakichś mainframe'ów na własnościowych archi to miały jakiś sens ale dzisiaj? Nawet ten nieszczęsny CLR od .NET dorobił się AOT.
Nie jestem na odpowiednim poziomie, aby odpowiedzeć na to pytanie - w marcu przyszłego roku wznawiam sezon chlania, może wrócę do tego punktu.
Trzeba było od razu że piszesz z antypodów. Sezon chlania w lecie to dla mnie jakaś egzotyka ;)
0
Nawet ten nieszczęsny CLR od .NET dorobił się AOT.
Ale Java tez ma AOT (Graal) tylko chyba nikt tego nie używa XD
0
KamilAdam napisał(a):
Ale Java tez ma AOT (Graal) tylko chyba nikt tego nie używa XD
Za późno przyszła refleksja nad tym co można a co nie :(
1
loza_prowizoryczna napisał(a):
No ale LLVM również - przy czym LLVM wspiera pewnie z bazylion więcej egzotycznych frontendów dla brainfucków niż JVM kiedykolwiek będzie. Więc po cholerę nam dynamiczny JVM z jego narzutem skoro 90%+ architektury na którym to chula to stary dobry x86/x64. Może w epoce kiedy korpa migrowały z jakichś mainframe'ów na własnościowych archi to miały jakiś sens ale dzisiaj? Nawet ten nieszczęsny CLR od .NET dorobił się AOT.
Pomijając, że JVM ma AOT, to jeszcze w kompilacji runtime nie chodzi tylko o architekturę, ale też o optymalizację kodu na podstawie statystyk faktycznego działania.
Dzięki temu rzeczy, które np. w takim C++ są herezją (jak inlinowanie metod wirtualnych) to normalka na JVM.
Standardowe AOT polegające na statycznej kompilacji produkuje istornie wolniejszy kod (docelowo) niż JIT - za to szybciej startuje.
Na to jest rozwiązanie, bo odpala się kod wstępnie i nagrywa profil wykonania (pgo)- dla kompilatora AOT. Tak skompilowany kod ma mniej więcej szybkość normalnie JITowanego.
0
jarekr000000 napisał(a):
Dzięki temu rzeczy, które np. w takim C++ są herezją (jak inlinowanie metod wirtualnych) to normalka na JVM.
Jeśli jest tak jak mówisz to JVM powinien być złotym graalem dla języków dynamicznych. Jak ostatnio sprawdzałem - nie jest.
Standardowe AOT polegające na statycznej kompilacji produkuje istornie wolniejszy kod (docelowo) niż JIT - za to szybciej startuje.
Na to jest rozwiązanie, bo odpala się kod wstępnie i nagrywa profil wykonania (pgo)- dla kompilatora AOT. Tak skompilowany kod ma mniej więcej szybkość normalnie JITowanego.
W sumie widziałem ostatnio przykład połączenia obu powyższych - kompilacja on-demand + cache z powodu różnorakich architektur. To chyba dotyczyło HLSL (obstawiam że SPIR-V również) i gejmdevu. W rezultacie na zunifikowanej architekturze wszystko działa świetnie a na zróżnicowanej działa ujowo aż nie przejdziesz wszystkiego (w sumie to chyba tłumaczy wprowadzenie mechanik nowa gra+)
Ale w gejmdev tak jak w prawdziwym życiu najważniejsze jest pierwsze wrażenie :(
1
KamilAdam napisał(a):
Nawet ten nieszczęsny CLR od .NET dorobił się AOT.
Ale Java tez ma AOT (Graal) tylko chyba nikt tego nie używa XD
na pewno jest ktoś ktos używa :]
a .net native aot deployment ktoś używa?
Limitations of Native AOT deployment
Native AOT apps have the following limitations:No dynamic loading, for example, Assembly.LoadFile.
No run-time code generation, for example, System.Reflection.Emit.
No C++/CLI.
Windows: No built-in COM.
Requires trimming, which has limitations.
Implies compilation into a single file, which has known incompatibilities.
Apps include required runtime libraries (just like self-contained apps, increasing their size as compared to framework-dependent apps).
System.Linq.Expressions always use their interpreted form, which is slower than run-time generated compiled code.
Not all the runtime libraries are fully annotated to be Native AOT compatible. That is, some warnings in the runtime libraries aren't actionable by end developers.
a tutaj są dalsze ciekawe ograniczenia: https://learn.microsoft.com/en-us/dotnet/core/deploying/trimming/incompatibilities (np: w zasadzie desktop gui w native aot nie działa).
z drugiej strony, awt i swing działają pod native-image: https://bugs.openjdk.org/browse/JDK-8254024 (nie wiem na jakich platformach, ale z czasem pewnie będzie komplet). pod native-image działa też javafx, np: https://docs.gluonhq.com/#_create_install_an_ios_native_image
1
loza_prowizoryczna napisał(a):
jarekr000000 napisał(a):
Nie wiem czy kiedykolwiek widziałem ARM w banku ( mogłem nie być świadomy, że coś jest odpalane na ARM - mimo to wątpie). Ostatnie lata to x86/64.
Czyli ta wirtualna maszyna to w sumie sprowadza się w sumie do takiego gorszego LXC z rekompilacją na bazowym poziomie (czyli bez SSE/AVX,NX)? Podobieństwa przyciągają podobieństwa - dziwnym trafem architektura hierarchii w każdym większym korpo wygląda podobnie (niewielka góra, rozbuchana warstwa menedżmentu pomiędzy i nieoptymalnie wykorzystany dół odwalający całą robotę). Przypadek?
vmki służące do interpretowania i kompilacji abstrakcyjnego kodu (jvm, clr, vmki do javascriptu, itp itd), czyli abstrahujące procesor, to zupełnie co innego niż hypervisory czy vmki abstrachujące głównie peryferia (virtualbox, kvm, xen, itp itd) ale wymagające natywnego kodu do odpalenia (no chyba, że dokładamy qemu czy inny emulator). te pierwsze vmki nie oferują izolacji czy abstrakcji tego samego typu co te drugie.
jvm potrafi automatycznie wykorzystać x86 sse, x86 avx (włączając avx-512), arm neon, arm sve/sve2, risc-v vector, itp itd ale ten automatyczny autowektoryzator jest gorszy niż ten w llvm czy gcc. za to w przygotowaniu jest api dzięki któremu możesz wyciągnąć bardzo wysoką wydajność jeśli potrafisz programować na wektorach:
niedawno do hotspota weszło sortowanie oparte o avx-512 i ręcznie optymalizowane (napisane w c++, a nie javie) i spotkało się z absurdalnie dużym poziomem ekscytacji: https://www.phoronix.com/news/Intel-x86-simd-sort-3.0 to sortowanie dotyczy tylko tablic prymitywów (tzn. int[], double[], long[] itd), a nie zadziała np dla sortowania tablicy obiektów po polu typu int, więc nie widzę powodu, by się mocno ekscytować. jednak mikrobenchmarki dla mało reprezentatywnych przypadków powodują taką podnietę, że przysłania to rozsądek.
1
loza_prowizoryczna napisał(a):
jarekr000000 napisał(a):
Dzięki temu rzeczy, które np. w takim C++ są herezją (jak inlinowanie metod wirtualnych) to normalka na JVM.
Jeśli jest tak jak mówisz to JVM powinien być złotym graalem dla języków dynamicznych. Jak ostatnio sprawdzałem - nie jest.
co konkretnie sprawdzałeś? zwykły jvm (nie-graalvm) operuje na bajtkodzie, a bajtkod jednak słabo się nadaje do obsługi języków kaczo typowanych.
graalvm operuje na innym poziomie abstrakcji (nawet nie jest pewien jakim, ale raczej chodzi o jakieś ast) i to jest jeden z powodów dla których optymalizuje lepiej.
dla przykładu:
https://www.graalvm.org/python/
cpython to standardowy interpreter pythona
jython to python tłumaczony do bajtkodu javowego
graalpy działa tylko na graalvmie i (z tego co wiem) nie jest tłumaczony do javowego bajtkodu tylko do ast graalowego
1
loza_prowizoryczna napisał(a):
Jeśli jest tak jak mówisz to JVM powinien być złotym graalem dla języków dynamicznych. Jak ostatnio sprawdzałem - nie jest.
Nie wiem co dokładnie sprawdzałeś. I na czym polega bycie świetnym graalem.
Zapewne działa też stare prawo: nieważne jaka jest teza, ważne kto jest promotorem.
(widziałem już najgłupsze rzeczy uzasadnione benchmarkami - odpowiedni brak wiedzy/doświadczenia pomaga zwykle w stworzeniu takich).
Bytecode jako język jest jednym z bardziej dynamicznych, a mimo to działa na jvm nieźle :P
0
Wibowit napisał(a):
te pierwsze vmki nie oferują izolacji czy abstrakcji tego samego typu co te drugie.
Ale ty mi świata nie tłumacz, ty mi lepiej wytłumacz po co komuś w dzisiejszym świecie abstrakcja czegoś co w enterprise jedzie na jednej architekturze która jest obecnie standardem przemysłowym. A tymi drugim to pies z kulawą by się nie interesował gdyby nie rozwój chmury i związane z tym wyzwania dot. izolacji czy uproszczenia deploymentu.
niedawno do hotspota weszło sortowanie oparte o avx-512 i ręcznie optymalizowane (napisane w c++, a nie javie)
Ręczną optymalizację tu masz tu. Ty po prostu wkleiłeś przykład gdzie eliminacja abstrakcji której nikt nie potrzebuje wymaga modyfikacji samej VMki
graalvm operuje na innym poziomie abstrakcji (nawet nie jest pewien jakim, ale raczej chodzi o jakieś ast) i to jest jeden z powodów dla których optymalizuje lepiej.
Czekam jeszcze na wrzutkę że korzysta przy tym z AI (tak żeby być na czasie z trendem). Bo tak szczerze to słabo widzę abstrakcję ogólnego zastosowania która by optymalizowała lepiej niż doświadczony dev ;)
jarekr000000 napisał(a):
Bytecode jako język jest jednym z bardziej dynamicznych, a mimo to działa na jvm nieźle :P
W końcu po coś ten tryb interpretera w tym JVM tam zostawili.
No i na koniec tego bezsensownego dylematu pozostaje kwestia: Dlaczego JVM a nie LLVM?
2
loza_prowizoryczna napisał(a):
Ale ty mi świata nie tłumacz, ty mi lepiej wytłumacz po co komuś w dzisiejszym świecie abstrakcja czegoś co w enterprise jedzie na jednej architekturze która jest obecnie standardem przemysłowym. A tymi drugim to pies z kulawą by się nie interesował gdyby nie rozwój chmury i związane z tym wyzwania dot. izolacji czy uproszczenia deploymentu.
(...)
No i na koniec tego bezsensownego dylematu pozostaje kwestia: Dlaczego JVM a nie LLVM?
I te wszystkie pytania w kontekście tego że mamy już JVM i .NET a zaraz będziemy mieć WASMa na desktopach i serwerach bo ktoś wpadł na szalony pomysł że po co kompilować bitcode LLVM natywnie jak można kompilować do WASMa i uruchamiać WASMa. Ja wiem iż pierwotną ideą było uruchamianie WASMa w przegladarce ale jakoś to sie wymkneło spod kontroli i niektórzy już snują jak wspaniale będzie wyglądać świat gdy będziemy kompilować mikroserwisy do WASMa XD
1
loza_prowizoryczna napisał(a):
No i na koniec tego bezsensownego dylematu pozostaje kwestia: Dlaczego JVM a nie LLVM?
LLVM nie jest kodem do uruchamiania. Cały preprocesor zależny od architektury i systemu wpływa na to jak wygląda wynikowy IR. Ten IR też trzeba jakoś przekształcić na kod wynikowy.
KamilAdam napisał(a):
I te wszystkie pytania w kontekście tego że mamy już JVM i .NET a zaraz będziemy mieć WASMa na desktopach i serwerach bo ktoś wpadł na szalony pomysł że po co kompilować bitcode LLVM natywnie jak można kompilować do WASMa i uruchamiać WASMa
WASM to pierwszy w miarę niezależny kod bajtowy, który nie jest skrojony pod konkretny produkt ani rozwiązanie (jak np. kod bajtowy javy, który jest mocno skrojony pod ten język). Nic dziwnego, że WASM jest traktowany przez wielu jako przenośny assembler, który można łatwo interpretować i JITować