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

N>Мне вот стало тут интересно
N>1) Какая принципиальная разница между загрузкой константы из литерала команды и из сегмента данных, кроме лишнего косвенного доступа по регистру и возможной задержки на чтении памяти?
N>Или тебе они настолько принципиальны?

Не готов спорить насчёт "принципиальности", но в реальных приложениях разница есть, когда используют регистры xmm даже не для векторных вычислений:

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

V>> Именно поэтому векторные операции и заруливают обычную арифметику с плавающей точкой, что за один раз можно указать адреса нескольких операндов (вектора их), бгг...
N>Это действительно основная причина? )

Да.
Поэтому и разница получается не "принципиальная", что-то около 15%.
(если аналогично потом выгружать в память из файла регистров результаты, как если бы происходили вычисления традиционным способом)

Плюс лишние операции со стековой машинкой вычислений с плавающей точкой — в отличие от нее mmx-регистры можно адресовать непосредственно.
ИМХО, тут больше рулит сам факт расширения файла регистров.

Ну и, совсем неординарная фишка — если используются инструкции вокруг mmx, то они замедляют традиционные вычисления.
Связано это с тем, что логически первые 8 64-битных mmx-регистров объединены со стековыми регистрами традиционной арифметики с плавающей точкой (вернее, с мантиссойй этих 80-тиразрядных регистров). Т.е., после работы с mmx-регистрами содержимое стека ST/BCD необходио рассматривать как невалидное, т.е., грубо, некоторые операции по подгрузке данных порой необхоимо "начинать сначала", как-то так.


V>>Фишка в том, что и обычная и векторная арифметика используют одни и те же аппаратные блоки ядер, т.е. унутре проца всё происходит с одинаковой скоростью, т.е. выигрыш сугубо "архитектурный" получается, а не волшебный-аппаратный. Поэтому, если векторные регистры используются не для векторных операций (а там есть и не векторные, ими можно как обычным файлом регистров распоряжаться), то быстродействие получается такое же. А чуть лучше оно получается в не-векторных операциях от того, что векторные регистры рассматриваются как дополнительный файл регистров, т.е. трафик общения проца и кеша 0-го уровня может быть заметно ужат.
N>Только гиморно это — как адрес не применить, сложение-вычитание целых не сделать, и вообще...

Целочисленные логические и арифметические операции над MMX-регистрами и векторами в памяти есть:
https://docs.oracle.com/cd/E18752_01/html/817-5477/eojdc.html#:~:text=The%20MMX%20instructions%20enable%20x86,or%20in%20general%2Dpurpose%20registers.

И там же есть операции загрузки-сохранения, именно поэтому С++ активно использует mmx-регистры даже при компиляции std::copy/std::move.
Т.е., однократное указание адреса для "большого" участка памяти за один раз — оно даёт профит.
(опять же ХЗ, насколько "принципиальный" и гдевообще эта "принципиальность" начинается)

S>>>Автоматическая векторизация при этом позволяет отказаться от статического порождения кода под все варианты целевых платформ.

V>>Это если под x86.
V>>Ты ведь курсе, например, что в природе нет активных поддерживаемых x86-х сборок Линукс?
V>>Они все давно переползли на x86_x64,

N>У тебя какая-то инопланетная природа.
N>Debian, например, продолжает вести 32-битные образы.

У нас дохрена Linux-юзверов, из DEB-мира у них только разные версии Убунты, смотрим:
https://releases.ubuntu.com/20.04.1/

Берём прошлый релиз:
http://old-releases.ubuntu.com/releases/18.04.1/

Последний релиз для x86 выходил в 2015-м году, т.е. 5 лет назад, в версии 16.04.

Для RHEL/CentOS это случилось еще раньше:

Since version 7, CentOS officially supports only the x86-64 architecture

это 2014-й.



N>Если постараться, ещё десяток можно поискать.

Если постараться, можно найти сотни Linux-сборок. ))
Но я говорил, как оно сейчас в мейнстриме.

Сейчас даже x86-х планшетов больше не выпускают, последние они были выпущены еще аж под Windows 8.1 (т.е. в 2016-м), сейчас планшеты идут с 64-битной версией Windows 10.
Узнать разницу просто — на планшеты до 4 гиг оперативы ставили преимущественно 32-разрядные винды, с 4 гигов ставят 64-разрядную.


N>[skip остальное, тут надо плотно сесть на вашу траву, чтобы понять смысл дискуссии]

Собсно, о чём и речь.
Синклер когда-то спровоцировал своим слогом посмотреть внимательней его эксперименты — не впечатлило:
— простейший мой хелпер показал аналогичные результаты в плане быстродействия;
— решение Синклера падало с исключением на большом классе алгоритмов.

В общем, реклама не соответствовала товару, поэтому сейчас и подавно смотреть облом, бо слог тот же, смотрю. ))
Несерьёзный какой-то подход...

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

N>Мне вот стало тут интересно
N>1) Какая принципиальная разница между загрузкой константы из литерала команды и из сегмента данных, кроме лишнего косвенного доступа по регистру и возможной задержки на чтении памяти?
N>Или тебе они настолько принципиальны?

Не готов спорить насчёт "принципиальности", но в реальных приложениях разница есть, когда используют регистры xmm даже не для векторных вычислений:

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

V>> Именно поэтому векторные операции и заруливают обычную арифметику с плавающей точкой, что за один раз можно указать адреса нескольких операндов (вектора их), бгг...
N>Это действительно основная причина? )

Да.
Поэтому и разница получается не "принципиальная", что-то около 15%.
(если аналогично потом выгружать в память из файла регистров результаты, как если бы происходили вычисления традиционным способом)

Плюс лишние операции со стековой машинкой вычислений с плавающей точкой — в отличие от нее mmx-регистры можно адресовать непосредственно.
ИМХО, тут больше рулит сам факт расширения файла регистров.

Ну и, совсем неординарная фишка — если используются инструкции вокруг mmx, то они замедляют традиционные вычисления.
Связано это с тем, что логически первые 8 64-битных mmx-регистров объединены со стековыми регистрами традиционной арифметики с плавающей точкой (вернее, с мантиссойй этих 80-тиразрядных регистров). Т.е., после работы с mmx-регистрами содержимое стека ST/BCD необходио рассматривать как невалидное, т.е., грубо, некоторые операции по подгрузке данных порой необхоимо "начинать сначала", как-то так.


V>>Фишка в том, что и обычная и векторная арифметика используют одни и те же аппаратные блоки ядер, т.е. унутре проца всё происходит с одинаковой скоростью, т.е. выигрыш сугубо "архитектурный" получается, а не волшебный-аппаратный. Поэтому, если векторные регистры используются не для векторных операций (а там есть и не векторные, ими можно как обычным файлом регистров распоряжаться), то быстродействие получается такое же. А чуть лучше оно получается в не-векторных операциях от того, что векторные регистры рассматриваются как дополнительный файл регистров, т.е. трафик общения проца и кеша 0-го уровня может быть заметно ужат.
N>Только гиморно это — как адрес не применить, сложение-вычитание целых не сделать, и вообще...

Целочисленные логические и арифметические операции над MMX-регистрами и векторами в памяти есть:
https://docs.oracle.com/cd/E18752_01/html/817-5477/eojdc.html#:~:text=The%20MMX%20instructions%20enable%20x86,or%20in%20general%2Dpurpose%20registers.

И там же есть операции загрузки-сохранения, именно поэтому С++ активно использует mmx-регистры даже при компиляции std::copy/std::move.
Т.е., однократное указание адреса для "большого" участка памяти за один раз — оно даёт профит.
(опять же ХЗ, насколько "принципиальный" и где вообще эта "принципиальность" начинается)


V>>Ты ведь курсе, например, что в природе нет активных поддерживаемых x86-х сборок Линукс?
V>>Они все давно переползли на x86_x64,
N>У тебя какая-то инопланетная природа.
N>Debian, например, продолжает вести 32-битные образы.

У нас дохрена Linux-юзверов, из DEB-мира у них только разные версии Убунты, смотрим:
https://releases.ubuntu.com/20.04.1/

Берём прошлый релиз:
http://old-releases.ubuntu.com/releases/18.04.1/

Последний релиз для x86 выходил в 2015-м году, т.е. 5 лет назад, в версии 16.04.

Для RHEL/CentOS это случилось еще раньше:

Since version 7, CentOS officially supports only the x86-64 architecture

это 2014-й.



N>Если постараться, ещё десяток можно поискать.

Если постараться, можно найти сотни Linux-сборок. ))
Но я говорил, как оно сейчас в мейнстриме.

Сейчас даже x86-х планшетов больше не выпускают, последние они были выпущены еще аж под Windows 8.1 (т.е. в 2016-м), сейчас планшеты идут с 64-битной версией Windows 10.
Узнать разницу просто — на планшеты до 4 гиг оперативы ставили преимущественно 32-разрядные винды, с 4 гигов ставят 64-разрядную.


N>[skip остальное, тут надо плотно сесть на вашу траву, чтобы понять смысл дискуссии]

Собсно, о чём и речь.
Синклер когда-то спровоцировал своим слогом посмотреть внимательней его эксперименты — не впечатлило:
— простейший мой хелпер показал аналогичные результаты в плане быстродействия;
— решение Синклера падало с исключением на большом классе алгоритмов.

В общем, реклама не соответствовала товару, поэтому сейчас и подавно смотреть облом, бо слог тот же, смотрю. ))
Несерьёзный какой-то подход...