Python 3.12 के लिए Windows SciPy बिल्ड को एक छोटा चमत्कार माना गया

• conda-forge का SciPy Windows बिल्ड Python 3.12.0 रिलीज़ होने के दो दिन बाद उपलब्ध हो गया, जिससे SciPy इकोसिस्टम का Python 3.12 migration कई महीनों तक अटकने के बजाय सिर्फ कुछ दिनों की देरी से आगे बढ़ सका
• Python 3.12 में distutils को standard library से हटाए जाने के बाद, SciPy ने numpy.distutils की जगह Meson build tool पर migrate करने का फैसला किया
• Meson आगे चलकर conda-forge द्वारा इस्तेमाल किए जा रहे MSVC+gfortran संयोजन को अस्वीकार करने वाला था, और Windows पर conda-forge के उपयोग के लिए कोई मुफ्त ABI-compatible Fortran compiler उपलब्ध नहीं था
• conda-forge ने अनुमान लगाया कि अगर वह Windows पर SciPy को दोबारा build नहीं कर पाया, तो SciPy पर निर्भर कम से कम 1,000 पैकेजों का migration सभी platforms पर देरी का शिकार होगा, या फिर Python migration में Windows को बाहर रखना पड़ेगा
• LLVM 17.0, Flang का वह पहला release था जिसमें -flang-experimental-exec फ्लैग हटा दिया गया था, और Flang की परिपक्वता का स्तर लगभग “0.8 level maturity” माना गया
• Meson में llvm-flang handling जोड़ने के बाद SciPy का build और install सफल रहा, और tests में 54,987 passed, 2,866 skipped, 245 xfailed, 11 xpassed, 1 warning के साथ 100% पास दर मिली {p:100}

[GN⁺]

Hacker News की राय

• वाकई शानदार लेख था, और अब समझ आया कि Python 3.12 में pip install क्यों fail हो रहा था, लेकिन आगे की राह ज़्यादा उजली लगती है
  मुझे Python पसंद है, लेकिन इससे यह समझने में भी मदद मिली कि Python packaging आखिर manage करने लायक अफरातफरी क्यों है
  वजह खुद Python नहीं, बल्कि C/C++/Fortran build tools का non-standard होना और ecosystem का विशाल आकार है; कुछ हद तक यह ऐसी complexity है जिसे कम नहीं किया जा सकता
  इसका चल पाना ही लगभग किसी चमत्कार जैसा है

  • सही है, Python packaging के complex होने की मूल वजह वहीं है
    Python की सफलता काफी हद तक इसलिए रही कि वह अहम mixed-language packages इस्तेमाल कर सका, और दूसरे mainstream language package managers ऐसे मुद्दों से शायद ही निपटते हैं
    उदाहरण के लिए Rust का cargo शानदार है, लेकिन वह अधिकतर Rust-only code की packaging मानकर चल सकता है; और compiled language होते हुए भी भाषा compiler को “own” करती है, इसलिए source build distribution strategy काम करती है
    cargo Fortran को default रूप से कैसे handle करता है, यह मुझे नहीं पता, लेकिन अगर Windows पर top-level cargo packages को Fortran code चाहिए हो, तो शायद वह अच्छी तरह नहीं चलेगा
    Python ecosystem में सबसे बड़ा सुधार binary package format wheel का standardization था, और तभी scientific Python ecosystem Windows पर सच में फलना-फूलना शुरू हुआ
    हालांकि binary compatibility, खासकर languages और CPU architectures के पार, जबरदस्त सिरदर्द है
  • इसे Python से असंबंधित कहना मुश्किल है, क्योंकि ऐसी FFI bindings मौजूद होने की वजह यही है कि Python बहुत slow है
  • “इसका चल पाना ही चमत्कार है” वाली बात से सहमत हूं
    software ecosystem की complexity जैसे exponential तरीके से बढ़ती दिखती है, और मैं सोचता हूं कि आखिर क्या चीज इसे Tower of Babel जैसी collapse की ओर जाने से रोकती है
    बेशक यह समस्या सिर्फ software तक सीमित नहीं है, लेकिन यह अच्छा उदाहरण है
  • सच में आंखें खोल देने वाला लेख था
    अक्सर लोग अपने पसंदीदा package manager की तुलना Python वाले से करते हैं और निष्कर्ष निकालते हैं कि Python बहुत खराब है, जबकि असल में ऐसा नहीं है
    बस एक बात समझ नहीं आती कि Python वाले Fortran के बजाय C/C++ math libraries क्यों नहीं इस्तेमाल करते
  • असली समस्या शायद यह है कि Python में software development की training न पाए हुए लोग आकर्षित होते हैं
    यानी अफरातफरी के ऊपर और अफरातफरी जमा हो गई है

