Здравствуйте, Alexander G, Вы писали:

AG>С точки зрение перформанса, есть случаи, где беззнаковые немного лучше, и нет случаев, где знаковые лучше.

Именно в C и C++ у знаковых принципиально лучше с точки зрения производительности, что позиция, что программист всегда позаботился о переполнениях, позволяет массу оптимизаций, типа замены a+1>a на true. Были отзывы о получении 20-50% выигрыша на этом в отдельных характерно интересных случаях.
Это хуже с точки зрения корректности (и потому я всегда говорю, что подобные оптимизации должны разрешаться только там, где программист это разрешил), иначе получаем проблемы типа такого

Автор: Кодт
Дата: 18.06.14

, но для производительности — таки в шоколаде.

AG> Примеры пользы беззнаковых:
AG>- замена деления на степень двойки на сдвиг. Включая неявное деление в i < container.size()

Если компилятор отловил, что по факту там неотрицательное — может заменить и так.
Если нет — получается только 3-4 дополнительных команд на регистрах — ничто по сравнению с тормозами RAM.

AG>- fused операция при сравнении и переходе: while (i > 0) или for ( i ; i < 10 ; i++ ) CMP и JCC выполняются как одна операция только для беззнаковых.

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

AG>- обычные умножение/деление быстрее для беззнаковых

Что сравнивали-то? Intel рисует (почти) противоположное — для длинного умножения времена одинаковы, а для короткого (которому пофиг на знак) на 1-2 такта меньше (3 вместо до 5).

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

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

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

И это тоже (хотя неудобно при отображении на какие-то внешние сущности вроде машинных адресов).