Jan 12
31
Журнал для начинающих “хакеров” на ряду с интересными и полезными публикациями с завидной регулярностью выдает “на гора” статейки “ни о чем“. Кризис жанра тому причиной, или отсутствие добросовестных и к в а л и ф и ц и р о в а н н ы х авторов приводят к появлению на страницах издания публикаций сомнительного содержания вводящих неокрепшие умы в заблуждение.
Автор статьи вообще умудрился имея верные данные сделать неверные выводы:
Как видим из результатов, однозначного вывода от использования такой оптимизации сделать нельзя. В чем-то получили совсем небольшой прирост (build-mplayer, john-the-ripper, compress-gzip, encode-ogg, mencoder, QGears2), где-то практически столько же проиграли (encodeflac, phpbench).
Хотя все, что есть, вполне укладывается в погрешность, которая есть у любого теста. Зато ресурсы и время, затраченные на пересборку системы, можно было бы использовать более продуктивно.
Да, от т а к о й “оптимизации” толку действительно не много. Не могу не согласиться и по последнему пункту. Вместо переливания из пустого в порожнее, ресурсы и время затраченные на пересборку системы высасывание “фактов” из пальца следовало бы потратить на изучение “матчасти” и тщательное тестирование системы. Вот это и было бы продуктивным использованием времени и ресурсов.
То, что Сергей «grinder» Яремчук гордо величает оптимизацией, по сути своей ей не является. Оптимизация системы не цель, а с р е д с т в о достижения максимальной производительности или баланса между скоростью и надежностью, то есть построение оптимально -сбалансированной системы.
Оптимизация ради оптимизации как у Сергея не имеет никакого смысла. Например, что даст “оптимизация” того же LibreOffice?
Человеку, печатающему со скоростью 300 орфографических ошибок в минуту никакая оптимизация ничем не поможет, грамотности не прибавит. Тут нужна оптимизация мозга.
Достигнуть максимальной производительности можно только используя к о м п л е к с н ы й подход к оптимизации системы. Для начала, стоит определить нужна ли вам оптимизация, что вы хотите получить в итоге.
Часто, пара лишних Гб оперативной памяти имеют не меньший “оптимизирующий” эффект чем использование самых изощренных опций компилятора почему то именуемых Яремчуком флагами. Не менее странным выглядит использование MESA для ATI Radeon X800 GTO в тестовой системе Сергея.
Так как я посмел поставить под сомнение выводы очень уважаемого тинейджерами журнала приведу свои тесты и выскажу н е к о т о р ы е свои соображения по поводу оптимизации.
Тестовая система:
- ноутбук ASUS x50vl, CPU T2330 1.6 Ггц, 3 Гб RAM, 320 Гб HDD, ATI Radeon X2300
- OS Calculate Linux 11.12. Ядро 3.2.2.
Тестируем систему сразу после установки. Профиль бинарный. Nbench – синтетический тест позволяющий оценить быстродействие системы и эффективность опций компилятора.
TEST : Iterations/sec
NUMERIC SORT : 742.44
STRING SORT : 159.06
BITFIELD : 2.8588e+08
FP EMULATION : 98.4
FOURIER : 16256
ASSIGNMENT : 21.722
IDEA : 3290.8
HUFFMAN : 1173.3
NEURAL NET : 33.453
LU DECOMPOSITION : 1056
==ORIGINAL BYTEMARK RESULTS==
INTEGER INDEX : 48.205
FLOATING-POINT INDEX: 37.878
Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==LINUX DATA BELOW==
CPU : Dual GenuineIntel Intel(R) Pentium(R) Dual CPU T2330 @ 1.60GHz @ 1.60GHz
L2 Cache : 1024 KB
OS : Linux 3.2.2-calculate
C compiler : x86_64-pc-linux-gnu-gcc
MEMORY INDEX : 13.418
INTEGER INDEX : 11.083
FLOATING-POINT INDEX: 21.009
“Оптимизация” по рецепту Яремчука дает следующие результаты:
TEST : Iterations/sec.
NUMERIC SORT : 740.76
STRING SORT : 156.94
BITFIELD : 3.0002e+08
FP EMULATION : 155.14
FOURIER : 16352
ASSIGNMENT : 22.964
IDEA : 4049.3
HUFFMAN : 1344.2
NEURAL NET : 32.535
LU DECOMPOSITION : 1106.5
==ORIGINAL BYTEMARK RESULTS==
INTEGER INDEX : 57.096
FLOATING-POINT INDEX: 44.914
Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==LINUX DATA BELOW===
MEMORY INDEX : 15.178
INTEGER INDEX : 13.025
FLOATING-POINT INDEX: 20.911
На первый, очень поверхностный взгляд, все вроде бы подтверждает вывод Сергея о малой эффективности оптимизации. Да, в чем то выиграли, в чем то проиграли… Игра свеч не стоит решит начинающий “оптимизатор” и будет абсолютно прав.
Для того, чтобы добиться максимального эффекта необходима к о м п л е к с н а я оптимизация: ”тюнинг” файловой системы, правка конфигурационных файлов, установка “свежего” gcc (см. Примечание 1 – важно) и glibc (и некоторая настройка), отсеивание “лишних” USE – флагов, удаление поддержки неиспользуемого оборудования и лишних локалей, обновление микропрограммы процессора, пересборка ядра “под железо”…
Итог этих мероприятий таков:
Вывод абсолютен и бесспорен. Компленсная оптимизация дает серьезный прирост производительности и улучшает “отзывчивость” системы, что немаловажно для комфортной работы. Скорость работы тяжелых приложений увеличилась на 10-100 процентов без потери стабильности.
Например, скорость архивирования Winrar под Winе на EXT4 разделе стала на 12 процентов выше (при одинаковых параметрах архивации) чем у того же Winrar работающего в windows 7 с NTFS (Win7 установлена на том же диске что и Linux). До оптимизации обе ОС шли “ноздря в ноздрю” как говорят лошадники.
Про 1С и говорить нечего. 7 версия, а тем более 8.2 имеют на линукс профит в среднем 30 процентов, а при формировании отчетов 40-70 процентов. Ну а при работе в конфигурации клиент – сервер преимущество линукс (при использовании SQL) достигает на некоторых операциях (например индексирование базы) 90 – 120 процентов.
VirtualBox так же получает существенное преимущество после пересборки с новыми параметрами. Скорость работы Windows больше либо равна скорости р е а л ь н о й системы (за исключением графики).
Производительность файловой системы, памяти и процессора на реальной и виртуальной системе полностью идентичны. Что позволяет сделать вывод: оптимизация и пересборка системы в некоторых случаях не просто желательна – она необходима.
Впрочем, если компьютер предназначен для офисного планктона и на нем установлен стандартный набор ПО, оптимизация смысла не имеет.
Практический рецепт оптимизации в следующей статье.
Примечание 1. Не всегда последняя версия gcc и glibc дают столь вожделенный профит. Я всегда использую последнюю версию компиляторов для изучения их новых возможностей и тестирования различных опций оптимизации и их комбинаций.
Если вернуться на gcc 4.5.3 и использовать (для моей системы, вам необходимо скорректировать размеры кэша первого и второго уровня и возможно некоторые другие опции) CFLAGS=”-O3 -fomit-frame-pointer -pipe -march=core2 -mtune=core2 –param l1-cache-size=32 –param l1-cache-line-size=64 –param l2-cache-size=1024 -mmmx -msse -msse2 -mssse3 -msse3 -mfpmath=both -fexcess-precision=fast -finline-functions -ftree-vectorize -fmerge-all-constants -fno-gcse -funroll-all-loops -g0 -Wno-all -mcx16 -msahf” будут такие результаты:
NUMERIC SORT : 792.48
STRING SORT : 359
BITFIELD : 3.0877e+08
FP EMULATION : 171.4
FOURIER : 24670
ASSIGNMENT : 30.364
IDEA : 4438.2
HUFFMAN : 1698.6
NEURAL NET : 39.971
LU DECOMPOSITION : 1299.6
=ORIGINAL BYTEMARK RESULTS==
INTEGER INDEX : 65.017
FLOATING-POINT INDEX: 42.936
Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==LINUX DATA BELOW==
MEMORY INDEX : 19.644
INTEGER INDEX : 13.660
FLOATING-POINT INDEX: 23.259
Ясно, что gcc4.6.2 сильно проигрывает gcc4.5.3 по “скоростным” показателям. Но, как показывает практика это явление временное, разработчики постоянно “допиливают” компилятор. Кроме того не факт, что мне удалось подобрать оптимальные параметры компилятора.
> компилятора почему то именуемых Яремчуком флагами.
похоже г-н Яремчук начитался мейкфайлов, там ведь частенько встречаются строки вида: CFLAGS, LDFLAGS, и т.п.
Вопрос терминологии всегда труден. сколько непонимания, когда пишут об одном, подразумевая другое… а вообще, и з у ч а т ь маны необходимо, иначе чтение мейкфайлов пустое занятие