Системные библиотеки с оптимизацией скомпилированы или нет? В скорость, или

в размер? Посчитаем сколько потерь при каждом их использовании в каждом софте?

Итог: надо писать свою операционную систему с максимальной оптимизацией.

В размер, или в скорость?

(С) Вилли

Оптимизация и про то, и про то.

в упоротость апи :)

Нет, оптимизация это что-то одно из этого.

По моему к скорости и размер важен, но как хочешь. Скорость.

Есть у нас inc - на одном процессоре есть баг с ним, который вызывает зависимость и соответствующую задержку. Он 1 байт. Есть add и lea, первый - лучше inc, без багов, но он уже 2 байта. Третий ещё круче - он не трогает флаги, но он уже 3 байта. Что выберешь?

add чтобы контролить переполнения

-march=native 😁

1. Смотря какой процессор, мне на него может быть без разницы. 2. Я бы add выбрал, хотя нужно по скорости посмотреть.

inc - выберу для инкремента всегда, даже если где то с ним баг.

add медленнее lea.

тогда inc.

inc медленнее add и lea. Самый медленный вариант, и имеет баг на некотором процессоре.

add dword[counter], 1 adc dword[counter + 4]

Окей, выбираю lea.

Это будет максимальная оптимизация по скорости. А как же размер? Целых 2 байта можно сэкономить (если их будет много в проекте - счёт может достигать 100 байт).

для длиных целых согласен перенос разряда важнее.

и получаем переполнение что выводит систему из состояния стабильности

Какое переполнение... Нормально всё будет.

Окей, выбираю пойти спать.

ну вот как пример, в одной ос есть TID - thread id который вроде как раз через inc инкрементируется. и что произойдёт с системой при переполнении никто не знает

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

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

А что мешает сделать проверку на переполнение потока (достижение 0xFFFFFFFF), и освобождение каких-то других потоков аварийно? В конце концов, можно расширить число потоков до 64-х бит (длинная арифметика).

ничего, кроме того что кол-во потоков тут вообще не роляет никак и проверка убьёт скорость запуска потока в ноль

Значит только одно - "переписывайте". И перед тем, как писать - блок-схему составить, как это будет работать.

Окей, у меня есть решение. not + neg.

У neg есть проблема, он ломается на середине диапазона

Не понял

Ну он у тебя как минимум поднимет carry flag при инкременте значения максимального положительного