Главная
Блог разработчиков phpBB
 
+ 17 предустановленных модов
+ SEO-оптимизация форума
+ авторизация через соц. сети
+ защита от спама

Meeting C 2013

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

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

Сама по себе move-семантика, думаю, каждому знакома. Беглый поиск даёт несколько постов на Прогре (12,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

 

Источник: programmingmaster.ru

 

Оставить комментарий
Форум phpBB, русская поддержка форума phpBB
Рейтинг@Mail.ru 2008 - 2017 © BB3x.ru - русская поддержка форума phpBB