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 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#30863

> 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

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

#30864

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 )

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

#30865

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.

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

#30867

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

 

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

#30871

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

Bardzo niestarannie omijasz kontekst tego o czym dyskutowaliśmy.
Chodziło mi o zachowanie proporcji w tych parametrach. Nie ma problemu w napisaniu prostego programu, który dużo zajmuje. Pytanie było o to, czy proporcje są zachowane - a skoro nie są, to czy ten brak proporcji jest uzasadniony.
Z Twoich wypowiedzi wynika, że nie ma takiej motywacji. To by sporo wyjaśniało, ale wątpliwości nie rozwiewa.

> Czy jak bym wziął przecietne seminarium jako punkt odniesienia do badań 
> nad religijnością obywateli

Ale ja nie wziąłem jądra Linuksa do badań nad tym, kto lubi jaki OS.
Jeśli chcesz się trzymać tej seminaryjnej analogii, to pytanie było raczej o indeks BMI wśród studentów. I nie, nie miałbym nic przeciwko, żeby wziąć seminarium jako jakiś znany punkt odniesienia i stwierdzić, że skoro gdzieś indziej ludzie mają zupełnie odmienny indeks BMI, to warto zapytać, dlaczego.

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

I właśnie o to pytam. O te proporcje, również w sensie czasu pracy. Bo skoro coś jest dziesiąt razy większe a nie zajęło dziesiąt razy więcej pracy, to znowu gdzieś zniknęły proporcje. Pytam gdzie, a słyszę wyzwiska.

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

I znowu niestarannie omijasz kontekst. Chodziło o proporcjonalną ilość pracy, czyli powiedzmy milion roboczo-lat. I tego nie dowiesz się z Total Commandera. Właśnie w ten sposób nie odpowiadasz na pytania a wyzwiska tego nie uzupełnią.

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

Pytam, czy te zupełnie odmienne proporcje mają uzasadnienie. I nadal pytam, nigdzie nie uciekłem, możesz śmiało odpowiadać.

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

I mamy piękną odpowiedź. Czyli gigabajtów jest tyle, bo tyle może być i nie ma potrzeby, żeby było mniej. Nie można było tak od razu?

> Ludzie piszacy tak wielki kod mają 
> *ZUPEŁNIE* inne problemy niż te z poziomu gimnazjum.

Ale ciągle nie napisałeś, jakie. Poza biznesowym. A ja bym chętnie o problemach podyskutował, zwłaszcza o technicznych - tylko najchętniej z kimś, kto też chciałby o technice.

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

Nie napisałem takiego wniosku. Wnioskiem jest to, że sama suma rozmiarów dużej liczby plików nie przekonuje mnie, że tyle tych bajtów musi być.

> Zazwyczaj detale jak kod debugowy, symbole itp 
> duperele

Brawo. Przy odrobinie wysiłku potrafisz między wyzwiskami zmieścić parę słów technicznych.
Teza o kodzie debugowym jest dobrą wskazówką.

> A już przeciez chciałeś pisać do MS że mają poważnego 
> buga w implementacji dll...

Po pierwsze nie chciałem pisać a po drugie to nawet nie był kompilator MS a po trzecie nawet nie sugerowałem, że to jest bug. Czyli zrobiłeś trzy błedy w jednym trollowym zdaniu.
Bardzo niestarannie trollujesz, masz słabą technikę. Nawet listę wyzwisk masz jakąś taką ubogą.

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

Czyli jednak zakładasz, że przeszedłbym rekrutację? A jeżeli ja bym ją przeszedł, to może jest tam już więcej takich ludzi? Ale wtedy - dlaczego mnie tam wysyłasz na naukę?

Widzisz? Ciągle beznadziejnie trollujesz i zamiast mnie obrazić, to się tylko kompromitujesz. Mógłbyś tego skilla poćwiczyć gdzie indziej?

> Nigdy jak widać nie pracowaleś nad projektem który ma 
> ~20 lat kodu stukanego przez 4 pokolenia ludzi.

Nie ma potrzeby włączać mojej prywatnej historii do tej dyskusji (chyba że musisz robić osobiste wycieczki z braku właściwych argumentów), ale jeśli możemy nawiązac do tego znanego punktu odniesienia jakim jest wspomniane już jądro Linuksa, to jest to projekt *jeszcze starszy*. I skoro nie zaistniały tam mechanizmy zwiększające jego rozmiar do gigabajtów, to najwyraźniej znowu sięgnąłeś po niewłaściwy argument.

Bo teraz mamy dodatkowy parametr: 15 milionów linii kodu, >20 lat trwania projektu, udział dużej liczby ludzi rozproszonych po całym świecie i... raptem kilkadziesiąt megabajtów kodu wynikowego.
Czyli jeszcze bardziej mam wątpliwości, czy te gigabajty tam muszą być.

> Najlepiej idź i wyjasnij 
> że trzeba wszystko przepisać w C#.

A dlaczego najlepiej?
Pytam, bo po pierwsze ani razu o tym nie wspomniałem (co wskazuje na Twoją ponowną nieumiejętną próbę wciskania mi nie moich słów), a po drugie to też jest ciekawy temat.

> Byłes już u tych imbecyli z Photoshopa

Znowu wyzwiska. Masz bardzo niskie umiejętności komunikacyjne.

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

Nie, niektóre duże aplikacje nie mają gigabajtów. Już o tym pisałem. Stąd pytanie, czy te gigabajty muszą tam być. W dodatku, to pytanie nie musi być obraźliwe - tak jak pytanie o to, czy samochód musi dymić i hałasować, nie musi być obraźliwe dla *wszystkich* kierowców. Niektórym nie dymi i nie hałasuje.

> I serio, masz czelnośc twierdzić że to ja obrażam ludzi?

Tak. Statystykę użytych wyzwisk zrobisz samodzielnie, czy trzeba pomóc?

> Ten kod jest niezbędny.

Tego nie pokazałeś. Odniosłeś się do motywacji biznesowych oraz do kodu debugowego i symboli. To jedyne ślady rzeczowych argumentów w tej dyskusji, ale żadnego z nich nie określiłbym jako "niezbędny".

> Nie mam interesu w 
> przekonywaniu kogokolwiek.

W tym jednym punkcie mnie przekonałeś.

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

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

#30873

On 11/22/2017 3:33 PM, Maciej Sobczak wrote:
> Bardzo niestarannie omijasz kontekst tego o czym dyskutowaliśmy.
> Chodziło mi o zachowanie proporcji w tych parametrach. Nie ma problemu w napisaniu prostego programu, który dużo zajmuje. Pytanie było o to, czy proporcje są zachowane - a skoro nie są, to czy ten brak proporcji jest uzasadniony.

Nie jest proste. Pozwól że zacytuje:

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

> Z Twoich wypowiedzi wynika, że nie ma takiej motywacji. To by sporo wyjaśniało, ale wątpliwości nie rozwiewa.

Nie. To jest tylko odległy parametr w funkcji celu. Jesli dostarczysz 
system embedded o rozmarze 10GB to nie osiągniesz celu bieznesowego. 
Jesli dostarczysz apliakcję EDA o prędkości żółwia to tez nie osiągniesz.

>> Czy jak bym wziął przecietne seminarium jako punkt odniesienia do badań
>> nad religijnością obywateli
> Ale ja nie wziąłem jądra Linuksa do badań nad tym, kto lubi jaki OS.

