بستن آگهی

مایک اش در وبلاگ خود اختصاص داده است پیامدهای عملی تغییر به معماری 64 بیتی در آیفون 5 اس. این مقاله از یافته های او استفاده می کند.

دلیل این متن عمدتاً به دلیل حجم زیادی از اطلاعات نادرست است که در مورد معنای واقعی آیفون 5s جدید با پردازنده ARM 64 بیتی برای کاربران و بازار چیست. در اینجا سعی خواهیم کرد اطلاعات عینی در مورد عملکرد، قابلیت ها و پیامدهای این انتقال برای توسعه دهندگان ارائه دهیم.

"64 بیت"

دو بخش از یک پردازنده وجود دارد که برچسب "X-bit" می تواند به آنها اشاره کند - عرض رجیسترهای عدد صحیح و عرض نشانگرها. خوشبختانه، در اکثر پردازنده های مدرن، این عرض ها یکسان است، بنابراین در مورد A7 این به معنی ثبات های اعداد صحیح 64 بیتی و اشاره گرهای 64 بیتی است.

با این حال، به همان اندازه مهم است که اشاره کنیم "64 بیت" به چه معنا نیست: اندازه آدرس فیزیکی RAM. تعداد بیت هایی که باید با RAM ارتباط برقرار کنند (بنابراین مقدار رمی که یک دستگاه می تواند پشتیبانی کند) به تعداد بیت های CPU ارتباطی ندارد. پردازنده‌های ARM دارای آدرس‌هایی بین ۲۶ تا ۴۰ بیت هستند و می‌توان آنها را مستقل از سایر قسمت‌های سیستم تغییر داد.

  • اندازه گذرگاه داده. مقدار داده های دریافتی از RAM یا حافظه بافر نیز به طور مشابه مستقل از این عامل است. دستورالعمل‌های جداگانه پردازنده ممکن است مقادیر متفاوتی از داده را درخواست کنند، اما آنها یا به صورت تکه‌ای ارسال می‌شوند یا بیش از آنچه نیاز است از حافظه دریافت می‌شوند. این به اندازه کوانتوم داده ها بستگی دارد. آیفون 5 قبلاً داده ها را از حافظه به صورت کوانتای 64 بیتی دریافت می کند (و دارای پردازنده 32 بیتی است) و ما می توانیم با اندازه هایی تا 192 بیت روبرو شویم.
  • هر چیزی که مربوط به ممیز شناور باشد. اندازه این رجیسترها (FPU) دوباره مستقل از عملکرد داخلی پردازنده است. ARM از قبل از ARM64 (پردازنده ARM 64 بیتی) از FPU 64 بیتی استفاده می کرد.

مزایا و معایب عمومی

اگر معماری‌های 32 بیتی و 64 بیتی مشابه را مقایسه کنیم، معمولاً تفاوت چندانی با هم ندارند. این یکی از دلایل سردرگمی عمومی است که به دنبال دلیلی برای حرکت اپل به سمت 64 بیت در دستگاه های تلفن همراه است. با این حال، همه اینها از پارامترهای خاص پردازنده A7 (ARM64) و نحوه استفاده اپل از آن ناشی می شود، نه فقط از این واقعیت که پردازنده دارای معماری 64 بیتی است.

با این حال، اگر همچنان به تفاوت های این دو معماری نگاه کنیم، تفاوت های متعددی را خواهیم یافت. نکته واضح این است که رجیسترهای اعداد صحیح 64 بیتی می توانند اعداد صحیح 64 بیتی را کارآمدتر مدیریت کنند. حتی قبل از آن، کار با آنها در پردازنده های 32 بیتی امکان پذیر بود، اما این معمولاً به معنای تقسیم آنها به قطعات طولانی 32 بیتی بود که باعث کندتر شدن محاسبات می شد. بنابراین یک پردازنده 64 بیتی به طور کلی می تواند با انواع 64 بیتی به همان سرعتی که با پردازنده های 32 بیتی محاسبه کند. این بدان معناست که برنامه‌هایی که معمولاً از انواع 64 بیتی استفاده می‌کنند، می‌توانند در یک پردازنده 64 بیتی بسیار سریع‌تر اجرا شوند.

اگرچه 64 بیت بر مقدار کل رمی که پردازنده می تواند استفاده کند تأثیر نمی گذارد، اما می تواند کار با تکه های بزرگ رم در یک برنامه را آسان تر کند. هر برنامه ای که روی یک پردازنده 32 بیتی اجرا می شود، تنها حدود 4 گیگابایت فضای آدرس دارد. با در نظر گرفتن این که سیستم عامل و کتابخانه های استاندارد چیزی را اشغال می کنند، این باعث می شود برنامه چیزی بین 1 تا 3 گیگابایت برای استفاده برنامه داشته باشد. با این حال، اگر یک سیستم 32 بیتی بیش از 4 گیگابایت رم داشته باشد، استفاده از آن حافظه کمی پیچیده تر است. باید متوسل شویم که سیستم عامل را مجبور کنیم تا این تکه های بزرگتر حافظه را برای برنامه ما نقشه برداری کند (مجازی سازی حافظه)، یا می توانیم برنامه را به چندین فرآیند تقسیم کنیم (که در آن هر فرآیند دوباره از نظر تئوری دارای 4 گیگابایت حافظه برای آدرس دهی مستقیم است).

با این حال، این "هک ها" به قدری دشوار و کند هستند که حداقل برنامه ها از آنها استفاده می کنند. در عمل، در یک پردازنده 32 بیتی، هر برنامه فقط از 1 تا 3 گیگابایت حافظه خود استفاده می کند و از رم بیشتر موجود می توان برای اجرای همزمان چندین برنامه یا استفاده از این حافظه به عنوان بافر (کش) استفاده کرد. این کاربردها عملی هستند، اما ما دوست داریم هر برنامه ای بتواند به راحتی از تکه های حافظه بزرگتر از 4 گیگابایت استفاده کند.

اکنون به ادعای مکرر (در واقع نادرست) می رسیم که بدون بیش از 4 گیگابایت حافظه، معماری 64 بیتی بی فایده است. فضای آدرس بزرگتر حتی در سیستمی با حافظه کمتر مفید است. فایل های نگاشت حافظه ابزار مفیدی هستند که در آن بخشی از محتویات فایل به طور منطقی به حافظه فرآیند متصل می شود بدون اینکه کل فایل در حافظه بارگذاری شود. بنابراین، برای مثال، سیستم می‌تواند به تدریج فایل‌های بزرگی را چندین برابر بزرگتر از ظرفیت RAM پردازش کند. در یک سیستم 32 بیتی، چنین فایل های بزرگی را نمی توان به طور قابل اعتمادی نقشه برداری از حافظه کرد، در حالی که در یک سیستم 64 بیتی، به لطف فضای آدرس بسیار بزرگتر، یک تکه کیک است.

با این حال، اندازه بزرگتر نشانگرها یک نقطه ضعف بزرگ نیز به همراه دارد: در غیر این صورت برنامه های یکسان به حافظه بیشتری روی یک پردازنده 64 بیتی نیاز دارند (این نشانگرهای بزرگتر باید در جایی ذخیره شوند). از آنجایی که نشانگرها بخش مکرر برنامه ها هستند، این تفاوت می تواند حافظه نهان را تحت فشار قرار دهد که به نوبه خود باعث کندتر شدن کل سیستم می شود. بنابراین در چشم انداز، می توانیم ببینیم که اگر معماری پردازنده را به 64 بیت تغییر دهیم، در واقع کل سیستم را کند می کند. بنابراین این عامل باید با بهینه سازی های بیشتر در جاهای دیگر متعادل شود.

ARM64

A7، پردازنده 64 بیتی که آیفون 5s جدید را تامین می کند، فقط یک پردازنده ARM معمولی با رجیسترهای گسترده تر نیست. ARM64 دارای پیشرفت‌های عمده‌ای نسبت به نسخه قدیمی‌تر و 32 بیتی است.

پردازنده Apple A7.

ثبت

ARM64 دو برابر ARM 32 بیتی رجیسترهای اعداد صحیح دارد (مراقب باشید تعداد و عرض رجیسترها را اشتباه نگیرید - ما در مورد عرض در قسمت "64 بیتی" صحبت کردیم. بنابراین ARM64 دارای رجیسترهای دو برابر و دو برابر بیشتر است. ثبت). ARM 32 بیتی دارای 16 رجیستر اعداد صحیح است: یک شمارنده برنامه (PC - حاوی تعداد دستورالعمل فعلی)، یک اشاره گر پشته (یک اشاره گر به یک تابع در حال پیشرفت)، یک ثبات پیوند (یک اشاره گر به بازگشت پس از پایان). از تابع)، و 13 باقیمانده برای استفاده کاربردی هستند. با این حال، ARM64 دارای 32 رجیستر عدد صحیح است، از جمله یک ثبات صفر، یک ثبت لینک، یک اشاره گر فریم (شبیه به یک اشاره گر پشته) و یکی رزرو شده برای آینده. این ما را با 28 رجیستر برای استفاده از برنامه ها، بیش از دو برابر ARM 32 بیتی، باقی می گذارد. در همان زمان، ARM64 تعداد رجیسترهای عدد ممیز شناور (FPU) را از 16 به 32 رجیستر 128 بیتی دو برابر کرد.

