Доброго дня всем.
Кто нибудь знает, как сделать сабж?
Нагуглил вот это : http://www.tangiblesoftwaresolutions.com/?gclid=CNeQqPjz45wCFVWF3godKjU3Gw
но демка так ничего и не сконвертила.

Корни проблемы растут вот откуда. Есть у меня своя либа на C#, в которой реализованы алгоритмы обработки изображения.
Алгоритмы юзают OpenCV (т.е. сделаны .NET обертки над CvMat, CvArr и другими типами OpenCV).
В целом получается очень даже удобно экспериментировать с алгоритмами, юзать любые фичи OpenCV. Намного проще чем колбасить код
на С/С++, особенно если учесть что опыта на С практически нет.
Перфоманс на стадии экспериментов меня вполне устраивает.

Начал дальше работать над перфомансом и вот проблема: unsafe код, работающий напрямую с указателями (double*) работает все равно медленее чем тот же код (один в один) написаный и скомпиленный в нативной dll (даже с затратами на интероп). Не понимаю почему, ведь чисто unsafe код, без использования .NET массивов и других классов..

Остается один выход — узкие места переносить в нативный С++ код. А это ведет к копипасту (полному или частичному) классов из C# кода в С++.
Отсюда желание как то это автоматизировать. Ведь если в коде нет использования чисто .NET-овских классов — то это вообшще должно быть просто.

Кто что думает? Переходить полностью на С++ у меня нет ни желания ни времени.

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

_>Кто что думает? Переходить полностью на С++ у меня нет ни желания ни времени.

Ты уже посмотрел профайлером, где именно самое медленное место в коде?

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

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

_>>Кто что думает? Переходить полностью на С++ у меня нет ни желания ни времени.

N>Ты уже посмотрел профайлером, где именно самое медленное место в коде?

Конечно, dotTrace юзал.

Тормоза например на поэлементной обработке матриц (в цикле проходим по строкам и постолбцам).
Сначала делал это также как пишут в доках к OpenCv:

