mold 2.0.0 - हाई-स्पीड linker

 (github.com/rui314)
4 पॉइंट द्वारा GN⁺ 2023-07-28 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • लाइसेंस AGPL से MIT में बदला गया, जो mold 2.0.0 का प्रमुख बदलाव है
  • --relocatable इस्तेमाल करने पर 65520 से ज़्यादा sections वाली object file नहीं बना पाने वाले bug को ठीक किया गया
  • -undefined को -u ndefined की बजाय --undefined के synonym के रूप में interpret किया जाता है, ताकि यह GNU linkers और LLVM lld के व्यवहार के अनुरूप हो
  • -nopie को --no-pie के synonym के रूप में handle किया जाता है
  • RISC-V पर R_RISCV_SET_ULEB128 और R_RISCV_SUB_ULEB128 relocation types का समर्थन
  • PPC64 पर R_PPC64_REL32 relocation type का समर्थन

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

1 टिप्पणियां

 
GN⁺ 2023-07-28
Hacker News की राय

  • mold आधुनिक सिस्टम्स पर सचमुच बेहतरीन काम है
    हाल में एक प्रोजेक्ट का build तेज़ करने की कोशिश करते हुए पता चला कि link step बहुत बड़ा bottleneck है। 24 core * 2 thread इस्तेमाल करने के बावजूद linker की वजह से कुल performance का करीब 30% idle पड़ा रहता है
    पहले mold से build करने की कोशिश की थी, लेकिन तब ठीक से नहीं हुआ था; फिर से कोशिश करने वाला हूं

    • Mold कमाल का है। कुछ महीने पहले O3DE के साथ काम करते हुए build-run cycle कम हो सकती है या नहीं देखने के लिए Mold पर switch किया था, और यह निश्चित रूप से तेज़ हुआ
      सटीक आंकड़े याद नहीं हैं, लेकिन gold और lld में जो चीज़ कुछ सेकंड लेती थी, mold में 1 सेकंड से कम में आ गई—काफी बड़ा फर्क था
    • कंपनी में भी हमने कुछ proof of concept किए, और एक छोटी test build machine पर UI layer का पूरा build time lld से mold पर बदलते ही 44–45 मिनट से घटकर 29 मिनट हो गया
      यह जटिल C++/Qt code था
    • mold -run ninja मेरे environment में बहुत अच्छे से काम करता है

  • license change की खबर देखकर बहुत खुशी हुई। उम्मीद है कि वे project से पैसा भी कमा पाएं, लेकिन MIT license होने पर इसे work projects में integrate करने की संभावना कहीं ज्यादा बढ़ जाती है
    अगर सच में इस्तेमाल करने लगे, तो मैं कंपनी को इस project को sponsor करने के लिए मनाने की कोशिश करूंगा

    • linker का license ज्यादा मायने नहीं रखना चाहिए। यह कोई copyrighted code inject नहीं करता, और GPL ecosystem में भी मामूली boilerplate को exception मानने की precedent पहले से है, इसलिए generated binary पर tool के copyleft license का असर पड़ने की वजह नहीं है
      AGPL भी शायद सिर्फ तब रोक लगाएगा जब privately modified linker को network service के रूप में distribute किया जाए, जो basic development tools के लिए कोई realistic scenario नहीं है

  • license change को लेकर उत्सुकता है। क्या यह executable नहीं है? अलग process के रूप में call करने से call करने वाले software को GPL बनाना जरूरी नहीं होता, इसलिए आम तौर पर MIT transition का असर नहीं होना चाहिए
    अगर authors सच में ज्यादा permissive license चाहते थे, तो AGPL से MIT में relicense करने के बजाय link exception वाले AGPL पर जाना चाहिए था। link exception वाले GPL project का उदाहरण libgit2 है https://github.com/libgit2/libgit2#license
    ऐसा license ज्यादा permissive भी होता, और private-source changes बनाने वालों को commercial license बेचने की गुंजाइश भी रहने देता

    • लगता है मूल बात यह है कि authors license sales जारी नहीं रखना चाहते। शायद झंझट की तुलना में उसका value कम था
      macOS version sold अपवाद लगता है

  • यह linker SeaORM और axum/tokio इस्तेमाल करने वाले, बड़े web monolith बनने की ओर जा रहे मेरे exploratory Rust repository में developer satisfaction को साफ तौर पर बढ़ाता है
    आप मेरी target directory का size जानना नहीं चाहेंगे, लेकिन incremental builds कहीं ज्यादा हल्के-फुल्के हो गए हैं

    • mold को थोड़ा आज़माना पड़ेगा
      15:55 $ du -Hs --si target/
      11G target/

  • Mold शानदार है, और इसके कुछ पसंदीदा use cases हैं

    1. Rust builds तेज़ हो जाते हैं
      [target.x86_64-unknown-linux-gnu]
      linker = "clang"
      rustflags = [
      "-C", "link-arg=-fuse-ld=mold",
      "-C", "target-cpu=native"
      ]
    2. ArchLinux पर CFLAGS में "-fuse-ld=mold" जोड़ने से makepkg भी तेज़ हो जाता है
    • क्या इस linker setting को सिर्फ local install में override करने का कोई तरीका है? production code या binaries बदलना नहीं चाहता, लेकिन build तेज़ हो जाए तो अच्छा होगा
    • Rust link time पहले और बाद में कितना बदला, यह जानना चाहूंगा
    • यह latest release lld की तुलना में कैसा है? क्या यह alpine/musl पर भी चल सकता है?

  • बहुत समझदारी भरा फैसला है। मेरे product या code में भी कभी-कभी यह मानने के कठिन पल आते हैं कि कुछ चीज़ें monetization के लिए fit नहीं हैं
    market बता देता है, और दुर्भाग्य से उससे लड़ने के बजाय market जिन दूसरी चीज़ों को reward करता है, उन्हें ढूंढना जरूरी है

  • क्या किसी को पता है कि यह license/business strategy change sold पर भी लागू होने वाला है? sold macOS के लिए mold है
    https://github.com/bluewhalesystems/sold

    • Apple के पास नया parallel linker है, जिसमें आपकी दिलचस्पी हो भी सकती है और नहीं भी
      https://twitter.com/davidecci/status/1665835119331135488
    • mold README के सबसे ऊपर देखकर, मेरा अनुमान है कि यह open source नहीं होगा
      “इस repository में mold linker का free version है। अगर आप macOS support करने वाला commercial version ढूंढ रहे हैं, तो sold linker repository देखें।”
    • समझ नहीं आता कि Apple इस project को sponsor करके इसे Xcode default linker क्यों नहीं बना देता
      काम के बदले अच्छा-खासा पैसा दे और दुनिया को बेहतर बना दे
      Apple के लिए तो यह बहुत आसान काम होना चाहिए

  • license AGPL से MIT में बदल गया
    लेकिन ऐसे बेहतरीन कारीगर को compensation कैसे मिलना चाहिए, और अभी तक ऐसा क्यों नहीं हो रहा? लगता है companies को size की परवाह किए बिना core dependencies या tools के लिए कुछ budget allocate करना चाहिए और इसे official website पर public करना चाहिए। एक तरह के cultural norm की और जरूरत दिखती है

  • मैं भूल गया था कि यह एक तेज़ linker था
    “Mold 2.0.0 हमारे तेज़ linker का नया major release है. इस release में user base बढ़ाने के लक्ष्य से हमने license को AGPL से MIT में बदल दिया है. जिन्होंने हमारी प्रगति देखी है, वे जानते होंगे कि यह आसान फैसला नहीं था, क्योंकि हम AGPL/commercial license के dual-license तरीके से product को monetize करने की कोशिश करते रहे थे. दुर्भाग्य से यह approach उम्मीदों पर खरी नहीं उतरी. license बदलना इसी वास्तविकता को स्वीकार करने का परिणाम है. हम ऐसी strategy पर अड़े नहीं रहना चाहते जो ठीक से काम नहीं कर रही थी.”

    • क्या किसी को वे दिन याद हैं जब Solaris पर cc cost चुकानी पड़ती थी? https://unix.stackexchange.com/questions/12731/usr-ucb-cc-la...
      वह भयानक था, और अपने OS के लिए software लिखने वाले developers के साथ व्यवहार करने का भी बेहद खराब तरीका था
      हम बहुत लंबे समय से low-level development tools के लिए पैसे न देने, और इसके बजाय support cost देने के आदी रहे हैं. इस तरह license आज़माया गया, यह अपने आप में हैरानी की बात है

  • लंबे समय से तेज़ linkers पर चर्चाएँ और यह कहानियाँ कई बार देखीं कि एक linker को तेज़ वाले से बदलने पर compile time काफी घट गया, लेकिन आम तौर पर यह ठीक से नहीं पता था कि linker धीमा क्यों होता है
    अच्छा होगा अगर कोई समझा सके

    • पूरा explanation नहीं है, लेकिन linking CPU-intensive होती है और पुराने linkers ज़्यादातर single-threaded होते हैं
      performance gain का बड़ा हिस्सा काम को parallel में process करने से आता है, और आधुनिक powerful multicore CPUs पर इससे बड़ा improvement मिलता है
      अगर और जानना हो तो Rui की Mold पर एक अच्छी talk है: https://www.youtube.com/watch?v=hAt3kCalE0Y
    • ideal case में linker cat जितना तेज़ होना चाहिए. binaries को जोड़ना है और काम खत्म. rotating disk के दौर में disk I/O समस्या था, लेकिन अब कम है
      समय उस हिस्से में लगता है जहाँ चलते-चलते contents को rewrite किया जाता है. relocation table से गुजरकर code में addresses डालना सस्ता है, और section-level dead stripping भी काफी सस्ती है, लेकिन function के अंदर अलग-अलग basic blocks को dead-strip करने के लिए कहीं ज़्यादा analysis चाहिए, इसलिए समय लगता है
      constant string deduplication अच्छा idea है, लेकिन सब कुछ किसी न किसी रूप की hash table में डालना पड़ता है. अगर common suffixes भी share करवाना चाहते हैं, तो काम और बढ़ जाता है
      deduplication, dead stripping, और debug info rewriting में भी समय लगता है. debug builds में कई GB DWARF हो सकता है जिसे rewrite करना पड़े
      दिलचस्प बात यह है कि linker का scriptable होना, यानी interpret करने के लिए program पास कर पाना, बड़ा cost नहीं लगता. शायद इसलिए कि वे scripts काफी छोटे होते हैं और उनकी functionality भी कुछ हद तक सीमित होती है
      ऐतिहासिक रूप से lld बहुत तेज़ इसलिए था क्योंकि वह debug info processing या दूसरी deduplication ज्यादा नहीं करता था. lld तेज़ चलता था, लेकिन output binary बड़ी होती थी
      link performance पर काम छोड़े मुझे कई साल हो गए, इसलिए मौजूदा स्थिति अच्छी तरह नहीं पता. खासकर यह नहीं पता कि mold या lld output quality और अपनी performance के बीच कहाँ खड़े हैं
    • मैंने जो सबसे अच्छा material पढ़ा, वह Ian Taylor का gold linker पर अपने काम के बारे में लिखा blog था
      https://www.airs.com/blog/archives/38
      “फिर से कहूँ तो लक्ष्य speed है. इस मामले में, मेरे दूसरे linker से भी तेज़ होना. वह linker ELF और shared library support जुड़ने के बाद वर्षों में काफी धीमा हो गया था. यह support शुरू से design नहीं किया गया था, बल्कि बाद में जोड़ा गया था. नए linker की future plans में incremental linking support भी शामिल है, जो speed बढ़ाने का एक और तरीका है.”
      शुरुआती Unix दौर के apps को याद करें. सरल single-purpose app, शायद एक source file, एक object, सिर्फ libc से link करना होता था, और shared libraries जैसी कोई चीज़ नहीं थी
      बाद में “ज़रूरी” features जुड़ते गए और linker code organically बढ़ता गया. खासकर उस दौर में जब rotating disks bottleneck थे, speed से ज़्यादा feature correctness महत्वपूर्ण थी