اگر از سیستم‌های ۱۶ هسته‌ای برای توسعه با Rust استفاده می‌کنید، احتمالاً می‌دانید که بخش زیادی از توان پردازشی شما هنگام کامپایل در حالت بیکاری می‌ماند. ابزار جدیدی به نام Headstart این اتلاف منابع را به چالش کشیده و زمان cargo check را در پروژه‌های حجیم تا ۵۴٪ کاهش داده است. طبق مستندات منتشر شده در ۴ اکتبر ۲۰۲۶، این رویکرد زنجیره خطی سنتی وابستگی‌ها را می‌شکند؛ یعنی دیگر لازم نیست هر کریت (Crate) — که شبیه به یک بسته یا ماژول مستقل در Rust است — کاملاً بررسی شود تا وابستگانش بتوانند کار خود را شروع کنند.
در گردش‌کار استاندارد Rust، یک کریت باید منتظر بماند تا تمام وابستگی‌هایش، از جمله بدنه توابع، بررسی نوع شوند. این وضعیت یک گلوگاه ایجاد می‌کند که در آن هسته‌های CPU بیکار می‌مانند تا یک وابستگی بزرگ به پایان برسد. این وضعیت شبیه به یک کارگاه ساختمانی است که در آن برق‌کارها اجازه ورود به ساختمان را ندارند تا تک‌تک آجرهای دیوارها چیده شود، در حالی که برای شروع کارشان فقط داشتن اسکلت ساختمان کافی است.
همان‌طور که در تحلیل‌های پیشین ما درباره بهینه‌سازی‌های کامپایلر اشاره کردیم، حذف گام‌های غیرضروری کلید افزایش سرعت است. Headstart این کار را با معرفی «متادیتای زودهنگام» انجام می‌دهد. این ابزار rustc را تغییر می‌دهد تا به محض بررسی رابط (Interface) یک کریت، یک فایل .early-rmeta بنویسد و تحلیل زمان‌بر بدنه توابع را نادیده بگیرد. طبق مستندات پروژه در گیت‌هاب، سپس cargo به کریت‌های وابسته دستور می‌دهد تا بلافاصله بر اساس این رابط زودهنگام، کامپایل را آغاز کنند.
سازوکار و جزئیات فنی
به نقل از مستندات پروژه در گیت‌هاب، کریت‌های Rust معمولاً بر اساس رابط وابستگی که در فایل .rmeta ذخیره شده است، کامپایل می‌شوند. Headstart تشخیص داده است که یک کریت وابسته برای بررسی نوع خود، نیازی به بدنه توابع وابستگی‌هایش ندارد.
در این مدل جدید، cargo check به وابستگان اجازه می‌دهد تنها با استفاده از متادیتای زودهنگام به پایان برسند. اما برای cargo build (ساخت نهایی)، وابستگان تمام تحلیل‌ها را روی متادیتای زودهنگام انجام می‌دهند، اما برای تولید کد نهایی باید منتظر متادیتای کامل بمانند. این رویکرد در مدیریت موازی منابع بسیار موثر است، مشابه آنچه در ابزارهای مبتنی بر Rust برای ساده‌سازی مدیریت موازی در عصر هوش مصنوعی مشاهده می‌کنیم.
برای حفظ صحت کد، Cargo خروجی یک کریت را تنها زمانی گزارش می‌کند که تمام وابستگی‌های آن با موفقیت به پایان رسیده باشند. اگر یک وابستگی با خطا مواجه شود، خروجی وابستگان آن حذف می‌شود. همچنین اگر بدنه یک تابع حاوی خطا باشد، ساخت پروژه با همان وضعیت و پیام‌های خطای سیستم فعلی شکست می‌خورد، هرچند ممکن است ترتیب پیام‌های JSON و خطوط پیشرفت با سیستم فعلی متفاوت باشد.
پیاده‌سازی فنی
این سیستم بر پایه چندین وصله (Patch) کلیدی در کامپایلر و مدیریت بسته است:
- rustc (-Zearly-metadata): این بخش شامل ۶ وصله است. یک پرس‌وجوی جدید به نام
analysis_interfacesتحلیل را به دو بخش «رابط‌های آیتم» و «بدنه توابع» تقسیم می‌کند. درایور کامپایلر فایل.early-rmetaرا دقیقاً بین این دو فاز می‌نویسد. - cargo (-Zheadstart): این بخش شامل ۳ وصله است. مدیریت بسته پرچم متادیتای زودهنگام را به تمام کامپایل‌ها می‌فرستد و وابستگان را بلافاصله پس از دریافت اعلان متادیتای زودهنگام فعال می‌کند.
- مدیریت جایگاه‌های شغلی (Job Slot): اگر یک کریت وابسته برای تولید کد نیاز به متادیتای کامل داشته باشد و متوقف شود، جایگاه شغلی خود را به کارهای دیگر بازمی‌گرداند تا بهره‌وری CPU به حداکثر برسد.
- تعویض متاداتا: لودر ابتدا متادیتای زودهنگام را می‌پذیرد و سپس پیش از مرحله تولید کد نهایی، آن را با متادیتای کامل جایگزین می‌کند. این فرآیند روی یک قفل (Lock) منتظر می‌ماند تا تولیدکننده متادیتای کامل را بنویسد.
بنچمارک‌های عملکرد
بر اساس بررسی‌های انجام شده روی ماشین‌های ۱۶ هسته‌ای و ۱۳ پروژه واقعی از جمله rust-analyzer، zed، bevy، lemmy و polars، دستاوردهای قابل‌توجهی ثبت شده است. برای cargo check سرعت تا ۵۴٪ و برای cargo build تا ۴۲٪ افزایش یافته است. هیچ‌یک از پروژه‌های تست شده با فعال‌سازی Headstart کندتر نشدند.
در حالت استفاده از فرانت-اند موازی (-Zthreads=8)، که پیش از این برخی از این حوزه‌ها را بهینه کرده بود، این ابزار تا ۲۵٪ بهبود اضافی ایجاد می‌کند.
در ماشین‌های کوچک‌تر ۴ هسته‌ای، به دلیل تعداد کمتر هسته‌های بیکار برای اشغال، دستاوردها متواضع‌تر است. برای مثال در rust-analyzer سرعت بررسی ۲۴٪ و سرعت ساخت ۱۳ تا ۱۵٪ بهبود یافت. همچنین پروژه codex-rs تست شد که ۱۴٪ بهبود در زمان بررسی نشان داد، در حالی که سرعت ساخت‌های گسترده (wide builds) تقریباً بدون تغییر باقی ماند.
اعتبارسنجی و تست
تیم توسعه برای تایید صحت پیاده‌سازی از مجموعه‌ای از اسکریپت‌های سخت‌گیرانه استفاده کرد:
- بررسی خطاها: اسکریپت
scripts/check-errors.shتایید کرد که ساخت‌های پاک (clean builds)، خطاهای وابستگی و خطاهای باینری، دقیقاً همان خروجی‌های انسانی و JSON نسخه اصلی (upstream) را تولید می‌کنند. - ویرایش‌های افزایشی: اسکریپت
scripts/check-incremental.shتوالی‌های مختلف ویرایش کد را تست کرد؛ مانند اضافه کردن یکimpl Fnکه یک وابستگان آن را فراخوانی می‌کند، یا عمداً خراب کردن و سپس اصلاح یک رابط. این دقت در ردیابی تغییرات، یادآور متدهای جدید برای نمایش استدلال‌های عامل‌های کدنویس است که بر ثبت دقیق مسیر پیاده‌سازی تمرکز دارند. - تایید تعویض متاداتا: اسکریپت
scripts/check-swap.shتضمین کرد کتابخانه‌هایی که با متادیتای زودهنگام شروع شده و سپس به متادیتای کامل سوئیچ می‌کنند، باینری‌هایی تولید می‌کنند که در تمام سطوح بهینه‌سازی، با نسخه‌های متادیتای کامل یکسان هستند. - بنچمارک گسترده: اسکریپت
scripts/sweep.shتمام ۵۳ بنچمارک کامپایلrustc-perfرا با پرچم-Zearly-metadata-verifyاجرا کرد تا اطمینان حاصل شود هیچ تغییری در تشخیص‌های (diagnostics) کامپایلر رخ نداده است.
این تغییر، فرض بنیادین مبنی بر اینکه بررسی نوع در Rust باید به‌صورت کاملاً متوالی در مرز کریت‌ها باشد را تغییر می‌دهد. با جداسازی رابط از پیاده‌سازی در فاز بررسی، کامپایلر می‌تواند هسته‌های CPU را به‌طور موثرتری اشغال کند.
برای توسعه‌دهندگان، این به معنای چرخه سریع‌تر «ویرایش-بررسی-تکرار» است. اگرچه هزینه مصرف حافظه کمی افزایش می‌یابد و ممکن است خطاها کمی دیرتر در فرآیند گزارش شوند، اما این بهای اندکی در برابر حذف زمان‌های بیکاری طولانی در ایستگاه‌های کاری قدرتمند است.
گام بعدی شما
- اگر از نسخه‌های ناپایدار Rust استفاده می‌کنید، وصله‌های rustc و cargo را اعمال کنید.
- متغیر محیطی
CARGO_UNSTABLE_HEADSTART=trueرا برای تست در پروژه‌های خود فعال کنید. - در فایل
.cargo/config.tomlعبارتheadstart = trueرا زیر بخش[unstable]اضافه کنید.
اما بهینه‌سازی‌های سخت‌افزاری برای زبان‌های سیستمی حتی پیچیده‌تر است — به تحلیل ما درباره معماری‌های جدید پردازشی مراجعه کنید.
گفتگو