• जब Linux एक चरमराता हुआ fringe case था, जिसे loosely coordinated hackers कभी-कभी अव्यावहारिक ideological constraints के साथ चला रहे थे, तब बेहतरीन लोगों द्वारा उसमें support जोड़ने के लिए भारी मेहनत करना शानदार लगता था
  लेकिन अब वही चरमराता fringe case ऐसे proprietary systems बन गया है जिनकी constraints की प्रकृति लगभग hostility जैसी है और जिन्हें cyber landlords चला रहे हैं; ऐसे में उसे support करने का काम पहले जितना सकारात्मक देख पाना मुश्किल है
  एक ओर, इन tools को सभी के लिए usable बनाने की गहरी परवाह सचमुच शानदार है, और मैं उस काम की सराहना करता हूं
  मैं दिशा बदलने को बिल्कुल नहीं कह रहा, बस यह सोचने पर मजबूर करता है
  पहले मैं सोचता था, “वाह, कितना अच्छा है कि यह काम हो रहा है”; अब ज़्यादा यह सोचता हूं, “वाह, वे शानदार लोग अगर इस काम में न अटके होते तो क्या हासिल कर पाते”

  • दरअसल यह ऐसा काम नहीं है जो उन्हें करना ही पड़े
    जैसा कई बार कहा गया है, SciPy developers volunteers हैं
    कहानी का बड़ा हिस्सा यह समझाता है कि SciPy को Windows के लिए open-source Fortran compiler किसी के बनाने की उम्मीद क्यों करनी पड़ी, और लगता है कि बचाव मुख्य तौर पर NVIDIA developers ने किया
  • वह भी मूल बात नहीं है
    SciPy, Python core developers के उस मूर्खतापूर्ण और बहुत पक्षपाती फैसले की कीमत चुका रहा है जिसमें उन्होंने Windows पर Python के toolchain के लिए MinGW के बजाय MSVC चुना
    मेरी राय में इसकी प्रेरणा Microsoft sponsorship से आई
    core developers की list में काफी Microsoft employees हैं, जिन्हें Microsoft उस list में शामिल रहने के लिए भुगतान करता है, और ऊपर से Microsoft CPython project के CI servers का खर्च भी उठाता है
    अगर Python ने toolchain में proprietary tools इस्तेमाल नहीं किए होते, तो यह पूरी समस्या टाली जा सकती थी

• “Meson conda-forge में इस्तेमाल होने वाले MSVC+gfortran कॉम्बिनेशन को अस्वीकार करने की कोशिश कर रहा था” — यह bug जैसा लगता है
  बिल्ड टूल का उद्देश्य दिए गए command चलाना है, “माफ़ कीजिए Dave” कहकर रोकना नहीं

  • असल में शिकायत करने वाला हिस्सा MSVC linker है
    समस्या यह है कि MSVC और gfortran जिन C runtime का इस्तेमाल करते हैं, खासकर gfortran की अपनी runtime library जो C में लिखी गई है, वे ABI-compatible नहीं हैं
    NumPy ने जो workaround इस्तेमाल किया था, वह Fortran objects को DLL के रूप में link करके import library नाम की एक indirect layer जोड़ना और इस तरह MSVC को संतुष्ट करना था
    इसलिए ऐसे DLL बनाने के लिए अतिरिक्त काम चाहिए था
    यह build description file में किया जाए या Meson में, करना तो पड़ता ही; लेकिन SciPy पक्ष इनमें से किसी भी जगह यह indirect layer implement नहीं करना चाहता था, और Meson developers भी सक्रिय रूप से मदद नहीं करना चाहते थे
    बेशक Meson developers ने Fortran और Cython support जैसी सामान्य मदद दी, लेकिन वे कोई जोखिमभरा सहारा नहीं देना चाहते थे
    वास्तव में यह hack के काफी करीब था; उदाहरण के लिए, यह सिर्फ इसलिए काम करता था क्योंकि Fortran side Python/C side से खोली गई files का इस्तेमाल नहीं कर रहा था
    https://web.archive.org/web/20180711144501/https://pav.iki.f...
  • लेख अच्छा और विस्तार से लिखा गया था, लेकिन Meson “C और C++ projects में व्यापक रूप से इस्तेमाल होता है” वाले दावे पर मुझे थोड़ा आश्चर्य हुआ
    निजी तौर पर मैंने Meson से ज्यादा Bazel को देखा है
    Meson Python में लिखा है, इसलिए शायद SciPy के लिए अच्छा विकल्प लगा होगा, और आखिरकार चीजें ठीक रहीं तो बधाई की बात है
    फिर भी कई अजीबताओं, जटिलताओं और समस्याओं के बावजूद CMake अब भी standard के करीब लगता है
  • Meson सिर्फ user द्वारा बताए गए commands चलाने से ज्यादा करता है
    यह MSVC/gcc/clang को support करने के लिए commands खुद compose भी कर सकता है
    अगर आप किसी अज्ञात combination के लिए command compose करने को कहेंगे, तो जाहिर है उसे “माफ़ कीजिए Dave” कहना पड़ेगा
  • सहमत हूं
    यह बता दूं कि मैं जल्द release होने वाले Meson competitor build system का author हूं
    लेकिन [1] वह कम-ज्ञात, छोटे रत्न जैसा rant है जिसने मुझे अभी कही बात समझाई
    सार यह है कि build system को वही commands चलाने चाहिए जो user ने चलाने को कहा है, बस
    क्योंकि कभी-कभी programmer सच में जानता है कि वह क्या कर रहा है
    शर्म की बात है, लेकिन वह comment पढ़ने से पहले मैं अपने build system को magical बनाने की सोच रहा था
    पर वह comment पढ़ने के बाद मुझे समझ आया कि लोग build systems से नफरत करते हैं तो वजह वही “magic” है
    [1]: https://ofekshilon.com/2016/08/30/cmake-rants/#comment-29273

