Комментарии 93
Если требуется такое обоснование, то лучше бежать от такого начальства.
Вас удивит, что в целом обстановка очень хороша. Я не знаю, может мысль о покупке 50 SSD пугает руководство. Тем не менее, только на одном рабочем месте у меня был SSD.
Нужно здесь же упомянуть о различных причинах апгрейда ноутбуков: habrahabr.ru/qa/44300/ — здесь список факторв, влияющих на совокупную стоимость. Замена диска на SSD или изначальный выбор модели с SSD — не последний способ приблизить производительность ноута к десктопу.
А можно мне такую низкую зарплату? Обещаю не просить SSD.
Я уже год на SSD на рабочем лэптопе. Вообще не представляю теперь как жить без него. Разве только RAID0 на двух SSD.
Простите, конечно, но вы думаете, что те менеджеры, которых пытались убедить программисты купить им SSD, но так и не получивших «оного», после прочтения статьи пойдут в магазины за дисками?
Можно было просто случайно открыть любое сравнение SSD с чем-нибудь ещё, чтобы посмотреть скорость доступа к случайным файлам разных размеров и не нужно было вычислять магические 3,2775 SSD.
Можно было просто случайно открыть любое сравнение SSD с чем-нибудь ещё, чтобы посмотреть скорость доступа к случайным файлам разных размеров и не нужно было вычислять магические 3,2775 SSD.
> и не нужно было вычислять магические 3,2775 SSD
Это не скорость. Это количество SSD, которые можно купить за деньги, теряемые на простоях.
>Простите, конечно, но вы думаете, что те менеджеры,
Отвечу через пару дней. Самому интересно. Как раз, можно будет знать, помогает ли это обоснование в данном вопросе.
Это не скорость. Это количество SSD, которые можно купить за деньги, теряемые на простоях.
>Простите, конечно, но вы думаете, что те менеджеры,
Отвечу через пару дней. Самому интересно. Как раз, можно будет знать, помогает ли это обоснование в данном вопросе.
Вроде дали добро. Но пока непонятно, как будто только мне, а я просил для всех :)
Как раз ссылку на пост и кидал
Как раз ссылку на пост и кидал
Вы с помощью этой статьи выбили себе новый жёсткий диск?
Не жетский, а «цельный» :)
Да, сегодня обещали SSD. Но цель была — SSD всей компании. Пока не ясно.
Да, сегодня обещали SSD. Но цель была — SSD всей компании. Пока не ясно.
Я рад за вас, и сам являюсь владельцем «твёрдотельного накопителя», но мне кажется статья, написанная сотрудником компании для указания начальству, что рабочий процесс идёт из рук вон плохо — это немного неправильно.
Всё это можно было бы решить внутри, без привлечения СМИ :)
Всё это можно было бы решить внутри, без привлечения СМИ :)
Не понимаю вас. Я же не указывал что-то конкретное, название компании. Вдобавок, как много полезного про ускорение компиляции в комментариях, что топик можно переносить в соответствующий раздел. Дополнительно, люди подтверждают (в основном) полезность SSD. И… по моему статья может принести пользу людям. Парочка вроде пишут, что отправят статью своему начальству. Мне кажется, я правильно сделал.
НЛО прилетело и опубликовало эту надпись здесь
>8-15 — более реально.
Все очень условно. У нас пока именно так. Ибо слишком долгая компиляция.
>Покупка SSD повысит скорость компиляции, но никак не производительности программиста.
Опыт с прошлого места — повысит. Я начинаю ненавидеть работу, когда жду, и я не могу нормально читать хабр, т.к. компиляция ресурсоёмка. Тормозит даже Chrome :)
И да, я ждал, когда кто-нибудь напишет, что SSD лишит законной передышки.
>Правильно писать «на абсенте»
Спасибо, и исправил, и повеселился :)
Все очень условно. У нас пока именно так. Ибо слишком долгая компиляция.
>Покупка SSD повысит скорость компиляции, но никак не производительности программиста.
Опыт с прошлого места — повысит. Я начинаю ненавидеть работу, когда жду, и я не могу нормально читать хабр, т.к. компиляция ресурсоёмка. Тормозит даже Chrome :)
И да, я ждал, когда кто-нибудь напишет, что SSD лишит законной передышки.
>Правильно писать «на абсенте»
Спасибо, и исправил, и повеселился :)
У меня выходит в районе трех полных компиляций в день на локальной машине. Еще до пары десятков на сборочной ферме.
На полную компиляцию уходит полтора часа на локальной машине и минут сорок на серваках сборочной фермы. Я не считаю запуск юнит тестов.
Буквально на днях увеличили память, SSD должны поставить позже…
А вообще, даже не используя SSD можно экономить время. Во первых, отказаться от студии. Она слишком прожорлива. В качестве системы сборки ninja заставила MSBuild курить в сторонке, а Sublime Text показал себя, как очень приятная IDE. Git из бранча с кешированием дисковых операций на винде, заметно быстрее обычного, включение компонентной сборки тоже возымело эффект.
Но не спорю, ждать компиляции всё равно приходится долго.
На полную компиляцию уходит полтора часа на локальной машине и минут сорок на серваках сборочной фермы. Я не считаю запуск юнит тестов.
Буквально на днях увеличили память, SSD должны поставить позже…
А вообще, даже не используя SSD можно экономить время. Во первых, отказаться от студии. Она слишком прожорлива. В качестве системы сборки ninja заставила MSBuild курить в сторонке, а Sublime Text показал себя, как очень приятная IDE. Git из бранча с кешированием дисковых операций на винде, заметно быстрее обычного, включение компонентной сборки тоже возымело эффект.
Но не спорю, ждать компиляции всё равно приходится долго.
Обидно: настраивать рабочее место под себя — это просто супер, но почему-то на рынке даже софта для программистов (т.е. люди как бы и для себя его пишут) преобладает парадигма «все равно компьютер быстрый».
Напр., толстая IDE на Java — да, она универсальна между платформами, но в разы тормознее не самой худой, но написанной под конкретную ОСь и с удержанием в уме фактора скорости работы. Из версии в версию явовский монстрик худее не становится, и вместо улучшения скорости этой важной для самого программиста программы выходом считается повышение скорости машины. По моему, это кошмар: программер сам себе уже не может построить удобный инструмент.
Но в реальном мире, где качество ПО определяется не его скоростью и безглючностью, а абстрактными параметрами, вроде числа строк кода и выполнением неких стандартных тестов (помните историю про «return(17)»?) — да, только и остается, что набивать машину памятью, ставить SSD (порой на свои деньги, кстати!), а лучше два, ставить FancyCache — и хоть так экономить свои нервы, настроение и работоспособность.
А то, и правда, соберешь проект — а уже и забыл, какая классная идея была в уме перед началом сборки, уже из потока вышел — и день можно тупо ковырять код, но уже «без огонька» :(
Напр., толстая IDE на Java — да, она универсальна между платформами, но в разы тормознее не самой худой, но написанной под конкретную ОСь и с удержанием в уме фактора скорости работы. Из версии в версию явовский монстрик худее не становится, и вместо улучшения скорости этой важной для самого программиста программы выходом считается повышение скорости машины. По моему, это кошмар: программер сам себе уже не может построить удобный инструмент.
Но в реальном мире, где качество ПО определяется не его скоростью и безглючностью, а абстрактными параметрами, вроде числа строк кода и выполнением неких стандартных тестов (помните историю про «return(17)»?) — да, только и остается, что набивать машину памятью, ставить SSD (порой на свои деньги, кстати!), а лучше два, ставить FancyCache — и хоть так экономить свои нервы, настроение и работоспособность.
А то, и правда, соберешь проект — а уже и забыл, какая классная идея была в уме перед началом сборки, уже из потока вышел — и день можно тупо ковырять код, но уже «без огонька» :(
Если компиляция настолько ресурсоёмка, что тормозит даже Chrome, то не диск является узким местом ;-)
Мне вот как раз сейчас нужно такое обоснование. На прошлой работе я сам себе купил SSD в рабочую машину, так как там было без вариантов, но теперь я работаю в компании уровнем выше, и, очень надеюсь, что эта компания может себе позволить SSD.
Но мне нужно конкретное обоснование с результатами тестов, для проектов похожих на те, с которыми я работаю.
У меня 50 проектов в решении и достаточно мощная машина — i5-2320 8Гб ОЗУ. Долго компилируется лишь в первый раз, затем весь рабочий день все необходимые библиотеки держатся в памяти и последующие компиляции занимают до 2 минут. Так что скорость компиляции я не могу использовать в качестве обоснования почему мне нужен SSD.
А как описать общее ощущение от работы с компьютером, мгновенного переключения и так далее — не представляю.
Но мне нужно конкретное обоснование с результатами тестов, для проектов похожих на те, с которыми я работаю.
У меня 50 проектов в решении и достаточно мощная машина — i5-2320 8Гб ОЗУ. Долго компилируется лишь в первый раз, затем весь рабочий день все необходимые библиотеки держатся в памяти и последующие компиляции занимают до 2 минут. Так что скорость компиляции я не могу использовать в качестве обоснования почему мне нужен SSD.
А как описать общее ощущение от работы с компьютером, мгновенного переключения и так далее — не представляю.
Я пытался выразить общее ощущение где-то в словах
«Для этого компьютер должен четко и быстро реагировать на действия пользователя. Даже 30 секундная задержка, при открытии браузера для гуглинга какого-либо технического вопроса, долгий запуск утилиты системы контроля версий, долгое открытие проекта и уж тем более компилирование, при котором, к тому же, компьютер начинает сильно тормозить, сбивает с ритма работы. Приходится учиться думать медленно, записывать на листочек мысли, потому что через 5 минут, когда ты получишь техническую возможность от своего электронного покемона Слоупок реализовать мысль, уже становится поздно.»
У вас в расчетах ошибка:
Таким образом, выигрыш по эффективности — 9 147 рублей в месяц.
Кроме того:
1. Где гарантия, что выход из потока на 2 минуты (вместо 10 — или сколько там) не будет наносить тот же ущерб?
2. «Простой из-за общих тормозов» — это что такое? Это как зависит от жесткого диска? А если у вас 100500 программ в памяти висят — SSD эту проблему решит?
Короче. Я согласен что хороший компьютер с SSD для программиста лучше. Но расчет выше на нормального манагера не должен возыметь никакого эффекта (потому что он выглядит сильно притянутым за уши).
Расходы компании на программиста, включая ЕСН (30%) ~100000 рне должны быть включены в расчет, поскольку они будут уплачены вне зависимости от того, эффективно работает программист или нет.
Таким образом, выигрыш по эффективности — 9 147 рублей в месяц.
Кроме того:
1. Где гарантия, что выход из потока на 2 минуты (вместо 10 — или сколько там) не будет наносить тот же ущерб?
2. «Простой из-за общих тормозов» — это что такое? Это как зависит от жесткого диска? А если у вас 100500 программ в памяти висят — SSD эту проблему решит?
Короче. Я согласен что хороший компьютер с SSD для программиста лучше. Но расчет выше на нормального манагера не должен возыметь никакого эффекта (потому что он выглядит сильно притянутым за уши).
не должны быть включены в расчет,Хм. Не понятно. Да, оплачены все равно. Но ведь все хотят, чтобы все оплаченное превратилось в эффективную работу и, как результат, хороший код. Но пусть даже так.
Где гарантия, что выход из потока на 2 минуты (вместо 10 — или сколько там) не будет наносить тот же ущерб?Персональные особенности каждого. В любом случае, шанс выше
«Простой из-за общих тормозов» — это что такое?Не уверен, что могу привести факты, но 100500 программ в памяти (которые наверно свопяться на ssd же) тоже будут работать быстрей.
Про манагера… Сообщу потом, повлияло ли :)
Ну если повлияет, я буду за вас рад.
Я немного уточню свою позицию. В ваших раскладах нет ни одного железного довода: даже по времени мы получаем все-равно какую-то вероятность того, что это не сработает. Предположим, что вероятность 50% (либо сработает, либо нет :-)).
Тогда получается, что оптимизируемая сумма равна 9200/2=4600.
4600 — это 11 часов работы инженера в месяц. Около получаса в день.
Теперь давайте посчитаем (а апелляция к деньгам может привести только к такому исходу) на что тратит программист время, кроме ожидания компиляции. Не будет ли верным утверждение, что на пообщаться с подругой в аське, пописать статьи на Хабр, почитать интересные блоги и т.д. программист тратит сопоставимое время? Думаю, что так оно и есть.
Теперь подумайте: вы приходите к манагеру и говорите: «Давай ты вложишь бабосов и сэкономишь копеечку!»
Вы готовы к его ответу, что чтобы сэкономить эту же копеечку ему достаточно попросить админов закрыть фейсбук, аську и хабр, причем забесплатно, а? Ну и ужесточить контроль.
Просто предупреждаю.
Но на самом деле желаю удачи.
Я немного уточню свою позицию. В ваших раскладах нет ни одного железного довода: даже по времени мы получаем все-равно какую-то вероятность того, что это не сработает. Предположим, что вероятность 50% (либо сработает, либо нет :-)).
Тогда получается, что оптимизируемая сумма равна 9200/2=4600.
4600 — это 11 часов работы инженера в месяц. Около получаса в день.
Теперь давайте посчитаем (а апелляция к деньгам может привести только к такому исходу) на что тратит программист время, кроме ожидания компиляции. Не будет ли верным утверждение, что на пообщаться с подругой в аське, пописать статьи на Хабр, почитать интересные блоги и т.д. программист тратит сопоставимое время? Думаю, что так оно и есть.
Теперь подумайте: вы приходите к манагеру и говорите: «Давай ты вложишь бабосов и сэкономишь копеечку!»
Вы готовы к его ответу, что чтобы сэкономить эту же копеечку ему достаточно попросить админов закрыть фейсбук, аську и хабр, причем забесплатно, а? Ну и ужесточить контроль.
Просто предупреждаю.
Но на самом деле желаю удачи.
Меня вполне устроит вероятность в 50% :)
Закрытие фейсбуков и асек приведет к (внезапно) исчезновению некоторых хороших разработчиков, на которых чувство контроля давит. Падению морали у оставшихся. Явно контрпродуктивно.
В любом случае, когда хабр открывается быстрее, это ведь лучше. Я понимаю вашу точку зрения, но считаю, что SSD надо внедрять насильно.
Закрытие фейсбуков и асек приведет к (внезапно) исчезновению некоторых хороших разработчиков, на которых чувство контроля давит. Падению морали у оставшихся. Явно контрпродуктивно.
В любом случае, когда хабр открывается быстрее, это ведь лучше. Я понимаю вашу точку зрения, но считаю, что SSD надо внедрять насильно.
[sarcasm]Да, чтоб увеличить производительность труда программистов, надо непременно закрыть фейсбук, аську, скайп, хабр и stackoverflow, запретить перекуры, кофе, печеньки и перекусы на рабочем месте[/sarcasm].
Он пошёл в серверную к сисадминам и велел им закрыть доступ на ПУКН со всех компьютеров в офисе.
Никакого другого начальства над разработчиками и сисадминами в Портале в этот момент в принципе не существовало, а Маг всё-таки назывался президентом. Сисадмины выполнили приказ и заблокировали IP-адрес ПУКНа, а потом вышли в общий зал и с недоумением сообщили программистам о странном приказе начальства.
По залу, от угла серверной во все концы стал быстро распространяться гул разговоров и смех, а потом начальник Рейтинга Лёха-Апач влез на стул и крикнул на весь зал: «Кто за полчаса не найдёт пяти способов ходить на ПУКН — уволим за служебное несоответствие». Зал покатился со смеху.
И в самом деле, блокировать доступ на сайты в интернет-компании, профессионально занимающейся поиском и рейтингом сайтов — глупее нельзя было придумать.
Ашманов. Жизнь внутри пузыря.
Кто не читал — рекомендую
Никакого другого начальства над разработчиками и сисадминами в Портале в этот момент в принципе не существовало, а Маг всё-таки назывался президентом. Сисадмины выполнили приказ и заблокировали IP-адрес ПУКНа, а потом вышли в общий зал и с недоумением сообщили программистам о странном приказе начальства.
По залу, от угла серверной во все концы стал быстро распространяться гул разговоров и смех, а потом начальник Рейтинга Лёха-Апач влез на стул и крикнул на весь зал: «Кто за полчаса не найдёт пяти способов ходить на ПУКН — уволим за служебное несоответствие». Зал покатился со смеху.
И в самом деле, блокировать доступ на сайты в интернет-компании, профессионально занимающейся поиском и рейтингом сайтов — глупее нельзя было придумать.
Ашманов. Жизнь внутри пузыря.
Кто не читал — рекомендую
Вы готовы к его ответу, что чтобы сэкономить эту же копеечку ему достаточно попросить админов закрыть фейсбук, аську и хабр, причем забесплатно, а? Ну и ужесточить контроль.Кстати, на такой ответ возникает встречный вопрос: почему это уже давно не сделано? Нет уверенности в эффективности и, вообще, безвредности? Тогда приём «парировать рискованными сомнительными идеями менее рискованные и менее сомнительные идеи» напоминает приём «говорить очевидную глупость с целью демонстрации права её говорить и вообще своего вышестоящего положения». Что сильно демотивирует.
Справедливости ради, кое-где на знакомых мне режимных заводах предложенные меры давно приняты. Но там контингент работников несколько особенный — программистов почти нет, а те, которые есть, приравнены к сисадминам и имеют доступ ко всему. В принципе я не против идеи подобных ограничений. Но они, по уму, должны сразу оговариваться ещё при собеседовании;-), чтоб чел знал на что идёт. А делать такие вещи внезапно посреди рабочего процесса равносильно пресловутой «смене коней на переправе». Я, конечно, не отрицаю право руководства быть «слоном» в собственной «посудной лавке», но пресловутое «снижение лояльности персонала» при таком раскладе — вещь ожидаемая…
Думаю, должны. Если некоторая доля рабочего времени программиста на что-то бесполезно теряется, то такая же доля их, как части трат на оплачиваемое рабочее время, тоже теряется.Расходы компании на программиста, включая ЕСН (30%) ~100000 рне должны быть включены в расчет, поскольку они будут уплачены вне зависимости от того, эффективно работает программист или нет.
Судя по времени компиляции — это С/С++? От SSD он не получит почти никакого ускорения. Только если до этого стоял полностью убитый диск 15-летней давности. Вот пример: www.fcenter.ru/online.shtml?articles/hardware/hdd/29573 Разница аж в целую секунду на 11 минут компиляции.
Нет… Это C#. ~300 проектов в решении. Винт, думаю, вполне себе старый и плоховатый. В общем, личный опыт — компилирование больших проектов ускоряется в несколько раз. Но я не проводил измерений.
Когда 8Гб было уже модно, а SSD еще не модно, проводил замеры с компиляцией на рам-диске. Действительно, разница получалась исчезающе маленькая.
все include файлы системных библиотек тоже были в ramdisk?
Действительно, по поводу Include, у нас при сборке еще over 9000 сторонних dll. А у меня позорные 8 Гб оперативки. Боюсь, все не влезет + Chrome 2 гига, студия 2 гига и прочее.
Для C/C++ важен сценарий с инкрементальной сборкой проекта. Здесь SSD может дать ускорение на порядок, в отличии от полной пересборки.
А вы замеры делали?
Я тестировал так:
Переносил Temp, файлы проекта и компилятор ( vc++ cmd line tools) на рам диск (даже не ssd) и компилировал Firefox (и в один поток и в 4). Разница была 30 минут и 29.5 (в один поток) и далее сохранялся паритет. Это было 3 года назад, когда я купил первый SSD. На SSD даже не тестировал после результатов. На компиляцию влияет процессор, его кэш и память в меньшей степени, но никак не диск. Диск важен в другом — это безусловно.
Я тестировал так:
Переносил Temp, файлы проекта и компилятор ( vc++ cmd line tools) на рам диск (даже не ssd) и компилировал Firefox (и в один поток и в 4). Разница была 30 минут и 29.5 (в один поток) и далее сохранялся паритет. Это было 3 года назад, когда я купил первый SSD. На SSD даже не тестировал после результатов. На компиляцию влияет процессор, его кэш и память в меньшей степени, но никак не диск. Диск важен в другом — это безусловно.
Переход на SSD увеличивает общую производительность труда программиста, но не так радикально как это хотят представить. Считать отдельно только компиляцию — это как-то глупо.
Если проект действительно большой и долго собирается — значит, не надо его собирать целиком, надо дробить на части, с тем чтобы перекомпилировать приходилось только небольшую часть.
В общем, SSD это скорее такая плюшка, как второй-третий монитор, а вовсе НЕ необходимость.
Если проект действительно большой и долго собирается — значит, не надо его собирать целиком, надо дробить на части, с тем чтобы перекомпилировать приходилось только небольшую часть.
В общем, SSD это скорее такая плюшка, как второй-третий монитор, а вовсе НЕ необходимость.
У программистов вообще нет необходимых вещей — дали им бюджетный нетбук, и пусть работают. Но каждая плюшка немного повышает производительность.
В небольших городах, где программисты получают по 15К в месяц, многие из инвестиций действительно не так выгодны, вместо них можно нанять дополнительного человека, что сильно повысит производительность. А вот в миллионниках, где зарплаты очень даже немаленькие, они почти всегда окупаются.
В небольших городах, где программисты получают по 15К в месяц, многие из инвестиций действительно не так выгодны, вместо них можно нанять дополнительного человека, что сильно повысит производительность. А вот в миллионниках, где зарплаты очень даже немаленькие, они почти всегда окупаются.
Четвертый монитор это плюшка. А доп. монитор и SSD это вещи без которых, невозможно представить, как жить.
>Считать отдельно только компиляцию — это как-то глупо.
Конечно, глупо. Добавьте сюда ускорение запуска ОС, IDE, поиска по проекту, копирования файлов, открытия документов — да почти всего. Вот тогда будет не глупо.
Когда ты на чём-то кликаешь и оно срабатывает мгновенно — это кайф, это мотивирует работать.
Конечно, глупо. Добавьте сюда ускорение запуска ОС, IDE, поиска по проекту, копирования файлов, открытия документов — да почти всего. Вот тогда будет не глупо.
Когда ты на чём-то кликаешь и оно срабатывает мгновенно — это кайф, это мотивирует работать.
Корень проблемы, насколько я понял, в том, что руководство не понимает зачем оно нужно. Пусть тогда они сначала себе поставят ssd, чтобы почувствовать насколько быстрее и комфортнее стало работать. Если и после этого они не захотят всем ssd установить, — то из конторы надо валить, такое руководство весьма далеко от IT, и вам, как девелоперу там ничего хорошего не светит.
Нарисуйте пару графиков. Начальство не любит читать тонны текста. Начальство любит чтобы диаграммка и вывод в 3 предложения.
В целом я согласен: SSD — это супер. Но вот экономическая сторона обоснования мне кажется притянутой «за уши».
Я не заметил ускорения своей работы после установки SSD. Да, компилировать стало 4 секунды, но на скорость думания и кодинга это не повлияло. Обычно когда надо скомпилировать, то это значит готова какая то логически законченная часть кода. И перед переходом к следующей подзадачи в любом случае будет некая пауза. То есть я не вижу доказательства, что время, которое тратится например на компиляцию могло бы быть потрачено с большей пользой.
В общем, я бы себе не купил SSD если бы решение принималось только на основе подобных экономических соображений, особенной учитываю мою сверхнизкую по столичным меркам зарплату.
Я не заметил ускорения своей работы после установки SSD. Да, компилировать стало 4 секунды, но на скорость думания и кодинга это не повлияло. Обычно когда надо скомпилировать, то это значит готова какая то логически законченная часть кода. И перед переходом к следующей подзадачи в любом случае будет некая пауза. То есть я не вижу доказательства, что время, которое тратится например на компиляцию могло бы быть потрачено с большей пользой.
В общем, я бы себе не купил SSD если бы решение принималось только на основе подобных экономических соображений, особенной учитываю мою сверхнизкую по столичным меркам зарплату.
SSD безусловно вещь в хозяйстве полезная, однако позволю себе не согласиться с доводом об ускорении компиляции.
Не всегда и не для всех.
Мы тоже думали, вот поставим SSD и ускорим компиляцию «хотя бы раза в два».
В нашем случае (проект на С\С++, сборка занимает больше 20 минут на i7) замена HDD на SSD дала 1-2% выигрыша.
В основном, за счёт ускорения линковки. Так получилось, потому что собирается один большой проект в один поток и распараллелить никак. Производительность упёрлась в частоту CPU.
Вывод: думать надо над архитектурой до, и рефакторингом после.
Не всегда и не для всех.
Мы тоже думали, вот поставим SSD и ускорим компиляцию «хотя бы раза в два».
В нашем случае (проект на С\С++, сборка занимает больше 20 минут на i7) замена HDD на SSD дала 1-2% выигрыша.
В основном, за счёт ускорения линковки. Так получилось, потому что собирается один большой проект в один поток и распараллелить никак. Производительность упёрлась в частоту CPU.
Вывод: думать надо над архитектурой до, и рефакторингом после.
IncrediBuild Вам в помощь.
Даже на одном компе, выигрыш пракитически линейный к кол-ву ядер, и от SSD сразу же пользу почуствуете.
Даже на одном компе, выигрыш пракитически линейный к кол-ву ядер, и от SSD сразу же пользу почуствуете.
Аналогично. Занимаюсь компиляцией пакетов программ для FreeBSD на SSD. Разницы по времени компиляции между SSD и HDD не заметил. Гораздо важнее частота процессора: чем она больше, тем заметнее уменьшение времени компиляции.
SSD — это как героин. Единожды попробовав его ты уже не представляешь — как можно обходиться без него. Для меня, в первую очень, SSD обеспечивает душевное спокойствие, т.к. с ним практически любая несложная операция происходит мгновенно. Ты не успеваешь об этом подумать, а оно уже произошло. Позволяет держать мозг в тонусе, не отвлекаясь на всякую мишуру.
Тут зашла речь про компиляцию, поэтому расскажу как я эту проблему решаю. Вообщем то, что нужно использовать SSD это и ежику понятно, и те кто их не используют просто не уважают себя и свое время. Но так или иначе, компиляция больших проектов является и CPU-bound и I/O-bound одновременно. Соответственно единственный вариант это масштабировать — это использовать больше ядер и больше дисков.
К сожалению «больше ядер» ждать от Intel не приходится, они застряли в дыре, поэтому даже расширение до пары Xeon-ов абсолютно бессмысленная задача. Ксеоны правда приходится использовать, и вот для чего… если коротко, все началось с наблюдения что виртуалки в некоторых случаях работают быстрее хостовой системы т.к. не замусорены всяким адским адом. Соответственно появилась такая идея, что если дать нескольким виртуалкам по маленькому SSD каждой и просто параллелить компиляцию и тестирование точно так же, как это делает MSBuild локально.
Ну а дальше все просто — нужна синхронизация файлов и scheduler который синхронизирует задачи и выполняет компиляцию, тестирование или что там надо. Естественно что в идеале хотелось бы процессную виртуализацию а-ля App-V, но такое руками не написать. Вообщем, на сегодняшний день этот проект, именуемый FreeSpace, так еще и не увидел свет — но как proof of concept он работает, хотя тем кто скупится на SSD наверное не понравится идея делать continuous/build на достаточно дорогом сервере с пачкой SSD и дорогой оперативкой. Что сказать, каждому своё.
К сожалению «больше ядер» ждать от Intel не приходится, они застряли в дыре, поэтому даже расширение до пары Xeon-ов абсолютно бессмысленная задача. Ксеоны правда приходится использовать, и вот для чего… если коротко, все началось с наблюдения что виртуалки в некоторых случаях работают быстрее хостовой системы т.к. не замусорены всяким адским адом. Соответственно появилась такая идея, что если дать нескольким виртуалкам по маленькому SSD каждой и просто параллелить компиляцию и тестирование точно так же, как это делает MSBuild локально.
Ну а дальше все просто — нужна синхронизация файлов и scheduler который синхронизирует задачи и выполняет компиляцию, тестирование или что там надо. Естественно что в идеале хотелось бы процессную виртуализацию а-ля App-V, но такое руками не написать. Вообщем, на сегодняшний день этот проект, именуемый FreeSpace, так еще и не увидел свет — но как proof of concept он работает, хотя тем кто скупится на SSD наверное не понравится идея делать continuous/build на достаточно дорогом сервере с пачкой SSD и дорогой оперативкой. Что сказать, каждому своё.
А почему интел «застрял в дыре»? Есть что почитать на эту тему? Единственная версия, которую видел я — это тот факт, что они вырвались сильно вперёд в десктопах по сравнению с AMD и поэтому на 3-4 года перекинули силы на мобильные платформы.
Спасибо! Отправил шефу, тема письма: «Настоятельно требую».
Пора уже создавать посты «основания НЕ покупать ССД для разработчиков», потому что стоят они настолько ничтожно мало, а прирост производительности настолько сногсшибательно огромен, что оснований выбрасывать деньги на древнюю технологию HDD для разработчиков в масштабе компании просто нет.
Я на позапрошлой работе делал проще. Если мне что-то надо было для рабочего компа — я шёл и покупал это за свои деньги. И мне пофиг было, одобряет начальство или нет. Вообще-то и начальству было глубоко пофиг на то чем я комп пичкаю, лишь бы работало. Так что в вашей ситуации купить себе в комп SSD за 4 тыщи при зарплате в 70 тыщ это самое простое и, возможно, правильное решение.
Время компиляции на ssd в рассчетах принято за ноль? Если нет, то «потеря потока» тоже одинаковая и ее можно сократить.
Впрочем, это не отменяет того факта, что с ssd жизнь становится попроще. Однако, время компиляции от жесткого диска зависит мало, современные ide все неплохо кэшируют. Процессор — вот тонкое место.
Требую статью на тему «обосноваие необходимости билд-фермы для разработчиков» :)
Впрочем, это не отменяет того факта, что с ssd жизнь становится попроще. Однако, время компиляции от жесткого диска зависит мало, современные ide все неплохо кэшируют. Процессор — вот тонкое место.
Требую статью на тему «обосноваие необходимости билд-фермы для разработчиков» :)
НЛО прилетело и опубликовало эту надпись здесь
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
SSD для разработчиков возможен массово лишь как такой буффер, на котором данные:
1. не хранятся
2. никто не расстроется от замены
Оптимальное сочетание офисное это:
SSD-20
Raid 1/0/10/5/6 — x 2(3) HDD 1ТБ
P.S. очень много маленьких файлов убьют SSD быстрее, так что выбирайте правильную ФС — btrfs,raser4 и т.д., но никак не Ext3
> никто не расстроится от замены.
dvcs же… У меня полная рабочая среда разворачивается за четыре часа из корпоративной сети, причем две трети времени занимает сборка мастера, одну треть — клонирование репозитория, а паралельно можно установить и настроить идешку, браузер, мессенджер, etc…
dvcs же… У меня полная рабочая среда разворачивается за четыре часа из корпоративной сети, причем две трети времени занимает сборка мастера, одну треть — клонирование репозитория, а паралельно можно установить и настроить идешку, браузер, мессенджер, etc…
Вот в интел то дураки сидят, с их 5-летней гарантией на ssd.
Современные ssd-диски уже вплотную приблизились к hdd по долговечности. Самое интересное что начальство, менеджеров как раз таки уговаривать не долго, лично я несколько раз сталкивался с тем что разработчики/сисадмины начитавшись винрарных статей про короткий цикл жизни ссд, категорически не желали его ставить ни на сервера, ни на рабочие компы.
Современные ssd-диски уже вплотную приблизились к hdd по долговечности. Самое интересное что начальство, менеджеров как раз таки уговаривать не долго, лично я несколько раз сталкивался с тем что разработчики/сисадмины начитавшись винрарных статей про короткий цикл жизни ссд, категорически не желали его ставить ни на сервера, ни на рабочие компы.
Вопрос автору: 10 минут, которые Вы указали это 1) каждый простой build после изменения даже одного файла, 2) clean+build, или вообще, 3) configure && make?
Конечно, если в Вашем проекте уходит по 10 минут на build после каждого изменения, что бы просто запустить на отладку, то это проблема и тогда, действительно, нужно SSD и/или радикально увеличивать объем памяти под дисковый кеш.
Но если это ситуации 2 или 3, то имхо покупка SSD неоправдана. Мне приходилось работать в проектах, полная пересборка которых занимала несколько часов, а прогон тестов несколько суток. Но это же не значит, что я, как разработчик должен это делать каждый раз, когда запускаю отладку. В процессе отладки, как правило, перекомпилируются несколько файлов исходных текстов, число которых от сборки к сборке редко превышает пары десятков. В результате таких правок приходится, как правило, пересобирать один модуль (dll, jar или что у Вас там). У меня, даже в очень больших проектах это занимает меньше минуты. У меня обычно деплой и старт приложения занимает больше, но в моем случае это при помощи SSD не ускорить :)
Исключения: те случаи, когда приходится отлаживать сборочный процесс, включая сборку инсталяторов, дистрибутивов. :)))
Конечно, если в Вашем проекте уходит по 10 минут на build после каждого изменения, что бы просто запустить на отладку, то это проблема и тогда, действительно, нужно SSD и/или радикально увеличивать объем памяти под дисковый кеш.
Но если это ситуации 2 или 3, то имхо покупка SSD неоправдана. Мне приходилось работать в проектах, полная пересборка которых занимала несколько часов, а прогон тестов несколько суток. Но это же не значит, что я, как разработчик должен это делать каждый раз, когда запускаю отладку. В процессе отладки, как правило, перекомпилируются несколько файлов исходных текстов, число которых от сборки к сборке редко превышает пары десятков. В результате таких правок приходится, как правило, пересобирать один модуль (dll, jar или что у Вас там). У меня, даже в очень больших проектах это занимает меньше минуты. У меня обычно деплой и старт приложения занимает больше, но в моем случае это при помощи SSD не ускорить :)
Исключения: те случаи, когда приходится отлаживать сборочный процесс, включая сборку инсталяторов, дистрибутивов. :)))
Несколько напрягает после правки допустим 6-10 проектов, все 6 проектов, еще и в правильном порядке по очереди сбилдить. В любом случае, все способы ускорения имеют право быть. Почему много проектов? Разнесено все, что только можно. Интерфейсы, реализации, клиенты этих реализаций. Один новый метод — изменение интерфейса, тройки реализаций и пары клиентов.
Приятней нажать один раз на солюшене — build, при том что студия сама определять должна, что не надо билдить вообще.
Приятней нажать один раз на солюшене — build, при том что студия сама определять должна, что не надо билдить вообще.
Ну это естественно, что должна быть одна кнопка. не важно сделана она в виде F5 или 'make' (как правило, стрелка вверх, enter в консоли). И естественно, что если не было изменений ни в одном файле по дереву целей, то ни один модуль и не должен пересобираться и ни один класс не должен компилироваться. Вопрос и был в том какой вариант занимает много времени типа 'make clean && make' или просто 'make' (не важно как оно в Вашей конкретной IDE/рабочей среде называется).
Ну ок, я Вас понял, то есть, у Вас случай — build, а не clean&&build.
Описанный Вами случай — изменение интерфейса взаимодействия между модулями действительно может потребовать существенных затрат времени на сборку пока интерфейсы еще не устоялись и часто меняются. Особенно для С++. C# и Java в этом смысле гораздо быстрее.
Простите, но 10 минут мне кажутся преувеличенными. В Ваших 6-ти проектах будут реально _компилироваться_ пара десятков файлов. А поскольку, судя по Вашему описанию, эти модули невелики, то мне как-то не верится, что линковка каждого из них будет занимать больше одной минуты. У Вас это реально занимает 10 минут? Может все таки не HDD является бутылочным горлышком?
Ну ок, я Вас понял, то есть, у Вас случай — build, а не clean&&build.
Описанный Вами случай — изменение интерфейса взаимодействия между модулями действительно может потребовать существенных затрат времени на сборку пока интерфейсы еще не устоялись и часто меняются. Особенно для С++. C# и Java в этом смысле гораздо быстрее.
Простите, но 10 минут мне кажутся преувеличенными. В Ваших 6-ти проектах будут реально _компилироваться_ пара десятков файлов. А поскольку, судя по Вашему описанию, эти модули невелики, то мне как-то не верится, что линковка каждого из них будет занимать больше одной минуты. У Вас это реально занимает 10 минут? Может все таки не HDD является бутылочным горлышком?
Возмем сферическую компанию в Москве из 10 человек. Всем купить SSD стоит 4к. Это стоимость двух недель работы одного программиста. За две недели можно прикрутить инкрементальную сборку. Эффект будет больше, чем от SSD.
Допустим, я откорректировал код, и хочу сразу начать его дебажить на локальной машине. Вы говорите о билд сервере? Он есть, он он не локальный. Или я не правильно понял?
Сборки сборками. Но когда у меня на рабочем компе с топовой конфигурацией, но обычными хардами — холодный запуск браузера тратится больше 10 секунд, старт IDE больше минуты. Дома бюджетный ноут, в котором я поменял хард на ssd, на теже действия уходят считанные секунды. Посмотреть аннотейты, проиндексировать весь проект, распаковать архив — все это мелочи которые на компе с ссд проходят настолько быстро, что потом засев обратно на hdd чувствуешь себя слоупоком.
Так что ссд я бы по хорошему ставил всем, вообще всем кто работает за компом
Так что ссд я бы по хорошему ставил всем, вообще всем кто работает за компом
Помню, в 2010-11 разрабатывал под XP, и начальство не хотело ставить дополнительные 2GiB памяти, мотивируя тем, что XP не поддерживает больше 3 (а было 2). Потом поставили, проект стал собираться быстро вместо 10 минут…
Думаю, хорошая тема — разместить на 20-гиговом SLC SSD swap-файл.
Работал с солюшеном, о котором говорит автор (300 проектов). Пробовал его собирать целиком в оперативной памяти (на машине 16 Гб, делал рамдиск, на который влезал собранный солюшен — около 5-6 Гб). Значительного прироста не заметил, что показалось странным. Возможно, компилятор генерирует временные файлы, которые записываются и читаются с жесткого диска (не уверен). Также пробовал его собирать и на SSD, тоже значительного прироста не заметил. Но если бывшим коллегам поставят SSD, буду рад :)
P.S. С автором, похоже, немного разминулись по времени :)
P.S. С автором, похоже, немного разминулись по времени :)
В статье упоминается о компиляции. А проводились ли реальные тесты, показывающие реальное ускорение компиляции? У меня небольшой проект С++ (~80файлов) + boost. Я хотоел ускрить компиляцию нашел рекомендацию использовать RamDrive. Какого-либо ощутимого ускорения не получил. Вообще! ОСь хорошо кеширует. А вот замена процессора ускорила компиляцию раза в полтора. И это уже было ощутимо. Ускорял инлайнингом cpp файлов, рефакторингом.
Даст ли SSD волшебные «ощутимые 10 раз»?
Я не говорю о том, когда нужно быстро запускать виртуальные машины, тяжелые приложения.
Даст ли SSD волшебные «ощутимые 10 раз»?
Я не говорю о том, когда нужно быстро запускать виртуальные машины, тяжелые приложения.
Я еще не получил SSD, чтобы провести тест. Но коммент выше выбил меня из колеи…
Надо запретить еще чай, печеньки и туалет закрыть на замок… На этом столько теряют времени, да еще и издержки! :)
Меня ещё в 2004 удивил тот факт, что 15-25% рабочего времени тратятся на ожидание реакции тормозной системы (Windows XP на 256GiB) при том, что стоимость компьютера сопоставима с размером месячной зарплаты, и начальство по этому поводу ничего не делает.
Производительность компиляции и тестов гораздо эффективнее повышает вынос этой задачи на сервера непрерывной интеграции. Остается компиляция для отладки, здесь да, SSD поможет.
Более бюджетный вариант для пользователей Linux.
Создаём raid1, состоящий из файла на hdd и ram-диска (или файла на tmpfs). Такое легко провернуть средствами btrfs. В результате — скорость чтения в разы превышает скорость любого ssd.
Один недостаток: после каждой перезагрузки придётся восстанавливать ram-зеркало. Но для пары-тройки гигабайт данных это дело нескольких секунд.
Создаём raid1, состоящий из файла на hdd и ram-диска (или файла на tmpfs). Такое легко провернуть средствами btrfs. В результате — скорость чтения в разы превышает скорость любого ssd.
Один недостаток: после каждой перезагрузки придётся восстанавливать ram-зеркало. Но для пары-тройки гигабайт данных это дело нескольких секунд.
С помощью SSD оживил слегка устаревший домашний ноут. Благо, в нем был отсек для дополнительного жесткого диска.
Правда, до конца не верю в сохранность данных, регулярно делаю бекапы и профиль пользователя держу на HDD.
Правда, до конца не верю в сохранность данных, регулярно делаю бекапы и профиль пользователя держу на HDD.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Обоснование необходимости приобретения SSD для разработчиков