ARM64 и Ты

[@ICELedyanoj]

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

Мне кажется, что всё не совсем так. Пример — один процесс на Windows x86 может адресовать максимум что-то около 2Gb.

[@mishaspbru]

При чем тут Windows x86?
2^32=4294967296 = 4G адресуемых байт. Больше адрес неоткуда взять, переполнение только и всего.

[@ICELedyanoj]

Каюсь, я просто не дочитал абзац — автор дополнил первое предложение тем, что часть адресного пространства выделена на ядро системы и не может быть отдана программе. Если считать ОС одной программой — то да, она может адресовать все 4Gb.

[@ValdikSS]

Ну, есть быть точным занудой, то это тоже не совсем так, т.к. адресное пространство отжирают еще устройства и начальный загрузчик (BIOS или UEFI)

[@WGH]

Хм, а эти устройства попадают в виртуальную память? Мне казалось, что они только «физические» адреса отжирают.

[@Fesor]

Вы не правы. Ардесуемая память (память для которой можно выделить адреса) ограничена размером инта. Есть режими работы процессоров вроде pae, которые могут использовать не 32 а 36 бит, и тогда можно адресовать уже 64 гига памяти.

[@abusalimov]

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

[@AxisPod]

Всё зависит от ОС, если ОС захочет и позволит контроллер памяти, то можно адресовать заметно больше, чем 2 в степени битности процессора. Опять же битность процессора и ширина шины адреса не связаны друг с другом.

Взять допотопные ZX-Spectrum'ы, 8 битный процессор, а есть модели с 128Кб памяти, а есть и 2Мб памяти. Тут уже от контроллера памяти всё зависит, а не процессора.

[@mishaspbru]

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

[@mejedi]

C x86 есть такой прикол — у него организация памяти сегментно-страничная. Это означает, что к указателю сначала прибавляется значение из сегментного регистра, а потом получившийся адрес отображается на ту или иную страницу памяти. Так как разные сегментные регистры могут хранить разный «базовый адрес», всего можно адресовать до 4x4 Гб в 32 битном режиме.

[@Mrrl]

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

[@khim]

Почему 4x4 Гб? Сегментных регистров у нас ведь шесть, а не 4…

[@mejedi]

Один регистр (FS или GS) обычно уже используется для того, чтобы организовать thread local storage.

[@khim]

Это-то тут вообще причём? Вы же тут явно какую-то гипотетическую OS с неплоским адресным пространством обсуждаете, а не существующую операционку — кто сказал, что там TLS тоже нужно через FS или GS делать???

[@mejedi]

Ок.

[@NeoCode]

Со счетчиком ссылок что-то для меня совсем непонятное.

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

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

[@meta4]

> а в хеш-таблице — нет, при том что счетчик все равно хранится в памяти, и количество счетчиков по идее должно совпадать с количеством объектов?
Сам был несколько удивлен. На данный момент единственную причину что нарыл — далеко не все объекты увеличивают счетчик больше 1, а в хеш-таблицу добавляются только объекты со счетчиком больше единицы.

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

[@NeoCode]

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

Дело не в этом, а в том, что придется обеспечивать, чтобы все структуры с информацией о классах хранились в одной непрерывной области памяти, не превышающей 4 гигабайта. То есть правильнее рассматривать isa не как указатель (который формально может указывать куда угодно), а как смещение в некотором глобальном массиве.
Я на самом деле не имею практического опыта с ObjC, и поэтому могу ошибаться — но сразу возникает вопрос — как быть, если например 4 гига основной программы уже заняты данными, а мы подгружаем динамическую библиотеку, в которой тоже есть метаинформация о классах.

[@corristo]

Когда 33 бита станет мало — вернутся к хэш-таблице, вот и все

[@amdf]

У вас оговорка по Фрейду:

AMD64 — приятное добавление от Apple.

[@PlazmX]

Давно ждал такую статейку. Спасибо за труд!

[@notxcain]

Я не понимаю, какой смысл ее ждать? Просто каждую пятницу нужно заходить на mikeash.com/pyblog/ и читать.

[@magic4x]

