Программирование

Умножение матриц, серия 4: NVidia G80, CUDA, CuBLAS и RapidMind

GPGPU или зачем все эти упражнения

Все предыдущие и более ранние мои упражнения были сделаны в качестве «подхода к снаряду», нужна была baseline для более интересной задачи: вычислений общего назначения на видеокарте.

Эта тема в последние год-полтора (а особенно, в последние полгода) очень сильно нагрелась. В то же время, в варианте от NVidia hardware и софт общедоступны, покупаешь видеокарту и развлекаешься.

Приборы и материалы: NVidia CUDA и прочие

Настоящий общедоступный сдвиг произошел меньше месяца назад: 6 февраля 2006 г. вышла вторая версия NVidia CUDA Toolkit, она же первая публичная (и первая более-менее работающая), она же версия 0.8.

Эта версия доступна всем желающим без подписания NDA, следовательно результаты тестов можно открыто публиковать.

Тема исследования, как обычно, умножение матриц. Задача очень простая алгоритмически, но со своими особенностями. В силу простоты задачи, изучать особенности одно удовольствие.

Рассматривались три доступных умножителя матриц:

  1. SGEMM в составе библиотеки CUBLAS.
  2. Тестовый пример от NVidia, который очень подробно разобран в документации.
  3. Реализация SGEMM от RapidMind.

Умножение матриц, серия 3: Woodcrest против Opteron, ACML против MKL, Goto BLAS против всех

Использованная в предыдущем тестировании библиотека численных методов Intel Math Kernel Library очевидно не является оптимизированной под процессоры AMD. Следовательно, нужно изучать альтернативы.

Альтернатив на сегодня видно три: это библиотека AMD Core Math Library от производителя процессора и две OpenSource библиотеки: Goto BLAS и ATLAS (Automatically Tuned Linear Algebra Software). Их и изучим.

Все бенчмарки были совершенно одинаковыми: заполнялись исходные матрицы (значениями от 0.0 до 1.0), затем вызывалась функция sgemm (для single precision) или dgemm (double), время выполнения которой и измерялось.

Кроме Dual Opteron 275, в руки попал еще сервер Dual Xeon 5140, показалось полезным сравнить две архитектуры.

Умножение матриц, серия 2: MKL против компилятора, single/double и int

Продолжаем умножать матрицы. Для начала смоделируем sgemm/dgemm: C=alpha*A*B+beta*C

Нас интересует, естественно, самый быстрый способ из изученных ранее, а вопрос заключается в разнице в скорости между float и double и разницы в скорости между простым кодом, написанным вручную, и библиотечной реализацией.

О перемножении матриц и прочих архитектурных заморочках

Осваиваю тут новую NUMA-архитектуру (пока не скажу какую, хотя многие уже в курсе). Хочется ее адекватно сравнивать с возможностями PC-CPU, т.е. опять гонять тесты. Начал с умножения матриц только на CPU.

Если оставить в стороне продвинутые алгоритмы Штрассена и Копперсмита с Виноградом, ограничившись классическим подходом с умножением "строка на столбец", то умножение матриц вполне прямолинейно: C(i,j) += A(i,k)+B(k,j) С другой стороны, входные матрицы могут быть транспонированы (одна или обе). При этом меняется pattern доступа к памяти, за счет чего ожидается некоторая разница в производительности.

Рассматривая результаты Linpack, я ожидал получить разницу между «плохим» и «хорошим» паттерном в разы. Результат превзошел все ожидания, получилась разница на полтора порядка.

Кросспост из MT в LJ

Продолжаем патчить MovableType.

Многим, вероятно, удобнее читать мои упражнения через френдленту ЖЖ. Следовательно, нужен кросспост туда. Коллективный разум предлагает два решения:

  • ljcrosspost — сделан неудобно, предполагает публикацию через выполнение тега, что означает перепубликацию при любой перевыкатке отдельных статей. Не понравилось.
  • MTLJpost сделан более человечно, публикация происходит при нажатии кнопки Save в редакторе т.е. вместе с trackback pings, нотификациями блог-поисков и еще один RPC call погоды не сделает.
Берем и ставим второй. Выясняется:
  1. Машинка глючит, если нет картинки (юзерпика), соответствующего категории. Но править это соответствие после каждого редактирования категорий - мучительно.
  2. Не хватает пары мелочей:
    • постинга тегов в ЖЖ
    • запрещения комментариев (с комментариями хочется всех загнать к себе)
Впрочем, пять минут работы напильником и готов очередной патч. Этот патч:
  1. Передает в ЖЖ теги
  2. Чуть лучше разбирается с ситуацией, когда не найден юзерпик
  3. запрещает комментарии.
Если запрещение комментирования не нужно, то из патча нужно удалить строчку
+   $lj->Setprop_nocomments($event,1);
upd: после ряда экспериментов, я матчинг юзерпика и категории вообще убрал нафиг. Странное оно и дикое

Темплейты MovableType

Меняя, в очередной раз, много темплейтов MT, задумался об более человечной их структуре.

Я уже писал, что темплейты MT расчитаны скорее на секретаршу, чем на программистов продвинутых пользователей. В то же время, позиционируется MT на продвинутый рынок. Даже возможность прицепить к блогу весь набор темплейтов одним движением руки уже сильно бы полечила, появились бы генераторы темплейтов на препроцессоре и т.п.

На мой вкус, человеческая темплейтная система должна строиться от других принципов:

  • Нужны layout-темплейты. Т.е. задание структуры (количество колонок, их состав и пр.) и общих по всему блогу элементов (header, footer, навигация) в одном месте. Конечно, в сложных случаях layout-ов будет много, но почти гарантированно один layout распространяется больше чем на одну страницу. Редактировать одно и то же в нескольких местах - глупо.
  • Нужны блоковые темплейты. Очевидный пример блока - это представление первых строк записи в индексах. Оно повторяется во всех архивах, в результатах поиска и так далее. Редактировать такую кучу мест - не менее глупо, чем править заголовки по всему блогу

Русификация MovableType

Русификация MovableType состоит из таких шагов
  1. Русификация дат
  2. Русификация имен файлов для dirify
  3. Перевод темплейтов и системных сообщений
Первые два пункта требуют правок кода, каковые правки и были сделаны. Все действия производились над MovableType 3.33

MovableType - сосет

Попытка разобраться с MovableType оставила двойственное впечатление:
  • Штука, несомненно, очень хорошая, вложена масса труда
  • Но при этом, сосет не нагибаясь
и ведь чем ближе рассматриваешь, тем больше хочется ругаться. Ужос просто!

Postgresql 8.2, UTF8 и русские буквы

В отличие от PostgreSQL 8.1.x, табличка преобразования UTF8<—>CP1251 уже нормальная, € там имеется.

Однако сама идеология осталась порочной, мне не нужны ошибки при попытке конверсии, я хочу их маскировать. Впрочем патч от 8.1.5 вполне подходит и к 8.2

Postgresql 8.1.x и UTF-8

В PostgreSQL начиная с версии 8.1.4 ужесточили правила конверсии из UTF-8 в однобайтовые кодировки. Если раньше при неконвертируемом символе было предупреждение, которое попадало в лог (или в приложение, если оно читало Warnings) и все работало, то сейчас неправильный символ приводит к ошибке и запрос не выполняется.

Тут же выяснилось, что у этих криворуких уродов таблица преобразования из/в windows-1251 неверная, там пропущен символ €. Пришлось, как водится, править.

Pages

Subscribe to Программирование