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

Довелось оказаться пророком.

В комментариях к записи про анонс NVidia работающего OpenCL я предположил, что

Конечно, сейчас начнется, они вполне могут начать с драйверов для Линукса (или для 32-битной XP, что от меня столь же далеко)

И угадал, блин. Именно XP-32 и Linux-32. XP-шные бинарники на Висте не работают, несмотря на драйвер нужной версии, ругаются что не могут создать OpenCL context

А у меня Vista (32/64) и MacOS. Ну в Маке, ладно, обещали в заснеженном леопарде, а с вистой что? Руки же чешутся....

На закуску: согласно спекам OpenCL, его можно/нужно кормить исходником прямо на этом самом OpenCL (а это практически C). То бишь компилятор этого самого C сидит прямо в драйвере....

Интересно, насколько успешно это пойдет в индустрию, ведь получается что computing kernel засекретить не выйдет, можно же подсунуть приложению драйвер похожий на настоящий и почитать им исходника. Видятся мне OpenCL-обфускаторы.

У меня дофига работы происходит под VMWare и все полностью устраивало, кроме одного моментика: если засаспендить большую виртуальную машину (скажем с 4-мя гигами RAM), то хост-система (Vista x64) на довольно долгое время (минут 5) впадает в депрессию: реактивность понижается до нуля, на кнопки не реагирует, на мышь тоже, думает о чем-то своем.

Рабочей гипотезой было то, что саспенд пишет в файл, этот файл кэшируется в файловом кэше, а потом медленно и печально выливается на диск. Кэш при этом, естественно, тоже вымыт нафиг и любая мелочь (DLL-ки там) требует доставания с диска, что в свою очередь интерферирует с вышеуказанным выливанием на диск.

Помогли следующие настройки виртуальной машины (которые я ставил вовсе для другого):

MemTrimRate = "0"
sched.mem.pshare.enable = "FALSE"
mainMem.useNamedFile = "FALSE"

Саспенд теперь происходит долго (не единицы секунд, а десятки), но и в процессе саспенда и сразу после него другие программы работают

Drupal закричал мне, что у меня все устарело, нужно срочно апгредиться. Ну, как он любит. Поапгрейдил, в том числе и Comment Notify до версии 1.2, про натягивание которого на Postgresql я уже писал.

Поапгрейдив, имею вопрос: а что, в MySQL у поля написано NOT NULL, то там самостоятельно появится еще и DEFAULT ...? Потому что я не верю, что автор Comment Notify его совсем не тестирует, однако в нем:

• В таблице заводится крайне полезное поле, позволяющее не слать повторные нотификации если комментарий редактировался. Но оно NOT NULL и без DEFAULT.
• Вставка в эту таблицу делается без инициализации данного поля.

Патчить можно или сам модуль или процедуру инсталляции/апгрейда. Точнее, без правки .install никак не обойтись, поэтому вот минимальный патч, который превращает Comment Notify 1.2 в работающий под Postgresql (про MySQL ничего не знаю, не проверял):

comment-notify-1.2-install.diff.gz

Если вы переезжаете с Comment Subscribe, то нужно выполнить еще две SQL-команды (чтобы уже разосланные нотификации не рассылались повторно):

UPDATE comment_notify set notified=1;
UPDATE comment_notify set notify=1 where cid in (SELECT cid FROM z_com
mentsubscribe WHERE subscribe > 0);

Если вы используете LibRaw 0.6.14, то вам полезно было бы обновиться до 0.6.15. В предыдущей версии - обидная ошибка (переполнение) в генерации гамма-кривой.

Кроме того, в 0.6.15 и в 0.7-BETA5 инкорпорирована новая dcraw. Из существенного: улучшена и генерализована поддержка PEF-файлов Pentax.

качать отсюда

Вся эта история с PhantomOS интересна тем, что будучи еще vapourware оно всколыхнуло в людях пласты и позволило заглянуть в многочисленные бездны. Ссылок на дискуссии не даю, кому интересно - уже все видели.

Вместе с тем, dz продолжает утверждать, что всякий JIT на виртуальной машине рулит примерно не хуже, чем макроассемблер, известный нам под именем C/C++.

