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

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 или базовый класс итд.
О чем люди и пишут "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 и фиксануть им джыт. Ты то с куда большим опытом наверняка такое каждый день делаешь.

Вот, задал вопрос, и на него ответил разработчик V8, читай сам:
https://stackoverflow.com/questions/72897668/deoptimizations-kill-the-performance-with-binary-trees?noredirect=1#comment128766951_72897668