> Nie jesteś w stanie przeprowadzić doświadczenia, jest zbyt kosztowne.
> Możesz liczyć jednak że exe będzie miał powiedzmy 2GB rozmiaru jesli
> suma dllek jest rzedu 2.5GB.

To ciekawa wartość. Bo np. o Linuksie (o jądrze, co niektórzy używają jako jakiś
znany punkt odniesienia w dyskusji o rozmiarach) mówi się, że ma ileś tam milionów
linii kodu i to jest warte ileś tam tysięcy lat pracy a po skompilowaniu jest tego
jakieś tam... megabajty. A tu mamy w dyskusji gigabajty. Z tego by wynikało, że tego
programu jest powiedzmy dwa rzędy wielkości więcej, niż Linuksa, czyli na oko miliard
linii kodu i milion lat pracy. Co z kolei każe poddać pod wątpliwość, czy w ogóle
taki program dało się na tej planecie napisać. A jeśli uznamy, że się nie dało, to
wniosek jest taki, że binarka jest rozdmuchana i pewnie da się z niej coś zdjąć.

Dla przykładu, ostatnia gigantyczna DLLka jaką widziałem, miała w sobie wpałowany
jako resource jakiś odjechany jeden plik z danymi. Po pouczeniu programistów, że tak
się nie robi (sprawa się rypła, bo się Visual na tym wywalał) i wyrzuceniu pliku
do... osobnego pliku (wczytywanego przez program w razie potrzeby!), DLLka schudła do
kilobajtów i chyba w ogóle przestała być potrzebna.
Może to jest jakiś trop?

W każdym razie, ja nie umiałbym naklepać tyle kodu (nawet z kolegami), żeby mi się
zrobiło z tego parę GB, więc jeżeli ktoś ma taką binarkę, to albo goście od Linuksa
mogą się od niego uczyć, albo on może się uczyć od gości od Linuksa, bo się te liczby
w jedną albo drugą stronę nie zgadzają.
No w każdym razie jakiś przepływ porad i doświadczeń byłby korzystny.

> b) ilośc zmiennych statycznych które musisz zainicjować od razu jest
> większa niż gdy aplikacja ladowana jest po kawałku, co spowolni proces
> startu.

A jeśli mam jedną zmienną statyczną, która jest kontenerem rzeczy, które będą do
niego dodane później?
Nie mylić statycznego linkowania ze statycznym zarządzaniem obiektami. Mój statycznie
zlinkowany program startuje szybciej, niż się ładuje z dysku, zmienne statyczne nie
mają związku ze statycznym linkowaniem.

> Jeśli chcesz zobaczyć *naprawdę* duże aplikacje to zerknij na rynek EDA.

Tak, wiem. Chyba w każdej dyskusji, jaką tu mieliśmy, miałem sobie tam zerkać. :-)

> Dla ilustracji: zakładając że masz 100MB kodu w dll i musisz szerować to
> między dwa exe (bo taką masz architekturę).

Jeśli w ogóle mam jakąś architekturę, to od razu zakładam, że jest rozproszona (i
zwykle tak jest, prędzej lub później). To znaczy, że dwa procesy raczej nie są na
jednym komputerze (albo nie mogę założyć, że będą) i wtedy dzielenie kodu za pomocą
DLL nie działa - tzn. nie ma żadnej wartości w kontekście oszczędzania pamięci.
Natomiast N komunikujących się statycznie zlinkowanych programów (być może na
niezależnych komputerach) działa wybornie, dając mi pełną swobodę wdrożeniową (której
DLL nie dają).

> Dla ilustracji2: wyobraź sobie że masz aplikację edytora która tylko
> wtedy kiedy trzeba laduje parser gramatyki Perla.

To jest przypadek, który opisałem na samym początku dyskusji (o pluginach, które są
częścią kultury używania programu). Nie mam problemu z tym, że takie coś jest w DLL.
Natomiast nadal mam problem z tym, że takie coś może być użyte tylko raz w czasie
działania programu - i pytanie, czy program zadba o to, żeby takiego niepotrzebnego
DLLa odpiąć. Jak zadba, to fajnie.
Nadal jest jeszcze opcja rozproszona, czyli parser w osobnym procesie (wtedy DLL i
tak nie jest potrzebny). Może to mieć sens, może nie mieć.

Niemniej, przykład binarki na kilka GB wzbudza u mniej więcej wątpliwości, niż mnie
przekonuje. Obliczenia powyżej.

--
Maciej Sobczak * http://www.inspirel.com

do góry

W dniu poniedziałek, 20 listopada 2017 13:42:30 UTC+1 użytkownik Maciej Sobczak
napisał:
> > Nie jesteś w stanie przeprowadzić doświadczenia, jest zbyt kosztowne.
> > Możesz liczyć jednak że exe będzie miał powiedzmy 2GB rozmiaru jesli
> > suma dllek jest rzedu 2.5GB.
>
> To ciekawa wartość. Bo np. o Linuksie (o jądrze, co niektórzy używają jako jakiś
znany punkt odniesienia w dyskusji o rozmiarach) mówi się, że ma ileś tam milionów
linii kodu i to jest warte ileś tam tysięcy lat pracy a po skompilowaniu jest tego
jakieś tam... megabajty. A tu mamy w dyskusji gigabajty. Z tego by wynikało, że tego
programu jest powiedzmy dwa rzędy wielkości więcej, niż Linuksa, czyli na oko miliard
linii kodu i milion lat pracy. Co z kolei każe poddać pod wątpliwość, czy w ogóle
taki program dało się na tej planecie napisać. A jeśli uznamy, że się nie dało, to
wniosek jest taki, że binarka jest rozdmuchana i pewnie da się z niej coś zdjąć.
>
> Dla przykładu, ostatnia gigantyczna DLLka jaką widziałem, miała w sobie wpałowany
jako resource jakiś odjechany jeden plik z danymi. Po pouczeniu programistów, że tak
się nie robi (sprawa się rypła, bo się Visual na tym wywalał) i wyrzuceniu pliku
do... osobnego pliku (wczytywanego przez program w razie potrzeby!), DLLka schudła do
kilobajtów i chyba w ogóle przestała być potrzebna.
> Może to jest jakiś trop?
>
> W każdym razie, ja nie umiałbym naklepać tyle kodu (nawet z kolegami), żeby mi się
zrobiło z tego parę GB, więc jeżeli ktoś ma taką binarkę, to albo goście od Linuksa
mogą się od niego uczyć, albo on może się uczyć od gości od Linuksa, bo się te liczby
w jedną albo drugą stronę nie zgadzają.
> No w każdym razie jakiś przepływ porad i doświadczeń byłby korzystny.
>
> > b) ilośc zmiennych statycznych które musisz zainicjować od razu jest
> > większa niż gdy aplikacja ladowana jest po kawałku, co spowolni proces
> > startu.
>
> A jeśli mam jedną zmienną statyczną, która jest kontenerem rzeczy, które będą do
niego dodane później?
> Nie mylić statycznego linkowania ze statycznym zarządzaniem obiektami. Mój
statycznie zlinkowany program startuje szybciej, niż się ładuje z dysku, zmienne
statyczne nie mają związku ze statycznym linkowaniem.
>
> > Jeśli chcesz zobaczyć *naprawdę* duże aplikacje to zerknij na rynek EDA.
>
> Tak, wiem. Chyba w każdej dyskusji, jaką tu mieliśmy, miałem sobie tam zerkać. :-)
>
> > Dla ilustracji: zakładając że masz 100MB kodu w dll i musisz szerować to
> > między dwa exe (bo taką masz architekturę).
>
> Jeśli w ogóle mam jakąś architekturę, to od razu zakładam, że jest rozproszona (i
zwykle tak jest, prędzej lub później). To znaczy, że dwa procesy raczej nie są na
jednym komputerze (albo nie mogę założyć, że będą) i wtedy dzielenie kodu za pomocą
DLL nie działa - tzn. nie ma żadnej wartości w kontekście oszczędzania pamięci.
Natomiast N komunikujących się statycznie zlinkowanych programów (być może na
niezależnych komputerach) działa wybornie, dając mi pełną swobodę wdrożeniową (której
DLL nie dają).
>
> > Dla ilustracji2: wyobraź sobie że masz aplikację edytora która tylko
> > wtedy kiedy trzeba laduje parser gramatyki Perla.
>
> To jest przypadek, który opisałem na samym początku dyskusji (o pluginach, które są
częścią kultury używania programu). Nie mam problemu z tym, że takie coś jest w DLL.
Natomiast nadal mam problem z tym, że takie coś może być użyte tylko raz w czasie
działania programu - i pytanie, czy program zadba o to, żeby takiego niepotrzebnego
DLLa odpiąć. Jak zadba, to fajnie.
> Nadal jest jeszcze opcja rozproszona, czyli parser w osobnym procesie (wtedy DLL i
tak nie jest potrzebny). Może to mieć sens, może nie mieć.
>
> Niemniej, przykład binarki na kilka GB wzbudza u mniej więcej wątpliwości, niż mnie
przekonuje. Obliczenia powyżej.
>
oczywiscie te exeki na kilka GB to jakas bzdura (az dziwne ze ktos tu takie bzdury
klekocze chyba ze poda jakies uzasadnienie co to takiego jest)

