четверг, декабря 31, 2009

Лучшее за 2009 год

Закончился еще один год, пора публиковать традиционный список наиболее популярных постов. Как обычно напоминаю, что популярность я определяю по посещаемости. Делить посты по категориям я в этот раз не буду.

Самый популярный пост этого года - видео, перепост с другого блога - Про технологии и чудеса.

Следом за ним следует наше с Джимом творение - Карта языка С++. Популярное не только у нас, но и за рубежом :-).

На третье место внезапно ворвался пост про Свою Компанию. Несмотря на близость Нового Года, на него идет огромный поток людей, пост разодрали на цитаты, его активно обсуждают в офисах.

Также в уходящем году пост про delete this вызвал некоторый интерес, а Задача про зеркало породила немеряно комментариев.

Все еще очень популярны посты прошлых лет: Хорошие книги по С++ для начинающих и Нарисовать граф красиво

Всем спасибо за внимание, всех с Новым Годом :-)



Ссылки по теме:
Лучшее за 2008 год
Лучшее за 2007 год
Лучшее за 2006 год
Лучшее за 2005 год

вторник, декабря 29, 2009

Статья They Write the Right Stuff

В комментариях к посту Искусство отладки Евгений Охотников дал ссылку на статью про то как разрабатывается софт в NASA: They Write the Right Stuff. Статья полезная, но очень пафосная и занудная, нужная информация начинается на четвертой странице, первые три страницы о том, какие замечательные люди там работают. Я убрала всю воду и получился перессказ на полстраницы.

Интересная статистика: В последних 11 версиях их продукта всего было 17 ошибок, в обычной софтверной компании в программе сравнимого объема было бы 5000 ошибок.

Автор статьи считает, что их рецепт успеха в том, что у них определен процесс, который позволяет сократить количество багов.
1. Тщательно составляется ТЗ, это занимает примерно треть всего времени разработки.
Ну у нас как обычно - ТЗ пишется в процессе разработки. Из-за этого в софт вносятся частые изменения, а каждое изменение - это баги.

2. Программисты разбиты на две группы.
Первая пишет код, вторая его проверяет. Вторая группа не тестеры, обратите внимание. Вообще их задача состоит в том, чтобы группа тестирования ни одной ошибки не нашла.

3.Ведется база данных найденных багов.
Как нашли, как починили.

4.Анализируется причина появления бага, пытаются понять какие неверные решения привели к его появлению. При этом людей никогда не чморят за баги.
Тут приведен пример:
Они разработали софт для роботизированной руки, которой мог управлять человек. В какой-то момент рука просто переставала двигаться. Проблема была в неверном округлении. Они стали анализировать код на предмет того, что еще может привести к остановке руки. Нашли несколько таких мест.


В самом конце говорится, что это самая дорогая софтверная организация одна из самых дорогих софтверных групп (on a dollars-per-line basis, it makes the group among the nation's most expensive software organizations), они тратят 35 миллионов долларов в год. Автор статьи был на встрече группы, там было 22 человека. Ну и небыстро там все происходит, я подозреваю.

четверг, декабря 17, 2009

Своя Компания

У программистов часто встречается большая и светлая мечта - открыть Свою Компанию по производству софта. К сожалению, для этого надо Много Денег, потому мечта неосуществима. На самом деле эта светлая мечта неосуществима по другим причинам.

Два вопроса, которые позволяют быстро оценить серьезность намерений.
1. Что именно будет делать эта компания?
2. Сколько конкретно нужно денег?

Ответы на первый вопрос обычно туманный: "ну.. игры...?". Народ любит делать игры, ага :-).
Ответ на второй вопрос тоже вызывает затруднения. Ответ обычно получается в миллионах долларов. "ну... миллион. Или два".

Откуда берутся эти миллионы никто толком сказать не может. "Надо снять офис и нанять людей". Детальный счет из этих миллионов никто составить не может. Правда, все уверены, что счет идет на миллионы. Прикольно. Но если сесть и посчитать, то получаются другие цифры. Я знаю, я считала. Это был 2006 год, расчет делался для компании по производству shareware игр, для Москвы. Получилось ~20000 долларов. Ден Шергин, гендиректор Unigine тоже считал. У него получилось $10-20k. Забавно, да? Сильно меньше миллиона...

Теперь подумайте действительно ли вам нужна своя компания? Поскольку речь идет о компании по производству софта, а не по перекладыванию денег туда-сюда, вам придется много работать, сильно больше 8 часов в сутки. И заставлять работать раздолбаев, которые будут на работу всячески забивать и вешать вам неинтересную лапшу на уши, они будут срывать сроки и канючить. И не факт что в итоге удастся заработать денег. Иногда на выходе получается только бесценный опыт, без денег, увы. Готовы?

У нас тут скоро Новый Год, пора сбычи мечт. Сделайте хоть что-нибудь. Ответьте на заданные мною вопросы. Если у вас есть идея, которая кажется вам ценной, расскажите о ней. Хотя красиво выглядящая идея далеко не самое главное. "У меня есть грандиозная идея и если бы только были деньги на ее реализацию...". Людей постоянно прет от идей, вы не поверите. Одна бредовее другой. Напишите прототип. Возможно, в процессе его написания вы поймете, что придумали фигню. Потом, поучаствуйте в Imagine CUP, попробуйте найдите финансирование.

На самом деле несбыточная мечта о Своей Компании - это светлый образ халявы. У разных людей она принимает разные формы, у программистов это Своя Компания. Так что определитесь чего вы хотите. Или не хотите. Ведь, как известно, обманывать нехорошо, а обманывать себя еще и очень глупо.

Несколько живых примеров создания Своей Компании:
Истории успеха
Два друга решили делать игровой движок и продавать его. Так получилась компания Unigine. Не знаю точно как у них дела, вроде бодрячком все.

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

Истории неудач
... которые зачастую интереснее историй успеха. Обе из области разработки игр.

Итак история номер раз.
Живое воплощение мечты. Папа дал сыну денег. И сын решил делать компанию по производствую компьютерных игр. Он поступил по сценарию, который был озвучен выше. Он снял помещение и нанял людей. У него получились люди, которые бродили по помещению. Через некоторое время деньги закончились, люди побрели в другие места. Конец истории.

История номер два.
Папа дал сыну денег :-).
Сын сделал компанию по производству игр. Сделали одну игру, она не зажгла, хотя неплохая вроде игра. Компанию пришлось закрыть, людей распустить.

Краткий словарик:
PoC (Proof of concept) - в нашем случае некий прототип, доказывающий, что идея рабочая
Венчурный капиталист - человек или компания, которые инвестируют деньги. Я знаю только одну такую компанию, это Y Combinator. Поищите, их много.
Ангел - человек, который готов дать вам денег либо просто так, либо на каких-то очень приятных условиях
Стартап - свежесозданная компания. Обычно этот термин применяется к компаниям в сфере IT.

Ссылки:
Будет ли работать бизнес-модель Y Combinator в России?

Книги:
Founders at work
Берись и делай
7 навыков высокоэффективных людей

воскресенье, декабря 06, 2009

Искусство отладки: технологии будущего

