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

Выложил (на то же место) новую версию программы для скругления уголков (я про неё писал в сентябре).

Изменения следующие:

• появился новый параметр ключа —width, можно указать «auto» или просто «a» и программа не будет масштабировать картинку.
• я постарался улучшить оптимизацию JPEG изображений встроенной программой jpegtran: теперь я указываю специальные профили из программы jpegcrush и задаю ключ «grayscale», если JPEG чёрно-белый (сканирую каждый пиксель и смотрю серый ли он).
• появилось «пасхальное яйцо».
  Добавлено позже: нашёл какую-то ошибку с определением серых изображений. Пожалуйста, пока не качайте эту версию.

Ещё позже: поправил. Опечатка в одном месте.

Решил попробовать уместить какую-нибудь игру с использованием тега CANVAS в 1КБ. После всех оптимизаций, который заняли у меня вдвое больше времени, чем написание игры, получилась несложная игрушка в 1020 1023 байта (то есть на четыре один байт меньше, чем килобайт).

Цель — подбить своим «танком» как можно больше вражеских ракет. Управление — курсорными клавишами, стрелять пробелом. Даётся три жизни, за каждые 20 сбитых ракет жизнь добавляется, если ракета долетит до вашей стороны или коснётся танка, жизнь теряется. Для рестарта игры просто перезагрузите страницу.

Должно работать везде, где поддерживается тег CANVAS, я тестировал в «Опере» 11, «Хроме» 10 и FF 3.6.13.

Have a fun!

Попробовал порисовать на теге CANVAS, хотелось хоть что-то попробовать нарисовать, а то совсем забывать начинаю как это делается. Нарисовал очень простой лист дерева, без контура.

<canvas width="500" height="240"></canvas>
<script type="text/javascript">
(function (c) {
    var img = c.createImageData(500, 240);

    var putPixel = function (x, y, c) {
        var index = (x + y * 500) << 2;

        for (var i = 0; i<4; i++) {
            img.data[index+i] = c[i];
        }
    };

    var x = 0, y = 0, color, leaf, idx,
    k = [
          [ 0.00, 0.00, 0.00, 0.16, 0.00, 0.00 ],
          [ 0.85, 0.04,-0.04, 0.85, 0.00, 1.60 ],    
          [ 0.05,-0.26, 0.23, 0.22, 0.00, 1.60 ],
          [-0.15, 0.30, 0.26, 0.24, 0.00, 0.44 ],
    ];

    for (var i = 0; i<200000; i++) {
        leaf = Math.random();

        if (leaf <= 0.010) leaf = 0; else
        if (leaf <= 0.860) leaf = 1; else
        if (leaf <= 0.930) leaf = 2; else    
        leaf = 3;

        x = x * k[leaf][0] + y * k[leaf][1] + k[leaf][4];    
        y = y * k[leaf][2] + y * k[leaf][3] + k[leaf][5];    

        putPixel(parseInt(y * 55), 120 - parseInt(x * 40), [10, 100, 20, 255]);
    }
    
    c.putImageData(img, 0, 0);
})(document.getElementsByTagName('canvas')[0].getContext('2d'));
</script>

Похоже весь opensource служит одной цели — чтобы мы, когда покупаем программы, могли сравнить и увидеть за что платим.

Скачал бесплатный графический редактор ГИМП, чтобы подредактировать пару фотографий. В диалоге открытия файла, чтобы ГИМП показал мне миниатюру файла, мне предлагается кликнуть сначала на файл, потом на место, где должна появиться миниатюра! Два клика и куча движений мышью на каждый из 120 файлов, в котором я хочу найти нужный.

И вот так там всё.

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

Как я уже писал, мне понравилась библиотека RE2, я даже скомпилировал её и посмотрел, к сожалению, оказалось, что она использует треды, а в PHP с этим не очень (не все модули PHP thread safe, поэтому чаще всего PHP собирается без поддержки тредов).

Я уже начал смотреть другие библиотеки, когда Алексей Захлестин напомнил мне про модуль PHP Multibyte String (функции mb_*), который содержит в себе движок регулярных выражений Oniguruma.

Я всегда плохо относился к этому движку, так как считал, что у него очень бедные возможности для работы с UTF-8, так как там не работают \p, \P и есть ещё пара недостатков (возможно они имеют место из-за того, что в PHP используется версия 4.7.1, тогда как последняя 5.9.2).

