Сделаем MS компилятор лучше =)

Некоторые недоделки MS компилера уже достали =) Особенно обидно, потому что компилер неплохой, где-то лучше gcc, где-то хуже.

Проголосуйте за suggestion, если не трудно:

http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedba ckId=9390d202-2fb0-419d-acee-0fbfc6e38881

там я написал недочеты, что щас вспомнил. Объясняю зачем это надо: как я понял, если за suggestion проголосовал 1 человек - то MS его вовсе не рассматривает (что спорно - мало кто вотит за других, тока если при создании нашелся аналогичный suggestion), если 2 - то оно где-то в конце списка и рассмотрение будет не скоро думаю все понятно...

 

вот такое - "...but can`t remember when it happens" они точно смотреть не будут

 

Broken Sword

Ты почитай - там и не такое пишут (тем более в профиле английскими буквами написано, что я русский - мне можно . А вообще я конечно не мастер такие вещи постить(как было так и написал - своими глазами видел конструкцию eax->e?x->eax, но тогда к сожалению не сохранил это дело никуда)... Покрайней мере я сделал все что смог... Если кто умеет лучше - можно еще один создать, поидее гении из MS должны их объединить.

PS: так и не проголосовал зря считаешь это бесполезным делом...

PS2: а вообще, если ругать, то за опечатку "somedimes", которую уже не исправить.

 

semen

мне просто довелось как-то месячишко проработать в quality assurance company, так там даже за это время на составление всевозможных баг-репортов натаскали до такой степени, что теперь составленные любительским способом отчеты вызывают негодование ). Нужно четко указывать последовательность действий, которые приводят к ошибке и еще кучу ньюансов указывать. Я не фанат этого дела, но в данном случае даже не понятно какие именно улучшения ты предлагаешь (я так понял - тебе не нравиться как он оптимизирует - так от этого не уйдешь, это субъективные все вещи)

 

Broken Sword

Ну дык, для того чтоб узнать все точно надо аттач скатать(в 2000 символов н уложился - там все точно написано, где он поступает неверно, и что надо сделать - надо тока прочесть все. Тока совсем по-хорошему надо каждый глюк в отдельный suggestion. Но я же не в "quality assurance" работаю и времени у меня тоже не вагон, пусть спасибо скажут, что хоть так на ляпы указал. И я привел случаи не где "не нравиться как он оптимизирует", а те, где компилер откровенно тупит. Ты вообще аттач смотрел? Там-же все с asm листингами. Так что считаю твои претензии необоснованными - скажи конкретно в каком примере из аттача я не прав и компилер не тупит, а ведь почти во всех случаях убрать глюк не составит труда, а _movss - это вообще баг, мелкий но баг. Лучше бы помог тогда нормальный suggestion составить, если работал в quality assurance company...

 

semen

до аттача не дошел, каюсь.

 

Broken Sword

если с __assume и логикой все четко, то с intrinsic засада, наскока я пока понял глюк происходит из-за того, что компил фиксирует хмм регистр, положим xmm0 для __m128 переменной, после неких вычислений результат положим сформировался в xmm1, но компил все равно переложит результат в выделенный xmm0, несмотря на то, что сформировать результат в xmm0 небыло труда. Выхода 2 - не фиксировать регистр, как GPR и формировать результат где надо(т.е не фиксировать неявные присвоения). Но в момент поста я еще об этом не знал - просто видел что это тупизм и с GPR таких ляпов нет. С неправильной оптимизацией выноса _mm_setzero_ps() за цикл тоже все четко.

 

> Некоторые недоделки MS компилера уже достали =) Особенно обидно, потому что компилер неплохой



Если достали, то используй Intel C компилер, интеловцы уж точно знают как оптимизировать код под свои камни. По моим тестам на крипто-библиотеках (целочисленные операции) прирост скорости от тупого рекомпайла достигал 20%, а при активном использовании в проекти fpu это были разы. Убожище GCC сосет причмокивая одним словом.

 

У меня на AES прирост в скорости у intel'а = 50%. что самое интересное, размер кода одинаков в MSVC =)



Однако, Intel C компилер тоже иногда откровенно тупит - вместо mov eax, esp делает lea eax, esp. Наверное, чтобы на атлонах работало медленнее %) И для вещей вроде memcpy для блоков в пару байт вызывает внешнюю функцию из либы %) в то время, как MSVC делает простой movds.

 

Есть еще модуль к MSVC под названием Vector C... Я игрался с ним, там можно получить очень оптимизированный код по размеру или скорости...

 