Wziąłeś bardzo specyficzny projekt do oceny możliwości lub nie napisania 
gigabajtów kodu.

>> Wyjaśnienie: w rzeczywistym świecie sa projekty większe
>> kilkanascie/dziesiąt razy od Linuxa pod względem kodu.
> I właśnie o to pytam. O te proporcje, również w sensie czasu pracy. Bo skoro coś jest dziesiąt razy większe a nie zajęło dziesiąt razy więcej pracy, to znowu gdzieś zniknęły proporcje.

Masz mikroskop do badania jądra linuxa i za jego pomoca zamierzasz 
oceniać budowę mostu. Proporcje Ci nie zniknęły tylko sa poza skalą i 
nie sa proporcjonalne.

> Pytam gdzie, a słyszę wyzwiska.

Słyszysz bo bezustannie emitujesz je w kierunku ludzi którzy takimi 
tematami zajmują się od lat (nie da się, niemożliwe, ktoś zlinkował 
pornola do dllki itp). Jesteś jak ten jehowiec, co przychodzi i gada o 
swoich urojeniach głuchy na fakty. W końcu się na takiego macha ręką, bo 
nieuleczalny.

>>> 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ć"
> I znowu niestarannie omijasz kontekst. Chodziło o proporcjonalną ilość pracy, czyli powiedzmy milion roboczo-lat. I tego nie dowiesz się z Total Commandera. Właśnie w ten sposób nie odpowiadasz na pytania a wyzwiska tego nie uzupełnią.

Ale dowiem się z doświadczeń swoich i okolicznych. Np. przez fakt że 
programy sa napisane pod architekture x86/Sparc wynika ze sa pisane nie 
dlużej niż jakieś 30 lat, no i zatrudnienia w firmach. Ale nie przejmuj 
się, to tylko głupie fakty. Miliony roboczolat brzmia zdecydowanie 
bardziej ekscytująco.

> I mamy piękną odpowiedź. Czyli gigabajtów jest tyle, bo tyle może być i nie ma potrzeby, żeby było mniej. Nie można było tak od razu?

Nie można bo dyskutuje z misiaczkiem co twierdził że na tej planecie nie 
sposób takiego kodu napisać.

>> Ludzie piszacy tak wielki kod mają
>> *ZUPEŁNIE* inne problemy niż te z poziomu gimnazjum.
> Ale ciągle nie napisałeś, jakie.

Wiele z nich jest oczywistych. Zacznij od zastanowienia się:
a) ile czasu trwa linkowanie gigabajtowych execów
b) ile na to potrzeba pamięci
c) jak rozwiązać problem testowania regresyjnego
d) jak uzywać dowolnych narzedzi debugowych

To tak na początek. Wyboraź sobie że mnożysz te czasy i pamięci razy 
ilośc programistów (setki) i liczysz dolary na prąd i papier toaletowy.

To tylko zerkniecie przez dziurkę od klucza do przeciętnej firmy 
pokazujące margines oczywistosci. Świadomie pomijam problemy u klienta i 
setki innych związanych z architekturą.

> Poza biznesowym. A ja bym chętnie o problemach podyskutował, zwłaszcza o technicznych - tylko najchętniej z kimś, kto też chciałby o technice.

No to dyskutuj. To jest cos odmiennego niż pokazywanie faktów palcem i 
mówienie że to niemożliwe.

>> 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.
> Nie napisałem takiego wniosku. Wnioskiem jest to, że sama suma rozmiarów dużej liczby plików nie przekonuje mnie, że tyle tych bajtów musi być.

Trudno. Jehowca tez nie posób przekonać do czegokolwiek.

>> Zazwyczaj detale jak kod debugowy, symbole itp
>> duperele
> Brawo. Przy odrobinie wysiłku potrafisz między wyzwiskami zmieścić parę słów technicznych.
> Teza o kodzie debugowym jest dobrą wskazówką.

Tak i jest ona wyświetlona prawie na środku ekranu Visuala. Nie 
spodziewaj sie że ktokolwiek powaznie będzie dyskutowal z kimś kto nie 
wie jakie efekty daje domyślna kompilacja w Visualu choć wyciąga wnioski 
zmieniające przyszłość świata.

>> A już przeciez chciałeś pisać do MS że mają poważnego
>> buga w implementacji dll...
> Po pierwsze nie chciałem pisać a po drugie to nawet nie był kompilator MS a po trzecie nawet nie sugerowałem, że to jest bug. Czyli zrobiłeś trzy błedy w jednym trollowym zdaniu.

To była ironia. Ciezko w niej robić błędy.

> Bardzo niestarannie trollujesz

Bardzo dziękuje, dokładnie tak własnie jest.

>, masz słabą technikę. Nawet listę wyzwisk masz jakąś taką ubogą.

Ja ich nie używam jako ja. Zazwyczaj krystalizuje tylko wypowiedzi 
innych w formie ironii.

>>>> 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.
> Czyli jednak zakładasz, że przeszedłbym rekrutację?

Obecnie biora każdego kto ma choć kawalek palca do stukania w klawisze. 
No dobra, nie, nie wszystkie. Niektóre nie biorą nawet ludzi po 
mad-fib-bzdziu. Zalezy do firmy. Zazwyczaj duże korporacje robiące durze 
rzeczy mają kilka poziomów dla programisty i znajdzie się coś dla 
poziomu -1 a potem sie pniesz. Mam nadzieje że nie zakładasz że trafisz 
od razu na stanowisko głównego architekta.

> A jeżeli ja bym ją przeszedł, to może jest tam już więcej takich ludzi?

Cała masa, jak mówie zalezy co chcesz robić. Możesz pisać router do fpga 
ale raczej nie stanie się to godzine po rekrutacji. Coś bardziej po 10 
latach.

> Ale wtedy - dlaczego mnie tam wysyłasz na naukę?

Ponieważ tak głupio skonstruowany jest swiat że warto celować wyżej niz 
swoja obecna wiedza.

>> Nigdy jak widać nie pracowaleś nad projektem który ma
>> ~20 lat kodu stukanego przez 4 pokolenia ludzi.
> Nie ma potrzeby włączać mojej prywatnej historii do tej dyskusji (chyba że musisz robić osobiste wycieczki z braku właściwych argumentów), ale jeśli możemy nawiązac do tego znanego punktu odniesienia jakim jest wspomniane już jądro Linuksa, to jest to projekt *jeszcze starszy*. I skoro nie zaistniały tam mechanizmy zwiększające jego rozmiar do gigabajtów, to najwyraźniej znowu sięgnąłeś po niewłaściwy argument.

Jeszcze starszy od jądra linuxa jest kod w zegarku na korytarzu w 
technikum gdzie uczęszczałem, na 8051. Jakie wnioski moglibysmy z tego 
wyciągnąc w dyskusji nad aplikacjami o rozmiarze x GB?

> Bo teraz mamy dodatkowy parametr: 15 milionów linii kodu, >20 lat trwania projektu, udział dużej liczby ludzi rozproszonych po całym świecie i... raptem kilkadziesiąt megabajtów kodu wynikowego.
> Czyli jeszcze bardziej mam wątpliwości, czy te gigabajty tam muszą być.

