(Это продолжение предыдущей темы)

Так не получается. Увеличение ширины регистров в 2 раза далеко не всегда приводит к двукратному увеличению объемов данных, которыеми они оперируют. Т.е. обычно не приводит, потому что в регистр как правило ложится одно целое число или один адрес, и над ним совершается операция. Т.е. обрабатывается один объект, а то, что его размер 32 или 64 байта, ограничевает диапазон допустимых величин, но не объем переваренной информации. Грубо говоря, для операции 2+2 все равно, это int32_t или int64_t, пускай даже и int16_t.
Вы сами можете легко проверить, позапускав какой-нибудь софт типа 7z.

Из практики - 32 и 64 битные версии архиватора RAR - 64 битная работает быстрее 32 битной процентов на 5-10, не более.

Ок, откуда они берут 64-битные данные?

zoog
откуда они берут 64-битные данные?
Отовсюду. Адреса-то 64-битные.

Верно для операций с памятью, но 2+2 обрабатываются за тот же такт. Это как, ну вот есть у вас 400 мл пива, надо перенести их к другу. Можно налить их в поллитровку (х32), а можно в литровую бутылку (х64), но нести вы что одну, что другую, будете ровно одинаковое время. Множество операций вычислительные, а не перекладывательные, и на практике народ нечасто работает с числами больше 4.2 млрд.

anty-x
Отовсюду. Адреса-то 64-битные
Супер. Это из разряда "автомобиль дал нам возможность ездить на заправку, ТО, за запчастями к нему"))
Только лучше)

nenin
далеко не всегда приводит к двукратному увеличению объемов данных, которыеми они оперируют.
это проблема разработчика или оптимизатора его компилятора. но не надо пожалуйста вдаваться в такие дебри: я ни разу не утверждал, что ОС или прикладное ПО в целом должно стать в 2 раза быстрее. если перечитать уже внимательно то, что я писал, то Вы увидите, что я говорил строго о доступности 64 бит регистров даже из 32 бит ПО, что может позволить использующим их инструкциям обрабатывать в 2 раза больше данных за 1 инструкцию. Вы же почему-то упираете на то, что это мол не всегда случается. ясен перец, не всегда!

AzikAtom
Из практики - 32 и 64 битные версии архиватора RAR - 64 битная работает быстрее 32 битной процентов на 5-10, не более.
ещё бы! его просто пересобрали для 64-битной адресации. я всю дорогу пишу про совершенно другое: про возможность даже программам откомпилированным для 32 бит адресации использовать 64 бит регистры при их наличии в процессоре. а вот если бы Рошаль потратил время и оптимизировал на уровне ассемблера, то мог бы быть и гораздо больший прирост. не путайте адресацию с использованием 64 бит регистров и версий комманд процессора. это не одно и то же и не автоматически происходит, а только если компилятор умеет оптимизировать или разраб врезает куски на асме руками, как например в юниксном memset().

Добавление от 14.05.2021 20:16:

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

ради бога!
то я говорил строго о доступности 64 бит регистров даже из 32 бит ПО
А как вин32 приложение вообще может знать о таких регистрах?

ну не имеет ширина регистров никакого отношения к величине чисел! там даже вообще не число может находиться.
Стльное утверждение, можно пример? Я как-то только обратное слышал.

ради бога!
сразу видно, кто когда-либо оптимизировал вручную на ассемблере
там даже вообще не число может находиться.
Это такой sefl-own был, на пару с каминг-аутом?

anty-x
Отовсюду. Адреса-то 64-битные.
Разрядность адреса и данных не связаны напрямую. В 8 битных процессорах данные 8 бит, а адреса 16 битные.

Добавление от 14.05.2021 21:24:

ради бога!
не путайте адресацию с использованием 64 бит регистров и версий комманд процессора
Не путаю. Однако, в нынешних процессорах часто эти разрядности совпадают, что удобно для программ.

Разницу х86 и х64 зачастую не видно даже в математических вычислениях... в обычных программах разница около 0... но при прочих равных х64 требует места в памяти

HaSPoNeD
Разницу х86 и х64 зачастую не видно даже в математических вычислениях... в обычных программах разница около 0
голословное утверждение. в каких конкретно вычислениях? нельзя бросаться просто лозунгами. следует упомянуть хотя бы примерно, какие инструкции использовались и какие из них не давали прироста.
AzikAtom
часто эти разрядности совпадают, что удобно для программ.
чаще всего именно совпадают. речь шла совсем не об этом, а о том, что даже 32 бит адресующая программа на 64 бит процессоре вполне может пользоваться 64 бит регистрами. то, что этим большинство не пожелало воспользоваться - это другая тема, которую мне затрагивать неинтересно потому что очевидно. точно так же большинство "погромистов" как чумы боятся многопоточности. это тоже частный случай: их личное дело. хотя могли бы.
zoog
Стльное утверждение, можно пример? Я как-то только обратное слышал.
открою секрет: лежащие в регистре данные не обязательно представляют собой число. они могут быть... кусочком картинки... звуковым колебанием... становится понятнее? иными словами, многими числами одновременно.
понятное дело, что всё можно считать числом.
например пиксел и его цвета: красный, зелёный, синий, альфа. но это всего 4 байта. в 32 бит регистр помещается 1 пиксель. в 64 бит уже два. становится понятнее? переслать или обработать за 1 комадну 2 пикселя вместо 1 - это не быстрее?
или при обработке строк, записать в регистр сразу 8 байт, а не 4, при смене регистра (не процессорного - uppercase, lowercase), например - это не быстрее?
одним словом: научные вычисления тут не при чём. обработка двойного объёма данных за 1 команду не завязана на вычисления с числами, будь они целыми или с плавающей точкой. это данные. но необязательно числовые.

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

открою секрет: лежащие в регистре данные не обязательно представляют собой число. они могут быть... кусочком картинки... звуковым колебанием... становится понятнее? иными словами, многими числами одновременно.
У картинок 6..8..10 бит на пиксель, у звука - 16 (ок, 32 в ДСП).

переслать или обработать за 1 комадну 2 пикселя вместо 1 - это не быстрее?
Ещё раз: все данные, позволяющие обработку "скопом", уже лет 30 как ускоряются SIMD/векторными инструкциями афаик.

ради бога!
переслать или обработать за 1 комадну 2 пикселя вместо 1 - это не быстрее?
Переслать - да. Но обработать - большой вопрос.
Да и с "переслать" остаётся вопрос - память-то та же самая, и на больших объёмах данных всё будет в неё упираться.

Добавление от 14.05.2021 23:20:

zoog
У картинок 6..8..10 бит на пиксель
6-8-10 бит на компонент, а не на весь пиксель. И это в YUV. А речь была про ARGB, который обычно 32 бит.

AzikAtom
В 8 битных процессорах данные 8 бит, а адреса 16 битные.
Расскажите пожалуйста, как впихать 16-битный адрес в ОДИН 8-битный регистр.

1. Нет такого понятия как 32битная адресация (у многих 32 битных процессоров адреса были 24-битные).
2. Разрядность процессора исторически определяется максимальной разрядностью его регистров.
3. Программы компилируются исходя разрядности регистров процессора.
4. Программы откомпилированые для 32битного процессора не имеют ни малейшего понятия про 64битные регистры.В целом так и должно быть. Современные алгоритмы компресии плохо параллелятся (и многие работают с битовыми потоками) поэтому увеличение разрядности регистров даже теоретически не не может дать значимого прироста скорости.Нет. И Рошаль это знает ибо не дурак.Разрядность адреса никак не связана с разрядностью данных. Возможны любые сочетания.32 битное приложение - никак.На низком уровне любые данные являются упорядоченным набром бит, который, внезапно, может быть представлен числом.
Таким образом данные лежащие в регистре представляют собой число.А процессор об этом знает ? Проблема в том что классические регистры не расчитаны на обработку векторных данных, поэтому что бы обработать "два условных пиксела" в одном регистре потребуются дополнительные битовые команды чтобы нивелировать интерференцию бит. Будет ли это быстрее чем последовательная обработка "двух условных пикселов" - это еще под большим вопросом и сильно зависит от архитектуры процессора (и да и системы в целом).

anty-x
Расскажите пожалуйста, как впихать 16-битный адрес в ОДИН 8-битный регистр.
В один легко - по очереди.

AzikAtom
6-8-10 бит на компонент, а не на весь пиксель.
А Вы 3 компонента за раз сможете обрабатывать?

vertur
2. Разрядность процессора исторически определяется максимальной разрядностью его регистров.
То есть современные интелы - 512-битные?

Читаем документацию по Z80: регистры H и L - регистр базы и регистр смещения.
То же самое и для 16 битных 86: 16-битные регистры базы (сегмента) и смещения дают 20-битный адрес.Ты либо слепой либо не умееш читать - про векторные регистры речь не идет (по факту это набор регистров с общим именем).

zoog
А Вы 3 компонента за раз сможете обрабатывать?
Вроде, для таких вещей есть SSE... Но ещё надо рассовать по регистрам как надо и затем собрать обратно.

vertur
Ты либо слепой либо не умееш читать - про векторные регистры речь не идет (по факту это набор регистров с общим именем).
Вы либо обиделись, либо не умеете формулировать свои мысли.

AzikAtom
Вроде, для таких вещей есть SSE
Вроде да, для всех однотипных/потоковых данных.

Можно, как я уже говорил, это требует дополнительных битовых команд чтобы убрать интерференцию битов.
Вот пример блендинга 4х 5-битовых выборок RGB (для 16-битового R5G6B5, b_i - коэффициенты блендинга, расчитываются отдельно):
Cам блендинг: 4 умножения + 3 сложения (7 команд)
Дополнительные команды: 8 битовых эндов и 4 шифта для приготовления масок + 1 битовый анд, 1 битовый ор и 1 шифт (15 команд)
Итого: 22 команды с использованием одного классического регистра для 3х компонент
и 21 команда в случае раздельной обработки компонент

На RISC архитектурах где команда умножения занимает 1 такт это вариант с обработкой в одном регистре невыгоден (медленее)
На других архитектурах где умножение медленное возможно и есть смысл, но небольшой.Нет. Я предельно точно написал "Разрядность процессора исторически определяется максимальной разрядностью его регистров".
Слово "векторный" отсутсвует, речь идет о классических регистрах.

vertur
Слово "векторный" отсутсвует, речь идет о классических регистрах.
Это и называется формулировкой - в уме держите условия, важные для (не)правильного понимания.

Можно, как я уже говорил, это требует дополнительных битовых команд чтобы убрать интеференцию битов.
В теории, конечно, можно, но это потребует дополнительных телодвижений - иначе давно вместо 8-ядерных процессоров делали бы 256-битные с гарантированным линейным ростом попугаев.

zoog
регистр и векторный регистр - это два общепринятых термина, которые понятны всем, кроме тебя.

ради бога!
я всю дорогу пишу про совершенно другое: про возможность даже программам откомпилированным для 32 бит адресации использовать 64 бит регистры при их наличии в процессоре.

Это аппаратно невозможно. 64-битные регистры доступны только после переключения режима работы CPU в "long mode", так что такая 32-битная программа будет на самом деле 64-битной, хотя и работающей преимущественно с 32-битными вариантами команд и только иногда использующей 64-битные. 32-битная программа в 32-битной ОС в принципе не может использовать что-то 64-битное.

В отличие, между прочим, от аналогичной ситуации с 16/32 битами 16-ти битного реального режима. В нем на 32-битных процессорах доступны любые (ну почти любые, если придираться) 32-битные регистры и команды, только адресация памяти остается 20-ти битной.

Исправлено: man_from_LOR, 15.05.2021 00:39