date:20101016

 Подскажите, пожалуйста, как можно заставить bash считать первую
 команду из параметров ключа запуска -c а последующие из stdin? Иначе:
 как заставить bash -с [command] не завершаться после выполнения, а
 ждать ввода?
 Для sh - /bin/dash это достигается комбинированием ключей -c и -s.
 Для наглядности в отдельном эмуляторе терминала:
 $ xterm -e sh -cs ls
 У bash ключ -s тоже есть, но в сочетании с -c он не работает.
А использовать xargs и read где-то после -c - не катит?


-- 
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/618771287229...@web106.yandex.ru

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

On Sat, Oct 16, 2010 at 05:14:03PM +0400, Н. Артём wrote:
Debian скомпилирован под i386, т.е. он не будет использовать команды более
современных процессоров и оптимизации под них.
Может, стабильность это и повышает (поскольку готовые бинарники долго
проверяют, но всё-же я сомневаюсь, что перекомпиляция сильно нестабильным его
сделает), но понижает производительность.
На десктопе, причём, по сегодняшним меркам, на слабой машине, компиляция под
нужную архитектуру, как мне кажется, вполне оправдана. RedHat, например,
компилируется под i586.

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

Какие пакеты нужно перекомпилировать?
Те, замеры по которым показывают заметную выгоду.

Понятно, что: sed, awk, coreutils, init, bash (я использую dash)...
С чего бы? Они процессор не используют.

--
WBR, wRAR
Powered by the ALT Linux fortune(6):

Посмотрите MTU на интерфейсах.
Фрагментация IP-пакетов разрешена?

Всё, мой телепатический модуль перегрелся.
-- alb in community@

signature.asc
Description: Digital signature

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

 On Sat, Oct 16, 2010 at 05:14:03PM +0400, Н. Артём wrote:
   Debian скомпилирован под i386, т.е. он не будет использовать команды более 
  современных процессоров и оптимизации под них.
   Может, стабильность это и повышает (поскольку готовые бинарники долго 
  проверяют, но всё-же я сомневаюсь, что перекомпиляция сильно нестабильным 
  его сделает), но понижает производительность.
   На десктопе, причём, по сегодняшним меркам, на слабой машине, компиляция 
  под нужную архитектуру, как мне кажется, вполне оправдана. RedHat, 
  например, компилируется под i586.

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

   Какие пакеты нужно перекомпилировать?
 Те, замеры по которым показывают заметную выгоду.
А конкретно? Есть где-либо список пакетов?

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


-- 
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/20711287235...@web150.yandex.ru

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

On Sat, Oct 16, 2010 at 05:27:30PM +0400, Н. Артём wrote:
Debian скомпилирован под i386, т.е. он не будет использовать команды
более современных процессоров и оптимизации под них.
Может, стабильность это и повышает (поскольку готовые бинарники долго
проверяют, но всё-же я сомневаюсь, что перекомпиляция сильно нестабильным
его сделает), но понижает производительность.
На десктопе, причём, по сегодняшним меркам, на слабой машине, компиляция
под нужную архитектуру, как мне кажется, вполне оправдана. RedHat,
например, компилируется под i586.
Отсюда вопросы. Кто имел опыт, проясните пожалуйста.
amd64 поставьте.
В смысле?
amd64 скомпилирован под amd64 с SSE2, а не под i386.

Какие пакеты нужно перекомпилировать?
Те, замеры по которым показывают заметную выгоду.
А конкретно? Есть где-либо список пакетов?
Так это вам самим мерять надо.
Навскидку - плееры, если бы они не умели автодетект, и bzip2 всякие, если
там действительно есть разница.

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

Они используются в скриптах. Повсеместно.
Используются. А при чём тут использование процессорной мощности?

--
WBR, wRAR
Powered by the ALT Linux fortune(6):

hiddenman dottedmag: btw, мог бы отдельно вынести features
dottedmag hiddenman: могу прямо сейчас перечислить. Features: конец списка

signature.asc
Description: Digital signature

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

amd64 поставьте.
   В смысле?
 amd64 скомпилирован под amd64 с SSE2, а не под i386.
А, понял. У меня P-4. Всё вышесказанное относится только к x86x32

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

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

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

   Они используются в скриптах. Повсеместно.
 Используются. А при чём тут использование процессорной мощности?
См. выше. Скорость работы, по-идее, может увеличиться?


-- 
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/594211287236...@web138.yandex.ru

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

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

On Sat, Oct 16, 2010 at 05:48:27PM +0400, Н. Артём wrote:
   Понятно, что: sed, awk, coreutils, init, bash (я использую dash)...
 С чего бы? Они процессор не используют.
В смысле, как это процессор не используют?
  В прямом. Зачем им?
 Затем, что они используются в скриптах инициализации, в правилах udev,
 во всех остальных скриптах. И т.д. Т.е., если с каждого будет небольшой,
 незаметный прирост, в сумме, теоретически, может кое-что набраться.
Не должно.

Они используются в скриптах. Повсеместно.
  Используются. А при чём тут использование процессорной мощности?
 См. выше. Скорость работы, по-идее, может увеличиться?
Пересобирать каждую новую версию придётся сильно дольше, чем выигранные
миллисекунды.

-- 
WBR, wRAR
Powered by the ALT Linux fortune(6):

 Так я ещё не собирал ничего... Боязно ;-)
Пакетов бояться -- самолетом не летать ;-)
-- mike in sisyphus@


signature.asc
Description: Digital signature

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

On Sat, 16 Oct 2010 19:32:45 +0600
Andrey Rahmatullin w...@wrar.name wrote:

 On Sat, Oct 16, 2010 at 05:27:30PM +0400, Н. Артём wrote:
 Debian скомпилирован под i386, т.е. он не будет использовать команды 
более современных процессоров и оптимизации под них.
 Может, стабильность это и повышает (поскольку готовые бинарники долго 
проверяют, но всё-же я сомневаюсь, что перекомпиляция сильно 
нестабильным его сделает), но понижает производительность.
 На десктопе, причём, по сегодняшним меркам, на слабой машине, 
компиляция под нужную архитектуру, как мне кажется, вполне оправдана. 
RedHat, например, компилируется под i586.
 Отсюда вопросы. Кто имел опыт, проясните пожалуйста.
   amd64 поставьте.
  В смысле?
 amd64 скомпилирован под amd64 с SSE2, а не под i386.

i386 скомпелирован под i486 фактически


--
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/20101016215101.0e859...@gmail.com

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

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

2010/10/16 Н. Артём artio...@yandex.ru:
 Debian скомпилирован под i386, т.е. он не будет использовать команды более 
 современных процессоров и оптимизации под них.
Под i486, если уж на то пошло.

-- 
С уважением,
Константин Матюхин

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

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

On Sat, 16 Oct 2010 19:18:27 +0600
Andrey Rahmatullin wrote:

AR  Понятно, что: sed, awk, coreutils, init, bash (я использую
AR  dash)...  
AR С чего бы? Они процессор не используют.

