Есть потребность в реализации высокопроизводительного алгоритма для математических вычислений на основе данных MSSQL. Результаты вычислений так же сохраняются в MSSQL.

Первая версия алгоритма реализована на T-SQL. Оптимизация программы показала невозможность избавиться от операций записи в журнале транзакций даже при отказе от использования физических таблиц в процессе расчета. Вывод - вынести расчет за пределы SQL Server.

Вторая версия алгоритма реализована на C# в виде CLR-сборки (Safe/DLL) под .Net 3.5. Производительность повысилась на несколько порядков. Однако ряд ограничений C# не позволяет добиться максимума производительности.
1. Сборщик мусора не позволяет самостоятельно удалять объекты, а их в процессе вычислений создается целая куча -> перерасход памяти.
2. Тип структур является типом данных и не может быть использован для построения индексных массивов (с элементами типа ссылки на структуру), что приводит к использованию классов вместо структур, а значит перерасходу памяти и возможному снижению производительности.
3. Требуется кодогенерация (переопределение математических функций) при создании экземпляра объекта. В C# - это делегаты, анонимные и лямбда-методы. В С++ это просто ссылка на функцию. Существует большое отличие с точки зрения производительности при использовании этих подходов.
4. Судя по тестам в Интернете C# существенно уступает С++ в производительности математических программ.
Вывод - сделать CLR-сборку на C++.

Проблема в том, что в VS2012 ultimate я не нашел типа проекта SQL CLR для VC++. Есть только шаблон SQL Server для C# и VB.NET. Когда я пытался собирать DLL на базе шаблона C++ CLR, то какие бы я ни ставил настройки компилятора, MSSQL2008 всегда отказывался импортировать сборку по самым разным причинам.

Вопросы:
1. Что думаете по поводу описанных выше недостатков C#. Я не писал на нем ранее, поэтому могу многого не знать и делать неверные выводы.
2. Был ли опыт создания CLR-сборок для MSSQL на C++? На MSDN есть примеры кода для VS2008, которые не работают в VS2012. Неужели нужно даунгрейдить VS???
3. Стоит ли использовать связку MSSQL->CLR на C#->DLL на C++? Здесь C# будет использоваться только для обращения к БД и передаче данных в DLL на C++ для вычислений.

Буду признателен, если укажете ссылки на тематические статьи в Интернете или примеры кода/настроек компилятора VC++.
Спасибо!

xstoredandreybs,

Я бы не заморачивался с CLR а создал бы обычную extended stored procedure на C

Я тоже сначала думал проапгрейдить SQL до 2012 и использовать его возможности инлайн-процедур. Но одной процедурой не обойтись. И сохранять промежуточные результаты нужно в независимой области памяти для быстрого повторного обращения к ним. Все таки это должна быть внешняя библиотека.

ИзопропилandreybsИ сохранять промежуточные результаты нужно в независимой области памяти для быстрого повторного обращения к ним.
ещё один источник геморроя с CLR

Проблема только в неуправляемости процессом освобождения памяти. Там есть свои "лазейки", но в С++ это делается просто и наглядно. Поэтому и хочется найти возможность собрать CLR-сборку на С++.

Изопропилandreybs,

соберите её без всяких визардов, как unsafe регистрируйте на сервере

Пробовал, не получилось. SQL Server в этом случае ругается, что сборка не является нативной .NET (хотя я использовал библиотеки .Net 2.0.0.0).

ИзопропилandreybsSQL Server в этом случае ругается, что сборка не является нативной .NET
регистрируемая сборка должна компилироваться с /clr:pure, а дальше эта сборка может уже обращаться к нормальному коду через P/Invoke

Начиная с MSSQL2005 это не поддерживается для VC++, если верить MSDNу

MasterZivandreybsпропущено...


Проблема только в неуправляемости процессом освобождения памяти. Там есть свои "лазейки", но в С++ это делается просто и наглядно. Поэтому и хочется найти возможность собрать CLR-сборку на С++.

А тебе зачем собственно CLR ?