Jak już mówiłem, możesz zmieniać świat. Idziesz do firmy, zatrudniają 
Cię i od razu walisz do szefa że masz watpliwości. I dostajesz wolna 
reke, odlinkowujesz pornola z ddlki, produkt zarabia miliard dolarów i 
się budzisz.

Znowu nazywasz ludzi pracujących z tym kodem głupimi. No bo niby jak to 
nie potrafią zredukować rozmiaru? Czyli że głupi no bo jak inaczej.

>> Najlepiej idź i wyjasnij
>> że trzeba wszystko przepisać w C#.
> A dlaczego najlepiej?

No to może w Go. Im bardziej ciekawy język wybierzesz tym klepanie w 
ramie bedzie miało bardziej charakter kierunkowy do najbliższych drzwi.

> Pytam, bo po pierwsze ani razu o tym nie wspomniałem (co wskazuje na Twoją ponowną nieumiejętną próbę wciskania mi nie moich słów), a po drugie to też jest ciekawy temat.

Tak bardzo. Przetestuj sam jakie wzbudzi zaciekawienie u kierownika 
projektu. Jakas prosta rewolucyjna myśl. Coś w rodzaju "zlinkujmy 
wszystko statycznie" albo "piszmy na ifona a nie na komputery". Tak zeby 
zakrztusił sie śmiertelnie herbatą z donutem.

>> Byłes już u tych imbecyli z Photoshopa
> Znowu wyzwiska. Masz bardzo niskie umiejętności komunikacyjne.

Tak, on sa wręcz śladowe. Ledwo litery stawiam na ekranie.

Ale umysl bystry i zauważylem że (tu przecieram oczy ze zdumienia) 
zrobiłeś sobie wycieczkę osobistą na ktorą to przed chwilą się sam 
oburzyłeś. No no :) Robisz postępy, już za chwile możesz pisac na advocacy.

Pamiętaj ze udawanie braku hipokryzji jest mocno nieludzkie i krzywdzące.

>>> 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.
> Nie, niektóre duże aplikacje nie mają gigabajtów. Już o tym pisałem. Stąd pytanie, czy te gigabajty muszą tam być.

Po raz drugi strzeliłeś programistów w pysk.

Masz grupę ludzi którzy klepią kod od 20 lat, niektórzy wybitni. 
Przychodzi przecietny misiaczek z zadupia internetu i mówi "ale czy wy 
jesteście pewni że dobrze robicie? Bo ja tu mam taka makietkę dllki...". 
No i co na to masz powiedzieć?

> W dodatku, to pytanie nie musi być obraźliwe - tak jak pytanie o to, czy samochód musi dymić i hałasować, nie musi być obraźliwe dla *wszystkich* kierowców. Niektórym nie dymi i nie hałasuje.

Nie, ty pytasz inżynierów w nasa czy na pewno silniki do rakiet musza 
być takie duże bo sąsiad ma taką kosiarkę i w niej ...

>> I serio, masz czelnośc twierdzić że to ja obrażam ludzi?
> Tak. Statystykę użytych wyzwisk zrobisz samodzielnie, czy trzeba pomóc?

Ja nie wyzywam ludzi. Ja stosuje tą sztuczkę aby pokazać jak Ty (mam 
nadzieje nieświadomie) traktujesz wszystkich na około za idiotów bo 
przeciez można zrobić taki eksperyment z dllką że od razu wiadomo że źle 
robią ...

>> Ten kod jest niezbędny.
> Tego nie pokazałeś.

Jakiego dowodu oczekujesz? Machania rekami? Przysięgi na jakąś ksiązke? 
Certyfikatu z pieczątką? Jak można to udowodnić bez znajomosci 
architektury aplikacji co jest a co nie niezbedne? Myslisz że wiedza o 
tym jak coś działa, jakie ma założenia, algorytmy, budowę, problemy i 
rozwiązania daje się zmieścić w małym trolingu internetowym? Jak juz 
mówiłem: celuj wyżej niz Nabino to zrozumiesz jaki popełniasz bład w 
płytkiej ocenie problemu.

> Odniosłeś się do motywacji biznesowych oraz do kodu debugowego i symboli. To jedyne ślady rzeczowych argumentów w tej dyskusji, ale żadnego z nich nie określiłbym jako "niezbędny".

Bo przeoczyłeś wszystkie ważne.

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

#30875

On 11/22/2017 6:20 PM, Sebastian Biały wrote:
> durze 

Hehehehe. Jeśli się ktoś zadławił to przepraszam.

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

#30878

> Masz mikroskop do badania jądra linuxa i za jego pomoca zamierzasz 
> oceniać budowę mostu. Proporcje Ci nie zniknęły tylko sa poza skalą i 
> nie sa proporcjonalne.

Dlaczego nie są?
Mamy:
- wielomodułowy system
- na kilkanaście milionów linii
- pisany ponad 20 lat
- przez setki ludzi
- w zespole rozproszonym po całym świecie

O jakim systemie teraz napisałem?
...
Wiesz, że nie zgadłeś?

Do tej pory użyłeś każdego z powyższych punktów jako argumentu uzasadniającego, że system ma wiele gigabajtów.
Tymczasem jest system, który spełniając te warunki tych gigabajtów nie ma.

Stąd wątpliwości i szukanie dalszych argumentów.

Odpowiedzi merytoryczne do tej pory:
- nie ma motywacji, żeby było mniej
- kod debugowy i symbole

To sa dobre odpowiedzi (ale potrafię sobie wyobrazić ich więcej).

> Jesteś jak ten jehowiec

O, nowe.

> Ale dowiem się z doświadczeń swoich i okolicznych. Np. przez fakt że 
> programy sa napisane pod architekture x86/Sparc wynika ze sa pisane nie 
> dlużej niż jakieś 30 lat, no i zatrudnienia w firmach. Ale nie przejmuj 
> się, to tylko głupie fakty. Miliony roboczolat brzmia zdecydowanie 
> bardziej ekscytująco.

Tak niestarannie trollujesz, że nawet swoich sąsiednich zdań nie kojarzysz.
Właśnie o to mi chodziło, że nie da się zmiescić tego (proporcjonalnego) miliona roboczo-lat w 30 lat realnie dostępnych na rozwój takiego produktu.
Właśnie to wskazuje na zaburzenie proporcji (czyli: ktoś przy mniejszym wysiłki zrobił większą binarkę).

> dyskutuje z misiaczkiem co twierdził że na tej planecie nie 
> sposób takiego kodu napisać.

Nadal twierdzę, że nie da się upchnąć miliona roboczo-lat w 30, które były dostępne. Stąd obserwacja, że mamy do czynienia z innymi proporcjami w czasach i rozmiarach. A stąd pytanie, dlaczego.

BTW - misiaczek też jest nowy w tej dyskusji. Gorzej, że wypalasz się na niewłaściwym odcinku i brakuje Ci energii na realną dyskusję.

> Wiele z nich jest oczywistych. Zacznij od zastanowienia się:
> a) ile czasu trwa linkowanie gigabajtowych execów
[...]

Moje pierwsze pytanie w tej dyskusji było: czy statycznie zlinkowane byłoby mniejsze. Nie wiemy tego (sam napisałeś, że nie możesz sprawdzić), więc teraz Twoje pytanie o to ile czasu trwa linkowanie gigabajtowych execów jest bezpodmiotowe. Najpierw ustalmy, czy te gigabajty byłyby w statycznie zlinkowanym programie. Tego nadal nie wiemy, bo z braku możliwości przeprowadzenia testu pozostają tylko domysły, ewentualnie wyzwiska.

