Имеет ли смысл использовать короткие целые типы в локальных переменных и параметрах?

[Spectramine]

Вопрос, в общем, далек от программирования на ZX-Spectrum, и касается современных архитектур. Но, надеюсь, не будет сочтен оффтопом.

Итак, имеет ли смысл использовать короткие целые типы в переменных и параметрах? Допустим, мы знаем, что в данном случае диапазона выбранного короткого целого типа (например, shortint / signed char) нам хватает с головой. Надо ли нам использовать именно его, или выгоднее не париться, и использовать целый тип по умолчанию (32/64-битный)? Вопрос экономии памяти в данном случае неоднозначен, т.к. команды работы с 32битными значениям обычно короче, чем с 8-16 битными (по крайней мере, для x86, если я не ошибаюсь). Да и вообще он на современных архитектурах малоактуален, особенно для переменных, а не больших массивов данных. Более актуален вопрос быстродействия.

У кого какие соображения по этому поводу? Стоит ли крохоборствовать, выбирая для переменных/параметров по возможности короткие целые типы, или выгоднее и правильнее писать int[eger] и не париться везде, где только можно? Или даже так - будет ли работать программа быстрее (в общем случае), если в ней везде, где только можно, используются короткие целые типы для переменных и параметров?

[Advertiser]

[Oleg N. Cher]

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

И ещё один вопрос: насколько эффективна 32-битная арифметика на 64-битных архитектурах? Предпочтительно ли на них использовать 32-битную арифметику вместо 64-битной? Будет ли это быстрее/короче/эффективнее хоть каким-то образом?

Но вопросы эти не так просты, сходу я не разобрался, хотя несколько часов добросовестно гуглил. И, видимо, дизассемблировать код передачи параметров и считать такты - в общем случае неправильно. Это же не Z80, на i80x86 есть многоуровневые кэши процессора и прочее.

Хорошая книга по подобным вещам: Крис Касперски - Техника оптимизации программ. Эффективное использование памяти

[shurik-ua]

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

[s_kosorev]

в stdint есть fast типы, которые говорят, дай мне к примеру тип, в который влезет 16 бит и он будет максимально быстро работать

по поводу 64/32, есть eabi где указатели 32 бит а данные 64 бит, но вообще компилятору ничего не мешает в 64 бит коде использовать 32bit инструкции для чтения констант, работы с памятью итд и он достаточно часто использует, но сами инструкции обработки использовать 64бит, они меньше по размеру, так как меньше забивается кеш и в итоге больше быстродействие, но это x86, как обстоят дела с ARM MIPS я хз, еще важно выравнивание по кеш линиям, MSVC очень часто вставляет NOP между инструкциями что бы инструкция не занимала 2 кеш строки

[Shiny]

Возьмите рекурсивный алгоритм, где передаются через стек значения. Например, DE=Y.X(хватит для экрана ZX) и сравните с 16-битными значениями.

[mastermind]

Для арифметики типично максимальное быстродействие для нативного размера слова процессора. (т.е. 32 бита на 32-битном процессоре, 64 на 64-битном и т.п., 8/16-бит арифметика на обоих из вышеперечисленных может быть медленнее чем "нативная").
Но если речь о хранении, то чем больше размер, тем, естественно, больше нагрузка на кэш, больше доступов к памяти и т.п. Касательно хранения также: на быстродействие еще влияет выравнивание данных. (смотреть в документации по конкретному процессору)

Вот на этом сайте можно поиграться с типами в коде по-быстрому, посмотреть во что ассемблируется: https://godbolt.org/

- - - Добавлено - - -

Кое какая интересная информация о том в каких случаях и как C (gcc 64 бит) упаковывает/распаковывает однобайтные значения: https://ro-che.info/articles/2017-01-25-word8-space
tl;dr: байтовые параметры и при операциях над байтами (т.е. в случаях когда данные в регистрах) распаковывает до 64 бит (8 байт), в массивах данные хранит как есть - 1 байт на элемент.

[Alex Rider]

Сдается мне, компиляторы принудительно используют нативную длину целых параметров независимо от того, что ты хочешь туда передавать. Потому как кладет их на стек. Использовать меньшие типы в качестве аргументов имеет смысл только для отладки с включенным контролем выхода за границы тпов.

[Spectramine]

Сдается мне, компиляторы принудительно используют нативную длину целых параметров независимо от того, что ты хочешь туда передавать. Потому как кладет их на стек. Использовать меньшие типы в качестве аргументов имеет смысл только для отладки с включенным контролем выхода за границы тпов.

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

- - - Добавлено - - -

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

[Shiny]

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

не всегда кмк

[kgbplus]

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