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

Ты все понял неправильно.
Я хочу забыть про плюсы навсегда и всё, включая алгоритмы, критичные по скорости, писать на управляемом коде.
За этим и затеяли этот эксперимент. Результат видишь сам.

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

MS>Во-вторых, использовать одномерную адресацию в обоих случаях, даже не через функцию at(), а напрямую, типа array[width*i+j].
Моя функция at разворачивается именно в то, что ты написал (т.к. она inline), а вот наглядность увеличивает. Так что смысла нет.

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

AD>Сделайте нормальную оптимизацию и там, и там. Алгоритмическую, то бишь.
AD>Тут дело в том, что вторая матрица обходится полностью, для вычисления каждой строки результирующей матрицы. Причем обход производится не в последовательном режиме.
AD>А вот вы возьмите и транспонируйте правую матрицу, пока вычисляется первая строка результата. А потом транспонируйте обратно, когда будете вычислять последнюю строку. Разница с первоначальным вариантом будет ой-ой-ой Тогда можно будет смотреть кто кого и во сколько раз уел.

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

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


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>Разница с первоначальным вариантом будет ой-ой-ой Тогда можно будет смотреть кто кого и во сколько раз уел.
Т.е. увеличится погрешность ихзмерений

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

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

M>>Собственно вопрос, а у тебя были основания думать иначе?

MF>Конечно!
MF>Железобетонные доводы, что JIT в теории обходит по эффективности заранее скомпиленный код мне кажутся очевидными.
MF>И то, что это не так, меня очень смущает.

Понимаешь, на практике разница между теорией и практикой гараздо больше, чем в теории

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

J>Понимаешь, на практике разница между теорией и практикой гараздо больше, чем в теории

Меня больше удручает знак этой разницы, а не ее абсолютная величина.

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

I>П.С. мот устроишь холивар "асм вс. плюсы"? Асм ваще там порвет плюсы аки тузик грелку. Бросишь всё, уйдешь на асм?

Попробуй порви. Только предварительно надо будет выучить количество тактов в командах, следить за выравниваем циклов (чтобы увеличить число TBL попаданий), самому решать задачу распределения регистров и т. д. Другими словами выполнять кучу рутинных операций, с которыми компьютер справляется куда лучше.

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

MF>Меня больше удручает знак этой разницы, а не ее абсолютная величина.

1. Производительность кода, который генерит JIT, на сегодня не является первоочередной задачей MS. Там где надо производительность, можно и на C++ код наваять. Другое дело объяснить недалеким программистам, что есть AV, bad pointer, ...

2. Производительность под конкретный процессор хороша в теории. Да, у меня дома стоит 64-битная Windows и ее преимущества можно было бы использовать. Но многие ли таких как я, которым нужны эти 64 бита? А на одной линейке новых ассемблерных команд не так уж и много... К тому же зачастую чтобы их можно было использовать, надо писать специальный код.

Рассмотрим конкретный пример. Вот ряд процессоров обладает такой замечательной ассемблерной командой, как определение номера первого бита, установленного в единицу. Возникает вопрос, какой код нужно написать, чтобы JIT-компилятор смог использовать эту команду? Такой команды нет в наборе инструкций CLI, поэтому логично предположить, что автор программы напишет аналогичную функцию, например следующий тривиальный вариант:

const int       lsz64_tbl[64] =
{
    0, 31,  4, 33, 60, 15, 12, 34,
   61, 25, 51, 10, 56, 20, 22, 35,
   62, 30,  3, 54, 52, 24, 42, 19,
   57, 29,  2, 44, 47, 28,  1, 36,
   63, 32, 59,  5,  6, 50, 55,  7,
   16, 53, 13, 41,  8, 43, 46, 17,
   26, 58, 49, 14, 11, 40,  9, 45,
   21, 48, 39, 23, 18, 38, 37, 27,
};

int  bitScan (const U64 bb)
{
   const U64 lsb = (bb & -(long long) bb) - 1;
   const unsigned int foldedLSB = ((int) lsb) ^ ((int) (lsb >> 32));
   return lsz64_tbl[foldedLSB * 0x78291ACF >> 26];
}

А теперь такой вопрос: какой мощи надо вшить оптимизатор в JIT, чтобы он догадался заменить любой вызов bitScan на ассемблерную инструкцию BSF?

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

