Здравствуйте, Serginio1, Вы писали:
S>Ну у тебя на каждом витке рекурсии своя версия а так же вложенность. можно управлять количеством вложенности и окончанием рекурсии
Ну вот это всё какой-то сюр. С обычным immutable-кодом в управляемой среде ненужные более останки удаляются сборщиком мусора.
А нужные, соответственно — не удаляются.

Здравствуйте, Serginio1, Вы писали:
S> Я все про использование манагед кода на сервере и аля сингулярити мечтаю! То есть из маршалинга максимум копирование результата в памяти, можно просто результат сразу класть в определенную память. Пока все грусно.
Да не особо грустно. Пока что самой сложной частью выглядит автоматическая конверсия "гражданского" кода, написанного в терминах интерфейсов (и, быть может, record классов) в код, который работает с "настоящим" представлением.
Если бы у нас не было значений переменного размера (string aka varchar aka ntext), то этой ненужной ботвы можно было бы избежать, выставляя в качестве внешнего API сразу внутреннее представление, т.е. структуры.
Потому что с ними вообще никаких проблем нет, zero copy zero allocation.
Но со всеми этими строками (и массивами, varbinary)- сплошной головняк. Нормально сохранять в файл можно только довольно-таки сложные конструкции, что-то типа rope. А вот выставлять их наружу, в клиентский код, не хочется категорически.

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

V>>И проблема не только в логарифмичности — даже если элемент найден в первом же узле дерева, то даже такой случай слишком проигрывает обычному массиву.
S>В листе B+ дерева внутри лежит обычный массив. Для размеров до 16 элементов доступ не слишком отличается от List<T>.

Во многие разы.


S>Ну, и в целом, иммутабельные коллекции делаются не для того, чтобы быть быстрее императивных, а для того, чтобы реализовывать логику. В частности, с ними не нужны блокировки при многопоточной работе.

Такие рассуждения уместны только если изменения необходимо делать видимыми остальным потокам.
Но тогда при обновлении некоей shared-ссылки всё-равно необходима или блокировка, или lock-free цикл.

Ну вот я и экспериментировал с различными структурами и lock-free алгоритмами когда-то.
На поверку >90% оказалось фуфелом, особенно иммутабельные структуры (а как глаза когда-то загорелись, ты бы только знал).

Иммутабельные структуры не несут эффективность, они несут простоту реализации, на это и стоит давить, ИМХО.
Например, ограничиться простым двоичным деревом, сделать код минимальным.
Ведь B+ деревья придуманы не для иммутабельности, а для приличного ветвления-индексирования, что хорошо ложится на блочное хранение данных.
У тебя же "блочность" микроскопическая — 16.
Такая маленькая блочность диктуется иммутабельной попыткой реализации, понятно, но противоречит концепции B+ деревьев.

В общем, мутанты всегда ведут себя странно...

Например, имеющаяся сейчас в дотнете ConcurrentQueue — тоже только поржать.
В момент роста очереди остальные потоки выполняют строго-блокированное ожидание на SpinWait.
Т.е., если поток, добавляющий новый сегмент в очередь, был снят и по каким-то причинам долго не получает управление — ну и всё, вся очередь стоит, условие lock-free не выполняется.

Для чего-то реального это не годится, но у них на этой очереди сделана аж очередь тасков.

Хорошо хоть большинство тасков ставятся в очередь к тому же самому потоку, поэтому оно хоть как-то работает, т.е., если текущий worker-поток исполнения задач по каким-либо причинам не получает доступ к процессору, то уже не важно насколько успешно к нему в очередь становятся задачи. Но это просто специфика такая. При обычной перекачке данных из нескольких потоков в некий один поток-обработчик (один из самых популярных сценариев) он проигрывает во многие разы альтернативным решениям.

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

V>>Ты собираешься копировать тело target-метода делегата?
S>Я и так строю делегат.

Ты рассказывал, что копируешь тела делегатов для инлайна.
Ведь джит не инлайнит делегаты.

И никакие альтернативные компиляторы Expression никакие делегаты тоже не инлайнят, т.е. если лямбды будут использованы в условиях типа where.

Кстате, а где живут альтернативные компиляторы Expression?

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

V>Такие рассуждения уместны только если изменения необходимо делать видимыми остальным потокам.
Всё наоборот. Мне приходит ссылка на ImmutableList<T> — и я могу смело отдавать её в метод, асинхронно выполняемый в отдельном потоке.
И не беспокоиться о том, станет ли вызвавший меня что-то делать с этим списком.

