17.01.2013 11:38
[#1]
Dlaczego programy w Amosie zajmują tak dużo?
Zastawiam się dlaczego programy po skompilowaniu zajmują tak dużo. Moja gierka waży prawi pół mega a prosty kod z paroma komendami 10kb. Od razu mówię, że nie dodaje biblioteki amos.library do programu. Użycie squasha zmniejsza program o parędziesiąt kilo. Sądzę, że coś jest nie tak bo skoro taka prosta gra waży pół mega to taki logion czy astral musiały by wazyć po 10 mega.
Benedykt Dziubałtowski
Benedykt Dziubałtowski
17.01.2013 14:53
[#6]
Re: Dlaczego programy w Amosie zajmują tak dużo?
@Benedykt Dziubałtowski, post #1
Cos jest nie tak. Wiekszosc bibliotek wlaczanych do programu w czasie kompilacji powinna zajmowac nieco ponad 100kb plus kod twojej gry i banki pamieci, to nastepne gora 100kb zatem wychodzi 200kb. Czyli "cos" zezarlo jeszcze raz tyle pamieci ile powinno i to "cos" nie jest przyjazne.
17.01.2013 16:56
[#7]
Re: Dlaczego programy w Amosie zajmują tak dużo?
@cholok, post #4
No to tylko pogratulować kompilatora, za wrzucanie do kodu wynikowego nie używanych funkcji.
Tak przy okazji, to takie zjawisko nie występuje tylko w AMOSie, tutaj jeden biedak otrzymuje kod plik powyżej 500kB przy programie typu "hello world" .
Jeśli AMOS nie ma optymalizacji kompilacji, to pozostaje ci np wykonanie tej samej operacji stosując inne polecenia (jeśli się da).
Ostatnia aktualizacja: 17.01.2013 17:14:39 przez rafgc
Tak przy okazji, to takie zjawisko nie występuje tylko w AMOSie, tutaj jeden biedak otrzymuje kod plik powyżej 500kB przy programie typu "hello world" .
Jeśli AMOS nie ma optymalizacji kompilacji, to pozostaje ci np wykonanie tej samej operacji stosując inne polecenia (jeśli się da).
Ostatnia aktualizacja: 17.01.2013 17:14:39 przez rafgc
17.01.2013 19:09
[#10]
Re: Dlaczego programy w Amosie zajmują tak dużo?
@rafgc, post #7
AMOS tak ma. Kompilatory Basica chyba rzadko są w stanie wygenerować zoptymalizowany wielkościowo kod - nie używa się przecież instrukcji preprocesora w rodzaju #include. Zresztą same instrukcje Basica są mocno wysokopoziomowe, więc linkowane biblioteki muszą być duże. To nie jest C.
17.01.2013 21:29
[#15]
Re: Dlaczego programy w Amosie zajmują tak dużo?
@wali7, post #10
A co tu ma do rzeczy czy to C czy nie, nie używane funkcje nie powinny być dołączane do pliku wynikowego, widocznie ktoś poszedł w Amosie na łatwiznę i wykorzystanie jednego polecenia z danego zbioru powoduje dołączanie całej biblioteki (tak jak wczytywanie jakiejś #?.library aby skorzystać z jednej funkcji) do wyniku. W czym tkwiłby problem, gdyby zamiast podłączania całej biblioteki pozostawić z niej tylko polecenia wykorzystywane w programie (chyba, że jedno polecenie samo w sobie korzysta z innych poleceń danej biblioteki)? Optymalizacja kodu a wycinanie niepotrzebnych rzeczy, to dwie różne rzeczy (choć i jedno i drugie można nazwać optymalizacją, z tym, że w przypadku tej drugiej opcji nie potrzeba żadnych algorytmów, tylko wykluczenia kodu, do którego nie ma żadnych odwołań).
17.01.2013 22:20
[#16]
Re: Dlaczego programy w Amosie zajmują tak dużo?
@rafgc, post #15
Kompilatory Basica rzadko są specjalnie zoptymalizowane - w końcu Basic to język interpretowany, a możliwość jego kompilacji jest tylko opcją.
A zwróć też uwagę na fakt, że instrukcje Basica są dosyć wysokopoziomowe: przykładowo, aby kompilator Basica przeprowadził skuteczną optymalizację komendy w rodzaju I=I+B należałoby wykonać dokładną analizę kodu (automatyczną) czego można się spodziewać w I, oraz B: liczby stało, czy zmiennoprzecinkowej i o jakiej precyzji. Basic (w odróżnieniu od m.in. C) nie definiuje tak dokładnie typów zmiennych, więc linkowana procedura musi obejmować wszystkie możliwości (z których w programie wynikowym zostanie wykorzystana tylko część) - musi być duża i mniej wydajna (bo gdzieś trzeba sprawdzić typ i wykonać skok do właściwej podprocedury obsługującej go).
Przykładem względnie wysokopoziomowej instrukcji w C jest printf: zawarte w niej możliwości formatowania i przyjmowania najrozmaitszych typów argumentów czynią ją naprawdę sporą (warto sprawdzić jak wpływa na wynikowy kod jej dolinkowanie). Po przeciwnej stronie jest inkrementacja ++ - w wielu przypadkach kompilowana do jednej instrukcji CPU.
A Basic (czyli także AMOS) ma wyłącznie instrukcje dosyć uniwersalne (co z jednej strony jest ich zaletą), ale właściwie nie nadające się do optymalizacji w fazie linkowania. Nawet jeśli instrukcje nieużywane nie są linkowane (to akurat da się zrobić dosyć prosto), to i tak procedury tych dolinkowanych MUSZĄ być duże. Więc plik wynikowy będzie duży.
PS. Można to prosto sprawdzić doświadczalnie: napisać cokolwiek np.
10 print "qwerty"
20 rem pusty komentarz
30 rem if 10 then print "uiop"
40 goto 10
następnie skompilować to. Zanotować rozmiar i usunąć rem z linii 30, ponownie skompilować. Jeśli długość kodu wynikowego będzie się różnić bardzo nieznacznie, to będzie znaczyć, że w obu przypadkach zostały dolinkowane nieużywane instrukcje.
Ostatnia aktualizacja: 17.01.2013 22:31:51 przez wali7
A zwróć też uwagę na fakt, że instrukcje Basica są dosyć wysokopoziomowe: przykładowo, aby kompilator Basica przeprowadził skuteczną optymalizację komendy w rodzaju I=I+B należałoby wykonać dokładną analizę kodu (automatyczną) czego można się spodziewać w I, oraz B: liczby stało, czy zmiennoprzecinkowej i o jakiej precyzji. Basic (w odróżnieniu od m.in. C) nie definiuje tak dokładnie typów zmiennych, więc linkowana procedura musi obejmować wszystkie możliwości (z których w programie wynikowym zostanie wykorzystana tylko część) - musi być duża i mniej wydajna (bo gdzieś trzeba sprawdzić typ i wykonać skok do właściwej podprocedury obsługującej go).
Przykładem względnie wysokopoziomowej instrukcji w C jest printf: zawarte w niej możliwości formatowania i przyjmowania najrozmaitszych typów argumentów czynią ją naprawdę sporą (warto sprawdzić jak wpływa na wynikowy kod jej dolinkowanie). Po przeciwnej stronie jest inkrementacja ++ - w wielu przypadkach kompilowana do jednej instrukcji CPU.
A Basic (czyli także AMOS) ma wyłącznie instrukcje dosyć uniwersalne (co z jednej strony jest ich zaletą), ale właściwie nie nadające się do optymalizacji w fazie linkowania. Nawet jeśli instrukcje nieużywane nie są linkowane (to akurat da się zrobić dosyć prosto), to i tak procedury tych dolinkowanych MUSZĄ być duże. Więc plik wynikowy będzie duży.
PS. Można to prosto sprawdzić doświadczalnie: napisać cokolwiek np.
10 print "qwerty"
20 rem pusty komentarz
30 rem if 10 then print "uiop"
40 goto 10
następnie skompilować to. Zanotować rozmiar i usunąć rem z linii 30, ponownie skompilować. Jeśli długość kodu wynikowego będzie się różnić bardzo nieznacznie, to będzie znaczyć, że w obu przypadkach zostały dolinkowane nieużywane instrukcje.
Ostatnia aktualizacja: 17.01.2013 22:31:51 przez wali7
18.01.2013 01:05
[#18]
Re: Dlaczego programy w Amosie zajmują tak dużo?
@Benedykt Dziubałtowski, post #17
"Rozmiar gry spadł z 440kb na 220"
Nie rozmiar gry, tylko pliku po kompilacji a rozmiar gry jest jeszcze wiekszy niz owe 440kb (bo te banki i tak beda zaladowane do pamieci z dysku/dyskietki) czyli ogolnie twoja gra wymaga pewnie juz ponad pol megabajta.
Troche duzo jak na gre logiczna i warto by wyjasnic dlaczego tyle zajmuje. Moze napisz co jest w tych bankach i ile kb one zajmuja.
Nie rozmiar gry, tylko pliku po kompilacji a rozmiar gry jest jeszcze wiekszy niz owe 440kb (bo te banki i tak beda zaladowane do pamieci z dysku/dyskietki) czyli ogolnie twoja gra wymaga pewnie juz ponad pol megabajta.
Troche duzo jak na gre logiczna i warto by wyjasnic dlaczego tyle zajmuje. Moze napisz co jest w tych bankach i ile kb one zajmuja.
18.01.2013 06:05
[#20]
Re: Dlaczego programy w Amosie zajmują tak dużo?
@Benedykt Dziubałtowski, post #17
1. Wczytaj edytor AMOS-a
2. Wczytaj swój plik .amos i NIE URUCHAMIAJ
3. Z menu Project wybierz opcję INFORMATION
4. Interesuje Cię tam TEXT LENGTH oraz BANK LENGTH. Ta druga powinna wynosić 0 chyba, że tworzysz program, który ma nie doczytywać danych i wszystko będzie w jednym pliku. Zakładam, że tak nie robisz.
5. Skopiuj cały tekst i wklej do nowego projektu. Banki powinny się wyczyścić.
6. Zapisz nowy projekt. Powinien być odpowiednio mniejszy.
7. Skompiluj.
2. Wczytaj swój plik .amos i NIE URUCHAMIAJ
3. Z menu Project wybierz opcję INFORMATION
4. Interesuje Cię tam TEXT LENGTH oraz BANK LENGTH. Ta druga powinna wynosić 0 chyba, że tworzysz program, który ma nie doczytywać danych i wszystko będzie w jednym pliku. Zakładam, że tak nie robisz.
5. Skopiuj cały tekst i wklej do nowego projektu. Banki powinny się wyczyścić.
6. Zapisz nowy projekt. Powinien być odpowiednio mniejszy.
7. Skompiluj.
18.01.2013 10:15
[#27]
Re: Dlaczego programy w Amosie zajmują tak dużo?
@Benedykt Dziubałtowski, post #9
Kod zajmuje koło 330kb. Da się dograć banki do pliku wynikowego?
Z tego co wiem to wszystkie załadowane banki domyślnie zapisują się razem z programem amosa. Po skompilowaniu takiego pliku banki dołączone są do pliku wynikowego. Jeśli chcesz mieć sam program to przed zapisem należy skasować banki komendą "Erase All"
