Войти
ФлеймФорумСофт

Границы применимости JavaScript (8 стр)

Страницы: 13 4 5 6 7 8
#105
11:37, 15 июня 2017

bodja
> Думаю, про JAVA Adobe знает намного больше нас с вами :)
  Я бы никогда в этом и не сомневался, а прочитав первые страницы вашего срача становится понятно, что вы и в JS мало что понимаете :)

Fla
> Почему Java анализировать и проверять типы перед JIT'ом можно, а V8 - нельзя
  Анализ байткода в Java при загрузке класса называется верификацией и она в принципе может быть даже пропущена с помощью специальной опции при запуске и на JIT это никак не повлияет (но, естественно, так лучше не делать). Байткод это уже скомпилированный исходный код с типизацией. Код на JS мало того, что не скомпилирован даже в AST, так там ещё и типов нет. То есть у анализатора V8 просто непаханное поле работы на стыке современных технологий статического анализа даже для того, чтобы превратить код хотя бы во что-то похожее на байткод Java, уже не говоря о какой-то там дальнейшей компиляции в машкод. И совсем ещё не факт, что результат будет таким же.


#106
13:10, 15 июня 2017

Zefick
LoL, ну судя, что вы умудрились спутать JAVA с JS, далеко от меня вы не ушли XD

#107
13:40, 15 июня 2017

bodja
> вы умудрились спутать JAVA с JS
  Где ты увидел чтобы я что-то спутал, ещё и с русским языком проблемы?

#108
14:19, 15 июня 2017

Zefick
Это все понятно, что JIT в Java работает лучше благодаря типам и верификации.
Мой поинт в том, что V8 успешно справляется и выносит проверку типов в начало верхней функции, а внутри неё вызывает функции уже безо всяких проверок. Само собой, это возможно только если писать более-менее чистые функции и не пользоваться eval'ами и прочим динамизмом. Но для числодробилок а не для них нет особой разницы все это и не нужно.
Это безусловно не настолько эффективно как в Java. Но это и не сплошные VariantAdd'ы, и не проверка типов перед каждым методом, и уж тем более не тупой threaded code.
> она в принципе может быть даже пропущена с помощью специальной опции
Не уверен насчет опции, не буду спорить. Но мне все же кажется, пропускать ее нельзянежелательно, т.к. рантайм должен проверить типы в стеке перед invoke'ом, иначе как раз таки придется проверять типы во время invoke'а. Ну или сегфолтится, что не очень Java-way.
Например, можно раздельно собраться два .class'а, и в одном дернуть другой с неправильными типами. Или просто руками сделать iconst_1, fstore_1: https://stackoverflow.com/questions/2637879/types-in-bytecode

#109
14:33, 15 июня 2017

Fla
> Мой поинт в том, что V8 успешно справляется

Пойнт же гугла и мозиллы состоит в том что их движки JavaScript не справляются с возросшими требованиями, особенно на фоне HTML 5 на фоне отказа от бинарных плагинов, Явы и Flash, и нужно пилить такие штуки как WebAssembly или asm.js.

#110
15:13, 15 июня 2017

=A=L=X=
Ясен хрен, что производительный байткод, который быстро и просто собирается в большинство популярных архитектур, делают ради производительности. Чему это противоречит?

#111
16:21, 15 июня 2017

bodja
> Ладно... 500 000 мячиков :)
Странно, не тормозит даже - 30 FPS на ноуте. У меня моя демка на 50000 частиц на ноуте уже 10 FPS выдаёт, но при этом на телефоне 60 FPS. А нативно то же самое на ноуте давало сотни FPS. Хотя все вычисления на шейдерах, JS тут ни при чём и тормозить не должен.

А зачем вообще делают WebAssembly? Почему нельзя напрямую скормить браузеру LLVM IR?

#112
17:15, 15 июня 2017

Нa моём в Хроме - 5.37…10.27.

#113
17:57, 15 июня 2017

gammaker
> Почему нельзя напрямую скормить браузеру LLVM IR?
Потому что LLVM IR позволяет делать эквивалент

*(uint32_t*)0xDEADBEAF = 0xBAADF00D
Который или сегфолтнет, или поломает твой процесс.
#114
18:51, 15 июня 2017

gammaker
> У меня моя демка на 50000 частиц на ноуте уже 10 FPS выдаёт, но при этом на телефоне 60 FPS.
  22 FPS на 10 миллионах. Всё что ниже - 60. Хром v58.

Fla
> Но мне все же кажется, пропускать ее нельзянежелательно, т.к. рантайм должен
> проверить типы в стеке перед invoke'ом, иначе как раз таки придется проверять типы во время invoke'а.
  Верификация это единственная часть JVM, где происходят статические проверки. Больше нигде типы не проверяются за исключением тайпкастов, где их статически просто нельзя проверить. Отключая верификацию ты кладёшь на себя ответственность за то, что байткд, не соответствующий спекая языка, может получить управление со всеми вытекающими, включая порчу стека, обращение по левым адресам и прочие радости, знакомые ещё по крестам. Больше ни на что, кроме того, загрузится класс или вывалится исключение при загрузке, это не влияет. Естественно не каждая JVM обязана в принципе допускать подобные вольности, но в оракловой виртуалке так можно делать.

#115
19:44, 15 июня 2017

Zefick
> 22 FPS на 10 миллионах. Всё что ниже - 60. Хром v58.
Ты в моей демке делал 10 миллионов? Размер частиц уменьшал? А то иначе там должен был быть дикий филлрейт.

У меня тоже Хром версии 58 и тормозит на обоих ноутах, которые у меня есть. Возможно браузер на встроенной интеловской видеокарте рендерит, но десктопная версия на встроенной карте летает и тянет миллионы частиц. Какая у тебя конфигурация?
Может у тебя нет встроенной и работает дискретная?

Fla
> Потому что LLVM IR позволяет делать эквивалент
> *(uint32_t*)0xDEADBEAF = 0xBAADF00D
> Который или сегфолтнет, или поломает твой процесс.
Если я такой код скомпилирую в Emscripten, то он скомпилируется. Но так как там память эмулируется на массивах, то сам процесс не упадёт - только скомпилированный скрипт. Что мешает так же виртуализировать память браузеру, который мог бы сразу JIT'ить LLVM IR без его преобразования в WebAssembly\asm.js?

#116
20:08, 15 июня 2017

Zefick
> Где ты увидел чтобы я что-то спутал
Ты закоментил текст про JAVA, а насисал JS
> ещё и с русским языком проблемы?
Да это было сразу заметно :)

#117
20:14, 15 июня 2017

gammaker
> Размер частиц уменьшал?
  Не имею ни малейшего понятия как это делается, просто нажимал на цифры. Видеокарте на филлрейт вообще плевать и растереть на таких смешных числах. Упирается в скорость передачи данных из JS-а, очевидно. Но только не совсем понятно какие данные там гоняются, когда всё должно лежать на видеокарте.

#118
20:17, 15 июня 2017

Zefick
> Верификация это единственная часть JVM, где происходят статические проверки.
Так я и не спорю. Я имел в виду "надо будет проверять типы перед каждым invoke'ом иначе может вылететь сегфолт".

gammaker
> Что мешает так же виртуализировать память браузеру
То, что это будет тормозить, очевидно же. Или ты второй MMU воткнешь?

#119
23:51, 15 июня 2017

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

Виртуалка кушает байткод, смысл кормить её кодом? Это ж не компилятор.

Страницы: 13 4 5 6 7 8
ФлеймФорумСофт

Тема в архиве.