На первой неделе сентября этого года вышла в свет новая версия продукта Intel Parallel Studio XE 2017. Давайте разбираться, что интересного появилось в ней.

Стремитесь узнать про все этапы проектирования и производства микросхем от идеи до фабрики? Хотите построить прототип своей собственной системы на кристалле используя микросхемы ПЛИС? Интересуетесь программированием микроконтроллеров и операционными системами реального времени? Тогда приходите на семинары, которые совместно организовали американские, российские и украинские компании и университеты. Эти семинары будут проходить в Москве, Зеленограде, Санкт-Петербурге, Киеве и Алма-Ате во второй половине октября и первой половине ноября:

• Nanometer ASIC — двухдневный семинар, описывающий все этапы проектирования и производства микросхем: создание спецификации, описание цифровой логики на языках описания аппаратуры Verilog и VHDL на уровне регистровых передач, логический синтез, размещение и трассировка, создание фотошаблонов и производство микросхем на фабрике. Для проведения этих семинаров из Калифорнии приезжает Чарльз Данчек, преподаватель такого курса в University of California Santa Cruz Extension in Silicon Valley. В Москве семинары проходят под эгидой Фонда инфраструктурных и образовательных программ (ФИОП) РОСНАНО и его дочерней компании eNANO.
  
  
• MIPSfpga — устройство систем на кристалле, протоколы внутри чипа и вне чипа, интеграция процессорного ядра с памятью и устройствами ввода-вывода, наблюдение работы кэша и конвейера промышленного процессора на плате с ПЛИС. Семинары проводятся под эгидой британской компании Imagination Technologies, известной как разработчик графического процессора PowerVR внутри Apple iPhone.
  
  
• Connected MCU — введение в использование микроконтроллеров, организация параллельности на одном процессоре, использование прерываний, таймеров, конечных автоматов реализованных в софтвере, и наконец — введение в RTOS и лабораторное занятие с использованием операционной системы FreeRTOS. Материалы семинаров подготовлены профессором Александром Дин из университета Северной Каролины в сотрудничестве с Imagination и Microchip Technology.
  

Андрей Саломатин ( filipovskii_off )

Сегодня каждый день появляются новые языки программирования — Go, Rust, CoffeeScript — все, что угодно. Я решил, что я тоже горазд придумать свой язык программирования, что миру не хватает какого-то нового языка…

Дамы и господа, я представляю вам сегодня Schlecht!Script — чумовой язык программирования. Мы все должны начать им пользоваться прямо сейчас. В нем есть все то, к чему мы привыкли — в нем есть условные операторы, есть циклы, есть функции и функции высших порядков. В общем, в нем есть все, что нужно нормальному языку программирования.

Что в нем не очень обычно, что может даже оттолкнуть, на первый взгляд, — это то, что в Schlecht!Script функции имеют цвет.

Блокировки в общем и мьютексы, как их частная реализация, имеют давнюю историю неправильной оценки скорости их работы. Ещё в 1986-ом году в одной из Usenet-конференций Matthew Dillon написал: «Большинство людей ошибочно уяснили себе, что блокировки работают медленно». Сегодня, спустя многие годы, можно констатировать, что ничего не изменилось.

Действительно, блокировки могут работать медленно на некоторых платформах, или в сверх-конкурентном коде. И, если вы разрабатываете многопоточное приложение, то вполне возможно, что рано или поздно натолкнётесь на ситуацию, когда какая-нибудь одна блокировка будет съедать очень много ресурсов (скорее всего из-за ошибки в коде, приводящей к слишком частому её вызову). Но всё это частные случаи, не имеющие в общем случае отношения к утверждению «блокировки работают медленно». Как мы увидим ниже, код с блокировками может работать весьма производительно.

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

Второй причиной заблуждений могут служить, как это ни парадоксально, бенчмарки. К примеру, далее в этой статье мы будем измерять производительность блокировок под высокой нагрузкой: каждый поток будет требовать блокировку для выполнения любого действия, а сами блокировки будут очень короткими (и, в результате, очень частыми). Это нормально для эксперимента, но такой способ написания кода — это не то, что вам нужно в реальном приложении.

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

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

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

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

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

Пути технологии неисповедимы. Три месяца назад к нам в Silicon Valley приехал бизнесмен из Украины Александр Романишин. Я пошел с Александром на выставку для разработчиков IoT, где мы встретили Дэвида Гарольда из британской части Imagination Technologies (компании, которая спроектировала PowerVR GPU внутри Apple iPhone).

Александр увидел у Дэвида демо платы MIPS Creator ci40 для «умных ферм», и минут двадцать рассказывал Дэвиду, что все правительство Украины начиная с Порошенко лично желает в порядке нахождения экономического будущего страны скрестить электронные технологии и сельское хозяйство. (Александр — старший менеджер аудит-компании, который делает анализ и поддержку сделок M&A)

