Пользователь
0,0
рейтинг
17 октября 2013 в 06:36

Разработка → ARM64 и Ты перевод

Несколько запоздалый перевод заинтересовавшего меня блогпоста о том, что в действительности дает 64-битность процессора в iPhone без маркетинговой шелухи. Если текст покажется вам слишком очевидным, пропустите часть «Базовые преимущества и недостатки».

Как только был анонсирован iPhone 5S, технические медия были переполнены недостоверными статьями. К сожалению, написание хороших статей занимает время, а мир технической журналистики больше ценит скорость, чем достоверность. Сегодня, по просьбе нескольких своих читателей, я кратко изложу, что дает 64-bit ARM в iPhone 5S в плане производительности, возможностей и разработки.

64 бита


Давайте для начала рассмотрим что, собственно, 64-битность означает. С этим термином связанно много путаницы, в основном из-за того, что нет единого устоявшегося определения. Однако, существует общее понимание этого термина. «Битность» обычно означает либо размер числового регистра, или размер указателя. К счастью, для большинства современных процессоров, их размер совпадает. Таким образом, 64-битность означает что процессор обладает 64-битными числовыми регистрами и 64-битными указателями.

Важно также отметить, что 64-битность не означает, т.к. и здесь есть много недопонимания. Итак, 64-битность не определяет:

  1. Размер адресуемой памяти. Количество бит, реально задействованных в указателе не связано с битностью процессора. Процессоры ARM использует от 26 до 40 бит, и это число может изменяться в отрыве от битности процессора.
  2. Ширину шины данных. Объем данных, запрашиваемых из RAM или кэша также не связано с битностью. Отдельные процессорные инструкции могут запрашивать произвольные объемы данных, но объем реально единовременно запрашиваемых данных может отличаться, либо разбивая запросы на части, или запрашивая больше чем необходимо. Уже в iPhone 5 размер запрашиваемого блока данных составляет 64 бита, а у PC доходит до 192 бит.
  3. Все что связано с вычислениями с плавающей запятой. Регистры FPU не связаны с архитектурой и процессоры ARM использовали 64-битные регистры задолго до ARM64.


Базовые преимущества и недостатки


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

Не смотря на то, что 64-битность не связана напрямую с объемом адресуемой памяти, она значительно облегчает использование большого объема RAM в рамках одной программы. Программа, запущенная на 32-битном процессоре может адресовать не больше 4GB адресного пространства. Часть памяти выделена под операционную систему и стандартные библиотеки, что оставляет 1-3GB на саму программу. Если у 32-битной системы больше 4GB RAM, то использование всего этого адресного пространства для программы значительно усложняется. Вам придется заняться махинациями вроде последовательного отображение разных частей RAM на часть виртуального адресного пространства или разбивание одной программы на несколько процессов.

Подобные трюки крайне трудозатраны и могут сильно замедлить систему, так что мало кто из программистов реально их использует. На практике, на 32-битных процессорах каждая программа используют до 1-3GB RAM, а вся ценность в обладании большего объема физической оперативной памяти заключается в возможности больше запускать программ одновременно и возможность кеширования больше данных с диска.

Увеличение объема адресного пространства полезно и для систем с небольшим объемом оперативной памяти — memory-mapped файлы, размеры которых могут быть  и больше доступной оперативной памяти, т.к. операционная система реально загружает только те части файла, к которым производились обращения и, кроме того, умеет «вытеснять» загруженные данные обратно в файл, освобождая оперативную память. На 32-битных системах нельзя отобразить файлы размером больше 1-3GB. На 64-битных системах, адресное пространство значительно больше, так что такой проблемы нет.

Увеличение размера указателя может быть и ощутимым минусом: таже программа будет использовать больше памяти (возможно, сильно больше) будучи запущенной на 64 битном процессоре. Увеличение используемой памяти также «забивает» кэш, что снижает производительность.

В двух словах: 64-битность может увеличить производительность некоторых частей кода и упрощает некоторые техники, вроде memory-mapped файлов. Однако, производительность может и пострадать из-за увеличения используемой памяти.

ARM64


64-битный процессор в iPhone 5S не просто ARM с увеличенным размером регистров, есть и существенные изменения.

Во-первых, отмечу название: официального название от ARM — «AArch64», однако это — глупое название, печатать которое меня раздражает. Apple называет архитектуру ARM64 и я буду называть также.

ARM64 увеличил вдвое число целочисленных регистров. 32-битный ARM предоставляет 16 целочисленных регистров, из которых один — счетчик команд (program counter), еще два используются для указателя на стэк и регистра связи (link register) и 13 регистров общего назначения. В ARM64 32 целочисленных регистра, с выделенным нулевым регистром, регистром связи и регистром указателя кадра (frame pointer register). Еще один регистр зарезервирован платформой, что оставляет 28 регистров общего назначения.

ARM64 также увеличивает число регистров для чисел с плавающей запятой. Регистры в 32-битных ARM несколько странные, так что сложно сравнивать. У 32-битного ARM 32 32-битных регистров с плавающей запятой, которые могут быть представлены как 16 перекрывающихся 64-битных регистров. Кроме того, есть еще 16 независимых 64-битных регистров. ARM64 упрощает это до 32 неперекрывающихся 128-битных регистров, которые могут быть использован для данных меньшего размера.

Число регистров может значительно влиять на производительность. Память значительно медленнее процессора, и чтение/запись памяти занимает значительно больше времени, чем выполнение инструкций процессора. Процессор пытается исправить это при помощи кэшей, но даже самый быстрый кэш значительно медленнее регистров процессора. Больше регистров — больше данных могут храниться внутри процессора. Насколько это влияет на производительность зависит от конкретного кода и эффективности компилятора, который оптимизирует использование регистров. Когда архитектура Intel перешла от 32 к 64 битам, число регистров увеличилось с 8 до 16, и это было значительное изменение производительности. У ARM уже было больше регистров чем у 32-битной архитектуры Intel, так что увеличение регистров хоть  и меньше повлияет на производительность, но это изменение все еще будет заметно.

