Все предыдущие
и более ранние мои упражнения были сделаны в качестве «подхода к снаряду», нужна
была baseline для более интересной задачи: вычислений общего назначения на видеокарте.
Эта тема в последние год-полтора (а особенно, в последние полгода) очень сильно нагрелась.
В то же время, в варианте от NVidia hardware и софт общедоступны, покупаешь видеокарту
и развлекаешься.
Приборы и материалы: NVidia CUDA и прочие
Настоящий общедоступный сдвиг произошел меньше месяца назад: 6 февраля 2006 г. вышла
вторая версия NVidia CUDA Toolkit, она же первая публичная (и первая более-менее работающая), она же
версия 0.8.
Эта версия доступна всем желающим без
подписания NDA, следовательно результаты тестов можно открыто публиковать.
Тема исследования, как обычно, умножение матриц. Задача очень простая алгоритмически, но
со своими особенностями. В силу простоты задачи, изучать особенности одно удовольствие.
Рассматривались три доступных умножителя матриц:
SGEMM в составе библиотеки CUBLAS.
Тестовый пример от NVidia, который очень подробно разобран в документации.
Использованная в предыдущем тестировании
библиотека численных методов 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, показалось полезным
сравнить две архитектуры.
Продолжаем умножать матрицы. Для начала смоделируем 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, я ожидал получить разницу между «плохим» и «хорошим» паттерном в разы. Результат превзошел все ожидания, получилась разница на полтора порядка.
Многим, вероятно, удобнее читать мои упражнения через френдленту ЖЖ. Следовательно, нужен кросспост туда. Коллективный разум предлагает два решения:
ljcrosspost — сделан неудобно, предполагает публикацию через выполнение тега, что означает перепубликацию при любой перевыкатке отдельных статей. Не понравилось.
MTLJpost сделан более человечно, публикация происходит при нажатии кнопки Save в редакторе т.е. вместе с trackback pings, нотификациями блог-поисков и еще один RPC call погоды не сделает.
Берем и ставим второй. Выясняется:
Машинка глючит, если нет картинки (юзерпика), соответствующего категории. Но править это соответствие после каждого редактирования категорий - мучительно.
Не хватает пары мелочей:
постинга тегов в ЖЖ
запрещения комментариев (с комментариями хочется всех загнать к себе)
Меняя, в очередной раз, много темплейтов MT, задумался об более человечной их структуре.
Я уже писал, что темплейты MT расчитаны скорее на секретаршу, чем на программистов продвинутых пользователей. В то же время, позиционируется MT на продвинутый рынок.
Даже возможность прицепить к блогу весь набор темплейтов одним движением руки уже сильно бы полечила, появились бы генераторы темплейтов на препроцессоре и т.п.
На мой вкус, человеческая темплейтная система должна строиться от других принципов:
Нужны layout-темплейты. Т.е. задание структуры (количество колонок, их состав и пр.) и общих по всему блогу элементов (header, footer, навигация) в одном месте. Конечно, в сложных случаях layout-ов будет много, но почти гарантированно один layout распространяется больше чем на одну страницу. Редактировать одно и то же в нескольких местах - глупо.
Нужны блоковые темплейты. Очевидный пример блока - это представление первых строк записи в индексах. Оно повторяется во всех архивах, в результатах поиска и так далее. Редактировать такую кучу мест - не менее глупо, чем править заголовки по всему блогу
В отличие от PostgreSQL 8.1.x, табличка преобразования UTF8<—>CP1251 уже нормальная, € там имеется.
Однако сама идеология осталась порочной, мне не нужны ошибки при попытке конверсии, я хочу их маскировать. Впрочем патч от 8.1.5 вполне подходит и к 8.2
В PostgreSQL начиная с версии 8.1.4 ужесточили правила конверсии из UTF-8 в однобайтовые кодировки. Если раньше при неконвертируемом символе было предупреждение, которое попадало в лог (или в приложение, если оно читало Warnings) и все работало, то сейчас неправильный символ приводит к ошибке и запрос не выполняется.
Тут же выяснилось, что у этих криворуких уродов таблица преобразования из/в windows-1251 неверная, там пропущен символ €. Пришлось, как водится, править.