FFmpeg डेवलपर्स का दावा, खुद लिखे गए assembly code से 100x तक की speedup

 (tomshardware.com)
6 पॉइंट द्वारा GN⁺ 2025-07-21 | 3 टिप्पणियां | WhatsApp पर शेयर करें
  • FFmpeg डेवलपर्स ने खुद लिखे गए assembly code के जरिए अधिकतम 100x performance improvement का ऐलान किया
  • यह patch पूरे प्रोग्राम पर नहीं, बल्कि सिर्फ एक खास function में speedup देता है
  • नवीनतम CPU में AVX512 support होने पर 100x तक, और AVX2 support पर 64% performance improvement देखा गया
  • यह improvement मुख्य रूप से कम चर्चित filters पर लागू किया गया है
  • compiler की automatic optimization और हाथ से लिखे गए assembly code के बीच performance gap अब भी साफ दिखता है

FFmpeg की performance improvement: 100x speedup का असली मतलब

नवीनतम patch और मुख्य सुधार

  • FFmpeg प्रोजेक्ट के डेवलपर्स ने हाथ से लिखे गए assembly code को लागू करने के बाद इस open source cross-platform media transcoding tool में "100x speedup" जैसी उपलब्धि को रेखांकित किया
  • लेकिन डेवलपर्स ने यह भी साफ किया कि यह दावा पूरे FFmpeg पर नहीं, बल्कि एक single function पर लागू होता है
  • rangedetect8_avx512 function में यह असाधारण optimization की गई, और नवीनतम AVX512 support वाले processors पर अधिकतम 100x तक, जबकि AVX2 path पर लगभग 64% performance improvement मिली
  • यह feature एक कम-ज्ञात filter पर लागू की गई है, जिसे पहले development priority नहीं मिली थी, लेकिन अब SIMD (single instruction, multiple data) तरीके से parallel processing optimization हासिल की गई

डेवलपर्स की व्याख्या और तकनीकी पृष्ठभूमि

  • FFmpeg डेवलपर्स ने Twitter पर साफ लिखा कि "यह एक function 100x तेज हुआ है, पूरा FFmpeg नहीं"
  • अतिरिक्त विवरण में उन्होंने कहा कि सिस्टम के अनुसार यह feature 100% तक speedup भी दे सकती है
  • यह performance improvement SIMD technology के आधार पर आधुनिक chips में parallel processing efficiency को काफी बढ़ाने का नतीजा है

assembly language को हाथ से लिखने का महत्व

पहले और अब के optimization approaches

  • 1980~1990 के दशक में सीमित hardware environment में हाथ से लिखे गए assembly code गेम्स और विभिन्न software की speed बढ़ाने का अहम तरीका हुआ करता था
  • आज ज़्यादातर modern compilers high-level language code को assembly में बदल देते हैं, लेकिन compiler optimization की सीमाएँ, जैसे register allocation, की वजह से हाथ से लिखे गए assembly code से अब भी बेहतर performance मिलती है
  • FFmpeg उन कुछ projects में से एक है जो इस optimization philosophy पर कायम हैं, और यह अपना assembly tutorial भी चलाता है

FFmpeg का ecosystem impact

  • FFmpeg की libraries और tools Linux, Mac OS X, Microsoft Windows, BSD, Solaris सहित कई environments में चलते हैं
  • VLC जैसे लोकप्रिय video players भी FFmpeg की libavcodec, libavformat libraries का इस्तेमाल करते हैं
  • इस तरह व्यापक open source media encoding/decoding ecosystem में FFmpeg का तकनीकी महत्व काफी बड़ा है

समापन

  • यह performance improvement पूरे core functionality की बजाय कुछ functions तक सीमित है, लेकिन यह performance limit को आगे बढ़ाने का उदाहरण है
  • modern hardware-specific optimization और open source spirit के मेल से FFmpeg media processing क्षेत्र में तकनीकी मिसाल पेश करता रहा है

संबंधित पढ़ाई

3 टिप्पणियां

 
bobcat 2025-07-24

यह बात पहले भी सही थी और आज भी सही है
इसी तरह, जब codec library को ARM पर port कर रहा था, तो SSE में लिखे kernel को एक-एक करके खोलने से शुरुआत की थी, और सब कुछ खोलकर केवल scalar बचा रहने की स्थिति में जब real-world benchmark चलाया, तो performance का अंतर meaningful था
 
aer0700 2025-07-23

Gcc से भी ज़्यादा optimized code लिख सकने वाले engineer... वाकई कमाल है।
 
GN⁺ 2025-07-21
Hacker News की राय

  • मैंने 10 साल तक HEVC वगैरह के SIMD optimization पर काम किया है, और assembly version और सामान्य C version की तुलना करना लगभग मज़ाक जैसा था, क्योंकि अक्सर 100x जैसे बहुत बड़े नंबर निकलते थे। असल में ऐसे नतीजे यह भी दिखाते हैं कि शुरुआती implementation बेहद inefficient थी। वास्तविक उपयोग में माहौल microbenchmark जैसा नहीं होता, जहाँ cache पूरी तरह भरी हो और वही function लाखों बार लगातार call हो। इसके बजाय, असली स्थिति में यह कई दूसरे कामों के बीच सिर्फ एक बार call हो सकता है। Cache effect कम करने के लिए बहुत बड़ा test memory region बनाकर test करना चाहिए, लेकिन सच में ऐसा किया जाता है या नहीं, इस पर संदेह है

    • यह भी जानना दिलचस्प होगा कि FFmpeg जैसे video conversion software अलग से "macro benchmark" भी चलाते हैं या नहीं। लगता है कि performance, quality, CPU usage वगैरह को लंबे समय तक कई videos और conversion combinations पर measure किया जाता होगा, और उसके लिए dedicated, consistent hardware चाहिए होगा

    • थोड़ा अलग दिशा का सवाल है, लेकिन आप SIMD में अनुभवी लगते हैं, इसलिए पूछना चाहता हूँ: क्या आपने ISPC इस्तेमाल किया है, और उसके बारे में आपकी क्या राय है? आज भी direct SIMD code लिखना पड़े और general compiler की auto-vectorization इतनी कमजोर हो, यह थोड़ा अजीब लगता है। GPU kernel में तो बहुत पहले से हमेशा auto-vectorization जैसा व्यवहार मिलता रहा है, उसके मुकाबले यह अलग लगता है

    • मेरा मानना है कि ffmpeg खुद भी microbenchmark से बहुत अलग नहीं है। मूल रूप से इसकी structure while (read(buf)) write(transform(buf)) जैसी ही है

    • अफसोस की बात है कि cache issue के अलावा भी, developers कभी-कभी 100% speedup कहते हैं जबकि असल में वह बहुत सीमित filter पर लागू होता है। फिर भी, जानकारी काफ़ी transparent तरीके से दी जाती है

    • "शुरुआत में inefficient था" वाली व्याख्या के बारे में, मेरा मानना है कि कौन-सा number निकलता है, यही महत्वपूर्ण है; परिणाम अपने आप में अहम है

  • लेख में कुछ जगह 100x लिखा है और कुछ जगह 100% speedup, इसलिए भ्रम हो रहा है। उदाहरण के लिए, "‘rangedetect8_avx512’ performance 100.73% बढ़ी" लिखा है, जबकि screenshot में 100.73x दिख रहा है। अगर 100x है तो वह 9900% increase है, और 100% speed increase का मतलब 2x तेज़ होना है। असल में सही क्या है, यह जानना चाहता हूँ

    • Screenshot में जैसा दिख रहा है, साफ़ तौर पर 100x (या 100.73x) ही सही है, जिसका मतलब 9973% speed increase है। लगता है लेख के मुख्य भाग में % notation गलत इस्तेमाल हुई है

    • Single function के हिसाब से 100x, पूरे filter के हिसाब से 100% (2x) है

    • ffmpeg की तरफ़ से दावा 100x का है। 100% शायद लेख की typo है

    • Function name का '8' से संबंध है, और अगर यह 8-bit values पर operate करता है, तो पहले की implementation scalar थी तो AVX512 के साथ एक बार में 128 elements तक process किए जा सकते हैं, इसलिए 100x speedup संभव लगती है

  • ffmpeg की ओर से assembly लिखने पर आधिकारिक guide भी है, इसलिए reference के तौर पर छोड़ रहा हूँ https://news.ycombinator.com/item?id=43140614

  • लेख में "rangedetect8_avx512" वास्तव में किस स्थिति में इस्तेमाल होता है और पूरे conversion process में real-time performance gain कितना होता है, यह स्पष्ट नहीं लगा। जानना चाहता हूँ कि क्या इसका सच में कोई दिखने वाला व्यावहारिक महत्व है

    • पहले, जब video signal analog हुआ करते थे, control signal को band के भीतर encode करके process किया जाता था। DVD के बाद भी digital signal analog में output होते थे, इसलिए 16 से नीचे के रंग मान (0~255 में) को "black से भी ज़्यादा black" signal के रूप में इस्तेमाल किया जाता था, और BluRay, HDMI में भी यही था। हाल के समय में पूरा 0~255 range इस्तेमाल करने की तरफ़ रुझान बदला है। लेकिन अब भी signal range की पहचान ठीक से न होने पर video अंधेरा और खराब दिख सकता है। लगता है यह function pixel values 16~255 हैं या 0~255, यह पहचानने के लिए है। अगर 16~255 होना पक्का हो, तो encoding के समय information बचाई जा सकती है। हालांकि यह मेरा अनुमान है। मैं भी पेशे से video काम करता हूँ, लेकिन black level handling में हमेशा गलती कर देता हूँ, यह मानने में शर्म आती है

    • यह filter conversion process में इस्तेमाल नहीं होता, बल्कि color range या alpha premultiplied है या नहीं जैसी metadata information detect करने के लिए इस्तेमाल होता है। जिस function की बात हो रही है, वह उनमें से color range पहचानने वाला हिस्सा है

  • एक दिलचस्प अनुभव साझा करना चाहता हूँ। मैंने assembly code सिर्फ SIMD की वजह से लिखा था। हाल ही में इस बारे में बात हुई तो याद आया कि उस समय assembly लिखना क्यों पड़ा था। असल में compiler aliasing issue की वजह से वैसी optimization नहीं कर रहा था जैसी मैं चाहता था। जब मैंने साफ़ बताया कि data को किसी दूसरे तरीके से access नहीं किया जाएगा, और non-standard keyword इस्तेमाल किया, तो compiler ने अपने आप SIMD instructions का उपयोग किया। आखिरकार मैंने खुद लिखा हुआ assembly हटा दिया

  • यह थोड़ा विडंबनापूर्ण है कि यह optimization सिर्फ x86/x86-64 (AVX2, AVX512) पर लागू होती है। एक समय था जब लगभग सब x86 इस्तेमाल करते थे, इसलिए SIMD optimization के व्यापक इस्तेमाल की संभावना थी, लेकिन नए extension architectures या तो अच्छे नहीं थे या compatibility कम थी। और अब जब बेहतर x86 SIMD आया है, x86 खुद standard platform नहीं रहा, इसलिए उस पर निर्भर होना कठिन हो गया है

    • AVX512 में कई extension sets हैं, इसलिए अगर सिर्फ base instructions का उपयोग न हो, तो हर CPU पर instruction support अलग हो सकता है। आधुनिक encoders की multi-threading performance बेहतर हुई है, लेकिन उसकी सीमाएँ भी हैं। पहले embedded project में SoC वाले video encoder compatibility issue से जूझना पड़ा था, तब ffmpeg चलाकर CPU के कई cores का उपयोग करते हुए बेहतर परिणाम मिले थे

  • सच कहूँ तो यह थोड़ा surprising था कि assembly, optimized C से भी तेज़ निकला। आजकल compilers इतने अच्छे हैं कि लगा था manually assembly लिखने से बस बहुत मामूली performance gain मिलेगा, लेकिन साफ़ हो गया कि मेरी सोच गलत थी। अब तय कर लिया है कि कभी न कभी assembly ठीक से सीखनी होगी

    • संबंधित patches देखने पर पता चलता है कि पुराना baseline (ff_detect_range_c) बहुत सामान्य scalar C code है, और speedup उसी operation के AVX-512 version (ff_detect_rangeb_avx512) से आया है। FFmpeg developers vector width से स्वतंत्र macros के साथ सीधे assembly लिखना पसंद करते हैं, लेकिन Intel intrinsics से भी इसे लगभग वैसा ही व्यक्त किया जा सकता है (आख़िरकार register allocation जैसी बातों का ही अंतर होगा, इसलिए व्यावहारिक अंतर बड़ा नहीं है)। असली बात यह है कि vectorization कितनी अच्छी हुई। आधुनिक compiler के लिए trivial न होने वाले loops की vectorization लगभग असंभव होती है, और तब भी वह gcc -O3 जैसे options देने पर ही कोशिश करता है। इसलिए 8-bit जैसे छोटे-unit operations में AVX/AVX2/AVX-512 से direct vectorization करने पर कम-से-कम कई दसियों गुना performance difference आता है। आधुनिक CPU पर बहुत carefully tuned scalar code कभी-कभी compiler से तेज़ लिखा जा सकता है, लेकिन यह बहुत rare है और इसके लिए dependency chains और execution port pressure जैसी चीज़ों पर बहुत ध्यान देना पड़ता है। मुझे खुद 40% speedup का अनुभव हुआ है। संबंधित links: baseline C, AVX512 version

    • अगर आप low-level optimization के और करीब जाते हैं, तो एक घंटे के भीतर ही C compiler के अजीब behavior के उदाहरण देखने लगेंगे। अगर code वास्तव में बेहद ज़्यादा बार call होता है, तो optimization issue सच में बहुत महत्वपूर्ण हो जाता है। उदाहरण: https://stackoverflow.com/questions/71343461/how-does-gcc-not-clang-make-this-optimization-deciding-that-a-store-to-one-str

    • सिर्फ SIMD intrinsics तक उतर आने पर भी compiler की तुलना में performance बहुत आसान तरीके से बढ़ाई जा सकती है। मैंने इस पर कई हिस्सों में एक guide भी लिखी थी https://scallywag.software/vim/blog/simd-perlin-noise-i

    • लगभग सभी C/C++ libraries के performance-critical हिस्सों में hand-written assembly इस्तेमाल होती है (यहाँ तक कि strlen जैसे simple functions में भी)। Compiler आम तौर पर ठीक-ठाक result देते हैं, लेकिन इतना निवेश सिर्फ कुछ ही ऐसे software के लिए जायज़ होता है जहाँ यह वाकई महत्वपूर्ण हो

    • वास्तविक speedup assembly की वजह से नहीं, AVX512 की वजह से है। यह kernel इतना simple है कि AVX512 intrinsics में लिखने पर C code और assembly के बीच फर्क लगभग नहीं होगा। 100x speed difference की वजह है: a) SIMD में min/max single instruction से हो जाता है, जबकि scalar में वह cmp+cmov में बँट जाता है b) 8-bit precision होने से हर AVX512 instruction एक साथ 64 values process करता है। नतीजतन L1, L2 cache bandwidth तक saturate की जा सकती है (Zen 5 के हिसाब से 128B, 64B/cycle)। लेकिन अगर पूरे frame को process किया जाए, तो memory size की वजह से L3 access करना पड़े तो यह लाभ आधा हो सकता है, और अगर L3 में भी fit न हो तो लाभ और कम होगा

  • Sound Open Firmware(SOF) याद आता है, जिसे gcc या commercial Cadence XCC compiler (Xtensa HiFi SIMD intrinsics support) में से किसी एक से build किया जा सकता है https://thesofproject.github.io/latest/introduction/index.html#toolchain-faq

  • यह 100x है, 100% x नहीं