@Левиафам

Ребят привет! Спросить хочу. Все охают и ахауют как здорово иметь 64 разрядную архитектуру процессора. Мне как-то преподаватель говорил, мол есть команды, которые поступают на дешифратор и обрабатываются процессором. Допустим в слове 32 бита содержатся команды и поступают в дешифратор на обработку, но в 64 битное слово можно уместить больше команд и следовательно быстрее будет обрабатываться программа. Когда я решил попрогать 8-разрядный микроконтроллер в описании было сказано что команда для выполнения дешифратором содержит 14 бит. Из них 6 бит на саму команду (например movlw) и 8 бит на значение которое нужно записать в регистр "w", следовательно это вызвало негодование у меня и походу я глупая обезьяна которая в трех соснах потерялась. Если разрядность определяется значением то почему 64 разрядная архитектура будет быстрее 32-ух?

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

0

@VTsaregorodtsev

32 либо 64 разряда будут занимать только адреса данных, если они в команде присутствуют.
Также в 64разрядной Интел-совместимой системе команд у ряда команд будет "префикс", указывающий, например, на новые/64разрядные регистры (rax и т.д.).
А остальные команды как были - так и остались. Вот кодировалась, например, команда ААА опкодом 37h начиная с 16разрядного 8086-процессора - и продолжает так же кодироваться и для 64разрядного режима.
Т.е. "длина" (в байтах) абсолютно любой команды автоматически не возрастает в 2 раза при переходе от 32 к 64.

Скорость в интел-совместимой 64разрядке может быть выше потому, что
1) добавились новые регистры - теперь отдельные алгоритмы могут получить пользу от большего числа регистров (если, например, внутри цикла меняется-корректируется десяток переменных - то теперь их можно запихать в регистры, а раньше приходилось держать в памяти и постоянно загружать-выгружать)
2) для операций с плавающей точкой скалярные SSE-команды стали работать быстрее старых х87-команд, т.е. дизайн процессора направлен на убыстрение работы новых команд вместо старых (тем более, что старые х87-команды и невозможно использовать в 64разрядном режиме).

2

@Левиафам

VTsaregorodtsev, а что можно почитать про это (есть ли какие книги)? Чтобы досконально разобраться в процессорах и его командах на примерах ассемблера?

0

@VTsaregorodtsev

Левиафам, я на английском читаю свободно, поэтому за русскими текстами не слежу. А на английском - стандартное:

у Интела взять Intel® 64 and IA-32 Architectures Software Developer’s Manual - там перечень всех команд для интел-совместимых процессоров, в т.ч. с описанием их двоичного кодирования.
Также Intel® 64 and IA-32 Architectures Software Developer’s Manual (несколько лет назад был разделён на 2 части - на Basic Architecture и на System Programming Guide, как он оформлен сейчас - не знаю, не обновлял его себе), и Intel® 64 and IA-32 Architectures Optimization Reference Manual. Там по рецептам разработки программ.

Если понравится - то у Агнера Фога на agner.org есть как руководства по оптимизации программ на С++ и ассемблере - так и справочник по растактовкам (временам выполнения в тактах процессора, временам декодирования в тактах дешифратора) процессорных команд для кучи семейств интел-совместимых процессоров начиная с Пентиума (т.е. за 20 лет). Т.е. это тоже не по архитектуре - а по программированию упор будет (чтобы, например, если пишем на ассемблере и некоторый кусок расчётов можно реализовать разными способами = с помощью разных команд - то можно было выбрать самый шустрый вариант реализации исходя именно из информации о числе тактов на каждую команду).

По архитектуре же процессора - не знаю, что посоветовать специально (что-то вводное в указанных справочниках будет, а именно по архитектуре - не знаю), а лезть на Интел проверять - лень


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

Добавлено через 9 минут
Чуть ошибся, а время правки сообщения истекло. Поэтому будет дописыванием:
Первый упомянутый Intel® 64 and IA-32 Architectures Software Developer’s Manual имелся в виду в виде справочника Instruction Set Reference.

2

@castaway

VTsaregorodtsev, а как же сама разрядность регистров? Если на 32-битной архитектуре приходилось эмулировать операции с целыми 64-битными значениями, то теперь это ни к чему.

0

@VTsaregorodtsev

castaway, Ну, осталось только посчитать число задач, где 64разрядные целые нужны и активно используются - и сравнить их с числом иных задач/алгоритмов.

Ну или другой вариант: почему-то вычислительные математики не подняли вой от того, что на 64разрядке им стал недоступен long double (10 байт), существовавший ещё со времён 8087-сопроцессора. Так что, видимо, тут 1-1 счёт - кому-то стало лучше, кому-то стало хуже.

0

@castaway

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

Добавлено через 4 часа 32 минуты
Старые - это какие? fsin - это старая команда?
Если вы имеете в виду все команды x87, то это не так.

0

@Jin X

Добавлю, что кроме inc регистр / dec регистр – для 32-битных регистров (они стали 2 байта вместо 1).

Я ещё добавлю пункт:
3) потому что за раз можно передавать/обрабатывать сразу 64 бита (как при работе с большими числами – включая арифметические операции сложения/вычитания, а там более умножение/деление, так и при копировании данных... хотя в 32 битах копирование можно организовать с помощью MMX/SSE).


Видимо, комментарий VTsaregorodtsev связан с тем, что на ЯВУ в x64 вместо FPU используется SSE (в Delphi точно, про MSVCPP не скажу, но думаю, тоже), которые работают с 8-байтовыми (64-битными) данными вместо 10-байтных (80-битных).



Добавлено через 17 минут
p.s. Я не спец в SSE или AVX, но подозреваю, что вероятно даже есть возможность работать с 128-битными (16-байтными) Floating Point-числами. Но не факт, конечно. Напишите, кто в курсе этой темы, интересно даже

0

@Kukuxumushu

Со 128-битными он работают. А в новых процессорах (самому опробовать не привелось) ещё и с 256-битными. Переделывал логарифм под SSE через 32-мегабайтную таблицу поиска - ускорение по сравнению с FPU (а там это 1 инструкция) примерно в 50 раз.

0

@Jin X

Регистры SSE 128-битные, но в них хранится обычно 2 числа по 64 бита. И в ЯВУ как раз идёт использование SSE для 64-битных чисел. Про единые 128-битные числа как раз у меня вопрос (написанный в p.s.).

А это уже AVX.

0

@Kukuxumushu

Там и 4 по 32 прекрасно хранятся.

Добавлено через 3 минуты
Нет таких чисел. Для них даже формат не разработан. Либо 4 сингла, либо 2 дабла, либо в скалярном режиме 1 сингл.

1

@Jin X

Странно, что сингл...

0

@Ol44

Скорее это расширение AMD64, которое Intel использует.
Делал как-то в SSE сравнение сразу по 16 байт командой и в больших циклах это гуд.
Что-то много получилось.

0

@Kukuxumushu

Да я сам в шоке. 4-кратная векторизация*распараллеливание на 2 ядра*HyperThreading дают примерно 10-12-кратный рост производительности. Остальное - это собственно скорость SSE+оптимизация алгоритма, в котором кстати всё равно осталось узкое место - за раз из таблицы 4 значения не выберешь, и даже все РОНы одной командой из XMM не загрузишь (хотя могли бы в Intel такую инструкцию предусмотреть).

0

@castaway

Не знаю что и с чем у него там связано, но сказано было одно, а по факту это не так. Плюс ко всему ещё и я видите ли не в тему ответил. Терпеть не могу таких "эрудитов".

2

@VTsaregorodtsev

Интересно, как меряли? Ведь не кэшируется же такая таблица целиком - т.е. к времени исполнения команды должно плюсоваться время на доступ к памяти. Может, Вы меряли скорость доступа к одной единственной ячейке, а не к произвольным и далеко отстоящим?
Но согласен - долго на FPU исполняется команда вычисления логарифма.

0

@Kukuxumushu

Мне в практической задаче надо было последовательно около 100 тысяч логарифмов посчитать в виде 100 выровненных по параграфу массивов по 1000 синглов, вот по ним целиком и мерил rdtsc от старта до финиша.

0

@Ethereal

И как много случаев, когда 32 бит будет мало, а 64 как раз достаточно ? Я таких не знаю.
Как правило, или 32 бит за глаза хватает, или и 64 маловато будет (несимметричная криптография, где осуществляется арифметика с целыми числами в 512, 1024, 2048 разрядов, к примеру).

Забавно, но есть алгоритмы где 64 разряда наоборот снизят быстродействие. Это симметричные криптоалгоритмы, где данные частенько шифруются блоками по 64 бит, а поскольку цепь Фейстеля, то текущая порция данных для обработки 32 бита. Для реализаций этих криптоалгоритмов типичны сдвиги и вращения этих 32 бит, а в нашем криптоалгоритме ГОСТ так прямо и стоит вращение 32 бит 11 раз. И теперь после каждого сдвига придется добавлять дополнительный and, чтобы биты, которые раньше на халяву терялись, убирать, а вращение так вообще неудобно становится делать. Удивительно, но 64 бита при реализации ходовых симметричных криптоалго начинают мешать, а 32 были как раз.

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

0

@Jin X

Как уже выше оговаривалось, для этого зачастую юзают MMX...

0

@Ethereal

А то я этого не знаю. Разговор же шел про разрядность саму по себе. Добавлено через 8 минут
З.Ы. Мне когда-то приходилось под Alpha AXP программы писать. А это чисто 64-разрядная архитектура, причем первая в мире такая. И вот там вот прочувствовал, что ничего от этого не быстрее, кроме пересылок больших массивов данных и длинной целочисленной арифметики (в несимметричной криптографии), для которой хоть и 64 разряда все равно мало, но сложение вычитание и умножение требует меньшего количества дроблений длинных чисел на порции.

0