я хз не следил в чем вопрос был

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

и чем плохо выгружать домен?

а то и просто сделать на двух процессах

Read only хотя бы, немутабельные данные

Я и говорю - грузи в основной. 2 домена использовать - это если "пром" и "критичны утечки" (ну и "так есть хорошо")

А ты данные меняешь?

Ну загрузил я данные в виде огромного объекта в один домен, а текущую версию софта - анализа в другой. Но доступ из 2го в первый то - сериализация, оверхед - я умру раньше чем расчёты закончатся.

Данные не меняю (пусть так)

Сколько занимает у тебя их копирование в памяти?

Клонирование?

Считать их с рам диска сколько времени требует?

~ну десятки минут

десяток

Короче я выяснил, что обмен между AppDomain это всегда сериализация , что крайне затратно для 20гб структур в памяти, а подгруженную к AppDomain с данными сборку, выгрузить невозможно, нет в нете такого...

можно без сериализации, но есть риск получить бубух

Или у тебя данные на диске а потом ты их в объектную модель переводишь?

да именно так

вся модель переводится на struct-ы НЕ содержащие ссылок на reference-типы

обращение к другим элементам модели по принципу тип+индекс

Сделай бинарную сериализацию готовых объектов на диск

это даст возможность сделать структуру данных, которая позиционно-независима

т. е. может находиться по любому смещению в оперативке

это всё счастье запихивается в файл на рамдиске именно в таком виде

после чего делается маппинг файла в память

и обращение к данным через unsafe по указателям

не уверен, что это будет достаточно эффективно под виндой

там рамдиски не интегрированы нормально с маппингом файлов

Сделай бинарную сериализацию готовых объектов на диск

да делал, стандартным бинарным сериализатором, выйгрыш есть раза в 2, но появляется другой геморой - нужно теперь жить с этим форматом, возникает усложнение пайплайна, а что 10 минут что 5 - многовато, для по факту исследовательской (над данными) работы

либо изначально делать именованый маппинг

и держать его в оперативке третьим процессом

это даст возможность сделать структуру данных, которая позиционно-независима

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

основная проблема использования маппинга - он не дружит с указателями от слова совсем

по-моему, еще на clrium сидристый как-то развлекался с shrared memory

поэтому имеет смысл вместо них использовать индексы

но я не помню, было там в итоге что-то полезное или нет.

да делал, стандартным бинарным сериализатором, выйгрыш есть раза в 2, но появляется другой геморой - нужно теперь жить с этим форматом, возникает усложнение пайплайна, а что 10 минут что 5 - многовато, для по факту исследовательской (над данными) работы

Это медленно слишком вот https://maxondev.com/serialization-performance-comparison-c-net-formats-frameworks-xmldatacontractserializer-xmlserializer-binaryformatter-json-newtonsoft-servicestack-text/

мдя, C# явно не заточен под такие задачки...

>сидристый подойди на дотнексте к акиньшину и спроси, что он думает о сидристом

мдя, C# явно не заточен под такие задачки...

а тут без избавления от указателей (reference-типов в терминологии C#) вообще никак

хоть на каком языке пиши

https://github.com/mapbox/tmpfs-mmap-zero-copy

для интереса упражнения с линуксовым аналогом рамдиска

который tmpfs

ты с калькулятора?

ты с калькулятора?

Это вообще-то мой домашний пк

вообще операционки с попроцессной виртуальной памятью этим всем страдают

в этом плане в WinCE была очень хорошая модель памяти

>сидристый подойди на дотнексте к акиньшину и спроси, что он думает о сидристом

интригискандалы, енто не про меня) https://github.com/mumusan/dotnetex/blob/master/Basic/03_appdomain/Program.cs#L39 вот такой штукой в итоге можно пробросить объект или нет. не помнишь?

можно было выделить кусок, который _всем_ процессам виден по одному адресу

а у кого win под рукой есть? сколько там калькулятор жрет?

мало

старый в смысле

который на обычном винапи

новый хипстерский много

я похоже нашёл тему http://geekswithblogs.net/akraus1/archive/2012/07/25/150301.aspx

да, так можно, но есть риск получить бубух

ну вот qalculate у меня тоже много жрет

но он на стероидах

но выглядит как хак и дыра в нете, чем даже не-продакшн решение

12mb хипстерский на винде

история. мат ф-ии и еще всякая хрень

дешевле не заморачиваться с доменами вообще

а просто грузить новую сборку в главный домен каждый раз

Можно извратиться и в домене с данными грузить ремоутингом (тем, древним) логику из второго процесса. Тогда сериализовать по идее ничего не надо.

ремоутинг работает через BinaryFormatter

если кому-то много жрет - есть bc

если кто не в курсе

ERROR: S client not available

дешевле не заморачиваться с доменами вообще

похоже да, так.... тем паче что код то очень компактный

И что?

сериализация в итоге будет и тормоза

вообще эта

Может зайти с другой стороны?

Что у тебя там за анализ?

Можно извратиться и в домене с данными грузить ремоутингом (тем, древним) логику из второго процесса. Тогда сериализовать по идее ничего не надо.

А он не deprecated с концами разве?

Я написал изнутри того домена с данными грузить классы второго домена без данных

в дотнеткоре вроде научился GC собирать ненужные сборки

можно на него перелезть

а просто грузить новую сборку в главный домен каждый раз

как ты два раза в домен сборку загрузишь

Может зайти с другой стороны?

Если заходить с этой стороны, я сломаю всем голову :)

А он не deprecated с концами разве?

Чо это, куча энтерпрайз софта ещё работает на нем

А что все таки за анализ то?

Может sql и без разницы сколько данных?

https://github.com/dotnet/coreclr/issues/552

а, нет, не допилили

как ты два раза в домен сборку загрузишь

через Assembly.Load

А что все таки за анализ то?

Нене, Sql там не пахнет, многомерные матрицы, графы, всё сильно связанно. Я поэтому даже на hadoop распилить не могу. Всё одним куском.

https://github.com/dotnet/coreclr/issues/552#issuecomment-270227626

Воооо

Собираешь .NET Core с этими патчами

и оно будет выгружать неиспользуемые сборки

через Assembly.Load

ему сборку переименовывать каждый раз или как ты одну сборку с логикой будешь подргужать при обновлении ее?

из байтмассива всегда заново грузится

ему сборку переименовывать каждый раз или как ты одну сборку с логикой будешь подргужать при обновлении ее?

да придётся переименовывать

Не пробовал другой сериализатор? Побыстрее какой нить

и всегда новая

из байтмассива всегда заново грузится

да с байтмассивом даже dll-ка не лочится

даже если точно такая же уже есть

я так делал облачный grid computing, слал сборку в узла сети:) наколеночный grid computing

я так делал облачный grid computing, слал сборку в узла сети:) наколеночный grid computing

на этом принципе вроде mbrace основан