Блин, как все таки хорошо что нету альтернативного кернела. А то и тут бы все засрали 8)

как это нету?!? хурд! :)

Возьми ядро от RH - будет тебе "альтернативное" :)

"...I found out that O_DIRECT does not work correctly on 2.4 kernels
compiled with the RH gcc-3.2.2-5 on RH9. It is working fine with
kernels compiled with the RH gcc-2.96-113 on RH 7.3."

А многие сидят уже на 3.2.3

Гхм, а что даст вам ядро под Афлон-хр, если у вас glibc i386 - не так уж и сильно. А по поводу gcc 3.3.0 скажу, что glibc с ключиком -march=athlon-xp не компилятся, в отличие от 3.2.3(только не надо рассказывать, что настоящие гуру компилят ядро под Opteron, а glibc специально пересобирают под i386 - дело вкуса и скорости. >>В итоге выигрыш на приложениях - 25-30% А это уже бред сивой кобылы - ни одна оптимизация, тем более без libc такого не даст, да и с ней. Это из области научной фантастики. Запустите простенький генератор чисел от 0 до XXX... и сделайте усредненный анализ, а пока _не_ верю в десятки процентов. ======= Кстати, как показывает практика(и моя и kerneltrap'овцев - 2.5.7x быстрее 2.4.21), но зачем здесь данные , люди пришли пофлеймить... (=

> А это уже бред сивой кобылы - ни одна оптимизация, тем более без libc такого не даст, да и с ней. Это из области научной фантастики. Запустите простенький генератор чисел от 0 до XXX... и сделайте усредненный анализ, а пока _не_ верю в десятки процентов. ======= Ок . Скорее здесь проблема в том, что я не уточнил, как замералась производительность. Конкретизирую - машина работает для числодробления. Есть стандартный "джентельменский набор" в прикладной в квантовой химии. В него входит программа GAMESS ( ссылку смотрите в новости про кластеры ). Я взял код, сгенерировананный нашим админом ( ГУРУ ) под march=i686 и после усатновки gcc-3.3 собрал эту же программу, но под athlon-mp. Затем, начал прогонять тестовые задачи под эту программу( вернее такие, которые сейчас актуальны для меня ) двумя бинарниками, собранные мной и ГУРУ. После завершения задач ( а прогонялись они в одинаковых условиях - в текстовом режиме ) я взял из каждого класса задач ( как то - расчет энергии в точке, расчет градиента, оптимизация геометрии, расчет матрицы вторых производных - гессиана) отношение время_на_моем_бинарнике/время_бинарник_ГУРУ. Отношение колеблется от 0.70-0.75. Я ответил на ваш вопрос - если есть желание, могу выслать логи -) С уважением, $echo.

Просьба ко всем. У кого есть много халявного нета - киньте патч к ядру на ftp.farlep.net/incoming Просто к этому хосту можно дозвониться на шару :-) Заранее спасибо.

...

> Я взял код, сгенерировананный нашим админом ( ГУРУ ) под march=i686 и 

а почему не с march=i386 уж сразу ? :))

>после усатновки gcc-3.3 собрал эту же программу, но под athlon-mp. 

корректнее все же сравнивать march=pentiumpro и march=athlon-mp

А насчет цифр если мне склероз не изменяет между сборкой с
i686 и pentiumpro на 2.95.3  как раз примерно такую же разницу  давала моя числобробильная задачка (решение FNS)

да все libpthread.so.0 (которые действительно либы) ссылки:
ll /lib/tls/libpthread.so.0
lrwxrwxrwx 1 root root 18 Июн 16 04:06 /lib/tls/libpthread.so.0 -> libpthread-0.34.so

ll /lib/i686/libpthread.so.0
lrwxrwxrwx 1 root root 18 Июн 16 04:06 /lib/i686/libpthread.so.0 -> libpthread-0.10.so

ll /lib/libpthread.so.0
lrwxrwxrwx 1 root root 18 Июн 16 04:06 /lib/libpthread.so.0 ->
libpthread-0.10.so

удалил пакет ntpl-devel в котором была еще одна Ж-) но все равно собиарает по умолчанию с первым файлом :-(((

libpthread-0.34.so это nptl-0.34 libpthread-0.10.so linuxthreads

я так понял что у тебя проблемы когда линковка шла с /lib/tls

сиречь nptl или нет ???

ppl, никто не заметил, что на 2.4.21 по сравнению с 2.4.20 повысился расход памяти??? Есть соображения?

дык вот как насильно с ней не линковать без ее удаления. Хоть что указываешь линкеру в параметрах при сборке, все равно с ней линкует сволочь.

А у тебя LIB_PATCH LD_SEARCH_DIR и прочая мутота в энвироне часом не подняты ?

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

Покажь место - где ты лиекуешь эту самую либу.

Насчет памяти - хз. У меня сейчас даже свободная есть (КДЕ!). Я имею ввиду совсем свободная - обычно у меня ее было мало (меньше метра), остальное, метров 80 жрал кэш. Сейчас 11 метров свободной как с куста.

4chuchelo: оффтопичный вопрос - а d4x будет когда-нить https держать и не материться в консоль на битый заголовок картинки корзины (на нескольких версиях проверял) (при запуске в кде проскакивает, когда пускаешь в первый раз, а корзина включена по умолчанию)?

2sS (*) (2003-06-18 11:59:56.57795):
Чё-то я не догоняю, наверное...
-march=i686 и -mpentiumpro - это ОДНО И ТОЖЕ!!! Так даже в man'е по GCC написано.
Собственно (если смотреть по железу), i686 и PentiumPro - это процессоры одинаковой архитектуры и разница между ними лишь в том, что у PentiumPro нет блока MMX (как тут неоднократно отмечалось, ядро НЕ ИСПОЛЬЗУЕТ команды MMX). Intel (в своё время) не стала включать блок MMX в Pentium Pro именно потому, что для серверных задач в 99% случаем MMX попросту не нужен (или, скажем, не был нужен в то время).
Так что твоя оценка - субъективна.
Возможен и другой вариант: вы оба запускали свои задачи одну за одной... Потому в кеше осталась инфа от старых задач (как минимум, остался дисковый кэш в ОЗУ) и вы получили заявленные 20%... Для чистоты эксперимента попробуйте перед каждым тестом сделать перезагрузку машины. На мой взгляд, реально должна быть разница не более 5% (просто потому, что большую часть времени занимает не задача, а обмен между относительно медленной ОЗУ и ещё более медленным жестким диском). Да, ещё... "nice -n -20 {$ЗАДАЧА}" тоже использовать (ради чистоты эксперимента) не следует... ;-)

jackil: уже не матерится на битые заголовки. А https в принципе не сложно привинтить...

Интересно, в этом ядре нормально реализована поддержка PCMCIA ne2000 девайса или где? А то до сих пор на ноуте 2.4.19 приходится держать, т.к. начиная с 20 версии скорость прокачки вместо 100Мбит - 2Мбита. И проц грузит на 100%, когда полностью карту трафиком забиваешь.

Но и в 19 ядре тоже проблема - вместо 100Мбит реально только 10Мбит работает, хотя карта детектит 100Мбит сеть...

Задолбали тормоза, в общем. Кто-нить сталкивался с проблемой? Карта - D-Link 100Mbit+Modem (всё "железное")