Перевод статьи Джефа Прешинга Atomic vs. Non-Atomic Operations. Оригинальная статья: http://preshing.com/20130618/atomic-vs-non-atomic-operations/

В Сети уже очень много написано об атомарных операциях, но в основном авторы рассматривают операции чтения-модификации-записи. Однако, существуют и другие атомарные операции, например, атомарные операции загрузки (load) и сохранения (store), которые не менее важны. В этой статье я сравню атомарные загрузки и сохранения с их неатомарными аналогами на уровне процессора и компилятора C/C++. По ходу статьи мы также разберемся с концепцией «состояния гонок» с точки зрения стандарта C++11.

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

Статьи цикла:

1. Многозадачность в ядре Linux: прерывания и tasklet’ы
2. Многозадачность в ядре Linux: workqueue
3. Protothread и кооперативная многозадачность

В прошлой статье мы познакомились с удобной библиотекой синтаксического анализа Pyparsing и написали парсер для выражения 'import matplotlib.pyplot as plt'.

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

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

Персептрон

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

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

Простой макрос

Все началось с простого макроса: (приблизительный код)

#define ADD_BYTE(C) do {            \
  if (offset == capa) {             \
    if (capa < 16) {                \
      capa = 16;                    \
    } else {                        \
      capa <<= 1;                   \
    }                               \
    buffer = realloc(buffer, capa); \
    assert(buffer != NULL);         \
  }                                 \
  buffer[offset++] = (C);           \
} while(0)

Для тех, кто не знаком с языком программирования C, поясню: этот простой макрос добавляет байт «C» в динамически выделяемый буфер (buffer), размер которого (в байтах) равен capa. Следующая позиция для записи определяется при помощи параметра offset. При каждом заполнении буфера происходит двукратное увеличение его объема (начиная с минимального размера в 16 байт).

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

Но как понять, насколько эффективна стратегия перераспределения?

Предисловие

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

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

C++ 14 готов!

По итогам заседания Исаква (Вашингтон, США) в феврале, мы запустили голосование за черновик международного стандарта (DIS) для следующего C++ стандарта. Это голосование завершилось в пятницу.

Сегодня мы получили уведомление, что голосование было единогласно успешным и следовательно мы можем приступить к публикации. Мы будем выполнять некоторые окончательные редакционные штрихи, для исправления некоторых орфографических опечаток и случайно пропущенных слов, а затем передадим этот документ в ISO для публикации в этом году как совершенно новый международный стандарт ISO/IEC 14882:2014(E) языка программирования С++, также известный как С++14.

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

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

Принципы условно сгруппированы в три группы: принципы принятия решений; принципы, направленные на повышение качества кода; принципы, направленные на повышение производительности кода.

