Здравствуйте, Ikemefula, Вы писали:
I>Примерно так:<script type="text/python(tcl, rexx и тд)">
Koгда и где такое работало? В Brython? Это как раз на коленках собранная альтернативная реализация на JS. В результате у тебя нет ни скорости ни совместимости.
Здравствуйте, alex_public, Вы писали:
_>Работу с web api (и не только — это будет общий механизм для взаимодействия с любым api программы, в которую встраивается движок wasm) будут обеспечивать эти самые "прозрачные" ссылки (я там выше опечатался — задумался о другом и вставил лишнее "не"): "a new set of operators would be added for allocating, deallocating, loading and storing from integer-indexed cells that could hold references". Т.е. очевидно что это ближе к классическому OS API на дескрипторах, без всяких GC.
Не-не. Opaque — это непрозрачные ссылки. Понятно, что они этим хотят обезопасить среду исполнения + интероперабельность. Да, это ближе к OS API, хотя сути это же меняет: OS-и вполне совершают подсчет ссылок объектов. Так и тут соврешенно ничего не должно мешать иметь маппинг wasm-handle на v8-handle (например). Если аккуратно с ними работать (ну и C++ к этому будет толкать, я надеюсь) — то и проблем быть не должно. А с другими языками — х.з.
Но это всё просто на примитивном API.
А возьмём XMLHttpRequest с его колбэками, немного надуманно, но всё таки (в общем-то Using XMLHttpRequest это и делает).
1. Создали XMLHttpRequest.
2. Подписались на событие "load".
3. Отправили запрос в космос.
4. Освободили ссылку на XMLHttpRequest.
5. Сидим ловим колбэки.
При этом:
Запрос давно отменён браузером, например по причине недоступности сети -> все замыкания/контексты которые ждут события — ждут его бесконечно, и что самое главное — никогда не дождуться и никогда не высвободятся. Это — уже ломает API, потому что в нормальной ситуации это всё заруливает GC. Понятно, что это можно побороть — необходимо хосту давать рулить временем жизни объектов хотя бы частично. Как это зарулить, на том же C++, при этом что бы это было и стандартно и не вырвиглазно — я честно говоря не знаю. Пусть они думают.
Здравствуйте, Mystic Artifact, Вы писали:
_>>Работу с web api (и не только — это будет общий механизм для взаимодействия с любым api программы, в которую встраивается движок wasm) будут обеспечивать эти самые "прозрачные" ссылки (я там выше опечатался — задумался о другом и вставил лишнее "не"): "a new set of operators would be added for allocating, deallocating, loading and storing from integer-indexed cells that could hold references". Т.е. очевидно что это ближе к классическому OS API на дескрипторах, без всяких GC. MA> Не-не. Opaque — это непрозрачные ссылки.
А, точно, сорри, что-то я всё запутал) Короче, формализую, чтобы не было больше путаницы:
Opaque reference (переводим как "непрозрачные ссылки") == handle (дескрипторы) и вводится ради реализации api (веб в случае браузеров).
Non-opaque reference (переводим как "прозрачные ссылки"?) == по сути обычные указатели, но в памяти выделенной GC, и вводится ради интеграции с JS.
Естественно это всё пока предположительные варианты.
MA>Понятно, что они этим хотят обезопасить среду исполнения + интероперабельность. Да, это ближе к OS API, хотя сути это же меняет: OS-и вполне совершают подсчет ссылок объектов. Так и тут соврешенно ничего не должно мешать иметь маппинг wasm-handle на v8-handle (например). Если аккуратно с ними работать (ну и C++ к этому будет толкать, я надеюсь) — то и проблем быть не должно. А с другими языками — х.з.
Во-первых JS движок не должен находиться между wasm и браузерными функциями. Не говоря уже о том, что некий api нужен всегда, а вот JS движок будет далеко не во всех программах, интегрирующих в себя движок wasm.
А во-вторых ты похоже называешь и механизм подсчёта ссылок разновидностью GC? На мой взгляд это всё же разные вещи... )
MA> Но это всё просто на примитивном API. MA> А возьмём XMLHttpRequest с его колбэками, немного надуманно, но всё таки (в общем-то Using XMLHttpRequest это и делает). MA> 1. Создали XMLHttpRequest. MA> 2. Подписались на событие "load". MA> 3. Отправили запрос в космос. MA> 4. Освободили ссылку на XMLHttpRequest. MA> 5. Сидим ловим колбэки. MA> При этом: MA> Запрос давно отменён браузером, например по причине недоступности сети -> все замыкания/контексты которые ждут события — ждут его бесконечно, и что самое главное — никогда не дождуться и никогда не высвободятся. Это — уже ломает API, потому что в нормальной ситуации это всё заруливает GC. Понятно, что это можно побороть — необходимо хосту давать рулить временем жизни объектов хотя бы частично. Как это зарулить, на том же C++, при этом что бы это было и стандартно и не вырвиглазно — я честно говоря не знаю. Пусть они думают.
Ой, вот уж не JS хвалиться реализациями асинхронного IO. В системных языках это настолько стандартный и детальной проработанный вопрос... И никакие "XMLHttpRequest" при этом очевидно не создаются. ))) Более того, даже в современном JS от этого уже ушли (см. fetch).
Здравствуйте, alex_public, Вы писали:
_>Opaque reference (переводим как "непрозрачные ссылки") == handle (дескрипторы) и вводится ради реализации api (веб в случае браузеров). _>Non-opaque reference (переводим как "прозрачные ссылки"?) == по сути обычные указатели, но в памяти выделенной GC, и вводится ради интеграции с JS. _>Естественно это всё пока предположительные варианты.
Да, прозрачные — transparent (по аналогии с opaque/transparent type aliases). Но про GC — это ты сейчас опять всех запутаешь. Вроде ж никто ничего такого не вводит. Ну и плюс зависит от типа GC: в общем случае — обращаться к GC хипу можно только через хэндл. В том же V8 почему есть разделение: одни ссылки (local) — они живут только на стёке, привязаны к текущему isolation, дешевые ну и т.п. А все другие — сильно тяжелее.
MA>>Понятно, что они этим хотят обезопасить среду исполнения + интероперабельность. Да, это ближе к OS API, хотя сути это же меняет: OS-и вполне совершают подсчет ссылок объектов. Так и тут соврешенно ничего не должно мешать иметь маппинг wasm-handle на v8-handle (например). Если аккуратно с ними работать (ну и C++ к этому будет толкать, я надеюсь) — то и проблем быть не должно. А с другими языками — х.з. _>Во-первых JS движок не должен находиться между wasm и браузерными функциями. Не говоря уже о том, что некий api нужен всегда, а вот JS движок будет далеко не во всех программах, интегрирующих в себя движок wasm.
Ох же ж. Просто, что бы было ясно: WASM выполняется не в космосе, а внутри JS движка. Есть куча готовых сервисов браузера (назовём хоста), который уже умеет всё что надо. Хост теоретически может позвать v8::Function, несмотря на то, что под ней будет настоящий wasm: зачем рисовать вторые биндинги, если для того, что бы выполнить любой колбэк — необходимо подготовить стёк: получить isolation, try_catch и прочее? Это то, что хостовая часть обязана будет делать в любом случае. wasm — это чисто модель, V8 — одна из реализаций, которая энфорсит свои правила игры. Тем более в случае с браузером — где JS всё равно надо поддерживать. Я опять же это говорю в контексте доступа к DOM и прочим вкусняшкам. Вне этого — возможно имеет смысл дать иные примитивы. На практике — им виднее, чисто моё имхо.
_>А во-вторых ты похоже называешь и механизм подсчёта ссылок разновидностью GC? На мой взгляд это всё же разные вещи... )
Наши взгляды тут совпадают.
_>Ой, вот уж не JS хвалиться реализациями асинхронного IO. В системных языках это настолько стандартный и детальной проработанный вопрос... И никакие "XMLHttpRequest" при этом очевидно не создаются. ))) Более того, даже в современном JS от этого уже ушли (см. fetch).
Да при чём тут асинхронный IO? Есть стандартный API, часть Web API. И с наскока он без проблем не переносится. Тут же ж важна сама технология (пока не отработанная).
Если дадут доступ к DOM — я думаю остальное тоже смогут подтянуть, ведь тогда уже технологический проблем быть не должно. А тянут — наверное хотят пощупать как оно будет лучше на как можно меньшем объеме.
Просто пока ясно, что с помощью opaque references можно будет интересные лики. Например дадут доступ к DOM. Мы тут раз элементик взяли, раз на событие подписались. А на элементик ссылку держим в хэндлере, что-бы цвет ему изменить по клику. В итоге даже когда элемент будет удалён из document tree — он навсегда будет висеть в памяти: ведь ты его держишь в модуле (понятно, что на время жизни wasm модуля / рендерера). Цикла GC не видит — просто висит себе объект и висит. Тоже самое с другими. Это же ж всё уже было пройдено ранее в JS. Но, когда предложат доступ — посмотрим чего в реальности предложат. А так это ж просто догадки. Но, имхо — даже так — было бы хорошо бы иметь доступ. С этими вещами вполне можно бороться.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Serginio1, Вы писали:
S>>Ты кстати с Net Native сравнивал?
_>Нет, у меня не установлена инфраструктура под него (собственно я даже не в курсе что там требуется установить, чтобы собрать соответствующее приложение). ) Я и .net то не ставил специально, просто он у всех пользователей винды присутствует по умолчанию. )))
MatrixMultiplication — Выполняет наивное O (n ^ 3) умножение двух целых матриц. Есть две версии этого кода — для прямоугольных (многомерных) и неровных массивов. Хороший оптимизирующий компилятор может выполнять здесь несколько оптимизаций, таких как замена циклов, векторизация, FMA и т. Д.
Рабочий стол JIT RectangularMatrixMultiplication — 50.30814ms
.NET Native RectangularMatrix Multiplication — 187.3474ms
Рабочий стол JIT JaggedMatrixMultiplication — 33.11678ms
.NET Native JaggedMatrixMultiplication — 33.08566ms
C ++ Matrix Multiplication — 21.11234ms
Мандельброт — вычисляет множество Мандельброта в заданных измерениях. Это контрольный показатель, который не имеет доступа к большому количеству памяти, но работает с узким циклом с умножениями и дополнениями, которые могут извлечь выгоду из векторизации, интеллектуального распределения регистров, переопределения команд и других соображений, которые использует оптимизирующий компилятор. Из всех приведенных выше показателей это, пожалуй, самый реалистичный с точки зрения количества и качества кода.
Обои для рабочего JIT Mandelbrot — 32.18214ms
.NET Native Mandelbrot — 46.48744ms
C ++ Mandelbrot — 15.26277ms
Полученные результаты довольно убедительны. На данный момент .NET Native не использует никаких оптимизаций супер-умного компилятора, которые приводят его производительность в соответствие с кодом на C ++. В некоторых случаях он даже генерирует код, который не подпадает под JIT рабочего стола (в частности, прямоугольные массивы и тесты Mandelbrot). Важно помнить, что это все еще предварительный просмотр, и я буду очень рад повторить эти измерения, когда будет выпущена обновленная версия .NET Native. Я знаю, что команда .NET Native активно работает над оптимизацией компилятора.
Пока C++ в сложных для .Net Jita алгоритмах проигрывает C++ в 2 раза. .Net Native пока сырой
Здравствуйте, novitk, Вы писали:
I>>Примерно так:<script type="text/python(tcl, rexx и тд)">
N>Koгда и где такое работало? В Brython? Это как раз на коленках собранная альтернативная реализация на JS. В результате у тебя нет ни скорости ни совместимости.
Это не наколеночные поделки, а нормальные браузеры.
Здравствуйте, Ops, Вы писали:
Ops>Здравствуйте, Ikemefula, Вы писали:
I>>Примерно так:<script type="text/python(tcl, rexx и тд)">
Ops>А как из этого скрипта написать Hello, world, покрасить body в розовый, добавить кнопку и обработать onclick?
Так же, как в JS. Только эти языки давно не поддерживаются браузерами.
Здравствуйте, alex_public, Вы писали:
I>>>>Это называется "технологический расизм" — все джависты/шарписты(нужное вписать) так себе, а С++ (нужное вписать) ого-го. _>>>Вообще то я говорил не про людей, а про технологии. Так вот с точки зрения производительности Java и C# действительно так себе, а C++ ого-го. ))) I>>"адепты последних ..." — это так ты говоришь про технологии ? Ты постоянно отказываешься от своих слов, потому тебе и верить нельзя. Завтра же откажешься от своей таблички на ровном месте.
_>Ну так а что же ты не закончил цитату то? ) Покажи где я там написал, что "адепты последних так себе". Или в очередной раз окажешься вруном.
Точнее ты назвал их неадекватными.
"адепты последних обычно достаточно разумны" — речь про Питон и JS. Итого — обобщение и характеристика людей, а не технологий.
"адепты первых..." — это про C# и Java. "...таким неадекватным товарищам приходится открывать глаза на реальность" И снова, обобщение и снова про людей, а не про технологии.
Итого —
1 "технологический расизм" — обобщение и характеристика людей, а не технологий
2 ты дважды за день отказался от своих слов. И как тебе можно верить ?
3 на роль судьи ты мягко говоря не тянешь
Так что за боль тебе дотнетчики причинили ?
_>>>Ну если бы ты осилил хотя бы прочитать до конца темку про тесты, то ты легко обнаружил бы это http://rsdn.org/forum/flame.comp/6731465.1
сообщение, в котором имеется ссылка на исходник, для неспособных записать двойной цикл. ))) I>>Ну да, а если порыться в форуме в сообщениях двух-трехлетней давности...
_>О, и ещё одна порция вранья — ты сегодня прямо на рекорд идёшь. )
Ога, а если и весь форум с самого начала перечитать, то ваще...
>Сообщение там шестидневной давности. ) Да и рыться нигде не надо, т.к. оно не только свежее, но и находится прямо в обсуждаемой теме. )))
Ты считаешь, что я обязан всю тему вычитывать на предмет поиска ссылок на обсуждение двухлетней давности ? Какой в этом смысл, если ты отказываеся от своих слов по нескольку раз на день ?
Здравствуйте, vdimas, Вы писали:
V>>>А слабо показать мне ленивую зону в JS? I>>Ну ты и крутой, ваще
V>Я-то обычный, какой и должен. V>Это же не я демонстрирую отрицательную степень социализированности:
Здравствуйте, Serginio1, Вы писали:
S>MatrixMultiplication — Выполняет наивное O (n ^ 3) умножение двух целых матриц. Есть две версии этого кода — для прямоугольных (многомерных) и неровных массивов. Хороший оптимизирующий компилятор может выполнять здесь несколько оптимизаций, таких как замена циклов, векторизация, FMA и т. Д. S>Рабочий стол JIT RectangularMatrixMultiplication — 50.30814ms S>.NET Native RectangularMatrix Multiplication — 187.3474ms S>Рабочий стол JIT JaggedMatrixMultiplication — 33.11678ms S>.NET Native JaggedMatrixMultiplication — 33.08566ms S>C ++ Matrix Multiplication — 21.11234ms
Здравствуйте, Ikemefula, Вы писали:
V>>>>А слабо показать мне ленивую зону в JS? I>>>Ну ты и крутой, ваще V>>Я-то обычный, какой и должен. V>>Это же не я демонстрирую отрицательную степень социализированности: I>Ты именно это и демонстрируешь
Конкретно с тобой мне приходится демонстрировать навыки уборщика мусора.
Здравствуйте, vdimas, Вы писали:
I>>>>Ну ты и крутой, ваще V>>>Я-то обычный, какой и должен. V>>>Это же не я демонстрирую отрицательную степень социализированности: I>>Ты именно это и демонстрируешь
V>Конкретно с тобой мне приходится демонстрировать навыки уборщика мусора.
У тебя во всех сообщениях один и тот же метод общения и тон, как будто ты всем хочешь рассказать, какой ты крутой и тд и тд и тд.
Здравствуйте, Ikemefula, Вы писали:
V>>Конкретно с тобой мне приходится демонстрировать навыки уборщика мусора. I>У тебя во всех сообщениях один и тот же метод общения и тон, как будто ты всем хочешь рассказать, какой ты крутой и тд и тд и тд.
Ты еще милицию позови. ))
Это что-то типа как хулигану набили морду в подворотне и он вспомнил про милицию... ))
Ты ж умудряешься не просто допускать ошибки, но еще оформлять их в форме широковещательного наезда.
Это я еще относительно сухо ответил на такое...
Здравствуйте, vdimas, Вы писали:
V>>>Конкретно с тобой мне приходится демонстрировать навыки уборщика мусора. I>>У тебя во всех сообщениях один и тот же метод общения и тон, как будто ты всем хочешь рассказать, какой ты крутой и тд и тд и тд.
V>Ты еще милицию позови. )) V>Это что-то типа как хулигану набили морду в подворотне и он вспомнил про милицию... ))
Ооо!!!
V>Ты ж умудряешься не просто допускать ошибки, но еще оформлять их в форме широковещательного наезда. V>Это я еще относительно сухо ответил на такое...
Здравствуйте, vdimas, Вы писали:
V>>>Начиная с Windows 8 бери современный "контейнер приложений" (за этим громким названием скрывается всего-навсего урезанное АПИ виндов для некоего процесса), и загружай что хошь откуда хошь )) Если у загруженного кода нет доступа к банальной GetLibrary и прочих из этой области, то такой подгруженный модуль становится беспомощным и относительно безопасным. _>>Ну полазить по памяти браузера оно легко смогло бы. ) V>Если на каждую страницу создавать свою независимую песочницу, как делает Edge и Хром, то абсолютно ничего любопытного этот код не увидит. ))
Да, если по процессу на страницу, то это частично решает проблему. Но это только если засунуть сам браузер в песочницу винды. А сейчас же это полноценные приложения, пишущие и читающие файлы где угодно. )
Здравствуйте, Mystic Artifact, Вы писали:
_>>Во-первых JS движок не должен находиться между wasm и браузерными функциями. Не говоря уже о том, что некий api нужен всегда, а вот JS движок будет далеко не во всех программах, интегрирующих в себя движок wasm. MA> Ох же ж. Просто, что бы было ясно: WASM выполняется не в космосе, а внутри JS движка.
В документации на wasm чётко указано, что это временное явление. Т.е. сейчас wasm загружается через js, а в будущем будет через html тег script, без всякой привязки к js. Кстати, не исключаю, что такое временное решение как раз из-за отсутствия доступа к web api, т.к. сейчас чтобы получить реальную пользу от wasm надо предоставлять ему набор js функций для импорта. А при наличие доступа к web api это будет уже не особо нужно.
MA>Есть куча готовых сервисов браузера (назовём хоста), который уже умеет всё что надо. Хост теоретически может позвать v8::Function, несмотря на то, что под ней будет настоящий wasm: зачем рисовать вторые биндинги, если для того, что бы выполнить любой колбэк — необходимо подготовить стёк: получить isolation, try_catch и прочее? Это то, что хостовая часть обязана будет делать в любом случае. wasm — это чисто модель, V8 — одна из реализаций, которая энфорсит свои правила игры. Тем более в случае с браузером — где JS всё равно надо поддерживать. Я опять же это говорю в контексте доступа к DOM и прочим вкусняшкам. Вне этого — возможно имеет смысл дать иные примитивы. На практике — им виднее, чисто моё имхо.
В идеальном мире JS в браузерах стал бы поддерживаться в виде одного из многих языковых движков (ну разве что с мелким отличием от остальных, что он входит в поставку браузерах, а не качается отдельно) скомпилированных под wasm. Т.е. что бы хост (браузер или что-то там ещё) предоставлял свой api только через wasm. Но с нашим историческим наследием мы видимо (насколько я понял из описание разработчиков wasm) получим другую схему — некий внутренний C++ api (свой для каждого браузера) поверх которого сидят два движка: js и wasm. А ты предлагаешь вообще наоборот, использовать в wasm api браузера "через" js движок? )
_>>Ой, вот уж не JS хвалиться реализациями асинхронного IO. В системных языках это настолько стандартный и детальной проработанный вопрос... И никакие "XMLHttpRequest" при этом очевидно не создаются. ))) Более того, даже в современном JS от этого уже ушли (см. fetch). MA> Да при чём тут асинхронный IO? Есть стандартный API, часть Web API. И с наскока он без проблем не переносится. Тут же ж важна сама технология (пока не отработанная).
Я пока не увидел ни единой проблемы, даже при реализации этого же старого XMLHttpRequest с помощью handle. )
MA> Если дадут доступ к DOM — я думаю остальное тоже смогут подтянуть, ведь тогда уже технологический проблем быть не должно. А тянут — наверное хотят пощупать как оно будет лучше на как можно меньшем объеме.
Так безусловно дадут. Все эти webgl, audio, сокеты и т.п. Более того, я не исключаю что как раз их в первую очередь сделают, а DOM потом. Потому как wasm всё же позиционируется в том числе и для тяжёлых игр, а им как раз это и надо (а DOM вообще не требуется).
Да, и ещё один момент. Если взглянуть на все эти api в браузере, то мы увидим чуть подправленные для понимания в JS классические интерфейсы (OpenGL и т.д.). Так вот мне показалось бы вполне логичным, если бы при реализации web api для wasm просто взяли бы классические интерфейсы и всё. )))
MA> Просто пока ясно, что с помощью opaque references можно будет интересные лики. Например дадут доступ к DOM. Мы тут раз элементик взяли, раз на событие подписались. А на элементик ссылку держим в хэндлере, что-бы цвет ему изменить по клику. В итоге даже когда элемент будет удалён из document tree — он навсегда будет висеть в памяти: ведь ты его держишь в модуле (понятно, что на время жизни wasm модуля / рендерера). Цикла GC не видит — просто висит себе объект и висит. Тоже самое с другими. Это же ж всё уже было пройдено ранее в JS. Но, когда предложат доступ — посмотрим чего в реальности предложат. А так это ж просто догадки. Но, имхо — даже так — было бы хорошо бы иметь доступ. С этими вещами вполне можно бороться.
Зачем держать ссылку, если там есть this? ) Который в случае интерфейса в стиле C будет всего лишь очередной непрозрачной ссылкой, передаваемой в обработчик события.
Здравствуйте, Serginio1, Вы писали:
_>>Нет, у меня не установлена инфраструктура под него (собственно я даже не в курсе что там требуется установить, чтобы собрать соответствующее приложение). ) Я и .net то не ставил специально, просто он у всех пользователей винды присутствует по умолчанию. ))) S> Ну вот здесь пишут http://our.componentone.com/2017/03/09/uwp-performance-and-net-native-compilation/ S>Что в VS 2017 порядка 600 исправлений и типа существенно повысили производительность на некоторых сценариях.
Ну это как бы ни о чём не говорит, если не известны изначальные цифры. Если ты мне покажешь где можно скачать компилятор (а не VS) для .net native, который нормально бы работал просто из командной строки (как обычный компилятор C# из поставки .net), то я могу прогнать некоторые тесты, чтобы увидеть разницу с обычным .net'ом и с C++.
S> Кстати интересная статья https://dzone.com/articles/net-native-performance-and
О да, и в качестве C++ компилятора там естественно используется MSVC 2013 — убогая хрень со слабым и набитым багами оптимизатором. А с gcc или icc сравнить конечно же никто не хочет. ))) Хотя там в тесте есть упоминания о том, что они попробовали Clang (тоже не самый сильный оптимизатор) и даже он он выдал результат в 2 раза лучше MSVC. Но внести эти данные в табличку они конечно же постеснялись. )))
А с gcc или icc сравнить конечно же никто не хочет. ))) Хотя там в тесте есть упоминания о том, что они попробовали Clang (тоже не самый сильный оптимизатор) и даже он он выдал результат в 2 раза лучше MSVC. 