Автоматический подсчет ссылок

Приложения, которые предназначаются для OS X v10.7 и позже должны использовать в своих интересах автоматический подсчет ссылок (ARC). Эта технология освобождает Вас от необходимости вручную сохранить и выпустить объекты, и таким образом, часто исправляет скрытые ошибки в приложениях.

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

Версия операционной системы

До OS X v10.6, все приложения, поставившие с операционной системой, были 32-разрядными приложениями. Начинаясь в v10.6, приложения, поставляющие с операционной системой, являются обычно 64-разрядными приложениями.

Это означает, что в v10.5 и предыдущий, первое стороннее 64-разрядное приложение, которое запускает пользователь, заставляет весь 64-разрядный штабель платформы быть загруженным в память, приводя к потере производительности запуска и значительной памяти наверху.

Точно так же в v10.6 и позже, первое не способное приложение на 64 бита платит производительность и штраф объема потребляемой памяти, потому что OS X должен ввести весь 32-разрядный штабель платформы. Таким образом при основном предназначении для OS X v10.6 и позже необходимо быть 64-разрядными если вообще возможный.

Драйверы Набора I/O и Другие Расширения ядра

Поскольку 64-разрядное ядро не может загрузить 32-разрядные расширения ядра, обязательно, чтобы все расширения ядра были скомпилированы 64-разрядные. При начале в OS X v10.6, некоторые аппаратные конфигурации используют 64-разрядное ядро по умолчанию, и начале в OS X v10.8, все конфигурации поддерживаемого оборудования используют 64-разрядное ядро исключительно. Это означает, что, если Ваше расширение ядра не является 64-разрядным, оно не будет функционировать в OS X v10.8 и позже.

Важные приложения производительности

Даже в более старых версиях OS X, если Ваше приложение является критически важной производительностью, Вы могли бы хотеть перекомпилировать свое приложение как 64-разрядную исполнимую программу, особенно на основанных на Intel компьютерах Macintosh.

Вот то, почему. 64-разрядная архитектура Intel содержит дополнительные регистры CPU, которые не доступны при компиляции 32-разрядной исполнимой программы Intel. Например, 64-разрядная архитектура имеет 16 целочисленных регистров общего назначения вместо 8. Из-за дополнительного пространства регистра первые несколько параметров передаются в регистрах вместо на штабеле. Таким образом, путем компиляции некоторых приложений как 64-разрядных, можно улучшить производительность, потому что код генерирует меньше доступов памяти на вызовах функции. Как правило 64-разрядные исполнимые программы Intel работают несколько более быстро, если увеличенный размер кода и размер данных не взаимодействуют плохо (мудрые производительностью) с кэшем CPU.

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

Вот некоторые потенциальные ловушки производительности:

• Больший размер кода и размер данных могут привести к увеличенному кэшу и буферу быстрого преобразования адреса (TLB) промахи.

• Больший код и данные (оба указателя и long целые числа), может потребовать, чтобы больше памяти избежало разбивки на страницы.

• Умножьтесь и разделитесь, операции медленнее, когда выполняется на 64-разрядных количествах, чем 32-разрядные количества. Другие операции занимают примерно то же количество времени как свои 32-разрядные дубликаты. Таким образом, если Ваш код часто умножает значения типа long, Вы будете видеть влияние производительности. (Реверс является истиной для типа long long потому что 64-разрядные приложения не должны разбивать 64-разрядные операции в многократные 32-разрядные операции.)

• Когда Вы используете 32-разрядное целое число со знаком в качестве индекса массива, если то число не будет сохранено в регистре, то CPU проведет дополнительное время на каждом доступе к знаку - расширяют значение.

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

«Огромные» объекты данных

Если Вашему приложению, возможно, понадобится произвольный доступ к исключительно большому (> 2 ГБ) наборы данных, проще поддерживать эти наборы данных в 64-разрядной среде. Можно поддерживать большие наборы данных в 32-разрядном приложении с помощью отображения памяти, но выполнение так требует дополнительного кода. Таким образом, для новых приложений, необходимо тщательно оценить, требуется ли поддержка таких больших наборов данных в 32-разрядной версии приложения.

64-разрядная математическая производительность

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

Сменная совместимость

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

В OS X v10.7 и позже, все приложения Apple, поставляющие как часть OS, 64-разрядные исполнимые программы. Это означает, что пользователи со способными компьютерами на 64 бита будут выполнять 64-разрядную часть ключевых системных компонентов. И начавшись в OS X v10.8 и позже, встроенные приложения составляют обычно 64 бита только. Это означает, что любые плагины (экранные заставки, расширения диалогового окна принтера, и т.д.), который должен загрузиться в этих приложениях, должны быть перекомпилированы как 64-разрядные плагины.

Как специальное исключение, приложение Установок системы обеспечивает 32-разрядный режим нейтрализации. Если пользователь выбирает область установок системы без 64-разрядной части, это повторно запускает себя как 32-разрядная исполнимая программа (после отображения диалогового окна). Для максимизации опыта пользователей, однако, необходимо все еще перейти эти предпочтительные области к 64-разрядным плагинам как можно скорее.

Требования к памяти

64-разрядное приложение может использовать значительно больше памяти, чем 32-разрядное приложение. Поэтому заманчиво продолжать поставлять 32-разрядные приложения. Однако это обычно - не правильное решение.

В OS X v10.6 и позже, большинство встроенных приложений является 64-разрядным. В первый раз, когда Вы запускаете 32-разрядное приложение, все 32-разрядные части платформы должны быть загружены в память. Это означает, что, загружаясь более старый, 32 биты только приложения вызывают значительное давление памяти, особенно на компьютерах с ограниченным RAM. Это часто перевешивает дополнительное влияние памяти, вызванное большими структурами данных.

Это беспокойство описано более подробно в Оптимизации Производительности, вместе с некоторыми подсказками для улучшения Вашего использования памяти в 64-разрядной среде.