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