بهینهسازی سطح بالای نرمافزار دیگر انحصار متخصصان کمیاب مهندسی عملکرد نیست. طبق تحلیل فنی دن لو (Dan Luu) که در ۲۲ اوت ۲۰۲۶ منتشر شد، زمان مورد نیاز انسان برای پیادهسازی بهینهسازیهای پیچیده، به دلیل استفاده از عاملهای کدنویس، بین ۱,۰۰۰ تا ۱,۰۰۰,۰۰۰ برابر کاهش یافته است.
برای چندین دهه، صنعت نرمافزار یک موازنه را پذیرفته بود: نرمافزار یا باید عمومی و با سرعت متوسط باشد، یا بسیار تخصصی و با هزینه ساخت بالا. کارهای عملکردی که زمانی به تیمی از متخصصان نیاز داشت، اکنون توسط هر کسی که بتواند چند جمله توصیفی را در یک عامل بنویسد، قابل اجراست. این چرخش، صنعت را به سمت «نرمافزار سفارشی پویا» میبرد؛ کدی که بهجای یک کلاس کلی از بارهای کاری، دقیقاً برای یک بار کاری (Workload) خاص تنظیم میشود.
زمینه و هزینههای عملکرد
در گذشته، هزینه کارهای تخصصی عملکرد بهقدری بالا بود که تنها برای سودآورترین پروژهها یا مقیاسهای عظیم توجیه داشت. این وضعیت باعث شد بیشتر نرمافزارها بدون بهینهسازی باقی بمانند، زیرا نیروی انسانی لازم برای استخراج حداکثر سرعت، بیش از حد گران بود.
همانطور که در بحثهای گذشتهی ما دربارهی امنیت مدلهای بازمتن اشاره کردیم، کاهش هزینههای ورود به حوزههای پیچیده فنی، همواره ریسکهای جدیدی را به همراه دارد. مارک بروکر (Marc Brooker) اشاره میکند که نتیجه احتمالی این تحول، نرمافزاری است که بهطور پویا با یک بار کاری خاص تطبیق مییابد. این رویکرد مشابه تکنیکهای قدیمی «دموسین» (Demoscene) است که بر این تمرکز داشتند تا برای مسائل یا سختافزارهای بسیار خاص، کدی فوقسریع و کوچک بسازند. در یک مثال افراطی، یکی از دموها برای دستیابی به محلیسازی بهتر حافظه پنهان (Cache Locality)، از کدهای خودش بهعنوان بافت (Texture) استفاده میکرد.
مرگ بهینهسازیهای «بیش از حد گران»
بسیاری از بهبودهای عملکردی پیش از این نادیده گرفته میشدند چون هزینه تأیید آنها از سودشان بیشتر بود. برای مثال، افزایش ۲ درصدی سرعت ممکن بود روزها تأیید دستی نیاز داشته باشد تا اطمینان حاصل شود که یک بهینهسازی پیچیده، باگهای غیرقطعی (Non-deterministic) ایجاد نکرده است. اکنون عاملها میتوانند خستگیبخشترین مراحل عیبیابی و تأیید را در یک حلقه تکرار کنند و این دستاوردهای حاشیهای را از نظر اقتصادی توجیهپذیر سازند.
دن لو چندین مثال عینی از کارهای «بسیار سخت» که اکنون ساده شدهاند را مطرح میکند:
- کامپایلرهای JIT: طبق گفته مایکل مالیس، در برخی حوزهها «کدنویسی هرگز بخش سخت کار نبود»، اما نوشتن کامپایلرهای Just-In-Time قطعاً سخت بود. کمیاب بودن این کامپایلرها نشان میدهد که آنها در گذشته دشوارتر از آن بودند که توجیهپذیر باشند. مدلهای زبانی بزرگ این مانع را کاهش دادهاند، همانطور که در پروژه pgrust دیده میشود. این پیشرفتها در راستای ظهور مدلهایی است که قابلیتهای کدنویسی آنها را به جایگزینی عملی برای توسعهدهندگان نزدیک میکند.
- چندرشتهایسازی (Multi-threading): پیادهسازی الگوریتمهای پیچیده چندرشتهای برای هوش مصنوعی بازیها — که اغلب نیاز به لاگهای بازپخش سفارشی برای رفع باگهای غیرقطعی دارد — اکنون بهجای هفتهها، در چند دقیقه انجام میشود. لو فرآیند را اینگونه توصیف میکند: یک عامل بهطور ساده حلقهای را اجرا میکند که لاگها را بازپخش کرده و برای موارد غیرقطعی، لاگهای جدید اضافه میکند تا زمانی که یک بازپخش کامل و دقیق حاصل شود.
- کامپایل کد بومی: در آزمایشی با موتور رگکس FRE، یک عامل سیستمی را پیاده کرد که در حین اجرای ripgrep، یک کامپایلر کد بومی را در رشتهای مجزا اجرا میکند و برای پرسوجوهای طولانی به کد بومی سوییچ میکند. اگرچه این روش یک رشته را صرف کامپایل میکند و ممکن است سرعت پرسوجوهای کوتاه را کاهش دهد، اما عملکرد را برای پرسوجوهایی که ثانیهها یا دقایق طول میکشند، بهطور قابلتوجهی بهبود میبخشد.
- اندکسگذاری سفارشی: لو به BitFunnel اشاره میکند، یک اندکس جستوجوی بینگ که برای جذب سریع متن تخصصی شده و جایزه بهترین مقاله در SIGIR را برده است. در حالی که نسخه متنباز آن یک JIT دارد، نسخه بینگ شامل چندین JIT است. چنین سطحی از بهینهسازی پیش از این یک پروژه عظیم بود، اما اکنون لو معتقد است این پروژهای است که میتوان آن را در یک آخر هفته به پایان رساند.
محک مزیت هوش مصنوعی
در یک مقایسه مستقیم، شکاف بین متخصصان انسانی و عاملهای هوش مصنوعی در مسائل بهینهسازی محدود، در حال عمیق شدن است. جیمی براندون، مهندس عملکرد حرفهای، آزمون تخصصی آنتروپیک را انجام داد. پس از اینکه او کارش را تمام کرد، از Claude خواست تا از همانجایی که او متوقف شده بود، کار را ادامه دهد. کلود به نتیجهای بسیار بهتر رسید و راهکارهای «دیوانهواری» را پیاده کرد که براندون هرگز امتحان نمیکرد، مگر اینکه هفتهها روی آن مسئله کار کرده باشد.
در یک بنچمارک موتور رگکس، موتور FRE که توسط عامل هدایت میشد، با فعالسازی کامپایل AOT (Ahead-of-Time)، ۷٪ افزایش سرعت در پرسوجوهای نمونه نشان داد. برای پرسوجوهای سادهتر و طولانیتر، این بهبود به ۲ تا ۴ برابر رسید. این نتیجه پس از آن حاصل شد که عامل یک ماه روی مجموعه بنچمارک rebar حلقه زد و در نهایت پس از هشدار درباره یک بنچمارک نگه داشته شده (Holdout)، بهینهسازیهای خود را تعمیم داد.
بهینهسازی ویژه بار کاری
مخربترین تغییر، حرکت به سمت نرمافزاری است که خود را برای کاربر خاص بهینه میکند. بهجای یک موتور «کارخانه نرمافزار» که برای همه طراحی شده، عاملها اکنون میتوانند دادههای یک مشتری خاص را تحلیل کرده و موتور را برای آن دادهها بازنویسی کنند.
در آزمونی که درست پیش از انتشار پست انجام شد، یک عامل بهینهسازی ویژه بار کاری را برای پرسوجوهای ripgrep تنها در دو دقیقه انجام داد. نتیجه ۲٪ افزایش سرعت روی یک مجموعه داده holdout بود؛ سودی ناچیز برای یک کاربر محلی، اما بردی عظیم وقتی در مقیاس زیرساخت ابری آمازون (Amazon) اجرا شود، جایی که مارک بروکر معتقد است این روند اجتنابناپذیر خواهد بود.
تحلیل بارهای کاری واقعی
لو برای درک دلیل موفقیت این روش، توزیع پرسوجوهای ripgrep در ماشین خود را تحلیل کرد:
- توزیع الگوها: الگوهای طولانی بیشتر از حد انتظار بودند و ۹۹٪ پرسوجوها از نوع رگکس بودند (تنها ۱٪ جستوجوی رشتهای غیر رگکس بودند).
- موضعی بودن: الگوها تکرار کمی داشتند (۹۴٪ فقط یکبار رخ دادند)، اما فایلها تکرار بالایی داشتند، به این معنی که احتمالاً فایلها بهطور مکرر در حافظه جستوجو میشوند.
- مجموعه نویسهها: تقریباً تمام پرسوجوها و فایلهای جستوجو شده فقط ASCII بودند.
لو اشاره میکند که بخش بزرگی از تلاشهای بهینهسازی عمومی FRE روی مسائل یونیکد (غیر ASCII) تلف شده بود. اگر عامل فقط روی مورد خاص ASCII برای بار کاری او تمرکز میکرد، نتایج حتی بهتر میشد. این نشان میدهد که پشتیبانی از ویژگیهای کمتر (مانند نادیده گرفتن ارجاعات پشتی یا نویسههای غیر ASCII) میتواند پیادهسازی را سریعتر کند.
سلسلهمراتب جدید عملکرد
این قابلیت، فضای رقابتی نرمافزار را تغییر میدهد. در مورد یک هوش مصنوعی بازی ساخته شده در عصر GPT-5.1 یا 5.2، دن لو دریافت که افزودن چندرشتهایسازی و ۱۰ تا ۲۰ بهینهسازی «آزاردهنده»، باعث شد هوش مصنوعی او بر دیگران غالب شود. او اشاره کرد که در این بازی خاص، به ازای هر دو برابر شدن سرعت، حدود ۱۰۰ امتیاز Elo کسب میشود.
چون هزینه این بهینهسازیها اکنون نزدیک به صفر است، دیگر منطقی نیست که انتظار داشته باشیم کدهای دستنویس با نسخههای بهینهشده توسط عامل رقابت کنند. هوش مصنوعی لو هم از نسخه کد بومی و هم از یک نسخه «هولناک» WASM با حافظه مشترک و جاوااسکریپت استفاده کرد و بسته به معماری، از الگوریتمهای مختلف چندرشتهای (minimax برای شبکههای کوچک و MCTS برای شبکههای بزرگتر) بهره برد.
با این حال، یک محدودیت حیاتی باقی مانده است: طراحی آزمایش. در حالی که عاملها میتوانند بهینهسازیها را اجرا کنند، هنوز در طراحی آزمایشهایی برای اثبات کارایی آنها ضعیف هستند. قضاوت انسانی همچنان برای ایجاد چارچوب لازم است و سپس عامل در آن چارچوب برای یافتن پیک عملکرد تکرار میکند.
این تحول نشان میدهد که «کدهای حجیم» (Bloated code) که اغلب به نرمافزارهای تولید شده توسط هوش مصنوعی نسبت داده میشود، یک انتخاب است، نه یک ضرورت. با این حال، برخی تحلیلگران معتقدند افزایش حجم کد توسط AI لزوماً به معنای افزایش سودآوری اقتصادی نیست و باید میان حجم کد و ارزش واقعی آن تمایز قائل شد. ابزارهای حذف این حجیمات و رسیدن به کارایی سطح اسمبلی اکنون در دسترس هر توسعهدهندهای با اشتراک یک مدل SOTA است.
پیامدهای بیشتر برای توسعه نرمافزار
این تکامل، نگاه ما به «بخشهای سخت» نرمافزار را تغییر میدهد. پیش از این، پایگاههای داده از سختترین بخشها برای ساخت بودند و این موضوع جاهطلبی آنها را محدود میکرد. با کاهش مانع ورود به اجزای پیچیده مانند کامپایلرهای JIT، توسعهدهندگان میتوانند درباره معماری نرمافزارهای خود بلندپروازتر باشند.
لو اشاره میکند برای کسانی که به مدلهای SOTA روی تراشههای Cerebras یا سایر شتابدهندهها دسترسی دارند، افزایش توکن در ثانیه (tok/s)، تقاضا برای جستوجو و اندکسگذاری را بیشتر میکند. این یک چرخه ایجاد میکند که در آن نیاز به اندکسهای سفارشی و پرسرعت افزایش مییابد، درست در زمانی که هزینه ساخت آنها سقوط میکند.
عنصر انسانی در عصر هوش مصنوعی
بهرغم کارایی عاملها، زمان لازم برای تبدیل یک نتیجه به چیزی واقعاً دقیق کاهش نیافته و در برخی موارد افزایش یافته است. لو اشاره میکند که اگرچه میتواند آزمایشها را سریع اجرا کند و کنجکاوی خود را ارضا کند، اما فرآیند پاکسازی دادهها و نوشتن گزارشهای دقیق همچنان کاری کند و انسانمحور است.
این وضعیت یک دوگانگی جدید در مهندسی ایجاد میکند: «فاز آزمایش» اکنون تقریباً آنی است، در حالی که «فاز تأیید و مستندسازی» همچنان یک گلوگاه است. با این حال، برای کاربر نهایی نتیجه یکسان است: نرمافزاری سریعتر و کارآمدتر از آنچه پیش از این بدون بودجه مهندسی میلیون دلاری ممکن بود.
جزئیات فنی تکمیلی
لو دادههای دقیقتری درباره مکانیزمهای بهینهسازی ارائه میدهد:
- هزینه دقت: لو اشاره میکند که اگرچه اکنون میتواند آزمایشها را در چند دقیقه اجرا کند، اما زمان لازم برای پاکسازی دادهها و نوشتن یک پست همچنان زیاد است. او تلاش کرد پست را در ۳۰ دقیقه بنویسد اما موفق نشد، زیرا مشکلات دادهها اغلب نیاز به بررسیهای عمیق برای رفع دارند.
- بحث حجیم بودن: لو با این دیدگاه که توسعهدهندگان باید بابت نوشتن کد کند احساس بدی کنند مخالف است. تخصص عملکرد کمیاب است و اغلب اولویت تجاری نیست. اما چون یک عامل اکنون میتواند مهترفی مثل جیمی براندون را در یک مسئله محدود شکست دهد، عملکرد مناسب اکنون برای همه در دسترس است.
- عملکرد فرانت-اند: لو پیشنهاد میکند عاملها به همان اندازه در کاهش معیارهای فرانت-اند مانند Largest Contentful Paint (LCP) و Interaction to Next Paint (INP) توانمند هستند.
- نقش سختافزار: تقاضا برای اندکسگذاری پرسرعت توسط آزمایشگاههای هوش مصنوعی که از شتابدهندهها استفاده میکنند تشدید شده است. لو اشاره میکند در حالی که حساب ۲۰۰ دلاری ماهانه او برای یک ripgrep سریعتر کافی است، کسانی که در آزمایشگاههای AI هستند انگیزه بیشتری دارند تا اندکسهای سفارشی با جذب سریع برای کل ماشین بسازند تا بتوانند دایرکتوریهای موقت عظیم و فایلهای تولید شده را مدیریت کنند.
گام بعدی شما
- اگر پروژهای با گلوگاههای عملکردی دارید، بهجای استخدام متخصص، از یک عامل کدنویس بخواهید برای بار کاری (Workload) خاص شما، بهینهسازیهای سطح پایین (مانند SIMD یا JIT) را پیاده کند.
- برای کاهش هزینههای زیرساختی ابری، بررسی کنید آیا میتوانید موتورهای پردازشی خود را بهصورت پویا با دادههای هر مشتری بازنویسی کنید.
- تمرکز خود را از «نوشتن کد بهینه» به «طراحی آزمایشهای دقیق برای تأیید بهینهسازی» تغییر دهید، زیرا این تنها جایی است که هنوز به تخصص انسانی نیاز است.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو