Вчера я делился своим впечатлением от интервью с Тим Свини из Epic Games. Напомню его основную мысль: "Компьютеры - хорошая штука для чего угодно, только не для игр". А сегодня мне на глаза попалось интервью с Алексом Джоном (Alex St. John) - CEO WildTangent и бывшим "игровым евангелистом" Microsoft.

В целом Алекс и Тим видят проблемы игровой индустрии примерно в одном свете, а вот выводы делают совершенно разные. Начну с такой вот метафоры Алекса:

Представьте, что вы пришли в продуктовый магазин:
- Я хотел бы купить шоколадку, продайте мне что-нибудь…
- О да, у нас есть шоколад в двадцатилитровых бочках, по $1000 за бочку.
- Я, конечно, люблю шоколад, но не до такой степени… Мне бы Hershey за 50 центов…
- Идите лесом, у нас тут только бочками. Платите $1000 или ищите другой магазин!

Перед тем, как продолжить цитировать Алекса, я должен сделать небольшое лирическое отступление. Некоторые мои коллеги считают, что в своем блоге я обязан строго следовать позиции Intel. И если мое мнение не совпадет с "мнением редакции", меня уволят. Лично я вижу свои служебные обязанности несколько иначе. Небольшой эксперимент поможет нам докопаться до истины: я сейчас буду коротенько пересказывать интервью Алекса, с мнением которого в целом согласен. Поэтому на всякий случай - прощайте и всем удачи! .

Intel и Microsoft надо бы оторвать руки за те тупые действия, благодаря которым компьютеры не стали той великолепной игровой платформой, которой они могли стать. Low-end PC прекрасно подошли бы для игр, если бы не убогая интегрированная графика и не раздутая операционная система. Intel привык работать с корпоративными клиентами, и в этом его беда – считает Алекс. Intel нужно продавать как можно больше "главных чипов" (процессоров), поэтому на протяжении долгих лет он принуждал OEM производителей продвигать системы с интегрированной графикой. Это понятно – на корпоративном рынке GPU вторичен, а CPU первичен. Но в игровой индустрии все должно быть "наоборот".

Что мы имеем в сухом остатке? Low-end PC появились задолго до игровых приставок, они продаются в сотни раз лучше чем консоли, они имели огромный исторический потенциал как игровая платформа… Но, к сожалению, рынок low-end компьютерных игр попросту уничтожен недальновидной политикой Microsoft и Intel.

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

В то же время, Алекс возлагает серьезные надежды на следующее поколение графики Intel (и в этом его мнение расходится с мнением Тима) – в новом поколении чипов возможности GPU и CPU будут объединены. Такие чипы в теории достигнут производительности в 5-10 раз выше, чем любое современное решение. Именно они будут составлять основу Low-end PC и лэптопов через пару лет. Конечно, запуск новой архитектуры займет время, но Алекс верит, что именно она реинкарнирует рынок компьютерных игр.

А что же с игровыми приставками? Текущее поколение приставок будет последним, считает Алекс: Sony и Microsoft переоценили себя. Затраты на разработку уникальных платформ оказались непомерно велики. Миллиарды долларов! Чтобы вернуть такие деньги нужны годы присутствия платформы на рынке. Годы, в течение которых конкуренция будет заставлять инвестировать все больше и больше средств в "железо". Мы видели, как ушли с рынка SEGA и Colecovision. Совсем скоро кто-то станет следующим.

И все-таки, где же деньги? Продавцы приставок и Hi-End компьютерных игр продают коробки, почти как те продавцы шоколада бочками. Неважно – один час вы играете в день, или 22 часа – платите $100 за коробку!

Но позвольте, мы живем в эпоху микроплатежей, сервисов по подписке и ad-ware. Любопытный факт – в 1998 рынок коробочных игр для PC составлял $2.2 миллиарда, сейчас он составляет примерно $1.2 миллиарда. Коллапс? Минутку, не одними коробками мы живем в 21-м веке! $1.2 миллиарда заработали парни из Blizzard на подписке WOW (смотрим на цены). Замечу, что им не нужно бороться с пиратами, заниматься логистикой поставок, и т.п.. Хочешь играть – плати за подписку! Всего-то дел… На $1.2 миллиарда .

