В этих 3-ех статьях я детально расскажу об атомарных операциях, барьерах памяти и о быстром обмене данными между потоками, а так же о «sequence-points» на примере «execute-around-idiom», а заодно постараемся вместе сделать что-нибудь полезное — умный указатель, который делает любой объект потоко-безопасным для любых операций с его членами переменными или функциями. А затем покажем как используя его достичь производительности высоко-оптимизированных lock-free алгоритмов на 8 — 64 ядрах.

Примеры использования и тестирование потоко-безопасного указателя и contention-free shared-mutex

В этой статье мы покажем: дополнительные оптимизации, примеры использования и тестирование разработанного нами потоко-безопасного указателя с оптимизированным разделяемым мьютексом contfree_safe_ptr<T> – это эквивалентно safe_ptr<T, contention_free_shared_mutex<>>
В конце покажем сравнительные графики тестов нашего thread-safe указателя и одних из лучших lock-free алгоритмов из libCDS на процессорах Intel Core i5/i7, Xeon, 2 x Xeon.

Дорого дня, уважаемые хабражители!

Сегодня я расскажу вам о том, как можно установить неподписанное (или плохо подписанное) приложение на устройство с iOS 9. Да, без Jailbreak. Да, бесплатно. Нужен лишь компьютер с OS X и Apple ID. Как такое возможно? Читаем под катом.



Осторожно! Много картинок!

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

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

Не буду сильно углубляться в теорию. Что такое частичное применение легко найти в интернете. В том числе на Википедии.

Если кратко, то это механизм, позволяющий зафиксировать k аргументов функции от n аргументов, сделав из неё функцию от (n - k) аргументов.

// Пусть имеется функция f от четырёх аргументов:
int f (int a, int b, int c, int d)
{
    return a + b + c + d;
}

// Фиксируем первые два аргумента:
auto g = part(f, 1, 2); // 1 + 2 + ...

// Добрасываем оставшиеся два:
assert(g(3, 4) == 10); // ... + 3 + 4 = 10

На эту тему уже существует масса публикаций, в том числе и на Хабре:

1. C++ Variadic templates. Каррирование и частичное применение
2. Частичное применение и каррирование в C++
3. Каррируем на C++

А ветка "How should I make function curry?" на stackoverflow — просто кладезь для тех, кто впервые сталкивается с этой темой.

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

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

Надо только всё внимательно проанализировать и сложить кубики в правильном порядке. Именно этим я и собираюсь заняться в данной статье.

Всем привет! Вы читаете третью часть статьи про создание VST-синтезатора на С#. В предыдущих частях был рассмотрен SDK и библиотеки для создания VST плагинов, рассмотрено программирование осциллятора и ADSR-огибающей для управления амплитудой сигнала.

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

Будет рассмотрен исходный код и применение эквалайзера из библиотеки NAudio (библиотека для работы со звуком под .NET).

Внимание — будет много матана — будем рассчитывать формулы для коэффициентов фильтра.

Исходный код написанного мною синтезатора доступен на GitHub'е.

Скриншот VST плагина-эквалайзера Fab Filter Pro Q

В компании Intel разрабатывают не только ПО для «внешних» потребителей — пишутся и программы, которые используются только внутри Intel. Среди них довольно много средств для численного моделирования различных физических процессов, протекающих при изготовлении процессоров — ведь именно последние и являются основной продукцией Интела. В этих программах, конечно, широко используются различные методы вычислительной математики и физики.
Вот некоторое время назад мне понадобилось программно решать одно уравнение методом Ньютона. Казалось бы, все просто, но для этого надо уметь вычислять производную левой части уравнения. Эта левая часть у меня была довольно сложная — даже просто вычисление ее значений в программе было разбросано по нескольким функциям, — и перспектива вычислять производную на бумажке меня не радовала. Перспектива воспользоваться каким-нибудь пакетом символьных вычислений меня радовала не больше — перенабирать все формулы, содержащие к тому же несколько частных случаев, далеко не очень приятно. Вариант вычислять производную численно как разность значений функции в двух соседних точках, деленную на соответствующее приращение независимой переменной, чреват потерей точности и вообще необходимостью подбирать подходящее приращение этой переменной.
Подумав некоторое время, я применил следующий подход. Потом я узнал, что он называется «автоматические дифференцирование», для него существует довольно обширная литература на английском, и ряд библиотек — но на русском я нашел только некоторые научные статьи про применение этого метода, и пост на Хабрахабре, в котором все рассказывается через смесь дуальных и комплексных чисел, и понять который с ходу, на мой взгляд, тяжело. С другой стороны, для понимания и практического применения автоматического дифференцирования не нужны никакие дуальные числа, и этот подход я тут и изложу.

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

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

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

