Re: zmniejszenie WinSxS

Autor: Sempiterna <rzopa_at_amorki.pl>
Data: Thu 03 Sep 2009 - 01:57:43 MET DST
Content-Type: text/plain; format=flowed; charset="iso-8859-2"; reply-type=response
Message-ID: <4a9f0677$1@news.home.net.pl>

Użytkownik "Grzegorz Niemirowski" <gnthexfiles@poczta.onet.pl> napisał w
wiadomości news:h7mtur$2tla$1@opal.icpnet.pl...
> Sempiterna <rzopa@amorki.pl> napisał(a):
>> Skoro różna ilość kodu po drodze nie zmienia szybkości działania
>> programu, to albo gdzieś są puste pętle opóźniające, albo wuchta kodu
>> jest na zalepienie dziur w płocie. Albo procek działa jakoś
>> magicznie...
>> Poza tym, odwrociłeś nieco kotka w przeciwną stronę - chodziło mi o
>> małę programy dające nie wiem po co duży kod wynikowy. Porównanie w
>> Pascalu dostałeś.
>
> Kompilator dba o optymalizację i stara się generować szybki kod. Jak
> jest

No, w sumie tak... ale kompilator sam jest programem, który w czymś
został napisany, skompilowany, a jeśli ta komplacja, wskutek albo błędu,
albo nienajlepszego algorytmu, da wynik powolniejszy...?

> duży plik wykonywalny to albo zawiera dane nie będące kodem albo kod
> nieużywany (np. statczycznie zlinkowaną bibliotekę).

W sytuacji, gdy zdarza się, że każdy wolny bajt jest cenny? (mimo, że
już są terabajtowe dyski, gigabajtowe pamiątki, gigahercowe procki...)

>
>> Bo nie przetłumaczysz mi, że te same / takie same programy, wymagają
>> coraz większej ilości kodu. Śmiem twierdzić, że to coraz bardziej
>> polega na tym, ze skoro sprzęt coraz szybszy, to już nie trzeba tak
>> bardzo pieścić się z mocożernością...
>
> Ależ oczywiście masz rację. Dlatego istnieje Java i .NET.

Ja rozumiem, że chodzi np. o uniwersalność, czyli ten sam kod "runie" na
PC, na Alfie, PPC, Makówce, Amidze... to ok, uniwersalność kosztem
wydajności, wiadomo, nic za darmo. Tylko dlaczego rozbuchanie kodu
dzieje się tam, gdzie nie powinno?

>
>>> To już się programistów pytaj co ten kod robi. System wcale nie każe
>>> kompilatorowi generować wielkiego kodu. Poza tym pamiętaj, że w
>>> programie
>> To kompilator nie jest programem samodzielnym?
>
> Nie rozumiem.

Napisałeś "system nie każe kompilatorowi", czyli jak np. odpalam
kompilator, a moja Szklarenka ma nagle coś i mówi mu np. "kompiluj pod
AMD"... To chyba programista, czy deklaracje w kodzie, o tym decyduj.ą,
a nie system, na którym kompilator jest odpalany? Chyba, że ostatnio coś
się zmieniło i doszłą interakcja? Rozumiem standardowo, bo np.
kompilator wczytuje kod z pliku na dysku, a o plik prosi system, system
może mu dać plik, ale także zakomunikować "pliku nie ma", etc. Kompilat
musi być zapisany, aby można potem go samodzielnie odpalić...?

>
>>> może być nie tylko kod napisan przez Ciebie ale także sprawdzający
>>> wyjątki, np. wyjście poza zakres tablicy.
>> Której akurat może w programie nie być...
>
> Oczywiście.

To automatycznie, niepotrzebny zasób, powinien nie być dołączany do
wyniku, bo dołączony, staje sie śmieciem, który zajmuje pamięć,
niedostępną już dla innych, potrzebniejszych zasobów.

>
>> Poza tym, ileż to bajtów programu musi być do sprawdzenia tego
>> przekroczenia użyte?
>
> Nie wiem ile, to tylko przkład.