Все-таки очень хочется от багов избавиться совсем. Разработка по времени тогда сократится значительно, случится счастье и технологический прорыв.

Я видела планы разработки составленные так, будто это счастье уже наступило. Существование багов просто игнорировалось и время на отладку запланировано не было. В конце таких проектов всех всегда ждал бардак и жуткое разочарование. Получалось такое глюкало, что было непонятно нужно ли это отлаживать или лучше сразу выкинуть и забыть. Мораль: если игнорировать реальность, то она больно бьет по ушам.

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

1. Формальное доказательство правильности программы.
Идея далеко не новая, выглядит красиво. Давайте докажем, что программа работает верно. На ВМиК МГУ читается курс по этой теме. По свидетельствам очевидцев доказать правильность программы, которая сортирует пузырьком - весьма нетривиальное занятие. О реально работающем проекте, который размером сильно больше такой сортировки, говорить не приходится.
Формальная верификация - статья в Википедии. Больше правильных ссылок дать не могу, потому что не знаю.

2. Статический анализ кода.
Выглядит уже более реалистично. Натравливаем на проект программу, которая анализирует код и пытается найти ошибки. Я не видела, чтобы эта метода была официально одобрена и использовалась в каких-нибудь компаниях серьезно. Однако, существуют статические анализаторы, которые стоят хороших денег с большим количеством нулей. Наверное их кто-то покупает. Я же встречала только ситуации, когда программисты из любопытства запускали какой-нибудь из таких анализаторов на своем проекте и просматривали результаты.
Народ говорит, что такие анализаторы много шумят не по делу, какие-то ошибки пропускают, но в целом выглядят интересно.
Тут много ссылок:
Static code analysis
Статический анализ кода C++ - обсуждение на Хабрахабре
Best tools noone uses: PREfast - статья на русском, немного про программы-анализаторы вообще, в основном про PREfast
dtjurev: Статический анализ С++ кода

среда, декабря 02, 2009

Искусство отладки: как починить баги

Мы подобрались к Злу вплотную. Вот они, баги - порождения человеческого разума и несчастного стечения обстоятельств. Они бывают разные. Забавные ( Алён, у нас по уровню ходят глаза, это нормально? ) и не очень ( CRASH BUG on the first level! FIX ASAP...).


Что меня всегда огорчало в вопросах починки багов - это многочисленные советы. Причем большинство из них, они как из страны эльфов. "Запустите дебаггер и в пошаговой отладке вы увидите что происходит". ОК, запустили. Под дебаггером у меня все хорошо. У меня вообще многопоточное приложение, его бессмысленно дебажить пошагово. Или я работаю со звуком, иногда проскакивает треск. Как такое пошагово отлаживать?
Вот еще совет. "Если у вас не работает релизная версия, запустите дебагную и посмотрите там". Запустили. В дебаге все нормально. И чего делать-то?
И это не такая уж и редкая ситуация, когда дебаг с релизом вот так кардинально различаются. Обычно здесь смотрять чем отличаются дебагная и релизная версия и что из этих различий оказалось причиной бага. Рассказ про такой баг.
Еще в различных форумах можно полчить мудрые советы, начинающиеся со слов "надо было". Крайне полезно, ага.

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

Первое и главное. Отладка багов требует активного сотрудничества между разработчиками и отделом тестирования, искренней заинтересованности в результате. Конфликты с отделом тестирования и попытки себя уговорить, что "им показалось" бессмысленны. Им не показалось.
И нет такого понятия "чужая бага". Любая бага в проекте - моя. Ведущий программист (иногда задачи в проекте распределяет менеджер, тогда это будет менеджер) назначает чинить багу как правило автора кода, в котором это бага возникла, не потому что этот человек виноват и теперь должен за это поплатиться, а потому что он лучше знает код и быстрее ее починит.

Про пошаговую отладку под дебаггером рассказывать не буду. Это вы все сами знаете и умеете. Баги, которые ловятся таким образом, тривиальны. Единственный момент тут - если вы проводите слишком много времени под дебаггером, это плохой признак. Значит код изначально написан криво.

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

Если "раньше все работало", а потом вдруг перестало, имеет смысл пошерстить репозиторий и найти методом бинарного поиска версию, с которой начались проблемы.

Трудновоспроизводимые баги заслуживают самого пристального внимания. Здесь спасает анализ ситуации и придирчивое чтение кода. Когда, при каких условиях бага проявлялась? Почему именно тогда? Как повысить воспроизводимость? Если повезет, то через какое-то время у вас будет не один, а несколько случаев проявления баги, их можно сравнивать, искать закономерности.

Выводы могут оказаться неожиданными. Пример: Open Office не печатал по вторникам. Бага оказалась не в Open Office, а в утилите file, которая определяла тип файла. По вторникам она определяла файл, отправленный на печать, не как PostScript файл и получалось, что напечатать его нельзя. Дело в том, что в начало файла записывалась дата. Начиная с четвертого байта по вторникам там лежало Tue, от Tuesday. Для утилиты это было знаком того, что это файл Erlang JAM.

Первый шаг работы с трудновоспроизводимыми багами - научиться воспроизводить их чаще, повысить воспроизводимость. Например, если бага проявляется только на конных юнитах - побольше конных юинтов, убрать всех остальных. У нас в арканоиде была бага - шарики сквозь кирпичи пролетали. По коду смотрю, ну не может такого быть никак. Вообще непонятно как им это удается, воспроизводится редко. Поставила вниз стену, запустила 20 шариков, скорость побольше. Вот тут оно все и вылезло.
Решение "вот у нас была такая бага, случалась редко, мы над ней поработали и теперь она случается еще реже" - это не прогресс, это не решение проблемы. Возможно, эта фраза и успокоит неопытного менеджера. Но на самом деле тем самым вы ухудшили ситуацию, а не улучшили ее.

Одним из видов трудновоспроизводимых багов являются ошибки по памяти. Работа с "мусором", произвольная порча памяти и подобные. Тут можно смотреть чем именно была затерта память, на что это похоже. Отладка ошибок по памяти подробно проанализирована тут: Debugging Memory Corruption in Game Development.

Еще один вид трудновоспроизводимых багов - так называемые гейзенбаги, названные так в честь принципа неопределенности Гейзенберга. Они пропадают как только пытаешься их отладить. Тут можно анализировать проявления багов, пытаться поэкспериментировать с кодом, поизменять его, что может помочь найти причину возникновения гейзенбага. Подробная статья про гейзенбаги: Debugging Heisenbugs.

Ошибки в многопоточных приложениях крайне неприятны и плохо воспроизводятся. Тут кроме анализа ситуации можно использовать волшебные тулзы типа Intel Threads Checker. Вот кроме него ничего и не знаю, прям стыдно. Под другие платформы наверяка есть свои тулзы.

Процесс починки багов любят объяснять, разбивая его на шаги. Давайте я тоже шаги напишу что ли...
Итак, хорошая последовательность действий при починке багов:
1. Понять в чем именно состоит проблема. Воспроизвести.
2. Прикинуть как ее можно решить, выбрать наилучший способ.
3. Имплементировать.
4. Проверить что проблема решена и что новых не возникло. (!не надо пропускать этот пункт)
5. Подумать над тем, что к проблеме привело, чтобы исключить подобные проявления в дальнейшем.

Классическая плохая последовательность действий:
Вот, кажется тут! Да, починил. А, не, не тут и не починил, отдел тестирования опять поймал это... ОК, смотрю опять, опять чиню.
И так по кругу. Процесс и не думает сходиться. Старый код починки остается, он бессмысленно замусоривает проект и служит источником новых багов. Багов остается столько же или их количество растет.

Как замаскировать
Если есть проблемы с починкой баги, ее можно временно замаскировать, чтобы потом вернуться к ней позже.
Итак, поздний вечер, завтра надо проект поставлять, пять минут назад была обнаружена злая бага (почему мы не замечали это раньше???), как чинить непонятно вообще. Очень хочется спать и есть. В таком случае, преисполнившись ненавистью к себе, обрамляем код комментариями //FIXME или тем, что принято в вашем стандарте кодирования. И пишем что-то вроде

if( value == 6 ) value = 5;
Ну или что-то такое же мерзкое, что решит проблему, хотя бы частично.
Хинт: иногда надо делать поиск в коде по FIXME. Сокрушаться над количеством найденного не надо. Надо чинить.

Байки:
Байка про стену
Байка про return в пустоту
Описание одного бага, другого наведённого бага, и одной отладки

Ссылки:
Дядя Дима - Рецепты отладки. 3 типа нестабильностей.
Дядя Дима - Теория ошибок. Нестабильности первого рода.
Дядя Дима - Теория ошибок. Нестабильности второго рода.
Дядя Дима - Теория ошибок. Нестабильности третьего и четвертого рода.

суббота, ноября 28, 2009

Искусство отладки: как предупредить появление багов

Очень хочется придушить все баги накорню. Совсем все придушить не получится, а вот сильно уменьшить их число - вполне.

Но тут не существует волшебного набора правил. Я не могу выдать вам список из N пунктов, соблюдая которые можно познать дзен. Тут надо думать, анализировать и действовать по обстановке.

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

В предупреждении багов помогают продуманная архитектура и читаемый код ( Джоэл Спольски в своем блоге называл его "самодокументируемый" ). И отношение тут не бинарное: плохая архитектура - хорошая архитектура. Читайте, разбирайтесь, пробуйте и постепенно архитектура у вас будет получаться все лучше и лучше. Классно сделанная архитектура не только не провоцирует появление багов, но и сопротивляется их внесению. Про архитектуру кода можно говорить долго, это отдельная большая тема, поэтому я просто дам несколько терминов со ссылками: слабо связный код, борьба со сложностью, Defensive programming. Еще стоит почитать хорошие книги об организации кода.

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

Не забывайте про автоматическое тестирование. Добавляйте его где возможно.

Вообще написали что-то - проверьте. Не надо надеяться, что багов в вашем коде нет. Потому что они там есть. И чем раньше вы их поймаете, тем лучше. Сейчас, прямо после написания кода, вы хорошо его помните, это не займет много времени. Это гораздо быстрее чем прогонять код через команду тестирования и получить от них баги в багтрак через пару дней. Если нетривиальный кусок кода заработал сразу - это повод для беспокойства, значит вы что-то пропустили. Тут я очень советую почитать прекрасную статью написаннию тестером специально для программистов: Testing for developers.

Написав код, остановитесь, подумайте. Что будет если? Если числа выйдут за заданный диапазон? Что если мне здесь придет нулевой указатель? Как можно сломать мой код? Хотя если вы сейчас в кранче, то наверное не стоит тратить время на медитацию над этими вопросами. Однако, если время есть, то ответы на них спасут вам недели времени.

Хорошо помогает code review. Когда кто-то из ведущих программистов просматривает код остальных. Но осложняется человеческим фактором "как же так, кто-то будет проверять и править мой гениальный код?!". Поэтому code review может привести к боязни коммита и конфликтам в команде. Статья про code review: Your Code Sucks and I Hate You: The Social Dynamics of Code Reviews.

Постоянная бдительность! Паранойя в разумных пределах есть благо. Наряду с вопросом "что будет если?" задавайтесь вопросом "почему?". Мы практически ничего не меняли в последнее время, а размер дистрибутива вырос, почему? Мы не меняли данные, однако SVN подсвечивает их как измененные, почему?

Очень важным индикатором проблемы является взрывной рост числа багов. Например, нам постоянно приходят баги из отдела тестирования по поводу работы со звуковой подсистемой. Причем проблемы одна страннее другой. Странные проблемы есть следствие странных решений. Мистически ломающиеся куски кода означают, что вы чего-то не понимаете. Когда нет понимания, вам начинают вспоминаться фазы луны, бубен и барабашка. Так вот, надо на мистически ломающийся кусок кода обратить самое пристальное внимание. Очень возможно, что источник всех этих проблем - один, а это его разные проявления. И это тот самый момент, где Старания и Аккуратность, упомянутые в прошлом посте, только усугубят ситуацию. Если вы будете старательно править баги, вместо того, чтобы разобраться с причиной, вы потеряете кучу времени и завяжете код узлом. Чем больше вы будете биться над кодом, тем сильнее затянется петля (см. симфоническую сказку Петя и Волк в качестве наглядной иллюстрации).

На сегодня, пожалуй, все. В следущий раз - основная тема. Как всё исправить.

Байки:
Про Блицкриг 2
Про четырехмесячный дебаг

Ссылки:
Отладка. Несколько советов.
Программистское: статистическая и доказательная стратегии защиты от ошибок (Тут есть бонусная байка про наковальню)

четверг, ноября 26, 2009

Искусство отладки

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

Я решила сделать серию постов про отладку, где соберу накопившиеся у меня материалы. Тут будет некоторое количество моих собственных спорных мыслей. И я дам ссылки на байки о багфиксе, чтобы было не так скучно. Как обычно приглашаю всех подискутировать и поделиться накопившейся мудростью. :-)

Поскольку получилось много, повествование разбито на части.

1. Введение.
То, что вы читаете прямо сейчас.

2. Как предупредить появление багов.
Предупреждать всегда лучше чем лечить.

3. Как починить баги.
В основном речь пойдет о трудновоспроизводимых багах. Про маскировку багов я напишу сюда же. Тут будет много ссылок.

4. Технологии будущего.
Странные подходы, которые могут привести к тому, что отладкой больше заниматься не придется. А могут и не привести.


Когда речь заходит об отладке всегда говорят о неких технологических приемах, но редко вспоминают, что тут много завязано на психологию программиста. Самая основная проблема багфиксинга состоит в том, что чинить баги непрестижно. Чинить чужие баги - непрестижо вдвойне. Дальше - хуже. Баг в программе считается виной программиста. Такое мнение часто культивируется менеджментом. Программистов гнобят за баги. Ирония ситуации заключается в том, что баги - это естественное следствие написания кода. Программист пишет код - программист пишет баги. Программист модифицирует код - программист привносит баги. И если начать над программистом глумиться и всячески его унижать, то он быстро сообразит, что лучший способ избежать багов - писать как можно меньше кода. И еще - убеждать отдел тестирования, что тем показалось. Итого: производительность труда понижается, качество софта падает.