po kompilacjio kod w c zmienie sie w kod binarny z grubsza proporcjonalny do dlugosci
kodu w c

binarka.exe = x * piliki.c

(kiedys liczylem ile na oko wynosi ten x ale juz nie pamietam (teraz w
swoja dllke wkompilowywuje bitmapowe fonty wiec ciezko mi doklednie pomieżyc),
prawodopodobnie to x wynosi cos w stylu 0.3 (to znaczy ze jak ktos ma 1 GB materii
dll/exe to musialby miec 3 GB plikow c)
(gdy 6kb zrodla c na dzien to jest bardzo dobra wydajnosc - raczej nie do utrzymania
w duzych projektach przez dluzszy czas - na rok to by dawalo 2 MB zrodla na osobe
(ale jak mowie nie jest to realistyczne,
realistyczne jest moze 0.2-0.5 MB),
3 GB zrodla w c 1500 osobo-lat niezwykle wydajnych koderów albo z 10 tys osobo-lat
bardziej normalnych
(szacunki troche przyblizone ale z grubsza cos w tym stylu - troche malo
prawdopodobne by tak skomplikowany program byl uruchamiany w calosci na raz na
normalnym pececie (mam na mysli przynajmniej programy w c bo nie wiem jak z c++owym
bloatem))

do góry

W dniu niedziela, 19 listopada 2017 13:21:16 UTC+1 użytkownik fir napisał:
> W dniu środa, 15 listopada 2017 06:10:23 UTC+1 użytkownik s...@g...com
napisał:
> > Witam
> > W wielu "dużych", "profesjonalnych" i "popularnych" programach obserwuję zjawisko
wyłączania z exe całego kodu aplikacji.
> > Moje pytanie brzmi: Dlaczego wyłącza się dll z exe?
> >
> > Moje domniemania:
> > 1. Żeby używać w innych aplikacjach. Tylko tu pojawia się takie pytanie: Czemu
cały exe jest przerzucany do dll?
> > 2. Żeby używać w innych aplikacjach jako obiektu COM.
> > 3. Żeby łatwiej testować (pisać programy exe testujące dll-kę zamiast mieszać kod
roboczy z testowym).
> >
> > A może są inne powody? Proszę potwierdzić moje domniemania lub je zweryfikować.
> >
> > z góry dzięki
> > Szyk Cech
>
> 1)
>
> z dll mozna wyexportowac funkcje, (z exe albo nie mozna albo tez mozna ale niktorzy
i tak tego nie chcą robic (w tej chwili nie pamietam czy sie da))
> - co prawda nie jestem pewien czy takie exportowanie z exe to dobry pomysl ale byc
moze niektprzy chcą
> lub muszą to robic (?)
> (ogolnie architektura wydaje sie prostsza i latwiejsza gdy miedzy dllakami importy
ida tylko w jedną strone ale nie ejestem w stanie powiedziec czy czasem nie ejst
zrobic w dwie, tj czy robienie w dwie strony jest zawsze bledem)
>
> 2)
> dllki mozna dzilic miedzy programami, na przyklad jesli dane fonta wrzuci sie do
dllki a jest on uzywany przez 117 programow to w pamieci bedzie on obecny tylko raz,
> gdyby zas kazdy z tych programow czytal go z jakiegos pliku .bin
> klasyczna metodą to por obiloby sie 117 oddzielnych kopii (co prawda
> to daloby sie obejsc chyba przez m-mapowanie plikow itd (mozna by sie zastanowic
ktory z tych sposobow
> dll czy mmap bylby lepszy /ogolniejszy)
>
> (podbnie jak wyzej nie jestem jednak pewien czy exekow tez nie mozna dzilic miedzy
procesami (instancjami) oraz czy o to moze tu chodzic)
>
> jeslibym jednak mial cos podejrzewac o powod to te dwa punkty (ciut bardziej
pierwszy niz drugi ale drugi tez byc moze moze byc prawdopodobny jesli ktos pisze na
chacie nie jeden a kilka programow robiacych podobne rzeczy)
>
> 3) trzeci powod tez jest prawdopodobny, komus moze nie bardzo zalezec czy
kompilowac
> jako exe czy dll i robi dll nawet wtedy gdy moglby robic exe

inna opcja to ew byc moze
4) program ktory sam siebie chialby aktualizowac (moden w ostatnich czasach):
sciagnac z netu na dysk dllke z glownym programem, nawet nie kasowac starej tylko po
sciagnieciu sprawdzic ktora jest najnowsza i ja zlinkowac i odpalic to wydaje sie
ravzej proste (sam tego co prawda nie robilem) - exe ktory sciagnal by swoja nowsza
wersje musialby chyba albo sam przerenamowac czy skasowac stara wersje itd i ja
pozatym odpalic i siebie zamknąć,
(jesli nie przerenamowac to musialby jakos updatnac linki itd)
nie jestem pewien jak to sie robi w takich sytuacjach ale byc moze ta wersja z dll
jest praktyczniejsza
(ale to moje spekulacje trzebaby poczytac )

do góry

On 11/20/2017 1:42 PM, Maciej Sobczak wrote:
>> Nie jesteś w stanie przeprowadzić doświadczenia, jest zbyt kosztowne.
>> Możesz liczyć jednak że exe będzie miał powiedzmy 2GB rozmiaru jesli
>> suma dllek jest rzedu 2.5GB.
> To ciekawa wartość. Bo np. o Linuksie (o jądrze, co niektórzy używają jako jakiś
znany punkt odniesienia w dyskusji o rozmiarach) mówi się, że ma ileś tam milionów
linii kodu i to jest warte ileś tam tysięcy lat pracy a po skompilowaniu jest tego
jakieś tam... megabajty.

Sprawdź to lepiej ile zajmuje jądro *plus* wszystkie moduły we
wszystkich konfiguracjach i jaki jest poziom trudności tego w porownaniu
z przeciętną aplikacją "normalną". Może się okazać że wydajnośc linikodu
na dobę jest znaczaco mniejsza niż w jakiejkolwiek innej aplikacji z
powodu specyfiki produktu.

> A tu mamy w dyskusji gigabajty. Z tego by wynikało, że tego programu
jest powiedzmy dwa rzędy wielkości więcej, niż Linuksa, czyli na oko
miliard linii kodu i milion lat pracy. Co z kolei każe poddać pod
wątpliwość, czy w ogóle taki program dało się na tej planecie napisać.

Innymi słowy przechodzisz do atakowania faktów aż wystraszone pochowają
się po norach. No więc to działa tylko w polityce. W technice można
najzwyczajniej sprawdzić rozmiar naciskając szary + w total commanderze.

> A jeśli uznamy, że się nie dało, to wniosek jest taki, że binarka jest rozdmuchana
i pewnie da się z niej coś zdjąć.

Wiadomo. Zawsze możesz sie zatrudnić w jednej z firm (a niektóre mają
oddziały w PL) i nawrzeszczeć na swojego kierownika że imbecyl i zaraz
mu pokażesz jak się pisze prawdziwy soft redukuja dllki do 5% rozmiaru
pierwotnego. To co, jesteś gotowy do pokazania światu jak sie pisze?
Zwróć jednak uwagę łaskawym okiem ze docelowy rozmiar dll nie jest
krytycznym parametrem decydującym o sprzedaży lub nie softu na rynku.

> Dla przykładu, ostatnia gigantyczna DLLka jaką widziałem

Nikt tu nie pisze o gigantycznych dllkach. Piszę natomiast o
gigantycznej liczbie dllek. Na codzien pracuje z projektem gdzie jest
ich koło setki i mają sumeryczny rozmiar 0.5GB co jest raczej
mikroskopijna wielkością w tej branży. Tak, to *jedna* aplikacja.

> , miała w sobie wpałowany jako resource jakiś odjechany jeden plik z danymi.

Ja zaś, rozumiesz, mialem taki przypadek że kiedys jak siadałem to pękło
ramię w fotelu na kółkach i przewróciłem kubek z herbata na klawiature.
Z tego wniosek że LG wszystkie klawiatury dziadowskie robi.

> Może to jest jakiś trop?

Nie. To tylko brednie.

> W każdym razie, ja nie umiałbym naklepać tyle kodu (nawet z kolegami), żeby mi się
zrobiło z tego parę GB

Więc zatrudnij się w jednej z większych firm programistycznych w okolicy
które nie trzepią gównianego outsorcingu i sam sprawdzisz w praktyce jak
doświadczenia hobbystyczne z hello world mają się nijak do praktyki.

> A jeśli mam jedną zmienną statyczną, która jest kontenerem rzeczy, które będą do
niego dodane później?

