Здравствуйте, Pauel, Вы писали:
P>>>Это заблуждение. Движок ноды, если не считать некоторых вещей, работает примерно с тем же перформансом, что и джава. P>·>Ловко. Иными словами, надо не считать случаи, когда нода работает медленее, чтобы сделать такой вывод. P>Учитывать нужно всё.
Демагогия.
P>>>c-cast это explicit, а я говорю об implicit. Понятно, что код будет другой, не 1 в 1, как в тайпскрипте. P>·>Код в студию. P>Какой в этом смысл? Когда ты последний раз писал на С++?
Демагогия.
P>>>Забавно, что ты сам с собой споришь — я всего то процитировал тебе твои собственные слова. P>·>Ты переиначил мои слова. Это не обёртка языка, а обёртка массива, низкоуровневой конструкции языка. Как какой-нибудь там UUID это обёртка над двумя long, например. P>IList это никакая не обёртка — это интерфейс, они ничего оборачивть не может. Обертки создает конкретный разработчик.
К словам придираешься. Пусть будут реализации IList, суть в том, что IList описывает тип и методы с типизированными параметрами.
P>>>Именно это и создаёт проблемы. P>·>Какие проблемы-то? P>Те самые.
Демагогия.
P>>>Таким приходится заниматься именно потому, что язык хилый, и энумы в ём так себе. P>·>Вкусовщина. А по-моему, самые удобные enum-ы, что мне встречались — их можно енумить! Ну и куча других полезных фич. P>Я в курсе, всё, что не как в джаве, сразу плохое.
Про "сразу плохое" ты сам сочинил, демагогия.
P>>>Например, моя реализация сериализатор для ODATA работает быстрее и джавовской, и дотнетной. P>·>Либо магия, либо нативный код (например парсер json), либо не все фичи. P>Скажем, с питоном даже близко подобраться к джаве не выйдет, хота в ём полно нативного кода. Идея понятна?
Вот тут он даже "супербыструю" ноду "обогнал", внезапно.
pidigits
source mem gz cpu
Python 3 #3 11,968 567 1.13
Node js #4 45,096 481 1.14
regex-redux
source mem gz cpu
Python 3 #2 111,680 1403 2.66
Node js #3 1,045,556 668 5.97
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Pauel, Вы писали:
НС>>Потому что используешь его как аргумент в споре.
P>Если непонятно, что такое мнение и точка зрения — попробуй не прибегая к зеркалу увидеть свою задницу или затылок. Не вышло? Такая вот у тебя точка зрения. И из неё никак не следует, что задницы или затылка у тебя нет. P>Собственно, это нормально — мы то на форуме, который есть обмен мнениями.
Нет, использовать свое мнение как аргумент не нормально.
Здравствуйте, ·, Вы писали:
P>>·>Ловко. Иными словами, надо не считать случаи, когда нода работает медленее, чтобы сделать такой вывод. P>>Учитывать нужно всё. ·>Демагогия.
Из нас двоих только я привел все бенчмарки. Так что если тут демагогия, то где то с твоей стороны.
P>>·>Код в студию. P>>Какой в этом смысл? Когда ты последний раз писал на С++? ·>Демагогия.
Попробуй таки ответить на мои вопросы. С моей точки зрения тебе абы оплевать любой из примеров. На примере жээса — используется нативная либа — херня. Нету нативной либы — тоже херня. И так плохо, и так плохо. Выглядит так, что всё плохо, что не джава.
P>>IList это никакая не обёртка — это интерфейс, они ничего оборачивть не может. Обертки создает конкретный разработчик. ·>К словам придираешься. Пусть будут реализации IList, суть в том, что IList описывает тип и методы с типизированными параметрами.
Ты похоже, контекст потерял. ты в курсе, что IList и IList<> это разные интерфейсы ?
P>>Я в курсе, всё, что не как в джаве, сразу плохое. ·>Про "сразу плохое" ты сам сочинил, демагогия.
Это сумма твоих высказываний.
P>>Скажем, с питоном даже близко подобраться к джаве не выйдет, хота в ём полно нативного кода. Идея понятна? ·>Вот тут он даже "супербыструю" ноду "обогнал", внезапно. ·>pidigits
Похоже, тебе абы накидывать — здесь была речь про сериализатор ODATA.
Здравствуйте, Ночной Смотрящий, Вы писали:
P>>Если непонятно, что такое мнение и точка зрения — попробуй не прибегая к зеркалу увидеть свою задницу или затылок. Не вышло? Такая вот у тебя точка зрения. И из неё никак не следует, что задницы или затылка у тебя нет. P>>Собственно, это нормально — мы то на форуме, который есть обмен мнениями.
НС>Нет, использовать свое мнение как аргумент не нормально.
Как аргумент как раз таки нормально — у каждого своя точка зрения, каждый говорит — "я считаю/вижу/думаю что..."
Более того, на форуме вполне легально убедить собеседника любым законным способом, хоть логичным, хоть алогичным, эмоциональным, рациональным, иррациональным — каким угодно. Можно просто написать — "поверь мне, я знаю о чем говорю" и это для многих будет решающим вкладом.
А вот доказательсво в суде, научной работе — ненормально. никто тебя не поймёт, если ты выдашь в описании вечного двигателя "поверьте, я знаю о чем говорю"
Здравствуйте, Pauel, Вы писали:
P>>>Учитывать нужно всё. P>·>Демагогия. P>Из нас двоих только я привел все бенчмарки. Так что если тут демагогия, то где то с твоей стороны.
И ты выбрал только удобные тебе результаты этих бенчмарков.
P>>>·>Код в студию. P>>>Какой в этом смысл? Когда ты последний раз писал на С++? P>·>Демагогия. P>Попробуй таки ответить на мои вопросы.
"Какой в этом смысл?" — это риторический вопрос. Демагогия. Отвечаю, если тебе так хочется: "большой".
"Когда ты последний раз писал на С++?" — это переход на личности. Демагогия. Отвечаю, если тебе так хочется: "не очень давно".
Если у тебя есть какой-то вменяемый вопрос, задавай, не стесняйся.
P> С моей точки зрения тебе абы оплевать любой из примеров. На примере жээса — используется нативная либа — херня.
Конечно, ибо в этом случае даже питон может выиграть.
P>Нету нативной либы — тоже херня.
Я такого не говорил.
P> И так плохо, и так плохо. Выглядит так, что всё плохо, что не джава.
Не "всё", а конкретно ts, И не только джава, а упомянутые тут java/c#/c++.
P>>>IList это никакая не обёртка — это интерфейс, они ничего оборачивть не может. Обертки создает конкретный разработчик. P>·>К словам придираешься. Пусть будут реализации IList, суть в том, что IList описывает тип и методы с типизированными параметрами. P>Ты похоже, контекст потерял. ты в курсе, что IList и IList<> это разные интерфейсы ?
Нет, не в курсе, c# я вообще не знаю. А что это меняет? object это не тип что-ли?
P>>>Я в курсе, всё, что не как в джаве, сразу плохое. P>·>Про "сразу плохое" ты сам сочинил, демагогия. P>Это сумма твоих высказываний.
Это твои домыслы.
P>>>Скажем, с питоном даже близко подобраться к джаве не выйдет, хота в ём полно нативного кода. Идея понятна? P>·>Вот тут он даже "супербыструю" ноду "обогнал", внезапно. P>·>pidigits P>Похоже, тебе абы накидывать
Ты первый начал накидывать, значит мне тоже можно: Движок питона, если не считать некоторых вещей, работает примерно с тем же перформансом, что и нода. Вот и попробуй докажи, что это не так.
P> — здесь была речь про сериализатор ODATA.
Я не знаю о чём идёт конкретно речь. Разве там не просто json? За счёт чего твой сериализатор быстрее. Магия?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
P>>Из нас двоих только я привел все бенчмарки. Так что если тут демагогия, то где то с твоей стороны. ·>И ты выбрал только удобные тебе результаты этих бенчмарков.
Я ничего не выбирал, а просто показал, что провал в основном только там, где многопоточность и пофиксить это никак нельзя. Все остальное или работает хорошо искаропки, или фиксится либами, что есть норма — так устроена платформа. И сравнивать нужно именно платформу с платформой, т.к. отделить яп от платформы никак не выйдет. Не бывает абстрактных языков вне платформы.
Твои аргументы — "регекспы считать низя, они не на жээсе"
P>>Попробуй таки ответить на мои вопросы. ·>"Какой в этом смысл?" — это риторический вопрос. Демагогия. Отвечаю, если тебе так хочется: "большой".
Это никакой не риторический вопрос. Объясни, ради чего мне стараться? У тебя есть внятный ответ на это? Вот у меня — нету.
·>"Когда ты последний раз писал на С++?" — это переход на личности. Демагогия. Отвечаю, если тебе так хочется: "не очень давно".
Нету здесь перехода, выглядит так, будто ты не в курсе Implicit cast https://en.cppreference.com/w/cpp/language/implicit_conversion
Ровно тот же кейс — заведомо некорректный код взял да и скомпилировался.
P>> С моей точки зрения тебе абы оплевать любой из примеров. На примере жээса — используется нативная либа — херня. ·>Конечно, ибо в этом случае даже питон может выиграть.
P>>Нету нативной либы — тоже херня. ·>Я такого не говорил.
А между тем ты оплевал и тот пример, где не было никаких дополнительных либ.
P>>Ты похоже, контекст потерял. ты в курсе, что IList и IList<> это разные интерфейсы ? ·>Нет, не в курсе, c# я вообще не знаю. А что это меняет? object это не тип что-ли?
Это значит, что на дыру, которую ты показал, можно напороться самыми разными способами.
То есть, всё тот же кейс "заведомо некорректный код скомпилировался т.к. система типов не смогла защитить"
P>>·>pidigits P>>Похоже, тебе абы P>> — здесь была речь про сериализатор ODATA. ·>Я не знаю о чём идёт конкретно речь. Разве там не просто json? За счёт чего твой сериализатор быстрее. Магия?
Конечно же нет. джсон это конечный формат. А надо обработать конкретный граф, где то с циклическими зависимостями, поотрубать лишние ветки, достроить необходимые, наложить на это метаданные, преобразовать все в серилизуемую форму и только потом преобразовать в джсон.
Здравствуйте, Pauel, Вы писали:
P>>>Из нас двоих только я привел все бенчмарки. Так что если тут демагогия, то где то с твоей стороны. P>·>И ты выбрал только удобные тебе результаты этих бенчмарков. P>Я ничего не выбирал, а просто показал, что провал в основном только там, где многопоточность и пофиксить это никак нельзя.
Я увидел по-другому. Провала не было только в коде с тривиальным циклом по байт-буферу. В остальном были либо тормоза, либо нативные либы, либо проблемы с многопотоком.
P>Все остальное или работает хорошо искаропки, или фиксится либами, что есть норма — так устроена платформа. И сравнивать нужно именно платформу с платформой, т.к. отделить яп от платформы никак не выйдет. Не бывает абстрактных языков вне платформы. P>Твои аргументы — "регекспы считать низя, они не на жээсе"
Регекспы это нетривиальный код, который делает какую-то хитрую реальную работу. Поэтому тест с нативной либой замеряет не скорость платформы, а скорость вызова нативных методов. Что, мягко говоря, неинтересно, и вообще питон победил.
А то что java отстаёт от нативной либы лишь немного с учётом того, что там регекспы написаны с использованием managed+gc чистого кода на самом яп — это круто. И не поверишь, без всяких интринзиков, полный список можешь увидеть тут.
P>>>Попробуй таки ответить на мои вопросы. P>·>"Какой в этом смысл?" — это риторический вопрос. Демагогия. Отвечаю, если тебе так хочется: "большой". P>Это никакой не риторический вопрос. Объясни, ради чего мне стараться? У тебя есть внятный ответ на это? Вот у меня — нету.
Вот обсуждение
Ты заявил, что там по ссылке какой-то "правильный" ответ, не совпадающий с моей цитатой. И ты так трудишься, скрывая свой ответ, что у меня стойкое впечатление, что ты что-то не так понял; вместо того, что просто признать ошибку, разводишь демагогию на пустом месте.
P>·>"Когда ты последний раз писал на С++?" — это переход на личности. Демагогия. Отвечаю, если тебе так хочется: "не очень давно". P>Нету здесь перехода, выглядит так, будто ты не в курсе Implicit cast https://en.cppreference.com/w/cpp/language/implicit_conversion P>Ровно тот же кейс — заведомо некорректный код взял да и скомпилировался.
Давай конкретную цитату. Что именно некорректно?
P>>>Нету нативной либы — тоже херня. P>·>Я такого не говорил. P>А между тем ты оплевал и тот пример, где не было никаких дополнительных либ.
"Хороший jit" — это такой плевок? Ок, пусть будет плохой jit.
P>>>Ты похоже, контекст потерял. ты в курсе, что IList и IList<> это разные интерфейсы ? P>·>Нет, не в курсе, c# я вообще не знаю. А что это меняет? object это не тип что-ли? P>Это значит, что на дыру, которую ты показал, можно напороться самыми разными способами. P>То есть, всё тот же кейс "заведомо некорректный код скомпилировался т.к. система типов не смогла защитить"
Это не дыра, т.к. потребуется явное преобразование типа. А там где оно есть, там, очевидно, может вылетать Class Cast Exception. В случае же ts там тупо молча без явных конструкций можно менять read-only поля и ловить CCE (ну точнее null reference exception, т.к. duck typing) в случайных строчках кода, happy debugging.
P>>>Похоже, тебе абы P>>> — здесь была речь про сериализатор ODATA. P>·>Я не знаю о чём идёт конкретно речь. Разве там не просто json? За счёт чего твой сериализатор быстрее. Магия? P>Конечно же нет. джсон это конечный формат. А надо обработать конкретный граф, где то с циклическими зависимостями, поотрубать лишние ветки, достроить необходимые, наложить на это метаданные, преобразовать все в серилизуемую форму и только потом преобразовать в джсон.
Так почему твой сериализатор быстрее?
Скажем, из бенчмарков о структуре в памяти подходит вот этот бенч. И нода совсем не блещет, на уровне php.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
В>>Меня, конечно, вообще удручаети общее состояние отрасли. Всё на коленке, хренак-хренак и в боевую часть.
Б>Нужно писать тесты, на любом языке. Тогда норм.
Которые или не пишутся или пишутся на "отвяжись от меня".
В>>Пытаюсь анализировать elscticseach. Есть 1.5 (знаю!) и 6.8 (тоже). 2000 гб каждая. В>>scoll не работает в первой. В>>search кончается на 1% во второй при выборке в 100, 1000, 10000 элементов. В>>Код на 20 строк, но работает 5 часов. Королева в шоке (с) В>>Какого хрена не придумали combined schema? Почему mapping отменили, но они всё ещё есть. Но даже там где есть, они не учитывают вложенность?
Б>Это я не распарсил.
Это особенности работы с эластиком. Который, как бы номер один в своей отрасли.
В>>Почему в питоне слияние словарей не учивает списки? *перезатираются последним, вместо слияния* И ещё довольные такие, типа это редкость. Сам пиши.
Б>Про "слияние словарей не учивает списки". Почему ты считаешь, что при слиянии надо списки объединять, а не заменять? Лично для меня это не очевидно. Написать функцию не проблема — 4-5 строк
Можно, только это будет существенно медленней, чем на C++, когда они делают.
И на миллиардах слияний разница огромная.
Можно было ключ какой-нить придумать, что-ли. Почему нужно?
Потому, что если у тебя
{"a": [{"b": {...}}, ...]} | {"a": []}, то информация о структуре элементов список пропадает напрочь.
Но это вообще даже не только проблема списков, но не списков тоже. Слияние не очень умное.
·>Ты заявил, что там по ссылке какой-то "правильный" ответ, не совпадающий с моей цитатой. И ты так трудишься, скрывая свой ответ, что у меня стойкое впечатление, что ты что-то не так понял; вместо того, что просто признать ошибку, разводишь демагогию на пустом месте.
Ага, ты про это. Собственно, я уже забыл что там в том треде. Может и ошибся.
P>>То есть, всё тот же кейс "заведомо некорректный код скомпилировался т.к. система типов не смогла защитить" ·>Это не дыра, т.к. потребуется явное преобразование типа. А там где оно есть, там, очевидно, может вылетать Class Cast Exception. В случае же ts там тупо молча без явных конструкций можно менять read-only поля и ловить CCE (ну точнее null reference exception, т.к. duck typing) в случайных строчках кода, happy debugging.
Это не такая страшная помеха, как ты представляешь. Есть куча других методов ограничить доступ чтением. На самом деле сама структурная типизация вещь вообще призрачная, т.к. Forum можно легко присвоить в Item, если у них структура совместимая.
И даже это не проблема.
P>>·>Я не знаю о чём идёт конкретно речь. Разве там не просто json? За счёт чего твой сериализатор быстрее. Магия? P>>Конечно же нет. джсон это конечный формат. А надо обработать конкретный граф, где то с циклическими зависимостями, поотрубать лишние ветки, достроить необходимые, наложить на это метаданные, преобразовать все в серилизуемую форму и только потом преобразовать в джсон. ·>Так почему твой сериализатор быстрее?
Рефлексия дешовая.
·>Скажем, из бенчмарков о структуре в памяти подходит вот этот бенч. И нода совсем не блещет, на уровне php.
Здравствуйте, Pauel, Вы писали:
P>·>Ты заявил, что там по ссылке какой-то "правильный" ответ, не совпадающий с моей цитатой. И ты так трудишься, скрывая свой ответ, что у меня стойкое впечатление, что ты что-то не так понял; вместо того, что просто признать ошибку, разводишь демагогию на пустом месте. P>Ага, ты про это. Собственно, я уже забыл что там в том треде. Может и ошибся.
Ок. Хорошо, но уже лучше. Продолжаем. Ты этот ошибочный аргумент использовал для доказательства "та самая дырка есть почти что во всех мейнстримных языках, а в Си/Си++ это вообще норма жизни.". К C это не применимо, там вообще типов нет таких. Как выяснилось в плюсах такой дыры нет, ты ошибся. В шарпе такой дыры тоже нет, там требуются явное приведение типов. В джаве только если использовать legacy raw types и игнорировать предупреждения компилятора. Какие ещё "почти все" мейнстрим языки остались?
P>>>То есть, всё тот же кейс "заведомо некорректный код скомпилировался т.к. система типов не смогла защитить" P>·>Это не дыра, т.к. потребуется явное преобразование типа. А там где оно есть, там, очевидно, может вылетать Class Cast Exception. В случае же ts там тупо молча без явных конструкций можно менять read-only поля и ловить CCE (ну точнее null reference exception, т.к. duck typing) в случайных строчках кода, happy debugging. P>Это не такая страшная помеха, как ты представляешь. Есть куча других методов ограничить доступ чтением.
Может тебе, привычному к динамике, это и не помеха, но когда заявляют static typing язык, то это уже неприемлимо. Суть в том, что ты перестаёшь доверять коду — написано одно, а там совершенно неожиданно совсем другое, т.к. где-то совсем в другом месте что-то не так сделали.
P>На самом деле сама структурная типизация вещь вообще призрачная, т.к. Forum можно легко присвоить в Item, если у них структура совместимая.
Так ведь проблема в том, что в ts оказывается Forum можно легко присвоить в Item, даже если у них структура совсем не совместимая, а вылезет проблема совсем в другом месте. Почти из той же оперы, что и расстрел памяти.
P>·>Так почему твой сериализатор быстрее? P>Рефлексия дешовая.
Погоди, в сабже есть рефлексия?.. Или ты имеешь в виду node javascript?
Впрочем, в java рефлексия не такая уж медленная, а ещё и MethodHandle есть. Скорее всего odata-либы в java на перформанс не особо заморачивались. Неясно зачем в такой области вообще о перформансе беспокоиться, всё равно json большую часть времени сожрёт.
P>·>Скажем, из бенчмарков о структуре в памяти подходит вот этот бенч. И нода совсем не блещет, на уровне php. P>Ты бы хоть посмотре, что там: P>Мне не сильно понятно, начорта там воркертреды
Ну ты сам эти бенчмарки притащил. И сказал, что хорошие бенчмарки, и выводов из них понаделал.
заметь вот это: тут ворктредов нет, и оно вообще жуть тормозит по всем параметрам.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
P>>Ага, ты про это. Собственно, я уже забыл что там в том треде. Может и ошибся. ·>Ок. Хорошо, но уже лучше. Продолжаем. Ты этот ошибочный аргумент использовал для доказательства "та самая дырка есть почти что во всех мейнстримных языках, а в Си/Си++ это вообще норма жизни.". К C это не применимо, там вообще типов нет таких.
У тебя здесь логическая ошибка — к Си это применимо еще ширше, т.к. там полноценных типов нет и нормой является использование указателей, которые фактически int. В динамических языках весь язык состоит позволяет такие дыры.
·>Может тебе, привычному к динамике, это и не помеха, но когда заявляют static typing язык, то это уже неприемлимо. Суть в том, что ты перестаёшь доверять коду — написано одно, а там совершенно неожиданно совсем другое, т.к. где-то совсем в другом месте что-то не так сделали.
Ты продолжаешь рассматривать статическую типизацию как способ анального огораживания, как в джаве. При этом всё, что ты накопал, это проблема с одной единственной фичей
Похоже, ты делаешь из мухи слона.
P>>На самом деле сама структурная типизация вещь вообще призрачная, т.к. Forum можно легко присвоить в Item, если у них структура совместимая. ·>Так ведь проблема в том, что в ts оказывается Forum можно легко присвоить в Item, даже если у них структура совсем не совместимая, а вылезет проблема совсем в другом месте.
Проверяем твоё утверждение. Присвоим {name: string} в {name: 'something'} и видим, что твоё утверждение невалидно. То есть, проблема всё еще в одной единственной фиче, как будто это какая то обязательная вещь. На самом деле тебе религия мешает найти тикет в гитхабе и увидеть что спроса на эту фичу нет.
P>>Рефлексия дешовая. ·>Погоди, в сабже есть рефлексия?.. Или ты имеешь в виду node javascript?
А как ты думаешь сериализатор работает? Нужно перебрать свойства рефлексией, получить значения той же рефлексией. Понасоздавать всякие временные и промежуточные объекты, самому склеивать строчки, делать кучу приседаний для конверсии и тд, т.к. платформа ничего другого не умеет. В жээсе всё делается легче и проще.
Не все вычисления такие эффективные, т.к. в жээсе хуже локальность, т.е. вместо кеша и регистров будем чаще работать с памятью. Но и в джаве есть похожая проблема — если джит компактификацию не сделает, получишь почти то же.
·>Впрочем, в java рефлексия не такая уж медленная, а ещё и MethodHandle есть. Скорее всего odata-либы в java на перформанс не особо заморачивались. Неясно зачем в такой области вообще о перформансе беспокоиться, всё равно json большую часть времени сожрёт.
Во первых, медленная. Во вторых, если ты к 10мс добавишь еще 10мс, то платить за железо тебе придется вдвое бОльше.
P>>Мне не сильно понятно, начорта там воркертреды ·>Ну ты сам эти бенчмарки притащил. И сказал, что хорошие бенчмарки, и выводов из них понаделал.
Я всего то отсортировал и показал, что именно в этих бенчмарках.
·>заметь вот это: тут ворктредов нет, и оно вообще жуть тормозит по всем параметрам.
Вообще то я сам сказал, что здесь жээс отстает где то в 5 раз. Что нового ты добавил? Я вот могу добавить — в данном примере, по твоей ссылке, ошибка — замер интерпретатора, а не джита. Может не совсем корректно, но код деоптимизируется, что видно если указать флаг --trace-deopt. Т.е. мы сравниваем деоптимизированый вариант жээс с оптимизированым джава.
Java быстрее
fannkuch-redux — менее 10%
n-body — менее 25%
pi-digits — около 50%
fasta — 50%
reverse-complement — около 50%
mandelbrot — ноздря в ноздрю
Node быстрее
spectral-norm — менее 10% <- похоже, ошибка на сайте, джава обгоняет на 10%
regex-redux — в три раза
Многопоточный код, джава выруливает
k-nucleotide — почти в трое
binary-trees — где то в 5 раз <- если речь про максимально быстрый вариант, то писать нужно несколько иначе
Итого — в большинстве случаев джава имеет сравнимый перформанс с жээсом, кроме тех случаев, где многопоточность.
Здравствуйте, Pauel, Вы писали:
P>>>Ага, ты про это. Собственно, я уже забыл что там в том треде. Может и ошибся. P>·>Ок. Хорошо, но уже лучше. Продолжаем. Ты этот ошибочный аргумент использовал для доказательства "та самая дырка есть почти что во всех мейнстримных языках, а в Си/Си++ это вообще норма жизни.". К C это не применимо, там вообще типов нет таких. P>У тебя здесь логическая ошибка — к Си это применимо еще ширше, т.к. там полноценных типов нет и нормой является использование указателей, которые фактически int. В динамических языках весь язык состоит позволяет такие дыры.
Ок, пусть даже Си и ширше и вообще бардак. Но считать нормой проблемы Си и тащить такое в бэкенд — это можно обосновать лишь жоп-секьюрити.
Спасибо что про c++/java/c# ошибки признал.
P>·>Может тебе, привычному к динамике, это и не помеха, но когда заявляют static typing язык, то это уже неприемлимо. Суть в том, что ты перестаёшь доверять коду — написано одно, а там совершенно неожиданно совсем другое, т.к. где-то совсем в другом месте что-то не так сделали. P>Ты продолжаешь рассматривать статическую типизацию как способ анального огораживания, как в джаве. При этом всё, что ты накопал, это проблема с одной единственной фичей P>Похоже, ты делаешь из мухи слона.
Спасибо, что хоть признал, что это проблема. А мухослон именно в том, что тайпскрипт на платформе js. Т.е. даже если игнорировать дыры в самом ts, то всё равно проблемы js лезут из всех щелей.
P>>>На самом деле сама структурная типизация вещь вообще призрачная, т.к. Forum можно легко присвоить в Item, если у них структура совместимая. P>·>Так ведь проблема в том, что в ts оказывается Forum можно легко присвоить в Item, даже если у них структура совсем не совместимая, а вылезет проблема совсем в другом месте. P>Проверяем твоё утверждение. Присвоим {name: string} в {name: 'something'} и видим, что твоё утверждение невалидно.
У тебя с логикой проблемы. Квантор существования не опровергается одним контрпримером.
P>То есть, проблема всё еще в одной единственной фиче, как будто это какая то обязательная вещь. На самом деле тебе религия мешает найти тикет в гитхабе и увидеть что спроса на эту фичу нет.
Знатное чтиво https://github.com/microsoft/TypeScript/issues/13347
P>>>Рефлексия дешовая. P>·>Погоди, в сабже есть рефлексия?.. Или ты имеешь в виду node javascript? P>А как ты думаешь сериализатор работает? Нужно перебрать свойства рефлексией, получить значения той же рефлексией.
Рефлексия это инфа о типах. В js типов нет (точнее у всего один тип).
P>Понасоздавать всякие временные и промежуточные объекты, самому склеивать строчки, делать кучу приседаний для конверсии и тд, т.к. платформа ничего другого не умеет. В жээсе всё делается легче и проще.
В java ровно то же делается на HashMap/ArrayList. Нет никакой магии.
P>Не все вычисления такие эффективные, т.к. в жээсе хуже локальность, т.е. вместо кеша и регистров будем чаще работать с памятью. Но и в джаве есть похожая проблема — если джит компактификацию не сделает, получишь почти то же.
компактификация это про gc, а не про jit.
P>·>Впрочем, в java рефлексия не такая уж медленная, а ещё и MethodHandle есть. Скорее всего odata-либы в java на перформанс не особо заморачивались. Неясно зачем в такой области вообще о перформансе беспокоиться, всё равно json большую часть времени сожрёт. P> Во первых, медленная. Во вторых, если ты к 10мс добавишь еще 10мс, то платить за железо тебе придется вдвое бОльше.
MethodHandle добавляет в районе десяти процентов. Да и суть в том, что если тебя так беспокоит цена железа, то надо выкинуть ODATA и взять какой-нибудь более экономичный протокол. Тогда даже с двухкратным приростом за железо будешь платить в 10 раз меньше.
P>·>заметь вот это: тут ворктредов нет, и оно вообще жуть тормозит по всем параметрам. P>Вообще то я сам сказал, что здесь жээс отстает где то в 5 раз. Что нового ты добавил? Я вот могу добавить — в данном примере, по твоей ссылке, ошибка — замер интерпретатора, а не джита.
Не понял, как ты отличил интерпретатор от джита?
P>Итого — в большинстве случаев джава имеет сравнимый перформанс с жээсом, кроме тех случаев, где многопоточность.
Вот тут нет многопоточности же. Код очень похожий. https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/binarytrees-java-3.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/binarytrees-node-7.html
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
P>>У тебя здесь логическая ошибка — к Си это применимо еще ширше, т.к. там полноценных типов нет и нормой является использование указателей, которые фактически int. В динамических языках весь язык состоит позволяет такие дыры. ·>Ок, пусть даже Си и ширше и вообще бардак. Но считать нормой проблемы Си и тащить такое в бэкенд — это можно обосновать лишь жоп-секьюрити.
Никто и не тащит. Из маленькой проблемы ты раздул целого слона.
·>Спасибо, что хоть признал, что это проблема. А мухослон именно в том, что тайпскрипт на платформе js. Т.е. даже если игнорировать дыры в самом ts, то всё равно проблемы js лезут из всех щелей.
"лезут изо всех щелей" — не совсем понятно, про что речь. У меня вот ничего не лезет, и у коллег ничего не лезет. Может это у тебя сложности?
У нас куча джавистов и дотнетчиков перешла на ТС, и у всех все нормально. Но ты, похоже, особенный.
P>>·>Так ведь проблема в том, что в ts оказывается Forum можно легко присвоить в Item, даже если у них структура совсем не совместимая, а вылезет проблема совсем в другом месте. P>>Проверяем твоё утверждение. Присвоим {name: string} в {name: 'something'} и видим, что твоё утверждение невалидно. ·>У тебя с логикой проблемы. Квантор существования не опровергается одним контрпримером.
У тебя нет никакого "квантора существования". Твое утверждение слишком общо "Forum можно легко присвоить в Item, даже если у них структура совсем не совместимая"
Поэтому простейшей валидации достаточно, для подтверждения этого "слишком общо"
А раз подробностей у тебя нет, то вероятнее всего примеров у тебя ровно один — про тот самый редонли.
P>>То есть, проблема всё еще в одной единственной фиче, как будто это какая то обязательная вещь. На самом деле тебе религия мешает найти тикет в гитхабе и увидеть что спроса на эту фичу нет. ·>Знатное чтиво https://github.com/microsoft/TypeScript/issues/13347
Я вижу там проголосовало ажно 180 людей и 20 каментов. За пять лет.
Вот это и есть "интерес", а точнее — его отсутствие.
И вот эту "фичу" ты мусолишь уже несколько недель.
P>>А как ты думаешь сериализатор работает? Нужно перебрать свойства рефлексией, получить значения той же рефлексией. ·>Рефлексия это инфа о типах. В js типов нет (точнее у всего один тип).
Рефлексия это гораздо больше, чем инфа о типах. И типов в жээсе гораздо больше одного.
P>>Понасоздавать всякие временные и промежуточные объекты, самому склеивать строчки, делать кучу приседаний для конверсии и тд, т.к. платформа ничего другого не умеет. В жээсе всё делается легче и проще. ·>В java ровно то же делается на HashMap/ArrayList. Нет никакой магии.
Это в каком таком мире взять филд из произвольного объекта по имени "делается на HashMap/ArrayList" ? Ты кстати в курсе, сколько стоит обращение к хештаблице?
P>>Не все вычисления такие эффективные, т.к. в жээсе хуже локальность, т.е. вместо кеша и регистров будем чаще работать с памятью. Но и в джаве есть похожая проблема — если джит компактификацию не сделает, получишь почти то же. ·>компактификация это про gc, а не про jit.
Итого — кроме как придраться к опечатке тебе добавить нечего.
P>> Во первых, медленная. Во вторых, если ты к 10мс добавишь еще 10мс, то платить за железо тебе придется вдвое бОльше. ·>MethodHandle добавляет в районе десяти процентов.
У тебя давняя проблема с таймингами Ты что с чем сравниваешь? Вызов метода по строке сравнивая с прямым вызовом — разница минимум в разы, что в дотнете, что в джаве.
Сам вызов метода занимает доли наносекунды, а если все инлайнится, то еще меньше, и слишком часто будет прямо в кеше. А что бы вызвать MethodHandle тебе его надо найти по строке, потому, как типичный реквест содержит перечень филдов, который должны быть в выхлопе. А это значит, что по именам тебе надо найти хендлы. А раз так, то обращение к хештаблице, вычисление хешкода, поколупаться внутри хештаблицы, и далее — косвенный вызов через MethodHandle. И здесь будет вагон промахов по кешу.
Вот тебе и чудовищные издержки. Для жээс ничего такого делать не надо, почти что output[odataName] = input[dtoName] Унутре будет lookup, как правило, дешовый.
> Да и суть в том, что если тебя так беспокоит цена железа, то надо выкинуть ODATA и взять какой-нибудь более экономичный протокол. Тогда даже с двухкратным приростом за железо будешь платить в 10 раз меньше.
Совет вида "Мышы-мыши, станьте ёжиками" @
Если взять другой протокол, то все задачи придется писать на нём, а это значит,что придется за рабочую силу платить в разы больше, потому что на более экономичном протоколе придется молотить в разы больше кода, и так не только на бакенде, но и у консумеров апи.
Конкурент odata, тот самый graphql не поможет — у него вечная проблема именно перформанс. И что интересно — ботлнек в том же сериализаторе.
P>>Вообще то я сам сказал, что здесь жээс отстает где то в 5 раз. Что нового ты добавил? Я вот могу добавить — в данном примере, по твоей ссылке, ошибка — замер интерпретатора, а не джита. ·>Не понял, как ты отличил интерпретатор от джита?
Цитирую себя
Может не совсем корректно, но код деоптимизируется, что видно если указать флаг --trace-deopt. Т.е. мы сравниваем деоптимизированый вариант жээс с оптимизированым джава.
P>>Итого — в большинстве случаев джава имеет сравнимый перформанс с жээсом, кроме тех случаев, где многопоточность. ·>Вот тут нет многопоточности же. Код очень похожий.
И что? Смотри цитату выше. Почему вылазит эта деоптимизация, и как её убрать, я не знаю. Могу сделать забесплатно процентов на 20-25 быстрее, минимальными телодвижениями, но деоптимизации остаются, т.е. принципиальная картина не изменится.
Здравствуйте, Pauel, Вы писали:
P>>>·>Так ведь проблема в том, что в ts оказывается Forum можно легко присвоить в Item, даже если у них структура совсем не совместимая, а вылезет проблема совсем в другом месте. P>>>Проверяем твоё утверждение. Присвоим {name: string} в {name: 'something'} и видим, что твоё утверждение невалидно. P>·>У тебя с логикой проблемы. Квантор существования не опровергается одним контрпримером. P>У тебя нет никакого "квантора существования". Твое утверждение слишком общо "Forum можно легко присвоить в Item, даже если у них структура совсем не совместимая"
"можно" — это кввантор существования. Можно присвоить, так ведь можно и не присвоить.
P>А раз подробностей у тебя нет, то вероятнее всего примеров у тебя ровно один — про тот самый редонли.
Ещё очень часто на границе с js вылазит. В случае java/c# если типы не совпадают, это грохнется на первом же присвоении Dog dog = maybecats[0]. А в ts из-за его особенностей никаких проверок типа нет и грохнутся может в произвольном месте, или тупо работать, но немного не так как ожидается.
P>>>Понасоздавать всякие временные и промежуточные объекты, самому склеивать строчки, делать кучу приседаний для конверсии и тд, т.к. платформа ничего другого не умеет. В жээсе всё делается легче и проще. P>·>В java ровно то же делается на HashMap/ArrayList. Нет никакой магии. P>Это в каком таком мире взять филд из произвольного объекта по имени "делается на HashMap/ArrayList" ?
В мире json-like сруктур.
P>Ты кстати в курсе, сколько стоит обращение к хештаблице?
Зависит от реализации и ключа. String как ключ довольно дешевый.
P>>>Не все вычисления такие эффективные, т.к. в жээсе хуже локальность, т.е. вместо кеша и регистров будем чаще работать с памятью. Но и в джаве есть похожая проблема — если джит компактификацию не сделает, получишь почти то же. P>·>компактификация это про gc, а не про jit. P>Итого — кроме как придраться к опечатке тебе добавить нечего.
Я просто не понял сути. Т.к. там ошибка на ошибке, а что ты сказать хотел — неясно. Компактификация нужна для дефрагметации кучи и помогает процу prefetch делать при последовательной обработке куска памяти, плюс под NUMA оптимизировать. Причём тут регистры? Это уже jit, ну ещё и оптимизации для многопотока и мембары всякие.
P>>> Во первых, медленная. Во вторых, если ты к 10мс добавишь еще 10мс, то платить за железо тебе придется вдвое бОльше. P>·>MethodHandle добавляет в районе десяти процентов. P>У тебя давняя проблема с таймингами Ты что с чем сравниваешь? Вызов метода по строке сравнивая с прямым вызовом — разница минимум в разы, что в дотнете, что в джаве.
Так field accessors надо кешировать и просто дёргать готовые. Иначе да, тормоза, если lookup делать каждый раз (зачем?). Это же не js, где к любому объекту внезапно можно новое поле добавить. В java/c# кешируешь accessors для каждого типа и вперёд.
P>Сам вызов метода занимает доли наносекунды, а если все инлайнится, то еще меньше, и слишком часто будет прямо в кеше. А что бы вызвать MethodHandle тебе его надо найти по строке, потому, как типичный реквест содержит перечень филдов, который должны быть в выхлопе. А это значит, что по именам тебе надо найти хендлы. А раз так, то обращение к хештаблице, вычисление хешкода, поколупаться внутри хештаблицы, и далее — косвенный вызов через MethodHandle. И здесь будет вагон промахов по кешу. P>Вот тебе и чудовищные издержки. Для жээс ничего такого делать не надо, почти что output[odataName] = input[dtoName] Унутре будет lookup, как правило, дешовый.
А lookup как работает по-твоему? Там возможно есть какие-то оптимизации, но в общем случае та же hashtable.
Если уж захочется скорости, то в java/c# можно даже кодогенерацию использовать, сводя вызовы к прямым, которые работают наносекунды.
>> Да и суть в том, что если тебя так беспокоит цена железа, то надо выкинуть ODATA и взять какой-нибудь более экономичный протокол. Тогда даже с двухкратным приростом за железо будешь платить в 10 раз меньше. P>Совет вида "Мышы-мыши, станьте ёжиками" @
Или продолжайте есть кактус... Сочувствую.
P>Если взять другой протокол, то все задачи придется писать на нём, а это значит,что придется за рабочую силу платить в разы больше, потому что на более экономичном протоколе придется молотить в разы больше кода, и так не только на бакенде, но и у консумеров апи. P>Конкурент odata, тот самый graphql не поможет — у него вечная проблема именно перформанс. И что интересно — ботлнек в том же сериализаторе.
Как я понимаю, оно микрософтом проталкивается. Ну ничего, лет 10 и выкинут в пользу новой игрушки.
P>>>Вообще то я сам сказал, что здесь жээс отстает где то в 5 раз. Что нового ты добавил? Я вот могу добавить — в данном примере, по твоей ссылке, ошибка — замер интерпретатора, а не джита. P>·>Не понял, как ты отличил интерпретатор от джита? P>Цитирую себя P>
P>Может не совсем корректно, но код деоптимизируется, что видно если указать флаг --trace-deopt. Т.е. мы сравниваем деоптимизированый вариант жээс с оптимизированым джава.
Ну т.е. jit не смог. О чём я тебе и говорил выше — простые циклы по байтбуферу — норм, а чуть сложнее — упс. Говорил же — ещё лет 5, то может доведут до ума и станет юзабельным.
P>>>Итого — в большинстве случаев джава имеет сравнимый перформанс с жээсом, кроме тех случаев, где многопоточность. P>·>Вот тут нет многопоточности же. Код очень похожий. P>И что? Смотри цитату выше. Почему вылазит эта деоптимизация, и как её убрать, я не знаю. Могу сделать забесплатно процентов на 20-25 быстрее, минимальными телодвижениями, но деоптимизации остаются, т.е. принципиальная картина не изменится.
Грустно. Человек с 10-летним опытом в технологии сдаётся на простом коде.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
P>>У тебя нет никакого "квантора существования". Твое утверждение слишком общо "Forum можно легко присвоить в Item, даже если у них структура совсем не совместимая" ·>"можно" — это кввантор существования. Можно присвоить, так ведь можно и не присвоить.
Ты продолжаешь играть в слова. Пример какой будет, или ты всё еще про readonly, который за 5 лет набрал ажно 20 каментов?
P>>А раз подробностей у тебя нет, то вероятнее всего примеров у тебя ровно один — про тот самый редонли. ·>Ещё очень часто на границе с js вылазит. В случае java/c# если типы не совпадают, это грохнется на первом же присвоении Dog dog = maybecats[0].
То есть, условно, т.к. далеко не факт, что будет именно такое присвоение. А может будет просто object или базовый класс итд.
О чем люди и пишут "Fun fact: In Java, arrays are both mutable and covariant. This is, of course, unsound."
Похоже, только ты про это не в курсе
P>>Это в каком таком мире взять филд из произвольного объекта по имени "делается на HashMap/ArrayList" ? ·>В мире json-like сруктур.
В частном случае такое может сработать, с потерей типизации, итд. В общем случае нужно таскать значения из обычного класса.
P>>Ты кстати в курсе, сколько стоит обращение к хештаблице? ·>Зависит от реализации и ключа. String как ключ довольно дешевый.
Дешевый относительно чего? Обращение к хештаблице это несколько вызовов, небольшая кучка приседаний. Как то странно — пяток-десяток примитивных операций оказываются вдруг всего на 10% больше, чем одна такая операция.
Поделись, что это за чудо такое?
P>>·>компактификация это про gc, а не про jit. P>>Итого — кроме как придраться к опечатке тебе добавить нечего. ·>Я просто не понял сути. Т.к. там ошибка на ошибке, а что ты сказать хотел — неясно. Компактификация нужна для дефрагметации кучи и помогает процу prefetch делать при последовательной обработке куска памяти, плюс под NUMA оптимизировать. Причём тут регистры? Это уже jit, ну ещё и оптимизации для многопотока и мембары всякие.
Джит отвечает за регистры, гц — за эффективную работу с кешем, компактификацию. И то, и другое в жээсе в силу особенностей реализации под капотом используется неэффективно,т.к. динамика. В джаве при определенных условиях будет ровно то же, ну чуть получше.
Поскольку компактификация местами отваливается, джава тебе не сообщает "ой, тут у нас мешанина".
Ситуация с регистрами в джаве чуть получше.
·>Так field accessors надо кешировать и просто дёргать готовые. Иначе да, тормоза, если lookup делать каждый раз (зачем?). Это же не js, где к любому объекту внезапно можно новое поле добавить. В java/c# кешируешь accessors для каждого типа и вперёд.
Доступ к такому кешу будет бесплатный, да?
P>>Вот тебе и чудовищные издержки. Для жээс ничего такого делать не надо, почти что output[odataName] = input[dtoName] Унутре будет lookup, как правило, дешовый. ·>А lookup как работает по-твоему? Там возможно есть какие-то оптимизации, но в общем случае та же hashtable.
В том то и дело, что не та же хештаблица. В общем случае именно хештаблицы не будет, т.к. слишком дорого.
·>Если уж захочется скорости, то в java/c# можно даже кодогенерацию использовать, сводя вызовы к прямым, которые работают наносекунды.
Теоретически. Одна проблема — написать такой кодогенератор задача непосильная для большинства команд, при этом он требует постоянного мейнтенанса.
P>>Совет вида "Мышы-мыши, станьте ёжиками" @ ·>Или продолжайте есть кактус... Сочувствую.
Ты же сам предлагаешь тот самый кактус. Никакой адекватно альтернативы у тебя нет.
P>>Если взять другой протокол, то все задачи придется писать на нём, а это значит,что придется за рабочую силу платить в разы больше, потому что на более экономичном протоколе придется молотить в разы больше кода, и так не только на бакенде, но и у консумеров апи. P>>Конкурент odata, тот самый graphql не поможет — у него вечная проблема именно перформанс. И что интересно — ботлнек в том же сериализаторе. ·>Как я понимаю, оно микрософтом проталкивается. Ну ничего, лет 10 и выкинут в пользу новой игрушки.
Итого — слова. Ничего конкретного. ·>Ну т.е. jit не смог. О чём я тебе и говорил выше — простые циклы по байтбуферу — норм, а чуть сложнее — упс. Говорил же — ещё лет 5, то может доведут до ума и станет юзабельным.
У тебя неадекватное экстраполирование. Вобщем, как я вижу, ты или статей начитался, или написал три строчки кода. Замеров реального приложения у тебя нет.
P>>И что? Смотри цитату выше. Почему вылазит эта деоптимизация, и как её убрать, я не знаю. Могу сделать забесплатно процентов на 20-25 быстрее, минимальными телодвижениями, но деоптимизации остаются, т.е. принципиальная картина не изменится. ·>Грустно. Человек с 10-летним опытом в технологии сдаётся на простом коде.
Ну да, надо бы отложить дела, устроиться в команду V8 и фиксануть им джыт. Ты то с куда большим опытом наверняка такое каждый день делаешь.
Здравствуйте, Pauel, Вы писали:
P>>>У тебя нет никакого "квантора существования". Твое утверждение слишком общо "Forum можно легко присвоить в Item, даже если у них структура совсем не совместимая" P>·>"можно" — это кввантор существования. Можно присвоить, так ведь можно и не присвоить. P>Ты продолжаешь играть в слова. Пример какой будет, или ты всё еще про readonly, который за 5 лет набрал ажно 20 каментов?
Это просто явная дыра в системе типов. Другая была с контра-ко-вариантностью, но это вроде закрыли.
А моя основная претензия, что внутре там всё тот же js, т.е. все эти проверки типов существуют только в момент компиляции. Т.е. ошибки с типами (особенно при наличии конверсий или|и js-кода) не локализуются, а могут валиться в любом месте или давать практически непредсказуемое поведение. Т.е. в каком-то смысле аналог порчи памяти.
P>>>А раз подробностей у тебя нет, то вероятнее всего примеров у тебя ровно один — про тот самый редонли. P>·>Ещё очень часто на границе с js вылазит. В случае java/c# если типы не совпадают, это грохнется на первом же присвоении Dog dog = maybecats[0]. P>То есть, условно, т.к. далеко не факт, что будет именно такое присвоение. А может будет просто object или базовый класс итд.
Dog это (is-a) и object, и базовый класс, т.е. это не будет ошибкой в системе типов. Т.е. если будет другое присвоение, то всё будет прекрасно работать, это не ошибка.
Иными словами, у тебя или корректное поведение, или class cast exception в конкретном месте. Очень облегчает поиск багов.
P>>>Ты кстати в курсе, сколько стоит обращение к хештаблице? P>·>Зависит от реализации и ключа. String как ключ довольно дешевый. P>Дешевый относительно чего? Обращение к хештаблице это несколько вызовов, небольшая кучка приседаний. Как то странно — пяток-десяток примитивных операций оказываются вдруг всего на 10% больше, чем одна такая операция. P>Поделись, что это за чудо такое?
Вызовы инлайнятся же. Дешевый относительно полезной работы, совершаемой программой. Сотня-другая маш-операций никакого измеримого влияния не оказывают на типичный http-запрос.
P>>>·>компактификация это про gc, а не про jit. P>>>Итого — кроме как придраться к опечатке тебе добавить нечего. P>·>Я просто не понял сути. Т.к. там ошибка на ошибке, а что ты сказать хотел — неясно. Компактификация нужна для дефрагметации кучи и помогает процу prefetch делать при последовательной обработке куска памяти, плюс под NUMA оптимизировать. Причём тут регистры? Это уже jit, ну ещё и оптимизации для многопотока и мембары всякие. P>Джит отвечает за регистры, гц — за эффективную работу с кешем, компактификацию. И то, и другое в жээсе в силу особенностей реализации под капотом используется неэффективно,т.к. динамика. В джаве при определенных условиях будет ровно то же, ну чуть получше. P>Поскольку компактификация местами отваливается, джава тебе не сообщает "ой, тут у нас мешанина". P>Ситуация с регистрами в джаве чуть получше.
Я знаю, эту мысль и пытаюсь донести. Там и gc, и с jit ситуация получше. Как минимум, банально больше человеколет вложено. Ну и сама платформа, т.к. не динамика, проще/лучше оптимизируется. Собственно поэтому нода всегда будет в догоняющих по перформансу.
P>·>Так field accessors надо кешировать и просто дёргать готовые. Иначе да, тормоза, если lookup делать каждый раз (зачем?). Это же не js, где к любому объекту внезапно можно новое поле добавить. В java/c# кешируешь accessors для каждого типа и вперёд. P> Доступ к такому кешу будет бесплатный, да?
Не дороже, чем доступ к полю в js.
P>>>Вот тебе и чудовищные издержки. Для жээс ничего такого делать не надо, почти что output[odataName] = input[dtoName] Унутре будет lookup, как правило, дешовый. P>·>А lookup как работает по-твоему? Там возможно есть какие-то оптимизации, но в общем случае та же hashtable. P>В том то и дело, что не та же хештаблица. В общем случае именно хештаблицы не будет, т.к. слишком дорого.
А какие ещё варианты по строке извлекать значение? Такую маш-инструкцию в процы ещё не завезли.
P>·>Если уж захочется скорости, то в java/c# можно даже кодогенерацию использовать, сводя вызовы к прямым, которые работают наносекунды. P>Теоретически. Одна проблема — написать такой кодогенератор задача непосильная для большинства команд, при этом он требует постоянного мейнтенанса.
Это не надо писать большинству команд. Такое надо писать только автору odata библиотеки.
P>>>Совет вида "Мышы-мыши, станьте ёжиками" @ P>·>Или продолжайте есть кактус... Сочувствую. P>Ты же сам предлагаешь тот самый кактус. Никакой адекватно альтернативы у тебя нет.
Ладно, сдаюсь. Я не теме, что за задачу решает odata и какие есть альтернативы.
P>·>Ну т.е. jit не смог. О чём я тебе и говорил выше — простые циклы по байтбуферу — норм, а чуть сложнее — упс. Говорил же — ещё лет 5, то может доведут до ума и станет юзабельным. P>У тебя неадекватное экстраполирование. Вобщем, как я вижу, ты или статей начитался, или написал три строчки кода. Замеров реального приложения у тебя нет.
Я просто говорю, что твои оценки этих бенчмарков нечестные. Ты как-то отнёс этот результат к многопоточке, хотя там ею и не пахнет, проблема на самом деле в jit.
P>>>И что? Смотри цитату выше. Почему вылазит эта деоптимизация, и как её убрать, я не знаю. Могу сделать забесплатно процентов на 20-25 быстрее, минимальными телодвижениями, но деоптимизации остаются, т.е. принципиальная картина не изменится. P>·>Грустно. Человек с 10-летним опытом в технологии сдаётся на простом коде. P>Ну да, надо бы отложить дела, устроиться в команду V8 и фиксануть им джыт. Ты то с куда большим опытом наверняка такое каждый день делаешь.
Не скажу, что каждый день такое приходится делать, но в той же java много тулзов, чтобы разобраться в поведении кода, поглядеть чем занимается gc, jit, генерированные маш-коды и т.п.
P>Вот, задал вопрос, и на него ответил разработчик V8, читай сам: P>https://stackoverflow.com/questions/72897668/deoptimizations-kill-the-performance-with-binary-trees?noredirect=1#comment128766951_72897668
Но что он там предлагает, это нарушает условие игры: "We ask that contributed programs not only give the correct result, but also use the same algorithm to calculate that result."
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>А моя основная претензия, что внутре там всё тот же js, т.е. все эти проверки типов существуют только в момент компиляции. Т.е. ошибки с типами (особенно при наличии конверсий или|и js-кода) не локализуются, а могут валиться в любом месте или давать практически непредсказуемое поведение. Т.е. в каком-то смысле аналог порчи памяти.
Ты пересказываешь байки десятилетней давности. Что такое было нормой — я такого не встречал ни на одном проекте.
P>>То есть, условно, т.к. далеко не факт, что будет именно такое присвоение. А может будет просто object или базовый класс итд. ·>Dog это (is-a) и object, и базовый класс, т.е. это не будет ошибкой в системе типов. Т.е. если будет другое присвоение, то всё будет прекрасно работать, это не ошибка. ·>Иными словами, у тебя или корректное поведение, или class cast exception в конкретном месте. Очень облегчает поиск багов.
Смешная вещь. Ты стесняешься сказать, что тебе придется написать ручной валидатор всех таких коллекций, например, потому, что в БЛ используется обобщенный код. И если тебя зареквестали список котов, пользователь не жаждет увидеть в ём собаку.
P>>Дешевый относительно чего? Обращение к хештаблице это несколько вызовов, небольшая кучка приседаний. Как то странно — пяток-десяток примитивных операций оказываются вдруг всего на 10% больше, чем одна такая операция. P>>Поделись, что это за чудо такое? ·>Вызовы инлайнятся же. Дешевый относительно полезной работы, совершаемой программой. Сотня-другая маш-операций никакого измеримого влияния не оказывают на типичный http-запрос.
Относительно абстрактного хттп запроса 10% это чудовищное количество времени. А для сериализатора будет не 10% а разы. То есть, пейлоад ты будешь отдавать не милисекунды...десятки а сотни. Что собственно и происходит. И это только сериализация.
·>Я знаю, эту мысль и пытаюсь донести. Там и gc, и с jit ситуация получше. Как минимум, банально больше человеколет вложено. Ну и сама платформа, т.к. не динамика, проще/лучше оптимизируется. Собственно поэтому нода всегда будет в догоняющих по перформансу.
Судя по бенчмаркам, джава недалеко ушла.
P>> Доступ к такому кешу будет бесплатный, да? ·>Не дороже, чем доступ к полю в js.
Наоборот. Похоже, ты ничего не знаешь о том, как устроен объект в жээсе. похожей будет только асимптотика, но вот абсолютные величины будут не в пользу кеша общего назначения.
P>>·>А lookup как работает по-твоему? Там возможно есть какие-то оптимизации, но в общем случае та же hashtable. P>>В том то и дело, что не та же хештаблица. В общем случае именно хештаблицы не будет, т.к. слишком дорого. ·>А какие ещё варианты по строке извлекать значение? Такую маш-инструкцию в процы ещё не завезли.
Все очень просто — хештаблица общего назначения крайне медленная. Если мы знаем, что именно, как и где будем хранить, то можно и нужно сделать частный случай. Что и сделано для жээса.
Можно ноду вытолкнуть в такой же режим, что бы ключи-значения хранились как в хештаблице общего назначения, и тогда получим замедление примерно в 5-10 раз.
P>>Теоретически. Одна проблема — написать такой кодогенератор задача непосильная для большинства команд, при этом он требует постоянного мейнтенанса. ·>Это не надо писать большинству команд. Такое надо писать только автору odata библиотеки.
Такой кодогенератор в целом сложнее всего одата процессинга включая серилизацию, парсинг, пайплайн, метадату итд.
ю. P>>Ты же сам предлагаешь тот самый кактус. Никакой адекватно альтернативы у тебя нет. ·>Ладно, сдаюсь. Я не теме, что за задачу решает odata и какие есть альтернативы.
graphql есть альтернатива. Намного медленнее, и менее функциональный. Зато больше обложен тулами, библиотеками итд.
·>Но что он там предлагает, это нарушает
Ты снова читаешь не то, не там, не так. Его главный поинт — что код этот есть синтетический микробенчмарк, и он подробно объясняет, что не так с кодом.
Скажем, обход-построение дерева это ровно то, чем занят сериализатор. И вот я шота не вижу, что бы жээс тут сливал. Совсем даже наоборот.
Здравствуйте, Pauel, Вы писали:
P>Ты пересказываешь байки десятилетней давности. Что такое было нормой — я такого не встречал ни на одном проекте.
Надеюсь. Но не очень верится.
P>·>Dog это (is-a) и object, и базовый класс, т.е. это не будет ошибкой в системе типов. Т.е. если будет другое присвоение, то всё будет прекрасно работать, это не ошибка. P>·>Иными словами, у тебя или корректное поведение, или class cast exception в конкретном месте. Очень облегчает поиск багов. P>Смешная вещь. Ты стесняешься сказать, что тебе придется написать ручной валидатор всех таких коллекций, например, потому, что в БЛ используется обобщенный код. И если тебя зареквестали список котов, пользователь не жаждет увидеть в ём собаку.
Не понял что за ручной валидатор и зачем. Такое впечатление, что ты мыслишь динамическими типами как в js, и пытаешься натянуть проблемы динамики в c#/java.
P>>>Дешевый относительно чего? Обращение к хештаблице это несколько вызовов, небольшая кучка приседаний. Как то странно — пяток-десяток примитивных операций оказываются вдруг всего на 10% больше, чем одна такая операция. P>>>Поделись, что это за чудо такое? P>·>Вызовы инлайнятся же. Дешевый относительно полезной работы, совершаемой программой. Сотня-другая маш-операций никакого измеримого влияния не оказывают на типичный http-запрос. P>Относительно абстрактного хттп запроса 10% это чудовищное количество времени. А для сериализатора будет не 10% а разы. То есть, пейлоад ты будешь отдавать не милисекунды...десятки а сотни. Что собственно и происходит. И это только сериализация.
Умываю руки, я не очень понимаю что происходит в odata, где там тормоза и узкое место.
P>·>Я знаю, эту мысль и пытаюсь донести. Там и gc, и с jit ситуация получше. Как минимум, банально больше человеколет вложено. Ну и сама платформа, т.к. не динамика, проще/лучше оптимизируется. Собственно поэтому нода всегда будет в догоняющих по перформансу. P>Судя по бенчмаркам, джава недалеко ушла.
В 5 раз по некоторым бенчам...
P>>>·>А lookup как работает по-твоему? Там возможно есть какие-то оптимизации, но в общем случае та же hashtable. P>>>В том то и дело, что не та же хештаблица. В общем случае именно хештаблицы не будет, т.к. слишком дорого. P>·>А какие ещё варианты по строке извлекать значение? Такую маш-инструкцию в процы ещё не завезли. P>Все очень просто — хештаблица общего назначения крайне медленная. Если мы знаем, что именно, как и где будем хранить, то можно и нужно сделать частный случай. Что и сделано для жээса. P>Можно ноду вытолкнуть в такой же режим, что бы ключи-значения хранились как в хештаблице общего назначения, и тогда получим замедление примерно в 5-10 раз.
Так как я понимаю, когда имя поля тебе приходит из запроса, то никакого другого варианта, кроме как поискать по хеш-таблице у тебя нет.
Более того. Если так подумать, odata схема, как я понимаю, доступна во время сборки проекта. Можно генерить код, вычислять perfect hash, чтобы потом извлекать нужные поля максимально возможно быстро.
P>>>Ты же сам предлагаешь тот самый кактус. Никакой адекватно альтернативы у тебя нет. P>·>Ладно, сдаюсь. Я не теме, что за задачу решает odata и какие есть альтернативы. P>graphql есть альтернатива. Намного медленнее, и менее функциональный. Зато больше обложен тулами, библиотеками итд.
Про него тоже ничего не знаю.
P>·>Но что он там предлагает, это нарушает P>Ты снова читаешь не то, не там, не так. Его главный поинт — что код этот есть синтетический микробенчмарк, и он подробно объясняет, что не так с кодом.
Так это очевидно, что синтетический, там все бенчи синтетические. Но ты занимаешься черри-пикингом фактов. Те бенчмарки, где нода не сливает, ты воспринимаешь как само собой разумеется, бенчмарк хороший, а тем где она сливает, там внезапно бенчмарк плохой.
Ок подытожим. Нода — хорошая, но почему-то сливает.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
P>>·>Иными словами, у тебя или корректное поведение, или class cast exception в конкретном месте. Очень облегчает поиск багов. P>>Смешная вещь. Ты стесняешься сказать, что тебе придется написать ручной валидатор всех таких коллекций, например, потому, что в БЛ используется обобщенный код. И если тебя зареквестали список котов, пользователь не жаждет увидеть в ём собаку. ·>Не понял что за ручной валидатор и зачем. Такое впечатление, что ты мыслишь динамическими типами как в js, и пытаешься натянуть проблемы динамики в c#/java.
Элементарно — вот ты написал багу, когда собака попадает в массив котов, что пролетает в выхлоп. Где искать будешь? Полагаю начнешь везде лепить Cat c = array[i] ?
P>>Относительно абстрактного хттп запроса 10% это чудовищное количество времени. А для сериализатора будет не 10% а разы. То есть, пейлоад ты будешь отдавать не милисекунды...десятки а сотни. Что собственно и происходит. И это только сериализация. ·>Умываю руки, я не очень понимаю что происходит в odata, где там тормоза и узкое место.
А у меня ощущение, что ты снова таймингов не понимаешь, сколко времени на что расходуется, потому тебе видится решениям магическая мапа.
P>>Судя по бенчмаркам, джава недалеко ушла. ·>В 5 раз по некоторым бенчам...
Всего в 4, если исправить багу в бенчмарке. А по остальным от 10 до 50%, всего.
P>>Можно ноду вытолкнуть в такой же режим, что бы ключи-значения хранились как в хештаблице общего назначения, и тогда получим замедление примерно в 5-10 раз. ·>Так как я понимаю, когда имя поля тебе приходит из запроса, то никакого другого варианта, кроме как поискать по хеш-таблице у тебя нет.
Снова магия полезла. Это у тебя в джаве другого варианта нет. А у меня — есть.
·>Более того. Если так подумать, odata схема, как я понимаю, доступна во время сборки проекта. Можно генерить код, вычислять perfect hash, чтобы потом извлекать нужные поля максимально возможно быстро.
Я ж говорю — сложность выше, чем сложность всего одата фремворка
P>>Ты снова читаешь не то, не там, не так. Его главный поинт — что код этот есть синтетический микробенчмарк, и он подробно объясняет, что не так с кодом. ·>Так это очевидно, что синтетический, там все бенчи синтетические. Но ты занимаешься черри-пикингом фактов. Те бенчмарки, где нода не сливает, ты воспринимаешь как само собой разумеется, бенчмарк хороший, а тем где она сливает, там внезапно бенчмарк плохой.
Если ты внимательно будешь читать, то узнаешь, что я в самом начале отметил отставание именно в этом тесте. А вот тебе похоже всё не нравится, что не в пользу джавы.
Здравствуйте, Pauel, Вы писали:
P>>>Смешная вещь. Ты стесняешься сказать, что тебе придется написать ручной валидатор всех таких коллекций, например, потому, что в БЛ используется обобщенный код. И если тебя зареквестали список котов, пользователь не жаждет увидеть в ём собаку. P>·>Не понял что за ручной валидатор и зачем. Такое впечатление, что ты мыслишь динамическими типами как в js, и пытаешься натянуть проблемы динамики в c#/java. P>Элементарно — вот ты написал багу, когда собака попадает в массив котов, что пролетает в выхлоп. Где искать будешь? Полагаю начнешь везде лепить Cat c = array[i] ?
Это надо очень постараться написать такую багу. Т.к. в c#/java голые массивы используются только в низкоуровневом коде и компилятор, и ide предупреждения пишут. Т.е. в прикладном коде такого тупо не будет.
В общем, я не понимаю эту проблему в мире статической типизации. Нет такой проблемы в принципе, имхо.
P>>>Можно ноду вытолкнуть в такой же режим, что бы ключи-значения хранились как в хештаблице общего назначения, и тогда получим замедление примерно в 5-10 раз. P>·>Так как я понимаю, когда имя поля тебе приходит из запроса, то никакого другого варианта, кроме как поискать по хеш-таблице у тебя нет. P>Снова магия полезла. Это у тебя в джаве другого варианта нет. А у меня — есть.
Ты опять в терминах json думаешь, опустись уровнем ниже. Причём тут java? В cpu тупо нет такой инструкции. Или у тебя квантовый компьютер, алгоритм Гровера используешь?
P>·>Более того. Если так подумать, odata схема, как я понимаю, доступна во время сборки проекта. Можно генерить код, вычислять perfect hash, чтобы потом извлекать нужные поля максимально возможно быстро. P>Я ж говорю — сложность выше, чем сложность всего одата фремворка
Я имел в виду, что генерация — часть фреймворка.
P>>>Ты снова читаешь не то, не там, не так. Его главный поинт — что код этот есть синтетический микробенчмарк, и он подробно объясняет, что не так с кодом. P>·>Так это очевидно, что синтетический, там все бенчи синтетические. Но ты занимаешься черри-пикингом фактов. Те бенчмарки, где нода не сливает, ты воспринимаешь как само собой разумеется, бенчмарк хороший, а тем где она сливает, там внезапно бенчмарк плохой. P>Если ты внимательно будешь читать, то узнаешь, что я в самом начале отметил отставание именно в этом тесте. А вот тебе похоже всё не нравится, что не в пользу джавы.
Ты сказал, что причина мультипоток, а на самом деле — jit.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Как аргумент как раз таки нормально — у каждого своя точка зрения, каждый говорит — "я считаю/вижу/думаю что..."
