Здравствуйте, 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 не компиляю, просто юзаю из стандартных реп линуксов.
Здравствуйте, kov_serg, Вы писали:
_>boost и другие чудо либы, не?
И что, при их использовании компилятор непрерывно инлайнит предкомпилированный код с максимальной скоростью доступа к кэшу/памяти, не отвлекаясь ни на что другое?
Хорошо, давайте представим, что так оно и есть. Пропускная способность DDR4 оценивается в среднем в 20 Гб/с. Пусть реально будет хотя бы четверть — 5 Гб/с. Если компиляция файла занимает хотя бы минуту, какого примерно объема должен получиться бинарник?
_>обычно выглидит так make -j 96
ЕМ>Хорошо, давайте представим, что так оно и есть. Пропускная способность DDR4 оценивается в среднем в 20 Гб/с. Пусть реально будет хотя бы четверть — 5 Гб/с. Если компиляция файла занимает хотя бы минуту, какого примерно объема должен получиться бинарник?
DDR4 — на 3200 должна давать ~ 50Гб/с. Дело не в бинарнике, а в том что компилятор выполняет кучу ненужной работы, которая связана с перемещением данных туда, сюда (особенно C++).
Если вам интересно, включите одноканальный режим, а потом двух канальный и потом на 12 канальном попробуйте. Или на крайняк на M1 попробуйте с HBM паматью.
ЕМ>Чего именно там 96?
Параллельных процессов сборки пускается столько сколько укажите. Обычно оно совпадает с числом ядер процессора для ускорения процесса. Если 8 ядер -j 8 если 24 с гипертриденгом то -j 12, если 4х процессорная система то можно указать и 192ядра
тебе — возможно, мне нет.
S>Компилять нужно 1% времени от всего времени разработки.
смотря что за задачи.
у меня, например, бывают и такие, когда компиляция занимает до половины времени.
если это время удастся сократить, то я с такими задачами буду справляться лучше.
S>Всегда забавляли программистеры, которые тянутся за производительным железом, типо он профи, ему надо.
не у всех программистов работа похожа на твою.
S>PS и никакой вижуанал студии. Это гавно на любом железе будет тормозить адски
Здравствуйте, smeeld, Вы писали:
S>PS и никакой вижуанал студии. Это гавно на любом железе будет тормозить адски
У меня не тормозила и на i5-2500, шо я делаю не так?
Здравствуйте, kov_serg, Вы писали:
_>компилятор выполняет кучу ненужной работы, которая связана с перемещением данных туда, сюда (особенно C++).
Чтобы регулярно упираться в производительность памяти, он должен очень часто перемещать достаточно большие (сотни килобайт — мегабайты) объемы данных предельно тупо (прямым копированием). Где и зачем такое требуется при компиляции C++? Когда инлайнятся шаблоны/функции, они проходят достаточно нетривиальную (с точки зрения процессорных операций) обработку.
_>включите одноканальный режим, а потом двух канальный и потом на 12 канальном попробуйте.
У меня в ноутбуке оно не управляется. Однако ж, любое изменение производительности памяти так или иначе скажется практически на всех (кроме "активно-вычислительных") процессах. Каким образом из этого изменения вывести, что является самым узким местом?
_>Параллельных процессов сборки пускается столько сколько укажите.
Если Вы имеете в виду, что производительности памяти не хватает для одновременного обслуживания большого количества ядер, чем компиляция в этом плане отличается от любой другой параллельной обработки?
Здравствуйте, LuciferSaratov, Вы писали:
LS>Приветствую всех присутствующих.
LS>Что сейчас лучше купить для С++? LS>Мне надо, чтобы в Visual Studio код быстро компилировался.
13900k, 7950x. Они будут плюс минус на равных. Быстрее — не бывает.
Верней, можно найти какой нибудь много-много ядерный HEDT, и очень, очень хорошо раскладывающийся на потоки при компиляции проект.
Но при работе в редакторе этот HEDT будет медленней чем 13900k/7950x, Т.к. однопоток у него слабей.
Здравствуйте, CreatorCray, Вы писали:
CC>У меня не тормозила и на i5-2500, шо я делаю не так?
ты использовал старые версии студии, без разного рода аддонов.
Ну и может проект маленький был.
На последних студиях, с разного рода Intellicodами и всяким таким прочим, на солюшене с > 50 проектами — оно довольно часто подтормаживает на 13900к. Подсказки с задержками появляются, и всякое такое прочее.
Здравствуйте, rm2, Вы писали:
rm2>ты использовал старые версии студии, без разного рода аддонов.
Из аддонов пользуюсь только VAX и ICC integration, больше ничего не нужно.
rm2>Ну и может проект маленький был.
Ну, когда то проектом было ядро VMware ESXi, который ну нихрена не маленький.
И тогда был проц вообще какой то мобильный в лапотопе.
Компилял через rsync + ssh на билдсервере, результат грузился по сети на сервак под столом.
rm2>На последних студиях, с разного рода Intellicodами и всяким таким прочим, на солюшене с > 50 проектами — оно довольно часто подтормаживает на 13900к. Подсказки с задержками появляются, и всякое такое прочее.
Чот мне кажется что просто эти интелликоды написаны на чём то изрядно тормозном.
Ну и сама студия тоже становилась всё хуже и хуже. Я с 2008й собственно потому и не стал слезать что следующие студии оказались совершенно неюзабельны на тех же самых проектах.
Однако ж, любое изменение производительности памяти так или иначе скажется практически на всех (кроме "активно-вычислительных") процессах. Каким образом из этого изменения вывести, что является самым узким местом?
