Добрый день уважаемые!
Вопрос к сожалению не по моему профилю поэтому хотелось бы услышать мнение сообществаОсновной целью поднятия данной темы является повышение производительности системы в целом в применении к архитектуре х86-64 в исполнении интел - процессоров.
Отсюда попытка оптимизации не только за счет правильной настройки ядра, стека tcp, но и за счет компилятора родного для данной платформы.
Есть ли среди вас кто пробовал воспользоваться сабжем(Intel® C++ Compiler 10 - for Linux) заменив им стандартную gcc на Unix-like системах.насколько это оправдано и как отразиться на дальнейшей компиляции ядра, программ и так далее .
просьба комментировать по теме, а не разводить абстрактные волны.
Спасибо за внимание.
В своё время, мы с помощью icc решили проблему нехватки производительности в одном драйвере (собственном). Платформа была IA-32, ядро - 2.4.x. Компиляли им только тот кусок, который выполнялся регулярно и отжирал всё процессорное время. Получили ускорение процентов в 50, чего вполне хватило в нашем случае (не хватало где-то 10-20). Компилировать всё ядро интеловским компилятором не пробовали, да и не факт, что это возможно (надо смотреть документацию). Некоторые пакеты точно нельзя им собрать. В частности, по-моему, glibc.Но в любом случае, говорить о повышении производительности абстрактно не имеет смысла. Нужно смотреть узкие места, задачи и тогда уже выбирать стратегию. Иначе может оказаться, что, к примеру, что в системе недостаточно оперативной памяти для кэширования I/O и сколь быстро не работал бы код, всё упрётся в это самое I/O и "работать быстрее" система не будет.
Кстати, как использовать аналогично приведённому выше примеру, интеловский компилятор с ядрами 2.6.x - я не знаю. Сейчас та проблема так остро не стоит, но узнать было бы любопытно, так что если кто-то случайно выяснит - свисните, пожалуйста.
to jd: and ALL
>
>Нужно смотреть узкие места, задачи и тогда уже выбирать стратегию. Иначе
>может оказаться, что, к примеру, что в системе недостаточно оперативной памяти
>для кэширования I/O и сколь быстро не работал бы код, всё
>упрётся в это самое I/O и "работать быстрее" система не будет.
>Думаеться мне, что все сколько нибудь опытные администраторы, к которым причисляю и себя заметят такую вешь как нехватка ресурсов в системе.
>
>Но в любом случае, говорить о повышении производительности абстрактно не имеет смысла.
>И все таки не соглашусь по поводу абстрактности - к примеру компиля ядро именно под свою систему мы не абстрактно повышаем производительность, а добиваемся известного результата за счет удаления лишних/несоответствующих модулей и...в итоге компилируя ядро. то есть мне было интересно насколько можно повысить производительность системы именно за счет более полноценного использования внутренних функций процессора родным компилятором от производителя и соответственно кодом своего ядра.
> компиля ядро именно под свою систему мы не абстрактно повышаем производительность, а
> добиваемся известного результата за счет удаления лишних/несоответствующих модулей и...в
> итоге компилируя ядро.А доказать сможешь?
Подсказака: метод тупого выключения лишнего не прокатит.
Бенчмарки будут одинаково разные. (говоря на мат. языке, с какой-то пост. дисперсией).P.S. Скорость загрузки не считается.
>Бенчмарки будут одинаково разные. (говоря на мат. языке, с какой-то пост. дисперсией).Да..., так как мат. ожидание дискретных величин = 1,
то результаты тестов будут = мат. ожиданию самих величин,
т.е. тупо среднее арифметическому.Cобственно, и надо определить величину дисперсии (т.е. поле отклонений).
Чем меньше, тем ты больше прав. :)
В общем долго это.... А так, на глазок, не заметно.
>[оверквотинг удален]
>
>Да..., так как мат. ожидание дискретных величин = 1,
>то результаты тестов будут = мат. ожиданию самих величин,
>т.е. тупо среднее арифметическому.
>
>Cобственно, и надо определить величину дисперсии (т.е. поле отклонений).
>Чем меньше, тем ты больше прав. :)
>
>
>В общем долго это.... А так, на глазок, не заметно.Тему закрыли Всем спасибо !!!