История изменений

прежде чем выделить int под счётчик от 0 до 10

Я вроде где-то слышал, что на некоторых (вполне возможно в том числе и x86) платформах наиболее быстро выполняются команды работы с переменными соответствующими разрядности процессора или кратные ей (например, на x86_64 такими будут 32-битные и 64-битные, а вот 16-битные и 8-битные инструкции будут тормозить, на x86 оптимальный размер переменной лишь один - 32 бита, на всяких ARM не знаю, но подозреваю, что тоже 32 бита). И уж точно быстрее выполняются обращения к выровненным данным. В свете этой информации int вполне может оказаться быстрее char, если у тебя не 8-битный процессор. А в оптимизации по скорости нет ничего зазорного на ПК, это только под микроконтроллеры компилируют с -Os.

Кстати, насчёт тормозов инструкций не той разрядности вполне есть пруф. Команды, работающие с 16-разрядными переменными на x86, кодируются с помощью специального префикса, а 32-разрядные - без него. Как следствие, процессор парсит команду дольше из-за этого самого лишнего байта префикса. И код получается жирнее из-за этих самых префиксов.

То есть сэкономив 2 байта и сделав 16-битную переменную вместо 32-битной на x86 ты потеряешь по байту на каждом обращении к ней (а обращаются к переменной как правило больше одного раза), а также немного скорости. Стоит ли игра свеч?

Зато стандарт более-менее гарантирует, что int будет иметь оптимальный размер для данной платформы (разве что на всяких восьмибитных микроконтроллерах int превышает размер машинного слова и поэтому char даст выигрыш), поэтому вполне разумно пихать его везде, где нет иных причин выбрать другой тип (для строки, а не одиночной переменной char уже даст очень заметный выигрыш в размере, поэтому стоит выбрать таки его, где-то int мало и надо long long).

прежде чем выделить int под счётчик от 0 до 10

Я вроде где-то слышал, что на некоторых (вполне возможно в том числе и x86) платформах наиболее быстро выполняются команды работы с переменными соответствующими разрядности процессора или кратные ей (например, на x86_64 такими будут 32-битные и 64-битные, а вот 16-битные и 8-битные инструкции будут тормозить, на x86 оптимальный размер переменной лишь один - 32 бита, на всяких ARM не знаю, но подозреваю, что тоже 32 бита). И уж точно быстрее выполняются обращения к выровненным данным. В свете этой информации int вполне может оказаться быстрее char, если у тебя не 8-битный процессор. А в оптимизации по скорости нет ничего зазорного на ПК, это только под микроконтроллеры компилируют с -Os.

Кстати, насчёт тормозов инструкций не той разрядности вполне есть пруф. Команды, работающие с 16-разрядными переменными на x86, кодируются с помощью специального префикса, а 32-разрядные - без него. Как следствие, процессор парсит команду дольше из-за этого самого лишнего байта префикса. И код получается жирнее из-за этих самых префиксов.

То есть сэкономив 2 байта и сделав 16-битную переменную вместо 32-битной на x86 ты потеряешь по байту на каждом обращении к ней (а обращаются к переменной как правило больше одного раза), а также немного скорости. Стоит ли игра свеч?

Зато стандарт более-менее гарантирует, что int будет иметь оптимальный размер для данной платформы (разве что на всяких восьмибитных микроконтроллерах int превышает размер машинного слова и поэтому char даст выигрыш), поэтому вполне разумно пихать его везде, где нет иных причин выбрать другой тип (для строки char уже даст очень заметный выигрыш в размере, поэтому стоит выбрать таки его, где-то int мало и надо long long).

прежде чем выделить int под счётчик от 0 до 10

Я вроде где-то слышал, что на некоторых (вполне возможно в том числе и x86) платформах наиболее быстро выполняются команды работы с переменными соответствующими разрядности процессора или кратные ей (например, на x86_64 такими будут 32-битные и 64-битные, а вот 16-битные и 8-битные инструкции будут тормозить, на x86 оптимальный размер переменной лишь один - 32 бита, на всяких ARM не знаю, но подозреваю, что тоже 32 бита). И уж точно быстрее выполняются обращения к выровненным данным. В свете этой информации int вполне может оказаться быстрее char, если у тебя не 8-битный процессор. А в оптимизации по скорости нет ничего зазорного на ПК, это только под микроконтроллеры компилируют с -Os.

Кстати, насчёт тормозов инструкций не той разрядности вполне есть пруф. Команды, работающие с 16-разрядными переменными на x86, кодируются с помощью специального префикса, а 32-разрядные - без него. Как следствие, процессор парсит команду дольше из-за этого самого лишнего байта префикса. И код получается жирнее из-за этих самых префиксов.

То есть сэкономив 2 байта и сделав 16-битную переменную вместо 32-битной на x86 ты потеряешь по байту на каждом обращении к ней (а обращаются к переменной как правило больше одного раза), а также немного скорости. Стоит ли игра свеч?

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

прежде чем выделить int под счётчик от 0 до 10