• Принятие решений
  • Любое техническое решение должно быть обосновано
  • Ответственность за принятое решение всегда лежит на том или тех, кто принял данное решение
  • При принятии технических решений необходимо учитывать их действие во времени и их соответствие потребностям бизнеса
  • Одним из основных критериев при принятии технических и иных решений должна быть их наибольшая эффективность
  • Смело отступать от правил, методологий, шаблонов и прочих ограничений, если эффект от такого отступления превышает возможные потери (Special cases aren't special enough to break the rules, although practicality beats purity)
  • При необходимости сделать работающее, но, возможно, не наилучшее, решение сразу, а позднее улучшить его (Now is better than never, although never is often better than *right* now)
  • Если сложно выбрать между двумя альтернативными техническими решениями, то нужно выбрать любое и двигаться с ним дальше, когда появится больше инфорации, то можно будет сделать рефакторинг, если решение оказалось неоптимальным
  • Гибкость технических решений крайне желательна, а универсальность не обязательна
• Качество исходного кода
  • Качество кода следует оптимизировать на базе сформированной системы критериев, сбалансированной по отношению к затратам в краткосрочном и долгосрочном периодах
  • Писать оптимальный код сразу, если это не увеличивает его сложность и сроки разработки (Beautiful is better than ugly)
  • Самодокументируемый код имеет приоритет над хорошо прокомментированным (Beautiful is better than ugly)
  • Писать TODO и FIXME в коде
  • Давать переменным, функциям, методам, классам и другим объектам исходного кода имена точно отражающие их назначение, несмотря на увеличение длины названий (Explicit is better than implicit)
  • Меньшее число строк и объем кода предпочтительнее, при сохранении прежней читабельности кода (Simple is better than complex)
  • Применять инспекцию кода (code review) как инструмент обнаружения ошибок, выравнивания стиля разработки, знакомства с чужим кодом и обучения в команде
  • Применять повторное использование своего и чужого кода
  • Использовать специализированные библиотеки для решения конкретных задач, вместо разработки своего аналогичного кода
• Производительность
  • Производительность разработки кода имеет приоритет над производительностью исполнения кода
  • Оптимизация производительности исполнения кода должна быть обоснована соответствующей потребностью
  • Оптимизация производительности исполнения кода должна выполняться за счет устранения наиболее серьезных узких мест
  • В первую очередь должны быть использованы наиболее эффективные методы оптимизации производительности исполнения кода

Далее дано развернутое пояснение каждому из перечисленных принципов. Для некоторых принципов в круглых скобках указанны постулаты Zen of Python, которые на мой взгляд имеют отношение к данным принципам, либо их частям.

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

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

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

Привет, Хабр! Решил побаловаться графоманством и поделиться результатом развлечения прошедших выходных (только эти выходные прошли давно и статья писалась гораздо дольше, чем развлечение. Как говорится, делу время — потехе час).

Я расскажу про так называемые алгоритмы расщепления (в частности, про DPLL-алгоритм), про теорему и числа Ван-дер-Вардена, а в заключение статьи мы напишем свой собственный алгоритм расщепления и за полчаса вычислений докажем, что число w(2; 5) равно 178 (первооткрывателям в 1978 году на это потребовалось более 8 дней вычислений).

Введение

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

В этой статье я расскажу о следующем:

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

Сегодня открыли доступ к обучающим материалам курса «Введение в Linux».
Курс создан Linux Foundation и проходит на платформе edX.

О курсе:
Linux обеспечивает работу 94% суперкомпьютеров, большинства серверов в Интернете, основных финансовых сделок в мире и миллиардов Android устройств. Если коротко, то Linux везде. Он присутствует во множестве различных архитектур, от мэйнфреймов до серверов, настольных компьютеров, мобильных устройств и на ошеломляющем разнообразии железа.

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

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

UPD: Курс очень простой, он для пользователей, которые действительно первый раз запускаю Linux



От автора курса:
Этот курс создан на основе оригинального курса Linux Foundation «Introduction to Linux», который всегда преподавали с инструктором в классе или в виртуальном классе через Интернет. Linux Foundation верит, что задача изменения этого курса для его бесплатного использования сообществом была стоящей и будет хорошо оценена.

В любом обнаружении NoSQL баз данных кто-нибудь обязательно вспомнит о CAP-«теореме». Я не случайно пишу слово «теорема» в кавычках. CAP-«теорема» вовсе не теорема в математическом понимании этого слова. Это неформальное утверждение, сделанное Эриком Брюером в докладе на конференции Principles of Distributed Computing (PODC) в 2000 году. Эрик утверждал, что невозможно создать распределенное (состоящие из нескольких равноценных экземпляров — звеньев) веб-приложение, которое будет одновременно обладать тремя свойствами: согласованность (consistency), доступность(availability) и устойчивость к разделению(partition tolerance), сокращенно CAP. Неформальность утверждения заключается в том, что Брюер не дал определения этим трем понятиям.

Спустя два года Сет Гилберт и Ненси Линч опубликовали исследование, где дали определения понятиям CAP а также формализовали "отложенную согласованность" (Delayed Consistency), которую потом прозвали "согласованность в конечном счете" (Eventual Consistency) и доказали CAP-«теорему» в терминах указанных определений. Если вы еще не читали исследование, то это обязательно стоит сделать — lpd.epfl.ch/sgilbert/pubs/BrewersConjecture-SigAct.pdf

Эта «теорема» так бы и не была никому нужна, если бы её не взяли на вооружение маркетологи NoSQL.

     Каждое натуральное число обладает очень многими известными и, по-видимому, еще в большем числе неизвестными свойствами. Четные — нечетные, простые — составные, конечные — бесконечные и др. свойства способствуют введению классификации чисел, некоторого порядка в их множестве. Традиционный подход предполагает, что не располагая самим числом (его значением) невозможно определить и его свойства. Но это не совсем так. Ряд полезных свойств для некоторых чисел можно определять не зная их значений, но имея данные об их положении в натуральном ряде чисел (НРЧ). Простыми числами, кроме 2, могут быть только нечетные с флексией ≠ 5, а их положение НРЧ определяется нечетной позицией. Сами эти позиции не все равнозначны. Про некоторые большие нечетные N(x1, x2) числа (разумеется в нечетных позициях в НРЧ) можно, не пользуясь традиционными (вероятностными) и детерминированным (весьма трудоемким) алгоритмами, однозначно утверждать, они не могут быть простыми.

Иллюстрация к последней задаче.

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

Одна из новых возможностей C++11 — спецификатор constexpr. С помощью него можно создавать переменные, функции и даже объекты, которые будут рассчитаны на этапе компиляции. Это удобно, ведь раньше для таких целей приходилось использовать шаблоны. Но тут все не так просто. У тех, кто не так хорошо знаком с constexpr, может сложиться впечатление, что теперь не будет никаких проблем с расчетами на этапе компиляции. Но на constexpr-выражения наложены серьезные ограничения.

В первой части будет рассказано про constexpr, о том, какие будут изменения в стандарте C++14, а во второй части будет пример использования constexpr: библиотека, которая считает результат математического выражения в строке.
С помощью нее можно будет написать следующий код:

constexpr auto x = "(4^2-9)/8+2/3"_solve;
std::cout << "Answer is " << x;

И ответ в виде дроби будет получен на этапе компиляции:
Answer is 37/24
Сразу предупреждаю, код этой библиотеки сложно понять.
Кому эта тема интересна, добро пожаловать под кат!

На Хабре о дистрибутиве CAELinux практически не писали (упоминали лишь раз), и совершенно напрасно. Это — специализированный дистрибутив для инженеров, с большим количеством предустановленного ПО для разного рода технических задач.

При этом CAELinux долгое время не обновлялся, более двух лет, и, наконец, вышла версия CAELinux 2013 (видимо, разработчики планировали выпустить обновленный дистрибутив немного раньше). Теперь новый стабильный релиз ОС Computer Aided Engineering (или САЕ) доступен для скачивания.

Стоит отметить, что CAELinux основан на 64-битной версии Xubuntu 12.04 LTS (которая, в свою очередь, является производной Ubuntu). Среди ПО, представляемого вместе с дистрибутивом, есть CAD-программы, различные 3D-инструменты анализа гидродинамики, 3D-инструменты работы с сигналами и их анализом. Есть инструментарий математического моделирования, работы с 3D анимацией и все прочее.

Перевод статьи «A Brief Introduction to Rvalue References», Howard E. Hinnant, Bjarne Stroustrup, Bronek Kozicki.

Rvalue ссылки – маленькое техническое расширение языка C++. Они позволяют программистам избегать логически ненужного копирования и обеспечивать возможность идеальной передачи (perfect forwarding). Прежде всего они предназначены для использования в высоко производительных проектах и библиотеках.

Введение

Этот документ даёт первичное представление о новой функции языка C++ – rvalue ссылке. Это краткое учебное руководство, а не полная статья. Для получения дополнительной информации посмотрите список ссылок в конце.

Rvalue ссылка

Rvalue ссылка – это составной тип, очень похожий на традиционную ссылку в C++. Чтобы различать эти два типа, мы будем называть традиционную C++ ссылку lvalue ссылка. Когда будет встречаться термин ссылка, то это относится к обоим видам ссылок, и к lvalue ссылкам, и к rvalue ссылкам.

В этой части моего цикла статей про Model-View в QML мы начнем рассматривать представления и начнем с тех, которые делаются на основе готовых компонентов.

Model-View в QML:

1. Model-View в QML. Часть нулевая, вводная
2. Model-View в QML. Часть первая: Представления на основе готовых компонентов
3. Model-View в QML. Часть вторая: Кастомные представления
4. Model-View в QML. Часть третья: Модели в QML и JavaScript
5. Model-View в QML. Часть четвертая: C++-модели