Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Для Firefox представлен API для задействования в web-приложе..."	+/–
Сообщение от opennews (ok), 10-Сен-14, 11:57
В ночных сборках (http://nightly.mozilla.org/) Firefox добавлена (http://sunfishcode.github.io/blog/2014/09/09/js-simd.html) реализация API JS-SIMD (https://01.org/blogs/tlcounts/2014/bringing-simd-javascript) (Single Instruction, Multiple Data), позволяющего организовать распараллеливание обработки данных с использованием инструкций SIMD (https://ru.wikipedia.org/wiki/SIMD). API JS-SIMD пока доступен только для web-приложений, использующих расширение Asm.js (http://www.opennet.dev/opennews/art.shtml?num=36468) с реализацией низкоуровневого подмножества языка JavaScript со строгой типизацией. Реализация API JS-SIMD не привязана к специфичным реализациям SIMD и может использовать как SIMD-инструкции Intel, так и ARM. В дальнейшем планируется предоставить возможность использования API JS-SIMD не только для Asm.js, но и для обычного JavaScript-кода. Кроме того ведётся работа по интеграции поддержки JS-SIMD в компилятор Emscripten (http://www.opennet.dev/opennews/art.shtml?num=35313), что позволит транслировать в JavaScript применяемые в программах на C/C++ механизмы SIMD. Для наглядной оценки  различий в производительности выполнения использующих интенсивные вычисления web-приложений, с задействованием SIMD и без него, подготовлена демонстрационная страница (http://peterjensen.github.io/idf2014-simd/idf2014-simd). Например, при построении множества Мандельброта с использованием SIMD наблюдается четырёхкратное увеличение производительности. В некоторых других тестах скорость возрастает до 10 раз. URL: http://sunfishcode.github.io/blog/2014/09/09/js-simd.html Новость: http://www.opennet.dev/opennews/art.shtml?num=40557
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по времени | RSS]