Следующей проблемой в борьбе с багами является Миф о Старании и Аккуратности. Удивительно живучая штука, и мне совсем непонятно откуда она взялась. Миф состоит в том, что если вы аккуратны, то багов у вас не будет. Вот так всё просто. Если у вас много багов, то это означает, что вы мало стараетесь. Это не так, баги не лечатся старанием. Поверьте, я очень аккуратный человек. Меня не раздражает монотонная работа, я могу по десять раз проверять одно и то же и это не вызывет приступ тихого бешенства. Но я не могу писать код без багов.

Приступать к борьбе с багами можно только если багфиксинг не вызывает у вас неприязни, чувства вины и страданий по поводу несовершенства Вселенной. Программистов, которые пишут код без багов, не существует. Те, кто любит рассказывать о своем умении писать безбажный код, нагло гонят. Научитесь писать код без багов и вы прославитесь и разбогатеете. Я серьезно.

Ну чего, в путь. И помните, Developers are born brave :-)



Байки:
Про вампиров
Про 500 миль


Книги:
"Совершенный код" Макконелла. Глава 23 полностью посвящена отладке.
David Agans "Debugging: The Nine Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems". Напишу по этой книге отдельный пост как только ее прочитаю.

Updated 29.11.2009
В комментариях заинтересовались непрестижностью отладки. Вот очень жизненный пост про это:
пионеры, поддержка, и Доктор Хаус. Там есть байка про белые точки. (Нашла по ссылке отсюда)

пятница, ноября 20, 2009

Приехали книги из Амазона

Сегодня ко мне приехали:

Debugging. Книга, целиком посвященная отладке. Заказала ее, потому что готовлю эпичную серию постов по этой теме.

Coders at work. Как Founders at work только про кодеров.

Game Programming Gems 6. Вообще уже вышла седьмая книга серии. Но, судя по отзывам, она неудачная. Так что я взяла шестую.

Warfare in the Medieval World. Про тактику средневековых сражений. Долго искала что-либо подобное, по описанию эта книга выглядит отлично, содержимое я скоро заценю.

По мере прочтения буду писать рецензии. :-)

Amazon.com не работает теперь с Почтой России и их можно понять. Доставляет всё очень быстро и очень дорого.

среда, ноября 11, 2009

Язык программирования Go

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

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

Официальный сайт языка Go, там есть FAQ.

Новость пользуется популярностью, вот уже многопоточный рейтрейсер написали... A Multi-threaded Go Raytracer

Updated 20.11.2009
Ссылки по теме:
Краткий пересказ Effective Go на русском языке

четверг, ноября 05, 2009

Code reuse

Проблемы с code reuse испытывают средние и большие программерские компании. Это 50 или больше программистов, не все друг друга знают в лицо и не все знают кто над каким кодом работает. Вы пишите проприетарный софт, как-то его документируете, однако раз за разом наступаете на одну и ту же проблему. Различные группы программистов постоянно пишут один и тот же код, дублируя тем самым работу друг друга. Ситуация может осложняться еще и тем, что у компании может быть несколько географически удаленных друг от друга девелоперских офисов. Как решать эту проблему? Я видела три подхода, все плохие.

1. А никак. Живем с дублированием кода. Иногда страдаем по этому поводу.

2. Периодически устраиваем встречи, делаем красивые презентации, кидаем обширные письма в общую рассылку. Желающие могут взять код соседнего отдела и начать с ним работать. Однако народ на встречи зачастую не приходит, рассылку читает наискосок. Кто-то начинает форкать чужой код и вот у нас уже куча вариантов одного и того же, но с разным набором багов.
Итог: Code reuse местами присутствует.

3. Жесткая модульная система. Подробное документирование. За каждым модулем закреплен ответственный. Возможно, есть отдельные люди, которые следят за тем, чтобы дублирования кода не было.
Казалось бы, вот оно! Однако в итоге получаем падение морали и резкое снижение производительности труда. Потому что у нас все команды становятся завязаны друг на друга и никто старается ничего не менять, чтобы не стать тем самым виноватым, который всё сломал.

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

понедельник, ноября 02, 2009

Несколько старых интервью

Так получилось, что на прошлой неделе я прочитала/посмотрела несколько интервью с разработчиками. На случай, если вы их не видели:

Рассказ Джона Кармака на QuakeCon 2009:

Раз уж зашла об этом речь, вот презентация об их движке Tech5[.pdf]. Презентация красивая, но несколько бестолковая, мало подробностей.

Интервью с Дмитрием Ясеневым об искусственном интеллекте СТАЛКЕР'а:
S.T.A.L.K.E.R.: Чистое небо - интервью о проблемах выживания искусcтвенного интеллекта в Чернобыльской Зоне

Интервью с Тимом Суини о GPU (Спасибо Денису Баженову за ссылку):
Twilight of the GPU: an epic interview with Tim Sweeney

среда, октября 14, 2009

Вызов деструктора константного объекта

Интересная штука получается с константными объектами. Не константные функции у них вызывать нельзя. То есть получается, что и деструктор звать нельзя. Потому что деструктор const объявлять нельзя. Конструктор, кстати, тоже нельзя. ( Я знаю, что на слово вы мне не поверите, поэтому привела куски из Стандарта в конце поста ).

В связи с чем возникают вопросы. А что будет вот с таким кодом? Будет ли вызван деструктор при выходе из блока?


{
const CMyClass p;
}


А вот это как же? Скомпилируется?

{
const int* p = new int(10);
delete p;
}


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

Об этом лучше помнить, чтобы потом не писать вот так:
delete const_cast<ReferenceCounter*>(this);


Куски из Стандарта по теме:
[class.dtor] 12.4/2:

A destructor is used to destroy objects of its class type. A
destructor takes no parameters, and no return type can be specified
for it (not even void). The address of a destructor shall not be
taken. A destructor shall not be static. A destructor can be invoked
for a const, volatile or const volatile object. A destructor shall
not be declared const, volatile or const volatile (9.3.2). const and
volatile semantics (7.1.5.1) are not applied on an object under
destruction. Such semantics stop being into effect once the destructor for the most derived object (1.8) starts.


[expr.delete] 5.3.5/2:

[Note: a pointer to a const type can be the operand of a
delete-expression; it is not necessary to cast away the
constness (5.2.11) of the pointer expression before it
is used as the operand of the delete-expression. ]


Ссылки по теме:
comp.lang.c++.moderated - Delete a const pointer?
comp.lang.c++.moderated - Why can operator delete be called on a const pointer?

вторник, октября 06, 2009

Google C++ Style Guide

Google C++ Style Guide как-то упомянули у меня в комментариях и я решила продублировать ссылку на него здесь. Это стандарт кодирования гугловых open source С++ проектов. Этот Style guide содержит некоторые спорные решения как то: отказ от исключений, отказ от RTTI.

В свое время Google C++ Style Guide активно обсуждался на Habrahabr'е.

пятница, сентября 25, 2009

Приехала на фестиваль 404

Завтра в Самаре будет фестиваль 404. Я решила посетить его с мужем за компанию. О разработке игр там, похоже, ничего не будет, так что подробные отчеты ищите на блогах веб-разработчиков, если интересно.

