?

Log in

No account? Create an account

Previous Entry | Next Entry

Бнопня по C++

Засада. Как вы думаете, какая C++ (11) функция может быть быстрее при достаточно развесистом классе Foo?

size_t DirectSize(Foo && foo) {
    auto v = std::vector{std::move(foo)};
    return v.size();
}


size_t IndirectSize(Foo && foo) {
    auto v = construct_vector(std::move(foo));
    return v.size();
}


при условии, что construct_vector() — это функция, определённая в другом модуле?

Poll #2054853 Быстрота, милота

Какая функция может быть быстрее?

DirectSize
9(40.9%)
IndirectSize
13(59.1%)


Вопрос специально сформулирован несколько расплывчато. Хочу мнений!

Comments

nponeccop
Oct. 1st, 2016 07:19 pm (UTC)
Я С++ не знаю, поэтому отвечу общими словами о применении стандарта и переносимости.

Нет варианта "обе"! Подвох в вопросе заключается в том, что в общем случае нельзя сказать, какой код будет быстрее - т.е. только бенчмарк. Это же касается размещения в другом модуле - результат может поменяться по мере развития межмодульной оптимизации и link time code generation (ltcg/lto).

В этом коде происходит изменение производительности при внесении seemingly equivalent changes. Соответственно, мы напарываемся на неполноту оптимизатора.

И вопрос можно переформулировать так: это всего лишь неполнота, или кроме неполноты ещё и стандарт нам что-то говорит по этому поводу? Т.е. есть ли в страндарте указание, что "Мув семантик не понимается инитиалайзерлистом".

Но надо учитывать, что гарантии стандарта - это некий минимальный уровень, ниже которого опускаться запрещено. Подниматься же выше - вполне можно.

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

Т.е. если у нас 2 кода, в одном из которых нам мув гарантирован, а во втором нет, то в некоем хорошем оптимизаторе разницы может и не оказаться вовсе.

Вообще такие вопросы надо задавать в разрезе ОС, архитектур и (версий) процессоров и компиляторов. Поскольку

а) гарантии стандартом даются слабые - всё отдано на откуп авторам оптимизатора
б) у нас как правило ограниченный набор таргетов, если только мы не Буст пишем

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

Edited at 2016-10-01 07:27 pm (UTC)
blackyblack
Oct. 1st, 2016 08:21 pm (UTC)
Ну так на любой вопрос по оптимизации ответ будет: "А вы профайлером смотрели?"
nponeccop
Oct. 1st, 2016 08:27 pm (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