Здравствуйте, Sinix, Вы писали:

S>Ув. EP из темы в тему сравнивает стоимость вызова заинлайненного метода в плюсах, странслированного в web asm пардон, в asm.js. Переклинило. (т.е. к JS оно строго говоря не относится) и делегата шарпа. Делать из этого глобальные выводы на полном серьёзе — троллинг из серии "замеряем работу с числами в питоне без numPy".
S>Я уже раза три намекал про "когда важен перфоманс, пишут немного в другом стиле", но чего-то не помогает. Нравится передёргивать — флаг в руки, главное чтоб остальные не велись.
Хоть я к этому и отношусь скептически — всё же зерно истины в его словах есть, в контексте этого треда. В тот большой тред влазить неохота, я его замахался читать в прошлый раз.

Я полностью согласен, что современные JS VM — весьма годные штуки. Другое дело, что .NET в целом — на две головы выше, просто потому что голая VM очень мало кому нужна. А .NET и генерирует код и выполняет его безо всяких приседаний, и имеет кучу библиотек, и GC получше, да и сама VM куда мощнее (хотя бы на уровне примитивных типов). Мне вот не хватает в JS int64 — приходится обходится по месту, чем есть (строки — если id).

У меня профайлер в одном из hot path показывает, что время тупо уходить на интероп... ну там из std::string преобразовывается в какой-нибудь WTF::String. И такие миленькие преобразования по колстэку только в нэйтиве — происходят 3 раза, иногда с копированием, иногда ещё и с конверсией (utf8/utf16), естественно это тянет за собой и аллокации -> в итоге уже плохо. А нерегулярное пропихивание строк в 0.5-4 мегабайта, с такими преобразованиями — и перфоманс превращается в торманз. Ну ничего, бывает, а проц и кеши у нас всё равно резиновые. Будем терпеть пока все либы не перейдут на одну строку , и очевидно std::string едет лесом.

Но вот вызов колбэка в цикле... ну да, это клёва уметь инлайнить, адаптивный/спекулятивный JIT и т.п. С другой стороны тут вот GCC HashTable показывает лучшие результаты (второй, но первый выигрывает не за счет инлайнинга), хотя это чистый C и компаратор никак не может быть заинлайнен. Так что на мой взгляд — значимость в целом думаю переоценена. Естественно где-то это очень нужно, а в синтетике без этого вообще никак нельзя.

Здравствуйте, Sinix, Вы писали:

S>Ув. EP из темы в тему сравнивает стоимость вызова заинлайненного метода в плюсах, странслированного в web asm пардон, в asm.js. Переклинило. (т.е. к JS оно строго говоря не относится) и делегата шарпа. Делать из этого глобальные выводы на полном серьёзе — троллинг из серии "замеряем работу с числами в питоне без numPy".
S>Я уже раза три намекал про "когда важен перфоманс, пишут немного в другом стиле", но чего-то не помогает. Нравится передёргивать — флаг в руки, главное чтоб остальные не велись.
Хоть я к этому и отношусь скептически — всё же зерно истины в его словах есть, в контексте этого треда. В тот большой тред влазить неохота, я его замахался читать в прошлый раз.

Я полностью согласен, что современные JS VM — весьма годные штуки. Другое дело, что .NET в целом — на две головы выше, просто потому что голая VM очень мало кому нужна. А .NET и генерирует код и выполняет его безо всяких приседаний, и имеет кучу библиотек, и GC получше, да и сама VM куда мощнее (хотя бы на уровне примитивных типов). Мне вот не хватает в JS int64 — приходится обходится по месту, чем есть (строки — если id).

У меня профайлер в одном из hot path показывает, что время тупо уходить на интероп... ну там из std::string преобразовывается в какой-нибудь WTF::String. И такие миленькие преобразования по колстэку только в нэйтиве — происходят 3 раза, иногда с копированием, иногда ещё и с конверсией (utf8/utf16), естественно это тянет за собой и аллокации -> в итоге уже плохо. А нерегулярное пропихивание строк в 0.5-4 мегабайта, с такими преобразованиями — и перфоманс превращается в торманз. Ну ничего, бывает, а проц и кеши у нас всё равно резиновые. Будем терпеть пока все либы не перейдут на одну строку , и очевидно std::string едет лесом.

Но вот вызов колбэка в цикле... ну да, это клёва уметь инлайнить, адаптивный/спекулятивный JIT и т.п. С другой стороны тут вот GCC HashTable показывает лучшие результаты (второй, но первый выигрывает не за счет инлайнинга), хотя это чистый C и компаратор никак не может быть заинлайнен. Так что на мой взгляд — значимость в целом думаю переоценена. Естественно где-то это очень нужно, а в синтетике без этого вообще никак нельзя.

Update: А в дотнете давно-давно я занимался и ручным инлайнингом, и ручным инлайнингом алгоритмов с адаптацией под разные вариации входных данных (типа строка, буффер, указатель). Хотя лучше бы как-то уметь сказать компилятору кто здесь.