subject:"Перекомпиляция ос новных программ"

Re: Перекомпиляция ос новных программ

2010-10-18 Пенетрантность Фролов Александр

On 18.10.2010 08:23, Н. Артём wrote:

On 17.10.2010 09:00, Н. Артём wrote:

On Sat, Oct 16, 2010 at 09:27:26PM +0400, Н. Артём wrote:

_Я хочу перекомпилировать не ради перекомпиляции, а ради увеличения
скорости._

Ускорение на 0.5-1% загрузочных скриптов позволит считать задачу
выполненной?

Каждого или всех вместе? Не думаю, что это заметное ускорение... Нет. :-(

Сочувствую. Видите ли, там действительно основная нагрузка -- форки.
Плюс старт бинарников: куча open() и mmap() -- код, исполняемый в ядре.
Плюс немного ELF loader. Плюс интерпретация скрипта башем, где SSE*
совершенно не требуются. Совершенно непонятно, где и что здесь можно
ускорить оптимизацией... Что касается самого ядра, в дебиане его можно
взять уже собранное с оптимизацией под нужную архитектуру.
Так что я ставлю на то, что перекомпиляция даст не более 1% ускорения.

Нечего мне сочувствовать. Причём _здесь_ SSE? Ну, в общем, понятно, что
смысла нет... Но и тестов - нет.

Прочитал всю тему.
Выжимка:

не знал про
не знаю
знаю, что можно, не хочу мерить
не проверял
не замерял

и т.д. рассуждения на тему без знания предмета и без желания понять.

Без знания предмета без желания понять.

Про смысл говорили и не раз, но вопрос не пропадает.

Ну, много про что уже говорят не раз... Но вопрос не пропадает. Опять же: Gentoo. Все
говорят про гибкость, настройку под себя.
Т.е. перекомпиляция, USE и прочее - только ради этого? И никто не опроверг то, что ту же
самую гибкость возможно получить и без перекомпиляции. Особенно, с учётом того, что
времени она занимает массу (плюс обновления софта...). Конечно, в некоторых случаях...
Но, блин, в этих случаях возможность скомпилировать нужное ПО есть и в пакетном
дистрибьютиве. Не легче ли собрать свой пакет на основе имеющегося, чем менять
дистрибьютив и пересобирать мир? :-\ Так почему же Gentoo существует и даже вполне
популярен? Для задротов?
Вы же хотите сказать, что я идиот, закрыть этот вопрос и утвердиться в своём
мнении. Дело ваше. Вероятно, что идея бредовая. Но вот без тестов - это не
вполне убедительно.

имо, вопрос нужно
было сформулировать в виде хочу пересобрать свой дистр / отдельные
проги, не уверен надо ли, накидайте тестов по прогам x, y, z...

Частично, наверное, нужно было и так. Поскольку, помимо рассуждений, хочется
увидеть цифры и как оно есть на самом деле, чтобы убедиться.

С конца: ну так сделай уже эти тесты и убедись.
Моё мение, как человека знакомого с генту всего пару часов: преимущества
генту в работе с исходиками: юз и настройки для конкретного приложения.
Когда эти возможности вам нужны для пары приложений, генту, возможно, и
выглядит неоправданным решением, но когда количество таких приложений
растёт, генту это то, что надо.
Куча времени? Не надо пересобирать мир каждый день. Вам нужен бинарный
дистр с прозрачной сборкой ПО из исходников? Ваш выбор арч.
Да, в деюе есть возможность пересборки из исходников. Допустим, вы нашли
нужные вам тесты, увидели цифры, они вас удовлетворили и вы решили
пересобирать, ну допустим 15 пакетов. А вот теперь мне интересно (нет,
правда, интересно), как вы собираетесь это делать постоянно.

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4cbc1120.4060...@yandex.ru

Re: Перекомпиляция ос новных программ

2010-10-18 Пенетрантность Фролов Александр

On 18.10.2010 18:47, Н. Артём wrote:

On 18.10.2010 08:23, Н. Артём wrote:

On 17.10.2010 09:00, Н. Артём wrote:

On Sat, Oct 16, 2010 at 09:27:26PM +0400, Н. Артём wrote:

_Я хочу перекомпилировать не ради перекомпиляции, а ради увеличения
скорости._

Ускорение на 0.5-1% загрузочных скриптов позволит считать задачу
выполненной?

Каждого или всех вместе? Не думаю, что это заметное ускорение... Нет. :-(

Нечего мне сочувствовать. Причём _здесь_ SSE? Ну, в общем, понятно, что
смысла нет... Но и тестов - нет.

Прочитал всю тему.
Выжимка:

не знал про
не знаю
знаю, что можно, не хочу мерить
не проверял
не замерял

и т.д. рассуждения на тему без знания предмета и без желания понять.

Без знания предмета без желания понять.

Про смысл говорили и не раз, но вопрос не пропадает.

Ну, много про что уже говорят не раз... Но вопрос не пропадает. Опять же: Gentoo. Все
говорят про гибкость, настройку под себя.
Т.е. перекомпиляция, USE и прочее - только ради этого? И никто не опроверг то, что ту
же самую гибкость возможно получить и без перекомпиляции. Особенно, с учётом того, что
времени она занимает массу (плюс обновления софта...). Конечно, в некоторых случаях...
Но, блин, в этих случаях возможность скомпилировать нужное ПО есть и в пакетном
дистрибьютиве. Не легче ли собрать свой пакет на основе имеющегося, чем менять
дистрибьютив и пересобирать мир? :-\ Так почему же Gentoo существует и даже вполне
популярен? Для задротов?
Вы же хотите сказать, что я идиот, закрыть этот вопрос и утвердиться в своём
мнении. Дело ваше. Вероятно, что идея бредовая. Но вот без тестов - это не
вполне убедительно.

С конца: ну так сделай уже эти тесты и убедись.

Это не муторно. Это очень муторно. Во-первых.
Во-вторых: нету у меня дебиана с субботнего вечера. :-( Радиатор северного
моста отлетел. Говорят, я переглер... Точнее, Debian остался, но вот загрузить
его не на чем. :-|

Моё мение, как человека знакомого с генту всего пару часов: преимущества
генту в работе с исходиками: юз и настройки для конкретного приложения.
Когда эти возможности вам нужны для пары приложений, генту, возможно, и
выглядит неоправданным решением, но когда количество таких приложений
растёт, генту это то, что надо.

Т.е., опять оправданность его существования сводится не к оптимизации, а к
компиляции в нужной конфигурации?

Вам нужен бинарный дистр с прозрачной сборкой ПО из исходников? Ваш выбор арч.

Нет уж, спасибо. Если вы ещё помните, вопрос был в том увеличит ли
перекомпиляция под нужную архитектуру скорость работы Debian.
Только Arch'а мне не хватало.

Да, в деюе есть возможность пересборки из исходников. Допустим, вы нашли
нужные вам тесты, увидели цифры, они вас удовлетворили и вы решили
пересобирать, ну допустим 15 пакетов. А вот теперь мне интересно (нет,
правда, интересно), как вы собираетесь это делать постоянно.

Примерно так:
Куча времени? Не надо пересобирать мир каждый день.
Аналогично: вы считаете, что все 15 будут каждый день все разом обновляться?

Да, не в оптимизациях плюшки генту. Имо, они никогда не были и не будут
сколь-нибудь серьёзным аргументом.

Это не муторно, это долго, на piv.

Нет, не думаю, однако это не умаляет моего интереса (а главное - проблем
того, кто собирается заниматься этим) к данной проблеме - как комфортно
и с минимальными усилиями добиться поставленной цели.

Re: Перекомпиляция ос новных программ

2010-10-17 Пенетрантность Mikhail A Antonov

17.10.2010 09:06, Н. Артём пишет:
 И чем докажете, что те модули лишние?
 Например тем, что оборудования, для которого они предназначены, у меня нет. 
 :-\
А вот когда тебе принесут на пару часов устройство, которое вроде как должно 
работать из коробки. Вот тогда начнётся цирк.
Будь то вебкамера или usb-звуковуха. Это так, на вскидку.
Время, которое затратишь на конфигурирование, сборку, пересборку ядра будет 
больше чем то, которое ты выиграешь.
Я считаю что пересборка ядра полезна только в случае добавления какого-нибудь 
не включённого патча.
Что-нибудь из PoM например.

-- 
Best regards,
 Mikhail.
-
xmpp: ant...@stopicq.ru
www: http://www.antmix.pp.ru/




signature.asc
Description: OpenPGP digital signature

Re: Перекомпиляция ос новных программ

2010-10-17 Пенетрантность Artem Chuprina

Делать измерения уж не такая великая задача, так что тешить этим
ЧСВ - просто глупо, т.к. как измерять знает даже google и есть
множество статеек и руководств.
:-)
_Я хочу перекомпилировать не ради перекомпиляции, а ради увеличения
скорости._
Ускорение на 0.5-1% загрузочных скриптов позволит считать задачу
выполненной?
Каждого или всех вместе?
Ты действительно не понимаешь, что для этой величины это одно и то же?
Ты действительно не понимаешь, что, если смайлик не поставлен, это не всегда
не граничит с шуткой?

Что не всегда - понимаю. Но из анализа прочих твоих утверждений у меня не
возникает уверенности, что данный случай - именно пограничный...

Хотя, с другой стороны, 1% или 10% - разница таки есть. :-\

Есть. Но к данному случаю она отношения не имеет.

Re: Перекомпиляция ос новных программ

2010-10-17 Пенетрантность Фролов Александр

On 17.10.2010 18:21, Н. Артём wrote:

17.10.2010 09:06, Н. Артём пишет:

И чем докажете, что те модули лишние?

Например тем, что оборудования, для которого они предназначены, у меня нет.
:-\

А вот когда тебе принесут на пару часов устройство, которое вроде как должно работать
из коробки. Вот тогда начнётся цирк.

Вы не поверите. Не принесут. А всё, что более ли менее вероятно у меня может
появиться, я делаю модулем.

Будь то вебкамера или usb-звуковуха. Это так, на вскидку.
Время, которое затратишь на конфигурирование, сборку, пересборку ядра будет
больше чем то, которое ты выиграешь.
Я считаю что пересборка ядра полезна только в случае добавления какого-нибудь
не включённого патча.

Не только. Поднастройка для своих задач, к примеру выбор планировщика, нужной частоты
таймера и пр. Или включение драйверов, которые не включили майнтанеры в свои ядра (те же
nouveau). Или установка ядра, которое ещё не включено в дистрибьютив. Да мало ли? В
дистрибьютивах делается среднее ядро/ядра, которое должно работать на всём и
со всем. Реально, раз имеется возможность его перекомпилировать под себя, почему бы ей не
воспользоваться?

Что-нибудь из PoM например.

Я даже не знаю что это такое. Ещё раз: не принесут. Например, точно мне не
принесут тестовую плату Texas Instruments (или что там у них). :-\

Ситуация, которую вы описываете, практически нереальна в моём случае.

Я до конца не уверен, но всё же
$ find /lib/modules/2.6.32-5-686/kernel/ | egrep '\.ko|\.so' | wc -l
2659
$ lsmod | wc -l
91
(PIV, дефолт, никакого специфичного оборудования)

Re: Перекомпиляция ос новных программ

2010-10-17 Пенетрантность Фролов Александр

On 17.10.2010 09:00, Н. Артём wrote:

On Sat, Oct 16, 2010 at 09:27:26PM +0400, Н. Артём wrote:

_Я хочу перекомпилировать не ради перекомпиляции, а ради увеличения
скорости._

Ускорение на 0.5-1% загрузочных скриптов позволит считать задачу выполненной?

Каждого или всех вместе? Не думаю, что это заметное ускорение... Нет. :-(

Нечего мне сочувствовать. Причём _здесь_ SSE? Ну, в общем, понятно, что смысла
нет... Но и тестов - нет.

Прочитал всю тему.
Выжимка:
не знал про
не знаю
знаю, что можно, не хочу мерить
не проверял
не замерял
и т.д. рассуждения на тему без знания предмета и без желания понять.
Про смысл говорили и не раз, но вопрос не пропадает. имо, вопрос нужно
было сформулировать в виде хочу пересобрать свой дистр / отдельные
проги, не уверен надо ли, накидайте тестов по прогам x, y, z...

Re: Перекомпиляция ос новных программ

2010-10-17 Пенетрантность Andrey Lyubimets

17.10.2010 12:28, Н. Артём пишет:

On 16.10.2010 13:14, Н. Артём wrote:

Debian скомпилирован под i386, т.е. он не будет использовать команды более
современных процессоров и оптимизации под них.
Отсюда вопросы. Кто имел опыт, проясните пожалуйста.

Те программы для которых это важно, уже есть в разных версиях для разных
процессоров.
Для остальных - важнее стабильность работы.
Мой опыт:
1. Скомпилировать свое ядро бывает очень полезно - рано или поздно
появится железка или будет нужна опция для которой нужно custom ядро, и
если оно уже есть, то добавить небольшое изменение в конфиг и
перекомпилировать будет несложно.

Согласен. Но кто-то тут предлагал использовать исключительно пакеты. :-\

здесь нет противоречия - всегда используй исключительно пакеты! ( на дебиане)
сам скомпилировал - сам собрал в пакет

--
С уважением, Любимец Андрей Алексеевич

Re: Перекомпиляция ос новных программ

2010-10-16 Пенетрантность alexey.kurinnij

Н. Артём wrote:

Debian скомпилирован под i386, т.е. он не будет использовать команды более
современных процессоров и оптимизации под них.
Может, стабильность это и повышает (поскольку готовые бинарники долго
проверяют, но всё-же я сомневаюсь, что перекомпиляция сильно нестабильным его
сделает), но понижает производительность.
На десктопе, причём, по сегодняшним меркам, на слабой машине, компиляция под
нужную архитектуру, как мне кажется, вполне оправдана. RedHat, например,
компилируется под i586.

Отсюда вопросы. Кто имел опыт, проясните пожалуйста.

Как правильно перекомпилировать ключевые пакеты (чтобы именно под целевую
архитектуру)?
Читал, что apt-build компилирует также, как и на серверах debian - под i386,
чтобы там не указывалось. Сам проверить не удосужился. Так ли это?
Какие пакеты нужно перекомпилировать? Понятно, что: sed, awk, coreutils, init,
bash (я использую dash)... Что ещё?
Вообще, оно того стоит?

Для этого существуют (как я это понимаю) дистрибутивы, в которых такая
оптимизация не является такой трудоёмкой задачей как в дебиане - тот же
дженту и его форки. Думаю благодаря таким дистрибутивам вы сэкономите
своё время используя их если Вы хотите оптимизировать свою систему.

Re: Перекомпиляция ос новных программ

2010-10-16 Пенетрантность alexey.kurinnij

Н. Артём wrote:
Ну, существует apt-build. И такая оптимизация, если брать в расчёт его
наличие, не столь трудоёмка.

При этом, я вовсе не хочу пересобирать всю систему. А поставить Женту, заместо
уже имеющегося дистрибьютива - это как предложить заменить одно авто на другое,
вместо небольшого тюнинга. Ради чего лишние проблемы?
Да и стоял у меня Жента какое-то время. Уже давно. Сейчас Дебиан. Я много чем
не доволен, но переходить на другие дистрибьютивы не собираюсь.

Ну если apt-build умеет хранить флаги компиляции для каждого пакета, то
тогда наверное дженту не потребуется.
Что касается того, какие желательно пересобрать под свой процессор -
наверное это надо спрашивать у самих разработчиков либо достаточно
осведомлённых людей по конкретному ПО - т.к. думаю им виднее.
Здесь ничего конкретного по вашему вопросу пока не прозвучало, хотя
вопрос интересный.

Re: Перекомпиляция ос новных программ

2010-10-16 Пенетрантность Artem Chuprina

Какие пакеты нужно перекомпилировать?
Те, замеры по которым показывают заметную выгоду.
А конкретно? Есть где-либо список пакетов?
Так это вам самим мерять надо.
Не, ну помимо тех пакетов, которые я часто использую (а сейчас это kde,
iceweasel и okular), есть же какие-то общие тесты для пакетов, которые
используют все?

И смысл оптимизировать цикл ожидания? Они же занимаются в основном тем, что
сидят на select(2)

Навскидку - плееры, если бы они не умели автодетект, и bzip2 всякие, если
там действительно есть разница.
Qmmp? Что за автодетект?

Не знаю как qmmp, а mplayer собирается так, что прежде чем начать использовать
процессор, он его обнюхивает. И использует то, что находит.

Тако же и libssl (криптография). Можно на досуге помедитировать на то, из
каких файлов состоит этот пакет. За bzip2 не скажу.

Причем, заметим, и mplayer, и libssl пользуются для ускорения не компиляцией
под 686, а включением в работу вручную написанных ассемблерных кусков.

Понятно, что: sed, awk, coreutils, init, bash (я использую dash)...
С чего бы? Они процессор не используют.
В смысле, как это процессор не используют?
В прямом. Зачем им?
Затем, что они используются в скриптах инициализации, в правилах udev, во
всех остальных скриптах. И т.д. Т.е., если с каждого будет небольшой,
незаметный прирост, в сумме, теоретически, может кое-что набраться.

Ключевое слово если. Откуда он возьмется? Если подумать головой? Подумать
головой предлагается на тему что именно отличает современный процессор от 386
в системе команд, и каким именно образом эти отличия могут ускорить выполнение
coreutils?

Re: Перекомпиляция ос новных программ

2010-10-16 Пенетрантность Artem Chuprina

On Sat, Oct 16, 2010 at 06:40:12PM +0400, Н. Артём wrote:
Может вы немного недооцениваете количество запусков интерпретаторов?
См. ниже про форки.
Я решил, что это просто такое образное сравнение. :-\ Причём тут форки?

Но вы померяйте, померяйте.
Никогда не занимался замерами. И очень смутно представляю как замерить
время выполнения скриптов запуска, например?
Именно.
Что именно? Но это же автоматически не говорит о том, что скорость не
увеличится. Это, вообще, ни о чём не говорит.

Первое правило оптимизации - оптимизировать следует только то место, на
которое показывают замеры как на узкое. Если замеры туда не показывают,
оптимизировать бессмысленно - результат не то что не будет заметен, а его,
скорее всего, не будет вообще.

Ты уже потратил на обсуждение вопроса больше процессорного времени, чем такая
оптимизация, которую ты пытаешься устроить, выиграет за все время жизни твоей
системы.

Расслабься.

Re: Перекомпиляция ос новных программ

2010-10-16 Пенетрантность Artem Chuprina

  Кстати, те 1-2%, что могут быть получены на 99% задач, попросту тонут
  в ошибках измерения.
 Хм... 1-2% Не больше?

Я думаю, что и 1-2% - это СИЛЬНО оптимистичная оценка.  Скорее всего, там
будет 1-2 сотых доли процента...


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87d3ra3u9e.wl%...@ran.pp.ru

Re: Перекомпиляция ос новных программ

2010-10-16 Пенетрантность Artem Chuprina

Может вы немного недооцениваете количество запусков
интерпретаторов?
См. ниже про форки.
Я решил, что это просто такое образное сравнение. :-\ Причём тут форки?

Но вы померяйте, померяйте.
Никогда не занимался замерами. И очень смутно представляю как
замерить время выполнения скриптов запуска, например?
Именно.
Что именно? Но это же автоматически не говорит о том, что скорость не
увеличится. Это, вообще, ни о чём не говорит.

Кхм, но замеров нет. С другой стороны: есть Gentoo. Зачем, если скорость
увеличивается всего лишь на 1-2%? Только из-за сборки с нужными
возможностями? Бессмысленно, поскольку для хранения всех исходников
требуется много дискового пространства - следовательно не оно критично, а в
пакетах, которые в репозиториях других дистрибьютивов, ПО собирается с теми
же самыми возможностями - несколько сборок.

Ну, скажем, пока я в основном пользовался vim, а не emacs - нужной _мне_
сборки в Debian не было. Приходилось делать свой пакет.

Но вообще есть ощущение, что Gentoo - оно в основном таки да, для задротов.
Любителей гордо похвастаться а у меня сборка вся из себя ускоренная и вон как
летает. Еще ни одного достаточно уверенного подтверждения того, что она таки
да, летает (по сравнению с, допустим, дебиановской), я не видел.

Ты уже потратил на обсуждение вопроса больше процессорного времени, чем
такая оптимизация, которую ты пытаешься устроить, выиграет за все время
жизни твоей системы.

Вероятно. Но сейчас мне нечего делать. Ведь иначе я бы не задался этим
вопросом. А скорость выше будет - в будущем.

Еще раз. За всё время жизни твоей системы ты не выиграешь этим и тех
нескольких секунд процессорного времени (не твоего - процессорного), что твоя
система затратила на это обсуждение.

Нет, это, конечно, не подкрепленное замерами утверждение. Оно подкреплено
опытом.

Расслабься.
Я бы с радостью. Но мне день и ночь покоя не даёт... :-\

Найди хорошего психотерапевта. После курса лечения ты сможешь потратить уже
_свое_ время на что-то гораздо более приятное.

Re: Перекомпиляция ос новных программ

2010-10-16 Пенетрантность Artem Chuprina

Делать измерения уж не такая великая задача, так что тешить этим ЧСВ - 
   просто глупо, т.к. как измерять знает даже google и есть множество 
   статеек и руководств.
  :-)
_Я хочу перекомпилировать не ради перекомпиляции, а ради увеличения 
   скорости._
  Ускорение на 0.5-1% загрузочных скриптов позволит считать задачу 
  выполненной?
 Каждого или всех вместе?

Ты действительно не понимаешь, что для этой величины это одно и то же?


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87aame3tun.wl%...@ran.pp.ru

Re: Перекомпиляция ос новных программ

2010-10-16 Пенетрантность Artem Chuprina

Все. Ты назвал пользовательские программы. Они подавляющую часть времени
занимаются тем, что ожидают действий пользователя. В системном вызове select.

То есть да, не потребляют процессор, причем совсем.

Нет, конечно, мозилловцы ухитрились-таки сделать браузер, который порой нехило
жрет процессор (интересно, куда?). Но в основном он жрет все-таки память, и
потому тормозит всё на ожидании ответа от диска.

Это к вопросу о том каким именно образом могут ускорить. А вот могут ли
ускорить реально..? Об этом я и спрашивал.

Так тебе сразу сказали, что не могут. Нечего на этих задачах теми
инструкциями ускорять.

Re: Перекомпиляция ос новных программ

2010-10-16 Пенетрантность Nicholas

On 16.10.2010 13:14, Н. Артём wrote:

Debian скомпилирован под i386, т.е. он не будет использовать команды более
современных процессоров и оптимизации под них.

Отсюда вопросы. Кто имел опыт, проясните пожалуйста.

Те программы для которых это важно, уже есть в разных версиях для разных
процессоров.

Для остальных - важнее стабильность работы.

Мой опыт:

1. Скомпилировать свое ядро бывает очень полезно - рано или поздно
появится железка или будет нужна опция для которой нужно custom ядро, и
если оно уже есть, то добавить небольшое изменение в конфиг и
перекомпилировать будет несложно.

2. Очень много времени потерял в попытке скомлилировать gnucash - там
цвет одного шрифта был прописал в исходнике, а черное на черном читать
было не удобно - скачал src, все сделал по инструкции, раз 10, результат
был стабилен: segmentation failed.

--
Sincerely,
Nicholas

Re: Перекомпиляция ос новных программ

Re: Перекомпиляция ос новных программ

Re: Перекомпиляция ос новных программ

Re: Перекомпиляция ос новных программ

Re: Перекомпиляция ос новных программ

Re: Перекомпиляция ос новных программ

Re: Перекомпиляция ос новных программ

Re: Перекомпиляция ос новных программ

Re: Перекомпиляция ос новных программ

Re: Перекомпиляция ос новных программ

Re: Перекомпиляция ос новных программ

Re: Перекомпиляция ос новных программ

Re: Перекомпиляция ос новных программ

Re: Перекомпиляция ос новных программ

Re: Перекомпиляция ос новных программ

Re: Перекомпиляция ос новных программ

16 matches

Site Navigation

Mail list logo

Footer information