Znowu masz opcje: idziesz do kierownika projektu i nazywasz go
imbecylem, skoro nie wie że można miec jedną zmienną statyczna na całą
aplikację. Wiesz, niektóre porady są niezwykle cenne tylko w teorii.
Brakuje ci pokory przed ogromem zagadnień jakie znajdziesz w tego typu
aplikacjach. I wiele z nich nie ma związku z programowaniem ale ma na
programowanie wpływ.

>> Jeśli chcesz zobaczyć *naprawdę* duże aplikacje to zerknij na rynek EDA.
> Tak, wiem. Chyba w każdej dyskusji, jaką tu mieliśmy, miałem sobie tam zerkać. :-)

I nie zerkasz dzięki czemu zyjesz w bąblu nieświadomości że moga istnieć
aplikacje gdzie kod wynikowy ma gigabajty. Sprawdź a potem zrewiduj
swoje hobbystyczne poglądy na programowanie. Możesz zacząć od
sprawdzenia ile dllek jest w windowsie 10 po instalacji i jaki mają
rozmiar a nastepnie pomyśleć o liczbie stanów kwantowych wszechświata
potrzebnych do ich wygenerowania. Albo wrócić na ziemię.

>> Dla ilustracji: zakładając że masz 100MB kodu w dll i musisz szerować to
>> między dwa exe (bo taką masz architekturę).
> Jeśli w ogóle mam jakąś architekturę, to od razu zakładam, że jest rozproszona

Brednia. Nic nie zakaldasz bo nie ma takiego założenia. dll mają
pozwolic na współdzelenie kodu na jednej maszynie, jak coś sobie
rozpraszasz to masz do czynienia z *wyjątkiem* a nie regułą i jest to
poza ta dyskusją o przydatności dllek.

>> Dla ilustracji2: wyobraź sobie że masz aplikację edytora która tylko
>> wtedy kiedy trzeba laduje parser gramatyki Perla.
> To jest przypadek, który opisałem na samym początku dyskusji (o pluginach, które są
częścią kultury używania programu). Nie mam problemu z tym, że takie coś jest w DLL.
Natomiast nadal mam problem z tym, że takie coś może być użyte tylko raz w czasie
działania programu - i pytanie, czy program zadba o to, żeby takiego niepotrzebnego
DLLa odpiąć. Jak zadba, to fajnie.

Zakładasz że oprogramowanie pisza gimazjaliści na zlecenie? No wiec to
też prawda, ale nie dotyczy raczej aplikacji po kilka GB kodu.

> Nadal jest jeszcze opcja rozproszona, czyli parser w osobnym procesie (wtedy DLL i
tak nie jest potrzebny). Może to mieć sens, może nie mieć.

Nie rozpraszaj tak od razu wszystkiego bo ktoś może zapytać jak
kosztowna jest synchronizacja i IPC. W realnym świecie ludzie zadają
takie pytania.

> Niemniej, przykład binarki na kilka GB wzbudza u mniej więcej wątpliwości, niż mnie
przekonuje.

Wiadomo, głupie fakty znowu nie pasują do poważnych bredni.

> Obliczenia powyżej.

To nie sa obliczenia. To brednie. Istnieją aplikacje gdzie kod wynikowy
liczony jest w gigabajtach na *jedną* aplikację i machanie rękami nic
tutaj nie zmieni, to są fakty. Sugerowanie ze go źle robią jest żałosne.
Tak, nie robią go optymalnie, ale chwilowo nie znamy lepszych metod niż
ten kod jednak generować ponieważ to jest zawsze balans pomiedzy
jakoscia, szybkością, ceną itp nieistotnymi dla hobbysty parametrami...

do góry

W dniu poniedziałek, 20 listopada 2017 22:53:30 UTC+1 użytkownik Sebastian Biały
napisał:
> On 11/20/2017 1:42 PM, Maciej Sobczak wrote:
> >> Nie jesteś w stanie przeprowadzić doświadczenia, jest zbyt kosztowne.
> >> Możesz liczyć jednak że exe będzie miał powiedzmy 2GB rozmiaru jesli
> >> suma dllek jest rzedu 2.5GB.
> > To ciekawa wartość. Bo np. o Linuksie (o jądrze, co niektórzy używają jako jakiś
znany punkt odniesienia w dyskusji o rozmiarach) mówi się, że ma ileś tam milionów
linii kodu i to jest warte ileś tam tysięcy lat pracy a po skompilowaniu jest tego
jakieś tam... megabajty.
>
> Sprawdź to lepiej ile zajmuje jądro *plus* wszystkie moduły we
> wszystkich konfiguracjach i jaki jest poziom trudności tego w porownaniu
> z przeciętną aplikacją "normalną". Może się okazać że wydajnośc linikodu
> na dobę jest znaczaco mniejsza niż w jakiejkolwiek innej aplikacji z
> powodu specyfiki produktu.
>
> > A tu mamy w dyskusji gigabajty. Z tego by wynikało, że tego programu
> jest powiedzmy dwa rzędy wielkości więcej, niż Linuksa, czyli na oko
> miliard linii kodu i milion lat pracy. Co z kolei każe poddać pod
> wątpliwość, czy w ogóle taki program dało się na tej planecie napisać.
>
> Innymi słowy przechodzisz do atakowania faktów aż wystraszone pochowają
> się po norach. No więc to działa tylko w polityce. W technice można
> najzwyczajniej sprawdzić rozmiar naciskając szary + w total commanderze.
>
> > A jeśli uznamy, że się nie dało, to wniosek jest taki, że binarka jest
rozdmuchana i pewnie da się z niej coś zdjąć.
>
> Wiadomo. Zawsze możesz sie zatrudnić w jednej z firm (a niektóre mają
> oddziały w PL) i nawrzeszczeć na swojego kierownika że imbecyl i zaraz
> mu pokażesz jak się pisze prawdziwy soft redukuja dllki do 5% rozmiaru
> pierwotnego. To co, jesteś gotowy do pokazania światu jak sie pisze?
> Zwróć jednak uwagę łaskawym okiem ze docelowy rozmiar dll nie jest
> krytycznym parametrem decydującym o sprzedaży lub nie softu na rynku.
>
> > Dla przykładu, ostatnia gigantyczna DLLka jaką widziałem
>
> Nikt tu nie pisze o gigantycznych dllkach. Piszę natomiast o
> gigantycznej liczbie dllek. Na codzien pracuje z projektem gdzie jest
> ich koło setki i mają sumeryczny rozmiar 0.5GB co jest raczej
> mikroskopijna wielkością w tej branży. Tak, to *jedna* aplikacja.
>
> > , miała w sobie wpałowany jako resource jakiś odjechany jeden plik z danymi.
>
> Ja zaś, rozumiesz, mialem taki przypadek że kiedys jak siadałem to pękło
> ramię w fotelu na kółkach i przewróciłem kubek z herbata na klawiature.
> Z tego wniosek że LG wszystkie klawiatury dziadowskie robi.
>
> > Może to jest jakiś trop?
>
> Nie. To tylko brednie.
>
> > W każdym razie, ja nie umiałbym naklepać tyle kodu (nawet z kolegami), żeby mi
się zrobiło z tego parę GB
>
> Więc zatrudnij się w jednej z większych firm programistycznych w okolicy
> które nie trzepią gównianego outsorcingu i sam sprawdzisz w praktyce jak
> doświadczenia hobbystyczne z hello world mają się nijak do praktyki.
>
> > A jeśli mam jedną zmienną statyczną, która jest kontenerem rzeczy, które będą do
niego dodane później?
>
> Znowu masz opcje: idziesz do kierownika projektu i nazywasz go
> imbecylem, skoro nie wie że można miec jedną zmienną statyczna na całą
> aplikację. Wiesz, niektóre porady są niezwykle cenne tylko w teorii.
> Brakuje ci pokory przed ogromem zagadnień jakie znajdziesz w tego typu
> aplikacjach. I wiele z nich nie ma związku z programowaniem ale ma na
> programowanie wpływ.
>
> >> Jeśli chcesz zobaczyć *naprawdę* duże aplikacje to zerknij na rynek EDA.
> > Tak, wiem. Chyba w każdej dyskusji, jaką tu mieliśmy, miałem sobie tam zerkać.
:-)
>
> I nie zerkasz dzięki czemu zyjesz w bąblu nieświadomości że moga istnieć
> aplikacje gdzie kod wynikowy ma gigabajty. Sprawdź a potem zrewiduj
> swoje hobbystyczne poglądy na programowanie. Możesz zacząć od
> sprawdzenia ile dllek jest w windowsie 10 po instalacji i jaki mają
> rozmiar a nastepnie pomyśleć o liczbie stanów kwantowych wszechświata
> potrzebnych do ich wygenerowania. Albo wrócić na ziemię.
>
> >> Dla ilustracji: zakładając że masz 100MB kodu w dll i musisz szerować to
> >> między dwa exe (bo taką masz architekturę).
> > Jeśli w ogóle mam jakąś architekturę, to od razu zakładam, że jest rozproszona
>
> Brednia. Nic nie zakaldasz bo nie ma takiego założenia. dll mają
> pozwolic na współdzelenie kodu na jednej maszynie, jak coś sobie
> rozpraszasz to masz do czynienia z *wyjątkiem* a nie regułą i jest to
> poza ta dyskusją o przydatności dllek.
>
> >> Dla ilustracji2: wyobraź sobie że masz aplikację edytora która tylko
> >> wtedy kiedy trzeba laduje parser gramatyki Perla.
> > To jest przypadek, który opisałem na samym początku dyskusji (o pluginach, które
są częścią kultury używania programu). Nie mam problemu z tym, że takie coś jest w
DLL. Natomiast nadal mam problem z tym, że takie coś może być użyte tylko raz w
czasie działania programu - i pytanie, czy program zadba o to, żeby takiego
niepotrzebnego DLLa odpiąć. Jak zadba, to fajnie.
>
> Zakładasz że oprogramowanie pisza gimazjaliści na zlecenie? No wiec to
> też prawda, ale nie dotyczy raczej aplikacji po kilka GB kodu.
>
> > Nadal jest jeszcze opcja rozproszona, czyli parser w osobnym procesie (wtedy DLL
i tak nie jest potrzebny). Może to mieć sens, może nie mieć.
>
> Nie rozpraszaj tak od razu wszystkiego bo ktoś może zapytać jak
> kosztowna jest synchronizacja i IPC. W realnym świecie ludzie zadają
> takie pytania.
>
> > Niemniej, przykład binarki na kilka GB wzbudza u mniej więcej wątpliwości, niż
mnie przekonuje.
>
> Wiadomo, głupie fakty znowu nie pasują do poważnych bredni.
>
> > Obliczenia powyżej.
>
> To nie sa obliczenia. To brednie. Istnieją aplikacje gdzie kod wynikowy
> liczony jest w gigabajtach na *jedną* aplikację i machanie rękami nic
> tutaj nie zmieni, to są fakty. Sugerowanie ze go źle robią jest żałosne.
> Tak, nie robią go optymalnie, ale chwilowo nie znamy lepszych metod niż
> ten kod jednak generować ponieważ to jest zawsze balans pomiedzy
> jakoscia, szybkością, ceną itp nieistotnymi dla hobbysty parametrami...