Rozumiem. Nie mogę jednak oprzeć sie wrażeniu, że wspłczesny kod jest
tym, jak stary dowcip o malarstwie współczesnym, trochę niesmaczny:
"Nasrałbym na płótno, rozmazał, poczekał, aż zaschnie, i zatytułowałbym
go }}Orgazm niedźwiedzia{{". Już bardziej jestem w stanie pojąć
malarstwo Picassa...

>
>> Napisałem -
>> program hej;
>> begin;
>> writeln ('Cześć, jak się masz?');
>> end.
>> I już, napisałem wszystko sam, wystarczy.
>
> A writeln to co? Też sam napisałeś tę funkcję?

Program napisałem. Tekst zajmuje 63 bajty.

>
>> Czyli to nie jest czysty asembler, tylko hybryda tak zatytułowana.
>> Wyrysowanie okienka, daję powiedzmy, 200-300 bajtów, program drugie
>> 200, na różności, procedury, pomnożenie przez 2, na "przyklepanie"
>> drugie pomnożenie... dwa kibobajty mamy, a nie np. 100 razy tyle.
>
> Dlaczego nie ma być czysty? Bo są makra użyte?

Czy makro jest rozpisane na kod maszynowy?

>
>> Wolę często napisać dwa kilobajty sam, niż z jakichś przypadłości,
>> czy to kompilatora, czy bibliotek, otrzymać wynik nawet
>> półmegabajtowy... a program miał służyć do dekodowania pewnego
>> prostego szyfru, którego algorytm zmieści się może w 2-3 kilobajtach
>> tekstu... W wolnej chwili pokuszę się o przeliczenie tego na
>> kalkulatorze...
>
> Proste programy nadal mają kilka-kilkanaście kB.

Co na dzisiejsze czasy jest do przyjęcia. Problem zaczyna się, gdy takie
same, robiące to samo, programy, nagle zaczynają mieć nie po 15-20, ale
po 150-200 kB, a nawet więcej...

>
>> No, jeszcze bym zrozumiał, gdyy kompilator tworzył po prostu
>> zarezerwowane miejsce, aby od razu po wczytaniu programu mieć gotową
>> przestrzeń roboczą, aby nie musieć rezerwować jej osobno...
>
> Jaką przestrzeń/>

Może to z dawnych czasów, niekiedy w pliku EXE było sporo wolnego
miejsca gdzieś w środku, co wyśledzone dawało np. miejsce dla spraw
"roboczych" programu (na zmienne np.), czy np. w jednym pliku był
program, dane, konfiguracja... Rozuimem, zapisama np. bitmapa z wyglądem
czołówki, OK, łyknę to.

>
>> Cóż, wyrosłem w czasach, kiedy każdy wolny bajt był cenny...
>
> A teraz czasy są inne i walka o każdy kilobajt jest nieopłacalna.

Tylko, że tak myśląc, bezkrytycznie, dojdziemy kiedyś do tego, że aby
odpalić calc.exe, (w XP 115200 bajtów, dużo IMO), będziemy musieli
znaleźć plik o objętości 50 MB, odpalalny na maszynie minimum 3 GHz, z 8
GB RAM, bo tyle będzie wymagać sam system, by w ogóle pracować, jako
absolutne minimum. Pamięci nie są z gumy. Ich możliwości kiedyś się
wreszcie skończą, a wtedy ręka w nocniku...

>
> Poza tym rozróżnijmy dwie sprawy:
> 1) wielkość pliku wykonywalnego
> 2) wielkość segmentów kodu
>
> Ad1. Nie ma większego znaczenia bo a) wielkość pliku wkonywalnego nie
> jest żadnym wskaźnikiem gdyż plik wykonywalny zawiera nie tylko kod b)
> to nie od plików exe zapychają się dyski

Od bajtów. Ich powinno być jak najmniej. Jeśli Kowalski ma duży dysk,
zajęte 10 %, to mu rybka pipka, czy program ma 10, czy 50 MB, aby
działał. Jednak w sytuacji, gdy miejsca mi na dysku brakuje (a taką
właśnie mam, musiałem zrzucić ok. 100 GB backupów, by zacząć w ogóle
porządki), to dla mnie każdy klobajt jest cenny. Byłbym więc zobowiązany
programistom, aby kompilator NIE DOŁĄCZAŁ kodu, który nie jest potrzebny
i nie zostanie nigdy wykonany. Tak, on zapycha dysk.

