В середине июня компания Intel представила новую, девятую версию своих компиляторов C++ и Fortran. Новую версию компиляторов нельзя назвать принципиально иной по сравнению с предыдущей версией 8.1, ее основные особенности — это интеграция компиляторов для платформ IA-32, IA-64 и EM64T (x86-64) в единый пакет, а с точки зрения оптимизации кода — дополнительные опции для процессоров с технологией Hyper-Threading и многоядерных процессоров, в частности, спекулятивной загрузки данных из памяти в отдельно создаваемом потоке (Software-based Speculative Pre-Computation, SSP).
В настоящей статье мы рассмотрим, насколько эффективна в плане скорости новая версия компиляторов по сравнению с предыдущей на топовых (или почти топовых) одноядерных процессорах — как Intel (Pentium 4 и Pentium M), так и… AMD (Athlon 64 FX-57 — разумеется, с некоторой «доработкой» кода, о чем ниже).
Использовались следующие версии компиляторов:
- Intel(R) C++ Compiler for 32-bit applications, Version 9.0 Build 20050624Z Package ID: W_CC_C_9.0.020
- Intel(R) Fortran Compiler for 32-bit applications, Version 9.0 Build 20050624Z Package ID: W_FC_C_9.0.019
В качестве «эталона сравнения» использовался код тестов, откомпилированный ранее с помощью Intel C++ Compiler 8.1.022 и Intel Fortran Compiler 8.1.025.
Во всех случаях (компиляторы версий 8.1 и 9.0, различные варианты оптимизации кода), как обычно, использовались одинаковые общие ключи компиляции кода:
PASS1_CFLAGS= -Qipo -O3 -Qprof_gen
PASS2_CFLAGS= -Qipo -O3 -Qprof_use
Pentium 4 670
Начнем с результатов «родного» для компиляторов процессора — Pentium 4 670 (частота 3.8 ГГц) с ядром Prescott, поддерживающего все необходимые наборы инструкций и позволяющего запускать код, откомпилированный со всеми возможными ключами специфических оптимизаций: -QxK, -QxW, -QxN, -QxB и -QxP.
| Без опт. | -QxK | -QxW | -QxN | -QxB | -QxP | |||||||
| ic8.1 | ic9.0 | ic8.1 | ic9.0 | ic8.1 | ic9.0 | ic8.1 | ic9.0 | ic8.1 | ic9.0 | ic8.1 | ic9.0 | |
| 164.gzip | 1150 | 1130 (-1.7%) | 1253 | 1239 (-1.1%) | 1255 | 1248 (-0.6%) | 1265 | 1251 (-1.1%) | - | 1247 | 1267 | 1241 (-2.1%) |
| 175.vpr | x | x | 1207 | 1201 (-0.5%) | 1290 | 1283 (-0.5%) | 1288 | 1272 (-1.2%) | - | 1255 | 1286 | 1270 (-1.2%) |
| 176.gcc | x | x | 2142 | 2119 (-1.1%) | 2132 | 2122 (-0.5%) | 2146 | 2125 (-1.0%) | - | 2116 | 2155 | 2116 (-1.8%) |
| 181.mcf | 1595 | 1594 (-0.1%) | 1599 | 1599 (0.0%) | 1598 | 1600 (0.1%) | 2125 | 2125 (0.0%) | - | 2113 | 2131 | 2115 (-0.8%) |
| 186.crafty | 1251 | 1260 (0.7%) | 1272 | 1285 (1.0%) | 1371 | 1398 (2.0%) | 1375 | 1406 (2.3%) | - | 1387 | 1387 | 1389 (0.1%) |
| 197.parser | 1553 | 1030 (-33.7%) | 1562 | 1031 (-34.0%) | 1562 | 1026 (-34.3%) | 1560 | 1025 (-34.3%) | - | 1019 | 1560 | 1031 (-33.9%) |
| 252.eon | 1640 | 1762 (7.4%) | 1795 | 1836 (2.3%) | 2188 | 2153 (-1.6%) | 2391 | 2360 (-1.3%) | - | 2101 | 2359 | 2320 (-1.7%) |
| 253.perlbmk | 1997 | 2021 (1.2%) | 1954 | 2015 (3.1%) | 1923 | 2012 (4.6%) | 1940 | 1991 (2.6%) | - | 2018 | 1947 | 2006 (3.0%) |
| 254.gap | 2033 | 2110 (3.8%) | 1936 | 1990 (2.8%) | 2019 | 2035 (0.8%) | 2022 | 2061 (1.9%) | - | 2029 | 2032 | 2049 (0.8%) |
| 255.vortex | 2876 | 2941 (2.3%) | 2871 | 2971 (3.5%) | 2869 | 2970 (3.5%) | 2854 | 2970 (4.1%) | - | 2852 | 2833 | 2948 (4.1%) |
| 256.bzip2 | 1423 | 1428 (0.4%) | 1390 | 1399 (0.6%) | 1378 | 1372 (-0.4%) | 1360 | 1348 (-0.9%) | - | 1354 | 1372 | 1415 (3.1%) |
| 300.twolf | 1867 | 1526 (-18.3%) | 1840 | 1880 (2.2%) | 1859 | 1898 (2.1%) | 1865 | 1910 (2.4%) | - | 1879 | 1869 | 1908 (2.1%) |
| SPECint_base2000 | 1682 | 1604 (-4.6%) | 1682 | 1642 (-2.4%) | 1734 | 1687 (-2.7%) | 1790 | 1739 (-2.8%) | - | 1708 | 1792 | 1739 (-3.0%) |
| 168.wupwise | 1882 | 1843 (-2.1%) | 2031 | 2074 (2.1%) | 2235 | 2304 (3.1%) | 2198 | 1735 (-21.1%) | - | 1762 | 2860 | 2914 (1.9%) |
| 171.swim | 2089 | 2088 (0.0%) | 2362 | 2544 (7.7%) | 2524 | 2596 (2.9%) | 2525 | 2595 (2.8%) | - | 2553 | 2526 | 2595 (2.7%) |
| 172.mgrid | 1022 | 1023 (0.1%) | 1237 | 1216 (-1.7%) | 1518 | 1511 (-0.5%) | 1674 | 1661 (-0.8%) | - | 1306 | 1675 | 1661 (-0.8%) |
| 173.applu | 1419 | 1438 (1.3%) | 1404 | 1414 (0.7%) | 1481 | 1472 (-0.6%) | 1655 | 1670 (0.9%) | - | 1555 | 1638 | 1691 (3.2%) |
| 177.mesa | 1399 | 1371 (-2.0%) | 1496 | 1476 (-1.3%) | 1666 | 1669 (0.2%) | 1662 | 1668 (0.4%) | - | 1574 | 1659 | 1653 (-0.4%) |
| 178.galgel | 1445 | 1440 (-0.3%) | 3036 | 3119 (2.7%) | 3581 | 3637 (1.6%) | 3564 | 3866 (8.5%) | - | 3626 | 3603 | 3889 (7.9%) |
| 179.art | 2716 | 2356 (-13.3%) | 2370 | 2393 (1.0%) | 2918 | 2613 (-10.5%) | 2987 | 2655 (-11.1%) | - | 2524 | 4648 | 4597 (-1.1%) |
| 183.equake | 2074 | 2105 (1.5%) | 2143 | 2118 (-1.2%) | 2155 | 2154 (0.0%) | 2158 | 2148 (-0.5%) | - | 2092 | 2156 | 2420 (12.2%) |
| 187.facerec | 1736 | 1773 (2.1%) | 2035 | 2148 (5.6%) | 2049 | 2151 (5.0%) | 2037 | 2165 (6.3%) | - | 2114 | 2075 | 2179 (5.0%) |
| 188.ammp | 1305 | 1226 (-6.1%) | 1240 | 1213 (-2.2%) | 1365 | 1345 (-1.5%) | 1371 | 1346 (-1.8%) | - | 1210 | 1369 | 1346 (-1.7%) |
| 189.lucas | 2109 | 2101 (-0.4%) | 2007 | 2025 (0.9%) | 2285 | 2320 (1.5%) | 2279 | 2331 (2.3%) | - | 1984 | 2302 | 2306 (0.2%) |
| 191.fma3d | 1316 | 1342 (2.0%) | 1291 | 1342 (4.0%) | 1600 | 1648 (3.0%) | 1581 | 1683 (6.5%) | - | 1371 | 1606 | 1646 (2.5%) |
| 200.sixtrack | 604 | 606 (0.3%) | 597 | 605 (1.3%) | 678 | 754 (11.2%) | 679 | 746 (9.9%) | - | 621 | 683 | 748 (9.5%) |
| 301.apsi | 1309 | 1277 (-2.4%) | 1317 | 1301 (-1.2%) | 1386 | 1370 (-1.2%) | 1408 | 1357 (-3.6%) | - | 1300 | 1410 | 1357 (-3.8%) |
| SPECfp_base2000 | 1511 | 1489 (-1.5%) | 1636 | 1657 (1.3%) | 1826 | 1842 (0.9%) | 1854 | 1845 (-0.5%) | - | 1690 | 1956 | 2007 (2.6%) |
Но начнем, тем не менее, с неоптимизированного варианта. Сразу отметим одну важную деталь: эта версия кода, откомпилированная как предыдущей, так и новой версией компилятора, вызывала ошибки в подтестах 175.vpr и 176.gcc — независимо от типа используемого процессора. В связи с чем, мы использовали --noreportable вариант запуска тестов, позволяющий игнорировать ошибки в отдельных подтестах (--ignore_errors). Итак, целочисленные тесты. Новая версия позволяет получить некоторое преимущество в ряде подтестов (252.eon, 253.perlbmk, 254.gap, 255.vortex), которое, однако, невозможно компенсировать значительным снижением производительности 197.parser (порядка 34%!), а также 300.twolf. В результате имеем общую оценку SPECint_base2000 = 1604, на 4.6% уступающую оценке, полученной с версией 8.1 (1682). В тестах с вещественными числами новая версия позволяет получить лишь едва заметное преимущество по скорости в ряде подтестов, но и здесь не обошлось без заметного снижения скорости отдельных подтестов (13.3% в 179.art). В результате, общая оценка SPECfp_base2000 (1489) на 1.5% уступает результату, полученному с предыдущей версией (1511).
Следующий вариант оптимизации, использующий инструкции SSE (-QxK). В целочисленных тестах наблюдаем аналогичную картину — незначительное преимущество новой версии в некоторых подтестах при 1.5-кратном снижении производительности 197.parser. Тем не менее, 300.twolf в этом случае отличается не только не худшей, но и даже лучшей производительностью (2.2%). Интегральная оценка примерно на 2.5% ниже по сравнению с версией 8.1. Совсем по-другому обстоит дело в тестах с плавающей точкой — производительность большинства задач возрастает при переходе к версии 9.0, максимальный прирост наблюдается в подтестах 171.swim (7.7%) и 187.facerec (5.6%). Интегральный показатель SPECfp_base2000 на 1.3% выше по сравнению с предыдущей версией.
Что касается остальных вариантов оптимизации кода (-QxW, -QxN и -QxP), в целочисленных тестах картина оказывается похожей на вариант -QxK: по-прежнему наблюдаем 1.5-кратное падение производительности 197.parser и, как следствие, несколько меньший интегральный показатель SPECint_base2000. В тестах с плавающей точкой между указанными вариантами оптимизации наблюдаются различия — как в интегральном показателе, так и в отдельных подтестах. Так, в варианте SSE2/Willamette (-QxW) заметен прирост в 200.sixtrack (11.2%) и 187.facerec (5.0%) при значительном снижении скорости 179.art (-10.5%). По SPECfp_base2000 новая версия выигрывает всего 0.9%. Вариант SSE2/Northwood (-QxN) по общей оценке, напротив, несколько проигрывает предыдущей версии (на 0.5%), благодаря значительному падению в скорости 168.wupwise (-21.1%) и том же 179.art (-11.1%) при некотором приросте в целом ряде подтестов (178.galgel, 187.facerec, 191.fma3d и 200.sixtrack). Наконец, «родной» для Prescott SSE3-вариант -QxP выигрывает 2.6% по общему показателю благодаря увеличению производительности задач 178.galgel (7.9%), 183.equake (12.2%), 187.facerec (5.0%) и 200.sixtrack (9.5%) при практически незаметном снижении скорости выполнения немногих других подтестов (максимальном — 3.8% в 300.aspi).
Абсолютная производительность как целочисленных, так и вещественных задач в целом (по интегральным показателям) возрастает в ряду -QxK < -QxB < -QxW < -QxN < -QxP, что вполне разумно для ядра Prescott.
Pentium M 770
Переходим ко второму «почти флагману» Intel — процессору Pentium M 770 с тактовой частотой ядра Dothan 2.13 ГГц. Тесты с участием этого процессора проводились на «десктопно-мобильной» системе — материнской плате DFI 855GME-MGF с не самым быстрым чипсетом Intel 855GM, а точнее — не самой быстрой подсистемой памяти (одноканальной DDR-333).
| Без опт. | -QxK | -QxW | -QxN | -QxB | ||||||
| ic8.1 | ic9.0 | ic8.1 | ic9.0 | ic8.1 | ic9.0 | ic8.1 | ic9.0 | ic8.1 | ic9.0 | |
| 164.gzip | 1143 | 1091 (-4.5%) | 1248 | 1245 (-0.2%) | 1236 | 1238 (0.2%) | 1247 | 1246 (-0.1%) | - | 1251 |
| 175.vpr | x | x | 1321 | 1316 (-0.4%) | 1367 | 1381 (1.0%) | 1364 | 1377 (1.0%) | - | 1361 |
| 176.gcc | x | x | 1822 | 1805 (-0.9%) | 1805 | 1803 (-0.1%) | 1825 | 1806 (-1.0%) | - | 1814 |
| 181.mcf | 1042 | 1059 (1.6%) | 1054 | 1052 (-0.2%) | 1051 | 1047 (-0.4%) | 1504 | 1507 (0.2%) | - | 1507 |
| 186.crafty | 1320 | 1303 (-1.3%) | 1312 | 1313 (0.1%) | 1455 | 1460 (0.3%) | 1455 | 1456 (0.1%) | - | 1631 |
| 197.parser | 1381 | 1004 (-27.3%) | 1392 | 1002 (-28.0%) | 1392 | 990 (-28.9%) | 1388 | 1008 (-27.4%) | - | 1001 |
| 252.eon | 1589 | 1736 (9.3%) | 1688 | 1668 (-1.2%) | 1922 | 1930 (0.4%) | 2096 | 2066 (-1.4%) | - | 2127 |
| 253.perlbmk | 1724 | 1716 (-0.5%) | 1736 | 1755 (1.1%) | 1750 | 1775 (1.4%) | 1752 | 1760 (0.5%) | - | 1811 |
| 254.gap | 1163 | 1282 (10.2%) | 1151 | 1168 (1.5%) | 1280 | 1302 (1.7%) | 1282 | 1298 (1.2%) | - | 1337 |
| 255.vortex | 2456 | 2484 (1.1%) | 2492 | 2497 (0.2%) | 2466 | 2492 (1.1%) | 2491 | 2488 (-0.1%) | - | 2482 |
| 256.bzip2 | 1225 | 1238 (1.1%) | 1156 | 1178 (1.9%) | 1196 | 1176 (-1.7%) | 1192 | 1178 (-1.2%) | - | 1205 |
| 300.twolf | 2102 | 1823 (-13.3%) | 2111 | 2149 (1.8%) | 2223 | 2252 (1.3%) | 2220 | 2256 (1.6%) | - | 2241 |
| SPECint_base2000 | 1459 | 1416 (-2.9%) | 1489 | 1453 (-2.4%) | 1544 | 1507 (-2.4%) | 1605 | 1564 (-2.6%) | - | 1591 |
| 168.wupwise | 1249 | 1264 (1.2%) | 1327 | 1356 (2.2%) | 1133 | 1145 (1.1%) | 1149 | 1045 (-9.1%) | - | 1285 |
| 171.swim | 713 | 722 (1.3%) | 854 | 782 (-8.4%) | 841 | 822 (-2.3%) | 845 | 821 (-2.8%) | - | 821 |
| 172.mgrid | 777 | 786 (1.2%) | 835 | 839 (0.5%) | 817 | 829 (1.5%) | 818 | 820 (0.2%) | - | 842 |
| 173.applu | 612 | 617 (0.8%) | 631 | 638 (1.1%) | 611 | 608 (-0.5%) | 701 | 703 (0.3%) | - | 729 |
| 177.mesa | 898 | 906 (0.9%) | 1379 | 1506 (9.2%) | 1578 | 1570 (-0.5%) | 1579 | 1552 (-1.7%) | - | 1651 |
| 178.galgel | 1753 | 1694 (-3.4%) | 2499 | 2503 (0.2%) | 2224 | 2237 (0.6%) | 2218 | 2428 (9.5%) | - | 2803 |
| 179.art | 2600 | 2495 (-4.0%) | 2388 | 2360 (-1.2%) | 2472 | 2437 (-1.4%) | 2645 | 2575 (-2.6%) | - | 2634 |
| 183.equake | 888 | 906 (2.0%) | 905 | 901 (-0.4%) | 898 | 898 (0.0%) | 900 | 899 (-0.1%) | - | 900 |
| 187.facerec | 1165 | 1156 (-0.8%) | 1244 | 1274 (2.4%) | 1237 | 1275 (3.1%) | 1252 | 1273 (1.7%) | - | 1268 |
| 188.ammp | 1019 | 980 (-3.8%) | 983 | 968 (-1.5%) | 922 | 905 (-1.8%) | 904 | 891 (-1.4%) | - | 963 |
| 189.lucas | 799 | 809 (1.3%) | 793 | 791 (-0.3%) | 891 | 899 (0.9%) | 895 | 898 (0.3%) | - | 897 |
| 191.fma3d | 808 | 821 (1.6%) | 801 | 812 (1.4%) | 829 | 840 (1.3%) | 839 | 853 (1.7%) | - | 845 |
| 200.sixtrack | 542 | 540 (-0.4%) | 533 | 513 (-3.8%) | 464 | 474 (2.2%) | 452 | 475 (5.1%) | - | 528 |
| 301.apsi | 916 | 903 (-1.4%) | 916 | 913 (-0.3%) | 851 | 853 (0.2%) | 856 | 846 (-1.2%) | - | 902 |
| SPECfp_base2000 | 963 | 960 (-0.3%) | 1038 | 1038 (0.0%) | 1015 | 1018 (0.3%) | 1031 | 1030 (-0.1%) | - | 1085 |
Целочисленные тесты без оптимизации кода: наибольший прирост в новой версии наблюдается в 254.gap (~10%), наиболее сильное падение — во все том же 197.parser (по сравнению с Pentium 4, оно несколько меньше — порядка 27%). Суммарная оценка SPECint_base2000 уступает предыдущей версии в среднем на 3%. В тестах с плавающей точкой наблюдается небольшой разброс значений — как в большую, так и в меньшую сторону, однако по интегральной оценке скорость выполнения кода, откомпилированного ICC/IFC 8.1 и 9.0, практически совпадает. Удивляют весьма низкие абсолютные оценки отдельных подтестов и общего показателя SPECfp_base2000 по сравнению с результатами Pentium 4 — при несильном отставании от него по целочисленным тестам. По-видимому, это связано с требовательностью этих тестов к пропускной способности памяти, которая в случае системы на базе Pentium M с одноканальной DDR-333 заметно ниже (2.67 против 6.4 ГБ/с). Но уж точно не блоком FPU, который в Pentium M реализован не только не хуже, но и намного лучше по сравнению с Pentium 4.
Использование ключей оптимизации (для данного процессора доступны -QxK, -QxW, -QxN и -QxB) не приводит к существенному изменению картины, за исключением увеличения общей производительности (которая, заметим, возрастает именно в указанном ряду, то есть «родная» оптимизация кода под ядро Banias оказывается наилучшей и для ядра Dothan). Целочисленные тесты по-прежнему немного (примерно на 2.5%) уступают предыдущей версии (благодаря заметно сниженной производительности 197.parser при одновременном отсутствии ощутимого выигрыша в остальных подтестах), а тесты с вещественными числами практически равны ей по скорости. Но последнее вновь достигается не за счет полной идентичности результатов каждого подтеста, а за счет наличия разброса величин — как в большую, так и в меньшую сторону (особенно заметного в вариантах -QxK и -QxN — до 10% в ряде подтестов), в итоге компенсирующего самого себя.
Athlon 64 FX-57
И напоследок — самое интересное! Результаты тестов компиляторов Intel C++/Fortran Compiler 8.1/9.0 на последнем одноядерном процессоре конкурента — AMD Athlon 64 FX-57. Вы спросите, как нам это удалось? Все очень просто — для этого оказалось достаточно разобраться в алгоритме проверки типа процессора кодом приложения, откомпилированного с помощью компиляторов Intel. Схематически, выглядит она следующим образом:
1. Проверка Vendor String процессора на соответствие «GenuineIntel»;
2. Определение типа модели процессора (Pentium III/Pentium M — модель 6, или Pentium 4/Xeon — модель 15);
3. Определение наличия необходимых расширенных наборов инструкций (SSE, SSE2, SSE3).
Исходя из этой схемы и простого анализа становится совершенно очевидно, что достаточно убрать проверку №1, и код, откомпилированный Intel C++/Fortran Compiler, станет работоспособным и на процессорах конкурента — при условии, что процессор поддерживает нужные наборы инструкций. Связано это с тем, что номера моделей у процессоров Intel и AMD, к счастью, совпадают: модели 6 соответствуют процессоры класса AMD K7 (большинство из которых поддерживают SSE), а модели 15 — процессоры AMD K8 (поддерживающие SSE, SSE2, а в последней ревизии ядра E — и SSE3). Впрочем, если бы этого совпадения и не было, нам ничего не мешало бы убрать и проверку №2. Тогда работоспособность приложения зависела бы только от наличия/отсутствия в процессоре необходимых расширений.
«Исправление» бинарных файлов можно осуществлять вручную, однако для этой цели мы написали небольшую вспомогательную утилиту — ICC Patcher (скачать ее можно отсюда). Она просматривает бинарный файл на предмет «подозрительных» проверок соответствия на GenuineIntel и заменяет все эти проверки пустыми операциями NOP. Заметим, что этим патчером можно «исправлять» не только готовые exe-файлы, но и исходные библиотеки Intel C++/Fortran Compiler, в том числе для EM64T. Тогда в результате компиляции всегда будут получаться программы, работоспособные как на процессорах Intel, так и AMD. Причем, повторим, такой патчинг не является «грубым» — например, код, откомпилированный с ключом -QxP, запустится только на процессорах AMD Athlon64/Opteron с ревизией ядра E, и выдаст корректное предупреждение о невозможности продолжения работы на более ранних ревизиях ядра и на процессорах класса AMD K7.
Но перейдем к результатам тестов. Из соображений экономии времени, мы решили не перекомпилировать заново все исходники тестов с «правильными» файлами библиотек Intel, а «исправить» уже имеющиеся бинарные файлы. В связи с этим, в config-файлах тестов выставлялась опция check_md5=0, ибо нетрудно догадаться, что «исправление» исполняемых файлов изменяет их контрольную сумму.
| Без опт. | -QxK | -QxW | -QxN | -QxB | -QxP | |||||||
| ic8.1 | ic9.0 | ic8.1 | ic9.0 | ic8.1 | ic9.0 | ic8.1 | ic9.0 | ic8.1 | ic9.0 | ic8.1 | ic9.0 | |
| 164.gzip | 1437 | 1363 (-5.1%) | 1568 | 1571 (0.2%) | 1546 | 1546 (0.0%) | 1566 | 1540 (-1.7%) | - | 1584 | 1574 | 1558 (-1.0%) |
| 175.vpr | x | x | 1429 | 1406 (-1.6%) | 1515 | 1510 (-0.3%) | 1516 | 1503 (-0.9%) | - | 1483 | 1514 | 1486 (-1.8%) |
| 176.gcc | x | x | 2178 | 2184 (0.3%) | 2161 | 2173 (0.6%) | 2182 | 2143 (-1.8%) | - | 2192 | 2199 | 2158 (-1.9%) |
| 181.mcf | 1149 | 1150 (0.1%) | 1153 | 1149 (-0.3%) | 1152 | 1148 (-0.3%) | 1498 | 1500 (0.1%) | - | 1501 | 1506 | 1505 (-0.1%) |
| 186.crafty | 1892 | 1877 (-0.8%) | 1903 | 1921 (0.9%) | 1952 | 1945 (-0.4%) | 1935 | 1939 (0.2%) | - | 2011 | 2011 | 1992 (-0.9%) |
| 197.parser | 1733 | 1257 (-27.5%) | 1773 | 1275 (-28.1%) | 1754 | 1253 (-28.6%) | 1766 | 1267 (-28.3%) | - | 1256 | 1764 | 1251 (-29.1%) |
| 252.eon | 2216 | 2622 (18.3%) | 2463 | 2410 (-2.2%) | 2973 | 2901 (-2.4%) | 3220 | 3124 (-3.0%) | - | 3176 | 3177 | 3133 (-1.4%) |
| 253.perlbmk | 2105 | 2104 (0.0%) | 2093 | 2121 (1.3%) | 2123 | 2148 (1.2%) | 2142 | 2132 (-0.5%) | - | 2209 | 2137 | 2250 (5.3%) |
| 254.gap | 1858 | 1869 (0.6%) | 1889 | 1910 (1.1%) | 1960 | 1999 (2.0%) | 1974 | 1968 (-0.3%) | - | 1990 | 1990 | 1952 (-1.9%) |
| 255.vortex | 2875 | 2799 (-2.6%) | 2823 | 2829 (0.2%) | 2797 | 2719 (-2.8%) | 2856 | 2881 (0.9%) | - | 2797 | 2835 | 2902 (2.4%) |
| 256.bzip2 | 1480 | 1514 (2.3%) | 1462 | 1460 (-0.1%) | 1431 | 1437 (0.4%) | 1433 | 1430 (-0.2%) | - | 1442 | 1451 | 1445 (-0.4%) |
| 300.twolf | 1934 | 1777 (-8.1%) | 1940 | 1939 (-0.1%) | 1958 | 1950 (-0.4%) | 1959 | 1962 (0.2%) | - | 1944 | 1947 | 1953 (0.3%) |
| SPECint_base2000 | 1814 | 1761 (-2.9%) | 1837 | 1787 (-2.7%) | 1879 | 1823 (-3.0%) | 1943 | 1879 (-3.3%) | - | 1894 | 1950 | 1893 (-2.9%) |
| 168.wupwise | 2121 | 2131 (0.5%) | 2166 | 2200 (1.6%) | 2128 | 2174 (2.2%) | 2456 | 2085 (-15.1%) | - | 2197 | 2385 | 2366 (-0.8%) |
| 171.swim | 1448 | 1448 (0.0%) | 2130 | 1944 (-8.7%) | 2136 | 2110 (-1.2%) | 2138 | 2110 (-1.3%) | - | 2118 | 2134 | 2111 (-1.1%) |
| 172.mgrid | 1231 | 1244 (1.1%) | 1330 | 1471 (10.6%) | 1432 | 1463 (2.2%) | 1458 | 1554 (6.6%) | - | 1486 | 1418 | 1566 (10.4%) |
| 173.applu | 1230 | 1251 (1.7%) | 1224 | 1243 (1.6%) | 1205 | 1196 (-0.7%) | 1530 | 1498 (-2.1%) | - | 1530 | 1538 | 1513 (-1.6%) |
| 177.mesa | 1569 | 1587 (1.1%) | 1893 | 1939 (2.4%) | 2075 | 2046 (-1.4%) | 2072 | 2075 (0.1%) | - | 2018 | 2077 | 2046 (-1.5%) |
| 178.galgel | 2080 | 2056 (-1.2%) | 2437 | 2459 (0.9%) | 2495 | 2464 (-1.2%) | 2445 | 2928 (19.8%) | - | 2980 | 2475 | 2915 (17.8%) |
| 179.art | 1798 | 1804 (0.3%) | 1785 | 1811 (1.5%) | 1844 | 1839 (-0.3%) | 1852 | 1847 (-0.3%) | - | 1839 | 2686 | 2910 (8.3%) |
| 183.equake | 1657 | 1680 (1.4%) | 1678 | 1669 (-0.5%) | 1685 | 1680 (-0.3%) | 1674 | 1671 (-0.2%) | - | 1693 | 1679 | 1788 (6.5%) |
| 187.facerec | 1862 | 1722 (-7.5%) | 1896 | 2024 (6.8%) | 1902 | 2030 (6.7%) | 1955 | 2036 (4.1%) | - | 1989 | 1963 | 2001 (1.9%) |
| 188.ammp | 1390 | 1331 (-4.2%) | 1333 | 1298 (-2.6%) | 1319 | 1299 (-1.5%) | 1276 | 1277 (0.1%) | - | 1285 | 1298 | 1301 (0.2%) |
| 189.lucas | 1615 | 1624 (0.6%) | 1570 | 1570 (0.0%) | 1727 | 1734 (0.4%) | 1729 | 1724 (-0.3%) | - | 1722 | 1730 | 1723 (-0.4%) |
| 191.fma3d | 1525 | 1537 (0.8%) | 1462 | 1483 (1.4%) | 1566 | 1564 (-0.1%) | 1593 | 1607 (0.9%) | - | 1570 | 1614 | 1630 (1.0%) |
| 200.sixtrack | 779 | 778 (-0.1%) | 781 | 791 (1.3%) | 757 | 779 (2.9%) | 750 | 779 (3.9%) | - | 820 | 748 | 793 (6.0%) |
| 301.apsi | 1493 | 1456 (2.5%) | 1475 | 1484 (0.6%) | 1484 | 1492 (0.5%) | 1519 | 1471 (-3.2%) | - | 1474 | 1510 | 1464 (-3.0%) |
| SPECfp_base2000 | 1515 | 1506 (-0.6%) | 1596 | 1613 (1.1%) | 1633 | 1642 (0.6%) | 1681 | 1693 (0.7%) | - | 1698 | 1725 | 1776 (3.0%) |
Неоптимизированный код: в целочисленных тестах и на этом процессоре весьма заметно отставание 197.parser (27.3% — аналогичную величину мы получили на Pentium M), а также 300.twolf (13.3%), которое в некоторой степени компенсируется выигрышем в задачах 252.eon (9.3%) и 254.gap (10.2%). Общая оценка SPECint_base2000 уступает предыдущей версии компилятора примерно на 3%, что вновь весьма похоже на результаты тестов Pentium M. Тесты с плавающей точкой вновь показывают результат, близкий к предыдущей версии, который и здесь достигается не равенством скорости исполнения отдельных подтестов, а их различиями как в большую, так и в меньшую стороны, компенсирующими друг друга. В результате общий результат SPECfp_base2000 уступает всего 0.6% коду, откомпилированному ICC/IFC 8.1.
Оптимизированные варианты целочисленных тестов не вносят заметных отличий в картину, полученную на других процессорах. А именно, заметное отставание 197.parser (27-28%) сохраняется, заметный же выигрыш в отдельных подтестах не наблюдается вовсе (в порядке исключения, следует отметить задачу 253.perlbmk в варианте -QxP, отличающуюся 5.3% ростом производительности). Отставание в 197.parser обуславливает примерно 3% снижение общей оценки SPECint_base2000 во всех случаях. Что касается абсолютных величин производительности, они возрастают в ряду -QxK < -QxW < -QxN < -QxP < -QxB, то есть лучшим (но совсем ненамного, и то лишь в некоторых тестах и общей оценке) вариантом оптимизации оказывается «заточка» кода под ядро Banias. Собственно, такой результат нельзя назвать из ряда вон выходящим, учитывая родство микроархитектуры AMD K8 с Intel Pentium III/Pentium M, а не Pentium 4 (NetBurst).
Переходим к оптимизированным вариантам кода SPECfp. Как и с процессорами Intel, на Athlon 64 FX-57 во всех случаях наблюдается прирост производительности при переходе к новой версии компилятора. Относительная величина выигрыша различна (зависит от типа оптимизации), различны и, скажем так, способы ее достижения. Так, в SSE-варианте (-QxK) заметно падение в 171.swim на 8.7% (заметим, что на Pentium 4 в этой задаче наоборот наблюдался выигрыш) при увеличении скорости 172.mgrid на 10.6% и 187.facerec на 6.8%, общий прирост SPECfp_base2000 составляет 1.1%. В «старом» варианте SSE2 для ядра Willamette (-QxW, который, заметим, работоспособен на AMD K8 и без «доработки») явное лидерство сохраняется лишь в задаче 187.facerec (6.7%), общий выигрыш — всего 0.6%. «Новый» вариант SSE2 для ядра Northwood отличается не большим возрастанием SPECfp_base2000 (0.7%), но заметен различный разброс величин в отдельных подтестах (-15.1%(!) в 168.wupwise, +6.6% в 172.mgrid и +19.8% в 178.galgel). Наконец, лучший вариант оптимизации под SSE3 (ядро Prescott, -QxP) характеризуется практически полным отсутствием падения производительности (следует упомянуть разве что 3% снижение в 301.aspi) при значительном росте скорости целого ряда задач (172.mgrid на 10.4%, 178.galgel на 17.8%, 179.art на 8.3%, 183.equake на 6.5%). В результате, общая оценка SPECfp_base2000 на целых 3% выше по сравнению с предыдущей версией. Что касается эффективности кода, как мы уже отметили, она наиболее высока при использовании SSE3. Вслед за ним располагается SSE2-вариант, рассчитанный на ядро Banias (-QxB), что вновь не имеет противоречий с представлениями о микроархитектуре AMD K8, далее располагаются -QxN, -QxW и -QxK.
Выводы
Новые компиляторы Intel C++/Fortran Compiler 9.0 в «типовом» варианте компиляции кода (если таковым считать компиляцию с профилированием) демонстрируют неоднозначную картину. Результирующий целочисленный код по скорости в целом несколько (на 3-5%) уступает коду, полученному с предыдущей версией компиляторов 8.1. Значимое падение производительности наблюдается лишь в одной задаче, зато весьма весомое — от 27 до 34% в зависимости от процессора. И хорошо, если пользовательский код не окажется подобным этой задаче :).
Тем не менее, в плане вычислений с вещественными числами (где используются инструкции SSE, SSE2, SSE3) новая версия компиляторов показывает некоторое преимущество над предыдущей — правда, весьма незначительное (от 0 до 3%). Сохраняется и адекватность использования ключей оптимизации под конкретную микроархитектуру процессора (-QxP для Pentium 4/Prescott, -QxB для Pentium M/Dothan, для процессоров класса AMD K8 можно рекомендовать поэкспериментировать с ключами -QxB и -QxP).
Кстати, несколько слов о процессорах AMD. Результаты проведенного исследования показывают, что обе версии ICC/IFC — 8.1 и 9.0 — выдают на выходе код, обладающий очень хорошей (а в ряде случаев — и лучшей) производительностью на процессорах конкурента… если только его немного «исправить» :), или же «исправить» библиотеки компилятора. Было бы просто замечательно, если бы корпорация Intel, производитель процессоров и компиляторов, заменила бы нынешний вариант проверки типа процессора на более разумный — наподобие того, который использовали мы.
Такая модификация оказалась бы выгодна, прежде всего, для конечных пользователей — в этом случае, даже при использовании разработчиком ПО «автоматических» вариантов оптимизации вида -Qax*, при исполнении приложения будет выбран наиболее оптимизированный вариант кода, причем в зависимости только от наличия необходимых расширенных наборов инструкций, а не изготовителя процессора. Отметим, что один из пунктов обвинения Intel со стороны AMD заключался как раз в том, что при исполнении «автоматического» варианта кода процессоры AMD могут сильно уступать процессорам конкурента, несмотря на присутствие в них необходимых расширений.
Не менее благоприятной она оказалась бы и для разработчиков и тестировщиков ПО — отпала бы необходимость использования разных компиляторов для разных процессоров, или в «привязке» к процессорам конкретного производителя при разработке и отладке приложений.
И, конечно, в немалой выгоде оказалась бы и сама компания AMD — ибо начисто отпала бы необходимость в разработке собственного компилятора, которая вот уже долгое время находится в состоянии неопределенности :).
