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

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

Страницы: 13 4 5 68 Следующая »
#45
17:06, 13 июня 2017

=A=L=X=
Нет, JavaScript не собирается в виртуальную машину. Каждый движок исполняет его как хочет.
Хром держит тупой интерпретатор и JIT. Сафари таки собирает в свою проприетарную виртуальную машину.
JavaScript не должен собираться в wasm. Но если какой-нибудь движок решит, что им так удобнее, им никто не запретит.

> не позволяющий делать add ebx, ecx, там где сейчас делается call VariantAdd
V8 прекрасно делает add ebx, ecx. http://wingolog.org/archives/2011/08/02/a-closer-look-at-cranksha… zing-compiler

> Именно поэтому типизация и нужна им позарез
Нет, нет и нет. Почитай Design Rationale: http://webassembly.org/docs/rationale/. Им нужна не типизация, а безопасный портабельный низкоуровневый байт код, в который можно будет собрать кресты и выполнять его примерно с такой же скоростью, но безопасно в терминах веба. И в этом байткоде, к слову, нет никакой типизации, там даже структур нет. Там буквально сохранение 4/2/1 байт по адресу с оффсетом.
Вот онлайн компилятор http://mbebenita.github.io/WasmExplorer/, можешь поиграться.


#46
17:40, 13 июня 2017

Fla

По полочкам: wasm был бы не нужен, просто не нужен, если бы JS имел бы типизацию и поэтому позволял бы делать full-scale оптимизации как в яве. Был бы это - даже в голове бы не возникло этой идеи.
А то что там где-то в узких случаях компиль может догадаться, что (например) в sin(a) + cos(b) оба операнда сложения есть числа - это к делу не относится и не решает данный вопрос.
Всё остальное к делу не относится. Им всем нужна реальная производителность реального JIT и её разными способами изобретают, от wasm до всяких type script - всё это ветки одного design lack.

#47
17:45, 13 июня 2017

Fla
> Потому что в случае первого было бы неплохо предоставить пруфы,
Ладно пруфы, даже на хабре нашел, ну извини, дело было давним, народ благополучно здох, но вот одним из этих методов я пользовался

2) JSONP (JSON Padding) или «JSON с подкладкой» является расширением JSON, когда имя функции обратного вызова указывается в качестве входного аргумента. Использовав тэг , мы можем обратиться к другим доменам, однако результат придет в виде json ответа, который мы не сможем обработать, jsonp предлагает следующее решение: передавая серверу имя функции, мы получаем в ответе не голые данные, а parseResponse({«paper»: «A4», «count»: 5}), что вызовет функцию parseResponse.

> Ходить по tcp и udp не надо никому.
Канеш, игровой сервер просто спит и видит, что бы ему состояние мира и игроков передавали по HTTP протоколу и назад, я уже не говорю про шутерки по UDP, и тем более не говорю про пробой НАТ.

> Он может хоть брейнфаком компилироваться. Исполняется он все равно виртуальной
> машиной Flash Player'а и к Java'е отношения не имеет.
Да не имеет, канеш, намек был про то, что он куда ближе к яве, чем к питону, что даже компиллятору ясно, что с ним делать.

> Как там в 2009м?
Да нормально, зайди на любой игровой портал в раздел браузерные, посмотри :)

> Все фишки из этих версий в JavaScript'е есть, а в ActionScript'е - нет.
Ну какие, поконкретнее можно?

> Серьезный разговор, я так понимаю, закончился?
Не, он только начался :)
Давай сделаем так, тут есть конкурс, даже с призами, у тебя есть возможность посыпать мне голову пеплом на нем, используя последние достижения JS :) Ок?

#48
17:47, 13 июня 2017

Fla
> нет никакой типизации, там даже структур нет. Там буквально сохранение 4/2/1
> байт по адресу с оффсетом

И не тупи, первая заявленная High Level Goal wasm-а это:

...can be compiled to execute at native speed...

Точка.
Всё что им надо от него в первую очередь - реальная производительность, которую чистый JS дать не может. Именно эти 4/2/1 байта и дают эту силу. Я уже объяснил почему.

#49
18:49, 13 июня 2017

bodja
> Канеш, игровой сервер просто спит и видит, что бы ему состояние мира и игроков
> передавали по HTTP протоколу и назад
Вот именно игровому серверу как раз глубоко посрать, что там и как ему передается.
Даже "шутеркам с UDP" траффик может приходить из таких жоп и тунелей, о каких ему никакой необходимости знать нет.

#50
19:36, 13 июня 2017