podstawowe pytanie coz to są za aplikacje dokladnie? wszystkie te dllki ladują do
jednej przestrzeni windowsowego procesu na raz?
moze to nie zwykle aplikacje (pojedyncze programy) a jakies cale zlozone systemy
programow? (pytanie zasadne bo jesli to wszystko to jest czysty kod musi to byc cos o
wiele bardziej zlozonego niz taki windows dla przykladu (ktorego kod jak mysle
wczytany do ramu to raczej jest w granicach kilkudziesieciu MB (nie licze dotnetowego
crapu i bardziej peryferyjnych dllek i programow, z tym by bylo oczywiscie sporo
wiecej ale to nie jest wszystko na raz ladowane do pamieci)) )

kolega trzeb zaznaczyc wydziela z siebie wiele konfronatacyjnych wyrzyknikow a malo
konkretnych informacji co nie robi za dobrego
wrazenia

do góry

> Sprawdź to lepiej ile zajmuje jądro *plus* wszystkie moduły

Nadal megabajty. Podobno kilkadziesiąt.

> i jaki jest poziom trudności tego w porownaniu
> z przeciętną aplikacją "normalną".

A to poziom trudności wpływa na stosunek rozmiaru binarki względem liczby linii kodu?
Ja piszę o tym, że jeżeli weźmiemy Linuksa jako pewny znany punkt odniesienia, to
przykład wielogigabajtowych DLLek tak bardzo od tego punktu odniesienia odbiega, że
aż się prosi o wyjaśnienie. I tego wyjaśnienia nadal nie widać.

> Innymi słowy przechodzisz do atakowania faktów

Ja podałem fakty z Linuksa.

> W technice można
> najzwyczajniej sprawdzić rozmiar naciskając szary + w total commanderze.

Nie napisałem nigdzie, że plik nie może mieć takiego rozmiaru, tylko że (w porównaniu
do znanego punktu odniesienia) ten rozmiar ma wątpliwe uzasadnienie.

> Zawsze możesz sie zatrudnić w jednej z firm (a niektóre mają
> oddziały w PL) i nawrzeszczeć na swojego kierownika że imbecyl

Zauważyłem, że za każdym razem gdy o czymś dyskutujemy pojawiają się dwa stałe
zjawiska:
1. mam sobie zerknąć na EDA
2. w Twoich postach pojawiają się wyzwiska

> Zwróć jednak uwagę łaskawym okiem ze docelowy rozmiar dll nie jest
> krytycznym parametrem decydującym o sprzedaży lub nie softu na rynku.

I w ten sposób sam podrzuciłeś argument do dyskusji wskazując, że nie ma motywacji,
żeby te DLLki były mniejsze.
Wstępne podsumowanie:
- ja stawiam zarys tezy, że taki rozmiar może nie być optymalny
- Ty stwierdzasz, że nie ma motywacji biznesowej, żeby był optymalny

Czyli nie ma między nami różnicy zdań, wbrew Twojemu wyobrażeniu, że ktoś kogoś
atakuje, itd.

> Nikt tu nie pisze o gigantycznych dllkach. Piszę natomiast o
> gigantycznej liczbie dllek.

Dobrze, popracujmy nad tym argumentem.
Napisałem pustą funkcję w C i bez żadnych optymalizacji zrobiłem z niej:
- plik obiektowy: 687 bajtów
- archiwum do linkowania statycznego: 840 bajtów
- dynamiczną bibliotekę dzieloną: 56731 bajtów

W przypadku linkowania z archiwum wyciągany jest sam tekst funkcji, więc tu narzutu
nie ma. Natomiast biblioteka dzielona jest 80 (słownie: osiemdziesiąt) razy większa,
niż plik obiektowy. Oczywiście ten narzut jest sztucznie zawyżony przez sam fakt, że
funkcja jest pusta, ale...

> Na codzien pracuje z projektem gdzie jest
> ich koło setki i mają sumeryczny rozmiar 0.5GB

... ale powinno być zrozumiałe, że skoro DLL ma pewne wewnętrzne narzuty, to suma
rozmiaru dużej liczby DLLek nie przekonuje mnie, że w sumie tyle tych bajtów musi
być.

> Ja zaś, rozumiesz, mialem taki przypadek że kiedys jak siadałem to pękło
> ramię w fotelu na kółkach i przewróciłem kubek z herbata na klawiature.
> Z tego wniosek że LG wszystkie klawiatury dziadowskie robi.

Ja takiego wniosku bym nie wyciągnął, ale cieszę się, że się z nami tym podzieliłeś.

> > Może to jest jakiś trop?
>
> Nie. To tylko brednie.

Więc powinno być bardzo łatwo to wykazać. A tymczasem od początku stwierdziłeś, że
odpowiedniego doświadczenia nie możesz przeprowadzić.

> Więc zatrudnij się w jednej z większych firm programistycznych w okolicy

A mógłbyś coś polecić?

> sam sprawdzisz w praktyce jak
> doświadczenia hobbystyczne z hello world mają się nijak do praktyki.

Praktyka jest taka, że nie ma motywacji, żeby było optymalnie. Sam tak napisałeś.

> > A jeśli mam jedną zmienną statyczną, która jest kontenerem rzeczy, które będą do
niego dodane później?
>
> Znowu masz opcje: idziesz do kierownika projektu i nazywasz go
> imbecylem,

Znowu wyzwiska. A może faktycznie można mieć mniej zmiennych statycznych?
Albo nawet w ogóle ich nie mieć?

> Brakuje ci pokory

Bo podałem liczby, z którymi nie wiesz, co zrobić?

> Możesz zacząć od
> sprawdzenia ile dllek jest w windowsie 10 po instalacji

Faktycznie można od tego zacząć, bo w pierwszym poście w tej dyskusji napisałem, że
base-system jest wyjątkiem, gdzie kod dzielony jest uzasadniony. Ale dyskutujemy o
aplikacjach.

> > Jeśli w ogóle mam jakąś architekturę, to od razu zakładam, że jest rozproszona
>
> Brednia. Nic nie zakaldasz bo nie ma takiego założenia.

Tak zakładam i do tej pory się to sprawdzało.
Co ciekawe, zrobiłem zgodnie z Twoim zaleceniem i zerknałem do branży EDA, żeby
skonfrontować swoje hobbystyczne wyobrażenie z prawdziwym światem:

https://www.google.com/patents/US20070073809

i popatrz jaka niespodzianka - tam też się sprawdziło.

(Właśnie dlatego nie traktuję branży EDA jako wyjątkowego źródła olśnień albo
przykładów. Branża jak inne.)

> Zakładasz że oprogramowanie pisza gimazjaliści na zlecenie?