Есть другая, не менее важная причина в переходе на ARM64 сейчас. И это черта эпла: долговременная поддержка своей продукции. Через год или два, или раньше, другие платформы перейдут на 64-битную архитектуру. И, «ох, надо же», все флагманы вдруг превратятся в картошку и перестанут получать апдейты, ибо несовместимость. Самсунг и оные настригут такое кол-во бобла, ух!
А пользователи эпл, не смотря на выход уже 6S к тому времени, тупо нажмут Update и получат современный софт.
p.s. честно говоря, мне стыдно, что я не замечал очевидного раньше, покупая раз в год смартфон, вместо раза в два года.

[@uSasha]

Что за ересь?
Вам же в статье даже написали, что архитектура бинарно совместима с предыдущими.
К процессору апдейты/их отсутствие никакого отношения иметь не будут.

[@magic4x]

Если я правильно понял, в статье говорится, что этот проц может запускать 32-битные приложения. Я же говорил о другом.
Допустим вы купите топовый смарт на андроиде, который еще будет на 32-битном проце. Через месяц выходит андроид 5 64-бит и он уже не встанет на ваше железо, если, конечно, гугл не станет поставлять его для обеих архитектур. Дальше проще: тому же самсунгу даже сейчас невыгодно поставлять апдейты на свое железо, иначе они бы давно дали сорцы дров на свои эксиносы, чтобы народ мог самостоятельно на свой страх и риск заняться портом. Ну, а потом у них появится нереальная клевая отмаза, мол несовместимы.
Правда в том, что большая часть топовых производителей смартов на андроиде не парятся на счет поддержки железа предыдущего поколения — им выгоднее продать новое. Все шутят, что «каждый год ваш айфон превращается в нереально унылое гавно» и просто отказываются замечать, что топы анроидов — это, по сути, одноразовое железо.

Новый iOS7 ставится даже на iphone 4 — т.е. это 5, 4s, 4 — три предыдущих поколений смартфонов! Эй, ребята с Galaxy S2, как там ваша тыква, получила 4.3?

[@uSasha]

эээ прошу прощения, похоже брежу я :)

[@pestrov]

Да даже не S2, а просто Galaxy S современником четвёртого iPhone был, который официально даже 4.0 не получил.

[@Mairon]

Пф, зачем про обновления задвигать? iOS догонит Android 4.0 ICS, которому уже года два, в функциональности только, может, к iOS 9. А мы, тем временем, будем на CyanogenMod 11. =)

[@ElleSolomina]

Вы сделали очень правильные выводы: производителям железа выгоднее продавать новые железки, производителям платформы выгоднее продавать платформу, а производителям софта выгоднее продавать софт :)
Примеры:
— Windows предыдущей версии не получает многих улучшений, потому что иначе не купят более новую версию, однако при этом работает на максимально возможном количестве устройств, и при этом старательно блюдётся обратная совместимость.
— Android (Nexus) поддерживается так же как и продукты Apple (как мобильные, так и десктоп), ибо все три примера являются законченной платформой (железо + ОС), при этом что Apple, что Google забивают на поддержку платформ, которые они считают устаревшими (зачастую софт от компаний не поддерживает платформы, объявленные устаревшими).
— Android от производителей железок не поддерживается никак, или почти никак, ибо не купят новые железки.

p.s: у меня Galaxy Nexus, который до сих пор поддерживается. Кстати с Nexus ситуация интереснее, ибо есть, вполне обоснованные, предположения, что после завершения официальной поддержки от Google, в следствии открытых исходников, устройство будет поддерживаться командой CyanogenMod.

[@magic4x]

Эпл ведь не продает iOS7 (или продает?) на старые смарты?
Нвидия ведь не продает драйвера к новой ОС?

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

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

[@ElleSolomina]

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

Всем знакомым я рекомендую нексусы.

аналогично.

[@DZhon]

На сколько мне видится, аппаратная криптография (вроде AES, SHA-1 и SHA-256) позволит в дальнейшем получать бОльшую производительность на всяких одноплатниках, используемых в качестве NAS и узлов скрытосетей (тут как раз ещё одно царство ARM архитектуры для энтузиастов).

[@ValdikSS]

