LINUX.ORG.RU

Тест сравнение Wasm/Js/C++/java

 ,


1

3

Сделал парочку тестов, не hello-word-ов
(пост не копипаста, в одном экземпляре для лора)

Зачем- ибо тесты в офф гитхабе emscripten все на уровне хеловордов без нагрузки.
тесты имеют одинаковый код на всех указанных языках/платформах, никаких скрытых переделок

Ссылка https://github.com/danilw/cputests там доступны исходники под четыре платформы (С++ только линукс) также лайв демонстрация (ссылки в Readme на гитхабе)

Описание тестов:
basic- простое копирование с конвертацией/конкатенацией строк, самый простой тест
terrain- рекурсия с лямбдой для построения изображения по общеизвестному алгоритму, также рисование изображения вертикальными прямоугольниками (что нагружает все системы отрисовки)
render- алгоритм рей-трейсинга с тенью и отражениями и красивыми материалами, сотни миллионов циклов для построения 640*480 картинки
render_mini- упрощенный render для отрисовки в реальном времени(камерой можно управлять, читай описание на гитхабе), от 3 до 5 миллионов циклов на один кадр 300*200

Результаты:(цифры смотреть на гитхабе)

javascript движок от Firefox намного быстрее и имеет очень много оптимизаций по сравнению с Chrome
даже результаты basic это демонстрируют
результат terrain- показывает что в Chrome (как и в Java) отсутствуют оптимизации «лямбд», при этом js45 (движок джаваскрипта файрфокса) можно запустить с параметрами --no-cgc --no-ggc --ion-offthread-compile=off --ion-osr=off --ion-inlining=off --ion-range-analysis=off то terrain и basic начнут давать результат идентичный версии Chrome (тоесть медленнее в разы)
Я тестировал на нескольких версиях вебкита(браузерах), включая одну самосборку и node.js (тут полный ужас он в два и более раза медленнее вебкита), Хром Хромиум QtWebEngine и другие, опции сборки не тормозили производительность вебкита

Результаты render и render_mini на джаваскрипте показывают что в все плохо с .prototype. и циклами, слово прототип тормозит код в разы
Почему об этом написано тут https://developer.mozilla.org/en-US/docs/Web/JavaScript/The_performance_hazar...

Подводные камни и проблемы:

javascript- очевидно что производительность всегда была проблемой, и при написании даже текстового редактора с функционалом WYSIWYG уже упираетесь в производительность, что ставит крест на любых «реальных играх на webgl» для браузера, о которых упоминают в подобных темах Blend4Web 17.04
про саму ограниченность джаваскрипта в синтаксисе, отсутствие многопоточности (ее нет, евенты и таймеры это однопоточность все таже), невозможность замены базовых алгоритмов типо конвертаци строк, или перевода текста в изображение(текстуру), css алгоритмы отрисовки и прочие базовые элементы браузера... не буду в лишний раз упоминать
про ограниченность webgl(которая даже до opengl2 по функционалу не доходит если сравнивать) и отсутствие Cuda тоже не буду расписывать, это очевидно.

