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