На первый взгляд Netatmo — просто стильная погодная станция, которая замеряет температуру, влажность, уровень углекислого газа и шум. Но на самом деле в гаджете заложен огромный потенциал, и вокруг него можно выстроить свой умный дом без проводов, паяльника и программирования.

Есть старые игры, которые можно назвать легендарными. Спустя десятилетия у них сохраняется большая аудитория увлечённых игроков. Среди таких легенд — Doom, «Цивилизация». К ним же относится и пошаговая стратегия UFO: Enemy Unknown (X-COM).

С момента первоначального выпуска X-COM в 1994 году создано более десятка «клонов» или «духовных преемников» этой игры. И вот сейчас сообщество завершило работу над OpenXcom 1.0 — первым мажорным релизом свободной версии OpenXcom. В свободной версии поддерживается большее разрешение, добавлены новые фичи и исправлены многие баги оригинальной X-COM.

Статью с обзором ситуации с микроэлектроникой в России я закончил утверждением, что сейчас в России есть технические возможности для создания любых военных микросхем (если не считаться с ценой). Однако и в комментариях к той статье, и во многих других — всех больше волновал вопрос отсутствия (на уровне погрешности измерений) производства чисто-коммерческих (гражданских) высокотехнологичных продуктов. Этот вопрос волновал и меня, потому я постоянно мучил вопросами всех, кто так или иначе связан с высокими технологиями и бизнесом в России.

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

Под катом попробуем разобраться чем отличаются «высокотехнологичные» компании от «низкотехнологичных», что нужно, чтобы высокотехнологичные компании могли рождаться и выживать, почему с софтом у нас лучше, чем с хардом, с чего начиналась кремниевая долина в США и можно ли её «скопировать», почему Китай всех рвет, а также — окинем взором все, что происходит в Сколково, Роснано, фонде перспективных исследований и приведут ли они к расцвету российских инноваций. Безусловно, я где-то могу ошибаться — буду рад дополнениям в комментариях.

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

В этом посте я расскажу о новой и (как мне кажется) относительно малоизвестной фиче C++ - reference-qualified member functions. Расскажу о правилах перегрузки таких функций, а также, в качестве примера использования, расскажу, как с помощью ref-qualified функций можно попытаться улучшить схему управления ресурсами, реализуемую с помощью другой идиомы С++ — RAII.

Достаточно сложной темой для программистов на С++ является undefined behavior. Даже опытные разработчики зачастую не могут четко сформулировать причины его возникновения. Статья призвана внести чуть больше ясности в этот вопрос.

Статья является ПЕРЕВОДОМ нескольких статей и выдержек из Стандарта по данной теме.

Что такое «точки следования»?

Стандарте сказано:

Точки следования (sequence points)– такие точки в процессе выполнения программы, в которых все побочные эффекты уже выполненного кода закончили свое действие, а побочные эффекты кода, подлежащего исполнению, еще не начали действовать. (§1.9/7)

Побочные эффекты? А что такое «побочные эффекты»?

Побочный эффект (side effect) (согласно Стандарту) – результат доступа к volatile объекту, изменения объекта, вызова функции из библиотеки I/O или же вызова функции, включающей в себя какие-то из этих действий. Побочный эффект является изменением состояния среды выполнения.

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

Например:

Недавно мы уже знакомили наших читателей с серией подходящих для «Умного дома» электроустановочных изделий. Хабр силён. После публикации поста у нас случилось неожиданное знакомство с представителем производства. В итоге мигом решилась проблема покупки подходящих пружинок и появилась возможность ближе приглядеться к продукции компании. Много фото ждет вас под катом.

В предыдущих своих заметках я описал основу, на которой строятся lock-free структуры данных, и базовые алгоритмы управления временем жизни элементов lock-free структур данных. Это была прелюдия к описанию собственно lock-free контейнеров. Но далее я столкнулся с проблемой: как построить дальнейший рассказ? Просто описывать известные мне алгоритмы? Это довольно скучно: много [псевдо-]кода, обилие деталей, важных, конечно, но весьма специфических. В конце концов, это есть в опубликованных работах, на которые я даю ссылки, и в гораздо более подробном и строгом изложении. Мне же хотелось рассказать интересно об интересных вещах, показать пути развития подходов к конструированию конкурентных контейнеров.
Хорошо, — подумал я, — тогда метод изложения должен быть такой: берем какой-то тип контейнера — очередь, map, hash map, — и делаем обзор известных на сегодняшний день оригинальных алгоритмов для этого типа контейнера. С чего начать? И тут я вспомнил о самой простой структуре данных — о стеке.

Введение

Здравствуйте, дорогие читатели.

В данном посте я постараюсь рассмотреть особенности выделения памяти для объектов OpenCL.

OpenCL является кросс-платформенным стандартом гетерогенных вычислений. Не секрет, что на нём пишут программы тогда, когда от них требуется скорость выполнения. Как правило, подобный код нуждается во всесторонней оптимизации. Всякий GPGPU-разработчик знает, что операции с памятью зачастую являются самым слабым звеном в скорости работы программы. Так как в природе существует великое множество аппаратных платформ, поддерживающих OpenCL, то вопрос организации объектов памяти зачастую становится головной болью. То, что хорошо работает на Nvidia Tesla, оснащённых локальной памятью и соединённых широкой шиной с глобальной, отказывается показывать приемлемую производительность на SoC, имеющих совершенно иную архитектуру.

