نحوه افزایش سرعت کامپایلر Rust در سپتامبر 2026

آخرین پست من در مورد اجرای کامپایلر Rust دو ماه پیش بود و از آن زمان تاکنون اتفاقات زیادی افتاده است.

اندازه گیری های دوره 2026-07-29 تا 2026-09-28 را می توانید در اینجا مشاهده کنید.

میانگین کاهش زمان دیوار 4.57٪ بود که بهبود قابل توجهی در تنها دو ماه است. از 629 اندازه گیری معیار، 555 مورد از آنها بهبود یافته و تنها 74 مورد پسرفت داشته اند. تعدادی از معیارها شاهد کاهش دو رقمی درصدی بودند. اصطلاح فنی برای این نتیجه "دریای سبز" است.

در آخرین پستم اشاره کردم که چگونه نوح لو در rustdoc برنده سرعت بسیار زیادی شد. او اخیرا پستی نوشت و در آن توضیح داد که دقیقا چگونه این کار را انجام داده است. خواندنی جالب و رضایت بخش است.

#159642: در این روابط عمومی، Jakub Beránek PGO را برای Clippy فعال کرد، و در بهترین حالت تا 18٪، در اکثر معیارهای Clippy بهبودهایی در زمان دیوار ایجاد کرد!

#158734: در این روابط عمومی، نیکیتا پوپوف نسخه LLVM مورد استفاده توسط کامپایلر را به LLVM 23 ارتقا داد. میانگین کاهش زمان دیوار در همه معیارها 1.2٪ بود که ممکن است زیاد به نظر نرسد اما برای یک PR منفرد واقعا چشمگیر است. کار عالی از طرف LLVM!

جستجوگر قرض جدید، پولونیوس آلفا (بدون ارتباط با ناپلئون دینامیت)، در Nightly فعال شد. دقیق‌تر از بررسی‌کننده قرض‌گیری موجود است و برخی برنامه‌های معتبر را می‌پذیرد که بررسی‌کننده قرض قدیمی آن‌ها را رد می‌کند. کار بیشتری نسبت به چک‌کننده قرض‌گیری قدیمی انجام می‌دهد، به اندازه‌ای است که تفاوت قابل‌اندازه‌گیری برای جمع‌آوری زمان در موارد اقلیتی، از جمله جعبه محبوب سرد، ایجاد کند. خوشبختانه جک هوی در این پرونده بوده است.

#161938: در این PR جک برخی از محاسبات زنده بودن را تنبل کرد، که تعداد دستورالعمل‌ها را برای serde 3-5٪ و برای برخی معیارهای دیگر کمتر از 1٪ کاهش داد.

#163027 : در این PR جک یک ساختار داده را تنظیم کرد و مقداری خطوط درونی را بهینه کرد، برای کاهش تعداد دستورات عمدتا زیر 1٪ در معیارهای متعدد.

کارهای بیشتری برای کاهش رگرسیون های آلفای پولونیوس باقی مانده وجود دارد، اما شایان ذکر است که "دریای سبز" نشان می دهد که این رگرسیون ها توسط بسیاری از پیشرفت های اخیر غرق شده اند.

حل کننده صفت جدید، پنه لوپه همرمتایم، [ویرایش. توجه داشته باشید: درست است؟] در Nightly نیز فعال شد.

مانند بررسی کننده قرض جدید، حل کننده صفت جدید در موارد کمی کندتر است. Jana Dönszelmann پست مفصلی در مورد تلاش ها برای بهبود عملکرد این حل کننده جدید نوشت.

پست جانا به اندازه کافی مفصل است که من در مورد حجم زیاد کار در حال انجام روی حل‌کننده جدید چیز بیشتری نمی‌گویم، اما در گذر از روابط عمومی‌ای که انجام دادم به این موارد اشاره می‌کنم: #160479، #160605، #160801، #160892، #161077، و #1611. برخی از این زمان‌های کامپایل را برای جعبه‌های پرت به شدت کاهش می‌دهند: 50% در اینجا، 25% در آنجا، 15% در آنجا، و حتی بیشتر در یک تست استرس. و من تنها کسی نیستم که اینجا پیشرفت کرده ام... برو پست جانا را بخوان.

مشارکت‌کننده جدید xmakro به پیشرفت‌های خوب خود ادامه داد.

#157281: در این PR xmakro بهینه سازی impl handling هنگام ساخت نمودار تخصصی. این باعث کاهش میانگین تعداد چرخه 1.58٪ در همه معیارها شد که برای یک PR منفرد بسیار زیاد است.

#158059: در این PR xmakro یک جنبه از بارگذاری داده های کامپایل افزایشی را بهینه کرد و تعداد دستورالعمل ها را در چندین معیار در بهترین حالت تا 6 درصد کاهش داد.

#160473: در این روابط عمومی xmakro از برخی تخصیصات در مسیر پردازش تعهدات پرهیز کرد، و تعداد دستورالعمل ها را در معیارهای متعدد، در بهترین حالت تا 2 درصد کاهش داد.