اما چرا تعداد ثبت ها اینقدر مهم است؟ حافظه به طور کلی کندتر از محاسبات CPU است و خواندن/نوشتن می تواند زمان بسیار زیادی را ببرد. این باعث می‌شود که پردازنده سریع منتظر حافظه بماند و ما به محدودیت سرعت طبیعی سیستم می‌رسیم. پردازنده‌ها سعی می‌کنند این نقص را با لایه‌هایی از بافر پنهان کنند، اما حتی سریع‌ترین آنها (L1) همچنان کندتر از محاسبه پردازنده است. با این حال، ثبات ها سلول های حافظه مستقیماً در پردازنده هستند و خواندن/نوشتن آنها به اندازه ای سریع است که سرعت پردازنده را کاهش نمی دهد. تعداد رجیسترها عملاً به معنای میزان سریعترین حافظه برای محاسبات پردازنده است که به شدت بر سرعت کل سیستم تأثیر می گذارد.

در عین حال، این سرعت نیاز به پشتیبانی بهینه سازی خوب از کامپایلر دارد تا زبان بتواند از این ثبات ها استفاده کند و مجبور نباشد همه چیز را در حافظه عمومی برنامه (آهسته) ذخیره کند.

مجموعه دستورالعمل

ARM64 همچنین تغییرات عمده ای را در مجموعه دستورالعمل ها ایجاد می کند. یک مجموعه دستورالعمل مجموعه ای از عملیات اتمی است که یک پردازنده می تواند انجام دهد (مثلاً 'ADD register1 register2' اعداد را در دو ثبات جمع می کند). توابع موجود برای هر زبان از این دستورالعمل ها تشکیل شده است. توابع پیچیده تر باید دستورالعمل های بیشتری را اجرا کنند، بنابراین می توانند کندتر باشند.

دستورالعمل های جدید در ARM64 برای رمزگذاری AES، عملکردهای هش SHA-1 و SHA-256 است. بنابراین به جای یک پیاده سازی پیچیده، فقط زبان این دستورالعمل را فراخوانی می کند - که سرعت زیادی را برای محاسبه چنین توابعی به ارمغان می آورد و امیدواریم امنیت را در برنامه ها اضافه کند. به عنوان مثال. Touch ID جدید همچنین از این دستورالعمل‌ها در رمزگذاری استفاده می‌کند و سرعت و امنیت واقعی را امکان‌پذیر می‌کند (در تئوری، مهاجم باید خود پردازنده را تغییر دهد تا به داده‌ها دسترسی پیدا کند - که حداقل با توجه به اندازه کوچک آن غیر عملی است).

سازگاری با 32 بیت

ذکر این نکته ضروری است که A7 می تواند به طور کامل در حالت 32 بیتی بدون نیاز به شبیه سازی اجرا شود. این بدان معناست که آیفون 5s جدید می تواند برنامه های کامپایل شده بر روی ARM 32 بیتی را بدون هیچ کاهش سرعت اجرا کند. با این حال، پس از آن نمی تواند از توابع جدید ARM64 استفاده کند، بنابراین همیشه ارزش دارد که یک ساخت ویژه فقط برای A7 ساخته شود، که باید بسیار سریعتر اجرا شود.

زمان اجرا تغییر می کند

Runtime کدی است که توابعی را به زبان برنامه نویسی اضافه می کند که می تواند در حین اجرای برنامه تا پس از ترجمه از آنها استفاده کند. از آنجایی که اپل نیازی به حفظ سازگاری برنامه ها ندارد (که یک باینری 64 بیتی روی 32 بیت اجرا می شود)، آنها می توانند چند پیشرفت بیشتر در زبان Objective-C انجام دهند.

