нарисовал не совсем корректный тест, но всё-же представления о разницах даёт. только у него какой-то зюк - работает в отладчике нормально, а без падает. и масм почему-то добавил мне в код мусора - вообще (.) Код (Text): .686 .model flat, stdcall option casemap:none include windows.inc include kernel32.inc include user32.inc includelib kernel32.lib includelib user32.lib .data formstr db "%i", 0 lpOut db 16 dup(0) lpOut2 db 16 dup(0) sCicl db "for cicle", 0 sFlat db "for flat", 0 .data? starttest dd ? timecicle dd ? .code start: rdtsc mov starttest, dword ptr eax mov ecx, 10000h testloop1: xor eax, eax loop testloop1 rdtsc sub eax, starttest mov timecicle, eax invoke wsprintfA, offset lpOut, offset formstr, eax invoke MessageBox, 0, offset lpOut, offset sCicl, MB_OK test2: rdtsc mov starttest, dword ptr eax dw 10000h dup(33c0h) rdtsc sub eax, starttest invoke wsprintfA, offset lpOut2, offset formstr, eax invoke MessageBox, 0, offset lpOut2, offset sFlat, MB_OK invoke ExitProcess, 0 end start http://ifolder.ru/8975617 это бинарик с мусором, как такое стало возможно?
Про С компилятор понятно. А Вы уверены, что транслятор в машинный код это учитывает? Думаю разницы нет. wsd dw 10000h dup(33c0h) Это такая программа? Нужно бы нормального алгоритма примерчик )
0040104B C033 C0 SAL BYTE PTR DS:[EBX],0C0 ; Shift out of range это потому что ты не учёл что младший байт сначала правильно dw 10000h dup(0c033h) Тест действительно некорректный хотя и наглядный - на малых повторах цикл значительно медленнне ибо там две команды xor + loop (которая быстрее выполняется если разбить её на части , но на 10000h время становится приблизительно равным значит есть замедление из-за кеширования, но реальный код не состоит из бессмысленных xor, а потому реальные команды дают большую фору на предварительное кеширование и формирование очереди в соотвествии с предсказанием переходов. Так что не всё однозначно, но в целом согласен - злоупотреблять инлайнами также не правильно как и их недооценивать. only dw 100000h dup(0c033h) это xor eax, eax развёрнутый в линейный код вместо цикла.
Y_Mur У меня пример wsd с циклом примерно в два раза быстрее. Но дело конечно в том, что бессмысленно инлайнить код, когда выйгрыш от этого мизерный. Просто увеличиваем размер программы, а толку никакого. Вот по-этому "умный" инлайн и кстати.
бессмысленный спор. напишите прогу с длинными инлайнами (или вызовом через строчку. ессно функа int foo(){return 0;} сообразится однозначно вне зависимости от инлайнов) и короткими не инлайнами или средними инлайнами и неинлайнами. скомпильте с разными оптимизациями на нормальном компиле. полюбуйтесь на прибор ложимый компилем на ваши инлайны иже и их отсутствие. имхо единственный боле-мене способ чтоб компиль не заинлайнил или не проилиминировал функу если сочтет нужным - ехтерн на ней.
Инлайнить функции по 100кб такой же бред, как измерять производительность цикла с 1 машинной командой. Тест высосан из пальца и слишком далёк от реальности. На практике, я считаю, издержки на вызовы функции в большинстве случаев будут незаметны. Причём ситуация примерно следующая(так я себе представляю). Если функция маленькая(3-4 строки, что в среднем составляет 10-20 машинных команд), то в таком случае время потраченной на её вызов будет всего-лишь в несколько раз меньше времени исполнения самой функции. Поэтому её вроде как имеет смысл заинлайнить. Но в то же время прирост от инлайна будет заметене при очень частом вызове функции(миллиарды раз). Время выполнения средних функций по отношению к вызову составляет 1-2%(из моих собственных наблюдений), поэтому тут и экономия мизерная. Большие функции не рассматриваем, их инлайнить бессмысленно. Но смысл в том, что инлайн не только позволяет сэкономить на вызове и сбросах конвеера на вызове(и что там ещё на аппаратном уровне происходит, знатоки поправьте), а в то же время существует масса ситуаций, когда инлайн снижает кол-во обращений к памяти или позволяет сэкономить время на копировании объекта(в C++). А макросы я не люблю, ибо они усложняют код и его восприятие и их сложно отлаживать.
W4FhLF да с кодом ксора от усталости попутал. там в тесте ещё косячок с рдтск, не учитывается EDX, может выстрелить. тест действительно не прецизионный но можеш в dup(33c0h) загнать более осмысленный код и увеличить множитель дупа. а ты как предлагаеш померять?
