Размер указателя

sizeof(void*);// Размер указателя на любой тип равен 8, почему так много? И можно ли как-нибудь узнать сколько под указатель выделено памяти не смотря в исходники?

0

Сообщение от Renji Корректировать this надо только при множественном наследовании в потомке.

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

Добавлено через 5 минут

Сообщение от Renji Вызов по 8-байтовому указателю: 1) Прочитать адрес метода. 2) Вызвать метод. "Вычесть ptrdiff_t из указателя на объект" делает код метода, в который ptrdiff_t Вхардкорден один раз. Не замечаете что в моем варианте число действий меньше, а код компакней и быстрее?

Тут вы снова хитрите. Вызов по вашему 8-байтовому указателю - это не вызов метода. Это вызов вызывалки. А внутри вызывалки будет по-прежнему тот же самый ptrdiff_t, только константный, а не времени выполнения и затем уже вызов собственно метода.

Код возможно-спорно компактней, но уж точно не быстрее. Ваш код медленее.

----------------------------------

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

Тут надо еще заметить, что компиляторы давно уже используют ваш метод с промежуточной вызывалкой в ситуациях, когда указатель инициализируется адресом виртуального метода. Указатель в такой ситуации ставится именно на промежуточную вызывалку. При этом они старательно экономят на генерации вызывалок - используется одна и та же промежуточная вызывалка для методов разных классов, занимающих одну и ту же позицию в VMT (и, возможно, одну и ту же "дельту" для this). Т.е. на низком уровне вызывалки с одинаковым результирующим кодом смело сливаются в одну. Таким образом обвинять авторов компиляторов в "лени" следовать этому подходу не приходится: они ему уже следуют в случае с виртуальными методами.

Однако в случае с невиртуальными методами этот подход не используется. Возможно, именно из-за невозможности "сэкономить" не генерации отдельных вызывалок.

0

Сообщение от avgoor Будут ли ваши обертки инлайниться?

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

Сообщение от avgoor Если да, то какая разница между ними и ptrdiff (учитывая, что и то и то в кэше)? Если нет то как два вызова улучшат код?

Как я понимаю, ассемблер вы не изучали?
1) Процессор работает с машинными словами. void* можно записать куда ни будь одной командой, потому что void* влезает в машинное слово. А вот std::pair<void*,size_t> в машинное слово не влезает и одной командой его записать нельзя. Значит, нужно две команды и код раздувается.
2) Чтобы передать указатель в callFoo, его надо записать в специально отведенное место. Стек или регистры процессора - не важно. Чем толще указатель, тем дольше будете записывать. Прямое следствие пункта 1.
3) Чтобы вызвать метод, вам нужно вычесть ptrdiff из this. На уровне ассемблера это делается одной командой. А вот под капотом процессора это все равно превратится в батарею "вычислить адрес, прочитать, вычесть". Это опять же тормознутей чем "вычесть вшитую в код константу". Хотя, может вам повезет и ptrdiff будет изначально в регистре.

Сообщение от TheCalligrapher Тут вы снова хитрите. Вызов по вашему 8-байтовому указателю - это не вызов метода. Это вызов вызывалки.

Так понятней?

0

Сообщение от Renji Как я понимаю, ассемблер вы не изучали?

А вы похоже изучали ассемблер 8086.
Если мы прочитали указатель с ptrdiff - он гарантированно в кэше. А ваша вызывалка? Сперва дергаем в кэш вызывалку, потом дергаем в кэш сам метод. Разницы не видите?

Добавлено через 4 минуты

Сообщение от Renji Так понятней?

Так не получится.

0

Сообщение от Renji Так понятней? Assembler 1 2 3 4 5 //Точка входа в "вызывалку" sub ecx,1234; //точка входа в метод bla-bla-bla ret;

Ну, так красиво, разумеется, не получится. Самое лучшее, что может получиться это

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

0

Сообщение от avgoor Если мы прочитали указатель с ptrdiff - он гарантированно в кэше. А ваша вызывалка? Сперва дергаем в кэш вызывалку, потом дергаем в кэш сам метод. Разницы не видите?

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

Сообщение от TheCalligrapher Ну, так красиво, разумеется, не получится.

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

0

Сообщение от Renji независимо от использования ptrdiff.

Один кэш мисматч от двух не отличаете? Тогда и виртуальные функции от обычных по быстродействию не отличаются, че уж там.

0

Сообщение от avgoor Один кэш мисматч от двух не отличаете?

Едем дальше. По каким таким мистическим причинам sub rcx,[rdi+8] перед каждым call кэш-мисматчи не плодит, а один разнесчастный sub rcx,1234 в начале тела метода - плодит? У вас в месте появления sub rcx,[rdi+8] кэш обретает свойства резины?
И да, один кэш-мисматч на тысячу вызовов, от двух кэш-мисматчей на тысячу вызовов я без лупы не отличаю.

Сообщение от avgoor Тогда и виртуальные функции от обычных по быстродействию не отличаются, че уж там.

А там обрушивается механизм предсказания переходов. Это отдельная песня.

0

Сообщение от Renji перед каждым call кэш-мисматчи не плодит

Потому, что и ptr ptrdiff находятся рядом и как правило в стеке.

Сообщение от Renji разнесчастный sub rcx,1234 в начале тела метода - плодит?

Потому, что в общем случае необходимость в sub rcx, 1234 возникает в другой единице трансляции.

0

Сообщение от avgoor Потому, что и ptr ptrdiff находятся рядом и как правило в стеке.

У вас, похоже, каша в голове. "Дергают вызывалку" в кэш кода, ptrdiff находится в кэше данных. Одно с другим не связано никак. Чтобы у вас возникали постоянные кэш-мисматчи кода, нужно чтобы этот код постоянно из кэша вываливался. А это произойдет тогда, когда код слишком разжиреет. Что и обеспечивается тучей sub rcx,[rdi+8].

Сообщение от avgoor Потому, что в общем случае необходимость в sub rcx, 1234 возникает в другой единице трансляции.

Кэш наполняется кэш-рядами, а не единицами трансляции.

0

Сообщение от Renji Кэш наполняется кэш-рядами, а не единицами трансляции.

Имелось ввиду, что ваша обертка, в общем случае, не будет рядом с методом.

Добавлено через 10 минут
Renji, Чтобы скорректировать указатель, в любом случае надо прочитать величину коррекции. Только в вашем случае читается адрес по которому лежит вызывалка (часть call вызывалка), а потом читается смещение (внутри вызывалки), а потом читается адрес метода (как jmp метод).
В моем случае читатется смещение и читается адрес метода (причем все лежит рядом и в кэше).

0

Сообщение от avgoor Имелось ввиду, что ваша обертка, в общем случае, не будет рядом с методом.

Это да, в худшем случае обертка скушает целый кэш-ряд. Но ваши sub rcx,[rdi+8] в худшем случае скушают весь кэш и еще попросят. Их количество ведь ничем не ограничено.

Сообщение от avgoor Renji, Чтобы скорректировать указатель, в любом случае надо прочитать величину коррекции.

Вот только у меня надо прочитать только на стадии декодирования команды, а потом все осядет в кэше трасс. У вас же надо читать при каждом исполнении команды. Причем, прежде чем прочитать величину коррекции, вам надо узнать адрес этой величины. И с виду простое "ну, адрес указателя+8 же" все равно не проходит бесплатно.

0

Сообщение от Renji Их количество ведь ничем не ограничено.

Но, как правило, указателей на член очень мало (Если они используются как делегаты дополнительные 8 байт в классе роли не сыграют).

Сообщение от Renji У вас же надо читать при каждом исполнении команды.

sub rcx, 8 и sub rcx, [rbp+off] при прочих равных (все в кэше) выполнятся практически за одно и то же время (На этом даже был хак - быстрое умножение на адресной арифметике). Но! Если что-то из данных не в кэше...

0

Сообщение от avgoor Но, как правило, указателей на член очень мало

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

Сообщение от avgoor Но! Если что-то из данных не в кэше...

sub rcx, 8, в отличие от, не использует кэш данных. Если же данных нет в кэше кода, то тормозить начнет любой код, будь то sub rcx, [rbp+off], sub rcx, 8 или вообще nop.

0

Сообщение от Renji sub rcx, 8, в отличие от, не использует кэш данных

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

Добавлено через 4 минуты
Предупреждая отсылки к предсказанию ветвей и пр. - они принципиально ничего не меняют.

0

Сообщение от avgoor Какая разница, какой кэш он жрет.

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

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

Во-первых, не страницу (четыре кило), а ряд (32/64 байта). Во-вторых, пачка sub rcx, [rbp+off] сожрет ровно тот же ряд. Но пачек, в который раз повторяю, может быть 100500, а вызывалка одна.

0

0

Сообщение от Kastaneda Не по теме: PAE как раз предназначена для страничной организации памяти, а не сегментной.

0

Сообщение от Renji а ряд (32/64 байта)

И для L1, и для L2, L3?

Добавлено через 7 минут


Добавлено через 4 минуты

Сообщение от Renji 32/64 байта

К тому же, если повезет, ptr и ptrdiff будут в одной кэш линии (а чтоб гарантированно повезло - химичим с выравниванием).

0

Сообщение от avgoor И для L1, и для L2, L3?

Для L2 на четвертом пне было 128 байт. Тоже, до страницы далеко.

Добавлено через 2 минуты

Сообщение от avgoor К тому же, если повезет, ptr и ptrdiff будут в одной кэш линии

Если повезет, нагрузку на процессор будет создавать 16 килобайтовый код, повторяющийся миллион раз. Что возвращает нас к исходному - если L1 кэш - 32 килобайта, а код в нем - 16 килобайт, то не все ли равно добавится к этому коду еще один кэш-ряд или нет?

0

Сообщение от Renji то не все ли равно добавится к этому коду еще один кэш-ряд или нет?

По сути - все равно.
Но, зачем городить огород (особенно новый keyword) если это не дает никакого профита?

0