В фортунки.

-- 
С уважением,
А.В.Коротков,

mailto:z...@uni.udm.ru


-- 
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/20101016173053.5a035...@desktop.home

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

Затем, что они используются в скриптах инициализации, в правилах udev,
во всех остальных скриптах. И т.д. Т.е., если с каждого будет небольшой,
незаметный прирост, в сумме, теоретически, может кое-что набраться.
Не должно.
Почему?

Они используются в скриптах. Повсеместно.
Используются. А при чём тут использование процессорной мощности?
См. выше. Скорость работы, по-идее, может увеличиться?
Пересобирать каждую новую версию придётся сильно дольше, чем выигранные
миллисекунды.
Ну не так часто они и обновляются. А насчёт миллисекунд - вовсе не факт. В i386
нет даже MMX. Я не знаю как оптимизирует gcc, но множество операций, которые к
мультимедиа никаким боком, гораздо быстрее исполняются, если их код
генерируется с использованием команд MMX расширения. А уж если говорить о более
новых расширениях... По-моему, тут нельзя без замеров однозначно сказать...

--
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/470561287238...@web44.yandex.ru

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

 2010/10/16 Н. Артём artio...@yandex.ru:
   Debian скомпилирован под i386, т.е. он не будет использовать команды более 
  современных процессоров и оптимизации под них.
 Под i486, если уж на то пошло.
Ну может. Просто где-то он пишет -i386- в имени пакета. Сути это не меняет.


-- 
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/614991287238...@web110.yandex.ru

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

Пересобирать каждую новую версию придётся сильно дольше, чем выигранные
миллисекунды.
Ну не так часто они и обновляются. А насчёт миллисекунд - вовсе не факт.
В i386 нет даже MMX. Я не знаю как оптимизирует gcc, но множество
операций, которые к мультимедиа никаким боком, гораздо быстрее
исполняются, если их код генерируется с использованием команд MMX
расширения. А уж если говорить о более новых расширениях... По-моему,
тут нельзя без замеров однозначно сказать...
Вот и не говорите.

--
WBR, wRAR
Powered by the ALT Linux fortune(6):

Created an attachment (id=606)
New /etc/profile.d/gnupg-agent.sh

gnupg-agent.sh, издание второе, переработанное и дополненное.
WORKSFORME(tm).
-- raorn in #5311

signature.asc
Description: Digital signature

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

On Sat, Oct 16, 2010 at 06:20:39PM +0400, Н. Артём wrote:
Затем, что они используются в скриптах инициализации, в правилах udev,
во всех остальных скриптах. И т.д. Т.е., если с каждого будет
небольшой,
незаметный прирост, в сумме, теоретически, может кое-что набраться.
Не должно.
Почему?
Потому что незаметный прирост просуммируется в заметный только при таком
количестве запусков, при каком суммарные расходы на форки будут сильно
выше.
Может вы немного недооцениваете количество запусков интерпретаторов? Причём,
скрипты могут быть достаточно сложными. Ведь, если бы они использовались редко,
не было бы причин заменять bash на более быстрый dash у тех, кто его писал.
Прирост от оптимизаций тоже не всегда уж столь маленький...
Опять же, взять, например, js движок, используемый firefox'ом. Там огромное
количество вызовом JS кода. Предполагаю, что оптимизация, в данном случае,
скорость работы может увеличить.

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

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

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

 Опять же, взять, например, js движок, используемый firefox'ом. Там
 огромное количество вызовом JS кода. Предполагаю, что оптимизация, в
 данном случае, скорость работы может увеличить.
Хромовый V8, например, джитит JS и в compile-time там оптимизировать особо
нечего. FF'шный вроде как тоже.

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

-- 
WBR, wRAR
Powered by the ALT Linux fortune(6):

[RaD] ппл, что полезнее выучить аутотулс или сконс?
Lost [RaD]: если полезность выражается в деньгах - тогда лучше учить ant :)


signature.asc
Description: Digital signature

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

16.10.10, 18:44, Andrey Rahmatullin w...@wrar.name:

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

Опять же, взять, например, js движок, используемый firefox'ом. Там
огромное количество вызовом JS кода. Предполагаю, что оптимизация, в
данном случае, скорость работы может увеличить.
Хромовый V8, например, джитит JS и в compile-time там оптимизировать особо
нечего. FF'шный вроде как тоже.
Ну, кроме того, что весь ff сверху и до низу пронизан JS, вплоть до хранения
настроек, я ещё использую немало плагинов. Это заметно тормозит. FF, как и
xulrunner в Debian скомпилированы по 486? Вы хотите сказать, что никакого
увеличения скорости, при перекомпиляции под P-IV не будет?

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

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

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

 Ну, кроме того, что весь ff сверху и до низу пронизан JS, вплоть до 
 хранения настроек, я ещё использую немало плагинов. Это заметно тормозит. FF, 
 как и xulrunner в Debian скомпилированы по 486? Вы хотите сказать, что 
 никакого увеличения скорости, при перекомпиляции под P-IV не будет?
Я не думаю, что оно будет заметным.

-- 
WBR, wRAR
Powered by the ALT Linux fortune(6):

А самое приятное - быть отловленным девушкой из 1C, которая на вопрос о
наличии их бухгалтерии под Linux даст положительный ответ ;-))
-- rider in devel@


signature.asc
Description: Digital signature

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

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

Н. Артём wrote:

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

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

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

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

On Sat, Oct 16, 2010 at 06:40:12PM +0400, Н. Артём wrote:
  Но вы померяйте, померяйте.
 Никогда не занимался замерами. И очень смутно представляю как замерить время 
 выполнения скриптов запуска, например?

 Вам зачем оптимизация, почувствовать себя крутым или почесать ЧСВ? :)
 На свете есть масса более лёгких способов самоудовлетворения.
 Оптимизацию оставьте тем, кто умеет заниматься делом, в частности,
 измерять нужные величины и делать из полученных чисел правильные выводы.
-- 
 Eugene Berdnikov


-- 
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/20101016150550.gb10...@protva.ru

Re: bash -cs

On Fri, Oct 15, 2010 at 01:46:20PM +0400, ??micier wrote:
 Подскажите, пожалуйста, как можно заставить bash считать первую
 команду из параметров ключа запуска -c а последующие из stdin? Иначе:
 как заставить bash -с [command] не завершаться после выполнения, а
 ждать ввода?

% echo echo aaa\necho bbb | bash -c 'date ; source /dev/stdin'
Сбт Окт 16 18:30:05 MSD 2010
aaa
bbb

 В принципе это башизм, хотя в zsh он тоже работает... Если нет
 требования исполнять подаваемые на stdin команды в том же шелле,
 то -c 'command ; $SHELL' достаточно портабильно.
-- 
 Eugene Berdnikov


-- 
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/20101016143434.ga10...@protva.ru

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

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