Вообще, мне нравится тенденция аппаратного AES. И VPN работает со скоростью сети, и файлы шифруются куда быстрее. Хотелось бы, чтобы там закладок не было, конечно…

[@mejedi]

О каких закладках идет речь? Насколько я понимаю, AES — детерминированный алгоритм, если шифровать как-то неправильно, другая сторона просто не расшифрует данные.

[@ICELedyanoj]

Ну, например, хитрый подход к процессу генерации ключей. Диапазон ключей соответствует некоторой системе, известной автору закладки. Сильно снижается криптостойкость при внешнем соответствии стандартам.

[@khim]

Генерацию ключей ещё никто не додумался ускорять аппаратно. Есть аппаратные генераторы случайных чисел, да, и с ними много воросов, но к ускорению AES'а это прямого отношения не имеет.

[@mejedi]

При желании, «железный» генератор случайных чисел можно вообще не использовать. Это две отдельные независимые фичи, ГСЧ и AES.

[@uSasha]

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

[@klirichek]

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

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

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

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

[@meta4]

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

Я упростил ограничение сверху теоретическим, потому что оно не имеет принципиального значения для memory-mapped файлов. И 4 гигабайта легко превысеить, например, фильмами в HD,

[@elgordo]

>> что 64-битность не означает: Ширину шины данных. Объем данных, запрашиваемых из RAM или кэша также не связано с битностью. Отдельные процессорные инструкции могут запрашивать произвольные объемы данных, но объем реально единовременно запрашиваемых данных может отличаться, либо разбивая запросы на части, или запрашивая больше чем необходимо. Уже в iPhone 5 размер запрашиваемого блока данных составляет 64 бита, а у PC доходит до 192 бит.

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

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

[@frog]

Угу, таких процессоров (где процессор 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 ..."

[@jcmvbkbc]

Битность — это тот объём информации, который процессор может передавать или получать за один машинный такт.

С появлением кешей всё стало не так однозначно, и то, что процессор с 32-битными регистрами за такт может зачитать со внешней шины 128 бит (что не редкость для AHB), не делает его 128-битным.

[@agmt]

За такт? Там на порядок больше времени уйдёт на обращение к ОЗУ.

[@jcmvbkbc]

ОЗУ бывает разное. Но правильнее сказать, конечно, за один цикл шины.

[@ElleSolomina]

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

[@jcmvbkbc]

Вот именно :) И этот цикл выполняется гораздо — гораздо дольше

Изначально речь шла о битности, в моём исходном комментарии не было ни слова о памяти, а минимальный цикл 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

[@beeruser]

Для этого и придумали кеш.

[@caffeinum]

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

[@beeruser]

При этом у процессора были 16-ти разрядные регистры

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

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

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

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

[@beeruser]

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

Уточню: шина «шире» чем регистры (64 vs 32)
«Уже» делали все кто хотел сэкономить

[@Propheta13]

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

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

[@uSasha]

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

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

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

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

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


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

Как минимум в Cortex A5 стоит FPU двойной точности, а это самый дохлый проц из ARMv7.

[@meta4]

>AArch64 это ARMv8? То есть обычный Cortex A53/57?

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

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

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

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

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

[@uSasha]

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

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

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

меня насторожило " NEON поддерживала только одинарную точность "

[@akaStiX]

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…

[@uSasha]

Можно какие-нибудь пруфы относительно того, что эпл разрабатывает свое ядро?
Как правило компании просто интегрируют готовое ядро а то, что делает их продукт уникальным это набор периферии, GPU и тд, этим как правило и обходят конкурентов. Вы же не пишете компилятор, чтобы обойти конкурентов :)
Вообще интересно было бы почитать подробностей по ядру, тк big.LITTLE да, это фишка а тут просто тот же набор инструкций и все? непонятно.

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

FPU двойной точности это я к тому, что в статье написано, что в ARMv8 это улучшение относительно ARMv7, что неверно

[@akaStiX]

Можно какие-нибудь пруфы относительно того, что эпл разрабатывает свое ядро?
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 скалярные.

[@uSasha]

Спасибо за ссылку, интересно было узнать, правда как-то мало информации «лучше производительность, меньше энергопотребление, от знающих людей узнал, что это не А15», потребление SoCа определяется не только ядром, жалко, что все так скрыто

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

2 full hd потока это нормальный GPU?
SIMD нужен для 2D графики, его очень просто заменить GPU, но возможно я просто не знаю каких-то еще областей его применения, тогда просвятите пожалуйста.

[@akaStiX]

в статье не указано ни одного преимущества над стоковыми ARMv8 ядрами, поэтому и возник вопрос.
В той статье описывается Apple A6, который в iPhone 5, т.е. ARMv7…

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

SIMD нужен для 2D графики, его очень просто заменить GPU
Эмм… для какой еще 2д графики? SIMD движок не рисует графику…

[@akorobko]

Лучше эту ссылку. Тут как раз про A7.

[@Mairon]

Можно какие-нибудь пруфы относительно того, что эпл разрабатывает свое ядро?

Конкретно в 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 будет.

[@beeruser]

Можно какие-нибудь пруфы относительно того, что эпл разрабатывает свое ядро?

Можете изучить 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

[@beeruser]

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 страниц

[@akaStiX]

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

[@ElleSolomina]

Отчасти согласен с вами, но не в том, что 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, и других языках? :)

[@meta4]

>Однако при этом в Objective-C даже гипотетически не может потечь память

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

[@ElleSolomina]

В Objective-C нет GC поскольку там вся память выделяется под строгим контролем, и именно для этого контроля там и используются счётчик ссылок.

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

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

[@meta4]

> там вся память выделяется под строгим контролем

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

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

При создании кешей (особенно кастомных, своих) или использовании хеш-таблицы как хранилище «внешних» полей к объекту, например.

[@Mrrl]

А как подсчёт ссылок спасает в случае наличия циклов?

[@meta4]

Плохо. Одну из ссылок нужно оформлять слабой, что в принципе особой сложности не составляет, но и забыть тоже можно, особенно используя замыкания.

[@akaStiX]

не может потечь память, а вот в С++ этого добиться очень даже легко
возможность утечки памяти в С\С++ никогда не была недостатком языка. Защита от утечек на коленке пишется за 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

[@Silverity]

А переопределить + (id)alloc и + (void)dealloc?

[@akaStiX]

переопределить + (id)alloc и + (void)dealloc
alloc просто создает новый объект.

[@Silverity]

alloc выделяет память под объект. Инициализирует его уже init.
Например:

+ (id)alloc
{
    Class *newInstance;
    newInstance = (Class *)calloc(1, class_getInstanceSize(self));
    *newInstance = self;
    return (id)newInstance;
}

[@akaStiX]

Реквестую статью на эту тему!

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

З.Ы. Хочу создать объект на стеке

[@Silverity]

*newInstance = self;

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

Хорошая статья уже давно написана: www.mikeash.com/pyblog/friday-qa-2010-12-17-custom-object-allocators-in-objective-c.html

[@meta4]

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

Только теперь это уже не совсем указатель (что описано в статье), и такой хак скорее всего не пройдет (в 64 битном режиме) — например потому, что там «срезаны» младшие 3 бита указателя. Не говоря о других флагах.

[@Silverity]

Не пройдёт, но можно использовать object_setClass()

[@ElleSolomina]

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

[@DjOnline]

>>ARM64 на iOS реально использует 33 бита
Что даёт адресацию всего 8гб. Учитывая что сейчас у смартфонов уже 2гб, то преодоление предела 8гб будет через 3 поколения, то есть всего через 5 лет. Это значит, что все эти программы, хранящие в указателе информацию, перестанут работать?
Сделали бы как в MacOS, 47 бит под указатель, 128Tb адресуемой памяти.

[@corristo]

Все будет работать. При переполнении inline-счетчика рантайм кладет значение в глобальную таблицу.

[@meta4]

>ARMы не используют переименование регистров?

Переименование здесь вообще не причем. Как оно поможет хранить больше данных в регистрах? Что такое fastcall знаете?

[@jeen]

Если объект не обладает C++-деструктором (который вызывается при dealloc), его тоже не нужно вызывать.

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

[@meta4]

Я думаю речь об Objective-C++.