Сегодня я присмотрелся к движку получше. Конечно, PCRE он не заменит, но некоторых случаях вполне сможет его подменить как быстрый аналог, только надо применять несколько правил (речь идёт о версии 4.7.1, которая в PHP):

Во-первых, модификатор „i“ не действует ни на какие буквы, кроме латинских, я перебрал весь Unicode, чтобы в этом убедиться.

Во-вторых, \b и \B внутри […] относятся к backspace, а не к word boundary, а \h и \H к hex digit, а не к horizontal whitespace.

В-третьих, не работают \p и \P, зато (хоть какая-то замена) с UTF-8 работают :…: (всякие там :space: и прочие).

В-четвёртых, есть синтаксис [a-w&&[^c-g]z], то есть «&» надо экранировать внутри диапазонов.

В-пятых, части синтаксиса PCRE просто нет, например, нет рекурсии, условных регулярок, но тут уже надо обращаться к документации.

Я погонял тесты, сравнивал PCRE в режиме полном UTF-8 (с «глаголом» UCP) и Oniguruma, по результатам последний в 4…4,5 раза быстрее:

bolk-dev ~/regexp-benchmark $ php test.php
PCRE Full UTF-8: 1.0458080768585
Oniguruma:         0.24942803382874

Много читал с утра о библиотеках регулярных выражений. Хочется найти такую, чтобы работала с UTF-8, была быстрой и мощной. Без особой надежды поискал в интернете обзоры библиотек и нашёл статью «Benchmark of Regex Libraries».

Автор сравнивает по скорости обработки три регулярных выражения, правда довольно несложных, на приличного объёма тексте. Но даже и на этих несложных регулярках есть явные аутсайдеры — например, Python (хотя другие тесты дают другие результаты).

Жалко автор не составил такую же таблицу для режима UTF-8, там производительность может сильно отличаться.

Например, мне из таблицы понравилась библиотека RE2, она показывает хорошие результаты, при этом в последнем тесте вырывается далеко вперёд. Правда в ней не реализована часть синтаксиса (например, нет backreferences), но это я бы пережил. А вот насколько она эффективная в режиме UTF-8 — вопрос (вопрос тем более актуален, что библиотека показывает примерно равную с PCRE эффективность, а PCRE с UTF-8 работает медленно).

Кстати, скрипты для тестирования доступны для скачивания. Можно попробовать переключить пару библиотек в UTF-8 и посмотреть что с ними будет.

Добавлено позднее: раз доступны скрипты тестирования, я решил посмотреть не находится ли уже RE2 в режиме UTF-8 (у неё это режим по-умолчанию), оказалось, что находится:

RE2 p(argv[1]);
buf = (char*)calloc(BUF_SIZE, 1);
while (fgets(buf, BUF_SIZE - 1, stdin)) {
        ++l;
        for (q = buf; *q; ++q); if (q > buf) *(q-1) = 0;
        if (RE2::PartialMatch(buf, p))
                printf("%d:%sn", l, buf);
}
free(buf);

Чтобы выключить режим UTF-8, нужно использовать константу RE2::Latin1, а её в коде нет. Значит, RE2 работает в режиме UTF-8. Интерееесно.

Владислав Шкодин написал статью на «Хабре», где рассказал как ему удалось победить старый баг в движке WebKit — если вставить SVG с прозрачным фоном в тег OBJECT, что «Сафари» и «Хром» (до 8-й версии) зальют фон белым цветом.

Решение очень простое. Прямо внутри файла SVG, после тега svg нужно написать следующее:

<style>
    svg { -webkit-background-clip: text; }
</style>

Как я уже писал, сегодня ночью я наткнулся на вариант измерения длины UTF-8 строки, написанный с применением ассемблерных иструкций SSE2. У этого кода есть недостаток — на каких-нибудь ARM он не заработает, с другой стороны, у меня нет такой потребности, запускать PHP на этих процессорах.

Сегодня я почистил код (в PHP известна бинарная длина строки, поэтому я убрал проверки на символ с кодом ноль и соптимизировал код), сгенерировал таблицу HammingWeight, которая отсутствует в коде автора и перевёл проверку в двух крайних циклах на подобную таблицу.

Потом это всё скомпилировал и погонял тесты.

