LINUX.ORG.RU

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

Исправление Stanson, (текущая версия) :

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

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

А причём тут атомы?

Попытка сделать маложрущий дешёвый CISC за счёт частоты в том числе.

Что за обычные задачи? Специализированные инструкции могут использоваться не так редко, например SIMD в strlen() в glibc и тд.

Поэтому, например, в ARM рассчитанные на strlen добавили Neon. А там где strlen не особо актуален, Neon’а нету, зато кристалл меньше и дешевле, и ужор меньше.

Кстати, SIMD вообще-то далеко не всегда даёт ощутимый прирост в скорости. Потому что тут уже имеет значение и скорость общения процессора с RAM.

Не знаю, за производительные процессоры отваливают любые бабки.

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

Исправление Stanson, :

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

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

А причём тут атомы?

Попытка сделать маложрущий дешёвый CISC за счёт частоты в том числе.

Что за обычные задачи? Специализированные инструкции могут использоваться не так редко, например SIMD в strlen() в glibc и тд.

Поэтому, например, в ARM рассчитанные на strlen добавили Neon. А там где strlen не особо актуален, Neon’а нету, зато кристалл меньше и дешевле, и ужор меньше.

Кстати, SIMD вообще-то далеко не всегда даёт ощутимый прирост в скорости. Потому что тут уже имеет значение и скорость общения процессора с RAM.

Не знаю, за производительные процессоры отваливают любые бабки.

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

Исходная версия Stanson, :

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

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

А причём тут атомы?

Попытка сделать маложрущий дешёвый CISC за счёт частоты в том числе.

Что за обычные задачи? Специализированные инструкции могут использоваться не так редко, например SIMD в strlen() в glibc и тд.

Поэтому, например, в ARM рассчитанные на strlen добавили Neon. А там где strlen не особо актуален, Neon’а нету, зато кристалл меньше и дешевле, и ужор меньше.

Кстати, SIMD вообще-то далеко не всегда даёт ощутимый прирост в скорости. Потому что тут уже имеет значение и скорость общения процессора с RAM.

Не знаю, за производительные процессоры отваливают любые бабки.

Вот только рынок менее производительных процессоров на порядки больше.