Недавно была опубликована статья под заголовком "Глобально оптимальный, восьмой и наиболее быстрый вид интерпретаторов байткода". Несколько тезисов из статьи вызвали у меня сомнения в их справедливости. Об этом я попробовал написать ряд комментариев тире вопросов к указанной статье. Но основной лейтмотив всех ответов сводился к тому - "а ты напиши свою статью". Подход не столько инженерно-научный, сколько детсадовский. Мне бы хватило и содержательных ответов в формате комментариев, но как говорится - уговорили.
Рубрика «jit-компиляция»
Ответ на статью о «Наиболее быстром интерпретаторе»
2024-11-09 в 20:41, admin, рубрики: jit-компиляция, x86, виртуальная машина, интерпретаторы, оптимизация, процессорPHP GR8: повысит ли JIT производительность PHP 8
2019-04-18 в 16:02, admin, рубрики: jit, jit-компиляция, php, php8, Блог компании Badoo, высокая производительность, Программирование, Разработка веб-сайтов
PHP — один из основных языков разработки в Badoo. В наших дата-центрах тысячи процессорных ядер заняты выполнением миллионов строк кода на PHP. Мы внимательно следим за новинками и активно ищем пути улучшения производительности, так как на наших объёмах даже небольшая оптимизация приводит к существенной экономии ресурсов. Одна из главных новостей в области производительности PHP — появление JIT в восьмой версии языка. Это, безусловно, не могло остаться без нашего внимания, и мы перевели статью о том, что есть JIT, как он будет реализован в PHP, зачем его решили делать и что от него ждать.
Если вы не вышли из пещеры или не прибыли из прошлого (в этом случае добро пожаловать), то уже знаете, что в PHP 8 будет JIT: на днях тихо-мирно завершилось голосование, и подавляющее большинство участников высказались за внедрение, так что всё решено.
Можно в порыве радости даже изобразить несколько безумных движений как на фото (это, к слову, называется «детройтский JIT»:
Читать полностью »
Когда вызовы функций через внешний интерфейс быстрее нативных вызовов C
2018-06-04 в 13:29, admin, рубрики: C, ffi, GOT, jit-компиляция, Lua, luajit, PLT, ПрограммированиеДополнено: хорошая дискуссия на Hacker News
Дэвид Ю на GitHub разработал интересный тест производительности для вызовов функций через разные внешние интерфейсы (Foreign Function Interfaces, FFI).
Он создал файл общего объекта (.so
) с одной простой функцией C. Затем написал код для многократного вызова этой функции через каждый FFI с измерением времени.
Для C «FFI» он использовал стандартную динамическую компоновку, а не dlopen()
. Это различие очень важно, так как действительно сказывается на результатах теста. Можно спорить, насколько честно такое сравнение с фактическим FFI, но всё равно его интересно измерить.
Самый удивительный результат бенчмарка — то, что FFI от LuaJIT существенно быстрее, чем C. Он примерно на 25% быстрее, чем нативный вызов C для функции общего объекта. Как смог слабо и динамически типизированный скриптовый язык обогнать в бенчмарке C? Точен ли результат?
Читать полностью »
Супермедленный и супербыстрый бенчмарк
2016-08-07 в 8:24, admin, рубрики: java, jit-компиляция, быстродействие, Программирование, производительность, метки: бенчмаркВ недавней статье про производительность Java разгорелась дискуссия на тему измерения производительности. Глядя на неё, с грустью приходится сознавать, что многие люди до сих пор не понимают, насколько сложно правильно измерить время выполнения того или иного кода. Кроме того, люди вообще не привыкли, что один и тот же код в разных условиях может выполняться существенно разное время. К примеру, вот одно из мнений:
Если мне надо узнать, "какой язык быстрее для меня на моей задаче", то я прогоню самый примитивный бенчмарк в мире. Если разница будет существенной (скажем, на порядок) — то скорее всего и на пользовательской машине все будет примерно также.
К сожалению, самый примитивный бенчмарк в мире — это как правило неправильно написанный бенчмарк. И не следует надеяться, что неправильный бенчмарк измерит результат хотя бы с точностью до порядка. Он может измерить что-нибудь абсолютно другое, что будет совершенно отличаться от реальной производительности программы с аналогичным кодом. Давайте рассмотрим пример.
JIT-компилятор оптимизирует не круто, а очень круто
2016-07-18 в 19:12, admin, рубрики: java, jit-компиляция, ассемблер, компилятор сам соптимизирует, Компиляторы, ничего не оптимизируйте, оптимизация, ПрограммированиеНедавно Лукас Эдер заинтересовался в своём блоге, способен ли JIT-компилятор Java оптимизировать такой код, чтобы убрать ненужный обход списка из одного элемента:
// ... а тут мы "знаем", что список содержит только одно значение
for (Object object : Collections.singletonList("abc")) {
doSomethingWith(object);
}
Вот мой ответ: JIT может даже больше. Мы будем говорить про HotSpot JVM 64 bit восьмой версии. Давайте рассмотрим вот такой простой метод, который считает суммарную длину строк из переданного списка:
static int testIterator(List<String> list) {
int sum = 0;
for (String s : list) {
sum += s.length();
}
return sum;
}