(кликабельно)

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

Однажды мне понадобилось решить простенькую (как мне тогда казалось) задачу – в PHP-скрипте узнать длительность mp3-файла. Я слышал о ID3 тегах и сразу подумал, что информация о длительности хранится либо в тегах, либо в заголовках mp3-файла. Поверхностные поиски в интернете показали что за пару-тройку минут решить эту задачу не получится. Поскольку от природы я довольно любопытен а время не поджимало — решил не использовать сторонние инструменты а разобраться в одном из самых популярных форматов самостоятельно.

Если Вам интересно, что там внутри – добро пожаловать под кат (трафик).

_{большое разрешение — по клику}

Снова здравствуй, Хабр!

В этом посте я бы хотел рассказать о великолепной программе под названием Nuke от компании The Foundry, которая уже затрагивалась вот в этом посте, но вызвала много вопросов читателей, далеких от 3д графики в общем, и от 3д-композитинга в частности.

Если описать в двух предложениях, то Нюк является мировым стандартом в композитинге и пост-обработке, и был одним из ключевых инструментов в подавляющем большинстве голливудских фильмов с бюджетом, отличным от кустарного.
Да что вообще говорить — Аватар, Трон: Наследие, Трансформеры, Watchmen, Властелины Колец, и большинство остальных голливудских блокбастеров были сделаны именно в Нюке.

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

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

В процессе написания поста я понял, что все, что я хотел бы описать, просто не уместится ни в один пост, ни в цикл статей. Хоть пост и получился длинным, но это вершина айсберга — в нем описывается чуть менее 0.01% всего, чем хочется поделиться.

Интересно?
Добро пожаловать под кат! Осторожно! Много трафика, Джобса, чайников, и надкусанных НЛО.

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

template <typename T>
void f (T t)
{
    // Завладели экземпляром `t` типа `T`.
    ...

    // Хочешь — переноси.
    g(std::move(t));

    // Не хочешь — не переноси.
    ...
}

Но есть один нюанс: требуется, чтобы принимаемый объект был строго rvalue. Следовательно, нужно:

1. Сообщать об ошибке компиляции при попытке передать lvalue.
2. Избежать лишнего вызова конструктора при создании объекта на стеке.

А вот это уже сложнее сделать.

Поясню.

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


Уязвимость рекурсивных алгоритмов навигации муравья: спираль смерти

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

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

Средства LINQ позволяют .Net-разработчикам единообразно работать как с коллекциями объектов в памяти, так и с объектами, хранящимися в базе данных или ином удаленном источнике. Например, для запроса десяти красных яблок из списка в памяти и из БД средствами Entity Framework мы можем использовать абсолютно идентичный код:

List<Apple> appleList; 
DbSet<Apple> appleDbSet;
var applesFromList = appleList.Where(apple => apple.Color == “red”).Take(10);
var applesFromDb = appleDbSet.Where(apple => apple.Color == “red”).Take(10);