O, w poprzedniej dyskusji też coś wspominałeś o gimnazjalistach.

> No wiec to
> też prawda, ale nie dotyczy raczej aplikacji po kilka GB kodu.

Ale jeszcze nie wykazałeś, że te GB są uzasadnione. Wręcz przeciwnie - sam wskazałeś,
że nie ma motywacji, żeby było tego mniej, czym tylko utwierdziłeś mnie w moich
wątpliwościach w tym temacie.

> Wiadomo, głupie fakty znowu nie pasują do poważnych bredni.
>
> > Obliczenia powyżej.
>
> To nie sa obliczenia. To brednie.

Ciekawe, ile osób przekonałeś.

--
Maciej Sobczak * http://www.inspirel.com

do góry

W dniu wtorek, 21 listopada 2017 13:35:43 UTC+1 użytkownik Maciej Sobczak napisał:
> Napisałem pustą funkcję w C i bez żadnych optymalizacji zrobiłem z niej:
> - plik obiektowy: 687 bajtów
> - archiwum do linkowania statycznego: 840 bajtów
> - dynamiczną bibliotekę dzieloną: 56731 bajtów
>

jak wspomnialem napisalem ostatnio asembler x86 ktory tworzy pliki exe na dysk i o
tyle moge cos powiedziec o tym rozmiarze:

tworzenia dllek nie zrobilem ale
wiem jak to by wygladalo w stosunku do exe sllka ma po prostu jeszcze
jedna sekcje z exportami czego exe normalnie nie ma

dllka nie musi byc tak duza tak naprawde chyba krytycznym parametrem decydujacym o
tym inicjalnym rozmiarze jest tzw file_aligment

exe ma zwykle minimum 4 sekcje (czesci) [naglowek, code, data, importy] ktore sa po
prostu wyrownywane do tej wartosci dlatego jesli ustawi sie jakis wiekszy
file_alignment to nawet prawie pusty exe moze miec wiekszy rozmiar
(dllka w tym wypadku mialaby mw 5 sekcji [naglowek, code, data, importy, exporty)

file alignment mozna ustawic zdaje sie minimalnie na 512 wiec minimalny rozmiar akiej
dllki tutaj mialby 5*512 bajtów czyli dwa i pol kilobajta wiec dllka nie musi miec az
takiego wielkiego narzutu - aczkolwiek z drugiej strony wlasnie taki minimalny narzut
raczej bedzie miec (zapomnialem ze jeszcze najprawdopodobniej bedzie sekcja
relokacjiwiec minimalny narzut bedzie raczej moze 3 kb)


file alignment mozna tez ustawic na wiecej oczywiscie (zdaje sie ze te granice nie sa
zbyt rozsadne mozn anwet ustawic nawet na 1 MB i wtdty niemal pusta dllka bedzie
miala z 6 MB ale to o niczym nie swiadczy), mozna tez w nią pewnie wbebeszyc jakies
niezbyt potrzebne dane, i rozmiar tej 56 kb dllki wyunika albo z jednego albo z
drugiego - tak czy owak 56 kb to nie jest minimalny narzut, minimalny narzut dllki
jest mniejszy - ms czy ktotam to projektowal mogl to nawiasem mowiac zaprojektowac
lepiej redukujac ten narzut z 3 kb bardziej w strone zera - co ma bardziej wyraz
estetyczny niz praktyczny ale yen eststyczny tez sie liczy bo wtedy czlowiek wyraznie
widzialby ile ma kodu

swoja dorga sa programiki ktore pokazuja ile bajtow ma ktora sekscje (zdaje sie ze
nwet 'wejscie' w dllke z poziomu winrara pokaze to info, to chyba taki winrarowy
easter egg ;c )

do góry

On 11/21/2017 1:35 PM, Maciej Sobczak wrote:
>> Sprawdź to lepiej ile zajmuje jądro *plus* wszystkie moduły
> Nadal megabajty. Podobno kilkadziesiąt.

A typowy program do usuwania pryszczy modelkom może i setki. Czy już
widzisz jak zły wybrałeś przykład?

> A to poziom trudności wpływa na stosunek rozmiaru binarki względem liczby linii
kodu?

Na podstawie bredni o tym ile lat pisano jądro linuxa wymysliłes sobie
że nie da się napisac aplikacji tak dużej aby kod zajmował GB.

Pozwól że zacytuje:

"czyli na oko miliard linii kodu i milion lat pracy"

> Ja piszę o tym, że jeżeli weźmiemy Linuksa jako pewny znany punkt odniesienia

Czy jak bym wziął przecietne seminarium jako punkt odniesienia do badań
nad religijnością obywateli to miałbyś może jakąs uwagę do metodyki czy
Ci nie zależy?

>, to przykład wielogigabajtowych DLLek tak bardzo od tego punktu odniesienia
odbiega, że aż się prosi o wyjaśnienie.

Wyjaśnienie: w rzeczywistym świecie sa projekty większe
kilkanascie/dziesiąt razy od Linuxa pod względem kodu.

> I tego wyjaśnienia nadal nie widać.

Ależ widać tylko nijak nie potrafisz szukać bądź obracasz się w
środowisku helloworldowców gdzie takich rozmiarów nie ma i eksrapolujesz
tą ignorację na ogromne aplikacje.

>> Innymi słowy przechodzisz do atakowania faktów
> Ja podałem fakty z Linuksa.

A ja z seminarium.

>> W technice można
>> najzwyczajniej sprawdzić rozmiar naciskając szary + w total commanderze.
> Nie napisałem nigdzie, że plik nie może mieć takiego rozmiaru

Znowu czas na cytat:

"Co z kolei każe poddać pod wątpliwość, czy w ogóle taki program dało
się na tej planecie napisać"

Ja robie szary + i mam wynik. Ty twierdzisz że nie mogę mieć. Ludzie o
wykształceniu technicznym nie spierają się o fakty i nie bazują na
urojeniach wyssanych z palca.

>, tylko że (w porównaniu do znanego punktu odniesienia) ten rozmiar ma wątpliwe
uzasadnienie.

Czyli już odwrót. Już nie tyle nie da sie napisać co nie ma
uzasadnienia. No no, szybko uciekasz.

>> Zawsze możesz sie zatrudnić w jednej z firm (a niektóre mają
>> oddziały w PL) i nawrzeszczeć na swojego kierownika że imbecyl
> Zauważyłem, że za każdym razem gdy o czymś dyskutujemy pojawiają się dwa stałe
zjawiska:
> 1. mam sobie zerknąć na EDA
> 2. w Twoich postach pojawiają się wyzwiska

Wyzwiskiem jest twoje twierdzenie że firma nie jest w stanie pisać softu
bo popełnia jakieś trywialne bledy jak linkowanie pornola do dllki czy
błedny kod który robi gigabajty zamiast megabajtów.

Ja tylko skrystalizowałem obelgi rzucane przez Ciebie w jedno *słowo*.

>> Zwróć jednak uwagę łaskawym okiem ze docelowy rozmiar dll nie jest
>> krytycznym parametrem decydującym o sprzedaży lub nie softu na rynku.
> I w ten sposób sam podrzuciłeś argument do dyskusji wskazując, że nie ma motywacji,
żeby te DLLki były mniejsze.

Nie ma. Motywacja jest biznesowa. Czasem też ważne jest, niestety, że
jakiś ficzer nie chce się zmiescić na dyskietce. Powiedzmy że wiekszość
uzytkownikow już ich nie używa między innymi z tego powodu.

> Wstępne podsumowanie:
> - ja stawiam zarys tezy, że taki rozmiar może nie być optymalny
> - Ty stwierdzasz, że nie ma motywacji biznesowej, żeby był optymalny
> Czyli nie ma między nami różnicy zdań, wbrew Twojemu wyobrażeniu, że ktoś kogoś
atakuje, itd.

Podsuwasz idityczny przykład z resourcami w dll i myślisz że nie
atakujesz? Atakujesz zdrowy rozsądek. Ludzie piszacy tak wielki kod mają
*ZUPEŁNIE* inne problemy niż te z poziomu gimnazjum.

>> Nikt tu nie pisze o gigantycznych dllkach. Piszę natomiast o
>> gigantycznej liczbie dllek.
> Dobrze, popracujmy nad tym argumentem.
> Napisałem pustą funkcję w C i bez żadnych optymalizacji zrobiłem z niej:
> - plik obiektowy: 687 bajtów
> - archiwum do linkowania statycznego: 840 bajtów
> - dynamiczną bibliotekę dzieloną: 56731 bajtów

Brawo. Kupiłem garnek. Wlałem do niego kroplę wody. Zważyłem i wyszło 1kg.

Wniosek: dwie krople wody w garnku to już 2kg.

> W przypadku linkowania z archiwum wyciągany jest sam tekst funkcji, więc tu narzutu
nie ma.
Natomiast biblioteka dzielona jest 80 (słownie: osiemdziesiąt) razy
większa, niż plik obiektowy. Oczywiście ten narzut jest sztucznie
zawyżony przez sam fakt, że funkcja jest pusta, ale...

Cała bzdura w tym ale. Zazwyczaj detale jak kod debugowy, symbole itp
duperele niezauwazalne hobbystycznie mają znaczenie. Oczywiście pod
warunkiem że ktokolwiek jest na tyle głupi aby z nagłówka kiepsko
skompilowanego dll wyciągać wnioski o narzucie.

>> Na codzien pracuje z projektem gdzie jest
>> ich koło setki i mają sumeryczny rozmiar 0.5GB
> ... ale powinno być zrozumiałe, że skoro DLL ma pewne wewnętrzne narzuty, to suma
rozmiaru dużej liczby DLLek nie przekonuje mnie, że w sumie tyle tych bajtów musi
być.

Nic nie kumasz. 95% tych bajtów to kod. Reszta "narzut", cokolwiek to
miało by znaczyć. Ten "narzut" posiada również zalety które ignorujesz.
To jest balans. Można stracić 5% dysku i zyskać znaczące ficzery w kodzie.

>> Ja zaś, rozumiesz, mialem taki przypadek że kiedys jak siadałem to pękło
>> ramię w fotelu na kółkach i przewróciłem kubek z herbata na klawiature.
>> Z tego wniosek że LG wszystkie klawiatury dziadowskie robi.
> Ja takiego wniosku bym nie wyciągnął, ale cieszę się, że się z nami tym
podzieliłeś.

Ty zas wyciągasz wnioski z nagłówka dll i nie widzisz swojej
śmieszności? Sprowadzenie dyskutanta do pozimu własnych absurdów czasem
działa ale tutaj widać nie bardzo.

>>> Może to jest jakiś trop?
>> Nie. To tylko brednie.
> Więc powinno być bardzo łatwo to wykazać.

Oczywiscie. Mam kilka dllek które z róznych względow musza się
kompilować rownież do .lib. Nie są małe, mają w sumie może z 100MB. Czy
to lib czy dll rozmiar plików jest podobny z dokładnością do szumu.
Zadziwiające, nie? A już przeciez chciałeś pisać do MS że mają poważnego
buga w implementacji dll...

> A tymczasem od początku stwierdziłeś, że odpowiedniego doświadczenia nie możesz
przeprowadzić.

Nie możesz. To nie jest tylko przestawienie switcha w projekcie. Tak to
dziala dla helloworldow. Dla duzych aplikacji jest to nie możliwe.
Przyczyn jest tak wiele że uważam za bezensowne dyskutowanie nad nimi.

>> Więc zatrudnij się w jednej z większych firm programistycznych w okolicy
> A mógłbyś coś polecić?

Nie, miałbym ich na sumieniu.

>> doświadczenia hobbystyczne z hello world mają się nijak do praktyki.
> Praktyka jest taka, że nie ma motywacji, żeby było optymalnie. Sam tak napisałeś.

Jest optymalne w granicach mozliwosci technicznych, tylko funkcja celu
jest zupełnie inna niż myślisz. Jest skomplikowana.

>>> A jeśli mam jedną zmienną statyczną, która jest kontenerem rzeczy, które będą do
niego dodane później?
>> Znowu masz opcje: idziesz do kierownika projektu i nazywasz go
>> imbecylem,
> Znowu wyzwiska.

Sam wyzywasz ludzi na około twierdząc że popełniają trywialne błedy z
dllkami i na pewno da sie je zredukować. No więc pewno się w niewielkim
stopniu da tylko PO CO?

> A może faktycznie można mieć mniej zmiennych statycznych?
> Albo nawet w ogóle ich nie mieć?

Idiotyczna rada. Nigdy jak widać nie pracowaleś nad projektem który ma
~20 lat kodu stukanego przez 4 pokolenia ludzi. Najlepiej idź i wyjasnij
że trzeba wszystko przepisać w C#. Na pewno znajdziesz zrozumienie, może
nawet ktoś poklepie po ramieniu współczując.

>> Brakuje ci pokory
> Bo podałem liczby, z którymi nie wiesz, co zrobić?

Brakuje Ci pokory abys zrozumiał że Twoje trywialne obliczenia z
helloworlda sa gówno warte w zderzeniu z rzeczywistościa gdzie kod
przytłacza, problemy sa nie do znalezienia na stackoverflow, gdzie
kompilatorom kończy się stos przy linkowaniu, gdzie milisekundy
ładowania aplikacji mają znaczenie dla testowania, gdzie istnieją w
ogóle jakieś testy, gdzie istnieje inzynieria programowania, gdzie
zespoły sa rozproszone w nastu miejscach na świecie itd itp setki
powodów. Zazwyczaj organizacyjnych a nie programistycznych, ale mających
wpływ na programowanie.

>> Możesz zacząć od
>> sprawdzenia ile dllek jest w windowsie 10 po instalacji
> Faktycznie można od tego zacząć, bo w pierwszym poście w tej dyskusji napisałem, że
base-system jest wyjątkiem, gdzie kod dzielony jest uzasadniony. Ale dyskutujemy o
aplikacjach.

Które zachowują się jak systemy operacyjne. Mają wlasne uniwersalne
abstrakcje, własne utility, współdziela kod między modułami itd itp. Nie
istnieje wyraźna roznica w złożoności jednego czy drugiego pod względem
podziału na funkcjonalności. Byłes już u tych imbecyli z Photoshopa aby
im wyjaśnić jak głupi sa nie linkując statycznie wszystkiego? Może nie
wiedza że powinni? Bigbounty czeka.

>>> Jeśli w ogóle mam jakąś architekturę, to od razu zakładam, że jest rozproszona
>> Brednia. Nic nie zakaldasz bo nie ma takiego założenia.
> Tak zakładam i do tej pory się to sprawdzało.

Powiedz to kolesiom od gcc na ten przykład. Że powinni zakładać ze
linker odpali sie gdzie indziej niż kompilator.

Wiesz dlaczego to głupie? Bo tak wlasnie można zrobić
distcc/IncrediBuild tylko że w tym celu w gcc nie trzeba linkować
niczego statycznie ani w ogóle o tym wiedzieć.

> Co ciekawe, zrobiłem zgodnie z Twoim zaleceniem i zerknałem do branży EDA, żeby
skonfrontować swoje hobbystyczne wyobrażenie z prawdziwym światem:
> https://www.google.com/patents/US20070073809
> i popatrz jaka niespodzianka - tam też się sprawdziło.

Nie, to najzwyczajniej nie na temat.

> (Właśnie dlatego nie traktuję branży EDA jako wyjątkowego źródła olśnień albo
przykładów. Branża jak inne.)

Nie, jest specyficzna. Jest znacznie wieksza niż "największe znane
aplikacje jakie widział kowalski w bogatej firmie".

>> Zakładasz że oprogramowanie pisza gimazjaliści na zlecenie?
> O, w poprzedniej dyskusji też coś wspominałeś o gimnazjalistach.

Bo tylko gimnazjalista mógłby zapomieć wyładować dllkę i tylko
gimnazjalista mogłby nie napisać na to testu i tylko popsute testowanie
benchmarkowe mogło by tego nie wykryć.

Innymi słowy tak, są firmy gdzie gimnazjalisci pisza soft. Niektórzy
mają 50 lat, ale to stan umysłu bardziej. I tak, niektórzy z obawy że
zapomna wyładować dllkę z pamięci linkuja wszystko statycznie,
niewątpliwie gdzieś tacy są. No bo jak spieprzyć to raz a dobrze.

>> No wiec to
>> też prawda, ale nie dotyczy raczej aplikacji po kilka GB kodu.
> Ale jeszcze nie wykazałeś, że te GB są uzasadnione.

W tej chwili właśnie strzeliłeś w pysk programistów wszystkich dużych
aplikacji. I serio, masz czelnośc twierdzić że to ja obrażam ludzi?

> Wręcz przeciwnie - sam wskazałeś, że nie ma motywacji, żeby było tego mniej

Ten kod jest niezbędny. Jesli chcesz go zredukować to uzyskasz 5-10%
nadludzkim wysiłkiem. Obawiam się że Twojego magebajta z gigabajta nie
da się uzyskać bez usuwania ficzerów.

>, czym tylko utwierdziłeś mnie w moich wątpliwościach w tym temacie.

Dalej masz wątpliwosci nad faktami?

>> To nie sa obliczenia. To brednie.
> Ciekawe, ile osób przekonałeś.

Moim celem jest tylko ekspozycja bredni. Nie mam interesu w
przekonywaniu kogokolwiek.

do góry

W dniu wtorek, 21 listopada 2017 22:21:10 UTC+1 użytkownik Sebastian Biały napisał:
> On 11/21/2017 1:35 PM, Maciej Sobczak wrote:
> >> Sprawdź to lepiej ile zajmuje jądro *plus* wszystkie moduły
> > Nadal megabajty. Podobno kilkadziesiąt.
>
> A typowy program do usuwania pryszczy modelkom może i setki. Czy już
> widzisz jak zły wybrałeś przykład?
>
> > A to poziom trudności wpływa na stosunek rozmiaru binarki względem liczby linii
kodu?
>
> Na podstawie bredni o tym ile lat pisano jądro linuxa wymysliłes sobie
> że nie da się napisac aplikacji tak dużej aby kod zajmował GB.
>
> Pozwól że zacytuje:
>
> "czyli na oko miliard linii kodu i milion lat pracy"
>
> > Ja piszę o tym, że jeżeli weźmiemy Linuksa jako pewny znany punkt odniesienia
>
> Czy jak bym wziął przecietne seminarium jako punkt odniesienia do badań
> nad religijnością obywateli to miałbyś może jakąs uwagę do metodyki czy
> Ci nie zależy?
>
> >, to przykład wielogigabajtowych DLLek tak bardzo od tego punktu odniesienia
odbiega, że aż się prosi o wyjaśnienie.
>
> Wyjaśnienie: w rzeczywistym świecie sa projekty większe
> kilkanascie/dziesiąt razy od Linuxa pod względem kodu.
>
> > I tego wyjaśnienia nadal nie widać.
>
> Ależ widać tylko nijak nie potrafisz szukać bądź obracasz się w
> środowisku helloworldowców gdzie takich rozmiarów nie ma i eksrapolujesz
> tą ignorację na ogromne aplikacje.
>
> >> Innymi słowy przechodzisz do atakowania faktów
> > Ja podałem fakty z Linuksa.
>
> A ja z seminarium.
>
> >> W technice można
> >> najzwyczajniej sprawdzić rozmiar naciskając szary + w total commanderze.
> > Nie napisałem nigdzie, że plik nie może mieć takiego rozmiaru
>
> Znowu czas na cytat:
>
> "Co z kolei każe poddać pod wątpliwość, czy w ogóle taki program dało
> się na tej planecie napisać"
>
> Ja robie szary + i mam wynik. Ty twierdzisz że nie mogę mieć. Ludzie o
> wykształceniu technicznym nie spierają się o fakty i nie bazują na
> urojeniach wyssanych z palca.
>
> >, tylko że (w porównaniu do znanego punktu odniesienia) ten rozmiar ma wątpliwe
uzasadnienie.
>
> Czyli już odwrót. Już nie tyle nie da sie napisać co nie ma
> uzasadnienia. No no, szybko uciekasz.
>
> >> Zawsze możesz sie zatrudnić w jednej z firm (a niektóre mają
> >> oddziały w PL) i nawrzeszczeć na swojego kierownika że imbecyl
> > Zauważyłem, że za każdym razem gdy o czymś dyskutujemy pojawiają się dwa stałe
zjawiska:
> > 1. mam sobie zerknąć na EDA
> > 2. w Twoich postach pojawiają się wyzwiska
>
> Wyzwiskiem jest twoje twierdzenie że firma nie jest w stanie pisać softu
> bo popełnia jakieś trywialne bledy jak linkowanie pornola do dllki czy
> błedny kod który robi gigabajty zamiast megabajtów.
>
> Ja tylko skrystalizowałem obelgi rzucane przez Ciebie w jedno *słowo*.
>
> >> Zwróć jednak uwagę łaskawym okiem ze docelowy rozmiar dll nie jest
> >> krytycznym parametrem decydującym o sprzedaży lub nie softu na rynku.
> > I w ten sposób sam podrzuciłeś argument do dyskusji wskazując, że nie ma
motywacji, żeby te DLLki były mniejsze.
>
> Nie ma. Motywacja jest biznesowa. Czasem też ważne jest, niestety, że
> jakiś ficzer nie chce się zmiescić na dyskietce. Powiedzmy że wiekszość
> uzytkownikow już ich nie używa między innymi z tego powodu.
>
> > Wstępne podsumowanie:
> > - ja stawiam zarys tezy, że taki rozmiar może nie być optymalny
> > - Ty stwierdzasz, że nie ma motywacji biznesowej, żeby był optymalny
> > Czyli nie ma między nami różnicy zdań, wbrew Twojemu wyobrażeniu, że ktoś kogoś
atakuje, itd.
>
> Podsuwasz idityczny przykład z resourcami w dll i myślisz że nie
> atakujesz? Atakujesz zdrowy rozsądek. Ludzie piszacy tak wielki kod mają
> *ZUPEŁNIE* inne problemy niż te z poziomu gimnazjum.
>
> >> Nikt tu nie pisze o gigantycznych dllkach. Piszę natomiast o
> >> gigantycznej liczbie dllek.
> > Dobrze, popracujmy nad tym argumentem.
> > Napisałem pustą funkcję w C i bez żadnych optymalizacji zrobiłem z niej:
> > - plik obiektowy: 687 bajtów
> > - archiwum do linkowania statycznego: 840 bajtów
> > - dynamiczną bibliotekę dzieloną: 56731 bajtów
>
> Brawo. Kupiłem garnek. Wlałem do niego kroplę wody. Zważyłem i wyszło 1kg.
>
> Wniosek: dwie krople wody w garnku to już 2kg.
>
> > W przypadku linkowania z archiwum wyciągany jest sam tekst funkcji, więc tu
narzutu nie ma.
> Natomiast biblioteka dzielona jest 80 (słownie: osiemdziesiąt) razy
> większa, niż plik obiektowy. Oczywiście ten narzut jest sztucznie
> zawyżony przez sam fakt, że funkcja jest pusta, ale...
>
> Cała bzdura w tym ale. Zazwyczaj detale jak kod debugowy, symbole itp
> duperele niezauwazalne hobbystycznie mają znaczenie. Oczywiście pod
> warunkiem że ktokolwiek jest na tyle głupi aby z nagłówka kiepsko
> skompilowanego dll wyciągać wnioski o narzucie.
>
> >> Na codzien pracuje z projektem gdzie jest
> >> ich koło setki i mają sumeryczny rozmiar 0.5GB
> > ... ale powinno być zrozumiałe, że skoro DLL ma pewne wewnętrzne narzuty, to suma
rozmiaru dużej liczby DLLek nie przekonuje mnie, że w sumie tyle tych bajtów musi
być.
>
> Nic nie kumasz. 95% tych bajtów to kod. Reszta "narzut", cokolwiek to
> miało by znaczyć. Ten "narzut" posiada również zalety które ignorujesz.
> To jest balans. Można stracić 5% dysku i zyskać znaczące ficzery w kodzie.
>
> >> Ja zaś, rozumiesz, mialem taki przypadek że kiedys jak siadałem to pękło
> >> ramię w fotelu na kółkach i przewróciłem kubek z herbata na klawiature.
> >> Z tego wniosek że LG wszystkie klawiatury dziadowskie robi.
> > Ja takiego wniosku bym nie wyciągnął, ale cieszę się, że się z nami tym
podzieliłeś.
>
> Ty zas wyciągasz wnioski z nagłówka dll i nie widzisz swojej
> śmieszności? Sprowadzenie dyskutanta do pozimu własnych absurdów czasem
> działa ale tutaj widać nie bardzo.
>
> >>> Może to jest jakiś trop?
> >> Nie. To tylko brednie.
> > Więc powinno być bardzo łatwo to wykazać.
>
> Oczywiscie. Mam kilka dllek które z róznych względow musza się
> kompilować rownież do .lib. Nie są małe, mają w sumie może z 100MB. Czy
> to lib czy dll rozmiar plików jest podobny z dokładnością do szumu.
> Zadziwiające, nie? A już przeciez chciałeś pisać do MS że mają poważnego
> buga w implementacji dll...
>
> > A tymczasem od początku stwierdziłeś, że odpowiedniego doświadczenia nie możesz
przeprowadzić.
>
> Nie możesz. To nie jest tylko przestawienie switcha w projekcie. Tak to
> dziala dla helloworldow. Dla duzych aplikacji jest to nie możliwe.
> Przyczyn jest tak wiele że uważam za bezensowne dyskutowanie nad nimi.
>
> >> Więc zatrudnij się w jednej z większych firm programistycznych w okolicy
> > A mógłbyś coś polecić?
>
> Nie, miałbym ich na sumieniu.
>
> >> doświadczenia hobbystyczne z hello world mają się nijak do praktyki.
> > Praktyka jest taka, że nie ma motywacji, żeby było optymalnie. Sam tak napisałeś.
>
> Jest optymalne w granicach mozliwosci technicznych, tylko funkcja celu
> jest zupełnie inna niż myślisz. Jest skomplikowana.
>
> >>> A jeśli mam jedną zmienną statyczną, która jest kontenerem rzeczy, które będą
do niego dodane później?
> >> Znowu masz opcje: idziesz do kierownika projektu i nazywasz go
> >> imbecylem,
> > Znowu wyzwiska.
>
> Sam wyzywasz ludzi na około twierdząc że popełniają trywialne błedy z
> dllkami i na pewno da sie je zredukować. No więc pewno się w niewielkim
> stopniu da tylko PO CO?
>
> > A może faktycznie można mieć mniej zmiennych statycznych?
> > Albo nawet w ogóle ich nie mieć?
>
> Idiotyczna rada. Nigdy jak widać nie pracowaleś nad projektem który ma
> ~20 lat kodu stukanego przez 4 pokolenia ludzi. Najlepiej idź i wyjasnij
> że trzeba wszystko przepisać w C#. Na pewno znajdziesz zrozumienie, może
> nawet ktoś poklepie po ramieniu współczując.
>
> >> Brakuje ci pokory
> > Bo podałem liczby, z którymi nie wiesz, co zrobić?
>
> Brakuje Ci pokory abys zrozumiał że Twoje trywialne obliczenia z
> helloworlda sa gówno warte w zderzeniu z rzeczywistościa gdzie kod
> przytłacza, problemy sa nie do znalezienia na stackoverflow, gdzie
> kompilatorom kończy się stos przy linkowaniu, gdzie milisekundy
> ładowania aplikacji mają znaczenie dla testowania, gdzie istnieją w
> ogóle jakieś testy, gdzie istnieje inzynieria programowania, gdzie
> zespoły sa rozproszone w nastu miejscach na świecie itd itp setki
> powodów. Zazwyczaj organizacyjnych a nie programistycznych, ale mających
> wpływ na programowanie.
>
> >> Możesz zacząć od
> >> sprawdzenia ile dllek jest w windowsie 10 po instalacji
> > Faktycznie można od tego zacząć, bo w pierwszym poście w tej dyskusji napisałem,
że base-system jest wyjątkiem, gdzie kod dzielony jest uzasadniony. Ale dyskutujemy o
aplikacjach.
>
> Które zachowują się jak systemy operacyjne. Mają wlasne uniwersalne
> abstrakcje, własne utility, współdziela kod między modułami itd itp. Nie
> istnieje wyraźna roznica w złożoności jednego czy drugiego pod względem
> podziału na funkcjonalności. Byłes już u tych imbecyli z Photoshopa aby
> im wyjaśnić jak głupi sa nie linkując statycznie wszystkiego? Może nie
> wiedza że powinni? Bigbounty czeka.
>
> >>> Jeśli w ogóle mam jakąś architekturę, to od razu zakładam, że jest rozproszona
> >> Brednia. Nic nie zakaldasz bo nie ma takiego założenia.
> > Tak zakładam i do tej pory się to sprawdzało.
>
> Powiedz to kolesiom od gcc na ten przykład. Że powinni zakładać ze
> linker odpali sie gdzie indziej niż kompilator.
>
> Wiesz dlaczego to głupie? Bo tak wlasnie można zrobić
> distcc/IncrediBuild tylko że w tym celu w gcc nie trzeba linkować
> niczego statycznie ani w ogóle o tym wiedzieć.
>
> > Co ciekawe, zrobiłem zgodnie z Twoim zaleceniem i zerknałem do branży EDA, żeby
skonfrontować swoje hobbystyczne wyobrażenie z prawdziwym światem:
> > https://www.google.com/patents/US20070073809
> > i popatrz jaka niespodzianka - tam też się sprawdziło.
>
> Nie, to najzwyczajniej nie na temat.
>
> > (Właśnie dlatego nie traktuję branży EDA jako wyjątkowego źródła olśnień albo
przykładów. Branża jak inne.)
>
> Nie, jest specyficzna. Jest znacznie wieksza niż "największe znane
> aplikacje jakie widział kowalski w bogatej firmie".
>
> >> Zakładasz że oprogramowanie pisza gimazjaliści na zlecenie?
> > O, w poprzedniej dyskusji też coś wspominałeś o gimnazjalistach.
>
> Bo tylko gimnazjalista mógłby zapomieć wyładować dllkę i tylko
> gimnazjalista mogłby nie napisać na to testu i tylko popsute testowanie
> benchmarkowe mogło by tego nie wykryć.
>
> Innymi słowy tak, są firmy gdzie gimnazjalisci pisza soft. Niektórzy
> mają 50 lat, ale to stan umysłu bardziej. I tak, niektórzy z obawy że
> zapomna wyładować dllkę z pamięci linkuja wszystko statycznie,
> niewątpliwie gdzieś tacy są. No bo jak spieprzyć to raz a dobrze.
>
> >> No wiec to
> >> też prawda, ale nie dotyczy raczej aplikacji po kilka GB kodu.
> > Ale jeszcze nie wykazałeś, że te GB są uzasadnione.
>
> W tej chwili właśnie strzeliłeś w pysk programistów wszystkich dużych
> aplikacji. I serio, masz czelnośc twierdzić że to ja obrażam ludzi?
>
> > Wręcz przeciwnie - sam wskazałeś, że nie ma motywacji, żeby było tego mniej
>
> Ten kod jest niezbędny. Jesli chcesz go zredukować to uzyskasz 5-10%
> nadludzkim wysiłkiem. Obawiam się że Twojego magebajta z gigabajta nie
> da się uzyskać bez usuwania ficzerów.
>
> >, czym tylko utwierdziłeś mnie w moich wątpliwościach w tym temacie.
>
> Dalej masz wątpliwosci nad faktami?
>
> >> To nie sa obliczenia. To brednie.
> > Ciekawe, ile osób przekonałeś.
>
> Moim celem jest tylko ekspozycja bredni. Nie mam interesu w
> przekonywaniu kogokolwiek.

mnie tak czy owak nadal ciekawi cos to za program ktorego process (chyba tak mozna to
nazwac mam na mysli startowy exe i grupe wgrywanych do przestrzeni procesu jego
skladnikow w postaci dll-ek) ma 3 GB czy cos kolo tego

szczerze mowiac to powątpiewam - (acz scisle nie jest to niemozliwe) niech ktos powie
jeszcze ze dziala na 32 bitowym windowsie ;c wtedy musi miec diablo malo ramo skoro
zapchal zala przestrzen adresową

wogole to nalezaloby znac takie programy bo moznaby/trzebby wpisac konkretne info do
ksiegi rekordów guinessa (yawn)

[tak naprawde 5 MB dllka to jest jus naprawde duzy kawał kodu, duza gra albo duzy
fragment windowsa etc

jesli chodzi o zasoby mojego dysku to chyba najwiekszą dll-a jest opera.dll 60 MB
(niejaki libcef.dll tez jest duze, ew niejaki xul.dll z firefoxa) ale raczej nie jest
to sam kod tylko nawaalane czy pozaszywanej jest tam na pewno kupe resourców czy
przynajmniej zahardkorowanych tabel - takie cos sie nie liczy*

* co prawda plugin do TC pokazuje

Size of code 03116200h
Size of initialized data 00CA9600h

teoretyczni powinien to byc rozmiar
sekcji kodu i jest to calkiem duzo (50 MB) ale bez glebszego sprawdzenia ciezko orzec
czy tego naprawde tam jest az tyle, moze natworzono tam jakich smieci albo
zarzucono jakies rozliczne alignmenty wielkiej ilosci kawałkow

moge jeszcze zrobic test i spakuje to opera.dll rarem co powinno pomoc oszacowac ile
tem jest ew pustego miejsca (co prawda nie wiem jak pakuje sie czysty kod) 63 MB
spakowaly sie do 22 MB rara ... chyba zwykly kod tez mw tak sie pakuje wiec trudno
powiedziec, trzebby disasemblowac itd by powiedziec wiecej

do góry

On Monday, November 20, 2017 at 5:26:22 PM UTC+1, fir wrote:
> W dniu poniedziałek, 20 listopada 2017 13:42:30 UTC+1 użytkownik Maciej Sobczak
napisał:
> > > Nie jesteś w stanie przeprowadzić doświadczenia, jest zbyt kosztowne.
> > > Możesz liczyć jednak że exe będzie miał powiedzmy 2GB rozmiaru jesli
> > > suma dllek jest rzedu 2.5GB.
> >
> > To ciekawa wartość. Bo np. o Linuksie (o jądrze, co niektórzy używają jako jakiś
znany punkt odniesienia w dyskusji o rozmiarach) mówi się, że ma ileś tam milionów
linii kodu i to jest warte ileś tam tysięcy lat pracy a po skompilowaniu jest tego
jakieś tam... megabajty. A tu mamy w dyskusji gigabajty. Z tego by wynikało, że tego
programu jest powiedzmy dwa rzędy wielkości więcej, niż Linuksa, czyli na oko miliard
linii kodu i milion lat pracy. Co z kolei każe poddać pod wątpliwość, czy w ogóle
taki program dało się na tej planecie napisać. A jeśli uznamy, że się nie dało, to
wniosek jest taki, że binarka jest rozdmuchana i pewnie da się z niej coś zdjąć.

Hello world w QT GUI w wersji debug wraz z libami zajmuje 0.5GB.

Pozdrawiam

do góry