В сообщении от Суббота 16 октября 2010 17:30:53 автор Aleksey Korotkov 
написал:
 On Sat, 16 Oct 2010 19:18:27 +0600
 Andrey Rahmatullin wrote:
 
 AR  Понятно, что: sed, awk, coreutils, init, bash (я использую
 AR  dash)...
 AR С чего бы? Они процессор не используют.
 
 В фортунки.
Хоть куда. Ведь так на самом деле и есть. 

Хоть как собирай программу,  узким местом которой является работа с диском, 
быстрее она работать не станет. Ежели программа работает с мультимедией 
всякой, то она содержит ассемблерные вставки и определяет возможно процессора 
в рантайме (см. mplayer). Пересборка программы под конкретный x86-32 процессор 
нифигуськи не дает. Этим занимаются только горе-генту-оптимизаторы.

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

On Sat, Oct 16, 2010 at 06:40:12PM +0400, Н. Артём wrote:
Но вы померяйте, померяйте.
Никогда не занимался замерами. И очень смутно представляю как замерить
время выполнения скриптов запуска, например?
Вам зачем оптимизация, почувствовать себя крутым или почесать ЧСВ? :)
На свете есть масса более лёгких способов самоудовлетворения.
Оптимизацию оставьте тем, кто умеет заниматься делом, в частности,
измерять нужные величины и делать из полученных чисел правильные выводы.
Проще: мне она затем, чтобы быстрее работало. Я не хочу ни чесать ЧСВ (или
что-то ещё, пока что), ни делать выводы. А небольшое удовлетворение будет
достигнуто в результате того, что станет быстрее работать.
Делать измерения уж не такая великая задача, так что тешить этим ЧСВ - просто
глупо, т.к. как измерять знает даже google и есть множество статеек и
руководств.
Я же просто не хочу этим заниматься.

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

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

 On Sat, Oct 16, 2010 at 06:55:10PM +0400, Н. Артём wrote:
 Может вы немного недооцениваете количество запусков интерпретаторов? 
 См. ниже про форки.
   Я решил, что это просто такое образное сравнение. :-\ Причём тут форки?
 Самое дорогое в шелл-скриптах - форки всяких cat/cut/awk/sed/whatever.
В смысле, их вызовы? Или именно форки в них?

   Ну, кроме того, что весь ff сверху и до низу пронизан JS, вплоть до 
  хранения настроек, я ещё использую немало плагинов. Это заметно тормозит. 
  FF, как и xulrunner в Debian скомпилированы по 486? Вы хотите сказать, что 
  никакого увеличения скорости, при перекомпиляции под P-IV не будет?
 Я не думаю, что оно будет заметным.
Не знаю... Опять же, хотя бы тест какой-нибудь был. Ведь, наверняка, 
проводились (я плохо искал)?


-- 
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/565061287242...@web10.yandex.ru

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

On Sat, Oct 16, 2010 at 07:13:53PM +0400, Н. Артём wrote:
  Может вы немного недооцениваете количество запусков интерпретаторов? 
  См. ниже про форки.
Я решил, что это просто такое образное сравнение. :-\ Причём тут форки?
  Самое дорогое в шелл-скриптах - форки всяких cat/cut/awk/sed/whatever.
 В смысле, их вызовы? Или именно форки в них?
Их вызовы при помощи fork.

-- 
WBR, wRAR
Powered by the ALT Linux fortune(6):

lioka roman: use std-smp и не ищи на опу приключений
roman lioka: дык до dist-upgrade все работало
roman причем отлично
lioka вот поэтому и std-smp. оно и после работает, как правило


signature.asc
Description: Digital signature

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

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

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

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

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

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

 Их вызовы при помощи fork.
А, въехал. НУ это уже относится к libc и ядру. Насчёт libc - тоже вопрос...


-- 
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/1161287242...@web80.yandex.ru

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

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

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

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

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

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

16 октября 2010 г. 21:20 пользователь Н. Артём artio...@yandex.ru написал:
 Их вызовы при помощи fork.
 А, въехал. НУ это уже относится к libc и ядру. Насчёт libc - тоже вопрос...

Ядро вполне ставится штатное с нужной сборкой.
А беспокойство по поводу libc рекомендуется лечить установкой libc6-i686

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

И еще, не следует надеяться на всякие SSE и MMX, они применимы к очень
узкому классу задач, в которые точно не входят ядро и скрипты.

-- 
Stanislav

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

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

Не должно.

Почему?

Они используются в скриптах. Повсеместно.

Используются. А при чём тут использование процессорной мощности?

См. выше. Скорость работы, по-идее, может увеличиться?

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

Ну не так часто они и обновляются. А насчёт миллисекунд - вовсе не факт. В
i386 нет даже MMX. Я не знаю как оптимизирует gcc, но множество операций,
которые к мультимедиа никаким боком, гораздо быстрее исполняются, если их
код генерируется с использованием команд MMX расширения. А уж если
говорить о более новых расширениях... По-моему, тут нельзя без замеров
однозначно сказать...
Вам не мерить всякую фигню надо, а почитать про векторные расширения.
Основной смысл этих расширений.
В процессор добавлены большие регистры (128бит и более) куда можно кинуть
много небольших переменных и за раз что-то с ними сделать. Допустим вы
складываете в цикле n-e кол-во 16битных целых. Программист может написать код,
который использует эту возможность. Этим он сделает вычисление быстрее, а
программу сложнее. Для числодробилок это усложнение необходимо и оправданно.
Ежели программист просто напишет плюсик, то в дело вступает компилятор. Ежели
компилятору скажут, что можно использовать mmx, sse и прочие векторные
расширения, то из программного кода он попытается вычленить те, куски, которые
можно векторизировать. Даже в простейшем случае, приведенном выше, компилятор
не будет знать что делать. А вдруг под кол-вом итераций (n) скрывается малое
число (1-15)? Компилятор, если возьмется векторизировать, должен отсечь кол-во
итераций меньше 8 и досчитывать их без расширений(или добивать нулями). Будет
работать этот код быстрее или медленнее - неизвестно. В реальном же коде если
программист не подстраивался под компилятор, то компилятор вообще почти ничего
не поймет. Запихнет эти инструкции в десятке-другом мест, причем с неизвестным
результатом.
Про зачатки векторизации в компиляторе gcc можно почитать сдесь
http://gcc.gnu.org/projects/tree-ssa/vectorization.html

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

2010-10-16 Пенетрантность Munko O. Bazarzhapov

Linux это гибкий мир, выбор дистрибутивов огромный
когда задавался вопросом которуй у топикстартера долго думал, потом все же
сверил, дома поставил ArchLinux а на работе Debian

Дома мазохизм но оптимизированный под конкретное железо, на работе
стабильность
разницы в скоростях почти не заметны, зато успокоено внутренее эго :)

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

p.s. ничего не имею против Gentoo она мне тоже нравится в свое роде, но к
сожалению со с годами начинаешь ценить время

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

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

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

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

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

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

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

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

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

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

Расслабься.

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

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