=A=L=X=
> отсутствие типизации, не позволяющий делать add ebx, ecx, там где сейчас делается call VariantAdd
> компиль может догадаться, что (например) в sin(a) + cos(b) оба операнда сложения есть числа - это к делу не относится
Ты уж определись, относится оно или нет.
> от wasm до всяких type script
TypeScript собирается в JavaScript, условно, выкидыванием всех типов. В результате у тебя обычный JavaScript, никакого профита с точки зрения скорости нет. Вот песочница: http://www.typescriptlang.org/play/index.html
> И не тупи, первая заявленная High Level Goal wasm-а это:
> Всё что им надо от него в первую очередь - реальная производительность
> Именно эти 4/2/1 байта и дают эту силу
Это ровно то, что я сказал:
> > Им нужна не типизация, а безопасный портабельный низкоуровневый байт код, в который можно будет собрать кресты и выполнять его примерно с такой же скоростью
> если бы JS имел бы типизацию и поэтому позволял бы делать full-scale оптимизации как в яве
Типизации как в Java'е в wasm'е нет (и, видимо, не предвидится). Ты можешь жонглировать байтами, не более. Это написано прямо на том сайте, на который ты сейчас ссылаешься, не потрудившись даже прочитать. http://webassembly.org/docs/semantics/#types

bodja
> игровой сервер просто спит и видит, что бы ему состояние мира и игроков передавали по HTTP протоколу
Добро пожаловать в будущее. У нас тут WebSocket'ы, WebRTC.
> Ну какие, поконкретнее можно?
Давай начнем с очевидного: async/await и генераторы.
Вангую громкое кудахтанье: нинужно, нинужно, в моем недоязыке этого нет, нормальные языки оскорбляют мой язык
> Да нормально, зайди на любой игровой портал в раздел браузерные, посмотри
Отвечу твоим же приемом: Ну какие, поконкретнее можно?
> я делал коменты на народе :)
> Ладно пруфы, даже на хабре нашел, ну
Что ты несешь? Если ты был разработчиком народ.ру, то давай пруфы, что был разработчиком народ.ру. Если ты просто на своем хомяке делал гостевую, то молодец, возьми с полки пирожок, твой хеловорлд никому не интересен.
> я делал коменты на народе :)
> JSONP
facepalm | Границы применимости JavaScript
Лол, давай, расскажи мне как ты на статическом народе пользовался JSONP, который требует сервера, чтобы таки обернуть результат в условный parseResponse(...).
Ты либо врунишка, либо жиквери-макака из нулевых, весь опыт которой - $.accordeon на сайтах ООО "Окна Реутов". Склоняюсь к первому.
> тут есть конкурс, даже с призами, у тебя есть возможность посыпать мне голову пеплом на нем, используя последние достижения JS
При чем тут конкурс игр, если мы обсуждаем язык? И как к нему относится JavaScript?
> у тебя есть возможность посыпать мне голову пеплом на нем
> :):):):):):)
Ноль конструктива, истерика смайлофага и попытка померяться письками как только запахло твоей некомпетентностью. Засчитываю тебе слив.

#51
20:30, 13 июня 2017

Fla
> Типизации как в Java'е в wasm'е нет (и, видимо, не предвидится). Ты можешь
> жонглировать байтами, не более.

Ты реально походу не понимаешь принципы работы процессоров, что такое компиляция и типы данных.
Единственная причина существования WASM - это то, что в JavaScript отсутствует типизация, поэтому он не может "жонглировать байтами", а вынужден на любой чих вызывать call VariantAction.

Например в недрах web-страницы где-нибудь на event посадили function (a,b){ return a+b; }; так как всё это динамически грузится, может в любой момент быть вызвано хрен знает куда и кем, то не существует никакого аналитического метода оптимизации, который мог бы свести тело этой функции к жонглированию байтами вида "сложить 4 байта с 4 байтами", т.е. превратить в одну функциональную инструкцию add eax, ebx, даже лучший экземпляр JIT-компиляции вынужден будет делать call VariantAdd, так как если мы совместимы с JS, то a и b могут быть не только числами, но и строками и результат будет верным и вполне себе определенным. А там где вместо add стоит call происходит падение производительности в десяток раз - приходится разворачивать последовательность из десятков, а то и сотен команд на одну элементарную операцию.

Поэтому этот недостаток JavaScript неустраним (как и у всех аналогов), а учитывая как там любят кэллбеки во всех либах и всём таком - то это просто no way.
В результате все мозговые штурмы кинуты на вещи, которые могут в типы осознанно и целенаправленно - это и wasm, который суть просто ядро виртуальной машины, не надо даже делать вид, что придумали что-то новое - в Java это было 20 лет назад.
Это TypeScript от MS (вводит типы, но может "деградировать" до безтипового JS), это Dart от Google, потом еще появился asm.js с довольно любопытным декорированием посредством незначащих операций, в итоге еще позже - wasm и скорее всего я еще чего нибудь упустил.

