‏کرنل QR؛ ۲۳۲ برابر سریع‌تر با Codex

GPU Mode با همکاری Core Automation یه مسابقهٔ auto-research گذاشت: پیاده‌سازی batched compact-Householder QR — یعنی تجزیهٔ ماتریس به یه بخش متعامد Q و یه بالامثلثی R، همون خروجی فشرده‌ای که torch.geqrf می‌ده — روی دسته‌ای از ماتریس‌های مربعی FP32. نویسنده می‌گه تو ۱۴ روز بیش از ۱۵۰۰ بار سابمیت کرده و آخرش رتبهٔ ۱۲ از ۱۸۳ شرکت‌کننده با ۲۳۲ برابر سرعت نسبت به خط پایه رو گرفته. این اولین تجربهٔ جدی‌ش تو auto-research بوده.

مسئله چرا برای حلقهٔ خودکار مناسب بود؟ چون popcorn CLI اجازه می‌داد ایجنت مستقیم تست، بنچمارک و سابمیت کنه و داور هم زمان‌بندی جدا به ازای هر شکل ماتریس برمی‌گردوند. یعنی یه فیدبک لوپ تنگ و عددی که مدل می‌تونه توش تپه‌نوردی کنه. سازمان‌دهنده‌ها هم سابمیت نامحدود دادن، به شرطی که پشت‌سرهم شلیک نکنی.

سمت الگوریتم، Householder ستون‌به‌ستون جلو می‌ره و هر reflector از ماتریسِ بعد از reflector قبلی ساخته می‌شه، پس کار سریاله و tensor coreها بیکار می‌مونن. راه‌حل کلاسیک نسخهٔ بلوکیه: کار سریالی رو توی یه پنل باریک (مثلاً ۳۲ یا ۶۴ ستون) حبس می‌کنی و بعد همهٔ reflectorهای پنل رو با نمایش WY توی یه آپدیت فشرده می‌کنی تا کل بلوک باقی‌مونده با سه ضرب ماتریسی به‌روز شه. یعنی کار به شکل GEMM درمیاد، دقیقاً همون چیزی که tensor coreها می‌خوان.

روش کارش با Codex هم ساختار داشت: یه AGENTS.md و problem_statement.md نوشت و یه لاگ نگه داشت تا سشن‌های بعدی بدونن کدوم ایده امتحان شده. با دستور goal هدف عددی مشخص می‌داد (یه بار بیشتر از یه روز پشت‌سرهم اجرا شد) و با btw وسط حلقه ازش سؤال می‌پرسید بدون این‌که متوقفش کنه. خط پایهٔ torch.geqrf حدود ۴۱۹ میلی‌ثانیه بود، تو یه روز به ۵۰۰۰ میکروثانیه روی شکل n=512 رسید و نتیجهٔ نهایی ۱٬۸۰۵ میکروثانیه شد.

بعد از مرز ۳۰۰۰ میکروثانیه کار سخت شد و به گفتهٔ نویسنده گلوگاه اغلب launch overhead و هزینهٔ پنل بود، نه حافظه و محاسبه؛ از همین‌جا CUDA graph replay و تخصصی‌کردن کرنل برای شکل‌های ثابت دراومد. مشکل بعدی گیرکردن مدل تو بهینهٔ محلی بود: به‌جای یه کاندید بهترین، بیم ۳ تا ۵ کاندیدی نگه داشت، ساب‌ایجنت‌ها رو روی ایده‌های پرریسک گذاشت و از یه مدل advisor قوی‌تر ایده گرفت. می‌گه Claude زودتر تسلیم می‌شد و Codex سرسخت‌تر بود.

نکات کلیدی:

• رتبهٔ ۱۲ از ۱۸۳ شرکت‌کننده، ۲۳۲ برابر سریع‌تر از خط پایه: از حدود ۴۱۹ میلی‌ثانیه به ۱٬۸۰۵ میکروثانیه.
• الگوریتم برنده Householder بلوکی با آپدیت WY بود تا کار سریالی توی یه پنل ۳۲ تا ۶۴ ستونی حبس شه.
• بیش از ۱۵۰۰ سابمیت تو ۱۴ روز؛ لاگ‌کردن ایده‌های شکست‌خورده بعد از مرز ۳۰۰۰ میکروثانیه حیاتی شد.
• گلوگاه غالب launch overhead و هزینهٔ پنل بود، نه حافظه یا محاسبه.
• برای فرار از بهینهٔ محلی: بیم ۳ تا ۵ کاندیدی، ساب‌ایجنت، و یه مدل advisor.