>1) Интересно было бы поглядеть на результаты _нормальных_ тестов --
>Linpack, FFT, etc. 

В смысле сравнить Linpack в разных дистрибутивах  ;) ? 

Думаю что результат будет предсказуем (если сам Linpack не трогать)

2green (*) (2003-08-04 15:06:35.15436): "-march=pentium3 -pipe -O3".
А остальное где? Всякие там "-s"... Я уж молчу про align'ы все? И почему оптимизация, всё же, не под PIV? Да и, кстати, могли бы SSE включить - чтобы уж точно убедиться в уго (не)эффективности.

В общем, от профессионалов я ожидал несколько более тщательного и более разумного подхода к задаче...

Покажите мне патч который добавляет хотябы
10% к общей производительности системы :)
Ну ладно 10% не надо давайте 5% ...

Патчи это чаще всего добавляют специфичные фичи
чтобы повысить защищённость или время отклика системы
но чтобы они обьёктивно повышали производительность :)
ой сомнительно мне это.

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

Раз ничего другого не указано, значит все остальное - по умолчанию (в смысле как там компилятор надумает) ;) А оптимизация не под P4 потому чот их комментарий в самом конце подразумевает что эти целероны которые они использовали - не P4-based. (у них там в todo - заюзать P4 hardware)

Собственно проведи свои тесты и докажи что пиплы были не правы, тут же апологеты генту споют тебе бравурную песнь и сложат о тебе балладу ;)

А что такое "общая производительность системы"? Сколько платишь за такой патч? ;)

Все, эра Генту закатилась... Генту на свалку!!

2green
>А что такое "общая производительность системы"? Сколько платишь >за такой патч? ;)
Не ... это общее число обработанных событий в системе деленное на uptime - измеряется исключительно в попугаях ;))  

2green:
Общая ... как бы так что быть пообьективнее
например чтоб бенчмарк mplayer больше показал на эти самые проценты :)
и мозилка компилиась на эти же проценты примерно быстрее :)
и mysql тож в ту ж сторону зашевелился .....

Ну если эти три теста для тебя репрезентативная выборка, то такой патч сделать относительно легко, правда другие ворклоады от этого здорово пострадают ;)

2green:
Ну вроде ж не дети уже :)
я постарался прикинуть примерно как раз такие вещи 
которые узконаправленным патчем не подогнать :)
как раз и имелось в виду что ничего не должно пострадать...

Celeron 2 GHz Processor

А разве бывают _не_ P4 based целероны на 2GHz? туалатины имхо на таких частотах не выпускались. AFAIK 2GHz целероны тольно на ядре P4 делаются. Кстати хз, что это за SIS чипсет, надо было убедится что во всех дистрах включилось dma на IDE перед измерениями, а то, если под Gentoo в их стандартном ядре поддержка этого sis чипсета не поставилась, то результаты вполне логичны.

Сорри, проглядел эту фразу - "hdparm was needed to get dma on the ide running, despite it being in the kernel", то есть проблемы с IDE DMA у них были, не уверен что они их правильно решили. hdparm -c1 интересно сделали? В мандраке это небось по дефолту стоит. "but "xfree --configure" worked for Bill using the stock SIS driver." Вот тоже не уверен что этот драйвер хорошо работал. Не знаю почему, но у меня предубеждение к SIS-у. Проверили бы они лучше на более нормальном железе.

а как же слака?

Ну я тоже думал что такие целероны P4-based, однако комментарий в конце текста намекает что авторы по какой-то страннйо причине уверены что это не p4

Debian собранный Гарри (Garry Buckle) компиллирует ядро быстрее Gentoo собранного Биллом (Bill Kenworthy). Вася как-то на BMW доехал из Тушино в Гольяново быстрее, чем Маша на мерседесе. Значит ли это, что БМВ лучше и Маше пора нести свой мерседес на свалку? Играют ли роль только технические параметры или еще искусство вождения? И загруженность улиц? И ехал ли Вася на стандартном БМВ (кстати, каком?) или поставил форсированный движок? В случае с Debian все ясно - ядро (движок) они собирали сами. Правда умалчивают с какой оптимизацией. И не говорят указали ли тип процессора 386 чтобы было поближе к родному Debian.

