Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > pl.comp.programming > #30838 > unrolled thread

Architektura aplikacji - powody wyłączania dll z exe

Back to article view | Back to pl.comp.programming

Contents

  Architektura aplikacji - powody wyłączania dll z exe szykcech@gmail.com - 2017-11-14 21:10 -0800
    Re: Architektura aplikacji - powody wyłączania dll z exe Tomasz Kaczanowski <kaczus@poczta.onet.pl> - 2017-11-15 08:01 +0100
      Re: Architektura aplikacji - powody wyłączania dll z exe szykcech@gmail.com - 2017-11-15 00:21 -0800
        Re: Architektura aplikacji - powody wyłączania dll z exe Tomasz Kaczanowski <kaczus@poczta.onet.pl> - 2017-11-15 09:44 +0100
    Re: Architektura aplikacji - powody wyłączania dll z exe Maciej Sobczak <see.my.homepage@gmail.com> - 2017-11-15 06:11 -0800
      Re: Architektura aplikacji - powody wyłączania dll z exe "M.M." <mmarszik@gmail.com> - 2017-11-18 02:38 -0800
        Re: Architektura aplikacji - powody wyłączania dll z exe Maciej Sobczak <see.my.homepage@gmail.com> - 2017-11-20 03:57 -0800
      Re: Architektura aplikacji - powody wyłączania dll z exe fir <profesor.fir@gmail.com> - 2017-11-19 05:02 -0800
        Re: Architektura aplikacji - powody wyłączania dll z exe fir <profesor.fir@gmail.com> - 2017-11-19 05:11 -0800
        Re: Architektura aplikacji - powody wyłączania dll z exe "M.M." <mmarszik@gmail.com> - 2017-11-19 23:08 -0800
      Re: Architektura aplikacji - powody wyłączania dll z exe michal@kleczek.org - 2017-11-19 09:26 -0800
        Re: Architektura aplikacji - powody wyłączania dll z exe michal@kleczek.org - 2017-11-19 09:28 -0800
    Re: Architektura aplikacji - powody wyłączania dll z exe Sebastian Biały <heby@poczta.onet.pl> - 2017-11-16 19:57 +0100
      Re: Architektura aplikacji - powody wyłączania dll z exe Maciej Sobczak <see.my.homepage@gmail.com> - 2017-11-17 01:29 -0800
        Re: Architektura aplikacji - powody wyłączania dll z exe Sebastian Biały <heby@poczta.onet.pl> - 2017-11-17 17:28 +0100
          Re: Architektura aplikacji - powody wyłączania dll z exe Maciej Sobczak <see.my.homepage@gmail.com> - 2017-11-20 04:42 -0800
            Re: Architektura aplikacji - powody wyłączania dll z exe fir <profesor.fir@gmail.com> - 2017-11-20 08:26 -0800
              Re: Architektura aplikacji - powody wyłączania dll z exe "M.M." <mmarszik@gmail.com> - 2017-11-21 22:52 -0800
            Re: Architektura aplikacji - powody wyłączania dll z exe Sebastian Biały <heby@poczta.onet.pl> - 2017-11-20 22:53 +0100
              Re: Architektura aplikacji - powody wyłączania dll z exe fir <profesor.fir@gmail.com> - 2017-11-20 14:57 -0800
              Re: Architektura aplikacji - powody wyłączania dll z exe Maciej Sobczak <see.my.homepage@gmail.com> - 2017-11-21 04:35 -0800
                Re: Architektura aplikacji - powody wyłączania dll z exe fir <profesor.fir@gmail.com> - 2017-11-21 08:17 -0800
                Re: Architektura aplikacji - powody wyłączania dll z exe Sebastian Biały <heby@poczta.onet.pl> - 2017-11-21 22:21 +0100
                  Re: Architektura aplikacji - powody wyłączania dll z exe fir <profesor.fir@gmail.com> - 2017-11-21 17:02 -0800
                  Re: Architektura aplikacji - powody wyłączania dll z exe Maciej Sobczak <see.my.homepage@gmail.com> - 2017-11-22 06:33 -0800
                    Re: Architektura aplikacji - powody wyłączania dll z exe Sebastian Biały <heby@poczta.onet.pl> - 2017-11-22 18:20 +0100
                      Re: Architektura aplikacji - powody wyłączania dll z exe Sebastian Biały <heby@poczta.onet.pl> - 2017-11-22 18:56 +0100
                      Re: Architektura aplikacji - powody wyłączania dll z exe Maciej Sobczak <see.my.homepage@gmail.com> - 2017-11-23 02:55 -0800
                        Re: Architektura aplikacji - powody wyłączania dll z exe fir <profesor.fir@gmail.com> - 2017-11-23 04:18 -0800
                        Re: Architektura aplikacji - powody wyłączania dll z exe "M.M." <mmarszik@gmail.com> - 2017-11-23 13:52 -0800
                        Re: Architektura aplikacji - powody wyłączania dll z exe Sebastian Biały <heby@poczta.onet.pl> - 2017-11-23 22:52 +0100
                Re: Architektura aplikacji - powody wyłączania dll z exe "M.M." <mmarszik@gmail.com> - 2017-11-21 23:05 -0800
                  Re: Architektura aplikacji - powody wyłączania dll z exe szykcech@gmail.com - 2017-11-22 09:45 -0800
                    Re: Architektura aplikacji - powody wyłączania dll z exe "M.M." <mmarszik@gmail.com> - 2017-11-23 13:35 -0800
                  Re: Architektura aplikacji - powody wyłączania dll z exe fir <profesor.fir@gmail.com> - 2017-11-23 04:26 -0800
                    Re: Architektura aplikacji - powody wyłączania dll z exe "M.M." <mmarszik@gmail.com> - 2017-11-23 13:57 -0800
                  Re: Architektura aplikacji - powody wyłączania dll z exe szykcech@gmail.com - 2017-11-23 09:10 -0800
                    Re: Architektura aplikacji - powody wyłączania dll z exe "M.M." <mmarszik@gmail.com> - 2017-11-23 14:04 -0800
                    Re: Architektura aplikacji - powody wyłączania dll z exe "AK" <nobody@nowhere.net> - 2017-11-27 09:57 +0100
                      Re: Architektura aplikacji - powody wyłączania dll z exe "M.M." <mmarszik@gmail.com> - 2017-11-27 04:20 -0800
                        Re: Architektura aplikacji - powody wyłączania dll z exe "AK" <nobody@nowhere.net> - 2017-11-30 01:16 +0100
                          Re: Architektura aplikacji - powody wyłączania dll z exe "M.M." <mmarszik@gmail.com> - 2017-11-30 08:27 -0800
                            Re: Architektura aplikacji - powody wyłączania dll z exe "AK" <nobody@nowhere.net> - 2017-12-01 01:22 +0100
                              Re: Architektura aplikacji - powody wyłączania dll z exe "M.M." <mmarszik@gmail.com> - 2017-12-01 04:21 -0800
                                Re: Architektura aplikacji - powody wyłączania dll z exe fir <profesor.fir@gmail.com> - 2017-12-01 07:42 -0800
                                Re: Architektura aplikacji - powody wyłączania dll z exe Roman Tyczka <noemail@because.no> - 2017-12-01 20:14 +0100
                                  Re: Architektura aplikacji - powody wyłączania dll z exe "M.M." <mmarszik@gmail.com> - 2017-12-01 15:11 -0800
                                    Re: Architektura aplikacji - powody wyłączania dll z exe fir <profesor.fir@gmail.com> - 2017-12-01 17:02 -0800
                                      Re: Architektura aplikacji - powody wyłączania dll z exe "AK" <nobody@nowhere.net> - 2017-12-02 09:24 +0100
                                        Re: Architektura aplikacji - powody wyłączania dll z exe fir <profesor.fir@gmail.com> - 2017-12-02 03:15 -0800
                                          Re: Architektura aplikacji - powody wyłączania dll z exe fir <profesor.fir@gmail.com> - 2017-12-02 03:43 -0800
                                            Re: Architektura aplikacji - powody wyłączania dll z exe "AK" <nobody@nowhere.net> - 2017-12-02 16:15 +0100
                                              Re: Architektura aplikacji - powody wyłączania dll z exe fir <profesor.fir@gmail.com> - 2017-12-02 07:26 -0800
                                          Re: Architektura aplikacji - powody wyłączania dll z exe "AK" <nobody@nowhere.net> - 2017-12-02 16:12 +0100
                                    Re: Architektura aplikacji - powody wyłączania dll z exe "AK" <nobody@nowhere.net> - 2017-12-02 09:15 +0100
                                  Re: Architektura aplikacji - powody wyłączania dll z exe "AK" <nobody@nowhere.net> - 2017-12-02 08:59 +0100
      Re: Architektura aplikacji - powody wyłączania dll z exe szykcech@gmail.com - 2017-11-17 06:23 -0800
        Re: Architektura aplikacji - powody wyłączania dll z exe Sebastian Biały <heby@poczta.onet.pl> - 2017-11-17 17:35 +0100
          Re: Architektura aplikacji - powody wyłączania dll z exe szykcech@gmail.com - 2017-11-17 09:11 -0800
            Re: Architektura aplikacji - powody wyłączania dll z exe Sebastian Biały <heby@poczta.onet.pl> - 2017-11-17 18:29 +0100
    Re: Architektura aplikacji - powody wyłączania dll z exe fir <profesor.fir@gmail.com> - 2017-11-19 04:21 -0800
      Re: Architektura aplikacji - powody wyłączania dll z exe fir <profesor.fir@gmail.com> - 2017-11-20 08:31 -0800
        Re: Architektura aplikacji - powody wyłączania dll z exe "M.M." <mmarszik@gmail.com> - 2017-11-21 22:56 -0800
          Re: Architektura aplikacji - powody wyłączania dll z exe Mateusz Bogusz <mabakay@o2.pl> - 2017-11-22 21:09 +0100
            Re: Architektura aplikacji - powody wyłączania dll z exe "M.M." <mmarszik@gmail.com> - 2017-11-23 13:44 -0800
              Re: Architektura aplikacji - powody wyłączania dll z exe Mateusz Bogusz <mabakay@o2.pl> - 2017-11-29 22:09 +0100
      Re: Architektura aplikacji - powody wyłączania dll z exe fir <profesor.fir@gmail.com> - 2017-11-22 12:09 -0800
    Re: Architektura aplikacji - powody wyłączania dll z exe szykcech@gmail.com - 2018-09-12 10:55 -0700

