Про SSD

Читающие мой твиттер в курсе (и вообще, читающие твиттер самые первые в курсе по любому поводу) что взял я себе на работу SSD, дабы посмотреть, а не ускорит ли сия чудо железка процесс компиляции, который всех уже порядком подзадолбал.



На самом деле, это была такая еврейская попытка сэкономить на апгрейде, потому что железки у всех стоят старые, более менее актуальные лет этак пять назад -- у меня Athlon 64 X2 4000+, 2 Gb RAM, поверх всего этого бегает старая и добрая WinXP (SATA на борту материнки есть, правда, по-моему, первой версии).

Бенчмаркал я все на плюсовом проекте, который собирал в VS2005. Проект не маленький -- в output валит где-то 600 объектных файлов объемом за полгига, используется много либ, включая Qt и boost.

Тестировал таким макаром -- добивался в IDE компиляции до состояния "project is up-to-date", выходил из IDE, запускал ее снова, менял один хидер (который приводит к перекомпиляции пару десятков файлов), собирался и мерил время, потом возвращал хидер в исходное состояние и мерил еще раз. Вторую компиляцию делал полагаясь, что на ней должен в полном объеме показать себя кэш.

На HDD вся эта история вела себя так. Начинаешь первый раз компилировать проект -- чуть больше минуты происходит нечто, жрущее CPU и жующее винт по полной программе (есть мнение, что это построение зависимостей файлов), только после этого начинается сборка. Компиляция занимает где-то 3 минуты, потом еще 2 минуты занимает линковка. Итоговое время 6:15.
Второй прогон дает 4:07. К этой цифре мы еще вернемся.

Теперь все тоже самое на SSD, куда я перенес все сырцы проекта и все либы, от которых зависит проект. Единственное, что я не сделал, не переставил на SSD Visual Studio.
Предварительный этап до начала компиляции на SSD так же брутален, и кушает те же самые минута 10 секунд. Компиляция -- те же самые три минуты, что и на HDD, а вот линковка в этом проходе работает в два раза быстрее, чем на HDD, все было сделано за минуту. Итого -- 5:10, на минуту лучше, ее мы выиграли при линковке.
Второй прогон дает 4:00, то же самое, что и на HDD. 3 минуты компиляция, минута -- линковка, предварительных действий, которые кушают минуту, при втором проходе не наблюдается.

Мораль?
Вся эта история о кэше дисковых данных в RAM. Когда вы работаете в IDE с одним проектом и у вас подтянулись все данные в кэш, в принципе, уже не важно, на HDD или SDD находятся ваши файлы. Результаты первого прохода на HDD хуже, очевидно, за счет того, что подготовка с билду выбивает из кэша объектные файлы, которые будут нужны на этапе линковки. Этот же самый вылет данных из кэша при компиляции на SSD не играет никакой роли -- SSD по скорости работы соизмерим со скоростью RAM. На второй проходе предварительного этапа подготовки к билду нет, поэтому работает все одинаково хорошо и на SSD, и на HDD.

Наверное, дополнительная RAM более полезный и универсальный ресурс, чем SSD. А главное, он обладает значительно большей амортизацией, ибо, подозреваю, SSD в таком режиме продержится дай б-г хотя бы год... Да, и на что-то 64-х битное пора, пора переходить.

Скорость чтения с SSD, конечно, очень впечатляет, и я догадываюсь, как лихо с такой железки стартует ОС и тяжелые программы, вроде фотошопа. Сам я наблюдал преимущества нереальной скорости чтения на вещах, вроде подсчета размера папки с boost (3+ Gb, 30k+ файлов) или на процедуре проверки дерева проекта на предмет того, какие именно файлы надо коммитить в репозиторий. На SSD эти вещи стабильно занимают максимум пару секунд. На винте, если вам не повезло (с кэшированием), то ждать можно несколько десятков (!) секунд.

The bottom line -- хуже точно не стало. Вопрос еще в том, насколько хватит ресурса этого дела, если каждый день его насиловать компиляциями. Ну и понятно, что в моем случае надо делать полный апгрейд железа и не пытаться кого-то обмануть.

зы. Доставляли комменты в твиттере от людей, мало чего понимающих в технических тонкостях, о том, что WinXP "плохо работает" с SSD. Наличие TRIM, конечно же, не помешало бы, но это критично только на операциях записи и только в случае основательно поюзанного раздела.