V>Но тогда при обновлении некоей shared-ссылки всё-равно необходима или блокировка, или lock-free цикл.
Даже если бы у нас была некая shared ссылка, то её обновление сделать атомарным в разы проще, чем обеспечить безопасный конкурентный доступ к списку или словарю.

V>Ну вот я и экспериментировал с различными структурами и lock-free алгоритмами когда-то.
V>На поверку >90% оказалось фуфелом, особенно иммутабельные структуры (а как глаза когда-то загорелись, ты бы только знал).
Всякое бывает. Ещё и типы нагрузок сильно отличаются.

V>Такая маленькая блочность диктуется иммутабельной попыткой реализации, понятно, но противоречит концепции B+ деревьев.
Нет, такая блочность диктуется кэшем процессора. Концепции B+ деревьев она не противоречит.

V>Хорошо хоть большинство тасков ставятся в очередь к тому же самому потоку, поэтому оно хоть как-то работает, т.е., если текущий worker-поток исполнения задач по каким-либо причинам не получает доступ к процессору, то уже не важно насколько успешно к нему в очередь становятся задачи. Но это просто специфика такая. При обычной перекачке данных из нескольких потоков в некий один поток-обработчик (один из самых популярных сценариев) он проигрывает во многие разы альтернативным решениям.
Ну, тут как обычно — заводим проект на гитхаб, пилим альтернативное решение, показываем бенчмарки.
Не знаю про ConcurrentQueue, а вот штатную реализацию IImmutableList<T> обыграть не так то легко — несмотря на то, что она как раз написана "по учебнику", без малейших оптимизаций производительности.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, Serginio1, Вы писали:

S>> Я все про использование манагед кода на сервере и аля сингулярити мечтаю! То есть из маршалинга максимум копирование результата в памяти, можно просто результат сразу класть в определенную память.

НС>Тебе зачем? Какую реальную проблему ты хочешь этим решить?
Я как бывший 1С ник вижу огромные тормоза. Например https://forum.mista.ru/topic.php?id=871825
Желательно, что бы код сервера приложений был в адресном пространстве SQL и обмен аля сингулярити
В свое время была мечта написать свою бд. Но уже ...

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

S>Но со всеми этими строками (и массивами, varbinary)- сплошной головняк. Нормально сохранять в файл можно только довольно-таки сложные конструкции, что-то типа rope. А вот выставлять их наружу, в клиентский код, не хочется категорически.
Ну наружу то выставляются свойства, а уж внутри эти свойства будут обращаться через MemoryMarshal

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

V>>Тогда на верхнем уровне в любом случае виртуальность.
S>Нет конечно, не в любом. Все эти типы — struct, так что в коде нет ни одного виртуального вызова.

Перечитай фразу на которую отвечаешь внимательно, плиз.

Если у нас есть россыпь структур, которые реализуют некий интерфейс, то в любом случае потребуется адаптер для вызова методов интерфейса.
И таких адаптеров всего два — это встроенное боксирование, либо ручное:

interface ISomeAPI {
   void Foo();
}

struct S1 : ISomeAPI { ... }
struct S2 : ISomeAPI { ... }

class ManualBox<T> : ISomeAPI 
    where T : struct, ISomeAPI
{ 
    T _boxed;
    public void Foo() { _boxed.Foo(); }
}

V>>Попробую найти время, посмотреть на балансировку.
S>Да она там совершенно обычная, как в учебнике.

В учебнике при балансировке B+ дерева можно копировать значения в родительские сегменты, если в тех есть незаполненные ячейки.
Сам алгоритм мутабельный.

Но в иммутабельных структурах принято полностью иниализировать объекты в конструкторе, а тут надо будет разделить создание узла, наполнение и последующую иммутабельную эксплуатацию.


V>>Точная балансировка тем дороже, чем больше арность, потому что приходится создавать более дорогие копии при каждом изменении дерева.
S>Да, одиночные вставки могут подтормаживать; зато на AddRange можно немножко наиграть за счёт повторного использования.

Ага, тогда точно в конструкторе завершить инициализацию не выйдет.


