Член класса/структуры типа uint8_t * или int8_t *, оптимизация?

Question

[floppa322]

Всем привет

Правильно ли я понимаю, что, если в классе есть член uint8_t * или int8_t * (char), например, указатель на начало массива, и в теле метода присутствуют разыменования данного члена и дальнейшие присваивания (а возможно даже и цикл присваиваний), то для того, чтобы компилятор мог применить оптимизацию, нужно закешировать член класса в локальную переменную ? Ссылка на обсуждение похожей темы
То есть вместо:
uint8_t * buffer; // Член класса/структуры

buffer[0] = value1;
buffer[1] = value2;
buffer[2] = value3;
...
buffer[n] = valueN;

Писать:

uint8_t * _buffer = buffer;
_buffer[0] = value1;
_buffer[1] = value2;
_buffer[2] = value3;
...
_buffer[n] = valueN;

И второй вопрос: можно ли вместо того, чтобы делать локальную копию этой переменной, просто добавить в сигнатуру метода __restrict, гарантировав, что this не изменится в теле метода ? Потому как, если я правильно понял, согласно 1-му ответу здесь

In that case, writing to this->target[0] would alter the contents of this (and thus, this->target).

может поменять константный в соответствии с сигнатурой метода __restrict указатель this ?

P.S.:

1. Замерял скорость работы этого участка кода с -O3 - при небольшом количестве присваиваний скорость отличается на 10-15%, а если присваивания происходят, например, в цикле с количеством итераций 10_000+, то скорость отличается в 2 раза
   
2. Ну и если заменить uint8_t *, например, на uint16_t *, то версия с кэшированием переменной не даёт никакого прироста производительности
   

Answer 1

[Wataru]

Тут проблема не в том, что член класса char*, а в том, что запись идет в char*, и из-за strict aliasing правил - это может быть запись куда угодно, в том числе в &this. Кешировать пришлось бы любой член структуры, любого типа.

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

Частично это можно решить кешированием, можно попробовать поменять типы кое где. Но делать это не стоит - это та самая преждевременная оптимизация, о которой писал Кнут. Лучше алгоритм хороший и структуры данных правильные в вашей программе выберите. А уже дальше, если профилирование покажет, что вот тут вот узкое место, то можно смотреть на ассемблерный код и думать, как убедить компилятор геренировать что-то более быстрое.

Comments

[floppa322]

Частично это можно решить кешированием, можно попробовать поменять типы кое где.

А добавление в сигнатуру метода __restrict (void method () __restrict {}) не является эквивалентным кэшированию в локлаьную переменную ? за исключением того, что ничего кэшировать не придётся, так как компилятор уже будет знать, что переменная ни с чем в рамках данного метода не overlapp'ится" в памяти ?

[floppa322]

Тут проблема не в том, что член класса char*, а в том, что запись идет в char*, и из-за strict aliasing правил - это может быть запись куда угодно, в том числе в &this. Кешировать пришлось бы любой член структуры, любого типа.

То есть если в классе/структуре есть член типа unsigned/signed char *, то из-за strict aliasing пришлось бы кэшировать любую переменную (например, перед обработкой её в цикле) ?

Эту же проблему можно воспроизвести в меньшем масштабе, если у вас в цикле есть запись в int* и чтение какой-то другой не меняющейся int переменной. Особенно, когда переменная в куче и указатель пришел в параметре функции.

Ну и второе правило, если метод принимает указатели на один и тот же тип и они точно не overlapp'ятся в памяти, то нужно добавлять __restrict (в зависимости от компилятора(лучше макросом)), если конечно метод очень часто вызывается

static void InterpolateSnapshot_Hermite_WithExtrapolation( float t,
                                                           float step_size,
                                                           float extrapolation,
                                                           const __restrict CubeState * a,
                                                           const __restrict CubeState * b,
                                                           __restrict view::ObjectUpdate * output )

Вот, например, нашёл в реальном проекте, только непонятно зачем __restrict у view::ObjectUpdate * output, он же тут только 1, значит ни с кем алиасится не может

[res2001]

floppa322, Это говорит компилятору, что других указателей, ссылающихся на ту же область памяти, что и this в функции нет. Поэтому он может уверенно закэшировать this в регистре и не перечитывать его каждый раз.

[floppa322]

res2001, хм, а если у меня, например, в объекте первое поле uint8_t * buffer, и я в методе сделаю что-то вроде &(this->buffer[0]), тогда и &(this->buffer[0]) и uint8_t * buffer на одну и ту жу область ссылаться будут, не приведёт ли это к UB? Или достаточно просто не пользоваться псевдонимом для buffer в виде &(this->buffer[0]) ? ну то есть, если начал писать buffer[i] = value, то в этом же месте не нужно писать что-то вроде this->buffer[i] = value (где i может быть = 0)

или я этим просто обещаю компилятору, что именно сам this не буду менять, а не то что под ним лежит, то есть:
this->buffer[0] = value - так можно
а вот this = something нельзя

просто тогда не понятно, почему все методы класса по умолчанию не __restrict, ведь мы обычно никогда ничего не записываем в сам this ( this = something )

[res2001]

floppa322,

а если у меня, например,

Когда это происходит в пределах одной функции, то компилятор справится с этими зависимостями и оптимизирует там где можно и не оптимизирует там где нельзя.
Но компилятор не может гарантировать, что параметры функции не ссылаются на одну область памяти, поэтому генерирует код без оптимизаций. Указывая restrict вы гарантируете компилятору от себя, что пересечений по памяти не будет и компиялтор начинает резвится как может.

я этим просто обещаю компилятору, что именно сам this не буду менять

restrict относится к памяти на которую ссылается указатель, а не к самому указателю.
Так что в моем сообщении выше "закэшировать this в регистре" - не правильно. Компилятор может кешировать значение this->buffer из вашего примера, в этом случае убирается лишняя команда чтения buffer, о которой вы писали - будет использована ранее сохраненная в регистре информация.

Тёмная материя :)

[floppa322]

res2001, а для случая, когда заалиасится может this и его член - uint8_t * (как в шапке моего вопроса), я так понимаю, лучшим решением будет просто пометить метод как __restrict ? __restrict для методов в C++

На всякий случай для ясности:

class Example
{
private:
    uint8_t * someSelfAliasableMember;
    int a;
    int b;
    int c;

public:
    
    Example() : someSelfAliasableMember(new uint8_t[100]) {}

    void doSomething() __restrict
    {
        for (int32_t i = 0; i < 10; ++i)
        {
            someSelfAliasableMember[i] = i;
        }
    }
};

То есть, насколко я понимаю, в случае передаваемых в функцию аргументов указателей (если они одного типа) они могут ссылаться на один участок памяти, и тогда, если они таки не ссылаются на один участок, их можно пометить, как __restrict
А в случае с членом класса, из-за того, что signed/unsigned char * может ссылаться на что угодно(не наруушая strict aliasing), включая this, как __restrict уже нужно пометить именно сам метод (Первый ответ к вопросу)

[res2001]

floppa322, Если это для вас критично, то restrict может немного добавить скорости.

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

[floppa322]

res2001, на самом деле кое-где это и не такая уж микро оптимизация, например, в методе для разрешения коллизий, который сначала находят пары-кандидаты для разрешении коллизии, а затем разрешает их, а пар (пара - состоит из каких-то двух типов T *, например, T - это какой-нибудь Shape) этих может быть очень много, это довольно прилично скажет на скорости работы алгоритма

я просто не понимаю, почему __restrict по умолчанию не применяется к сигнатуре метода, делая this - константным указателем, потому как редко в коде встретишь что-то вроде this = something

[res2001]

floppa322, Все может быть, но в оптимизациях всегда надо тестировать до и после, иначе не понять работает ли твоя оптимизация. Так что все подобные рассуждения теоретические.
Restrict это совсем не то что константный указатель.
Кстати, this, является rvalue, поэтому this = something нигде и не встретишь.

Попробуйте объявить someSelfAliasableMember из вашего последнего примера с restrictом.

[floppa322]

res2001, хм, тогда либо википедия дезинформирует

Ключевое слово __restrict для метода структуры или класса C++ обозначает, что указатель this имеет тип «T * __restrict const». Пример:

,
либо я не понимаю, тогда зачем this делать константным

[res2001]

floppa322, Учитывая, что restrict в стандарте нет, то какой конкретно тип будет у this в этом случае сильно зависит от компилятора.
const в данном примере не принципиально и никак не влияет на тему нашего обсуждения.
Константный указатель вполне может указывать на не константный объект.

[floppa322]

res2001, в MSVC это слово в сигнатуре метода просто делает тип restrict у this


Почему не влияет ? Как раз теперь, в someSelfAliasableMember точно не может быть this (по крайней мере так будет думать компилятор)

[res2001]

floppa322, Там не обязательно не может быть this, важно, что там не может быть какого-то другого значения, отличного от того, что он прочитал при прошлом обращении к этой же памяти.
И это он будет думать не из-за const, а из-за restrict.
const в данном случае делает сам this константным, а не память под ним.

Answer 2

[res2001]

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

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

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

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

С restrict можно поиграть, но в чистом С++ его нет, на сколько я знаю, но можно включить расширения в gcc/clang и, возможно его можно будет использовть в плюсовом коде. Но применяйте его лучше сразу к локальному bufferу, а не к this.

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

Comments

[Василий Банников]

вычислять усредненное время работы

По хорошему, во время тестов надо ещё доверительный интервал построить, чтобы понять, действительно ли быстрее/медленнее работает, или всё в рамках погрешности.

[floppa322]

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

В версии без кэширования в локальную переменную появляется дополнительная инструкция перед каждым присваиванием