Meeting C++ 2013

в 19:55, , рубрики: c++, c++11, Conference, конференция, метки: , , ,

Meeting C++, Dusseldorf

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

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

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

Move-семантика

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

Параметры Рекомендации для C++11
Входные:
маленькие и sink значения
все остальные
Передаём по значению
const ref
Выходные Передаём по значению
Входные/Выходные Используем stateful algorithm object2

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

Кроме общих слов, вроде «асинхронность начинается с дизайна» в основном звучали жалобы: ведь асинхронного ввода/вывода в языке до сих пор нет. Понятно, что асинхронная программа при синхронном вводе/выводе теряет всякий смысл. Поэтому были разговоры о будущих стандартах, об 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.3

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(); 

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

pointer type real hardware virtualization
native 3.0 sec. 5.7 sec.
std::unique_ptr 2.9 sec. 5.7 sec.
std::shared_ptr 6.0 sec. 11.8 sec.
std::make_shared 6.5 sec.


Ссылки
1. Eric Niebler, C++11 and No-Compromise Library Design
2. Out Parameters, Move Semantics, and Stateful Algorithms
3. Rainer Grimm, Embedded Programming with C++11

Автор: sermp

Источник


* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js