ARM64 также привнес существенные изменения помимо увеличения числа регистров.

Большинство 32-битных инструкций ARM могут выполняться/не выполняться в зависимости от состояние регистра-условия. Это позволяет транслировать условные выражения (if-statements) без использования ветвления. Предполагалось, что это увеличит  производительность, однако, судя по тому, что в ARM64 от этой возможности отказались, она порождала больше проблем, чем давала пользы.

В ARM64 набор SIMD (одна-инструкция-много-данных) NEON полностью поддерживает стандарт IEEE754 для чисел с плавающей запятой с двойной точностью, в то время как 32-битная версия NEON поддерживала только одинарную точность и не в точности следовала стандарту для некоторых битов.

В ARM64 добавили специализированные инструкции для AES шифрования и SHA-1 & SHA-256 хешей. Не слишком полезное в общем, однако существенный бонус если вы занимаетесь именно этими вопросами.

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

Совместимость с 32-битным приложениями


Важно отметить, что A7 включает в себя 32-битный режим совместимости, который позволяет запускать 32-битные приложения без каких либо изменений. Это означает, что iPhone 5S может исполнять любые старые приложения без какого-то влияния на производительность.

Изменения в системе периода исполнения


Apple использует преимущества новой архитектуры в своих библиотеках. Так как им нет надобности беспокоиться о бинарной обратной совместимости при таких изменениях, это отличное время чтобы внести изменения которые в противном случае «поломали» уже существующие приложения.

В Max OS X 10.7 Apple ввела меченные указатели (tagged pointers). Меченные указатели позволяют хранить некоторые классы с небольшим количеством данных в экземпляре напрямую в указателе. Это позволяет избежать выделений памяти в некоторых случаях, например NSNumber и может дать существенный прирост производительности. Меченные указатели поддерживаются только на 64-битной платформе, частично из-за вопроса производительности, а частично из-за того что в 32-битном указателе не так много остается места под «метки». Видимо по-этому, у iOS не было поддержки меченных указателей. Таким образом, в ARM64 в рантайме Objective-C включена поддержка меченных указателей, что дает те же преимущества, что в Mac.

Не смотря на то, что размер указателя составляет 64 бита, не все эти биты на самом деле используются. В Mac OS X на x86-64 используется только 47 битов. В iOS на ARM64 используется еще меньше — только 33 бита. Если маскировать эти биты каждый раз перед использованием то можно использовать остальные биты чтобы хранить дополнительные данные. Это позволило внести одно из самых значительных изменений в рантайм Objective-C за всю его историю.

Переосмысление указателя isa


Большая часть информации в этой секции почерпана из статьи Грега Паркера. Во первых, для освежения памяти: объекты в Objective-C представляют выделенные блоки памяти. Первый часть, размером с указатель, это isa. Обычно, isa это указатель на класс объекта. Чтобы узнать больше о том, как объекты хранятся  в памяти, читайте мою другую статью.

Использовать весь размер указателя на указатель isa несколько расточительно, особенно на 64-битной платформе, которая не использует все 64-бита. ARM64 на iOS реально использует 33 бита, оставляя 31 бит для других вещей. Классы в памяти выровнены по границе 8 байт, так что последние 3 бита можно отбросить, что дает 34 бита из isa доступные для хранения дополнительной информации. И Apple-овский рантайм в ARM64 использует это для повышения производительности.

Наверно, самой важной оптимизацией стало встраивание (inline) счетчика ссылок. Практически все объекты в Objective-C обладают счетчиком ссылок (за исключение неизменяемых объектов, таких как литералы NSString) и операции retain/release, которые меняют этот счетчик случаются очень часто. Это особенно критично для ARC, который вставляет вызовы retain/release чаще, чем бы это делал программист. Таким образом, высокая производительность retain/release методов крайне важна.

Обычно, счетчик ссылок не хранится в самом объекте. Можно было бы хранить счетчик ссылок в самом объекте, но это заняло бы слишком много места. Это не так важно сейчас, но тогда, давно, это было весьма существенно. Из-за этого, счетчик ссылок хранится во внешней хеш-таблице. Каждый раз при вызове retain, производятся следующие действия:
  1. Получить глобальную хеш-таблицу счетчиков указателей
  2. Заблокировать хеш-таблицу, чтобы операция была потокобезопасной
  3. Найти в хеш-таблице счетчик для заданного объекта
  4. Увеличить счетчик на один и сохранить его обратно в таблицу
  5. Отпустить блокировку хеш-таблицы

Достаточно медленно! Реализация хеш-таблицы счетчиков сделана очень эффективной, для хеш-таблицы, но это все еще значительно медленнее прямого доступа к памяти. В ARM64, 19 бит указателя isa используются для хранения счетчика ссылок. Это означает, что вызов retain упрощается до:
  1. Произвести атомарное увеличение части isa-поля

И все! Это должно быть гораздо, гораздо быстрее.

На самом деле все несколько сложнее из-за разных краевых случаев, которые тоже надо обработать. По-настоящему последовательность действий приблизительно такая:
  1. Последний бит в isa говорит, используются ли дополнительные биты в isa для хранения счетчика ссылок. Если нет, используется старый алгоритм с хеш-таблицами.
  2. Если объект уже удаляется, ничего не выполняется
  3. Если счетчик переполняется (что случается редко, но вполне возможно при 19 битах), используется старый алгоритм с хеш-таблицей
  4. Произвести атомарное изменение isa на новое значение

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

Использование оставшихся неиспользованных под счётчик ссылок биты в isa позволило ускорить деаллокацию объектов. Теоретически, нужно совершить кучу действий когда объект в Objective-C удаляется и возможность пропустить ненужные может значительно увеличить производительность.  Эти шаги:
  1. Если у объекта не было ассоциированных объектов, установленных используя objc_setAssociatedObject, их не надо удалять.
  2. Если объект не обладает C++-деструктором (который вызывается при dealloc), его тоже не нужно вызывать.
  3. Если на объект ни разу не ссылались слабым (__weak) указателем, то эти указатели не надо обнулять.

Раньше, все эти флаги хранились в классах. Например, если хоть один экземпляр класса когда-либо хранил ассоциированные объект, то все экземпляры этого класса удаляли ассоциированные объект при деаллокации. Отслеживание этих флагов для каждого экземпляра в отдельности позволило вызывать соответствующие методы только для тех экземпляров, для которых это действительно было нужно.

Суммарно, это существенный выигрыш. Мои бенчмарки показали, что создание и удаление простого объекта  занимает 380нс на 5S в  32-битном режиме, в то время как в 64-битном только 200нс. Если хоть один экземпляр когда-либо имел слабую ссылку на себя, то в 32-битном режим время удаления для всех увеличивалось до 480нс, в то время как в 64-битном режиме время осталось в районе 200нс для всех экземпляров, на которых слабых ссылок не было.

Короче говоря, улучшения в рантайме таковы, что в 64-битном режиме время аллокации занимают 40-50% от времени аллокации в 32-битном режиме. Если ваше приложение создает и удаляет много объектов, это может оказаться существенным.

Заключение


64-битность A7 не просто маркетинговая уловка, но это и не поражающий воображение прорыв который позволит создавать новый класс приложений. Истина, как всегда, лежит посередине.

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

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

Apple использовала переход на новую архитектуру для улучшения в рантайме. Основное изменение — встраиваемый (inlined) счетчик ссылок, который позволяет избежать дорогого поиска по хеш-таблице. Так операции retain/release очень часты в Objective-C, это существенный выигрыш. Удаление ресурсов в зависимости от флагов делает удаление объектов почти вдвое быстрее. Меченные (tagged) указатели также добавляют производительность и уменьшают потребление памяти.

ARM64 — приятное добавление от Apple. Мы все знали, что это рано или поздно случится, но мало кто ожидал что так скоро. Но оно есть, и это отлично.
Перевод: Mike Ash
Даниил @meta4
карма
39,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (86)

  • –20
    Программа, запущенная на 32-битном процессоре может адресовать не больше 4GB адресного пространства.

    Мне кажется, что всё не совсем так. Пример — один процесс на Windows x86 может адресовать максимум что-то около 2Gb.
    • +8
      При чем тут Windows x86?
      2^32=4294967296 = 4G адресуемых байт. Больше адрес неоткуда взять, переполнение только и всего.
      • +1
        Каюсь, я просто не дочитал абзац — автор дополнил первое предложение тем, что часть адресного пространства выделена на ядро системы и не может быть отдана программе. Если считать ОС одной программой — то да, она может адресовать все 4Gb.
        • +4
          Ну, есть быть точным занудой, то это тоже не совсем так, т.к. адресное пространство отжирают еще устройства и начальный загрузчик (BIOS или UEFI)
          • +1
            Хм, а эти устройства попадают в виртуальную память? Мне казалось, что они только «физические» адреса отжирают.
    • 0
      Вы не правы. Ардесуемая память (память для которой можно выделить адреса) ограничена размером инта. Есть режими работы процессоров вроде pae, которые могут использовать не 32 а 36 бит, и тогда можно адресовать уже 64 гига памяти.
      • +3
        PAE — это адресация физической памяти. Насколько мне известно, виртуально (в пределах одного процесса) адресовать по-прежнему можно только 4GB. Зато можно запустить больше таких процессов, которые суммарно будут использовать больше 4GB без необходимости свопиться.
    • +3
      Всё зависит от ОС, если ОС захочет и позволит контроллер памяти, то можно адресовать заметно больше, чем 2 в степени битности процессора. Опять же битность процессора и ширина шины адреса не связаны друг с другом.

      Взять допотопные ZX-Spectrum'ы, 8 битный процессор, а есть модели с 128Кб памяти, а есть и 2Мб памяти. Тут уже от контроллера памяти всё зависит, а не процессора.
      • 0
        У Z80 адресная шина 16 бит, поэтому изначально они 64K были. Увеличить-то можно, конечно, составляя адрес за несколько приемов.
    • +3
      C x86 есть такой прикол — у него организация памяти сегментно-страничная. Это означает, что к указателю сначала прибавляется значение из сегментного регистра, а потом получившийся адрес отображается на ту или иную страницу памяти. Так как разные сегментные регистры могут хранить разный «базовый адрес», всего можно адресовать до 4x4 Гб в 32 битном режиме.
      • +1
        Если можно управлять отображением адресов на память, то, по идее, размер адресуемой памяти вообще не ограничен (хотя переключение страниц может оказаться довольно медленным).
      • +1
        Почему 4x4 Гб? Сегментных регистров у нас ведь шесть, а не 4…
        • +1
          Один регистр (FS или GS) обычно уже используется для того, чтобы организовать thread local storage.
          • +2
            Это-то тут вообще причём? Вы же тут явно какую-то гипотетическую OS с неплоским адресным пространством обсуждаете, а не существующую операционку — кто сказал, что там TLS тоже нужно через FS или GS делать???
            • +1
              Ок.
  • +2
    Со счетчиком ссылок что-то для меня совсем непонятное.
    Обычно, счетчик ссылок не хранится в самом объекте. Можно было бы хранить счетчик ссылок в самом объекте, но это заняло бы слишком много места. Это не так важно сейчас, но тогда, давно, это было весьма существенно.

    Как может быть такое, что в объекте он занимает много места, а в хеш-таблице — нет, при том что счетчик все равно хранится в памяти, и количество счетчиков по идее должно совпадать с количеством объектов?
    Ну и с использованием isa для счетчика для счетчика ИМХО намудрили в том же духе. В результате, когда через несколько лет 33 бит для isa станет мало, придется придумывать еще третий механизм, и сохранять совместимость с двумя существующими.
    • 0
      > а в хеш-таблице — нет, при том что счетчик все равно хранится в памяти, и количество счетчиков по идее должно совпадать с количеством объектов?
      Сам был несколько удивлен. На данный момент единственную причину что нарыл — далеко не все объекты увеличивают счетчик больше 1, а в хеш-таблицу добавляются только объекты со счетчиком больше единицы.

      >33 бит для isa станет мало
      4 Гигабайта на метаинформацию о классах не будет хватать? Думаю очччень нескоро.
      • 0
        4 Гигабайта на метаинформацию о классах не будет хватать? Думаю очччень нескоро.

        Дело не в этом, а в том, что придется обеспечивать, чтобы все структуры с информацией о классах хранились в одной непрерывной области памяти, не превышающей 4 гигабайта. То есть правильнее рассматривать isa не как указатель (который формально может указывать куда угодно), а как смещение в некотором глобальном массиве.
        Я на самом деле не имею практического опыта с ObjC, и поэтому могу ошибаться — но сразу возникает вопрос — как быть, если например 4 гига основной программы уже заняты данными, а мы подгружаем динамическую библиотеку, в которой тоже есть метаинформация о классах.
    • 0
      Когда 33 бита станет мало — вернутся к хэш-таблице, вот и все
  • +5
    У вас оговорка по Фрейду:
    AMD64 — приятное добавление от Apple.
  • +3
    Давно ждал такую статейку. Спасибо за труд!
    • +4
      Я не понимаю, какой смысл ее ждать? Просто каждую пятницу нужно заходить на mikeash.com/pyblog/ и читать.
  • +5
    Есть другая, не менее важная причина в переходе на ARM64 сейчас. И это черта эпла: долговременная поддержка своей продукции. Через год или два, или раньше, другие платформы перейдут на 64-битную архитектуру. И, «ох, надо же», все флагманы вдруг превратятся в картошку и перестанут получать апдейты, ибо несовместимость. Самсунг и оные настригут такое кол-во бобла, ух!
    А пользователи эпл, не смотря на выход уже 6S к тому времени, тупо нажмут Update и получат современный софт.
    p.s. честно говоря, мне стыдно, что я не замечал очевидного раньше, покупая раз в год смартфон, вместо раза в два года.
    • –3
      Что за ересь?
      Вам же в статье даже написали, что архитектура бинарно совместима с предыдущими.
      К процессору апдейты/их отсутствие никакого отношения иметь не будут.
      • +8
        Если я правильно понял, в статье говорится, что этот проц может запускать 32-битные приложения. Я же говорил о другом.
        Допустим вы купите топовый смарт на андроиде, который еще будет на 32-битном проце. Через месяц выходит андроид 5 64-бит и он уже не встанет на ваше железо, если, конечно, гугл не станет поставлять его для обеих архитектур. Дальше проще: тому же самсунгу даже сейчас невыгодно поставлять апдейты на свое железо, иначе они бы давно дали сорцы дров на свои эксиносы, чтобы народ мог самостоятельно на свой страх и риск заняться портом. Ну, а потом у них появится нереальная клевая отмаза, мол несовместимы.
        Правда в том, что большая часть топовых производителей смартов на андроиде не парятся на счет поддержки железа предыдущего поколения — им выгоднее продать новое. Все шутят, что «каждый год ваш айфон превращается в нереально унылое гавно» и просто отказываются замечать, что топы анроидов — это, по сути, одноразовое железо.

        Новый iOS7 ставится даже на iphone 4 — т.е. это 5, 4s, 4 — три предыдущих поколений смартфонов! Эй, ребята с Galaxy S2, как там ваша тыква, получила 4.3?
        • +1
          эээ прошу прощения, похоже брежу я :)
        • +1
          Да даже не S2, а просто Galaxy S современником четвёртого iPhone был, который официально даже 4.0 не получил.
        • –7
          Пф, зачем про обновления задвигать? iOS догонит Android 4.0 ICS, которому уже года два, в функциональности только, может, к iOS 9. А мы, тем временем, будем на CyanogenMod 11. =)
    • 0
      Вы сделали очень правильные выводы: производителям железа выгоднее продавать новые железки, производителям платформы выгоднее продавать платформу, а производителям софта выгоднее продавать софт :)
      Примеры:
      — Windows предыдущей версии не получает многих улучшений, потому что иначе не купят более новую версию, однако при этом работает на максимально возможном количестве устройств, и при этом старательно блюдётся обратная совместимость.
      — Android (Nexus) поддерживается так же как и продукты Apple (как мобильные, так и десктоп), ибо все три примера являются законченной платформой (железо + ОС), при этом что Apple, что Google забивают на поддержку платформ, которые они считают устаревшими (зачастую софт от компаний не поддерживает платформы, объявленные устаревшими).
      — Android от производителей железок не поддерживается никак, или почти никак, ибо не купят новые железки.

      p.s: у меня Galaxy Nexus, который до сих пор поддерживается. Кстати с Nexus ситуация интереснее, ибо есть, вполне обоснованные, предположения, что после завершения официальной поддержки от Google, в следствии открытых исходников, устройство будет поддерживаться командой CyanogenMod.
      • 0
        Эпл ведь не продает iOS7 (или продает?) на старые смарты?
        Нвидия ведь не продает драйвера к новой ОС?

        Если бы Самсунг продавал только железо, на него можно было бы накатить тот же цьян. Я сам подписывал петицию отдать сообществу дрова для эксиноса, чтобы мы могли и дальше пользоваться все еще новыми смартами. Зачем-то производители берут андроид, выворачивают кишки наружу, получают такое htcdroid/andsung и потом «опля» несовместимость. Т.е. получается они производят и железо, и софт, прям как эпл.

        Всем знакомым я рекомендую нексусы. Но когда я брал свой S3, некусус было просто не достать.

        • 0
          Вообще странно, агу, действительно получается, что Samsung, HTC, и другие производят платформу, и им просто плевать на своих пользователей.
          Всем знакомым я рекомендую нексусы.

          аналогично.
  • +1
    На сколько мне видится, аппаратная криптография (вроде AES, SHA-1 и SHA-256) позволит в дальнейшем получать бОльшую производительность на всяких одноплатниках, используемых в качестве NAS и узлов скрытосетей (тут как раз ещё одно царство ARM архитектуры для энтузиастов).
    • +1
      Вообще, мне нравится тенденция аппаратного AES. И VPN работает со скоростью сети, и файлы шифруются куда быстрее. Хотелось бы, чтобы там закладок не было, конечно…
      • 0
        О каких закладках идет речь? Насколько я понимаю, AES — детерминированный алгоритм, если шифровать как-то неправильно, другая сторона просто не расшифрует данные.
        • +2
          Ну, например, хитрый подход к процессу генерации ключей. Диапазон ключей соответствует некоторой системе, известной автору закладки. Сильно снижается криптостойкость при внешнем соответствии стандартам.
          • +2
            Генерацию ключей ещё никто не додумался ускорять аппаратно. Есть аппаратные генераторы случайных чисел, да, и с ними много воросов, но к ускорению AES'а это прямого отношения не имеет.
          • 0
            При желании, «железный» генератор случайных чисел можно вообще не использовать. Это две отдельные независимые фичи, ГСЧ и AES.
    • 0
      Вообще во всех современных процах это добавлял вендор отдельным блоком периферии, сейчас это скорее просто внесло стандартизацию. Никаких функциональных изменений не произошло.
  • +3
    Программа, запущенная на 32-битном процессоре может адресовать не больше 4GB адресного пространства.


    Стоп! А выше тем временем сказано:

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


    Для интеловской архитектуры — бесспорно; и ограничения в 1-3гига на каждую программу x86 давно известны. Но тут же речь уже про ARM, не?
    • 0
      >Стоп! А выше тем временем сказано:

      Я упростил ограничение сверху теоретическим, потому что оно не имеет принципиального значения для memory-mapped файлов. И 4 гигабайта легко превысеить, например, фильмами в HD,
  • +2
    >> что 64-битность не означает: Ширину шины данных. Объем данных, запрашиваемых из RAM или кэша также не связано с битностью. Отдельные процессорные инструкции могут запрашивать произвольные объемы данных, но объем реально единовременно запрашиваемых данных может отличаться, либо разбивая запросы на части, или запрашивая больше чем необходимо. Уже в iPhone 5 размер запрашиваемого блока данных составляет 64 бита, а у PC доходит до 192 бит.

    Друзья, вы меня извините, но битность всю жизнь именно означала ширину шины данных. Упомянутый процессор Z80 имел 8-разрядную шину данных (там физически было 8 выводов — извините, я их видел своими глазами). При этом у процессора были 16-ти разрядные регистры которые как раз предназначались для адресации также упомянутых 16-битов (т.е. 64 Кб) адресного пространства. И наличие этих регистров никак не делает Z80, равно как и Intel 8080 16-ти разрядными процессорами.

    Битность — это тот объём информации, который процессор может передавать или получать за один машинный такт. Подразумевается в первую очередь работа с памятью, а не портами, т.к. для портов существует отдельное адресное пространство — что у Z80, что у семейства x86. Битности прямо пропорционально быстродействие системы, построенной на данном процессоре, именно поэтому данный параметр является очень важным. Косвенное доказательство важности — то, что маркетологи издавна манипулируют этими понятиями, возьмите хотя бы игровые приставки 90-х.
    • 0
      Угу, таких процессоров (где процессор 8-разрядный, но есть 16-разрядные регистры) — немало среди популярных. 6809, к примеру.

      Бывают и ещё более интересные случаи: en.wikipedia.org/wiki/HP_Saturn_%28microprocessor%29
      "… The Saturn microprocessor is a hybrid 64-bit / 20-bit CPU hardware-wise but acts like a 4-bit processor in that it presents nibble-based data to programs and uses a nibble-based addressing system ..."
    • +1
      Битность — это тот объём информации, который процессор может передавать или получать за один машинный такт.

      С появлением кешей всё стало не так однозначно, и то, что процессор с 32-битными регистрами за такт может зачитать со внешней шины 128 бит (что не редкость для AHB), не делает его 128-битным.
      • –1
        За такт? Там на порядок больше времени уйдёт на обращение к ОЗУ.
        • +1
          ОЗУ бывает разное. Но правильнее сказать, конечно, за один цикл шины.
          • 0
            Вот именно :) И этот цикл выполняется гораздо — гораздо дольше. К тому же никакие кеши не помогут при обращении к некоторым данным (volatile С/C++ переменные, если говорить о языках высокого уровня), для которых обязательно обращение к ячейкам конечного ОЗУ, которые оттуда нельзя копировать, и для доступа к которым в итоге шина процессора будет заблокирована на всё время доступа к таким данным.
            • 0
              Вот именно :) И этот цикл выполняется гораздо — гораздо дольше

              Изначально речь шла о битности, в моём исходном комментарии не было ни слова о памяти, а минимальный цикл AHB занимает 2 такта шины. А шина, повторю, может быть и 128 и 1024 битной.
              К тому же никакие кеши не помогут при обращении к некоторым данным (volatile С/C++ переменные, если говорить о языках высокого уровня), для которых обязательно обращение к ячейкам конечного ОЗУ

              Хорошо, вы же ассемблер знаете, можете проинтерпретировать следующий код, с точки зрения «конкретных ячеек ОЗУ, к которым обязательно обращение»?
              volatile int i;
              int f(void)
              {
                      return i;
              }
              

              gcc -S test.c
              cat test.s
              

                      .file   "test.c"
                      .comm   i,4,4
                      .text
                      .globl  f
                      .type   f, @function
              f:
              .LFB0:
                      .cfi_startproc
                      pushq   %rbp
                      .cfi_def_cfa_offset 16
                      .cfi_offset 6, -16
                      movq    %rsp, %rbp
                      .cfi_def_cfa_register 6
                      movl    i(%rip), %eax
                      popq    %rbp
                      .cfi_def_cfa 7, 8
                      ret
                      .cfi_endproc
              .LFE0:
                      .size   f, .-f
                      .ident  "GCC: (GNU) 4.7.2 20121109 (Red Hat 4.7.2-8)"
                      .section        .note.GNU-stack,"",@progbits
              
        • 0
          Для этого и придумали кеш.
    • 0
      Наверное, учитывая концепцию SIMD в ARM, битность уже не прямо влияет на быстродействие системы. Процессор получил данные, и несколько тактов их обрабатывает, не работая с памятью. Поэтому тут важнее, как быстро он их обрабатывает внутри. А здесь уже важны размеры регистров.
    • +1
      При этом у процессора были 16-ти разрядные регистры

      У Z80 нет 16-разрядных регистров. Есть регистровые пары из двух 8-битных регистров.
      И да, у z80 4х-битное ALU, кстати

      Начиная с Pentium шина данных не зависит от разрядности процессора.

      Подразумевается в первую очередь работа с памятью, а не портами

      Откуда вы взяли порты, которых нет на ARM?
      Упомянутые 192-бита обеспечивает трехканальный контроллер памяти у Nehalem+

      • 0
        Начиная с Pentium шина данных не зависит от разрядности процессора.

        Уточню: шина «шире» чем регистры (64 vs 32)
        «Уже» делали все кто хотел сэкономить
  • +4
    Во-первых, отмечу название: официального название от ARM — «AArch64», однако это — глупое название, печатать которое меня раздражает. Apple называет архитектуру ARM64 и я буду называть также.

    Мнение конечного пользователя архитектуры(Apple) конечно же авторитетней чем мнение создателей этой самой архитектуры.
  • 0
    Честно говоря, так и не смог для себя отчистить этот проц от рекламной шелухи, хоть пост и должен был это сделать.

    AArch64 это ARMv8? То есть обычный Cortex A53/57?
    Если нет то что это?(желательно со ссылкой на сайт арм.ком)

    Если это A53/57 — то какой из них, и если оба то поддерживается ли биг-литл?

    Самое главное:
    причем тут вообще эпл?

    В ARM64 набор SIMD (одна-инструкция-много-данных) NEON полностью поддерживает стандарт IEEE754 для чисел с плавающей запятой с двойной точностью, в то время как 32-битная версия NEON поддерживала только одинарную точность и не в точности следовала стандарту для некоторых битов.


    Стоп, NEON это SIMD, FPU это FPU, это разные вещи.
    Во многих ядрах NEON это опция а FPU нет.

    Как минимум в Cortex A5 стоит FPU двойной точности, а это самый дохлый проц из ARMv7.
    • +4
      >AArch64 это ARMv8? То есть обычный Cortex A53/57?

      На сколько я понимаю, это ARMv8 конкретная реализация AArch64. Приблизительно как Core2Duo (не сам проц конечно, а его дизайн) — реализация x86-64.

      >причем тут вообще эпл?

      Рассматривается конкретно A7, а не вообще любой AArch64

      >Во многих ядрах NEON это опция а FPU нет.

      Все это верно, но из текста видно, что автор сравнивает предыдщее поколение процессоров в айфонах и текущее.
      • 0
        > Рассматривается конкретно A7, а не вообще любой AArch64

        ни одного отличия от A53/A57 в статье я не увидел

        > Все это верно, но из текста видно, что автор сравнивает предыдщее поколение процессоров в айфонах и текущее.

        меня насторожило " NEON поддерживала только одинарную точность "
    • +3
      AArch64 это ARMv8?
      Да

      То есть обычный Cortex A53/57?
      Вряд ли.

      У ARM есть 2 варианта лицензирования их разработок — лицензия на ISA (Instruction Architecture Set) т.е. лицензия на набор инструкций ARMv7\ARMv8 или лицензия на готовую микроархитектуру (ядро) разработанное АРМ — А8\А9\А15 и так далее.

      Эпл несколько лет назад купила компанию занимающуюся разработкой арм процессоров. И вот в 5-м айфоне мы увидели результат их работы — свое ядро, Swift. Вряд ли Octane является тупо А53\57, так как ясно, что у эпл другой вектор развития.
      На рынке сейчас, по сути только 2 компании разрабатывающие свои микраорхитектуры на базе ISA от ARM — Apple и Qualcomm. У обоих чипы оставляют конкурентов далеко позади. Нельзя же обойти конкурентов с теми же технологиями, что и у них.

      Во многих ядрах NEON это опция а FPU нет.
      NEON был опцией только в Cortex A9. Привет идиотам из Nvidia с их говно-чипом Tegra 2. Даже в Cortex A8 он был обязательным

      Как минимум в Cortex A5 стоит FPU двойной точности, а это самый дохлый проц из ARMv7.
      И? Вы же сами сказали, что VFP это FPU, а NEON это SIMD…
      • –1
        Можно какие-нибудь пруфы относительно того, что эпл разрабатывает свое ядро?
        Как правило компании просто интегрируют готовое ядро а то, что делает их продукт уникальным это набор периферии, GPU и тд, этим как правило и обходят конкурентов. Вы же не пишете компилятор, чтобы обойти конкурентов :)
        Вообще интересно было бы почитать подробностей по ядру, тк big.LITTLE да, это фишка а тут просто тот же набор инструкций и все? непонятно.

        Ну вот например в Cortex A5 NEON это тоже опция, и это правильно, потому, что SIMD не всегда нужен, или его заменяет нормальный GPU.

        FPU двойной точности это я к тому, что в статье написано, что в ARMv8 это улучшение относительно ARMv7, что неверно
        • +1
          Можно какие-нибудь пруфы относительно того, что эпл разрабатывает свое ядро?
          www.anandtech.com/show/6292/iphone-5-a6-not-a15-custom-core

          а тут просто тот же набор инструкций и все?
          ну так у Core i7 4-го поколения и у какого-нить amd один и тот же набор инструкций — AMD64, SSE, FMA, что-то еще, а производительность ооочень сильно отличается. Микроархитектура решает.

          что SIMD не всегда нужен, или его заменяет нормальный GPU.
          Он нужен не для каждой задачи, но современные девайсы не однозадачные. Потому SIMD нужен в каждом чипе. В мобильниках вам никогда не дадут «нормальный» GPU, который смог бы решать часть задач SIMD. К тому же все современные gpu скалярные.
          • –1
            Спасибо за ссылку, интересно было узнать, правда как-то мало информации «лучше производительность, меньше энергопотребление, от знающих людей узнал, что это не А15», потребление SoCа определяется не только ядром, жалко, что все так скрыто

            в статье не указано ни одного преимущества над стоковыми ARMv8 ядрами, поэтому и возник вопрос.

            2 full hd потока это нормальный GPU?
            SIMD нужен для 2D графики, его очень просто заменить GPU, но возможно я просто не знаю каких-то еще областей его применения, тогда просвятите пожалуйста.
            • 0
              в статье не указано ни одного преимущества над стоковыми ARMv8 ядрами, поэтому и возник вопрос.
              В той статье описывается Apple A6, который в iPhone 5, т.е. ARMv7…

              2 full hd потока это нормальный GPU?
              ???

              SIMD нужен для 2D графики, его очень просто заменить GPU
              Эмм… для какой еще 2д графики? SIMD движок не рисует графику…
          • +1
            Лучше эту ссылку. Тут как раз про A7.
        • 0
          Можно какие-нибудь пруфы относительно того, что эпл разрабатывает свое ядро?

          Конкретно в Apple A7 используется ядро Cyclone.

          Ну вот например в Cortex A5 NEON это тоже опция, и это правильно, потому, что SIMD не всегда нужен, или его заменяет нормальный GPU.

          Не скажите. Google, например, делает серьёзную ставку на SIMD. Та же реализация PNaCl в Chrome требует VFP3 с NEON. Или в том же Android Google свои приложения векторизует с NEON, поэтому, например, тот же свайп в гугловой клавиатуре уже не работает на смартфонах и планшетах с Tegra 2, если ставить кастомные прошивки типа CyanogenMod 10.1/10.2

          На рынке сейчас, по сути только 2 компании разрабатывающие свои микраорхитектуры на базе ISA от ARM — Apple и Qualcomm

          Ещё и NVIDIA с её Project Denver, но это не ранее Tegra 6 будет.
        • 0
          Можно какие-нибудь пруфы относительно того, что эпл разрабатывает свое ядро?

          Можете изучить floorplan
          A15: eda360insider.files.wordpress.com/2010/11/arm-cortex-a15-floorplan.jpg?w=640&h=809
          Apple A6: www.extremetech.com/wp-content/uploads/2012/09/apple-a6-ARM-CPU-cores2-640x353.jpg
    • 0
      AArch64 это ARMv8? То есть обычный Cortex A53/57?

      ARMv8 это архитектура.
      Вы можете создать свой собственный совместимый процессор, скачав ARMv8-A Architecture Reference Manual
      infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0487a/index.html
      Всего 5000 страниц
  • –6
    Apple использовала переход на новую архитектуру для улучшения в рантайме. Основное изменение — встраиваемый (inlined) счетчик ссылок, который позволяет избежать дорогого поиска по хеш-таблице. Так операции retain/release очень часты в Objective-C, это существенный выигрыш. Удаление ресурсов в зависимости от флагов делает удаление объектов почти вдвое быстрее. Меченные (tagged) указатели также добавляют производительность и уменьшают потребление памяти.
    кривой by design рантайм\язык исправляют при помощи хардварной инженерии — перехода на 64 бита. Что угодно сделают, лишь бы не писать на православных С\С++ facepalm.jpg
    • +2
      Отчасти согласен с вами, но не в том, что Apple тут не правы, и не в том, что C, а точнее C++ vs Objective-C однозначно лучше или хуже. Я бы сказал, что C++ в плане управления памятью гораздо более гибкий и низкоуровневый, а соответственно более производительный, чем Objective-C. Однако при этом в Objective-C даже гипотетически не может потечь память, а вот в С++ этого добиться очень даже легко, в С++11 уже почти не возможно, если не использовать сырые указатели, однако из-за отсутствия make_unique, и того факта, что большая часть различных системных апи на платформах это C, то всё ещё можно выстрелить себе в ногу. Если в Objective-C нужна высокая производительность, то никто не мешает делать часть механизмов на голом C, что кстати частенько делают и в C++ для полного исключения лишнего функционала, и получения ещё большей производительности. Кстати говоря счётчик ссылок умных указателей в С++ реализована как дополнительный atomic мембер в классе.

      На всякий случай отмечу, что Objective-C не используется для ядерного кода, к тому же — в ядрах всех операционок есть много мест где не используется даже C, а используется голый ассемблер.

      p.s: я сам не сторонник Objective-C, более того на нём не пишу, да и вообще разработкой под Apple не занимаюсь, пишу как раз таки на C/C++ под Windows и Linux, и занимаюсь так же системным программированием для данных ОС, но всё таки более менее представляю и начинку Objective-C.

      p.p.s: кстати, к вопросу о дизайне, а как вы думаете каким образом реализованы GC в Java, C#, D, и других языках? :)
      • –1
        >Однако при этом в Objective-C даже гипотетически не может потечь память

        Это, безусловно, неверно. Память отлично течет даже в языках с автоматической сборкой мусора, а уж без нее — и подавно. (Нет, в Objective-C нет GC)
        • 0
          В Objective-C нет GC поскольку там вся память выделяется под строгим контролем, и именно для этого контроля там и используются счётчик ссылок.

          Так же мне очень интересны примеры ситуаций, и языков, в которых память течёт при наличии GC для всех выделений в куче. Может я чего то не знаю, я не отрицаю этот факт, но из того, что мне известно я не вижу возможностей утечек при наличии в языке не отключаемого GC, или при таком строгом контроле, который есть в Objective-C.

          При этом я конечно исключаю ситуации в ошибках реализации подсчёта ссылок или GC в целом, ибо это уже совсем другая история.
          • 0
            > там вся память выделяется под строгим контролем

            Что за контроль? Подсчет ссылок работает быстрее, и что самое важное, предасказуемее и без внезапных пауз из-за которых от него и отказались.

            >Так же мне очень интересны примеры ситуаций, и языков, в которых память течёт при наличии GC

            При создании кешей (особенно кастомных, своих) или использовании хеш-таблицы как хранилище «внешних» полей к объекту, например.
            • 0
              А как подсчёт ссылок спасает в случае наличия циклов?
              • 0
                Плохо. Одну из ссылок нужно оформлять слабой, что в принципе особой сложности не составляет, но и забыть тоже можно, особенно используя замыкания.
      • –3
        не может потечь память, а вот в С++ этого добиться очень даже легко
        возможность утечки памяти в С\С++ никогда не была недостатком языка. Защита от утечек на коленке пишется за 5 минут — переопределяем все ф-ции аллокации памяти и храним в мапе\листе\динамическом массиве указатели на все аллоцированные блоки памяти, при освобождении памяти — удаляем. При закрытии приложения проверяем, есть ли не удаленные блоки и выводим об этом сообщение с файлом и строкой аллокации. Это в случае, если под вашу платформу нет тулзов для отлавливания утечек памяти.

        Если в Objective-C нужна высокая производительность, то никто не мешает делать часть механизмов на голом C
        Это не даст желанной производительности. Я еще в пеленках был, когда стоимость доступа к памяти перевалила за стоимость выполнения инструкций. В Objective-C НЕЛЬЗЯ переопределить аллокатор. И если системный аллокатор паршивый, то вам никогда не достичь высокой производительности. Особенно любителям ООП. Этот язык broken by design. Непригоден для написания чего либо стоящего.

        На всякий случай отмечу, что Objective-C не используется для ядерного кода
        Он ни для чего серьезного не используется. Все серьезные вещи пишут на С\асм\С++

        p.p.s: кстати, к вопросу о дизайне, а как вы думаете каким образом реализованы GC в Java, C#, D, и других языках? :)
        Как-то так — javarevisited.blogspot.com/2011/04/garbage-collection-in-java.html
        • 0
          А переопределить + (id)alloc и + (void)dealloc?
          • 0
            переопределить + (id)alloc и + (void)dealloc
            alloc просто создает новый объект.
            • +1
              alloc выделяет память под объект. Инициализирует его уже init.
              Например:
              + (id)alloc
              {
                  Class *newInstance;
                  newInstance = (Class *)calloc(1, class_getInstanceSize(self));
                  *newInstance = self;
                  return (id)newInstance;
              }
              
              • +1
                Реквестую статью на эту тему!

                *newInstance = self;
                self, получается, уже создан? И мы копируем в новый объект?!

                З.Ы. Хочу создать объект на стеке
                • +1
                  *newInstance = self;

                  Так мы выставляем isa объекта.

                  Хорошая статья уже давно написана: www.mikeash.com/pyblog/friday-qa-2010-12-17-custom-object-allocators-in-objective-c.html
                  • 0
                    >Так мы выставляем isa объекта.

                    Только теперь это уже не совсем указатель (что описано в статье), и такой хак скорее всего не пройдет (в 64 битном режиме) — например потому, что там «срезаны» младшие 3 бита указателя. Не говоря о других флагах.
                    • 0
                      Не пройдёт, но можно использовать object_setClass()
        • 0
          По поводу дизайна я спрашивал у Вас именно объяснения процесса работы GC, потому как у меня складывается впечатление, что Вы не понимаете как данный механизм работает, и по этой причине так яростно ругаете счётчик ссылок. В общем я веду к тому, что в GC тоже используется счётчик ссылок для выделенных объектов, просто его не видно, а удаление объектов всегда выполняется фоновым потоком.
  • +1
    >>ARM64 на iOS реально использует 33 бита
    Что даёт адресацию всего 8гб. Учитывая что сейчас у смартфонов уже 2гб, то преодоление предела 8гб будет через 3 поколения, то есть всего через 5 лет. Это значит, что все эти программы, хранящие в указателе информацию, перестанут работать?
    Сделали бы как в MacOS, 47 бит под указатель, 128Tb адресуемой памяти.
    • +2
      Все будет работать. При переполнении inline-счетчика рантайм кладет значение в глобальную таблицу.
  • 0
    > Число регистров может значительно влиять на производительность.
    ARMы не используют переименование регистров?
    • +1
      >ARMы не используют переименование регистров?

      Переименование здесь вообще не причем. Как оно поможет хранить больше данных в регистрах? Что такое fastcall знаете?
  • 0
    Если объект не обладает C++-деструктором (который вызывается при dealloc), его тоже не нужно вызывать.

    Это о чем? С++ деструктор у Objective-C объекта? Или речь про поля объекта?
    • 0
      Я думаю речь об Objective-C++.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.