Mam takie pytanie czy gdyby np. jądro linuksa albo windowsa napisać w całości w assemblerze to ten OS działałby szybciej i byłby bardziej bezpieczny no bo w teorii programy napisane w assemblerze powinny działać nawet 2 x szybciej niż np. w c, a co do bezpieczeństwa to tutaj nie wiem jak z tym jest.
0
1
Pod względem bezpieczeństwa nie zmieni się praktycznie nic - sporo dziur jest w innych częściach systemu, np. w wywołaniu spekulatywnym czy w Javie.
Dobrze napisanym kodem C i opcjami kompilatora można wycisnąć z procesora naprawdę dużo, samym asm ciężko coś wnieść. Więcej da zmiana logiki aplikacji, niż przepisanie jądra. Poza tym w wielu miejscach jądra są już wstawki asemblerowe.
Przede wszystkim postawiłbym sobie pytanie czy gra jest warta świeczki. Trzeba by było się naprawdę napracować. Tak naprawdę jeśli miałbym jakąś uber optymalną aplikację w asemblerze, mógłbym dopisać kod uruchomieniowy (bootstrap) i odpalić z dyskietki :D .
1
pol90 napisał(a):
bo w teorii programy napisane w assemblerze powinny działać nawet 2 x szybciej niż np. w c
Jakoś nie bardzo kojarzę tą teorię. Masz jakieś źródło, link do badań czy coś?
2
pol90 napisał(a):
bo w teorii programy napisane w assemblerze powinny działać nawet 2 x szybciej niż np. w c
Wg jakiej teorii? Fakt, że pisze się w języku niższego poziomu nie oznacza, że coś będzie działało szybciej. Na pewno trzeba będzie na to poświęcić więcej czasu.
2
Ręcznie nie napiszesz tak dobrze zoptymalizowanego kodu jak wyplują dzisiejsze kompilatory od C/C++, chyba, że faktycznie jakieś cuda będziesz wyprawiał na SIMD (w co wątpię), a druga rzecz SIMD nie wykorzystasz do wszystkiego. Co do bezpieczeństwa tego kodu to też nie jest to prawdą, z prostego powodu, dla C i C++ istnieje o wiele bardziej rozbudowany ekosystem sprawdzania i analizy kodu pod każdym możliwym względem, w tym bezpieczeństwa, potencjalnych luk już na poziomie kodu źródłowego, a dla assemblera (też jakiego?) tych narzędzi po prostu nie ma. Pisząc jakiś szalony, pseudo-zoptymalizowany kod w assemblerze o wiele łatwiej też jest przemycić trudno wykrywalne błędy.
0
jarekr000000 napisał(a):
pol90 napisał(a):
bo w teorii programy napisane w assemblerze powinny działać nawet 2 x szybciej niż np. w c
Jakoś nie bardzo kojarzę tą teorię. Masz jakieś źródło, link do badań czy coś?
No bo np. masz taką instrukcję
zmienna_a = 12;
zmienna_b = 2;
i teraz chcesz je pozamieniać
to w języku wysokiego poziomu robisz to tak
zmienna_c = zmienna_a;
zmienna_b = zmienna_a
zmienna_a = zmienna_b
I to po przetłumaczeniu na język assemblera da chyba 10 rozkazów, a gdyby ktoś miał to napisać w asemblerze to by użył miej linijek kodu ja nie pochwalam pisania w assemblerze tylko chcę porównanie.
6
Kernel Linux ma 25+ mln linii kodu.
Chcącym przepisać to na ASM pozostaje życzyć powodzenia.
0
@pol90 kompilatory współcześnie są bardzo dobre, i wielce powątpiewam w fakt, że OS napisany w assemblerze byłby szybszy. Na 100% byłby trudniejszy w utrzymaniu, byłby zdecydowanie mniej przenośny i zapewne zawierałby więcej błędów.
3
Oprócz tego co przedmówcy powiedzieli o kompilatorach, duża część jądra oraz duża część kodu bibliotek użytkowych w przestrzeni użytkownika nie wymaga wcale super wydajności. Serio, myślisz że ktoś zauważy 10 nadmiarowych cykli CPU zmarnowanych na każdy komunikat odebrany od myszki albo klawiatury?
W praktyce dużo ważniejsza jest rozszerzalność i możliwość długotrwałego rozwoju kodu. To wymaganie dużo łatwiej spełnić w językach wysokiego poziomu niż w asemblerze, zwłaszcza w językach które umożliwiają opcjonalnie zejście kilka poziomów niżej tam gdzie jest to konieczne (C, C++, Rust, nawet Java i C# umożliwiają). Wpływ języka programowania na wydajność jest znacznie mniejszy niż wpływ np. projektu architektury, struktur danych, algorytmów, organizacji kodu (czyli ogólnie: umiejętności programistów i projektantów). Dobrze ogarnięty programista C# napisze szybszy kod niż średnio ogarnięty programista asma i zajmie mu to znacznie mniej czasu.
Poza tym istotne są też aspekty bezpieczeństwa. Używanie języków takich jak asm, C i C++ często prowadzi do błędów zarządzania pamięcią i błędów związanych ze współbieżnością. Dlatego prędzej ktoś napisze nowy system operacyjny w bardzo wysokopoziomowym Rust niż cofnie się z C do asma.
Niestety napisanie nowego systemu to wielkie przedsięwzięcie, więc mało prawdopodobne jest, że kiedykolwiek ujrzymy konkurencję dla Windows/OSX/Linux. Nawet Android to tylko zmodyfikowany Linux. Eksperymenty z nowymi językami mają sens tylko dla jakiś niszowych, specjalistycznych systemów.
0
To nie kernel stanowi problem, a wszystko w okół niego. Odpalenie wszystkich peryferiów sprzętu nie zajmuje aż tak dużo czasu i odbywa się tuż po odpaleniu zasilania. Później w systemie to już z górki/ Przypatrz się na soft, który przetwarza jakieś operacje. O ile dzisiaj w sumie chyba ciężko o tak toporne oprogramowanie o tyle jeszcze 10+ lat temu takich programów było setki. Proste operacje, a potrafiły wykonywać się kilkanaście sekund.
Poza tym nawet jeśli już przepiszesz te 25mln linii kodu z C/C++ to w ASM zajmie Ci to jakieś 250mln albo i więcej. Teraz powodzenia z debudowaniem tego gdy okaże się, że Twój super mózg walnął gdzieś błąd :-)
Nawet gdyby ktoś rzucił się na pisanie nowego systemu to nie wydaje mi się, że zacznie to robić w ASM. Świetnym przykładem będzie tutaj ReactOS, który swój start miał w 1998 roku i nadal jest w wersji Alpha :D + powstaje w C/C++. Skoro 21 lat temu ktoś nie zaczął pisać systemu w ASM to robienie tego dzisiaj tym bardziej nie ma sensu.