Page 1 of 4  [1] 2 3 4  Next page →

#30838 — Architektura aplikacji - powody wyłączania dll z exe

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

--
http://szyk.jcom.pl/
http://szyk.free.of.pl/
http://szykcech.cba.pl/
http://szyk.000webhostapp.com/
http://www.geocities.ws/szyk/
http://szyk.wex.pl/

[toc] | [next] | [standalone]

#30839

W dniu 2017-11-15 o 06:10, szykcech@gmail.com pisze:
> 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ć.

jedynie punkt 1 jest sensowny
dodam 4, czasami pewne funkcjonalności mogą być wariantowo dodawane do 
programu.

Dodatkowo nie zauważyłem takiego zjawiska...

Pozdrawiam
-- 
http://kaczus.ppa.pl
http://zrzeda.pl

[toc] | [prev] | [next] | [standalone]

#30840

> Dodatkowo nie zauważyłem takiego zjawiska...

Acrobat Reader
Mozilla FireFox
Dia
Google Chrome
Internet Explorer
Libre Office
VLC
7-zip

To tak na szybko po przeglądnięciu katalogów Program Files i PF (x86)...

Po za tym prosiłbym o wypowiedź osób które znają to zjawisko...

[toc] | [prev] | [next] | [standalone]

#30841