Я вроде где-то слышал, что на некоторых (вполне возможно в том числе и x86) платформах наиболее быстро выполняются команды работы с переменными соответствующими разрядности процессора или кратные ей (например, на x86_64 такими будут 32-битные и 64-битные, а вот 16-битные и 8-битные инструкции будут тормозить, на x86 оптимальный размер переменной лишь один - 32 бита, на всяких ARM не знаю, но подозреваю, что тоже 32 бита). И уж точно быстрее выполняются обращения к выровненным данным. В свете этой информации int вполне может оказаться быстрее char, если у тебя не 8-битный процессор. А в оптимизации по скорости нет ничего зазорного на ПК, это только под микроконтроллеры компилируют с -Os.

Кстати, насчёт тормозов инструкций не той разрядности вполне есть пруф. Команды, работающие с 16-разрядными переменными на x86, кодируются с помощью специального префикса, а 32-разрядные - без него. Как следствие, процессор парсит команду дольше из-за этого самого лишнего байта префикса. И код получается жирнее из-за этих самых префиксов.

То есть сэкономив 2 байта и сделав 16-битную переменную вместо 32-битной на x86 ты потеряешь по байту на каждом обращении к ней (а обращаются к переменной как правило больше одного раза), а также немного скорости. Стоит ли игра свеч?

прежде чем выделить int под счётчик от 0 до 10

Я вроде где-то слышал, что на некоторых (вполне возможно в том числе и x86) платформах наиболее быстро выполняются команды работы с переменными соответствующими разрядности процессора или кратные ей (например, на x86_64 такими будут 32-битные и 64-битные, а вот 16-битные и 8-битные инструкции будут тормозить). И уж точно быстрее выполняются обращения к выровненным данным. В свете этой информации int вполне может оказаться быстрее char, если у тебя не 8-битный процессор. А в оптимизации по скорости нет ничего зазорного на ПК, это только под микроконтроллеры компилируют с -Os.

Кстати, насчёт тормозов инструкций не той разрядности вполне есть пруф. Команды, работающие с 16-разрядными переменными на x86, кодируются с помощью специального префикса, а 32-разрядные - без него. Как следствие, процессор парсит команду дольше из-за этого самого лишнего байта префикса. И код получается жирнее из-за этих самых префиксов.

То есть сэкономив 2 байта и сделав 16-битную переменную вместо 32-битной на x86 ты потеряешь по байту на каждом обращении к ней (а обращаются к переменной как правило больше одного раза), а также немного скорости. Стоит ли игра свеч?

прежде чем выделить int под счётчик от 0 до 10

Я вроде где-то слышал, что на некоторых (вполне возможно в том числе и x86) платформах наиболее быстро выполняются команды работы с переменными соответствующими разрядности процессора или кратные ей (например, на x86_64 такими будут 32-битные и 64-битные, а вот 16-битные и 8-битные инструкции будут тормозить). И уж точно быстрее выполняются обращения к выровненным данным. В свете этой информации int вполне может оказаться быстрее char, если у тебя не 8-битный процессор. А в оптимизации по скорости нет ничего зазорного на ПК, это только под микроконтроллеры компилируют с -Os.

Кстати, насчёт тормозов инструкций не той разрядности вполне есть пруф. Команды, работающие с 16-разрядными переменными на x86, кодируются с помощью специального префикса, а 32-разрядные - без него. Как следствие, процессор парсит команду дольше из-за этого самого лишнего байта префикса. И код получается жирнее из-за этих самых префиксов.

То есть сэкономив 2 байта и сделав 16-битную переменную вместо 32-битной на x86 ты потеряешь по байту на каждом обращении к ней (а обращаются к переменной как правило больше одного раза), а также немного скорости.

прежде чем выделить int под счётчик от 0 до 10

Я вроде где-то слышал, что на некоторых (вполне возможно в том числе и x86) платформах наиболее быстро выполняются команды работы с переменными соответствующими разрядности процессора или кратные ей (например, на x86_64 такими будут 32-битные и 64-битные, а вот 16-битные и 8-битные инструкции будут тормозить). И уж точно быстрее выполняются обращения к выровненным данным. В свете этой информации int вполне может оказаться быстрее char, если у тебя не 8-битный процессор. А в оптимизации по скорости нет ничего зазорного на ПК, это только под микроконтроллеры компилируют с -Os.

прежде чем выделить int под счётчик от 0 до 10

Я вроде где-то слышал, что на некоторых (вполне возможно в том числе и x86) платформах наиболее быстро выполняются команды работы с переменными соответствующими разрядности процессора. И уж точно быстрее выполняются обращения к выровненным данным. В свете этой информации int вполне может оказаться быстрее char, если у тебя не 8-битный процессор. А в оптимизации по скорости нет ничего зазорного на ПК, это только под микроконтроллеры компилируют с -Os.

прежде чем выделить int под счётчик от 0 до 10

Я вроде где-то слышал, что на некоторых (вполне возможно в том числе и x86) платформах наиболее быстро выполняются команды работы со переменными соответствующими разрядности процессора. И уж точно быстрее выполняются обращения к выровненным данным. В свете этой информации int вполне может оказаться быстрее char, если у тебя не 8-битный процессор. А в оптимизации по скорости нет ничего зазорного на ПК, это только под микроконтроллеры компилируют с -Os.