Какие последствия имеет JIT (javascript / canvas) и AOT (Flash) с точки зрения производительности браузерной игры?


8

По моему опыту, даже до сегодняшнего дня я все еще вижу больше визуального отставания в перемещении / анимации сущностей в играх на основе JavaScript (Canvas), чем в играх на основе Flash.

Почему это так? Каково именно расхождение на самом базовом уровне между компилятором JIT и AOT в конкретном сценарии JavaScript против Flash.


2
Flash-код в браузере не компилируется заранее; Flash Player включает в себя виртуальную машину для интерпретации кода. Единственная платформа, поддерживаемая Flash через AOT-компиляцию, - iOS.
Джоккинг

Ответы:


4

Это не метод компиляции, который делает игру задержкой, это сборщик мусора, и сборщик мусора Flash отделен от браузеров.

Я думаю, что могу с полной уверенностью сказать, что вы запускаете Firefox, потому что сборщик мусора Firefox - худшая часть дерьма, которую вы можете получить с игровой точки зрения. Если вы открываете только одну вкладку и запускаете в нее легкую JavaScript-игру, это обычно терпимо, а то и незаметно. Но если вы откроете кучу вкладок, запустите что-то более требовательное или воспользуетесь Firebug, вы легко получите обычные скачки задержки, превышающие 100 мс.

Некоторое время я не проводил всестороннего тестирования, но Chrome всегда хорошо справлялся с этим, и IE9 и Safari, по-видимому, также выполняют приемлемую работу.

Я сделал инструмент для тестирования лага JavaScript, вы можете поиграть с ним, если хотите: http://ebusiness.hopto.org/lagtest/


Я на самом деле использую Chrome из-за точной причины, о которой вы говорите выше, я чуть не бросил сборку мусора в вышеприведенную смесь, но хотел сосредоточить вопрос. Даже в Chrome сборка мусора по-прежнему вызывает визуальное отставание по сравнению со вспышкой. Итак, с наивной точки зрения - каково решение этой проблемы (кроме просто «лучшей сборки мусора»)?
Энтони

@ Энтони Забавно, я не вижу этой проблемы в Chrome вообще, вы получаете что-нибудь, кроме зеленых полос, если вы запускаете мой самый медленный? Конечно, вы всегда можете написать программу, которая в какой-то момент просто выполняется слишком долго, вы уверены, что это не проблема?
аааааааааааа

Ф.Ф. был чрезвычайно хрупким за последние пару лет. Не уверен, о чем идет речь, но постоянные выпуски, которые только и заставляют авторов плагинов адаптироваться / обновляться, в то время как серьезные ошибки игнорируются для меня, как неправильно примененные agile или scrum. Это чертовски стыдно.
Эрик Реппен

3

Трудно сказать, не глядя на реальный код, но несколько моментов:

  • Вспышка была вокруг дольше. Люди, которые создают инструменты и библиотеки для этого, имеют больший опыт работы с анимацией. Я не большой поклонник инструментов и запатентованной технологии, но я никогда не буду стучать с разработчиком ActionScript, который знает, что он / она делает.

  • JIT-браузеры также являются относительно новыми для разработчиков JS. Лучший выбор для действительно отточенных перфитационных инициатив - это то, что мы рассмотрим как сообщество. В большинстве случаев встроенная функция def была пограничной глупостью. Теперь это отличный способ повысить производительность во многих сценариях JIT.

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

  • (отредактируйте: не совсем правильно, но здесь, возможно, есть смысл - Эрик). Плагин Flash поддерживает вектор, и широко понимается, как извлечь из этого максимум пользы. Будут ли схемы наследования приносить нам массу пользы с контекстными объектами Canvas, еще неизвестно, но я сомневаюсь, что это будет в той же степени, что и вы, выигрывая от вектора.


Мне нужно лично прочитать некоторые термины, но это также отличный ответ.
Энтони

1
Я думаю, что я был неправ насчет векторной стороны. В Canvas есть встроенные в API методы на основе векторов. Я думаю, что недавно меня неправильно исправил кто-то, кто только что сделал ошибочные предположения о том, что вы всегда выводите растровые изображения. Читал на графике JavaScript с наддувом О'Рейли в поезде, и я очень рекомендую.
Эрик Реппен

3

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

Другое отличие в производительности, как уже упоминалось, GC. Я подозреваю (я не проверял), что большинство браузеров используют GC для подсчета ссылок (поскольку вся память, выделенная GC для страницы, может быть освобождена при выходе из страницы, это фактически одно из лучших мест для использования GC для подсчета ссылок ) или консервативное сканирование ГК (например, Бёма). Последний может быть значительно медленнее первого, если он не реализован правильно. (Boehm - пример правильной реализации) С другой стороны, Flash использует точный GC (намного проще сделать в строго типизированной системе). Поскольку Flash использует точный GC, у него нет накладных расходов на подсчет ссылок во время выполнения. (который не огромен, но все еще существует) Хорошим примером точного GC является SGen Mono, который также сжимает кучу.

Затем следует тот факт, что JavaScript не был разработан с учетом анимации. (как уже упоминалось) Насколько мне известно, ни один браузер не будет генерировать инструкции в стиле SSE для циклов анимации, тогда как основные функции рендеринга во Flash, вероятно, были оптимизированы вручную для достижения максимальной производительности. (в некоторых местах пишется в сыром виде)

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


Java также строго типизирован и обладает высокой производительностью при выполнении тестов. Я бы по-прежнему делал ставку на разработчиков Node.js против разработчиков Java в конкурсе производительности для базового веб-приложения на стороне сервера, предполагая чуть более посредственные уровни талантов. Сильные и слабые типы - это компромисс в дизайне, а не гарантия того, что ваше приложение будет работать быстрее, если его передадут человеческие руки, которые делают глупости, когда приходится много манипулировать кодом. Не то чтобы я рекомендовал писать 3D-движок на JS, Flash или Java.
Эрик Реппен

0

ИМХО, что различие происходит от того факта, что Flash был построен с нуля, чтобы сделать именно это, анимации. Flash реализует (хотя и не по общему мнению) методы для более плавной визуализации, выполняемой по умолчанию, когда в JS вам нужно будет сделать эти реализации вручную.

Есть примеры отличных реализаций JS / Canvas, которые работают даже лучше, чем большинство Flash-игр, которые я вижу вокруг. Все зависит от разработчика.


0

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

В последней версии Flash Player Flash начал прибегать к аппаратному ускорению для рендеринга этих изображений, что делает процесс рендеринга более быстрым и качественным. в то время как игры на основе JS в некоторых браузерах (FF, CHROME) еще не начали этого. Однако было одно исключение: браузер IE9 начал перепроектировать со уровня аппаратной абстракции, браузеры из IE9 добились огромного прогресса в использовании аппаратного ускорения, поэтому рендеринг графики в этих браузерах определенно лучше и быстрее, чем в других браузерах.


Как примечание: в chrome / ff вы можете форсировать аппаратное ускорение (webgl), независимо от того, выполняется ли оно с помощью настроек кода и / или настроек браузера, небольшое преимущество доступно. В любом случае я предполагаю, что внедрение в chrome / ff все еще более незрелое, чем в IE 9+
Энтони

@ Энтони, да, определенно согласен. В наши дни в области графических API DX значительно превосходит OPENGL, и Chrome или другие браузеры не могут работать лучше, чем IE9, по крайней мере, в течение короткого периода времени.
мелькает
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.