вторник, сентября 08, 2009

Блог I Get Your Fail

I Get Your Fail - Epic failures in the game development field. Что-то вроде The Daily WTF, но посвящен исключительно геймдеву.

Ссылку на него я привожу не столько для того, чтобы поржать, а скорее для того, чтобы поучиться на чужих ошибках.

Пара интересных видео оттуда.

Неправильная физика обломков


Атака ветряных мельниц

понедельник, сентября 07, 2009

Конструктор или оператор присваивания?

В C++ не всегда бывает так, что знак = означает вызов оператора присваивания, из-за чего народ начинает путаться.

Я нашла в comp.lang.c++.moderated большой хороший пример, может пригодится кому.


class B { ... };

class A
{
...
public:
// Constructor
A() { ... }

// Copy constructor
A(const A& a_obj) { ... }

// Constructor overloading
A(const B& b_obj) { ... }
...
A& operator=(const A& a_src) { ... }
...

};

// Примеры:
A a1; // конструктор вида A()
A a2(a1); // конструктор копирования A(a1)
A a3 = a2; // конструктор копирования A(a2)

B b;
A a4(b); // перегруженный конструктор A(b)
A a5 = b; // перегруженный конструктор A(b)

a1 = a5; // operator=(const A&) то есть operator=(a5)
a2 = b; // Шаг1: создается временный объект класса а A
// с помощью конструктора вида A(b),
// Шаг2: -> operator=(const A&) то есть operator=(A(b))

Если будете экспериментировать, не забудьте выключить оптимизацию.

воскресенье, августа 23, 2009

Робот EATR

Давно ничего не было про роботов, вот веселая история.

Компании Cyclone Power Technologies и Robotic Technology Inc. по заказу DARPA создают робота, который может работать на биологическом топливе. Также он может использовать и другое топливо, пропан, например. Называется робот EATR, расшифровывается как Energetically Autonomous Tactical Robot (энергетически автономный тактический робот).
Сам робот существует только в проекте.

Вот официальная страница с документацией, вот презентация [.pdf].

До поры до времени это была просто интересная перспективная разработка. Робот, которому не надо подвозить горючее - очень удачная идея...
А потом об этом узнала пресса. Робот будет работать на биомассе. Биомасса - это у нас что? Это ж трупы! Мне не удалось найти, кому именно в голову пришла эта блестящая мысль. То ли журналисты сами придумали, то ли кто-то из разработчиков неудачно пошутил, то ли какой-нибудь PR не то пропиарил.
И началось...

Military EATR Robot Could Feed On Dead Bodies On Battlefield (Военный робот EATR может питаться мертвыми телами на поле боя)

DARPA Killing Robot Machines Eat Everything In Their Path (Роботы-убийцы DARPA жрут всё на своем пути)

EATR Robot: Robots Gone Zombie? (Робот EATR: роботы-зомби)

Military EATR robot could fuel itself with corpses (Военный робот EATR может получать энергию от трупов)

Разработчики робота пытаются людей успокоить, говорят, что робот будет работать исключительно на траве. Тогда появились вот такие заголовки:

Company Denies its Robots Feed on the Dead (Компания отрицает, что их роботы жрут трупы). Картинка соответствующая.

Fox News поправила статью и заголовок к ней.
Biomass-Eating Military Robot Is a Vegetarian, Company Says (Компания утверждает, что робот, питающийся биомассой - вегетарианец.)

EATR Robot Is A Vegetarian(Робот EATR - вегетарианец)


Спасибо Maniac'у за ссылку.

пятница, августа 21, 2009

Блог My Productivity Blog

Блогов по самомотивации и всяким прочим GTD - много, хороших мало. Этот - лучший.
My Productivity Blog.

Спасибо Maniac'у за ссылку.

четверг, августа 20, 2009

C++0x - концепций не будет

Добралась до блога, чтобы поделиться бородатой новостью. Concepts Get Voted Off The C++0x Island.
Статья Страуструпа об этом решении: The C++0x "Remove Concepts" Decision.

Про концепции можно посмотреть/почитать тут: Видео Concepts: Extending C++ Templates For Generic Programming.

четверг, июля 16, 2009

Евгений Зуев просит помочь с комментариями к переводу нового стандарта С++

Евгений Зуев, который сейчас делает перевод нового стандарта С++, просит ему помочь.

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

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


Не знаю, смогу ли я в этом поучаствовать, но я постараюсь.

пятница, июля 03, 2009

Nerd humor

понедельник, июня 29, 2009

Книга Founders at work

English version of this post is here.

Founders at work - это сборник интервью со стартапперами. В ней собраны очень разные истории. Удачные и неудачные. Никакие. Хотя пропорция явно не соблюдена, историй успеха здесь значительно больше. Описания долгих работ, ошибок, неудач. Книга немного устарела, но это не очень страшно.

О своих историях рассказывают Стив Возняк(Apple), Джоэл Спольски(Fog Creek Software), Тим Брэди (Yahoo), Катерина Фейк (Flickr), Блейк Росс (Firefox), Чарльз Гешке (Adobe Systems) и ещё куча народу.

Из нее вы узнаете, что PayPal изначально был не об электронных платежах. Что у del.icio.us были проблемы с масштабируемостью, что Flickr начинался как побочный проект одной онлайн-игры.

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

Из истории про Блоггер

Виллиамс: ... Все ушли и на следующий день я был единственным, кто пришел в офис
Ливингстон: И как вы чувствовали себя в то утро?
Виллиамс: Это было очень плохое время...


Из истории про Yahoo
Брэди:
Самая забавная история, которую я помню случилась, в Мае 95-го, тогда был сильный шторм и электричество отключилось на несколько дней. Нам пришлось арендовать электрогенератор и по-очереди заправлять его дизельным топливом в течение 4 дней. Круглосуточно. Мы смеялись. "Как много страниц приходится на галлон?". Это был безумный шторм, здание начало протекать. У нас были запланированы встречи, мы не могли их просто так отменить. С некоторыми видными компаниями встречи проходили при свечах. Они приходят, света нет, повсюду провода от генератора, с потолка капает вода. Мы их убеждаем "о, да, у нас стоящий бизнес" и тут же "погодите, мне надо наполнить бак". Я помню эти дни довольно хорошо.


Книга толстая, интервью там много, читала я ее долго. Я считаю, что для поднятия мотивации её надо продавать в комплекте с книгой Founders at leisure, в которой надо сделать поменьше текста и побольше цветных картинок в хорошем качестве. Чтение тогда пойдет гораздо веселее.

Ссылки по теме:
Founders at work есть на Озоне
Talking To The Developers Of The Unigine Engine

пятница, июня 26, 2009

Geek clock

Забавные часики


Updated 01.07.2009:
Как и обещала, расшифровка по позициям:
1. Константа Лежандра. Когда Лежандр вводил эту константу он не знал, что она равна единице.
2. Сумма бесконечно убывающей последовательности. Про которую есть известный математический анекдот. "Бесконечное число математиков приходят в бар. Первый заказывает кружку пива. Второй - полкружки пива. Третий - четверть кружки и так далее. Через некоторое время бармен говорит "Вы все идиоты!" и ставит им две кружки пива".
3. Представление юникодного символа в XML.
4. Сравнение по модулю.
5. Фи в формуле - это золотое сечение.
6. 1*2*3
7. Шесть и девять в периоде. 6.9999999999...
8. Двоичный код.
9. 21 в базисе 4.
10. Биномиальный коэффицент.
11. Число в шестнадцатиричной системе.
12. Корень кубический из 1728.