Вам на генту.

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

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

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

On Sat, Oct 16, 2010 at 07:11:54PM +0400, Н. Артём wrote:
 Делать измерения уж не такая великая задача, так что тешить этим ЧСВ - просто 
 глупо, т.к. как измерять знает даже google и есть множество статеек и 
 руководств.

 :-)

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

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


-- 
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/20101016164818.gc10...@protva.ru

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

 Ну если apt-build умеет хранить флаги компиляции для каждого пакета, то 
 тогда наверное дженту не потребуется.
Не, ну мне же не нужна функциональность USE флагов.
Для меня достаточно пересборки с нужным -march/-mtune, одинаковыми для всех, и 
иже с ними.

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


-- 
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/486801287247...@web43.yandex.ru

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

В сообщении от Суббота 16 октября 2010 18:20:39 автор Н. Артём написал:
Затем, что они используются в скриптах инициализации, в правилах udev,
во всех остальных скриптах. И т.д. Т.е., если с каждого будет
небольшой, незаметный прирост, в сумме, теоретически, может кое-что
набраться.
Не должно.
Почему?
Они используются в скриптах. Повсеместно.
Используются. А при чём тут использование процессорной мощности?
См. выше. Скорость работы, по-идее, может увеличиться?
Пересобирать каждую новую версию придётся сильно дольше, чем выигранные
миллисекунды.
Ну не так часто они и обновляются. А насчёт миллисекунд - вовсе не факт. В
i386 нет даже MMX. Я не знаю как оптимизирует gcc, но множество операций,
которые к мультимедиа никаким боком, гораздо быстрее исполняются, если их
код генерируется с использованием команд MMX расширения. А уж если
говорить о более новых расширениях... По-моему, тут нельзя без замеров
однозначно сказать...
Вам не мерить всякую фигню надо, а почитать про векторные расширения.
Блин, сколько сижу на своём старье, ни разу про них не слышал. Почитаю. Но
сомневаюсь, что в P4 это есть. В P3 - нет на 100% (если, конечно, книжки не
врут и у него внезапно не оказалось такой недокументированной возможности).

Сейчас посмотрел. Понял: это и есть SSE о котором я толком ничего не знаю...

Основной смысл этих расширений.
В процессор добавлены большие регистры (128бит и более) куда можно кинуть
много небольших переменных и за раз что-то с ними сделать.
Допустим вы складываете в цикле n-e кол-во 16битных целых. Программист может
написать код, который использует эту возможность.
Честно, не думаю, что программисты будут этим заниматься. По крайней мере, для
неспецифического ПО. Вот если компилятор умеет оптимизировать так, что их
задействует...

Ежели программист просто напишет плюсик, то в дело вступает компилятор. Ежели
компилятору скажут, что можно использовать mmx, sse и прочие векторные
расширения, то из программного кода он попытается вычленить те, куски,
которые можно векторизировать. Даже в простейшем случае, приведенном выше,
компилятор не будет знать что делать.
А вдруг под кол-вом итераций (n) скрывается малое
число (1-15)?
Компилятор, если возьмется векторизировать, должен отсечь кол-во итераций
меньше 8 и досчитывать их без расширений(или добивать нулями).
Будет работать этот код быстрее или медленнее - неизвестно. В реальном же
коде если программист не подстраивался под компилятор, то компилятор вообще
почти ничего не поймет. Запихнет эти инструкции в десятке-другом мест, причем
с неизвестным результатом.
Именно gcc?

Про зачатки векторизации в компиляторе gcc можно почитать сдесь
http://gcc.gnu.org/projects/tree-ssa/vectorization.html
Почитаю.

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

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

Linux это гибкий мир, выбор дистрибутивов огромный
когда задавался вопросом которуй у топикстартера долго думал, потом все же
сверил, дома поставил ArchLinux а на работе Debian
Дома мазохизм но оптимизированный под конкретное железо, на работе
стабильность
Так я и говорю про то. Не полная перекомпиляция. Не часто. Ведь, допустим, мне
не особенно и нужно новое ПО. За чем мне гнаться? За новыми фичами, которые
мне не нужны? Разве только за исправлением багов. Так и то - одни исправляют,
новые появляются. Не так уж и часто производятся обновления того, что нужно
перекомпилировать...

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

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

Не знаю как qmmp, а mplayer собирается так, что прежде чем начать
использовать процессор, он его обнюхивает. И использует то, что находит.
Тако же и libssl (криптография). Можно на досуге помедитировать на то, из
каких файлов состоит этот пакет. За bzip2 не скажу.
Причем, заметим, и mplayer, и libssl пользуются для ускорения не компиляцией
под 686, а включением в работу вручную написанных ассемблерных кусков.
Ну с ними - понятно.

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

Но, вообще, годного справочника у меня нет под рукой, а искать - лениво. Но
факт: такие команды, как jcxz или команды прологов/эпилогов... Я не знаю с
какого CPU они появились. Но знаю, что система команд расширялась. И не знаю
быстрее ли они, и использует ли их компилятор (хотя, вероятно, но точно не все
компиляторы и не всегда).

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

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

On Sat, 16 Oct 2010 18:50:54 +0400
Ekimov Alexandr wrote:

EA Хоть куда. Ведь так на самом деле и есть.

Ну да. Исполняются они не процессором, а магическими пассами.

-- 
С уважением,
А.В.Коротков,

mailto:z...@uni.udm.ru


-- 
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/20101016212534.61ce2...@desktop.home

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

 On Sat, Oct 16, 2010 at 07:11:54PM +0400, Н. Артём wrote:
   Делать измерения уж не такая великая задача, так что тешить этим ЧСВ - 
  просто глупо, т.к. как измерять знает даже 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/424891287250...@web42.yandex.ru

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

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

16 октября 2010 г. 21:20 пользователь Н. Артём artio...@yandex.ru написал:
Их вызовы при помощи fork.
А, въехал. НУ это уже относится к libc и ядру. Насчёт libc - тоже вопрос...
Ядро вполне ставится штатное с нужной сборкой.
Ядро у меня самосборное, естественно. Зачем мне штатное с тонной модулей и
кучей барахла? Я просто имел ввиду, что скорость fork, вероятно, может
зависеть, например от планировщика, который был выбран.

А беспокойство по поводу libc рекомендуется лечить установкой libc6-i686
Посмотрю. Однако, 686 - хорошо, а p4, в данном случае, - лучше. Не так ли? :-)

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

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

Рекомендую не извращаться с пересборкой, а посмотреть в дистрибутиве.
И еще, не следует надеяться на всякие SSE и MMX, они применимы к очень
узкому классу задач, в которые точно не входят ядро и скрипты.
Ну хорошо, я не про не скрипты, во-первых, говорил, а про их интерпретаторы.
А, во-вторых... Ядро? Там же специально дали возможность компилировать под
конкретную модель ЦП. Блин, в менюшке выбор. :-\ Ведь не от праздного же
безделья они это сделали?

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

