Здравствуйте, Sinclair, Вы писали:
V>>Потому что мои Op выполняются, считай, сразу, без стадии компиляции в CIL на моей стороне. S>Ну, ок. Статика. Если удастся сконструировать их статически.
Конструируются динамически через зеркальную цепочку фабрик.
При конструировании происходит анбоксинг параметров до пятого уровня вложенности и всё сначала.
Результирующее выражение всё-равно боксированное к известному интерфейсу, но забоксирован сложный value-type.
V>>Берём серверную сторону, сервак работает 24x7. V>>Серверная сторона не для красного словца — та задача изначально под серверную сторону потребовалась. V>>Compile каждый раз порождает новый код, который остаётся в памяти процесса и нет способа этот мусор собрать. S>А зачем делать это каждый раз, когда можно один раз проинициализировать статическое поле результатом Compile, а потом обращаться к нему за стоимость вызова IOperation<int>.Execute или даже быстрее?
Так в этом смысл — выражения вводят юзвери.
Только ради этого ограничивал глубину вложенности типов небоксируемых AST-выражений, чтобы бороться с разнообразием.
V>>Перезагрузки доменов теперь тоже нет. S>Почему не скомпилировать это в DynamicMethod, который прекрасно соберётся безо всякой выгрузки доменов?
Облом было ради такой задачи возиться аж с опкодами.
S>Эмм, если где-то есть парсер-билдер, то никакой статики уже не будет.
Оперировать известными типами проще, чем неизвестными через метаинформацию и систему приоритетов приведений.
Не было задачи написать полноценный компилятор, нужно было написать "вычислитель" выражений, оперирующих известными переменными-параметрами.
А да, я прочитал как .Net Core 3.0, а не версия языка.
ОК.
V>>В реальных коммерческих проектах всегда весы — трудоёмкость vs получаемые плюшки. S>Точно. Именно это я и написал.
И если малые плюшки имеют низкую трудоёмкость, то их часто в приоритете двигают вперёд.
Так проще сугубо психологически даже разработчикам — не накапливается технический долг.
V>>А здесь ситуация вдвойне забавной получилась, бо поддержка статических локальных методов в expression builder не стоит дороже написания нового кода, который сгенерирует и выдаст новую ошибку компиляции с новым номером при попытке использовать статические локальные методы в expressions. S>Возможно. Я в код компилятора не смотрел, не могу сказать, что было дороже.
Для этого не обязательно заглядывать в код, достаточно знать, что статический локальный метод компилятор превращает в обычный статический метод в отличие от нестатического метода, захватывающего контекст, а обычный статический метод допустим для использования в Expression.
V>>Рассуждая похожим образом: V>>- отсутствие linq в дотнете аффектило примерно 0 человек в мире V>>- отсутствие дотнета аффектило примерно 0 человек в мире S>Вот эти натянутые аналогии показывают, что вам пока рано в продакт менеджмент
Не тебе судить.
Даже тут оценка "натяжка" — насос из пальца.
Т.е. ты среагировал на содержание, хотя показывался принцип.
И как может столь субъективный человек, с полутыка агрящийся на некие "маркеры", рассуждать о чьей-то там готовности?
Только через такую же точно неконтроллируемую субъективность.
Тут всё слишком стандартно — хотя я где-то приветствую увлекающихся людей и "болею" за них, но в деле принятия решений их слово последнее.
S>Отсутствие linq в дотнете аффектило миллионы человек в мире.
Дудки.
99% людей не знали что это такое и потому не желали этого.
Как можно желать того, о чём не в курсе? ))
S>Хейльсберг в своё время очень убедительно обосновывал, почему был разработан Linq — а ведь это потребовало огромных инвестиций. Уж очень дофига принципиально нового было добавлено в язык.
Да пофик.
Тот самый случай, когда дотнету все года надо было бежать впереди паровоза джавы, чтобы хотя бы просто оставаться на месте.
Ты опять цепляешься за конкретику, не понимая общего принципа разработки дотнета и языка C#.
(по каждому нововведению есть кучи и обсуждений, и убедительных обоснований)
Добавление в язык linq не потребовало изменять рантайм, к сожалению.
К сожалению — потому что пришлось завязать его целиком на имеющихся делегатах.
А те всегда наследники MulticastDelegate.
Тоже так себе компроммиссное решение, из которого теперь непонятно как выкручиваться.
S>Отсутствие дотнета аффектило, в первую очередь, позиции Microsoft
Ага, а теперь MS отпустил дотнет в свободное плавание.
И выглядит так, что практически совсем свободное.
S>которому хотелось делать свою JVM, но Sun не давала им пилить JVM в нужную микрософту сторону.
Sun не давала возможность пилить ни в какую.
То бишь, Sun боролась за то, чтобы новые версии Джавы выходили только из под её пера.
Если честно, я так и не понял, как им удалось доказать свою правоту — вот тебе тупость амеровской судебной системы.
Если некая контора отпустила некий стандарт в свободное плавание, то за каким чёртом у неё остаётся возможность контроллировать дальнейшее развитие этого стандарта?
Сюрр...
V>>Посмотри в зеркало, плиз, на каждый именно твой пост запросто можно отвечать "это никому не нужно" и "ты всё-равно до этого не доживёшь", бо ты пишешь сюда именно такой материал, заведомо допускающий именно таких оценок. S>Ну естественно. По умолчанию, linq2d нафиг никому не упал.
Не только в этом дело, т.е. не конкретно в linq2d.
Ты человек увлекающийся, болеющий не за IT в целом, а за любимые конкретно тебе его островки.
Как грится, без обид, но слова любого человека, который позволяет себе слишком много личного в технических вещах, принято делить на два и более.
Приветствуются люди со здравой циничностью, умеющие смотреть на одну и ту же вещь под разными углами и на разном удалении, т.е. не только из любимой позиции.
Последнее банально утомляет/раздражает, т.к. такой человек потенциально в любой момент может начать профанировать любое обсуждение, которое пойдет не по самому любимому пути.
V>>Решения принимаются в несколько этапов, происходящих итеративно: из формулирования целей и приоритетов, затем из анализа потенциальной трудоёмкости задач, соотнесения с располагаемыми ресурсами, goto на начало. S>Именно. И вот этот процесс привёл к тем результатам, которые мы и наблюдаем.
Увы.
Я же отслеживаю фичи, обсуждения, расставляемые приоритеты и как вообще принимается решения о назначении приоритетов.
Сейчас фичи включаются в релизы по мере фактической готовности, а приоритеты расставляются исходя из того, есть кому заниматься такой-то задачей или нет.
В коммерческой разработке происходит чуть иначе — если некая запланированная фича начинает запаздывать, то на неё выделяют доп.ресурсы.
А в нынешней разработке дотнета этого важного момента нет.
Сейчас набежали добровольцы по интересам (особенно из нейтива) и делают лишь то, что считают необходимым.
(в т.ч. серьезно переделали SslStream уже дважды, и вообще принципы работы с X509-сертификатами).
Им этот Exression и даром не упал, они считают его за чушь/блажь, бо есть более срочные вещи.
А в эту область (exression и прочий сахар) разработки нужны люди навроде тебя, любящие дотнет в его исходной парадигме, чтобы холили и лелеяли такой взгляд на вещи в платформе, усиливали своим вкладом те самые моменты.
Но сейчас там задают тон люди, не принявшие исходную парадигму, т.е. твои "природные дотнетные враги", навроде меня. ))
Причём, это они пока заняты сугубо АПИ и принципами низкоуровневого происходящего (заняты всем тем, на недостаток чего я все годы жаловался), т.е. вкладывают в дотнет низкоуровневые инструменты, делая его более пригодным для более широкого круга задач.
Посмотрим что будет, когда они доберутся до джит...
Мне уже заранее жаль нынешнюю метаинформацию, бо она со 2-го дотнета практически не менялась...
Здравствуйте, vdimas, Вы писали:
S>>Отсутствие linq в дотнете аффектило миллионы человек в мире.
V>Дудки. V>99% людей не знали что это такое и потому не желали этого. V>Как можно желать того, о чём не в курсе? ))
На самом деле как минимум 50% работали с SQL. А Linq то больше был нужен именно для работы с БД через деревья выражений.
Да для коллекций сначала многие не принимали, но потихоньку втянулись. Учитывая ленивый вызов итераторов с права на лево.
и солнце б утром не вставало, когда бы не было меня
Re[69]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Sinclair, Вы писали:
V>>Это называется заблудиться в трёх соснах. )) V>>Я уже подсказал, где можно найти аналогичную реализацию очереди, свой исходник вряд ли имею право дать. S>Смешно. Сделайте другой исходник.
Т.е. тот же исходник, с чуть другим форматированием и идентификаторами?
Действительно, смешно.
S>ГК РФ запрещает относить к служебным произведениям что-то, сделанное вне рамок должностных обязанностей или распоряжений руководства.
Исследования имеющихся lock-free алгоритмов и потенциальных способов их применимости в наших сценариях я делал за зарплату в рабочее время когда-то.
Туда же изобретение собственных как алгоритмов, так и сценариев их применения.
Например, у нас при банальной отсылке данных в сокет совместно работает сразу 3 lock-free алгоритма.
Каждый из них простейший, но их определённая комбинация рождает новый алгоритм более высокого уровня, который умудряется быть тем эффективней, чем больше нагрузка.
По-сути, тут требуется как приводить код всех трех составляющих по отдельности, так и показывать синергию от совместного использования с рассмотрением отклика системы на различные возникающие сценарии.
V>>(да и смысла нет, если аналог доступен в открытом доступе) S>Обожаю смотреть, как вы начинаете вертеться, как только речь заходит о реальном коде.
И это при выданных координатах аналогичного кода?
Выглядит как "я хочу на блюдечке с голубой каёмочкой".
Хотел бы по-настоящему, уже бы давал свои соображения по реализации (там есть на что обратить внимание).
V>>И что было непонятного в том замечении, что очередь с той дисциплиной потребует переписать механизм тасков? V>>Это попытка замылить суть вопроса или что? S> От критиков ConcurrentQueue не требуется переписать механизм тасков.
Ну не демагогам же это решать?
Невозможно свести совокупность высказанных мною претензий к простому "критика ConcurrentQueue".
Слишком грубая подмена тезиса.
S>Если очередь плоха сама по себе — то её можно заменить на ту очередь, которая хорошая сама по себе.
Абстрактного коня в вакууме заменить на абстрактного верблюда в вакууме?
Ну ты ж всё-равно не готов, коль рассуждаешь в терминах "плохая-хорошая".
Было сказано "очередь не является lock-free", было сказано "дисциплина очереди оверинжениред для требований раздачи тасков потокам".
(уже не в первый раз пытаюсь вернуть к тезисам).
И да, замена очереди и переосмысливание всей системы в конце всех концов делает асинхронщину в разы эффективнее, например, как у нас.
S>То, что в реализации механизма тасков используется не лучшая реализация очереди для механизма тасков — ортогональный вопрос.
На пальцах показываешь как работает приём "подмена тезиса"?
V>>Альтернативные lock-free очереди с дисциплиной многие-ко-многим на этом сайте тоже публиковались неоднократно, только при чём тут они, если эта дисциплина банально не нужна в деле огранизаций очередей к конкретным потокам? S>Ну, раз они публиковались, то наверняка можно привести на них ссылку.
Можно.
Их поиск будет стоить мне столько же трудоёмкости, сколько и тебе.
S>Ну, и убедительно продемонстрировать разницу между "плохим" вариантом и "хорошим" вариантом.
Разница в разы эффективности системы в целом, как throughput, так и latency.
Причём, в дотнетной же реализации, которая калька с плюсовой, но отстаёт от плюсовой совсем немного, что малость неожиданно.
Но у нас еще присутствует уникальная lock-free реализация самого task объекта (пара promise-future в терминах С++, перетащили и в дотнет), чего в майкрософтных PPL нет.
И нигде сегодня нет.
Я специально много искал — глухо, везде блокирующие алгоритмы у альтернативных реализаций future-подобных объектов.
S>Без этого вся дискуссия — споры футбольных фанатов.
Ну, если фанаты будут обсуждать не технику игроков, а их одежду и даже стрижку вратаря — то где-то так и будет.
Мода ветренна, пристрастия ненадёжны.
Здравствуйте, Serginio1, Вы писали:
V>>Как можно желать того, о чём не в курсе? )) S>На самом деле как минимум 50% работали с SQL. А Linq то больше был нужен именно для работы с БД через деревья выражений.
Linq не похож на SQL от слова вообще.
Даром что ключевые слова взяты те же, но принцип построения выражений другой.
S>Да для коллекций сначала многие не принимали, но потихоньку втянулись. Учитывая ленивый вызов итераторов с права на лево.
Не принимали из-за не SQL-подобных конструкций выражений.
Т.е. из-за невозможности переиспользовать имеющуюся компетенцию.
Выражения Linq — это другой язык.
Соответственно, "втянулись" лишь по мере изучения этого языка.
Да и то, потому что Решарпер подсказывал замену foreach на linq. ))
Re[83]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Serginio1, Вы писали:
V>>>Как можно желать того, о чём не в курсе? )) S>>На самом деле как минимум 50% работали с SQL. А Linq то больше был нужен именно для работы с БД через деревья выражений.
V>Linq не похож на SQL от слова вообще. V>Даром что ключевые слова взяты те же, но принцип построения выражений другой.
Это тебе только кажется. Тот кто декларативно использовал SQL быстро начали использовать и Linq
Ну Linq в SQL синтаксисе очень даже близок к SQL. Я больше его предпочитаю для сложных выражений
S>>Да для коллекций сначала многие не принимали, но потихоньку втянулись. Учитывая ленивый вызов итераторов с права на лево.
V>Не принимали из-за не SQL-подобных конструкций выражений. V>Т.е. из-за невозможности переиспользовать имеющуюся компетенцию.
Угу сейчас его используют налево и направо, от циклов отказались напрочь где надо и где не надо V>Выражения Linq — это другой язык.
V>Соответственно, "втянулись" лишь по мере изучения этого языка. V>Да и то, потому что Решарпер подсказывал замену foreach на linq. ))
Не пользовался решарпером. Но быстро перешел на Linq.
и солнце б утром не вставало, когда бы не было меня
Re[81]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, vdimas, Вы писали:
V>Облом было ради такой задачи возиться аж с опкодами.
С какими ещё опкодами?
Во-первых, там внутри — dynamicMethod. https://stackoverflow.com/questions/43041190/do-compiled-expression-trees-leak
Во-вторых, даже если бы его там не было, то достаточно самому состряпать DynamicMethod и отдать его в Expression.CompileToMethod().
V>Оперировать известными типами проще, чем неизвестными через метаинформацию и систему приоритетов приведений. V>Не было задачи написать полноценный компилятор, нужно было написать "вычислитель" выражений, оперирующих известными переменными-параметрами.
V>И если малые плюшки имеют низкую трудоёмкость, то их часто в приоритете двигают вперёд. V>Так проще сугубо психологически даже разработчикам — не накапливается технический долг.
V>>>А здесь ситуация вдвойне забавной получилась, бо поддержка статических локальных методов в expression builder не стоит дороже написания нового кода, который сгенерирует и выдаст новую ошибку компиляции с новым номером при попытке использовать статические локальные методы в expressions.
V>Для этого не обязательно заглядывать в код, достаточно знать, что статический локальный метод компилятор превращает в обычный статический метод в отличие от нестатического метода, захватывающего контекст, а обычный статический метод допустим для использования в Expression.
V>Тут всё слишком стандартно — хотя я где-то приветствую увлекающихся людей и "болею" за них, но в деле принятия решений их слово последнее.
V>Как можно желать того, о чём не в курсе? ))
Аффект — это от английского affect = "to act on, to change something".
Речь не о том, что кто-то из пользователей чего-то хотел. А о том, что миллионы людей страдали, описывая SQL в строковых константах.
V>Ты опять цепляешься за конкретику, не понимая общего принципа разработки дотнета и языка C#. V>(по каждому нововведению есть кучи и обсуждений, и убедительных обоснований)
V>Добавление в язык linq не потребовало изменять рантайм, к сожалению. V>К сожалению — потому что пришлось завязать его целиком на имеющихся делегатах. V>А те всегда наследники MulticastDelegate. V>Тоже так себе компроммиссное решение, из которого теперь непонятно как выкручиваться.
Нуу... да. Теоретически можно замутить свой SinglecastDelegate на основе managed function pointer, а в компилятор запилить умение компилировать лямбду в него .
Тогда лёгким манием руки дропаем нынешний код Func<...>, переименовываем SinglecastDelegate<...> в Func<...>, и наслаждаемся.
Мультикастами могут быть только Action<...>.
S>>Отсутствие дотнета аффектило, в первую очередь, позиции Microsoft V>Ага, а теперь MS отпустил дотнет в свободное плавание. V>И выглядит так, что практически совсем свободное.
Угу. Вот на это больше похоже.
V>Если некая контора отпустила некий стандарт в свободное плавание, то за каким чёртом у неё остаётся возможность контроллировать дальнейшее развитие этого стандарта? V>Сюрр...
Свободное плавание явы началось только в ноябре 2006. Т.е. через 9 лет после иска Sun, и через пять с половиной после мирового соглашения. А, да, и через четыре с половиной — после выхода дотнета.
V>Я же отслеживаю фичи, обсуждения, расставляемые приоритеты и как вообще принимается решения о назначении приоритетов. V>Сейчас фичи включаются в релизы по мере фактической готовности, а приоритеты расставляются исходя из того, есть кому заниматься такой-то задачей или нет.
Это вы сейчас про свою секретную компанию, или про дотнет?
Если про дотнет, то мы оба неправы.
Исходно локальные функции прекрасно работали в Expression Trees, и там захватывался ровно mangled method name — всё, как вы хотели.
Вот pull request, который это изменил: https://github.com/dotnet/roslyn/pull/3849
Не было никаких комитетов и обсуждения "добавить их в expression builder или нет", не было оценок стоимости, полезности, и движения в бэклоге.
Не было никаких "нам сложно объяснять, почему статик можно, а нестатик нельзя" — было можно оба.
Не было даже рассуждений типа "при разборе деревьев выражений имена важны, и замена имени метода могла сбить с толку" (https://stackoverflow.com/a/44229632).
Просто конкретная Эшли Хаук решила, что "References to local functions are now disallowed in expression trees, which may or may not change in the future (Previously they were generated as a reference to a mangled method name, which seemed wrong)".
Почему wrong? Да потому, что "local functions in general are bad" (смотреть обсуждение PR). Всё. Это reason enough.
V>А в эту область (exression и прочий сахар) разработки нужны люди навроде тебя, любящие дотнет в его исходной парадигме, чтобы холили и лелеяли такой взгляд на вещи в платформе, усиливали своим вкладом те самые моменты. V>Но сейчас там задают тон люди, не принявшие исходную парадигму, т.е. твои "природные дотнетные враги", навроде меня. ))
И это тоже выглядит неверным. Я вот пока не понимаю, почему де Смет не делает Pull Request. Уже больше года, как поддержка всего на свете в Expression готова.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[70]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, vdimas, Вы писали:
V>Т.е. тот же исходник, с чуть другим форматированием и идентификаторами?
Примерно так.
V>Исследования имеющихся lock-free алгоритмов и потенциальных способов их применимости в наших сценариях я делал за зарплату в рабочее время когда-то. V>Туда же изобретение собственных как алгоритмов, так и сценариев их применения.
Вы же в курсе, что алгоритмы не являются охраноспособными?
А исходный код — это исходный код. В него входит и форматирование, и идентификаторы. ГК РФ запросто разрешает параллельно разрабатывать два кода, один из которых является служебным произведением, а второй — нет.
V>Например, у нас при банальной отсылке данных в сокет совместно работает сразу 3 lock-free алгоритма. V>Каждый из них простейший, но их определённая комбинация рождает новый алгоритм более высокого уровня, который умудряется быть тем эффективней, чем больше нагрузка.
Хорошо вам.
V>Выглядит как "я хочу на блюдечке с голубой каёмочкой". V>Хотел бы по-настоящему, уже бы давал свои соображения по реализации (там есть на что обратить внимание).
Не, я не настолько квалифицирован в lock-free алгоритмах.
V>И да, замена очереди и переосмысливание всей системы в конце всех концов делает асинхронщину в разы эффективнее, например, как у нас.
Ну, вы молоцы. Жалко, что кроме вас, об этом никто не знает
V>Но у нас еще присутствует уникальная lock-free реализация самого task объекта (пара promise-future в терминах С++, перетащили и в дотнет), чего в майкрософтных PPL нет. V>И нигде сегодня нет. V>Я специально много искал — глухо, везде блокирующие алгоритмы у альтернативных реализаций future-подобных объектов.
V>Ну, если фанаты будут обсуждать не технику игроков, а их одежду и даже стрижку вратаря — то где-то так и будет.
Так а как можно обсуждать технику, которой нет? Нет кода — нет предмета обсуждения. Выходит так, что ваша часть дискуссии — это "ваш Месси плохо держит мяч, у меня есть игрок, который делает это лучше. Но я вам его не покажу, потому что он секретный. И вообще — есть множество других игроков, вполне публичных, которые играют лучше Месси. Но я вам их не назову — сами найдите да посмотрите".
Предлагаю тему свернуть, потому как про воображаемый секретный код мне не очень интересно. Если будут какие-то фрагменты кода или приёмы, которые вы готовы обсуждать — велком.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[68]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Sinclair, Вы писали:
V>>Я не вижу на графиках объезжания на малых объемах данных, но ты утверждаешь обратное. S>Надо внимательно смотреть: S>Image: 2021_08_05_17_40_39_SmallSize.png
И под каким графиком площадь меньше?
V>>Это с большой копипастой. V>>Я бы для простоты сделал на виртуальных методах или if-ах с последующим разбоксированием. S>Не понимаю смысл.
Узел типа вложенности 1 должен породить тип узла вложености 2 при разбиении, для сохранения статичности типа и т.д.
V>>Можно было бы повторить замеры с предварительным full GC после наполнения дерева. S>Можно. Почему бы и нет. Сделайте форк да повторите.
Я так и делаю в интересующих меня вопросах даже для совсем мелочей.
Ты же видел, что я за раз прогоняю максимально полную сетку вариантов, хотя бы потому что benchmark переводится как сравнительное тестирование, а тестировать один вариант за раз мне обычно лень. ))
А в этой задаче я просто готов подкидывать идеи, разминка для ума, не более.
Разве тебе самому не любопытно, почему в начале графика имеющаяся версия эффективней?
И как это соотносится с твоими возражениями на моё предложение делать арность первых слоёв меньше, мол, это будет слив производительности?
V>>Обрабатываются по-факту на один уровень косвенности, если содержимое целевого слота памяти независима от текущих вычислений. S>Ну так оно ж зависит. Мы же пойдём в неизвестного заранее ребёнка.
Адрес ф-ии берется по константному смещению от RXC последней операцией, причём, независимо от результата предыдущих операций.
Это как альтернатива проверки типа или флага дочернего узла:
internal static unsafe class NodeHelper<T> {
private static readonly delegate*<BranchNode<T>, int, T> s_branchGetItem = &BranchNode<T>.GetItem;
private static readonly delegate*<LeafNode<T>, int, T> s_leafGetItem = &LeafNode<T>.GetItem;
public static delegate*<object, int, T> GetItemFun(bool isLeaf)
=> isLeaf ? (delegate*<object, int, T>)s_leafGetItem : (delegate*<object, int, T>)s_branchGetItem;
}
internal class LeafNode<T> {
private Bunch<T> _values;
public static T GetItem(LeafNode<T> @this, int index) => @this._values[index];
}
internal unsafe class BranchNode<T> {
#region do not reorder
private struct Indicies { private fixed int _data[16];}
private Indicies _indicies;
private Bunch<object> _children;
private readonly delegate*<object, int, T> _childGetItem;
#endregion
internal BranchNode(bool childIsLeaf) => _childGetItem = NodeHelper<T>.GetItemFun(childIsLeaf);
// agressive-optimization
// no-locals-initpublic static T GetItem(BranchNode<T> @this, int index) {
object child;
(child, index) = @this.FindChild(index);
return @this._childGetItem(child, index);
}
private (object child, int index) FindChild(int index) => (0, 0);
}
В общем, в дотнете статический метод с первым @this и нестатический метод с неявным this в железе выглядят одинаково, но пока нельзя взять адрес нестатической ф-ии без рефлексии.
В тех своих тестах на эффективность вызовов я брал адрес нестатической ф-ии из рефлексии, затем приводил адрес к указателю на статичесую ф-ию, где первым элементом подавал @this, вызывая де-факто нестатический метод.
Здесь в коде тоже хак — типы указателей на ф-ии приводятся к друг другу без проверки, т.е. корректность должна обеспечиваться самим кодом, бо в рантайме тоже проверок нет.
Это дыра в привычной безопасности, поэтому delegate*<> может жить только в unsafe-блоках кода.
V>>При повороте дочерний узел заменяет собой родительский узел. S>Какой именно из дочерних узлов?
Где происходит сбой разметки красное-черное.
В худшем случае (при упорядоченной вставке) происходит, если склероз не изменяет, одна балансировка на две вставки.
V>>А у тебя при росте вложенности потребуется перестроить всё дерево, насколько я сейчас понял. S>Нет конечно. Рост вложенности — это split, он очень простой. порождаются ровно три узла, независимо от глубины дерева. Это же B-tree, они все работают одинаково.
Ты говорил, что у тебя узлы одного уровня одинаковы.
Т.е. все листья располагаются на одинаковой глубине.
Выше код именно под этот случай.
V>>В мутабельном B+ дереве легко последовательно обойти хранящиеся значения (один из основных кейзов для списка), т.к. все листья соеденены в связанный список. V>>В иммутабельном виде этой функциональности нет, насколько я понимаю, поэтому обход достаточно дорогой. S>Обход я ещё не оптимизировал; но там скорее всего тоже всё будет не намного дороже. Прямо сейчас итератор сделан тупо через _list[_position], то есть шаг итерации ~ O(log(N)). Можно сделать на immutable stack за O(1).
Зачем для итератора immutable stack?
Обычно это локальная переменная.
Можно приделать ему Сlone() при надобности.
(хотя, от сценариев надо плясать)
Сам интерфейс итератора для foreach и для реализации IEnumerable мутабельный.
Здравствуйте, Sinclair, Вы писали:
V>>Т.е. тот же исходник, с чуть другим форматированием и идентификаторами? S>Примерно так.
Это слив корпоративного ноу-хау.
V>>Исследования имеющихся lock-free алгоритмов и потенциальных способов их применимости в наших сценариях я делал за зарплату в рабочее время когда-то. V>>Туда же изобретение собственных как алгоритмов, так и сценариев их применения. S>Вы же в курсе, что алгоритмы не являются охраноспособными?
Только на алгоритмы и можно получить патент.
Но на конкретную реализацию алгоритма (вотчина авторского права) патент получить нельзя.
Далее.
Патент требует раскрытия алгоритма.
Срок патента ограничен.
Ограничена географическая область патента — охрана действительна только в стране выдачи и в странах, где действуют взаимные патентные соглашения со страной выдачи.
Патенты стоят денег, патентировать алгоритмы по всему миру дорого.
Не зря в программировании прижилось в основном "ноу-хау" — коммерческая тайна.
А крупные конторы патентируют обычно вещи, которые видны невооружённым взглядом, т.е. алгоритмы работы системы в целом, на высоком уровне.
И то, я как-то почитывал такие патенты — удивлялся.
Похоже, патентируют очевидные вещи сугубо в кач-ве защиты от патентных троллей.
Этим информационным мусором отбили всякое любопытство почитывать западные патенты.
S>А исходный код — это исходный код. В него входит и форматирование, и идентификаторы. ГК РФ запросто разрешает параллельно разрабатывать два кода, один из которых является служебным произведением, а второй — нет.
Да плевать на тонкости реализации и форматирования. ))
Не уверен, что требуется кому-либо объяснять это.
V>>Например, у нас при банальной отсылке данных в сокет совместно работает сразу 3 lock-free алгоритма. V>>Каждый из них простейший, но их определённая комбинация рождает новый алгоритм более высокого уровня, который умудряется быть тем эффективней, чем больше нагрузка. S>Хорошо вам.
Там кейз специфический — lock-free очередь обслуживает так же примитив сигнализации, на котором надо ожидать в отсутствии задач или IO.
И потоки из пула ожидают на внутренних своих примитивах сигнализации внутри WinaAPI, где нет возможности добавить знание о происходящем в очереди в сам факт манипулирования примитивами сигнализации.
Например, дотнет должен обслуживать как потенциально-легковесную очередь задач самому себе, так и поступающие извне в поток UserWorkItem, даже если они к Task не имеют никакого отношения.
Я же говорю — тут требуется комплексное переосмысление происходящего.
Мне даже очередь таймеров пришлось переосмыслить от классической приоритетной очереди до, скажем так, своей релизации, более подходящей под наши сценарии.
Даже запрос текущего monotonic-системного времени был переосмыслен. ))
Кароч, всё то, что отжирало то тут, то там сотни наносекунд или даже до микросекунды на каждый чих, складываясь в общую задержку.
Стоимость своих альтернативных решений — единицы-десяки наносекунд на каждую такую операцию-кирпичик.
V>>Выглядит как "я хочу на блюдечке с голубой каёмочкой". V>>Хотел бы по-настоящему, уже бы давал свои соображения по реализации (там есть на что обратить внимание). S>Не, я не настолько квалифицирован в lock-free алгоритмах.
Ну, сложные lock-free алгоритмы не всегда в реальном использовании обгоняют простые на мьютексах, если блокировки мьютексов короткие и вероятность конфликтов низка.
По настоящему эффективными могут быть только предельно простые lock-free алгоритмы, их можно понять и без специальной подготовки.
Тогда задача перетекает в несколько другую плоскость — попытаться расписать работу всей системы на комбинации отдельных простых lock-free алгоритмов.
Для меня это неотъемлимый контекст по работе, с этих позиций и рассуждал.
Поэтому, нет желания прогибаться под попытку переиначить исходные мои заявления, вычленить и рассмотреть только часть и т.д.
Опять же, дотнетный пул потоков под таски обычно в разы больше кол-ва ядер в системе.
Я как-то замерял — на моих 12 ядрах он создавал под 200 с лишним потоков в пуле на интенсивном использовании.
Поэтому, потенциальное блокирование из-за того, что реализация конкурентной очереди не удовлетворяет гарантиям lock-free, что потенциально может заморозить лишь +1 попавший в конфликт поток — это вроде как приписанное системе допущение. И тогда очередь остальных задач к потоку может разгребаться другими потоками.
Но эта парочка задач-неудачниц будет страдать. ))
Совсем другое дело, когда в нашем пуле ровно столько потоков, сколько ядер, гарантии lock-free соблюдаются, ни один поток не морозится.
Таски, таймеры и IO обслуживаются в этом общем пуле, процессоры переключают контексты исполнения крайне редко — когда нет данных, т.е. можно уйти в спячку до получения сигнала о пробуждении.
V>>И да, замена очереди и переосмысливание всей системы в конце всех концов делает асинхронщину в разы эффективнее, например, как у нас. S>Ну, вы молоцы. Жалко, что кроме вас, об этом никто не знает
Индустрия знает, мы в лидерах, 1-2-е места по репортам тестовых лабораторий Intel.
Т.е. разница где-то в 30-40 раз.
При этом сама наша асинхронщина быстрее всего-лишь раз в 17, т.е., эффективность надо набирать отовсюду, получая конечную её.
Никакое одно решение не даёт нормальной эффективности, это всегда большой комплекс мер.
V>>Ну, если фанаты будут обсуждать не технику игроков, а их одежду и даже стрижку вратаря — то где-то так и будет. S>Так а как можно обсуждать технику, которой нет?
Можно обсуждать, какой она могла бы быть.
Тем более, что адрес одного из примеров был дан.
S>Нет кода — нет предмета обсуждения.
Слава богу, очень немногие коллеги так категорично ставят вопрос.
В основе всего лежит идея.
И даже не спорь. ))
"Дайте готовый код" — присказка уставших от жизни ленивцев.
S>Выходит так, что ваша часть дискуссии — это "ваш Месси плохо держит мяч, у меня есть игрок, который делает это лучше. Но я вам его не покажу, потому что он секретный. И вообще — есть множество других игроков, вполне публичных, которые играют лучше Месси. Но я вам их не назову — сами найдите да посмотрите".
Отсылка к футболу была твоей, аналогия малость хромает...
Можно взять аналогию ближе к инженерной, например, сравнить характеристики ракет потенциальных противников, где применённые технологии являются охраняемой тайной.
S>Предлагаю тему свернуть, потому как про воображаемый секретный код мне не очень интересно.
А как другой код поможет тебе понять, что именно происходит в дотнетных тасках сейчас?
Чем тебя не устраивает уже имеющийся дотнетный код для целей анализа происходящего?
Не интересно? (скорее всего)
У меня же не было перед глазами готового решения.
Я должен был проводить анализ происходящего, сравнивать различные подходы, внимательно смотреть как данные циркулируют, где и сколько раз дёргаются примитивы сигнализации, а нужно ли их там дёргать и т.д. и т.п.
Здравствуйте, Sinclair, Вы писали:
V>>Облом было ради такой задачи возиться аж с опкодами. S>С какими ещё опкодами? S>Во-первых, там внутри — dynamicMethod. https://stackoverflow.com/questions/43041190/do-compiled-expression-trees-leak S>Во-вторых, даже если бы его там не было, то достаточно самому состряпать DynamicMethod и отдать его в Expression.CompileToMethod().
Если я сказал, что с выходом Expression посмотрел на возможность построения альтернативных Expression (т.е. неких своих), то как на момент их разработки я мог взять Expression и DynamicMethod?
И какие плюшки, кроме ощущения причастности к новизне, должно было дать переписывание готового кода на более тяжеловесную технологию?
В том контексте оно означало "задевает, имеет отношение, касается".
Вот я и спрашиваю, как меня может задевать отсутствие некоей функциональности, о потенциальном наличии которой я даже не догадываюсь?
А в случае отсутствия поддержки статических локальных методов — догадываюсь, меня это касается. ))
S>Речь не о том, что кто-то из пользователей чего-то хотел. А о том, что миллионы людей страдали, описывая SQL в строковых константах.
Ну, у нас когда-то был свой query builder, недалеко от методов-расширений Linq уехало.
Но без поддержки query-синтаксиса.
В любом случае, даже с появлением linq запросы на обновление и удаление точно так же требовали генерирования SQL каким-либо образом вне Linq.
Т.е., из CRUD linq повлиял только на одну букву.
(и да, я в курсе про остроумное решение с синтаксисом обновления в ORM-библиотеке за авторством IT)
S>Нуу... да. Теоретически можно замутить свой SinglecastDelegate на основе managed function pointer, а в компилятор запилить умение компилировать лямбду в него .
И это был мой второй подход к Exression, буквально через минуту, как увидел указатели на ф-ии.
Но там есть сложность — лямбда может захватывать контекст или нет, т.е. представлять из себя статический метод или экземплярный захваченного контекста.
Делегаты в этом смысле обеспечивают абстракцию.
Делегат хранит адрес целевой ф-ии и знает как надо вызывать эту ф-ию — подставляя значение сохранённого object в кач-ве this или нет.
Это разные вызовы с разной арностью при одинаковой внешней арности делегата.
S>Тогда лёгким манием руки дропаем нынешний код Func<...>, переименовываем SinglecastDelegate<...> в Func<...>, и наслаждаемся. S>Мультикастами могут быть только Action<...>.
V>>Если некая контора отпустила некий стандарт в свободное плавание, то за каким чёртом у неё остаётся возможность контроллировать дальнейшее развитие этого стандарта? V>>Сюрр... S>Свободное плавание явы началось только в ноябре 2006.
В смысле, заопенсорсили реализацию?
Я про стандарт языка говорил.
Java Community Process был создан в 90-е, стандарт на язык был опубликован тогда же.
Но нельзя присвоить опубликованный стандарт языка, если нет патента.
А патент на язык не дадут.
Любой может пользоваться стандартом, форкать в своих интересах на своё усмотрение и т.д.
Это личное дело субъекта предпринимательства.
Т.е., юридической основы для иска не было.
V>>Я же отслеживаю фичи, обсуждения, расставляемые приоритеты и как вообще принимается решения о назначении приоритетов. V>>Сейчас фичи включаются в релизы по мере фактической готовности, а приоритеты расставляются исходя из того, есть кому заниматься такой-то задачей или нет. S>Это вы сейчас про свою секретную компанию, или про дотнет?
Про дотнет.
В нашей компании всё стандартно — ресурсы перекидываются по велению руководства.
S>Если про дотнет, то мы оба неправы. S>Исходно локальные функции прекрасно работали в Expression Trees, и там захватывался ровно mangled method name — всё, как вы хотели. S>Вот pull request, который это изменил: https://github.com/dotnet/roslyn/pull/3849 S>Не было никаких комитетов и обсуждения "добавить их в expression builder или нет", не было оценок стоимости, полезности, и движения в бэклоге. S>Не было никаких "нам сложно объяснять, почему статик можно, а нестатик нельзя" — было можно оба.
В случае нестатик возможны неоднозначности, которые непонятно как решать.
Например, без локальных ф-ий происходящее очевидно:
var expressions = new List<Expression<Func<int>>>();
for(var i = 0; i < 4; i++)
expressions.Add(() => i);
expressions.ForEach(e => Console.WriteLine(e.Compile()()));
Выведет
4
4
4
4
О захвате мутабельной переменной i компилятор честно выдаст warning при компиляции.
Но локальная ф-ия может скрыть свою мутабельную природу.
А как обеспечить чистоту функций на уровне языка — непонятно.
S>Просто конкретная Эшли Хаук решила, что "References to local functions are now disallowed in expression trees, which may or may not change in the future (Previously they were generated as a reference to a mangled method name, which seemed wrong)". S>Почему wrong? Да потому, что "local functions in general are bad" (смотреть обсуждение PR). Всё. Это reason enough.
Про локальные я полностью согласен — это непредсказуемая дичь в случае Expression и обычных делегатов, т.к. не всегда очевидно, что именно захватывается и где, т.к. таких локальных ф-ий может быть несколько, но они шарят общий контекст.
Но статические локальные ф-ии чисты относительно контекста, т.е. не подменяют значений и ссылок локальных переменных.
V>>А в эту область (exression и прочий сахар) разработки нужны люди навроде тебя, любящие дотнет в его исходной парадигме, чтобы холили и лелеяли такой взгляд на вещи в платформе, усиливали своим вкладом те самые моменты. V>>Но сейчас там задают тон люди, не принявшие исходную парадигму, т.е. твои "природные дотнетные враги", навроде меня. )) S>И это тоже выглядит неверным. Я вот пока не понимаю, почему де Смет не делает Pull Request. Уже больше года, как поддержка всего на свете в Expression готова.
Может, понимает, что не пройдёт.
Или видит недостаточный приоритет этой задаче.
Разобрать серьезный PR — это не лужу перешагнуть.
У нас на работе как начинаю разбирать... Иногда ловишь себя на мысли, что быстрее было самому сделать чем тщательно объяснять десяток одновременно участвующих тонкостей.
А в его коде этих тонкостей сотни.
Это нужна приличная команда для верификации такого PR, которая будет много дней разбирать его код.
Здравствуйте, Serginio1, Вы писали: S>>Мультикастами могут быть только Action<...>.
Ну вот эта порнография наглядно показывает, что в случаях вроде описанного, надо не маяться фигнёй вроде GetInvocationsList, а по честному делать списки:
Здравствуйте, Sinclair, Вы писали:
S>Ну вот эта порнография наглядно показывает, что в случаях вроде описанного, надо не маяться фигнёй вроде GetInvocationsList, а по честному делать списки: S>
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Sinclair, Вы писали: V>Унутри MulticastDelegate безопасная lock-free реализация.
Ну, это была так, схема. С учётом того, что от этой коллекции требуется только добавление, удаление по значению, и прямой перебор, то хватит банального односвязного списка.
И все операции будут не только lock-free, но и wait-free.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[86]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Sinclair, Вы писали:
V>>Здравствуйте, Sinclair, Вы писали: V>>Унутри MulticastDelegate безопасная lock-free реализация. S>Ну, это была так, схема. С учётом того, что от этой коллекции требуется только добавление, удаление по значению, и прямой перебор, то хватит банального односвязного списка. S>И все операции будут не только lock-free, но и wait-free.
1. А как вы wait-free достигли-то?
2. Если добавили последовательно два коллбэка, A и потом B, какой порядок их вызова вы предполагаете?
Я думаю, 99% предполагают, что всегда первым вызовется A, вторым B, даже если это нигде не декларировано.
Что-то я в этом случае слабо верю в lock-free на односвязном списке.
The God is real, unless declared integer.
Re[87]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, netch80, Вы писали:
S>>И все операции будут не только lock-free, но и wait-free.
N>1. А как вы wait-free достигли-то? ImmutableList<T>
Делегаты не ахти и огромные списки. Любой метод возвращает новую коллекцию
public System.Collections.Immutable.ImmutableList<T> Add (T value);
и солнце б утром не вставало, когда бы не было меня
Re[83]: MS забило на дотнет. Питону - да, сишарпу - нет?
V>?
Выведет причину того, что комбинировать делегаты, возвращающие значение, не имеет смысла. Более наглядным, возможно, будет следующий пример:
Func<int, bool> isEven = (x) => x % 2 == 0;
Func<int, bool> isXthree = (x) => x % 3 ==0;
Func<int, bool> combine = (Func<int, bool>)Delegate.Combine(isEven, isXthree);
foreach(var t in from r in Enumerable.Range(1, 10) where combine(r) select r)
Console.WriteLine(t);
V>Я про стандарт языка говорил. V>Java Community Process был создан в 90-е, стандарт на язык был опубликован тогда же.
JCP появился в 1998, примерно через год после обсуждаемого иска.
V>Т.е., юридической основы для иска не было.
Ну, я не хочу сейчас лезть в юридические дебри. Интересно пофантазировать, что было бы, если бы не было этого иска и мирового соглашения.
Возможно, мы сейчас бы жили в мире, где дотнета нет, зато есть java с value-типами и нормальными генериками, а не этой порнографией.
То есть вместо двух управляемых платформ мы бы имели одну, сочетающую лучшие стороны обеих.
V>Про дотнет.
Ок, а то было непонятно. V>В нашей компании всё стандартно — ресурсы перекидываются по велению руководства.
Ну вот в нашей компании ресурсы, конечно, перекидываются по велению руководства, но продакт менеджмент стоит достаточно близко к руководству, чтобы а) понимать, на основании чего перекидываются ресурсы и б) в определённой степени влиять на приоритеты.
V>В случае нестатик возможны неоднозначности, которые непонятно как решать. V>Например, без локальных ф-ий происходящее очевидно: V>
V> var expressions = new List<Expression<Func<int>>>();
V> for(var i = 0; i < 4; i++)
V> expressions.Add(() => i);
V> expressions.ForEach(e => Console.WriteLine(e.Compile()()));
V>
V>Выведет V>
V>4
V>4
V>4
V>4
V>
V>О захвате мутабельной переменной i компилятор честно выдаст warning при компиляции. V>Но локальная ф-ия может скрыть свою мутабельную природу.
Ну, в таком случае — почему работает вот это?
int i=0;
Func<int> getI = () => i;
var expressions = new List<Expression<Func<int>>>();
for(i = 0; i < 4; i++)
expressions.Add(() => getI());
expressions.ForEach(e => Console.WriteLine(e.Compile()()));
То есть анонимную локальную функцию — можно, безо всяких ворнингов, а именованную — уже нельзя.
Почему можно вот так?
int i=0;
int getI() => i;
var callbacks = new List<Func<int>>();
for(i = 0; i < 4; i++)
callbacks.Add(() => getI());
callbacks.ForEach(e => Console.WriteLine(e()));
То есть в делегате ссылаться на потенциально нечистую функцию — ок, а в expression — уже зашквар? V>А как обеспечить чистоту функций на уровне языка — непонятно.
Это опять рационализация иррационального.
V>Про локальные я полностью согласен — это непредсказуемая дичь в случае Expression и обычных делегатов, т.к. не всегда очевидно, что именно захватывается и где, т.к. таких локальных ф-ий может быть несколько, но они шарят общий контекст.
Как видим, в случае делегатов это никому не мешает. V>Но статические локальные ф-ии чисты относительно контекста, т.е. не подменяют значений и ссылок локальных переменных.
Правильный ответ — локальные функции настолько редко используются в делегатах и выражениях, что всем просто наплевать.
V>Может, понимает, что не пройдёт. V>Или видит недостаточный приоритет этой задаче. V>Разобрать серьезный PR — это не лужу перешагнуть. V>У нас на работе как начинаю разбирать... Иногда ловишь себя на мысли, что быстрее было самому сделать чем тщательно объяснять десяток одновременно участвующих тонкостей. V>А в его коде этих тонкостей сотни. V>Это нужна приличная команда для верификации такого PR, которая будет много дней разбирать его код.
Надо будет ему написать и спросить.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[87]: MS забило на дотнет. Питону - да, сишарпу - нет?
N>1. А как вы wait-free достигли-то?
Ну, ладно, ладно, wait-free не выйдет
N>2. Если добавили последовательно два коллбэка, A и потом B, какой порядок их вызова вы предполагаете?
Никакой. N>Я думаю, 99% предполагают, что всегда первым вызовется A, вторым B, даже если это нигде не декларировано.
Я думаю, 99.9% вообще об этом не задумываются. N>Что-то я в этом случае слабо верю в lock-free на односвязном списке.
Если прямо хочется обеспечить порядок First-added-first-called, то придётся строить инверсию списка при вызове. Это сохранит асимптотику всех операций (O(1) для add и remove, O(N) для invoke), но ухудшит стоимость вызова.
Я б не стал.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