Dr.Golova

Про интел компилер я знаю и тоже его юзаю и в свое время на интел тоже постил репорты, но и он не идеален, по тупизму примерно равен MS и 50% различия никогда не позволял, всегда добивался примерно равной скорости без применения асма. Для интела есть еще недостаток, что надо гораздо больше контролировать то что делает компилятор, например иногда совершенно разные ключи компиляции необходимы для разных файлов проекта или давать указания #pragma везде, например что этот кусок векторизировать не надо - иначе будет перфоманс дроп. Ну и остальное про что говорил Стас. MS в этом отношении лучше - не делает лишнее, хотя в 8й студии компил уже больше походит на интел - кискификатор вырезали, что плохо. А вообще интел(8.1.018) прошел все тесты что я запостил, кроме __assume и logic_test. intrinsic, logic_test1 и logic_test2 прошли на ура, с чем не справился MS. Короче удалить эти ляпы (ну и может быть внести векторизатор, но только для PGO) и MS будет рулить. Да, чуть не забыл - интел платный, а VS2005Tools можно юзать свободно, хотя деньги вобщем небольшие.

Версию gcc и ключи компиляции в студию.



Tim Sobolev

Очень интересно, что за Vector C?

 

semen >

Ну это не всегда так - он бывает начинает тупо разворачивать циклы где не нужно, и единственный известный мне способ его вразумить - __asm nop в нужном месте :/



>

В моём случае это не реально - MSVC интенсивно пихает в/из памяти промежуточные данные, а Intel лучше обходится недостаточным для алго количеством регистров. Мои попытки улучшить код привели к увеличению корости и там и там хотя сильно не старался





VS2005Tools - это Express Beta? У меня постоянно IDE падает =) Да и юзать его свободно для коммерческого использования нельзя.

 

S_T_A_S_

Ну дык интел это делает куда активнее. Кстати именно для этого и нужен __assume c <, > - чтоб без PGO указать компилеру что разворачивать ничего не надо, в аттаче там есть такой тест - __assume с радостью хинт глотает, но не юзает, пашет тока == и !=.

Ну тут ничего не могу сказать - мне всегда удавалось. Может ты юзаешь не тот MS компилер? У меня v14.00.41115.19

Нет VS2005Tools это тока компилятор без ИДЕ, но бесплатно и можно юзать в коммерческих целях...

PS: так никто и не проголосовал - чтож все такие ленивые...

 

Про "разворачивание" я наврал чуток, уточняю:

Code (Text):

1.  
2. while( 1 )
3. {
4.     do_someting();
5.     if( its_time ) break;
6.     do_someting_else();
7. }

Такой код преобразуется к

Code (Text):

1.  
2. do_someting();
3. while( ! its_time )
4. {
5.     do_someting_else();
6.     do_someting();
7. }

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





>