1. "Для Firefox представлен API для задействования в web-приложе..."	+13 +/–
Сообщение от A.Stahl (ok), 10-Сен-14, 11:57
Пора делать свой "интернет" с поэтесс^W^W БЕЗ жаваскрипта:) А то скоро код для обеспечения эффективной работы жаваскрипта будет тормозить сильнее, чем сам жаваскрипт:)
Ответить | Правка | Наверх | Cообщить модератору

	3. "Для Firefox представлен API для задействования в web-приложе..."	–1 +/–
	Сообщение от бедный буратино (ok), 10-Сен-14, 12:07
	web 0.5, о котором я мечтал, так и не случился... пришло время для web 1.44, может быть, он станет удачнее :)
	Ответить | Правка | Наверх | Cообщить модератору

	4. "Для Firefox представлен API для задействования в web-приложе..."	+2 +/–
	Сообщение от renta (??), 10-Сен-14, 12:23
	>web 0.5 Это случаем не гипертекстовый фидонет?
	Ответить | Правка | Наверх | Cообщить модератору

	5. "Для Firefox представлен API для задействования в web-приложе..."	+6 +/–
	Сообщение от A.Stahl (ok), 10-Сен-14, 12:31
	>web 1.44 Давай уж пятидюймовый 1.2. Так теплее и "ламповей":)
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	12. "Для Firefox представлен API для задействования в web-приложе..."	+2 +/–
	Сообщение от Аноним (-), 10-Сен-14, 13:41
	> Давай уж пятидюймовый 1.2. Так теплее и "ламповей":) А чего не восьмидюймовый?
	Ответить | Правка | Наверх | Cообщить модератору

	14. "Для Firefox представлен API для задействования в web-приложе..."	–1 +/–
	Сообщение от A.Stahl (ok), 10-Сен-14, 13:50
	Я с ними не работал. Даже не видел вживую никогда.
	Ответить | Правка | Наверх | Cообщить модератору

	29. "Для Firefox представлен API для задействования в web-приложе..."	+2 +/–
	Сообщение от Аноним (-), 10-Сен-14, 17:08
	лама =)
	Ответить | Правка | Наверх | Cообщить модератору

	40. "Для Firefox представлен API для задействования в web-приложе..."	+/–
	Сообщение от Аноним (-), 10-Сен-14, 18:44
	> Я с ними не работал. Даже не видел вживую никогда. Такие же как 5", только крупнее.
	Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

	62. "Для Firefox представлен API для задействования в web-приложе..."	+/–
	Сообщение от Аноним (-), 10-Сен-14, 22:09
	Web 6 Plus
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

	107. "Для Firefox представлен API для задействования в web-приложе..."	–1 +/–
	Сообщение от XoRe (ok), 13-Сен-14, 23:54
	web 0.640 хватит всем!
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	11. "Для Firefox представлен API для задействования в web-приложе..."	+/–
	Сообщение от Аноним (-), 10-Сен-14, 13:40
	>  Пора делать свой "интернет" с поэтесс^W^W БЕЗ жаваскрипта:) Гугл сделал - pnacl называется. А мозилла продолжает удалять гланды через ж...у автогеном, пытаясь получать доступ к низкоуровневым фичам из высокоуровневого ЯП. Что, разумеется, требует феерических костылей и выглядит диковато.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	19. "Для Firefox представлен API для задействования в web-приложе..."	+/–
	Сообщение от Xasd (ok), 10-Сен-14, 15:21
	> то, разумеется, требует феерических костылей и выглядит диковато. использование КОДА (js) для выполнения КОДА (asm.js) -- это на много МЕНЕЕ диковато выглядет, ... ..., чем использование ВИЗУАЛЬНОГО объекта < object ... >...</object> для выполнения кода. так что nacl\pnacl -- на много более черезжопная идея чем asm.js .. это если говорить субъективо. а если говорить объективно -- то суть одна и таже (и у nacl\pnacl и у emscripten->asm.js) но при этом у nacl\pnacl нет обратной совместимности для запуска кода в браузерах без nacl\pnacl.
	Ответить | Правка | Наверх | Cообщить модератору

	32. "Для Firefox представлен API для задействования в web-приложе..."	+/–
	Сообщение от Crazy Alex (ok), 10-Сен-14, 17:25
	А с какой стати object обязан быть визуальным? Только потому, что так раньше было? Кроме того, насколько я понимаю, даже с JS для реализации нормальной изоляции кода нужно использовать iframe, который уж точно визуальный. Иначе скрипт гарантированно имеет доступ ко всему, что есть на странице. Ну и в реализации разница принципиальна - для NaCl имеем вполне классическую компиляцию, для asm.js - набор навороченных техник (костылей, в общем-то), количество которых всё растёт. Что проще релизуется и заведомо имеет меньше ошибок - очевидно.
	Ответить | Правка | Наверх | Cообщить модератору

	45. "Для Firefox представлен API для задействования в web-приложе..."	+1 +/–
	Сообщение от Аноним (-), 10-Сен-14, 19:18
	> А с какой стати object обязан быть визуальным? Лучше пусть скажет - какие такие текстовые данные он намерен дробить с использованием SIMD :). А чтобы мальчикам вебдванольчикам стало совсем хорошо - посмотрите на то как SPDY устроен.
	Ответить | Правка | Наверх | Cообщить модератору

	65. "Для Firefox представлен API для задействования в web-приложе..."	–1 +/–
	Сообщение от Xasd (ok), 10-Сен-14, 23:23
	> Лучше пусть скажет - какие такие текстовые данные он намерен дробить с использованием SIMD :). ты хоть в курсе того что asm.js -- ВООБЩЕ НЕ УМЕЕТ работать с текстовыми строками? asm.js может работать только с бинарными данными (int32 , float , double , ... и их массивы). там ВООБЩЕ нет переменных строкового типа! это тебе не Javascript и не Perl .
	Ответить | Правка | Наверх | Cообщить модератору

	76. "Для Firefox представлен API для задействования в web-приложе..."	+1 +/–
	Сообщение от Аноним (-), 11-Сен-14, 04:23
	> ты хоть в курсе того что asm.js -- ВООБЩЕ НЕ УМЕЕТ работать > с текстовыми строками? Тогда к чему весь этот бзик по тексту? Представлять явно бинарные объекты как текст - это крeтинизм в терминальной стадии, чувак. Потому что ничего кроме гемора с парсингом и распухания в несколько раз это не дает. > там ВООБЩЕ нет переменных строкового типа! Зато сам JS код после emscripten - это очень даже текст. И когда в этом представлении записывают всякие int, float и прочие массивы - это, как бы тебе сказать, не совем удобно и быстро для машины в парсинге и только почем зря заставляет качать в несколько раз больше хлама и потом жpeтся уйма памяти, просто потому что IR выбран убер-дeбильнo. У гугла хватило ума прекратить этот сказочный д@лб#%$зм и сделать IR из того что специально делалось под то чтобы быть IR. Мозильщики занялись фигурным онaнизмoм с забиванием гвоздей микроскопами, оптимизируя массу бойка и дорабатывая конструкцию тубуса для более удобного захвата. Хотя если уж задача вбить гвоздь - надо было просто взять молоток. А не пытаться догнать микроскоп до состояния когда из него сносный молоток получится.
	Ответить | Правка | Наверх | Cообщить модератору

	109. "Для Firefox представлен API для задействования в web-приложе..."	+/–
	Сообщение от Xasd (ok), 18-Сен-14, 20:42
	> Зато сам JS код после emscripten - это очень даже текст. И когда в этом представлении записывают всякие int, float и прочие массивы - это, как бы тебе сказать, не совем удобно и быстро для машины в парсинге ды не надо это по 10 раз повторять. да -- это не оптимально. (мы все тебя поняли). но является ли эта неоптимальность узким горлышком? ответ -- нет. это была бы ЭКОНОМИЯ НА СПИЧКАХ! эта неоптимальность настолько не существенная, что ею можно пренебречь. (зато текстовый вид -- даёт некоторые плюсы. а представление байткода ввиде JS -- ещё больше плюсов). а если ты про эту неоптимальность будешь писать на форуме по 20~30 сообщений -- то всё-равно это НЕ ДОБАВИТ ЕЙ ВЕСУ! она как была не существенная так и осталась не существенной. > У гугла хватило ума прекратить этот сказочный д@лб#%$зм и сделать IR из того что специально делалось под то чтобы быть IR. но выигрышь почти нулевой от этого. потому что решили проблему КОТОРАЯ НЕ ЯВЛЯЕТСЯ УЗКИМ ГОРЛЫШКОМ. и при этом -- добавили кучу неудобств. Asm.Js был придуман позже чем NaCl\PNaCl . поэтому Asm.Js сразу учёл недостатки кривой гугловской задумки. главный недостаток, который устарнил Asm.Js -- это обратная совместимость, которая заложена в  Asm.Js на фундаментальном уровне. по хорошему (лучший исход для web-разработчиков), Google мог бы тоже рализовать Asm.Js в V8 ( https://code.google.com/p/v8/issues/detail?id=2599 ) .. но в этом случае ни кто не станет писать код для NaCl\PNaCl -- и это не выгодно для Google, так как это снизит его браузерную монополию. если бы Google Chrome не занимал бы сейчас монопольное положение среди браузеров -- то Google С_ПРИПРЫЖКОЙ бы сразу реализовал бы Asm.Js у себя в браузере (забросив бы к чёртовой бабушке NaCl\PNaCl). отличный пример того как монополия пагубно влияет на прогресс..
	Ответить | Правка | Наверх | Cообщить модератору

	64. "Для Firefox представлен API для задействования в web-приложе..."	–2 +/–
	Сообщение от Xasd (ok), 10-Сен-14, 22:37
	> даже с JS для реализации нормальной изоляции кода нужно использовать iframe, который уж точно визуальный. Иначе скрипт гарантированно имеет доступ ко всему, что есть на странице. пургу не неси. скрипт как раз и нужен чтобы ИМЕТЬ доступ ко всему что есть на странице. для обмена дамными с удалнным сервером (сервисом) -- используются CORS (Cross-Origin Resource Sharing) через XMLHttpRequest. iframe это костыль который когда-то раньше был актуален для эпического костылнестроения особенно для всяких говнобраузеров типа Опера. > А с какой стати object обязан быть визуальным? Только потому, что так раньше было? а как ты его сделаешь не визуальным? сделаешь нулевой размер? то есть нулевой размер это по твоему не костыль? :-) сам себя-то послушай.. > Ну и в реализации разница принципиальна - для NaCl имеем вполне классическую компиляцию, для asm.js - набор навороченных техник где-же разница? и там компиляция и там компиляция. и там и там на основе LLVM . (хотя asm.js можно и вручную написать а можно и компилировать --- то есть и здесь asm.js выигрывает) и там и там нет многонитевости (multithreading). хотя в случае с asm.js можно заиспользовать workers (но сложно согласовать этот код на практике).
	Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

	71. "Для Firefox представлен API для задействования в web-приложе..."	+/–
	Сообщение от Crazy Alex (ok), 11-Сен-14, 03:45
	Это надо посмотреть, кто здесь несет пургу. Ладно, я понимаю, что веб исторически кривым вырос, но зачем защищать этот уродливый набор костылей? То, что все скрипты ко всему на странице доступ имеют - это одна из причин паршивой архитектуры вебовских приложений. А заодно - вечный источник проблем с безопасностью. Должен быть - набор компонентов, которые имеют явно заданные интерфейсы. В том числе это решило бы проблемы недоверенных скриптов. А iframe - и сейчас, насколько я понимаю, единственный сравнительно надежный способ организовать что-то вроде песочницы для скрипта. По многонитевости - в NaCl она есть. Почти обычные pthreads (было вроде ограничение на вызовы OpenGl только из главного потока). И дело не в компиляции, а в том, что в случае asm.js браузер что-то начинает колдовать дальше, а в случае NaCl - код совершенно тупо и предсказуемо выполняется. И костыли вроде того, о котором новость - просто не нужны.
	Ответить | Правка | Наверх | Cообщить модератору

	44. "Для Firefox представлен API для задействования в web-приложе..."	+1 +/–
	Сообщение от Аноним (-), 10-Сен-14, 19:16
	> использование КОДА (js) для выполнения КОДА (asm.js) -- это на много МЕНЕЕ > диковато выглядет, ... JS никогда не делался для быстрого и оптимального выполнения. И тем более SIMD. У него с самого начала низкоуровневый доступ и предсказуемость были променяны на простое использование нубами. Штатно JS типизацию вообще не умеет, что накрывает многие техники оптимизации медным тазом и кушает время на уйму проверок "а не поменялся ли тип?!". Потом стали городить феерические костыли. Появились типизированные массивы. Только не везде. Так что радости с них немного. Потом еще более крутые костыли типа asm.js. > ..., чем использование ВИЗУАЛЬНОГО объекта < object ... >...</object> > для выполнения кода. Вещи которые имеет смысл так запускать - в JS поставляют как транслированный и/или минимизированный код. Который наглухо нечитабельный, но при том пухлый, тормозной и неудобный в парсинге. И пaмять такое представление жрет как свинья помои, делая изначальную нативную версию в разы. Вот нафига ж так делать? Не удобно ни машинам, ни людям. Трехметровую портянку с минимизированными переменными вида a129=493 - читать смысла не имеет, радости с того что оно текст - крайне мало. Да и если вас в simd понесло - вы явно не с текстом работать собрались. А так, для сравнения: IPv4 как бинарные данные - 4 байта. А как текст - до 15. Почти в 4 раза распухон на ровном месте. А теперь прикинь если такая фигня случится со ВСЕМИ ПЕРЕМЕННЫМИ В ПРОГРАММЕ?! Получается знатное забивание гвоздей микроскопом, с созданием себе кучи искусственных трудностей. При этом читаемость выражений вида a129=493 не сильно далеко ушла от хексдампа, зато представление распухло в несколько раз и стало тормозным в парсинге и прожорливым до оперативы. > так что nacl\pnacl -- на много более черезжопная идея чем asm.js .. pnacl не вы...тся и транслирует промежуточный нейтральный поток команд в команды процессора, будучи скорее компилятором по сумме свойств. А JS в качестве intermeriate representation - это интерпретатор на стероидах с кучей костылей для потуг избавиться от тормозливости. И вы знаете, в конечном итоге проц не умеет выполнять текст. Он машинные команды выполняет. И если уж вам скорость и SIMD - то проц логично кормить его нативными представлениями, а IR должен быть не сильно далеко от оного. А если вы с SIMD работать решили - вы явно вознамерились обсчитывать отнюдь не текст, опять же. А вполне себе нацелились какие-то бинарные данные массивом круптооптово долбить. JS тут - ни в п...у, ни в красну армию вообще. А из очевидных плюсов pnacl - кроме более вменяемого IR ему все-равно какой ЯП породит IR биткод. Так можно любой ЯП прикрутить, при условии что он может оттранслировать программу в IR код. При этом с точки зрения программы - ее все-таки скомпилировали. И там где надо скорость - там всякие типы, константы и прочие можно заранее посчитать на фазе компиляции, так что во время выполнения на этом не будет торможения. > а если говорить объективно -- то суть одна и таже (и у > nacl\pnacl и у emscripten->asm.js) но при этом у nacl\pnacl нет обратной > совместимности для запуска кода в браузерах без nacl\pnacl. Если говорить - да, суть одна и та же. Но если посмотреть на "текст" которым обычно востребован asm.js - станет понятно что лучше бы они сразу взяли pnacl и не выделывались.
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	70. "Для Firefox представлен API для задействования в web-приложе..."	+/–
	Сообщение от Аноним (-), 11-Сен-14, 00:15
	pnacl - проприетарное непортабельное yблюдство. А так работают оно с js почти одинаково - что там портабельное представление транслируется в нитивный код, что здесь, только в одном случае llvm bitcode, в другом - js. Второе хотя бы открыть и посмотреть можно.
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

	77. "Для Firefox представлен API для задействования в web-приложе..."	+/–
	Сообщение от Аноним (-), 11-Сен-14, 04:31
	> pnacl - проприетарное Вообще-то там есть исходники, etc и даже под OSI-approved лицензиями насколько я помнб. > непортабельное yблюдство. Не более чем asm.js, который умеет только фокс. Хотя настоящее yблюдство - это пять мегабайтов "текста" вида a129=453, где таким макаром закодированы значения транслированных регистров (в конечном итоге программ). Вот это я понимаю - ни вам читабельности текста, ни вам скорости работы нативного представления. Все хучшее из обоих миров. А где плюсы этого у...щного подхода??? > Второе хотя бы открыть и посмотреть можно. Ну, открыл. Пятиметровую портянку с текстом вида a129=453. Мне конечно же сразу понятно - по какому поводу какой-то переменной с автогенерированным именем назначено какое-то волшебное значение. С таким же успехом и пониманием я и хексдамп почитать могу...
	Ответить | Правка | Наверх | Cообщить модератору

	22. "Для Firefox представлен API для задействования в web-приложе..."	–8 +/–
	Сообщение от Аноним (-), 10-Сен-14, 15:55
	Школьник, где ты видел тормоза JavaScript? Чем он медленнее чем тот же Python или PHP? Про NodeJS держащий миллион соединений без заметной нагрузки рассказать? Не путай тормоза JavaScript и реализации DOM в браузерах.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	24. "Для Firefox представлен API для задействования в web-приложе..."	+1 +/–
	Сообщение от анон (?), 10-Сен-14, 16:04
	Ох, лол. Вот это у тебя бомбануло.
	Ответить | Правка | Наверх | Cообщить модератору

	46. "Для Firefox представлен API для задействования в web-приложе..."	+1 +/–
	Сообщение от Аноним (-), 10-Сен-14, 19:20
	> Python или PHP? Чемпионат тормозов? :) > Про NodeJS держащий миллион соединений Только вот нжинкс любимый хайлоадом - почему-то на чистом си.
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

	51. "Для Firefox представлен API для задействования в web-приложе..."	+/–
	Сообщение от Michael Shigorin (ok), 10-Сен-14, 20:09
	>> Про NodeJS держащий миллион соединений > Только вот нжинкс любимый хайлоадом - почему-то на чистом си. Потому как ему не только держать лежачего соединения, а и обрабатывать бегучего.
	Ответить | Правка | Наверх | Cообщить модератору

	57. "Для Firefox представлен API для задействования в web-приложе..."	+/–
	Сообщение от Аноним (-), 10-Сен-14, 21:37
	> Потому как ему не только держать лежачего соединения, а и обрабатывать бегучего. Да даже лежачих - компактность структур данных и отсутствие 100500 проверок при работе с базовыми типами все-таки позволяют при прочих равных удержать больше. И протолкать больше. В JS в этом плане изначально протупили, подложив свинью и оптимизаторам, и програмерам, у которых куча трудноуловимых ошибок из-за сравнения гвоздей с бананами, при том сразу не заваливается, фазы компиляции нет. А то что что через полчаса работы что-то где-то обломалось - удачи разобраться почему оно вот так.
	Ответить | Правка | Наверх | Cообщить модератору

	56. "Для Firefox представлен API для задействования в web-приложе..."	–1 +/–
	Сообщение от Аноним (-), 10-Сен-14, 21:28
	> Только вот нжинкс любимый хайлоадом - почему-то на чистом си. Железобетонная логика. Может потому что он появился задолго до NodeJS, а также потому что ему требуются низкоуровневые операции, чего не каждой программе на JS нужно?
	Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

	58. "Для Firefox представлен API для задействования в web-приложе..."	+1 +/–
	Сообщение от Аноним (-), 10-Сен-14, 21:39
	> Может потому что он появился задолго до NodeJS, а также потому что > ему требуются низкоуровневые операции, чего не каждой программе на JS нужно? Ну если вы про скорость - вот побейте его по скорости и количеству соединений. А то пинать всяких слоупоков типа питона - ну это конечно да, легко отнять у детки конфетку. Поди лучше отними конфетку у вон того боксера, если хочешь выглядеть крутым Уокером.
	Ответить | Правка | Наверх | Cообщить модератору

	60. "Для Firefox представлен API для задействования в web-приложе..."	+/–
	Сообщение от Аноним (-), 10-Сен-14, 22:06
	Я все же напомню, что JavaScript - динамический язык со своей нишей. Говорить о его тормозах некорректно, он не медленнее других широко распространенных динамических языков. Только вот хомячки, смотря на тормоза своей Лисы, делают вывод, что тормозит именно JS (в отдельных реализациях умеющий без напряга держать миллион коннектов), а не что-то другое.
	Ответить | Правка | Наверх | Cообщить модератору

	78. "Для Firefox представлен API для задействования в web-приложе..."	+/–
	Сообщение от Аноним (-), 11-Сен-14, 04:36
	> Я все же напомню, что JavaScript - динамический язык со своей нишей. Именно. И поэтому делать из JS intermediate representation - надо конкретно упасть с дуба. Особенно если хочется скорость. И особенно если настолько что аж SIMD хочется явно. JS крайне враждебен по своему устройству таким вещам. By design. Так что с точки зрения программизма - могу пожелать мозилле быстрой, но мучительной смерти с таким рантаймом и IR, пусть их захавает хром. Тогда по крайней мере можно будет кодить под нормальный рантайм на удобном мне ЯП и не заморачиваться всем этим восьмиэтажным кластерфаком который эти удоды развели. > Говорить о его тормозах некорректно, он не медленнее других широко распространенных > динамических языков. В данном случае мы говорим про IR, и гугловый pnacl выжимает скорость в общем то в районе обычных нативных программ. И потребление ресурсов - более-менее обычное. А мозильщики сделали какое-то у...ще!
	Ответить | Правка | Наверх | Cообщить модератору

	105. "Для Firefox представлен API для задействования в web-приложе..."	–1 +/–
	Сообщение от haha (??), 12-Сен-14, 13:51
	>Только вот нжинкс любимый хайлоадом - почему-то на чистом си. Сравнил мягкое с теплым.  А слабо веб-фреймфорк на чистом Си назвать, только чтобы им пользовались не полтора землекопа.
	Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

	59. "Для Firefox представлен API для задействования в web-приложе..."	–1 +/–
	Сообщение от rshadow (ok), 10-Сен-14, 22:02
	> миллион соединений Просто напомню что одновременных соединений может быть максимум 60к.
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

	61. "Для Firefox представлен API для задействования в web-приложе..."	+/–
	Сообщение от Аноним (-), 10-Сен-14, 22:08
	Не путай количество портов с соединениями. http://habrahabr.ru/post/123154/
	Ответить | Правка | Наверх | Cообщить модератору

	72. "Для Firefox представлен API для задействования в web-приложе..."	+/–
	Сообщение от rshadow (ok), 11-Сен-14, 03:49
	Ну там то они делали на облаке а не машине. Хотя конечно ip адресов можно на тачку выделить и сделать возможность в миллион коннектов.
	Ответить | Правка | Наверх | Cообщить модератору

	80. "Для Firefox представлен API для задействования в web-приложе..."	+1 +/–
	Сообщение от Аноним (-), 11-Сен-14, 05:00
	> ip адресов можно на тачку выделить и сделать возможность в миллион коннектов. На входящем порту можно получить более 65536 соединений. Вплоть до 65536 соединений с каждого из IP ремоты.
	Ответить | Правка | Наверх | Cообщить модератору

	92. "Для Firefox представлен API для задействования в web-приложе..."	–2 +/–
	Сообщение от клоун (?), 11-Сен-14, 16:19
	Забей. С ним общаться всё равно что г--вно месить: сколько не меси оно вонять меньше не станет.
	Ответить | Правка | Наверх | Cообщить модератору

	93. "Для Firefox представлен API для задействования в web-приложе..."	+1 +/–
	Сообщение от Аноним (-), 11-Сен-14, 17:12
	> всё равно что г--вно месить Тебе как профессиональному гoвнoмесу виднее, конечно, с твоим микрософтом.
	Ответить | Правка | Наверх | Cообщить модератору

	100. "Для Firefox представлен API для задействования в web-приложе..."	+/–
	Сообщение от Led (ok), 12-Сен-14, 01:04
	>> всё равно что г--вно месить > Тебе как профессиональному гoвнoмесу виднее, конечно, с твоим микрософтом. Он не месит, он только потребляет его.
	Ответить | Правка | Наверх | Cообщить модератору

	79. "Для Firefox представлен API для задействования в web-приложе..."	+/–
	Сообщение от Аноним (-), 11-Сен-14, 04:56
	> Просто напомню что одновременных соединений может быть максимум 60к. С чего это ради? Конекция уникально идентифицируется IP1:Port1 <-> IP2:port2. Если допустить что у хоста один IP2 и он слушает на 1 порту port2, всего получается 256^6 комбинаций (4 байта IP1 + 2 байта port1 = 6 байтов которые могут меняться, у каждого 256 возможных значений). На секундочку, это 2.814749767×10¹⁴. Хинт: миллиард это 10⁹. Это число содержит на 5 нолей больше. Это число соответствует случаю если все возможные IP и их порты сделают соединение к нашему IP:Port. Реально нкесколько меньше - т.к. часть адресов зарезервированы а часть портов обычно не используется для исходящих соединений.
	Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

	66. "Для Firefox представлен API для задействования в web-приложе..."	+/–
	Сообщение от Аноним (-), 10-Сен-14, 23:35
	> Школьник, где ты видел тормоза JavaScript? Только что, в соседней вкладке.
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

2. "Для Firefox представлен API для задействования в web-приложе..."	+1 +/–
Сообщение от Аноним (-), 10-Сен-14, 11:57
>Например, при построении множества Мандельброта с использованием SIMD наблюдается четырёхкратное увеличение производительности. В некоторых других тестах скорость возрастает до 10 раз. Верной дорогой идёте, товарищи! Ведь фаерфокс это не веб-браузер.
Ответить | Правка | Наверх | Cообщить модератору

	9. "Для Firefox представлен API для задействования в web-приложе..."	+9 +/–
	Сообщение от Денис Смирнов (?), 10-Сен-14, 13:00
	Да, он уже давно не веб-браузер. Последние годы приложения, которые по традиции продолжают называть веб-браузерами по сути являются специализированными ОС, а веб-сайты являются приложениями, у которых часть кода выполняется на сервере, а часть -- на клиенте.
	Ответить | Правка | Наверх | Cообщить модератору

	15. "Для Firefox представлен API для задействования в web-приложе..."	–1 +/–
	Сообщение от cmp (ok), 10-Сен-14, 14:08
	Это да.
	Ответить | Правка | Наверх | Cообщить модератору

	20. "Для Firefox представлен API для задействования в web-приложе..."	–1 +/–
	Сообщение от Xasd (ok), 10-Сен-14, 15:27
	> а веб-сайты являются приложениями зависит от web-сайта. бывают обычные web-сайта (сайт с информацией). а бывают web-приложения. Firefox даёт возможность выбора -- открывать можно и web-сайты и web-приложения. а люди которым не нравятся web-приложения -- кто-то разве насильно заставляет использовать web-приложения?
	Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

	47. "Для Firefox представлен API для задействования в web-приложе..."	+/–
	Сообщение от Аноним (-), 10-Сен-14, 19:21
	> кто-то разве насильно заставляет использовать > web-приложения? Ну... заходя на сайт я заранее не знаю что мне вгрузят - информацию или приложение.
	Ответить | Правка | Наверх | Cообщить модератору

	68. "Для Firefox представлен API для задействования в web-приложе..."	–2 +/–
	Сообщение от Xasd (ok), 10-Сен-14, 23:53
	> я заранее не знаю что мне вгрузят тык крестик нажми, в случае если что-то не понравится
	Ответить | Правка | Наверх | Cообщить модератору

	81. "Для Firefox представлен API для задействования в web-приложе..."	+/–
	Сообщение от Аноним (-), 11-Сен-14, 05:06
	> тык крестик нажми, в случае если что-то не понравится Поздно пить боржоми когда почки отказали...
	Ответить | Правка | Наверх | Cообщить модератору

	41. "Для Firefox представлен API для задействования в web-приложе..."	+/–
	Сообщение от rob pike (?), 10-Сен-14, 18:47
	Киса, не говорите красиво. А то еще давайте игры называть "специализированными ОС", в них ведь вся логика обычно на Lua написана, и на сервере тоже много чего выполняется.
	Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

	42. "Для Firefox представлен API для задействования в web-приложе..."	+/–
	Сообщение от Аноним (-), 10-Сен-14, 19:00
	Блин, а может мне оно как раз надо на веб-странице? Чего это за множество такое?
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

6. "Для Firefox представлен API для задействования в web-приложе..."	–3 +/–
Сообщение от Анонимус_б6 (?), 10-Сен-14, 12:36
>Реализация API JS-SIMD не привязана к специфичным реализациям SIMD и может использовать как SIMD-инструкции Intel, так и ARM отлично, а где АМД спрашивается?
Ответить | Правка | Наверх | Cообщить модератору

	8. "Для Firefox представлен API для задействования в web-приложе..."	+/–
	Сообщение от EuPhobos (ok), 10-Сен-14, 12:45
	Потестировал на AMD, прирост явно виден, от 10-25 FPS до ~150-200 FPS
	Ответить | Правка | Наверх | Cообщить модератору

7. "Для Firefox представлен API для задействования в web-приложе..."	+1 +/–
Сообщение от YetAnotherOnanym (ok), 10-Сен-14, 12:41
Не, а чо, клёвая штука - теперь распределённо брутфорсить хэши паролей можно ещё быстрее.
Ответить | Правка | Наверх | Cообщить модератору

	21. "Для Firefox представлен API для задействования в web-приложе..."	+/–
	Сообщение от Xasd (ok), 10-Сен-14, 15:29
	> Не, а чо, клёвая штука - теперь распределённо брутфорсить хэши паролей можно > ещё быстрее. не забудь только на web-сайте написать фразу -- "пожалуйста не закрывайте эту web-страничку. даже если она для вас бесполезна". а-то ведь за 3 секунды много не набрутфорсишь :-)
	Ответить | Правка | Наверх | Cообщить модератору

	53. "Для Firefox представлен API для задействования в web-приложе..."	+/–
	Сообщение от Аноним (-), 10-Сен-14, 21:23
	> не забудь только на web-сайте написать фразу -- "пожалуйста не закрывайте эту > web-страничку. даже если она для вас бесполезна". Да легко. Сделать какую-нибудь казуальную игрушку... А вообше, вот: http://crypto.stanford.edu/flashproxy/ - да-да, некоторые сайты могут тебя без спроса поюзать как websocket-based прокси для анонимизации. И ты будешь проксировать чей-то трафф. Впрочем с учетом надвигающейся интернет-гестаповщины, нам это пригодится.
	Ответить | Правка | Наверх | Cообщить модератору

	67. "Для Firefox представлен API для задействования в web-приложе..."	+/–
	Сообщение от Аноним (-), 10-Сен-14, 23:44
	> http://crypto.stanford.edu/flashproxy/ 404 Только по https открываеца
	Ответить | Правка | Наверх | Cообщить модератору

	82. "Для Firefox представлен API для задействования в web-приложе..."	+/–
	Сообщение от Аноним (-), 11-Сен-14, 05:08
	> Только по https открываеца У меня открывается и так и сяк. Подозреваю что у вас на пути засел какой-то прозрачный прокси поставленный людьми "синдромом вахтера", который видимо не в восторге от таких инициатив как эта. Возможно рубануто по URL.
	Ответить | Правка | Наверх | Cообщить модератору