V>>Ну вот как раз ради случая хеш-таблицы в хеш-таблицах всё и затевалось.
V>>Capacity каждой хеш-таблицы относительно невелик (23, 19, 17, 13, 11), пересоздавать при изменении достаточно одну таблицу, а не всю цепочку их до корневого узла, как оно есть в иммутабельных деревьях при балансировке.
S>Да, мысль хорошая. У меня задачи делать IDictionary<,> не стояло, а для IList<> B-дерево выглядит самой эффективной реализацией.

Только у тебя B+.
И еще тебе иммутабельность нужна не сама по себе, а как ср-во межпоточной реализации контейнеров.

Например, copy-on-write тоже пляшет от иммутабельных структур.

Например, взять сложные структуры, разбитые на сегменты (как B+ деревья или очереди с приоритетами, или простые двусторонние очереди с возможностями вставки-удалениях элементов из середины) — такие алгоритмы могут использовать copy-on-write "точечно", на уровне отдельных сегментов.

Например, копирование узлов до вершины при балансировке иммутабельного дерева не нужно, если не происходит перемещение значений м/у уровнями или разбиениях и обновление индекса вверх.

Потому что для перечисленного набора ограничений чистая иммутабельность не диктуется, а разве что выбирается как ср-во решения задачи.
А диктуется лишь атомарность/транзакционность при внесении изменений, т.е. согласованность данных при чтении.

На каком-то уровне изменений для B+ дерева достаточно будет через lock-free цикл обновить ссылку на дочерний узел, например, при вставке в конец.
Или при вставке в середину можно создавать копии только части узлов при провижении наверх.


V>>Самый простой вариант — складывать конфликты в упорядоченный список (массив конфликтующих значений).
S>Да, именно этот вариант первым приведён у Кнута, емнип.

Но этот вариант имеет плохой лейаут в памяти, если не использовать кастомный пул-аллокатор.
Поэтому, дотнетный вариант реализован иначе.

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

S>Я плохо знаком с миром ФП, и пока что до меня не доходит, каким волшебным образом memoize поможет сделать из мутабельной хеш-таблицы эффективную иммутабельную.

Хеш-таблицы у меня были не иммутабельные, а просто не блокирующие.

Необходимо получить ссылку на пару { хеш, ссылка-на-дочернюю-таблицу } из родительской таблицы и в этой паре через CAS в цикле обновить ссылку для указания на новый экземпляр дочерней хеш-таблицы.

Цикл возникает при неудачном обновлении, т.е. если по данному хеш-коду конкурирующий поток уже внёс изменения в эту же пару в родительcкой таблице, тогда подготовленный сегмент отбрасывается и создаётся заново с заходом на новый cas.

При такой реализации N-арность уменьшает вероятность возникновения конфликтов в каждой отдельной паре.

Но, повторюсь, чем больше арность, тем больше данных копируется при создании копии сегмента, поэтому, подбор N стоит делать для вполне конкретного множества сценариев.

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

S>Классика жанра — рекурсивные алгоритмы. Я в каждую ветку рекурсии передаю копию "текущего" словаря, тот его модифицирует и передаёт дальше. Благодаря иммутабельности у меня бесплатные откаты.

Ну, откаты, т.е. версионность — это дополнительное требование.

Здравствуйте, vdimas, Вы писали:
V>Ты рассказывал, что копируешь тела делегатов для инлайна.
V>Ведь джит не инлайнит делегаты.
Это было в пред-предыдущей версии Linq2d, которая была выкинута на помойку. Уж очень она была убогая по возможностям и производительности.
С честными делегатами невозможно адски тяжело делать простые вещи типа векторизации или автоматической замены значения константой.
Поэтому уже чуть больше года как в аргументах linq2d выражений используются не делегаты, а деревья выражений.

V>И никакие альтернативные компиляторы Expression никакие делегаты тоже не инлайнят, т.е. если лямбды будут использованы в условиях типа where.
Ну вот как раз инлайн делегатов — штука относительно простая, но результирующий MSIL слишком плох для практического использования.

Но у меня гораздо более простая задача — вместо "инлайна делегатов" я могу брать деревья выражений. Их инлайнить несравненно проще — этим занимается каждый первый проект, использующий Expression Trees.
И вообще, любые потребные мне трансформации я могу делать сам перед тем, как отправить полученное дерево в Expression.Compile.


V>Кстате, а где живут альтернативные компиляторы Expression?
Как и всё — в гитхабе

https://github.com/dadhi/FastExpressionCompiler

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