Дэвид воспринял все это максимально буквально и сегодня утром я получил от начальника Дэвида письмо, откуда узнал, что они в Великобритании сделали онлайн вебинар по использованию MIPS Creator ci40 для построения системы умной ирригации, и соратники Александра могут зарегистрироваться для этого семинара, который состоится в среду 28 сентября в 11 утра по Silicon Valley / в 21.00 по киевскому времени:





По этому поводу я хочу копнуть глубже внутрь чипа и рассказать про историю и особенности процессорного ядра в показываемом в вебинаре устройстве. Внутри MIPS Creator ci40 стоит чип на основе многопоточного двухядерного кластера MIPS interAptiv, продвинутого отпрыска ядра MIPS 24KEc. Последний сейчас переживает вторую молодость внутри только что вышедшего на рынок Omega2, Linux-компьютера ценой $5 размером с почтовую марку. Чем же MIPS interAptiv внутри MIPS Creator ci40 отличается от MIPS 24KEc внутри Omega2 с точки зрения микроахитектуры и как это задевает программиста?

(Поскольку люди спрашивали: Sublime Text 3 с «Spacegray Light» («платиново-серый светлый») из Materialize и гарнитура Ubuntu Mono Bold)

Как и большинство других студентов, обучавшихся по программе компьютерных наук в Калифорнийском университете в Сан-Диего, я в течение нескольких лет шёл через различные курсы просто «накатом». Я никогда не был ни хорошим, ни плохим по успеваемости, и мой средний балл был «не очень». Я любил курсы программирования с их чрезвычайно сложными заданиями; математический анализ же был мне не по душе.

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

Если вы сейчас изучаете компьютерные науки или предполагаете делать это, то надеюсь, что вам будет полезен мой опыт.

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

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

• Подключайте более мощные параллельные библиотеки, например, Intel BLAS (доступна под Linux, OS X и Windows как часть дистрибутива Microsoft R Open). Это позволит заменить уже используемые библиотеки их параллельными версиями, благодаря чему получите ускорение (на соответствующих задачах, например, связанных с линейной алгеброй в lm()/glm()).
  
  
• Вынесите обработку задач моделирования из R во внешнюю библиотеку для параллелизации. Это стратегия, которую используют следующие системы: методы rx от RevoScaleR (теперь Microsoft Open R), методы h2o от h2o.ai, RHadoop.
  
  
• Используйте утилиту parallel в R, чтобы запускать функции на других экземплярах R. Эта стратегия из «Небольшого введения в параллельное программирование на R» и ряда библиотек на основе parallel. Фактически это реализация удаленного вызова процедуры через сокет или сеть.

Рассмотрим подробнее третий подход.

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

Информация, чтобы быть использованной, должна получить интерпретацию. Например, красный сигнал светофора можно интерпретировать как запрет ехать, улыбку как сигнал хорошего расположения и тому подобное. Конкретная интерпретация называется смыслом информации. По крайней мере, такой трактовки придерживается международная организация по стандартизации: «knowledge concerning objects, such as facts, events, things, processes, or ideas, including concepts, that within a certain context has a particular meaning».

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

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

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

Анатомия веб-сервиса

Андрей Смирнов

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

Какую часть я называю веб-сервисом, бэкендом, application-сервером? В классической архитектуре это то, что стоит за http rеverse proxy или load-балансировщиком, а с другой стороны у него находятся база данных, memcached и др. Вот только об этом бэкенде и будет идти речь.

RxJava — это реализация ReactiveX для Java — библиотеки для асинхронной обработки потоков данных. Паттерн observable на стероидах, как они сами пишут. В интернете, в том числе на Хабре, есть много «введений в RxJava». Я хочу привести несколько примеров реальных задач. Они не очень сложные, но возможно кто-то увидит какие-то сходства со своими и задумается.

Собственно, задачи:

1. Простое клиентское TCP-соединение. Есть протокол поверх TCP/IP, нужно сформировать сообщение, подключиться к удаленному узлу, если еще не подключился, передать сообщение и прочитать ответ. Плюс обработка ошибок, проверка таймаутов, повтор отправки в случае неудачи. Жестких требований к производительности нет, трафик не большой.

2. Есть двигатель и некоторый датчик. Нужно произвести сканирование — пройтись двигателем по заданной траектории: послать двигатель к точке, дождаться, когда он к ней приедет, снять показания датчика, отобразить точку на графике (в GUI потоке), поехать к следующей точке…

3. Полученные после сканирования данные нужно обработать (условно длительный вычислительный процесс) и засунуть в pdf-отчет (условно длительный процесс ввода-вывода) вместе с изображением графика и данными введенными пользователем (GUI поток).

Друзья, перед вами очередной выпуск «Без слайдов» — программы, видеокаста, подкаста, где я беру интервью с интересными мне людьми. Гостем этого выпуска стал Руслан Черёмин aka cheremin, эксперт по Java и Concurrency. Мы поговорили про Java Memory Model, техническое блогерство, культуру эксперимента, фундаментальное образование и многое другое.



Как всегда — под катом расшифровка интервью.

