Передача в функцию тяжёлого temporary

1. Почему аллокаций 7 миллионов, а не 4, учитывая move semantics и всё такое?

GCC 5.3.0

==13237==   total heap usage: 4,000,001 allocs, 4,000,000 frees, 108,072,704 bytes allocated

move тут негде происходить.

2. Почему компилятор не может построить вектор со строками статически в .rodata, учитывая, что он передаётся по константной ссылке и не изменяется? Или какие-то свойства языка запрещают так делать?

Было бы оно constexpr, может компилятор так и сделал. А так у конструкторов/деструкторов могут быть побочные эффекты (то же выделение/освобождение памяти в хипе) и это невозможно. Из-за этих же эффектов оно не может автоматически быть вынесено за пределы цикла.

Наличие побочных эффектов в copy- и move-конструкторах не мешает делать copy elision.

GCC 5.3.0
==13237== total heap usage: 4,000,001 allocs, 4,000,000 frees, 108,072,704 bytes allocated

Регрессия? Не верится.

move тут негде происходить.

Ну как же «негде»? Из initializer_list'а.

Было бы оно constexpr, может компилятор так и сделал. А так у конструкторов/деструкторов могут быть побочные эффекты (то же выделение/освобождение памяти в хипе) и это невозможно. Из-за этих же эффектов оно не может автоматически быть вынесено за пределы цикла.

Т. е. правило «as-if» распространяется и на такие низкоуровневые побочные эффекты, как количество и порядок вызовов аллокатора?

Из initializer_list'а.

// http://en.cppreference.com/w/cpp/utility/initializer_list/begin
const T* begin() const;

const T*

😭

total heap usage: 4,000,001 allocs, 4,000,000 frees

Что-то странное у вас двоих происходит, у меня:

total heap usage: 1,000,001 allocs, 1,000,001 frees

Что логично, т.к. такие короткие строки не хранятся в куче, они создаются в хвосте самого объекта std::string.

П.С. gcc 6.2

чтобы исключить small string optimization

Туплю.

Класс.

А как тогда у xaizek получилось 4M аллокаций?

Класс.

Как это понимать?

<sarcasm> ... </sarcasm>

Печально, что от лишних аллокаций, получается, никак не избавиться.

(три строки + один вектор) * 1М раз.

С каким-нибудь array_view<string_view> может и аллокаций не будет. А вообще из цикла такое надо выносить, при возможности.

Принимай initializer_list :-)

Да я понял, что три строки + один вектор, но анонимус выше корректно говорит, что initializer_list указывает на константный массив объектов (а конструктор вектора принимает конкретно initializer_list<T>, а не любого типа, приводимого к T), поэтому по стандарту без копирования строк вроде как не обойтись. Отсюда вопрос: как у тебя получилось это обойти?

А вообще из цикла такое надо выносить, при возможности.

Да, я в курсе. Вопрос возник при рефакторинге существующего (не моего) кода. Очевидное решение в том, чтобы вынести этот вектор в статическую константную переменную, но хочется всё-таки не жертвовать читабельностью (если в данной ситуации это вообще возможно).

std::vector::reserve(), не? А llvm/clang из транка такой же результат дают?

std::vector::reserve(), не?

Вообще не в ту степь. У меня вопрос именно про temporary. Так-то, понятно, я могу вынести этот вектор в статическую константную переменную и всё решится, но от этого пострадает читабельность.

А llvm/clang из транка такой же результат дают?

Выше уже объяснили, что это по стандарту так.

как у тебя получилось это обойти?

Судя по всему, GCC на стеке создал три строки объединённые в initializer_list и из него сконструировал вектор 1М раз. Возможно, из-за отсутствия передачи в функцию он проанализировал использование и решил, что можно и так. Могли исправить в GCC6, ибо это как-то непоследовательно.

Т. е. правило «as-if» распространяется и на такие низкоуровневые побочные эффекты, как количество и порядок вызовов аллокатора?

Раз copy ellision разрешено, то выделение памяти должно быть можно пропускать хотя бы для него. Другой вопрос, что это решать компилятору на основе его эвристик, которые ничего не гарантируют (если сможет доказать, что разницы не будет, то соптимизурует).

На побочные эффекты copy ellision может закрыть глаза:

When certain criteria are met, an implementation is allowed to omit the copy/move construction of a class
object, even if the constructor selected for the copy/move operation and/or the destructor for the object
have side effects.

— when a temporary class object that has not been bound to a reference (12.2) would be copied/moved
to a class object with the same cv-unqualified type, the copy/move operation can be omitted by
constructing the temporary object directly into the target of the omitted copy/move

Не вижу выше выдержки из стандарта, только медитация на тему constexpr...

gcc (GCC) 6.2.1 20160830

total heap usage: 7,000,001 allocs, 7,000,001 frees, 1,128,072,704 bytes allocated

void foo(const std::vector<std::string>& vec) {
}

int main() {
	for (unsigned i = 0; i < 1e6; ++i) {
		std::vector<std::string> v;
		
		foo({"foofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofooofoooofoooofoooofoooofooooofoo",
		     "bbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarrbararrbararrbararrbararbarar",
		     "bbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazaz"});
	}

	return 0;
}

total heap usage: 4,000,001 allocs, 4,000,001 frees, 612,072,704 bytes allocated

void foo(const std::vector<std::string>& vec) {
}

int main() {
	for (unsigned i = 0; i < 1e6; ++i) {
		std::vector<std::string> v;
		v.reserve(3);
		v.push_back("foofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofooofoooofoooofoooofoooofooooofoo");
		v.push_back("bbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarrbararrbararrbararrbararbarar");
		v.push_back("bbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazaz");
		
		foo(std::move(v));
	}

	return 0;
}

total heap usage: 1,000,001 allocs, 1,000,001 frees, 48,072,704 bytes allocated

void foo(const std::vector<boost::string_view>& vec) {
}

int main() {
	for (unsigned i = 0; i < 1e6; ++i) {
		std::vector<boost::string_view> v;
		v.reserve(3);
		v.push_back("foofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofooofoooofoooofoooofoooofooooofoo");
		v.push_back("bbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarrbararrbararrbararrbararbarar");
		v.push_back("bbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazbazaz");
		
		foo(std::move(v));
	}

	return 0;
}

Инит лист, энивей, копируется. Если в последнем коде его заюзать будет 2 миллиона аллокаций. Самая плохая фича 11 стандарта, еще и uniform initialization ломает.

Можешь найти этот в стандарте, если хочешь. Мне лень.

http://en.cppreference.com/w/cpp/utility/initializer_list/begin

Очевидное решение в том, чтобы вынести этот вектор в статическую константную переменную, но хочется всё-таки не жертвовать читабельностью

Вот этот момент мне непонятен. Ты выносишь инициализацию вектора в отдельную переменную, даешь ей говорящее название. Как это может быть менее понятно, чем существующий вариант. Если понадобиться, все места, в которых эта переменная используется, можно посмотреть в IDE по «Find Usages». Поясни, почему это станет менее читаемо...

4.8.1 - 4M аллокаций
как в 6.2.1 - 7М получилось ?

а еще 1 выделение для for ?

void foo(const std::vector<boost::string_view>& vec)
foo(std::move(v));

совершенно бесполезный и бестолковый move

У меня вопрос именно про temporary.

ну так конструкция вектора, деструкция, конструкция каждой строки, деструкция. отсюда и выделения.

Я в курсе.

ну так конструкция вектора, деструкция, конструкция каждой строки, деструкция. отсюда и выделения.

Вопрос в том, можно ли заставить компилятор построить вектор единожды (статически), но чтобы это синтаксически красиво выглядело (т. е. без временных переменных). Видимо, нельзя.

Ага, я по привычке написал, думая, что там передача по значению.

Из-за этого не бесполезный, кстати. Можно сигнатуру функции менять и тебе за это ничего не будет.

В лямбду оберни. Лишние переменные будут, но в другом скоупе.

Обалдеть :-) Цепепе настолько гибок, что вынуждает его любителей писать тесты, для понимания что же быстрее, описанный в современном стандарте initializer_list или давний push_back :-) Хе-хе-хе :-)

https://godbolt.org/g/Px3bWW

Ты просто выкинул цэпэпэ

Почему компилятор не может построить вектор со строками статически в .rodata, учитывая, что он передаётся по константной ссылке и не изменяется? Или какие-то свойства языка запрещают так делать?

Всё просто - на уровне компилятора такого языка как С++ не существует - он существует только на уровне рантайма, вернее что-то и существует, но не то, что ты юзаешь.

И каким образом ты пытаешься от компилятора получить что-то писая рантайм конструкции? Да, можно научить компилятор понимать рантайм конструкции, но опять же этого нигде нет, а если и есть то в зачаточном состоянии.

Да, можно научить компилятор понимать рантайм конструкции

Я ожидал, что это уже в каком-то виде сделано. Если такого нигде нет — окей, вопрос исчерпан.

Я ожидал, что это уже в каком-то виде сделано.

А как ты себе это представляешь? Как можно выпилить вызов аллокатора, который можно переопределить в другой единицы трансляции? Никак. Разве что на уровне lto и то libc++ надо собирать с лто и статически линковать.

А как ты себе это представляешь?

Примерно так же, как вызов memcpy(dest, src, sizeof void *) заменяется на два mov.

Ну во-первых совершенно разные ситуации. В одном мы просто инлайним функцию( это не понимание логики рантайма - это просто кастыль из-за ущербанской допотопной системы раздельной сборки, линковки и прочего днища из 50-х годов. С таким же успехом можно просто определить тело memcpy() в единице трансляции - будет тот же самый эффект), а во второй какая-то совершенно левая логика в которой мы могли бы работать с памятью как-то на уровне компиляции.

В сишке единственная память в которой могут создаваться объекты на уровне компиляции - это списки инициализации. На этом всё. Собственно и в С++ это так.

Я думаю, что году к 2030 крестовики дойдут до понятия «компилтайм память», а их язык не будет из себя представлять протухшую сишку из 50-х годов. Раньше чего-то ждать не следует.

Тем более, насколько я знаю, переопределение operator new[]() определено на уровне стандарта крестов, а переопределение malloc() нет. Компиляторы спокойно выпиливают не имеющие эффекта вызовы malloc(), но опять же - только выпиливают.

ущербанской
днища
протухшую сишку

Nick: ftrspnsp
Дата регистрации: 29.11.2016 15:33:46
Последнее посещение: 29.11.2016 18:16:23

Царь, што ль, вернулся?

В одном мы просто инлайним функцию

А замена memmove на memcpy - это не понимание рантайм конструкций?

Ну во-первых совершенно разные ситуации.

Что значит «совершенно разные»? В одном случае компилятор делает некие предположения насчёт поведения функции memcpy(), а именно — что в список её побочных эффектов не входит скачивание двух гигабайт прона тебе в ~/Downloads, следовательно, её можно заменить builtin'ом и развернуть в две инструкции.

А раз так, то компилятор мог бы сделать аналогичные предположения насчёт поведения своего стандартного аллокатора и заменить его вызов на подстановку заранее выделенного адреса в .rodata.

Вот мой ход рассуждений. Дальше ставится вопрос: этот ход рассуждений где-то ошибочен, или же подобная оптимизация попросту «не реализована»?

В одном случае компилятор делает некие предположения насчёт поведения функции memcpy()

Не обязательно. Это может быть простое встраивание по общим правилам с последующей раскруткой цикла.

Где-то — может быть, но у себя в /usr/include я сишного кода memcpy() не наблюдаю.

gcc и clang «знают» про многие библиотечные функции и пользуются этим https://godbolt.org/g/V8PBJX

возможно ли сделать то же самое более оптимально, но не жертвуя читабельностью?

https://www.youtube.com/watch?v=1S1fISh-pag

P. S. крестодети не слышали про boost::string_ref?

Единственный дельный ответ. Спасибо. Разве что я бы тогда сделал так:

template <int D, typename T, typename ...Ts>
const std::vector<T>& make_vector( Ts && ...ts ) {
  static std::vector<T> vec(std::forward<Ts>(ts)...);
  return vec;
}

D — различитель на случай многократного использования с одними и теми же типами (в этом случае нужны, разумеется, разные векторы).

Зачем разные, если const std::vector& ? Собрался его элементы модифицировать?

А замена memmove на memcpy - это не понимание рантайм конструкций?

Это не имеет смысла. Нет.

Замена «шило» на «мыло» в тексте является понимаем конструкций? Нет. Это тупая замена и ничего более.

https://www.youtube.com/watch?v=1S1fISh-pag

Самое смешное, что уже дали рабочее решение, правда опять же у любого крестовика религия всегда первична.

Затем, что в его решении я не могу позвать эту функцию из двух разных мест и получить два разных (но статически сконструированных) вектора.

Типа int спасёт тебя, лол. Кто-нибудь возьмёт и пед^Hредаст одинаковый int из нескольких мест.