> To tak na początek. Wyboraź sobie że mnożysz te czasy i pamięci razy 
> ilośc programistów (setki)

Słyszałem o buildach integracyjnych off-line.
Nie ma potrzeby, żeby każdy programista linkował u siebie kompletny system.
Podobnie jest z testami.

> Nie 
> spodziewaj sie że ktokolwiek powaznie będzie dyskutowal z kimś kto nie 
> wie jakie efekty daje domyślna kompilacja w Visualu

Ja nawet przez chwilę nie zakładałem, że w takiej specyficznej branży ktoś używa domyślnych opcji kompilacji. Naprawdę.

Ale jeśli używa się domyślnych, to jest to kolejny trop.

Nadal jednak nie wpada mi to do kategorii "niezbędne".

> > Czyli jednak zakładasz, że przeszedłbym rekrutację?
> 
> Obecnie biora każdego kto ma choć kawalek palca do stukania w klawisze.

Pewnie dlatego kompilują z domyślnymi opcjami...
 
> Możesz pisać router do fpga 
> ale raczej nie stanie się to godzine po rekrutacji. Coś bardziej po 10 
> latach.

Dziwna strategia. Jak my zatrudniamy specjalistę od FPGA, to nie po to, żeby przez 10 lat tego nie robił.
Ale jak już napisałeś - ta branża jest specyficzna. :-)

> Jeszcze starszy od jądra linuxa jest kod w zegarku na korytarzu w 
> technikum gdzie uczęszczałem, na 8051.

Ale nie ma 15 milionów linii kodu i nie był pisany przez >20 lat przez setki ludzi w rozproszonym zespole.

> Jakie wnioski moglibysmy z tego 
> wyciągnąc

Bardzo starannie nie wyciągasz żadnych.

> Znowu nazywasz ludzi pracujących z tym kodem głupimi.

Nic podobnego. Pytam tylko. I do tej pory mamy takie odpowiedzi, po odfiltrowaniu wyzwisk:

- nie ma potrzeby biznesowej, żeby był mniejszy rozmiar,
- kod debugowy,
- stosowanie domyślnych opcje kompilacji

> Masz grupę ludzi którzy klepią kod od 20 lat, niektórzy wybitni.

Masz na myśli jądro Linuksa?
Bo już się pogubiłem w Twoich argumentach i o jakim systemie rozmawiamy.

> Nie, ty pytasz inżynierów w nasa

O NASA jeszcze w tej dyskusji nie pytałem. Nieumiejętnie trollujesz.

> Ja nie wyzywam ludzi. Ja stosuje tą sztuczkę

Gdybyś był politykiem, miałbyś już mema za to stwierdzenie.

> >> Ten kod jest niezbędny.
> > Tego nie pokazałeś.
> 
> Jak można to udowodnić bez znajomosci 
> architektury aplikacji co jest a co nie niezbedne?

I gdybyś od początku wyłożył karty na stół, że nie znasz tej architektury, to bym wiedział, że nie trzeba tak mocno tej dyskusji toczyć.

Pozostaję więc przy tym, co udało nam się do tej pory zebrać:

- brak motywacji biznesowej,
- kod debugowy,
- domyślne opcje kompilacji.

Jeśli chciałbyś dołożyć coś do tej listy (oprócz wyzwisk), to ja bardzo chętnie.

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

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

#30879

W dniu czwartek, 23 listopada 2017 11:55:53 UTC+1 użytkownik Maciej Sobczak napisał:
> > Masz mikroskop do badania jądra linuxa i za jego pomoca zamierzasz 
> > oceniać budowę mostu. Proporcje Ci nie zniknęły tylko sa poza skalą i 
> > nie sa proporcjonalne.
> 
> Dlaczego nie są?
> Mamy:
> - wielomodułowy system
> - na kilkanaście milionów linii
> - pisany ponad 20 lat
> - przez setki ludzi
> - w zespole rozproszonym po całym świecie
> 
> O jakim systemie teraz napisałem?
> ...
> Wiesz, że nie zgadłeś?
> 
> Do tej pory użyłeś każdego z powyższych punktów jako argumentu uzasadniającego, że system ma wiele gigabajtów.
> Tymczasem jest system, który spełniając te warunki tych gigabajtów nie ma.
> 
> Stąd wątpliwości i szukanie dalszych argumentów.
> 
> Odpowiedzi merytoryczne do tej pory:
> - nie ma motywacji, żeby było mniej
> - kod debugowy i symbole
> 
> To sa dobre odpowiedzi (ale potrafię sobie wyobrazić ich więcej).
> 
> > Jesteś jak ten jehowiec
> 
> O, nowe.
> 
> > Ale dowiem się z doświadczeń swoich i okolicznych. Np. przez fakt że 
> > programy sa napisane pod architekture x86/Sparc wynika ze sa pisane nie 
> > dlużej niż jakieś 30 lat, no i zatrudnienia w firmach. Ale nie przejmuj 
> > się, to tylko głupie fakty. Miliony roboczolat brzmia zdecydowanie 
> > bardziej ekscytująco.
> 
> Tak niestarannie trollujesz, że nawet swoich sąsiednich zdań nie kojarzysz.
> Właśnie o to mi chodziło, że nie da się zmiescić tego (proporcjonalnego) miliona roboczo-lat w 30 lat realnie dostępnych na rozwój takiego produktu.
> Właśnie to wskazuje na zaburzenie proporcji (czyli: ktoś przy mniejszym wysiłki zrobił większą binarkę).
> 
> > dyskutuje z misiaczkiem co twierdził że na tej planecie nie 
> > sposób takiego kodu napisać.
> 
> Nadal twierdzę, że nie da się upchnąć miliona roboczo-lat w 30, które były dostępne. Stąd obserwacja, że mamy do czynienia z innymi proporcjami w czasach i rozmiarach. A stąd pytanie, dlaczego.
> 
> BTW - misiaczek też jest nowy w tej dyskusji. Gorzej, że wypalasz się na niewłaściwym odcinku i brakuje Ci energii na realną dyskusję.
> 
> > Wiele z nich jest oczywistych. Zacznij od zastanowienia się:
> > a) ile czasu trwa linkowanie gigabajtowych execów
> [...]
> 
> Moje pierwsze pytanie w tej dyskusji było: czy statycznie zlinkowane byłoby mniejsze. Nie wiemy tego (sam napisałeś, że nie możesz sprawdzić), więc teraz Twoje pytanie o to ile czasu trwa linkowanie gigabajtowych execów jest bezpodmiotowe. Najpierw ustalmy, czy te gigabajty byłyby w statycznie zlinkowanym programie. Tego nadal nie wiemy, bo z braku możliwości przeprowadzenia testu pozostają tylko domysły, ewentualnie wyzwiska.
> 
> > To tak na początek. Wyboraź sobie że mnożysz te czasy i pamięci razy 
> > ilośc programistów (setki)
> 
> Słyszałem o buildach integracyjnych off-line.
> Nie ma potrzeby, żeby każdy programista linkował u siebie kompletny system.
> Podobnie jest z testami.
> 
> > Nie 
> > spodziewaj sie że ktokolwiek powaznie będzie dyskutowal z kimś kto nie 
> > wie jakie efekty daje domyślna kompilacja w Visualu
> 
> Ja nawet przez chwilę nie zakładałem, że w takiej specyficznej branży ktoś używa domyślnych opcji kompilacji. Naprawdę.
> 
> Ale jeśli używa się domyślnych, to jest to kolejny trop.
> 
> Nadal jednak nie wpada mi to do kategorii "niezbędne".
> 
> > > Czyli jednak zakładasz, że przeszedłbym rekrutację?
> > 
> > Obecnie biora każdego kto ma choć kawalek palca do stukania w klawisze.
> 
> Pewnie dlatego kompilują z domyślnymi opcjami...
>  
> > Możesz pisać router do fpga 
> > ale raczej nie stanie się to godzine po rekrutacji. Coś bardziej po 10 
> > latach.
> 
> Dziwna strategia. Jak my zatrudniamy specjalistę od FPGA, to nie po to, żeby przez 10 lat tego nie robił.
> Ale jak już napisałeś - ta branża jest specyficzna. :-)
> 
> > Jeszcze starszy od jądra linuxa jest kod w zegarku na korytarzu w 
> > technikum gdzie uczęszczałem, na 8051.
> 
> Ale nie ma 15 milionów linii kodu i nie był pisany przez >20 lat przez setki ludzi w rozproszonym zespole.
> 
> > Jakie wnioski moglibysmy z tego 
> > wyciągnąc
> 
> Bardzo starannie nie wyciągasz żadnych.
> 
> > Znowu nazywasz ludzi pracujących z tym kodem głupimi.
> 
> Nic podobnego. Pytam tylko. I do tej pory mamy takie odpowiedzi, po odfiltrowaniu wyzwisk:
> 
> - nie ma potrzeby biznesowej, żeby był mniejszy rozmiar,
> - kod debugowlat, niektórzy wybitni.
> 
> Masz na myśli jądro Linuksa?
> Bo już się pogubiłem w Twoich argumentach i o jakim systemie rozmawiamy.
> 
> > Nie, ty pytasz inżynierów w nasa
>y,
> - stosowanie domyślnych opcje kompilacji
> 
> > Masz grupę ludzi którzy klepią kod od 20  
> O NASA jeszcze w tej dyskusji nie pytałem. Nieumiejętnie trollujesz.
> 
> > Ja nie wyzywam ludzi. Ja stosuje tą sztuczkę
> 
> Gdybyś był politykiem, miałbyś już mema za to stwierdzenie.
> 
> > >> Ten kod jest niezbędny.
> > > Tego nie pokazałeś.
> > 
> > Jak można to udowodnić bez znajomosci 
> > architektury aplikacji co jest a co nie niezbedne?
> 
> I gdybyś od początku wyłożył karty na stół, że nie znasz tej architektury, to bym wiedział, że nie trzeba tak mocno tej dyskusji toczyć.
> 
> Pozostaję więc przy tym, co udało nam się do tej pory zebrać:
> 
> - brak motywacji biznesowej,
> - kod debugowy,
> - domyślne opcje kompilacji.
> 
> Jeśli chciałbyś dołożyć coś do tej listy (oprócz wyzwisk), to ja bardzo chętnie.
> 

