Ключ /MP в Visual Studio 2008 говорит компилятору запускать несколько процессов на компиляцию. Что полезно, если у вас многоядерный процессор.
Но 2008-й студией мало кто пользуется. Вот 2005-я втречается чаще. И там тоже эта возможность есть, только она не задокументирована. Герб Саттер об этом написал в своем блоге. Дело в том, что они не успели как следует закончить ее и 2005-я студия вышла без этого волшебного ключика в документации. Но он там вполне себе работает. Может сглючить, конечно, но максимум чем вам это грозит - полным rebuild'ом проекта.
Я попробовала /MP на одном небольшом проекте и rebuild у меня уменьшился с 41 секунды до 27.
пятница, апреля 25, 2008
Ключ /MP в Visual Studio
Подписаться на:
Комментарии к сообщению (Atom)
Atom feed
18 коммент.:
Компиляцию ускоряет действительно.
Я вот тут для Qt шников отписал, как только Suttter признался.
http://wiki.qtcentre.org/index.php?title=Qt4_with_Visual_Studio#Multicore_processors
А то я всё переживал как же так в Linux make -j [processMax] есть
а в VS не было ничего, для распараллеливания компиляции.
Только странно, что он об этом сейчас сообщил, мог бы и раньше на годик два...
Всем срочно спать :)
2Borisov Sergey:
Только странно, что он об этом сейчас сообщил, мог бы и раньше на годик два...
Они и раньше об этом писал, я не обратила внимания просто.
Спасибо!
Попробовал - время компиляции одного проекта сократилось с 3m15s до 2m10s. Надо на полном продукте попробовать - сейчас он больше получаса собирается.
Теперь начал тоже хотеть 4х-ядерный процессор.
не уверен что на маленьких проектах компилирующихся меньше 5 минут корректно сравнивать время компиляции с этим ключом и без него :)
а вообще хочу добавить о системах распараллеливания компиляции по сети - когда другие компьютеры в сети участвуют в сборке твоего проекты - мы для этого под windows используем IncrediBuild а под линуксом - TeamBuilder
чего и вам советую :) время сборки одного прошлого проекта уменьшилось с 40 минут до 10-15. Текущий проект теперь под линуксом собирается 15-20 минут вместо нескольких часов.
А вот для C# я ничего такого не нашел... Обидно.
Для одного ядра тоже должен повышать скорость, по крайней мере в GNU make утилизация процессора больше становится
[b]2 rocker[/b]
Скорость компиляции C# проектов и так во много раз выше чем С++
Гм, это прикол такой ? Оно и так по умолчанию включено в среде, если система мультипроцессорная. Надо же, больше года пользуюсь, как на VS2005 перешёл, а оказывается это тайна :-D
См. Tools\Options\Projects and Solutions\Build and Run\maximum number of parallel project builds
2Анонимный
Гм, это прикол такой ? Оно и так по умолчанию включено в среде, если система мультипроцессорная. Надо же, больше года пользуюсь, как на VS2005 перешёл, а оказывается это тайна :-D
См. Tools\Options\Projects and Solutions\Build and Run\maximum number of parallel project builds
Нет, это другая параллельность. Это возможность параллельно собирать несколько проектов. /MP распараллеливает компиляцию одного проекта.
Почитай у Саттера, он подробнее об этом пишет.
Ок, не обратил внимания, согласен :)
а мы в 2005-й студии наткнулись на баг (уже отрепорченный), когда происходила неправильная инстанциация статических объектов при использовании boost.spirit из boost 1.35
для MSVS2005 есть адд-ин, который разблочивает эту функцию.
вот он: http://www.todobits.es/mpcl.html
2Анонимный:
для MSVS2005 есть адд-ин, который разблочивает эту функцию.
вот он: http://www.todobits.es/mpcl.html
Добавляет к ней интерфейс, скорее. А так она не заблокировна - бери и пользуйся. Но не документирована и интерфейса к ней нет.
К сожелению
"Command line warning D9030 : '/Gm' is incompatible with multiprocessing; ignoring /MP switch"
Тоесть польза только при полном ребилде. А его кстати было бы хорошо делать чем-то вроде CruiseControl.
Почему-то глючило с сишными библиотеками - они пересобирались всё время после добавления ключа /MP. С С++ библиотеками такого не было.
Впрочем, сишные либы и так сильно быстрей собираются, чем С++.
Интересно, а как ведет себя компилятор во время этого самого сбоя? Видно ли, что компиляция прошла успешно или нет? Просто не хотелось бы, чтобы сбой остался незамечанным и я поставил клиенту глючную программу из за одного только ключа.
2C++ Developer:
Интересно, а как ведет себя компилятор во время этого самого сбоя? Видно ли, что компиляция прошла успешно или нет? Просто не хотелось бы, чтобы сбой остался незамечанным и я поставил клиенту глючную программу из за одного только ключа.
Не знаю как ведет... Если есть такие сомнения, то лучше финальную сборку проводить без этого ключа. Поставить его только в дебаге, например.
Отправить комментарий