НС>>Тебе зачем? Какую реальную проблему ты хочешь этим решить?
S> Я как бывший 1С ник вижу огромные тормоза. Например https://forum.mista.ru/topic.php?id=871825

Не буду читать эту простыню. Из заголовка — речь про IO, отсутствие межпроцессного маршалинга тут не спасет.

S>Желательно, что бы код сервера приложений был в адресном пространстве SQL

Это какой то бред. SQL сервер это отдельная машина, иначе смысла нет.

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

V>Если у нас есть россыпь структур, которые реализуют некий интерфейс, то в любом случае потребуется адаптер для вызова методов интерфейса.
V>И таких адаптеров всего два — это встроенное боксирование, либо ручное:
V>

V>interface ISomeAPI {
V>   void Foo();
V>}

V>struct S1 : ISomeAPI { ... }
V>struct S2 : ISomeAPI { ... }

V>class ManualBox<T> : ISomeAPI 
V>    where T : struct, ISomeAPI
V>{ 
V>    internal T _boxed;
V>    public void Foo() { _boxed.Foo(); }
  V>}
V>

Всё правильно. Внутри ManualBox<T>.Foo лежит вполне себе невиртуальный вызов T.Foo().
А при дальнейшем цепочка строится из наших ManualBox<T> примерно так:

struct SM<T>: ISomeAPI
  where T: struct, ISomeAPI
{
...  
  private Children: ManualBox<T>[];
  public void Foo() { Children[0]._boxed.Foo(); }
}

В итоге, когда JIT строит код SM<S1>.Foo(), у него тоже нет ни одного виртуального вызова. И вообще, весь ManualBox нам нужен только для того, чтобы заставить SM<S1> хранить массив ссылок на S1, а не массив копий S1. И при этом продолжать обращаться к Foo детишек невиртуально.

И это работает, пока в цепочке не появляются одноимённые классы — к примеру, код this[] для BranchNode<LeafNode<int>, int> прекрасно инлайнится целиком — потому, что там внутри идут обращения к Box<LeafNode<int>>.Value, точный тип которого виден джиту.


V>В учебнике при балансировке B+ дерева можно копировать значения в родительские сегменты, если в тех есть незаполненные ячейки.
Не совсем так. Это вы про B-дерево пишете. В B+ все значения лежат только в листьях, поэтому в родителей ничего не копируется никогда.
V>Сам алгоритм мутабельный.
Мутабельное дерево очень легко превратить в иммутабельное путём порождения копий узлов вместо модификаций. Конкретно B-деревья прекрасно к этому адаптируются, т.к. там и так постоянно возникают ситуации типа "ой, давайте заменим этот 1 лист на 2 вот этих" и наоборот.
V>Но в иммутабельных структурах принято полностью иниализировать объекты в конструкторе, а тут надо будет разделить создание узла, наполнение и последующую иммутабельную эксплуатацию.
Это всё тривиально реализуется в конструкторе, который принимает коллекцию, при помощи флагов заморозки на уровне узлов.
То есть в процессе "наполнения" дерево мутабельное, но перед тем, как отдать ссылку на него наружу, все его узлы замораживаются.

V>Ага, тогда точно в конструкторе завершить инициализацию не выйдет.
В конструкторе дерева — выйдет. А конструктор узла никого не интересует — это подробность реализации.

V>И еще тебе иммутабельность нужна не сама по себе, а как ср-во межпоточной реализации контейнеров.
Ну не обязательно. У меня вообще не стояло никакой прикладной задачи, для которой нужна была бы иммутабельность. Стояла значительно более приземлённая задача — обыграть System.Collections.Immutable.ImmutableList.
Парни из TunnelVision пришли к той же идее, что и я, но их реализация недостаточно оптимизирована. Abstraction Penalty у них сожрало весь выигрыш от cache friendliness и уменьшения глубины дерева.

V>Например, взять сложные структуры, разбитые на сегменты (как B+ деревья или очереди с приоритетами, или простые двусторонние очереди с возможностями вставки-удалениях элементов из середины) — такие алгоритмы могут использовать copy-on-write "точечно", на уровне отдельных сегментов.
Так и делается.

V>Например, копирование узлов до вершины при балансировке иммутабельного дерева не нужно, если не происходит перемещение значений м/у уровнями или разбиениях и обновление индекса вверх.
Так и делается.

