0,0
рейтинг
31 июля 2013 в 18:42

Управление → Обоснование необходимости приобретения SSD для разработчиков из песочницы

Добрый день, уважаемые хабраюзеры.

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

image

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

Я решил написать эту статью в то время, пока мой проект компилировался. И он все еще компилировался, когда я написал треть.

Мозг и компьютер


Компьютер следует воспринимать не как нечто великое, достойное поклонения, перед которым нужно стоять на коленях, когда он выполняет вычисления. Нет, это время прошло вместе с ламповыми ЭВМ середины XX века. Сейчас компьютер — это помощник, инструмент, отвертка, которая должна быстро и своевременно помогать. Работы выполняет пользователь, программист, и этой работе оборудование должно помогать, а не наоборот.
Во время работы программиста в его мозгу летает множество идей, мыслей, вариантов. Программисту требуется быстро их проверять и реализовывать. Для этого компьютер должен четко и быстро реагировать на действия пользователя. Даже 30 секундная задержка, при открытии браузера для гуглинга какого-либо технического вопроса, долгий запуск утилиты системы контроля версий, долгое открытие проекта и уж тем более компилирование, при котором, к тому же, компьютер начинает сильно тормозить, сбивает с ритма работы. Приходится учиться думать медленно, записывать на листочек мысли, потому что через 5 минут, когда ты получишь техническую возможность от своего электронного покемона Слоупок реализовать мысль, уже становится поздно. Мозг уже занят другим. И, самое страшное, если мозг теряет поток (Поток). Сейчас компилирование Awad с тремя сотнями проектов в решении — заняло около 10 минут. Это потеря потока. Мозг уже занят другими глобальными задачами, поиском вселенской справедливости или другой багой. И требуется еще 10 минут, помимо времени на завершение текущего процесса мозга, чтобы вернуться в поток. Это ужасно. На одном проекте, для тестирования изменений в коде, надо было потратить до 20 минут на развёртывание. Там были жуткие и долгие кодогенераторы, и для работы измеренной логики, генераторы должны были отработать. Так вот, та 20 минутная задержка превращалась в 40 минутную. Даже после 5-10 минутного компилирования уже можно забыть, зачем же ты это делал. В состоянии технического поиска и тестирования, необходимо быстро проверять разные возможности, и время между задержками на эти проверки, должно быть минимальным.
Быстрый компьютер, который удовлетворяет желаниям программиста, является очень важной вещью. Так же как и гоночный автомобиль, он должен быть быстрым, позволяя реализовать весь потенциал гонщика, а не задерживать его. За быстрым ПК комфортно работать, физически экономится время, и самое главное, не начинается диссонанс с работой головы, не происходит потеря потока.

Скорость работы ПК


Очевидно, что на производительность влияет множество деталей. С центральными процессорами все понятно, они все быстрей и все многоядерней, и загружены они будут только при компилировании. 3D дизайнеры и математики у нас расчеты не ведут. Память поможет большему количеству программ работать совместно. А студия прожорлива на память. Скорость памяти тоже важна. Но следует понимать, что обратиться к оперативной памяти компьютеру, все равно, что сходить в библиотеку человеку. В зависимости от технических характеристик, эта библиотека либо в соседней комнате, либо в соседнем доме. А вот получить данные с устройства постоянного хранения — равносильно заказать книгу на Amazon с доставкой ее по океану на гребной галере, а потом еще и почтой России на телеге, запряжённой старой клячей. Но сейчас происходит очень важная революция в системах хранения данных. К нам приходит SSD, это очень важная веха, наравне, а то и значительнее, чем появление многоядерных процессоров.
SSD — это самолет. Это самолет, в котором сидит курьер FedEX, который с парашютом спрыгнет прямо над твоим домой. SSD дает 5 кратное ускорение при чтении больших файлов. Но это неинтересно. Мы работает с тысячами мелких файлов с кодами, конфигами, и студия все это компилирует. А в сегменте мелких файлов скорость чтения SSD превосходит HDD в 50-100 раз. Это означает компилирование раз в 10 быстрей, как минимум! И общий прирост производительности, гораздо более быстрый запуск системы, своевременную реакцию системы на действия пользователя, готовность системы выполнять требования программиста. SSD даст, условно говоря, 10 кратный прирост производительности; замена же памяти, процессоров даст двух кратный. Вложить в SSD, все равно, что вложить в платину в 18 веке, когда они была дешевле меди. Результат много превосходит затраты. Но об этом в следующей главе.

Экономическое обоснование


Попробуем рассчитать выгодность SSD
Требуется SSD со 120GB – это хватит на систему, проекты и резерв в ~40% свободного места, нужный для полной эффективности накопителя.

Исходные данные
  • Произвольный сферический SSD на120GB 4000 р.
  • Сферический программист в вакууме с низкой зарплатой в месяц 70000 р. (речь о Москве)
  • Продолжительность рабочего месяца 176 ч.
  • Расходы компании на программиста, включая ЕСН (30%) ~100000 р.
  • Стоимость часа программиста 570 р.
  • Среднее число рабочих дней в месяце 23 дня

