Ядро

[coirius]

плюс ядро помітно менше займає і бутиться швидше, і не розумію нащо мені в ядрі підтримка фіч процесора від intel якщо в мене amd, або підтримка блутус, чи навіть dial-up модема, файлових систем, які мною не використовуються. Я можу довго продовжувати список. Не треба воно просто напросто.

Це усі відмінності між ними?

[roman-pikalyuk]

Ви читали повідомлення #13 в цій темі?

[sigito]

плюс ядро помітно менше займає і бутиться швидше, і не розумію нащо мені в ядрі підтримка фіч процесора від intel якщо в мене amd, або підтримка блутус, чи навіть dial-up модема, файлових систем, які мною не використовуються. Я можу довго продовжувати список. Не треба воно просто напросто.

Це усі відмінності між ними?

в силу того як я розумію: так.
плюс ще ядро, скомпілене на своїй машині, працює швидше.

ну звичайно можна компілить ядро із тими ж конфігураціями, що й ядро із репозиторія, але тоді я взагалі суті компіляції ядра вручну не бачу... :-?

[DalekiyObriy]

плюс ще ядро, скомпілене на своїй машині, працює швидше.

серйозно? це хто таке сказав, невже сеньйор Торвальдс?

[Praporshic]

плюс ще ядро, скомпілене на своїй машині, працює швидше.

Далеко не завжди.

ну звичайно можна компілить ядро із тими ж конфігураціями, що й ядро із репозиторія, але тоді я взагалі суті компіляції ядра вручну не бачу... :-?

Як приклад: http://linux.org.ua/cgi-bin/yabb/YaBB.pl?num=1193373582

[Pablo]

ну звичайно можна компілить ядро із тими ж конфігураціями, що й ядро із репозиторія, але тоді я взагалі суті компіляції ядра вручну не бачу... :-?

Компілити ядро з тим же кофігом, з яким встановлена система це те ж, що і заняти дві години процесорного часу  командою cat /dev/zero > /dev/null. Я завжди перезбираю ядра тільки з репозиторію дистрибутивів, пропатчені до KDE2 під FreeBSD під систему, з якою будуть працювати, редагуючи при цьому конфіг в залежності від потреб. ІМХО морочитись з збиранням ванільного ядра для робочих машин/серверів сенсу не бачу.

[noddeat]

ядро, заточене під моє конкретне залізо, звісно, буде трохи швидше працювати, але, боюся, цю швидкість виміряти можна лише фалометром, а такого приладу в мене нема.

і що ви будете робити, якщо купите нову веб-камеру чи інший пристрій? перекомпілювати ядро знову? без сенсу: нічого страшного, що в ньому є драйвери пристроїв, яких зараз в мене нема.

це все актуально для хіба що нетбуків, КПК та мобілок.

перекомпілював ядро лише раз, і то мені це не допомогло.

[roman-pikalyuk]

Ядро, зібране мною вручну завантажується на моєму комп'ютері 2.9 секунд, а стандартне в Debian 8.0 секунд.
Це разом з модулями.
І Оперативної пам'яті займає на 2 Мб менше сам Linux в процесі роботи.
Переваги невеликі, але їх можна точно виміряти.

[sigito]

плюс ще ядро, скомпілене на своїй машині, працює швидше.

серйозно? це хто таке сказав, невже сеньйор Торвальдс?

і до чого даний сарказм? при компіляції відбувається оптимізація для власного процесора.
як приклад є доступні версії firefox сккомпілені під різними процесорами і відповідно рекомендовані для користування під подімними моделями, хоча б з одного сімейтва. Нащо це робити? по вашому бо немає чим зайнятись?

[sigito]

ядро, заточене під моє конкретне залізо, звісно, буде трохи швидше працювати, але, боюся, цю швидкість виміряти можна лише фалометром, а такого приладу в мене нема.

і що ви будете робити, якщо купите нову веб-камеру чи інший пристрій? перекомпілювати ядро знову? без сенсу: нічого страшного, що в ньому є драйвери пристроїв, яких зараз в мене нема.

це все актуально для хіба що нетбуків, КПК та мобілок.

перекомпілював ядро лише раз, і то мені це не допомогло.

дозібрати в ядро модуль-два для підтримки якого пристрою займає кілька хвилин, це не є проблемою.

[roman-pikalyuk]

і до чого даний сарказм? при компіляції відбувається оптимізація для власного процесора.
як приклад є доступні версії firefox сккомпілені під різними процесорами і відповідно рекомендовані для користування під подімними моделями, хоча б з одного сімейтва. Нащо це робити? по вашому бо немає чим зайнятись?

Firefox і ядро Linux - це трохи різні речі.

дозібрати в ядро модуль-два для підтримки якого пристрою займає кілька хвилин, це не є проблемою.

Згіден.

[sigito]

і до чого даний сарказм? при компіляції відбувається оптимізація для власного процесора.
як приклад є доступні версії firefox сккомпілені під різними процесорами і відповідно рекомендовані для користування під подімними моделями, хоча б з одного сімейтва. Нащо це робити? по вашому бо немає чим зайнятись?

Firefox і ядро Linux - це трохи різні речі.

я навів взагалі приклад щодо компіляхії під різними процесорами.

[DalekiyObriy]

плюс ще ядро, скомпілене на своїй машині, працює швидше.

серйозно? це хто таке сказав, невже сеньйор Торвальдс?

