Meeting C++ 2013

Meeting C++, Dusseldorf

Так вышло, что у меня получилось принять участие в работе конференции, посвящённой C++. Уровень, конечно, не GoingNative: доклады были разного уровня. Как очень сильные и интересные, так и совсем пустые. Самым главным для меня была атмосфера — давно я ни с кем лично не обсуждал столько интересных тем. Это мне так понравилась, что я загорелся идеей создать в Санкт-Петербурге C++ User Group, чтобы больше общаться лично с коллегами по цеху. Но об этом как-нибудь потом, а пока о конференции. Не буду описывать и пересказывать все доклады, отмечу только наиболее интересные мне темы и темы, которые затрагивались почти в каждом докладе.

Основные тренды

• move-семантика;
• асинхронность;
• сеть
• повышение производительности, делящееся на инь и янь
  • масштабирование c++ приложений на многоядерной архитектуре;
  • c++ на embedded системах.

Move-семантика

Сама по себе move-семантика, думаю, всем знакома. Беглый поиск даёт несколько постов на Хабре (1, 2, 3). Почти каждый докладчик выжимал из неё что-то своё. Из интересного, Эрик Ниблер порассуждал о том, как теперь лучше передавать параметры функциям и что из них возвращать. С учётом sink-аргументов и того, что компилятор может опознать rvalue, получилась замечательная сводная табличка¹.

Асинхронность

Кроме общих слов, вроде «асинхронность начинается с дизайна» в основном звучали жалобы: ведь асинхронного ввода/вывода в языке до сих пор нет. Понятно, что асинхронная программа при синхронном вводе/выводе теряет всякий смысл. Поэтому были разговоры о будущих стандартах, об std::async и std::future, но, к сожалению, пока асинхронность в C++ скорее мертва, чем жива. Можно использовать много разных хороших библиотек или платформозависимых решений, но язык как стоял на этом месте, так и стоит.
Согласно заявлениям универсальная асинхронная модель будет включена только в C++17. Пока можно познакомится с её описанием здесь.
Что же конкретно нам можно использовать в ожидании этого рая на земле? Ничего нового!

• POSIX: aio;
• FreeBSD: kqueue;
• Linux: epoll;
• где угодно boost::asio.

Сеть

Всё также печально как с асинхронностью (если не хуже). Представитель WG21/SG4 (исследовательская группа в комитете по стандартизации, занимающаяся сетью) привел их роадмап на ближайшие годы:

• 2014 — сетевой порядок байт, URI, IP-адреса;
• 201X — универсальная асинхронная модель (та самая), HTTP, Resolvers;
• 201Y — сокеты, асинхронные потоки ввода/вывода;
• 201Z — SSL, ICMP.

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

Повышение производительности

Как только говорим о повышении производительности, сразу в разговор врываются голоса: «Как мне правильно масштабировать приложение на несколько ядер?» и «Как мне оптимизировать приложение под embedded?». Если Вы думаете, что C++ и embedded это нонсенс, то вот список документов для ознакомления:

• Joint Strike Fighter Air Vehicle C++ Coding Standards for the System Development and Demonstration Program, Lockheed Martin Corporation, 2005;
• MISRA-C: 2008 – Guidelines for the use of the C++ language in critical systems, MIRA Limited, 2008;
• Technical Report on C++ Performance, глава 7 Using C++ in Embedded Systems.

В аспекте же C++11 обе проблемы могут рассмотрены с общих позиций.

• Наша любимая асинхронность: даёт нам lock- и wait-free на многоядерных архитектурах, уходим от большого количества потоков в embedded.
• Где можно используем POD'ы, так как теперь есть is_pod, is_trivial, is_standard_layout позволяющие стандартной библиотеке (да, и нам) разобраться где можно копировать память блоками, а где придётся обойтись поэлементным копированием.
• Никуда без move-семантики. Экономим на лишних перемещениях.
• Выносим всё что можно на этап компиляции. В частности, теперь у нас есть std::array, который можно использовать стандартных алгоритмах, но при этом мы избегаем динамического выделения памяти.
• Управляем памятью при помощи std::shared_ptr, std::unique_ptr.

Кстати, по поводу std::shared_ptr. В обзоре Going Native'2012 есть упоминание того, почему стоит использовать std::make_shared вместо конструктора std::shared_ptr:

auto sp1 = make_shared<T>( args ); // 1 allocation, 24 bytes overhead
shared_ptr<T> sp2( new T( args ) ); // 2 allocations, 40 bytes overhead

Райнер Гримм не поленился сравнить производительность разных подходов, включая обычные указатели, std::shared_ptr и std::unique_ptr.³

auto st = std::chrono::system_clock::now(); 
 
for (long long i=0 ; i < 100000000; ++i){ 
 int* tmp(new int(i)); 
 delete tmp; 
 // std::unique_ptr<int> tmp(new int(i)); 
 // std::shared_ptr<int> tmp(new int(i)); 
 // std::shared_ptr<int> tmp= std::make_shared<int>(i); 
} 
 
std::chrono::duration<double> dur=std::chrono::system_clock::now() - st(); 
std::cout << dur.count(); 

Получил такую сравнительную таблицу.

Автор: sermp

Источник