2010/10/16 Н. Артём artio...@yandex.ru:
 Открыл справочник. Ну и пылища... :-\ Первой попалась инструкция cpuid. если 
 говорить _именно о 386-м_ - там её нет. Если говорить не о coreutils, а, 
 например об mplayer, вами хвалёный autodetect будет работать, если он 
 скомпилирован под 386-й? Там чем-то заменяется cpuid?
Извините, но вы просто сетевой тролль. Вам уже давно написали, что debian
компилируется под i486. В этих процессорах инструкция cpuid есть.

-- 
С уважением,
Константин Матюхин

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

16.10.10, 20:35, Artem Chuprina r...@ran.pp.ru:

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

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

В чём же тогда причина того, что Gentoo до сих пор не умер на десктопах?
Неужели кому-то нравится ждать ebuild'ов? :-\

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

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

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

  Кстати, те 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 Н. Артём artio...@yandex.ru:
Открыл справочник. Ну и пылища... :-\ Первой попалась инструкция cpuid.
если говорить _именно о 386-м_ - там её нет. Если говорить не о coreutils,
а, например об mplayer, вами хвалёный autodetect будет работать, если он
скомпилирован под 386-й? Там чем-то заменяется cpuid?
Извините, но вы просто сетевой тролль.
Вам про троллофобию никто не говорил? Троллить, вообще, - это уныло. А троллить
рассылку - это даже уже не уныло, а просто я не знаю... Уж больно низко вы меня
ставите. :-\

Вам уже давно написали, что debian
компилируется под i486. В этих процессорах инструкция cpuid есть.
Я заметил. Вопрос был не в том. А в том чем таким отличаются i386 и p-iv, что
может ускорить выполнение coreutils.
Привёл пример к тому что _может_ (о только не подумайте, что я вам пытаюсь
втереть, что cpuid используется в coreutils, там ниже написано про что...). И
там дальше, кстати, продолжение ответа.
К словам придираться - это здорово.
Если не понятно, общая мысль такова: Я решил, что перекомпиляция shell, awk,
coreutils, etc. (заметьте не одних coreutils) может повысить скорость их
выполнения, поскольку, во-первых, в новых CPU добавлены новые команды, которые
может использовать компилятор, в сгенерированном коде. Причём их скорость может
быть выше, чем использование связок из нескольких 'старых'. Следовательно,
выполнение будет быстрее (заметьте - при выполнении предыдущего условия, в
котором нет утверждения). Во-вторых, для некоторых пакетов возможно включить
-O3, поскольку это не сильно повлияет на их стабильность. Что также может
ускорить выполнение. Поскольку ПО из coreutils используется часто, возможно,
скорость работы в целом возрастёт.

Вы здесь троллинг где-то усмотрели? Или надо каждую мою мысль так разъяснять?
Я спрашиваю, поскольку не знаю. Знал бы и утверждал - не спрашивал бы.
Или, может, вы усмотрели в моём сообщении саботаж работы рассылки? :-\

P.S.:
Также, если вы считаете, что это троллинг, вас никто не заставляет на него
отвечать.

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

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

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

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

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

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

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

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

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

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

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

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

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

Кстати, те 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/451091287251...@web49.yandex.ru

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

Делать измерения уж не такая великая задача, так что тешить этим ЧСВ - 
   просто глупо, т.к. как измерять знает даже 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: Перекомпиляция осн овных программ

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

Так что я ставлю на то, что перекомпиляция даст не более 1% ускорения.
--
Eugene Berdnikov

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

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

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

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

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

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

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

Я конечно понимаю, что отсылка к возрасту, пожалуй, самый гнилой аргумент
в любом споре, но мне кажется, что число 14 в e-mail адресе нашего субъекта
оказалось там совсем неспроста.

-- 
С уважением,
Константин Матюхин

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

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

P.S.:
И не надо мне психотерапевтов советовать, бэ. Для этого есть другие обсуждения.


-- 
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/15861287252...@web22.yandex.ru

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

 Я конечно понимаю, что отсылка к возрасту, пожалуй, самый гнилой аргумент
 в любом споре, но мне кажется, что число 14 в e-mail адресе нашего субъекта
 оказалось там совсем неспроста.
Да, неспроста. Только этому e-mail'у уже не так мало лет. И кто здесь тролль? 
Сочувствую.


-- 
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/15991287252...@web22.yandex.ru

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

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

В Sat, 16 Oct 2010 21:54:30 +0400
Artem Chuprina r...@ran.pp.ru пишет:

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

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

(Пока разворачивается debootstrap, вклинюсь в ваш чатик. :))
Скорее не опыт, а трезвый расчёт: сколько места на дисках и процессорного
времени
понадобится для сборки ещё под несколько архитектур (i486, i586, pentium II,
III, iV
core, atom, i3-i7, ну и пачка от AMD).
Для полноты добавим к этому отслеживание ошибок по каждой архитектуре.
Кто и на чём всё это будет делать?

Для оптимизаторов есть потомки Debian -- для музыки, медицины, науки и т.д.
Там нужные пакеты доработаны и пересобраны так, что действительно ощутим
результат.

--
Best Regards,
Yuri Kozlov

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

Хм... Таки вы действительно имеете квалификацию выше, чем те, кто в
дебиане собирают ядра?
И чем докажете, что те модули лишние?

Я просто имел ввиду, что скорость fork, вероятно, может зависеть, например от
планировщика, который был выбран.

Для самого fork - те же 1-2%. Разве что машина будет _действительно_ загружена.
У меня на работе такая одна. И то, загружена она по диску, а не по
процессору, ибо БД, а не вычисления.

Нет. P4 от P3 в этом месте отличается не настолько сильно.
По-крайней мере, оптимизация без всяких MMX и SSE одинаковая.

Да. Достаточно прочитать документацию.

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

Таки вы не первый пытаетесь получить что-то пересборкой.
В инете тестов дофига было.

1-2%. Интерпретаторы чаще обращаются к libc, чем к своим функциям. А
для libc есть и -i686

А, во-вторых... Ядро? Там же специально дали возможность компилировать под
конкретную модель ЦП. Блин, в менюшке выбор. :-\ Ведь не от праздного же
безделья они это сделали?

И? Ставь нужное ядро из дистрибутива, результат по скорости работы
будет такой же.

--
Stanislav

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

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

16 октября 2010 г. 23:54 пользователь Artem Chuprina r...@ran.pp.ru написал:
 Но вообще есть ощущение, что Gentoo - оно в основном таки да, для задротов.
 Любителей гордо похвастаться а у меня сборка вся из себя ускоренная и вон как
 летает.  Еще ни одного достаточно уверенного подтверждения того, что она таки
 да, летает (по сравнению с, допустим, дебиановской), я не видел.

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

-- 
Stanislav

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

On Sat, Oct 16, 2010 at 09:32:38PM +0400, Н. Артём wrote:
 Ядро у меня самосборное, естественно. Зачем мне штатное с тонной модулей
 и кучей барахла? 