1) teoretycznie mozliwe sa takie
wielkie procesy na kilka GB ale
ja powiatpiewam w to glownie dlatego ze wydaje mi sie ze takie wielkie programy raczej beda jakimis raczej zestawami procesow a nie pojedynczym procesem
(jak ktos chce blysnac ze zna takie wielkie procesy to prosze o konkretne dane bo inacczej to zachowywanie sie jak prz4edszkolak)

2) jak podalem wyliczenia takie wielkie binarki to nie miliony 
roboczo lat tylko kilka tysiecy 
(przy zalozeniu dosyc przezwoitej 
produktywnosci w firmach moze z tym byc gorzej niz zalozona ale nie wiem dokladnie )

3) kod w postaci dllek i libek statycznych zamuje dokladnie tyle samo 
(w przypadku libek mnozna czasem linkowac wybiórczo ale to nie ma wiekszego znaczenia imo pominawszy 
patologiczne przypadki gdy ktos linkuje dziesiatki dllek ktorych prawie wcale nie uzywa ot by zlinkowac -
w przypadku dllek za to mozna wspoldzielic dllki miedzy procesami
co w zaleznosci od systemu moze spowodowac zmniejszenie zuzycia pamieci)
(osobiscie jestem raczej fanem linkowanie dynamicznego - jesli robi sie je dobrze)

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

#30885

On Thursday, November 23, 2017 at 11:55:53 AM UTC+1, Maciej Sobczak wrote:
> > Masz mikroskop do badania jądra linuxa i za jego pomoca zamierzasz 
> > oceniać budowę mostu. Proporcje Ci nie zniknęły tylko sa poza skalą i 
> > nie sa proporcjonalne.
> 
> Dlaczego nie są?
> Mamy:
> - wielomodułowy system
> - na kilkanaście milionów linii
> - pisany ponad 20 lat
> - przez setki ludzi
> - w zespole rozproszonym po całym świecie

Hmmm czy wie ktoś ile lat i przez ilu (średnio) programistów było
rozwijane QT? Bo tak jak mówiłem, hello world gui w qt (według
dedykowanego narzędzia) wymaga 500MB libów w debug i 50MB libów w
release. Też trochę się dziwię skąd się biorą te gigabajty kodu
wynikowego, z jakiejś super-optymalizacji na wydajność, rozwijanie
pętli, template do każdego duperela? Zarówno qt jaki i linux są
na różne platformy, więc przy konkretnej kompilacji dużo odrzuca
if-def.

Pozdrawiam

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

#30886

On 11/23/2017 11:55 AM, Maciej Sobczak wrote:
>> Masz mikroskop do badania jądra linuxa i za jego pomoca zamierzasz
>> oceniać budowę mostu. Proporcje Ci nie zniknęły tylko sa poza skalą i
>> nie sa proporcjonalne.
> Dlaczego nie są?
> Mamy:
> - wielomodułowy system
> - na kilkanaście milionów linii
> - pisany ponad 20 lat
> - przez setki ludzi
> - w zespole rozproszonym po całym świecie

A tu mamy:
- konkretny cel pisany za konkretne pieniadze opierający się o 
specyfikacje i dokumentacje
- kilkadziesiąt milionów lini kodu zbieranych przez lata przez 
wchlanianie róznych firm i produkcję własną
- pisany przez tak dlugo że mało kto pamięta kiedy zaczeli
- pisany przez niekreslone ilości ludzi, ale raczej idace w grube tysiące
- w zespołach rozproszonych, ale w srodku grupy *zwartych*
- i ktoś za to płaci co jest nie najgorszym motywatorem
- i ktos pilnuje co robią

> O jakim systemie teraz napisałem?

O jakims innym.

> Do tej pory użyłeś każdego z powyższych punktów jako argumentu uzasadniającego, że system ma wiele gigabajtów.
> Tymczasem jest system, który spełniając te warunki tych gigabajtów nie ma.

Dalej nie pojmujesz że porównujesz dwa światy i próbujesz wszykim wmówić 
ze duże aplikacje pisza imbecyle bo na pewno zlinkowali pornola do dllki 
albo zapomnieli wyłączyc debug. To jest obelga w stosunku do dużej 
liczby ludzi majacych pojecie o programowaniu grubo większe.

> Stąd wątpliwości i szukanie dalszych argumentów.