Продаются в Uncommon Goods.

Найдено по ссылке отсюда.
Спасибо Maniac'у за ссылку.

четверг, июня 25, 2009

Статья Your Code Sucks and I Hate You

Несмотря на название, Your Code Sucks and I Hate You: The Social Dynamics of Code Reviews - небольшая взвешенная статья про то как надо делать code review. Там идет речь об open source проектах, но эти советы подойдут всем, кому приходится делать code review.

Спасибо Maniac'у за ссылку.

пятница, июня 19, 2009

Термоядерная энергетика

Около месяца назад я была на выступлении сэра Кристофера Ллевеллина Смита по термоядерной энергетике. После этого меня народ с интересом расспрашивал что да как, так что решила изложить всё это в блоге, чтобы не повторяться. Я, пожалуй, подсокращу его имя, пускай будет просто Смит.

Лекция состоялась в здании ФИАН, вход был бесплатный для всех желающих. Народу было много, в основном молодежь. Сзади меня общались какие-то ребята.
-Смотри сколько симпатичных девушек.
(Девушек, кстати, действительно было довольно много).
-Да...
-Значит они существуют.
-Да...
На доказательстве существования симпатичных девушек, интересующихся физикой, они успокоились. Математики, наверное ;-).

"Уважаемые товарищи!" - неожиданно начал Смит. Дальше было вступление на русском, но с сильным английским акцентом. Он работал некоторое время в ФИАНе, поэтому русский знает. С большим уважением говорил об ученых, с которыми там работал. После вступления он уже говорил по-английски.

Весь его рассказ целиком есть на Элементах (по ссылке текст, не видео), картинку я взяла оттуда. Здесь я расскажу всё то же самое только значительно короче.
Нефть и уголь у нас когда-нибудь да закончатся, поэтому надо что-то думать. Энергии нам надо 15,7 тераватт. Ветер, солнце и прочие экологически чистые источники энергии дадут нам максимум 6. Очевидно, не хватает.
Очень хочется получать побольше энергии от Солнца. Энергии от него идет огромное количество, но непонятно как эту энергию а)уловить б)сохранить и в)передавать. То есть вообще ничего непонятно. Нет, как-то сейчас это удается делать, но КПД там смешной получается. Работы в этом направлении продолжаются.
Смит предлагает нам другой путь. А именно электростанции на основе термоядерной реакции (AKA ядерная реакция синтеза). В процессе ядерного синтеза легкие атомные ядра сливаются более тяжелые и выделяется энергия. Удобно для этой реакции использовать изотопы водорода, дейтерий и тритий. Чтобы инициировать реакцию надо нагреть газ из смеси дейтерия и трития до 100 миллионов градусов. Есть попытки добиться холодного ядреного синтеза, то есть, чтобы реакция ядерного синтеза шла при комнатной температуре. Смит сказал, что это всё научная фантастика и холодный ядерный синтез невозможен.
Надо довольно мало легко доступного сырья, чтобы получить огромное количество энергии. Смит привел красивый пример. Из одной ванны воды (45 литров, оттуда мы берем водород) и одной батарейки для ноутбука (там есть литий, нужный для получения трития) можно получить столько же энергии сколько из 70 тонн угля. Полученной энергии хватит одному человеку на 30 лет.
Термоядерная электростанция в основе своей имеет Токамак (ТОроидальная КАмера с МАгнитными Катушками), его конструкция была разработана в СССР еще в далеком 1951 году.


Есть построенная работающая экспериментальная установка JET. Однако проблема в том, что термоядерную электростанцию нельзя сделать маленькой. Потому что отношение затрачиваемой и получаемой энергии возрастает по меньшей мере пропорционально квадрату линейных размеров установки. То есть надо сделать здоровую. И стоить это будет немерено. Сейчас делают ITER, который хотят сделать больше. Строить и экспериментировать собираются лет 40. Финансировать ее собирались несколько государств, но вот США уже перехотели, например.
Бизнесмены этим проектом не интересуются. Горизонт в 40 лет как-то никого не интересует, ну и непонятно как сохранить тут интеллектуальную собственность. Вернее, понятно, что никак.

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

В заключении немного об организации лекции. Отлично все было организовано. Была регистрация, но никакой давки. Печатные материалы хорошего качества. Просторный чистый зал, вежливые девушки.
Прекрасный перевод (а переводить это всё было очень сложно, в конце лекции задавали много весьма нетривиальных вопросов). Переводчик из кожи вон лез, чтобы перевести все корректно. Наушники для синхронного перевода раздавали всем желающим.

Ссылки по теме:
Официальный сайт проект ITER
Авария на Чернобыльской АЭС
Kardashev scale

суббота, июня 13, 2009

Twitpocalypse случился

2009-06-12 23:52:04 GMT. Идентификаторы сообщений Твиттера превысили 32х битный signed int и твиттеровцы теперь считают потери. Многие Твиттер-клиенты не выдержали этого испытания.
Особенно эпичная история получилось с Twitterrific. Его десктопная версия работает нормально, а вот версия под iPhone - нет. При этом они недавно выпускали патч, который должен был всё это починить. Не починил. Пользовали недовольны, потому что этот клиент к тому же еще и платный.
Наблюдаются проблемы с TweetDeck, Beak. Destroy Twitter продолжает работать, но новые записи создает с отрицательными идентификаторами.
Твиттер пестрит сообщениями вида

Twitpocalypse victims: Twitterrific, Tweetsville. Survivors: Tweetie, Twinkle. #twitpocalypse

Программисты спешно выпускают патчи.
Twitpocalypse ждали несколько позже, но незадолго перед ним количество сообщений в Твиттере увеличилось. Все обсуждали Twitpocalypse, я так понимаю.
Updated 14.06.2009
В комментариях поправили, что этот момент приблизили искусственно.

Мораль - программисты, будьте бдительны!

Ссылки по теме:
Основной сайт этого события. Картинка взята оттуда.
Twitterrific, TweetDeck and Destroy Twitter: 1st Victims of Twitpocalypse?

P.S. У меня Твиттера нет. :-)

Спасибо Maniac'у за ссылку.

среда, июня 03, 2009

Карта языка C++ (The C++ Lands)

Updated 18.03.2012: Эта карта безнадежно устарела. Есть новая карта С++11!

This post is outdated. Here is the new map: The C++11 Lands




English translation is below.

Updated 07.06.2009
Карта быстро расползается по Интернету. Нас уже обоср раскритиковали на reddit и обсудили на boingboing.
Поскольку карта пользуется невероятной популярностью, мы с Джимом серьезно думаем над тем, чтобы сделать вторую версию. Больше, лучше, красивее. Поэтому пишите в комментарии свои замечания, не стесняйтесь.



