https://www.opennet.me/openforum/vsluhforumID3/92479.html Представлены (http://slashdot.org/topic/bi/speed-test-comparing-intel-c-gnu-c-and-llvm-clang-compilers/) результаты оценки производительности компиляторов Intel C++, GNU C++ (g++) и LLVM Clang. Экспериментаторы постарались подобрать реалистичные сценарии тестирования с использованием средств распараллеливания выполнения на многоядерных системах. <br><br><br><br>Лидером по скорости процесса сборки стал Clang (в режиме полной оптимизации ICC - 6.074 сек, GCC - 2.974 сек, Clang 1.752 сек). Размер бинарного файла оказался минимален у GCC и Clang (по 8329 байт, в ICC - 20331 байт). При оценке средств для параллельного программирования, тестированию Clang мешало неготовность поддержки Cilk Plus и Threading Building Blocks. Производительность параллельного приложения, использующего Threading Building Blocks, для ICC и GCC оказалась примерно на одном уровне 10.983 сек. и 10.510 сек. Параллельное приложение, написанное с использованием Cilk Plus, было выполнено при компиляции в ICC за 0:09.98, GCC - 0:11.28, Clang - 0:10.96. https://www.opennet.me/openforum/vsluhforumID3/92479.html#66 Thu, 07 Nov 2013 17:52:11 GMT &gt; а не спеши ты нас хоронить! :3 <br><br>А не спешу, дел действительно много, но скорость, увы, не исправить.<br> https://www.opennet.me/openforum/vsluhforumID3/92479.html#65 Thu, 07 Nov 2013 06:21:37 GMT &gt; Положим, со скоростью компиляции горбатого могила исправит.<br><br>а не спеши ты нас хоронить! :3<br> https://www.opennet.me/openforum/vsluhforumID3/92479.html#64 Thu, 07 Nov 2013 06:15:41 GMT Положим, со скоростью компиляции горбатого могила исправит.<br> https://www.opennet.me/openforum/vsluhforumID3/92479.html#63 Wed, 06 Nov 2013 18:59:45 GMT Прошу поклонников Шланга и GCC в целях разжигания нового холивора и тыканья пальцем, обратить внимание, что в единственном тесте, где победа осталась за Шлангом:<br><br>"Параллельное приложение, написанное с использованием Cilk Plus, было выполнено при компиляции в ICC за 9.98 сек., GCC - 11.28 сек., Clang - 10.96 сек."<br><br>Согласно оригинальной статье, пользовательское время для gcc было в полтора раза меньше, а сравнение по системному времени, учитывая что производилось массовое распараллеливание, вообще говоря некорректно, ибо сильно зависит от настроения планировщика, и раз на раз не приходится.<br> https://www.opennet.me/openforum/vsluhforumID3/92479.html#62 Wed, 06 Nov 2013 16:45:03 GMT &gt; Я бы не стал называть такой код "самомодифицирующимся", так как в JIT <br>&gt; создается новый код в отдельно замапленной области памяти, а не меняется <br>&gt; существующий.<br><br>В целом да, но есть такая категория JIT-компиляторов (pre-JIT, я бы сказал), как рекомпайлеры в эмуляторах. В таких применениях иногда действительно может модифицироваться существующая область при определенных событиях.<br> https://www.opennet.me/openforum/vsluhforumID3/92479.html#61 Wed, 06 Nov 2013 16:39:28 GMT &gt; в виде JIT<br><br>Я бы не стал называть такой код "самомодифицирующимся", так как в JIT создается новый код в отдельно замапленной области памяти, а не меняется существующий.<br> https://www.opennet.me/openforum/vsluhforumID3/92479.html#60 Wed, 06 Nov 2013 16:37:43 GMT &gt; Тот вывод, что даёт флаг -S совершенно отличается от того, что выдает <br>&gt; мне бинарник в дизассемблере или objdump -S ./elf.<br><br>Естественно, у icc там подробностей больше. Что сказать-то хотел?<br><br>&gt;В это случаи у gcc самый лучший вывод, хотя и в нем мусора хватает.<br><br>Если под "лучшим" выводом понимается отсутствие комментариев от оптимизатора, то да, лучший.<br> https://www.opennet.me/openforum/vsluhforumID3/92479.html#59 Wed, 06 Nov 2013 16:33:46 GMT Звучит так, как будто свопа мало просто. pypy, помнится, отличался какими-то совсем запредельными требованиями к памяти при сборке, а если еще и опциями компилятора что-то вроде LTO накрутить - он, пожалуй, гиг десять захочет. Насчет вебкита с дебагом - мыслей нет никаких.<br> https://www.opennet.me/openforum/vsluhforumID3/92479.html#58 Wed, 06 Nov 2013 11:42:00 GMT &gt; Мне кажется Intel стоит приложиться для улучшения оптимизации кода для их платформ <br>&gt; в GCC/CLang, чем дальше развивать свой компилятор <br><br>А кто такой slashdot.org новый друг похороникса ? И почему новый друг похороникса забыл о сан студии ? Или о процах амд он тоже не в курсе ? Этакая скрытая реклама интела ?<br>