W dniu 2017-11-15 o 09:21, szykcech@gmail.com pisze:
>> Dodatkowo nie zauważyłem takiego zjawiska...
> 
> Acrobat Reader
> Mozilla FireFox
> Dia
> Google Chrome
> Internet Explorer
> Libre Office
> VLC
> 7-zip
> 
> To tak na szybko po przeglądnięciu katalogów Program Files i PF (x86)...
> 
> Po za tym prosiłbym o wypowiedź osób które znają to zjawisko...
> 

wymieniłeś rzeczy, które właśnie są bardzo zależne od wariantowych 
bibliotek, program główny jest w zasadzie oknem, które steruje resztą...

Część z nich można kompilować tez tak, że będziesz miał część bibliotek 
zewnętrznych wkompilowanych, ale jest to bezsensowne. Podobnie masz np z 
jądrem linuksa, możesz część rzeczy mieć wkompilowanych w jądro, albo 
jako zewnętrzne moduły. Nie ma to nic wspólnego z testowaniem...

-- 
http://zrzeda.pl
http://kaczus.republika.pl

[toc] | [prev] | [next] | [standalone]

#30842

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

Zamieszam trochę: od dłuższego czasu jestem zwolennikiem linkowania statycznego wszystkiego co nie jest base-systemem. Życie mi się uprościło.

Dopuszczam DLL-ki tam, gdzie elementy programu mogą być pozyskiwane niezależnie od głównego programu i ten ficzer jest istotną częścią filozofii używania danego programu (np. pluginy).

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

[toc] | [prev] | [next] | [standalone]

#30850

On Wednesday, November 15, 2017 at 3:11:20 PM UTC+1, Maciej Sobczak wrote:
> Zamieszam trochę: od dłuższego czasu jestem zwolennikiem linkowania
> statycznego wszystkiego co nie jest base-systemem. Życie mi się uprościło.

Kilka pytań:

Jaki rozmiar mają Twoje pliki wynikowe?

