пятница, апреля 25, 2008

Ключ /MP в Visual Studio

Ключ /MP в Visual Studio 2008 говорит компилятору запускать несколько процессов на компиляцию. Что полезно, если у вас многоядерный процессор.

Но 2008-й студией мало кто пользуется. Вот 2005-я втречается чаще. И там тоже эта возможность есть, только она не задокументирована. Герб Саттер об этом написал в своем блоге. Дело в том, что они не успели как следует закончить ее и 2005-я студия вышла без этого волшебного ключика в документации. Но он там вполне себе работает. Может сглючить, конечно, но максимум чем вам это грозит - полным rebuild'ом проекта.

Я попробовала /MP на одном небольшом проекте и rebuild у меня уменьшился с 41 секунды до 27.

18 комментариев:

  1. Компиляцию ускоряет действительно.
    Я вот тут для Qt шников отписал, как только Suttter признался.
    http://wiki.qtcentre.org/index.php?title=Qt4_with_Visual_Studio#Multicore_processors

    А то я всё переживал как же так в Linux make -j [processMax] есть
    а в VS не было ничего, для распараллеливания компиляции.

    Только странно, что он об этом сейчас сообщил, мог бы и раньше на годик два...

    ОтветитьУдалить
  2. Всем срочно спать :)

    ОтветитьУдалить
  3. 2Borisov Sergey:
    Только странно, что он об этом сейчас сообщил, мог бы и раньше на годик два...

    Они и раньше об этом писал, я не обратила внимания просто.

    ОтветитьУдалить
  4. Спасибо!
    Попробовал - время компиляции одного проекта сократилось с 3m15s до 2m10s. Надо на полном продукте попробовать - сейчас он больше получаса собирается.

    Теперь начал тоже хотеть 4х-ядерный процессор.

    ОтветитьУдалить
  5. не уверен что на маленьких проектах компилирующихся меньше 5 минут корректно сравнивать время компиляции с этим ключом и без него :)

    а вообще хочу добавить о системах распараллеливания компиляции по сети - когда другие компьютеры в сети участвуют в сборке твоего проекты - мы для этого под windows используем IncrediBuild а под линуксом - TeamBuilder
    чего и вам советую :) время сборки одного прошлого проекта уменьшилось с 40 минут до 10-15. Текущий проект теперь под линуксом собирается 15-20 минут вместо нескольких часов.

    ОтветитьУдалить
  6. Анонимный25/4/08 14:39

    А вот для C# я ничего такого не нашел... Обидно.

    ОтветитьУдалить
  7. Анонимный25/4/08 16:43

    Для одного ядра тоже должен повышать скорость, по крайней мере в GNU make утилизация процессора больше становится

    ОтветитьУдалить
  8. Анонимный25/4/08 18:08

    [b]2 rocker[/b]
    Скорость компиляции C# проектов и так во много раз выше чем С++

    ОтветитьУдалить
  9. Анонимный26/4/08 13:08

    Гм, это прикол такой ? Оно и так по умолчанию включено в среде, если система мультипроцессорная. Надо же, больше года пользуюсь, как на VS2005 перешёл, а оказывается это тайна :-D

    См. Tools\Options\Projects and Solutions\Build and Run\maximum number of parallel project builds

    ОтветитьУдалить
  10. 2Анонимный

    Гм, это прикол такой ? Оно и так по умолчанию включено в среде, если система мультипроцессорная. Надо же, больше года пользуюсь, как на VS2005 перешёл, а оказывается это тайна :-D

    См. Tools\Options\Projects and Solutions\Build and Run\maximum number of parallel project builds


    Нет, это другая параллельность. Это возможность параллельно собирать несколько проектов. /MP распараллеливает компиляцию одного проекта.
    Почитай у Саттера, он подробнее об этом пишет.

    ОтветитьУдалить
  11. Анонимный26/4/08 14:07

    Ок, не обратил внимания, согласен :)

    ОтветитьУдалить
  12. а мы в 2005-й студии наткнулись на баг (уже отрепорченный), когда происходила неправильная инстанциация статических объектов при использовании boost.spirit из boost 1.35

    ОтветитьУдалить
  13. Анонимный27/4/08 12:49

    для MSVS2005 есть адд-ин, который разблочивает эту функцию.

    вот он: http://www.todobits.es/mpcl.html

    ОтветитьУдалить
  14. 2Анонимный:
    для MSVS2005 есть адд-ин, который разблочивает эту функцию.

    вот он: http://www.todobits.es/mpcl.html


    Добавляет к ней интерфейс, скорее. А так она не заблокировна - бери и пользуйся. Но не документирована и интерфейса к ней нет.

    ОтветитьУдалить
  15. К сожелению
    "Command line warning D9030 : '/Gm' is incompatible with multiprocessing; ignoring /MP switch"

    Тоесть польза только при полном ребилде. А его кстати было бы хорошо делать чем-то вроде CruiseControl.

    ОтветитьУдалить
  16. Почему-то глючило с сишными библиотеками - они пересобирались всё время после добавления ключа /MP. С С++ библиотеками такого не было.

    Впрочем, сишные либы и так сильно быстрей собираются, чем С++.

    ОтветитьУдалить
  17. Анонимный16/3/09 10:37

    Интересно, а как ведет себя компилятор во время этого самого сбоя? Видно ли, что компиляция прошла успешно или нет? Просто не хотелось бы, чтобы сбой остался незамечанным и я поставил клиенту глючную программу из за одного только ключа.

    ОтветитьУдалить
  18. 2C++ Developer:
    Интересно, а как ведет себя компилятор во время этого самого сбоя? Видно ли, что компиляция прошла успешно или нет? Просто не хотелось бы, чтобы сбой остался незамечанным и я поставил клиенту глючную программу из за одного только ключа.

    Не знаю как ведет... Если есть такие сомнения, то лучше финальную сборку проводить без этого ключа. Поставить его только в дебаге, например.

    ОтветитьУдалить