Еще дальше пошла компания WildTangent со своим Orb. Строго говоря, они собираются совершить революцию, не имея революционных идей. Ведь всегда можно скрестить ужа с ежом! Идея в следующем: вы покупаете некий манипулятор (как у приставки), который подключаете к любому компьютеру. Сам по себе манипулятор представляет собой не только позиционирующее устройство, но и ключ для доступа к нескольким сотням коллективных онлайн игр. Оплачиваться данный сервис будет либо микроплатежами (например, SMS), либо по принципу ad-ware: посмотри спонсорский рекламный ролик и играй.

Учитывая опыт Алекса, стоит признать, – его massive multiplayer online ежовый уж выглядит вполне логичным. Впрочем, Тим тоже товарищ весьма опытный, и в ставке на консольный рынок тоже есть своя логика.

А на кого бы поставили вы?

Всем удачи!

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

О возможностях последнего поколения интегрированной графики Интел и о том, как использовать их по максимуму, будет рассказано на соответствующей лекции на Конференции Разработчиков Игр (КРИ) 2008 двадцатого апреля. Так что - не пропустите.

Кстати, такая требовательная к ресурсам игра, как "Кризис", прекрасно работает на интегрированной графике Интел (конечно, при минимальных настройках графики).

На русском THG опубликовано интервью с Тимом Свини (Tim Sweeney), основателем и CEO компании Epic Games, известной своим легендарным движком Unreal.

Тим высказал несколько интересных мыслей, которые перекликаются с нашей дискуссией «блеск и нищета игровой индустрии». В частности, он прошелся по идеологии hi-end геймерских компьютеров: "Они как спортивные машины. Они всегда на слуху, о них постоянно пишут, но только немногие могут себе их позволить. "

"Разница в производительности между high-end и low-end компьютерами что-то порядка 100x" – считает Тим. "Ну, это он загнул" – подумал я, и решил непременно взять какой-нибудь игровой тест и сравнить, скажем, интегрированную интеловую графику и что-нибудь класса 8600-8800 GT. Удивительно, но как раз сегодня ребята с iXBT со всем этим разобрались. Вот тут лежит отличный (рекомендую!) онлайн-калькулятор, где можно сравнить производительность типовых связок "видео+процессор".

В абсолютных попугаях Core 2 Quad Q6600 + 8800GT в 13.5 раз обгоняет Pentium E2160 на интегрированной графике Интел. А в играх типа F.E.A.R так вообще в 50(!) с лишним раз. Надо отметить, что Core 2 Quad Q6600 на 8800GT - далеко не Феррари. Это вполне доступная конфигурация, примерно $1000 за системный блок. А если посмотреть в сторону машинок вроде SkullTrail (да поможет вам Google! ), который мы будем показывать на КРИ, то разница как раз и будет все 100x .

Но это еще не самое интересное! Если в iXBT калькуляторе выбрать вариант Pentium E2160 + 8800GT, то он все равно "сделает" конфигурацию Core 2 Quad Q6600 + интегрированная графика почти в 10 раз! Вывод делайте сами.

Возвращаемся к Тиму. "Встроенная графика Intel не работает. И не думаю, что когда-нибудь заработает" – считает он. Разумеется, с этим можно поспорить (см. статью "Интегрированные графические карты Intel® – рассчитывайте на них!" Виктории Жислиной). А мое личное мнение – не работает, и правильно делает! Она и не должна работать в сегменте "быстрых" игр, где все решают детализация и FPS. Другой вопрос к маркетингу, который всеми правдами и неправдами пытается заставить нас поверить в играбельность графики за "ноль долларов". Может, стоит ориентироваться только на сегмент относительно "легких" игрушек? Достаточно большой сегмент, кстати.

К тому же, Тим сам говорит, что не имеет практического смысла затачивать одну игру под hi-end и под low-end системы, потому что это будут две совершенно разные игры, а соответственно – разный маркетинг и разные целевые аудитории.

Там же есть интересный прогноз на будущее графических API. В двух словах, API класса DirectX 10 – отличная идея, т.к. всегда будут разработчики, которым удобно использовать API. Однако, наблюдается значительный рост вычислительной мощности как CPU, так и GPU. Соответственно, уже в ближайшее время программный рендеринг станет вполне приемлемым по скорости (не важно на CPU он рассчитывается или на GPU), и достаточно удобным с т.з. независимости от конкретной аппаратной реализации. Тим считает, что DirectX станет скорее программной библиотекой, чем интерфейсом к "железу" как сейчас. Кстати, разработчики, тут есть о чем задуматься – Тим входит в Microsoft Advisory Board для DirectX

А что думаете вы о будущем игр и игрового железа?
Всем удачи!

А вспомнил я про эту ссылку это потому, что начитался сегодня описаний игр с нашего конкурс Intеl Game Demo. Если вкратце, там народ делится идеями своих будущих игрушек. Местами смешно, но показывать где именно не имею права т.к. я лицо официальное - сходите, полистайте "все конкурсные работы"...

Удивительные вещи происходят в игровой индустрии. С одной стороны, аналитики в приходят в экстаз от мега-успешных проектов типа WOW и пророчат рост годовой выручки от MMORPG (коллективных онлайн игр) аж до $11.8 миллиардов к 2011 году. В прошлом, 2007 году, суммарный доход индустрии (включая продажи консолей и прочей оснастки) составил $8.85 миллиардов – задумайтесь об этой цифре!

Однако, если оторваться от столь радужной картины взглянуть внимательно на интересующие нас детали, то не все так гладко. Доля PC игр составила лишь 14%. Причем, значительную часть продаж PC игр в количественном выражении представляют буквально несколько тайтлов, включая тот же WOW и Sims 2 со своими многочисленными адд-онами. Все это детский лепет по сравнению с числом проданных копий, к примеру, консольной игры Halo 3...

Являясь человеком «компьютерным», хотя и не имеющим ничего против игровых приставок, я немного призадумался над этими цифрами. Давайте посчитаем вместе: Мой домашний компьютер стОит примерно $2000. Он нещадно тормозит на разрешениях 1600x1200. Тот же 3DMark 2006 в некоторых тестах выдает не более 15fps! Да, у меня не самая крутая видеокарта – GeForce 8600 GTS, но карточка класса 8800 GTX стоит около $500, а это, между прочим, стоимость новенького x-Box или PS3. Целиком, и прямо в упаковке.

И это еще полбеды. Настоящая беда в том, что большинство игр вообще не позволяют поднять разрешение выше чем 1280 на 1024, или позволяют, но превращаются при этом в пошаговые стратегии с рекламными паузами в виде синего экрана.

Игра Sopwith, 1984 год

Почти 25 лет назад вышла игра Sopwith (см. картинку). Что революционного появилось в играх для PC с тех пор? Скорость? Позвольте, Sopwith просто «летал» на моем IBM XT. Графика? О графике я уже говорил. Гемплей? Точно нет! Командный режим? Так и в Sopwith можно было играть вдвоем.

А на дворе-то уже как третий месяц идет 2008-й год… В чем же проблема рынка PC игр? В дороговизне видеокарт и процессоров для геймеров? В отставании программного обеспечения? В плохом геймплее? А может быть проблема в отсутствии хороших идей?

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

Всем удачи!

За последнее время мне довелось наблюдать несколько таких попыток, в которых параллельный код был написан при помощи библиотеки Threading Building Blocks (TBB). К удивлению экспериментаторов, их простые параллельные программы порой не только не показывают ускорения по сравнению с обычной, последовательной версией, но даже и проигрывают в скорости! И далеко не всегда автор может (или хочет) разобраться, что к чему.

Разбираться приходилось мне, как одному из разработчиков TBB. А поскольку мне уже не раз предлагали вести сетевой журнал-блог на Intel Software Network, я в конце концов решил попытаться, и начать с анализа таких вот примеров. Они, с одной стороны, просты и понятны: не каждый готов начать параллельные эксперименты со сколь-нибудь сложной программы, а написать цикл, суммирующий элементы вектора – дело недолгое. С другой стороны, они весьма познавательны, причём порой именно в силу простоты.

Начну как раз с суммы элементов вектора. Вопрос о том, почему столь простая программа медленнее в параллельной TBB версии, чем в не-параллельной, возник на форуме TBB (см. тему “performance of parallel_for”). Я приведу здесь лишь часть кода:

#define REAL double
#define MAX 10000000
class SumFoo {
    REAL *a;
    REAL sum;
    ...
    void operator()(const blocked_range<size_t>& r) {
        REAL *arr = a;
        for(size_t i=r.begin(); i!=r.end(); i++) sum+=arr[i];
    }
};
void ParallelSumFoo(REAL a[], size_t n, size_t gs) {
    SumFoo sf(a,n);
    parallel_reduce(blocked_range<size_t>(0,n,gs), sf);
    ...
}
class SerialApplyFoo {
    REAL *a;
    size_t len;
    double sum;
public :
    SerialApplyFoo(REAL *array, size_t length) : a(array), len(length){
        sum = 0.0;
        for(size_t i=0; i<len; i++)
            sum += a[i];
    }
    …
};
int main() {
    task_scheduler_init init;
    REAL *array = new REAL[MAX];
    ...
    SerialApplyFoo sf(array, MAX);
    ParallelSumFoo(array, MAX, GRAINSIZE);
    ...
}

На двухъядерном процессоре Intel® Core® 2 Duo, вместо ожидаемого двукратного ускорения, параллельный код работал почти вдвое медленнее, чем последовательный; на моём ноутбуке, к примеру, 0.08 сек против 0.044. В чём дело?

Прежде всего, давайте посмотрим, а что произойдёт, если параллельный код запустить последовательно, в одном потоке. С TBB это можно сделать двумя способами: либо явно указав количество потоков (в нашем случае, один) конструктору объекта инициализации библиотеки task_scheduler_init, либо установив параллельному алгоритму так называемый «размер зерна» (grain size) равным количеству итераций цикла. Я воспользуюсь первым способом:

    task_scheduler_init init(1);

Результат может показаться неожиданным: 0.21 сек, почти впятеро медленнее, чем исходный последовательный код! Такое замедление явно не из-за использования TBB. Неудивительно, что и на двух ядрах нет выигрыша.

Всё дело в оптимизации, проводимой компилятором. Цикл суммирования в последовательной версии очень прост для оптимизации; компилятор знает о нём всё, начиная от константной длины (передача через аргумент для компилятора не помеха), заканчивая тем, что результат sum должен быть виден только по выходу из конструктора. Поэтому он может сгенерировать очень эффективный машинный код, к примеру, вот такой (я использовал Visual Studio* 2005):

            fldz
            lea      eax, DWORD PTR [edi+010h]
            mov      ecx, 0x2625A0h
main+0x105: fadd     QWORD PTR [eax-16]
            add      eax, 0x20h
            sub      ecx, 0x1h
            fadd     QWORD PTR [eax-40]
            fadd     QWORD PTR [eax-32]
            fadd     QWORD PTR [eax-24]
            jnz      main+0x105

0x2625A0 – это 2500000, четверть длины массива. Компилятор развернул четыре итерации цикла в одну, снизив расходы на обслуживание цикла. Промежуточные результаты вычислений накапливаются в регистре процессора, и только конечный результат будет записан в память. На каждую итерацию исходного цикла ровно одна операция чтения данных из памяти.

В случае использования TBB для компилятора всё не так просто. Начало и конец цикла определяются полями объекта, переданного по ссылке, длина цикла во время компиляции неизвестна, результат накапливается в поле данных “живого” объекта. Компилятор вынужденно более консервативен, и результат не замедлил сказаться:

execute+0x57: fld      QWORD PTR [edi]
              add      ecx, 0x1h
              fadd     QWORD PTR [edx+08h]
              add      edi, 0x8h
              fstp     QWORD PTR [edx+08h]
              cmp      ecx, DWORD PTR [esi+08h]
              jnz      execute+0x57

Здесь одна итерация цикла обрабатывает один элемент, но при этом задействует 3 операции чтения (!) и одну – записи. Помимо элемента данных, каждый раз подгружаются из памяти значение конца цикла для сравнения и промежуточная сумма, которая затем сохраняется и на следующей итерации подгружается снова.

Изложив всё это в форуме, я добавил, что тест «отдаёт предпочтение» последовательному коду, и этим, боюсь, направил автора не в ту сторону. В попытке улучшить тест, автор ввёл чтение размера массива с клавиатуры и заменил в не-параллельном коде объект на функцию:

REAL SerialSum(REAL *a_, unsigned long int start, unsigned long int end) {
    REAL sum = 0.0;
    for(unsigned long int i=start; i<end; i++)
        sum += a_[i];
    return sum;
}

Первое изменение делает тест более реалистичным и несколько усложняет развёртывание цикла; второе никак вообще не влияет, потому что в новой функции промежуточная сумма накапливается в локальной переменной, которая точно так же может храниться в регистре процессора. А чтобы решить проблему, надо в параллельный код внести изменения, которые помогут компилятору применить оптимизацию, а именно – использовать в operator() локальные переменные:

    void operator()(blocked_range<size_t> &r) {
        REAL local_sum = 0;
        const size_t end = r.end();
        for(size_t i=r.begin(); i!=end; i++)
            local_sum+=a[i];
        sum += local_sum;
    }

И вот какой получен машинный код:

              fldz
execute+0x58: fadd        qword ptr [edx]
              add         edx,8
              sub         ecx,1
              jne         execute+58h
              fadd        qword ptr [edi+8]
              fstp        qword ptr [edi+8]

Последние две инструкции – добавление локального результата к полю sum. Как и в последовательном коде, мы получили одно обращение к памяти на итерацию, и это сразу сказалось на скорости: теперь параллельный код выполняется 0.033 сек на двухъядерном процессоре. Ускорение достигнуто, но с коэффициентом 1.33, а не 2. Почему? В этом попробуем разобраться в следующий раз.

Вывод: при разработке тестов на производительность, да и просто программ, необходимо учитывать, что использование классов и функций TBB усложняет компилятору работу по оптимизации, что особенно негативно сказывается на простых алгоритмах. Грамотное использование локальных переменных способствует лучшей оптимизации и быстродействию параллельного кода.

А почему бы мне не злоупотребить служебным положением и не обратиться к общественности? Итак, мы ищем веб-разработчика в команду Intel Software Network. В Нижегородском отделении Intel открыта позиция “ISN College Intern”, что на русский язык можно перевести как “студент-практикант”. Иными словами, кандидаты должны быть студентами дневного отделения вуза или аспирантами. Предстоит работа на многих фронтах – начиная от подготовки материалов к публикации и заканчивая тестированием, отладкой и доработкой нашей многосложной инфраструктуры :).

Формальные требования к кандидатам:

• Хорошее понимание веб-технологий и практические навыки работы с ними
• Приличное владение HTML, CSS, JavaScript
• Понимание принципиальных основ WEB 2.0 сервисов (блоги, RSS и т.п.)
• Некоторый опыт программирования для платформ Windows* либо Linux*
• Навыки общения, хороший уровень владения русским языком

Кроме того, приветствуется:

• Опыт работы с ASP.NET* или PHP
• Опыт использования платформ Community Server* и Word Press*
• Понимание основ проектирования пользовательских интерфейсов
• Владение английским языком

Еще более приветствуется наличие персонального блога - на любую тему.

Если вы или ваши знакомые заинтересованы в данной позиции, - добро пожаловать по этой ссылке. Найдите вакансию с номером 547885 и прикрепите к ней свое резюме (желательно на английском языке). Если все это у вас получится – считайте, что первый этап отбора успешно пройден.

Удачи!

Вчера мне прислали ссылку на сайт некой компании TIOBE Software, которая занимается консалтингом, и в том числе – анализом кода на предмет его соответствия неким стандартам качества… Впрочем, не это меня заинтересовало.

На их сайте есть рейтинг “популярности” языков программирования, который называется просто и с достоинством – “TIOBE Programming Community Index”. Насколько я понял из описания, данный индекс составляется исходя из статистики поисковых машин, и основывается на “доступности опытных программистов, курсов и поставщиков решений” (конец цитаты).

Первые 10 строк, под картинкой ссылка на полную таблицу.

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

Во-первых, из 20 “наиболее популярных” языков я когда-либо использовал только 9. Думаю, это нормально :). О четырех языках - SAS, D, Lua и Logo - я вообще не имею никакого представления, что немного меня беспокоит. Причем два из этих четырех языков (Lua и Logo) демонстрируют какой-то невероятный рост популярности. Видимо, я что-то важное в последнее время упустил :).

Что еще интересно – большинство из языков, упомянутых в таблице, имеют средства распараллеливания. Те, где это в принципе возможно :). Используются ли эти средства в реальной жизни? Ситуация с C++, Java и .NET вроде ясна, а вот что с PERL и Python? Вопрос тем, кто пишет на подобных языках - насколько критичны для ваших типовых задач механизмы распараллеливания? И насколько они удобны для вас?

По сумме баллов в трех турах bugman занимает сейчас пятое место, а в целом Россия удерживает пять мест в двадцатке: 5-е, 9-е, 11-е, 13-е и 15-е. Очень неплохо, ведь в конкурсе участвуют программисты из множества стран. Желаю нашим программистам дальнейших успехов: впереди еще 9 этапов и главный приз, который, я надеюсь, приедет в Россию :).

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

Марианна Светлосанова награждает победителей

Стив Чейз поздравляет участников конкурса

Андрей Нарайкин с незапланированной официальной речью

Андрей Нарайкин делится секретами оптимизации

А теперь ссылки на архивы с файлами большого размера:

Часть 1 (~3.3Mb)
Часть 2 (~3.6Mb)
Часть 3 (~2.6Mb)

И еще раз спасибо Юле за фотографии!

PS: Если кому-то понадобится еще больший размер - не стесняйтесь, пишите!