Kernel 2.6.28 w mini-code, 20% ułatwień dla programistów

LiTE - 31-12-2008 02:22
Z okazji nudów postanowiłem sprawdzić ile będzie zajmował kernel w wersji 2.6.28 po przekonwertowaniu go do mini-code.
Co rozumiem przez mini-code?

Przykład Hello World w C #include <stdio.h>
int main()
{
/* Proba komenta */
printf ("Hello World!\n"); // wyswietlanie hello
return 0;
} Teraz ten sam Hello World w mini-code: #include <stdio.h>
int main() { printf ("Hello World!\n"); return 0; } Czyli usuwamy wszystkie wcięcia, tabulacje, komentarze - zostaje nam sam kod do kompilowania. Ile można zaoszczędzić przestrzeni dyskowej po takiej operacji? Sprawdziłem to na jądrze Linuksa w wersji 2.6.28

Bez kompresji:
Przed: 343.8 MB | Po: 273.8 MB | Różnica: 70 MB (20,3%)

Kompresja bz2
Przed: 50.2 MB | Po 36.6 MB | Różnica: 13.6 MB (27%)

Czy warto? Sam nie wiem. Traktujcie to bardziej jako ciekawostkę :)

yantar - 31-12-2008 02:31
Jak ktos ma mala partycje /boot i teraz nie chce sie bawic w jej przesuwanie albo starego blaszaka z malym dyskiem to dla niego moze byc to calkiem przydatne :)

grzesiek - 31-12-2008 16:34

Czyli usuwamy wszystkie wcięcia, tabulacje, komentarze - zostaje nam sam kod do kompilowania. Ile można zaoszczędzić przestrzeni dyskowej po takiej operacji? Sprawdziłem to na jądrze Linuksa w wersji 2.6.28 Co :?:

Pierwszy raz coś takiego słyszę. To wbrew wszystkim książkom jakie przeczytałem o C/C++.
Na czy ty oszczędzasz na rozmiarze kodu źródłowego chyba nie na binarce. Chcesz powiedzieć, że jak pousuwam zbędne znaki to kompilator stworzy mniejszy plik wynikowy :->
Nie próbowałem ale i bez tego nie wieżę w to.

matiit - 31-12-2008 16:40
strip -R .note -R .comment BINARKA - Tym można zmniejszyć rozmiar binarki.
Sposób podany przez autora pozwala zaoszczędzić miejsce na źródłach...

sidjestgit - 31-12-2008 16:50
Grzesiek - a mi sie wydaje ze prawda jest to co napisal LiTe.
Nie jestem programista - tylko troche bawilem sie HTML.

Powiedzmy ze napisalismy strone - stronka zawiera tekst piosenki (np 3000 znakow/liter)
Nastepnie wezmy ta sama strone i "wzbogacmy" ja o opisy W tych opisach zamiescimy tekst Bibli.
Przegladarka wysietli nam jak poprzednio tylko tekst piosenki ale strona bedzie sie wczytywala kilka min.

LiTE - 31-12-2008 17:24

Co :?:

Pierwszy raz coś takiego słyszę. To wbrew wszystkim książkom jakie przeczytałem o C/C++.
Na czy ty oszczędzasz na rozmiarze kodu źródłowego chyba nie na binarce. Chcesz powiedzieć, że jak pousuwam zbędne znaki to kompilator stworzy mniejszy plik wynikowy :->
Nie próbowałem ale i bez tego nie wieżę w to. Przecież nigdzie nie napisałem, że zmniejszam wielkość pliku wynikowego. Chodzi mi o sam kod źródłowy - co słusznie zauważył @matiit. Celem tego było zobaczenie ile danych jest 'traconych' na komentarze oraz wcięcia w kodzie źródłowym. Wszystko co przeczytałeś w książkach jest nadal aktualne ;-)

grzesiek - 31-12-2008 17:26
@sidjestgit:Kolego, co ty porównujesz. To co piszesz to prawda w HTML to zmniejsza objętość kodu, może nawet ciupek przyspieszy interpretowanie strony ale to będą setne ;)
W językach kompilowanych takich jak C/C++ kompilator czyta kod, nie zwraca uwagi na znaki nie należące do języka, wcześniej jeszcze precompilator rozwija makra funkcje inline, podstawia wartości zmiennych które można obliczyć przed wykonaniem kodu itp. Potem kompilator tworzy kod wynikowy programu co jest mieszanką optymalizacji skoków itp oraz łączeniem z bibliotekami statycznymi a na końcu to mało ma wspólnego z tym co było napisane w C/C++ (kod jest przedstawiony w assemblerze a czy on jest obiektowy ;) - to abstrakcja).
Więc program (jego wielkość) nie zależy od objętości kodu źródłowego. Poza tym obecne kompilatory dodają tyle do kodu (np. tego co tu był przedstawiony), że on sam będzie po kompilacji to tylko 20% stanowił. Jeszcze ważne jest jaki kompilator i jakie opcje. Np. takie RTTI ile kodu dodaje.

