Сегодня вас ждет рассказ об исходном коде Doom 3 и о том, насколько он красив.
Да, красив. Позвольте мне объясниться.

Метод недопустимой операции:
Разделить кошку на ноль,
после чего она станет бесконечно большой,
так что её будет невозможно упустить.
[АбсурдопедиЯ]

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

Итак, имеем задачу последовательной перестановки байтов в каждом слове массива (big-endian <-> little-endian) и суммирования всех слов в одно (reduction). Оставим пока в стороне задачу распараллеливания, ибо ее решение близко к тривиальному, и для нас пока не представляет интереса.

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

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

Я поделюсь 30 практиками для достижения максимальной производительности приложений, которые этого требуют. Затем, я расскажу, как применил их для коммерческого продукта и добился небывалых результатов!
Приложение было написано на C# для платформы Windows, работающее с Microsoft SQL Server. Никаких профайлеров – содержание основывается на понимании работы различных технологий, поэтому многие топики пригодятся для других платформ и языков программирования.

Перевод нескольких статей, в т.ч. Shawn Burke (thanks!), ScottGu(thanks!), Paul Krill (thanks!) и John Robbins (First great thanks! Second great thanks!)

Конечный результат, к которому мы здесь стремимся — возможность отладчиком любой IDE войти «внутрь» вызова .Net Framework методов. Я надеюсь, этот пост содержит все, что вам понадобится. Последние несколько недель мы провели много экспериментов и собрали очень много данных по этому вопросу. И мы хотим поделиться полученным опытом с сообществом.

Изначально для основного освещения одной из комнат, где шёл капитальный ремонт, планировалась обычная люстра. Но недавно мне на глаза попалась суперяркая светодиодная лента Ultra 5000 со светодиодами smd 5630 торговой марки Arlight. Решение было принято быстро, окончательно и бесповоротно — хочу такую ленту в качестве основного света в комнате.

Введение

Как известно размер .NET фреймворка увеличивается от релиза к релизу. Но, к сожалению, не у всех потенциальных пользователей широкий безлимитный канал.
Стояла задача — определить какой .NET Framework, поддерживающий WPF, оптимален с точки зрения простоты распространения. Ведь не хочется терять пользователей из-за лишних мегабайт в установщике.
Т.е. надо было принять решение какой .NET Framework использовать: .NET 3.0 или .NET 3.5.

Неожиданное продолжение этого поста (честно не ожидал резонанса), поэтому часть 2 хардкорных трюков, в которой речь пойдет немного о другом, пока подождет.
Итак, в двух словах, что изменилось: добавлен контрол и тестовое приложение для WindowsForms, вариант WPF немного изменился, рефакторинг-причесалинг, добавился threadsafe и контрол теперь может нормально ресайзиться в рантайме (включено в сэмплы, но не советую разворачивать на полный экран — это реально пугает). Спасибо камрадам, указавшим на ошибки и недостатки и теперь теперь проект гордо 0.5 beta. Можно сразу отправиться за обновлением на razorgdipainter.codeplex.com/, кому интересны подробности прошу под кат.

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

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

Half-Life 2 была лишь мимолетным слухом, будоражившим умы геймеров, но на выставке E3 в мае 2003 года демонстрация продукта произвела на публику настолько сильное впечатление, что ещё невышедшая видеоигра получила несколько наград. В Сиэттле говорили о дате релиза в сентябре 2003 года, и якобы незаскриптованные сцены геймплея на E3 заставляли в это верить.

В то же время на другом конце света, в крошечном (чуть больше двух тысяч человек населения) городке Шёнау в Германии проживал со своим отцом 22-летний Аксель Джембе, хакер, которому было уготовано сыграть в этой пьесе главную роль. Мир взлома затянул геймера случайно — однажды он скачал и установил программу-вирус sdbot, маскировавшийся под генератор ключей Warcraft III, но вместо того, чтобы почистить систему и забыть о трояне, Джембе подверг продукт обратному инжинирингу и изучил принципы её работы.

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



Для имитации этого эффекта в играх используется механизм, называемый tonemapping.

tonemapping — процесс проекции всего бесконечного интервала яркостей (HDR, high dynamic range, от 0 и до бесконечности) на конечный интервал восприятия глаза/камеры/монитора (LDR, low dynamic range, ограничен с обоих сторон).

Для того, чтобы работать с HDR, нам понадобится соответствующий экранный буфер, поддерживающий значения больше единицы. Наша же задача будет состоять в правильной конвертации этих значений в диапазон [0..1].

Сегодня мы будем заниматься постпроцессингом изображения в DirectX.

Как известно, в темноте зрение человека обеспечивается клетками-палочками сетчатки, высокая световая чувствительность которых достигается за счет потери цветочувствительности и остроты зрения (хотя палочек в сетчатке и больше, они распределены по гораздо большей площади, так что суммарное «разрешение» выходит меньше).

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

В результате мы получим что-то вроде следующего (смотреть на весь экран!):

До: унылый польский шутер


После: финалист IGF и лауреат всех наград E3

Herb Sutter (автор Exceptional C++, бывший глава ISO C++ standards committee, мистер Free Lunch Is Over и прочая, и прочая) работает в Microsoft и иногда по средам читает атомные лекции.

Я наконец-то на одну такую попал, и очень радовался. На умных мужиков всегда радостно поглядеть и послушать.
Для отчета — кроме Херба, видел живого Олександреску и живого Walter Bright (который "D").

Лекция называлась «Machine Architecture: Things Your Programming Language Never Told You» (здесь можно скачать презентацию и видео) и была про конкретную часть abstraction penalty — Memory Latency.

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

Сразу уточнение: Bitmap 200x100 на компе с быстрой памятью и i7 3930K на 1366. Но, это честный System.Drawing.Bitmap.
Вводная: приложение типа осциллографа. Ссылка на готовый проект с фронтэндом в конце статьи.
Как же быстро рисовать его на экран? WriteableBitmap хорош, быстр, и он лучшее решение для WP, WinRT, WPF. Но занудного старпёра-кодера также волнует WinForms, .Net 2.0, Win2K (да-да, в некоторых гос.органах до сих пор теплый ламповый Win2K).
Далее, я обратил внимание на DirectX, тем более у нас для WPF появился полезный контрол D3DImage. Я перепробовал много движков, но ни один из них не давал удобного изящного способа рисовать GDI+ Bitmap из памяти. Некоторые работали и вовсе только с DX10-11. Ближе всех к цели оказался SlimDX. В любом случае, фронтэнд для контрола оказывался некрасивым. Все эти движки… мягко говоря избыточны, для моей простой задачи.