Elten ARM, jakieś szanse?

Witam, czy są jakieś szanse na przepisanie Eltena na architektórę ARM? Zauważyłem, że na laptopie Asus Zenbook z procesorem Snapdragon X Elite Elten potrafi na prawdę ciąć. Nie wspominam o tym, że trzeba grzebać w ustawieniach emulacji, bo na domyślnych wypluwa błędy z bibliotekami.

Hmmm, najnowsza beta Eltena 3.0 działa natywnie na architekturze amd64, świetnie się emuluje testowana w Parallelsie na procesorze M3 i M5 Max, na obydwu śmiga pięknie na domyślnych ustawieniach.
Elten działa na architekturze ARM natywnie w kompilacji dla OSX. Będziemy wspierać też arm64 dla Windowsa, w jednej z następnych wersji beta. Ale prawdę mówiąc po tym, jak pięknie śmiga emulacja, nie traktowałem tego jak priorytet.
Sam kod nie stanowi problemu, kwestią do sprawdzenia jest czy wszystkie używane biblioteki przez Eltena mają już odpowiedniki ARM64 i czy są one stabilne. Nie sprawdzałem jeszcze, kręci mi się po głowie, że chyba Phonon (biblioteka HRTF) nie ma jeszcze wersji dla ARM, ale mogę się mylić. W każdym razie problemem jest sam toolchain i dependencje, wykonanie tego jest stosunkowo proste.

OK, sprawdziłem to, więc tak. Phonon nie jest oficjalnie kompilowane na ARM64 i nie ma jeszcze pełnego wsparcia. Można go kompilować ręcznie i ponoć działa (ufam komentarzom, sam nie sprawdziłem), ale część akceleracji jest na razie obchodzona przez fallbacki, bez użycia sprzętowego przyspieszenia. A więc w praktyce HRTF może na natywnym ARM64 działać mniej wydajnie, niż na AMD64.
O ile kojarzę, chyba wszystkie inne biblioteki są przeportowane i działają.

Cuż, ja mam tyloSnapdragona, a tu działa, no, tak jak chce.

Czekaj, ale sprawdzałeś to na wersji beta? Bo ogólnie nie powinno być tak skrajnych różnic architektonicznych.

Na stabilce.

A tak, to na stabilce tak, bo to jest RGSS.

Chciałem na tym komputerze sprawdzić wszystko jak najbardziej możliwie że tak powiem zwyczajnie. Niekażdy ci betę będzieinstalować na daily, a jednak ten rynek robi się co raz to większy.

Wiadomo, ale i tak nie da się przepisać RGSS na ARM. I, tak, problemy RGSS na Armie są mi znane od blisko dwóch lat, ale to nie jest coś, co się da rozwiązać małą zmianą w kodzie, tu potrzebna jest zmiana silnika.
A właśnie Elten 3.0 pracuje na nowym, własnym.

A jakby tak wszystko na jakieś c# przerobić? Wiem robota, robota, robota.

Beta pewnie dosyć szybko przejdize do stabilki, testnij jak ci będzie działać, jak coś nie tak, zawsze lepiej teraz zgłaszać błędy niż potem

Ale jaki to ma sens prócz stworzenia potwora? C to wspaniały język, najwspanialszy jaki kiedykolwiek powstał, rewolucja IT, prawdopodobnie i za 50 lat kernele systemów operacyjnych będą pisane w C, ale tworzenie w nim czegoś rozmiaru Eltena jest absolutnie bez sensu.
-- (pates):
A jakby tak wszystko na jakieś c# przerobić? Wiem robota, robota, robota.
--

Stabilność, responsywność i lepsze zarządzanie zasobami. No niestety, ale patrząc na to co klient potrafi odwalać i co potrafił w ciągu ostatnich lat to.

To od razu idźmy w rusta. Też stabilny, też lepsze zarządzanie pamięcią. :D

Ale nie jest aż tak szybki jak C. Ja wiem, że tam różnica to ułamek ułamka procenta na poziomie wskaźników, no ale jest. :D

A tak już serio, to co proponujesz Patesie nie ma najmiejszego sensu.

Pates, Ty tak serio?

Ciekawe, że Linus już ię zgodził na pisanie sterowników do kernela w ruście, bo ponoć aki bezpieczny, mniej podatny na wcieki pamięci, bo unsafe itd.

No bo to jest prawda. O wiele trudniej stracić dane i zrobić overflow. Sam musze się Rusta poduczyć prawdę mówiąc.
W sensie nie rozumiem Twojego posta, bo jeśli się ze mną nie zgadzasz, to nie masz w czym się nie zgadzać. :)

Nie no, jak t się nie zgadzam, mówię, że bezpieczny jest, ponoć. Jest trochę dziwny jak dla mnie, ale to jak ze wszystkim, czego próbowałem na początku.

Nie, na niby.

-- (Julitka):
Pates, Ty tak serio?

--