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

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

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

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

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

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

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

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

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

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

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

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

Давайте поговорим об использовании и преимуществах параллельных вычислений в R.

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

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

• Хорошие параллельные библиотеки, например, многопоточные BLAS/LAPACK, включены в Revolution R Open (RRO, сейчас Microsoft R Open) (смотреть здесь).
• Специализированные параллельные расширения, предоставляющие свои собственные высокопроизводительные реализации важных процедур, например, методы rx от RevoScaleR или методы h2o от h2o.ai.
• Фреймворки абстрактной параллелизации, например, Thrust/Rth.
• Использование прикладных библиотек R, связанных с параллелизацией (в частности, gbm, boot и vtreat). (Некоторые из этих библиотек не используют параллельные операции, пока не задано окружение для параллельного выполнения.)

Друзья, перед вами очередной выпуск «Без слайдов» — программы, видеокаста, подкаста, где я беру интервью с интересными мне людьми. Гостем этого выпуска стал Руслан Черёмин 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 изображений в реальном времени и при полном разрешении. Естественно, что кроме скорости необходимо было получить приемлемое качество обработки и шумоподавления, и мне кажется, что нам это удалось.

По программированию написано много хороших книг. Однако профессиональный ландшафт разработчика сейчас меняется так стремительно, что печатная литература не всегда успевает вовремя: появляются новые программные средства и аппаратные компоненты, внедряется поддержка прогрессивных технологий, на «железо» переносится всё больше программных функций… как уследить за этим профессиональным калейдоскопом, как не отстать от жизни? Intel предлагает свое решение этой проблемы.

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

Господа! Мы с Тимуром Палташевым из 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++ компилируется с включенным по умолчанию анализом потокобезопасности.

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

Сегодня на повестке дня — разработка для ARM на голом железе и технологии верификации. Общий призовой фонд — более 8000€.

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

В последние годы требования к современным приложениям и методы их разработки значительно изменились. Большинство таких приложений используют асинхронную модель, состоящую из множества слабо связанных компонентов (микросервисов). Пользователи же хотят, чтобы приложение работало безотказно и всегда было в актуальном состоянии (данные должны быть синхронизированы в любой момент времени), проще говоря, пользователи чувствуют себя более комфортно, когда им не нужно каждый раз нажимать кнопку «Обновить» или полностью перезагружать приложение, если что-то пошло не так. Под катом немного теории и практики и полноценное приложением c открытым исходным кодом со cтеком разработки React, Redux/Saga, Node, TypeScript и нашим проектом Theron.


Rick and Morty. Рик открывает множество порталов.

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

В далеком 2012, когда цена на нефть еще была трехзначной, а трава зеленее, майкрософтом был выпущен .NET 4.5, а с ним и конструкция async/await. Про неё написано уже довольно много статей (Async в C#), а большинство разработчиков C# хорошо её изучили. Но все ли варианты использования были рассмотрены, можно ли выжать из await немного больше?

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

В классическом варианте это выльется в использование CancellationToken для обработки отмены, try catch для обработки разрыва соединения и код анализа возвращенных данных, для оценки результата запроса. Но можно ли уместить всё это в единой парадигме? В этот статье я предлагаю рассмотреть альтернативный подход, основанный на событийной модели с использованием синтаксического сахара async/await.

Давным-давно перестал работать 1stat.ru — откровенно говоря, для нас это была трагедия (сейчас вроде он как-то работает).

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

Работу каждой программы можно ускорить минимум в десять раз

Рабочая установка разработчиков Smart Engines

Мы расскажем о нескольких приемах ускорения распознавания с помощью OCR Tesseract. Всё рассказанное было использовано в реализации проекта, смысл которого состоял в классификации большого числа образов страниц деловых документов (таких документов как паспорт, договор, контракт, доверенность, свидетельство о регистрации и т.п.) и сохранении результатов в электронном архиве. Часть алгоритмов классификации была основана на анализе собственно образов страниц, а часть – на анализе извлечённых из образа текстов. Для извлечения текстов было необходимо распознавание с помощью OCR.

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

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

Стоит отметить, что автор расширения, Joe Watkins, в своих статьях предупреждает, что многопоточность — это всегда не просто и надо быть к этому готовым.

Кто не испугался, идем далее.

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

Меня же интересует технология ПЛИС — и поэтому когда-то я сделал реализацию life для ПЛИС Альтера Cyclone III. Правда поместилось в чип тогда очень мало: всего 32x16 клеток. На таком маленьком поле довольно трудно испытать сложные фигуры.

Сейчас у меня в руках другая плата: тут уже стоит Altera MAX10 с 50-ю тысячами логических элементов. Было интересно, смогу ли я расширить поле хотя бы в 4 раза? В общем задумал сделать хотя бы 64x32.

Результат представлен на этом видео, я называю эту картину: «ружье Госпера убивает самоё себя».

Ниже подробности реализации.