?

Log in

No account? Create an account

Previous Entry | Next Entry

Ответ на бнопню по C++

Код, который напрямую зовёт std::vector{std::move(foo)} на данных в ощущениях компиляторах (gcc, clang) будет медленнее, чем construct_vector(std::move(foo)), где:

std::vector construct_vector(Foo && foo) {
    std::vector vec;
    vec.emplace_back(std::move(foo));
    return vec;
}


Почему это так случается? Из-за отсутствия оптимизации std::initializer_list. Конструкция вектора через std::vector{} создаёт initializer_list, мувает в него один элемент foo, затем копирует из initializer_list внутрь вектора. К сожалению.

construct_vector же копированием foo не занимается, а делает move construction. Значение вектора попадает в место вызова без копирования, через RVO.

Ну вот так хреново пока работаем с std::initializer_list. В стандарте C14 про это вот что есть: "the underlying array is copy-initialized". Опаньки.

Типичный C++, что ни фича, то засада. JavaScript и то без копирования передавал бы всё :)

P.S. По поводу «почему C++» (mpd) — это было не моё решение. Нам и на Эрланге с сишными вставками неплохо работалось, правда, в сервис работал в десять раз медленнее. Но если у компании есть ресурсы и время на то, чтобы создать поддерживать в тонусе команду C++-програмистов, почему бы и нет? :)

Ключевой момент тут такой: если не заниматься байтодрочерством, C++ из-за подобных недофич (чуть что — копируем! ну или не смогли понять жизненный цикл — тоже на всякий случай скопируем) будет работать не сильно быстрее остальных дефолтных языков, а то и медленнее и/или глючнее. Только если действительно понимать, что происходит, можно выжрать нетривиальный буст по производительности, и, если повезёт, не сильно потерять в безопасности. Но это если такая производительность действительно нужна. На мобилке она, за редкими исключениями, вряд ли нужна. В датацентре (если это не cuda) — уже более интересное распределение. Разница между десятью нодами и сотней нод в плане управления — колоссальна. Между сотней и тысячью — уже речь встаёт о дешевизне датацентра по сравнению с рабочим временем программиста.

Если C++ на вашем продукте позволяет обеспечить эту разницу в 10x, есть средства на программистов и время на их реализацию, почему бы и нет? У нас в MZ — есть. Компания зарабатывает несколько миллионов долларов в день. А в вашем НИИГиТ наверняка нет ни таких средств, ни таких требований к производительности, которые бы требовали кластера из более чем десятка машин, а их оптимизация явно встанет зарплатой программистов дороже, чем выгода от их сокращения.

Comments

nponeccop
Oct. 4th, 2016 08:41 pm (UTC)
В наше время™ хранение по ссылке чревато pointer chasing overhead, т.е. хранение по значению позволяет использовать префетчер. Т.е. если у них много объектов в пределах пары-тройки строк кеша, может оказаться, что оно оправдано.
sleepy_drago
Oct. 4th, 2016 09:16 pm (UTC)
они ж ничего не считают. на уровень 10х от скриптов выходит практически код в лоб, где аккуратно и компактно хранится то что нужно запросам/сессиям. на этом уровне выжимания тиков налажать можно только если наделать циклов с зависимыми чтениями. намного чаще упор в io, на очередях задач, и тп.
у нас в цацках, например если победить высокоуровневую лажу на координации задачек, мы не упираемся в современные кеши интела совсем, даже откровенным китайским кодом. Гпу и драйвер оного это совсем другая история, но им же оно не надо.
cd_riper
Oct. 5th, 2016 03:48 am (UTC)
ты забыл главное -- оно может быть оправдано только если у тебя вектор маленький и ты его редко модифицируешь

Profile

lionet
Lev Walkin
Website

Latest Month

December 2016
S M T W T F S
    123
45678910
11121314151617
18192021222324
25262728293031

Page Summary

Powered by LiveJournal.com
Designed by yoksel