Сначала я получил очень странные результаты и только потом понял что случилось. В общем, разрыв в скорости функций (mb_strlen и той, что на SSE2) тем больше, чем ближе тестируемая строка к однобайтовой. Чаще всего, с SSE2 быстрее встроенной в PHP в 5—8 раз:

thasonic-dev ~/uni/futf-0.1 $ php ../test/test_strlen.php | sort -k2 -t:
SSE2 UTF-8:                 0.025604963302612
mb_strlen:                   0.15917205810547
strlen/utf8_decode:   0.62052989006042

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

В общем, о приросте в 24 раза остаётся только мечтать.

Похоже, это почти предел на сегодняшний момент. Единственная возможность ускорения, которая приходит в голову — использовать GPU на видеокарте. Например, видеокарта GTX275 управляется с 16000 потоков (!), что позволяет подсчитать длину строки порциями по 15,5КБ!

Но это больше из разряда задач-головоломок, чем чего-то практического — у нас на серверах таких видеокарт нет и вряд ли появятся, пока интерпретаторы-флагманы не заявят у себя поддержку GPU.

Так что оставлю как есть, займусь переписываем substr в SSE2, а потом выложу всё в открытый доступ.

Добавлено позднее: в следующем году Intel и AMD выпустят процессоры, поддерживающие набор комманд AVX, интересно там то, что размер регистров SIMD (которые используются и в SSE) расширяется до 256 бит. То есть через годик-другой можно будет читать строку сразу по 32 байта за раз.

Из кода быстрой функции strlen для UTF-8 можно получить функцию substr. Николай Захаров, который работает со мной в группе внутренних сервисов, переделал strlen в substr.

Я вкомпилил эту функцию в PHP, помог найти ошибки и отладить и сделал замеры:

bolk-dev ~/uni/futf-0.1 $ php ../test/test_substr.php  | sort -k2 -t:
Fast UTF-8: 0.18010711669922
mb_substr:  0.87068700790405

Разница примерно в 4 раза. Я ещё попробовал отрезать строку через функцию preg_match, сравнимо по скорости с mb_substr, но медленнее и есть ограничение — квантификатор preg_match не захватывает больше 65535 символов.

Добавлено позднее: после того как мы отладили эту функцию, я вспомнил про команды ассемблера SSE — это наборы команд (сейчас их пять — SSE1, 2, 3, 4.1 и 4.2), которые оперируют восемью регистрами размером 128 бит.

Как я рассказывал, самый быстрый алгоритм для strlen, который я нашёл, работает следующим образом: сначала указатель на строку первым циклом выравнивается по границе 4 или 8 байт (в зависимости от архитектуры процессора), чтобы процессор смог быстрее читать дальше, потом, работая сразу с числом длиной 4 или 8 байт, одной операцией подсчитывается сколько в выделенной строке содержится начальных байт символов.

Если внутри нашего рабочего участка встречается символ с кодом ноль (признак конца строки), то происходит выход в последний цикл, который занимается тем, что просматривает побайтно получившийся «хвост».

128-битные регистры, соотвественно, позволяют читать участки сразу по 16 бит, что должно дать солидную экономию на длинных текстах. Хороши они ещё и тем, что многие операции позволяют работать с регистром, как с набором байт, производя групповые операции над каждым байтом в регистре.

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

Нашёл в интернете тест для таких функций, включил туда найденную и сделал замеры:

C:\MinGW\bin\test.exe
cp_strlen_utf8:          0.105706
cp_strlen_utf8_sse2: 0.030002

В 3,5 раза обгоняет предыдущий вариант, то есть, смею надеяться, обгонит встроенную в PHP функцию примерно в 24 раза. Завтра попробую.

Немаловажно, что даже на машинах с архитектурой 32 бита рассматриваемый вариант покажет ту же скорость, что и на машинах 64 бита.

47. КуМир — очередной неинтересный язык программирования «Комплект учебных Миров или Миры Кушниренко».

В 1995 году «КуМир» (о ужас!) был рекомендован Министерством образования РФ в качестве основного учебного материала по курсу «Основы информатики и вычислительной техники» на основе учебника А. Г. Кушниренко, Г. В. Лебедева и Р. А. Свореня.

Совершенно неинтересно про него рассказывать, если честно, хотя среда разработки очень неплоха в плане диагностики ошибок.