یکی از آنها به اصطلاح است نشانگر برچسب گذاری شده (نشانگر مشخص شده). به طور معمول، اشیاء و اشاره گرها به آن اشیا در بخش های جداگانه ای از حافظه ذخیره می شوند. با این حال، انواع اشاره گر جدید به کلاس هایی با داده های کمی اجازه می دهد تا اشیا را مستقیماً در اشاره گر ذخیره کنند. این مرحله نیاز به تخصیص مستقیم حافظه برای شی را برطرف می کند، فقط یک اشاره گر و شی درون آن ایجاد کنید. نشانگرهای برچسب‌گذاری شده تنها در معماری 64 بیتی پشتیبانی می‌شوند، همچنین به این دلیل که دیگر فضای کافی در یک اشاره‌گر 32 بیتی برای ذخیره داده‌های مفید کافی وجود ندارد. بنابراین iOS برخلاف OS X هنوز از این قابلیت پشتیبانی نمی کرد. با این حال، با ورود ARM64، این موضوع در حال تغییر است و iOS در این زمینه نیز به پای OS X رسیده است.

اگرچه نشانگرها 64 بیت هستند، اما در ARM64 فقط 33 بیت برای آدرس خود اشاره گر استفاده می شود. و اگر بتوانیم بقیه بیت های اشاره گر را به طور قابل اعتمادی از ما بپوشانیم، می توانیم از این فضا برای ذخیره داده های اضافی استفاده کنیم - مانند مورد اشاره گرهای برچسب گذاری شده ذکر شده. از نظر مفهومی، این یکی از بزرگترین تغییرات در تاریخ Objective-C است، اگرچه یک ویژگی قابل فروش نیست - بنابراین اکثر کاربران نمی دانند که اپل چگونه Objective-C را به جلو می برد.

در مورد داده های مفیدی که می توان در فضای باقی مانده از چنین نشانگر برچسب گذاری شده ذخیره کرد، برای مثال Objective-C اکنون از آن برای ذخیره به اصطلاح استفاده می کند. تعداد مراجع (تعداد مراجع). قبلاً، شمارش مرجع در مکان دیگری در حافظه ذخیره می‌شد، در جدول هش که برای آن آماده شده بود، اما این می‌تواند کل سیستم را در صورت تعداد زیادی تماس alloc/dealloc/retain/release کند کند. جدول به دلیل ایمنی نخ باید قفل می شد، بنابراین تعداد ارجاع دو شی در دو رشته را نمی توان همزمان تغییر داد. با این حال، این مقدار به تازگی به بقیه به اصطلاح وارد شده است ISA شاخص ها. این یکی دیگر از مزیت ها و شتاب های نامحسوس، اما بزرگ در آینده است. با این حال، این هرگز در یک معماری 32 بیتی قابل دستیابی نیست.

اطلاعات مربوط به اشیاء مرتبط، اینکه آیا شیء دارای ارجاع ضعیفی است یا خیر، آیا لازم است یک تخریب کننده برای شیء تولید شود یا خیر، همچنین به تازگی در محل باقی مانده نشانگرها به اشیاء درج می شود. به لطف این اطلاعات، Objective-C Runtime قادر است به طور اساسی سرعت اجرا را افزایش دهد که در سرعت هر برنامه منعکس می شود. از آزمایش، این به معنای افزایش سرعت 40 تا 50 درصدی تمام تماس‌های مدیریت حافظه است. فقط با جابجایی به نشانگرهای 64 بیتی و استفاده از این فضای جدید.

نتیجه

اگرچه رقبا سعی خواهند کرد این ایده را گسترش دهند که حرکت به معماری 64 بیتی غیر ضروری است، شما از قبل می دانید که این فقط یک نظر بسیار ناآگاهانه است. درست است که تغییر به 64 بیت بدون تطبیق زبان یا برنامه های کاربردی واقعاً معنی ندارد - حتی کل سیستم را کند می کند. اما A7 جدید از یک ARM64 مدرن با یک مجموعه دستورالعمل جدید استفاده می‌کند و اپل زحمت مدرنیزه کردن کل زبان Objective-C و بهره‌گیری از قابلیت‌های جدید را بر عهده گرفته است - از این رو سرعت وعده داده شده است.

در اینجا ما به دلایل زیادی اشاره کرده‌ایم که چرا معماری 64 بیتی قدم درستی به جلو است. این یک انقلاب دیگر "زیر سرپوش" است که به لطف آن اپل سعی می کند نه تنها با طراحی، رابط کاربری و اکوسیستم غنی، بلکه عمدتاً با مدرن ترین فناوری های موجود در بازار در خط مقدم باقی بماند.

منبع: mikeash.com
.