10. "Для Firefox представлен API для задействования в web-приложе..."	+1 +/–
Сообщение от x0r (??), 10-Сен-14, 13:12
тогда уже проще на PNaCl приложения делать
Ответить | Правка | Наверх | Cообщить модератору

	13. "Для Firefox представлен API для задействования в web-приложе..."	+/–
	Сообщение от Аноним (-), 10-Сен-14, 13:42
	> тогда уже проще на PNaCl приложения делать Мозильщики не ищут легких путей - они предпочитают гланды через ж...у автогеном удалять, адски костылируя JS.
	Ответить | Правка | Наверх | Cообщить модератору

	17. "Для Firefox представлен API для задействования в web-приложе..."	–1 +/–
	Сообщение от Lain_13 (ok), 10-Сен-14, 14:46
	Если учесть, что тебе всё одно руками писать поддержку этих инструкций не нужно и это за тебя сделает Emscripten, то можно считать, что ничего не изменилось, просто некоторый код, скомпилированный в asm.js представление, теперь будет работать быстрее в случае его сборки новыми версиями Emscripten и поддержки этих команд браузером. Строго говоря нет ни какой разницы между PNaCl и asm.js — и то, и другое оперирует с байткодом. Просто байткод для asm.js оформлен в форме JS инструкций и управляющих комментариев, а не бинарный, и потому теоретически его легче читать и понимать, но в большинстве случае тебе всё одно не придётся этого делать.
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	33. "Для Firefox представлен API для задействования в web-приложе..."	+1 +/–
	Сообщение от Crazy Alex (ok), 10-Сен-14, 17:34
	Угу. В теории разницы между теорией и практикой нет. На практике это, понятное дело, не так. Разница в том, что в случае NaCl мы имеем слегка модифицированный существующий компилятор, поддерживаемый большой командой специалистов и работающий без особой чертовщины. Вот этой новости в случае NaCl вообще быть не могло - инструкции - они инструкции и есть, если LLVM их поддерживает для данной платформы - то и будет использовать. А вот с asm.js - трансляция черт знает во что, потом то ли JIT, то ли нет, то ли оптимизируют, то ли не сумеют... Зачем оно всё, есил можно использовать гораздо более прямолинейную технику, да ещё при этом получить гарантированную изоляцию от JS?
	Ответить | Правка | Наверх | Cообщить модератору

	39. "Для Firefox представлен API для задействования в web-приложе..."	–1 +/–
	Сообщение от Lain_13 (ok), 10-Сен-14, 18:42
	Вообще-то asm.js обычно генерируется через Emscripten, который его генерирует в свою очередь из всё того же LLVM байткода. Причём конкретно в Firefox он не JIT, а AOT. По-сути этот всё тот же LLVM байткод, что и PNaCl, только выполняемый штатным компилятором браузера, что как понижает количество лишних компонентов в браузере, так и идёт на пользу этому штатному компилятору так-как его приходится оптимизировать, а от большинства таких оптимизаций выигрывают все, а не только приложения на asm.js. В любом случае для получения того или иного в браузере нужно либо туда засунуть компилятор LLVM-байткода и PPAPI, либо расширить функциональность встроенного компилятора JS. PPAPI надо потому, что PNaCl приложения вынуждены им пользуется, а как ты должен знать Mozilla хоть и участвовала в разработке PPAPI, но забросила этот проект и решила, что плагинов не должно существовать вовсе. В результате PPAPI так и не был принят в Firefox, а без него там невозможен и PNaCl. Из реальных минусов asm.js мне видится только лишь конский размер сгенерированного кода, но это во многом исправимо путём его архивации… что и так обычно происходит при отдаче страниц, стилей и скриптов. PNaCl просто этот шаг пропускает и сразу работает с байткодом, но в результате мы получаем два компилятора в браузере и непонятно зачем нужный API для плагинов вместо развития того, что там и так уже есть.
	Ответить | Правка | Наверх | Cообщить модератору

	55. "Для Firefox представлен API для задействования в web-приложе..."	+1 +/–
	Сообщение от Аноним (-), 10-Сен-14, 21:27
	> из всё того же LLVM байткода. Да, и в результате 1) Лишние действия для програмера. 2) Дурное IR - пухлое и ресурсожoркое. JS никогда не делался для того чтобы быть IR. 3) Уйма костылей и дeбилизмов неизвестно ради чего.
	Ответить | Правка | Наверх | Cообщить модератору

	63. "Для Firefox представлен API для задействования в web-приложе..."	+/–
	Сообщение от Lain_13 (ok), 10-Сен-14, 22:09
	> 1) Лишние действия для програмера. Не совсем понимаю в чём? В компиляции через Emscripten? Она 1 раз настраивается. В отладке? Тут пока да, но это решаемая проблема и ещё решают. > 2) Дурное IR - пухлое и ресурсожoркое. JS никогда не делался для того чтобы быть IR. Я практически это и сказал выше. Это реальный минус, хоть и не сильно существенный, как мне кажется. Тем более, что жрёт только память, да и то в основном за счёт размера кода. asm.js код ведь сразу скармливается AOT-компилятору пропуская стадию интерпретации. Я помню обсуждался вопрос хранения уже собранного бинарного кода локально и подгрузки его из локального хранилища, но не знаю было ли это реализовано. > 3) Уйма костылей и дeбилизмов неизвестно ради чего. А тягать с собой ещё один компилятор, который больше нигде нафиг не нужен, это не костыль? А работать с тем, что в браузере есть напрямую через API для плагинов это не костыль? Фига ж себе! При том, что в asm-js из костылей пожалуй только управляющие комментарии с подсказками для компилятора. Тем более, что они фактически сделали возможной низкоуровневую оптимизацию и AOT компиляцию в обычных веб-проектах и сохранили полную обратную совместимость с обычным JS. Или тебя не устраивает, что они в качестве памяти используют TypedArray?
	Ответить | Правка | Наверх | Cообщить модератору

	69. "Для Firefox представлен API для задействования в web-приложе..."	+/–
	Сообщение от Xasd (ok), 10-Сен-14, 23:56
	всё правильно написал -- и плюсы есть у asm.js и минусы. просто плюсы перевешивают. :) а однобоковая характеристика здесь неуместна (у любой технологии есть и плюсы и минусы).
	Ответить | Правка | Наверх | Cообщить модератору

	74. "Для Firefox представлен API для задействования в web-приложе..."	–1 +/–
	Сообщение от Crazy Alex (ok), 11-Сен-14, 04:04
	Лично меня больше всего не устраивает, что эта хрень продевает жизнь джаваскрипту, сохраняя иллюзию, что на нём можно что-то толковое писать. И ещё раз напоминаю, что в NaCl без буковки P никакого компилятора на стороне клиента не требуется.
	Ответить | Правка | К родителю #63 | Наверх | Cообщить модератору

	83. "Для Firefox представлен API для задействования в web-приложе..."	+/–
	Сообщение от Lain_13 (ok), 11-Сен-14, 05:25
	…и с ним есть такая проблема, как его абсолютная непереносимость ни на что. Сколько там нам разных билдов поддерживать для разных архитектур и фичь разных моделей? Нет, можно, конечно, ограничить себя и запретить использовать современные фичи процессоров, которые есть далеко не у всех, но это как наступать самому себе же на горло. А нафига, если можно собрать 1 раз и будет работать везде со всеми этими оптимизациями? Помимо того asm.js будет работать даже если специальной поддержки для него в браузере нет вовсе. Просто медленно. Если мы не об игре говорим или подобном, то это просто идеальная особенность. Да и с играми порой тоже забавно получается. Так, например, оптимизация под новые технологии в NaCl отсутствует по определению. Код собранный пару лет назад даже под самые современные на тот момент процессоры не будет иметь возможности пользоваться современными фичами процесоров, тогда как собираемый из байткода как минимум попробует. Постоянно выпускать новые билды? До конца своей жизни, а потом ещё и внукам завещать? Ну с онлайн-играми это может и работает, но не все так могут, да и вообще хотят этим заморачиваться, а в результате мы получим странный результат, когда NaCl код собранный под старые системы на новых будет откровенно сливать в производительности и PNaCl, и asm.js, собранным в то же время. А безопасность всего этого безобразия? Да она же как начинается, так и заканчивается в песочнице. Так что ты извини, но у NaCl в вебе недостатки не просто большие, а буквально несовместимые с жизнью. То, что даже Google делают ему замену в форме PNaCl, говорит само за себя. Наступать на грабли в форме архитектурно-зависимых бинарей в браузере всем уже изрядно надоело.
	Ответить | Правка | Наверх | Cообщить модератору

	85. "Для Firefox представлен API для задействования в web-приложе..."	+/–
	Сообщение от Аноним (-), 11-Сен-14, 05:47
	> Не совсем понимаю в чём? В компиляции через Emscripten? Она 1 раз настраивается. Это даже не компиляция а просто дурная трансляция более-менее нормального IR от LLVM в гoрбaтый и кривой IR в виде JS. Просто лишнее действие из-за кpeтинизма мозильщиков. > В отладке? Тут пока да, но это решаемая проблема и ещё решают. Лучше бы они мoгилy себе кoпaли с такой ж@пopyкостью. Впрочем, они неплохо с этим справляются, делая из лисы жaлкий ripoff хрома по виду и фичам (но как видим даже тут лажа выходит - некоторые фичи содpать не могут и городят такой вот у...щный эpзaц). > Я практически это и сказал выше. Это реальный минус, хоть и не > сильно существенный, как мне кажется. Вообще-то существенный, ибо SIMD и прочее - это когда по ресурсам уже прижало настолько что оптимизацией пришлось заморочиться, настолько что некто готов освоить весьма специфичное программирование, которое довольно существенно отличается от обычных подходов. А тут сразу на старте нагaдили везде где могли, ибо JS. Зачем??? > Тем более, что жpёт только память, да и то в основном за счёт размера кода. Жрeтся, извините, 1) Бандвиз. Пухлое представление дольше качать при прочих равных. Когда вес меряется в мегабайтах - не больно кайфово качать в 4 раза больше. 2) Память - не "только" ибо JS ее жpет крупнооптово и счет запросто идет не то что на сотни мегов, а на гигабайты, так что какая-нибудь простенькая игрушка запросто взлетит в системных требованиях до новья AAA, если не больше. 3) Время на парсинг дyрного IR тоже никуда не денется. Проц не знает что такое "a129=453". Он может какое-нибудь "mov r3, #453", которое в бинарном виде занимает ну может 2 байта. Ну может 4. Но врядли больше. А тут - восемь. И эти восем еще надо сперва распарсить и ... перегнать в те пару байтов. Не больно оптимально, а? > asm.js код ведь сразу скармливается AOT-компилятору пропуская стадию интерпретации. Вот только сам JS как IR - шит, и это не лечится иначе чем заменой IRа на что-то более вменяемое. Как шит скармливается - малосущественно. Фэйл сразу на старте, при выборе IR. > вопрос хранения уже собранного бинарного кода локально и подгрузки его из > локального хранилища, но не знаю было ли это реализовано. Кэширование компиленого кода - второй вопрос. А первый - горбатое IR. Гугл предпочел не выеживаться и взять для IR то что задумано быть IR. А мозильщики занялись доработкой микроскопа до состояния когда он кой-как может забить не очень большой гвоздь, если поднакачаться. > А тягать с собой ещё один компилятор, который больше нигде нaфиг не > нужен, это не костыль? Не больший костыль чем JIT в браузере. Этот JIT тоже нигде кроме браузера не требуется. > А работать с тем, что в браузере есть напрямую через API для плагинов > это не костыль? Фига ж себе! Зато оно в результате работает со скоростью нативного кода и, @#$, не ограничено дeбильным HTML. Права там местами порезано, но в остальном это вполне себе такой запуск программы со свойствами близкими к запуску нативной программы. Только от платформы не зависит и не заставляет програмеров изгибаться буквой зю по части оптимизации. Т.к. работает более-менее со скоростью обычной компилированной программы, плюс-минус лапоть. > При том, что в asm-js из костылей пожалуй только управляющие комментарии с > подсказками для компилятора. JS как IR - это даже не костыль а вообще меганекропедозоопорно. Оно нифига не читабельно двуногими (попробуй почитать то что выдает emscripten, да?) но при этом неудобно для машин. Просто удивительно как можно взять все хучшее из обоих миров. Такие инженерные решения и те кто их делает - должны умереть жестокой смертью. > Тем более, что они фактически сделали возможной низкоуровневую > оптимизацию и AOT компиляцию в обычных веб-проектах и сохранили полную обратную > совместимость с обычным JS. Только толку с этой обратной совместимости - буй. То что нуждается в этих трюках - в fallback режиме ... не, ну, конечно, можно чисто для галочки запустить юзеру гамезу, показывая целые 0.5 FPS. Но какую ценность этот кластерфак представляет? Никто не будет полчаса ждать обсчета, смотреть на полтора FPS и прочее. Так что оно есть чисто для галочки. > Или тебя не устраивает, что они в качестве памяти используют TypedArray? Меня не устраивает миндфак с использованием JS как IR. Если нужен IR - возьмите уж нормальные средства. Зачем из микроскопа кувалду то делать? Хреновая кувалда получается!
	Ответить | Правка | К родителю #63 | Наверх | Cообщить модератору

	88. "Для Firefox представлен API для задействования в web-приложе..."	–1 +/–
	Сообщение от Lain_13 (ok), 11-Сен-14, 07:05
	> Вообще-то существенный, ибо SIMD и прочее - это когда по ресурсам уже прижало настолько Вообще-то SIMD в данном случае это когда у тебя есть код, который можно распараллеливать, все так делают, а ты так не делаешь. И если ты не в курсе, то PNaCl тоже поддерживает инструкции SIMD и ему это тоже нужно, а в NaCl с ними и вовсе собирали не решая нужно или не нужно так-как ответ и так очевиден. > Бандвиз. Ну во-первых кто его считает, а во-вторых всё одно потом из кэша в следующий раз поднимется. Особенно если эта игра, которой надо сходу загрузить пару сотен метров моделек и текстур. ± несколько метров тут роли как-то не играют. > Память - не "только" ибо JS ее жpет крупнооптово и счет запросто идет… На близкий к потреблению нативного приложения так-как asm.js без интерпретации сразу скармливается компилятору и дальше работает с памятью как нативное приложение, а не как JS обычно это делает. > Время на парсинг дyрного IR тоже никуда не денется. Это играет свою крайне незначительную роль до первой компиляции и зависит от оптимизаций в самом компиляторе. Парадоксально, но asm.js порой умудряется обгонять PNaCl в скорости загрузки даже на холодном старте: https://blog.mozilla.org/luke/2014/01/14/asm-js-aot-compilat.../ > Т.к. работает более-менее со скоростью обычной компилированной программы, плюс-минус лапоть. Ага, лапоть процентов эдак в 15-20. Да, в asm.js начинал c 50% лаптем, но уж в декабре прошлого года довели до 25% лаптя и с тех пор продолжали его сокращать. Уж не знаю на сколько они это сделали, но разница с родным для системы кодом не существенна у обоих. Оверхед в 5-10% есть даже у NaCl, который вроде как native, а поди ж ты. > Вот только сам JS как IR - шит, и это не лечится иначе чем заменой IRа на что-то более вменяемое. Как шит скармливается - малосущественно. Фэйл сразу на старте, при выборе IR. Но если в твои планы входит исключение лишних сущностей и полная обратная совместимость, то это лютый вин. > Только толку с этой обратной совместимости… Очень много, когда дело касается веб-приложений, которые не прочь работать быстро, но могут и медленно. Графический редактор, например. Есть asm.js — летаем, нет — всё одно пользоваться можно. В конце-концов уже сейчас существуют вполне сносные по скорости работы графические редакторы, написанный на чисто JS. > Не больший костыль чем JIT в браузере. Этот JIT тоже нигде кроме браузера не требуется. Т.е. то, что это костыль, ты не оспариваешь? JIT в компиляторе JS хоть нужен для ускорения работы с JS, который используется считай что везде, тогда как PNaCl это сугубо нишевое решение и держать под это ещё один совершенно иной компилятор, и нафиг ни для чего более не нудное API непонятно зачем надо. Ну кроме как иметь возможность работать с настоящим байткодом и на этом как-то всё. > Меня не устраивает миндфак с использованием JS как IR. И это на самом деле всё, что тебя не устраивает.
	Ответить | Правка | Наверх | Cообщить модератору

	94. "Для Firefox представлен API для задействования в web-приложе..."	+/–
	Сообщение от Аноним (-), 11-Сен-14, 18:28
	> Вообще-то SIMD в данном случае это когда у тебя есть код, который > можно распараллеливать, SIMD - это когда у тебя есть большой кусок данных который надо более-менее однотипно но массово дробить. Тогда данные можно вгружать в отдельные широкие SIMD регистры, оптом. И делать сразу несколько однотипных операций за присест. От чего и наступает профит - за раз дробится заметно более крупная порция данных чем при обычном счете в обычных регистрах. Все это восходит к практически assembly-level пониманию работы железа и оптимизации load/store на предмет того что хорошо бы за 1 команду проца долбануть побольше данных, так что оверхед минимален + хардварная параллелизация. Не в том плане что параллельно выполняется несколько потоков команд. А в том плане что железо за 1 операцию обмолотит несколько порций данных сразу. Но реализация подобных техник в JS смотрится как утонченный глум над программистами. Ибо мальчики-вебдванольчики не способны к мышлению на таком уровне, а тем кто так мыслить может - JS ничего кроме борьбы с искусственно созданными сложностями не может предложить. Т.к. изначально он делался совсем не для этого. А тут к тому же местечковые, ни с чем не совместимые костыли. > все так делают, а ты так не делаешь. Ну я понимаю что у мальчиков-вебдванольчиков это вызывает чувство собственной неполноценности, но вы неполноценные не потому что так не умеете, а потому что не понимаете как работают компьютеры. Для вас компьютер - черный ящик. > И если ты не в курсе, то PNaCl тоже поддерживает инструкции SIMD > и ему это тоже нужно, А PNaCl для начала намного более вменяемый IR для передачи программ использует. JS как IR - это пиндец, товарищи. Мозилла же вместо того чтобы осознать что микроскопом гвозди забивать субоптимально - занимается оптимизацией массы основания и формы тубуса, попутно заявляя что мы тут должны поднакачаться. Хотя молотками мы и так гвозди бойко фигачили, а то что микроскопом это делать неудобно - бакланами из мозиллы просто игнорируется. > а в NaCl с ними и вовсе собирали не решая нужно или не нужно так-как ответ и > так очевиден. А NaCl - непортабелен. Это жирный минус. Популяризуется завтра какой-нибудь MIPS и юзер с мипсовым ноутом будет в обломе (транслировать x86 -> MIPS не самое эффективное занятие). В pnacl умнее - платформонейтральный биткод который на месте перегоняется в нативный для вон той платформы. Так ARM себе из нейтрального кода сделает нативный ARMовый, MIPS - MIPSовый, ну и так далее. В общем чем-то на Java похоже, только без невъ...х рантаймов и с относительно низкоуровневой механикой. Жаба как-то так сама по себе и с немеряным рантаймом. Готовые программы на сях или плюсах в нее ну не то чтобы принципиально невозможно транслировать, но эффективных и простых методов так делать - нет. А полтора кривых аплета писаных с ноля, с рантаймом который взлетает полчаса, вгружая 100500 либ на все случаи жизни - да ну его такое нафиг?! Кому он такой нужен и зачем? > Ну во-первых кто его считает, Те кто файлы отгружает - если один и тот же сервер может сервировать в три раза больше народа - PROFIT. И те кто их качает. Например гамеза сколь-нибудь серьезнее примитивных казуалок - это минимум несколько метров кода. Круто если 10 мегов превратятся в 30, да? А юзер не устанет загрузки ждать? Да и потом у него чего доброго OOM браузер пристрелит, когда он этот пи...ц парсить попытается :). > а во-вторых всё одно потом из кэша Первое впечатление - решает. Если юзер не дождется загрузки в первый раз - никакого "потом" у вас не будет! Это настолько базовая грабля юзабилити что я вообще не понимаю что вы там разрабатываете, если не в курсе этой "мелочи", способной в два счета накрыть медным тазом любой проект. > в следующий раз поднимется. Следующего раза при таком подходе не будет. > Особенно если эта игра, которой надо сходу загрузить пару сотен метров > моделек и текстур. ± несколько метров тут роли как-то не играют. Да, конечно, если не считать того что загрузку устанешь ждать, парсинг JSа юзера выморозит, да и 200 мегов из JS парсить - не больно приятно, браузер рискует по OOM вылететь в два счета. Особенно учитывая что ему еще на вход ...цатимеговую простыню исполняемого кода в виде "типа, текста" дали. Даже у относительно простых игр эта простынка весит по несколько метров и неиллюзорно клинит браузер, который постоянно орет "slow script!" и просто истошно тормозит по 5 минут. > На близкий к потреблению нативного приложения Никакого близкого не получится - хотя-бы потому что начальное представление в несколько раз жирнее нативного кода. А его еще парсить и код из этого генерить. Поэтому даже тривиальная игрушка в результате память лопает круче чем нативные AAA игры, а браузер то орет на медленный скрипт, то падает по OOM. Кластерфак. > так-как asm.js без интерпретации сразу скармливается компилятору и дальше работает > с памятью как нативное приложение, а не как JS обычно это делает. Видели мы эти "нативные" приложения. В виде 10 метровой простыни с текстом типа a129=453 в количестве нескольких мегабайтов и более. Браузер неиллюзорно клинит при вгрузке этой простыни (вплоть до воплей про медленный скрипт) и он кушает оптовое количество ресурсов. > Это играет свою крайне незначительную роль до первой компиляции Вообще-то по моим наблюдениям - вполне себе значительную. Смотреть на заклиненый браузер пару минут и клацать диалоги про медленные скрипты - не здорово. И первое впечатление - самое важное. Если юзер не дождется - второго шанса попросту не будет. > и зависит от оптимизаций в самом компиляторе. Парадоксально, но asm.js порой > умудряется обгонять PNaCl в скорости загрузки даже на холодном старте: > https://blog.mozilla.org/luke/2014/01/14/asm-js-aot-compilat.../ Блин, вы еще на сайте микрософта про винду почитайте - они тоже линукс обгоняют, главное максимально синтетический пример брать. Там как-то так очень странно выпячены лишь 2 теста в разных случаях. Видимо, в остальных случаях натянуть не вышло? :) Но т.к. это все-таки не MS - там есть очень интересная секция: JIT Problems. Как вам ее содержимое? > Ага, лапоть процентов эдак в 15-20. Да когда как. Те кто портировал свои игры на pnacl основной проблемой называли в основном борьбу с порубаными правами, что заставляет погреть мозг с загрузкой ресурсов, но это как раз относительно легко починить. А те кто ипaлся с emscripten вечно долбутся с клинами браузера на ***минуты***, постоянной руганью про slow script и прочими прелестями. При том если я понимаю как профайлить нативную программу - как сколь-нибудь вменяемо профайлить тот шит который выдает emscripten я вообще не понимаю. JS представление неинформативная простыня на уровне хексдампа, чесать репу чем же было то "a129=453" в оригинале программы - эээ... как бы это сказать... кластерфак это. > Да, в asm.js начинал c 50% лаптем, но уж в декабре прошлого года довели до 25% лаптя Да вообще зае...сь: после того как ты по@#$%шься с чуть ли не assembly level оптимизацией, просирoн нативному коду будет не в два раза а всего на треть, при диком жpaче памяти и воплях браузера про slow script. Очень "круто". Тогда как в гуглохроме программа буквально просто запускается почти без переделки (ну может вгрузка ресурсов) и работает как обычно. Минимум брейнфака. > и с тех пор продолжали его сокращать. Главное с 1929 годом не забывать сравнивать, чтобы этот булшит и кластерфак покрасивее смотрелся. > не существенна у обоих. Оверхед в 5-10% есть даже у NaCl, > который вроде как native, а поди ж ты. Плюс pnacl - в том что он сделан достаточно вменяемо. Нормальный IR, более-менее обычные программы, никаких клинов на минуты всего браузера и визгов про медленный скрипты, никакого жрача памяти гигабайтами. Из особенностей програмер вообще замечает - права порезаны. Ну, да, загружаемой снаружи программе никто не даст шариться по всей системе. А у мозиллы надо много кастомного кластерфака, при том что результат хуже и предоставляет уйму дурных грабель на все вкусы. Потому что глупая это идея - JS в качестве IR для передачи программ использовать. Ну не делался JS для того чтобы IRом быть. > Но если в твои планы входит исключение лишних сущностей Emscripten - лишняя сущность. Представление программы как JS-портянки - лишняя сущность и адовы костыли. И SIMD в JS - лишняя сущность. > и полная обратная совместимость, то это лютый вин. Это громкие бла-бла ни о чем, ибо если случился fallback - никому ваши 0.5 FPS нафиг не упали, хоть это и "обратно совместимо". Как уже было сказано тем кексом на которого вы сослались, с предсказуемостью скорости вычислений и так то ж...а, а если еще и fallback рассмотреть - програмер вообще опупеет с этим бодаться. > Очень много, когда дело касается веб-приложений, которые не прочь работать быстро, Если кому не надо работать быстро - SIMD ему и подавно не уперся. Ломать свой мозг тем чтобы грузить и долбить данные не так как логично на первый взгляд, а так как удобно машине - это уже заявка на весьма хардкорную оптимизацию. А тут на тебе - JS везде. > но могут и медленно. Графический редактор, например. Ага, угу. Попробуй на фото на 10 Мпикс покрутить кривые например. Да чтобы с показом результата, ибо вслепую крутить - EPIC FAIL. Сразу осознаешь зачем мощные процессоры и многопоточность требуются. > Есть asm.js — летаем, Ага, считаем в 2 раза медленнее гимпа. > нет — всё одно пользоваться можно. Да, только при мало-мальски ресурсоемкой операции можно оставлять писюк пахать на ночь. > В конце-концов уже сейчас существуют вполне сносные по скорости работы > графические редакторы, написанный на чисто JS. Ну да, а opencl в них прикручивают наверно для прикола. А вовсе и не потому что так в ...цать раз быстрее, а юзеров бесит когда все дико тормозит. На секундочку, применить сколь-нибудь продвинутые операции к МИЛЛИОНАМ пикселей - это не быстро нифига. А если у нас еще и фоток сто штук... > Т.е. то, что это костыль, ты не оспариваешь? Весь JS - большой костыль. Не понимаю почему надо было завязаться на один единственный ЯП с далеко не лучшими свойствами. А потом особо утонченные извращенцы стали его еще и как IR для передачи платформонезависимых программ использовать, что совсем уж форменное е...тство. > JIT в компиляторе JS хоть нужен для ускорения работы с JS, который > используется считай что везде, Для именно легкого скриптинга страничек - JIT даром не упал. А если уж кто полез воротить кодеки, криптографию, игры и прочее - так можно было нормальный IR и тулчейн взять хотя-бы, а не делать из микроскопа хреновенькое подобие кувалды. > ни для чего более не нудное API непонятно зачем надо. Это апи нужно для того же для чего и JS с SIMD и JIT. Только для програмера намного меньше брейнфака при более хорошем результате. Что ни говори, а представлять промежуточную форму программы как "типа, текстовый JS" - идиотизм. Читать то что выдал Emscripten как текст можно только если брейнфак показался слишком простым и очевидным :). > Ну кроме как иметь возможность работать с настоящим байткодом и на этом > как-то всё. Ну да, человеческое компактное и простое в парсинге IR забыли. А так все хорошо >> Меня не устраивает миндфак с использованием JS как IR. > И это на самом деле всё, что тебя не устраивает. И еще уйма левого, файрфокс-специфичного миндфака, отсутствующего где либо еще, левые тулзы типа емскриптена и полные непонятки с тем как это отлаживать и профилировать. А так все хорошо, прекрасная маркиза. Поэтому со своей стороны я бы предпочел чтобы фокс просто сдох с таким подходом и его место сожрал хром. Если как програмеру рассматривать мир - жизнь после этого стала бы сильно проще.
	Ответить | Правка | Наверх | Cообщить модератору

	98. "Для Firefox представлен API для задействования в web-приложе..."	–1 +/–
	Сообщение от Lain_13 (ok), 11-Сен-14, 20:29
	Я просто оставлю тут вот эту ссылку, а то она тебе вроде как нужна: https://github.com/kripken/BananaBread/ - открывай в фоксе и переходи по non-stable testing version. А то спорить с твоим потоком сознания и навязчивыми идеями о "slow script" и просто таки диком жраче памяти мне как-то не с руки. Я согласен только с тем, что JS слишком толстый для IR и с тем, что ещё не все вопросы с отладкой решены.
	Ответить | Правка | Наверх | Cообщить модератору

	73. "Для Firefox представлен API для задействования в web-приложе..."	–1 +/–
	Сообщение от Crazy Alex (ok), 11-Сен-14, 04:01
	ХЗ какой он там байткод, но  новости вроде текущей ясно показывают, что оно требует каких-то дополнительных телодвижений для скармливания вменяемого кода процессору по сравнению с PNaCl.  И тем более -  по сравнению с NaCl, в котором вообще готовый исполняемый бинарь прилетает. Учитывая, что у нас живых аж шесть архитектур - (а по факту - три: intel 32/64 и arm32) - на практике необходимость PNaCl не слишком очевидна. А что Мозилла последние несколько лет двинулась головой и отчаянно старается воевать с гуглом, беря из Хрома только худшее - ну да, есть такое. Что ж делать. А API для плагинов - это хорошо. Это значит, что у браузера чуть меньше шансов оказаться вешью в себе и чуть больше - взаимодействовать с окружением, в котором он находится.
	Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

	84. "Для Firefox представлен API для задействования в web-приложе..."	–2 +/–
	Сообщение от Lain_13 (ok), 11-Сен-14, 05:44
	О да, плагины это вообще такая классная штука. Сколько лет уже наблюдаем постояную галиматью с Флэшем, Явой и прочими кривыми недоделками. Очень хорошо и, главное, нужно. Их не должно существовать. Вообще. А про дополнительные телодвижения это чьи телодвижения-то? Твои или Мозиллы, Интела и Гугла? А тебе не пофиг каким местом и когда они там двигают? А сколько нужно телодвижений и кому, чтоб сделать новую оптимизацию или фичу в том, чем ты NaCl код собирал? Про NaCl я выше уже написал и тремя архитектурами тут не отделаешься. Придётся вести пожизненную поддержку этому геморрою, а когда внезапно появится ещё одна архитектура (кто-то ожидал ещё 10 лет назад ARMы в каждом доме?), то все старые бинари можно будет просто выбрасывать на помойку, а кто новые версии собирать будет?
	Ответить | Правка | Наверх | Cообщить модератору

	86. "Для Firefox представлен API для задействования в web-приложе..."	+/–
	Сообщение от Аноним (-), 11-Сен-14, 05:52
	> и, главное, нужно. Их не должно существовать. Вообще. Тогда если нужна нормальная производительность в приложениях - сделайте нормальнй IR. JS как IR - это полный кластерфак. Он для этого не создавался и то что делают мозильщики - это п...ц какой-то. > двигают? Про NaCl я выше уже написал и тремя архитектурами тут > не отделаешься. Придётся вести пожизненную поддержку этому геморрою, Ну если JIT JSовский можно поддерживать - то и этот выводок LLVM можно. И геморрой - это когда некто предлагает записать компиленую программу как текстовый скрипт, каковым оно ни разу не являлось, и поэтому оттранслировано по методу "я его слепила из того что было". > в каждом доме?), то все старые бинари можно будет просто выбрасывать > на помойку, а кто новые версии собирать будет? В случае pnacl ничего выбрасывать не придется - pnacl отгружает платформонейтральный биткод, а он уже на месте перегоняется в нативный. Так что если для этой новой архитектуры есть бэкэнд - ну и на нее перегонится.
	Ответить | Правка | Наверх | Cообщить модератору

	87. "Для Firefox представлен API для задействования в web-приложе..."	–1 +/–
	Сообщение от Lain_13 (ok), 11-Сен-14, 06:04
	Ну Crazy Alex тут задвигает, что NaCl и больше не надо. А тут видишь, уже как минимум PNaCl надо и одним лишь NaCl не отделаешься. Ну а про достоинства и недостатки asm.js vs PNaCl тут и я писал, и другие, и я конский размер «байткода» asm.js не считаю критическим и непоправимым недостатоком в сравнении с PNaCl. Один раз собрал, закэшировал локально нативный бинарник и грузи его на здоровье потом вообще ничего не загружая из веба и не пересобирая без веской на то причины. Собственно о нём тут, например: https://blog.mozilla.org/luke/2014/01/14/asm-js-aot-compilat.../
	Ответить | Правка | Наверх | Cообщить модератору

	95. "Для Firefox представлен API для задействования в web-приложе..."	+/–
	Сообщение от Аноним (-), 11-Сен-14, 19:53
	> Ну Crazy Alex тут задвигает, что NaCl и больше не надо. IMO, PNaCl - чтобы не вышло так что обладатели очередной архитектуры внезапно в пролете. Про кроссплатформенность мы забывать все-таки не будем, в этом весь пойнт веба. Вообще, вы когда-нибудь слышали про "процесс-странник"? Ну так, чтобы понимать как все это с сетями, виртуализацией и прочим может быть "по максимуму". Насколько и кому оно надо, кто и как это видит и насколько это может хорошо работать в современных реалиях - второй вопрос, однако конвергенцию в этом направлении можно видеть невооруженным глазом. > А тут видишь, уже как минимум PNaCl надо и одним лишь NaCl не отделаешься. Потому что идея собирать все только под 1 архитектуру - порочна по своей сути. С JIT кстати такая же фигня. И он, кстати, как и бэкэнды pnacl есть не для всех архитектур. Но сделать 1 бэкэнд проще чем убедить всех перекомпилить всё и вся. А без JIT JS будет работать ну понятно как, в этом плане JIT ничем не лучше. Он вообще уйму непредсказуемости добавляет и прямо в рантайме лопает прорву ресурсов. AOT в этом плане лучше, но если уж делать AOT - так по человечески, а не с JS в качестве IR, блин. Потому что это - извращение, похуже хоккея на траве и балета на льду. > тут и я писал, и другие, и я конский размер «байткода» > asm.js не считаю критическим и непоправимым недостатоком в сравнении с PNaCl. А я считаю что в сумме с точки зрения разработчика весь этот oнaнизм с потугами использовать JS как промежуточное представление программ - некропедозообдсмпорно в хучшем виде который вообще можно придумать. В результате много долботни с проблемами созданными на ровном месте, при достаточно поганом и малопредсказуемом результате. А разработчик должен сильно фачить себе мозг особенностями малопопулярного нишевого рантайма, который есть в 1 браузере, старательно продувающем рынок. > Один раз собрал, закэшировал локально нативный бинарник и грузи его на > здоровье потом вообще ничего не загружая из веба и не пересобирая А почему, на секундочку, нельзя сразу качать бинарник в человеческом виде? Не в нативном (так кроссплатформенность пролюбится, что неприемлимо) так хоть в каком-то *разумно* скроенном IR, которое компактное и просто, быстро, предсказуемо и без дикого жранья ресурсов перегоняется в нативный код без кучи дурных ограничений и особенностей, фачащими мозг разработчику. > без веской на то причины. Собственно о нём тут, например: https://blog.mozilla.org/luke/2014/01/14/asm-js-aot-compilat.../ JS головного мозга. С пофигизмом на ряд довольно фундаментальных проблем. Нормальные люди поняв что им надо вбить гвоздь - берут молоток. Мозильщики истошно оптимизируют микроскоп в надежде что любимой тулзой тоже можно станет забивать гвозди.
	Ответить | Правка | Наверх | Cообщить модератору

	54. "Для Firefox представлен API для задействования в web-приложе..."	+/–
	Сообщение от Аноним (-), 10-Сен-14, 21:25
	> Если учесть, что тебе всё одно руками писать поддержку этих инструкций не > нужно и это за тебя сделает Emscripten, то можно считать, что > ничего не изменилось, ...кроме того что JS - очень галимный вариант промежуточного выполняемого кода. И грузится в браузер многометровая портфнка. Которую уже не прочитаешь, ибо читать минимизированный автосгенеренный код удовольствие на любителя, и которая тормозит и память жрет в три горла. В этом плане гугл получает 5 очков форы вперед - нормальный тулчайн, человеческий подход.
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