і до чого даний сарказм? при компіляції відбувається оптимізація для власного процесора.

1) просто при перекомпіляції на своїй машині нічого специфічного не відбувається, хіба що ви виставите відповідний прапорець, інакше де його не компілюй різниці (майже) не буде (підказка: автоматична перекомпіляція сирців може дати «заточку» під поточну машину, якщо встановлено прапорець -march=native/-mcpu=native, в ядрі ж лінукса «native» не використовується, натомість ці прапорці встановлено відповідно до налаштувань процесора в .config, але навіть якщо б native вживався значення процесора в .config впливає на купу інший речей, які не контролюються gcc і тому це вживати native буде дуже обмежена допомога)
2) але навіть, якщо міняти прапорці, 99% цих прапорців впливають на швидкодію ядра десь на 2-3%, окрім дуууже специфічних випадків
3) найбільше на що можна виплинути конфігурацією ядра (зауважте: не просто перекомпіляцією!!!) — це його розмір через вимикання деяких частин, що також може вплинути на швидкість завантаження (оскільки можна пропустити ініціалізацію деяких периферійних пристроїв, на що йде багато часу), на швидкодію роботи ж після завантаження це все буде мати настільки мінімальне значення, що не варте часу компілювання

власне через 2) та 3) перекомпіляція ядра варта лише в окремих випадках, напр. вбудованих системах (де час завантаження критичний), в мене були випадки коли для автомобільного програвача на лінуксі мені виходило збити завантаження з 10сек до 3, на це йшло тиждень-другий длюпання в опціях ядра і випробувань, але там дуууже обмежений набір заліза і мінятися воно ніколи не буде, також дууже слабенький проц, окрім того час завантаження є критичним

щоб пришвидшити роботу користувацького простору після завантаження ядра треба буде перекомпілювати glibc та головні користувацькі програми, але якщо навіть припустити такий шанс, що ви це зробите краще ніж розробники дистрибутиву, пришвидшення буде в межах 5% і це лише робота з ЦП (може пам’яттю), а якщо врахувати, що багато часу користувацькі програми чекають на В/В то й взагалі змін не буде видно

отже якщо у Вас декстоп, не дуже древній, і час завантаження є критичним, я б порадив перемикнути увагу на suspend (hibernate)/resume — ця технологія дозволяє вмикати комп’ютер набагато швидше ніж будь-які перекомпіляції ядра

P.S. щодо firefox — спробуйте дві версії його скомпільовані під різні процесори (я сподіваюсь ви не говорите про i586 проти x86-64 бо це різні архітектури) і поганяйте його бенчмарками на тій самій машині, мені цікаво чи побачите ви там однозначну різницю більше ніж в декілька процентів
P.P.S. власне якщо б різниця при перекомпіляції була суттєвою дистрибутиви б пропонували програми заточені під різні процесори, але чомусь всі дають в основному лише під i586 з компілюванням під загальний проц; єдиний більш-менш поширений випадок — це дві версії glibc (i586 та i686) в деяких дистрах

P.P.P.S. до чого ця довга розповідь, а до того, що перед тим, як витрачати час на (пере)компілювання, треба зробити дві речі:
1) визначитися з цілями — що є критичним для більшої насолоди роботи з комп’ютером: швидше завантаження ядра, швидший FF (бо працюєте багато з javascript), швидше завантаження графічної системи тощо...
2) почитати (той же гугль в поміч) що люди кажуть про пришвидшення: які є технології пришвидшення (багато способів пришвидшення роботи системи насправді не мають нічого спільного з перекомпілюванням), якщо вже зупинились на компіляції, визначитися які компоненти треба перекомпілювати, почитати які опції вплинуть на що і як сильно
3) подивитися бенчмарки (напр., той же phoronix для загальної швидкодії) що їх робили інші люди
4) поставити собі бенчмарки, проїхатися ними до оптимізації
5) зробити оптимізацію
6) проїхатися бенчмарками після оптимізації
7) порівняти цихри — визначитится чи варто заради отриманих % витрачати дорогоцінний час свого життя, чи краще піти пограти в футбол чи почитати цікаву книжку

[roman-pikalyuk]

власне якщо б різниця при перекомпіляції була суттєвою дистрибутиви б пропонували програми заточені під різні процесори

Вони економлять місце на своїх серверах.

[DalekiyObriy]

власне якщо б різниця при перекомпіляції була суттєвою дистрибутиви б пропонували програми заточені під різні процесори

Вони економлять місце на своїх серверах.

1) місце зараз страшенно дешеве, здублювати цілий дистр — це 10, ну 20Гб, фактично копійки, навіть якщо брати до уваги сервер розробки зі збиранням сирців, ну скажімо 100-200Гб — це фігня
2) якщо б вони щось і економили — це людські ресурси/час, бо їх завжди не вистачає, а (в розвинених країнах) їх праця коштує на декілька порядків вище ніж місце на диску
3) але навіть комерційні дистри на штиб RHEL або SLES не роблять такого, і враховуючи те, що за їх підтримку вони беруть гроші, навіть витрати на додатковий сервер/сховище/технаря окупилися, якщо б це дійсно давало перевагу, напр. у RHEL був оптимізований дистр під ЦП замовника, що був би швидший хоча б на 20% ніж дистр конкурента без заточки під ЦП - ринок це страшна штука, і авторегулювання за рахунок адаптації для виживання там працює повним ходом