Добавлено позднее: Язык оказался диалектом или реализацией уже известного мне языка «РАЯ».

| написал Евгений Степанищев bolknote.ru

алг песня про пиво
нач
    цел пиво
    нц для пиво от 99 до 1 шаг -1
        вывод сколько пива(пиво), ' on the wall, ', нс
        вывод 'Take one and pass around,', нс
        вывод сколько пива(пиво-1), ' on the wall.', нс, нс
    кц
    вывод "No more bottles of beer...", нс
    вывод "Go to the store and buy some more...", нс
    вывод "99 bottles of beer."
кон

алг лит сколько пива(цел пиво)
нач
    если пиво = 0 то
        знач:="No"
    иначе
        знач:=цел_в_лит(пиво)
    все

    знач:=знач + ' bottle'

    если пиво <> 1 то
        знач:=знач+'s'
    все
кон

Очень давно хотел посмотреть во что превратился Perl6 за те годы, что я его не видел. Посвятил четыре часа своей жизни на изучение. Что я хочу сказать, богатейший язык при беднейшей документации. Синтаксис, как и положено языку Perl, позволяет сделать одно и то же миллионом различных способом, 99% из которых нечитаемы.

Я в восторге.

К сожалению, не всё описанное в документации работает (например, lvalue-метод substr класса Str у меня работать отказался), а кое-что работает ужасно медленно (я попытался в своём коде использовать замены через regexp, не дождался окончания работы программы).

Сегодня на «Хабре» появилась интересная статья, где описывался нормальный алгоритм Маркова для деления двух целых чисел с точностью 4 знака после запятой в унарной системе счисления. То есть: |/|||| = 0.25, ||/||| = 0.6666 и так далее.

Замены в статье уже описаны, осталось реализовать алгоритм (в заменах я поменял пустую строку на два апострофа: ’’). Привожу с сокращением списка замен:

use v6;

my $входная = '||/|||';
my @замены  = <%* *% %| %* *| ** |* t t* *t …тут просто замены через пробел… p^ '' p .FIN _ .FIN>;

loop {
    my $нашёл = Bool::False;
    my $начтонадо;

    for @замены -> $что, $начто {
        my $где = $входная.index($что);

        if defined $где {
            $нашёл = Bool::True;

            given $начто {
                when <''>  {
                    $начтонадо = ''
                }                                
                when /FIN/ {
                    ($начтонадо = $начто) ~~ s[FIN] = '';
                    $нашёл = Bool::False;
                }
                default    {
                    $начтонадо = $начто
                }
            }

            #`{
                К сожалению, lvalue метод не сработал:
                $входная.substr($где, $что.chars) = $начтонадо;

                выдаёт «cannot modify readonly value
            }

            $входная = $входная.substr(0, $где) ~ $начтонадо ~ $входная.substr($где + $что.chars);
            say $входная;
            last;
        }
    }
        
    last unless $нашёл;
}
END {
    $входная.say;
}

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

Меня очень радует нативная поддержка Unicode, которая реализована куда глубже, чем в Python, к примеру, конструкция языка >> может быть заменена на », в качестве ограничителей (например, многострочного комментария) можно использовать символы 「 и 」, а say "Ⅰ".succ правильно выдаёт Ⅱ).

Наворотили в языке много. Отдельной строкой — регулярные выражения. Синтаксис совсем другой, мне кажется более продуманным, чем тот, что сейчас в Perl5 (и тем более в PCRE), возможностей стало больше, а выражения выглядят аккуратнее.

Поговорил с одним из разработчиков PHP по поводу судьбы PHP6, самое ожидаемое изменение которого — переход на юникодные строки. Так вот Антон Довгаль рассказал, что проект, по сути, заброшен. Те несколько человек, которые занимались проектом, либо уволились, либо потеряли к нему интерес и сейчас считается, что поддержка юникодных строк в языке не так уж и нужна.

На примере своего опыта разработки и перевода проектов на PHP на UTF-8, скажу это не так. В Пайтоне, где таких проблем нет, работать гораздо проще и приятнее.

То, что в PHP приходится для поддержки Юникода работать с UTF-8, а не с UTF-32 сильно снижает производительность всех строковых операций. И добро бы, если бы для всех функций были юникодные аналоги, так это ведь не так.