Теоретические основы императивного программирования были заложены ещё в 30-х годах XX века Аланом Тьюрингом и Джоном фон Нейманом. Теория, положенная в основу функционального подхода, формировалась в 20-х и 30-х годах. В числе разработчиков математических основ функционального программирования — Мозес Шёнфинкель (Германия и Россия) и Хаскелл Карри (Англия), а также Алонзо Чёрч (США). Шёнфинкель и Карри заложили основы комбинаторной логики, а Чёрч является создателем лямбда-исчисления.

Функциональное программирование как раз основано на идеях из комбинаторной логики и лямбда-исчисления.

Но теория так и оставалась теорией, пока в начале 50-х прошлого века Джон МакКарти не разработал язык Lisp (1958), который стал первым почти функциональным языком программирования. На протяжении многих лет у Lisp не было конкурентов. Позднее появились функциональные языки программирования APL (1964), ISWIM (1966) и FP (1977), которые не получили столь широкого распространения.

Со временем Lisp перестал удовлетворять некоторым требованиям разработчиков программ, особенно с ростом объема и сложности программного кода.

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

Здравствуйте, меня зовут Дмитрий Карловский и я… многозадачный человек. В смысле у меня много задач и мало времени, чтобы их все уже, наконец, закончить. Отчасти это и к лучшему — всегда есть чем заняться. С другой стороны — пока ты разрываешься между проектами, мир катится куда-то не туда и некому забраться на броневик и призвать толпу остановиться и немного подумать. А вопрос-то серьёзный — долгое время мир JS был погружён в ад обратных звонков и с ними не только не боролись — их боготворили. Потом он чуть менее чем полностью погряз в обещаниях. Сейчас к ним с разных сторон усиленно вставляют подпорки разной степени кривизны. А света в конце тоннеля всё не видать. Но обо всём по порядку...

Теория многозадачности

Сперва определимся с терминами. В процессе работы, приложение выполняет различные задачи. Например, "скачать файл с удалённого сервера" или "обработать запрос пользователя".

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

Запустить подзадачу мы можем синхронно, и тогда текущая задача заблокируется в ожидании завершения подзадачи. А можем запустить асинхронно, и тогда текущая задача продолжит своё выполнение не дожидаясь завершения подзадачи.

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

На Хабре у меня уже было две статьи (1 и 2), обе они касались реализации быстрого сжатия изображений по алгоритму JPEG на CUDA. Теперь я бы хотел рассказать о другой, гораздо более масштабной задаче — как мы сделали конвертер и видео плеер для серий DNG изображений на CUDA. При этом мы получили очень высокую скорость работы, потому что вся обработка исходных данных в формате DNG теперь выполняется на видеокарте NVIDIA.


Исходное изображение в формате DNG взято с сайта blackmagicdesign.com

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

Господа! Мы с Тимуром Палташевым из AMD в Саннивейл, Калифорния, а также с несколькими соратниками из России, Украины и Казахстана решили спланировать несколько семинаров разных форматов, которые покрывают темы на стыке хардвера и софтвера: цифровая логика, Verilog, правила RTL (Register Transfer Level), введение в микроахитектуру (строение конвейера) процессоров, низкоуровневое программирование на ассемблере, использование микроконтроллеров, особенности чипов для интернета вещей, введение в RTOS-ы, лабы на ПЛИС-ах / FPGA, а также (для части аудитории, которая интересуется производством чипов) физические аспекты проектирования и производства на фабрике (для последнего мы решили привлечь материалы от преподавателя курса в Университете Калифорнии Санта Круз, отделение в Silicon Valley).

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

Писать многопоточные приложения нелегко. Некоторые средства статического анализа кода позволяют помочь разработчикам, давая возможность чётко определить политики поведения потоков и обеспечить автоматическую проверку выполнения этих политик. Благодаря этому появляется возможность отлавливать состояния гонки потоков или их взаимной блокировки. Эта статья описывает инструмент анализа потокобезопасности С++ кода, встроенный в компилятор Clang. Его можно включить с помощью опции командной строки −Wthread−safety. Данный подход широко распространён в компании Google — полученные от его применения преимущества привели к повсеместному добровольному использованию данной технологии различными командами. Вопреки популярному мнению, необходимость в дополнительных аннотациях кода не стала бременем, а наоборот, дала свои плоды выражающиеся в упрощении поддержки и развития кода.

Предисловие

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

Средства статического анализа кода помогают разработчикам определить политики потокобезопасности и проверять их при сборке проекта. Примером таких политик могут быть утверждения «мьютекс mu всегда должен использоваться при доступе к переменной accountBalance» или «метод draw() должен вызываться только из GUI-потока». Формальное определение политик даёт два основных преимущества:

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

Данная статья рассказывает о применении данного подхода в Clang, хотя изначально он был разработан для GCC, однако версия для GCC более не поддерживается. В Clang данная возможность реализована как предупреждение компилятора. В Google на данный момент вся кодовая база C++ компилируется с включенным по умолчанию анализом потокобезопасности.

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