К сожалению, у него там в комментариях каптча даже для авторизованных пользователей, я через себя переступить не могу, приходится писать у себя и отдельно.

Да, действительно, судя по этим бенчмаркам Java временами рулит. Но что мы можем сказать про эти бенчмарки:

1. Они старые, 2003-й год, updated в 2004. Конечно, JIT за это время мог развиться на неимоверные высоты, однако и процессоростроители на месте не стояли, в i7, как я слышал, уже 3 SSE-юнита на ядро, а нормальное программирование SSE - это никакая не автовекторизация компилятором, а натурально фигурное выпиливание прямо на его ассемблере.
2. Что это за бенчмарки - мне с первого взгляда ясно не стало. Если это обращение матрицы 100x100, которая влезает в кэш L1 - это одно. Если это относительно большие данные, то плохие (не cache-aware) алгоритмы будут одинаково плохи, ибо cache miss будет стоить гораздо дороже, чем эффективность или неэффективность JIT. И, соответственно, выигрыши-провалы на тех графиках - это косвенное указание на то, попали или не попали в кэш.

Вместе с тем, быстрое пользование гуглом навело на реальную имплементацию FFT и реальные бенчмарки в сравнении не с каким-то левым sample/микробенчмаркой, а с кодом, который действительно доводится годами и считается оптимальным или близким к этому.

Решил по случаю воскресенья поапргейдить блоговый движок. C Movable Type 4.21 на 4.23.

Обнаружил неприятность: в поиске (включая поиск по тегу) пролюбили локализацию дат. То бишь, независимо от настроек блога, название месяцев пишутся английские, а формат даты тоже тамошний (Месяц, число год).

Спешу анонсировать LibRaw 0.7.0-Alpha-5

Эта альфа завершает цикл крупных изменений, затеянных в версии 0.7. В последней версии новая схема чтения, реализованная поверх C++-враппера, коий враппер каждый может заточить под свои нужды (одна из высказанных пользователями нужд, например, это извлечение метаданных из начала файла, который качается по PTP).

Как обычно, я очень заинтересован в фидбеке, особенно от разработчиков использующих LibRaw, но и просто проблемные файлы (если у вас что-то упало или не так раскодировалось) весьма интересны.

Все-таки общедоступность работающих контейнеров в STL (и не только в STL) - это зло. И добро, конечно, тоже, ибо можно левой ногой делать действительно сложные структуры данных, но результат временами доставляет.

Не хочу (сначала хотел, потом передумал) разбирать конкретный код, просто замечу, что возможность сделать список указателей на "слово с атрибутами", причем "слово с атрибутами" - содержит список основ с флагами, а каждая основа - это std::string - это отличная возможность.

Я бы такую сложную структуру руками запрограммировать бы быстро не сумел (да и не стал бы), а несколько дней выпиливал бы какое-нибудь zero-copy решение, которое копий строк не содержит (или по-возможности не содержит).

Отрываю ненужные куски от LibRaw (попавшие туда из dcraw) и никак не могу остановиться. В очередной версии сделал отключаемым пропускание RAW-данных через тоновую кривую.

Естественно, этот режим работы может быть интересен только тем, кто сам пишет RAW-конверторы или анализаторы RAW или подобные вещи. Ну и любопытствующим, ибо поставляемый в составе библиотеки пример unprocessed_raw (в версиях под Win32/Mac/Linux он лежит скомпилированным и готовым к использованию) способен эту опцию включить и показать ваши данные прямо как они из файла раскодированы.

Тоновая кривая есть не во всех камерах и форматах данных, среди распространенных это Nikon (compresssed NEF) и Sony A700/A900 (8-битный cRAW)

Достаточно очевидно, что от тоновой кривой нет вреда (или практически нет вреда) если выходное пространство шире чем входное, скажем из 8 бит делаем 12 (как оно у Sony). А вот если входное и выходное пространство имеют одинаковую битность, а кривая отлична от линейной, то мы обязательно потеряем градации. Такое должно случаться, насколько я понимаю, с 12-битными NEF-ами, было бы прикольно, если бы кто-то проверил.

Аналогично предыдущему анонсу просьба: если unprocessed_raw -N падает на каком-то файле, то я хочу этот файл пощупать.