„პროგრამები ნელი რატომ არის? ამის მიზეზი აღარ არსებობს“ — დან ლუს არგუმენტი

წლების განმავლობაში ნელი პროგრამები ექსპერტიზის ეკონომიკით აიხსნებოდა: წარმადობაზე მუშაობა იშვიათი უნარების მქონე ინჟინრებს სჭირდებოდა, ამიტომ პროექტების უმეტესობა ამის გარეშე რჩებოდა. ინჟინერი დან ლუ ახალ ბლოგპოსტში ამტკიცებს, რომ ეს ბალანსი დაირღვა — კოდირების აგენტებმა ოპტიმიზაციის ფასი რამდენიმე რიგით შეამცირეს.

არგუმენტი

პოსტი იწყება ვირუსული მტკიცებით, რომ LLM-ების მიერ გამოწვეული „მსუქანი“ კოდის კრიტიკოსები შერცხვებიან, როცა ყველაფერი „სუპერ-ოპტიმიზებულ ასემბლერზე“ გადაიწერება. ლუ ამას ასე შორს არ მიჰყვება: ასემბლერზე ყველაფრის გადაწერა არ გველის, მაგრამ ოპტიმიზაცია, რომელიც ადრე იშვიათი უნარების მქონე ადამიანს ან გუნდს სჭირდებოდა, ახლა ნებისმიერს შეუძლია, ვისაც რამდენიმე წინადადების აკრეფა შეუძლია. მისი შეფასებით, ადამიანური დროის ხარჯი „ხშირად 1000-ჯერ, 10000-ჯერ ან 1000000-ჯერ“ დაეცა, ფულადი ხარჯი კი დაახლოებით 1000-ჯერ — თუ შევადარებთ იმ ბინგის ინჟინერს, რომელიც საძიებო ინდექსისთვის კომპილატორებსა და JIT-ებს წერდა.

კონკრეტული ციფრები: regex და ripgrep

ლუ ამას ექსპერიმენტებით ამოწმებს FRE-ზე — regex-ის ძრავზე, რომელიც წინა პოსტში ისე შეიქმნა, რომ აგენტი ერთი თვე მუშაობდა rebar-ის ბენჩმარკების კრებულზე. ზედმეტი მორგება იმდენად ძლიერი იყო, რომ აგენტს holdout-ტესტის არსებობის შესახებ ეთქვა, სანამ ოპტიმიზაციები განზოგადდა. ერთ ექსპერიმენტში ripgrep-მა შაბლონები ფონურ ნაკადში ნატიურ კოდში კომპილაცია დაიწყო და კომპილაციის დასრულებისას გადაერთო: 2x–4x სიჩქარე რამდენიმე გრძელ და მარტივ შაბლონზე, ხოლო დაახლოებით 7% მოგება holdout-შაბლონებზე, სადაც ნატიური გზა გამოიყენება — იმ ფასად, რომ მოკლე შაბლონები ნელდება.

ერთ სამუშაო დატვირთვაზე მორგებული პროგრამები

მარკ ბრუკერმა ეს ტენდენცია FFTW-სა და დემოსცენის ხრიკებს შეადარა — კოდს, რომელიც ერთ კონკრეტულ ამოცანაზეა მორგებული და არა ამოცანათა კლასზე — და იწინასწარმეტყველა მეტი „დინამიურად მორგებული პროგრამული უზრუნველყოფა“. pgrust-ზე მომუშავე მაიკლ მალისი ამატებს: მემი იმის შესახებ, რომ „კოდის წერა არასდროს ყოფილა რთული ნაწილი“, მხოლოდ ზოგ სფეროში მართალია — JIT-კომპილატორები იშვიათია, რადგან მათი დაწერა ძალიან ძვირი იყო, ხოლო მონაცემთა ბაზები ისტორიულად ყველაზე რთული პროგრამები იყო. ლუ თავად მუშაობდა BitFunnel-ზე, ბინგის საძიებო ინდექსზე, რომელმაც SIGIR-ის საუკეთესო სტატიის ჯილდო მიიღო; ბინგის ვერსიაში რამდენიმე JIT-კომპილატორია — მასშტაბი, რომლისთვისაც „შაბათ-კვირაში გავაკეთებდი“ ახლა ნამდვილად მართალია.

რა არ იცვლება

ლუ ზღვრებსაც ასახელებს. ოპტიმიზაციებს, რომლებიც შედეგს ცვლიან, საჭიროა საზომი სისტემა, და თანამედროვე მოდელები ექსპერიმენტის დიზაინში სუსტია — ამიტომ შეფასების ჩარჩო ჯერ კიდევ ადამიანმა უნდა ააწყოს. რჩება ზედმეტი მორგების რისკიც: კონკრეტულ დატვირთვაზე მორგებული ოპტიმიზაცია ტყდება, როცა დატვირთვა იცვლება. აგენტი, რომელსაც უბრალოდ „ოპტიმიზაციას“ უხსენებ, ბევრ არასწორ რამეს გააკეთებს, რაც უნდა შეამჩნიოთ. მიუხედავად ამისა, ლუს დასკვნაა, რომ ნორმალური წარმადობა აღარ არის სპეციალიზებული უნარი — ის ღირსეული მოლოდინია ყველასთვის, ვინც კოდირების აგენტებს სერიოზულად იყენებს.