16. "Для Firefox представлен API для задействования в web-приложе..."	+/–
Сообщение от клоун (?), 10-Сен-14, 14:08
Ещё один нестандартизированный и ни с кем не совместимый API в HTML. Ура! Ура! Ура! Больше бардака. Больше!
Ответить | Правка | Наверх | Cообщить модератору

	18. "Для Firefox представлен API для задействования в web-приложе..."	+1 +/–
	Сообщение от Lain_13 (ok), 10-Сен-14, 15:03
	А теперь ходим по ссылкам в статье и фалломорфируем от осознания того факта, что этот API оказался каким-то образом совместим с Хромом и выдаёт там те же плюшки, что и в Фоксе. Действительно, как же так получилось? Может дело в том, что над этим API работала не только Мозилла, но и Google, и даже Intel, чем сходу превратили его в совместимый со всеми нормальными браузерами стандарт de facto? Причём поработали так, что идентичный профит получился даже на процессорах от AMD, которые в статье не указаны. Более того, они все вместе работают над продвижением этого API в ES7, что сделает его стандартом de jure. У тебя есть возражения против API для распараллеливания вычислений в стандарте ES7?
	Ответить | Правка | Наверх | Cообщить модератору

	23. "Для Firefox представлен API для задействования в web-приложе..."	+/–
	Сообщение от Latin1 (?), 10-Сен-14, 15:55
	> идентичный профит получился даже на процессорах от AMD Процессоры AMD реализуют SIMD-инструкции Intel.
	Ответить | Правка | Наверх | Cообщить модератору

	31. "Для Firefox представлен API для задействования в web-приложе..."	+/–
	Сообщение от Stellarwind (?), 10-Сен-14, 17:23
	В статье написано ARM, а не AMD :) Товарищ читал по диагонали.
	Ответить | Правка | Наверх | Cообщить модератору

	36. "Для Firefox представлен API для задействования в web-приложе..."	–1 +/–
	Сообщение от Lain_13 (ok), 10-Сен-14, 18:14
	Если ты это обо мне, то нет, я в курсе, что в статье написано ARM, но фокус в том, что на процессорах AMD все эти оптимизации дают тот же профит, хотя AMD в разработке стандарта вроде как не участвовало. Ну а он мне пояснил почему, за что ему спасибо.
	Ответить | Правка | Наверх | Cообщить модератору

	25. "Для Firefox представлен API для задействования в web-приложе..."	+/–
	Сообщение от клоун (?), 10-Сен-14, 16:11
	> совместимый со всеми нормальными браузерами стандарт Этот стандарт уже существует и называется HTML5. Я пытаюсь достучаться до твоего разума и сказать ему: что ещё один не-стандарт, который некоторые браузеры считают стандартом, а другие не считают, а третьи реализуют иначе, ничего, кроме бардака, не создаёт.
	Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

	26. "Для Firefox представлен API для задействования в web-приложе..."	+1 +/–
	Сообщение от Lain_13 (ok), 10-Сен-14, 16:25
	Знаешь, мне даже дико интересно стало как ты собираешься приплести API для распараллеливания вычислений в JS к стандарту для разметки веб-страниц. Да что меня, я уверен, что мы тут все сейчас внимательно тебя слушаем.
	Ответить | Правка | Наверх | Cообщить модератору

	27. "Для Firefox представлен API для задействования в web-приложе..."	–1 +/–
	Сообщение от клоун (?), 10-Сен-14, 16:34
	HTML5 был создан, как единый язык разметки. Он расширяет, улучшает, ля-ля-ля, а также добавляет единое API для сложных веб-приложений. единое API для веб-приложений единое API единое API > как ты собираешься приплести API  к стандарту для разметки веб-страниц http://www.w3.org/Consortium/contact
	Ответить | Правка | Наверх | Cообщить модератору

	28. "Для Firefox представлен API для задействования в web-приложе..."	+/–
	Сообщение от Lain_13 (ok), 10-Сен-14, 16:47
	Ок, и какое это всё имеет отношение к расширению стандарта ECMAScript путём добавление нового API в спецификацию ES7? Каким образом это нарушает единый API для веб-приложений? Ты вообще хот раз задумывался над тем что именно подразумевается под API для веб-приложений в контексте языка разметки веб-страниц и какое это всё имеет отношение к JS?
	Ответить | Правка | Наверх | Cообщить модератору

	30. "Для Firefox представлен API для задействования в web-приложе..."	–3 +/–
	Сообщение от клоун (?), 10-Сен-14, 17:16
	Не дошло... Ну и ладно. Хочешь, анекдот расскажу? Слушай: ЛОПАТА.
	Ответить | Правка | Наверх | Cообщить модератору

	34. "Для Firefox представлен API для задействования в web-приложе..."	+/–
	Сообщение от Lain_13 (ok), 10-Сен-14, 18:09
	Ну извини, я тебе рассказывать всё это так, чтоб дошло, не намерен. И так предоставил более чем достаточно наводящих вопросов.
	Ответить | Правка | Наверх | Cообщить модератору

	35. "Для Firefox представлен API для задействования в web-приложе..."	+2 +/–
	Сообщение от Geol (ok), 10-Сен-14, 18:14
	HTML5 не язык разметки HTML5 не добавляет единое API для веб-приложений. Он объединяет стандартом требования к разметке и  пару десятков разных пересекающихся и не очень JavaScript API =)
	Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

