Как реализации JVM, такие как Jython и JRuby, могут превзойти своих собственных аналогов?

Question

Я смотрел это видео здесь , где Роберт Николсон обсуждает P8, реализацию PHP на JVM.В какой-то момент он упоминает, что они стремятся превзойти нативный PHP по производительности в будущем.

Он упоминает JRuby и Jython, которые начинались медленнее, чем их родные аналоги, но в итоге превзошли их.Quercus, другой интерпретатор PHP на JVM, утверждает, что он в 4 раза быстрее , чем mod_php, и также заслуживает внимания.

Означает ли это, что общая идея о том, что JVM медленнее, чем C, неверна, или есть недостатки в оригинальных реализациях C?

Answer 1

Означает ли это, что общая идея о том, что JVM медленнее, чем C, неверна, или в первоначальных реализациях C есть недостатки?

Немного из обоих

JVM существует уже давно и добилась значительного прогресса в эффективности. Сборка мусора, джиттинг, кэширование и другие области более продвинуты, чем в «справочных» реализациях, таких как PHP.

Любой, кто заглянет под капот PHP, поймет, почему легко добиться повышения эффективности.

Я лично сомневаюсь, что JVM может превзойти CPython, однако ... но я могу ошибаться ... Да, это связано с тем, что GV JVM работает быстрее, и IronPython тоже . Улучшения производительности могут быть вызваны не зависимостью от стека вызовов C, например в Python без стека. Сайт Jython сообщает

Jython примерно так же быстр, как CPython - иногда быстрее, иногда медленнее. Поскольку большинство JVM - конечно, самые быстрые - работают долго, горячий код будет работать быстрее со временем.

То, что я могу оценить как факт, поскольку JVM достигнет уровней производительности C при генерации кэшей и т. Д., В основном сводит на нет аспекты более высокого уровня в коде реализации виртуальной машины (большая часть которого написана на C в любом случае)

Во многих интерпретируемых языках, таких как PHP и Python, это просто мосты к эквивалентным вызовам C и погружение в машинный код. В JVM Jitter выполняет аналогичную функцию, сводя байт-код к эквивалентам машинного кода. В конце концов, промежуточные представления, такие как высокоуровневый синтаксис и байт-код, обычно все равно сводятся к C-скорости или более быстрым процессорам ЦП ... так что все равно, просто больше промежуточных шагов , которые влияют только на задержка до полной эффективности при загрузке нового кода. В оперативной памяти наступает момент, когда вы говорите «в чем реальная разница?» и ответ - только процесс, который получает это там и окончательное представление, которое определяет скорость намотки стека, алгоритмы сборки мусора, использование регистра и логическое представление, такое как арифметика.

Answer 2

Это не так уж сложно. Если вы пишете свою реализацию на C, вы должны написать свой собственный GC, JIT и многое другое (чтобы быть быстрым и эффективным). Чтобы сделать это действительно хорошо, вам нужны действительно умные люди с большим опытом и уделите им много времени.

Я выйду здесь на передний план и скажу, что текущая реализация PHP (основана не на знании внутренней работы, а скорее на тестах, которые я видел, и на материалах, которые мне рассказали люди, которые знают больше о PHP) это не состояние искусства. Facebook пытается решить эту проблему, но они делают это необычным образом (из-за особых потребностей и типичного использования PHP см. http://www.stanford.edu/class/ee380/Abstracts/100505.html).

Резюме: Поэтому, если кто-то реализует PHP в Java (или на любой быстрой ВМ), ему не нужно писать супер-GC или JIT, чтобы он был быстрым «только» компилятором (который может быть простым).

Answer 3

Есть несколько советов о том, что виртуальная машина делает здесь .Например, похоже, что виртуальная машина Java сначала проверяет, какие части байт-кода выполняются наиболее часто, а затем компилирует соответствующие части в собственный код (который затем должен выполняться с такой же скоростью, как, например, скомпилированный код C).

Кстати, PHP компилируется в байт-код или он просто интерпретируется с использованием структуры данных в памяти?Переводя сначала PHP в байт-код, исполняемый виртуальной машиной Java, можно автоматически воспользоваться существующей (независимой от языка) оптимизацией выполнения байт-кода.