Работать в PHP с UTF-32 нельзя, если вы собираетесь использовать регулярные выражения: библиотека PCRE, предназначенная для работы с регулярными выражениями, понимает только две кодировки: latin-1 (по всей видимости) и UTF-8. Кроме того, функции, использующие локаль или ICU так же работают только с UTF-8.

Если бы этот язык нативно поддерживал UTF-32… Мечты-мечты.

Я потихоньку буду писать как получается оптимизировать самые важные функции работы с UTF-8 в PHP. Оформлять буду как продолжение своей эпопеи перевода наше внутренней «Вики» на UTF-8 (в ближайшее время добавлю оглавление).

Сейчас, после перевода «Вики» мы столкнулись с тем, что некоторые операции занимают непозволительно много времени. Кое-какие проблемы решаются моими итераторами для строки (прямым и обратным), но и другие оптимизации приходится делать.

Простые оптимизации я уже применил: выкинул из класса UTF-8 проверки на self::ON (по этой константе я определял включена ли в проекте поддержка UTF-8, сейчас в ней необходимости уже нет) и сделал другие микрооптимизации, теперь пора посмотреть на методы моего класса UTF.

Одна из самых частоиспользуемых функций — strlen, которая определяет длину строки. Я всегда считал, что самый быстрый способ подсчитать длину UTF-строки в PHP, это вызывать strlen(utf8_decode(…)).

Мои тесты показывают что это не так. Самый быстрый способ (по крайней мере в PHP 5.3.2) — это mb_strlen, strlen/utf8_decode — на втором месте, потом идёт sizeof+preg_split, а самый медленный — iconv_strlen.

Для интереса я вкомпилил в PHP функцию для быстрого подсчёта длины строки в UTF-8, найденную в интернете, выигрыш по сравнению с mb_strlen незначителен:

bolk-dev ~/uni/ $ php ../test/test_strlen.php | sort -k2 -t:
Fast UTF-8: 0.68232107162476
mb_strlen: 0.88710689544678
strlen/utf8_decode: 1.5211808681488

Это тысяча итераций на файле в 400КБ.

Я оставил функцию mb_strlen.

Добавлено позднее: другая быстрая функция дала ещё худший результат: 0,79, против прежнего варианта в 0,68.

Добавлено ещё позже: а вот третья функция показала действительно впечатляющие результаты:

bolk-dev ~/uni/ $ php ../test/test_strlen.php | sort -k2 -t:
More Fast UTF-8:  0.12948799133301
mb_strlen: 0.88710689544678
strlen/utf8_decode: 1.5211808681488

Это уже дело — она почти в 7 раз быстрее лучшего результата PHP.

Вкратце, алгоритм такой: строка циклом выравнивается по границе четырёх (на 64-битных системах — 8) байт, далее читается сразу по четыре (или восемь) байт и внутри каждого кусочка одним выражением считается сколько там байт, с которых начинается символ. Поэтому на моей 64-битной системе семикратный выигрыш (на 32 битах будет примерно в три раза).

Добавлено через несколько дней: есть и ещё более быстрая функция.

Если бы я сейчас на ночь глядя не решил почитать по диагонали спецификацию тега LINK, то так, наверное, никогда в жизни бы и не узнал о существовании мета-тега «Default-Style», между тем, этот трюк описан ещё в HTML 4.01.

Если у вас подключены несколько таблиц стилей к одному документу, вы можете дать им имя, прописав его в атрибуте «title», и выбрать его через мета-тег или HTTP-заголовок. Например:

<head>
<style type="text/css" title="right">
body {
  background: blue;
}
</style>

<style type="text/css" title="wrong">
body {
  background: red;
}
</style>

<meta http-equiv="Default-Style" content="right" />
</head>

Работать должен только стиль с именем «right» (можно дать и русские имена). Слово должен я выделил, потому что это стандарт. Жизнь, как всегда, богаче.

Я проверил на браузерах, которые у меня есть, в «Опере» 11 RC3 и Internet Explorer 9 beta это не работает, работает в Firefox 3.6.12, Safari 5 и Chrome 9.0.597.19, можете проверить свой браузер, фон должен быть синим.

Можно из этого сделать своеобразный CSS-хак.

Добавлено: во встроенном браузере на моём «Нексусе» работает («Андроид» 2.2.1), в Firefox 2.0 и Chrome 5.0.375.125 — тоже.