2ananymous (*) (2003-08-04 17:08:05.45488)

нормально... я про ник.

Я тут провел тесты... Кароче, слака отымела всех! И сорс-бэйзд,
и бинари-онли. Ва все дырачки!

> Я тут провел тесты... Кароче, слака отымела всех! И сорс-бэйзд, и бинари-онли. Ва все дырачки!

Это как в анекдоте - Грузины лучше чем армяне. - Чем лучше? - Чем армяне :)

Что, где, зачем, почему и куда в студию плз

> Что, где, зачем, почему и куда в студию плз В какую студию? Он просто нагло гонит про тесты, верить таким нельзя. И вообще, _таких_ надо в больницу класть. С диагнозом слакваризм левого полушария.

разговоры про MPICH....

> Слушай, а с тобой можно поподробнее про MPICH побеседовать?

Я сам [сравнительно] недавно начал осваивать MPICH, хочу заставить
GiNaC с ним дружить...

> К тому же, действительно, есть огромная куча примеров, когда код с
> оптимизацией на i386 работает чуть ли не в 2 раза быстрее, чем тот же
> код от P/PII/PIII/PIV...

Это как-то странно... Можно поподробнее -- что собирали, чем, как
проверяли производительность...

> Скажем, конкретный пример - использование MMX/SSE/SSE2 команд.
> Зачастую тот же код реализовать без использования этих команд
> получается быстрее.

Сомневаюсь я однако, что, скажем, перемножение матриц или FFT
будет быстрее БЕЗ mmx/3dnow!

Debian, безусловно, круче всякого Gentoo. Это было ясно с самого начала.
PS. А слаку даже тесить не стали. И так все ясно.

Некорректный какой-то вывод в статье.
У меня rh. Когда я собираю из _редхатовских_ сорцов XFree и kde,
по сравнению с тем, что идет по умолчанию я получаю полную загрузку
kde за 10 секунд вместо 16, если бы я ставил сразу rpm.
Загрузка проца в спокойном режим идет 0-2% вместо 3-4%.

Вполне возможно, что gentoo патчат хуже. Правильнее было бы сказать,
что gentoo не быстрее, чем mdk, хотя и собран из сорцов.

А для проверки оптимизации было бы правильно собирать один и тот же
gentoo под разные процы и пускать в них для проверки что-нить.

Подписаться забыл :)

А легко! Я как-то прогу накатал на всеми любимом Turbo Pascal 7.0. То там такая фича получилась!!! Просто атас! Если компилировать с использованием аппаратного х87, то прога работала медленне чем с эмуляцией х87. Причем, прога чисто числодробилка с плавающей точкой. Думать надо когда юзать эти MMX/3Dnow!

Сравнивать генту с генту - эта ж некайфово, типа никому ниче не доказать. А тут значится выставили другие дистрибутивы чтобы продемонстрировать все преимущества... Однако неожиданно преимуществ неоказалось.

А то что оптимизация вообще говоря влияет - это и так очевидно было. ;)

Я тестов не проводил, но долго сидел на мандрейке (8.2-9.1),
потом поставил 9 слаку и просто ох.ел. По субъективным
ощущениям все работает кораздо шустрее (от загрузки, до запуска Х
и мозиллы).
Сам долго этим фактам удивлялся, так как мандркей скомпилен под
i586, а слака под i386, но теперь забил на все это, и просто
ху.ю от щастья :))

ЗЫ не хотил постить, чтоб флейм не провоцировать, но и молчать не мог...

2Dselect (*) (2003-08-04 19:42:57.614735):
А я совсем-совсем недавно... :-)
В общем, у меня сегодня MPICH откомпилировался без error'ов, а когда пытаюсь сделать make testing - оно чего-то компилирует, а потом само к себе через rsh ломится (пока что я мучаю одну машину). И возмущается, что что-то ему там недоступно (ещё бы оно доступно было, раз на машине даже inetd не запущен... ;-) ). В общем, научи чего делать, а? :-) А если кинешь доступное HOW-TO (можно и на аглицком), то буду совсем-совсем счастлив! :-)