Ile czasu czekasz na kompilacje/zlinkowanie po zmianie jednej 
linijki w pliku cpp/h ? Czy linkiery potrafią wykorzystać wiele rdzeni albo
GPU? Mnie ten problem na tyle bolał, że napisałem swój generator
plików make.


Z jakich bibliotek korzystasz? Czy masz łatwo dostępne prekompilowane
wersje do wkompilowywania statycznego? Jeśli nie masz, ile czasu 
prekompilowałeś sam?


Jak rozwiązujesz problem dopasowania kodu do systemu? Bo w przypadku 
dll po prostu ładuje się inną bibliotekę.


Czy w pracy zespołowej przydzielenie osobnym programistom/pod-zespołom
wykonanie osobnych plików dll/pluginów nie przyspieszałoby i nie
upraszczałoby realizacji całego projektu?


Pozdrawiam

[toc] | [prev] | [next] | [standalone]

#30857

> Kilka pytań:
> 
> Jaki rozmiar mają Twoje pliki wynikowe?

Relatywnie[*] nieduży, do kilku MB.

[*] Relatywnie, bo w relacji do danych, których mogę mieć dowolnie dużo.

> Ile czasu czekasz na kompilacje/zlinkowanie po zmianie jednej 
> linijki w pliku cpp/h ?

Kilka(naście) sekund.

> Czy linkiery potrafią wykorzystać wiele rdzeni

Linker nie musi. Natomiat jest sens kompilować równolegle, służy do tego opcja -j w make'u (i świetnie się sprawdza).

> Mnie ten problem na tyle bolał, że napisałem swój generator
> plików make.

Nie miałem takiej potrzeby.

> Z jakich bibliotek korzystasz?

Różnych!

> Czy masz łatwo dostępne prekompilowane
> wersje do wkompilowywania statycznego? Jeśli nie masz, ile czasu 
> prekompilowałeś sam?

Skoro robię coś tylko raz, to nie mierzę, ile to trwa.

> Jak rozwiązujesz problem dopasowania kodu do systemu?

Co to znaczy?

> Bo w przypadku 
> dll po prostu ładuje się inną bibliotekę.

A w przypadku linkowania statycznego po prostu linkuje się inną bibliotekę.

> Czy w pracy zespołowej przydzielenie osobnym programistom/pod-zespołom
> wykonanie osobnych plików dll/pluginów nie przyspieszałoby i nie
> upraszczałoby realizacji całego projektu?

A w czym to miałoby być prostsze? Efektem wykonania zadania jest nowy kod a nie plik wykonywalny. Sposób linkowania jest zupełnie drugorzędny - i w chwili zlecania takiego zadania może nawet nie być jeszcze znany (czyli: nie zdecydowałem jeszcze, jak to będę linkował, ale napisz mi funkcję do liczenia czegośtam).
Zauważ, że gdybyśmy mówili o językach skryptowych (np. Python), to w ogóle ta kwestia nie miałaby znaczenia przy zlecaniu zadania. W C++ też nie ma potrzeby tej kwesti na takim etapie adresować. Dlatego sposób linkowania nie wpływa (tzn. nie widzę potrzeby, żeby wpływał) na organizację pracy zespołowej.

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

[toc] | [prev] | [next] | [standalone]

#30852

W dniu środa, 15 listopada 2017 15:11:20 UTC+1 użytkownik Maciej Sobczak napisał:
> > 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?
> 
> Zamieszam trochę: od dłuższego czasu jestem zwolennikiem linkowania statycznego wszystkiego co nie jest base-systemem. Życie mi się uprościło.
> 
> Dopuszczam DLL-ki tam, gdzie elementy programu mogą być pozyskiwane niezależnie od głównego programu i ten ficzer jest istotną częścią filozofii używania danego programu (np. pluginy).
> 

ja odwrotnie, kompilowanie ststyczne to dla mnie za duzo roboty

bo o ile pamietam (nie jestem pewien czy dobrze pamietam ale chyba tak) aby statyczny linker dzialal 'wybiórczo' nie wystarczy zlinkowac duzego pojedynczego pliku.o (powiedzmy 5 MB) - jesli uzywamy tylko jednej prostej funkcji z tego obiektu i tak statyczny linker zlinkuje 5 MB -
aby dzialal wybiórczo tworca tej
liby musialby kompilowac ja do wielu skladowych .o i potem pakowac ja w jedną zbiorczą libe .lib 
(tak mi sie przynajmniej wydaje bo co ciekawe nigdy o tym wiecej nie czytalem i nigdy jakos specjalnie tego nie uzywalem itd) tak ze to jest ok (dodatkowo np pozwala kompilowac rozne podkawalki z roznymi opcjami kompilacji) ale wymaga zauwazalnej ilosci dodatkowej roboty a dla mnie dodatkowa robota jest zwykle denerwujaca (ta robota moglaby byc 
byc moze mniejsza gdyby toole robily troche wiecej z automatu itp, tak naprawde mozna tez zauwazyc ze dynamiczne linkowanie 
tez mogloby byc zrobione tak by dzialac wybiórczo acz to by co nieco skomplikowalo sprawy)

