Сообщение Re[3]: Посоветуйте конфигурацию от 25.01.2026 20:04
Изменено 25.01.2026 22:32 SkyDance
Re[3]: Посоветуйте конфигурацию
M>Windows, но имхо, на SSD это мало роялит, разбор плюсиков — это основная нагрузка
Я же не просто так упомянул "и какой компилятор". ICC, MSVC и clang уж шибко по-разному себя ведут.
Чтобы на Windows добиться близкой к linux/MacOS скорости сборки, нужно правильно настроить кучу разных мест. Например, выключить Defender (эта скотина порой вдвое увеличивает время сборки), Bitlocker (потому что оно до сих пор на CPU все шифрует, причем без использования аппаратного ускорения — то есть медленно), установить "Maximum Performance" режим в Power Options, и сделать еще кучу приседаний. И даже после всего этого macos/linux собирают быстрее. В конечном итоге, я на домашнем десктопе если что-то разрабатываю, то обычно в виртуалке, где крутится Linux. И это все работает быстрее, чем на хосте.
Понимаю, что верится с трудом, — поэтому предлагаю просто попробовать.
M>Тысяч двести могу потратить, в баксах это тыщи три по текущему курсу, но я хз, как рублёвые цены в наших магазинах соответствуют долларовым
А, ну это бытовой компьютер, ни о каких threadripper и речи идти не может. Предполагаю, что монитор/клавиатура/мышь и прочая периферия есть, так что бюджет чисто на системный блок.
Если затачивать именно под С++ сборку, то нужно больше ядер, причем желательно однородных, дабы планировщику не плохело в попытках догадаться "а куда что забросить". Поскольку бюджет невелик, я бы брал AMD 9950X, хотя бы 32 Гб памяти, приличную материнку (чтобы ее питание не ограничивало процессор), кулер по вкусу (многие рекомендуют водянку, но я лично не люблю это усложнение). Разумеется, NVMe SSD, причем можно PCIe4 (гнаться за свежими PCIe5 пока смысла нет).
Если очень хочется именно Intel, и брать нужно прямо сейчас, то 285K или 14900K будут примерно одинаковы в плане производительности, но первый будет заметно горячее и сложнее охладить.
M>Это понятно, но хочется локально, есть идея потом в конторе попробовать внедрить, а там сорцы на сторону нельзя отдавать
Скажу честно, это не вариант. Лучше сразу смотреть в сторону Amazon Bedrock и аналогов. Проекты на С++ не то что LLM, а даже человекам-то сложно понять. Локально запустить LLM на устройстве с мозгом от таракана, скажем так, мало что даст.
M>Да, вот в соседней теме почитал твои вроде рекомендации про этот кеш, почитал обзоры, но в них тесты компиляции нигде не делали, этот момент интересует. А почему доп кеш не ускоряет компиляцию? Мне казалось, что должно бы
Кэш очень заметно ускоряет (как правило однопоточные) расчеты игрового цикла. Подавляющее большинство игр — несмотря на весь прогресс в этой области — чудовищно однопоточные. Есть много причин, почему распараллелить основной игровой цикл не получается. Загрузить другие ядра (всякой фигней вроде более частого pathfinding'а для NPC) можно, но это делается в основном для того, чтобы успокоить глупых юзеров. Мол, наша игра хорошая, она все ядра использует.
Так вот, этот самый основной поток игрового цикла почти всегда требует доступа ко всей модели "мира" (игрового уровня, как logical, так и render tree). А это много данных — причем требуется не последовательный, а random'ный доступ. Увеличение кэша играет заметную роль.
А вот для компиляции С++ ничего подобного не требуется, там все помещается и в собственный кэш процессора. Конечно, выигрыш от наличия большого L3 все равно есть. Но он нивелируется необходимостью снижать частоты, ибо сам кэш не бесплатный. Кроме того, — и это даже более важное отличие — на данный момент в официальной продаже нет 16-ядерных процессоров, у которых в каждой "плитке" есть 3D Cache. То есть, если ты возмешь AMD 9950X3d, то у восьми ядер этот кэш будет (это одна плитка), а у других восьми не будет (вторая плитка без кэша). Так что опять планировщику нужно гадать, что куда направлять, и в случае с компиляцией — хрен угадаешь.
Ожидается, что AMD выпустить что-то вроде 9950X3D2, так чтобы в каждой плитке был кэш. Но неизвестно, когда именно это произойдет. И ценник у этого процессора явно будет "премиальным". А выигрыш на компиляции, думаю, уложится в 5-10%.
Я же не просто так упомянул "и какой компилятор". ICC, MSVC и clang уж шибко по-разному себя ведут.
Чтобы на Windows добиться близкой к linux/MacOS скорости сборки, нужно правильно настроить кучу разных мест. Например, выключить Defender (эта скотина порой вдвое увеличивает время сборки), Bitlocker (потому что оно до сих пор на CPU все шифрует, причем без использования аппаратного ускорения — то есть медленно), установить "Maximum Performance" режим в Power Options, и сделать еще кучу приседаний. И даже после всего этого macos/linux собирают быстрее. В конечном итоге, я на домашнем десктопе если что-то разрабатываю, то обычно в виртуалке, где крутится Linux. И это все работает быстрее, чем на хосте.
Понимаю, что верится с трудом, — поэтому предлагаю просто попробовать.
M>Тысяч двести могу потратить, в баксах это тыщи три по текущему курсу, но я хз, как рублёвые цены в наших магазинах соответствуют долларовым
А, ну это бытовой компьютер, ни о каких threadripper и речи идти не может. Предполагаю, что монитор/клавиатура/мышь и прочая периферия есть, так что бюджет чисто на системный блок.
Если затачивать именно под С++ сборку, то нужно больше ядер, причем желательно однородных, дабы планировщику не плохело в попытках догадаться "а куда что забросить". Поскольку бюджет невелик, я бы брал AMD 9950X, хотя бы 32 Гб памяти, приличную материнку (чтобы ее питание не ограничивало процессор), кулер по вкусу (многие рекомендуют водянку, но я лично не люблю это усложнение). Разумеется, NVMe SSD, причем можно PCIe4 (гнаться за свежими PCIe5 пока смысла нет).
Если очень хочется именно Intel, и брать нужно прямо сейчас, то 285K или 14900K будут примерно одинаковы в плане производительности, но первый будет заметно горячее и сложнее охладить.
M>Это понятно, но хочется локально, есть идея потом в конторе попробовать внедрить, а там сорцы на сторону нельзя отдавать
Скажу честно, это не вариант. Лучше сразу смотреть в сторону Amazon Bedrock и аналогов. Проекты на С++ не то что LLM, а даже человекам-то сложно понять. Локально запустить LLM на устройстве с мозгом от таракана, скажем так, мало что даст.
M>Да, вот в соседней теме почитал твои вроде рекомендации про этот кеш, почитал обзоры, но в них тесты компиляции нигде не делали, этот момент интересует. А почему доп кеш не ускоряет компиляцию? Мне казалось, что должно бы
Кэш очень заметно ускоряет (как правило однопоточные) расчеты игрового цикла. Подавляющее большинство игр — несмотря на весь прогресс в этой области — чудовищно однопоточные. Есть много причин, почему распараллелить основной игровой цикл не получается. Загрузить другие ядра (всякой фигней вроде более частого pathfinding'а для NPC) можно, но это делается в основном для того, чтобы успокоить глупых юзеров. Мол, наша игра хорошая, она все ядра использует.
Так вот, этот самый основной поток игрового цикла почти всегда требует доступа ко всей модели "мира" (игрового уровня, как logical, так и render tree). А это много данных — причем требуется не последовательный, а random'ный доступ. Увеличение кэша играет заметную роль.
А вот для компиляции С++ ничего подобного не требуется, там все помещается и в собственный кэш процессора. Конечно, выигрыш от наличия большого L3 все равно есть. Но он нивелируется необходимостью снижать частоты, ибо сам кэш не бесплатный. Кроме того, — и это даже более важное отличие — на данный момент в официальной продаже нет 16-ядерных процессоров, у которых в каждой "плитке" есть 3D Cache. То есть, если ты возмешь AMD 9950X3d, то у восьми ядер этот кэш будет (это одна плитка), а у других восьми не будет (вторая плитка без кэша). Так что опять планировщику нужно гадать, что куда направлять, и в случае с компиляцией — хрен угадаешь.
Ожидается, что AMD выпустить что-то вроде 9950X3D2, так чтобы в каждой плитке был кэш. Но неизвестно, когда именно это произойдет. И ценник у этого процессора явно будет "премиальным". А выигрыш на компиляции, думаю, уложится в 5-10%.
Re[3]: Посоветуйте конфигурацию
M>Windows, но имхо, на SSD это мало роялит, разбор плюсиков — это основная нагрузка
Я же не просто так упомянул "и какой компилятор". ICC, MSVC и clang уж шибко по-разному себя ведут.
Чтобы на Windows добиться близкой к linux/MacOS скорости сборки, нужно правильно настроить кучу разных мест. Например, выключить Defender (эта скотина порой вдвое увеличивает время сборки), Bitlocker (потому что оно до сих пор на CPU все шифрует, причем без использования аппаратного ускорения — то есть медленно), установить "Maximum Performance" режим в Power Options, и сделать еще кучу приседаний. И даже после всего этого macos/linux собирают быстрее. В конечном итоге, я на домашнем десктопе если что-то разрабатываю, то обычно в виртуалке, где крутится Linux. И это все работает быстрее, чем на хосте.
Понимаю, что верится с трудом, — поэтому предлагаю просто попробовать.
M>Тысяч двести могу потратить, в баксах это тыщи три по текущему курсу, но я хз, как рублёвые цены в наших магазинах соответствуют долларовым
А, ну это бытовой компьютер, ни о каких threadripper и речи идти не может. Предполагаю, что монитор/клавиатура/мышь и прочая периферия есть, так что бюджет чисто на системный блок.
Если затачивать именно под С++ сборку, то нужно больше ядер, причем желательно однородных, дабы планировщику не плохело в попытках догадаться "а куда что забросить". Поскольку бюджет невелик, я бы брал AMD 9950X, хотя бы 32 Гб памяти, приличную материнку (чтобы ее питание не ограничивало процессор), кулер по вкусу (многие рекомендуют водянку, но я лично не люблю это усложнение). Разумеется, NVMe SSD, причем можно PCIe4 (гнаться за свежими PCIe5 пока смысла нет).
Если очень хочется именно Intel, и брать нужно прямо сейчас, то 285K или 14900K будут примерно одинаковы в плане производительности, но последний будет заметно горячее и сложнее охладить.
M>Это понятно, но хочется локально, есть идея потом в конторе попробовать внедрить, а там сорцы на сторону нельзя отдавать
Скажу честно, это не вариант. Лучше сразу смотреть в сторону Amazon Bedrock и аналогов. Проекты на С++ не то что LLM, а даже человекам-то сложно понять. Локально запустить LLM на устройстве с мозгом от таракана, скажем так, мало что даст.
M>Да, вот в соседней теме почитал твои вроде рекомендации про этот кеш, почитал обзоры, но в них тесты компиляции нигде не делали, этот момент интересует. А почему доп кеш не ускоряет компиляцию? Мне казалось, что должно бы
Кэш очень заметно ускоряет (как правило однопоточные) расчеты игрового цикла. Подавляющее большинство игр — несмотря на весь прогресс в этой области — чудовищно однопоточные. Есть много причин, почему распараллелить основной игровой цикл не получается. Загрузить другие ядра (всякой фигней вроде более частого pathfinding'а для NPC) можно, но это делается в основном для того, чтобы успокоить глупых юзеров. Мол, наша игра хорошая, она все ядра использует.
Так вот, этот самый основной поток игрового цикла почти всегда требует доступа ко всей модели "мира" (игрового уровня, как logical, так и render tree). А это много данных — причем требуется не последовательный, а random'ный доступ. Увеличение кэша играет заметную роль.
А вот для компиляции С++ ничего подобного не требуется, там все помещается и в собственный кэш процессора. Конечно, выигрыш от наличия большого L3 все равно есть. Но он нивелируется необходимостью снижать частоты, ибо сам кэш не бесплатный. Кроме того, — и это даже более важное отличие — на данный момент в официальной продаже нет 16-ядерных процессоров, у которых в каждой "плитке" есть 3D Cache. То есть, если ты возмешь AMD 9950X3d, то у восьми ядер этот кэш будет (это одна плитка), а у других восьми не будет (вторая плитка без кэша). Так что опять планировщику нужно гадать, что куда направлять, и в случае с компиляцией — хрен угадаешь.
Ожидается, что AMD выпустить что-то вроде 9950X3D2, так чтобы в каждой плитке был кэш. Но неизвестно, когда именно это произойдет. И ценник у этого процессора явно будет "премиальным". А выигрыш на компиляции, думаю, уложится в 5-10%.
Я же не просто так упомянул "и какой компилятор". ICC, MSVC и clang уж шибко по-разному себя ведут.
Чтобы на Windows добиться близкой к linux/MacOS скорости сборки, нужно правильно настроить кучу разных мест. Например, выключить Defender (эта скотина порой вдвое увеличивает время сборки), Bitlocker (потому что оно до сих пор на CPU все шифрует, причем без использования аппаратного ускорения — то есть медленно), установить "Maximum Performance" режим в Power Options, и сделать еще кучу приседаний. И даже после всего этого macos/linux собирают быстрее. В конечном итоге, я на домашнем десктопе если что-то разрабатываю, то обычно в виртуалке, где крутится Linux. И это все работает быстрее, чем на хосте.
Понимаю, что верится с трудом, — поэтому предлагаю просто попробовать.
M>Тысяч двести могу потратить, в баксах это тыщи три по текущему курсу, но я хз, как рублёвые цены в наших магазинах соответствуют долларовым
А, ну это бытовой компьютер, ни о каких threadripper и речи идти не может. Предполагаю, что монитор/клавиатура/мышь и прочая периферия есть, так что бюджет чисто на системный блок.
Если затачивать именно под С++ сборку, то нужно больше ядер, причем желательно однородных, дабы планировщику не плохело в попытках догадаться "а куда что забросить". Поскольку бюджет невелик, я бы брал AMD 9950X, хотя бы 32 Гб памяти, приличную материнку (чтобы ее питание не ограничивало процессор), кулер по вкусу (многие рекомендуют водянку, но я лично не люблю это усложнение). Разумеется, NVMe SSD, причем можно PCIe4 (гнаться за свежими PCIe5 пока смысла нет).
Если очень хочется именно Intel, и брать нужно прямо сейчас, то 285K или 14900K будут примерно одинаковы в плане производительности, но последний будет заметно горячее и сложнее охладить.
M>Это понятно, но хочется локально, есть идея потом в конторе попробовать внедрить, а там сорцы на сторону нельзя отдавать
Скажу честно, это не вариант. Лучше сразу смотреть в сторону Amazon Bedrock и аналогов. Проекты на С++ не то что LLM, а даже человекам-то сложно понять. Локально запустить LLM на устройстве с мозгом от таракана, скажем так, мало что даст.
M>Да, вот в соседней теме почитал твои вроде рекомендации про этот кеш, почитал обзоры, но в них тесты компиляции нигде не делали, этот момент интересует. А почему доп кеш не ускоряет компиляцию? Мне казалось, что должно бы
Кэш очень заметно ускоряет (как правило однопоточные) расчеты игрового цикла. Подавляющее большинство игр — несмотря на весь прогресс в этой области — чудовищно однопоточные. Есть много причин, почему распараллелить основной игровой цикл не получается. Загрузить другие ядра (всякой фигней вроде более частого pathfinding'а для NPC) можно, но это делается в основном для того, чтобы успокоить глупых юзеров. Мол, наша игра хорошая, она все ядра использует.
Так вот, этот самый основной поток игрового цикла почти всегда требует доступа ко всей модели "мира" (игрового уровня, как logical, так и render tree). А это много данных — причем требуется не последовательный, а random'ный доступ. Увеличение кэша играет заметную роль.
А вот для компиляции С++ ничего подобного не требуется, там все помещается и в собственный кэш процессора. Конечно, выигрыш от наличия большого L3 все равно есть. Но он нивелируется необходимостью снижать частоты, ибо сам кэш не бесплатный. Кроме того, — и это даже более важное отличие — на данный момент в официальной продаже нет 16-ядерных процессоров, у которых в каждой "плитке" есть 3D Cache. То есть, если ты возмешь AMD 9950X3d, то у восьми ядер этот кэш будет (это одна плитка), а у других восьми не будет (вторая плитка без кэша). Так что опять планировщику нужно гадать, что куда направлять, и в случае с компиляцией — хрен угадаешь.
Ожидается, что AMD выпустить что-то вроде 9950X3D2, так чтобы в каждой плитке был кэш. Но неизвестно, когда именно это произойдет. И ценник у этого процессора явно будет "премиальным". А выигрыш на компиляции, думаю, уложится в 5-10%.