Об особенностях выделения памяти для систем с общей памятью CPU и GPU и пойдёт речь в данном посте. Использование типов памяти Image оставим в стороне и сосредоточимся на наиболее общеупотребительном типе Buffer. В качестве стандарта будем рассматривать версию 1.1, как наиболее распространённую. В начале проведём краткий теоретический курс, а затем рассмотрим несколько примеров.

В предыдущей статье мы рассмотрели азы создания нового проекта в Godot. И с этими поверхностными знаниями можно разве что поглядеть demo-версии игр.

Во второй части на повестке дня у нас:
1) Экспорт готового проекта в бинарные файлы для выбранной архитектуры.
2) Новые анимации. Параметры персонажа.
3) Управление.
3) GDScript. Добро пожаловать в настоящий кодинг!
4) Импорт простейших Tilesets.
5) Бонус: разбор устройства простейших задников.

Ну и как обычно, много картинок!

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

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



Если это кому-то интересно, добро пожаловать под Хабракат!

Какими качествами должны обладать розетки и выключатели умного дома? Они должны быть недорогими, симпатичными внешне, иметь минимальные размеры «в глубину» и уметь работать в «кнопочном» режиме (подобно стандартной кнопке звонка). Найти один такой выключатель в серии какого-нибудь производителя — задача не из легких. Найти серию таких выключателей — задача из области фантастики. Но и фантастика иногда случается. Сегодня мы познакомим вас с розетками и выключателями LK60, которые прекрасно подойдут для инсталляции встраиваемых модулей COOLRF. Под катом довольно много фотографий (трафик!).

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

То есть, умный дом — это дом, который может все. А удобный дом — это дом, который все, что может, делает сам.

Давайте сначала я просто похвастаюсь тем, что умеет мой дом сейчас, а вы решите, имеет ли смысл читать про мой местами горький (а местами очень даже ничего) опыт дальше, ок?

На Хабре было немало статей про использование различных методов обработки изображений, включая классификацию данных, фильтрацию. Многие из этих подходов применяются и в дистанционном зондировании при обработке цифровых изображений Земли.

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

Хотите получить представление о том, как устроен boost::function, boost::any “под капотом”? Узнать или освежить в памяти, что скрывается за непонятной фразой “стирание типа”? В этой статье я постараюсь кратко изложить мотивацию, стоящую за этой идиомой и ключевые элементы реализации.

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

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

Если вам понадобится алгоритм сортировки массива, который:

• Работал бы гарантированно за O(N*log(N)) операций (обменов и сравнений);
• Требовал бы O(1) дополнительной памяти;
• Был бы устойчивым (то есть, не менял порядок элементов с одинаковыми ключами)

то вам, скорее всего, предложат ограничиться любыми двумя из этих трёх пунктов. И, в зависимости от вашего выбора, вы получите, например, либо сортировку слиянием (требует O(N) дополнительной памяти), либо пирамидальную сортировку (неустойчив), либо сортировку пузырьком (работает за O(N²)). Если вы ослабите требование на память до O(log(N)) («на рекурсию»), то для вас найдётся алгоритм со сложностью O(N*(log(N)²) — довольно малоизвестный, хотя именно его версия используется в реализации метода std::stable_sort().

На вопрос, можно ли добиться выполнения одновременно всех трёх условий, большинство скажет «вряд ли». Википедия о таких алгоритмах не знает. Среди программистов ходят слухи, что вроде бы, что-то такое существует. Некоторые говорят, что есть «устойчивая быстрая сортировка» — но у той реализации, которую я видел, сложность была всё те же O(N*(log(N)²) (по таймеру). И только в одном обсуждении на StackOverflow дали ссылку на статью B-C. Huang и M. A. Langston, Fast Stable Merging and Sorting in Constant Extra Space (1989-1992), в которой описан алгоритм со всеми тремя свойствами.

OpenMP – пожалуй, самая распространённая модель параллельного программирования на потоках, на системах с общей памятью. Ценят её за высокоуровневые параллельные конструкции (в сравнении с программированием системных потоков) и поддержку разными производителями компиляторов. Но этот пост не про сам стандарт OpenMP, про него есть много материалов в сети.

Распараллеливают вычисления на OpenMP ради производительности, о чём, собственно, и статья. Точнее, об измерении производительности с помощью Intel VTune Amplifier XE. А именно, как получить информацию о:

• Получении профиля всего OpenMP приложения
• Профиле отдельных параллельных регионов OpenMP (время CPU, горячие функции и т.д.)
• Балансе работы внутри отдельного параллельного региона OpenMP
• Балансе параллельного/последовательного кода
• Уровне гранулярности параллельных задач
• Объектах синхронизации, времени ожидания и передачах управления между потоками

Каждая новая спецификация OpenMP вводит очень полезные и необходимые дополнения к уже существующему функционалу. Например, в версии 3.0 были добавлены так ожидаемые задачи (tasks), позволившие решать ещё больший спектр задач по распараллеливанию приложений. В 3.1 целый ряд улучшений по работе с задачами и редукциями.

Но по сравнению с тем, что нам теперь даёт стандарт 4.0, предыдущие нововведения кажутся какими-то мелкими. Последняя версия расширила типы поддерживаемого параллелизма, чего раньше никогда не замечалось.