Здравствуйте, alex_public, Вы писали:
_>>>В описание моих тестов была ссылка на работающий прямо на страничке JS тест. Открываешь его исходник и видишь функцию Update — это по сути и есть весь тест, остальное мишура. I>>И как я найду ошибку в остальном твоем коде, телепатией или домыслами ?
_>В каком ещё остальном коде?
У тебя в таблице кучка результатов. Ты привел только JS код Предлагаешь догадываться о коде остальных замеров ?
I>>Я так и подумал. Но почему то вспомнил, что как только речь про C#, так ты придираешься к каждой доле процента скажем, в сравнении с джавой или питоном. Парадокс! Расскажи, чем тебя шарписты обидели ?
_>Нет, как раз к C# и Java у меня одинаковое отношение. ) И оно в данном контексте отличается от отношения к Python и JS. Потому что адепты последних обычно достаточно разумны, чтобы не претендовать на какие-то результаты в области производительности (ну в абсолютном смысле, а не внутри своего мирка скриптовых языков) — их языки сильны другим. А вот адепты первых иногда пытаются заявлять что-то вроде того, что могут достигать близких к нативным языкам результатов. И вот таким неадекватным товарищам приходится открывать глаза на реальность, демонстрируя, что на самом деле разница как минимум в разы, а иногда и на порядки.
Это называется "технологический расизм" — все джависты/шарписты(нужное вписать) так себе, а С++ (нужное вписать) ого-го.
Пока что наблюдаем следующее — ровно один сиплюсник никак не может понять, зачем публиковать не только результаты, но и исходный код тестов. Точнее, делает вид, что ему непонятно. То есть, юродствует.
Здравствуйте, novitk, Вы писали:
N>>>Вообще то Питон без доступа к DOM-у нафиг никому не нужен. Это как бы основной посыл. I>>Питон уже был в браузере. Не взлетел.
N>A что имеется ввиду под "был"? Двухнедельные поделки типа PythonJS?
Примерно так:<script type="text/python(tcl, rexx и тд)">
Здравствуйте, alex_public, Вы писали:
_>>>Это если они вообще это реализуют, т.к. для интеграции web api этого не требуется (достаточно внешних дескрипторов), а требуется только для удобной (простая... MA>> DOM и JS неявно требует GC. Вот только это. В остальном — любые API отлично ложаться на разные языки. Ну DOM API влезет даже в C++ без изменений практически.
_>Работа с DOM не требует ни GC, ни C++. Для её полноценной реализации достаточно всего десятка функций на стареньком C.
Это справедливо для чего угодно. Но в W3C DOM Node после removeChild оказывается в подвешенном состоянии: с одной стороны мы можем его куда-то вставить, а с другой — "забыть" о нём и тогда он будет собран GC. Никаких механизмов явно или неявно его убить нету ж.
Здравствуйте, Serginio1, Вы писали:
_>>А зачем им взаимодействовать? Движок python'а на wasm при загрузке просто сканирует все html теги script на предмет питоновского кода и исполняет найденное. Ему ни с кем взаимодействовать не надо. А отдельные питоновские скрипты на странице естественно без проблем будут между собой взаимодействовать, т.к. будут исполняться внутри одной запущенной копии движка. S> Я уже приводил пример использования JQuery нескольких модулях. так и с python'а он должен отслеживать уже загруженные сборки, что бы каждый модуль не тянул одно и тоже.
Смешно. Очевидно же что Питон давным давно имеет это всё, т.к. в нём от рождения есть полноценная система модулей. )))
_>>Если (точнее когда) в wasm предоставят нативный доступ к web api, то весьма вероятно, что подобный код будет работать и побыстрее js версии. Ведь web api (и DOM в том числе, как его часть) не имеют никакого отношения к движку JS — это всего лишь внутренний api браузера, который этот движок вызывает. S> Внутри wasm да, а вот вызов из V8, а так же вызов V8 из wasm будут задержки.
V8 вообще не будет задействован на такой странице — зачем он там по твоему, если весь код написан на Питоне? )
_>>Так будут новые, на новых языках. ) С совершенно другой архитектурой (нынешняя является в основном наследием проблем JS). S> Вот когда появятся ... S> На самом то деле я не вижу необходимости замены JS.
Ну как минимум не хорошо отсутствие возможности конкуренции на данной платформе. )
Здравствуйте, vdimas, Вы писали:
V>COM в этом плане очень облегчал жизнь, бо не плодил зоопарк из конкурирующих систем подсчета банальных ссылок.
К COM у меня не плохое отношение. А вот к ActiveX (конкретному набору интерфейсов) сомнительное.
V>Начиная с Windows 8 бери современный "контейнер приложений" (за этим громким названием скрывается всего-навсего урезанное АПИ виндов для некоего процесса), и загружай что хошь откуда хошь )) Если у загруженного кода нет доступа к банальной GetLibrary и прочих из этой области, то такой подгруженный модуль становится беспомощным и относительно безопасным.
Ну полазить по памяти браузера оно легко смогло бы. )
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Serginio1, Вы писали:
_>>>А зачем им взаимодействовать? Движок python'а на wasm при загрузке просто сканирует все html теги script на предмет питоновского кода и исполняет найденное. Ему ни с кем взаимодействовать не надо. А отдельные питоновские скрипты на странице естественно без проблем будут между собой взаимодействовать, т.к. будут исполняться внутри одной запущенной копии движка. S>> Я уже приводил пример использования JQuery нескольких модулях. так и с python'а он должен отслеживать уже загруженные сборки, что бы каждый модуль не тянул одно и тоже.
_>Смешно. Очевидно же что Питон давным давно имеет это всё, т.к. в нём от рождения есть полноценная система модулей. )))
Я рад, что поднял тебе настроение. Одно дело когда питон является основной программой, другое дело когда вызываемой.
Например у меня вызов .Net происходит в одном домене. Как между собой взаимодействуют wasm модули я не знаю.
_>>>Если (точнее когда) в wasm предоставят нативный доступ к web api, то весьма вероятно, что подобный код будет работать и побыстрее js версии. Ведь web api (и DOM в том числе, как его часть) не имеют никакого отношения к движку JS — это всего лишь внутренний api браузера, который этот движок вызывает. S>> Внутри wasm да, а вот вызов из V8, а так же вызов V8 из wasm будут задержки.
_>V8 вообще не будет задействован на такой странице — зачем он там по твоему, если весь код написан на Питоне? )
Угу. То есть движок будет написан на питоне?
_>>>Так будут новые, на новых языках. ) С совершенно другой архитектурой (нынешняя является в основном наследием проблем JS). S>> Вот когда появятся ... S>> На самом то деле я не вижу необходимости замены JS.
_>Ну как минимум не хорошо отсутствие возможности конкуренции на данной платформе. )
Компилируй в JS тот же питон. Не вижу проблем. А ввод нового языка никому из браузостроителей не интересно.
Это уже нужно поддерживать несколько парсеров, компиляторов.
Но это только мое сугубо личное мнение. Буду рад ошибиться.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, vdimas, Вы писали:
_>>Ты какую-то ерунду пишешь) Никто не собирается втаскивать в C++ элементы DOM как первоклассные сущности. V>Почему нет? V>Работа с DOM в IE из плюсов такая быстрая именно из-за предоставления наружу "бинарных" COM-объектов. V>Ничего более быстрого пока не придумали.
Судя по разговорам о непрозрачных ссылках и т.п. я предполагаю что они всё же ориентируются на C интерфейс в стиле виндовых handle. )))
Здравствуйте, Ikemefula, Вы писали:
I>>>И как я найду ошибку в остальном твоем коде, телепатией или домыслами ? _>>В каком ещё остальном коде? I>У тебя в таблице кучка результатов. Ты привел только JS код Предлагаешь догадываться о коде остальных замеров ?
Для тебя проблема переписать данный простейший цикл на все эти языки? Да там и переписывать почти ничего не надо (в основном смена let/var/auto/int), странно что такая простейшая задачка для первокурсника вызывает у тебя затруднения.
I>Это называется "технологический расизм" — все джависты/шарписты(нужное вписать) так себе, а С++ (нужное вписать) ого-го.
Вообще то я говорил не про людей, а про технологии. Так вот с точки зрения производительности Java и C# действительно так себе, а C++ ого-го. )))
I>Пока что наблюдаем следующее — ровно один сиплюсник никак не может понять, зачем публиковать не только результаты, но и исходный код тестов. Точнее, делает вид, что ему непонятно. То есть, юродствует.
Здравствуйте, Mystic Artifact, Вы писали:
_>>Работа с DOM не требует ни GC, ни C++. Для её полноценной реализации достаточно всего десятка функций на стареньком C. MA> Это справедливо для чего угодно. Но в W3C DOM Node после removeChild оказывается в подвешенном состоянии: с одной стороны мы можем его куда-то вставить, а с другой — "забыть" о нём и тогда он будет собран GC. Никаких механизмов явно или неявно его убить нету ж.
На фоне всех этих разговоров о введение "непрозрачных ссылок" для реализации web api, я подозреваю что там будет некий аналог функции CloseHandle из win api.
Здравствуйте, Serginio1, Вы писали:
_>>Смешно. Очевидно же что Питон давным давно имеет это всё, т.к. в нём от рождения есть полноценная система модулей. ))) S> Я рад, что поднял тебе настроение. Одно дело когда питон является основной программой, другое дело когда вызываемой. S>Например у меня вызов .Net происходит в одном домене. Как между собой взаимодействуют wasm модули я не знаю.
WASM модуль будет в таком раскладе ровно один — движок Питона.
_>>V8 вообще не будет задействован на такой странице — зачем он там по твоему, если весь код написан на Питоне? ) S> Угу. То есть движок будет написан на питоне?
Движок будет написан на C/C++ и скомпилирован под wasm. Не авторами сайта (те будут писать только код на Питоне), а создателями Питона (ну или какими-то энтузиастами языка, если авторы Питона будут тормозить с созданием подобного дистрибутива).
_>>Ну как минимум не хорошо отсутствие возможности конкуренции на данной платформе. ) S> Компилируй в JS тот же питон. Не вижу проблем. А ввод нового языка никому из браузостроителей не интересно. S>Это уже нужно поддерживать несколько парсеров, компиляторов.
Безусловно создателям браузеров не интересно возиться с этим. И как раз появление WebAssembly позволяет переложить эту работу на других, кому это может быть интересно. Т.е. вот например ты сможешь придумать свой личный гениальный язык SerginioScript, написать движок для него на C++, скомпилировать под wasm и после этого спокойно писать скрипты на этом своём языке прямо на html страничке.
Здравствуйте, alex_public, Вы писали:
I>>Это называется "технологический расизм" — все джависты/шарписты(нужное вписать) так себе, а С++ (нужное вписать) ого-го.
_>Вообще то я говорил не про людей, а про технологии. Так вот с точки зрения производительности Java и C# действительно так себе, а C++ ого-го. )))
"адепты последних ..." — это так ты говоришь про технологии ? Ты постоянно отказываешься от своих слов, потому тебе и верить нельзя. Завтра же откажешься от своей таблички на ровном месте.
I>>Пока что наблюдаем следующее — ровно один сиплюсник никак не может понять, зачем публиковать не только результаты, но и исходный код тестов. Точнее, делает вид, что ему непонятно. То есть, юродствует.
_>Ну если бы ты осилил хотя бы прочитать до конца темку про тесты, то ты легко обнаружил бы это http://rsdn.org/forum/flame.comp/6731465.1
Здравствуйте, alex_public, Вы писали:
_>На фоне всех этих разговоров о введение "непрозрачных ссылок" для реализации web api, я подозреваю что там будет некий аналог функции CloseHandle из win api.
"Непрозрачной ссылкой" может выступать хэндл GC. Не спроста же все ведущие браузеры реализуют wasm в своих движках JS. Там уже всё есть: кодогенерация, GC и интероп с сервисами браузера. Остаётся только ждать до чего они там договорятся.
ADD: Я об этом и говорил сразу — прикрутили бы только по человечески, не через pinning / ref counting GC объектов, а через честные GC-ссылки, что бы сразу отcечь все возможные проблемы из-за циклов и т.п.
Здравствуйте, Ikemefula, Вы писали:
S>> Кстати про потоки и зоны I>Ребята пока путают реактор с проактором. Как разберутся, тогда можно и зоны смотреть.
Смишно, эти "ребята" уже сто лет как проглотили ваши "зоны" и выкакали. C#:
// асинхронная зона
Task task1 = Task.Factory.StartNew(lambda);
// синхронная зона
Task task2 = new Task(lambda);
task2.RunSynchronously();
C++:
// асинхронная зона
future<void> fut1 = async(launch::async, lambda);
// синхронная ленивая зона
future<void> fut2 = async(launch::deferred, lambda);
// синхронная энергичная зона
packaged_task<void()> task(lambda);
future<void> fut2 = task.get_future();
task();
А уж ваши runZoned, так вообще смехотворными получаются:
template<class Lambda, class NormalCallback, class ErrorCallback>
void runZoned(Lamdba l, NormalCallback n, ErrorCallback e) {
try {
n(l());
} catch(...) {
e(current_exception());
}
}
Здравствуйте, alex_public, Вы писали:
V>>COM в этом плане очень облегчал жизнь, бо не плодил зоопарк из конкурирующих систем подсчета банальных ссылок. _>К COM у меня не плохое отношение. А вот к ActiveX (конкретному набору интерфейсов) сомнительное.
Какой из интерфейсов вызывает сложности? ))
Я же говорю, проблема там не в интерфейсах, а в том, что код из интернета (загружаемые ActiveX) начинают работать так, как будто они локальные.
V>>Начиная с Windows 8 бери современный "контейнер приложений" (за этим громким названием скрывается всего-навсего урезанное АПИ виндов для некоего процесса), и загружай что хошь откуда хошь )) Если у загруженного кода нет доступа к банальной GetLibrary и прочих из этой области, то такой подгруженный модуль становится беспомощным и относительно безопасным. _>Ну полазить по памяти браузера оно легко смогло бы. )
Если на каждую страницу создавать свою независимую песочницу, как делает Edge и Хром, то абсолютно ничего любопытного этот код не увидит. ))
Здравствуйте, alex_public, Вы писали:
V>>Работа с DOM в IE из плюсов такая быстрая именно из-за предоставления наружу "бинарных" COM-объектов. _>Судя по разговорам о непрозрачных ссылках и т.п. я предполагаю что они всё же ориентируются на C интерфейс в стиле виндовых handle. )))
Это чтобы не подвязываться на ABI таблицы виртуальных ф-ий С++. И это правильно, я бы тоже так сделал, если надо предоставить интерфейс для вообще любых языков.
Здравствуйте, Serginio1, Вы писали:
S>Ты кстати с Net Native сравнивал?
Нет, у меня не установлена инфраструктура под него (собственно я даже не в курсе что там требуется установить, чтобы собрать соответствующее приложение). ) Я и .net то не ставил специально, просто он у всех пользователей винды присутствует по умолчанию. )))
Здравствуйте, Ikemefula, Вы писали:
I>>>Это называется "технологический расизм" — все джависты/шарписты(нужное вписать) так себе, а С++ (нужное вписать) ого-го. _>>Вообще то я говорил не про людей, а про технологии. Так вот с точки зрения производительности Java и C# действительно так себе, а C++ ого-го. ))) I>"адепты последних ..." — это так ты говоришь про технологии ? Ты постоянно отказываешься от своих слов, потому тебе и верить нельзя. Завтра же откажешься от своей таблички на ровном месте.
Ну так а что же ты не закончил цитату то? ) Покажи где я там написал, что "адепты последних так себе". Или в очередной раз окажешься вруном.
_>>Ну если бы ты осилил хотя бы прочитать до конца темку про тесты, то ты легко обнаружил бы это http://rsdn.org/forum/flame.comp/6731465.1
сообщение, в котором имеется ссылка на исходник, для неспособных записать двойной цикл. ))) I>Ну да, а если порыться в форуме в сообщениях двух-трехлетней давности...
О, и ещё одна порция вранья — ты сегодня прямо на рекорд идёшь. ) Сообщение там шестидневной давности. ) Да и рыться нигде не надо, т.к. оно не только свежее, но и находится прямо в обсуждаемой теме. )))
Здравствуйте, Mystic Artifact, Вы писали:
_>>На фоне всех этих разговоров о введение "непрозрачных ссылок" для реализации web api, я подозреваю что там будет некий аналог функции CloseHandle из win api. MA> "Непрозрачной ссылкой" может выступать хэндл GC. Не спроста же все ведущие браузеры реализуют wasm в своих движках JS. Там уже всё есть: кодогенерация, GC и интероп с сервисами браузера. Остаётся только ждать до чего они там договорятся. MA> ADD: Я об этом и говорил сразу — прикрутили бы только по человечески, не через pinning / ref counting GC объектов, а через честные GC-ссылки, что бы сразу отcечь все возможные проблемы из-за циклов и т.п.
Работу с 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.
Плюс к этому отдельно (причём наверняка только в браузерном варианте, т.к. оно нужно только для полной интеграции с JS) будет поддержка работы с внешним GC, через "непрозрачные" ссылки (т.е. это будет что-то вроде функции GCAlloc), в которые можно будет писать напрямую (например чтобы эффективным образом вернуть из wasm кода JS объект).
Да, и ещё один нюанс: это всё далёкое будущее, т.к. в ближайшее время у них в планах стоит поддержка многопоточности и SIMD (что гораздо важнее для их основной цели — производительного кода). А это так, размышления о будущем. Так что ещё далеко не факт в какой степени и когда оно будет реализовано (например не факт что после добавления web api обязательно буду реализовывать плотную интеграцию с JS).
Предлагаешь догадываться о коде остальных замеров ?
Да там и переписывать почти ничего не надо (в основном смена let/var/auto/int), странно что такая простейшая задачка для первокурсника вызывает у тебя затруднения.