Прикинем потери времени программиста в день.
Предположим активный кодинг, 4 компиляции проекта в день
  • Время компиляции 10 минут
  • Простой из-за долгой загрузки (время на полный запуск системы и софта – 7 минут, с SSD 2 минуты) 5 минут
  • Простой из-за общих тормозов сложно оценит 30 минут

Посчитаем потери времени
  • 4 компиляции 40 минут
  • 4 потери потока 40 минут
  • Загрузка 5 минут
  • Тормоза 30 минут

Итого 115 минут. Предположим погрешность в +-50% и предположим, что мы переоценили потери и ошиблись в большую сторону. Предположим общий простой в 1 час в день.
Итого 23 часа в месяц. Это 13110 рублей. Это 3,2775 SSD в месяц.

Таким образом, покупка SSD один раз может принести уменьшение убытков на простои вследствие прироста производительности на 13110 рублей в месяц.

Заключение


Покупка SSD повысит производительность программистов и общую удовлетворенность от работы. Экономический эффект многократно превысит стоимость SSD.

p.s. Трудно было выбрать правильный хаб. Если посоветуете в какой хаб перепубликовать — сделаю.

UPDATE
Для интереса решил добавить опрос, Есть ли у вас SSD?
Это будет и поводом потенциальному читателю-менеджеру оценить, соответствует ли его подход тренду, и просто интересно разработчкиам.
Кирюшкин Александр @alexus_ru
карма
10,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Управление

