Ничего удивительного нету в ваших результатах.
Удивительно то, что куча людей не согласны с тем что С# не может конкурировать по скорости с С++, у него совсем другие цели...
Здравствуйте, gandjustas, Вы писали:
G>С чего это? Ты считаешь что JIT оптимизирует лучше C++ комилятора? Как он это вообще может делать?
Теоретически он может профилировать программу по мере выполнения, и на ходу менять параметры всякие. Что-то вроде зам. процессорного предсказателя ветвлений, только у него больше информации. Можно на ходу инлайнить самые интересные куски кода и т. п.
Здравствуйте, Roman Odaisky, Вы писали:
G>>С чего это? Ты считаешь что JIT оптимизирует лучше C++ комилятора? Как он это вообще может делать? RO>Теоретически он может профилировать программу по мере выполнения, и на ходу менять параметры всякие. Что-то вроде зам. процессорного предсказателя ветвлений, только у него больше информации. Можно на ходу инлайнить самые интересные куски кода и т. п. Практически именно так делает HotSpot-компилятор в Java — виртуальные методы вполне себе инлайнит. На некоторых микротестах благодаря этому даже С++ обходит.
Здравствуйте, bot1984, Вы писали:
B>Ничего удивительного нету в ваших результатах. B>Удивительно то, что куча людей не согласны с тем что С# не может конкурировать по скорости с С++, у него совсем другие цели...
Цели-то другие, конечно, но дело не в языке C#, а в JIT-е платформы .Net, который стОит того, чтобы его соптимизировали по максимуму.
Микрософт F# решил продвигать в качестве языка для математических вычислений, а с такими способностями к оптимизации JIT-а это смотрится просто смешно.
Здравствуйте, AndreyR7, Вы писали:
MS>>Во-вторых, использовать одномерную адресацию в обоих случаях, даже не через функцию at(), а напрямую, типа array[width*i+j]. AR>Моя функция at разворачивается именно в то, что ты написал (т.к. она inline), а вот наглядность увеличивает. Так что смысла нет.
Похоже, что ты не хочешь прочитать смысл. Смысл в том, чтобы уровнять условия — на C++ прямая адресация и на С# прямая адресация. Ну и конечно же, рекомендация об идентичном генераторе псевдо-случайных чисел и строгой верификации результатов пропущена мимо ушей.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, AndreyR7, Вы писали:
AR>Здесь C++ AR>Здесь C#
А почему только C#? Предлагаю также сравнить с java, ABAP, PL/SQL и конечно же с ассемблером
Здравствуйте, Дмитрий В, Вы писали:
ДВ>Здравствуйте, AndreyR7, Вы писали:
AR>>Здесь C++ AR>>Здесь C# ДВ>А почему только C#? Предлагаю также сравнить с java, ABAP, PL/SQL и конечно же с ассемблером
Пользуешься ими в работе — пожалуйста, добавляй реализации сюда
Интересный ссылко, спасибо.
Но ЭТО не устраивает, так как хотелось увидеть именно способности JIT-а к оптимизации.
Как видно, выполнив определенную тупую работу по ручной оптимизации кода, можно заставить .Net отставать от плюсов не слишком сильно.
Меня лично интересовало именно то, насколько много я проиграю в скорости работы приложения, если буду следить исключительно за читабельностью и поддерживаемостью кода, забив на тупые оптимизации.
Выводы ужасны.
Здравствуйте, McSeem2, Вы писали:
MS>>>Во-вторых, использовать одномерную адресацию в обоих случаях, даже не через функцию at(), а напрямую, типа array[width*i+j]. AR>>Моя функция at разворачивается именно в то, что ты написал (т.к. она inline), а вот наглядность увеличивает. Так что смысла нет.
MS>Похоже, что ты не хочешь прочитать смысл. Смысл в том, чтобы уровнять условия — на C++ прямая адресация и на С# прямая адресация. Ну и конечно же, рекомендация об идентичном генераторе псевдо-случайных чисел и строгой верификации результатов пропущена мимо ушей.
Не, все правильно, условия уравниваются так — на C++ метод at и на C# метод at. То что на C++ этот метод заинлайнится является его преимуществом. У меня, например, как раз за счет инлайнов release версия часто работает на порядок быстрее debug. Без потери читаемости кода. К тому же в исходных условиях автор явно был против написания одной большой функции.
Здравствуйте, AndreyR7, Вы писали:
AR>Здравствуйте, infree, Вы писали:
I>> получается просто пример, который "высосан из пальца". Для наиболее типичных задач текущей потребности рынка , дотнета и джавы хватает вполне и они справляются лучше, чем плюсы. AR>Никто не спорит, сам бы не взялся корпоративное приложение на плюсах делать
I>>П.С. мот устроишь холивар "асм вс. плюсы"? Асм ваще там порвет плюсы аки тузик грелку. Бросишь всё, уйдешь на асм? AR>Ну кстати с асмом спорный вопрос, я склонен думать что плюсовый компилятор оттачивался годами и все-таки достаточно хорош.
AR>С другой стороны может получиться что разница между асмом и плюсами будет похожа на разницу между плюсами и шарпом. Зато время разработки можно выстроить как 100-10-1
Разница межда асмом и плюсами не такая уж большая
А в сишном примере сделайте проверки на выход за граници массива — тогда и посмотрим
Здравствуйте, int13h, Вы писали:
I>Разница межда асмом и плюсами не такая уж большая I>А в сишном примере сделайте проверки на выход за граници массива — тогда и посмотрим
Хехе. А зачем?
Попробуйте в шарповом примере отключите эти проверки
Здравствуйте, AndrewJD, Вы писали:
AD>>Разница с первоначальным вариантом будет ой-ой-ой Тогда можно будет смотреть кто кого и во сколько раз уел. AJD>Т.е. увеличится погрешность ихзмерений
Погрешность измерений увеличится, да, но кому нужны эти измерения? Я к тому, что при этой оптимизации C# возможно удовлетворит потребности и надобности в C++ не будет. Если нет, то тогда уже вынос в unmanaged, разумеется. То, что C++ работает быстрее — факт. То, что на C# быстрее разрабатывается — тоже факт, однако. Нужно просто найти баланс и усе А линейки ради линеек — глупость
Здравствуйте, andrey.desman, Вы писали:
AD>То, что C++ работает быстрее — факт. То, что на C# быстрее разрабатывается — тоже факт, однако. Нужно просто найти баланс и усе
Дык, в том-то и был вопрос топика — где этот баланс начинается. Вот и люди начали мерять для себя где граница.
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Здравствуйте, minorlogic, Вы писали:
M>Я все жду что появится VladD2 и покажет что C# бывает медленнее C++ на 15 -20% а в реальной программе ничуть не уступает.
Здравствуйте, andrey.desman, Вы писали:
AD>Здравствуйте, AndreyR7, Вы писали:
AR>>Коллеги, присоединяйтесь
AR>>Здесь C++ AR>>Здесь C#
AD>Сделайте нормальную оптимизацию и там, и там. Алгоритмическую, то бишь. AD>Тут дело в том, что вторая матрица обходится полностью, для вычисления каждой строки результирующей матрицы. Причем обход производится не в последовательном режиме. AD>А вот вы возьмите и транспонируйте правую матрицу, пока вычисляется первая строка результата. А потом транспонируйте обратно, когда будете вычислять последнюю строку. Разница с первоначальным вариантом будет ой-ой-ой Тогда можно будет смотреть кто кого и во сколько раз уел.
Вот такой код MatrixComplex класса на C# уделывает первоначальный код на C++ на 25% (1.36s (C#) vs 1.75s (C++)):
public class MatrixComplex
{
private int _width;
private int _height;
readonly Complex[] _values;
public int Width { get { return _width; } }
public int Height { get { return _height; } }
public Complex this[int x, int y]
{
get { return _values[y * _width + x]; }
set { _values[y * _width + x] = value; }
}
public MatrixComplex(int width, int height)
{
_width = width;
_height = height;
_values = new Complex[width * height];
}
public unsafe static MatrixComplex operator *(MatrixComplex left, MatrixComplex right)
{
int leftWidth = left._width;
int leftHeight = left._height;
int rightWidth = right._width;
int rightHeight = right._height;
Require.IsTrue(left._width == right._height);
MatrixComplex rightDash = new MatrixComplex(rightHeight, rightWidth);
for (int x = 0; x < rightWidth; x++)
for (int y = 0; y < rightHeight; y++)
rightDash._values[y + x * rightHeight] = right._values[x + rightWidth * y];
MatrixComplex result = new MatrixComplex(rightWidth, leftHeight);
fixed (Complex * leftV = left._values)
fixed (Complex * rightV = rightDash._values)
{
for (int y = 0; y < leftHeight; y++)
{
Complex * leftVV = leftV + y * leftWidth;
int firstResInd = y * rightWidth;
for (int x = 0; x < rightWidth; x++)
{
Complex res = new Complex();
Complex * rightVV = rightV + x * rightHeight;
for (int n = 0; n < leftWidth; n++)
{
Complex * c1 = leftVV + n;
Complex * c2 = rightVV + n;
res.R += c1->R * c2->R - c1->I * c2->I;
res.I += c1->R * c2->I + c1->I * c2->R;
}
result._values[firstResInd + x] = res;
}
}
}
return result;
}
}
Здравствуйте, l33thaxor, Вы писали:
L>Вот такой код MatrixComplex класса на C# уделывает первоначальный код на C++ на 25% (1.36s (C#) vs 1.75s (C++)):
Может и уделывает, но согласись, это не C# уже в том виде, в котором его хочется видеть
К тому же есть подозрение, что если плюсовый код переписать аналогично, шарп опять будет немного отставать.
Здравствуйте, MatFiz, Вы писали:
MF>Меня лично интересовало именно то, насколько много я проиграю в скорости работы приложения, если буду следить исключительно за читабельностью и поддерживаемостью кода, забив на тупые оптимизации. MF>Выводы ужасны.
В выводах учитывается скорость разработки и отладки приложения, цена работы программиста и цена нового компьютера?
Я к тому,ч то в реально жизни никого не интересует быстродействие программы. Интересует решение проблемы. И надо думать именно об этом в первую очередь. И соответственно задаче (а не рекламе!) выбирать инструмент. Где-то тебе подойдет С++ и только С++. По каким-то причинам.
А где-то окажется, что интерес представляет:
1. решение сложной задачи — несколько человеко-лет
2. постоянная поддержка этого решения, добавление новых возможностей
3. стоимость закупки железа.
вот важно, что ВСЕ эти пункты имеют прямое выражение в деньгах.
И зачастую экономия на пунктах 1 и 2 с лихвой окупит более крупные затраты на пункт 3.
Но не всегда конечно же — бывают совершенно разные задачи. Если ты пишешь код для мобильника, то "железо" тебе дано свыше и никуда от него не деться.
А микротесты — они показывают только отдельные кадры и по большому счету ничего не значат...