MF>Железобетонные доводы, что JIT в теории обходит по эффективности заранее скомпиленный код мне кажутся очевидными.
MF>И то, что это не так, меня очень смущает.

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

подсказка.

используй unsafe + fixed + указатель на массив. Скорость возрастет на порядок.

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

M>А теперь такой вопрос: какой мощи надо вшить оптимизатор в JIT, чтобы он догадался заменить любой вызов bitScan на ассемблерную инструкцию BSF?

Такие извращения рассматривать нет смысла. Думаю, такие команды никто и не добавляет, так как от них толку нет.
Добавляют более полезные команды, например, позволяющие сложить или перемножить не два числа, а сразу 4 пары чисел — и тут JIT должен разбираться слёту, что к чему, разворачивать цикл, перекраивать арифметические выражения и использовать эту новую векторную команду процессора.

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

MF>Я в Шарповом коде убрал оптимизацию, потому что она элементарна и JIT должен делать ее сам.
С чего это? Ты считаешь что JIT оптимизирует лучше C++ комилятора? Как он это вообще может делать?

Вся оптимизация под специфичный процессор будет заключаться в применениии команд, которые лучше "спариваются" с другими. Такие оптимизации в лучшем случае дадут несколько процентов прироста быстродействия.

Любой код на managed языке в 99% случаев будет работать медленнее скопилированного unmanaged кода.

В свое время меня очень веселили статьи, где рассказывалось что программа на Java быстрее программы на C++. Как оказывалось в программе на С++ по значению передавались большие объекты, поэтому и тормозило (а все выглядело также, как на Java)

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

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

M>>А теперь такой вопрос: какой мощи надо вшить оптимизатор в JIT, чтобы он догадался заменить любой вызов bitScan на ассемблерную инструкцию BSF?

MF>Такие извращения рассматривать нет смысла. Думаю, такие команды никто и не добавляет, так как от них толку нет.

Почему нет толку? Тут (англ) есть целая ветка на эту тему, так как при программировании шахмат (да и вообще многих логических игр) это становится очень даже критично. А вообще битовый AND это распараллеливание логического AND (считай 32/64 одновременных логических AND-ов). Поэтому представление некоего объекта в виде битовых масок и последующую работа с ним дает большой прирост производительсноти. И тут операция получения первого бита становится полезной. Например

Есть битовая маска белых пешек (64-битное целое число).
1. Делаем AND с битовой маской всех полей, кроме вертикали A
2. Сдвигаем на семь
3. Делаем AND с битовой маской всех черных фигур
Итого у нас есть битовая всех взятий влево белыми пешками. Осталось только в цикле перебрать все установленые в единицу биты. Тут и оказываются полезными те команды, о которых я писал.

В общем это обобщается и на другие сферы...

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

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

M>>А теперь такой вопрос: какой мощи надо вшить оптимизатор в JIT, чтобы он догадался заменить любой вызов bitScan на ассемблерную инструкцию BSF?

MF>Такие извращения рассматривать нет смысла. Думаю, такие команды никто и не добавляет, так как от них толку нет.
Многие команды никто не добавляет потому что нет эквивалентов для языков выского уровня. Вы знаете хоть один языка высокого уровня, который непосредственно работает с битами числа и флагами процессора?

MF>Добавляют более полезные команды, например, позволяющие сложить или перемножить не два числа, а сразу 4 пары чисел — и тут JIT должен разбираться слёту, что к чему, разворачивать цикл, перекраивать арифметические выражения и использовать эту новую векторную команду процессора.

Это только если все методы заинлайнятся. А это покачто фантастика.

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

В>используй unsafe + fixed + указатель на массив. Скорость возрастет на порядок.
Поздно, пиво уже выйграно
Кстати, в условиях было не использовать unsafe и interop. Задача была именно сравнить стандартные механизмы.

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

MF>Железобетонные доводы, что JIT в теории обходит по эффективности заранее скомпиленный код мне кажутся очевидными.
MF>И то, что это не так, меня очень смущает.

1) посмотри на скорость компиляции C++ компилятора и его расход памяти. у JIT есть возможность столько же ресурсов использовать?
2) разный уровень языков, разные модели памяти

реклама подчёркивает только одно достоинство JIT, умалчивая о многих недостатках. кстати, cpu-specific код для сишных программ может генерить, например, gentoo при инсталляции из исходников