Кстати, пока шарился по вики вспоминая всех вышеперечисленных товарищей - наткнулся, что wasm и asm.js оба выросли (по крайней мере духовно) из Native Client от гугл же, борода у этой истории еще длиннее, чем я думал.

И ведь чсх - если наконец то введут тот же wasm или asm.js так чтобы все приняли и все запустили - то получится, что "внезапно" поймут, что неплохо еще бы либку контейнеров, столь же нативных, а не словари яваскрипта, а с ней неплохо бы либку алгоритмов, а к ней обработки строк, а к ней регэкспеов, а к ней... ну и понеслася...

В итоге 10 лет топчемся на месте, когда можно было эти 10 лет пилить преспокойно себе яву в этом же направлении - уже почти всё было готово, биндинги только получше сделать, поудобнее.

#52
20:47, 13 июня 2017

=A=L=X=
> неплохо еще бы либку контейнеров, столь же нативных, а не словари яваскрипта, а
> с ней неплохо бы либку алгоритмов, а к ней обработки строк, а к ней регэкспеов, а к ней... ну и понеслася...
  Регекспы у JS довольно быстрые, может быть даже самые быстрые из всех, ибо написаны на Си и иногда даже сишные аналоги у неё посасывают (тут надо понимать, что так как в Си регекспов нет, то тамошние "аналоги" это наскоро слепленные под конкретную задачу велосипеды из типичных инструментов этого языка - говна и палок).

#53
20:51, 13 июня 2017

Zefick
> Регекспы у JS довольно быстрые
Это смотря как реализуют опять таки биндинги. Что вообще из этого вороха выплывет в итоге наружу - еще вопрос.

#54
21:21, 13 июня 2017

=A=L=X=
> походу не понимаешь принципы работы процессоров, что такое компиляция и типы
> данных.

а что это такое?

#55
21:40, 13 июня 2017

Fla
> Добро пожаловать в будущее. У нас тут WebSocket'ы, WebRTC.
То что было у AS3 изначально и даже больше, у JS оказалось "будущим"...  Ура товарищи :)

> Давай начнем с очевидного: async/await и генераторы.
Канеш, спору нет, эта фишка ставит этот язык на голову выше :)

> Лол, давай, расскажи мне как ты на статическом народе пользовался JSONP,
> который требует сервера
Не прошло и двух страниц, как ты догадался, что я использовал другой сайт и кроссдомен по AJAX :)

> При чем тут конкурс игр, если мы обсуждаем язык? И как к нему относится
> JavaScript?
Действительно...
Подними глаза вверх и влево и прочитай название этого ресурса :)
Не, ну ты сам меня начал обвинять в несерьезности.
Ладно, не хочешь игру, давай приведем небольшой тест, посмотрим насколько JS стал реально крут.
Здесь почти 400к поликов, повторить не хочешь? :)

#56
5:34, 14 июня 2017

Rikk
> а что это такое?

"жонглирование байтами"

#57
11:42, 14 июня 2017

=A=L=X=
> даже лучший экземпляр JIT-компиляции вынужден будет делать call VariantAdd, так
> как если мы совместимы с JS, то a и b могут быть не только числами, но и
> строками и результат будет верным и вполне себе определенным.
нуу, если JIT компилятор обнаружит что обычно эта функция вызывается с числами, он создаст две версии - одну Variant, другую - add eax. Конечно, для такой маленькой функции это не имеет смысла, но если она вызывается из другой (которая тоже чаще всего вызывается с числами), то он может заинлайнить вызов, и тогда проверка "число это или нет" будет выполняться только при входе в большую функцию.

#58
11:58, 14 июня 2017

kipar
> нуу, если JIT компилятор обнаружит что обычно эта функция вызывается с числами,
> он создаст две версии - одну Variant, другую - add eax.

Хрень, не работает в большинстве случаев, не позволяет ничего толком оптимизировать. Как я уже сказал сразу - в JS привычно все программируют на коллбеках, поэтому ни функция не знает толком откуда её вызовут, ни код что-то дёргающий не знает толком что именно он дёргает - это норма.
Для того чтобы из этого выкарабкаться статический анализ применяют, конечно, но без тех или иных видов костылей оно высоко не взлетает.

#59
12:03, 14 июня 2017

=A=L=X=
для js я согласен что ничего не поможет, только закапывать. Я просто комментировал то что "JIT компилятор ничего не сможет сделать". Как раз в этом и отличие JIT - он может в рантайме анализировать частоту запусков и то какие типы (или конкретные значения) где чаще встречаются.

Страницы: 13 4 5 68 Следующая »
ФлеймФорумСофт

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