Исходное сообщение
"Использование Intel® C++ Compiler 10 - for Linux вместо..." Отправлено jd, 23-Дек-07 20:17
В своё время, мы с помощью icc решили проблему нехватки производительности в одном драйвере (собственном). Платформа была IA-32, ядро - 2.4.x. Компиляли им только тот кусок, который выполнялся регулярно и отжирал всё процессорное время. Получили ускорение процентов в 50, чего вполне хватило в нашем случае (не хватало где-то 10-20). Компилировать всё ядро интеловским компилятором не пробовали, да и не факт, что это возможно (надо смотреть документацию). Некоторые пакеты точно нельзя им собрать. В частности, по-моему, glibc. Но в любом случае, говорить о повышении производительности абстрактно не имеет смысла. Нужно смотреть узкие места, задачи и тогда уже выбирать стратегию. Иначе может оказаться, что, к примеру, что в системе недостаточно оперативной памяти для кэширования I/O и сколь быстро не работал бы код, всё упрётся в это самое I/O и "работать быстрее" система не будет. Кстати, как использовать аналогично приведённому выше примеру, интеловский компилятор с ядрами 2.6.x - я не знаю. Сейчас та проблема так остро не стоит, но узнать было бы любопытно, так что если кто-то случайно выяснит - свисните, пожалуйста.

Ваше сообщение
Имя*:
EMail:	Для отправки новых сообщений в текущей нити на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	> В своё время, мы с помощью icc решили проблему нехватки производительности в > одном драйвере (собственном). Платформа была IA-32, ядро - 2.4.x. Компиляли им > только тот кусок, который выполнялся регулярно и отжирал всё процессорное время. > Получили ускорение процентов в 50, чего вполне хватило в нашем случае > (не хватало где-то 10-20). Компилировать всё ядро интеловским компилятором не пробовали, > да и не факт, что это возможно (надо смотреть документацию). Некоторые > пакеты точно нельзя им собрать. В частности, по-моему, glibc. > Но в любом случае, говорить о повышении производительности абстрактно не имеет смысла. > Нужно смотреть узкие места, задачи и тогда уже выбирать стратегию. Иначе > может оказаться, что, к примеру, что в системе недостаточно оперативной памяти > для кэширования I/O и сколь быстро не работал бы код, всё > упрётся в это самое I/O и "работать быстрее" система не будет. > Кстати, как использовать аналогично приведённому выше примеру, интеловский компилятор > с ядрами 2.6.x - я не знаю. Сейчас та проблема так > остро не стоит, но узнать было бы любопытно, так что если > кто-то случайно выяснит - свисните, пожалуйста.
	Введите код, изображенный на картинке: