Рубрика «Блог компании Инфопульс Украина» - 5

Реинкарнация графического отладчика PIX для DirectX 12 - 1Я люблю графические отладчики. Обычные я тоже люблю, но графические — больше. Они дают ощущение сродни заглядыванию за кулисы театра во время выступления: «ага, вот эта декорация крепится так, а этот луч света падает отсюда, а у этого шкафа нет задней стенки...». Графический отладчик пробрасывает мостик понимания между текстовым кодом приложения и полученной красивой картинкой.

Но индустрия не балует нас обилием подобного инструментария. Есть графические отладчики от Intel, NVidia и AMD, но они не работают на чипах конкурентов и предназначены не столько для разработкиотладки, сколько для бенчмарков и хвастовства своими видеокартами. Они неплохо рассказывают ЧТО и КОГДА произошло, но плохо объясняют ПОЧЕМУ и КАК ИСПРАВИТЬ.

В другом лагере находится мой любимый RenderDoc, о котором я уже писал. Прекрасная утилита, написанная ребятами из Crytek для себя и людей. Открытый код, поддержка всех вендоров, DirectX11 (с планами на Вулкан и DirectX12), куча мелких полезных мелочей.

Вторым представителем когда-то был PIX — утилита для анализа производительности DirectX9. Задумывалась она как инструмент для разработки под XBox (само название это аббревиатура от Performance Investigation for XBox), но хорошо работала и для десктопных приложений. До того момента, пока не умерла (с выходом DirectX 10/11 и новых версий Windows). Microsoft, у которого в очередной раз маркетологи победили инженеров, объявил единственным инструментом для графической отладки Visual Studio, в которой именно для этих целей было много лишнего, многого не хватало, а кое-что было и вовсе невозможно. Студия — прекрасный инструмент для программирования, но далеко не столь хорошая вещь для изучения, профилирования и отладки графического кода (тем более чужого).

Всё это уныние продолжалось несколько лет, пока инженеры Microsoft не одержали временную победу и в январе 2017 года Microsoft объявила о запуске беты полностью обновлённой версии PIX для DirectX 12!

Давайте же посмотрим, что мы получили.
Читать полностью »

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

Практически каждая современная графическая сцена являет собой результат работы некоторого кода, написанного специально для GPU — от реалистичных эффектов освещения в новейших ААА-играх до 2D-эффектов и симуляции жидкости.
image
Сцена в Minecraft до и после применения нескольких шейдеров.

Цель этой инструкции

Программирование шейдеров иногда кажется загадочной черной магией. Тут и там можно встретить отдельные куски кода шейдеров, которые обещают вам невероятные эффекты и, возможно, вправду способны их обеспечить — но при этом совершенно не объясняют, что именно они делают и как добиваются столь впечатляющих результатов. Данная статья попробует закрыть этот пробел. Я сфокусируюсь на базовых вещах и терминах, касающихся написания и понимания шейдерного кода, так что впоследствии вы сами сможете менять код шейдеров, комбинировать их или писать свои собственные с нуля.
Читать полностью »

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

Мы тогда писали под DEC VAX на VAX Basic. Чтобы вся эта история имела какой-то смысл, вы должны понимать, что VAX Basic не был тем классическим Basic, о котором вы думаете. Разработчики компилятора из DEC начали с синтаксиса Basic и понемногу добавили всё хорошее из FORTRAN, Modula II и Pascal. Например, ещё в начале 1980-ых в языке уже были исключения.

Также нужно помнить, что в 1980-ых ещё не существовало полноценных IDE с богатыми редакторами кода (вроде Visual Studio). Мы использовали нечто, называемое TPU (Text Processing Utility). Эта программа была несколько мощнее, чем Notepad, но значительно уступала современным редакторам. Тогда она соревновалась с Emacs и vi. В результате, каждый разработчик был сам ответственен за свой стиль кода, а текстовый редактор в это дело совершенно не вмешивался.

Марк определил строгий набор правил и стандартов написания кода. Его приверженность этим стандартам была близка к фанатизму. К примеру, он мог приконнектиться к рабочему компьютеру ночью из дому (а в тот момент это означало использование модема со скоростью около 1200 бод) ради ревью кода. На следующее утро меня ждало совещание с Марком, где он построчно комментировал мой код, указывая на ошибки в стиле и требуя, чтобы я сегодня же их исправил.
Читать полностью »

Я только что закончил серию изменений в коде браузера Chrome, которая уменьшила размер его бинарника под Windows примерно на 1 мегабайт, перенесла около 500 КB из read/write сегмента в read-only, а также уменьшила потребление оперативной памяти в общем примерно на 200 KB на каждый процесс Chrome. Удивительное заключается в том, что конкретно данная серия изменений состояла исключительно из удаления и добавления ключевого слова const в некоторых местах кода. Да, компиляторы — странные.

Эта задача возникла, когда я писал документацию для некоторых утилит, которые я использую для исследования регрессий кода, связанных с увеличением размера скомпилированных бинарников под Windows. Я запустил утилиту, скопировал в документацию её вывод и начал его описывать, когда заметил нечто странное: несколько больших глобальных объектов, которые согласно архитектуре должны были быть константными, почему-то находились в сегменте read/write данных. Сокращённая версия того вывода утилиты показана ниже:

image

Большинство исполняемых форматов имеют как минимум два сегмента данных — один для read/write объектов и ещё один для read-only. Если у вас есть константные данные, такие, например, как kBrotliDictionary, то их будет логично поместить в read-only сегмент, который является сегментом «2» в бинарнике Chrome под Windows. Однако некоторые константные данные, такие как unigram_table, device::UsbIds::vendors_ и blink::serializedCharacterData были в секции «3», то есть в read/write сегменте.

