Re: Перекомпиляция основных п рограмм
17 октября 2010 г. 11:06 пользователь Н. Артём написал: >> > Ядро у меня самосборное, естественно. Зачем мне штатное с тонной модулей >> > и кучей барахла? >> Хм... Таки вы действительно имеете квалификацию выше, чем те, кто в >> дебиане собирают ядра? > Не смешите. Пичём тут квалификация? Квалификация в чём? Я использую их патчи, > а уж выбрать опции из меню - много ума не надо. Квалификация как раз в выборе опций. Сможете обосновать для _каждой_, какую надо в модули, какую в ядро, какую выкинуть и, самое главное, _почему_? >> И чем докажете, что те модули лишние? > Например тем, что оборудования, для которого они предназначены, у меня нет. > :-\ Ну удалите файлы модулей с диска, если вас это так напрягает. На быстродействие их наличие/отсутствие не влияет. Меня наличие файлов модулей не напрягает. Напряжет их отсутствие, когда понадобится воткнуть новую железку. >> > А, во-вторых... Ядро? Там же специально дали возможность компилировать >> > под конкретную модель ЦП. Блин, в менюшке выбор. :-\ Ведь не от праздного >> > же безделья они это сделали? >> И? Ставь нужное ядро из дистрибутива, результат по скорости работы >> будет такой же. > Положим, повыше. Мне большого труда перекомпилировать его не составит. Я не > настолько ленив. Не выше. Скорость загрузки может быть и побольше, если всё засунуть в ядро. Но не настолько радикально, чтоб этим заниматься. А вот скорость работы точно не поменяется. Проверено как-то на досуге во времена 2.6.8 -- Stanislav
Re: Перекомпиляция основных п рограмм
16 октября 2010 г. 23:54 пользователь Artem Chuprina написал: > Но вообще есть ощущение, что Gentoo - оно в основном таки да, для задротов. > Любителей гордо похвастаться "а у меня сборка вся из себя ускоренная и вон как > летает". Еще ни одного достаточно уверенного подтверждения того, что она таки > да, летает (по сравнению с, допустим, дебиановской), я не видел. Могу добавить, что было сравнение дебиана и генту с оптимизациями. Таки не в пользу генту по тестам. Правда, это было довольно давно, во времена Etch, если не ошибаюсь. -- Stanislav
Re: Перекомпиляция основных п рограмм
16 октября 2010 г. 23:32 пользователь Н. Артём написал: >> 16 октября 2010 г. 21:20 пользователь Н. Артём написал: >> > > Их вызовы при помощи fork. >> > А, въехал. НУ это уже относится к libc и ядру. Насчёт libc - тоже >> > вопрос... >> Ядро вполне ставится штатное с нужной сборкой. > Ядро у меня самосборное, естественно. Зачем мне штатное с тонной модулей и > кучей барахла? Хм... Таки вы действительно имеете квалификацию выше, чем те, кто в дебиане собирают ядра? И чем докажете, что те модули лишние? > Я просто имел ввиду, что скорость fork, вероятно, может зависеть, например от > планировщика, который был выбран. Для самого fork - те же 1-2%. Разве что машина будет _действительно_ загружена. У меня на работе такая одна. И то, загружена она по диску, а не по процессору, ибо БД, а не вычисления. >> А беспокойство по поводу libc рекомендуется лечить установкой libc6-i686 > Посмотрю. Однако, 686 - хорошо, а p4, в данном случае, - лучше. Не так ли? :-) Нет. P4 от P3 в этом месте отличается не настолько сильно. По-крайней мере, оптимизация без всяких MMX и SSE одинаковая. >> Что касается выигрыша - выигрыш в 1-2% от ускорения запуска скриптов >> вполне может быть получен другими средствами. Например, достаточно >> обеспечить наличие всех используемых библиотек и бинарников в кеше, а >> не тягать их по запросу с винта. > Но, вроде бы, такое уже есть..? Да. Достаточно прочитать документацию. >> Кстати, те 1-2%, что могут быть получены на 99% задач, попросту тонут >> в ошибках измерения. > Хм... 1-2% Не больше? Таки вы не первый пытаетесь получить что-то пересборкой. В инете тестов дофига было. >> Рекомендую не извращаться с пересборкой, а посмотреть в дистрибутиве. >> И еще, не следует надеяться на всякие SSE и MMX, они применимы к очень >> узкому классу задач, в которые точно не входят ядро и скрипты. > Ну хорошо, я не про не скрипты, во-первых, говорил, а про их интерпретаторы. 1-2%. Интерпретаторы чаще обращаются к libc, чем к своим функциям. А для libc есть и -i686 > А, во-вторых... Ядро? Там же специально дали возможность компилировать под > конкретную модель ЦП. Блин, в менюшке выбор. :-\ Ведь не от праздного же > безделья они это сделали? И? Ставь нужное ядро из дистрибутива, результат по скорости работы будет такой же. -- Stanislav
Re: Перекомпиляция основных п рограмм
Я конечно понимаю, что отсылка к возрасту, пожалуй, самый гнилой аргумент в любом споре, но мне кажется, что число 14 в e-mail адресе нашего субъекта оказалось там совсем неспроста. -- С уважением, Константин Матюхин
Re: Перекомпиляция основных п рограмм
2010/10/16 Н. Артём : > Открыл справочник. Ну и пылища... :-\ Первой попалась инструкция cpuid. если > говорить _именно о 386-м_ - там её нет. Если говорить не о coreutils, а, > например об mplayer, вами хвалёный autodetect будет работать, если он > скомпилирован под 386-й? Там чем-то заменяется cpuid? Извините, но вы просто сетевой тролль. Вам уже давно написали, что debian компилируется под i486. В этих процессорах инструкция cpuid есть. -- С уважением, Константин Матюхин
Re: Перекомпиляция основных п рограмм
Linux это гибкий мир, выбор дистрибутивов огромный когда задавался вопросом которуй у топикстартера долго думал, потом все же сверил, дома поставил ArchLinux а на работе Debian Дома мазохизм но оптимизированный под конкретное железо, на работе стабильность разницы в скоростях почти не заметны, зато успокоено внутренее эго :) Попробуйте заниматься процессами компиляции, посчитаете потерянное время умножайте на кол-во обновляемых пакетов (ежедневно/месячно) и поймете что разница в секундах/миллисекундах при работе не сравнится с потерянным временем на ожидание при компиляции, выискиванием причин, оптимизацией и изучением кода. p.s. ничего не имею против Gentoo она мне тоже нравится в свое роде, но к сожалению со с годами начинаешь ценить время
Re: Перекомпиляция основных п рограмм
16 октября 2010 г. 21:20 пользователь Н. Артём написал: >> Их вызовы при помощи fork. > А, въехал. НУ это уже относится к libc и ядру. Насчёт libc - тоже вопрос... Ядро вполне ставится штатное с нужной сборкой. А беспокойство по поводу libc рекомендуется лечить установкой libc6-i686 Что касается выигрыша - выигрыш в 1-2% от ускорения запуска скриптов вполне может быть получен другими средствами. Например, достаточно обеспечить наличие всех используемых библиотек и бинарников в кеше, а не тягать их по запросу с винта. Кстати, те 1-2%, что могут быть получены на 99% задач, попросту тонут в ошибках измерения. Рекомендую не извращаться с пересборкой, а посмотреть в дистрибутиве. И еще, не следует надеяться на всякие SSE и MMX, они применимы к очень узкому классу задач, в которые точно не входят ядро и скрипты. -- Stanislav
Re: Перекомпиляция основных п рограмм
2010/10/16 Н. Артём : > Debian скомпилирован под i386, т.е. он не будет использовать команды более > современных процессоров и оптимизации под них. Под i486, если уж на то пошло. -- С уважением, Константин Матюхин
