Почему WD Velociraptor не ускоряет мою компиляцию VC ++?

Question

Несколько человек здесь рекомендовали перейти на новый жесткий диск WD Velociraptor 10000rpm . Также журнальные статьи высоко оценивают представление. Я купил один и отразил на нем мою старую систему. Результирующее увеличение скорости компиляции несколько разочаровывает:

• На моем старом диске Samsung (SATA, 7200) время компиляции было 16: 02 .
• На Velociraptor сборка занимает 15: 23 .

У меня есть E6600 с оперативной памятью 1,5G. Это C ++ - проект с 1200 файлами. Сборка выполняется в Visual Studio 2005. Управление акустикой отключено (в любом случае, большой разницы).

Что-то пошло не так или это скромное ускорение действительно все, я могу ожидать?

Edit: Некоторые рекомендовали увеличить оперативную память. Я сделал это сейчас и получил минимальный прирост (3-5%), удвоив объем ОЗУ до 3 ГБ.

Answer 1

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

Answer 2

Visual Studio 2005 может создавать несколько проектов параллельно и будет делать это по умолчанию на многоядерном компьютере, но в зависимости от того, как ваши проекты зависят друг от друга, может быть невозможно параллельное их построение.

Если ваши файлы 1200 cpp находятся в одном проекте, вы, вероятно, используете не весь свой процессор. Если я не ошибаюсь, C6600 - это четырехъядерный процессор.

Dave

Answer 3

Это на самом деле довольно большой скачок в скорости просто для замены жесткого диска. Вы, вероятно, на данный момент связаны с памятью или процессором. В наши дни 1,5 ГБ - это мало, а ОЗУ очень дешево. Вы можете увидеть некоторые довольно большие улучшения с большим объемом памяти.

В качестве рекомендации, если у вас установлено более одного диска, вы можете попробовать установить каталог сборки где-то на диске, отличном от ваших исходных файлов.

Что касается этого комментария:

Если ваши файлы 1200 cpp находятся в одном проекте, вы, вероятно, используете не весь свой процессор. Если я не ошибаюсь, C6600 - это четырехъядерный процессор.

На самом деле, C6600 - это не что-нибудь. Есть E6600 и Q6600. E6600 - двухъядерный, а Q6600 - четырехъядерный. На моем компьютере разработчика я использую четырехъядерный процессор, и, хотя в нашем проекте более 1200 файлов, он все еще ограничен ЛЕГКИМ процессором во время компиляции (хотя более быстрый жесткий диск все равно поможет ускорить процесс!)

Answer 4

Как уже отмечали многие, вы, вероятно, не атаковали настоящее узкое место. Случайно меняющиеся части (или код в этом отношении) - это, как можно сказать, «басовые звуки». Сначала вы определяете узкое место в производительности, а затем что-то меняете.

Perfmon может помочь вам получить хороший обзор, если вы связаны с процессором или вводом-выводом, вы хотите посмотреть на загрузку процессора, длину очереди диска и байты ввода-вывода, чтобы получить первый взгляд на происходящее.

Answer 5

~ 6% увеличение скорости всего от улучшения вашего жесткого диска. Как сказал Хоулер. Возьмите быстрее оперативной памяти и PCU.

Answer 6

По результатам я бы предположил, что либо ваша задержка hdd не была узким местом, которое вы искали, либо ваш проект уже близок к максимально быстрому созданию. Другие пункты для рассмотрения будут:

1. время доступа к жесткому диску (хотя вы, возможно, не сможете сделать это из-за ограничений скорости шины)
2. скорость доступа к памяти и размер
3. Скорость процессора
4. Сокращение фоновых процессов

Answer 7

Я полагаю, что чтение с жесткого диска не было вашим узким местом при компиляции. Реально, некоторые вещи должны быть прочитаны / записаны с / на жесткий диск. Скорее всего, вы увидите увеличение производительности от увеличения оперативной памяти или более быстрого процессора.

Answer 8

Я сократил время компиляции вдвое, поместив весь свой источник в оперативную память.

Я попробовал этих парней http://www.superspeed.com/desktop/ramdisk.php, установил 1 Гб оперативной памяти, затем скопировал на него весь мой источник. Если вы строите напрямую из ОЗУ, накладные расходы ввода-вывода значительно уменьшаются.

Чтобы дать вам представление о том, что я собираю, и о чем;

• WinXP 64-bit
• 4 ГБ оперативной памяти
• 2.? ГГц двухъядерные процессоры
• 62 C # проектов
• около 250клоц.

Моя сборка увеличилась с 135 до 65 лет.

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

Кроме того, вы должны заплатить за программное обеспечение. Но так как вы хотите использовать жесткие диски, возможно, это не так уж важно.

Недостатками являются увеличенное время компиляции и тот факт, что исполняемые файлы уже находятся в памяти, поэтому время запуска и время отладки немного лучше. Однако реальная выгода - это время компиляции.

Answer 9

VC 2005 не компилирует более одного файла за раз для каждого проекта, поэтому либо перейдите на VC 2008, чтобы использовать оба ядра вашего процессора, либо разбейте свое решение на несколько подпроектов библиотек, чтобы запустить несколько компиляций.

Answer 10

1200 Исходных файлов много, но ни один из них, вероятно, не превышает пары сотен К, поэтому, хотя все они должны быть прочитаны в память, это не займет много времени.

Увеличение системной памяти до 4G (да, да, я знаю о 3-м или другом ограничении, которое имеют 32-разрядные ОС), и, возможно, анализ вашего ЦП даст гораздо большее улучшение производительности, чем простое использование более быстрого диска диск мог.