MF>У .Net-а с этим оказывается намного хуже, чем у плюсового компилера, хотя MS активно внедряет мнение о том, что JIT лучше плюсов, так как может компилить под конкретную платформу и использовать ее особенности. Получается, что это просто маркетинг, не имеющий за собой реальных оснований.
получается просто пример, который "высосан из пальца". Для наиболее типичных задач текущей потребности рынка , дотнета и джавы хватает вполне и они справляются лучше, чем плюсы.
уже кучу раз обсуждали "плюсы vs остальное". Не надоело?
кому и что есть желание доказать?
найти себе аргументацию остаться на плюсах, и не переходить на джаву и дотнет?
"пока плюсовики из Виларибо распухают от осознания соственной важности, пытаются мериться пиписками с другими, пытаются изобретать заново "велосипед" на проекте, джависты/дотнетчики из Вилабаджио давно сдали текущие проекты и получили новые. Бизнес, однако. Скорость, удобство разработки, однако. И заказчик, однако, уйдет к ребятам из Вилабаджио."
П.С. мот устроишь холивар "асм вс. плюсы"? Асм ваще там порвет плюсы аки тузик грелку. Бросишь всё, уйдешь на асм?
П.П.С. джава/дотнет — это не столько какой-то там Java-язык, C#-язык, это — ПЛАТФОРМЫ. Вот, что ключевое. у плюсов просто нет вменяемой платформы. Вот такие дела.
Здравствуйте, MatFiz, Вы писали:
MF>Меня больше удручает знак этой разницы, а не ее абсолютная величина.
1. Производительность кода, который генерит JIT, на сегодня не является первоочередной задачей MS. Там где надо производительность, можно и на C++ код наваять. Другое дело объяснить недалеким программистам, что есть AV, bad pointer, ...
2. Производительность под конкретный процессор хороша в теории. Да, у меня дома стоит 64-битная Windows и ее преимущества можно было бы использовать. Но многие ли таких как я, которым нужны эти 64 бита? А на одной линейке новых ассемблерных команд не так уж и много... К тому же зачастую чтобы их можно было использовать, надо писать специальный код.
Рассмотрим конкретный пример. Вот ряд процессоров обладает такой замечательной ассемблерной командой, как определение номера первого бита, установленного в единицу. Возникает вопрос, какой код нужно написать, чтобы JIT-компилятор смог использовать эту команду? Такой команды нет в наборе инструкций CLI, поэтому логично предположить, что автор программы напишет аналогичную функцию, например следующий тривиальный вариант:
Здравствуйте, AndreyR7, Вы писали:
AR>Здравствуйте, l33thaxor, Вы писали:
L>> public unsafe static MatrixComplex operator *(MatrixComplex left, MatrixComplex right) AR>Кажется увидел слово unsafe? Здравствуй обратно ручное управление памятью?
... и досвиданья. unsafe не имеет никакого отношения к ручному управлению памяти. Учись, пока молод.
Я видел тут у некоторых такую зелененькую подпись: "эксперт". Пора вводить новую, ярко красную мигающую: "студент".
Здравствуйте, MatFiz, Вы писали:
MF>Железобетонные доводы, что JIT в теории обходит по эффективности заранее скомпиленный код мне кажутся очевидными. MF>И то, что это не так, меня очень смущает.
Оптимизация под процессор процентов 10, может, и даст. Только проверки выхода за границу массива, сборка мусора не даром ведь даются.
Вообще, отвратительно, что программисты становятся аудиторией для рекламы по продвижению каких-то виртуальных платформ. И их разводят, как домохозяек на стиральный порошок. И JIT, и managed код и более доступные широкой аудитории языки программирования — всё это нужно. Только производители думают не о том, как просто дать людям всё это. Они думают, как это упаковать, чтобы впарить где надо и где не надо. Чтобы связавшись с этим никто уже не мог свернуть в сторону. Чтобы никто не мог предложить пользователям альтернативу отдельным компонентам платформы. Производители не хотят конкуренции. Им хочется подсадить как можно больше народу на свои решения. А потом только стричь купоны.
Здравствуйте, int13h, Вы писали:
I>Разница межда асмом и плюсами не такая уж большая I>А в сишном примере сделайте проверки на выход за граници массива — тогда и посмотрим
Хехе. А зачем?
Попробуйте в шарповом примере отключите эти проверки
Здравствуйте, l33thaxor, Вы писали:
AR>>Кажется увидел слово unsafe? Здравствуй обратно ручное управление памятью? L>... и досвиданья. unsafe не имеет никакого отношения к ручному управлению памяти. Учись, пока молод.
Ну здрасьте, приехали. А значит арифметика указателей — это не ручное управление памятью? Или в управление памятью входит только операции new/delete(GC)? Или ошибки в плюсовых программах типа "BlahBlah. Memory can't be read" — это наверное неправильное использование оператора new?
Я имел в виду широкое понятие, не только выделение/освобождение, но и работа с памятью. И слово unsafe как раз об этом.
L>Я видел тут у некоторых такую зелененькую подпись: "эксперт". Пора вводить новую, ярко красную мигающую: "студент".
Ага. И синюю жирную "умник". Уважаемый l33thaxor, оставьте свое мнение при себе.
Здравствуйте, AndreyR7, Вы писали:
AR>Код на C++ работал в 9 (!) раз быстрее чем аналогичный на шарпе.
Мне достаточно было посмотреть на ассемблерный код, который генерирует JIT, и все сразу стало понятно и без тестов. Смотреть Оптимизация в .NET]тут[/url].
Если тестировать каждый отдельный компонент, то результаты тестирования сравнимы. Ибо никто же не будет тестировать inline метод с обычным вызовом? Но когда все в начинает работать в комплексе, то...
Кстати, пресловутых преимуществ работы на другой архитектуре я не заметил Новые команды почти не используются (ибо это зачастую либо экзотика, либо надо изначально писать код под эти команды). Более того, смотрел на то, что генерирует .NET для 64 бит. Получаем:
1. По стандарту вызова метода, параметры передаются в регистрах.
2. JIT компилятор упорно размещает переменные производные от class в стеке (может это надо для сборки мусора или еще чего, не знаю).
Поэтому, при вызове метода происходило следующее
1. Аргументы копировались в регистры
2. Вызов функции
3. Инициализация cтека внутри функции
4. Копирование аргументов из регистров в стек
5. Выполнение кода функции
Здравствуйте, andrey.desman, Вы писали:
AD>Сделайте нормальную оптимизацию и там, и там. Алгоритмическую, то бишь. AD>Тут дело в том, что вторая матрица обходится полностью, для вычисления каждой строки результирующей матрицы. Причем обход производится не в последовательном режиме. AD>А вот вы возьмите и транспонируйте правую матрицу, пока вычисляется первая строка результата. А потом транспонируйте обратно, когда будете вычислять последнюю строку. Разница с первоначальным вариантом будет ой-ой-ой Тогда можно будет смотреть кто кого и во сколько раз уел.
На самом деле, идея в том, что я хочу просто описать алгоритм наиболее чистым способом, а оптимизатор должен сделать свое дело и сгенерировать максимально быстрый код, выкинув лишние проверки, развернув циклы, заинлайнив код и т.п.
У .Net-а с этим оказывается намного хуже, чем у плюсового компилера, хотя MS активно внедряет мнение о том, что JIT лучше плюсов, так как может компилить под конкретную платформу и использовать ее особенности. Получается, что это просто маркетинг, не имеющий за собой реальных оснований.
Здравствуйте, infree, Вы писали:
I>П.С. мот устроишь холивар "асм вс. плюсы"? Асм ваще там порвет плюсы аки тузик грелку. Бросишь всё, уйдешь на асм?
Попробуй порви. Только предварительно надо будет выучить количество тактов в командах, следить за выравниваем циклов (чтобы увеличить число TBL попаданий), самому решать задачу распределения регистров и т. д. Другими словами выполнять кучу рутинных операций, с которыми компьютер справляется куда лучше.
Здравствуйте, MatFiz, Вы писали:
MF>Здравствуйте, l33thaxor, Вы писали:
L>>Вот такой код MatrixComplex класса на C# уделывает первоначальный код на C++ на 25% (1.36s (C#) vs 1.75s (C++)):
MF>Может и уделывает, но согласись, это не C# уже в том виде, в котором его хочется видеть
А вам хочется чтобы и красиво, и быстро, и GC работал? Спуститесь на землю, такого не бывает.
Всетаки на C# можно писать отличающиеся по скорости на проценты (а не на порядки) от С++. Для C# это отличный результат
Здравствуйте, MatFiz, Вы писали:
MF>Меня лично интересовало именно то, насколько много я проиграю в скорости работы приложения, если буду следить исключительно за читабельностью и поддерживаемостью кода, забив на тупые оптимизации. MF>Выводы ужасны.
В выводах учитывается скорость разработки и отладки приложения, цена работы программиста и цена нового компьютера?
Я к тому,ч то в реально жизни никого не интересует быстродействие программы. Интересует решение проблемы. И надо думать именно об этом в первую очередь. И соответственно задаче (а не рекламе!) выбирать инструмент. Где-то тебе подойдет С++ и только С++. По каким-то причинам.
А где-то окажется, что интерес представляет:
1. решение сложной задачи — несколько человеко-лет
2. постоянная поддержка этого решения, добавление новых возможностей
3. стоимость закупки железа.
вот важно, что ВСЕ эти пункты имеют прямое выражение в деньгах.
И зачастую экономия на пунктах 1 и 2 с лихвой окупит более крупные затраты на пункт 3.
Но не всегда конечно же — бывают совершенно разные задачи. Если ты пишешь код для мобильника, то "железо" тебе дано свыше и никуда от него не деться.
А микротесты — они показывают только отдельные кадры и по большому счету ничего не значат...
Здравствуйте, WolfHound, Вы писали:
WH>1)Вариант на С++ написан не верно.
Неверно математически?
WH>2)Вариант на С++ отдельно оптимизировали.
Да, выносил переменную за циклы и заменял + на +=. Дало немного. Правда я удивился, что что-то все-таки дало.
WH>3)Многомерные массивы в .NET тормозят. Нужно использовать одномарные.
Все массивы в .Net тормозят Некоторые больше, некоторые меньше.
WH>4)Используются разные генераторы псевдослучайных чисел.
Не имеет значения — время генерации не учитывается раз; замеры проводили на матрица заполненной 1+1i
WH>5)Нет полного вывода результатов.
Также не имеет значения.
Здравствуйте, MatFiz, Вы писали:
WH>>1)Вариант на С++ написан не верно. MF>В чем ошибка?
Вторую матрицу кто использовать будет?
WH>>2)Вариант на С++ отдельно оптимизировали. MF>Я в Шарповом коде убрал оптимизацию, потому что она элементарна и JIT должен делать ее сам.
А почему она есть в С++ном?
WH>>4)Используются разные генераторы псевдослучайных чисел. MF>Замеряется скорость перемножения, скорость заполнения матриц числами не учитывается. WH>>5)Нет полного вывода результатов. MF>Вывод результатов на скорость перемножения не влияет.
Без этого нельзя проверить корректность теста.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, MatFiz, Вы писали:
MF>Здравствуйте, Mystic, Вы писали:
M>>А теперь такой вопрос: какой мощи надо вшить оптимизатор в JIT, чтобы он догадался заменить любой вызов bitScan на ассемблерную инструкцию BSF?
MF>Такие извращения рассматривать нет смысла. Думаю, такие команды никто и не добавляет, так как от них толку нет.
Почему нет толку? Тут (англ) есть целая ветка на эту тему, так как при программировании шахмат (да и вообще многих логических игр) это становится очень даже критично. А вообще битовый AND это распараллеливание логического AND (считай 32/64 одновременных логических AND-ов). Поэтому представление некоего объекта в виде битовых масок и последующую работа с ним дает большой прирост производительсноти. И тут операция получения первого бита становится полезной. Например
Есть битовая маска белых пешек (64-битное целое число).
1. Делаем AND с битовой маской всех полей, кроме вертикали A
2. Сдвигаем на семь
3. Делаем AND с битовой маской всех черных фигур
Итого у нас есть битовая всех взятий влево белыми пешками. Осталось только в цикле перебрать все установленые в единицу биты. Тут и оказываются полезными те команды, о которых я писал.
Здравствуйте, MatFiz, Вы писали:
MF>Железобетонные доводы, что JIT в теории обходит по эффективности заранее скомпиленный код мне кажутся очевидными. MF>И то, что это не так, меня очень смущает.
1) посмотри на скорость компиляции C++ компилятора и его расход памяти. у JIT есть возможность столько же ресурсов использовать?
2) разный уровень языков, разные модели памяти
реклама подчёркивает только одно достоинство JIT, умалчивая о многих недостатках. кстати, cpu-specific код для сишных программ может генерить, например, gentoo при инсталляции из исходников
Здравствуйте, andrey.desman, Вы писали:
AD>То, что C++ работает быстрее — факт. То, что на C# быстрее разрабатывается — тоже факт, однако. Нужно просто найти баланс и усе
Дык, в том-то и был вопрос топика — где этот баланс начинается. Вот и люди начали мерять для себя где граница.
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Здравствуйте, 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;
}
}
inline void multiply(const matrix<T, N>& second, matrix<T, N>& result) const
{
T value;
T temp;
for(int i = 0; i < N; ++i)
{
for(int j = 0; j < N; ++j)
{
value = T();
for(int k = 0; k < N; ++k)
{
temp = at(i, k);
temp *= at(k, j);
value += temp;
}
result.at(i, j) = value;
}
}
}
public static MatrixDouble operator *(MatrixDouble left, MatrixDouble right)
{
Require.IsTrue(left.Width == right.Height);
MatrixDouble result = new MatrixDouble(right.Width, left.Height);
for (int x = 0; x < result.Width; x++)
for (int y = 0; y < result.Height; y++)
for (int n = 0; n < left.Width; n++)
result[x, y] += left[n, y] * right[x, n];
return result;
}
1)Вариант на С++ написан не верно.
2)Вариант на С++ отдельно оптимизировали.
3)Многомерные массивы в .NET тормозят. Нужно использовать одномарные.
4)Используются разные генераторы псевдослучайных чисел.
5)Нет полного вывода результатов.
Короче сначала исправьте тесты, а потом можно будет вернутся к разговору.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, MatFiz, Вы писали:
MF>Здравствуйте, Mystic, Вы писали:
M>>А теперь такой вопрос: какой мощи надо вшить оптимизатор в JIT, чтобы он догадался заменить любой вызов bitScan на ассемблерную инструкцию BSF?
MF>Такие извращения рассматривать нет смысла. Думаю, такие команды никто и не добавляет, так как от них толку нет.
Многие команды никто не добавляет потому что нет эквивалентов для языков выского уровня. Вы знаете хоть один языка высокого уровня, который непосредственно работает с битами числа и флагами процессора?
MF>Добавляют более полезные команды, например, позволяющие сложить или перемножить не два числа, а сразу 4 пары чисел — и тут JIT должен разбираться слёту, что к чему, разворачивать цикл, перекраивать арифметические выражения и использовать эту новую векторную команду процессора.
Это только если все методы заинлайнятся. А это покачто фантастика.
Здравствуйте, gandjustas, Вы писали:
G>С чего это? Ты считаешь что JIT оптимизирует лучше C++ комилятора? Как он это вообще может делать?
Теоретически он может профилировать программу по мере выполнения, и на ходу менять параметры всякие. Что-то вроде зам. процессорного предсказателя ветвлений, только у него больше информации. Можно на ходу инлайнить самые интересные куски кода и т. п.
Интересный ссылко, спасибо.
Но ЭТО не устраивает, так как хотелось увидеть именно способности JIT-а к оптимизации.
Как видно, выполнив определенную тупую работу по ручной оптимизации кода, можно заставить .Net отставать от плюсов не слишком сильно.
Меня лично интересовало именно то, насколько много я проиграю в скорости работы приложения, если буду следить исключительно за читабельностью и поддерживаемостью кода, забив на тупые оптимизации.
Выводы ужасны.
Здравствуйте, McSeem2, Вы писали:
MS>>>Во-вторых, использовать одномерную адресацию в обоих случаях, даже не через функцию at(), а напрямую, типа array[width*i+j]. AR>>Моя функция at разворачивается именно в то, что ты написал (т.к. она inline), а вот наглядность увеличивает. Так что смысла нет.
MS>Похоже, что ты не хочешь прочитать смысл. Смысл в том, чтобы уровнять условия — на C++ прямая адресация и на С# прямая адресация. Ну и конечно же, рекомендация об идентичном генераторе псевдо-случайных чисел и строгой верификации результатов пропущена мимо ушей.
Не, все правильно, условия уравниваются так — на C++ метод at и на C# метод at. То что на C++ этот метод заинлайнится является его преимуществом. У меня, например, как раз за счет инлайнов release версия часто работает на порядок быстрее debug. Без потери читаемости кода. К тому же в исходных условиях автор явно был против написания одной большой функции.
Здравствуйте, AndreyR7, Вы писали:
AR>Здравствуйте, l33thaxor, Вы писали:
AR>>>Кажется увидел слово unsafe? Здравствуй обратно ручное управление памятью? L>>... и досвиданья. unsafe не имеет никакого отношения к ручному управлению памяти. Учись, пока молод. AR>Ну здрасьте, приехали. А значит арифметика указателей — это не ручное управление памятью? Или в управление памятью входит только операции new/delete(GC)? Или ошибки в плюсовых программах типа "BlahBlah. Memory can't be read" — это наверное неправильное использование оператора new?
Не смешивай все в одну кучу. А то получится балаган, как с твоим бестолковым бенчмарком.
AR>Я имел в виду широкое понятие, не только выделение/освобождение, но и работа с памятью. И слово unsafe как раз об этом.
Люблю дискуссии на rsdn. Как только кто-нибудь пропирается, начинаются попытки подменить понятия. Ну, да ладно, по доброте души пошлю тебя на wikipedia:
Memory management is the act of managing computer memory. In its simpler forms, this involves providing ways to allocate portions of memory to programs at their request, and freeing it for reuse when no longer needed.
А то, что в моем коде происходит, называется pointer arithmetics. Это тебе на будущее, чтоб знал.
L>>Я видел тут у некоторых такую зелененькую подпись: "эксперт". Пора вводить новую, ярко красную мигающую: "студент". AR>Ага. И синюю жирную "умник". Уважаемый l33thaxor, оставьте свое мнение при себе.
Иногда приходится учить студентов. Ничего не поделаешь.
Недавно с коллегой поспорили на тему производительности в математических вычислениях. Задачка была довольно простая — перемножить 2 матрицы комплексных числе размером 600 на 600. Он писал на C#, я на C++. Изначально ожидалось, что C++ будет быстрее, но тем не менее результаты поразили нас обоих. Код на C++ работал в 9 (!) раз быстрее чем аналогичный на шарпе. И это после того, как мы включили все возможные оптимизации, по несколько раз пересмотрели сам код и оптимизировали все что могли.
От форумчан поступило предложение выложить тот и другой код, чтобы совместными услилиями C# догнал C++.
Требования обозначались простые:
1) Не использовать ничего стороннего. В случае C# — только managed код (никакого interop & unsafe) + .Net framework, в случае C++ — только сам язык + STL.
2) Код должен быть читаемым. Т.е. не стоит запихивать все в один метод только из-за того, чтобы устранить вызовы функций.
3) Настройка параметров проекта (компилятора, линкера) — произвольная. Так в C++ проекте я указал размер стека в 64 мб.
В приложенных файлах оба решения, открывать можно/нужно в 2005 студии.
Здравствуйте, WolfHound, Вы писали:
WH>1)Вариант на С++ написан не верно.
В чем ошибка?
WH>2)Вариант на С++ отдельно оптимизировали.
Я в Шарповом коде убрал оптимизацию, потому что она элементарна и JIT должен делать ее сам.
WH>3)Многомерные массивы в .NET тормозят. Нужно использовать одномарные.
Ты путаешь [][] с [,]. Первый вариант работает быстрее, он и использован.
WH>4)Используются разные генераторы псевдослучайных чисел.
Замеряется скорость перемножения, скорость заполнения матриц числами не учитывается.
WH>5)Нет полного вывода результатов.
Вывод результатов на скорость перемножения не влияет.
MatFiz wrote: > WH>3)Многомерные массивы в .NET тормозят. Нужно использовать одномарные. > Ты путаешь [][] с [,]. Первый вариант работает быстрее, он и использован.
В .NET нет настоящих многомерных массивов — поэтому формат обращения,
AFAIR, никакой роли не играет.
Здравствуйте, Cyberax, Вы писали:
C>В .NET нет настоящих многомерных массивов — поэтому формат обращения, C>AFAIR, никакой роли не играет.
Ошибаешся, в .net в отличии от плюсов есть настоящие многомерные массивы. Это про [,]. Именно они и тормозят т.к. для них нет специальных инструкций msil (для одномерных есть) и приходится вызывать статический метод класса Array (В деталях могу ошибаться)
[][] — это псевдомногомерные массивы или jagged arrays. Они не должны тормозить так сильно как истинно многомерные.
AndreyR7 wrote: > Ошибаешся, в .net в отличии от плюсов есть настоящие многомерные > массивы. Это про [,]. Именно они и тормозят т.к. для них нет специальных > инструкций msil (для одномерных есть) и приходится вызывать статический > метод класса Array (В деталях могу ошибаться)
Т.е. оно реально в виде одного блока в памяти сидит, а не просто
засахареные jagged arrays?
> [][] — это псевдомногомерные массивы или jagged arrays. Они не должны > тормозить так сильно как истинно многомерные.
По идее, как раз настоящие многомерные массивы должны работать быстрее
(так как мы убираем лишнюю косвенность). В Фортране, например, это
именно так и есть.
Здравствуйте, AndreyR7, Вы писали:
WH>>1)Вариант на С++ написан не верно. AR>Неверно математически?
Ага.
AR>Все массивы в .Net тормозят Некоторые больше, некоторые меньше.
Если их готовить правильно нет.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Cyberax, Вы писали:
C>По идее, как раз настоящие многомерные массивы должны работать быстрее (так как мы убираем лишнюю косвенность). В Фортране, например, это именно так и есть.
А в .NET они тормозят. Ибо мелкомягкие не осилили их оптимизировать.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>>>1)Вариант на С++ написан не верно. MF>>В чем ошибка? WH>Вторую матрицу кто использовать будет?
Сорри
Поправил — на время заметно не повлияло
Здравствуйте, AndreyR7, Вы писали:
AR>Коллеги, присоединяйтесь
AR>Здесь C++ AR>Здесь C#
Сделайте нормальную оптимизацию и там, и там. Алгоритмическую, то бишь.
Тут дело в том, что вторая матрица обходится полностью, для вычисления каждой строки результирующей матрицы. Причем обход производится не в последовательном режиме.
А вот вы возьмите и транспонируйте правую матрицу, пока вычисляется первая строка результата. А потом транспонируйте обратно, когда будете вычислять последнюю строку. Разница с первоначальным вариантом будет ой-ой-ой Тогда можно будет смотреть кто кого и во сколько раз уел.
Ты все понял неправильно.
Я хочу забыть про плюсы навсегда и всё, включая алгоритмы, критичные по скорости, писать на управляемом коде.
За этим и затеяли этот эксперимент. Результат видишь сам.
Здравствуйте, McSeem2, Вы писали:
MS>Во-вторых, использовать одномерную адресацию в обоих случаях, даже не через функцию at(), а напрямую, типа array[width*i+j].
Моя функция at разворачивается именно в то, что ты написал (т.к. она inline), а вот наглядность увеличивает. Так что смысла нет.
Здравствуйте, andrey.desman, Вы писали:
AD>Сделайте нормальную оптимизацию и там, и там. Алгоритмическую, то бишь. AD>Тут дело в том, что вторая матрица обходится полностью, для вычисления каждой строки результирующей матрицы. Причем обход производится не в последовательном режиме. AD>А вот вы возьмите и транспонируйте правую матрицу, пока вычисляется первая строка результата. А потом транспонируйте обратно, когда будете вычислять последнюю строку. Разница с первоначальным вариантом будет ой-ой-ой Тогда можно будет смотреть кто кого и во сколько раз уел.
Да, забыл сказать. Одним из условий было не оптимизировать алгоритм, т.е. оставить его предельно простым, без хитростей.
I> получается просто пример, который "высосан из пальца". Для наиболее типичных задач текущей потребности рынка , дотнета и джавы хватает вполне и они справляются лучше, чем плюсы.
Никто не спорит, сам бы не взялся корпоративное приложение на плюсах делать
I>П.С. мот устроишь холивар "асм вс. плюсы"? Асм ваще там порвет плюсы аки тузик грелку. Бросишь всё, уйдешь на асм?
Ну кстати с асмом спорный вопрос, я склонен думать что плюсовый компилятор оттачивался годами и все-таки достаточно хорош.
С другой стороны может получиться что разница между асмом и плюсами будет похожа на разницу между плюсами и шарпом. Зато время разработки можно выстроить как 100-10-1
Здравствуйте, MatFiz, Вы писали:
MF>На самом деле, идея в том, что я хочу просто описать алгоритм наиболее чистым способом, а оптимизатор должен сделать свое дело и сгенерировать максимально быстрый код, выкинув лишние проверки, развернув циклы, заинлайнив код и т.п. MF>У .Net-а с этим оказывается намного хуже, чем у плюсового компилера, хотя MS активно внедряет мнение о том, что JIT лучше плюсов, так как может компилить под конкретную платформу и использовать ее особенности. Получается, что это просто маркетинг, не имеющий за собой реальных оснований.
Собственно вопрос, а у тебя были основания думать иначе?
Здравствуйте, infree, Вы писали:
MF>>У .Net-а с этим оказывается намного хуже, чем у плюсового компилера, хотя MS активно внедряет мнение о том, что JIT лучше плюсов, так как может компилить под конкретную платформу и использовать ее особенности. Получается, что это просто маркетинг, не имеющий за собой реальных оснований. I> получается просто пример, который "высосан из пальца". Для наиболее типичных задач текущей потребности рынка , дотнета и джавы хватает вполне и они справляются лучше, чем плюсы.
Тут дело не в применимости C#/Java а о заведомом обмане со стороны неких деятелей.
Здравствуйте, minorlogic, Вы писали:
M>Собственно вопрос, а у тебя были основания думать иначе?
Конечно!
Железобетонные доводы, что JIT в теории обходит по эффективности заранее скомпиленный код мне кажутся очевидными.
И то, что это не так, меня очень смущает.
Здравствуйте, andrey.desman, Вы писали:
AD>Сделайте нормальную оптимизацию и там, и там. Алгоритмическую, то бишь.
Зачем? Задача ведь состоит не в написании самого быстрого алгоритма умножения, а сравнении производительности при одинаковой алгоритмической сложности.
AD>Разница с первоначальным вариантом будет ой-ой-ой Тогда можно будет смотреть кто кого и во сколько раз уел.
Т.е. увеличится погрешность ихзмерений
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Здравствуйте, MatFiz, Вы писали:
MF>Здравствуйте, minorlogic, Вы писали:
M>>Собственно вопрос, а у тебя были основания думать иначе?
MF>Конечно! MF>Железобетонные доводы, что JIT в теории обходит по эффективности заранее скомпиленный код мне кажутся очевидными. MF>И то, что это не так, меня очень смущает.
Понимаешь, на практике разница между теорией и практикой гараздо больше, чем в теории
Здравствуйте, Mystic, Вы писали:
M>А теперь такой вопрос: какой мощи надо вшить оптимизатор в JIT, чтобы он догадался заменить любой вызов bitScan на ассемблерную инструкцию BSF?
Такие извращения рассматривать нет смысла. Думаю, такие команды никто и не добавляет, так как от них толку нет.
Добавляют более полезные команды, например, позволяющие сложить или перемножить не два числа, а сразу 4 пары чисел — и тут JIT должен разбираться слёту, что к чему, разворачивать цикл, перекраивать арифметические выражения и использовать эту новую векторную команду процессора.
Здравствуйте, MatFiz, Вы писали:
MF>Я в Шарповом коде убрал оптимизацию, потому что она элементарна и JIT должен делать ее сам.
С чего это? Ты считаешь что JIT оптимизирует лучше C++ комилятора? Как он это вообще может делать?
Вся оптимизация под специфичный процессор будет заключаться в применениии команд, которые лучше "спариваются" с другими. Такие оптимизации в лучшем случае дадут несколько процентов прироста быстродействия.
Любой код на managed языке в 99% случаев будет работать медленнее скопилированного unmanaged кода.
В свое время меня очень веселили статьи, где рассказывалось что программа на Java быстрее программы на C++. Как оказывалось в программе на С++ по значению передавались большие объекты, поэтому и тормозило (а все выглядело также, как на Java)
Здравствуйте, Ватакуси, Вы писали:
В>используй unsafe + fixed + указатель на массив. Скорость возрастет на порядок.
Поздно, пиво уже выйграно
Кстати, в условиях было не использовать unsafe и interop. Задача была именно сравнить стандартные механизмы.
Ничего удивительного нету в ваших результатах.
Удивительно то, что куча людей не согласны с тем что С# не может конкурировать по скорости с С++, у него совсем другие цели...
Здравствуйте, 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 и конечно же с ассемблером
Пользуешься ими в работе — пожалуйста, добавляй реализации сюда
Здравствуйте, AndreyR7, Вы писали:
AR>Здравствуйте, infree, Вы писали:
I>> получается просто пример, который "высосан из пальца". Для наиболее типичных задач текущей потребности рынка , дотнета и джавы хватает вполне и они справляются лучше, чем плюсы. AR>Никто не спорит, сам бы не взялся корпоративное приложение на плюсах делать
I>>П.С. мот устроишь холивар "асм вс. плюсы"? Асм ваще там порвет плюсы аки тузик грелку. Бросишь всё, уйдешь на асм? AR>Ну кстати с асмом спорный вопрос, я склонен думать что плюсовый компилятор оттачивался годами и все-таки достаточно хорош.
AR>С другой стороны может получиться что разница между асмом и плюсами будет похожа на разницу между плюсами и шарпом. Зато время разработки можно выстроить как 100-10-1
Разница межда асмом и плюсами не такая уж большая
А в сишном примере сделайте проверки на выход за граници массива — тогда и посмотрим
Здравствуйте, AndrewJD, Вы писали:
AD>>Разница с первоначальным вариантом будет ой-ой-ой Тогда можно будет смотреть кто кого и во сколько раз уел. AJD>Т.е. увеличится погрешность ихзмерений
Погрешность измерений увеличится, да, но кому нужны эти измерения? Я к тому, что при этой оптимизации C# возможно удовлетворит потребности и надобности в C++ не будет. Если нет, то тогда уже вынос в unmanaged, разумеется. То, что C++ работает быстрее — факт. То, что на C# быстрее разрабатывается — тоже факт, однако. Нужно просто найти баланс и усе А линейки ради линеек — глупость
Здравствуйте, minorlogic, Вы писали:
M>Я все жду что появится VladD2 и покажет что C# бывает медленнее C++ на 15 -20% а в реальной программе ничуть не уступает.
Здравствуйте, l33thaxor, Вы писали:
L>Вот такой код MatrixComplex класса на C# уделывает первоначальный код на C++ на 25% (1.36s (C#) vs 1.75s (C++)):
Может и уделывает, но согласись, это не C# уже в том виде, в котором его хочется видеть
К тому же есть подозрение, что если плюсовый код переписать аналогично, шарп опять будет немного отставать.
Здравствуйте, l33thaxor, Вы писали:
L> public unsafe static MatrixComplex operator *(MatrixComplex left, MatrixComplex right)
Кажется увидел слово unsafe? Здравствуй обратно ручное управление памятью?
Здравствуйте, andrey.desman, Вы писали:
AD>То, что на C# быстрее разрабатывается — тоже факт, однако.
Вовсе не факт. Проблема плюсов как правило в библиотеках, т.е. для разработки серьезных приложений нужно использовать библиотеки, которые не очень (а то и API использовать — вообще кошмар)
P.S. Данный тест на плюсах по времени разрабатывался примерно столько же, сколько и шарповый. Может чуть дольше — приходилось вспоминать что там к чему
Здравствуйте, AndreyR7, Вы писали:
AR>Вовсе не факт. Проблема плюсов как правило в библиотеках, т.е. для разработки серьезных приложений нужно использовать библиотеки, которые не очень (а то и API использовать — вообще кошмар)
Если брать в расчёт простое набивание кода, то действительно можно поспорить. Если же учесть возможности современных IDE (вива Решарпер!), то C# ИМХО однозначно впереди.
Здравствуйте, Delight, Вы писали:
D>Если брать в расчёт простое набивание кода, то действительно можно поспорить. Если же учесть возможности современных IDE (вива Решарпер!), то C# ИМХО однозначно впереди.
Для MS VC++ есть (по крайней мере раньше был) Visual Assist, который очень неплохо со всем справлялся, где-то и получше решарпера. И памяти столько не кушал (хватало для разработки 128 мб RAM, сейчас с решарпером 1 гига мало, если несколько студий открывать)
Здравствуйте, l33thaxor, Вы писали:
L>Я видел тут у некоторых такую зелененькую подпись: "эксперт". Пора вводить новую, ярко красную мигающую: "студент".
Ты сам себя к которым причисляешь?
Зелёненькой надписи рядом с твоим ником что-то не видно...
Здравствуйте, COFF, Вы писали:
COF>Не, все правильно, условия уравниваются так — на C++ метод at и на C# метод at. То что на C++ этот метод заинлайнится является его преимуществом. У меня, например, как раз за счет инлайнов release версия часто работает на порядок быстрее debug. Без потери читаемости кода. К тому же в исходных условиях автор явно был против написания одной большой функции.
C++ метод at — уродство. Вопервых можно руками написать асерт, правда тут еще замут с стльной беззнаковостью. Нужно иметь возможность включать ранже, а где она?
Здравствуйте, AndreyR7, Вы писали:
AR>1) Не использовать ничего стороннего. В случае C# — только managed код (никакого interop & unsafe) + .Net framework, в случае C++ — только сам язык + STL.
В STL комплех чем дальше тем чуднее, там проверки на нвалуе встречаются непонятно зачем, деление с лишней нормировкой. Ну и вообще наворочено
