__>основной бенефит этого поделия был продать стаду баранов сикуэль сервер удачно купленный у сайбаса. __>а теперь этот сикуэль сервер вообще никому не нужен а вы все еще тащите сюда этот мертворожденный индуззский выблев
__>хотел бы задать вопрос экзистенциальный
__>вы сказали — "если надо получить стабильное решение задачи и быстро то современный шарп имеет сотню очков форы". в чем это проявляется?
это не экзистенциальный вопрос
это почесать языками
выбор языка в формате "я померял у кого длиннее и выучил победителя" происходит редко
одни покажут тесты где java быстрее, другие — где c#, и все с довольным видом пойдут писать на своем языке на котором на самом деле пишут потому что когда-то работу на нем предложили — ну и попали в колею
а контора, в которой вы это делаете попала в колею из-за интеграции с каким-то существующим кодом, с которым было удобнее интегрироваться на java или, соответственно, c#
количество языков, которые я в какой-то степени освоил потому что они в какой-то метрике кроют остальных как бык овцу — наверное, десятка полтора
и совершенно уверен, что у вас их не меньше, но толку от этого мало — как пишем на том, что и раньше в резюме было написано, так и будем писать, изредка попадая в свежую колею нового языка, быстро завоевывающего популярность
Здравствуйте, a_g_99, Вы писали:
>это ужасное поделие индузов не нужно. зачем это? все эти попытки МС переизобрести sql вместо того чтобы использовать вменяемое api для работы с коллекциями просто жалки. ну зачем вам уродливое подобие скул в вашем коде вообще? >что там индуз Панкай оптимизирует с танцами и плясками?
__>вы тут много чего написали (и наверное правильно)
Да написал много. И понимал что иду на, возможно, фатальный риск Ведь в священных войнах каждое лишнее слово это дополнительный шанс оппоненту прикопаться, найти косяк, и отбросить всё, кроме найденного косяка.
__>но я бы хотел адресовать ваше внимание на производительности виртуальных машин c# и hotspot jvm под нагрузкой.
Hotspot JVM безусловно очень умный, но огромная часть его наворотов вынужденная — из-за родовых болезней Java. По опыту _моих_ проектов, при оптимизации производительности мы прежде всего смотрим на алгоритмическую сложность в узких местах, затем (или параллельно) на нагрузку на GC и memory traffic. До вопросов "что же там нагенерил JIT что оно так тормозит" дело доходит ну просто в редчайших случаях.
Кроме того я не рассматриваю одну лишь VM. Потому что мы всегда пишем на связке Язык-VM. Современный C# имеет много встроенных в язык возможностей минимизировать нагрузку на GC. Писать в стиле zero-copy и alloc-free в 2020-м на C# относительно просто только добавьте наконец варнинг на defensive copy, гады!.
Для JVM же проблема ]inplace, zero-copy каста даже массива интов в массив байт, насколько я могу судить по SO, до сих пор не решена. А с другой стороны у нас C#, где это вообще не проблема для произвольных пользовательских структур (без ссылок на управляемые объекты).
Ну а под нагрузкой — чего я только не видел под нагрузкой на JVM, когда писал на scala. И паузы на кучу секунду, и "пилу" когда потребление CPU скачет от 5 до 99% на разных ядрах, при равномерном потоке входящих пакетов, и т.п. Т.е. я не особо верю что без поддержки со стороны языка даже самый гениальный хотспот сравнится с кодом в котором изначально используется меньше буферов, изначально временные объекты создаются на стеке, и т.д.
Ну и поскольку я при любом раскладе буду для скептиков недостаточно убедителен — вот пост человека про работу "под нагрузкой" с ycombinator (часть большого обсуждения по нашей теме). То обсуждение от 2017-го года, и уверяю, сейчас в вопросе производительности всё стало ещё лучше чем было тогда.
__>тн числодробильный код может эффективно писаться только на С++ и любые потуги писать что то на vm сделанных индузами просто смешны. что касается эффективного многопоточного кода то java просто эталон здесь (с java memory model в том числе)
Я не согласен с тем что java, или вообще кто-то или что-то, может быть "просто эталон". Например повсеместное движение от Threads в сторону Tasks/Promises/Futures очень сильно снижает потребность в примитивах синхронизации (для прикладного программиста), по сравнению с, допустим, 2005-м годом. А библиотечный код обеих VM вылизывается и там и там настолько, что всё упирается в конкретный процессор, с его, процессора, memory model.
В интернетах есть например такой сайт с микробенчмарками, и там регулярно обновляются версии Core VM и Hotspot. Заодно можно сравнить в попугаях с C++. Ну а на нашем форуме разные чудеса демонстрирует Sinclair
, заодно можно посмотреть как каскадёры могут использовать Linq.
__>это ужасное поделие индузов не нужно. зачем это? все эти попытки МС переизобрести sql вместо того чтобы использовать вменяемое api для работы с коллекциями просто жалки. ну зачем вам уродливое подобие скул в вашем коде вообще?
Ну во-первых потому что типичный C# запрос с парочкой let написать без linq конкретно сложнее. То что выглядит на linq тупо, просто, и максимально читабельно, в записи цепочками методов превращается в лапшу. Собственно про то нужен linq или нет, и что он даёт, копья были поломаны так давно, что интернет почти забыл Но в веб архиве кое что сохранилось.
Второе — у меня уже достаточно много проектов в которых работа с базой не подразумевает серьёзной серверной логики, хранимок и т.п. Нет каких-то распределённых транзакций. Надо просто чего-то ложить в несколько таблиц, а составляет по БД отчёты уже другое приложение. И тут связка linq + linq2db это простое и проверенное решение, которое тащит.
__>так а что они там подкручивают если сама vm очень слабенькая? если архитектура vm по умолчанию очень слабая что можно сделать в общем? что там индуз Панкай оптимизирует с танцами и плясками?
Чтобы мы могли содержательно продолжать беседу, было бы неплохо договориться о размерностях сил vm. Потому что в лошадиных силах цифры одни, а в ньютонах надо ещё делить на метры в секунду.
Здравствуйте, Sharov, Вы писали: S>Можно пару нововведений и оптимизации для числодробилок? Речь о языке(сахаре) или о CLR?
Обо всём. Там и язык и CLR и JIT допилили.
Мои любимые — SIMD-интринсики. Т.е. я могу вручную оптимизировать код под AVX, не полагаясь на магию встроенного оптимизатора.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, mrTwister, Вы писали:
_>>>Небольшой знаток kotlin, но когда смотрел его последний раз — например вменяемого linq там не было. __>>это ужасное поделие индузов не нужно. зачем это? все эти попытки МС переизобрести sql вместо того чтобы использовать вменяемое api для работы с коллекциями просто жалки. ну зачем вам уродливое подобие скул в вашем коде вообще? 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"
Ну т.е. ты тут по сути подтверждаешь слова своего оппонента, говоря что оригинальный (для работы с коллекциями) Linq никому не нужен, а имеют смысл исключительно вариации на тему linq2db, берущие от Linq expression tree и конвертирующие их в настоящий sql для настоящих СУБД.
Здравствуйте, alex_public, Вы писали:
_>Ну т.е. ты тут по сути подтверждаешь слова своего оппонента, говоря что оригинальный (для работы с коллекциями) Linq никому не нужен, а имеют смысл исключительно вариации на тему linq2db, берущие от Linq expression tree и конвертирующие их в настоящий sql для настоящих СУБД.
Как раз оригинальный (для работы с коллекциями) Linq используется везде при работе с коллекциями напрополую.
Для элементарного Where вместо foreach , List. Или группировки, соединения. Это упрощает не только написание, но и читабельность кода
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, alex_public, Вы писали:
_>Ну т.е. ты тут по сути подтверждаешь слова своего оппонента, говоря что оригинальный (для работы с коллекциями) Linq никому не нужен, а имеют смысл исключительно вариации на тему linq2db, берущие от Linq expression tree и конвертирующие их в настоящий sql для настоящих СУБД.
Не совсем. Во-первых, у оппонента была претензия к SQL-подобному синтаксису, но никто и не заставляет использовать SQL-подобный синтаксис, лично я предпочитаю явно вызывать extension методы. Это чертовски удобно, так работать удобнее чем в java, но это все-таки синтаксический сахар, который принципиально ничего не меняет. А вот когда дело доходит до expression trees, то это уже принципиально иной уровень, это другая недоступная из java (да и из остальных mainstream языков) парадигма.
Здравствуйте, mrTwister, Вы писали:
_>>Ну т.е. ты тут по сути подтверждаешь слова своего оппонента, говоря что оригинальный (для работы с коллекциями) Linq никому не нужен, а имеют смысл исключительно вариации на тему linq2db, берущие от Linq expression tree и конвертирующие их в настоящий sql для настоящих СУБД. T>Не совсем. Во-первых, у оппонента была претензия к SQL-подобному синтаксису, но никто и не заставляет использовать SQL-подобный синтаксис, лично я предпочитаю явно вызывать extension методы. Это чертовски удобно, так работать удобнее чем в java, но это все-таки синтаксический сахар, который принципиально ничего не меняет. А вот когда дело доходит до expression trees, то это уже принципиально иной уровень, это другая недоступная из java (да и из остальных mainstream языков) парадигма.
Во-первых создание и использование деревьев выражений вполне себе часто встречается в mainstream языках. Более того, вокруг этого даже построено множество сложных библиотек, реализующих различные DSL'и (далеко не только SQL).
Во-вторых к самой идее генерировать SQL по деревьям выражений в коде естественно никаких претензий быть не может — мы тут получаем сразу множество различных плюсов. Есть определённый набор претензий к реализации этой идеи в .net (т.к. некоторые особенности деревьев выражений linq портят производительность), но к самой идее вопросов думаю ни у кого нет. Так что не очень понятно с чего ты стал защищать мысль, с которой и так все согласны.
И в третьих, твой оппонент говорил именно о применение Linq к коллекциям, а не о генерации чего-то по деревьям выражений. И вот в таком применение Linq очевидно не самый лучший инструмент. Причём речь естественно не о синтаксическом сахаре, а именно о базовой архитектуре — IEnumeration и набору функций (а вот этот набор уже является следствием подобия бухгалтерскому инструменту под названием SQL).
Здравствуйте, alex_public, Вы писали: _>И в третьих, твой оппонент говорил именно о применение Linq к коллекциям, а не о генерации чего-то по деревьям выражений. И вот в таком применение Linq очевидно не самый лучший инструмент. Причём речь естественно не о синтаксическом сахаре, а именно о базовой архитектуре — IEnumeration и набору функций (а вот этот набор уже является следствием подобия бухгалтерскому инструменту под названием SQL).
Ок, давайте поговорим о наборе функций. Напомните, чего вам не хватает в "базовой архитектуре" для IEnumerable<>?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, alex_public, Вы писали:
_>Во-первых создание и использование деревьев выражений вполне себе часто встречается в mainstream языках. Более того, вокруг этого даже построено множество сложных библиотек, реализующих различные DSL'и (далеко не только SQL).
Все-таки у linq есть поддержка компилятора, т.е. встроен в язык, а у этих библиотек нет.
_>Есть определённый набор претензий к реализации этой идеи в .net (т.к. некоторые особенности деревьев выражений linq портят производительность),
Здравствуйте, vdimas, Вы писали:
T>>ValueTask (асинхронный код без аллокаций) V>Не совсем без аллокаций, просто позволяет переиспользовать task-like объекты.
В каком месте ValueTask обязательно порождает аллокации? И при чем тут переиспользование, если речь про замены классов на структуры? Моя твоя не понимай.
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, alex_public, Вы писали:
_>>Во-первых создание и использование деревьев выражений вполне себе часто встречается в mainstream языках. Более того, вокруг этого даже построено множество сложных библиотек, реализующих различные DSL'и (далеко не только SQL).
S>Все-таки у linq есть поддержка компилятора, т.е. встроен в язык, а у этих библиотек нет.
An automatic query optimizer-compiler for Sequential and Parallel LINQ. LinqOptimizer compiles declarative LINQ queries into fast loop-based imperative code. The compiled code has fewer virtual calls and heap allocations, better data locality and speedups of up to 15x
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Sharov, Вы писали:
_>>Во-первых создание и использование деревьев выражений вполне себе часто встречается в mainstream языках. Более того, вокруг этого даже построено множество сложных библиотек, реализующих различные DSL'и (далеко не только SQL). S>Все-таки у linq есть поддержка компилятора, т.е. встроен в язык, а у этих библиотек нет.
С учётом того как встроено, то лучше уж была бы библиотека, а не такая кривизна.
_>>Есть определённый набор претензий к реализации этой идеи в .net (т.к. некоторые особенности деревьев выражений linq портят производительность), S>Какие особенности?
Необходимость создавать дерево, обходить его с помощью рефлексии и генерировать нужный нам код при каждом вызове. Как минимум это должно было бы происходить один раз при старте приложения, а по нормальному вообще на стадии компиляции (с помощью метапрограммирования и статической интроспекции).
Здравствуйте, Sinclair, Вы писали:
_>>И в третьих, твой оппонент говорил именно о применение Linq к коллекциям, а не о генерации чего-то по деревьям выражений. И вот в таком применение Linq очевидно не самый лучший инструмент. Причём речь естественно не о синтаксическом сахаре, а именно о базовой архитектуре — IEnumeration и набору функций (а вот этот набор уже является следствием подобия бухгалтерскому инструменту под названием SQL). S>Ок, давайте поговорим о наборе функций. Напомните, чего вам не хватает в "базовой архитектуре" для IEnumerable<>?
Ой, ну вот уж с тобой я точно не буду дискутировать на эту тему. Просто потому что мы это уже делали и очень подробно, с примерами кода и т.п., обсудили это всё. И ты даже вполне себе согласился с большинством моих примеров. Странно, что ты забыл это и начинаешь по второму кругу. Если так и не вспомнишь, то я постараюсь найти на форуме ту темку и кинуть сюда ссылку на неё. Помнится там должны быть такие ключевые слова: произвольный доступ, двоичный поиск, рекурсии, двухмерные массивы (и их свёртки с ядром) и т.д.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Sharov, Вы писали:
_>>>Во-первых создание и использование деревьев выражений вполне себе часто встречается в mainstream языках. Более того, вокруг этого даже построено множество сложных библиотек, реализующих различные DSL'и (далеко не только SQL). S>>Все-таки у linq есть поддержка компилятора, т.е. встроен в язык, а у этих библиотек нет.
_>С учётом того как встроено, то лучше уж была бы библиотека, а не такая кривизна.
Посмотри LinqOptimizer _>>>Есть определённый набор претензий к реализации этой идеи в .net (т.к. некоторые особенности деревьев выражений linq портят производительность), S>>Какие особенности?
_>Необходимость создавать дерево, обходить его с помощью рефлексии и генерировать нужный нам код при каждом вызове. Как минимум это должно было бы происходить один раз при старте приложения, а по нормальному вообще на стадии компиляции (с помощью метапрограммирования и статической интроспекции).
Ведь в священных войнах каждое лишнее слово это дополнительный шанс оппоненту прикопаться, найти косяк, и отбросить всё, кроме найденного косяка.