Комментарии (93)

  • +33
    Если требуется такое обоснование, то лучше бежать от такого начальства.
    • 0
      Вас удивит, что в целом обстановка очень хороша. Я не знаю, может мысль о покупке 50 SSD пугает руководство. Тем не менее, только на одном рабочем месте у меня был SSD.
    • +1
      Нужно здесь же упомянуть о различных причинах апгрейда ноутбуков: habrahabr.ru/qa/44300/ — здесь список факторв, влияющих на совокупную стоимость. Замена диска на SSD или изначальный выбор модели с SSD — не последний способ приблизить производительность ноута к десктопу.
  • +29
    А можно мне такую низкую зарплату? Обещаю не просить SSD.
    • +3
      Наверное, стоило уточнить, что речь о Москве
      • 0
        Наверное надо еще уточнить примерный уровень программиста. А то сферический junior на 3-4м курсе вуза это тоже «Сферический программист в вакууме»
        • +1
          Так речь не об уровнях программиста, а о том, что деньги на его оплату много выше стоимости SSD.
          Ну и в конце есть поправка на 50%, чтобы покрыть оплошности
          • 0
            Я больше в контексте предыдущего комментария, нежели самой статьи)
        • +6
          Некоторым джуниорам SSD не поможет.
  • +18
    Я уже год на SSD на рабочем лэптопе. Вообще не представляю теперь как жить без него. Разве только RAID0 на двух SSD.
    • 0
      У меня RAID0 на двух SSD на ноуте — я забыл, что такое ожидание дисковых операций. В целом, вау эффект от одного SSD отсутствует (в отличие от перехода с HDD), ну копировать гигабайты за секунды — очень приятно.
  • –3
    Простите, конечно, но вы думаете, что те менеджеры, которых пытались убедить программисты купить им SSD, но так и не получивших «оного», после прочтения статьи пойдут в магазины за дисками?

    Можно было просто случайно открыть любое сравнение SSD с чем-нибудь ещё, чтобы посмотреть скорость доступа к случайным файлам разных размеров и не нужно было вычислять магические 3,2775 SSD.
    • +1
      > и не нужно было вычислять магические 3,2775 SSD
      Это не скорость. Это количество SSD, которые можно купить за деньги, теряемые на простоях.

      >Простите, конечно, но вы думаете, что те менеджеры,
      Отвечу через пару дней. Самому интересно. Как раз, можно будет знать, помогает ли это обоснование в данном вопросе.
      • 0
        Вроде дали добро. Но пока непонятно, как будто только мне, а я просил для всех :)
        Как раз ссылку на пост и кидал
        • 0
          Вы с помощью этой статьи выбили себе новый жёсткий диск?
          • 0
            Не жетский, а «цельный» :)
            Да, сегодня обещали SSD. Но цель была — SSD всей компании. Пока не ясно.
            • 0
              Я рад за вас, и сам являюсь владельцем «твёрдотельного накопителя», но мне кажется статья, написанная сотрудником компании для указания начальству, что рабочий процесс идёт из рук вон плохо — это немного неправильно.
              Всё это можно было бы решить внутри, без привлечения СМИ :)
              • 0
                Не понимаю вас. Я же не указывал что-то конкретное, название компании. Вдобавок, как много полезного про ускорение компиляции в комментариях, что топик можно переносить в соответствующий раздел. Дополнительно, люди подтверждают (в основном) полезность SSD. И… по моему статья может принести пользу людям. Парочка вроде пишут, что отправят статью своему начальству. Мне кажется, я правильно сделал.
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      >8-15 — более реально.
      Все очень условно. У нас пока именно так. Ибо слишком долгая компиляция.

      >Покупка SSD повысит скорость компиляции, но никак не производительности программиста.
      Опыт с прошлого места — повысит. Я начинаю ненавидеть работу, когда жду, и я не могу нормально читать хабр, т.к. компиляция ресурсоёмка. Тормозит даже Chrome :)
      И да, я ждал, когда кто-нибудь напишет, что SSD лишит законной передышки.

      >Правильно писать «на абсенте»
      Спасибо, и исправил, и повеселился :)
      • 0
        У меня выходит в районе трех полных компиляций в день на локальной машине. Еще до пары десятков на сборочной ферме.
        На полную компиляцию уходит полтора часа на локальной машине и минут сорок на серваках сборочной фермы. Я не считаю запуск юнит тестов.
        Буквально на днях увеличили память, SSD должны поставить позже…

        А вообще, даже не используя SSD можно экономить время. Во первых, отказаться от студии. Она слишком прожорлива. В качестве системы сборки ninja заставила MSBuild курить в сторонке, а Sublime Text показал себя, как очень приятная IDE. Git из бранча с кешированием дисковых операций на винде, заметно быстрее обычного, включение компонентной сборки тоже возымело эффект.

        Но не спорю, ждать компиляции всё равно приходится долго.
        • –1
          Обидно: настраивать рабочее место под себя — это просто супер, но почему-то на рынке даже софта для программистов (т.е. люди как бы и для себя его пишут) преобладает парадигма «все равно компьютер быстрый».

          Напр., толстая IDE на Java — да, она универсальна между платформами, но в разы тормознее не самой худой, но написанной под конкретную ОСь и с удержанием в уме фактора скорости работы. Из версии в версию явовский монстрик худее не становится, и вместо улучшения скорости этой важной для самого программиста программы выходом считается повышение скорости машины. По моему, это кошмар: программер сам себе уже не может построить удобный инструмент.

          Но в реальном мире, где качество ПО определяется не его скоростью и безглючностью, а абстрактными параметрами, вроде числа строк кода и выполнением неких стандартных тестов (помните историю про «return(17)»?) — да, только и остается, что набивать машину памятью, ставить SSD (порой на свои деньги, кстати!), а лучше два, ставить FancyCache — и хоть так экономить свои нервы, настроение и работоспособность.

          А то, и правда, соберешь проект — а уже и забыл, какая классная идея была в уме перед началом сборки, уже из потока вышел — и день можно тупо ковырять код, но уже «без огонька» :(
      • +2
        Если компиляция настолько ресурсоёмка, что тормозит даже Chrome, то не диск является узким местом ;-)
  • 0
    Мне вот как раз сейчас нужно такое обоснование. На прошлой работе я сам себе купил SSD в рабочую машину, так как там было без вариантов, но теперь я работаю в компании уровнем выше, и, очень надеюсь, что эта компания может себе позволить SSD.

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

    У меня 50 проектов в решении и достаточно мощная машина — i5-2320 8Гб ОЗУ. Долго компилируется лишь в первый раз, затем весь рабочий день все необходимые библиотеки держатся в памяти и последующие компиляции занимают до 2 минут. Так что скорость компиляции я не могу использовать в качестве обоснования почему мне нужен SSD.

    А как описать общее ощущение от работы с компьютером, мгновенного переключения и так далее — не представляю.
    • 0
      Я пытался выразить общее ощущение где-то в словах
      «Для этого компьютер должен четко и быстро реагировать на действия пользователя. Даже 30 секундная задержка, при открытии браузера для гуглинга какого-либо технического вопроса, долгий запуск утилиты системы контроля версий, долгое открытие проекта и уж тем более компилирование, при котором, к тому же, компьютер начинает сильно тормозить, сбивает с ритма работы. Приходится учиться думать медленно, записывать на листочек мысли, потому что через 5 минут, когда ты получишь техническую возможность от своего электронного покемона Слоупок реализовать мысль, уже становится поздно.»
  • +1
    У вас в расчетах ошибка:
    Расходы компании на программиста, включая ЕСН (30%) ~100000 р
    не должны быть включены в расчет, поскольку они будут уплачены вне зависимости от того, эффективно работает программист или нет.

    Таким образом, выигрыш по эффективности — 9 147 рублей в месяц.

    Кроме того:
    1. Где гарантия, что выход из потока на 2 минуты (вместо 10 — или сколько там) не будет наносить тот же ущерб?
    2. «Простой из-за общих тормозов» — это что такое? Это как зависит от жесткого диска? А если у вас 100500 программ в памяти висят — SSD эту проблему решит?

    Короче. Я согласен что хороший компьютер с SSD для программиста лучше. Но расчет выше на нормального манагера не должен возыметь никакого эффекта (потому что он выглядит сильно притянутым за уши).
    • 0
      не должны быть включены в расчет,
      Хм. Не понятно. Да, оплачены все равно. Но ведь все хотят, чтобы все оплаченное превратилось в эффективную работу и, как результат, хороший код. Но пусть даже так.

      Где гарантия, что выход из потока на 2 минуты (вместо 10 — или сколько там) не будет наносить тот же ущерб?
      Персональные особенности каждого. В любом случае, шанс выше

      «Простой из-за общих тормозов» — это что такое?
      Не уверен, что могу привести факты, но 100500 программ в памяти (которые наверно свопяться на ssd же) тоже будут работать быстрей.

      Про манагера… Сообщу потом, повлияло ли :)
      • 0
        Ну если повлияет, я буду за вас рад.
        Я немного уточню свою позицию. В ваших раскладах нет ни одного железного довода: даже по времени мы получаем все-равно какую-то вероятность того, что это не сработает. Предположим, что вероятность 50% (либо сработает, либо нет :-)).
        Тогда получается, что оптимизируемая сумма равна 9200/2=4600.

        4600 — это 11 часов работы инженера в месяц. Около получаса в день.

        Теперь давайте посчитаем (а апелляция к деньгам может привести только к такому исходу) на что тратит программист время, кроме ожидания компиляции. Не будет ли верным утверждение, что на пообщаться с подругой в аське, пописать статьи на Хабр, почитать интересные блоги и т.д. программист тратит сопоставимое время? Думаю, что так оно и есть.

        Теперь подумайте: вы приходите к манагеру и говорите: «Давай ты вложишь бабосов и сэкономишь копеечку!»
        Вы готовы к его ответу, что чтобы сэкономить эту же копеечку ему достаточно попросить админов закрыть фейсбук, аську и хабр, причем забесплатно, а? Ну и ужесточить контроль.

        Просто предупреждаю.
        Но на самом деле желаю удачи.
        • +2
          Меня вполне устроит вероятность в 50% :)
          Закрытие фейсбуков и асек приведет к (внезапно) исчезновению некоторых хороших разработчиков, на которых чувство контроля давит. Падению морали у оставшихся. Явно контрпродуктивно.
          В любом случае, когда хабр открывается быстрее, это ведь лучше. Я понимаю вашу точку зрения, но считаю, что SSD надо внедрять насильно.
        • +2
          [sarcasm]Да, чтоб увеличить производительность труда программистов, надо непременно закрыть фейсбук, аську, скайп, хабр и stackoverflow, запретить перекуры, кофе, печеньки и перекусы на рабочем месте[/sarcasm].
          • +1
            Он пошёл в серверную к сисадминам и велел им закрыть доступ на ПУКН со всех компьютеров в офисе.

            Никакого другого начальства над разработчиками и сисадминами в Портале в этот момент в принципе не существовало, а Маг всё-таки назывался президентом. Сисадмины выполнили приказ и заблокировали IP-адрес ПУКНа, а потом вышли в общий зал и с недоумением сообщили программистам о странном приказе начальства.

            По залу, от угла серверной во все концы стал быстро распространяться гул разговоров и смех, а потом начальник Рейтинга Лёха-Апач влез на стул и крикнул на весь зал: «Кто за полчаса не найдёт пяти способов ходить на ПУКН — уволим за служебное несоответствие». Зал покатился со смеху.

            И в самом деле, блокировать доступ на сайты в интернет-компании, профессионально занимающейся поиском и рейтингом сайтов — глупее нельзя было придумать.


            Ашманов. Жизнь внутри пузыря.

            Кто не читал — рекомендую
        • 0
          Вы готовы к его ответу, что чтобы сэкономить эту же копеечку ему достаточно попросить админов закрыть фейсбук, аську и хабр, причем забесплатно, а? Ну и ужесточить контроль.
          Кстати, на такой ответ возникает встречный вопрос: почему это уже давно не сделано? Нет уверенности в эффективности и, вообще, безвредности? Тогда приём «парировать рискованными сомнительными идеями менее рискованные и менее сомнительные идеи» напоминает приём «говорить очевидную глупость с целью демонстрации права её говорить и вообще своего вышестоящего положения». Что сильно демотивирует.

          Справедливости ради, кое-где на знакомых мне режимных заводах предложенные меры давно приняты. Но там контингент работников несколько особенный — программистов почти нет, а те, которые есть, приравнены к сисадминам и имеют доступ ко всему. В принципе я не против идеи подобных ограничений. Но они, по уму, должны сразу оговариваться ещё при собеседовании;-), чтоб чел знал на что идёт. А делать такие вещи внезапно посреди рабочего процесса равносильно пресловутой «смене коней на переправе». Я, конечно, не отрицаю право руководства быть «слоном» в собственной «посудной лавке», но пресловутое «снижение лояльности персонала» при таком раскладе — вещь ожидаемая…
    • 0
      Расходы компании на программиста, включая ЕСН (30%) ~100000 р
      не должны быть включены в расчет, поскольку они будут уплачены вне зависимости от того, эффективно работает программист или нет.
      Думаю, должны. Если некоторая доля рабочего времени программиста на что-то бесполезно теряется, то такая же доля их, как части трат на оплачиваемое рабочее время, тоже теряется.
  • 0
    Судя по времени компиляции — это С/С++? От SSD он не получит почти никакого ускорения. Только если до этого стоял полностью убитый диск 15-летней давности. Вот пример: www.fcenter.ru/online.shtml?articles/hardware/hdd/29573 Разница аж в целую секунду на 11 минут компиляции.
    • +1
      Нет… Это C#. ~300 проектов в решении. Винт, думаю, вполне себе старый и плоховатый. В общем, личный опыт — компилирование больших проектов ускоряется в несколько раз. Но я не проводил измерений.
      • +1
        Вы точно уверены что вам нужно все 300 пересобирать?
        Студия, вроде, умная, билдит только то, что менялось.

        А вот Resharper без SSD тупит дико, но он и с SSD тупит. Так что отключайте решарпер, когда он вам не нужен.
        • 0
          Я обычно тыкаю Build на солюшене. Еще лучше был бы Rebuild, 100%, что все изменения подтянутся, всякие глюки бывают. А разработка всегда трогает 3-10 проектов, интерфейсы, реализации, провайдеры, клиенты.
    • 0
      Когда 8Гб было уже модно, а SSD еще не модно, проводил замеры с компиляцией на рам-диске. Действительно, разница получалась исчезающе маленькая.
      • 0
        все include файлы системных библиотек тоже были в ramdisk?
        • 0
          Нет, на рамдиск выносились только Output Directory and Intermediate Directory. Наверняка я пробовал и весь проект переносить на рамдиск, но раз не помню впечатляющих результатов, значит их не было.
          • 0
            много времени может тратится на чтение include. Если включить опцию «показывать все читаемые include», то их обычно сотни на каждый компилируемый файл.
      • 0
        Действительно, по поводу Include, у нас при сборке еще over 9000 сторонних dll. А у меня позорные 8 Гб оперативки. Боюсь, все не влезет + Chrome 2 гига, студия 2 гига и прочее.
    • 0
      Для C/C++ важен сценарий с инкрементальной сборкой проекта. Здесь SSD может дать ускорение на порядок, в отличии от полной пересборки.
  • 0
    А вы замеры делали?

    Я тестировал так:

    Переносил Temp, файлы проекта и компилятор ( vc++ cmd line tools) на рам диск (даже не ssd) и компилировал Firefox (и в один поток и в 4). Разница была 30 минут и 29.5 (в один поток) и далее сохранялся паритет. Это было 3 года назад, когда я купил первый SSD. На SSD даже не тестировал после результатов. На компиляцию влияет процессор, его кэш и память в меньшей степени, но никак не диск. Диск важен в другом — это безусловно.
    • +2
      SSD ускоряет другой важный сценарий — инкрементальную сборку. По моим замерам ускорение от 3 до 20 раз (для нашего проекта). На полную пересборку SSD практически не повлиял, CPU важней.
  • –3
    Переход на SSD увеличивает общую производительность труда программиста, но не так радикально как это хотят представить. Считать отдельно только компиляцию — это как-то глупо.
    Если проект действительно большой и долго собирается — значит, не надо его собирать целиком, надо дробить на части, с тем чтобы перекомпилировать приходилось только небольшую часть.
    В общем, SSD это скорее такая плюшка, как второй-третий монитор, а вовсе НЕ необходимость.
    • 0
      У программистов вообще нет необходимых вещей — дали им бюджетный нетбук, и пусть работают. Но каждая плюшка немного повышает производительность.

      В небольших городах, где программисты получают по 15К в месяц, многие из инвестиций действительно не так выгодны, вместо них можно нанять дополнительного человека, что сильно повысит производительность. А вот в миллионниках, где зарплаты очень даже немаленькие, они почти всегда окупаются.
      • +1
        > нанять дополнительного человека, что сильно повысит производительность

        Ну, 9 женщин за месяц ребенка никак не родят :)

        Другое дело, что факт лишних рук порой заставляет задуматься — кого первого уволят под горячую руку, если уж руки лишние есть?
    • +7
      Четвертый монитор это плюшка. А доп. монитор и SSD это вещи без которых, невозможно представить, как жить.
    • +4
      >Считать отдельно только компиляцию — это как-то глупо.

      Конечно, глупо. Добавьте сюда ускорение запуска ОС, IDE, поиска по проекту, копирования файлов, открытия документов — да почти всего. Вот тогда будет не глупо.

      Когда ты на чём-то кликаешь и оно срабатывает мгновенно — это кайф, это мотивирует работать.
  • +2
    Корень проблемы, насколько я понял, в том, что руководство не понимает зачем оно нужно. Пусть тогда они сначала себе поставят ssd, чтобы почувствовать насколько быстрее и комфортнее стало работать. Если и после этого они не захотят всем ssd установить, — то из конторы надо валить, такое руководство весьма далеко от IT, и вам, как девелоперу там ничего хорошего не светит.
  • +3
    Нарисуйте пару графиков. Начальство не любит читать тонны текста. Начальство любит чтобы диаграммка и вывод в 3 предложения.
    • +1
      После покупки SSD время на ожидание компиляции станет в 3 раза меньше, и следующие статьи станут короче.
  • +4
    В целом я согласен: SSD — это супер. Но вот экономическая сторона обоснования мне кажется притянутой «за уши».
    Я не заметил ускорения своей работы после установки SSD. Да, компилировать стало 4 секунды, но на скорость думания и кодинга это не повлияло. Обычно когда надо скомпилировать, то это значит готова какая то логически законченная часть кода. И перед переходом к следующей подзадачи в любом случае будет некая пауза. То есть я не вижу доказательства, что время, которое тратится например на компиляцию могло бы быть потрачено с большей пользой.
    В общем, я бы себе не купил SSD если бы решение принималось только на основе подобных экономических соображений, особенной учитываю мою сверхнизкую по столичным меркам зарплату.
  • 0
    SSD безусловно вещь в хозяйстве полезная, однако позволю себе не согласиться с доводом об ускорении компиляции.
    Не всегда и не для всех.
    Мы тоже думали, вот поставим SSD и ускорим компиляцию «хотя бы раза в два».
    В нашем случае (проект на С\С++, сборка занимает больше 20 минут на i7) замена HDD на SSD дала 1-2% выигрыша.
    В основном, за счёт ускорения линковки. Так получилось, потому что собирается один большой проект в один поток и распараллелить никак. Производительность упёрлась в частоту CPU.
    Вывод: думать надо над архитектурой до, и рефакторингом после.
    • 0
      IncrediBuild Вам в помощь.
      Даже на одном компе, выигрыш пракитически линейный к кол-ву ядер, и от SSD сразу же пользу почуствуете.
    • 0
      Аналогично. Занимаюсь компиляцией пакетов программ для FreeBSD на SSD. Разницы по времени компиляции между SSD и HDD не заметил. Гораздо важнее частота процессора: чем она больше, тем заметнее уменьшение времени компиляции.
  • +2
    SSD — это как героин. Единожды попробовав его ты уже не представляешь — как можно обходиться без него. Для меня, в первую очень, SSD обеспечивает душевное спокойствие, т.к. с ним практически любая несложная операция происходит мгновенно. Ты не успеваешь об этом подумать, а оно уже произошло. Позволяет держать мозг в тонусе, не отвлекаясь на всякую мишуру.
  • +1
    Тут зашла речь про компиляцию, поэтому расскажу как я эту проблему решаю. Вообщем то, что нужно использовать SSD это и ежику понятно, и те кто их не используют просто не уважают себя и свое время. Но так или иначе, компиляция больших проектов является и CPU-bound и I/O-bound одновременно. Соответственно единственный вариант это масштабировать — это использовать больше ядер и больше дисков.

    К сожалению «больше ядер» ждать от Intel не приходится, они застряли в дыре, поэтому даже расширение до пары Xeon-ов абсолютно бессмысленная задача. Ксеоны правда приходится использовать, и вот для чего… если коротко, все началось с наблюдения что виртуалки в некоторых случаях работают быстрее хостовой системы т.к. не замусорены всяким адским адом. Соответственно появилась такая идея, что если дать нескольким виртуалкам по маленькому SSD каждой и просто параллелить компиляцию и тестирование точно так же, как это делает MSBuild локально.

    Ну а дальше все просто — нужна синхронизация файлов и scheduler который синхронизирует задачи и выполняет компиляцию, тестирование или что там надо. Естественно что в идеале хотелось бы процессную виртуализацию а-ля App-V, но такое руками не написать. Вообщем, на сегодняшний день этот проект, именуемый FreeSpace, так еще и не увидел свет — но как proof of concept он работает, хотя тем кто скупится на SSD наверное не понравится идея делать continuous/build на достаточно дорогом сервере с пачкой SSD и дорогой оперативкой. Что сказать, каждому своё.
    • 0
      А почему интел «застрял в дыре»? Есть что почитать на эту тему? Единственная версия, которую видел я — это тот факт, что они вырвались сильно вперёд в десктопах по сравнению с AMD и поэтому на 3-4 года перекинули силы на мобильные платформы.
      • 0
        А читать ничего не надо, достаточно посмотреть на цены, поизводительность и кол-во ядер Xeon-ов и изменения за последние лет 5. Если коротко — все плохо.
        • 0
          перфоманс десктопных и лэптопных интеловских процов вырос за последние 5 лет раза в полтора, не более. Ну так просто конкурентов нету.

          Я уточню вопрос: я верю, что скорости не растут и что всё плохо. Мне интереснен анализ прочин.
  • 0
    Спасибо! Отправил шефу, тема письма: «Настоятельно требую».
  • +6
    Пора уже создавать посты «основания НЕ покупать ССД для разработчиков», потому что стоят они настолько ничтожно мало, а прирост производительности настолько сногсшибательно огромен, что оснований выбрасывать деньги на древнюю технологию HDD для разработчиков в масштабе компании просто нет.
  • +9
    Я на позапрошлой работе делал проще. Если мне что-то надо было для рабочего компа — я шёл и покупал это за свои деньги. И мне пофиг было, одобряет начальство или нет. Вообще-то и начальству было глубоко пофиг на то чем я комп пичкаю, лишь бы работало. Так что в вашей ситуации купить себе в комп SSD за 4 тыщи при зарплате в 70 тыщ это самое простое и, возможно, правильное решение.
    • +2
      +1
      Причем всё ваше, вместе с вами, благополучно переедет и на новую работу при случае. Таким образом, у вас всегда удобные мышь/клавиатура/доп.монитор/ssd/и т.п.
  • –1
    Время компиляции на ssd в рассчетах принято за ноль? Если нет, то «потеря потока» тоже одинаковая и ее можно сократить.

    Впрочем, это не отменяет того факта, что с ssd жизнь становится попроще. Однако, время компиляции от жесткого диска зависит мало, современные ide все неплохо кэшируют. Процессор — вот тонкое место.

    Требую статью на тему «обосноваие необходимости билд-фермы для разработчиков» :)
  • +6
    Если ССД действительно так жизненно необходим, то программист с зарплатой 70к в месяц может купить себе его всего за 1 день работы. Хотя, это же надо свои деньги в рабочий процесс вкладывать, лучше статью на хабр написать.
    • 0
      Я категорически не согласен. Я не могу купить 50 SSD на офис, я не могу потратить 185 000 рублей. Но я хочу, чтобы SSD был у всех. Считайте меня миссионером. Проще пост на хабре? Сомневаюсь. Пост, его поддержка и модификация, ответы на комментарии, по времени могут выйти и подороже SSD.
      • 0
        Сомневаюсь. Пост, его поддержка и модификация, ответы на комментарии, по времени могут выйти и подороже SSD.

        Угу, щедро оплаченном работодателем :)
  • –5
    SSD живет 3 года. SSD возможен только на материнках которые поддерживают его как Giga-buffer(вместо штатных 64Мб).
    SSD для разработчиков возможен массово лишь как такой буффер, на котором данные:
    1. не хранятся
    2. никто не расстроется от замены

    Оптимальное сочетание офисное это:
    SSD-20
    Raid 1/0/10/5/6 — x 2(3) HDD 1ТБ

    P.S. очень много маленьких файлов убьют SSD быстрее, так что выбирайте правильную ФС — btrfs,raser4 и т.д., но никак не Ext3
    • +5
      > никто не расстроится от замены.
      dvcs же… У меня полная рабочая среда разворачивается за четыре часа из корпоративной сети, причем две трети времени занимает сборка мастера, одну треть — клонирование репозитория, а паралельно можно установить и настроить идешку, браузер, мессенджер, etc…
    • +2
      Вот в интел то дураки сидят, с их 5-летней гарантией на ssd.
      Современные ssd-диски уже вплотную приблизились к hdd по долговечности. Самое интересное что начальство, менеджеров как раз таки уговаривать не долго, лично я несколько раз сталкивался с тем что разработчики/сисадмины начитавшись винрарных статей про короткий цикл жизни ссд, категорически не желали его ставить ни на сервера, ни на рабочие компы.
  • 0
    Вопрос автору: 10 минут, которые Вы указали это 1) каждый простой build после изменения даже одного файла, 2) clean+build, или вообще, 3) configure && make?
    Конечно, если в Вашем проекте уходит по 10 минут на build после каждого изменения, что бы просто запустить на отладку, то это проблема и тогда, действительно, нужно SSD и/или радикально увеличивать объем памяти под дисковый кеш.

    Но если это ситуации 2 или 3, то имхо покупка SSD неоправдана. Мне приходилось работать в проектах, полная пересборка которых занимала несколько часов, а прогон тестов несколько суток. Но это же не значит, что я, как разработчик должен это делать каждый раз, когда запускаю отладку. В процессе отладки, как правило, перекомпилируются несколько файлов исходных текстов, число которых от сборки к сборке редко превышает пары десятков. В результате таких правок приходится, как правило, пересобирать один модуль (dll, jar или что у Вас там). У меня, даже в очень больших проектах это занимает меньше минуты. У меня обычно деплой и старт приложения занимает больше, но в моем случае это при помощи SSD не ускорить :)

    Исключения: те случаи, когда приходится отлаживать сборочный процесс, включая сборку инсталяторов, дистрибутивов. :)))
    • 0
      Несколько напрягает после правки допустим 6-10 проектов, все 6 проектов, еще и в правильном порядке по очереди сбилдить. В любом случае, все способы ускорения имеют право быть. Почему много проектов? Разнесено все, что только можно. Интерфейсы, реализации, клиенты этих реализаций. Один новый метод — изменение интерфейса, тройки реализаций и пары клиентов.

      Приятней нажать один раз на солюшене — build, при том что студия сама определять должна, что не надо билдить вообще.
      • 0
        Ну это естественно, что должна быть одна кнопка. не важно сделана она в виде F5 или 'make' (как правило, стрелка вверх, enter в консоли). И естественно, что если не было изменений ни в одном файле по дереву целей, то ни один модуль и не должен пересобираться и ни один класс не должен компилироваться. Вопрос и был в том какой вариант занимает много времени типа 'make clean && make' или просто 'make' (не важно как оно в Вашей конкретной IDE/рабочей среде называется).

        Ну ок, я Вас понял, то есть, у Вас случай — build, а не clean&&build.

        Описанный Вами случай — изменение интерфейса взаимодействия между модулями действительно может потребовать существенных затрат времени на сборку пока интерфейсы еще не устоялись и часто меняются. Особенно для С++. C# и Java в этом смысле гораздо быстрее.

        Простите, но 10 минут мне кажутся преувеличенными. В Ваших 6-ти проектах будут реально _компилироваться_ пара десятков файлов. А поскольку, судя по Вашему описанию, эти модули невелики, то мне как-то не верится, что линковка каждого из них будет занимать больше одной минуты. У Вас это реально занимает 10 минут? Может все таки не HDD является бутылочным горлышком?
        • 0
          Да, есть проблемы и в памяти, сейчас 4, на днях обещают 8. И в процессоре i3 2120.
          Но разве make не должен вызвать пересборку сборок, зависящих от изменившейся сборки? И пересборку зависимых от зависимых? А это целое дерево
          • 0
            Да, это целое дерево.

            И VisualStudio, так же как и make и ant и все прочие системы сборок просто проходится по этому дереву для того чтобы определить что им надо перекомпилировать и перелинковать.
  • 0
    Возмем сферическую компанию в Москве из 10 человек. Всем купить SSD стоит 4к. Это стоимость двух недель работы одного программиста. За две недели можно прикрутить инкрементальную сборку. Эффект будет больше, чем от SSD.
    • 0
      Допустим, я откорректировал код, и хочу сразу начать его дебажить на локальной машине. Вы говорите о билд сервере? Он есть, он он не локальный. Или я не правильно понял?
      • 0
        Я говорю о локальной машине. В случае с дебагом, при стандартном проекте, в современной IDE уже есть инкрементальный билд.
    • 0
      Сборки сборками. Но когда у меня на рабочем компе с топовой конфигурацией, но обычными хардами — холодный запуск браузера тратится больше 10 секунд, старт IDE больше минуты. Дома бюджетный ноут, в котором я поменял хард на ssd, на теже действия уходят считанные секунды. Посмотреть аннотейты, проиндексировать весь проект, распаковать архив — все это мелочи которые на компе с ссд проходят настолько быстро, что потом засев обратно на hdd чувствуешь себя слоупоком.
      Так что ссд я бы по хорошему ставил всем, вообще всем кто работает за компом
  • 0
    Помню, в 2010-11 разрабатывал под XP, и начальство не хотело ставить дополнительные 2GiB памяти, мотивируя тем, что XP не поддерживает больше 3 (а было 2). Потом поставили, проект стал собираться быстро вместо 10 минут…
  • 0
    Думаю, хорошая тема — разместить на 20-гиговом SLC SSD swap-файл.
  • –1
    Работал с солюшеном, о котором говорит автор (300 проектов). Пробовал его собирать целиком в оперативной памяти (на машине 16 Гб, делал рамдиск, на который влезал собранный солюшен — около 5-6 Гб). Значительного прироста не заметил, что показалось странным. Возможно, компилятор генерирует временные файлы, которые записываются и читаются с жесткого диска (не уверен). Также пробовал его собирать и на SSD, тоже значительного прироста не заметил. Но если бывшим коллегам поставят SSD, буду рад :)

    P.S. С автором, похоже, немного разминулись по времени :)
  • +1
    В статье упоминается о компиляции. А проводились ли реальные тесты, показывающие реальное ускорение компиляции? У меня небольшой проект С++ (~80файлов) + boost. Я хотоел ускрить компиляцию нашел рекомендацию использовать RamDrive. Какого-либо ощутимого ускорения не получил. Вообще! ОСь хорошо кеширует. А вот замена процессора ускорила компиляцию раза в полтора. И это уже было ощутимо. Ускорял инлайнингом cpp файлов, рефакторингом.
    Даст ли SSD волшебные «ощутимые 10 раз»?

    Я не говорю о том, когда нужно быстро запускать виртуальные машины, тяжелые приложения.
    • 0
      Я еще не получил SSD, чтобы провести тест. Но коммент выше выбил меня из колеи…
      • 0
        %TEMP% и %TMP% тоже должны на быстрый диск указывать.
        Соурсы тоже должны на быстром диске лежать.
        Зависимости между проектами должны быть выставлены
        Обратитите внимание, если Visual Studio до 2010, то оно все последовательно собирает в любом случае.
  • 0
    Надо запретить еще чай, печеньки и туалет закрыть на замок… На этом столько теряют времени, да еще и издержки! :)
  • 0
    Меня ещё в 2004 удивил тот факт, что 15-25% рабочего времени тратятся на ожидание реакции тормозной системы (Windows XP на 256GiB) при том, что стоимость компьютера сопоставима с размером месячной зарплаты, и начальство по этому поводу ничего не делает.
  • 0
    Производительность компиляции и тестов гораздо эффективнее повышает вынос этой задачи на сервера непрерывной интеграции. Остается компиляция для отладки, здесь да, SSD поможет.
  • 0
    Более бюджетный вариант для пользователей Linux.

    Создаём raid1, состоящий из файла на hdd и ram-диска (или файла на tmpfs). Такое легко провернуть средствами btrfs. В результате — скорость чтения в разы превышает скорость любого ssd.

    Один недостаток: после каждой перезагрузки придётся восстанавливать ram-зеркало. Но для пары-тройки гигабайт данных это дело нескольких секунд.
  • 0
    С помощью SSD оживил слегка устаревший домашний ноут. Благо, в нем был отсек для дополнительного жесткого диска.
    Правда, до конца не верю в сохранность данных, регулярно делаю бекапы и профиль пользователя держу на HDD.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.