dla mnie linkowanie dllek jest ok 
tyle ze nalezy moze jedynie pamietac by te dllki mialy rozsądne
rozmiary (rozsądna jak na dzis to dla mnie  chyba do 10 MB na jedną)
oraz by dependencje miedzy nimi byly jak najmniejsze (tj by nie bylo ich duzo i jak juz sa by mialy w swoim secie jak najmniej dependencji (te dependencje miedzy dllkami mozna zliczajac zliczajac kreseczki importow na grafie miedzy dllkami, (mowie o importach calej dllki nie pszczegolnych symboli) 
np jak ktos mialby 10 dllek z ktorych kazda importowalaby kazda inną to w sumie zdaje sie tych dependencji byloby 90 - za duzo,
u mnie w moich projektach mam na
przyklad zaleznosc/import do green.fire.dll ktora z kolei ma importy do 7 systemowych dllek (kernel32.dll gdi32.dll msvcrt.dll psapi.dll user32.dll winmm.dll ws2_32.dll) sam exe moze tez siegac do niektorych bezposrednio (akurat moj klient irca siega bezposrednio do kernel32 (i do msvcrt.dll choc to jest zrozumiela) na 12 funkcji (dotyczacych critcal section, tls, exit process, get masage adress itp, i tego ciagle do konca troche nie lapie szczerze mowiac, czy to gcc wkompilowuje te 12 funkci jako normalne calle w startupie mojego kodu czy tez moze tworzy sobie takie importy tak troszke jakby na wyrost?) (wiem przynajmniej jedno, jak sam zasembluje sobie swoim asemblerem swoj plik exe to moge miec eleganckie zero importow mimo ze program dziala (i pisze na konsole przez msvcrt.printf - hmm - w takim razie to tez jest dziwne, moze moj exe oszukuje plugin do total commandera bo importy dzialają ale sie nie pokazują)

[toc] | [prev] | [next] | [standalone]

#30853

W dniu niedziela, 19 listopada 2017 14:02:54 UTC+1 użytkownik fir napisał:
> W dniu środa, 15 listopada 2017 15:11:20 UTC+1 użytkownik Maciej Sobczak napisał:
> > > 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?
> > 
> > Zamieszam trochę: od dłuższego czasu jestem zwolennikiem linkowania statycznego wszystkiego co nie jest base-systemem. Życie mi się uprościło.
> > 
> > Dopuszczam DLL-ki tam, gdzie elementy programu mogą być pozyskiwane niezależnie od głównego programu i ten ficzer jest istotną częścią filozofii używania danego programu (np. pluginy).
> > 
> 
> ja odwrotnie, kompilowanie ststyczne to dla mnie za duzo roboty
> 
> bo o ile pamietam (nie jestem pewien czy dobrze pamietam ale chyba tak) aby statyczny linker dzialal 'wybiórczo' nie wystarczy zlinkowac duzego pojedynczego pliku.o (powiedzmy 5 MB) - jesli uzywamy tylko jednej prostej funkcji z tego obiektu i tak statyczny linker zlinkuje 5 MB -
> aby dzialal wybiórczo tworca tej
> liby musialby kompilowac ja do wielu skladowych .o i potem pakowac ja w jedną zbiorczą libe .lib 
> (tak mi sie przynajmniej wydaje bo co ciekawe nigdy o tym wiecej nie czytalem i nigdy jakos specjalnie tego nie uzywalem itd) tak ze to jest ok (dodatkowo np pozwala kompilowac rozne podkawalki z roznymi opcjami kompilacji) ale wymaga zauwazalnej ilosci dodatkowej roboty a dla mnie dodatkowa robota jest zwykle denerwujaca (ta robota moglaby byc 
> byc moze mniejsza gdyby toole robily troche wiecej z automatu itp, tak naprawde mozna tez zauwazyc ze dynamiczne linkowanie 
> tez mogloby byc zrobione tak by dzialac wybiórczo acz to by co nieco skomplikowalo sprawy)
> 
> dla mnie linkowanie dllek jest ok 
> tyle ze nalezy moze jedynie pamietac by te dllki mialy rozsądne
> rozmiary (rozsądna jak na dzis to dla mnie  chyba do 10 MB na jedną)
> oraz by dependencje miedzy nimi byly jak najmniejsze (tj by nie bylo ich duzo i jak juz sa by mialy w swoim secie jak najmniej dependencji (te dependencje miedzy dllkami mozna zliczajac zliczajac kreseczki importow na grafie miedzy dllkami, (mowie o importach calej dllki nie pszczegolnych symboli) 
> np jak ktos mialby 10 dllek z ktorych kazda importowalaby kazda inną to w sumie zdaje sie tych dependencji byloby 90 - za duzo,
> u mnie w moich projektach mam na
> przyklad zaleznosc/import do green.fire.dll ktora z kolei ma importy do 7 systemowych dllek (kernel32.dll gdi32.dll msvcrt.dll psapi.dll user32.dll winmm.dll ws2_32.dll) sam exe moze tez siegac do niektorych bezposrednio (akurat moj klient irca siega bezposrednio do kernel32 (i do msvcrt.dll choc to jest zrozumiela) na 12 funkcji (dotyczacych critcal section, tls, exit process, get masage adress itp, i tego ciagle do konca troche nie lapie szczerze mowiac, czy to gcc wkompilowuje te 12 funkci jako normalne calle w startupie mojego kodu czy tez moze tworzy sobie takie importy tak troszke jakby na wyrost?) (wiem przynajmniej jedno, jak sam zasembluje sobie swoim asemblerem swoj plik exe to moge miec eleganckie zero importow mimo ze program dziala (i pisze na konsole przez msvcrt.printf - hmm - w takim razie to tez jest dziwne, moze moj exe oszukuje plugin do total commandera bo importy dzialają ale sie nie pokazują)

wiem tez z doswiadczenia (z moim wlasnym asemblerem ) ze odnoscnika do kernel32.dll program tak naprawde nie potrzebuje: niektorzy wywolują exit process na koniec programu ale zwykle ret (aloi nawet program zlozony wylacznie z ret (0xc3)) tez dziala (i to komicznie bo taki program przy uruchomieniu tylko blinka czy tez ew wywoluje jakby 'no reaction' ;c tak jak zreszta chyba powinno byc)

[toc] | [prev] | [next] | [standalone]

#30856

On Sunday, November 19, 2017 at 2:02:54 PM UTC+1, fir wrote:
> ja odwrotnie, kompilowanie ststyczne to dla mnie za duzo roboty

Wszystko zależy od okoliczności. Jeśli aplikacja korzysta z kilku
nie za dużych bibliotek 'poza systemowych', a poza tym z systemu, to
skompilowanie statyczne faktycznie wszystko upraszcza - jeden
plik copy-paste i działa. Gorzej, gdy trzeba zlinkować pól giga - 
nie wiem czy to w ogóle jest możliwe w rozsądnym czasie.


> bo o ile pamietam (nie jestem pewien czy dobrze pamietam ale chyba tak) aby
> statyczny linker dzialal 'wybiórczo' 

Kiedyś czytałem że to jest w ogóle niemożliwe w przypadku języków c/c++. 
Uzasadnienia autor nie podawał - ja uwierzyłem.


> nie wystarczy zlinkowac duzego pojedynczego pliku.o (powiedzmy 5 MB) - jesli uzywamy tylko jednej prostej funkcji z tego obiektu i tak statyczny linker zlinkuje 5 MB -
> aby dzialal wybiórczo tworca tej
> liby musialby kompilowac ja do wielu skladowych .o i potem pakowac ja w jedną zbiorczą libe .lib 
Tak, twórca musiałby dostosować liba do linkowania statycznego, ale to i 
tak na nic, jeśli jedna funkcja wywołuje drugą, itd.


> (tak mi sie przynajmniej wydaje bo co ciekawe nigdy o tym wiecej nie czytalem i nigdy jakos specjalnie tego nie uzywalem itd) tak ze to jest ok (dodatkowo np pozwala kompilowac rozne podkawalki z roznymi opcjami kompilacji) ale wymaga zauwazalnej ilosci dodatkowej roboty a dla mnie dodatkowa robota jest zwykle denerwujaca (ta robota moglaby byc 
> byc moze mniejsza gdyby toole robily troche wiecej z automatu 

Pracowałem na kilku bibliotekach w visual studio i wszystko działo się z
automatu, tylko wybierałem czy statycznie czy dynamicznie.


> itp, tak naprawde mozna tez zauwazyc ze dynamiczne linkowanie 
> tez mogloby byc zrobione tak by dzialac wybiórczo acz to by co nieco skomplikowalo sprawy)

Musiałby być kod źródłowy i podpowiedzi kompilatora który element kodu
zależy od którego, bo po samym call nie wiem czy kompilator w ogóle
może wywnioskować.


> dla mnie linkowanie dllek jest ok 
> tyle ze nalezy moze jedynie pamietac by te dllki mialy rozsądne
> rozmiary (rozsądna jak na dzis to dla mnie  chyba do 10 MB na jedną)
> oraz by dependencje miedzy nimi byly jak najmniejsze (tj by nie bylo ich duzo i jak juz sa by mialy w swoim secie jak najmniej dependencji (te dependencje miedzy dllkami mozna zliczajac zliczajac kreseczki importow na grafie miedzy dllkami, (mowie o importach calej dllki nie pszczegolnych symboli) 
> np jak ktos mialby 10 dllek z ktorych kazda importowalaby kazda inną to w sumie zdaje sie tych dependencji byloby 90 - za duzo,

A co ze statycznymi zmiennymi? Jeśli lib ma działać 'od zera' to przynajmniej
jego dane trzeba zaimportować. By trzeba dane statyczne podmieniać przed
wywoływaniem metody z innego dll... nie wiem jak to jest w praktyce, ale
coś mi się wydaje, że po protu ładuje się liby jak są potrzebne i nie
ma że za dużo.


> u mnie w moich projektach mam na
> przyklad zaleznosc/import do green.fire.dll ktora z kolei ma importy do 7 systemowych dllek (kernel32.dll gdi32.dll msvcrt.dll psapi.dll user32.dll winmm.dll ws2_32.dll) sam exe moze tez siegac do niektorych bezposrednio (akurat moj klient irca siega bezposrednio do kernel32 (i do msvcrt.dll choc to jest zrozumiela) na 12 funkcji (dotyczacych critcal section, tls, exit process, get masage adress itp, i tego ciagle do konca troche nie lapie szczerze mowiac, czy to gcc wkompilowuje te 12 funkci jako normalne calle w startupie mojego kodu czy tez moze tworzy sobie takie importy tak troszke jakby na wyrost?) (wiem przynajmniej jedno, jak sam zasembluje sobie swoim asemblerem swoj plik exe to moge miec eleganckie zero importow mimo ze program dziala (i pisze na konsole przez msvcrt.printf - hmm - w takim razie to tez jest dziwne, moze moj exe oszukuje plugin do total commandera bo importy dzialają ale sie nie pokazują)

Nie rozumiem, to już jakieś Twoje bardzo specyficzne (co nie znaczy że
złe) rozwiązanie.

Pozdrawiam

[toc] | [prev] | [next] | [standalone]

#30854

On Wednesday, November 15, 2017 at 3:11:20 PM UTC+1, Maciej Sobczak wrote:
> > 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?
> 
> Zamieszam trochę: od dłuższego czasu jestem zwolennikiem linkowania statycznego wszystkiego co nie jest base-systemem. Życie mi się uprościło.
> 

Eee tam. Staromodny jestes. Trzeba tworzyc obrazy Dockera!

--
Michal

[toc] | [prev] | [next] | [standalone]

#30855

On Sunday, November 19, 2017 at 6:26:06 PM UTC+1, mic...@kleczek.org wrote:
> On Wednesday, November 15, 2017 at 3:11:20 PM UTC+1, Maciej Sobczak wrote:
> > > 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?
> > 
> > Zamieszam trochę: od dłuższego czasu jestem zwolennikiem linkowania statycznego wszystkiego co nie jest base-systemem. Życie mi się uprościło.
> > 
> 
> Eee tam. Staromodny jestes. Trzeba tworzyc obrazy Dockera!
> 

Aha - zapomnialem.
Dllki nalezy koniecznie przerobic na mikrousługi.

--
Michal

[toc] | [prev] | [next] | [standalone]

#30843

On 11/15/2017 6:10 AM, szykcech@gmail.com wrote:
> Moje pytanie brzmi: Dlaczego wyłącza się dll z exe?

Aby nie ładować wszystkiego na raz do pamięci. Przeciętna poważna 
aplikacja może mieć sumę zajmowanego kodu w dll w granicach kilku GB.

[toc] | [prev] | [next] | [standalone]

#30844

> Aby nie ładować wszystkiego na raz do pamięci. Przeciętna poważna 
> aplikacja może mieć sumę zajmowanego kodu w dll w granicach kilku GB.

A ile ta przeciętna poważna aplikacja zajmowałaby gdyby była zlinkowana statycznie?

Przykład obrazkowy (nierealny, ale łatwy): jest biblioteka funkcji, nich będzie, że matematycznych. Jest tam 1000 funkcji i biblioteka w postaci DLL ma 1000MB, czyli średnio 1MB/funkcję. Program korzysta tylko z jednej funkcji i powiedzmy, że jest ona niezależna od innych. Taki program wciąga 1GB DLL dynamicznie (i korzysta tylko z 1 promila tego) albo jest tylko o 1MB grubszy statycznie.

To nie jest taki całkiem nierealny przykład, zwłaszcza jeśli mówimy o bibliotekach masowego rażenia, np. GUI albo innych 3rd-party. Przeciętny program używa tylko ułamka takich bibliotek i jeśli jest linkowany statycznie, to jego ciężar może być znacznie mniejszy, niż suma wszystkich bezpośrednio i pośrednio wciąganych DLLek. Czas startu takiego programu też będzie mniejszy, nie tylko z powodu mniejszego rozmiaru (czyli mniejszej ilości danych do wczytania), ale też z powodu braku konieczności patchowania symboli z dynamicznie wczytanych bibliotek (jeśli taki mechanizm w danym systemie występuje).

Ponawiam pytanie: ile przeciętna poważna aplikacja (taka na kilka GB) zajmuje po statycznym linkowaniu? I jak to wpływa na jej czas uruchamiania?

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

[toc] | [prev] | [next] | [standalone]

#30846

On 11/17/2017 10:29 AM, Maciej Sobczak wrote:
> A ile ta przeciętna poważna aplikacja zajmowałaby gdyby była zlinkowana statycznie?

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. Wyssałem to z palca, ale palec wcześniej 
miał kontakt z takimi rozmiarami i takim kodem.

> Przykład obrazkowy (nierealny, ale łatwy): jest biblioteka funkcji, nich będzie, że matematycznych. Jest tam 1000 funkcji i biblioteka w postaci DLL ma 1000MB, czyli średnio 1MB/funkcję. Program korzysta tylko z jednej funkcji i powiedzmy, że jest ona niezależna od innych. Taki program wciąga 1GB DLL dynamicznie (i korzysta tylko z 1 promila tego) albo jest tylko o 1MB grubszy statycznie.

Opisujesz inny przypadek. Ja opisuje przypadek kiedy *cały* kod w 
dllkach jest unikatowy, używay, ale niekoniecznie ładowany od razu bo 
nie ma takiej potrzeby.

> Ponawiam pytanie: ile przeciętna poważna aplikacja (taka na kilka GB) zajmuje po statycznym linkowaniu? I jak to wpływa na jej czas uruchamiania?

Nie przypuszczam abyś dal radę przeprowadzić to doświadczenie. Ale 
pozwole sobie na podstawie własnych doświadczeń zasugerować że:
a) mniej więcej tyle samo co suma dll minus specjalizacje templates i 
meta szum dll
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.
c) ilośc danych do relokacji od razu jest znacząco większa

Jeśli chcesz zobaczyć *naprawdę* duże aplikacje to zerknij na rynek EDA. 
Np. sciągnij instalator Vivado, który wcale nie jest jakoś specjalnie 
duży jak na ta branżę a na przeciętnym klikaczu robi wrażenie. Ten 
projekt, gdyby go statycznie zlinkowac, miał by całkiem sporo problemów 
związanych z czasami ladowania, zajętością pamięci, współdzieleniem kodu 
i co najwazniejsze był by kilka razy większy.

Dla ilustracji: zakładając że masz 100MB kodu w dll i musisz szerować to 
między dwa exe (bo taką masz architekturę). W przypadku dynamicznych 
biblitek te 100MB można szerować między dwa procesy. Po statycznym 
linkowaniu nie bo to różne exe. Oczywiście trzeba wziąć poprawkę na 
gówniany x86 ale na szczęscie to badziewie już znika z rynku. Aplikacji 
ktore dostarczają wiele exe w jednej instalacji dzieląc kod jest 
pierdyliard.

Dla ilustracji2: wyobraź sobie że masz aplikację edytora która tylko 
wtedy kiedy trzeba laduje parser gramatyki Perla. Jeśli nie otwierasz 
plików perla to po ch... ma to siedzieć w pamięci? Jeszcze kilka lat 
temu było to problemem z uwagi na 4GB przestrzeni adresowej więc 
ładowanie wszystkiego bylo mało sensowne bo zabierałes przestrzeń na 
projekt użytkownika.

[toc] | [prev] | [next] | [standalone]

#30858

> 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

[toc] | [prev] | [next] | [standalone]

#30859

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

[toc] | [prev] | [next] | [standalone]

#30868

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

[toc] | [prev] | [next] | [standalone]

#30861

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

[toc] | [prev] | [next] | [standalone]

#30862

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

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | pl.comp.programming

csiph-web