Phenom’енальный шестичлен II: введение

Автор: Алексей Федорчук

Первое из этих вводных слов относится как раз к вере в цифры. На самом деле давние обитатели IT-мира, сохранившие ещё крохи здравомыслия, цифрам не верят ни на грош. Ибо с помощью тестов можно доказать, что люди ходят на руках, и люди ходят на боках, ничуть не хуже, нежели это делали в Весёлой башне дона Рэбы.

И потому все тесты выполняют одну из двух задач:

  • доказать кому-либо, что объект тестирования превосходит любые другие обычные стиральные порошки объекты, и
  • доказать самому себе, что объект тестирования был приобретён мной не зря.

Поскольку я не занимаюсь впариванием процессоров (или чего бы то ни было иного) кому бы то ни было, во всех последующих тестах преследовалась именно вторая задача. Да и то, весьма относительно: заряд положительных эмоций я получил уже на стадии сборки машины, установки системы и её первого запуска. Так что приводимая ниже цифирь не более чем отмазка перед самим собой. И ни устно, ни письменно, не буду утверждать, что всё это истина.

Тем не менее, в рамках всё той же отмазки, сделаем серьёзное лицо и зададимся вопросом: а какие пользовательские задачи нынче требуют нев… пардон, неописуемой мощи процессора? Точнее, на скорости выполнения которых эта не… ну вы понимаете… мощь могла бы сказаться. Ведь очевидно, сколько бы членов ядер не было бы у Phenom‘ена или сколько бы i не подставили в уравнение с Core, буковки в текстовом редакторе набираться быстрее не станут. Не говоря уже о мыслях, которые этими буковками выражаются.

Первая из задач, критичных к быстродействию процессора — всё та же компиляция. Да, ныне ей, кроме собственно разработчиков, систематически занимаются только записные дженедужники и суровые фришники (да и то проделывают это, как правило, в фоновом режиме). Но и пользователям более иных дистрибутивов время от времени приходится пересобирать ядро с изменением одного-двух параметров или компилировать пакет, отсутствующий в официальном репозитории. Правда, с каждым годом такие задачи возникают всё реже — но уж коль скоро возникли, обычно требуют действительно быстрого решения.

Вторая задача процессорно-зависимая задача, возникающая перед каждым пользователем — архивация и разархивация данных. Обычно это тоже вполне решается в фоновом режиме, но опять-таки бывают ситуации, когда надо хватать мешки, бо вокзал уходит.

Третья задача — это всякого рода кодирование звука и видео. Например, преобразование аудио-записей в flac-формат, каковой, при его открытости и нынешних дисковых пространствах, следует считать предпочтительным перед всеми остальными. Это — тоже типично фоновая проблема. Но вдруг вашему товарищу срочно захотелось послушать некую песенку?

Очевидно, что требования к быстродействию процессора при всех этих трёх задачах либо возникают достаточно редко, либо, как в случае с бэкапами, обусловлены собственным раздолбайством. Но есть группа задач, где, как при шести пиках, пользователя не спрашивают — его обязывают. И это — исполнение Java-кода и Javascript, а также флэш-анимации.

Разумеется, на это можно возразить: а вы не ходите на сайты, где вас понуждают к таким извращениям. Соглашусь — тем более, что обычно именно так и поступаю. Но бывают случаи, когда это приходится делать по долгу службы — например, отсортировывать ресурсы с порнухой (термин порнуха, в отличие от созвучного парнуха, я употребляю в отношении порнографии в собственном смысле слова). Или, например, при чтении сайта моего друга Владимира Родионова http://www.rwpbb.ru/ — первого в истории мироздания ресурса (и до сих пор одного из немногих), где флэш используется не украшательства ради, а исключительно представления контенту для. Не считая чисто порнографических сайтов, разумеется — те флэш-технологию освоили сразу по её появлении.

Разумеется, есть ещё задачи игровые и всякого рода 3D-графика, но о них я говорить не буду. Игры — это совсем отдельная история, от меня далёкая. А рендерингом трёхмерных сцен или расчётом спецэффектов для фильма Титаник на дому нынче мало кто занимается — на то специальные студии есть, со штатными сотрудниками. Которые работают на том, что им дают.

Так что на ближайших страницах я остановлюсь на измерении скорости компиляции и архивирования/разархивирования. К flac-кодированию обращусь, когда у меня появится очередной реальный объект для рассмотрения (пока всё, что я хотел и мог перегнать во flac, я уже перегнал). А вот с Java и Javascript — пока не придумал, как это можно измерить в условиях, приближенных к реальности. Буду признателен за конструктивные пожелания, только чур синтетику любого рода не предлагать.