Comments 71
Закон Амдала — общее время вычисления зависит от доли вычислений которые можно сделать только последовательно (a) и числа вычислительных узлов (p). Выражение (1-a) это доля вычислений которые можно делать параллельно.
Одна из задач многозадачности — использовать все имеющиеся ресурсы для выполнения задачи. Поэтому задача 1 это как само собой разумеющееся.
Задача 2 может быть решена запуском и самой программы и программы тестирования на другом (отличном от пользовательского) рабочем столе.
Задача 3 не решится распаралеливанием, если канал в интернет имеет ограничение по пропускной способности, тут надо либо умерять аппетиты, либо выставлять приоритеты. :)
Задача 2 может быть решена запуском и самой программы и программы тестирования на другом (отличном от пользовательского) рабочем столе.
Задача 3 не решится распаралеливанием, если канал в интернет имеет ограничение по пропускной способности, тут надо либо умерять аппетиты, либо выставлять приоритеты. :)
>> Одна из задач многозадачности — использовать все имеющиеся ресурсы для выполнения задачи. Поэтому задача 1 это как само собой разумеющееся.
Согласен. Однако есть нюанс. Одна из задач многозадачности — это чтобы пользователь не ждал завершения программы, а мог делать на машине что-то еще. Так что тут приходится выбирать, что важнее пользователю. Быстрее получить результат, или делать что-то еще (другое) на машине.
>> Задача 2 может быть решена запуском и самой программы и программы тестирования на другом (отличном от пользовательского) рабочем столе.
Опять же согласен, но инструментарий пока не позволяет делать это легко. Ясно хотя, что проблема решаема хотя бы в принципе. «В принципе» — это значит, что наверняка есть инструменты/среды уже сейчас, которые это позволяют.
Согласен. Однако есть нюанс. Одна из задач многозадачности — это чтобы пользователь не ждал завершения программы, а мог делать на машине что-то еще. Так что тут приходится выбирать, что важнее пользователю. Быстрее получить результат, или делать что-то еще (другое) на машине.
>> Задача 2 может быть решена запуском и самой программы и программы тестирования на другом (отличном от пользовательского) рабочем столе.
Опять же согласен, но инструментарий пока не позволяет делать это легко. Ясно хотя, что проблема решаема хотя бы в принципе. «В принципе» — это значит, что наверняка есть инструменты/среды уже сейчас, которые это позволяют.
Задача 1 — легко решается постановкой пониженного приоритета. Увеличение времени на 1%-5% не заметно (если ни чего ресурсоемкого при этом не делать, а голова и так будет забита уже другой работой). Также можно ее выполнить, поставив специальный сервер тестирования (или что-то вроде облачных вычислений применить, с объединением всех свободных ресурсов сети в 1 мега мозг).
Задача 2 — если на машине и так 4 ядра, то 2 можно отдать виртуальной машине (на время тестирования). Или опять же отдельным сервером. И установкой туда виртуальных машин, для каждого пользователя — своя. Все одновременно едва ли будут запускаться, поэтому должно хватить.
Задача 2 — если на машине и так 4 ядра, то 2 можно отдать виртуальной машине (на время тестирования). Или опять же отдельным сервером. И установкой туда виртуальных машин, для каждого пользователя — своя. Все одновременно едва ли будут запускаться, поэтому должно хватить.
>> Задача 1 — легко решается…
Честно говоря, не решается. Мы недавно так и сделали — стали приоритети пониженный использовать. Получилось значительно лучше, но если загружено 4 ядра и 8 гигабайт памяти (как у нас), то работать на этой же машине некомфортно. Понятно, что это экстремальный случай. Понятно, что нужен выделенный сервер. Это все есть.
Я пытался выразить в посте вот какую мысль. Пользователю говорят: «Вот смотри — многозадачность тебе даем и счастье вместе с ней!». А не получается такого. Пользователь ждет пока компьютер отработает. И тогда оказывается, что счастье вместе с многозадачностью не пришло.
Кто-то скажет, что я странного хочу даже на больших кластерах надо ждать, пока все досчитается до конца. Это тоже понятно. Поэтому призыв в конце поста и получился такой: «Позволяйте пользователю ваших программ работать с данным до того, как подсчитан окончательный результат».
Вот в Visual Studio сделано хорошо. Открываешь проект и уже можешь с ним работать сразу же, хотя пока там IntelliSence достроит свои базы…
Честно говоря, не решается. Мы недавно так и сделали — стали приоритети пониженный использовать. Получилось значительно лучше, но если загружено 4 ядра и 8 гигабайт памяти (как у нас), то работать на этой же машине некомфортно. Понятно, что это экстремальный случай. Понятно, что нужен выделенный сервер. Это все есть.
Я пытался выразить в посте вот какую мысль. Пользователю говорят: «Вот смотри — многозадачность тебе даем и счастье вместе с ней!». А не получается такого. Пользователь ждет пока компьютер отработает. И тогда оказывается, что счастье вместе с многозадачностью не пришло.
Кто-то скажет, что я странного хочу даже на больших кластерах надо ждать, пока все досчитается до конца. Это тоже понятно. Поэтому призыв в конце поста и получился такой: «Позволяйте пользователю ваших программ работать с данным до того, как подсчитан окончательный результат».
Вот в Visual Studio сделано хорошо. Открываешь проект и уже можешь с ним работать сразу же, хотя пока там IntelliSence достроит свои базы…
Пользователю говорят: «Вот смотри — многозадачность тебе даем и счастье вместе с ней!». А не получается такого. Пользователь ждет пока компьютер отработает. И тогда оказывается, что счастье вместе с многозадачностью не пришло.Не знаю. Лично мне счастье многозадачность принесла. Тормоза (какие раньше на 1 ядерной системе были) теперь наблюдаются только при нехватке памяти (у меня машинка поскромнее, чем 4ядра и 8GB), что впрочем, случается не так часто (только при серьезной работе с БД).
Думаю, проблема не в том, что многоядерность не принесла ожидаемых результатов. Проблема в том, что требования пользователей возрастали вместе с количеством ядер.
>> пользователей возрастали вместе с количеством ядер
Уверен, что это основная причина моих… ну не то чтобы разочарований, но причина этого поста — это уж точно. Спасибо за сформулирвоанную мысль.
Ведь конечно же то, что сейчас у меня «тормозит» на 4ядра/8гигабайт, раньше было просто немыслимо запустить на одноядерной машине с 512 мегабайтами памяти.
А поскольку человек всегда хочет большего, то и получается некоторая «неудовлетворенность», выраженная в данном посте.
Уверен, что это основная причина моих… ну не то чтобы разочарований, но причина этого поста — это уж точно. Спасибо за сформулирвоанную мысль.
Ведь конечно же то, что сейчас у меня «тормозит» на 4ядра/8гигабайт, раньше было просто немыслимо запустить на одноядерной машине с 512 мегабайтами памяти.
А поскольку человек всегда хочет большего, то и получается некоторая «неудовлетворенность», выраженная в данном посте.
А почему для задачи 2 нельзя использовать виртуальную машину?
Таким образом, пользователь (программист, запустивший тесты) сидит и ждет завершения работы. . Что за глупость? Если пользователь в это время будет что-то печатать в редакторе, тесты сильно затормозятся? Не верю. А понижение приоритета не замедляет тесты, оно всего лишь определяет кому первому достанутся процессорные тики.
Пользователь сидит и ждет (завершения тестов) потому, что переключение мозга на другую задачу намного более сложная вещь, чем переключение процессора на другую задачу. Пользователю нужно в зависимости от результата (тестов) сделать то или иное действие.
Во-первых, нет. Всегда есть куча мелких дел, которые можно делать параллельно. Не хочется отрывать взгляд от тестов? Пустить их на одном мониторе, работать на другом. Во-вторых, это проблема уже не компьютера, а человека, ne? Лично я всегда занят хотя бы 1-2 делом одновременно, именно на случаи, когда одно начинает «работать без моего участия».
Система тестирования позволяет, конечно же, использовать либо часть ядер, либо использовать пониженный приоритет процесса, чтобы все не тормозило во время тестирования. Однако поскольку результат тестов (прошли/не прошли) хочется узнать быстрее, то лучше загрузить машину на полную и не беспокоить ее. Таким образом, пользователь (программист, запустивший тесты) сидит и ждет завершения работы.
И при чем тут многозадачность, если в данном примере проблема прежде всего в пользователе? Ведь можно освободить 1 ядро для выполнения других задач. Просто нужно верно распределять свое время и задачи.
Я думаю дело в том, что термин «многозадачность» часто понимают (как и я в этой статье) в некоем широком смысле, а стоило бы только в техническом узком.
Если пользователь ждет завершения тестов, то с точки зрения пользователя компьютер выполняет одну задачу. Хотя с точки зрения компьютера многозадачность (многопоточность) используется вовсю.
Согласитесь с тем, что в этом случае пользователь и компьютер «понимают» под многозадачностью разное?
Если пользователь ждет завершения тестов, то с точки зрения пользователя компьютер выполняет одну задачу. Хотя с точки зрения компьютера многозадачность (многопоточность) используется вовсю.
Согласитесь с тем, что в этом случае пользователь и компьютер «понимают» под многозадачностью разное?
Так может, это виновата однозадачность пользователя, что он только 1 задачей заниматься может?
Угу. При этом пить чай за многозадачность не считается, а вот переключиться на тест с кодом и дописать пару десятков строк — считается. Чем бы человек не страдал, лишь бы не работать…
Согласен с тем, что виновато восприятие человека.
Но вот про многозадачный чай не соглашусь. В советских НИИ по слухам чай «вырубал» из трудого процесса на часы даже целые отделы!
Но вот про многозадачный чай не соглашусь. В советских НИИ по слухам чай «вырубал» из трудого процесса на часы даже целые отделы!
Чтобы пить чай загружать мозг не нужно (если не считать процесс его готовки).
А вот дописать десяток строк — это уже не в «фоновом» режиме делается. На самом деле я считаю чай в этом вопросе скорее +, чем —. Т.к. на чай отрываешься в те моменты, когда ты не уверен в том, что сейчас собираешься писать и надо немного обмозговать. А отрываться просто так кажется неправильным.
К тому же часто умная мысль приходит если отвлечься от основной задачи (скажем, пойти чая сделать), а не пытаться, сидя на месте, усиленно думать.
А вот дописать десяток строк — это уже не в «фоновом» режиме делается. На самом деле я считаю чай в этом вопросе скорее +, чем —. Т.к. на чай отрываешься в те моменты, когда ты не уверен в том, что сейчас собираешься писать и надо немного обмозговать. А отрываться просто так кажется неправильным.
К тому же часто умная мысль приходит если отвлечься от основной задачи (скажем, пойти чая сделать), а не пытаться, сидя на месте, усиленно думать.
Задача 2 запросто решается с помощью multiseat
По поводу тестов проектов на C++.
Я не хочу принижать достоинств C++, сам его использую в работе каждодневно. Но именно этот язык является проблемой медлительности, как сборки тестов, так и просто длительной сборки всего приложения. Когда окунешся в разработку на других, более современных языках, то разница становится настолько разительной, что возвращаться к С++ не хочется. Ведь то, что на С++ компилится 15-30 минут, на других языках компилится около минуты и меньше. И, к сожалению, никто пока не предложил достойной альтернативы, чтобы и в нативный код компилило, и быстро, и синтаксис был хотя бы не хуже C++, и средства разработки достойные. Вот так и живем с тем, что есть, а не с тем, что могло бы быть. И одной многозадачностью здесь не справиться.
Я не хочу принижать достоинств C++, сам его использую в работе каждодневно. Но именно этот язык является проблемой медлительности, как сборки тестов, так и просто длительной сборки всего приложения. Когда окунешся в разработку на других, более современных языках, то разница становится настолько разительной, что возвращаться к С++ не хочется. Ведь то, что на С++ компилится 15-30 минут, на других языках компилится около минуты и меньше. И, к сожалению, никто пока не предложил достойной альтернативы, чтобы и в нативный код компилило, и быстро, и синтаксис был хотя бы не хуже C++, и средства разработки достойные. Вот так и живем с тем, что есть, а не с тем, что могло бы быть. И одной многозадачностью здесь не справиться.
Это не проблема C++, это проблема конкретных проектов.
Если использовать precomiled headers и принципы инверсии зависимостей и отделения интерфейса, то время повторной компиляции будет пренебрежимо мало.
Если использовать precomiled headers и принципы инверсии зависимостей и отделения интерфейса, то время повторной компиляции будет пренебрежимо мало.
Ну почему же? Известно ведь, что компиляторы pascal быстрее c++ работают, к примеру. И среднем C++-проекты компилируются дольше. Так что комментарий, на мой взгляд, вполне справедлив.
полные — да. а так cmake/make только измененные и связи пересобирают.
Прекомпилированные файлы заголовков являются аналогом скомпилированных модулей интерфейса для Паскаля. Так что компилирование происходит со сравнимой скоростью, если не включать всевозможную оптимизацию.
На деле самой тяжёлой фазой является линковка, но и здесь можно использовать так называемую инкрементальную линковку.
На деле самой тяжёлой фазой является линковка, но и здесь можно использовать так называемую инкрементальную линковку.
Возможно. Но не всегда есть возможность использовать «precomiled headers», сам давно их не использую, потому что раньше бывали глюки с тем что что-то недоперекомпилилось, сейчас даже не знаю — стало ли лучше с этим.
И это проблема C++, дело в том что другим языкам «танцы с бубном» не нужны, там хидеры только локально подключаются, а проблема ведь именно в этом.
И это проблема C++, дело в том что другим языкам «танцы с бубном» не нужны, там хидеры только локально подключаются, а проблема ведь именно в этом.
опять-таки, крайне рекомендую почитать статьи из серии S.O.L.I.D.
Например, blog.byndyu.ru/2009/12/blog-post.html
При следовании этому подходу, в частности, изменения обычно затрагивают проект так, что перекомпилировать и распространять требуется обычно минимум кода.
Например, blog.byndyu.ru/2009/12/blog-post.html
При следовании этому подходу, в частности, изменения обычно затрагивают проект так, что перекомпилировать и распространять требуется обычно минимум кода.
Есть половинчатое решение — Clang(++). У них компиляция выполняется в 2-2.5 раза быстрее, чем на gcc.
UFO just landed and posted this here
Виртуальная машина поможет вам сократить потребление чая
Если убрать слова «при разработке собственных программ», то получилась хорошая статья для блондинок, эмоциональная такая.
1. у нас долго мучились, в итоге был куплен двухпроцессорный (ксеоны) сервер. во-первых, это позволило разработчикам проводить очень тяжелые тесты (с большим количеством потребляемой оперативной памяти), во-вторых, компьютер человека, который у нас отвечает за проведение расчетов, документацию и тестирования освободился для первых двух занятий, в-третьих, когда возникает необходимость выполнить для клиентов срочный расчет, у нас всегда под рукой этот крайний вариант. отдельная машина для тестирования — крайне полезная штука.
У нас система тестирования проверяет множество различных моделей расчетных (кстати, была замечательная статья о тестировании научных программ на хабре совсем недавно), т.е. решается множество разных задач, по несколько на определенную функциональность. Естественно результаты можно посмотреть отдельно для каждого теста. Сразу видно, где проблема и стоит ли продолжать. Часто проблема бывает локальна, можно ей заниматься, пока продолжается тестирование. А для продолжения тестирования и одновременного решения проблемы нужна отдельная машина. Все же я считаю, что для тестирования просто необходима отдельная машина, не важно, занимается тестированием специально обученный человек или каждый разработчик.
2. А нельзя для этого использовать машину с серверной системой, подключаться к ней под разными логинами через rdp и запускать любое удобное число визуальных тестов?
Кстати, а какой системой пользуетесь? Собственная разработка или какой-то известный продукт?
Ну а вообще, Ваша статья о многозадачности, но не о процессорной в частности, а вообще. И тут можно об очень многом поразмыслить, понаписать, а потом отправить в «учись работать». В общем при чем тут интел?
У нас система тестирования проверяет множество различных моделей расчетных (кстати, была замечательная статья о тестировании научных программ на хабре совсем недавно), т.е. решается множество разных задач, по несколько на определенную функциональность. Естественно результаты можно посмотреть отдельно для каждого теста. Сразу видно, где проблема и стоит ли продолжать. Часто проблема бывает локальна, можно ей заниматься, пока продолжается тестирование. А для продолжения тестирования и одновременного решения проблемы нужна отдельная машина. Все же я считаю, что для тестирования просто необходима отдельная машина, не важно, занимается тестированием специально обученный человек или каждый разработчик.
2. А нельзя для этого использовать машину с серверной системой, подключаться к ней под разными логинами через rdp и запускать любое удобное число визуальных тестов?
Кстати, а какой системой пользуетесь? Собственная разработка или какой-то известный продукт?
Ну а вообще, Ваша статья о многозадачности, но не о процессорной в частности, а вообще. И тут можно об очень многом поразмыслить, понаписать, а потом отправить в «учись работать». В общем при чем тут интел?
Я промахнулся комментарием. Вот это Вам ответ был.
>> 1.
Спасибо за подробный комментарий, сразу видно, что нашел понимающего читателя :-). Сайт своего продукта покажете? Интересно.
>> 2. А нельзя…
Можно. И через rdp делаем. И на другой машине делаем. По-разному делаем.
>> Кстати, а какой системой пользуетесь?
Visual Studio 2010. В новой версии они встроили неплохую систему тестирования UI.
>> В общем при чем тут интел?
Ах ты ж. Вы меня подловили. Думал что в этот раз обойдется без этого традиционного вопроса :-). Что-то какой пост не посмотришь (из этого блога) в последнее время, обязательно где-нибудь да всплывет «а причем здесь...».
Отвечаю на вопрос «причем». Данный пост навеян разными мыслями о много- (поточности/задачности). Эти мысли испускает (на Хабре) Интел. Соответственно и здесь же их наиоблее удобно обсудить, так как люди понимают о чем речь.
Спасибо за подробный комментарий, сразу видно, что нашел понимающего читателя :-). Сайт своего продукта покажете? Интересно.
>> 2. А нельзя…
Можно. И через rdp делаем. И на другой машине делаем. По-разному делаем.
>> Кстати, а какой системой пользуетесь?
Visual Studio 2010. В новой версии они встроили неплохую систему тестирования UI.
>> В общем при чем тут интел?
Ах ты ж. Вы меня подловили. Думал что в этот раз обойдется без этого традиционного вопроса :-). Что-то какой пост не посмотришь (из этого блога) в последнее время, обязательно где-нибудь да всплывет «а причем здесь...».
Отвечаю на вопрос «причем». Данный пост навеян разными мыслями о много- (поточности/задачности). Эти мысли испускает (на Хабре) Интел. Соответственно и здесь же их наиоблее удобно обсудить, так как люди понимают о чем речь.
Прошу прощения за старый комикс, но как альтернатива чаю:
UFO just landed and posted this here
вспоминается анекдот
— Папа, а что такое многозадачность?
— Ну, это когда компьютер позволяет тебе делать несколько дел одновременно
— Покажешь?
— Сейчас, только дискету доформатирую…
— Папа, а что такое многозадачность?
— Ну, это когда компьютер позволяет тебе делать несколько дел одновременно
— Покажешь?
— Сейчас, только дискету доформатирую…
По пункту номер 3.
Торренты (может немного в другом ракурсе) — чем не распараллеливание загрузки. Правда опять упирается в канал и количество раздающих.
Торренты (может немного в другом ракурсе) — чем не распараллеливание загрузки. Правда опять упирается в канал и количество раздающих.
насчер сети я не согласен. разве торренты не решили это проблему? в итоге все упирается только в толшину канала вашего провайдера и сумму скоростей сидеров
> пользователь (программист, запустивший тесты) сидит и ждет завершения работы.
Ага, программист может на 3 вещи можно смотреть бесконечно — на огонь, на воду и на прогресс бар…
А большие долгие тесты — так их по ночам пускать надо. Я вот компьютер рабочий уже много лет вообще не выключаю.
Ага, программист может на 3 вещи можно смотреть бесконечно — на огонь, на воду и на прогресс бар…
А большие долгие тесты — так их по ночам пускать надо. Я вот компьютер рабочий уже много лет вообще не выключаю.
Что-то я не понял какое утверждение вы опровергаете?
Что несмотря на повышающуюся производительность компьютеров всё равно необходимо ждать завершения работы программ?
Что несмотря на повышающуюся производительность компьютеров всё равно необходимо ждать завершения работы программ?
Несмотря на повышающуюся производительность, пользователь все-равно «тупит» перед компьютером (ожидая результатов). И хорошо бы (программистам) делать так, чтобы «ожидал результатов» пользователь меньше.
Раньше пользователь тупил два часа чтобы решилось СЛАУ из 20 переменных.
А теперь он тупит по пол часа, чтобы строилась визуализация с тенями, объёмным светом, туманом, шерстью и другими фишками.
Оптимизация — это всегда плюс, и всегда чем меньше времени работает программа тем лучше, но не надо только говорить о том, что ожидания человечества обмануты, и «что пользователь все-равно «тупит» перед компьютером».
Чем быстрее работает не тривиальная программа, тем дороже она обошлась в разработке. Причём работающие мгновенно стоят ∞ долларов. Соответственно, компания, решая оптимизационную задачу находит точку в которой максимизируется прибыль.
То есть, не тривиальные программы всегда будут чуть-чуть притормаживать. Меняется не скорость, меняется круг решаемых задач.
А теперь он тупит по пол часа, чтобы строилась визуализация с тенями, объёмным светом, туманом, шерстью и другими фишками.
Оптимизация — это всегда плюс, и всегда чем меньше времени работает программа тем лучше, но не надо только говорить о том, что ожидания человечества обмануты, и «что пользователь все-равно «тупит» перед компьютером».
Чем быстрее работает не тривиальная программа, тем дороже она обошлась в разработке. Причём работающие мгновенно стоят ∞ долларов. Соответственно, компания, решая оптимизационную задачу находит точку в которой максимизируется прибыль.
То есть, не тривиальные программы всегда будут чуть-чуть притормаживать. Меняется не скорость, меняется круг решаемых задач.
Так я не понял о чем статья? Многозадачность — возможность запускать несколько задач одновременно. Многоядерность — прирост общей производительности системы при запуске нескольких задач одновременно. Но ни то ни другое не означает что ресурсы системы становятся резиновыми.
Отдать все ресурсы одной задаче, а потом жаловатся что этих ресурсов не осталось и дескать многозадачность в этом виновата — глупо.
Отдать все ресурсы одной задаче, а потом жаловатся что этих ресурсов не осталось и дескать многозадачность в этом виновата — глупо.
извините… но вы-же оцениваете не распараллеленные алгоритмы…
кто сказал, что ваш тест в №1 правильно написан?
по №3 — сравнивайте ftp vs torrents хотя-бы
кто сказал, что ваш тест в №1 правильно написан?
по №3 — сравнивайте ftp vs torrents хотя-бы
UFO just landed and posted this here
Есть два типа людей. Одни хнычат бесконечно, другие — решают задачи.
1) тесты должны быть как можно легче. Такая большая штука как Python — и та тестируется минут 15 от силы. При этом тесты ооооооооооочень хорошо распараллеливаются на многоядерных машинах). Учитывая саму парадигму что каждый тест не должен зависеть от другого. Да и в общем-то никто не заставляет сидеть и глазеть на запущенные тесты, ни одна многоядерная машина не «встанет» даже если все ядра использовать на «100%». Если только в встанет в iowait, но это уже совсем идиотские тесты значит
2) тестирование UI должно быть на отдельной машине. Более того — на отдельнЫХ машинАХ. Чаще всего это 1 тачка с кучей виртуалок. Если же вы девелопите только под винду — тогда все вопросы в п1 становятся ясны =)
3) 25мбит — я уже и забыл что такое «ждать».
1) тесты должны быть как можно легче. Такая большая штука как Python — и та тестируется минут 15 от силы. При этом тесты ооооооооооочень хорошо распараллеливаются на многоядерных машинах). Учитывая саму парадигму что каждый тест не должен зависеть от другого. Да и в общем-то никто не заставляет сидеть и глазеть на запущенные тесты, ни одна многоядерная машина не «встанет» даже если все ядра использовать на «100%». Если только в встанет в iowait, но это уже совсем идиотские тесты значит
2) тестирование UI должно быть на отдельной машине. Более того — на отдельнЫХ машинАХ. Чаще всего это 1 тачка с кучей виртуалок. Если же вы девелопите только под винду — тогда все вопросы в п1 становятся ясны =)
3) 25мбит — я уже и забыл что такое «ждать».
Не все умеют писать маленькие красивые тесты. Нужно сказать «Молодцы!» за то, что они вообще есть. :-)
по первому пункту: habrahabr.ru/blogs/development/93570/ в этой статье очень здорово описано, почему и когда тесты могут длиться больше 15 минут. И, к сожалению, речь здесь начинает идти уже даже не о полутора часах. Но это так, к примеру.
Замечание про «не встающую машину» тоже справедливо. Лично я в случае необходимости загрузить все ядра даже просто понижаю приоритет процесса. Потеря в производительности не велика при этом, зато текстовый редактор не тормозит ничуть :)
Замечание про «не встающую машину» тоже справедливо. Лично я в случае необходимости загрузить все ядра даже просто понижаю приоритет процесса. Потеря в производительности не велика при этом, зато текстовый редактор не тормозит ничуть :)
кстати вот ещё, копирайт не мой :), давать програмерам тормозные компы.
у пользователей будет всё летать просто!
очень успешно использовалось в одной конторе :)
у пользователей будет всё летать просто!
очень успешно использовалось в одной конторе :)
А доплачивать программистам за вредность там не забывали? Ведь это очень вредно для нервов, работать на тормозных компах…
зато эффективно. прикиньте, они прямо в голове алгоритмы отлаживали :) дабы сократить время.
имо, это правильно.
имо, это правильно.
Ох не уверен… Нет. Уверен. Бред это.
Если программист хороший, он свой код сначала в мозгах выполняет, а только потом пишет и проверяет. Ну а если программист плохой, то он всё равно будет сначала писать (параллельно (!) матерясь), выполнять на машине, пробовать… И на это на слабой машине будет уходить куда больше времени.
«Писать код со скоростью мысли» и, ИМХО, нужно к этому стремиться. А медленный компьютер будет сильно мешать и отвлекать.
Если программист хороший, он свой код сначала в мозгах выполняет, а только потом пишет и проверяет. Ну а если программист плохой, то он всё равно будет сначала писать (параллельно (!) матерясь), выполнять на машине, пробовать… И на это на слабой машине будет уходить куда больше времени.
«Писать код со скоростью мысли» и, ИМХО, нужно к этому стремиться. А медленный компьютер будет сильно мешать и отвлекать.
я слишком много видел программистов, которые шли к правильному алгоритму методом итераций :( на таких собственно и рассчитано
Ну так если программист такой (тоже насмотрелся, да и сам таким был, когда начинал), то медленная машина лишь увеличит время разработки и раздражительность его самого и окружающих от него.
Я даже не уверен, что это будет иметь хотя бы такой эффект, как подстёгивание новичка-, говно-, недо-программиста к повышению своего навыка. Но, вполне может быть, это очень зависит от человека и на некоторых личностей оно будет действовать именно так.
Не знаю. Ты посеял сомнение во мне. :-)
Я даже не уверен, что это будет иметь хотя бы такой эффект, как подстёгивание новичка-, говно-, недо-программиста к повышению своего навыка. Но, вполне может быть, это очень зависит от человека и на некоторых личностей оно будет действовать именно так.
Не знаю. Ты посеял сомнение во мне. :-)
Про вторую задачу…
У нас есть рабочий сервер о восьми ядрах и восьми гигах, исполняющий роли маршрутизатора и гипервизора (KVM)… Так вот, несколько виртуалок работают под виндой с разными версиями ишака (6, 7, 8) и прочей лабудой. Дизайнеры пишут тесты для Силениума (у нас продвинутые дизайнеры) и гоняют их там. Никаких проблем.
Очень рекомендую.
P.S. Используем VNC, так как RDP лень поднимать — в общем-то и так всех устраивает. :-)
P.P.S. Наше железо явно избыточно для этих целей — 256 Mb и 2 ядра на XP хватает за глаза.
У нас есть рабочий сервер о восьми ядрах и восьми гигах, исполняющий роли маршрутизатора и гипервизора (KVM)… Так вот, несколько виртуалок работают под виндой с разными версиями ишака (6, 7, 8) и прочей лабудой. Дизайнеры пишут тесты для Силениума (у нас продвинутые дизайнеры) и гоняют их там. Никаких проблем.
Очень рекомендую.
P.S. Используем VNC, так как RDP лень поднимать — в общем-то и так всех устраивает. :-)
P.P.S. Наше железо явно избыточно для этих целей — 256 Mb и 2 ядра на XP хватает за глаза.
для тестирования гуя, кроме виртуальных машин, также можно приспособить второй экземпляр X.org. На UNIX-системах особых телодвижений не нужно, все уже предусмотрено. На окнах вроде бы есть много сторонних реализаций иксов, но не знаю, как у них со стабильностью, производительностью и совместимостью с нативным софтом. Но попробовать можно
Для сборки существенных приложений и их тестирования обычно делают отдельный build сервер, который при успешном билде и прогоне тестов обновляет на dev сервере.
А если уж программа на C++ и долго компилируется, то distcc спасает. И тут многопоточность реально рулит.
А что касается пользовательского интерфейса, чтож, запускайте его в rdp или в virtualbox :-) Тем более, если это не веб-приложение, то виртуалбокс очень даже спасает при тестировании
А если уж программа на C++ и долго компилируется, то distcc спасает. И тут многопоточность реально рулит.
А что касается пользовательского интерфейса, чтож, запускайте его в rdp или в virtualbox :-) Тем более, если это не веб-приложение, то виртуалбокс очень даже спасает при тестировании
Sign up to leave a comment.
Многозадачность – это миф?