image
Читать полностью »

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

Тысяча диалектов

Знаете ли вы, что спецификация языка программирования С часто упоминает термин «объект»? Нет, это не объект в том понимании, как он описывается в ООП — объект в С определяется как «блок данных в среде выполнения, содержимое которого может представлять некоторое значение». В этом понимании объекта имеет смысл говорить о, например, «объекте типа char».

Термин «метод» достаточно распространён, но вы можете встретить программистов, которые будут говорить исключительно «функция-член класса». Язык программирования Java, поэтому, то ли имеет, то ли не имеет функций, в зависимости от того, кого вы об этом спросите. Термины «процедура» и «подпрограмма» иногда используются как аналог «функции», но в некоторых языках программирования (например, Pascal) процедура это совершенно не то же самое, что функция.

Даже в рамках одного языка программирования мы, бывает, путаемся.
Читать полностью »

Эта статья объясняет почему при разработке Win32-приложений механизм Slim Reader/Writer Lock (SRWL) часто более предпочтителен, чем классические критические секции.

Легковесность

SRWL-объект занимает в памяти всего 8 байт на x64-архитектуре, в то время как критическая секция — 40 байт. Критическая секция требует инициализации и деинициализации через вызовы функций ядра ОС, в то время как SRWL инициализируется простым присваиванием ему константы SRWLOCK_INIT, а затрат на удаление нет вообще никаких. Использование SRWL генерирует более компактный код и использует меньше оперативной памяти при работе.

Если у вас будет 100 000 объектов, требующих некоторой внутренней синхронизации, экономия памяти будет уже существенной. Прирост производительности от избегания лишних промахов кэша будет ещё более ощутимым. В современных процессорах (начиная с Intel Nehalem, вышедшего в 2008-ом) одна кэш-линия занимает 64 байта. Если вы используете на объект синхронизации 40 из них — это существенно ударит по производительности доступа к небольшим объектам в вашем ПО.
Читать полностью »

Протокол QUIC (название расшифровывается как Quick UDP Internet Connections) — совершенно новый способ передачи информации в интернете, построенный поверх протокола UDP, вместо общепринятого ранее использования TCP. Некоторые люди называют его (в шутку) TCP/2. Переход к UDP — наиболее интересная и мощная особенность протокола, из которой следуют некоторые другие особенности.

Сегодняшний Web построен на протоколе TCP, который был выбран за его надёжность и гарантированность доставки пакетов. Для открытия TCP-соединения используется так называемое «трёхкратное рукопожатие». Это означает дополнительные циклы отправки-приёма сообщений для каждого нового соединения, что увеличивает задержки.

image

Если вы захотите установить защищённое TLS-соединение, придётся переслать ещё больше пакетов.

image

Некоторые инновации, вроде TCP Fast Open, улучшат некоторые аспекты ситуации, но эта технология пока не очень широко распространена.

Протокол UDP, с другой стороны, построен на идее «отправить пакет и забыть о нём». Сообщение, отправленное по UDP, будет доставлено получателю (не гарантированно, с некоторой вероятностью успеха). Яркое преимущество здесь в меньшем времени установки соединения, такой же яркий недостаток — негарантированность доставки или порядка прихода пакетов получателю. Это означает, что для обеспечения надёжности придётся построить некоторый механизм поверх UDP, который гарантирует доставку пакетов.

И здесь на сцену выходит QUIC от Google.
Читать полностью »

О производительности именованных каналов в многопроцессных приложениях - 1В статье об особенностях новой версии Visual Studio одним из главных нововведений (с моей точки зрения) оказалось разделение ранее монолитного процесса среды разработки (devenv.exe) на компоненты, которые будут работать в отдельных процессах. Это уже сделано для системы контроля версий (переезд с libgit на git.exe) и некоторых плагинов, а в будущем и другие части VS будут вынесены в подпроцессы. В связи с этим в комментариях возник вопрос: «А не замедлит ли это работу, ведь обмен данными между процессами требует использования IPC (Inter Process Communications)?»

Нет, не замедлит. И вот почему.
Читать полностью »

5 октября 2016-го года вышел Visual Studio «15» Preview 5. Команда разработчиков сфокусировалась на повышении производительности IDE. В этой статье мы рассмотрим некоторые из улучшений. Запускайте инсталлятор и, пока он устанавливается, читайте о нововведениях в этой статье или в оригинальных release notes.

Значительный шаг вперёд в производительности и экономии памяти

Я хотел бы начать с видео, которое очень хорошо показывает рост производительности в данном превью. Здесь показана загрузка проекта Roslyn, которая ранее занимала 60 секунд, а в новом превью полностью заканчивается уже к 30-ой секунде.

Читать полностью »

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

Некоторые из DevTools функций вы возможно не знали. Я буду очень счастлив, если хотя бы одну из них вы найдете для себя полезной.

(В статье ниже присутствуют анимированные гифги, которые начинают раздражать после первого цикла. Поэтому я советую открыть dev tools и удалить DOM ноды, которые отвечают за изображения.)

Итак, поехали:

Копируем переменную в буфер обмена

Об этой возможности я узнал из комментариев, и считаю ее достаточно полезной чтобы быть описанной в начале. Иногда бывает нужно скопировать содержимое переменной в буфер обмена. Например html код или json объект. Для этого можно использовать copy функцию.

copy (someVariable)

Теперь текстовое представление переменной скопировано в буфер обмена.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js