Re: zmniejszenie WinSxS

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
duży plik wykonywalny to albo zawiera dane nie będące kodem albo kod
nieużywany (np. statczycznie zlinkowaną bibliotekę).

> 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.

>> 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.

>> 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.

> Poza tym, ileż to bajtów programu musi być do sprawdzenia tego
> przekroczenia użyte?

Nie wiem ile, to tylko przkład.

> 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ę?

> 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?

> 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.

> 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ń/>

> 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.

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
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ć.

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

-- 
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i aktualności ze świata Outlook Express: grzegorz.net/oe
Uptime: 1 day, 23 hours, 35 minutes and 1 second