Если вы считаете, что файлы ненужных модулей тратят какие-то ваши ресурсы,
проще и быстрее удалять их rm(1), а не пересобирать ядро целиком.

-- 
WBR, wRAR
Powered by the ALT Linux fortune(6):

thresh я двач не читаю, я туда пишу!
Lost срешь?
Lost теперь я понимаю как твой ник читается по англицки


signature.asc
Description: Digital signature

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

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

Кстати apt-build-ом пытался только что побилдить - он ругнулся, при чём 
не ясно на что, но мне понравился конец коротенького мана

*BUGS
  Many.
*Достаточно сырая вещь, по крайней мере в стабильном*
*Да и без функционала вроде use-флагов - мало толку с него.


--
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/4cb9f678.50...@gmail.com

Re: диагностика openvpn

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

2010/10/11 Nicholas s...@networkgate.us

 On 11.10.2010 18:18, Dmitry E. Oboukhov wrote:

 Когда-то я задавал уже смежный с этой проблемой вопрос, но потом
 проблема сама рассосалась а теперь вот опять всплыло...


 Заметил, что иногда бывают проблемы на определенных портах, помогает
 переход с port 80 на 8080 и обратно.


Шейпер у провайдера, давят торенты?

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

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

Stanislav Vlasov stanislav@gmail.com writes:

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

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

Настоящие хардкорные гентушники говорят прежде всего о гибкости, которую
дает перекомпиляция (use-флаги, позволяющие для многих пакетов
включить/выключить использование каких-либо библиотек). А задроты с
-funroll-loops -- явление вполне кросс-дистрибутивное; в генту им,
конечно, комфортнее, потому что в процессе их естественной
жизнедеятельности не встают вопросы типа а как сделать make uninstall,
если я каталог сборки давно снёс?.

Кстати, я с нетерпением жду, когда кто-нибудь популяризует среди
озабоченных -fprofile-arcs/-fbranch-probabilities, что придаст процессу
перекомпиляции совершенно особую прелесть: «опций gcc накрутить любой
дурак сможет, а настоящий мужик должен собрать первый раз, позапускать
как следует и собрать во второй раз с использованием собранной
статистики».

Об ошибках измерения: не так давно в tcl-c...@sf.net появился повод
вспомнить, что рантаймовые ошибки могут оказаться полной фигнёй по
сравнению с «артефактами выравнивания» конкретных сборок: то есть,
делаешь изменение (кода или опций компилятора -- неважно), компилируешь,
на запусках имеешь стабильное ускорение на 10% -- и внезапно
оказывается, что к *смыслу* изменений оно никакого отношения не имеет, а
просто какой-то кусок кода или данных расположился удачнее. Такой тип
ошибок почему-то редко кто подозревает; обычно присматриваются к
методике тестирования в части порядка запуска, или там набора исходных
данных -- при том, что основная составляющая ошибки может быть к моменту
запуска уже внесена.

-- 
Regards, Anton Kovalenko
+7(916)345-34-02 | Elektrostal' MO, Russia

Broadcom BCM5751 jumbo

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


Всем привет.

Может тут есть кто-нибудь, кто может подвердить, что BCM5751 не умеет 
jumbo. Или опровергнуть.


В даташите пусто.

http://lists.freebsd.org/pipermail/freebsd-net/2006-June/010868.html
Fujitsu-Simens says:
'Jumbo frames (up to 9 KB) (except for BCM5721 and BCM5751)'
Dell says:
'Jumbo frames (up to 9 kB) (only for BCM5721 and BCM5751)'

--
sergio.


--
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/4cba2f89.1000...@sergio.spb.ru

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

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

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

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

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

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

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

Мой опыт:

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

--
Sincerely,
Nicholas

Re: диагностика openvpn

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


On 16.10.2010 21:13, Oleg Motienko wrote:

2010/10/11 Nicholass...@networkgate.us


On 11.10.2010 18:18, Dmitry E. Oboukhov wrote:


Когда-то я задавал уже смежный с этой проблемой вопрос, но потом
проблема сама рассосалась а теперь вот опять всплыло...



Заметил, что иногда бывают проблемы на определенных портах, помогает
переход с port 80 на 8080 и обратно.



Шейпер у провайдера, давят торенты?


Нет, с торрентами проблем никогда небыло.

Мне объясняли так: ддосят далекие сети на каких-то портах - эти порты 
прижимают, временно, пока не разберутся.


Это, кстати, можно проверить - пакету можно точно задать маршрут и 
посмотреть по какому маршруту что происходит.


http://www.opennet.ru/docs/RUS/ip_network/glava_4.html#_4_2

Альтернативой одношаговому подходу является указание в пакете всей 
последовательности маршрутизаторов, которые пакет должен пройти на своем 
пути. Такой подход называется маршрутизацией от источника - Source 
Routing. В этом случае выбор маршрута производится конечным узлом или 
первым маршрутизатором на пути пакета, а все остальные маршрутизаторы 
только отрабатывают выбранный маршрут, осуществляя коммутацию пакетов, 
то есть передачу их с одного порта на другой. Алгоритм Source Routing 
применяется в сетях IP только для отладки, когда маршрут задается в поле 
Резерв (IP OPTIONS) пакета.


--
Sincerely,
Nicholas


--
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/i9dje9$js...@dough.gmane.org

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

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

On Saturday 16 of October 2010 23:52:25 Н. Артём wrote:

Не, ну мне же не нужна функциональность USE флагов.
Для меня достаточно пересборки с нужным -march/-mtune, одинаковыми для
всех, и иже с ними.

Лет 10 назад занимался опртимизацией своей собственной программы.
С тех пор вынес следующее впечатления:

1) Разница между -O0 и -O2, на обычных задачах, незаметна вообще.
Только на числодробительных что-то можно заметить.
Прочие опции компилятора, чаще всего не помогают, но могут ухудшить.

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

3) многозадачность убивает напроч любую подобную оптимизацию,
если, конечно, программа не числодробилка.

Дело в том, что числодробилка, в основном, складывает и вычитает, умножает и
делит.
Чтобы улучшить производительность числодробилки, нужно чтобы арифметика
работала побыстрее, а прочих команд было поменьше.
Вот для этого и нужны MMX, SSE и опции компилятора.

А прочие программы, в основном, занимаются копированием данных туда-сюда.
Тут никакая оптимизация не поможет.

--
Скажи, кузнечик,
О своей жизни в траве
Не упрыгивай!

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