А про команды MMX/SSE/SSE2... Хм... Даже не учитывая самих команд по себе, поинтересуйся, сколько времени уходит у системы на то, чтобы переключиться с FPU на MMX/SSE/SSE2. (я думаю, ты в курсе, что работать одновременно эти блоки не могут). Далее, сюда же приплюсуй время перемножения матрицы, а затем - время обратного переключения на FPU. Вот и получится, что стоит действительно хорошо подумать, прежде чем совать MMX/SSE/SSE2 в программу... Другой вопрос, если у тебя программа считает ТОЛЬКО на MMX/SSE/SSE2, не используя FPU (соответственно, и время на переключения тратить не придется) - тогда оно будет выгоднее.

rsh - несекурно

by R00T А про команды MMX/SSE/SSE2... Хм... Даже не учитывая самих команд по себе, поинтересуйся, сколько времени уходит у системы на то, чтобы переключиться с FPU на MMX/SSE/SSE2. (я думаю, ты в курсе, что работать одновременно эти блоки не могут). Далее, сюда же приплюсуй время перемножения матрицы, а затем - время обратного переключения на FPU. Вот и получится, что стоит действительно хорошо подумать, прежде чем совать MMX/SSE/SSE2 в программу... Другой вопрос, если у тебя программа считает ТОЛЬКО на MMX/SSE/SSE2, не используя FPU (соответственно, и время на переключения тратить не придется) - тогда оно будет выгоднее.

R00T, извини, конечно, но по-моему ты гонишь. SSE/SSE2 тем и крут, что использует свои 128-ми битные регистры (8 штук) и context switching ему по барабану. А ещё есть и data prefetch и cacheing. В AMD Athlon AFAIK даже MMX с 3DNOW можно юзать без потери тактов на switching, т.к. тоже отсутствует необходимость переключения контекста (насчёт наличия prefetch не уверен).

Прочитано в IA-32 Intel Architecture Optimization и AMD x86 Code Optimization Guide.

cya

Пардон, забыл сказать, что имея в своём распоряжении SSE/SSE2 использование FPU просто теряет всякий смысл.

cya

я тоже здесь отмечусь:

по счёту :) т.е. субъективно разницы между Генту (заточенной как они рекоммендуют) и Слакой (слаковский кернел также перекомпилен как и Гентувский) я на своей машинке не вижу (в пределах ошибки <10%): пользуюсь и тем и тем. И бут одинаков в секундах (опять же в пределахз разброса ошибки) и тяжёлые IDE типа netbeans (и там и там - по 23-25 сек) - на пне 1.4

Мандрейк и редхат были субъективно медленнее но во-первых - не успел заточить - снёс, а во-вторых - куча сервисов по-умолчанию там: если посидеть и почистить всё убрав - может быть и получилось бы как у слаки/генту - не пробовал.

Короче - все дистры хороши - если ими заниматься (а вот на чём ты тратишь время, что конкретно - это разное). У Генту - на сборку (но потом - порты всё сделают), у шапки - на чистку и на исправления когда возникают проблемы с rpm (если nodeps - теряем смысл rpm как-бы) у слаки ... ничего не теряем (ладно, я пошутил - не флейма ради:)

Anode

Я так понял вопрос "кто круче?" до сих пор остался открытым.

Про переключение контекста это совершенно верно. Странно, что кто-то еще не знает, что регистры FPU использовались для SIMD только на самых первых Pentium'ах. А про то, что fpu никому не нужен, это Вы, батенька, зря. Попробуйте seti@home или любое другое приложение где точность нужна на SSE 1/2 реализовать... Не получится, к сожалению.

