Я скомпилировал релизный билд, поставил breakpoint в коде, запустил отладку,
когда выполнение остановилось на breakpoint, я перешел в disassembly из контекстного меню.
Если есть более правильный способ, распишите его пожалуйста тоже.
Да, безусловно актуализация важна. Тесты актуальны для используемых версий Visual Studio и приведенного в них железа, но на свежей Visual Studio и например более свежем железе результаты могут быть другими.
Я пытаюсь оценить издержки, простые задачи позволяют это сделать и позволяют выполнить анализ причин.
Далеко идущие выводы из одной этой оценки вряд-ли стоит делать, но думаю есть смысл принимать их во внимание при анализе среди прочих факторов.
Это более сложный вопрос. Он за рамками статьи. Есть некоторые соображения на этот счет, но пока они далеки от формализованных. Попробую как-нибудь написать об этом боле развернуто, в виде статьи, когда сформулирую.
Ага, понятно, спасибо.
И правда скомпилировал заметно лучше, действительно сильный прогресс в рассмотренном примере.
А проверка выхода за границы массива теперь ушла?
Так же, как понимаю, переменную tmp с оптимизировали до использования регистров?
Вообще конечно надо будет уже скоро переходить на 2015 студию.
Стоимость оценивается исключительно в единицах времени, которое занимает код в runtime.
Методика заключается в измерении этого времени и анализе disassembly являющегося причиной разницы этого времени. (хотя методика, это наверное слишком громко сказано)
Я привел disassembly релизного кода, а не дебажного.
Сборщик мусора вызывал для эмуляции delete (о чем писал в статье), ведь в реальном приложении рано или поздно будет потрачено время на сборку мусора, хотелось как то его учесть.
Считаете ли вы что менеджмент кода возможно осуществлять без накладных расходов? Если нет, то в чем я не прав, экстраполируя факт наличия расходов на менеджмент простого кода на более сложные случаи?
В статье я писал, что использовал Visual Studio 2010 и настройки по умолчанию для релизной конфигурации (исходники с настройками проекта приложены в статье)
И если быть более точным, то Visual Studio 2010 SP1, С++ компилятор 16.00.40219.01, С# компилятор 4.0.30319.17929.
В статье я лишь пытаюсь оценить стоимость выбора между С# и С++ с точки зрения производительности. Разумеется, производительность — далеко не единственный критерий для выбора средства разработки, и поэтому, как правило, нельзя делать выбор основываясь исключительно на нем.
Но я думаю, что вы согласитесь, что даже самые сложные решения состоят из максимально простых элементов.
В разобранном примере продемонстрированы издержки на managed среду (в частности, дополнительные проверки), и думаю даже в самом сложном примере задача обеспечения управления кодом никуда не уйдет.
Поэтому мне кажется экстраполировать само наличие издержек на «менеджмент» кода вполне можно, другое дело что возможно процент кода, необходимого для осуществления «менеджмента» в различных случаях будет разный.
Спасибо. Да, действительно reserve был бы очень полезен в тесте для std::vector.
Я попробовал его добавить в тест, суммарные результаты получились схожими, и хотя создание вектора стало занимать чуть больше времени, зато заполнение вектора данными стало примерно в 2.5 раза быстрее.
Правда сортировка заняла столько же времени (что наверное логично), поэтому сумма изменилась не существенно.
int tmp;
for (int i = 0; i < ITEMS_COUNT; i++)
00000076 xor edx,edx
00000078 mov dword ptr [ebp-38h],edx
for (int j = i; j < ITEMS_COUNT; j++)
0000007b mov ebx,dword ptr [ebp-38h]
0000007e cmp ebx,2710h
00000084 jge 000000BB
00000086 mov esi,dword ptr [edi+4]
{
if (items[i] < items[j])
00000089 mov eax,dword ptr [ebp-38h]
0000008c cmp eax,esi
0000008e jae 000001C2
00000094 mov edx,dword ptr [edi+eax*4+8]
00000098 cmp ebx,esi
0000009a jae 000001C2
000000a0 mov ecx,dword ptr [edi+ebx*4+8]
000000a4 cmp edx,ecx
000000a6 jge 000000B0
000000a8 mov dword ptr [edi+ebx*4+8],edx
items[i] = tmp;
000000ac mov dword ptr [edi+eax*4+8],ecx
for (int j = i; j < ITEMS_COUNT; j++)
000000b0 add ebx,1
000000b3 cmp ebx,2710h
000000b9 jl 00000089
for (int i = 0; i < ITEMS_COUNT; i++)
000000bb inc dword ptr [ebp-38h]
000000be cmp dword ptr [ebp-38h],2710h
000000c5 jl 0000007B
}
}
Спасибо, мне нужно обновить
когда выполнение остановилось на breakpoint, я перешел в disassembly из контекстного меню.
Если есть более правильный способ, распишите его пожалуйста тоже.
Далеко идущие выводы из одной этой оценки вряд-ли стоит делать, но думаю есть смысл принимать их во внимание при анализе среди прочих факторов.
И правда скомпилировал заметно лучше, действительно сильный прогресс в рассмотренном примере.
А проверка выхода за границы массива теперь ушла?
Так же, как понимаю, переменную tmp с оптимизировали до использования регистров?
Вообще конечно надо будет уже скоро переходить на 2015 студию.
Методика заключается в измерении этого времени и анализе disassembly являющегося причиной разницы этого времени. (хотя методика, это наверное слишком громко сказано)
Visual Studio 2010 SP1, С++ компилятор 16.00.40219.01, С# компилятор 4.0.30319.17929.
Почему то не вижу в вашем примере кода для
items[j] = items[i];
items[i] = tmp;
а вижу только код для items[i] = tmp;
Сборщик мусора вызывал для эмуляции delete (о чем писал в статье), ведь в реальном приложении рано или поздно будет потрачено время на сборку мусора, хотелось как то его учесть.
>вместо 10000 использовать items.Length?
Прямо сейчас попробовал. В результате items[j] = items[i]; скомпилировалось в
items[j] = items[i];
00000106 mov eax,dword ptr [ebp-38h]
00000109 mov edx,dword ptr [ebp-58h]
0000010c cmp eax,dword ptr [edx+4]
0000010f jb 00000116
00000111 call 73153D61
00000116 mov eax,dword ptr [edx+eax*4+8]
0000011a mov dword ptr [ebp-4Ch],eax
0000011d mov eax,dword ptr [ebp-3Ch]
00000120 mov edx,dword ptr [ebp-58h]
00000123 cmp eax,dword ptr [edx+4]
00000126 jb 0000012D
00000128 call 73153D61
0000012d mov ecx,dword ptr [ebp-4Ch]
00000130 mov dword ptr [edx+eax*4+8],ecx
На вид явно остались какие то проверки…
Считаете ли вы что менеджмент кода возможно осуществлять без накладных расходов? Если нет, то в чем я не прав, экстраполируя факт наличия расходов на менеджмент простого кода на более сложные случаи?
И если быть более точным, то Visual Studio 2010 SP1, С++ компилятор 16.00.40219.01, С# компилятор 4.0.30319.17929.
Из комментариев я понял, что ряд из моих утверждений в статье про выбор выглядели крайне голословно, и это упущение я понемногу пытаюсь исправить.
Но ведь я говорю чистую правду. Сложное состоит из простого, по крайней мере в разработке ПО.
В разобранном примере продемонстрированы издержки на managed среду (в частности, дополнительные проверки), и думаю даже в самом сложном примере задача обеспечения управления кодом никуда не уйдет.
Поэтому мне кажется экстраполировать само наличие издержек на «менеджмент» кода вполне можно, другое дело что возможно процент кода, необходимого для осуществления «менеджмента» в различных случаях будет разный.
Я попробовал его добавить в тест, суммарные результаты получились схожими, и хотя создание вектора стало занимать чуть больше времени, зато заполнение вектора данными стало примерно в 2.5 раза быстрее.
Правда сортировка заняла столько же времени (что наверное логично), поэтому сумма изменилась не существенно.