On Sat, Oct 16, 2010 at 09:27:26PM +0400, Н. Артём wrote:
_Я хочу перекомпилировать не ради перекомпиляции, а ради увеличения
скорости._
Ускорение на 0.5-1% загрузочных скриптов позволит считать задачу
выполненной?
Каждого или всех вместе? Не думаю, что это заметное ускорение... Нет. :-(
Сочувствую. Видите ли, там действительно основная нагрузка -- форки.
Плюс старт бинарников: куча open() и mmap() -- код, исполняемый в ядре.
Плюс немного ELF loader. Плюс интерпретация скрипта башем, где SSE*
совершенно не требуются. Совершенно непонятно, где и что здесь можно
ускорить оптимизацией... Что касается самого ядра, в дебиане его можно
взять уже собранное с оптимизацией под нужную архитектуру.
Так что я ставлю на то, что перекомпиляция даст не более 1% ускорения.
Нечего мне сочувствовать. Причём _здесь_ SSE? Ну, в общем, понятно, что смысла
нет... Но и тестов - нет.

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

16 октября 2010 г. 23:32 пользователь Н. Артём artio...@yandex.ru написал:
16 октября 2010 г. 21:20 пользователь Н. Артём artio...@yandex.ru
написал:
Их вызовы при помощи fork.
А, въехал. НУ это уже относится к libc и ядру. Насчёт libc - тоже
вопрос...
Ядро вполне ставится штатное с нужной сборкой.
Ядро у меня самосборное, естественно. Зачем мне штатное с тонной модулей и
кучей барахла?
Хм... Таки вы действительно имеете квалификацию выше, чем те, кто в
дебиане собирают ядра?
Не смешите. Пичём тут квалификация? Квалификация в чём? Я использую их патчи, а
уж выбрать опции из меню - много ума не надо.

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

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

А, во-вторых... Ядро? Там же специально дали возможность компилировать под
конкретную модель ЦП. Блин, в менюшке выбор. :-\ Ведь не от праздного же
безделья они это сделали?
И? Ставь нужное ядро из дистрибутива, результат по скорости работы
будет такой же.
Положим, повыше. Мне большого труда перекомпилировать его не составит. Я не
настолько ленив.

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

В Sat, 16 Oct 2010 21:54:30 +0400
Artem Chuprina r...@ran.pp.ru пишет:
Первое правило оптимизации - оптимизировать следует только то
место, на которое показывают замеры как на узкое. Если замеры туда
не показывают, оптимизировать бессмысленно - результат не то что не
будет заметен, а его, скорее всего, не будет вообще.
Еще раз. За всё время жизни твоей системы ты не выиграешь этим и тех
нескольких секунд процессорного времени (не твоего - процессорного), что
твоя система затратила на это обсуждение.

Нет, это, конечно, не подкрепленное замерами утверждение. Оно
подкреплено опытом.
(Пока разворачивается debootstrap, вклинюсь в ваш чатик. :))
Скорее не опыт, а трезвый расчёт: сколько места на дисках и процессорного
времени
понадобится для сборки ещё под несколько архитектур (i486, i586, pentium
II, III, iV
core, atom, i3-i7, ну и пачка от AMD).
Это понятно. Но для себя-то..? Хотя, видимо, не стоит.

Для полноты добавим к этому отслеживание ошибок по каждой архитектуре.
Кто и на чём всё это будет делать?
Насчёт ошибок понятно... Но, тем не менее, не думаю, что настолько много
специфичных для архитектуры ошибок.

Для оптимизаторов есть потомки Debian -- для музыки, медицины, науки и т.д.
Там нужные пакеты доработаны и пересобраны так, что действительно ощутим
результат.
За счёт чего? Именно специфичные для задач пакеты?

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

 Кстати apt-build-ом пытался только что побилдить - он ругнулся, при чём 
 не ясно на что, но мне понравился конец коротенького мана
 *BUGS
 Many.
 *Достаточно сырая вещь, по крайней мере в стабильном*
 *Да и без функционала вроде use-флагов - мало толку с него.
Да, мне тоже нечто похожее, бывало выдавал.. Весьма информативно: Ошибка: make 
завершился с кодом выполнения 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/574591287292...@web23.yandex.ru

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

 On Sat, Oct 16, 2010 at 09:32:38PM +0400, Н. Артём wrote:
   Ядро у меня самосборное, естественно. Зачем мне штатное с тонной модулей
   и кучей барахла? 
 Если вы считаете, что файлы ненужных модулей тратят какие-то ваши ресурсы,
 проще и быстрее удалять их rm(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/23031287292...@web6.yandex.ru

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

 Stanislav Vlasov stanislav@gmail.com writes:
Но вообще есть ощущение, что Gentoo - оно в основном таки да, для 
   задротов.
Любителей гордо похвастаться а у меня сборка вся из себя ускоренная и 
   вон как
летает.  Еще ни одного достаточно уверенного подтверждения того, что 
   она таки
да, летает (по сравнению с, допустим, дебиановской), я не видел.
   Могу добавить, что было сравнение дебиана и генту с оптимизациями.
   Таки не в пользу генту по тестам. Правда, это было довольно давно, во
   времена Etch, если не ошибаюсь.
 Настоящие хардкорные гентушники говорят прежде всего о гибкости, которую
 дает перекомпиляция (use-флаги, позволяющие для многих пакетов
 включить/выключить использование каких-либо библиотек).
Вряд ли это сильно влияет на скорость. Скорее, на объём занятого дискового 
пространства.
Разве сейчас это кого-то сильно волнует на десктопе?

 Кстати, я с нетерпением жду, когда кто-нибудь популяризует среди
 озабоченных -fprofile-arcs/-fbranch-probabilities, что придаст процессу
 перекомпиляции совершенно особую прелесть: «опций gcc накрутить любой
 дурак сможет, а настоящий мужик должен собрать первый раз, позапускать
 как следует и собрать во второй раз с использованием собранной
 статистики».
:-D Жестоко. Профилированием пусть разработчики занимаются.

 Об ошибках измерения: не так давно в tcl-c...@sf.net появился повод
 вспомнить, что рантаймовые ошибки могут оказаться полной фигнёй по
 сравнению с «артефактами выравнивания» конкретных сборок: то есть,
 делаешь изменение (кода или опций компилятора -- неважно), компилируешь,
 на запусках имеешь стабильное ускорение на 10% -- и внезапно
 оказывается, что к *смыслу* изменений оно никакого отношения не имеет, а
 просто какой-то кусок кода или данных расположился удачнее. Такой тип
 ошибок почему-то редко кто подозревает; обычно присматриваются к
 методике тестирования в части порядка запуска, или там набора исходных
 данных -- при том, что основная составляющая ошибки может быть к моменту
 запуска уже внесена.
Но, тем не менее, что-то же  этому способствовало?


-- 
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/586441287293...@web15.yandex.ru

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

On 16.10.2010 13:14, Н. Артём wrote:
Debian скомпилирован под i386, т.е. он не будет использовать команды более
современных процессоров и оптимизации под них.
Отсюда вопросы. Кто имел опыт, проясните пожалуйста.
Те программы для которых это важно, уже есть в разных версиях для разных
процессоров.
Для остальных - важнее стабильность работы.
Мой опыт:
1. Скомпилировать свое ядро бывает очень полезно - рано или поздно
появится железка или будет нужна опция для которой нужно custom ядро, и
если оно уже есть, то добавить небольшое изменение в конфиг и
перекомпилировать будет несложно.
Согласен. Но кто-то тут предлагал использовать исключительно пакеты. :-\

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

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

2010-10-16 Пенетрантность Dmitry A. Zhiglov

On Saturday 16 of October 2010 23:52:25 Н. Артём wrote:
Не, ну мне же не нужна функциональность USE флагов.
Для меня достаточно пересборки с нужным -march/-mtune, одинаковыми для
всех, и иже с ними.
Лет 10 назад занимался опртимизацией своей собственной программы.
С тех пор вынес следующее впечатления:
1) Разница между -O0 и -O2, на обычных задачах, незаметна вообще.
Только на числодробительных что-то можно заметить.
Прочие опции компилятора, чаще всего не помогают, но могут ухудшить.
2) Основной ресурс оптимизации -- это грамотное расположение кода и данных,
чтобы правилно забить кэш процессора.
Но
а) это большая морока
б) имеет смысл только на числодробительных задачах
А на мультимедиа? Иногда, тоже имеет смысл?