Язык C++, как известно, сложный и запутанный. Его сложно представить себе целиком и когда только начинаешь с ним работать в голове образуется неприятная каша. Очень не хватало общей схемы, которую я и попыталась изобразить. У меня получилась какая-то фигня и я позвала на помощь друга. И теперь, слава Джиму, у нас есть простая и наглядная карта языка C++. ;-)

Текущий вариант. Добавлены шаблоны и Qt. В разрешении 1600x1110. И, по многочисленным просьбам тех, кто собирался карту печатать - в охренительном разрешении (3298×2288).
Updated 05.06.2009
Поправили опечатку. managment->management.



Старый вариант никуда не делся, вот он.


Старая версия в большем разрешении: 2702x1886



English translation
Updated 07.06.2009
The map is very popular all over the Internet. It's discussed on reddit and boingboing.
And we are seriously thinking about making a new version of it. Bigger and better. Feel free to post your criticism in comments if you have any. The publish button is the orange one.


C++ language is quite complicated. It looks like a total mess when you start studying it. That's why I tried to draw a scheme of it. My drawing was real crap and I asked a friend to help me. And now, thanks to Jim, we have a nice and simple C++ language map.

The current version. With templates and Qt. 1600x1110. And for printing 3298×2288.


The previous one. With a typo.


Old version in higher resolution: 2702x1886

вторник, июня 02, 2009

Новый XBOX'овый контроллер

Новый XBOX'овый контроллер, вернее его отсутствие. Тот же ролик на YouTube:

Кодовое название этого чуда Project Natal. Рядом с XBOX'ом ставится девайс с видеокамерами, который распознает движения человека.

Всё это прикольно, но дьявол, как обычно, кроется в деталях. Непонятно насколько стабильно работает распознавание. Что будет при плохом освещении, распознает ли человека с бородой и в очках и т.п..
Но демка впечатляет, да.

Ссылки по теме:
E3: Microsoft Xbox throws down gauntlet with "Natal" controller

среда, мая 27, 2009

понедельник, мая 25, 2009

Статья 18 Embarrassing Game AI Bugs Caught On Tape...

В статье 18 Embarrassing Game AI Bugs Caught On Tape... Алекс разобрал несколько AI багов, выложенных на YouTube, и высказал предложения по тому как их фиксить. На мой взгляд фиксить баги по записи на YouTube - это все равно что лечить по фотографии, но, тем не менее, статья очень хорошая. Там в комментариях отметился разработчик, который за некоторые из этих багов ответственнен, интересно почитать.

Баги, в которых юниты идут в стену или ходят кругами выглядят скучно. Вот самые на мой взгляд интересные баги (по ссылке больше и подробнее :-) ).

Crysis, 2007
NPC исследует упавшую бочку, не обращая внимания на то, что она горит и вот-вот взорвется. Бочка в итоге взрывается, NPC погибает.


Crysis, 2007
Два NPC беседуют, игрок стреляет в одного из них усыпляющей пулей, один из NPC засыпает. Второй NPC продолжает беседу.




Grand Theft Auto San Andreas, 2004
Полицейские бросаются в воду, забыв что они не умеют плавать.


Ссылки по теме:
Avoiding Ten Common Game AI Mistakes

вторник, мая 19, 2009

Задачка про зеркало

Задачка, которая способна занять отдел программистов как минимум на час.

Почему в зеркале лево и право местами меняются, а верх и низ - нет? Ответ должен быть достаточно простым, чтобы его понял даже восьмилетний ребенок.

Небольшое замечание - первая мысль, что это из-за расположения глаз на голове. В таком случае предлагается повернуть голову набок и посмотреть в зеркало. :-)

Updated 19.05.2009:
Документ с подробным ответом здесь. Цитата оттуда "Надо снабдить зеркального двой­ника не нашей собственной координатной системой, а систе­мой координат, отраженной в зеркале".

воскресенье, мая 17, 2009

КРИ-2009. День третий

Сегодня был последний день КРИ, я была на двух докладах.

Роман Лут, Deep Shadows
Внедрение многопоточного рендеринга в игровой движок

Полезный вдумчивый доклад. Начался с общих рассуждений о многопоточности. Что вот, бывает "плохая" многопоточность, это когда создаем несколько потоков и делаем в них что-нибудь. Так лучше не делать, лучше анализировать код и разделять его на независимые компоненты с минимальным, четко описанным взаимодействием. Говорил про task parallel, data parallel и построение task dependency graph'а.
Что сделали у себя. Хотели task dependency graph, но было понятно, что это займет сильно много времени поэтому сделали вот что: обход сцены в одном поток, они пишет все в ring buffer, откуда читает код рендеринга, который находится в другом потоке. Заняло это 2 недели разработки и 3 месяца отладки. Получили увеличение производительности в 1.5 раза.
По ходу рассказа хвалил Intel TBB. Они даже портировали TBB под XBOX. Рассказывал, что пользовались Intel Thread Checker'ом. Все это вызвало оживление в стане Интела :-).
Упомянул emergent DirectX command buffer library, которая позволяет распараллелить работу с DirectX версии ниже одиннадцатой, который, как известно, не поддерживает работу с многопоточностью.

Евгений Макаров, NVIDIA
NVIDIA APEX - широкий взгляд на технологии PhysX

Доклад был в разделе арт, пошла на него, потому что его рекомендовали на лекции по CUDA. Но был действительно в основном арт, много красивых картинок, по программингу практически ничего. Для себя узнала, что все это есть и под Nintendo Wii.


Давайте в заключение скажу пару слов об организации КРИ. Организовано все было хорошо. Мест всем хватало, возникавшие на докладах проблемы с слайдами разрешались быстро (и было их мало, надо признать). Не тесно, не душно, чего еще надо...

Updated 18.05.2009: В комментариях поправляют, мест хватало не всегда.

Итог дня: Есть TBB под XBOX, есть PhysX под Wii

КРИ-2009. День второй

Доклады, на которых я побывала сегодня.

Константин Колчин, NVidia
Краткий обзор Direct3D 11

Тут было неожиданно много народу.
Константин рассказал, что в новом Direct3D будет тесселяция, многопоточный рендеринг, динамическое подключение шейдеров, улучшенная компрессия текстур. Сказал, что все это более подробно описано в документации. На некоторых слайдах был код, был он мелкий и читался плохо.

Александр Харламов, NVIDIA
GPU computing или параллельные вычисления в играх

Сначала долго рассказывал, что такое CUDA и как она работает. По-моему, это было невозможно усвоить, не зная ничего про CUDA до этого. Очень уж запутанная и неочевидная штука. Я знала, поэтому более-менее следила за ходом доклада. В самом конце Александр предложил на CUDA обсчитывать системы частиц в играх. Его спрашивали, чего еще там можно хорошо посчитать - он предложил посетить доклад по PhysX. Он будет завтра, я туда схожу.
Про архитектуру CUDA информации полно, это не очень интересно. Чего было, о чем я раньше не знала - CUDA работает на том же устройстве, что и OpenGL/Direct3D. Поэтому, когда используешь CUDA одновременно с ними, надо как можно реже переключаться между CUDA и графическим API.
На основе CUDA строятся новые API - DirectX Compute и OpenCL, но, как я поняла из дальнейшего обсуждения, они находятся в зачаточном состоянии.

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

