Здравствуйте, netch80, Вы писали:
N>Ну да, явовский компилятор не умеет резать функции на куски по границе await (точнее, он вообще await не знает). Но кто ставит такие короткие задачи в асинхронное выполнение и зачем?
Здравствуйте, Nuzhny, Вы писали:
N>Улыбнуло. Эту фишку от C# рекламировали с самой первой версии, типа оно будет само оптимизироваться при запуске на целевой платформе под эту самую платформу.
Нет, не эту. Речь про то что ты сам можешь написать код, компилирующийся в итоге в AVX инструкции при их наличии, а не про автоматическую универсальную оптимизацию.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, netch80, Вы писали:
N>>Ну да, явовский компилятор не умеет резать функции на куски по границе await (точнее, он вообще await не знает). Но кто ставит такие короткие задачи в асинхронное выполнение и зачем?
НС>https://en.wikipedia.org/wiki/Granularity_(parallel_computing)#Fine-grained_parallelism
Классная мода — кинуть рандомную ссылку и не объяснить, как она отвечает на вопрос.
Зато типа ответил, да.
Здравствуйте, hi_octane, Вы писали:
_>К примеру ни kotlin ни java вообще насколько я понимаю, не позволяют писать, alloc-free асинхронный код на future/task. В современном .NET это ещё с приседаниями, но уже можно делать. Более того, можно написать библиотеку которая будет отдавать клиенту alloc-free tasks, и при этом клиент сможет её использовать вообще не заметив отличий от обычной.
Пересобрать клиента все же придется. JIT вроде пока не умеет преобразовывать Task в ValueTask.
Здравствуйте, Sharov, Вы писали:
_>>Современный высокопроизводительный код тоже делится на пару составляющих — возможность писать числодробильный код, и возможность писать эффективный многопоточный код. S>Можно пару нововведений и оптимизации для числодробилок?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, netch80, Вы писали:
N>>Классная мода — кинуть рандомную ссылку и не объяснить, как она отвечает на вопрос. N>>Зато типа ответил, да.
НС>Она не рандомная, она прямо отвечает зачем может потребоваться мелкая нарезка задач на куски.
Важно не "зачем может потребоваться" в какой-то там теории, а какой из этого реальный выигрыш.
А вот его ещё надо доказать, вместе с тем, зачем проектировать с такими мелкими задачами.
Здравствуйте, VladCore, Вы писали:
VC>>>А JIT в джаве умеет SSE/AVX на ксеонах и NEON на армах? .NET Core 3.1 LTS умеет на ксеонах, а .NET Core 5.0 preview умеет и NEON на армах. __>>конечно умеет. jvm поддерживает AVX в полной мере. вы угораете надо мной что ли ? VC>повторюсь про performance VC>А сколько латенси у await в джаве на старом ксеоне 2 Ггц? В .NET — одна микросекунда вот в таком коде:
Мериться микрооптимизациями и синтаксическими конструкциями это круто только в садике. Хочется чего-то более реальное увидеть. Про успех lmax уже лет 20 известно. А вот c# всё обещают и обещают... Вот одно
Здравствуйте, hi_octane, Вы писали:
_>Современный высокопроизводительный код тоже делится на пару составляющих — возможность писать числодробильный код, и возможность писать эффективный многопоточный код.
вы тут много чего написали (и наверное правильно) но я бы хотел адресовать ваше внимание на производительности виртуальных машин c# и hotspot jvm под нагрузкой.
и спросить себя почему таки jvm гораздо более производительный под нагрузкой чем си щарп и пхп
тн числодробильный код может эффективно писаться только на С++ и любые потуги писать что то на vm сделанных индузами просто смешны. что касается эффективного многопоточного кода то java просто эталон здесь (с java memory model в том числе)
_>Небольшой знаток kotlin, но когда смотрел его последний раз — например вменяемого linq там не было.
это ужасное поделие индузов не нужно. зачем это? все эти попытки МС переизобрести sql вместо того чтобы использовать вменяемое api для работы с коллекциями просто жалки. ну зачем вам уродливое подобие скул в вашем коде вообще?
__>>вы сказали — "если надо получить стабильное решение задачи и быстро то современный шарп имеет сотню очков форы". в чем это проявляется? _>Долгое время программируя на C#, как и на других языках, был некий tradeoff. Что-то типа "тут используем весь доступный синтаксический сахар, пусть тормозит, но что-то зарелизим уже завтра" vs "тут надо заморочиться, вспомнить кучу глав из Writing High Perf .NET Code, и потом профайлером".
так а что они там подкручивают если сама vm очень слабенькая? если архитектура vm по умолчанию очень слабая что можно сделать в общем? что там индуз Панкай оптимизирует с танцами и плясками?
Здравствуйте, ·, Вы писали:
·>Мериться микрооптимизациями и синтаксическими конструкциями это круто только в садике. Хочется чего-то более реальное увидеть. Про успех lmax уже лет 20 известно. А вот c# всё обещают и обещают... Вот одно
_>>Небольшой знаток kotlin, но когда смотрел его последний раз — например вменяемого linq там не было. __>это ужасное поделие индузов не нужно. зачем это? все эти попытки МС переизобрести sql вместо того чтобы использовать вменяемое api для работы с коллекциями просто жалки. ну зачем вам уродливое подобие скул в вашем коде вообще?
SQL-подобный синтаксис можно и не использовать, ничего при этом не теряя, linq не про это. Основной бенефит от linq — это построение expression tree, которые доступны в рантайме, что позволяет действительно удобно работать с СУБД. Например, можно в IDE вместе с поддержкой интеллисенса, выводом типов и ошибками компиляции писать код типа "users.Where(user => user.Age > 18).Select(user => user.Name)", а этот код в рантайме преобразуется в SQL запрос вида "SELECT Name FROM Users WHERE Age > p_arg1"
Здравствуйте, mrTwister, Вы писали:
T>SQL-подобный синтаксис можно и не использовать, ничего при этом не теряя, linq не про это. Основной бенефит от linq — это построение expression tree, которые доступны в рантайме, что позволяет действительно удобно работать с СУБД. Например, можно в IDE вместе с поддержкой интеллисенса, выводом типов и ошибками компиляции писать код типа "users.Where(user => user.Age > 18).Select(user => user.Name)", а этот код в рантайме преобразуется в SQL запрос вида "SELECT Name FROM Users WHERE Age > p_arg1"
основной бенефит этого поделия был продать стаду баранов сикуэль сервер удачно купленный у сайбаса.
а теперь этот сикуэль сервер вообще никому не нужен а вы все еще тащите сюда этот мертворожденный индуззский выблев
си щарп программисты вообще слышали там про domain driven design? все со своим сикуэлем еще носятся. как в лихих девяностых
Здравствуйте, VladCore, Вы писали:
VC>·>Мериться микрооптимизациями и синтаксическими конструкциями это круто только в садике. Хочется чего-то более реальное увидеть. Про успех lmax уже лет 20 известно. А вот c# всё обещают и обещают... Вот одно
из последних, но опять куда-то пропало. VC>я тебя помню. ты опять не понимаешь о чем пишешь — никто тут микрооптимизациями не меряется. смотри внимательней.
Объясни тогда. Я у тебя увидел заявление о крутом времени выполнения одной строчки кода (т.е. микрооптимизация) и замечательный и такой прям весь необходимый await (синтаксическая конструкция). Что я не так понял?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, a_g_99, Вы писали:
T>>А с чего ты взял, что jvm производительнее под нагрузкой, чем dotnet? __>потому что я знаю как работает hotspot jvm и C# vm в отличии от си щарп программистов которые читают статеечки и смотрят видюшки про линку
Вот на этом месте я попрошу вас пояснить про популярность Ruby, Python и Node.js при такой высокой производительности JVM. А заодно и рассказать, для чего тогда выкатили Go и рекламируют его из каждого утюга.
Не производительностью всё оканчивается.
PS: вообще этот тред получился на редкость хорошей иллюстрацией к эффекту Даннинга-Крюгера. Люди хамят на ровном месте (и вы тоже) и пишут всякую ерунду, не найдя разумных доводов.
Здравствуйте, Слава, Вы писали:
T>>>А с чего ты взял, что jvm производительнее под нагрузкой, чем dotnet? С>Не производительностью всё оканчивается.
Он отвечал на конкретный вопрос "jvm производительнее под нагрузкой, чем dotnet?", а ты тут приплёл Ruby.
С>PS: вообще этот тред получился на редкость хорошей иллюстрацией к эффекту Даннинга-Крюгера. Люди хамят на ровном месте (и вы тоже) и пишут всякую ерунду, не найдя разумных доводов.
А ты просто пофлеймить?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Здравствуйте, Слава, Вы писали:
T>>>>А с чего ты взял, что jvm производительнее под нагрузкой, чем dotnet? С>>Не производительностью всё оканчивается. ·>Он отвечал на конкретный вопрос "jvm производительнее под нагрузкой, чем dotnet?", а ты тут приплёл Ruby.
С>>PS: вообще этот тред получился на редкость хорошей иллюстрацией к эффекту Даннинга-Крюгера. Люди хамят на ровном месте (и вы тоже) и пишут всякую ерунду, не найдя разумных доводов. ·>А ты просто пофлеймить?
Здравствуйте, a_g_99, Вы писали:
__>основной бенефит этого поделия был продать стаду баранов сикуэль сервер удачно купленный у сайбаса. Linq не имеет никакого отношения к SQL серверу. Linq фреймворки поддерживают кучу разных хранилищ данных. При чем ту SQL сервер?
__>си щарп программисты вообще слышали там про domain driven design? все со своим сикуэлем еще носятся. как в лихих девяностых DDD и SQL — это ортогональные понятия
Здравствуйте, a_g_99, Вы писали:
__>потому что я знаю как работает hotspot jvm и C# vm в отличии от си щарп программистов которые читают статеечки и смотрят видюшки про линку
Ага, "потому что я знаю" — бронебойный аргумент, идеально подходит для любой чуши.