3) многозадачность убивает напроч любую подобную оптимизацию,
если, конечно, программа не числодробилка.
Дело в том, что числодробилка, в основном, складывает и вычитает, умножает и
делит.
Чтобы улучшить производительность числодробилки, нужно чтобы арифметика
работала побыстрее, а прочих команд было поменьше.
Вот для этого и нужны MMX, SSE и опции компилятора.
А прочие программы, в основном, занимаются копированием данных туда-сюда.
Тут никакая оптимизация не поможет.
Хм... Вероятно, вы правы. Но тесты посмотреть, тем не менее, охота.

Re: Broadcom BCM5751 jumbo

2010/10/17 sergio mail...@sergio.spb.ru:
 Всем привет.

 Может тут есть кто-нибудь, кто может подвердить, что BCM5751 не умеет jumbo.
 Или опровергнуть.

 В даташите пусто.

 http://lists.freebsd.org/pipermail/freebsd-net/2006-June/010868.html
 Fujitsu-Simens says:
 'Jumbo frames (up to 9 KB) (except for BCM5721 and BCM5751)'
 Dell says:
 'Jumbo frames (up to 9 kB) (only for BCM5721 and BCM5751)'

 --
 sergio.


Привет!

Пошукал в доках: http://www.broadcom.com/collateral/pg/57XX-PG105-R.pdf
Таблица сравнения чипов на странице 67.
Jumbo frame support (for BCM5751): none

С уважением,
Дмитрий

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

2010-10-16 Пенетрантность Yves-Alexis Perez

В Sun, 17 Oct 2010 09:10:25 +0400
Н. Артём artio...@yandex.ru пишет:
(Пока разворачивается debootstrap, вклинюсь в ваш чатик. :))
Скорее не опыт, а трезвый расчёт: сколько места на дисках и
процессорного времени понадобится для сборки ещё под несколько
архитектур (i486, i586, pentium II, III, iV core, atom, i3-i7, ну и
пачка от AMD).
Это понятно. Но для себя-то..? Хотя, видимо, не стоит.

Так ктож мешает? Разворачиваете дебиановскую систему сборки buildd :)
Или допиливаете apt-build.

Всё равно это требует места, настройки и сопровождения.

Для оптимизаторов есть потомки Debian -- для музыки, медицины, науки и
т.д. Там нужные пакеты доработаны и пересобраны так, что действительно
ощутим результат.
За счёт чего? Именно специфичные для задач пакеты?

Угу. Например, http://www.64studio.com/

--
Best Regards,
Yuri Kozlov

evolution 2.30.3-3: Please update debconf PO translation for the package evolution

Hi,

You are noted as the last translator of the debconf translation for
evolution. The English template has been changed, and now some messages
are marked fuzzy in your translation or are missing.
I would be grateful if you could take the time and update it.
Please send the updated file to
pkg-evolution-maintain...@lists.alioth.debian.org, or submit it as a wishlist
bug against evolution.

The deadline for receiving the updated translation is
Wed, 20 Oct 2010 12:28:28 +0200.

Thanks in advance,

# translation of ru.po to Russian
# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the PACKAGE package.
#
# Yuri Kozlov yu...@komyakino.ru, 2009.
msgid
msgstr
Project-Id-Version: evolution 2.26.1.1-2\n
Report-Msgid-Bugs-To: evolut...@packages.debian.org\n
POT-Creation-Date: 2010-10-14 23:07+0200\n
PO-Revision-Date: 2009-05-10 10:38+0400\n
Last-Translator: Yuri Kozlov yu...@komyakino.ru\n
Language-Team: Russian debian-l10n-russian@lists.debian.org\n
Language: ru\n
MIME-Version: 1.0\n
Content-Type: text/plain; charset=UTF-8\n
Content-Transfer-Encoding: 8bit\n
X-Generator: KBabel 1.11.4\n
Plural-Forms: nplurals=3; plural=(n%10==1 n%100!=11 ? 0 : n%10=2 n
%10=4 (n%10010 || n%100=20) ? 1 : 2);\n

#. Type: error
#. Description
#: ../evolution.templates:1001
msgid Running instances of Evolution detected
msgstr Обнаружены работающие экземпляры Evolution

#. Type: error
#. Description
#: ../evolution.templates:1001
msgid
You are currently upgrading Evolution to a version with an incompatible
index format. However, it has been detected that Evolution is currently
running. Upgrading it before shutting it down could lead to crashes or to
serious data loss in some cases.
msgstr
В данный момент выполняется обновление Evolution до версии, которая имеет
несовместимый с предыдущими версиями формат индексов. Однако, обнаружено,
что в системе есть работающий Evolution. Если его не остановить, то
обновление приведёт к его падению или даже потере данных.

#. Type: error
#. Description
#: ../evolution.templates:1001
msgid
You need to shut down all running instances of Evolution using the
\evolution --force-shutdown\ command before the upgrade can proceed.
msgstr
Перед тем как процесс обновления сможет продолжиться вам нужно остановить
все запущенные экземпляры Evolution выполнив команду \evolution --force-
shutdown\.

#. Type: error
#. Description
#: ../evolution.templates:1001
msgid
If this command isn't sufficient, you might want to leave all desktop
environments before upgrading.
msgstr

#. Type: select
#. Description
#: ../evolution.templates:2001
msgid Evolution processes still present on the system.
msgstr

#. Type: select
#. Description
#: ../evolution.templates:2001
msgid
Evolution processes are still present on this system, preventing a safe
upgrade.
msgstr

#. Type: select
#. Description
#: ../evolution.templates:2001
msgid
You can decide to abort the upgrade to solve the situation, let the upgrader
kill the processes itself and proceed with the upgrade.
msgstr

[BTS#600353] po-debconf://evolution/ru.po

Hello.

-- 
Best Regards,
Yuri Kozlov


-- 
To UNSUBSCRIBE, email to debian-l10n-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101016173940.1ffb0...@keeper.home.local

Re: