Здравствуйте, imh0, Вы писали:
I>Больше ядер — AMD. I>Если софт не умеет в много поточность, а VS именно такое — Intel
По-моему похрен по большому счету, современные процессоры и тех и других компилируют (и многое другое делают) плюс/минус одинаково быстро. Но если так сильно важно, то надо смотреть тесты конкретных версий VS под конкретные процессоры.
Здравствуйте, LuciferSaratov, Вы писали:
LS>Что сейчас лучше купить для С++? LS>Мне надо, чтобы в Visual Studio код быстро компилировался.
Бери процессор с большим количеством каналов памяти.
Компиляция упирается не в вычислительные возможности, а в пропускную способность памяти.
Здравствуйте, LuciferSaratov, Вы писали:
LS>надо, чтобы в Visual Studio код быстро компилировался.
Тогда выбирайте процессор по наибольшей линейной производительности на ядро, затем — по количеству ядер.
Но код с большим количеством сложных и вложенных шаблонов требует приличного дискового обмена, так что недостаточно быстрый диск может испортить картину.
Здравствуйте, imh0, Вы писали:
I>Если софт не умеет в много поточность, а VS именно такое
Компилятор VC++ умеет в многопоточность уже очень давно. VS позволяет это указать, если не ошибаюсь, с версии 2010, а до того достаточно добавить /MP в командную строку.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, kov_serg, Вы писали:
_>>Компиляция упирается не в вычислительные возможности, а в пропускную способность памяти.
ЕМ>Далеко не вся, а лишь та, где активно используется множество крупных шаблонов, не влезающих в кэш процессора — это достаточно редкое явление.
Оно почти не когда в кэш и не влазит. А если учесть что ему еще и линковать надо и всё это вертится 96 ядрах, то упираемся в память.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Компилятор VC++ умеет в многопоточность уже очень давно. VS позволяет это указать, если не ошибаюсь, с версии 2010, а до того достаточно добавить /MP в командную строку.
Здравствуйте, kov_serg, Вы писали:
_>Оно почти не когда в кэш и не влазит.
Чтоб "почти никогда", исходники должны быть построены так, чтоб бОльшая часть конструкций, которая чаще всего инлайнится, непрерывно протаскивалась через 16-Мб кэш. То есть — ужасающе.
_>ему еще и линковать надо
Опять же, при грамотной структуре затраты на линковку ничтожны по сравнению с затратами на компиляцию.
_>и всё это вертится 96 ядрах
Какой смысл распараллеливать компиляцию одного файла? Чтоб делать проекты из двадцати файлов по десять мегабайт каждый?
Здравствуйте, imh0, Вы писали:
ЕМ>>что еще в процессе сборки требует сравнимых ресурсов?
I>Что еще требуется чтобы собрать приложение? I>Ты же эксперт в винде помоему, а мы про винду.
Ну так в винде, чтобы собрать приложение C++, нужно скомпилировать файлы на C++, скомпилировать ресурсы, и слинковать все это вместе. Практически все потребные ресурсы уходят на компиляцию C++, остальное — жалкое подобие.
По количеству ядер выбирают — https://habr.com/ru/news/503658/
Правда на сегодня это был бы уже threadripper pro 5995wx, а не старичок 3970X. По карману такая игрушка сильно ударит...
Здравствуйте, LuciferSaratov, Вы писали:
LS>Приветствую всех присутствующих.
LS>Что сейчас лучше купить для С++? LS>Мне надо, чтобы в Visual Studio код быстро компилировался.
Любой сойдет. Компилять нужно 1% времени от всего времени разработки. Всегда забавляли программистеры, которые тянутся за производительным железом, типо он профи, ему надо.
PS и никакой вижуанал студии. Это гавно на любом железе будет тормозить адски
Здравствуйте, smeeld, Вы писали:
S>Любой сойдет. Компилять нужно 1% времени от всего времени разработки.
Будет печаль, если придется собирать чет типа boost. По старым воспоминаниям там аж на часы!!! И проц там был загружен на 100%. Было бы забавно сравнить на теперешнем железе чет настолько тяжелое. Если кто-то сбацает такой тест — в VS такой то открытый и максимально тяжелый проект собрать, спецом запущу на домашнем (пылящимся сейчас) сервачке с 2 x 2699v4, зарешают ли потоки в количестве 88шт...?
Здравствуйте, smeeld, Вы писали:
S>Компилять нужно 1% времени от всего времени разработки.
С одной стороны, да. С другой стороны, регулярно возникают ситуации, в которых время, потребное на поиск ошибки логическим анализом текста, будет больше, чем уйдет на одну-две-несколько пробных правок с пересборкой.
S>PS и никакой вижуанал студии. Это гавно на любом железе будет тормозить адски
Студии последних лет тормозят главным образом при работе с текстом. Для сборки они тупо запускают внешние компиляторы, на скорость их работы студия никакого влияния не оказывает.
Здравствуйте, Евгений Музыченко, Вы писали:
> Чтоб "почти никогда", исходники должны быть построены так, чтоб бОльшая часть конструкций, которая чаще всего инлайнится, непрерывно протаскивалась через 16-Мб кэш. То есть — ужасающе.
boost и другие чудо либы, не?
_>>и всё это вертится 96 ядрах ЕМ>Какой смысл распараллеливать компиляцию одного файла? Чтоб делать проекты из двадцати файлов по десять мегабайт каждый?
o_O
обычно выглидит так make -j 96
Здравствуйте, _ilya_, Вы писали:
__>Здравствуйте, smeeld, Вы писали:
S>>Любой сойдет. Компилять нужно 1% времени от всего времени разработки.
__>Будет печаль, если придется собирать чет типа boost. По старым воспоминаниям там аж на часы!!!
Последний раз boost компилял где-то в 2014-ом, просто потехи ради. Ноутовый тогдашний i3 c 4GB RAM справился минут за 10. Больше boost не компиляю, просто юзаю из стандартных реп линуксов.