#160268: در این PR xmakro با تغییر کد انتخاب حل‌کننده صفت قدیمی/جدید برای استفاده از ارسال استاتیک به جای ارسال پویا، از تخصیص‌های زیادی اجتناب کرد. این باعث کاهش بیشتر تعداد دستورالعمل‌های زیر 1٪ در تعدادی از معیارها شد. این مسیر تخصیص داغ برای مدتی در پروفایل ها نشان داده شده بود و من قبلا دقیقا همان ایده را در #155714 امتحان کرده بودم. اما من روی چند معیار رگرسیون گرفتم، احتمالا به دلیل انتخاب های کمی متفاوت در محل قرار دادن برخی ویژگی های #[inline]. خوب بود که شاهد رفع این ناکارآمدی آشکار بودیم.

#160193: در این PR من الگوریتم پیمایش CFG مورد استفاده توسط تجزیه و تحلیل جریان داده در کامپایلر را تغییر دادم. این تجزیه و تحلیل ها تا نقطه ثابت تکرار می شوند و الگوریتم پیمایش می تواند بر سرعت رسیدن به نقطه ثابت تأثیر بگذارد. برای اکثر کدها، الگوریتم جدید تفاوتی ایجاد نمی کند، اما جعبه کرانلیفت-کدژن یک عملکرد عظیم با بیش از 18000 بلوک اصلی دارد. الگوریتم قدیمی به 1.5 میلیون تماس نیاز داشت تا application_effects_in_block به نقطه ثابتی برای تجزیه و تحلیل EverInitializedPlaces مورد استفاده توسط بررسی کننده قرض برسد. الگوریتم جدید به 90000 نیاز دارد.

این باعث کاهش 30 درصدی زمان دیوار برای ساخت چک این جعبه شد.

#160033: در این روابط عمومی، EverInitializedPlaces را دوباره کارآمدتر کردم، این بار با ردیابی داده های غیر ضروری برای پیش بینی ها. این دستورالعمل کاهش‌یافته روی معیار استرس مسابقه تا 17 درصد و در چند معیار دیگر کمتر از 1 درصد محاسبه می‌شود.

آنها در انواع خاصی از تحلیل ها بسیار خوب هستند. من هنوز در حال نوشتن تمام کد و متن خودم هستم، زیرا (الف) این مهم است، و (ب) خط‌مشی پروژه آن را ایجاب می‌کند، اما من از کمک تجزیه و تحلیل LLM مفیدی در چندین مورد از PRهای ذکر شده در این پست داشتم.

#160535: در این روابط عمومی، کریس دنتون اندازه پشته پیش‌فرض مورد استفاده توسط کامپایلر را افزایش داد، که امکان حذف sure_sufficient_stack را فراهم کرد، مکانیزم گسترش پشته دستی که در مکان‌هایی که مستعد سطوح بالای بازگشت هستند پاشیده می‌شود. بحث‌های زیادی در مورد این مورد وجود داشت، زیرا تصمیم‌گیری برای بهترین روش مقابله با فرسودگی پشته می‌تواند دشوار باشد. اما اثرات عملکرد واضح است، با کاهش تعداد دستورالعمل ها در بسیاری از معیارها، در بهترین حالت تقریبا 3٪.

#160506: این پروژه از تعداد زیادی PRهای "rollup" استفاده می کند، که در آن چندین PR با هم ادغام می شوند. این به این دلیل است که ما ظرفیت CI کافی برای ادغام هر روابط عمومی را به صورت جداگانه نداریم. معمولا PRهایی که بر عملکرد تأثیر می گذارند خود به خود ادغام می شوند تا بتوانیم اثرات آنها را به وضوح اندازه گیری کنیم. برای اولین بار، در یک نقطه، ما آنقدر روابط عمومی بهبود عملکرد داشتیم که در صف ادغام منتظر بودند که جاناتان بروور مجموعه‌ای حاوی 10 روابط عمومی بهبود عملکرد را ایجاد کرد تا همه چیز در حرکت باشد! این یک مشکل خوب است. و بعدا ما #162859 را داشتیم که شامل چهار PR بهبود عملکرد بود.

(نباید نگران لغزش اثرات غیرمنتظره باشید زیرا ما این توانایی را داریم که مجموعه معیار perf را پس از ادغام بر روی هر یک از PR ها اجرا کنیم تا مطمئن شویم که هر PR اثر عملکرد مورد انتظار را دارد.)

#162747: در این روابط عمومی، برخی بهبودهای جزئی در کدی ایجاد کردم که AST را به HIR کاهش می دهد. این پاکسازی بود که انتظار نمی رفت بر عملکرد تأثیر بگذارد، اما تعداد دستورالعمل ها را در معیارهای متعدد کاهش داد، در بهترین حالت 1.5٪. گاهی اوقات شما شانس می آورید.

فردا در Hexcat روی هدف پروژه بهینه سازی عملکرد کامپایلر کار خواهم کرد. هیجان انگیز است! با تشکر فراوان از مارا بوس، پردراگ گرووفسکی، و همه افرادی که به تحقق این امر کمک کردند.

نام حل کننده جدید Penelope Hammer time نیست. این یک شوخی بود