просто с ръчно компилираното се усеща прираст в производителноста, а на мен от време на време ми трябва да съм на максимум...
Аз пък страдам от липса на въображение и все не мога да усетя тоя прираст на производителност. Нито пък виждам откъде ще ми дойде. Това, че ще орежа модулите с нищо няма да промени положението. А, услугите и без това са ми орязани до крайност.
Идва оттам че го компилираш оптимизирано за процесора ти (дали ще е да се ползват SIMD разширения като SSE2/3/4 или AVX, дали ще генерира по-оптимален код спрямо това което компилаторът знае за латентност на инструкции на конкретния процесор, където може да замести някоя инструкция с друга или комбинация, дето са по-бързи, дали ще има правилни предположения за cacheline и alignment, дали ще достъпва паметта по-оптимално с оглед на процесорните кешове по-ефективно). Пребилднатите ядра в репата на дистрибуциите обикновено са компилирани за generic x86 или x86_64 таргет, така че да вървят на максимално множество от системи (SSE4 инструкция би изгърмяла на по-стар процесор примерно) и тези оптимизации там съответно ги няма.
Друг е въпроса че файдата от всичко това е маргинална, освен обикновено в разни частни/гранични случаи или при високо натоварване. А и работата, която ядрото извършва е предимно I/O-интензивна, а не CPU-интензивна така или иначе.
Същото е и с изключването на разни подсистеми и модули - в частни случаи може да спести доста процесорни тактове, в общият случай няма особено значение. За десктоп система за общо ползване, обикновено няма никакво значение.
P.S за да изпреваря въпроса "дай ми пример", простият банален пример е с conntracking-а в ядрото, който в общи линии ти дава възможността да си правиш NAT и/или stateful firewall там с iptables. Като го изключиш, печелиш одма поне едни 50% по-ниска латентност при обслужването и рутирането на всеки TCP пакет просто защото не ходи да рови в разни таблици, които може да са в процесорния кеш, може да не са, ако не са, хабиш стотици процесорни тактове, докато се достави, а conntrack таблицата може да стане брутално голяма с времето и при подходящно натоварване. Ако просто ползваш машината за да браузваш и да гледаш видео в youtube, няма никакво значение. Ако я ползваш обаче като рутер, при прилично натоварване, машината ще се сгъне и ще откаже да търкаля повече трафик, отделно jitter-а ще е неприлично голям.
Обаче айде това не е добър пример, защото може да се билдне като като модул и при добро желание може да го разкараш. Но все още има прилично много неща, които не стават точно така.
Bottom line: повечето хора които прекомпилират ядра и твърдят че вървят по-бързо, обикновено не могат да дефинират кое точно е по-бързо. Чисто теоретично е по-бързо и в определени случаи това "по-бързо" може да е с порядъци. Userland-а е достатъчно сложен, начините на ползването му - също. Може това дето да е по-бързо да е абсолютно ирелевантно, примерно да речем като отвориш видео в някой плеър оттам до възпроизвеждането да минат 50 вместо 200 милисекунди и аха изглежда като подобрение, обаче на човек изначално му е трудно да идентифицира кое точно му изглежда по-бързо.
Те затова такива спорове са тъпи, първо защото не може да се конкретизира върху конкретен проблем и второ, дори това да е налице, profile-ването на цялата работа е достатъчно досадно занимание, а пък точно оттам евентуално ще дойдат твърдите "числа" дето да докажат нещо.
Това казано, за x86 не съм ползвал прекомпилирани ядра от сигурно едно 10 години, просто защото не виждам нужда. За ARM признавам сме билдвали custom ядра, но на старата работа, не за мои си неща. Компилирането на ядра е ужасно досадна работа, аз сигурно съм прост обаче не ми се получава добре от първия път, обикновено не и от втория и третия, евентуално след един месец се сещам поради някаква причина че не ми се е получило пак и отново, часове потрошено процесорно време и електроенергия, майката природа не се кефи на такъв зъл carbon footprint нали така.
Автор
Тема: Debian 8 печели! (Прочетена 10314 пъти)
Sep 25, 2002, 11:52