Twoje wątpliwości nikogo nie interesują podobnie jak urojenia jehowcow. 
Przedstaw dowody że jesteś w stanie prawdziwą aplikajce rzędu 1GB 
zredukować tylko przez samo linkowanie.

> Odpowiedzi merytoryczne do tej pory:
> - nie ma motywacji, żeby było mniej
> - kod debugowy i symbole

I Ty twierdzisz że mam kiepskie zdolności komunikacyjne a sam nie 
pojmujesz ze kod debugowy i symbole sam zrobiłeś i wyssales z tego 
idiotyczne wnioski?

W powaznej firmie, nawet niewielkiej, istnieje wiele poziomów 
*zapewniania* że w dll nie ma kodu debugowego i syboli. Niektóre 
automatyczne a inne białkowe. Serio, po raz kolejny dajesz w pysk 
programistom twierdząc że ich kłopoty to zapomniany debug? I mówisz to 
na podstawie własnych urojeń...

> To sa dobre odpowiedzi (ale potrafię sobie wyobrazić ich więcej).

To są złe odpowiedzi. Poza Nabino nie pamiętam ostatnio o wpadce aby 
ktokolwiek dostarczył na produkcje kod debugowy.

> Właśnie o to mi chodziło, że nie da się zmiescić tego (proporcjonalnego) miliona roboczo-lat w 30 lat realnie dostępnych na rozwój takiego produktu.

Oczywiście, fakty jak zwykle perfidnie kłamia. Nie da się i już. Chyba 
że ten milion roboczolat to tylko urojenie, ale przecież to obliczenie 
opiera sie o soline pociągnięcie z palca wiec nie może być błędne.

> Właśnie to wskazuje na zaburzenie proporcji (czyli: ktoś przy mniejszym wysiłki zrobił większą binarkę).

A może zrobił większa binarkę przy większym wysiłku uzyskując prędkośc, 
ficzery i tym podobne zbędne na helloworldowców rzeczy?

> Nadal twierdzę, że nie da się upchnąć miliona roboczo-lat w 30, które były dostępne.

Znowu te głupie fakty. Myślaleś żeby się zapisać do jakiejś 
populistycznej partii? Oni też z zapałem walczą z faktami.

> Stąd obserwacja, że mamy do czynienia z innymi proporcjami w czasach i rozmiarach. A stąd pytanie, dlaczego.

Dostajesz odpowiedzi i ciągle pytasz dlaczego. Jesteś może botem?

> BTW - misiaczek też jest nowy w tej dyskusji. Gorzej, że wypalasz się na niewłaściwym odcinku i brakuje Ci energii na realną dyskusję.

Uważasz że pieprzenie "to nie może być prawda że 2+2=4" jest realnym 
pomysłem na dyskusję?

> Moje pierwsze pytanie w tej dyskusji było: czy statycznie zlinkowane byłoby mniejsze.

Tak. Nie. Nie wiadomo. Raczej niewiele.

> Nie wiemy tego (sam napisałeś, że nie możesz sprawdzić)

Nikt tego nie może sprawdzić. Choćby dlatego że architektura aplikacji 
nie umozliwia statycznego linkowania aby zachowac funkcjonalność a samo 
doświadczenie bywa że jest niemożliwe do uzyskania bez kolosalnych zmian 
za które nikt nie zapłaci bo skutek jest i tak wiadomy.

>, więc teraz Twoje pytanie o to ile czasu trwa linkowanie gigabajtowych execów jest bezpodmiotowe.

Przedmiotowe bo tak się akuratnie składa że w sąsiedniej firmie jakiś 
pustak wpadł na ten pomysł i od 2010 roku niektóre osoby nic nie robią 
tylko tna aplikację na kawałki żeby się ratować. Jesli debuger odzyskuje 
callstack przez 2 minuty a drogie narzedzia do profilingu wieszają się 
za każdym razem to oznacza ze właśnie jesteś w dupie. Niby mało ważny 
argument, ten komfort pisania, a zatrzymal firme w rozwoju na kilka lat.

> Najpierw ustalmy, czy te gigabajty byłyby w statycznie zlinkowanym programie.

Tak, byłyby. To oczywiste - kod w dll jest unikatowy i wykorzystywany. 
Chyba że uwazasz że statyczne linkowanie kompresuje asembler zipem. 
Przyznam ze nie słyszałem o takim ale ja się słabo znam na programowaniu.

> Tego nadal nie wiemy, bo z braku możliwości przeprowadzenia testu pozostają tylko domysły, ewentualnie wyzwiska.

Nie, to co Ty nazywasz domysłami jest najnormalnie w świecie *wiedza*. I 
nie pochodzi ona z pustych funkcji w dllkach tylko z pracy nad dużą 
aplikacją.

> Słyszałem o buildach integracyjnych off-line.
> Nie ma potrzeby, żeby każdy programista linkował u siebie kompletny system.
> Podobnie jest z testami.

Oczywiście. Na ten przykald możesz sobie zlinkować tylko prawą częśc 
execa, lewą olać i puścić na testy regresyjne. Tak, jest w tym jakiś 
pomysł na to żeby napierw spieprzyć a potem ratować dupę workaroundami. 
Zupełnie jak w socjaliźmie, dzielnie walczy z problemami które sam generuje.

> Ja nawet przez chwilę nie zakładałem, że w takiej specyficznej branży ktoś używa domyślnych opcji kompilacji. Naprawdę.

Najbardziej zaś nie zakładałeś robiąc "eksperyment" który miał udowodnic 
że programiści to imbecyle.

> Ale jeśli używa się domyślnych, to jest to kolejny trop.

Tak, oczywiscie używa sie domyślnych a programisci to imbecyle. Idzie Ci 
coraz lepiej.

> Nadal jednak nie wpada mi to do kategorii "niezbędne".

A może zaproponowałbyś jakaś apliakcję do wycinania przypadkowych 
funkcji z dllek? Branża była by wdzięczna, manager wpisuje "wytnij mi 
30% kodu na release" i po chwili ma co chciał. Można by na tym zrobić 
dużą kasę, jak na homeopatii.

>> Możesz pisać router do fpga
>> ale raczej nie stanie się to godzine po rekrutacji. Coś bardziej po 10
>> latach.
> Dziwna strategia. Jak my zatrudniamy specjalistę od FPGA, to nie po to, żeby przez 10 lat tego nie robił.

Specjalista od FPGA może nie mieć pojęcia o programowaniu. To częsty 
przypadek. Ponadto mowa była o misiaczkach którzy wpadają do firmy z 
rewolucja. Sadza się ich w kącie i daje trywialne bugi aż zmiekną i z 
generowania nastrojow rewolucyjnych przejda do czajenia bazy. Czasem to 
trwa z 10 lat.

>> Jeszcze starszy od jądra linuxa jest kod w zegarku na korytarzu w
>> technikum gdzie uczęszczałem, na 8051.
> Ale nie ma 15 milionów linii kodu i nie był pisany przez >20 lat przez setki ludzi w rozproszonym zespole.

Oczywicie że nie, to tylko drugi idiotyczny przykład po Twoim w tej 
dyskusji. Postawienie dwoch absurdów obok siebie pozwala w końcu je 
dostrzec.

>> Znowu nazywasz ludzi pracujących z tym kodem głupimi.
> Nic podobnego. Pytam tylko.