Это что ли Visual C++ 2005 Tools Refresh? не могу найти ничего на их сайте :-(

у мя 13.10.х.з.

 

S_T_A_S_

ИМХО все верно она делает - это оптимизация для P4 - чтоб не делать в цикле бранч вперед, при этом если цикл не нулевой то все переходы статически предскажутся верно:

Code (Text):

1. #include <stdio.h>
2.  
3. volatile int its_time;
4.  
5. void do_someting()
6. {
7.   printf("a\n");
8. }
9.  
10. void do_someting_else()
11. {
12.   printf("b\n");
13. }
14.  
15. void f()
16. {
17.   while( 1 )
18.   {
19.     do_someting();
20.     if( its_time ) break;
21.     do_someting_else();
22.   }
23. }
24. /*
25. ?f@@YAXXZ PROC                      ; f, COMDAT
26. ; Line 19
27.     push    OFFSET ??_C@_02LDEEGPHA@a?6?$AA@
28.     call    _printf
29. ; Line 20
30.     mov eax, DWORD PTR ?its_time@@3HC       ; its_time
31.     add esp, 4
32.     test    eax, eax
33.     jne SHORT $LN12@f
34. $LL3@f:
35. ; Line 21
36.     push    OFFSET ??_C@_02LBACNBCJ@b?6?$AA@
37.     call    _printf
38.     push    OFFSET ??_C@_02LDEEGPHA@a?6?$AA@
39.     call    _printf
40.     mov ecx, DWORD PTR ?its_time@@3HC       ; its_time
41.     add esp, 8
42.     test    ecx, ecx
43.     je  SHORT $LL3@f
44. $LN12@f:
45. ; Line 23
46.     ret 0
47. ?f@@YAXXZ ENDP                      ;
48. */

Без такой оптимизации прескотту будет не сладко

 

semen >

это же выход из цикла по условию! он и так будет предсказан как not taken.

Code (Text):

1.  
2. ?f@@YAXXZ PROC
3. l00p:
4.     push    OFFSET ??_C@_02LDEEGPHA@a?6?$AA@
5.     call    _printf
6.     mov eax, DWORD PTR ?its_time@@3HC
7.     add esp, 4
8.     test    eax, eax
9.     jne SHORT $LN12@f
10. $LL3@f:
11.     push    OFFSET ??_C@_02LBACNBCJ@b?6?$AA@
12.     call    _printf
13.     mov ecx, DWORD PTR ?its_time@@3HC
14.     add esp, 8
15.     test    ecx, ecx
16.     je  l00p
17. $LN12@f:
18.     ret 0
19. ?f@@YAXXZ ENDP

и там не всё так просто: do_someting() - это большая куча кода, а не call. и этот цикл крутится в другом. в результате "оптимизации" падение скорости 10% (начинает ещё интенсивнее хранить промежуточные результаты в памяти). intel не делает такой бесполезной лабуды.

 

S_T_A_S_

Да, ступил - предсказание тут не причем. И все же в твоем случае 2 бренча во внут. цикле вместо одного - короче тут надо как-то решение пренимать - надо это делать или нет, но все-же это оптимизация - иначе перфоманс будет падать в другом случае - когда это маленький и критичный цикл. А вот критерий выбора видать подкачал или его вообще нет...

Кстати MS поступает точно так-же как интел в случае ключа /Os:

Code (Text):

1. ?f@@YAXXZ PROC                      ; f, COMDAT
2. ; Line 20
3.     jmp SHORT $LN11@f
4. $LL3@f:
5. ; Line 21
6.     call    ?do_someting_else@@YAXXZ        ; do_someting_else
7. $LN11@f:
8. ; Line 19
9.     call    ?do_someting@@YAXXZ         ; do_someting
10. ; Line 20
11.     mov eax, DWORD PTR ?its_time@@3HC       ; its_time
12.     test    eax, eax
13.     je  SHORT $LL3@f
14. ; Line 23
15.     ret 0
16. ?f@@YAXXZ ENDP                      ;
17.  

Короче это уже из раздела как компилятор должен правильно принимать решения, а не из раздела ляпов о коих идет речь в suggestion.

PS: это не ты проголосовал и поставил 4? Походу лучше не голосовать чем 4 ставить - рейтинг стал хуже...

 

semen

Никак не могу увидеть каких-то приимуществ - бранчей всегда 2 - условный и безусловный. Разве что при каких-то загадочных условиях код за меткой $LN12@f в моём примере может оказаться не в кэше при джампе на него .

/Os не решение - будет ещё медленнее.

Короче, IMHO, это не ляп, а design flow =)



ЗЫ: я ещё не проголосовал, жутко всё тормозит на их сайте с моим инетом. буду чегонибуть качать - проголосую

 

S_T_A_S_

Кхм, может я опять туплю, но в случае MS внутри цикла бранч один:

Code (Text):

1. $LL3@f:
2. ; Line 21
3.     push    OFFSET ??_C@_02LBACNBCJ@b?6?$AA@
4.     call    _printf
5.     push    OFFSET ??_C@_02LDEEGPHA@a?6?$AA@
6.     call    _printf
7.     mov ecx, DWORD PTR ?its_time@@3HC       ; its_time
8.     add esp, 8
9.     test    ecx, ecx
10.     je  SHORT $LL3@f
11.  

Так что в оптимизации смысл есть - тока что проверил - быстрее...

 

semen

Да, действительно, получается меньше на бранч. Но прирост в скорости от выкидывания одной инструкции - довольно сомнительная вещь. В случаях, когда в цикле всего пара команд лишний джамп может и влияет (хотя, иногда, "лишняя" инструкция может увеличить скорость - в случае P6 из-за портов, например).

А когда в цикле пара тысяч инструкций - этот джамп не будет заметен.

И вот делая "полуразвёртывание" цикла компилер ещё лишнюю тыщу добавляет. У компилера из-за этого как раз проблемы и начинаются - он плохо соображает что в каком регистре хранить на больших линейных участках кода. Ты же сам писАл про подобные проблемы с XMM регистрами.