• मुझे लगा था ऐसे मामलों में सब WSL2 इस्तेमाल करके बात खत्म कर देते हैं
  native Windows version build करने की जरूरत आखिर क्यों है?

  • यह macOS developers से यह पूछने जैसा है कि native build क्यों चाहिए, Linux virtual machine में काम कर लो न
    virtual machine में काम करना असुविधाजनक है और integration भी कमजोर होती है
  • उम्मीद से कहीं ज्यादा researchers Windows इस्तेमाल करते हैं
    students भी
  • बड़ी कंपनियां, जहां Windows के अलावा कोई machine मिलना लगभग असंभव है, शायद महत्वपूर्ण user base हैं
  • Microsoft और NVIDIA ने WSL2 की CUDA driver समस्या हल कर दी, यह सच में बड़ी राहत थी
    खासकर जब उसके ऊपर Docker Desktop इस्तेमाल किया जा सके
    non-ideal स्थिति में यह best possible निकालने जैसा है

• καταστροφή में κατα का मतलब “अचानकपन” नहीं, बल्कि “नीचे की ओर” या “के अनुसार” जैसा है, और इसमें गलत दिशा में मुड़ने का संकेत मजबूत है
  κατα का विपरीत आम तौर पर ανα है, लेकिन αναστροφή का शाब्दिक अर्थ “ऊपर की ओर घूमना” या reversal है
  इसलिए “अच्छे turn” के अर्थ में ευστροφη, यानी eustrophe, शायद बेहतर गढ़ा हुआ शब्द हो सकता है
  फिर भी अगर JRR Tolkien से भाषा-निर्माण पर बहस करके जीत जाएं, तो वह ευκαταστροφη, यानी सौभाग्य ही होगा
  कुल मिलाकर, प्रचुर grace को पकड़ने वाली बात अच्छी लगी, और ऐसी चीज दुनिया में खुशी और सुख लाती है

  • katastrofi में kata असल में “against” के करीब है, इसलिए katastrofi किसी चीज के “पीठ फेरने” जैसा है

• मेरा impression है कि सबसे अच्छे BLAS ज्यादातर C में हैं
  MKL, BLIS, OpenBLAS जैसी चीजें
  सोचता हूं C और Python भर से कितनी दूर तक जाया जा सकता था
  यह भी सोचता हूं कि अगर आज शुरू करते तो शायद सीधे libflame चुनते
  बेशक SciPy में iterative methods, sparse matrices आदि कई दूसरे features भी हैं, इसलिए Fortran से बचना मुश्किल हो सकता है
  फिर भी Fortran एक शानदार language है, और खुशी है कि Windows पर tooling की स्थिति कम से कम सुधरनी शुरू हुई है

  • SciPy से Fortran हटाने पर कुछ बार चर्चा हुई थी, लेकिन ऊपर बताए कारणों से बात आगे नहीं बढ़ी
    SciPy में खुद भी काफी Fortran code है, और उसे फिर से लिखने के लिए कई वर्षों का manpower चाहिए
    संभव होने के बाद Fortran का इस्तेमाल करने वाले कुछ core parts हटाए भी गए
    उदाहरण के लिए FFT से जुड़े हिस्से
  • सच कहूं तो 2023 में “Fortran एक शानदार language है, और खुशी है कि Windows पर tooling की स्थिति सुधरनी शुरू हुई है” जैसा वाक्य देखने की उम्मीद नहीं थी

• शानदार लेख
  इस साल मैंने Python bindings वाले CMake C++ project को modernize करने में काफी समय लगाया, और उसे नए feedstock के रूप में conda-forge में सफलतापूर्वक जोड़ने के बाद मैं पूरे confidence से कह सकता हूं
  अगर मैं god-emperor बना, तो IT से जुड़ा मेरा पहला कदम सभी universes से Windows को हमेशा के लिए जड़ से खत्म करना होगा

• यह बहुत भोला सवाल है, लेकिन क्या Fortran semantics इतने अलग हैं कि पहले उसे C में बदलकर फिर C compiler से compile नहीं किया जा सकता?
  उसके बाद क्या उसे C में maintain भी नहीं किया जा सकता?
  ऐसा नहीं लगता कि इतनी पुरानी libraries maintain करने वाले Fortran लोग बहुत होंगे, फिर भी maintenance तो चाहिए ही न?

  • अगर धीमा होना ठीक है, तो संभव है
    Fortran में pointers नहीं होते और सिर्फ arrays होते हैं, और function arguments aliases नहीं रख सकते, इसलिए COMMON blocks की भयावहता को फिलहाल अलग रखें तो aggressive optimization और vectorization आसान हो जाता है
    standard Fortran math libraries बस ठीक से काम करती हैं और तेज़ होती हैं
    C/C++ में भी, खासकर C के restrict keyword का उपयोग करके, बराबर speed वाला code लिखा जा सकता है
    लेकिन मौजूदा code को f2c step से convert करने पर कई मामलों में performance काफी खराब हो जाती है
  • Fortran, C से ज़्यादा high-level language है
    Fortran developers भी पर्याप्त संख्या में हैं
    application development के लिए यह भयानक है, लेकिन वह Fortran का मुख्य क्षेत्र नहीं है
  • ऐसी चीज़ पहले से मौजूद है
    f2c दशकों से मौजूद है
  • सही है, Fortran में native arrays होते हैं

• एक छोटी-सी जिज्ञासा है: मेरी जानकारी में aarch64 और arm64 एक ही चीज़ हैं
  क्या मेरी समझ गलत है?

  • एक ही हैं, लेकिन पहले backend तरफ दो competing LLVM implementations थीं
    [1] https://www.phoronix.com/news/MTY5ODk
  • ज़रूरी link: https://lkml.org/lkml/2012/7/15/133
  • Python में मेरी नज़र में aarch64 आमतौर पर Linux को दर्शाता है, और arm64 आमतौर पर macOS ARM को
    नाम अलग क्यों हैं, यह समझने लायक मैं इस क्षेत्र को अच्छी तरह नहीं जानता

• Python के build system बदलावों का पीछा करना वाकई मुश्किल है
  Windows पर performance numbers भी जानने की उत्सुकता है
  हालांकि प्राथमिक तौर पर शायद यह महत्वपूर्ण न हो
  क्योंकि गंभीर काम शायद Linux machine पर ही चलेगा

  • शुक्र है, अब लगता है बदलाव धीमे पड़ेंगे
    बड़ा transition यह था कि सभी से PEP 517 अपनवाया जाए, खासकर पुराने Setuptools projects को transition कराना
  • pure CPU computation में Windows भी Linux जितना तेज़ है
    क्योंकि 99.9% समय operating system नहीं, बल्कि user code चल रहा होता है

[ahwjdekf]

यह तो binary compile होने वाली भाषाओं पर हमारी लाचारी को बहुत ही नंगा करके दिखाने वाला मामला है।

[kayws426]

क्या Python में तो समस्या हल हो गई, लेकिन दूसरे ecosystems में नहीं हो पाई? इसलिए ही शायद pre-built binaries उपलब्ध कराए जाते होंगे।