cnc.info.pl - FORUM CNC

Obrazek wyjaśnia wszystko:

Wiele lat temu, jeszcze w czasach ZX Spectrum, Commodore, Atari i pierwszych pecetów dyskutowałem z kolegą o wyższości asemblera nad językami wyższego poziomu pod kątem optymalizacji kodu wynikowego.
Kolega użył wtedy argumentu pozamerytorycznego, mianowicie że "pamięć jest coraz tańsza"...
Jak widać miał rację...
Pytanie jest tylko takie, czy jest jakaś granica, po przekroczeniu której system będzie już tak zaśmiecony, że przestanie działać?

A masz świadomość że języki wyższego poziomu są tylko nakładka na assemblera. I de facto programując w C to programuje się w assemblerze? Tylko z pewną utratą optymalności kodu?

I to się nigdy nie zmieni, bo
1. Napisanie dużego systemu w assemblerze trwa i kosztuje zbyt dużo. Nikt nie kupi oprogramowania za 20 tyś zł do tańszego komputera. I nikt nie będzie na nie czekał 5 lat.
2. Znalezienie czegoś i zmienienie w assemblerze to są niewyobrażalne nakłady pracy. A przy rozbudowie lub poprawie jest to konieczne.

Ba, obecne trendy to już dawno odeszły od języków wyższego poziomu. Dzisiaj pisze się oprogramowanie we frameworkach (ASP.NET, Unity, Laravel, React, Ruby on Rails) które dopiero dowalają niewydajności. I nadal to się opłaca klientowi.

tuxcnc pisze:Pytanie jest tylko takie, czy jest jakaś granica, po przekroczeniu której system będzie już tak zaśmiecony, że przestanie działać?

A czy jest jakaś zależność między tym, jak szybko procesor wykonuje operacje, a tym, ile pamięci jest używane?

tuxcnc pisze:Wiele lat temu, jeszcze w czasach ZX Spectrum, Commodore, Atari i pierwszych pecetów dyskutowałem z kolegą o wyższości asemblera nad językami wyższego poziomu pod kątem optymalizacji kodu wynikowego.

O czym tu dyskutować? Przecież to oczywiste. A że w 99,999% przypadków nie ma to żadnego sensu to inna sprawa. Jedyne sensowne zastosowanie assemblera dzisiaj moim zdaniem to jakieś superkrytyczne czasowo/rozmiarowo fragmenty kodu embedded albo jakichś driverów. To te 0,001%.

Temat nie jest o asemblerze.

Problem leży gdzie indziej, to złożoność i różnorodność sprzętu. Pominę ZX Spectrum, bo był na Zilogu Z80, ale biorąc Commodore C64 i Atari 800XL, oba były na 6502/6510, a kod był praktycznie nie do przeniesienia. Uniwersalna architektura PC wymusiła natomiast stosowanie driverów, uniwersalnych bibliotek i innych zabiegów (warstwa abstrakcji), w celu umożliwienia uruchomienia oprogramowania na dowolnej konfiguracji, to stąd biorą się całe megabajty dodatkowego kodu, a to że z wydania na wydanie się to powiększa, to skutek ciągłego rozwoju, nowych sterowników i konieczności zapewnienia wstecznej kompatybilności.
Zastanawiasz się co tyle waży, zobacz na listę zmian, w sekcję "dodaliśmy wsparcie dla...".

JacekBelof pisze: ↑

31 paź 2022, 11:01

to stąd biorą się całe megabajty dodatkowego kodu, a to że z wydania na wydanie się to powiększa, to skutek ciągłego rozwoju, nowych sterowników i konieczności zapewnienia wstecznej kompatybilności.
Zastanawiasz się co tyle waży, zobacz na listę zmian, w sekcję "dodaliśmy wsparcie dla...".

Nie.
Nadal da się zainstalować najnowszego Debiana na 4 GB partycji, ale nie z obrazu instalacyjnego "desktop", tylko z "minimal" i samodzielnie doinstalować środowisko graficzne.
Znaczy to dokładnie tyle, że w standardzie instaluje się kilka gigabajtów śmieci, które w najlepszym razie nie są potrzebne, a w najgorszym mulą komputer, albo się gryzą z innymi pakietami.
Miałem niedawno taką hecę, że coś tam mi nie działało (w tej chwili nie pamiętam co, ale chyba coś z obsługą FTDI), Komunikaty o błędach były debilne i nic nie mówiące, ale w Google znalazłem że przyczyną był pakiet Braile. Po jego odinstalowaniu wszystko zaczęło działać jak powinno... Ja oczywiście nie mam nic przeciwko dostępności dla niepełnosprawnych, ale jestem stanowczo przeciwny upychaniu wszystkiego co komuś może się przydać, bo efektów takiej polityki przewidzieć się nie da....

