Сколько копий было уже сломано при обсуждении SIMD-инструкций в процессорах! Наверное, ни одно другое архитектурное нововведение в линейке х86 не рассматривалось и не изучалось столь пристально, как MMX, 3D Now!, SSE и прочее им подобное. Впрочем, ММХ как таковой особых споров не вызывал: обсуждали лишь нужны ли вообще эти инструкции и если да, то насколько. Связано это с тем, что на тот момент все производители процессоров плыли в «одной лодке», внедрив новые команды почти одновременно (естественно, в случае AMD и Cyrix небольшая задержка была, но без этого обойтись бы никак не удалось). Зато когда каждая компания пошла своим путем… Естественно, сами фирмы в рекламе утверждали, что без SIMD-инструкций в наш просвещенный век прожить никак нельзя, причем именно без набора, поддерживаемого именно этой фирмой — все в порядке вещей. Зато пользователи оттягивались по полной :) В промежутке между выходом К6-2 и Pentium III поклонники Intel утверждали, что никому особо-то нецелочисленные SIMD-команды не нужны. После появления SSE их мнение немного изменилось: пользу от подобных команд признали, постановили, что они действительно всем необходимы, но именно SSE, а никак не 3D Now! AMD встроила поддержку SSE в свои новые процессоры, после чего началось уже обсуждение того, что жить трудно ныне без SSE2, а остальное не так важно. Впрочем, поклонники AMD вели себя не лучше, заявляя, например, что неважно, что в К6-2 сопроцессор «дохлый» — все равно сей процессор всех забьет, ибо 3D Now! есть рулез форева :)
А время шло, производители ПО потихоньку осваивали «подарки» от чипмейкеров… Что же у нас получилось в итоге? Ну, это все от софта зависит, конечно. Вообще, долгое время напрямую сравнить эффективность наборов команд от разных производителей было невозможно, поскольку процессоры отличались не только этим. Можно было разве что сравнить, что дают новые команды по сравнению с их отсутствием, да и то следовало дожидаться оптимизированного реального, а не тестового программного обеспечения. Сейчас все проще. Новые процессоры AMD поддерживают все, кроме SSE2, так что сравнение можно проводить на одной платформе. Для SSE2 же пока ПО маловато (если не сказать сильнее), так что его отложим на потом, а пока посмотрим, что дает оптимизация под SIMD-команды на примере одной, но немаловажной для многих задачи — кодирования звука в МР3.
Что я делал
Почему я ухватился именно за эту сферу применения компьютера? Да по двум причинам: во-первых, жму много, во-вторых, нашлось, чем хорошо сравнить. Речь идет о кодеке от GOGO. Вообще последний — мечта тестера: есть оптимизация под ММХ, 3D Now!, Enchanced 3D Now!, SSE, многопроцессорные конфигурации, причем все это включается и выключается вручную, так что ошибок с автоопределением процессоров не бывает. Есть отличный фронт-енд, после кодирования выдающий точную информацию о том, сколько времени заняло сжатие и скорость в «иксах», привычных по CD-ROM (1x=150 Кбайт/с). Впрочем, в его случае это называется отношением времени проигрывания ко времени кодирования, но суть-то та же. Ну и сам по себе кодек весьма неплох, обеспечивая наряду с бешеной скоростью работы еще и высокое качество и отличную совместимость с различными декодерами. Собственно, именно поэтому я связку из GOGO 2.39c и WinGOGO и использую на практике уже давно и менять ее ни на что пока не собираюсь.
Какие методы оптимизации я использовал? Ну, во-первых, тестировал выключив все — для получения некоего базового результата. Второй результат — использование только ММХ. В общем-то, давно признано, что целочисленные инструкции на скорость сжатия музыки влияют очень слабо, но почему бы это лишний раз не проверить? К тому же, многие кодеки до сих пор только под ММХ и оптимизированы (а некоторым и этот набор команд — как мертвому припарки). Все остальные результаты (начиная с данного) были получены с включенным ММХ. Третья строка — оригинальный набор 3D Now!. Четвертая — Enchanced 3D Now!/MMX2: расширение базового набора, пришедшее к нам вместе с первыми Athlon (использование базовых команд при этом, естественно, тоже включено). Пятая — SSE от Intel, благо процессор эти команды поддерживает. Может быть, и не совсем правильно тестировать команды от Intel на процессоре AMD, но… другого пути нет. К тому же, существует мнение, что поддержка SSE в Athlon XP/Duron реализована лучше, чем в процессорах самой фирмы Intel. Может оно верное, может — нет, но я предпочел исходить из того, что все сделано примерно на одном уровне. Возможно, это дает некоторую фору SSE (ведь вообще никто не утверждал, что в процессорах AMD SSE реализовано хуже, чем у Intel), но, как мы увидим в дальнейшем, не сильно-то это предположение помогает ;) Ну и последний вариант: включено абсолютно все, а там уж пускай программа разбирается :)
Мне интересно было сравнить результаты не только внутри программы, но и с кем-нибудь из плохооптимизированных кодеков. На роль последнего был выбран Lame 3.89. Этот вариант наиболее логичен: GOGO собственно и вырос из Lame. В последнем ничего особо понастраивать не дают: только оптимизация по скорости, по качеству и ее отсутствие. Качество файлов, получаемых GOGO при настройках по умолчанию, находится где-то между двумя последними способами оптимизации Lame (хуже, чем при оптимизации по качеству и чуть-чуть лучше, чем без оной). В принципе, можно было бы кроме всего прочего отключить GOGO психоакустику (для более корректного сравнения с Lame в «быстром» режиме), однако результаты получились бы малоинтересными: в данном случае кодер из-за своей «скорострельности» пригоден разве что для тестирования дисковой системы ;)
Теперь об объекте эксперимента. Взял с полки пиратский сборник Ларисы Черниковой «Вспоминать и не надо» (мнение о моих музыкальных пристрастиях можете оставить при себе — оно меня абсолютно не интересует… да и к делу не относится) и при помощи ЕАС сграбил все в один WAV-файл размером 751 Мбайт (для тех, кто любит точность, размер в байтах — 787 873 004). Вот его-то я и сжимал в МР3 с битрейтом 128 и 320 Кбит/с (для сравнения), режим — стерео. Каждый эксперимент проводился по три раза, цифры усреднены и округлены до целых секунд и десятых долей «иксов» (а то любит GOGO давать первое с точностью до сотых, а второе — до тысячных).
Теперь пара слов об оборудовании, которое использовалось для этого, с позволения сказать, тестирования. Ничего сверхординарного: AMD Athlon XP 1800+, Soltek SL-75DRV (обычный КТ266), 256 Мбайт РС2100 DDR SDRAM, винчестер Fujitsu MPG3204AH-E (20 Гбайт, UDMA100). Обычно диски я граблю при помощи SCSI CD-ROM Plextor 4PlexPlus, однако последний имеет скорость лишь 4.5х, а мне сейчас время извлечения треков было важно (чтобы сравнить со временем сжатия), поэтому диск грабил на SCSI CD-RW Plextor PlexWriter 1210TS. Скорость, кстати, получилась неплохой — порядка 20х в начале диска и где-то 26х в конце, но это все, естественно, от диска зависит. Все это работало под управлением Windows 2000 Professional.
Ну а теперь самое интересное — результаты.
128 Кбит/с
| Кодер | Режим | Время, мин:с | Скорость, Х |
| GOGO | No optimization | 4:00 | 18.6 |
| MMX | 3:50 | 19.4 | |
| MMX+3D Now! | 2:46 | 26.9 | |
| MMX+Enchanced 3D Now!/MMX2 | 2:36 | 28.7 | |
| MMX+SSE | 2:40 | 27.9 | |
| Full Optimization | 2:36 | 28.7 | |
| Lame | Speed | 2:12 | |
| 3:30 | |||
| Quality | 7:39 |
Какие выводы можно сделать из данной таблицы? Прирост от целочисленных инструкций действительно очень мал — это заметно по результатам и в случае использования ММХ, и в случае Enchanced 3D Now!/MMX2 (в последнем случае тоже больше все же упор на целочисленку). Впрочем, судя по результатам, для оригинального 3D Now! и SSE, для AMD и такой прирост был важен: и по времени появления, и по эффективности данные три набора выстраиваются абсолютно в одинаковом порядке. Слухи о большей эффективности SSE, чем Enchanced 3D Now! оказались несколько преувеличенными, даже если принять за рабочую гипотезу одинаково успешную реализацию SSE и AMD, и Intel (что я и делал). Пользователям процессоров AMD SSE нужно только в том случае, если используемая программа не поддерживает 3D Now!, что, впрочем, довольно часто встречается. Приятно, что кодек не «запутался», даже когда я попросил его использовать все возможные варианты оптимизации: результат совпал с полученным при более шустром Enchanced 3D Now!, а не с более медленным SSE. 
Результаты Lame по вполне понятным причинам куда хуже. Только при использовании оптимизации по скорости ему удается вырваться вперед, но ценой качества. Примерно такое же на этом битрейте получается у GOGO с выключенной психоакустикой, но в таком случае он тратит на сжатие данного файла всего 50 секунд. Выключенная оптимизация дает несколько меньшее качество, чем в случае GOGO и несколько меньшую скорость. Ну а про оптимизацию по качеству и говорить-то не стоит. Вот тут оптимизация под SSE/3D Now! дала бы просто замечательный абсолютный результат: относительный тот же, но при такой низкой скорости сжатия он куда заметнее.
Ну и еще один вывод: при сжатии музыки с диска «на лету» и использовании неоптимизированных под нецелочисленные SIMD-инструкции кодеков, у многих пользователей узким местом будет процессор. Заметьте: даже Athlon ХР 1800+ недостаточно чтобы угнаться за скоростным приводом, если вся нагрузка ляжет на сопроцессор. Что же говорить о маломощных процессорах типа Celeron 1200 или Duron 1000 (к примеру). Ну а пользователям Pentium 4 оптимизация под SSE (про SSE2 пока сказать ничего нельзя) для кодирования МР3 нужна просто как воздух! В еще более интересном положении находятся те, кто до сих пор использует К6-2, К6-III и К6-2+: неоптимизированные кодеки для этих процессоров подобны гире на ногах, в то время как оптимизация под 3D Now! позволяет получить не самые худшие (относительно, конечно) результаты. А самое важное то, что использование оптимизации под SIMD-инструкции позволяет, наряду со значительным ускорением кодирования, сохранить такое же качество, чем и отличается от «оптимизации по скорости» в Lame и подобном софте.
320 Кбит/с
| Кодер | Режим | Время, мин:с | Скорость, Х |
| GOGO | No optimization | 2:51 | 26.1 |
| MMX | 2:41 | 27.8 | |
| MMX+3D Now! | 1:58 | 38.0 | |
| MMX+Enchanced 3D Now!/MMX2 | 1:51 | 40:1 | |
| MMX+SSE | 1:54 | 39.4 | |
| Full Optimization | 1:51 | 40.1 | |
| Lame | Speed | 2:24 | |
| 2:29 | |||
| Quality | 4:34 |
Сжимать в четыре раза проще, чем в 11, так что результаты стали лучше почти во всех строках. Да и со сжатием на лету проблем уже практически в любом случае не будет (ну, естественно, на достаточно мощных процессорах). Тенденции остались теми же, кроме одного случая: оптимизация по скорости в Lame не дает практически никакого эффекта на высоких битрейтах, что привело к проигрышу кодера всюду. Но вот ценителям качества (а именно его обычно «жаждут» сжимая в 320 Кбит/с) жить стало хоть и легче, но… хорошая оптимизация Lame все равно нужна.
Кстати — GOGO с выключеной психоакустикой с этой задачей справился за те же 50 секунд, что и при меньшем битрейте. Так что, как я и сказал в начале, в этом случае узким местом будет уже производительность дисковой системы. Казалось бы, 15 Мбайт/с слишком мало для UDMA100, но… Где-то полгода назад на ITC я читал любопытные результаты: сравнение производительности реальных приложений при двух режимах работы винчестера — UDMA100 и DMA2. В обоих случаях получилось практически одно и тоже, т.е. DMA2 с его пропускной способностью порядка 16 Мбайт/с вполне достаточно даже для современных винтов на 7200 об/мин и с двумя мегабайтами кэш-памяти. Причем это не особенности аппаратуры — в ITC все проверяли на винчестере IBM DTLA и материнской плате на i815E, я же получил подобный результат на Fujitsu (винчестере того же класса) и КТ266. Жаждущим UDMA133 советую серьезно подумать над этим вопросом ;)
Выводы
Конечно, по одной задаче не стоит делать далеко идущих выводов: в других приложениях все может несколько измениться. Может оказаться так, что в некоторых приложениях ММХ даст просто огромный выигрыш, а SSE и 3D Now! почти ничего к нему добавить не смогут даже при попытке использования. Во всяком случае, проиграть оптимизированные задачи просто не смогут — в худшем случае выигрыш будет равен единицам процентов, а не десяткам. Это что касается скорости — платить за нее качеством нам не придется (это все же не оптимизация «по скорости» в классическом понимании). В общем, основные тенденции понятны: нецелочисленные SIMD-инструкции нужны (раз), оптимизация под них программного обеспечения необходима (два), обеспечивают они примерно равный прирост производительности при небольшом преимуществе 3D Now! (три). Впрочем, третий пункт в ближайшее время может оказаться маловажным: ввиду того, что AMD решила таки поддерживать и SSE, количество программного обеспечения, рассчитанного именно на этот набор команд, может вскоре оказаться большим, чем рассчитанного на 3D Now!. Причем не просто большим, а заметно большим. Ну а пока… пока все так. По крайней мере, в случае одной конкретной задачи :)
