VisualC vc VisualC Express
Slawa Olhovchenkov
А то на экспресовский плюются жутко, на оптимизатор.
http://netch.livejournal.com/41508.html?thread=249636
--
Slawa Olhovchenkov
Alex Kotov
>А у сабжей компиляторы одинаковые или нет?
Компилятор у VS2005 PE/TE точно отличается -- у него поддержка
amd64/em64t есть. По слухам компилятор у VC++ 2005 Express точно такой же
как и в VS2005 SE. Однако Express обделили библиотеками -- точно отсутствуют
MFC и ATL. ATL, впрочем, народ приспособился древнюю из Platform SDK брать.
> А то на экспресовский плюются жутко, на оптимизатор.
>
> http://netch.livejournal.com/41508.html?thread=249636
Брешуть. Вот что выдал VS2005 PE:
; Listing generated by Microsoft (R) Optimizing Compiler Version
14.00.50727.42
.686P
.XMM
include listing.inc
.model flat
INCLUDELIB MSVCRT
INCLUDELIB OLDNAMES
PUBLIC _main
; Function compile flags: /Ogtpy
; File test.cpp
; COMDAT _main
_TEXT SEGMENT
_main PROC ; COMDAT
; 2 : int n, a, b;
; 3 : return 0;
xor eax, eax
; 4 : }
ret 0
_main ENDP
_TEXT ENDS
END
Valentin Nechayev
>> А то на экспресовский плюются жутко, на оптимизатор.
>> http://netch.livejournal.com/41508.html?thread=249636
AK> Брешуть. Вот что выдал VS2005 PE:
Что "брешуть"? У express'а действительно кроме разрешения SSE и
SSE2 других рычагов нет (или ткните в конкретное место в
настройках). Может, потому что express - не знаю, до полного не
добрался.
AK> ; 2 : int n, a, b;
AK> ; 3 : return 0;
Так это не тот тест - на 'int n, a, b' gcc проверяется, а не
MSC.;)
-netch-
Cyril Novikov
>>А у сабжей компиляторы одинаковые или нет?
> Компилятор у VS2005 PE/TE точно отличается -- у него поддержка
> amd64/em64t есть. По слухам компилятор у VC++ 2005 Express точно такой же
> как и в VS2005 SE. Однако Express обделили библиотеками -- точно отсутствуют
> MFC и ATL. ATL, впрочем, народ приспособился древнюю из Platform SDK брать.
>
>> А то на экспресовский плюются жутко, на оптимизатор.
>>
>> http://netch.livejournal.com/41508.html?thread=249636
> Брешуть. Вот что выдал VS2005 PE:
Ну это-то понятно. Этот компилятор явно полагает, что ему дадут уже
выровненный стек. netch явно испытывал его на чем-то более сложном.
--
Кирилл
Alex Kotov
> Что "брешуть"? У express'а действительно кроме разрешения SSE и
> SSE2 других рычагов нет (или ткните в конкретное место в
> настройках).
Тычу: сперва переключить конфигурацию проекта из Active(Debug) в
Active(Release). Затем в свойствах проекта выбрать Configuration
Properties->C/C++->Optimization. Там есть:
Optimization: /Od, /O1, /O2, /Ox
Inline function expansion
Enable intrinsic functions
Favor size or speed
Omit frame pointers
Enable fiber-safe optimizations
Whole program optimization
Как это из коммандной строчки рулится лень смотреть.
> Может, потому что express - не знаю, до полного не добрался.
Выше информация для Visual C++ 2005 express edition. На самом деле в
express тоже оптимизирующий компилятор. И судя по настройкам поддерживает
даже PGO.
> AK> ; 2 : int n, a, b;
> AK> ; 3 : return 0;
>
> Так это не тот тест - на 'int n, a, b' gcc проверяется, а не
> MSC.;)
Я подставил что на странице предлагалось ;)
SY,
Alex Kotov
Alex Kotov
> Ну это-то понятно. Этот компилятор явно полагает, что ему дадут уже
> выровненный стек. netch явно испытывал его на чем-то более сложном.
Ну так пусть не молчит а дает то на чем испытывал -- у меня есть
релизные Express, 2005 Standard Edition и 2005 Professional Edition.
SY,
Alex Kotov
Valentin Nechayev
>> Что "брешуть"? У express'а действительно кроме разрешения SSE и
>> SSE2 других рычагов нет (или ткните в конкретное место в
>> настройках).
AK> Тычу: сперва переключить конфигурацию проекта из Active(Debug) в
AK> Active(Release). Затем в свойствах проекта выбрать Configuration
AK> Properties->C/C++->Optimization. Там есть:
AK> Optimization: /Od, /O1, /O2, /Ox
Стоп. Это всё есть, против этого я не возражал. Хотя, как вижу,
неясно выразился. То что не нашёл - выбор оптимизации под процессор
более детальный чем включение того или иного SIMD (кстати, как я
понял - предполагается, что MMX есть всегда? Надо ещё раз в доке
порыться)
>> Может, потому что express - не знаю, до полного не добрался.
AK> Выше информация для Visual C++ 2005 express edition. На самом деле в
AK> express тоже оптимизирующий компилятор. И судя по настройкам поддерживает
AK> даже PGO.
Что он оптимизирует я не возражаю - он в позе "whole program
optimization" ухитрился у меня свернуть каскад глубины 4 в вывод
двух констант.
> AK>> ; 2 : int n, a, b;
> AK>> ; 3 : return 0;
>> Так это не тот тест - на 'int n, a, b' gcc проверяется, а не
>> MSC.;)
AK> Я подставил что на странице предлагалось ;)
Ну с темой push'ей была неявная ссылка на моё общение с Кириллом в
ru.unix.prog. В более новых комментариях есть явная.
-netch-
Alex Kotov
> Стоп. Это всё есть, против этого я не возражал. Хотя, как вижу,
> неясно выразился. То что не нашёл - выбор оптимизации под процессор
> более детальный чем включение того или иного SIMD
А нету. Т.е. есть TargetMachine, но оно лишь глобально архитектуру
выбирает. Конкретный процессор для machineX86 указать нельзя. Причем не
только в Express Edition, но и в Professional.
> (кстати, как я понял - предполагается, что MMX есть всегда? Надо ещё раз в
> доке
> порыться)
ХЗ, не разбирался.
>>> Так это не тот тест - на 'int n, a, b' gcc проверяется, а не
>>> MSC.;)
> AK> Я подставил что на странице предлагалось ;)
> Ну с темой push'ей была неявная ссылка на моё общение с Кириллом в
> ru.unix.prog. В более новых комментариях есть явная.
Все равно лишних push'ей у MSVC Express/Pro не вижу. Если какие и
появляются то обусловлены передачей параметров через стэк тому коду который
свернуть не удалось как и просили компилятор.
SY,
Alex Kotov
Konstantin Topanov
You wrote in news:2006012922...@quarta.carrier.kiev.ua
to Alex Kotov <al_k...@ukr.net> on Mon, 30 Jan 2006 00:14:59 +0200:
[skipped]
AK>> Properties->C/C++->Optimization. Там есть:
AK>> Optimization: /Od, /O1, /O2, /Ox
VN> Стоп. Это всё есть, против этого я не возражал. Хотя, как вижу,
VN> неясно выразился. То что не нашёл - выбор оптимизации под процессор
VN> более детальный чем включение того или иного SIMD (кстати, как я
VN> понял - предполагается, что MMX есть всегда? Надо ещё раз в доке
VN> порыться)
http://msdn.microsoft.com/library/en-us/dnppcgen/html/migrating_evc_vs2005.asp
Migrating Microsoft eMbedded Visual C++ Projects to Visual Studio 2005
Nishan Jebanasam
Microsoft Corporation
[...]
/G3, /G4, /G5, /G6, /G7, and /GB compiler options have been removed.
The compiler now uses a blended model that attempts to create the best
output file for all architectures.
[...]
--- With kind regards,
Konstantin (ddt.demos.su)
Valentin Nechayev
>> Стоп. Это всё есть, против этого я не возражал. Хотя, как вижу,
>> неясно выразился. То что не нашёл - выбор оптимизации под процессор
>> более детальный чем включение того или иного SIMD
AK> А нету. Т.е. есть TargetMachine, но оно лишь глобально архитектуру
AK> выбирает. Конкретный процессор для machineX86 указать нельзя. Причем не
AK> только в Express Edition, но и в Professional.
Угу, см. также соседнее письмо Топанова. Логика к тому конечно
сомнительна - да, старые различия, существенно менявшие принципы
оптимизации для 386/486/P1 ушли в прошлое, но ведь и новых дофига и
больше - и есть отзывы о том что применение специфических для P4
оптимизаций может ускорять код _в разы_.
> AK>> Я подставил что на странице предлагалось ;)
>> Ну с темой push'ей была неявная ссылка на моё общение с Кириллом в
>> ru.unix.prog. В более новых комментариях есть явная.
AK> Все равно лишних push'ей у MSVC Express/Pro не вижу. Если какие и
AK> появляются то обусловлены передачей параметров через стэк тому коду который
AK> свернуть не удалось как и просили компилятор.
Ты не понял. См. вот здесь наиболее яркую формулировку:
http://groups.google.ru/group/fido7.ru.unix.prog/msg/c02df7067450bfa8
Суть в том, что передача через стек совершенно необязательно требует
push или pop, а наоборот - может без них обходиться. Да, может;
осталось понять, обязана ли. И вот тут начинаются разногласия.
Собственно утверждение про зависимости команд push/pop по *SP
настолько очевидны, что логика Intel C по обратному включению
push/pop при оптимизации (и невключении без оптимизации - см.
http://netch.livejournal.com/41508.html?thread=251172#t251172)
выглядит крайне неожиданно. Вот с этого собственно и начался тред
здесь: с того, специфичен ли акцент на push/pop для MSC "взрослого",
зависит ли это от каких-либо регулировок которых нет в express
версии.
-netch-
Alex Kotov
> Ты не понял. См. вот здесь наиболее яркую формулировку:
> http://groups.google.ru/group/fido7.ru.unix.prog/msg/c02df7067450bfa8
>
> Суть в том, что передача через стек совершенно необязательно требует
> push или pop, а наоборот - может без них обходиться. Да, может;
> осталось понять, обязана ли. И вот тут начинаются разногласия.
> Собственно утверждение про зависимости команд push/pop по *SP
> настолько очевидны, что логика Intel C по обратному включению
> push/pop при оптимизации (и невключении без оптимизации - см.
> http://netch.livejournal.com/41508.html?thread=251172#t251172)
> выглядит крайне неожиданно.
Это неожиданно если не читал IA-32 Architecture Optimization Reference
Manual
ftp://download.intel.com/design/Pentium4/manuals/24896612.pdf
В нем говорится что современные интеловские процессоры используют
технику ESP Folding при которой серия PUSH/POP и прочих которые _неявно_
используют ESP stalls не вызывает и спокойно распараллеливается.
SY,
Alex Kotov
Alex Kotov
> больше - и есть отзывы о том что применение специфических для P4
> оптимизаций может ускорять код _в разы_.
Это каких это и на каком коде? Чтобы именно специфических для P4 и
именно в разы. Ничего кроме использования SSE/SSE2/SSE3 не придумывается.
Если ты об компиляторе от Intel так он же махлюет -- для p4 кроме чистого
fp87 кода вставляет еще и SSE2 версию и в рантайме определяет как он будет
математику считать. Причем на процессорах от Amd выбирает обычный fp87 даже
если процессор SSE/SSE2 поддерживает.
> логика Intel C по обратному включению
> push/pop при оптимизации (и невключении без оптимизации - см.
> http://netch.livejournal.com/41508.html?thread=251172#t251172)
> выглядит крайне неожиданно. Вот с этого собственно и начался тред
> здесь: с того, специфичен ли акцент на push/pop для MSC "взрослого",
> зависит ли это от каких-либо регулировок которых нет в express
> версии.
Акцент на push/pop для ia-32 будет специфичен для всех современных
оптимизирующих компиляторов которые хотят генерировать код выполняемый
быстро на процессорах от Intel. Взрослый MSVC от MSVC Express в этом смысле
ничем не отличается. Все регулировки оптимизации которые есть у Professional
и не относятся к amd64/em64t есть и у Express Edition. У меня обе эти версии
сейчас установлены поэтому могу сравнивать.
SY,
Alex Kotov
Cyril Novikov
>> Суть в том, что передача через стек совершенно необязательно требует
>> push или pop, а наоборот - может без них обходиться. Да, может;
>> осталось понять, обязана ли. И вот тут начинаются разногласия.
>> Собственно утверждение про зависимости команд push/pop по *SP
>> настолько очевидны, что логика Intel C по обратному включению
>> push/pop при оптимизации (и невключении без оптимизации - см.
>> http://netch.livejournal.com/41508.html?thread=251172#t251172)
>> выглядит крайне неожиданно.
> Это неожиданно если не читал IA-32 Architecture Optimization Reference
> Manual
> ftp://download.intel.com/design/Pentium4/manuals/24896612.pdf
> В нем говорится что современные интеловские процессоры используют
> технику ESP Folding при которой серия PUSH/POP и прочих которые _неявно_
> используют ESP stalls не вызывает и спокойно распараллеливается.
О как. Другими словами, они запись в память и изменение ESP слили в один
микрооп.
Но это только Pentium M, если верить написанному.
--
Кирилл
Alex Kotov
> Но это только Pentium M, если верить написанному.
Если есть VTune то можно в нем посмотреть как к такому коду оригинальный
P4 отнесется. Мой склероз мне врет что и у P4 о какой-то фишке с PUSH/POP я
несколько лет назад читал.
SY,
Alex Kotov
Cyril Novikov
>> Но это только Pentium M, если верить написанному.
> Если есть VTune то можно в нем посмотреть как к такому коду оригинальный
> P4 отнесется. Мой склероз мне врет что и у P4 о какой-то фишке с PUSH/POP я
> несколько лет назад читал.
Судя по тому, что латентность операций PUSH и POP на П4 обозначена как
1.5, никаких особых фишек там нет. Только обычная оптимизация благодаря
архитектуре:
http://netch.livejournal.com/41508.html?thread=250660#t250660
--
Кирилл
Alex Kotov
>>> Но это только Pentium M, если верить написанному.
Может быть, спорить не стану. Если найду старый optimization manual на
DVDшках с backup'ами то гляну что мне там привиделось.
SY,
Alex Kotov
Valentin Nechayev
>> Собственно утверждение про зависимости команд push/pop по *SP
>> настолько очевидны, что логика Intel C по обратному включению
>> push/pop при оптимизации (и невключении без оптимизации -
>> выглядит крайне неожиданно.
AK> Это неожиданно если не читал IA-32 Architecture Optimization Reference
AK> Manual
AK> ftp://download.intel.com/design/Pentium4/manuals/24896612.pdf
AK> В нем говорится что современные интеловские процессоры используют
AK> технику ESP Folding при которой серия PUSH/POP и прочих которые _неявно_
AK> используют ESP stalls не вызывает и спокойно распараллеливается.
Там есть вот такое:
=== cut ===
Assembly/Compiler Coding Rule 61. (M impact, M generality) Avoid
putting explicit references to ESP in a sequence of stack operations
(POP, PUSH, CALL, RET). 2-84
=== end cut === (страницы 2-83 и 2-97)
Про ESP folding написано только про Pentium M (страница 1-28).
Но как тогда быть с кодом который icc генерирует при -O2, -O3?
..B1.1: # Preds ..B1.0
pushl 12(%esp) #2.1
pushl 12(%esp) #2.1
pushl 12(%esp) #2.1
Они нарушают собственное правило?
Включение указания оптимизировать под Pentium M не помогает.
-netch-
Alex Kotov
> Но как тогда быть с кодом который icc генерирует при -O2, -O3?
>
> ..B1.1: # Preds ..B1.0
> pushl 12(%esp) #2.1
> pushl 12(%esp) #2.1
> pushl 12(%esp) #2.1
>
> Они нарушают собственное правило?
А что им еще для твоего кода остается делать? Пачку mov'ов нагенерить
каждый из которых будет исполняться столько же сколько и push, но которые за
счет количества свое возьмут? Не, серьезно, напиши код который с твоей точки
зрения будет работать лучше для твоего случая копирования параметров
вызывающей функции в вызываемую.
SY,
Alex Kotov