V>На каком-то уровне изменений для B+ дерева достаточно будет через lock-free цикл обновить ссылку на дочерний узел, например, при вставке в конец.
V>Или при вставке в середину можно создавать копии только части узлов при провижении наверх.
Так и делается — клонируются ровно те узлы, которые входят в путь от изменяемой ячейки к корню. Независимо от операции — вставка, удаление, изменение.
Всего log(N) копий, что значительно дешевле, чем вставлять в середину copy-on-write массива.

V>Но этот вариант имеет плохой лейаут в памяти, если не использовать кастомный пул-аллокатор.
V>Поэтому, дотнетный вариант реализован иначе.
Возможно, поэтому. Может, из-за других причин. Я свечку не держал, точно сказать не могу.

Здравствуйте, vdimas, Вы писали:
V>Хеш-таблицы у меня были не иммутабельные, а просто не блокирующие.
Это не к вам вопрос, а к НС. Он владеет какой-то ФП-магией, которая мне непонятна.

Здравствуйте, Ночной Смотрящий, Вы писали:

S>>Желательно, что бы код сервера приложений был в адресном пространстве SQL

НС>Это какой то бред. SQL сервер это отдельная машина, иначе смысла нет.
Отдельная машина это еще бОльшие тормоза. Проблема в том, что в сложных алгоритмах нельзя одним запросом вытащить все данные.
И приходится получить данные обработать послать следующий запрос итд. А в конце когда данные подготовлены послать данные на сервер для записи.
Вот если всю эту беду делать в пространстве сервера, домене или аля сингулярити скорость резко возрастет.
Да для простых алгоритмов плюс всякие редисы скорости хватает, но вот в более навороченных учетных системах бухгалтерского учета все достаточно сложнее.
И в оракуле и в MSSQL можно делать ХП на манагед языке. Но в примерах только простые вещи типа регулярных выражений итд.
Хотелось бы примеры тиgа EF или Linq2DB
И может убивца 1С можно сделать

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

НС>>Очевидно — никак. А должны были?
I>Именно. И с наследованием ровно так же.

Да, так же. И что?

I>>>Это нарушение всех принципиов вместе взятых
НС>>Нет.
I>Тут стоит посмотреть Skott Meyers, Herb Sutter, Bertrand Meyer, начало 90х. Чем больше методов — тем сильнее нарушается инкупсуляция.

Нет там такого.

I>>>С глубокой иерархией интерфейсов все ровно так же.
НС>>Нет.
I>И никакого обоснования, как будто это и так ясно. Аргументы будут?

О, заметил наконец. Теперь можно посмотреть на свои утверждения и задать себе тот же вопрос.

I>>>Например, если в иерархии, построеной на иммутабельный принципах
НС>>Иммутабельность никогда не была тем, что ОО контракты гарантируют.
I>Возьми любое другое свойство, например тот самый метод add.

Нет, надо взять то, что таки ОО контракты гарантируют. Только смысл сего действа непонятен.

I>>>А вот смысл конкретной абстрации вполне себе может быть в иммутабельности.
НС>>При чем тут наследование и интерфейсы?
I>Тебе интерфейсы для чего нужны?

А мне они нужны?

I>>>Именно — не может. А раз не язык даёт гарантии, то кто их предоставит?
НС>>Ну да, вернулись к "раз мы всех воров поймать не можем, то нефик их вообще ловить".
I> Всё проще фича extends это плохое решение, которое плохо решает три задачи — subtype, переиспользование и композицию. А нужны раздельные языковые конструкции для каждого аспекта.

И ровно это я с самого начала и написал. Ты с чем споришь то?

I>Вот чудо — и тут интерфейсы облажались

И?

I> Почему же ты ждешь чего то большего от наследования?

С чего ты решил, что я жду? Ты опять споришь с воображаемым собеседником.

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

НС>>Это какой то бред. SQL сервер это отдельная машина, иначе смысла нет.
S>Отдельная машина это еще бОльшие тормоза.

Разумеется. Важнее то, что никакие сингулярити тебя от этих тормозов не спасут.

S> Вот если всю эту беду делать в пространстве сервера, домене или аля сингулярити скорость резко возрастет.

Ну так попытки засунуть жабу или дотнет вовнутрь сиквела были, чего тебя в них не устраивает?

S>И может убивца 1С можно сделать

Нельзя. 1С такой популярный не из-за его технологий.

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

V>>Но тогда при обновлении некоей shared-ссылки всё-равно необходима или блокировка, или lock-free цикл.
S>Даже если бы у нас была некая shared ссылка, то её обновление сделать атомарным в разы проще, чем обеспечить безопасный конкурентный доступ к списку или словарю.

Ну вот внутри MulticasDelegate обычный дотнетный массив, который обновляется по схеме copy-on-write.
Абсолютно безопасно.

Причём, ввиду того, что там всё-равно lock-free цикл и в массиве null может считаться как пустая ячайка, не обязательно каждый раз пересоздавать массив на точное кол-во элементов, можно увеличивать его, например, вдвое при добавлении элементов, если пустых ячеек уже нет.


V>>Ну вот я и экспериментировал с различными структурами и lock-free алгоритмами когда-то.
V>>На поверку >90% оказалось фуфелом, особенно иммутабельные структуры (а как глаза когда-то загорелись, ты бы только знал).
S>Всякое бывает. Ещё и типы нагрузок сильно отличаются.

Разница в разы.
Хотя, если ты рассуждаешь о версионности, т.е. о дополнительной функциональности, то там иммутабельность рулит, ес-но.

Но в "обычных случаях", например, когда кешируются справочные данные, должные быть доступными из разных потоков, там другие подходы эффективнее кратно.



V>>Такая маленькая блочность диктуется иммутабельной попыткой реализации, понятно, но противоречит концепции B+ деревьев.
S>Нет, такая блочность диктуется кэшем процессора.

Размером линейки кеша, ты хотел сказать?
Самые ходовые 64 байта, у продвинутых 128 байт.
Оба раза всё-равно меньше размера твоего узла.
И в этих делах не только размер играет роль, но и выравнивание.

Например, часть памяти твоей иммутабельной структуры залезло на линейку кеша, где живёт мутабельная переменная — получи трафик когерентности и тормоза даже для иммутабельных данных.
Необходимо для классов верхнего уровня, в которых хранятся структуры, расставлять выравнивание через [StructLayout)], дополнительно указывать размеры структур-классов кратными размеру линейки кеша в этом же аттрибуте.


S>Концепции B+ деревьев она не противоречит.

Ну, изначально B+ деревья разрабатывались под куда как большие размеры блоков, чем 64 байта.


V>>Хорошо хоть большинство тасков ставятся в очередь к тому же самому потоку, поэтому оно хоть как-то работает, т.е., если текущий worker-поток исполнения задач по каким-либо причинам не получает доступ к процессору, то уже не важно насколько успешно к нему в очередь становятся задачи. Но это просто специфика такая. При обычной перекачке данных из нескольких потоков в некий один поток-обработчик (один из самых популярных сценариев) он проигрывает во многие разы альтернативным решениям.
S>Ну, тут как обычно — заводим проект на гитхаб, пилим альтернативное решение, показываем бенчмарки.

Тю, там придётся весь механизм тасков переделывать, включая реализацию work stealing и учитывая тот факт, что пул IO-потоков, поток таймеров — это отдельные потоки, не пересекающиеся с пулом потоков для тасков.

У нас в нейтиве один пул потоков, равный кол-ву всех ядер.


S>Не знаю про ConcurrentQueue, а вот штатную реализацию IImmutableList<T> обыграть не так то легко — несмотря на то, что она как раз написана "по учебнику", без малейших оптимизаций производительности.

Во сколько раз и какие операции у тебя получились быстрее?

В дотнете AVL-дерево, оно проигрывает красно-чёрному при мутирующем ребалансе, но при немутирующем, требующем воссоздания родителей до корня, красно-чёрные не имеют преимуществ.

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

V>>Хеш-таблицы у меня были не иммутабельные, а просто не блокирующие.
S>Это не к вам вопрос, а к НС. Он владеет какой-то ФП-магией, которая мне непонятна.

Ты просто неверно меня понял. Я тебе говорил не про то что есть какая то магия, а про то что в ФП от необходимости использовать словари явно уходят в пользу замены их использования на паттерн Memoize. Т.е. то что ты хранишь в словаре в ФП вычисляется каждый раз при обращении, а чтобы не вычислять каждый раз одно и тоже используют memoize.

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

V>Тю, там придётся весь механизм тасков переделывать, включая реализацию work stealing и учитывая тот факт, что пул IO-потоков, поток таймеров — это отдельные потоки, не пересекающиеся с пулом потоков для тасков.

Ты пока без тасков, просто лучший вариант ConcurrentQueue попробуй сделать.