Сообщение Re[52]: Поругайте TypeScript/node.js от 08.07.2022 8:58
Изменено 08.07.2022 9:03 Pauel
Re[52]: Поругайте TypeScript/node.js
Здравствуйте, ·, Вы писали:
P>>У тебя нет никакого "квантора существования". Твое утверждение слишком общо "Forum можно легко присвоить в Item, даже если у них структура совсем не совместимая"
·>"можно" — это кввантор существования. Можно присвоить, так ведь можно и не присвоить.
Ты продолжаешь играть в слова. Пример какой будет, или ты всё еще про readonly, который за 5 лет набрал ажно 20 каментов?
P>>А раз подробностей у тебя нет, то вероятнее всего примеров у тебя ровно один — про тот самый редонли.
·>Ещё очень часто на границе с js вылазит. В случае java/c# если типы не совпадают, это грохнется на первом же присвоении Dog dog = maybecats[0].
То есть, условно, т.к. далеко не факт, что будет именно такое присвоение. А может будет просто object или базовый класс итд.
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 и фиксануть им джыт. Ты то с куда большим опытом наверняка такое каждый день делаешь.
P>>У тебя нет никакого "квантора существования". Твое утверждение слишком общо "Forum можно легко присвоить в Item, даже если у них структура совсем не совместимая"
·>"можно" — это кввантор существования. Можно присвоить, так ведь можно и не присвоить.
Ты продолжаешь играть в слова. Пример какой будет, или ты всё еще про readonly, который за 5 лет набрал ажно 20 каментов?
P>>А раз подробностей у тебя нет, то вероятнее всего примеров у тебя ровно один — про тот самый редонли.
·>Ещё очень часто на границе с js вылазит. В случае java/c# если типы не совпадают, это грохнется на первом же присвоении Dog dog = maybecats[0].
То есть, условно, т.к. далеко не факт, что будет именно такое присвоение. А может будет просто object или базовый класс итд.
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 и фиксануть им джыт. Ты то с куда большим опытом наверняка такое каждый день делаешь.
Re[52]: Поругайте TypeScript/node.js
Здравствуйте, ·, Вы писали:
P>>У тебя нет никакого "квантора существования". Твое утверждение слишком общо "Forum можно легко присвоить в Item, даже если у них структура совсем не совместимая"
·>"можно" — это кввантор существования. Можно присвоить, так ведь можно и не присвоить.
Ты продолжаешь играть в слова. Пример какой будет, или ты всё еще про readonly, который за 5 лет набрал ажно 20 каментов?
P>>А раз подробностей у тебя нет, то вероятнее всего примеров у тебя ровно один — про тот самый редонли.
·>Ещё очень часто на границе с js вылазит. В случае java/c# если типы не совпадают, это грохнется на первом же присвоении Dog dog = maybecats[0].
То есть, условно, т.к. далеко не факт, что будет именно такое присвоение. А может будет просто object или базовый класс итд.
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 и фиксануть им джыт. Ты то с куда большим опытом наверняка такое каждый день делаешь.
Вот, задал вопрос, и на него ответил разработчик V8, читай сам:
https://stackoverflow.com/questions/72897668/deoptimizations-kill-the-performance-with-binary-trees?noredirect=1#comment128766951_72897668
P>>У тебя нет никакого "квантора существования". Твое утверждение слишком общо "Forum можно легко присвоить в Item, даже если у них структура совсем не совместимая"
·>"можно" — это кввантор существования. Можно присвоить, так ведь можно и не присвоить.
Ты продолжаешь играть в слова. Пример какой будет, или ты всё еще про readonly, который за 5 лет набрал ажно 20 каментов?
P>>А раз подробностей у тебя нет, то вероятнее всего примеров у тебя ровно один — про тот самый редонли.
·>Ещё очень часто на границе с js вылазит. В случае java/c# если типы не совпадают, это грохнется на первом же присвоении Dog dog = maybecats[0].
То есть, условно, т.к. далеко не факт, что будет именно такое присвоение. А может будет просто object или базовый класс итд.
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 и фиксануть им джыт. Ты то с куда большим опытом наверняка такое каждый день делаешь.
Вот, задал вопрос, и на него ответил разработчик V8, читай сам:
https://stackoverflow.com/questions/72897668/deoptimizations-kill-the-performance-with-binary-trees?noredirect=1#comment128766951_72897668