Нужно завести игровой сервер. Поднять там 2500 клиентов, каждый из которых будет отправлять в среднем 50 сообщений в секунду и получать примерно 750 (через web socket).
Работа gc замечается в едва заметных глазу лагах при передвижении игровых объектов.
Сервера бывают разные. Ваши полмиллина клиентов — это игровые клиетны в реальном времени, как у меня?
Кроме этого, вы не захотели понять суть статьи. Она не о том, что go — лучший язык.
И не о том, что в ява нет профайлеров.
Я сравнил усилия, которые от меня потребовали языки, чтобы сделать одно и то же. Go в данном случае потребовал в разы меньше.
Да, вы правы. В обоих случаях срабатывает AOT и мое сравнение некорректно, а разница в скорости связана с оптимизацией кода.
Я ошибочно связал два факта — существенную разницу в скорости и наличие директивы use asm в production билде при её отсутствии (ну нет её там!) в девелоперском.
FF, действительно влючает AOT несмотря на отсутствие директивы. Интересно, кстати, почему.
>Публичные версии юнити пока не умеют компилировать в WebAssambly
Да, но для целей сравнения скорости достаточно сравнить asm.js и обычный js. Потому что на даный момент WebAssembly — просто бинарное представление asm.js и работает оно ровно с той же скоростью. Разница лишь во времени на скачивание, разархивирование и парсинг. Всё это происходит при инициализации. А дальше скорость одинакова.
>В js в браузере нет интерпретатора, есть разные виды компиляторов.
JIT, конечно есть. Тут я был неточен. Но я хотел сравнить js без AOT и webassembly (где AOT есть всегда).
>Наличие директивы «use asm» никак не влияет на отладку. При открытом отладчике FF иногда отключает AOT компиляцию, но на отладку это не влияет
Возможно, это было просто предположение.
>Я проверил ради интереса — в обоих случаях работает AOT компиляция, так что все осмыслено и директива остается на месте.
А директива «use asm» у вас тоже есть в коде в обоих случаях? В моих девелоперских билдах её нет.
Если она у вас есть, то, видимо, мы используем разные настройки девелоперских билдов.
Если её у вас нет, то как именно вы определили, что AOT работает в обоих случаях?
Всё так. Но даже при том, что код, действительно оптимизирован в обоих случаях, AOT даёт ощутимую прибавку по сравнению с интерпретатором.
Что касается отключения AOT в девелоперском билде, полагаю, это сделано с целью облегчения отладки в браузерном дебагере. Хотя точно не знаю зачем.
Я про то и говорю. Я сравнил asm.js (который по скорости работы равен Webassembly) и обычный интерпретатор javascript (который исполнят в Unity девелоперские сборки)
Вы не правы. AOT компилятор включается только при наличии в скрипте директивы "use asm"
Так вот в девелоперском билде такой директивы нет (специально перепроверил сейчас)
И, хотя код тот же самый, но в девелоперском билде он исполняется интерпретатором js, а в production — прогоняется через AOT компилятор.
По поводу webassembly — если не использовать DOM, то он реально быстрее.
Например, если сравнить девелоперский build Unity игры на webgl (он на чистом яваскрипте) с production build (а он — на asm.js), то у второго FPS на 15-20% выше.
Разумеется, руководитель отдела не будет запускать тесты. Но он будет прислушваться к мнению экспертов (вот как вы слушали руководителя группы и сисадмина). А они уже при помощи тестов смогут лучше оценить новый продукт.
Вроде как суд между гуглом и ораклом закончился как раз обатным: So long as the specific code used to implement a method is different, anyone is free under the Copyright Act to write his or her own code to carry out exactly the same function or specification of any methods used in the Java API. It does not matter that the declaration or method header lines are identical (https://en.wikipedia.org/wiki/Oracle_America,_Inc._v._Google,_Inc.)
И так берут пока нет альтернатив. А вот если один продукт откроет тесты, а его конкурент — нет, то, скорее всего, первый получит конкурентное преимущество.
Одним из важнейших качеств продукта является момент выхода его на рынок. Если кто-то сейчас сделает более дешевую и качественную альтернативу, например, Windows, он всё-равно ничего никому не продаст.
Чтобы выйти на рынок нужно или превосходить существующий продкут на порядок (что невозможно при копировании), либо делать продукт нишевым (здесь копирование тоже почти ничего не даст)
Релиз 1.0.0 редко бывает беспроблемным. Но разница с тем, что было в бете, огромна.
Это даёт основания рассчитывать на улучшение ситуации в следующих релизах.
>И возникнет старая проблема — невозможность создания кастомных серверов без хостинга в юнити.
Тут согласен с вами. Поэтому сам просто взял здесь простой клиент к WebSocket и прицепил его к Jetty (читай — к любому серверу с поддержкой WebSocket). Работает прекрасно.
>Это новая сеть, которую они пилят с 5-ки и к которой выкатывают 100500 фиксов к шоустоперам каждый патч.
Так часто бывает с ноыми продуктами. Скорее всего, процесс скоро сойдется.
>Не совсем понял, с чего сеть вообще должна быть синхронной?
Сеть не должна быть синхронной. Я к тому, что нельзя просто так обернуть Socket в WebSocket хотя бы потому, что первый поддерживает синхронные сообщения, а второй в браузерах не поддерживает.
Работа gc замечается в едва заметных глазу лагах при передвижении игровых объектов.
Кроме этого, вы не захотели понять суть статьи. Она не о том, что go — лучший язык.
И не о том, что в ява нет профайлеров.
Я сравнил усилия, которые от меня потребовали языки, чтобы сделать одно и то же. Go в данном случае потребовал в разы меньше.
Что касается quasar, я сравнивал сами языки, а не экосистему.
Именно поэтому я и не нашел её. Искал с двойными кавычками.
Я ошибочно связал два факта — существенную разницу в скорости и наличие директивы use asm в production билде при её отсутствии (ну нет её там!) в девелоперском.
FF, действительно влючает AOT несмотря на отсутствие директивы. Интересно, кстати, почему.
>Публичные версии юнити пока не умеют компилировать в WebAssambly
Да, но для целей сравнения скорости достаточно сравнить asm.js и обычный js. Потому что на даный момент WebAssembly — просто бинарное представление asm.js и работает оно ровно с той же скоростью. Разница лишь во времени на скачивание, разархивирование и парсинг. Всё это происходит при инициализации. А дальше скорость одинакова.
JIT, конечно есть. Тут я был неточен. Но я хотел сравнить js без AOT и webassembly (где AOT есть всегда).
>Наличие директивы «use asm» никак не влияет на отладку. При открытом отладчике FF иногда отключает AOT компиляцию, но на отладку это не влияет
Возможно, это было просто предположение.
>Я проверил ради интереса — в обоих случаях работает AOT компиляция, так что все осмыслено и директива остается на месте.
А директива «use asm» у вас тоже есть в коде в обоих случаях? В моих девелоперских билдах её нет.
Если она у вас есть, то, видимо, мы используем разные настройки девелоперских билдов.
Если её у вас нет, то как именно вы определили, что AOT работает в обоих случаях?
Что касается отключения AOT в девелоперском билде, полагаю, это сделано с целью облегчения отладки в браузерном дебагере. Хотя точно не знаю зачем.
Так вот в девелоперском билде такой директивы нет (специально перепроверил сейчас)
И, хотя код тот же самый, но в девелоперском билде он исполняется интерпретатором js, а в production — прогоняется через AOT компилятор.
Например, если сравнить девелоперский build Unity игры на webgl (он на чистом яваскрипте) с production build (а он — на asm.js), то у второго FPS на 15-20% выше.
С тестами так не выйдет.
Чтобы выйти на рынок нужно или превосходить существующий продкут на порядок (что невозможно при копировании), либо делать продукт нишевым (здесь копирование тоже почти ничего не даст)
Это даёт основания рассчитывать на улучшение ситуации в следующих релизах.
Тут согласен с вами. Поэтому сам просто взял здесь простой клиент к WebSocket и прицепил его к Jetty (читай — к любому серверу с поддержкой WebSocket). Работает прекрасно.
Так часто бывает с ноыми продуктами. Скорее всего, процесс скоро сойдется.
>Не совсем понял, с чего сеть вообще должна быть синхронной?
Сеть не должна быть синхронной. Я к тому, что нельзя просто так обернуть Socket в WebSocket хотя бы потому, что первый поддерживает синхронные сообщения, а второй в браузерах не поддерживает.