@LiTe stąd to nieporozumienie bo nie napisałeś co właściwie zmniejszasz.

LiTE - 31-12-2008 17:32
W sensie, że śmieszą Cie Twoje wypowiedzi? 8-)
Nie chodzi tutaj o czytanie tego kodu później czy też przyspieszanie kompilacji- skąd takie wnioski. Jak napisałem na końcu, traktować jako ciekawostka :> W liście mailingowej przeczytałem, że same komentarze w kodzie to około 3,5 miliona linii (~10% całości) więc pozostałe 10%, które wyszło w wyniku eksperymentu to wcięcia i znaki nowej linii :)

grzesiek - 31-12-2008 17:37

W liście mailingowej przeczytałem, że same komentarze w kodzie to około 3,5 miliona linii (~10% całości) więc pozostałe 10%, które wyszło w wyniku eksperymentu to wcięcia i znaki nowej linii :) Było trzeba tak od razu ;-) a ja tu się zastanawiam... czy Ci chodziło również o objętość binarki hehehe

A co do tych komentarzy to dobrze świadczy o projekcje.

yantar - 31-12-2008 17:41
Buu myslalem ze to zmniejsza wynik koncowy ;]

tadzik - 01-01-2009 13:14
Patrzę w tytuł, i łapię się za głowę - niby w jaki sposób wywalenie komentarzy, wcięć i nowych linii miałoby ułatwić pracę programiście? Jeśli już to raczej utrudnić, i to na fest.

LiTE - 01-01-2009 15:55
Chodzi o to, że 20% to w kodzie to ułatwienia dla programistów ;-)

tadzik - 01-01-2009 16:24
Aaa, w ten sposób ; )
Ale trzeba przyznać że nie ma jak dobrze skomentowany kod, przy analizie takiegoż

Spectral Lynx - 01-01-2009 16:45
Oczywiście że programiście utrudniłoby to prace ale np. można zaoszczędzić na transwerze (ja na przykład ściągałem źródła żeby skompilować jądro a więc po co mi komentarze i przejrzysty kod skoro nie chcę go czytać ani tym bardziej modyfikować).
Programiści mogliby ściągać wersje z komentarzami a tacy co chcą tylko sobie skompilować wersję bez, oszczędzając czas, pieniądze, miejsce i zmiejszają obciążenie serwera.

LiTE - 01-01-2009 17:24
Tylko musimy brać po uwagę też to, że patche to kernela nie będą działać - oczywiście można tworzyć patche dla mini-code, ale to znowu zabawa ;-)

tadzik - 01-01-2009 17:29
Spectral Lynx dla nie-programistów są własnie binarki - jajka już skompilowane. Tam na bank nie ma komentarzy ; P

Spectral Lynx - 01-01-2009 17:49
Proste:
mini-code jako podstawa a komentarze itp. jako patche (komnenty do patchów także jako patche nakładane puźniej)
lub
stworzyć specjalny program do patchowania
Tak czy siak gra warta świeczki...

Co do binarek ja musiałem kompilować samemu już kilka razy, jeszcze trzeba by było dowiedzieć się ile % użytkowników np. takiego kernel.org ściąga źródła by kompilować a ile żeby czytać, modyfikować etc.

giaur - 01-01-2009 18:07
Bez sensu. Kod przede wszystkim ma byc przejrzysty, a nikt nie bedzie usuwac komentarzy i tworzyc specjalnej wersji do pobrania innej niz tej, nad ktora pracuja programisci, zwlaszcze ze zmiany sa wprowadzane dosc czesto.

Poza tym zrodel kernela po kompilacji nie ma po co trzymac - wystarcza jedynie nagłówki, które zajmują niewiele, wiec to mija sie z celem - byloby zbyt klopotliwe. Przy dzisiejszych łączach pobranie 50 MB to nie tak znów duzo, nawet przy łączu 512 kB/s - wolniejsze to rzadkosc.

Spectral Lynx - 01-01-2009 19:09
Tylko dla wersji stabilnych (wychodzą chyba co kilkanaście dni). Może to robić program. Oszczędności (pieniężne) głównie po stronie serwera. Nie wszyscy mają tak dobrze, niektórzy mają łącze radiowe. Do wszystkich programów (niekoniecznie tylko dla kernel.org). Poza tym są także dystrybucje, które automatycznie kompilują całe oprogramowanie podczas instalacji (więcej pakietów szybsza instalacja nie trzeba czytać tyle z cd/PXE/...).

Dla deweloperów nic się nie zmieni a serwery będą mniej obciążone => niższe koszty (kasę można wykorzystać na rozwój).
Grosz do grosza a będzie kokosza...