Часть нити удалена модератором

	38. "Для Firefox представлен API для задействования в web-приложе..."	+/–
	Сообщение от Geol (ok), 10-Сен-14, 18:35
	> До тебя тоже не дошло, что уже есть ЕДИНЫЙ СТАНДАРТ. И что До меня не дошло, каким боком стандарт  HTML5/5.1 пересекается с Asm.js? Это же вещи сорвершенно разные, почти  не имеющие друг к другу отношения. > вместо его развития создают множество локальных не-стандартов, которые затем будут продвигать > на стандарты. Ну примерно так HTML5 и возник, да =) > Ты линуксоид, тебе привычно, что программа может не запуститься на дистре соседа, > но для меня это бред сивой кобылы. Это не очень про меня и не совсем понятно к чему.
	Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

	43. "Для Firefox представлен API для задействования в web-приложе..."	+/–
	Сообщение от Lain_13 (ok), 10-Сен-14, 19:14
	Ну давай обратимся к W3C: http://www.w3.org/TR/html5/ Если верить секции Abstract, то HTML5 это очередная версия спецификации языка разметки гипертекста Она, как и её предыдущие версии, как определяет новые элементы страницы в этом языке, так и то, как с ними можно взаимодействовать из кода. Сверх того она определяет набор объектов, который должен быть доступен из кода в самом браузере, и тут я согласен, что к разметке страницы они отношения действительно не имеют (собственно как и взаимодействие с элементами страницы), но это ведь уже давно не новость — HTML4 тоже не ограничивался одним лишь языком разметки. Я всё это к тому, что я не согласен с тем, что это «не язык разметки», хотя согласен с тем, что спецификация HTML5 определяет нечто большее, нежели язык разметки гипертекста. Важным моментом является то, что HTML5 никак не ограничивает JS в наборе используемых в нём команд, а лишь описывает какие свойства и функции должны быть доступны у объектов на странице и в самом браузере из JS. За функциональность самого JS отвечает спецификация ECMAScript и реализация новых API в ней вообще никак не влияет на совместимость кода с HTML5. Именно потому мне так забавно наблюдать за тем, как тов. клоун пытается утверждать обратное.
	Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

	48. "Для Firefox представлен API для задействования в web-приложе..."	+/–
	Сообщение от Geol (ok), 10-Сен-14, 19:23
	> Я всё это к тому, что я не согласен с тем, что > это «не язык разметки», хотя согласен с тем, что спецификация HTML5 > определяет нечто большее, нежели язык разметки гипертекста. Ну вопрос определения. Пусть будет "не только язык разметки" (В спецификации про разметку поцентов 10%) > Важным моментом является то, что HTML5 никак не ограничивает JS в наборе > используемых в нём команд, а лишь описывает какие свойства и функции должны быть доступны у объектов на странице и в самом браузере Ну а я про что? Это и называется API > из JS. За функциональность JS отвечает спецификация ECMAScript. Разумеется. или ты это клоуну?
	Ответить | Правка | Наверх | Cообщить модератору

	49. "Для Firefox представлен API для задействования в web-приложе..."	+/–
	Сообщение от Lain_13 (ok), 10-Сен-14, 19:29
	> Ну а я про что? Это и называется API Я и не говорю, что это не так. Просто тов. клоун утверждает, что добавление нового API в JS каким-то магическим образом нарушает эти и мне реально интересно было услышать от него каким именно макаром это происходит, а он мне вместо этого анекдот про лопату рассказал. :(
	Ответить | Правка | Наверх | Cообщить модератору

	96. "Для Firefox представлен API для задействования в web-приложе..."	+1 +/–
	Сообщение от Аноним (-), 11-Сен-14, 19:59
	> это происходит, а он мне вместо этого анекдот про лопату рассказал. :( Ну что ты как маленький? Досадно клоуну, что его любимый IE-е-е - теперь отнюдь не то место где случается проба пера разных инноваций. Особенно учитывая с какой скоростью fallback работать будет. Представь себе: юзер хрома качнет программу в pnacl и оно будет работать со скоростью нативной. Юзер лисы почертыхается на тупняки, но в конце концов 30 FPS получит, хоть и дерганые. А тут ишак. Показывает 0.5FPS в fallback, pnacl - нет, ну и все такое прочее. Что скажет юзер про 0.5FPS? "Ваш браузер г@вно!!!111"
	Ответить | Правка | Наверх | Cообщить модератору

	50. "Для Firefox представлен API для задействования в web-приложе..."	+/–
	Сообщение от Anonplus (?), 10-Сен-14, 19:46
	Не выдирай слова из контекста. Это я про единое API. HTML и JS это не две разные реализации одного и того же. Это совсем разные сущности. Это все равно, что ты бы предложил привести к одному стандарту TCP/IP и C++ на том основании, что эти стандарты задействованы вместе при создании некоей программы.
	Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

	75. "Для Firefox представлен API для задействования в web-приложе..."	–1 +/–
	Сообщение от клоун (?), 11-Сен-14, 04:06
	Firefox браузер или нет? Задача браузера (единственная) - правильное отображение веб страниц. Нтмл5 - стандарт правильного отображения веб страниц. Никаких других стандартов быть не должно.
	Ответить | Правка | Наверх | Cообщить модератору

	89. "Для Firefox представлен API для задействования в web-приложе..."	–1 +/–
	Сообщение от Lain_13 (ok), 11-Сен-14, 07:32
	Да, давай сначала давать свои собственны определения терминам, а потом строить из них совершенно абсурдные выводы. Сходи ознакомься со значениями терминов «браузер» и «HTML5». Можешь потом не возвращаться.
	Ответить | Правка | Наверх | Cообщить модератору

	90. "Для Firefox представлен API для задействования в web-приложе..."	–1 +/–
	Сообщение от клоун (?), 11-Сен-14, 14:15
	Чем больше ты пытаешься умничать, тем больше я убеждаюсь что прав.
	Ответить | Правка | Наверх | Cообщить модератору

	91. "Для Firefox представлен API для задействования в web-приложе..."	+/–
	Сообщение от Lain_13 (ok), 11-Сен-14, 14:19
	> Чем больше ты пытаешься умничать, тем больше я убеждаюсь что прав. Ну естественно я прав, разве могло быть иначе? Спасибо, что наконец признал это.
	Ответить | Правка | Наверх | Cообщить модератору

	97. "Для Firefox представлен API для задействования в web-приложе..."	+/–
	Сообщение от Аноним (-), 11-Сен-14, 20:02
	> Никаких других стандартов быть не должно. Ну тогда после реализации HTML5 можешь ложиться в могилку и присыпаться земличкой. Ведь больше делать нечего, так? :)
	Ответить | Правка | К родителю #75 | Наверх | Cообщить модератору

	101. "Для Firefox представлен API для задействования в web-приложе..."	–1 +/–
	Сообщение от клоун (?), 12-Сен-14, 11:08
	Ситуация с web-документами такая же, как и с электронными: должен быть один стандарт, который поддерживается всеми и никто его не косяпорит. Только это гарантирует, что однажды сверстанная страница будет одинаково отображаться и работать во всех браузерах: как нынешних, так и будущих. С электронными документами понимание этой простой истины уже пришло, с web-документами ещё нет. И наоборот: стандарт web-документов прописан весьма детально и достаточно полно охватывает все возможные элементы страницы, вкл. скриптовый язык. Стандарта электронных документов до сих пор не создано, есть два недо-стандарта: 1. OOXML - описывает всё, но слишком сложен и поэтому никем так и не реализован 2. ODF - неполностью описывает все элементы (так напр. до сих пор не описан скриптовый язык), что создаёт "возможности для творчества" в плане формата файла. В итоге имеем: и там полдела, и здесь полдела. И нигде нет порядка, один бардак. И я с каждым годом всё больше склоняюсь к мысли о гос. регулировании и блокировании (на уровне провайдеров) файлов не по стандарту. Такая же фигня (такой же бардак) была с зарядными устройствами для телефонов, пока государству всё это не остохернело и оно не зарегулировало эту сферу по самое не балуйся. Ну вот зачем доводить до такого?
	Ответить | Правка | Наверх | Cообщить модератору

	102. "Для Firefox представлен API для задействования в web-приложе..."	–1 +/–
	Сообщение от Geol (ok), 12-Сен-14, 11:24
	> Ситуация с web-документами такая же, как и с электронными: должен быть один > стандарт, который поддерживается всеми и никто его не косяпорит. Только это > И наоборот: стандарт web-документов прописан весьма детально и достаточно полно охватывает Стандарт HTML и стандарт язырка JavaScript (EcmaScript) - это два разных, непересекающихся стандарта. Так понятно? Asm.js никаким боком к отображению html-разметки не относиться.
	Ответить | Правка | Наверх | Cообщить модератору

	103. "Для Firefox представлен API для задействования в web-приложе..."	–1 +/–
	Сообщение от клоун (?), 12-Сен-14, 11:38
	Вот и камень преткновения. Я считаю, что стандарт документов (электронных, web, таблиц, ..) должен быть полным. Всё, что может быть в документе, должно описываться в стандарте. Иначе НЕЛЬЗЯ ГАРАНТИРОВАТЬ корректное отображение документа, а без этого теряется весь смысл.
	Ответить | Правка | Наверх | Cообщить модератору

	104. "Для Firefox представлен API для задействования в web-приложе..."	+/–
	Сообщение от Geol (ok), 12-Сен-14, 12:09
	> Вот и камень преткновения. > Я считаю, что стандарт документов (электронных, web, таблиц, ..) должен быть полным. > Всё, что может быть в документе, должно описываться в стандарте. Иначе > НЕЛЬЗЯ ГАРАНТИРОВАТЬ корректное отображение документа, а без этого теряется весь смысл. Причем тут вообще отображение документа? EcmaScript имеет к нему ровно такое же отношение как и стандарт на C/C++
	Ответить | Правка | Наверх | Cообщить модератору

	108. "Для Firefox представлен API для задействования в web-приложе..."	–1 +/–
	Сообщение от Anonym2 (?), 14-Сен-14, 23:11
	>> Вот и камень преткновения. >> Я считаю, что стандарт документов (электронных, web, таблиц, ..) должен быть полным. >> Всё, что может быть в документе, должно описываться в стандарте. Иначе >> НЕЛЬЗЯ ГАРАНТИРОВАТЬ корректное отображение документа, а без этого теряется весь смысл. > Причем тут вообще отображение документа? EcmaScript имеет к нему ровно такое же > отношение как и стандарт на C/C++ Вот уже ни причём, при том что должно быть при чём. То есть так называемый браузер Firefox со свими приблудами оказывается не имеющим никакого отношения к какому-то отображению документов... К Ecma эти приблуды имеют так же не большее отношение. И даже можно поставить вопрос является ли это из Firefox собственно [i]приблудами[/i] в собственном значении этого слова. Что осталось? Осталось некое блодвар...
	Ответить | Правка | Наверх | Cообщить модератору

	52. "Для Firefox представлен API для задействования в web-приложе..."	+/–
	Сообщение от Michael Shigorin (ok), 10-Сен-14, 20:13
	Ну вот, весь кайф поломали поклоннику одной копрорации, которая как раз и славится "ещё одними нестандартизированными ни с чем не совместимыми" и если бы только API... PS: #37 удалено как преднамеренная ложь.
	Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

106. "Для Firefox представлен API для задействования в web-приложе..."	–1 +/–
Сообщение от Брат Анонпитонер (?), 13-Сен-14, 13:35
Только тырнет не 1,44, а 3.14. Для фешуя, не?
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема