64-битный int arthimetic на 32-битной x86 (из c)
Есть ли быстрый способ использования 64-битных целых на 32
машины x86 (в компиляторах языка c (добавлено: и c ++))?
32-битные x86 поддерживают 64-битные операции в некоторых
экстент (есть некоторая инструкция movq в старом mmx
и некоторые другие команды, вероятно), но как использовать его из c?
Что делать, если кто-то хочет использовать 64-битную арифметику
в C на 32-битных машинах x86 — как это сделать наиболее
легко и эффективно?
//Редактировать
сделать сейчас я нашел несколько кандидатов на это
uint64_t A;
long long a;
int64 a;
__int64 a;
что следует использовать? есть ли шанс, что некоторые
реализация вышеупомянутого артеметика лучше / быстрее
чем другие?
Решение
Для выполнения 64-битных операций вы можете использовать либо int64_t или же uint64_t,
Они определены в C99 по заголовочному файлу stdint.h,
Другие решения
Есть ли быстрый способ использования 64-битных целых на 32 компьютерах x86 (в
языковые компиляторы)?
int не гарантированно будет иметь ширину 64 бита; Он гарантированно будет иметь ширину не менее 16 бит. Если вы хотите, чтобы тип имел ширину не менее 64 бит, используйте long long вместо. Разговоры об оптимизации на этом уровне совершенно бесплодны. Вам лучше придумать законченное решение, профилировать его, чтобы определить, какая самая медленная часть решения, и нацелить эту часть вашего кода для оптимизации или выбрать другой алгоритм, который выполняет эту медленную операцию быстрее. Примечание. Под решением я имею в виду «программу, которая решает актуальную проблему».
32-битный x86 в некоторой степени поддерживает 64-битные операции (возможно, в старых mmx и некоторых других командах есть какая-то команда movq), но как использовать ее из c?
Независимо от того, выполняет ли ваш компилятор оптимизацию movq и / или mmx, которую вы упомянули автоматически, вы сомневаетесь, так как вы не сказали нам, какой компилятор вы используете. Однако, учитывая простоту такого рода оптимизации по сравнению с другими (например, оптимизация мертвого кода, оптимизация хвостового вызова, даже развертывание цикла), я предполагаю, что ваш компилятор делает это автоматически. Это еще одна причина, по которой разговоры об оптимизации на этом уровне бесплодны; Те, кто пишут компиляторы, обычно являются очень хорошими программистами, хорошо разбирающимися в алгоритмах, которые могут писать автоматы для простого выполнения простых оптимизаций.
Что если кто-то захочет использовать 64-битную арифметику в c на 32-битной x86
машины — как это сделать максимально просто и эффективно?
Вы пытались собрать полностью оптимизированный тестовый сценарий и искать movq операции в его машинном коде? Если я не убедил вас в том, что вы должны профилировать свой код, чтобы определить, стоит ли на самом деле на него ориентироваться, то сделайте следующее: скомпилируйте свое решение (что-то, что решает проблему, помните … и скомпилируйте как «полностью оптимизированное») сравните его, чтобы у вас было что сравнить с оптимизацией, преобразовать машинный код в сборку, выполнить любые ручные оптимизации при сборке, перекомпилировать и снова протестировать. Ты можешь:
- потратьте неделю на оптимизацию и тестирование производительности, чтобы убедиться, что вы сэкономили несколько микросекунд и сдались … Это было бы хорошим свидетельством того, что ваш компилятор тратит несколько секунд на создание кода, который так же хорош, как и код, который вы потратили бы на недели написать. Сохраняйте компилятор, но отказывайтесь от микрооптимизации.
- найдите значительную оптимизацию, которую не выполняет ваш компилятор (довольно маловероятно). Либо выберите более оптимальный компилятор, либо свяжитесь с людьми, которые написали ваш компилятор, и объясните им это …
В любом случае, прогресс!
Насколько мне удалось узнать, в сборке есть несколько развернутых процедур, вставленных здесь на 32-битных системах, поэтому, вероятно, нет способа выполнить ускоренное 64-битное умножение или деление на 32-битных системах (используются программные процедуры) ( Это было бы частичным ответом на это) Но я не уверен на все 100%, поэтому исправьте это, если я ошибаюсь.