> Ad2. Duży kod nie musi być niczym złym. Wywołania procedur są dosyć
> drogie i dlatego czasem opłaca się kopiować kod w wielu miejscach
> zamiast do niego skakać. W języku C++ jest słówko kluczowe inline żeby
> takie działanie kompilatorowi jawnie zalecić.

Ależ tak, jeśli rzeczywiście tak się opłaca, to błogosławię. Czasem
jednak odnoszę wrażenie, ze rozmiar kodu, to pójście na łatwiznę.

>
> Tutaj jeszcze obrazek z pliku w którym kod wykonywalny stanowi kilka
> procent zawartości pliku:
>
> C:\Documents and Settings\Administrator\Moje
> dokumenty\STM32_USB-FS-Device_Lib_V
> 3.0.1\Project\Virtual_COM_Port\EWARMv5\STM3210E-EVAL\Exe>dir
> Wolumin w stacji C nie ma etykiety.
> Numer seryjny woluminu: D098-AE0E
>
> Katalog: C:\Documents and Settings\Administrator\Moje
> dokumenty\STM32_USB-FS-De
> vice_Lib_V3.0.1\Project\Virtual_COM_Port\EWARMv5\STM3210E-EVAL\Exe
>
> 2009-09-02 13:41 <DIR> .
> 2009-09-02 13:41 <DIR> ..
> 2009-09-02 13:41 322 064 VirtualCOMPort.out
> 2009-09-01 22:18 13 595 VirtualCOMPort.sim
> 2009-09-01 22:18 13 595 VirtualCOMPort.sim._1
> 3 plik(ów) 349 254 bajtów
> 2 katalog(ów) 9 312 059 392 bajtów wolnych
>
> C:\Documents and Settings\Administrator\Moje
> dokumenty\STM32_USB-FS-Device_Lib_V
> 3.0.1\Project\Virtual_COM_Port\EWARMv5\STM3210E-EVAL\Exe>"C:\Program
> Files\IAR S
> ystems\Embedded Workbench 5.0 Kickstart\ARM\bin\size.exe"
> VirtualCOMPort.out
> text data bss dec hex filename
> 13672 0 1856 15528 3ca8 VirtualCOMPort.out

Jeśli pozostałe miejsce jest potrzebne np. na rezerwację obszaru
zmiennych, aby nie bujać systemu ich deklaracją i "zastanawianiem",
gdzie umieścić, czy np. to jest bitmapa z obrazkiem (np. ikony zaszyte w
kodzie), czy porcja danych na poczatek, bądź bufor na produkty ich
obróbki, to OK. Jeśli to puste, niewykorzystane miejsce... to trudno mi
to pojąć. Rozumiem, że może być czasem potrzebne wyrównanie określonej
porcji kodu (gubiłem fachową nazwę tego...) do określonego... offsetu?,
a takich małych porcji może ileś być, a jest ich dużo, same porcje np.
po 10 kB, a rozmieszczone muszą być co 64,jest ich np. tysiąc i między
nei nie może być nic wciśnięte... rozumiem, może być. Ale nie zawsze
widzę, by tak się działo.
Ja zdaję sobie sprawę, że Windows narzuca pewne wymagania i nie da się
zrobić nawet takiego prostego programu,
10 INPUT "PODAJ IMIĘ"; A$
20 PRNT "WITAJ" + A$+ ", NAZYWAM SIĘ KOMPUTER"
 w 100 bajtach kompilatu. Ale niech to będzie naprawdę tylko tyle, ile
jest naprawdę niezbędne, bez dołączania rzeszy procedur... Dla mnie do
przyjęcia będzie kompilat do 4 kB, chyba, ze "narzut Szklarniowy" będzie
większy...

-- 
"E, tam, oszukaństwo, oszukaństwo... Zwyczajna polityka!"
(C) Kazimierz Pawlak, do Kargula, o pomalowanej czarną pastą świni;
"Nie ma mocnych" - druga część tryptyku.
Received on Thu Sep 3 02:00:03 2009

To archiwum zostało wygenerowane przez hypermail 2.1.8 : Thu 03 Sep 2009 - 02:42:00 MET DST