wasm:
во первых- это не настоящий C или C++, так как стандарты не соблюдены и приведены к джаваскрипт стандарту
можно инициализировать static там где нельзя, можно вообще не объявлять static или public/private компилятор выдаст стандартные ошибки «illegal/unknown reference» но проект соберется и будет работать в браузере, потоки ненастоящие(половина из которых вообще не доступна, и узнать что можно что нельзя можно только методом тыка запуская свой проект и читая ошибки браузера «thread(имя либы, SDL треды тоже не поддерживаются) initialization not supported in wasm», std::chrono::duration_cast и std::chrono::duration и std::chrono::high_resolution_clock (и много подобного) привязано к типу джаваскрипта Date что ломает Си/++ программы полностью, ибо возвращаемые данные и результаты не соответствуют «тому что должно быть в Си»
слишком много подводных камней о которых узнаешь из сообщения в браузере
несовместимость «портов» с настоящими, абсолютно все что есть в портах GLFW, SDL ...(и тесты SDL2 и новых портов из гитхаба) работают совершенно подругому, инициализации и функций рисования, некоторые функции которые «обязаны быть» вообще нельзя использовать в месте где они нужны(или они просто неработают) и нужно делать магию с асертами (assert.h)
офф вики библиотек чьи порты сделаны в wasm- просто несоответствует реализации в wasm

TL:DR Из тестов видно что wasm показал очень хороший результат и всего в два раза медленнее java, только скорость отрисовки в «экран»(2d софтвеерно) очень медленная(и опятьже ограниченность на порты, левых либ(буст каиро гтк кутэ.....сотни полезного существует) зависимых от левых либ- неполучится по очевидной причине(сложные либы не соберутся))

Я сделаю еще, как минимум, один проект для сравнения OpenGL производительности отрисовки (посмотрю по факту), в течении пары дней/недели, тогда смогу говорить и про OpenGL

Ты нюансы не учитываешь:

Javascript
==========

- он плохо переваривает плавучку, а гадать по деоптимизированному коду - дело тухлое.

- FF, который в лабораторных условиях круче Хрома, на реальных задачах почему-то часто уступает.

- есть вебворкеры. Это не многопоточность, но ядра загрузить хватит.

- webgl определенно убог. Но вроде уже есть webgl2, где побороли самые эпичные косяки.


WASM
====

Пока еще просто кривые компиляторы. Насчет emcc могу отметить, что он процентов 10 уступает LLVM в нынешнем постоянии. То что код криво собирается - проблемы компиляторов, а не WASM.

Vit ★★★★★ ()
Ответ на: комментарий от Vit

нюансы

Таких ньюансов нет

Как я сказал- взяв в пример функционал WYSIWYG
после реализации красивой «быстрой» подсветки и разметки текста и примитивного функционала по добавлению/убиранию тегов участкам текста

начнется добавление более сложного функционала требующего уже анализ «строк», и в 100% проектах сложнее хело-ворда используются циклы и разбор/сборка массивов(карт тдтп)

FF, который в лабораторных условиях круче Хрома, на реальных задачах почему-то часто уступает.

ты сам и озвучил причину- все пишут под «хром джаваскрипт» учитывая его особенности что нужно раскладывать все на линейную простейшую функциональщину желательно одной функцией на всю странице

никтож не использует лямбды для быстрой сортировки массивов, на стороне клиентов, нет, из за хрома все массимы от сервера уже передаются клиенту отсортированными, либо сервер имеет функцию сортировки которую запрашивает клиент передавая несортированное/получая сортированное

все что в хроме тормозит-вынесено в на серверную часть, и это «не круто»

testersup889 ()
Ответ на: комментарий от testersup889

Таких ньюансов нет

Ты берешь очень «сложные» задачи, где задеваешь сразу до фига разнородных мест, касающихся деоптимизации. И не смотришь логи JIT. Какой в этом смысл? Я и так могу сказать, что деоптимизированный код где-то на порядок медленнее сишечки и т.п.

ты сам и озвучил причину- все пишут под «хром джаваскрипт» учитывая его особенности что нужно раскладывать все на линейную простейшую функциональщину желательно одной функцией на всю странице

Нет. Это у тебя в голове нафантазировал кто-то похожий на меня. Я всего лишь написал, что ты слишком много вещей валишь в кучу.

Берем для примера ресайзер картинок https://github.com/nodeca/pica. Математика в фаерфоксе допускает больше вольностей. А потом всё просасывает на извлечении пикселей из канваса и времени создания вебворкера.

Если к тестам ты сможешь пояснять что конкретно и как именно тупит, их ценность сильно возрастет.

Vit ★★★★★ ()
Ответ на: комментарий от Vit

ресайзер картинок

у меня тоже есть, в render_mini в джаваскрипте строка 83 по 86 https://github.com/danilw/cputests/blob/master/js/render_mini.html

все как ты и сказал- ресайз не тормозит,потому что там тормозить нечему

а вот если каждый из for вынести в отдельный .prototype. время на выполнение ресайза возрастет
также если разделить конечный фрейм на несколько массивов, из которых собирать(один пиксель получается сложением 1 и 2 массива,второй пиксель сложением 1 и 3 массива и тдтп) картинку в цикле рисования попикселям- тоже станет тормозить

это и сделано в render и render_mini где много массивов «складываются»(этож математика рейтрейсинга, все знают) друг с другом, и в джаваскрипте это тормозит
а вот работа с 1 линейным массивом не тормозит

Если к тестам ты сможешь пояснять что конкретно

в 1 посте я конкретно указал что тормозит-прототип и массивы(работа с кучей данных), ничего не придумывал тесты можешь сам потыкать

testersup889 ()
Ответ на: комментарий от testersup889

https://github.com/danilw/cputests/blob/master/js/render_mini.html#L85

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

Прототипы не тормозят, если ты не корежишь их на ходу, и не делаешь условного создания свойств в конструкторе. Если у тебя тормозят - значит что-то сделал не так, а не прототипы кривые. Надо бить все на мелкие части, влючать лог деоптимизаций и смотреть где JIT спотыкается.

Массивы, где надо много и быстро - делай типизированные (если не пересоздаются постоянно). Если просто целочисленные константы читать - обычные тоже шустрые.

Посмотри вот этот бложик http://mrale.ph/, если хочешь быстрый JS писать. И видос Егорова на ютюбе глянь.

Vit ★★★★★ ()
Последнее исправление: Vit (всего исправлений: 1)
Ответ на: комментарий от Vit

Вот эта строка должна все просаживать

....поставь таймер до и после этого всего блока for, время будет меньше 50мсек на весь блок в хроме, в файрфоксе вообще 0 будет слишком быстро

это строчка просто рисует пиксели,рисует пиксели, мое время timetocalc не учитывает эту функию отрисовки(она слишком быстрая)

в инструкции https://github.com/danilw/cputests/blob/master/build_readme.md читай

render_mini

uncomment line 170 and 343 in render_mini.js

js45 render_mini.js

это запуск без «браузера» через любой консольный джаваскрипт движок, вместо js45 используй node.js или любой другой

попиксельная отрисовка занимает менее 0.05 сек в любом браузере и не имеет отношения к основному алгоритму

testersup889 ()
Ответ на: комментарий от Vit

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

testersup889 ()
Ответ на: комментарий от testersup889

Я ничего не защищаю, просто объясняю что бенчмарки деоптимизированного кода показывают погоду на марсе. Судить по ним о производительности бессмысленно.

Vit ★★★★★ ()
Ответ на: комментарий от Vit

деоптимизированного кода

сложение массивов и векторная математика-это не деоптимизация, это математика

деоптимизация-это обфускация кода

банальные операции с массивами из книжек 80-х годов которые работали на 1Мгц процессорах

конечно я знаю что такое «оптимизация» под джаваскрипт, вот конкретно код render_mini имеет два пути оптимизации
первый-перемещение кода render_mini.js на сервер, на Java там запустить и отдавать готовые кадры клиенту
второй-статически пререндерить фреймы/состояния массивов и их показывать одинаковые всем клиентам

так вот подход «оптимизации под джаваскрипт» и есть Ограничение о котором я говорю

и конкретно привел пример-даже в WYSIWYG редакторе который пилит любой деревенский сисадмин под сайт своей конторы/офиса уже будет упираться в производительность, ни о каком реальном применении темболее для создания «игр» веббраузер не может использоваться

вобщем это мои детские травмы насчет джаваскрипта и боль от просмотра вебсайтиков на 5 фпсах с восьмиядерником

testersup889 ()
Ответ на: комментарий от Vit

мне кажется его подход интересным, на самом деле. т.е. да, то что ты делаешь - т.е. писать «оптимизированный» код , это отдельная и важная профессия, особенно для библиотек которыми потенциально могут пользоваться тысячи разработчиков.

Но у него, на сколько я понял, немного другой взгляд: он пишет так как напишет обычный программист. И смотрит что выходит. И мне кажется такой подход тоже заслуживает внимания, потому как большая часть кода написана «как есть».

В конце концов какая разница как jit работает с «оптимизированным» кодом, если более 99 процентов кода никто никогда оптимизировать не будет.

AndreyKl ★★★★★ ()
Последнее исправление: AndreyKl (всего исправлений: 1)
Ответ на: комментарий от AndreyKl

99 процентов кода никто никогда оптимизировать не будет.

если проект долгоиграющий и есть программист(ы) на проекте - будут.

а если проект не долгоиграющий, то и тормозить обычно там особо нечему

Ford_Focus ★★★★★ ()
Последнее исправление: Ford_Focus (всего исправлений: 1)
Ответ на: комментарий от testersup889

WYSIWYG редакторе

который пилит любой деревенский сисадмин

«любой деревенский сисадмин»(C) и не только просто подключит ACE. Или что там сейчас модно, я хз

Ford_Focus ★★★★★ ()
Ответ на: комментарий от testersup889

деоптимизация-это обфускация кода

Деоптимизация, это когда в JIT проверки ломаются, и он с компилированного кода откатывается на интерпретируемый вариант.

http://mrale.ph/ почитай все-таки. У нас сейчас расхождение на уровне терминологии, в таком состоянии невозможно ни спорить ни объяснять.

Vit ★★★★★ ()

что ставит крест на любых «реальных играх на webgl» для браузера

Это те самые игры о которых так любят кричать закапыватели flash и откапыватели html5?

PPP328 ★★ ()
Ответ на: комментарий от AndreyKl

Дык я ничего не имею против проекта вцелом.

Просто говорю что для яваскрипта результат предсказуем. И если он хочет получить быстрый код, надо дергать за другие педальки (быстрый - в 1.3-4.0 раза медленнее С, не больше).

В случае wasm возможно бенчмаркается кривоватый тулчейн.

Что касается практической стороны вопроса - очевидно что самое предсказуемое будет писать на C и прегонять в wasm.

Vit ★★★★★ ()
Ответ на: комментарий от Vit

Что касается практической стороны вопроса - очевидно что самое предсказуемое будет писать на C и прегонять в wasm.

Гм.

В смысле конечно «практической стороны» - это скорее всего только именно с твоего ракурса (с ракурса важных «сильных» оптимизаций), потому что с ракурса современного, гм, приложениестроения что ли, на сколько я его понимаю, писать на си тот ещё геморой. В смысле того что производительность труда крайне низкая и в среднем уж точно проще и дешевле, и что интересно в большом числе случаев в практическом смысле не хуже если написано на обычном яваскрипте.

Но для меня лично это очень интересная мысль, по определённым причинам. Позволь поинтересоваться, а это ты из какой-то практики? (в смысле бенчмарки там или даже может быть реальный код?) Или так должно выходить «теоритически» (из того как васм работает по идее)?

AndreyKl ★★★★★ ()
Последнее исправление: AndreyKl (всего исправлений: 1)
Ответ на: комментарий от Ford_Focus

ну бог с ним, не 99, 95. Просто затык обычно не в каждой строчке, а уж затык на который стоит обращать внимание в смысле оптимизации скорости, это вряд ли больше 1/20 части кода проекта. В большинстве случаев тормозить просто нечему, много тривиальных форм, приём-отправка. Т.е. абсолютно шаблонные операции оптимизация которых даже дав ускорение в 10 раз, не изменит нагрузки на сервер даже на 20% и не будет замечена пользователем ввиду того что делается ли это за 0.05 секунды или за 0.005 на глаз неотличимо.

AndreyKl ★★★★★ ()
Ответ на: комментарий от AndreyKl

Речь конечно шла о тех классах задач, где нужны быстрые вычисления. Например, обработка картинок и некоторые виды парсеров.

Если ты делаешь «библиотеку для всех», там есть смысл пободаться на яваскрипте и получить универсальный компактный код с поддержкой старого хлама. Но это гиморно, т.к. для JS отсутствуют нормальные тулзы для низкоуровневой отладки. То есть ты будешь писать как на C, но без блекджека и прочих удобств. С этой точки зрения забацать на сях и странслировать будет практичнее.

Конечно, может случится чудо, и у тебя есть программист, который совсем не знает C и при этом шарит в быстром JS. Но я пишу про более вероятные случаи. Если бизнесу нужен быстрый код - он берет программера на сях и этот код получает. Или берет программера на JS, и потом огребает, что в каком-то браузере провалилась скорость, а что-то сделать быстро принципиально невозможно.

Вопрос насчет «из какой практики» не понял. Проекты же все на гитхабе выложены. Там и числодробилки и парсеры яваскриптовые. Плюс wasm для саморазвития, просто по приколу (заметного профита по скорости пока нет).

Vit ★★★★★ ()
Ответ на: комментарий от Vit

Да, в целом согласен, видимо я где-то не совсем понял мысль.

Вопрос насчет «из какой практики» не понял. Проекты же все на гитхабе выложены. Там и числодробилки и парсеры яваскриптовые. Плюс wasm для саморазвития, просто по приколу (заметного профита по скорости пока нет).

Вопрос был конкретно про васм и си. Ты сказал:

Что касается практической стороны вопроса - очевидно что самое предсказуемое будет писать на C и прегонять в wasm.

Правда сейчас говоришь что

Плюс wasm для саморазвития, просто по приколу (заметного профита по скорости пока нет)

Может быть я не совсем верно понял мысль? Я подумал ты имеешь ввиду что с -> wasm это проверенный вариант который даёт предсказуемо хороший результат. И спросил насколько это доказанный факт. Просто я не очень в теме, поэтому хотел поинтересоваться у тебя как человека который ближе к вопросу.

AndreyKl ★★★★★ ()
Последнее исправление: AndreyKl (всего исправлений: 1)
Ответ на: комментарий от AndreyKl

Личный опыт. Я неплохо представляю чего стоит делать быстрый код на JS. На сишечке навалять выйдет проще и фатальных неожиданностей не случится.

По скорости wasm и быстрый js примерно одинаковы. Но последний намного гиморнее делать, и там есть много ограничений по плавучке, делению, округлению и т.п.

Vit ★★★★★ ()
Ответ на: комментарий от Vit

быстрый JS это- переброс всей «сложной» логики на сервер, и рисование рамочек окошечек и текста с тегами форматирования у клиента
другого «быстрого» дж не существует

в моем render и render_mini нет деления(есть в 1% от кода вне циклов), есть только сложение и умножение присвоение(копирование)(сложения строк в математике нет, в .js файлах), разницы в просзводительности между «целым» и «дробным» числом в JS нет, умнож все числа в моем коде на 1000000 и сделай окургление и дальше работай с целыми, в выводе пикселя раздели на 1000000... будет также медленно

По скорости wasm и быстрый js примерно одинаковы

вот я и сделал свой проект чтоб показать что это не так

testersup889 ()
Ответ на: комментарий от testersup889

быстрый JS это- переброс всей «сложной» логики на сервер, и рисование рамочек окошечек и текста с тегами форматирования у клиента
другого «быстрого» дж не существует

Ты отстал от жизни. Вот ссылка https://github.com/nodeca/pako, там можно самостоятельно поразвлекаться с бенчмарками.

По скорости wasm и быстрый js примерно одинаковы

вот я и сделал свой проект чтоб показать что это не так

Ну если писать JS как попало, то конечно не так. Но для такого простого утверждения не нужно вообще ничего писать, это и так понятно, говорил уже.

http://nodeca.github.io/pica/demo/ - вот тут можно убедиться, что целочисленная арифметика на JS особо не уступает WASM. Но делать такой код надо уметь.

Vit ★★★★★ ()
Ответ на: комментарий от Vit

Вот именно поэтой причине

если писать JS как попало,

Но делать такой код надо уметь.

я и сделал просто эталонную реализацию алгоритма рейтрейсинга описанного еще в 80-х годах, рассмотренного десятками и сотнями профессоров математики а все это время
посмотрев код любого открытого проекта по «софтвеерному моделированию сцены(даже блендер) код будет идентичен моему даже имена функий и классов типа Vec или нормализация совпадать, потому что быстрее этого алгоритма пока не придумано за десятки лет
чтоб не писали „твой код не правильный“ когда код реализация эталонного алгоритма (хотя как код может быть не правильным если он идентичен для всех реализаций...)

твой код по ссылке- https://ru.wikipedia.org/wiki/Deflate цитата

Deflate — это алгоритм сжатия без потерь, использующий комбинацию алгоритмов LZ77 и Хаффмана.

прости но там нечему тормозить

взять алгоритм сжатия jpeg или h264 - вот они будут тормозить,и тоже раз в 10-20 по сравнению с Си (если не вериш-могу поспорить с тобой, я делаю порт jpeg либы на джаваскрипте 1 в 1, если он тормозит как минимум в 10 раз-ты оплачиваеш мое время потраченное на порт(один два дня)

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

повторять одно и тоже мне надоело, я занят работой над OpenGL щас тестов на процессор уже хватит, либо плати за новый

testersup889 ()
Ответ на: комментарий от testersup889

Ты имплементировал хороший алгоритм без учета особенностей JIT. Поэтому у тебя яваскриптовый движок работает не в том режиме, и бенчмаркать это IMHO бессмысленно.

прости но там нечему тормозить

Ты утверждал, что быстрого яваскрипта не бывает. Я привел пример реальной тяжелой (deflate) задачи, где прогретый JS сливает сишечке всего в 1.3 раза.

(если не вериш-могу поспорить с тобой, я делаю порт jpeg либы на джаваскрипте 1 в 1, если он тормозит как минимум в 10 раз-ты оплачиваеш мое время потраченное на порт(один два дня)

А фишка в том, что никому не надо 1:1, надо чтобы быстро :). И чтобы ты не тратил время, вот https://github.com/notmasteryet/jpgjs. Правда ХЗ как бенчмаркать, надо в сишном коде все SIMD-оптимизации отключать, в deflate этого не требовалось. Почему ты считаешь что jpeg показательнее deflate - не знаю.

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

Есть твой проект, где сколот 1:1 стандартный алгоритм на яваскрипт, из-за чего возможности современных JIT не используются и код работает медленно.

Я не оцениваю, хорошо это или плохо. Просто пытаюсь объяснить, что твой код не использует фичи современных JIT. А то что интепретируемый код будет тупить - и так очевидно.

Vit ★★★★★ ()
Ответ на: комментарий от Vit

лямбда-современная возможность джаваскрипта используется в terrain-проекте

хром работает в 10 раз медленнее с лямбдой

никто не испольузет лямбды даже неспотря на быструю реализацию в файрфокс

testersup889 ()
Ответ на: комментарий от testersup889

Как сторонний наблюдатель замечу: у тебя несколько неравные условия. Хорошо, положим ты можешь написать код jpeg-компрессора который будет тормозить 10-20 раз по сравнению с сишной версией. Примем это как посылку 1. Положим Vit заплатил бы за тест, если бы в нём был смысл. Пусть это будет посылка 2.

Принимая во внимание обе посылки, вопрос:

Если Vit сможет
- либо написать свой jpeg-компрессор, причём используя тот же алгоритм что и ты как базу, но модифицировав его под jit

- либо модифицировать твой алгоритм

и при этом значительно ускорит выполнение алгоритма, ты будешь за это платить?

Если нет, то почему должен платить Вит? Это ведь вам обоим интересно (тут я полагаю, ты споришь не просто чтобы брякнуть, а из профессионального интереса)?

И вопрос номер два - какой вообще смысл в такой постановке вопроса? Ты можешь написать алгоритм тупо переложив его с си и он будет тормозить? Ну вероятно да. Так искусство тут в том чтобы он __не тормозил__. А так вопрос выглядит так «я могу сделать говно, ты заплати мне, я сделаю».

Выглядело бы справедливо если бы ты поставил условие «я портирую, а ты ускоряешь не меняя математику алгоритма»: если у него не выходит ускорить значительно, значит прав ты, если выходт - он, очевидно.

Но требовать с него платы неизвестно за что выглядит странным. (Что может оказаться твоим непрофессионализмом в итоге, кстати. я не утверждаю, но как вариант)

AndreyKl ★★★★★ ()
Ответ на: комментарий от testersup889

Это к чему? Я пытаюсь донести до тебя простую вещь - у современных яваскриптовых движков 2 режима работы: интерпретатора и компилятора. Ты фактически бенчмаркаешь интерпретатор. Ну он медленный, ясен пень.

Vit ★★★★★ ()
Ответ на: комментарий от AndreyKl

Да не, я не против за что-нибудь заплатить. Просто должна быть явная выгода. JPEG портировать бессмысленно, т.к. это уже сделали. А вот какой-нибудь face-detect haar-овским каскадом - дело нужное. Что-то мне не очень нравятся текущие имплементации.

Ну и акцент конечно стоит сместить, с «портирования 1:1» на «чтобы было быстро».

Vit ★★★★★ ()
Ответ на: комментарий от Vit

чтобы было быстро

ты сам сказал что быстро только то что «реализовано в движке джаваскрипта»... естественно я выбиру то чего там быть не может(и таких алгоритмов полно)

у современных яваскриптовых движков 2 режима работы: интерпретатора и компилятора.

ты всю тему повторяеш что я написал

невозможность замены базовых алгоритмов типо конвертаци строк, или перевода текста в изображение(текстуру), css алгоритмы отрисовки и прочие базовые элементы браузера... не буду в лишний раз упоминать

«режим компиляции» как ты назвал, это просто реализаций некоторого функционала внутри движка...и если код выходи за границы доступного «быстрого функционала»-тормоза

wasm такойже- прсото расширяет границы,вот пример https://github.com/danilw/cputests/blob/master/C/basic.c функция make_hex_string_learning заменяет функцию sprint %x встроенную, потомоу что встроенная в пару раз медленнее, на Си/низкоуровневых языках можно переделать что угодно- в этом все и заключается, джаваскрипт слишком сильно ограничивает
wasm ограничивает в выборе более высокоуровневых библиотек и интерфейсов

однако тест на сложение /сортировку/обработку кучи данных-слишком тривиальный чтоб гворить что он «нестандартный» или неподходящая задача для джаваскрипта, потмоу что такой функционал используется в любом проекте

testersup889 ()
Ответ на: комментарий от testersup889

сори за опечатки, писал одной рукой пока кушал пироженку с чаем

testersup889 ()
Ответ на: комментарий от AndreyKl

а ты ускоряешь не меняя математику алгоритма

менять математики и ускорять самый быстрый алгориттм рейтрейсинга, или jpeg по которым, обеим, написана не одна научная работа и они ускорены максимально...

ты скорее имел в виду, что я хочу сделать «через кривые функции» когда в джаваскрипте есть «супербыстрые суперкласные точно такиеже встроенные функции»...да но
jpeg и рейтрейсинг- это банальная математика копирования перемножения и сложения, плюс функии квадратного корня(встроенные в джаваскрипт естественно)... и это все

ускорять там нечего кроме математики, и если ускорить математику-она станет на «одинаково быстрее» во всех реализациях, в джаваскрипте нет «своей скрытой математике недоступной другим»

testersup889 ()

вобщем по jpeg, когда алгоритм jpeg в джаваскрипт реализации станет быстрее(если его делать)

сейчас- его надо делать целиком и джаваскрипт не включает ниодной встроенной функции которую использует jpeg

как стать быстрее- идем сюда https://ru.wikipedia.org/wiki/JPEG читаем весь абзац который идет после «Далее яркостный компонент Y и отвечающие за цвет компоненты Cb и Cr разбиваются на блоки 8х8 пикселов»
вот когда все перечисленные алгоритмы будут реализованы одной функцией которую вызываешь из джаваскрипта и получаеш готовый результат[] тогда и jpeg алгоритм станет быстрее, но возникнет вопрос отличия такого алгоритма об бинарного...

тоесть в конечном итоге, сейчас весь алгоритм jpeg будет:
function jpeg(){ ...и весь порт целиком всех алгоритмов на джаваскрипт синтаксисе... }

после переноса ключевых функций внутрь джаваскрипт движка, будет так:
function jpeg(){ build_in_js_alg_1(data);build_in_js_alg_2(data); result=build_in_js_alg_3(data)}

все сведется к вызову трех(или более) встроенных функций которые «все сделают» без 100500 кодов математики на джаваскрипте

вот такой подход не называется «оптимизацией» ниразу

testersup889 ()
Ответ на: комментарий от testersup889

Мне просто показалось странным, что ты называешь бенчмарком заведомо медленный код. Обычно стараются бенчмаркать быструю реализацию. Поэтому и написал комментарии про те имплементации, в которых был похожий опыт. Но я ни на чем не настаиваю, каждый пишет как хочет.

Vit ★★★★★ ()
Ответ на: комментарий от Vit

он плохо переваривает плавучку

ЕМНИП в JS ничего кроме «плавучки» и нет.

beastie ★★★★★ ()
Ответ на: комментарий от beastie

В спеке-то нет, а в имплементациях под капотом есть. Они ж на ходу статистику собирают, чтобы сгенерированный код переоптимизировать.

Vit ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.