फ़्रेम पॉइंटर्स की वापसी

फ़्रेम पॉइंटर्स के प्रदर्शन-सम्बंधी समझौते

• चर्चा किए गए मुख्य खर्च: एक कम सामान्य-उद्देश्य रजिस्टर (32-बिट x86 पर गंभीर, x86_64 और अन्य ISA पर मामूली) और अतिरिक्त प्रोलॉग/एपिलॉग निर्देश, जो छोटे, बार-बार बुलाए जाने वाले फ़ंक्शनों को बड़ा कर सकते हैं और I‑cache पर दबाव डाल सकते हैं।
• रिपोर्ट की गई धीमापन की मात्रा बहुत अलग-अलग है: कुछ को वास्तविक ऐप्स में लगभग 1–3% दिखा; Phoronix के एक परीक्षण में लगभग 14% ज्यामितीय औसत दंड बताया गया; kernel मापों में कुछ workloads के लिए 5–10% का उल्लेख है; जबकि अन्य आधुनिक toolchains के साथ distro-व्यापी “1% से कम” होने का दावा करते हैं।
• benchmark की गुणवत्ता पर असहमति: कुछ DB benchmarks को “microbenchmarks” कहते हैं, जबकि अन्य तर्क देते हैं कि वे यथार्थवादी end-to-end परीक्षण हैं। सहमति यह है कि प्रभाव workload-निर्भर है और इसे सार्वभौमिक रूप से नहीं कहा जा सकता।
• 32-बिट x86 को अभी भी विशेष रूप से रजिस्टर-तंगी वाला माना जाता है; कई अन्य architectures के लिए खोया हुआ रजिस्टर नगण्य समझा जाता है।

प्रोफाइलिंग, डिबगिंग, और FPs क्यों महत्वपूर्ण हैं

• बहुत से लोग भरोसेमंद, कम-overhead stack traces को CPU, memory, और खासकर off-CPU profiling तथा execution tracing के लिए आवश्यक मानते हैं।
• frame pointers के बिना, kernel perf को बड़े stack chunks कॉपी करने पड़ते हैं और बाद में unwind करना पड़ता है, जिससे CPU, memory, और disk overhead बढ़ता है और debug packages की आवश्यकता होती है।
• developers का तर्क है कि “बस FPs के साथ फिर से compile कर लो” अव्यावहारिक है जब पूरे systems और third-party libraries शामिल हों, और end-users से traces माँगना व्यावहारिक नहीं रहता।
• कुछ लोग बताते हैं कि बेहतर profiling ने वास्तविक software में >10–20% speedups दिए हैं, जो एक छोटे global FP overhead से आसानी से अधिक हैं।

DWARF और वैकल्पिक unwinding approaches

• DWARF/.eh_frame unwinding को flexible लेकिन जटिल और high-rate sampling या off-CPU profiling के लिए धीमा बताया गया है। perf का वर्तमान DWARF path विशेष रूप से महँगा है क्योंकि stack copying करनी पड़ती है।
• अन्य लोग दावा करते हैं कि DWARF को preload और cache करके तेज बनाया जा सकता है, और eBPF-based profilers की ओर इशारा करते हैं जो tables को कुशल in-kernel formats में बदलते हैं।
• JVM/JIT और अन्य high-level runtimes अभी भी कठिन बने हुए हैं: custom unwinding, mixed native/managed stacks, और भारी JIT activity DWARF-only समाधानों को fragile या scale पर बहुत महँगा बना देती है।

डिफ़ॉल्ट, distro नीतियाँ, और लागत कौन उठाए

• बहस इस पर केंद्रित है कि kernels, libc, और distro builds के लिए डिफ़ॉल्ट क्या होना चाहिए।
• एक पक्ष: FPs को globally सक्षम करें ताकि system-wide profiling “बस काम करे”, जिससे production releases का continuous optimization और post-hoc analysis संभव हो।
• दूसरा पक्ष: अधिकांश user कभी profiling नहीं करते; millions of devices और servers पर कुछ प्रतिशत की हानि energy और cost के लिहाज़ से महत्वहीन नहीं है; performance-sensitive code dev builds में ही FPs सक्षम कर सकता है।
• सुझावों में per-function attributes (कुछ caveats के साथ), अलग “dev” बनाम “end-user” libc builds, और source-based या Nix/Guix systems का उपयोग करके policy को system-wide toggle करना शामिल है।

सुरक्षा और architecture के विचार

• return addresses के लिए separate या shadow stacks को एक साफ़-सुथरा, अधिक सुरक्षित design माना गया है, लेकिन current hardware और ABI compatibility व्यावहारिक deployment को सीमित करती है।
• कुछ लोग alloca() पर प्रतिबंध लगाने का सुझाव देते हैं बजाय FP cost चुकाने के; अन्य जवाब देते हैं कि FPs कम से कम अभी deployable हैं, जबकि अधिक radical बदलाव नहीं।