А можете раскрыть мысль? Да, корутины будут stackless. Да, это просто хитрое преобразование кода. Но почему это мешает использовать их в многопоточном коде?
Да даже семантику Go должно быть несложно воспроизвести на основе новых корутин.
Если кого-то огорчает, что вынос функции в отдельный файл замедляет тест в 10 раз, то специально для таких случаев есть link time optimization (-flto).
Чтобы получить обратную функцию Аккермана в асимптотике, нужно использовать и эвристику сжатия путей, и ранговую эвристику. Но подозреваю, чтобы это проявилось, нужны специально сгенерированные тесты.
Bucket sort деградирует если разные элементы попадают в одну корзину. С маленькими весами bucket sort это как раз то, что нужно. В одну корзину будут попадать в точности элементы одного веса.
Не совсем верная эвристика сжатия путей. На корень будет указывать только элемент, для которого был вызван find, а должны указывать все элементы в пути до корня.
Можно добавлять описания всех тестов в один большой массив. Или если жалко виртуальную память, то в аналог std::vector.
А потом разом этот массив регистрировать.
Но да, динамические структуры рано или поздно возникнут, а возможность проставлять приоритет в __attribute__((constructor)) может пригодиться.
Если уж зашла речь о том, что нельзя сделать на чистом C.
Как насчет __attribute__((constructor))?
Он позволяет определять функции, которые будет вызваны до main.
Ух. Формализма и правда хватает :)
Попробую резюмировать.
Мы обходим ациклический ориентированный граф, хотим посетить каждую вершину один раз и не хотим ставить пометки.
Для каждой вершины (кроме корня) мы неким образом выделяем ровно одно входящее ребро, то есть учимся однозначно находить предка.
Граф из выделенных ребер представляет из себя дерево.
Теперь для обхода графа достаточно идти только по выделенным ребрам, то есть при проходе по ребру проверять, что первая ее вершина, является предком второй.
Числа, указанные в статье получены при компиляции с ключом -O3, а в выложенных исходниках она по-умолчанию происходит с ключом -Os
При желании можно исправить KPHP/tests/Makefile и пересобрать bench.php, предварительно удалив директорию в которую происходила компиляция. По-умолчанию это KPHP/tests/kphp_tmp.
Написание jit компилятора несколько более масштабная задача, чем написание транслятора. В частности его разработчикам придется проделать весь тот путь, который прошел gcc. И если gcc что-то оптимизирует, а HHVM нет, то только потому что в HHVM этот путь пройден не до конца.
Я не вижу никаких плюсов для VK в подходе с виртуальной машиной. Работать она будет медленней, усилий и ресурсов на нее пришлось бы потратить в разы больше.
Но конечно я понимаю, что всех интересует применимость KPHP к их задачам, а не только к VK.
Учли конечно. Это данные где-то 12-ого запроса к серверу. По умолчанию на разогрев происходит во время выполнения первых 11-ти запросов.
На 12-ом заметен скачок с 3.5 до 0.44 секунд.
Похожих результатов можно добиться простым однократным запуском hhvm с параметром -v«Eval.Jit=true». Учитывая специфику теста, на саму компиляцию уйдет совсем немного времени и результат будет около 0.49 секунд.
Стоит заметить, что этот бенчмарк взят (с незначительными изменениями) из исходников PHP (php-src/Zend/bench.php)
Он проверяет основные конструкции языка от производительности которых зависит производительность всего кода, но конечно не претендует на какую любо универсальность.
Любые бенчмарки кроме реально используемого кода немного условны. В том смысле, что они могут не иметь никакого отношения к реальной жизни.
Даже без фиксированного числа итераций компилятор C++ может многое упростить. Например в тесте nestedloop С++ (и соответственно KPHP) оптимизирует вложенные циклы в вычисление простой формулки.
Про mbstring справедливое замечание. Я бы удалил оттуда ещё и поддержку cp1251, потому что чаще всего те, кто используют его вместо utf-8, неправы.
К тому моменту, когда KittenPHP начинали разрабатывать, классы в коде VK использовались разве что как пространства имен. От них было легко отказаться, и до сих пор они никому особенно не потребовались. Меня самого немного удивляет как они так справляются =)
На самом деле в KittenPHP классы были бы даже быстрее массивов. Добавить ООП по модулю некоторых ограничений не очень сложно. Просто в условиях VK, это никому бы не пригодилось.
Да даже семантику Go должно быть несложно воспроизвести на основе новых корутин.
И не понятно, как изменять значение, когда удаленный ключ добавится снова. Ведь это значение сейчас кто-то может еще читать.
А потом разом этот массив регистрировать.
Но да, динамические структуры рано или поздно возникнут, а возможность проставлять приоритет в __attribute__((constructor)) может пригодиться.
Как насчет __attribute__((constructor))?
Он позволяет определять функции, которые будет вызваны до main.
Попробую резюмировать.
Мы обходим ациклический ориентированный граф, хотим посетить каждую вершину один раз и не хотим ставить пометки.
Для каждой вершины (кроме корня) мы неким образом выделяем ровно одно входящее ребро, то есть учимся однозначно находить предка.
Граф из выделенных ребер представляет из себя дерево.
Теперь для обхода графа достаточно идти только по выделенным ребрам, то есть при проходе по ребру проверять, что первая ее вершина, является предком второй.
При желании можно исправить KPHP/tests/Makefile и пересобрать bench.php, предварительно удалив директорию в которую происходила компиляция. По-умолчанию это KPHP/tests/kphp_tmp.
Написание jit компилятора несколько более масштабная задача, чем написание транслятора. В частности его разработчикам придется проделать весь тот путь, который прошел gcc. И если gcc что-то оптимизирует, а HHVM нет, то только потому что в HHVM этот путь пройден не до конца.
Я не вижу никаких плюсов для VK в подходе с виртуальной машиной. Работать она будет медленней, усилий и ресурсов на нее пришлось бы потратить в разы больше.
Но конечно я понимаю, что всех интересует применимость KPHP к их задачам, а не только к VK.
HipHop VM 2.5.0-dev (rel)
На 12-ом заметен скачок с 3.5 до 0.44 секунд.
Похожих результатов можно добиться простым однократным запуском hhvm с параметром -v«Eval.Jit=true». Учитывая специфику теста, на саму компиляцию уйдет совсем немного времени и результат будет около 0.49 секунд.
Он проверяет основные конструкции языка от производительности которых зависит производительность всего кода, но конечно не претендует на какую любо универсальность.
Любые бенчмарки кроме реально используемого кода немного условны. В том смысле, что они могут не иметь никакого отношения к реальной жизни.
Даже без фиксированного числа итераций компилятор C++ может многое упростить. Например в тесте nestedloop С++ (и соответственно KPHP) оптимизирует вложенные циклы в вычисление простой формулки.
Про mbstring справедливое замечание. Я бы удалил оттуда ещё и поддержку cp1251, потому что чаще всего те, кто используют его вместо utf-8, неправы.
На самом деле в KittenPHP классы были бы даже быстрее массивов. Добавить ООП по модулю некоторых ограничений не очень сложно. Просто в условиях VK, это никому бы не пригодилось.