a_ij = ((double*)(mat.data.Ptr + mat.step * i)[j]
— медленно, главная проблема — приведение к (double*)

потом сделал для каждой матрицы предварительное формирование массива указателей строк (т.е. массив double*[])
— стало быстрее.
Перейти на double** думаю не сильно ускорит.

В общем проверено, unsafe код на .NET не компилится в эффективный нативный код (в райнтайме имею ввиду когда IL->машинный код).

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

_>a_ij = ((double*)(mat.data.Ptr + mat.step * i)[j]
_>- медленно, главная проблема — приведение к (double*)

а какого типа (mat.data.Ptr + mat.step * i)?

Здравствуйте, Пельмешко, Вы писали:

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

_>>a_ij = ((double*)(mat.data.Ptr + mat.step * i)[j]
_>>- медленно, главная проблема — приведение к (double*)

П>а какого типа (mat.data.Ptr + mat.step * i)?

public double*[] DoubleRows
{
get
{
if (_doubleRows == null)
{
_doubleRows = new double*[_matHeader.rows];
for (int i = 0; i < _matHeader.rows; i++)
{
_doubleRows[i] = (double*)((int)_matHeader.data + _matHeader.step * i);
}
}
return _doubleRows;
}
}
— это способ работы с матрицой, самый быстрый который я нашел.

Здравствуйте, barn_czn, Вы писали:
_>Тормоза например на поэлементной обработке матриц (в цикле проходим по строкам и постолбцам).
_>Сначала делал это также как пишут в доках к OpenCv:

_>a_ij = ((double*)(mat.data.Ptr + mat.step * i)[j]
_>- медленно, главная проблема — приведение к (double*)
Непонятно, почему вы не хотите использовать арифметику указателей.
Примерно так:

double* ptr = (double*)mat.data.Ptr;
for(int i = 0; i<rowCount; i++)
  for(int j = 0; j<colCount; j++)
  {
    a_ij = *ptr;
    ptr++; // 
  }

Здесь нет приведений к *double внутри цикла.

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


_>Начал дальше работать над перфомансом и вот проблема: unsafe код, работающий напрямую с указателями (double*) работает все равно медленее чем тот же код (один в один) написаный и скомпиленный в нативной dll (даже с затратами на интероп). Не понимаю почему, ведь чисто unsafe код, без использования .NET массивов и других классов..

Оптимизация, однако. Если вместо VC++ взять Intel C++ — может, еще немного выиграешь.

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

S>Здравствуйте, barn_czn, Вы писали:
_>>Тормоза например на поэлементной обработке матриц (в цикле проходим по строкам и постолбцам).
_>>Сначала делал это также как пишут в доках к OpenCv:

_>>a_ij = ((double*)(mat.data.Ptr + mat.step * i)[j]
_>>- медленно, главная проблема — приведение к (double*)
S>Непонятно, почему вы не хотите использовать арифметику указателей.
S>Примерно так:
S>

S>double* ptr = (double*)mat.data.Ptr;
S>for(int i = 0; i<rowCount; i++)
S>  for(int j = 0; j<colCount; j++)
S>  {
S>    a_ij = *ptr;
S>    ptr++; // 
S>  }
S>

S>Здесь нет приведений к *double внутри цикла.

Объясняю. Строки в матрицах, в битмапах, практически во всех либах не следуют друг за другом.
Они следуют с некоторым постоянным смещением.

a_ij = ((double*)(mat.data.Ptr + mat.step * i)[j]

— здесь mat.step не я придумал, так Intel задумал, и очень правильно сделал.

Какой в этом смысл? Во первых выравнивание в памяти. Поправте меня если я не прав но кажется это как то влияет на перфоманс.
Во вторых это возможность из матриц (битмапов) извлекать подматрицы (думаю сами поймете как).

Очень жаль что в .NET не сделали такой возможности с массивами: например неплохо было бы даже из одномерных массивов извлекать подмассив без копирования в другой. Но это я уже не по теме.

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

_>Объясняю. Строки в матрицах, в битмапах, практически во всех либах не следуют друг за другом.
_>Они следуют с некоторым постоянным смещением.

_>a_ij = ((double*)(mat.data.Ptr + mat.step * i)[j]
_>- здесь mat.step не я придумал, так Intel задумал, и очень правильно сделал.
Прекрасно. Немножко перепишем код:

double* rowStart = (double*)mat.data.Ptr;
for(int i = 0; i<rowCount; i++)
{
  double* ptr = rowStart;
  for(int j = 0; j<colCount; j++)
  {
    a_ij = *ptr;
    ptr++; // 
  }
  rowStart += mat.Step/sizeof(double); // вы почему-то избегаете приводить объявление mat и его мемберов. приходится угадывать.
}

По-прежнему никаких приведений. Что говорит профайлер?

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

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

_>>Объясняю. Строки в матрицах, в битмапах, практически во всех либах не следуют друг за другом.
_>>Они следуют с некоторым постоянным смещением.

_>>a_ij = ((double*)(mat.data.Ptr + mat.step * i)[j]
_>>- здесь mat.step не я придумал, так Intel задумал, и очень правильно сделал.
S>Прекрасно. Немножко перепишем код:
S>

S>double* rowStart = (double*)mat.data.Ptr;
S>for(int i = 0; i<rowCount; i++)
S>{
S>  double* ptr = rowStart;
S>  for(int j = 0; j<colCount; j++)
S>  {
S>    a_ij = *ptr;
S>    ptr++; // 
S>  }
S>  rowStart += mat.Step/sizeof(double); // вы почему-то избегаете приводить объявление mat и его мемберов. приходится угадывать.
S>}
S>

S>По-прежнему никаких приведений. Что говорит профайлер?

Целочисленное деление?? И что будет если mat.Step не делится на цело на sizeof(double) ?
Думаю бага будет.

Здравствуйте, barn_czn, Вы писали:
_>Целочисленное деление?? И что будет если mat.Step не делится на цело на sizeof(double) ?
_>Думаю бага будет.
Кто-то только что рассказывал про выравнивание, или мне показалось?

Если mat.step не делится нацело на 8 (то есть выравнивание таки сломано), то можно и принудительно инкрементировать void* поинтер. Всё равно "приведений к double*" будет на порядки меньше.
Вы, вместо того, чтобы обсуждать очевидные мелочи, лучше запустите эту модификацию под профайлером, и расскажите, что получилось. Есть мнение, что не в приведении типов там дело.

S>Кто-то только что рассказывал про выравнивание, или мне показалось?

S>Если mat.step не делится нацело на 8 (то есть выравнивание таки сломано), то можно и принудительно инкрементировать void* поинтер. Всё равно "приведений к double*" будет на порядки меньше.
S>Вы, вместо того, чтобы обсуждать очевидные мелочи, лучше запустите эту модификацию под профайлером, и расскажите, что получилось. Есть мнение, что не в приведении типов там дело.

Я не против обсуждать очевидные мелочи если бы это хоть как то помогло делу.
Способ с делением степа на размер типа я нигде не видел чтобы юзали, поэтому сомневаюсь что это правильно. В доках OpenCV есть вполне конкретный ответ на то как обращатся к элементам матрицы, там умножение с приведением, и я им почему то больше верю. Вообще, какая разница, приведение не приведение, если бы .NET нормальный код генерил — это бы работало также быстро (или также медленно) как на С++. Однако нет, любой алгоритм реализованый на С++ все равно работает быстрее — вот в чем суть вопроса этого топика, а не в том как с матрицами работать.
Ну конечно дело не в приведении типов, дело в .NET, как я сразу и сказал, и поэтому топик называется C# to C++.

На счет деления степа вы действительно правы, в исходниках OpenCV используется такой прием..
Но не думаю что это даст какое то преимущество C# перед C++.

Ну что, защитники дотнета, кто говорил, что C# как бы рвет C++ во всех тестах? (Здесь еще используется unsafe-код, заметьте.)

(Это ни разу не троллинг, просто хотелось бы услышать от Nikov'а объяснение, в чем тут может быть дело.)

Здравствуйте, Аноним, Вы писали:

А>Ну что, защитники дотнета, кто говорил, что C# как бы рвет C++ во всех тестах? (Здесь еще используется unsafe-код, заметьте.)

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

Я вот тоже думал, что код в NET априори работает медленне нативного. Однако-же мои первые, достаточно неуклюжие пробы шарпа дают несколько иную картину. Есть конечно ситуации, где заметно явное отставание от натива, хотя и по большей части не катастрофичное. Но во многих случаях код, написанный на шарпе, если и отстаёт, то это отставание вполне укладывается в погрешность измерений. Превосходства, правда, я пока тоже не видел, но ведь и опыта в NET у меня — с Гулькин нос

А>(Это ни разу не троллинг, просто хотелось бы услышать от Nikov'а объяснение, в чем тут может быть дело.)

Я тоже надеюсь, что уважаемый Nikov выскажет своё мнение на этот счёт, а пока выскажу свою гипотезу. Может быть здесь дело в попытке перенести в NET "as is" подходы, хорошо работающие в нативном коде, без учёта особенностей NET? Вот предлагает-же Sinclair самоочевидную, на мой взгляд, вещь — коль скоро некая операция явно тормозит, то очевидно-же, что следует минимизировать количество таких операций.

С другой стороны, я вот сейчас специально посмотрел — привидение Int32 к указателю на double скомпилилось в одну-единственную ассемблерную команду:

mov         ebp,edi

Обе переменные были локальными. Для Int64 получилось

dword ptr [esp+8],esi

а для глобальной Int64:

 mov         eax,dword ptr ds:[00B68920h] 
 mov         ebx,eax

То есть совершенно то-же самое, что сделал бы и нативный компилятор. Так может быть дело всё-таки не в NET?

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

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

Уверяю вас, что у меня нет никакого желания писать на С++, но мне приходится выносить узкие места в нативный С++.
На счет проверки. В коде на шарпе я избавился от приведения с помощью деления степа на sizeof(double), спасибо Sinclair за наводку на как казалось сначало пустую мысль. К стыду своему я не понимал смысла выравнивания строк, я думал это выравнивание на 1-2 байта специально под физические особенности процессоров. Так вот, после того как я избавился приведения IntPtr к double* — код на шарпе стал работать БЫСТРЕЕ чем версия на С++ (но там с приведением было).
Это хорошо, но все еще не говорит о том что .NET быстр, так как после того как сделал тоже самое в С++ коде, последний опять стал работать в 3 раза быстрее. Теперь профилировщик показывает горячие места не на обращениях к матрице а на умножениях, что в общем то нормально.

Итог. Эффективность .NET по прежнему сомнительна, но для подтверждения этого надо делать более прозрачные тесты, вероятно где то они уже есть.

М>Может быть здесь дело в попытке перенести в NET "as is" подходы, хорошо работающие в нативном коде, без учёта особенностей NET?

Да дадно. Случай, описанный здесь — далеко не первый, я о таком слышу уже в N-ый раз.

Каждый раз одна и та же история: обычный программист, не являющийся искушенным экспертом (а таких большинство), пишет идентичный (насколько это возможно) код на C++ и на C#, и на C++ работает быстрее.

Конечно, большинство таких примеров написано наивно (без учета особенностей конкретной платформы), и продвинутые программисты могут устроить соревнование оптимизации под обе платформы, но нюанс как раз в том и состоит, что речь идет о простой программе, написанной простым программистом, хотя считается, что в C++ нужно затрачивать больше усилий на разработку. Получается, если вам надо удовлетворить требования производительности, программирование на .Net более трудозатратно.

Кстати, отмазка с «учетом особенностей», то есть хардкорной оптимизацией под особенности платформы, не прокатывает, так как очевидно, что в C++ в этом плане возможностей побольше будет. Если начать глубоко оптимизировать «наивные» программы, например, ввести управление памятью как в промышленных программах — с помощью специализированных алокаторов и алокаторов без блокировок, более специализированные контейнеры, а не какой-нибудь универсальный map, то очевидно, что в C++ возможностей маленько побольше будет. К тому же, с шаблонами на C++ в плане оптимизации можно гораздо шире развернуться, чем с генериками, благо еще C++0x в этом плане подсобил. Я уже не говорю про вкусности компилятора, такого как Intel Compiler типа поддержки всех последних технологий в процессорах, Global и Profile-Guided Optimization. У… куда там вашему дотнету, что вы.

Кстати, еще раз, получается, что для глубоко оптимизированных программ трудозатраты на C++ могут быть гораздо меньше, чем на .Net.

(Еще раз говорю, я не тролль, так что спорить дальше не буду, это так было — лирическое отступление. Вообще, я жду, что Nikov скажет.)

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

_>Это хорошо, но все еще не говорит о том что .NET быстр, так как после того как сделал тоже самое в С++ коде, последний опять стал работать в 3 раза быстрее. Теперь профилировщик показывает горячие места не на обращениях к матрице а на умножениях, что в общем то нормально.

_>Итог. Эффективность .NET по прежнему сомнительна, но для подтверждения этого надо делать более прозрачные тесты, вероятно где то они уже есть.

Хм, Вы опять говорите о тормозах при привидении, хотя в моём предыдущем посте со всей очевидностью показано, что никаких тормозов при этом не может быть в принципе. Может стоит всё-таки над этим фактом задуматься? Может Вы что=то не то или не так, как надо, приводили?

Теперь у Вас якобы тормозит умножение. Хорошо, давайте посмотрим на умножение. Наберём такой код:

double[] d = new double[10];
for (int n = 0; n < d.Length; d[n++] = n*10) ;
fixed (double* pd = &d[0])
{
    double * a1 = pd;
    double * a2 = a1;
    a2++;
    double a3 = *a1 * *a2;
    Console.WriteLine(a3);
}

Откомпилируем и посмотрим, во что-же вылилась команда умножения двух адресуемых по ссылке чисел double. А получилось вот что:

fld         qword ptr [ebp] 
fmul        qword ptr [ebx] 
fstp        qword ptr [esp+8]

На случай, если понимание аcсемблера представляет для Вас затруднение, я поясню. Вся операция умножения выполняется 3-ия командами процессора. Первая загружает в арифметический сопроцессор 8-мибайтное число, адрес которого находится в регистре EBP процессора. Вторая приказывает сопроцессору перемножить ранее загруженное число с числом, адрес которого находится в регистре EBX. Наконец третья команда приказывает сопроцессору выгрузить полученный результат в локальную переменную, расположенную, естественно, на стеке. Адрес этой переменной на 8 больше числа, лежащего в регистре ESP.

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

Я не хотел-бы показаться навязчивым, но может быть стоит пока воздержаться от подведения итогов? Может быть Вы ещё что-нибудь пока не знаете, не только про выравнивание, как Вы думаете?

Здравствуйте, Аноним, Вы писали:

М>>Может быть здесь дело в попытке перенести в NET "as is" подходы, хорошо работающие в нативном коде, без учёта особенностей NET?

А>Да дадно. Случай, описанный здесь — далеко не первый, я о таком слышу уже в N-ый раз.

А>Каждый раз одна и та же история: обычный программист, не являющийся искушенным экспертом (а таких большинство), пишет идентичный (насколько это возможно) код на C++ и на C#, и на C++ работает быстрее.

Если человек не знает C++, то он и на нём напишет такое, что "мама, не горюй". И даже данный случай это лемонстрирует — смотрите высказывание о том, что после переделки код на C# стал работать быстрее первоначального кода на Си Так что разговоры про "неискушённость" — это и есть отмазка. Программист обязан знать инструмент, которым пользуется, это аксиома. Мне приходилось видеть слишком много абсолютно безграмотного с точки зрения оптимизации, с совершенно очевидными тормозами кода, написанного на самых разных языках. Но одна вещь эти языки объединяла — все они не имели ни малейшего отношения к NET. Безграмотность никак не коррелирует ни с используемым языком, ни с платформой.

Но все эти слова, как видно, ни к чему. Два моих предыдущих поста одназначно показывают, что код, полученный после JIT-компиляции, абсолютно такой-же, какой сгенерил бы любой нативный компилятор, но Вы благополучно этот факт проигнорировали. Похоже, Вы пришли сюда с единственной целью — поругаться с конкретным человеком, а факты Вас не интересуют. Что-же, дело Ваше.

М>Откомпилируем и посмотрим, во что-же вылилась команда умножения двух адресуемых по ссылке чисел double. А получилось вот что:
М>

М>fld         qword ptr [ebp] 
М>fmul        qword ptr [ebx] 
М>fstp        qword ptr [esp+8]
М>

М>Если Вы скомпилируете подобный код в каком-нибудь нативном языке, и посмотрите полученный ассемблерный листинг, то увидите те-же самые три команды. Могут отличаться имена регистров или величина смещения, но сами команды будут те-же самые, просто потому, что более быстрого способы выполнить это действие на данном процессоре не существует.

Как бы фигвам. Ключевое слово SSE ни о чем не говорит? И потом, вытаскивание трех команд из кода для оценки скорости их выполнения — занятие бессмысленное, а на современной архитектуре Intel — бессмысленное в кубе.

Кстати, интересно, что JIT-комплиятор обломался и не использовал SSE.

М>Я не хотел-бы показаться навязчивым, но может быть стоит пока воздержаться от подведения итогов? Может быть Вы ещё что-нибудь пока не знаете, не только про выравнивание, как Вы думаете?

Конечно я много чего не знаю, но ваши примеры меня пока не убедили отказатся от С++:
Ваши примеры состоят просто из операций над локальными переменными в теле цикла. Это хорошо что вы показали что хотя бы такой код должен работать одинаково. Но это все еще не доказательство того что на шарпе можно писать эффективный unsafe код. Например С++ и ШАрп уже оказались не на равных из-за ключевого слова inline ( а я его использовал в С++). Конечно, в шарпе это можно компенсировать копипастом, но это уже геморой. Далее, какой код будет генерить .NET для вызова методов других классов — тоже вопрос.
В общем получается так: хочеш писать только на шарпе — придется сильно рефакторить узкие места, так что код станет абсолютно нечитабельным. Другой вариант — вынести код на С++ и воспользоватся всеми прелестями компилятора (inline,шаблоны).

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

_>Конечно я много чего не знаю, но ваши примеры меня пока не убедили отказатся от С++:
_>Ваши примеры состоят просто из операций над локальными переменными в теле цикла. Это хорошо что вы показали что хотя бы такой код должен работать одинаково. Но это все еще не доказательство того что на шарпе можно писать эффективный unsafe код. Например С++ и ШАрп уже оказались не на равных из-за ключевого слова inline ( а я его использовал в С++). Конечно, в шарпе это можно компенсировать копипастом, но это уже геморой. Далее, какой код будет генерить .NET для вызова методов других классов — тоже вопрос.
_>В общем получается так: хочеш писать только на шарпе — придется сильно рефакторить узкие места, так что код станет абсолютно нечитабельным. Другой вариант — вынести код на С++ и воспользоватся всеми прелестями компилятора (inline,шаблоны).
Предлагаю тебе также посмотреть вот этот тред: С# vs C++, голые цифры

Автор: IID
Дата: 20.05.09

.
Никто в здравом уме и не будет доказывать, что код на C# всегда быстрее.

Здравствуйте, Аноним, Вы писали:

А>Как бы фигвам. Ключевое слово SSE ни о чем не говорит?

Да кто же не знает SSE? Это южно-американский сумчатый попугай.

Да Вы не напрягайтесь, относительно Вас я уже всё, что было нужно, понял. Ждите Nikov, хотя я бы на его месте ничего не стал бы говорить. А пока его нет, можно поразмыслить, почему в компиляторах Си для этих наборов предусмотрена специальная опция, а NET ничего подобного нет. А заодно, почему в компиляторе Си нет опции включения поддержки SSE9. Ну а про такую общеизвестную мелочь, как SSE4.1 vs SSE4a и напоминать не надо, Вы наверняка в курсе.

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

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