Однако, выполняются эти запросы по-разному. В первом случае при перечислении результата с помощью foreach яблоки будут отфильтрованы с помощью заданного предиката, после чего будут взяты первые 10 из них. Во втором случае синтаксическое дерево с выражением запроса будет передано специальному LINQ-провайдеру, который транслирует его в SQL-запрос к базе данных и выполнит, после чего сформирует для 10 найденных записей объекты С# и вернет их. Обеспечить такое поведение позволяет интерфейс IQueryable<T>, предназначенный для создания LINQ-провайдеров к внешним источникам данных. Ниже мы попробуем разобраться с принципами организации и использования этого интерфейса.

На перевод этой статьи меня подтолкнуло обсуждение записей «Почему WPF живее всех живых?» и «Семь лет WPF: что изменилось?» Исходная статья написана в 2011 году, когда Silverlight еще был жив, но информация по WPF не потеряла актуальности.

Сначала я не хотел публиковать эту статью. Мне казалось, что это невежливо — о мертвых надо говорить либо хорошо, либо ничего. Но несколько бесед с людьми, чье мнение я очень ценю, заставили меня передумать. Вложившие много усилий в платформу Microsoft разработчики должны знать о внутренних особенностях ее работы, чтобы, зайдя в тупик, они могли понимать причины произошедшего и более точно формулировать пожелания к разработчикам платформы. Я считаю WPF и Silverlight хорошими технологиями, но… Если вы следили за моим Twitter последние несколько месяцев, то некоторые высказывания могли показаться вам безосновательными нападками на производительность WPF и Silverlight. Почему я это писал? Ведь, в конце концов, я вложил тысячи и тысячи часов моего собственного времени в течение многих лет, пропагандируя платформу, разрабатывая библиотеки, помогая участникам сообщества и так далее. Я однозначно лично заинтересован. Я хочу, чтобы платформа стала лучше.

Context Model Pattern — концепция проектирования приложений, сочетающая черты архитектурных паттернов MVVM, MVP, MVC и основанная на наборе достаточно свободных, прогрессивных, отлично согласованных между собой положений. Краеугольными камнями являются представления, медиаторы, контекстные объекты и их коллекции, а основополагающая рекомендация — принцип прямых инжекций.

Aero Framework — открытая библиотека на языке C#, содержащая всю необходимую инфраструктуру для создания xaml-ориентированных приложений, соответствующих рассматриваемому паттерну. При её грамотном использовании исходный код получается беспрецедентно лаконичным, высокопроизводительным и интуитивно понятным даже начинающим разработчикам.

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

Внимательный и терпеливый читатель будет щедро вознаграждён знаниям.

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

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

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

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

последняя редакция статьи доступна на сайте makeloft.xyz

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

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

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

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

Если вы разрабатываете приложения для XAML-based платформ, таких как WPF, Silverlight, Windows Phone, или Windows Store, то Prism, определённо, сильно поможет вам упростить их разработку. После создания нескольких проектов с использованием Prism, я убедился в работоспособности такого подхода и решил подготовить перевод официального руководства Prism. Итак, часть первая, что же такое Prism.

Оглавление

1. Введение
2. Инициализация приложений Prism
3. Управление зависимостями между компонентами
4. Разработка модульных приложений
5. Реализация паттерна MVVM
6. Продвинутые сценарии MVVM
7. Создание пользовательского интерфейса
   
   1. Рекомендации по разработке пользовательского интерфейса
8. Навигация
   1. Навигация на основе представлений (View-Based Navigation)
9. Взаимодействие между слабо связанными компонентами

Prism является руководством, разработанным для того, чтобы помочь проектировать и создавать насыщенные, гибкие и легко поддерживаемые Windows Presentation Foundation (WPF) приложения, Silverlight Rich Internet Applications (RIAs), и программы под Windows Phone 7-8, а также Windows Store приложений. Используя паттерны проектирования, которые воплощают важные принципы архитектурного дизайна, такие как разделение ответственности (Separation of Concerns, SoC) и слабая связанность (Loose coupling), Prism помогает вам проектировать и писать приложения со слабо связанными компонентами, которые могут независимо развиваться и потом объединяться в одно целое с минимальными усилиями. Этот тип приложений известен как составные приложения.