Re: Скорость
> > > Добрый день. Я хотел бы узнать, в чем причина больших задержек в
> > > выпуске обновленных пакетов KDE? Я знаю много людей, которые
> > > используют debian как рабочую систему, и для них Gnome и KDE очень
> > > важны (про гном не могу ни чего сказать, т.к. не использую). К
> > > этому же относится и KDevelop. Не могли бы вы как-то ускорить
> > > процесс сборки? Пожалуйста. :-)
> >
> > Please go and learn how Debian organization works :).
> > If you are ready to help, please start with reading Debian Policy and
> > Maintainer's Guide.
> > If not, please be patient :).
>
> I want to help. But can't make acceptable .deb package.
Ну почему же?
Почитайте документацию, возьмите имеющееся за образцы ... :)
Кстати мне вообще не очень понятно о чём речь. В sarge - KDE 3.2.3, в sid -
3.3.0 (и частично уже 3.3.1)
>
> > > И еще один маленький вопросик. В чем причина сборки под i386. Лично
> > > я не представляю себе машины с процом 386 и соотв. кол. памяти, на
> > > которой запустится скажем KDE 3.3. Нет, наверняка запустится...
> > > через часа 1,5 и достаточном объеме подкачки ;-) Нельзя ли собирать
> > > хотябы для 586/686?
> >
> > This was talked about zillion of times.
> > Optimizing for 586/686 won't give you any measurable speed gain in 99%
> > of software. And the for the rest 1% Debian does provide optimized
> > versions.
>
> I think you are wrong. I made (for test) kde3.2 for athlon. Gain 10%-15%
> of speed (approximately).
И как же это измерялось? :)
Да - надеюсь при тестировании i386 deb-ов пакет libc6-i686 стоял?
Поменьше эмоций, побольше фактов (C) :)
> In any way i386 - too rare used processor to
> compile for. I'm wrong? I do not seen this processor for many years,
> so... I think it's good to do i586.
Есть работающая инфраструктура для сборки пакетов, используемая для сборки
всех пакетов. Не думаю, что кто-либо станет её менять, не имея на то
веских оснований.
Кстати одно такое основание сравнительно недавно случилось. Было выяснено,
что при сборке libstdc++ на i386 из-за недоступности атомарных машинных
команд вроде cmpxchg и необходимости их эмуляции через mutex-ы имеет место
*реальная* потеря производительности. В результате было принято решение
делать сборку для 486, а в дебиановские ядра добавить код, эмулирующий при
необходимости недостающие инструкции на "настоящих 386" (которые кстати
реально сегодня используются много где). Но название архитектуры в архиве
при этом остаётся i386 - оно много где прошито, и вносить в систему
нестабильности, меняя его, совершенно незачем.
Что же касается сборки не под 486, а под старшие x86, то тема поднималась в
debian-devel миллион раз, и конкретных результатов измерений, позволяющих
утверждать о каком-то реальном припосте производительности от этого, так и
не было.
Оптимизация под процессор может быть важна для конкретных пакетов. Но так у
нас есть kernel-image-*-686-*, libc6-i686, пакеты openssl содержат
несколько so-шек, собранных под разные архитектуры, и т.п.
Если же вы имеете в виду 64-битные процессоры AMD, то для них есть
64-битная сборка :).
Reply to: