Примерно к 2001 году вопрос с кодировками для русскоязычных WWW-сайтов казался полностью решенным: все сколько-нибудь распространенные браузеры научились кодировке Windows-1251 и только ее можно было оставить на сайтах (выдавая правильный Content-Type)
Но жизнь на месте не стоит и появилась новая беда: UTF-8. Никаких проблем с самой кодировкой нет - все поддерживают, работать несложно, можно писать многоязыковые документы.
Сейчас расцветает динамика, которую рисуют разными видами яваскрипта
Продолжаем умножать матрицы. Для начала смоделируем sgemm/dgemm:
C=alpha*A*B+beta*C
Нас интересует, естественно, самый быстрый способ из
изученных ранее, а вопрос заключается в разнице в скорости между float и double и разницы в скорости между простым кодом, написанным вручную, и библиотечной реализацией.
Рассматривая результаты нового пересчета pagerank (не закончилось) - для каких страниц оно произошло, а для каких - нет, удалось довольно точно определить дату, на которую заморожено состояние интернета для пересчета.
Осваиваю тут новую 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 распространяется больше чем на одну страницу. Редактировать одно и то же в нескольких местах - глупо.
Нужны блоковые темплейты. Очевидный пример блока - это представление первых строк записи в индексах. Оно повторяется во всех архивах, в результатах поиска и так далее. Редактировать такую кучу мест - не менее глупо, чем править заголовки по всему блогу