Мляяяяяя.............................. ЛОР првращается в базар (( По моему это глупо разводить подобного рода флейм Вот у меня стоит gentoo больше года и я не верю что если поставлю mandrake-redhat-debian оно будет быстрее чем мой gentoo, и вообще мля дело не в быстроте, вот-так то господа! И что бы не порождать лишнего потока ничестот я ничего против не имею против перечисленых выше дистров!

Всё млин высказался!

Ну вообще, как правило, перекомпиляция софта действительно даёт прирост на уровне невидимого (за исключением некоторых случаев). По поводу этого теста мне кажется, что он был бы более наглядным если использовался П3 вместо П4. Так или иначе gcc не может ещё в полной мере создавать код с поддержкой SSE2. Хотя, безусловно, формально такая поддержка существует, но всем известно что intel`овский компилятор в этом отношении всё-же лучше, но это уже отдельная тема. А вообще конечно как лично мне было понятно и ранее, смысла в использовании source-based дистрибутивов практически нет. Пользователям считающим, что такой дистрибутив как gentoo позволяет максимально настроить всё установленное ПО осмелюсь возразить. Во-первых в том же Debian есть такая вещь как apt-build позволяющая компилировать целый ветки ПО строящиеся из зависимостей и предпочтений исходных пакетов. Плюс штатные возможности сборки бинарных пакетов из исходных. Хотя очевидно, что gentoo в этом направлении более развит, но сугубо по моему мнению, это не должно быть самоцелью никакого дистрибутива. Ну во-первых потому что как уже было замечено скорости это не придаст. Я всё же считаю, что gentoo это крайность.

>Параметры оптимизации - фигня. Все дело в том что ов обычных >дистрибутиводелающих конторах обычно есть люди которые ДУМАЮТ как >сделать систему быстрее концептуально. Видимо в gentoo таких людей нет ^^^^^^^^^^^^^^^^^^^^^^ >и там надеются на "а вот мы щас как все пересоберем и оно все кааак >полетит!" ;)

>green (*) (2003-08-04 11:42:24.368989)

Ипать калатить, за убийство этого ЗЕЛЕНОГО ЧЕЛОВЕЧКА мне не жалко лишь одного патрона!!!!! Обидна ((

Грустно господа !

Re: Mandrake 9.1 из коробки

пророчествую что слово "слака" было сказано зря ....

ezhikov (*) (2003-08-04 13:52:14.429781)

LOL =8-)))))

Drolyk

А вроде как комунити считается а за свой дистр(кучку скомпиленых прог по суещству поубивать готовы). ФпирЁт.

SCOтина

Красноглазики! вам пиэдец! SCOтина

В Мандраке 9.1 пересобрал ядро с MARCH=Athlon , после чего оно стало меньше весить в полтора раза. Ну и что? Нифига не заметил прироста нигде. Траблов не видел, глючности тоже, даже и из коробки. Нахер орём "... - отстой, ... - рулез"? Юзай то, что больше нравится, а пытаться обосрать человека на форуме - удел ибланов. Говорю в который раз - не кричите громких слов в адрес собеседников, в реале вы, ругающиеся, - прыщавые лошки 40 кг весом и многих тех, на кого катите просто обходите стороной. Уважайте друг друга, спорьте за своё мнение и пытайтесь отстоять его, но БЕЗ ОБСИРАЛОВА.

Насчёт этого могу сказать одно, в своё время пробовал на P233MMX с 64М ОЗУ два дистра с целью выбора наиболее подходящего для этой тачки, испытывал ALTLinux Junior 2.0 и ASPLinux (не помню какой тогда был, короче оба дистра самые новые на тот момент). В результате был сделан вывод о том, что ASP просто на той машине не может нормально работать, а в Junior можно было даже фильмы смотреть ксином. Из-за чего такая разница точно сказать не могу, возможно .i586.rpm в Junior, но до сих пор замечаю более высокую скорость ALT дистрибов в исходных конфигурациях

Интересно, и чем же они ее так концептуально увеличивают

by anonymous (*) (2003-08-05 01:19:38.393145)
А про то, что fpu никому не нужен, это Вы, батенька, зря. Попробуйте seti@home или любое другое приложение где точность нужна на SSE 1/2 реализовать... Не получится, к сожалению.

Погорячился я, конечно, насчёт тотального изничтожения FPU, но всё-таки для большинства приложений можно легко закрыть глаза на некоторую неточность SSE/SSE2 (максимум вроде double) и пользоваться всеми преимуществами SIMD.

cya

разговоры про MPICH....часть 2

> В общем, у меня сегодня MPICH откомпилировался без error'ов, а
> когда пытаюсь сделать make testing - оно чего-то компилирует, а потом
> само к себе через rsh ломится (пока что я мучаю одну машину).

Да вроде бы оно все с полпинка заводится:

ssh-keygen -t dsa -f ~/.ssh/myself_dsa
[snipped]
ssh-add ~/.ssh/myself_dsa
ln -s /where/is/ssh /somewhere/else/rsh

apt-build mpich
sudo apt-get install mpich

В документации сказано, что требуется rsh с беспарольным доступом.
Но на самом деле все работает и с ssh, если настроить "беспарольный"
доступ, например, с помощью ssh-keys. Соответственно,
если машина одна, то надо уметь ходить по ssh на localhost.
( Это если не охота "настоящий" rsh ставить. )
В реальных условиях использование ssh в кластере -- СЛИШКОМ
большой overhead.


> А про команды MMX/SSE/SSE2

Давайте отделим мух от котлет. AFAIK, MMX -- это набор регистров
и инструкций для _целочисленной_ арифметики

SIMD (Single Instruction stream, Multiple Data stream) Within A Register
(SWAR) isn't a new idea. Given a machine with k-bit registers, data paths,
and function units, it has long been known that ordinary register operations
can function as SIMD parallel operations on n, k/n-bit, integer field values.
However, it is only with the recent push for multimedia that the 2x to 8x
speedup offered by SWAR techniques has become a concern for
mainstream computing.

( см., например http://www.europe.redhat.com/documentation/HOWTO/Parallel-Processing-HOWTO-4.... )

А SSE -- это просто наличие нескольких конвейеров, выполняющих
различные ( в т.ч. и FP ) операции.

Так что ( если я правильно понимаю ), то

1) MMX и FPU делают совершенно разные вещи и друг другу не мешают. Более того, если я считаю _аналитически_, то FPU
практически не испольуется.

2) А зачем надо переключаться с SSE на FPU?

> Далее, сюда же приплюсуй время перемножения матрицы, а затем -
> время обратного переключения на FPU.

Да никто никуда не переключается...

про double...

> можно легко закрыть глаза на некоторую неточность SSE/SSE2 (максимум вроде double)

Можно легко закрыть глаза на SSE, если требуются вычисления
с гарантированной точностью...

2Dselect (*) (2003-08-05 11:28:02.945013):
Черт с ними, с регистрами...

Ты мне объясни, как по rsh ходить без пароля? :-)

2 Dselect: ya tebe skolko raz govoril, po4itai
umnye knijki pro vychisleniya na compe - est' spec.
metodiki, kak pravilno summurovat', umnojat', delit',........
- to est' mojno normalno kontrolirovat' tochnost'
vychislenij, tebe togda hvatit sushestvuyushih tipov
peremennyh.
Kone4no, kogda programit' budesh, pridetysa podumat',
zato vyigrysh po skorosti ocheviden. Ya kone4no ponimayu,
chto ochen' kruto pisat' na Ginac i kogda zadacha krutitsya
nedelyami (solidno, blin - che-to vajnoe s4itaetsya), no
vse-taki inogda lu4she podumat', a ne proshibat' golovoi
stenu.

P.S. sorry za naezdy (pishu ne fleima radi) i za translit (normalnoi
russkoi locali seichas netu :( )

about calculations....

2 ivon:

> ya tebe skolko raz govoril, po4itai
> umnye knijki pro vychisleniya na compe - est' spec.
> metodiki, kak pravilno summurovat', umnojat', delit'

That's methods of *approximate* calculations...
And I need _exact_ analytic result. The answer like
"pole mass is gauge invariant up to n digits" is idiotic.
Period.

> Ya kone4no ponimayu, chto ochen' kruto pisat' na
> Ginac i kogda zadacha krutitsya nedelyami
> (solidno, blin - che-to vajnoe s4itaetsya)

That's not true. GiNaC is not a silver bullet, but it's better
than nothing...

> P.S. sorry za naezdy (pishu ne fleima radi) i za translit (normalnoi
> russkoi locali seichas netu :( )

No Russian locale in CERN... Nothing magic about it...