"Panie kierowniku, bo tu jakiś imbecyl zlinkował do dllek, a czemu nie 
statycznie? Bo ja tu mam taką makietkę dllki... Tak tylko pytam."

Wbrew temu co mówią tumaniści istnieja głupie pytania.

> I do tej pory mamy takie odpowiedzi, po odfiltrowaniu wyzwisk:
> - nie ma potrzeby biznesowej, żeby był mniejszy rozmiar,

Jedna z setek.

> - kod debugowy,
> - stosowanie domyślnych opcje kompilacji

To brednie. Nikt, potarzam, nikt nie wypuscił by kodu w debug, symboli, 
barku optymalizacji poza firmami garażowymi.

>> Masz grupę ludzi którzy klepią kod od 20 lat, niektórzy wybitni.
> Masz na myśli jądro Linuksa?

Mam na myśli setki aplikacji.

> Bo już się pogubiłem w Twoich argumentach i o jakim systemie rozmawiamy.

Rozmawiamy o bardzo wielu rzeczach, ale ja mam najwyraźniej kiepskie 
zdolności komunikacyjne.

>> Nie, ty pytasz inżynierów w nasa
> O NASA jeszcze w tej dyskusji nie pytałem. Nieumiejętnie trollujesz.

To taka alegoria, choć przypuszczalnie zaraz za użycie tego słowa 
zdzieli mnie w łeb była polonistka.

>>>> Ten kod jest niezbędny.
>>> Tego nie pokazałeś.
>> Jak można to udowodnić bez znajomosci
>> architektury aplikacji co jest a co nie niezbedne?
> I gdybyś od początku wyłożył karty na stół, że nie znasz tej architektury, to bym wiedział, że nie trzeba tak mocno tej dyskusji toczyć.

Nie, ty nie znasz. Wypowiadasz się że "na pewno można coś zmniejszyć" 
nie mają sladowego pojęcia o architekturze. Ja mam pojęcie ale wymagało 
by kilku lat wyjasniania z kodem (bo kiepski jestem w komunikacji). 
Możesz oczywiście podpisać NDA jesli bardzo chbcesz.

> Pozostaję więc przy tym, co udało nam się do tej pory zebrać:
> - brak motywacji biznesowej,
> - kod debugowy,
> - domyślne opcje kompilacji.

Czyli nic nie pojmujesz.

> Jeśli chciałbyś dołożyć coś do tej listy (oprócz wyzwisk), to ja bardzo chętnie.

Nie widze sensu. Nie probujesz się czegokolwiek dowiedzieć. Ot, 
wyrzuciłeś z siebie idiotyzm że linkowanie statyczne jest zarąbiste i 
teraz nie ma drogi odwrotu, wstyd porzucić, do przodu i huraaa! Prosto w 
opary absurdu, debilnych argumentów, idiotycznych eksperymentów, chorych 
urojeń.

A świat obok toczy się ze swoimi milionami roboczolat mając Twoje 
urojenia głeboko na marginesie.

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

#30870

On Tuesday, November 21, 2017 at 1:35:43 PM UTC+1, Maciej Sobczak wrote:
> 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ć.

Wyjaśniam ponownie, hello world w qt gui w wersji debug wraz z bibliotekami dll
zajmuje ponad pół gigabajta. W wersji release ponad 50mb. I nie odpowiadajcie
że debug nie ma znaczenia, bo zanim wypuści się wersje release to 
chociażby do testów rozprowadza się pewną ilość wersji debug. Hmmmm czy
w przypadku linkowania statycznego w wersji debug linkier za każdym
razem musiałby zapisywać na dysk około 500mb danych, podobną ilość
danych wczytywać i analizować? Nie wiem dlaczego czas kompilacji u
was nie jest problemem, stosujecie małe biblioteki? Gdy moja aplikacjia
używała kiedyś tylko np. mfc to faktycznie liniowałem statycznie i
nie miałem problemów. Ale linkować statycznie z QT... czy ktoś
próbował w ogóle?


Pozdrawiam

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

#30874

> Ale linkować statycznie z QT... czy ktoś
> próbował w ogóle?

A czy ktoś kupił wersję komercyjną?!? W Polsze to chyba raczej odpada. Wiec nie zadawaj głupich pytań! Jak masz problem z rozmiarem bibliotek to sypnij kasą 3,5K€ od stanowiska. A jak Cię nie stać, to się ciesz, że dają za darmo dynamicznie linkowaną wersję za darmo! Dziś postęp w nośnikach danych jest tak wielki, że nie jest to problem!

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

#30883

On Wednesday, November 22, 2017 at 6:45:02 PM UTC+1, szyk...@gmail.com wrote:
> > Ale linkować statycznie z QT... czy ktoś
> > próbował w ogóle?
> 
> A czy ktoś kupił wersję komercyjną?!? W Polsze to chyba raczej odpada. Wiec nie zadawaj głupich pytań! Jak masz problem z rozmiarem bibliotek to sypnij kasą 3,5K€ od stanowiska. A jak Cię nie stać, to się ciesz, że dają za darmo dynamicznie linkowaną wersję za darmo! Dziś postęp w nośnikach danych jest tak wielki, że nie jest to problem!

Ja przestałem się interesować szczegółowo licencjami, gdy zobaczyłem, że nawet
prawnicy się sprzeczają o to, jak poprawnie zinterpretować tak popularne
licencje jak apache, gpl, lgpl, mit, berkeley, itd.

Darmowa wersja QT jest na licencji LGPL. Ktoś kiedyś mi tłumaczył, że to
oznacza, iż programu napisanego z wykorzystaniem kodu LGPL nie trzeba
udostępniać ze źródłami. Jeśli zmodyfikuje się sam kod objęty LGPL to
trzeba udostępnić zmodyfikowany kod - nic więcej. 

Natomiast chyba do woli można kompilować kod objęty LGPL i po skompilowaniu
do woli wykorzystywać, w tym także jako biblioteki statycznie wkompilowane?
Więc skąd pytanie czy ktoś kupił komercyjną? Coś mylę z tą wolnością
kompilowania i statycznego linkowania?

Pozdrawiam

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

#30880

W dniu środa, 22 listopada 2017 08:05:42 UTC+1 użytkownik M.M. napisał:
> On Tuesday, November 21, 2017 at 1:35:43 PM UTC+1, Maciej Sobczak wrote:
> > 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ć.
> 
> Wyjaśniam ponownie, hello world w qt gui w wersji debug wraz z bibliotekami dll
> zajmuje ponad pół gigabajta. W wersji release ponad 50mb. I nie odpowiadajcie


patologia - choc ciezko w to uwierzyc

ja juz sam z trudem wierze i rozumiem co to za kram gdzie skompilowanie hello worlda w c++ pod sfmlem twory 1.5 MB exe
(c++ nie dotykam od lat, pominawszy ze czesc swoich kodow kompiluje 
w trybie c++, co i tak robi chyba jakies kilkudziesieco-kilobajtowe narzuty ale nie az takie)
(zdrowy hello world jak ktos sie zastanawia powinien miec kilka kilobajtow (ze wzgledu na te alignmenty w formacie pe) jak na razie nie widze powodu by mial miec wiecej)

postsawowe pytanie co tam dokladnie
siedzi w tych bloatowanych syfach
i co to jest (trzeba sie wiec nauczyc troche lepiej reverse engeeneringu i znajomosci bebechow
binarek - szkoda ze nikt poza mna tu specjalnie sie tym nie interesuje, a moja wiedza jest nadal czesciowa)


> że debug nie ma znaczenia, bo zanim wypuści się wersje release to 
> chociażby do testów rozprowadza się pewną ilość wersji debug. Hmmmm czy
> w przypadku linkowania statycznego w wersji debug linkier za każdym
> razem musiałby zapisywać na dysk około 500mb danych, podobną ilość
> danych wczytywać i analizować? Nie wiem dlaczego czas kompilacji u
> was nie jest problemem, stosujecie małe biblioteki? Gdy moja aplikacjia
> używała kiedyś tylko np. mfc to faktycznie liniowałem statycznie i
> nie miałem problemów. Ale linkować statycznie z QT... czy ktoś
> próbował w ogóle?
> 
> 
> Pozdrawiam

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

#30887

On Thursday, November 23, 2017 at 1:26:58 PM UTC+1, fir wrote:
> W dniu środa, 22 listopada 2017 08:05:42 UTC+1 użytkownik M.M. napisał:
> > On Tuesday, November 21, 2017 at 1:35:43 PM UTC+1, Maciej Sobczak wrote:
> > > 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ć.
> > 
> > Wyjaśniam ponownie, hello world w qt gui w wersji debug wraz z bibliotekami dll
> > zajmuje ponad pół gigabajta. W wersji release ponad 50mb. I nie odpowiadajcie
> 
> 
> patologia - choc ciezko w to uwierzyc

Tyle plików dołącza dedykowane narzędzie - czy ono minimalizuje 
czy nie wiem. Faktem jest, że po użyciu tego narzędzia jeszcze
kilka dllek dodaję ręcznie, bo bez nich nie działa ;-)



> ja juz sam z trudem wierze i rozumiem co to za kram gdzie skompilowanie hello worlda w c++ pod sfmlem twory 1.5 MB exe

Nie rozumiem.


> (c++ nie dotykam od lat, pominawszy ze czesc swoich kodow kompiluje 
> w trybie c++, co i tak robi chyba jakies kilkudziesieco-kilobajtowe narzuty ale nie az takie)
> (zdrowy hello world jak ktos sie zastanawia powinien miec kilka kilobajtow (ze wzgledu na te alignmenty w formacie pe) jak na razie nie widze powodu by mial miec wiecej)

Ale nie odbiegajmy za bardzo od linkowania statycznego vs dynamicznego.

> 
> postsawowe pytanie co tam dokladnie
> siedzi w tych bloatowanych syfach
> i co to jest (trzeba sie wiec nauczyc troche lepiej reverse engeeneringu i znajomosci bebechow
> binarek - szkoda ze nikt poza mna tu specjalnie sie tym nie interesuje, a moja wiedza jest nadal czesciowa)

Za darmo ja tylko szukam nowych algorytmów do AI, na pewno nie będę analizował
budowy exe czy elf dla rozrywki :)

Pozdrawiam

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

#30882

W dniu 22.11.2017 o 08:05, M.M. pisze:
> Wyjaśniam ponownie, hello world w qt gui w wersji debug wraz z bibliotekami dll
> zajmuje ponad pół gigabajta. 

To kłamstwo! Wszystkie biblioteki Qt w wersji debug zajmują 313,26MB. A do "Hello Word" wszystkich nie potrzebujesz! Potrzeba QtCored.dll 12MB + QtGuid.dll 13MB + QtWidgetsd.dll 11MB. Czyli łącznie 36MB a nie 500!!!

> Hmmmm czy
> w przypadku linkowania statycznego w wersji debug linkier za każdym
> razem musiałby zapisywać na dysk około 500mb danych, podobną ilość
> danych wczytywać i analizować? 

Tu znowu podajesz, że g* wiesz o linkowaniu. Linkowanie statyczne polega na pobraniu jedynie tego co użyłeś do exe.

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

#30888

On Thursday, November 23, 2017 at 6:10:10 PM UTC+1, szyk...@gmail.com wrote:
> W dniu 22.11.2017 o 08:05, M.M. pisze:
> > Wyjaśniam ponownie, hello world w qt gui w wersji debug wraz z bibliotekami dll
> > zajmuje ponad pół gigabajta. 
> 
> To kłamstwo! Wszystkie biblioteki Qt w wersji debug zajmują 313,26MB. A do "Hello Word" wszystkich nie potrzebujesz! Potrzeba QtCored.dll 12MB + QtGuid.dll 13MB + QtWidgetsd.dll 11MB. Czyli łącznie 36MB a nie 500!!!

Dedykowanie narzędzie, program o nazwie windeploy.exe, u mnie dodawał 
ponad 500MB plików, głównie dlli. Gdy robiłem Twoją metodą, to działało...
cztery lata temu gdy oprogramowanie działało zazwyczaj na jednym 
komputerze z jednym osem. Gdy miało działać na wielu wersjach windowsa z
różnymi update, to wywalało się. Dopiero po użyciu windeploy nie mam
niespodzianek.

> 
> > Hmmmm czy
> > w przypadku linkowania statycznego w wersji debug linkier za każdym
> > razem musiałby zapisywać na dysk około 500mb danych, podobną ilość
> > danych wczytywać i analizować? 
> 
> Tu znowu podajesz, że g* wiesz o linkowaniu. Linkowanie statyczne 
> polega na pobraniu jedynie tego co użyłeś do exe.
Ty gówno wiesz, bo kompilator musi wstawić zarówno to co użyłeś, jak i to
co do czego nie potrafi obliczyć czy zostanie użyte. A takie obliczenie
nie jest trywialne. Kiedyś było normą, że wstawia wszystko z całego pliku 
cpp, jeśli z tego pliku był użyty dowolny element. 

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

#30897

Użytkownik <szykcech@gmail.com> napisał:
>> Hmmmm czy
>> w przypadku linkowania statycznego w wersji debug linkier za każdym
>> razem musiałby zapisywać na dysk około 500mb danych, podobną ilość
>> danych wczytywać i analizować?

> Tu znowu podajesz, że g* wiesz o linkowaniu. Linkowanie statyczne polega na pobraniu
> jedynie tego co użyłeś do exe.

Wszystko "zalezy". Widzalem statyczne linkowane exe-ki, ktore  mialy w sobie np.
z pol biblioteki, mimo, ze w kodzie uzyta byla jedna funkcja (wolna od zaleznosci).

AK

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

#30899

On Monday, November 27, 2017 at 9:57:57 AM UTC+1, AK wrote:
> Użytkownik <szykcech@gmail.com> napisał:
> >> Hmmmm czy
> >> w przypadku linkowania statycznego w wersji debug linkier za każdym
> >> razem musiałby zapisywać na dysk około 500mb danych, podobną ilość
> >> danych wczytywać i analizować?
> 
> > Tu znowu podajesz, że g* wiesz o linkowaniu. Linkowanie statyczne polega na pobraniu
> > jedynie tego co użyłeś do exe.
> 
> Wszystko "zalezy". Widzalem statyczne linkowane exe-ki, ktore  mialy w sobie np.
> z pol biblioteki, mimo, ze w kodzie uzyta byla jedna funkcja (wolna od zaleznosci).
> 
> AK

Jaka to była biblioteka i kompilator?

Pozdrawiam

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

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

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

csiph-web