И еще - если тип данных меньше, не значит, что работает с ним процессор быстрее. Например, если взять структуру:
struct {
int8_t a; int8_t b; int8_t c; int8_t d;
}
То работать с ней на x86 будет медленней, чем с:
struct {
int32_t a; int32_t b; int32_t c; int32_t d;
}
Так как процессор может прочитать только выровненные данные. Если обратиться по адресу без выравнивания, то произойдет ошибка, её обработчик вытащит выровненные данные, затем побитовыми операциями приведет их к нужному виду. Например, чтобы прочитать 'c' из структуры будет выполнено что-то вроде:
(int8_t)((*(int32_t*)(&st) >> 8 ) && 0xFF)
эта, можно воткнуть pragma pack и все поровняется 
та небудет ошибки, будут лишние такты на смещения, мыж не в эпоху старых маков живем где ОС ребуталась при обращению к неровным данным
Ошибка не обязательно как-то отразится на выполнении. Она просто будет автоматически обработана, как раз ценой этих нескольких тактов (реально это как-то повлияет только если, например, 4 байтовое значение не будет выровнено по 4^n байтам, тогда из-за этого чтение перестанет быть атомарной операцией). Я знаю, что компиляторы сами сейчас выравнивают структуры. Просто тут похоже распространен миф, что раз маленькие числа - обязательно быстрее.
Вов больше проц грузит, чем видео.
Это было из-за циферек которые сплюснули, да и то не везде, а лишь в боях 15+рыл, ну и процц i5+ спокойно это обрабатывал в пассивном режиме, а с выходом WoD большая часть нагрузки на процц будет связанна с раскрытием потенциала видяхи, как и в любых других современных играх.
В данный момент с видео есть проблемы например на PTR на фулах может вышибить картинку в черный экран на доли секунды, надеюсь на лайв данная проблема не просочится =)
Для машины нет разницы между 1+1 и 100000+100000, время выполнения операции будет одинаковым.
да что вы говорите? 1+1 и 100000+100000 между прочим тоже разные типы данных и занимают разное колличество байт в памяти
Совсем не обязательно разные. Если тип 32 битное знаковое, то можно и 2 и 200000 хранить в нём, от этого не изменится тот факт, что тип занимает 4 байта в памяти. Даже 8 битное значение после выравнивания может фактически занимать 4 байта.
Предлагаю закрыть эту тему насчет типов данных, так как тут уже все что можно уже было сказано. Надеюсь к тому, что я сказал, что сплющивание не повлияет на производительность никак - вопросов нет? Все остальное, что я писал - это лишь попытка опровергнуть некоторые мифы по поводу влияния цифр на производительность. Оно хоть и есть, но проявляется только при смене типа данных (которого не будет) или при работе с неограниченными целыми (которые опять же не используются). В остальных случаях разница настолько мала, что совершенно не заметна.
Тема: Переход к формату CASC в версии 6.0.2 (Прочитано 45226 раз)