Dość- imho - ciekawy filmik na teamat języków programowania: https://youtu.be/8Ab3ArE8W3s

W skrócie - tutaj nawet nie chodzi o wyższe poziomy abstrakcji ale o rzeczy typu kod który jest "żywy" i interaktywny podczas już podczas pisania i tworzenie oprogramowania z intuicyjnych elementów grficznych.
Wszystko po to żeby programista miał łatwiejszą robotę. Dla "starych wyjadaczy" brzmi to jak herezja - ale mnie do pewnego stopnia przekonuje - coraz większa część naszego życia jest zależna od software, a jakość kodu... cóż - niedawno kupiłem budzik (beurer wl50) z ewidentnym błędem software. Jeśli programista potrafił spieprzyć głupi budzik... to może lepiej jeśli następnym razym zamiast assemblera dostanie do ręki coś w stylu klocków duplo dla developerów

grg12 pisze: ↑

31 paź 2022, 11:38

Jeśli programista potrafił spieprzyć głupi budzik... to może lepiej jeśli następnym razym zamiast assemblera dostanie do ręki coś w stylu klocków duplo dla developerów

Jeśli programista potrafił spieprzyć głupi budzik, to powinien zmienić pracę.
Widzisz problem, ale go nie rozumiesz, więc próbujesz go ominąć zamiast naprawić...
Ludzie zasadniczo dzielą się na cztery kategorie - tych którzy potrafią zapamiętać, tych którzy potrafią zrozumieć, tych którzy potrafią jedno i drugie, oraz tych którzy nie potrafią nic.
Statystycznie najliczniejszą grupą są ci, którzy pamiętają ale nie rozumieją.
Człowiek który pamięta ale nie rozumie może zostać programistą i tworzyć kod wyjątkowo kiepskiej jakości, ale zasadniczo działający. Po prostu on pamięta, że określony ciąg znaków daje określony efekt, ale nie rozumie dlaczego tak się dzieje, ani tego że można albo powinno się to robić inaczej.
Kod takiego "programisty" wyjątkowo łatwo poznać, gdyż najprostsze rzeczy są tam robione w skomplikowany sposób i na jedno kopyto...
Tacy ludzie mogą znaleźć swoją niszę na wielkim rynku, ale nie powinni się brać za systemy operacyjne, czy jakiekolwiek programy na słabsze mikrokontrolery.
I żadne "klocki" nie poprawią kodu, kiedy programista jest najzwyczajniej głupi.

Zakładzasz że jedynym źrudłem problemów jest brak kompetencji - jest jeszcze lenistwo*. Marzy mi się środowisko programistyczne które automatycznie wykrywa "optymalizacje" łamiące zasady sztuki programistycznej (oraz zdrowego rozsądku) a następnie wali winnego po pysku...
Na podstawie własnych doświadczeń - przypuszczam że nowi, niedoświadczeni progamiści wyszli by z tego bez większych obrażeń bo kiedy napotykają problem zaczynają zadawać pytania i potrafią zaakcepotwać odpowiedzi a nie biorą się za hakowanie systemu

* - uważam że są dwa rodzaje lenistwa - "poświęć godzinę teraz żeby zaoszczędzić sobie dnia roboty za pół roku" oraz "zrób teraz na odwal".

Chyba wiem, o co Ci chodzi, ale... Linux chcąc trafić pod strzechy, musiał się z pewnymi rozwiązaniami pożegnać. Pamiętam czasy, gdy instalacja "pingwina" rozpoczynała się od przekopania się przez dziesiątki okien konfiguracyjnych, nierzadko wyświetlanych w trybie tekstowym z semigrafiką, gdzie trzeba było samemu wybrać pakiety i dbać o zależności. Owszem, daje to system skrojony na miarę, bez zbędnych dodatków (jeszcze lepszy jest, gdy sam sobie jądro skompilujesz), o minimalnej wadze, ale to rozwiązanie jest wybitnie hardkorowe, nie zachęcisz takim podejściem "przeciętnego Kowalskiego" do skorzystania z twojej dystrybucji. I dobrze tu wskazałeś przykład Debiana, który zachował poniekąd opcje dla zaawansowanych, podtykając pospólstwu pod nos gotowe (full-wypas) rozwiązanie. Wymieniłbym w tym miejscu dystrybucje takie jak SUSE, czy EuroLinux, które zachowują się w podobny sposób... a gdy ktoś chce powrócić do korzeni, to proszę bardzo, choć odpłatnie - RHEL.