Компилятор msvc2010

получается

вместо cmp     [ecx+18h], esi
хорошо бы чтобы константа прибавлялась не на каждой итерации цикла, а один раз в самом начале
также не есть хорошо jnz short not_a_value / inc eax / not_a_value


------------
Тема не предполагает какого-то обсуждения, просто примеры плохого кода генерируемого MSVC.
Как написать код С++ с явным циклом вместо std::count, чтобы сгенерился оптимальный код - я знаю, объяснять мне это не надо.

MSVC-* - гуан* и ее STL - тоже гуан*. © Abyx

Прошу прощение, не удержался.

djamshud, так ведь g++ то еще хуже =)

Abyx, может и хуже, но я на нем пишу так, что решения из STL сливают, изредко многократно. Когда писал на MSVC тоже сливали. Так что мое имхо, что STL само по себе тупое неповоротливое решение by design.

Эх... не могу удержаться... Нами всеми любимая std::sort


..... барабанная дробь...



????!!!!

поясняю: mov eax, 92492493h / imul ecx это деление на sizeof(Foo), чтобы получить число элементов диапазона.
деление умножением это быстро. (у нас стоит оптимизация по скорости) 

смотрим дальше.

all the same shit, +18h

однако лямбда заинлайнилась везде где есть ее вызов (об этом кстати говорят и имена функций)

----------------------
как убрать +18h в каждой итерации, и при этом использовать std::sort я тоже знаю

А я... а Я.... вы либо код показывайте, либо прекращайте сказки рассказывать %)

Добавлено через 13 минут и 32 секунды
продолжаем....

возьмем-ка мы, и уберем лямбду

дизасмим, и...

ой, передача указателя...

а теперь лулзы:

да... и вот эта _cdecl хрень вызывается на каждой итерации, с прологами, эпилогами....

пишем "inline bool pred(const Foo& a, const Foo& b)"...
... и ничего не происходит.

пишем "bool __fastcall pred(const Foo& a, const Foo& b)", и получаем

да, прологов\эпилогов нет, компилятор даже воткнул xor ecx, ecx чтобы спарить инструкции, но всеравно вызов функции на каждой итерации это дороговато, по сравнению с ее телом.

Abyx,

>А я... а Я.... вы либо код показывайте, либо прекращайте сказки рассказывать %)

Хорошо, вечером я попробую найти сортировку, писанную мной года три-четыре назад чисто в академическом интересе, которая сильно нагибала std::sort и std::sort_как_его_там. Но вообще как я уже писал, считаю сортировку (в чистом виде!) мало применимой в реальном программировании. Что касается вектора, строки и списка - они в STL очень тупы даже несмотря на реализованый для них (в gcc) CoW. Но свои реализации сейчас выложить не могу, так что это пусть пока останется сказкой о силе.

Добавлено через 2 минуты
Abyx, эмм. Так мое предположение о вызовах функций таки подтвердилось? В gcc, я смотрел, на агрессивной оптимизации коллбеки разворачивались в инлайны.

djamshud, да, я тоже счя смотрю гцц, там последний пример инлайнится. И у гцц вроде существенно меньше кода.
Хотя я хз хорошо или это или нет, надо замерить производительность.

не.. там все интереснее, у гцц. оно инлайнит, но не везде, о_О

coming soon в соседнем разделе

тот же код, скомпилированный gcc:
http://forum.vingrad.ru/index.php?showtopi...t&p=2202122

Это сообщение отредактировал(а) Abyx - 24.8.2010, 14:11

у вас что-то тормозит или это просто преждевременная оптимизация?

jonie, перечитайте тему, если не осилили.

И в чем тогда смысл этого топика? Все знают, что VC плохой, g++ плохой, C++ Builder еще хуже, и что дальше? Люди пишут на них программы (причем, часто с использованием STL), они отлично работают и никто не жалуется.
Оптимизация ради оптимизации - это, ИМХО, дело людей, которые не создают реальных проектов.

Продолжаем.

Хвостовая рекурсия, оптимизируем по размеру.


Если убрать __fastcall, код разрастется из за прологов\эпилогов и не будет разворачиваться.
Видим что присутствует лишняя работа с регистром esi.
Студия следует соглашениям вызова, и не хочет использовать другие регистры для предачи параметров.

Интересно то, что функция не инлайнится. Однако в месте вызова мы видим

Т.е. первая итерация инлайнится, а остальные - нет.

Abyx, Посмотрите реализацию АПИ в kernel32.dll на Windows 7 вообще улыбает...
     Сохранения кадра стека.
      Перенаправления на kernelbase.dll

На самом деле все решает алгоритм, а не несколько инструкция(дажет если это 1000 инструкция или миллион, за частую это виду только в крипто алгоритмах).