Тут настало время обеда, поэтому о еде на КРИ. Еда не входит в те 6000 рублей, что я заплатила, ее можно было купить отдельно, я пожадничала, да и поздно было уже. Поэтому я питаюсь в окрестностях, и я такая не одна. Во время обеда к ларькам с хотдогами стоят очереди. В местном Макдональдсе тоже очень много участников КРИ :-). Поела в каком-то итальянском ресторанчике рядом с Макдональдсом, там тоже был народ с КРИшными бэджиками.

Владимир Ческис, Nival Online
Тюнинг красивого боя в MMORPG

Владимир показывал записанные анимационные ролики из Аллодов Онлайн, рассказывал где чего было не так как правили. Тут важно, чтобы анимации атаки одного персонажа и защиты другого работали синхронно, чтобы не было такого, что один еще не ударил, а второй уже заблокировал удар. Но перессказывать это бессмысленно, смотреть надо.
Было много вопросов, особенно народ заинтересовался роликом с некромантом, он там красиво так летучих мышей на жертву направлял. Вопрошающие пытались выяснить, возможна ли ситуация, когда мыши жертву не настигнут. Ответ - нет, не возможна.
Это был самый зрелищный доклад из тех, что я видела. Однако при этом создавалось впечатление, что докладчика читать доклад заставили силой и он этому явно не рад. Говорил тихо, часто вздыхал. Доклад осилили не все.


Да, WiFi на КРИ таки есть. В районе Кракена-Нивала-далее везде, wifi есть в комнате аструма. Но сама я не проверяла.

Вчера не было фоток, сегодня будет много.

Nova Online, самый красивый стенд:



Акелла, Left4Dead стерео. Я поиграла, прикольно. Нужны специальные очки и монитор с разверткой не меньше 120Гц.


Стенд Сталкера


Ярмарка проектов


Еще стенды




А Микрософт просто поставили два XBox'а. Народу - не протолкнешься.


Фотография специально для Джима


Итог дня: NVidia хорошо подготовлена, мыши некроманта неизбежны.

пятница, мая 15, 2009

КРИ-2009. День первый.

Как и обещала, буду рассказывать о конференции разрабочиков игр, которая проходит в Москве прямо сейчас. В прошлый раз я была на КРИ в далеком 2005 и буду сравнивать с ним, больше мне сравнивать не с чем.

Стендов очень мало. Народу тоже сильно меньше, чем в 2005. WiFi'я нет. Вернее есть, но какой-то Comstar за деньги, это не интересно.

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

После посещения КРИ вы твердо усвоите одну вещь - Аструм нанимает.

Об этом висят плакаты у входа, рекламные листовки кидают в пакет участников. Объявления висят даже на дверях туалета. HRы Аструма сидят в отдельном зале (!). Меня этот факт несколько удивил. Обычно на конференциях запрещают хантить народ, потому что тогда компании отказываются присылать туда своих сотрудников. На HighLoad2007 очень по этому поводу наезжали на Яндекс, даже заставили убрать один слайд.

Собственно доклады, на которых я была сегодня.
Илья Пшеничный, Creat Studios
Разговоры про жизнь


Илья попробовал активно в доклад вовлечь зал. Программеры из зала реагировали вяло, доклад тянулся медленно. Но зато доклад отличался от других, потому Илье бонус за смелость. Что запомнилось из полезного - рассказал, что FMOD+многопоточность - это тяжело, что просто так Хавок для физики машинки прикрутить не удастся, надо будет много тюнить...

Александр Лазарев, Intel
Многопоточный интеллект - это победа! Построение N-поточной масштабируемой оболочки.


На синтетическом примере показывал, что код AI можно распараллелить. Меня по этому поводу обеспокоил один вопрос - как это все отлаживать. Александр посоветовал Intel Thread checker и добавил, что да, проблем прибудет, потому решение параллелить AI должно быть очень оправдано.

Задача Интела понятна - им надо железо и тулзы продавать. И железо, и тулзы у Интела традиционно хорошие. (Intel vTune - супервещь). Но распараллеливая AI вы открываете ящик Пандорры. И оттуда такое полезет - мало не покажется. И отлаживать код придется вам, а не Интелу.

Арсений Капулкин (AKA Zeux), Creat Studios
SPU Render

Гвоздь программы. Большой подробный рассказ по делу, поэтому тут будет много.
Вообще обычно организаторы выкладывают записи выступлений на КРИ и это тот случай, когда доклад следует послушать целиком, а не довольствоваться перессказом. Мой перессказ - он для того, чтобы понять интересна вам вообще эта тема или нет.
Zeux сказал, что доклад большой, слайдов много и времени на вопросы не останется. И понеслась.
Если совсем кратко, то доклад о том, как в игре Smash Cars 2 под PS3 код рендеринга переносили с PPU на SPU.

Рендеринг, который работал на PPU, занимал 12 ms. Что было много и они решили перенести его на SPU.

Немножко информации про SPU, чтобы дальше было понятнее. SPU всего шесть штук. Речь идет о работе на одном из них. У SPU есть Local Storage (дальше LS) 256 Кб памяти под код и данные. Код не может работать с данным, которые лежат не в LS.
256 Кб - это не много, но у них код занимал максимум 80 Кб в дебаге, так что все влезало.
Доступ к внешней памяти через DMA.

Перенос кода происходил в три этапа.

Этап 1. Собрали прототип.
Цель - чтобы рендеринг заработал хоть как-то. Использовали пока синхронные DMA вызовы.
В силу особенностей архитектуры возникли проблемы с виртуальными фукнциями и инкапсуляцией. С тем, что vptr'ы не туда показывали, разобрались так: вообще отказались от виртуальных функций и использовали enum'ы.
Проблему с инкапсуляцией решили волшебной строкой

#define private public

Как происходит синхронизация PPU и SPU. У них PPU всегда ждет SPU. А SPU - достаточно быстрый.

Этап занял 3 дня. Время рендеринга 25 ms.

Этап 2. Оптимизация данных
Синхронные DMA вызовы, понятное дело, тормозили.
Начали они с того, что переуложили данные, чтобы их можно было загрузить все за один запрос. Сделали software cache. И сделали вызовы DMA асинхронными. В процессе работы время рендеринга уменьшилось сначала до 12ms, потом до 8ms. Сколько времени заняла работа не помню, по-моему тоже 3 дня.

Этап 3. Оптимизация кода.
Использовали SNTuner, SPUsim.
Этот кусок доклада похож на экскурсию в восьмидесятые. Использовали loop unrolling, branch flattering, ибо ветвления дорогие и они пытались уменьшить их число. Заменили switch по числам 0..N на function pointer table, получили ускорение в полтора раза.
Еще использовали branch hinting, который Zeux назвал шагом отчаяния и который принес десятипроцентный прирост производительности. Для branch hinting есть такой gcc-specific синтаксис, который говорит, что "вот этот if скорее всего не сработает".
Меняли работу с LS. Запись/чтение только по 16 байт.
Времени это у них заняло 5 дней. Время рендеринга стало 2 ms.


Итог дня: без WiFi'я плохо, Creat - молодцы.