Добавлено ещё позже: в комментарях меня поправляет Денис Попов: по стандарту если заданы несколько тегов LINK, задающих стили с title, то выбирается первый («Опера» и «IE» нарушают стандарт уже в этом месте, я проверил), если не задан специальный META-тег, о котором я рассказывал.

Прочитайте комментарий, там есть немаловажные подробности.

Как-то, много лет назад, партнёр по бизнесу показал исходник первой страницы сайта студии Лебедева. Он был очень озадачен остроумной шуткой — исходник представлял из себя одну строку HTML-комментария и, на первый взгляд, больше ничего. Я быстро догадался, что надо было всего лишь прокрутить текст вниз — за переводами строки прятался остальной код.

Если бы мне сегодня показали исходник страницы (будет видно только в «Опере» и «FireFox»), который я встретил сейчас на «Хабре», я был бы озадачен куда больше.

Кода у этой страницы просто нет. Ларчик открывается (в «Опере» и FF) просто: есть такой RFC 5988, озаглавленный «Web Linking», где описан способ подключать в документ различные ресурсы прямо через HTTP-заголовок.

Идея проста: подключаем через заголовок CSS для пустой страницы и внутри CSS уже формируем то, что нужно (текст можно писать через свойство «content»). HTTP-заголовок может выглядеть, например, так:

Link: </pathto/magic.css>;rel=stylesheet

В WebSocket (протоколе) нашли дыру, в этой связи «Опера» 11 и FF 4 отключат у себя реализацию этого протокола до решения проблем безопасности.

Добавлено: подробный обзор проблемы есть на «Хабре»

Если я когда-нибудь задумаю писать свою систему Wiki, то у меня есть уже для неё красивое название — WikiNG (Wiki New Generation).

Век живи, век учись.

Не знал, что в MySQL есть своеобразный typecast для строк — можно объявить любой collate для строки вот таким простым синтаксисом (я всега пользовался «’строка’ COLLATE latin1_danish_ci» и ему подобным):

SELECT n'текст' -- эквивалентно следующей строке
SELECT _utf8'текст'

SELECT _binary'aaa' = _binary'AAA' -- эти строки не равны (бинарное сравнение)

Заодно, после перевода проекта на UTF-8, стали появляться первые проблемы с новой библиотекой PCRE. Как я писал, для того, чтобы в PCRE некоторые комбинации работали как положено, мне перешлось перейти на версию 8.10.

Для этого я собрал специальный модуль YGX, это тот же extension PCRE, только с новой версией библиотеки (кстати, модуля пришлось делать два — для PHP 5.2.xx и 5.3.xx отдельно).

Теперь, когда у меня в PHP два вида функций — preg_* (старая PCRE) и ygx_* (новая PCRE 8.10), можно сравнивать поведение обоих. Вот первый небольшой тест:

bolk-dev ~/wiki $ php -r 'var_dump(ygx_replace("/a?/u", "", "abc"));'
string(2) "bc"
bolk-dev ~/wiki $ php -r 'var_dump(preg_replace("/т?/u", "", "тест"));'
string(4) "ес"
bolk-dev ~/wiki $ php -r 'var_dump(ygx_replace("/т?/u", "", "тест"));'
NULL

Как видно, PCRE 8.10 в последнем случае выдаёт NULL. Такое поведение похоже на баг. Выражение, конечно, довольно бессмысленное, но на практике оно встретилось в составе более сложного.

Чтобы в этом случае не получался NULL (хотя правильного результата всё равно не будет), можно поставить «глагол» «(*FAIL)» (это специальное значение, который ни с чем не совпадает):

bolk-dev ~/wiki $ php -r 'var_dump(ygx_replace("/(*FAIL)т?/u", "", "тест"));'
string(8) "тест"

Стоит ввести в выражение хоть что-то, что не содержит квантификатора «ноль или…» и NULL исчезает.

Что делать в этом случае, кроме как переписать регулярное выражение полностью, я пока не придумал.

Обсуждается возможность аппаратного ускорения PHP, точнее использования в коде возможностей GPU, в данный момент речь идёт о библиотеке CUDA фирмы NVIDIA.

Первое что приходит в голову — это ускорение сортировок чисел и вычисление md5/sha1. Я слишком слабо разбираюсь в вопросе, чтобы понять с первого взгляда куда ещё можно приспособить графические ускорители.