Komentowana treść: AmigaGPT 2.6.0
08.05 20:08
[#1]
Re: AmigaGPT 2.6.0
Jak to wytłumaczyć?
AmigaGPT dla m68k zajmuje niecałe 200kb, dla OS4 - prawie 400kb, a wersja dla MOS to już 4.72MB.
Gdzie jest "haczyk"?
AmigaGPT dla m68k zajmuje niecałe 200kb, dla OS4 - prawie 400kb, a wersja dla MOS to już 4.72MB.
Gdzie jest "haczyk"?
08.05 20:20
[#3]
Re: AmigaGPT 2.6.0
@Norbert, post #1
Libc? czy cuś takiego co się linkuje po kompilacji z binarką wynikową? Czet Dżepet a raczej jego kuzyn z X:
Różnice w rozmiarach plików AmigaGPT dla różnych systemów (m68k, AmigaOS 4, MorphOS) wynikają z kilku czynników:
Haczyk: Nie ma tu ukrytego problemu – różnice wynikają z wymagań sprzętowych, systemowych i sposobu kompilacji. MorphOS, jako bardziej nowoczesny system, wymaga większego pliku binarnego, by wykorzystać jego możliwości. Jeśli chcesz szczegółów, mogę przeanalizować pliki na GitHubie lub Aminecie, jeśli podasz linki!
Różnice w rozmiarach plików AmigaGPT dla różnych systemów (m68k, AmigaOS 4, MorphOS) wynikają z kilku czynników:
- Architektura procesora: Wersja dla m68k (AmigaOS 3.1) jest zoptymalizowana dla starszych procesorów Motorola 68000, co wymaga mniejszego i bardziej kompaktowego kodu. Wersja dla AmigaOS 4 (PowerPC) jest większa, bo musi obsługiwać nowszą architekturę i bardziej złożone instrukcje. MorphOS, również na PowerPC, ma największy plik, prawdopodobnie z powodu dodatkowych bibliotek lub optymalizacji specyficznych dla tego systemu.
- Biblioteki i zależności: MorphOS może wymagać dołączania większej liczby bibliotek (np. związanych z kompatybilnością lub interfejsem graficznym), co znacząco zwiększa rozmiar pliku. AmigaOS 4 używa mniejszego zestawu bibliotek, a AmigaOS 3.1 jeszcze mniejszego, bo system jest prostszy.
- Optymalizacja kodu: Wersja dla m68k została zoptymalizowana (jak wspomniano w poście), co pozwoliło zredukować rozmiar. Wersje dla nowszych systemów mogą zawierać więcej funkcji lub mniej agresywną optymalizację, co zwiększa rozmiar.
- Sposób kompilacji: Różne kompilatory i ustawienia dla każdej platformy mogą generować kod o różnej wielkości. MorphOS mógł zostać skompilowany z większym zestawem opcji lub debugowania, co tłumaczy 4,72 MB.
Haczyk: Nie ma tu ukrytego problemu – różnice wynikają z wymagań sprzętowych, systemowych i sposobu kompilacji. MorphOS, jako bardziej nowoczesny system, wymaga większego pliku binarnego, by wykorzystać jego możliwości. Jeśli chcesz szczegółów, mogę przeanalizować pliki na GitHubie lub Aminecie, jeśli podasz linki!
09.05 10:50
[#8]
Re: AmigaGPT 2.6.0
@Norbert, post #1
To na kazdym exeku tak jest z PPC, na MAC-u tez (mozesz sprawdzic programy ktore maja wersje 68k i PPC w archiwum)
Jest on przecietnie 2 razy wiekszy nawet jak to jest ta sama gra czy program.
Wynika to z tego ze to jest 64 bitowy procesor a nie 32 bitowy, i do tego zle zaprojektowany.
Meynaf twierdzi, ze przez to jest tez malo wydajny i ze przez to przegral z x86, bo po prostu przy tej samej wielkosci cache mniej instrukcji sie tam zmiesci.
W cache x86 zmiesci sie wiecej instrukcji niz w cache PPC, o ile to nie wiem, bo to nie moja domena.
Meynaf nazywa to "code density".
Ale przegladalem Macowe exeki z PPC, gdy robil port HOMM2 z Maca (tam tez jest wersja PPC).
To ta wersja exeka wygladala dziwnie dla mnie, mnostwo zer w programie bylo, z tego co pamietam.
Cos jakby uzywac move.l #$00000001,D0 zamiast moveq #1,D0 na 68k.
Jest on przecietnie 2 razy wiekszy nawet jak to jest ta sama gra czy program.
Wynika to z tego ze to jest 64 bitowy procesor a nie 32 bitowy, i do tego zle zaprojektowany.
Meynaf twierdzi, ze przez to jest tez malo wydajny i ze przez to przegral z x86, bo po prostu przy tej samej wielkosci cache mniej instrukcji sie tam zmiesci.
W cache x86 zmiesci sie wiecej instrukcji niz w cache PPC, o ile to nie wiem, bo to nie moja domena.
Meynaf nazywa to "code density".
Ale przegladalem Macowe exeki z PPC, gdy robil port HOMM2 z Maca (tam tez jest wersja PPC).
To ta wersja exeka wygladala dziwnie dla mnie, mnostwo zer w programie bylo, z tego co pamietam.
Cos jakby uzywac move.l #$00000001,D0 zamiast moveq #1,D0 na 68k.
09.05 10:55
[#9]
Re: AmigaGPT 2.6.0
@recedent, post #6
W skrócie tak, z dwiema uwagami.
Po pierwsze na AmigaOS 4 i tak będziesz już miał AmiSSL zainstalowane, chociażby do przeglądarki.
Po drugie MorphOS ma swoją implementację OpenSSL jako bibliotekę systemową. Tylko że ona nie jest kompatybilna z AmiSSL. Wersja MorphOS-owa mogłaby więc też być "chudsza", ale trzebaby jej poświęcić więcej pracy.
Po pierwsze na AmigaOS 4 i tak będziesz już miał AmiSSL zainstalowane, chociażby do przeglądarki.
Po drugie MorphOS ma swoją implementację OpenSSL jako bibliotekę systemową. Tylko że ona nie jest kompatybilna z AmiSSL. Wersja MorphOS-owa mogłaby więc też być "chudsza", ale trzebaby jej poświęcić więcej pracy.
09.05 23:06
[#11]
Re: AmigaGPT 2.6.0
@Norbert, post #10
Tylko, ze wtedy musisz doliczyc OpenSSL do wersji OS4, i wtedy mozna porownywac, tak samo jak mozesz dodac OpenSSL dla wersji 68k, i porownac. Podejrzewam, ze calosc i tak bedzie minimum 2 razy mniejsza niz dowolna wersja PPC.
Bo np. jak kompilujesz AMOS-em, to tez mozesz albo dolaczyc AMOS.library do exeka, albo uzywac zewnetrznie.
Raz taki exek bedzie wiekszy a raz mniejszy.
Bo np. jak kompilujesz AMOS-em, to tez mozesz albo dolaczyc AMOS.library do exeka, albo uzywac zewnetrznie.
Raz taki exek bedzie wiekszy a raz mniejszy.
09.05 23:08
[#12]
Re: AmigaGPT 2.6.0
@radekcz, post #3
https://github.com/sacredbanana/AmigaGPT/blob/master/Makefile.OS4
https://github.com/sacredbanana/AmigaGPT/blob/master/Makefile.MorphOS
dwie ważne różnice przy linkowaniu które na pewno wpływają na wielkość pliku wynikowego:
AOS4
LDFLAGS = -Wl,-Map=$(EXECUTABLE_OUT).map,-L$(LIBDIR),-L$(SDKLIBDIR),-lm,-lamisslstubs,-ljson-c,-lauto
MOS
LDFLAGS = -Wl,-Map=$(EXECUTABLE_OUT).map,-L$(LIBDIR),-L$(SDKLIBDIR),-lm,-ljson-c,-lssl,-lcrypto,-L$(GCCLIBDIR),-latomic
Ostatnia aktualizacja: 09.05.2025 23:12:29 przez Rafael/ARMO
https://github.com/sacredbanana/AmigaGPT/blob/master/Makefile.MorphOS
dwie ważne różnice przy linkowaniu które na pewno wpływają na wielkość pliku wynikowego:
AOS4
LDFLAGS = -Wl,-Map=$(EXECUTABLE_OUT).map,-L$(LIBDIR),-L$(SDKLIBDIR),-lm,-lamisslstubs,-ljson-c,-lauto
MOS
LDFLAGS = -Wl,-Map=$(EXECUTABLE_OUT).map,-L$(LIBDIR),-L$(SDKLIBDIR),-lm,-ljson-c,-lssl,-lcrypto,-L$(GCCLIBDIR),-latomic
Ostatnia aktualizacja: 09.05.2025 23:12:29 przez Rafael/ARMO
10.05 16:37
[#13]
Re: AmigaGPT 2.6.0
@Don_Adan, post #8
Wynika to z tego ze to jest 64 bitowy procesor a nie 32 bitowy, i do tego zle zaprojektowany.Gdy piszesz kod 32-bitowy dla PowerPC to na jego wielkość nie wpływa zupełnie, czy procesor, który będzie go wykonywał, jest 32-bitowy, czy 64-bitowy.
Meynaf twierdzi, ze przez to jest tez malo wydajny i ze przez to przegral z x86, bo po prostu przy tej samej wielkosci cache mniej instrukcji sie tam zmiesci.
Wielkość kodu PowerPC wynika z architektury RISC i podejścia load-store. To drugie polega na tym, że instrukcje przetwarzające dane operują tylko na rejestrach, do wymiany danych między rejestrami a pamięcią są oddzielne instrukcje.
Jeżeli przyjmiemy, że wybór przez twórców procesora PowerPC architektury RISC jest "złym zaprojektowaniem", to OK. Z drugiej jednak strony, x86_64 jest praktycznie jedynym nie-RISCem, który jest popularny. ARM to RISC, RISC-V to... wiadomo. Tak naprawdę wewnątrz procesory x86_64 to też RISC-e, które emulują x86.
To ostatnie posunięcie, oraz problemy Motoroli z przechodzeniem na nowsze procesy technologii półprzewodnikowej pozwoliły x86 uniknąć techologicznej przegranej i wykorzystać nietechnologiczne przewagi. A nie to ile się rozkazów mieści w cache...