https://opennet.me/openforum/vsluhforumID9/7063.html Добрый день уважаемые!<br>Вопрос к сожалению не по моему профилю поэтому хотелось бы услышать мнение сообщества<br><br>Основной целью поднятия данной темы является повышение производительности системы в целом в применении к архитектуре х86-64 в исполнении интел - процессоров.<br>Отсюда попытка оптимизации не только за счет правильной настройки ядра, стека tcp, но и за счет компилятора родного для данной платформы.<br><br><br>Есть ли среди вас кто пробовал воспользоваться сабжем(Intel&#174; C++ Compiler 10 - for Linux) заменив им стандартную gcc на Unix-like системах.<br><br>насколько это оправдано и как отразиться на дальнейшей компиляции ядра, программ и так далее .<br><br>просьба комментировать по теме, а не разводить абстрактные волны. <br>Спасибо за внимание.<br><br><br><br> <br> https://opennet.me/openforum/vsluhforumID9/7063.html#5 Sun, 06 Jan 2008 13:00:06 GMT &gt;[оверквотинг удален]<br>&gt;<br>&gt;Да..., так как мат. ожидание дискретных величин = 1, <br>&gt;то результаты тестов будут = мат. ожиданию самих величин, <br>&gt;т.е. тупо среднее арифметическому. <br>&gt;<br>&gt;Cобственно, и надо определить величину дисперсии (т.е. поле отклонений). <br>&gt;Чем меньше, тем ты больше прав. :) <br>&gt;<br>&gt;<br>&gt;В общем долго это.... А так, на глазок, не заметно. <br><br>Тему закрыли Всем спасибо !!!<br> https://opennet.me/openforum/vsluhforumID9/7063.html#4 Wed, 02 Jan 2008 14:40:48 GMT &gt;Бенчмарки будут одинаково разные. (говоря на мат. языке, с какой-то пост. дисперсией). <br><br>Да..., так как мат. ожидание дискретных величин = 1, <br>то результаты тестов будут = мат. ожиданию самих величин, <br>т.е. тупо среднее арифметическому.<br><br>Cобственно, и надо определить величину дисперсии (т.е. поле отклонений). <br>Чем меньше, тем ты больше прав. :)<br><br><br>В общем долго это.... А так, на глазок, не заметно.<br><br> https://opennet.me/openforum/vsluhforumID9/7063.html#3 Wed, 02 Jan 2008 14:18:59 GMT &gt; компиля ядро именно под свою систему мы не абстрактно повышаем производительность, а <br>&gt; добиваемся известного результата за счет удаления лишних/несоответствующих модулей и...в <br>&gt; итоге компилируя ядро. <br><br> А доказать сможешь? <br><br>Подсказака: метод тупого выключения лишнего не прокатит. <br>Бенчмарки будут одинаково разные. (говоря на мат. языке, с какой-то пост. дисперсией).<br><br>P.S. Скорость загрузки не считается.<br> https://opennet.me/openforum/vsluhforumID9/7063.html#2 Sun, 23 Dec 2007 18:18:04 GMT to jd: and ALL <br><br><br>&gt;<br>&gt;Нужно смотреть узкие места, задачи и тогда уже выбирать стратегию. Иначе <br>&gt;может оказаться, что, к примеру, что в системе недостаточно оперативной памяти <br>&gt;для кэширования I/O и сколь быстро не работал бы код, всё <br>&gt;упрётся в это самое I/O и "работать быстрее" система не будет. <br>&gt;<br><br>Думаеться мне, что все сколько нибудь опытные администраторы, к которым причисляю и себя заметят такую вешь как нехватка ресурсов в системе.<br><br>&gt;<br>&gt;Но в любом случае, говорить о повышении производительности абстрактно не имеет смысла. <br>&gt;<br><br>И все таки не соглашусь по поводу абстрактности - к примеру компиля ядро именно под свою систему мы не абстрактно повышаем производительность, а добиваемся известного результата за счет удаления лишних/несоответствующих модулей и...в итоге компилируя ядро. то есть мне было интересно насколько можно повысить производительность системы именно за счет более полноценного использования внутренних функций процессора родным компилятором от производителя и соответственно ко https://opennet.me/openforum/vsluhforumID9/7063.html#1 Sun, 23 Dec 2007 17:17:15 GMT В своё время, мы с помощью icc решили проблему нехватки производительности в одном драйвере (собственном). Платформа была IA-32, ядро - 2.4.x. Компиляли им только тот кусок, который выполнялся регулярно и отжирал всё процессорное время. Получили ускорение процентов в 50, чего вполне хватило в нашем случае (не хватало где-то 10-20). Компилировать всё ядро интеловским компилятором не пробовали, да и не факт, что это возможно (надо смотреть документацию). Некоторые пакеты точно нельзя им собрать. В частности, по-моему, glibc.<br><br>Но в любом случае, говорить о повышении производительности абстрактно не имеет смысла. Нужно смотреть узкие места, задачи и тогда уже выбирать стратегию. Иначе может оказаться, что, к примеру, что в системе недостаточно оперативной памяти для кэширования I/O и сколь быстро не работал бы код, всё упрётся в это самое I/O и "работать быстрее" система не будет.<br><br>Кстати, как использовать аналогично приведённому выше примеру, интеловский компилятор с ядрами 2.6.x - я не знаю. Сейчас та пробл