Потому что вызов пересчета должен происходить изнутри SQL Server, а он использует либо CLR, либо unsafe сборки. Последнее заколебешься дебагить в случае ошибки. Хотя и это ограничение можно обойти, собрав простое консольное приложение на С++ (в перспективе виндовс-сервис), которое лезет в сиквел и делает тоже самое, что и CLR на C#. Но тут сложность - как управлять этим консольным приложением. В конечном счете основную часть кода можно будет вынести в DLL и дебагить ее с помощью вызова из консольного приложения, а в рабочем режиме эта DLL будет цепляться к SQL как unsafe сборка с external или unrestricted access. Как то так, но до этого еще не скоро. Сначала отлажу алгоритм на C# и посмотрю на результаты. Может овчинка выделки не стоит...

ИзопропилandreybsНачиная с MSSQL2005 это не поддерживается для VC++, если верить MSDNу
Поддерживается (сборки /clr:pure)


Технически да, поддерживаются, но с целым рядом ограничений , которые в моем случае не позволят обеспечить прямое взаимодействие SQL<->DLL, только через интерфейсную прослойку SQL<->DLL/CLR<->DLL/Unmanaged. Это возможно, но очень геморно с точки зрения дебагинга, о чем я писал выше. Если проигнорировать ограничения, то при импорте такой DLL/CLR MSSQL выдаст ошибку - "unsupported clr code", а если /pure заменить на /safe, то даже не используя элементы unmanaged code все равно при импорте вылетает ошибка " assembly not supported " вне зависимости от того, на базе какой версии .Net это все собрано.


ИзопропилUNSAFE enables assemblies unrestricted access to resources, both within and outside an instance of SQL Server. Code running from within an UNSAFE assembly can call unmanaged code.
http://msdn.microsoft.com/en-us/library/ms189524.aspx

P.S. крики о deprecated extended stored procedure слышны уже много лет

Да понятно, но лично я не встречал юзабельных возможностей по поддержке deprecated SP в mssql. Говорят, в 2012 они тали лучше. Не знаю, посмотрим. Но судя по документации, в которой нет примеров на c++, только c# и asp.net, Майкрософт развивает свою технологию clr в связке с .Net и им нафиг сдалось поддерживать c++ с его unmanaged кодом. Так что писать библиотеки для mssql на c++ становится все сложнее и сложнее.

ИзопропилВопрос замены сервера на PostgeSQL не рассматривался?

Не рассматривался. В MSSQL реализованы алгоритмы обработки данных, на базе которых далее производятся вычисления. Объемы данных довольно большие. Тут нужна мощная СУБД.

MasterZivandreybs,

Про С++ тут нет ничего. Перенесу тему в C#, если нет возражений.

Не возражаю.

Модератор: Тема перенесена из форума "C++".

Изопропилandreybs, что приводит к использованию классов вместо структур, а значит перерасходу памяти и возможному снижению производительности.
сколько байтов считали?

Добавляет ли readonly property к размеру класса?

Точно не считал, но оптимизировал как мог, чтобы сохранить читабельность кода при минимуме размеров. В итоге получилась примерно такая модель:

struct D
{
... 5-7 переменных типа Int32 и Double
}

Class C
{
T Parent; // ссылка на родительский объект
List<T> Links; // 10-20 связей на каждый объект
D Data; // структура с данными
C(...) { конструктор }
}

Выделил 4 типа данных T, для каждого из которых применил подобную модель. Всего одновременно живет до 1000 объектов (пока, в перспективе до 10000). За счет перекрестных ссылок все данные представлены одновременно в иерархическом/сетевом (для вычислений) и плоском представлении (для импорта/экспорта). Все управление классами делается на базе внешнего статического класса (экономим на таблице методов в каждом классе). Использовать структуры не получится, т.к. для создания перекрестных ссылок нужно ссылаться на объект из нескольких индексных массивов одновременно.

В этом все деле меня больше всего интересует освобождение памяти после отчуждения объектов (на примере класса выше):
1. Нужно ли ставить Parent=null, чтобы разорвать сильные связи объектов и облегчить работу сборщика мусора.
2. Нужно ли ставить Links.Capacity=0 после очистки массива, чтобы высвободить память для повторного использования новым объектом.

ИзопропилWinnipuhSQLCLR есть и надо пользоваться.
так топикстартеру не нравится.

Я не против. Но хотел бы сделать это на С++. Но собрать сборку, которую схавает SQL пока не получилось.