64-битные приложения и встроенная сборка - PullRequest
24 голосов
/ 29 мая 2011

Я использую Visual C ++ 2010 для разработки 32-битных приложений Windows. Есть кое-что, что я действительно хочу использовать для встроенной сборки. Но я только что понял, что Visual C ++ не поддерживает встроенную сборку в 64-битных приложениях. Так что в будущем портирование на 64bit будет большой проблемой.

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

Мое приложение должно взаимодействовать с другими компонентами ОС, например, драйверы, которые я знаю, должны быть 64-битными в 64-битных окнах. Будет ли мое 32-битное приложение совместимо с ними?

Ответы [ 4 ]

16 голосов
/ 29 мая 2011

Visual C ++ не поддерживает встроенную сборку для процессоров x64 (или ARM) , потому что обычно использование встроенной сборки - плохая идея.

  1. Обычно компиляторы производят лучшую сборку, чем люди.
  2. Даже если вы можете создать лучшую сборку, чем компилятор, использование встроенной сборки обычно побеждает оптимизаторы кода любого типа. Несомненно, ваш код, оптимизированный для рук, может быть быстрее, но тот факт, что код вокруг него не может быть оптимизирован, обычно приводит к более медленной программе в целом.
  3. Встроенные функции компилятора доступны практически во всех основных компиляторах, которые позволяют получить доступ к расширенным функциям ЦП (например, SSE) способом, который совместим с языками C и C ++, и не побеждает оптимизатор.

Мне интересно, будет ли шанс, что 32-битные приложения ВСЕ должны будут быть обновлены до 64-битных в будущем.

Это зависит от вашей целевой аудитории. Если вы ориентируетесь на серверы, то да, разумно разрешить пользователям не устанавливать подсистему WOW64, потому что это сервер - вы знаете, что он, вероятно, не будет выполнять слишком много 32-битного кода. Я полагаю, что Windows Server 2008 R2 уже допускает это в качестве опции, если вы устанавливаете его как экземпляр «ядра сервера».

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

64 бит не имеет ничего общего с регистрами. Это связано с размером адресуемой виртуальной памяти.

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

Скорее всего. 32-разрядные приложения ограничены в том, что они не могут отображать в память вещи размером более ~ 2 ГБ одновременно. 64-битные приложения не имеют этой проблемы. Даже если они не используют более 4 ГБ физической памяти, возможность адресации более 4 ГБ виртуальной памяти полезна для отображения файлов на диске в память и тому подобное.

Мое приложение должно взаимодействовать с другими компонентами ОС, например, драйверы, которые я знаю, должны быть 64-битными в 64-битных окнах. Будет ли мое 32-битное приложение совместимо с ними?

Это полностью зависит от того, как вы общаетесь с этими драйверами. Если это что-то вроде «именованного файлового интерфейса», тогда ваше приложение может оставаться 32-битным. Если вы попытаетесь сделать что-то вроде общей памяти («Да! Общая память доступна из пользовательского режима с помощью драйвера?!?»), Вам придется создать приложение как 64-битное.

13 голосов
/ 29 мая 2011

Помимо формы @ Отличная статья Билли: если вы действительно чувствуете необходимость использовать встроенную 64-битную сборку, то вы можете использовать внешний ассемблер, такой как MASM, чтобы сделать это, посмотрите это . (также возможно ускорить это с помощью скриптов предварительной сборки).

6 голосов
/ 18 января 2015

Intel C Compiler 15 также имеет встроенную возможность в 64-битной версии.И вы можете интегрировать IC в Visual Studio как набор инструментов: тогда у вас будет 64-битный VC ++ со встроенной сборкой.Один улов - хотя, дорогие ура

0 голосов
/ 26 апреля 2019

Пока у нас в MinGW также есть 64-битный встроенный язык ассемблера; и это довольно быстро и бесплатно. Раньше на какой-то математике это было медленно; поэтому я бы начал сравнивать характеристики MSVC и MinGW, чтобы определить, является ли это достойной отправной точкой для вашего приложения.

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

  1. На самом деле, люди очень часто делают сборку кода, которая выполняется более эффективно, чем компиляторы - или, по крайней мере, это всегда было обычной мудростью, когда я изучал программирование в 70-х и 80-х годах и продолжал работать до 2000 года.
  2. В зависимости от времени, проведенного в циклах и количества кода; рукописная процедура сборки может настолько ускорить процедуру, что потеря производительности при оптимизации может быть относительно небольшой; или нет - как в случае преобразования всей функции в сборку.

Сборка может иметь место в коде, который требует высокой оптимизации, независимо от того, что говорит M $. Вы действительно не будете знать, будет ли сборка ускорять код, пока не попробуете. Все остальное только понтификаты.

Я предпочитаю подход, заключающийся в компиляции кода на языке С ++ в сборку, а затем в оптимизации вручную. Это избавляет вас от необходимости писать большую часть этого; и, немного поэкспериментировав, вы сможете использовать лучшие оптимизации компилятора; а затем начать улучшать это. FWIW, мне никогда не нужно было с современной программой. Часто другие вещи могут ускорить это так же или больше - например, такие как многопоточность. Тем не менее, для приложений, критичных к производительности, я не вижу причин, чтобы не пытаться; и просто используйте его, если он работает. M $ просто ленится.

...