हाई-परफॉर्मेंस कंप्यूटिंग की कला

 (theartofhpc.com)
3 पॉइंट द्वारा GN⁺ 2023-12-31 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • The Art of HPC TACC के Victor Eijkhout द्वारा बनाई गई हाई-परफॉर्मेंस कंप्यूटिंग पाठ्यपुस्तक श्रृंखला है, जो scientific computing की बुनियाद से लेकर parallel programming और development tools तक को एक ही प्रवाह में जोड़ती है
  • पहली पुस्तक scientific computing की पृष्ठभूमि पर केंद्रित है, जिसमें यह बताया गया है कि computer architecture, arithmetic, linear algebra, और ODE/PDE बड़े पैमाने की गणना में कैसे एक-दूसरे से जुड़ते हैं
  • दूसरी पुस्तक MPI और OpenMP पर केंद्रित होकर parallel programming को समझाती है, और PETSc, Kokkos, Sycl, Co-array Fortran को भी संक्षेप में शामिल करती है
  • तीसरी पुस्तक scientific और engineering programming में उपयोग होने वाले C++17 और Fortran2008 को कवर करती है, और इसे शुरुआती पाठक तथा C प्रोग्रामर दोनों पढ़ सकते हैं
  • चौथी पुस्तक compiler, build system, और source code management जैसे वास्तविक HPC कार्य के लिए आवश्यक development workflow tools का परिचय कराती है

The Art of HPC पाठ्यपुस्तक संरचना

  • The Art of HPC TACC के Victor Eijkhout द्वारा बनाई गई हाई-परफॉर्मेंस कंप्यूटिंग पाठ्यपुस्तक श्रृंखला है
  • यह श्रृंखला scientific computing की पृष्ठभूमि, parallel programming, scientific programming languages, और HPC development ecosystem को अलग-अलग खंडों में विभाजित करके प्रस्तुत करती है

खंडवार दायरा

  • Volume 1: The Science of Computing

    • scientific computing को समझने के लिए आवश्यक सामान्य पृष्ठभूमि ज्ञान को कवर करता है
    • इसमें computer architecture, parallel computer architecture, computer arithmetic, linear algebra, और ODE/PDE शामिल हैं
    • यह बताता है कि प्रत्येक तत्व बड़े पैमाने की गणना में कैसे मिलकर काम करता है, और Volume 2 के साथ मिलकर HPC के “क्या/क्यों” और “कैसे” को पूरा करता है

  • Volume 2: Parallel Programming for Science and Engineering

    • यह खंड scientific computing में महत्वपूर्ण parallel programming पर केंद्रित है
    • इसमें आधुनिक संस्करणों के MPI और OpenMP का परिचय दिया गया है
    • PETSc, Kokkos, Sycl, और Co-array Fortran पर छोटे सेक्शन भी शामिल हैं
    • MPI और OpenMP को C, Fortran, और C++ में समझाया गया है, जबकि MPI में Python भी शामिल है

  • Volume 3: Introduction to Scientific Programming

    • scientific और engineering programming में व्यापक रूप से उपयोग होने वाले C/C++ और Fortran की पृष्ठभूमि के साथ, यह आधुनिक C++17 और Fortran2008 सिखाता है
    • इसमें C की तुलना में C++17 को प्राथमिकता देने वाला दृष्टिकोण अपनाया गया है
    • इसे शुरुआत से scientific programming सीखने वाली पुस्तक के रूप में भी, और C प्रोग्रामर के लिए C++ सीखने की पुस्तक के रूप में भी पढ़ा जा सकता है
    • इसमें कई लंबे programming projects शामिल हैं

  • Volume 4: HPC Carpentry

    • यह इस बात पर ध्यान देता है कि scientific computing ecosystem केवल programming languages और parallel programming systems से नहीं बनता
    • इसमें compiler, build system, source code management जैसे scientific workflow के लिए आवश्यक तत्वों का परिचय दिया गया है
    • यह हर चीज़ को समेटने वाली reference book से अधिक, scientific workflow के अनुरूप एक शुरुआती संकलन के करीब है

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

1 टिप्पणियां

 
GN⁺ 2023-12-31
Hacker News की राय

  • इस विषय का hardware/data center पक्ष भी उतना ही दिलचस्प है
    पहले मैं AWS में software/service साइड पर काम करता था, और कभी-कभी data center टीम की presentations चुपके से सुनने चला जाता था
    सबसे बड़ी समझ यह थी कि data center में computing क्षमता बढ़ाना असली computing से ज़्यादा thermodynamics की समस्या के करीब है। Node density इतनी बढ़ जाती है कि power देना और heat निकालना, और उसके ऊपर हर तरह की redundancy जोड़ना, बेहद कठिन हो जाता है। कोई inefficiency मिल भी जाए तो उसे software update की तरह ठीक नहीं किया जा सकता
    यह लगभग 10 साल पुरानी बात है, इसलिए अब कुछ चीज़ें बदली भी होंगी, लेकिन यह हैरानी की बात है कि internet bookstore के रूप में शुरू हुआ Amazon thermodynamics की समस्या सुलझाने की अग्रिम पंक्ति में है

    • Seymour Cray ने 1970s में ही कहा था कि सबसे बड़ी समस्या heat dissipation है
      Cray-2 में उन्होंने इससे भी ज़्यादा चरम तरीका अपनाया: घनी circuit board stacks को Fluorinert™ नाम के एक विशेष non-conductive liquid में डुबोने वाली cooling संरचना इस्तेमाल की गई थी: “The Cray-2's unusual cooling scheme immersed dense stacks of circuit boards in a special non-conductive liquid called Fluorinert™”
    • मैं हमेशा सोचता था कि data center में liquid cooling का ज़्यादा व्यापक इस्तेमाल क्यों नहीं होता
      पानी की heat capacity बहुत अधिक होती है, और यह optimal temperature तक तेज़ी से बड़ी मात्रा में cooling कर सकता है। जिन components में liquid cooling नहीं हो सकती, उनकी heat निकालने के लिए fan और air conditioning फिर भी चाहिए होंगे, लेकिन CPU या GPU/compute engine जैसे ज़्यादा power खाने वाले components में यह भारी मात्रा की heat को तेज़ी और सीधे तरीके से हटा सकता है
      leakage की complexity और risk समस्या तो होंगे, लेकिन Amazon के पैमाने के data center में यह इतनी बड़ी चिंता नहीं लगती
    • क्या इस समस्या के पैमाने को दिखाने वाला कोई अच्छा data या visualization material है?
      मैं जानना चाहता हूँ कि cutting-edge cooling technology कैसी दिखती है

  • जब HPC हार्डवेयर से काफ़ी abstracted दिखता है, तो यह दिलचस्प लगता है
    किताबें शायद SPMD programming, algorithm और data structure, task parallelism, synchronization वगैरह पर बहुत बात करती हैं, लेकिन computer architecture की details जैसे supercomputer memory subsystem, CXL जैसे high-bandwidth interconnect, GPU architecture पर कम सामग्री दिखती है
    यह जानने की जिज्ञासा है कि क्या abstraction और tools अब इतने अच्छे हो चुके हैं कि इन details की चिंता न करनी पड़े, या फिर HPC practitioners performance निकालने के लिए black-box knobs बहुत घुमाते हैं

    • ज़्यादातर HPC में hardware architecture और behavior की गहरी समझ के बिना parallelism और throughput को maximize नहीं किया जा सकता
      एक सामान्य सिद्धांत यह है कि बेहतर scalability के लिए software की topology को hardware की topology से जितना हो सके उतना मेल खाना चाहिए। प्रभावी HPC software पर hardware characteristics का बहुत गहरा असर होता है
      जब भी नए HPC hardware के लिए code लिखना होता था, तो मैं programming docs के बजाय system hardware और architecture docs माँगता था, और लोग हमेशा चकित हो जाते थे। Hardware design को समझने पर यह first principles से साफ़ हो जाता था कि उसके ऊपर software कैसे design किया जाना चाहिए। Programming docs में अक्सर ऐसे आधे-सच होते थे जो चीज़ों को developers के लिए वास्तविकता से आसान दिखाते थे
      कुछ HPC platforms ने “लिखने में आसान” दिखने की कोशिश में लगातार यह गलत बताया कि peak performance पाने के लिए developers को क्या करना चाहिए, और marketing ने जिस तरह software लिखने का संकेत दिया, उस तरह लिखने पर silicon जितनी performance दे सकता था उतनी नहीं मिली, इसलिए बड़ी विफलताएँ भी हुईं
      आप abstraction के ऊपर HPC code लिख सकते हैं, और वास्तव में बहुत लोग ऐसा करते भी हैं, लेकिन performance और scalability में नुकसान अक्सर अपरिहार्य रूप से integer-multiple स्तर का होता है। दूसरे software की तरह, अगर इससे कम skilled developers भी code design कर पाते हैं, तो कई बार यह नुकसान स्वीकार्य माना जाता है
      HPC भी दूसरे software की तरह ही है; नाम मात्र के professional developers में भी बहुत लोग लगातार अच्छे नतीजे देने में संघर्ष करते हैं। HPC में इस्तेमाल होने वाला काफ़ी महँगा hardware, खराब software design से होने वाले performance loss को कम करने के लिए मौजूद है
      अगर आपको maximum performance चाहिए, तो hardware वास्तव में कैसे काम करता है इसे सचमुच समझने का कोई shortcut नहीं है। यह सामान्य software से अलग नहीं है; बस HPC में hardware systems बड़े और अधिक जटिल होते हैं
    • मैंने लगभग 2 साल पहले एक Fortune 100 कंपनी के करीब 500-node cluster पर HPC का काम शुरू किया। सच कहूँ तो मैं बस ऐसा काम ढूँढ रहा था जिसमें 100% Linux हो, और अब तक यह मज़ेदार रहा है
      लेकिन यह मेरी अपेक्षा से अलग निकला। मुझे लगा था कि मैं ज़्यादा performance-oriented काम करूँगा, numbers analyze करूँगा, और cluster से आख़िरी performance तक निचोड़ूँगा। ईमानदारी से कहूँ तो शुरुआत में monitoring भी नहीं थी। मैंने खुद बनाई, लेकिन उसका शायद ही इस्तेमाल होता है। कभी-कभी management बस इतना पूछता है कि “cluster कितना busy है”, वह भी budget justification जैसी वजहों से
      ज़्यादातर ‘optimization’ इस बात की जाँच होती है कि लोग 16 CPU इस्तेमाल करने वाली script के लिए 384 CPU request न करें, या यह test करना कि कोई software कितने CPU तक बिना performance degradation के चलता है। मैंने Intel profiler सिर्फ़ दो बार खोला है
      काम का बड़ा हिस्सा researchers की मदद करने जैसा है। आमतौर पर commercial या open source programs चलाना और problems troubleshoot करना, या दूसरे teams द्वारा दूसरे clusters पर लिखा गया code लाकर हमारे cluster पर build और run करवाना। घटिया Python code खंगालना, और ज़्यादा modern cluster पर बने C++ projects को CentOS 7 environment में build करने की कोशिश करना
      अपने तरीके से यह मज़ेदार है। मैंने कई languages के साथ काम किया है, इसलिए मुझे चीज़ों को चलाना, crashes और stack traces में गहराई तक जाना पसंद है। बड़े systems के साथ काम करने पर नज़रिए बदल जाते हैं; फिर 128GB RAM या 20TB disk वाला server ‘सिर्फ़’ इतना ही लगता है
      डराने वाली बात यह है कि इन results का इस्तेमाल वास्तविक दुनिया में होता है, जबकि simulations चलाने वाले लोग कभी-कभी काम ठीक से नहीं करते। मैंने गलत code, उलझा हुआ source code, वह data इस्तेमाल होते देखा है जो वे समझते थे उससे अलग था, और यहाँ तक कि 3 साल पुराना एक बहुत बड़ा bug भी मिला। तब लगता है कि क्या इस विषय पर किया गया सारा काम अमान्य नहीं हो जाता
      एक downside यह है कि काफ़ी HPC jobs, जो असल में सिर्फ़ cluster operations हैं, फिर भी master’s degree माँगती हैं। यह मेरी समझ से बाहर है। मैं वह software नहीं लिख रहा जिसे मैं चलाता हूँ, न ही मैं कोई cutting-edge TOP500 cluster चला रहा हूँ। मैं बस कई machines को network से जोड़कर code चलवा रहा हूँ
    • Abstraction बहुत हैं, लेकिन कौन-सी abstraction इस्तेमाल करनी है यह जानने के लिए अभी भी hardware के बारे में बहुत कुछ जानना पड़ता है
      CUDA developers के साथ काम करने के मेरे अनुभव में, performance निकालने के लिए knobs काफ़ी घुमाने पड़ते हैं। Shmoo Plot(https://en.wikipedia.org/wiki/Shmoo_plot, जिसे कुछ industries में ‘wedge’ भी कहा जाता है) रोज़मर्रा की optimization का एक अहम tool है
      हालाँकि, मैं इसे black box कहूँगा या नहीं, यह निश्चित नहीं है। अंत में शायद असर मिलता-जुलता हो सकता है। आप जानते हैं कि knobs क्या करते हैं और कैसे काम करते हैं, और educated guesses भी लगाते हैं, फिर भी measurement करने पर बड़े surprises मिल जाना आम बात है। Optimization का पहला नियम है measurement
      मुझे हमेशा Michael Abrash की “Black Book” के पहले अध्याय “The Best Optimizer is Between Your Ears” http://twimgs.com/ddj/abrashblackbook/gpbb1.pdf की याद आती है। यह modern HPC पर नहीं, बल्कि PC games पर ज़्यादा केंद्रित है, लेकिन high-performance philosophy को बहुत अच्छे से दिखाने वाला शानदार लेख है
      Abstraction के संदर्भ में, सबसे भारी knob tuning optimization process के अंत में करना बेहतर होता है। क्योंकि refactor करने या कुछ बदलने पर knob tuning फिर से करनी पड़ती है। Register spill या cache access pattern में छोटे बदलाव भी thread configuration, cache, shared memory size जैसी fine-grained tuning को पूरी तरह reset कर सकते हैं
      फिर भी बीच-बीच में कुछ हद तक knob tuning ज़रूरी रहती है। यह sanity checks और balance के लिए, और code के आसपास के performance space की intuition पाने के लिए काम आती है
    • एक HPC administrator के रूप में मैं आम तौर पर “science की long tail” वाले researchers को support करता हूँ
      आज के x86_64 hardware में supercomputer memory subsystem जैसी कोई चीज़ नहीं है। वह बस एक fancy NUMA system है, और सबसे बड़ा मुद्दा memory को cores के पास रखना है, यानी latency कम करने के लिए data को उसी NUMA node के भीतर local बनाए रखना
      Resource mapping scheduler संभालता है। Scheduler hardware को जानता है, इसलिए वह requirements को पूरा करते हुए जितना संभव हो उतना optimized cgroup बनाता है, और application को उसी cgroup में रखकर चलाता है

फ़िलहाल high-performance interconnect का बादशाह InfiniBand है, और यह fabric स्तर पर MPI को accelerate करता है। इससे message transfer, broadcast, और result reduction बहुत तेज़ी से हो सकते हैं। message पहुँचने तक वह पहले से reduced हो सकता है, और broadcast के समय केवल एक message भेजना पड़ता है जिसे fabric layer पर broadcast कर दिया जाता है। multi-context IB cards में बहुत सारी queues होती हैं, इसलिए एक ही node/card पर queue/context isolation के साथ कई MPI jobs चलाई जा सकती हैं
GPU workloads के लिए framework इस्तेमाल करने पर structure और optimization आमतौर पर उसी स्तर पर अपने-आप handle हो जाते हैं। मुश्किल काम ज़्यादातर framework developers करते हैं। NVIDIA driver भी एक तरह का शुद्ध काला जादू है, और optimization का कुछ हिस्सा संभालता है। GPUs के बीच का interconnect physical fabric संभालता है, और उसे driver तथा उसके अपने daemons manage करते हैं
अगर bottleneck CPU है, तो libraries आमतौर पर vendor द्वारा हाथ से tuned होती हैं। Intel MKL, BLAS, Eigen आदि ऐसे ही हैं, और मैंने व्यक्तिगत रूप से जो Eigen इस्तेमाल किया है उसमें processor-specific hints और optimizations शामिल थे
ध्यान रखने वाली बात यह है कि code को सही architecture के लिए compile किया जाए, और यह जाँचा जाए कि जिस hardware पर वह चलेगा वह requirements पूरी कर सकता है या नहीं। उदाहरण के लिए, random memory access बहुत ज़्यादा न हो, node पर “जितना संभव हो उतनी तेज़ी से” जाने के लिए prefetcher और branch predictor का सही उपयोग हो, और disk access का दुरुपयोग न किया जाए
numerical computing में मुख्य बात यह है कि काम को स्वतंत्र रखा जाए ताकि instruction-level parallelism/vectorization संभव हो, अनावश्यक computation न की जाए, और MPI का ज़रूरत से ज़्यादा उपयोग न हो — यानी nodes के बीच communication को सिर्फ़ उतने तक सीमित रखा जाए जितना वास्तव में ज़रूरी हो
कहना आसान है, लेकिन एक बार आदत हो जाए तो इन बातों पर सोचना दूसरी प्रकृति जैसा बन जाता है। अगर इस तरह का काम आपकी रुचि के अनुकूल है, तो यही मतलब है

  • यह सही भी है और नहीं भी
    MPI और OpenMP, HPC में hardware को abstract करने के मुख्य साधन हैं। MPI distributed-memory parallel computing का abstraction है, और OpenMP shared-memory parallel computing का abstraction है। बहुत से शोधकर्ता केवल इन्हीं दोनों के साथ code लिखते हैं, और कई बार एक ही code में दोनों का इस्तेमाल भी होता है। इन्हें इस्तेमाल करते समय ज़्यादातर architecture details की चिंता नहीं करनी पड़ती
    फिर भी, जो शोधकर्ता और ज़्यादा optimization पसंद करते हैं, वे performance बढ़ाने के लिए कई छोटे architectural details को छेड़ते हैं। उदाहरण के लिए loop unrolling काफ़ी आम है, और व्यक्तिगत रूप से मुझे यह काफ़ी भ्रमित करने वाला लग सकता है। मुझे धुंधला-सा याद है कि किसी खास CPU architecture की वजह से multiplication की तुलना में addition को प्राथमिकता देकर operations को vectorize करने की बात होती थी, लेकिन मैंने इसे वास्तव में होते नहीं देखा
    cache misses को रोकना भी एक बड़ा विषय है। कुछ code इस तरह लिखे जाते हैं कि सबसे ज़रूरी जानकारी memory में नहीं बल्कि CPU cache में रहे। ज़्यादातर code सिर्फ़ इतना सुनिश्चित करते हैं कि Fortran में array operations के लिए column-major traversal और C में row-major traversal हो, लेकिन इस अवधारणा को और आगे बढ़ाया जा सकता है। अगर processor की cache size पता हो, तो operations को इस तरह optimize किया जा सकता है कि ज़रूरी जानकारी पूरी तरह cache में बनी रहे और cache misses कम से कम हों। मैंने इसे व्यवहार में नहीं देखा, लेकिन 2013 में जो scientific computing class मैंने ली थी उसमें इस पर सक्रिय चर्चा होती थी
    किसी खास GPU का उपयोग करना है या नहीं, यह काफी हद तक इस बात पर निर्भर करता है कि आप किस समस्या को हल करना चाहते हैं। कुछ समस्याएँ GPU पर बेहतरीन चलती हैं, और कुछ के लिए यह बहुत मुश्किल होता है। दुर्भाग्य से उस हिस्से के बारे में मुझे ज़्यादा जानकारी नहीं है

  • Victor ने इतना शानदार सामग्री संकलित की है, यह देखकर प्रभावित हूँ
    व्यक्तिगत रूप से परिचय नहीं है, लेकिन 1990s में UT Austin में PhD करते समय मैंने TACC द्वारा प्रबंधित संसाधनों (Cray Y-MP, IBM SP/2 Winterhawk, और उस समय Cray T3E को दर्शाने वाला hostname Lonestar) का उपयोग करके अपना शोध पूरा किया था। मेरी PhD committee के एक सदस्य अभी भी वहाँ हैं। अगर मुझे सही याद है, उस समय TACC को HPCC या CHPC कहा जाता था
    उस समय programmers को code खुद parallelize करना पड़ता था, और मेरे मामले में मैंने UNICOS environment वाले Cray T3E पर MPI इस्तेमाल किया था। यह क्षेत्र तब अभी शुरुआती दौर में था, इसलिए hardware की कुछ समझ भी ज़रूरी थी। समस्याएँ मैंने धूसर Cray ring binder और Gropp आदि की किताबें पढ़कर हल कीं, और निश्चित ही पहले बताए गए जानकार contacts भी बहुत मददगार रहे

    • Lonestar5 फिर से Cray था। मौजूदा Lonestar6 एक oil-immersed AMD Milan cluster है, जिसमें A100 GPU हैं
      समय कभी नहीं रुकता
    • TACC के माध्यम से बड़े simulations करते हुए मैंने उनके साथ काम किया है, और मदद के लिए आभार स्वरूप मैंने इस series की volume 1 की paperback खरीदी थी
      यह मेरे क्षेत्र से थोड़ा बाहर है, लेकिन बहुत रोचक था। बाकी भी देखने का इरादा है, और जिसकी रुचि हो उसे इसे ज़रूर देखना चाहिए

  • मेरी रुचि HPC के hardware management पक्ष में है
    मैं जानना चाहता हूँ कि समस्याओं का पता कैसे लगाया और diagnosis कैसे किया जाता है, और फिर उन्हें reboot/reinstall/repair जैसे actions से कैसे map किया जाता है, ये काम कैसे schedule होते हैं, और best service level देने के लिए कैसे optimize किए जाते हैं
    जब node availability और overall throughput जैसे कई लक्ष्यों को एक साथ optimize करना हो, तब यह कैसे किया जाता है; अलग-अलग topologies ऊपर की बातों को कैसे प्रभावित करती हैं; दूसरी constraints का क्या असर होता है; और कुल मिलाकर system dynamics के नज़रिये से इन समस्याओं को कैसे संभाला जाता है, इसमें भी दिलचस्पी है
    इस तरह की जानकारी को अच्छी तरह कवर करने वाली सामग्री मुझे ज़्यादा नहीं मिली। अगर किसी को कुछ पता हो तो बताना अच्छा होगा

    • सामान्य non-blocking folded-Clos network या Little's law से आगे, अगर आप ज़्यादा engineering दृष्टिकोण चाहते हैं, तो queueing theory में गहराई से जाना होगा
      queueing theory पहली बार सीखते समय तुच्छ और आसान लग सकती है, लेकिन इसमें बहुत से open problems हैं
      उदाहरण के लिए, random arrival times, independent service times, और k servers वाले system (M/G/k) के performance metrics भी अब तक open problem हैं
      https://www.sciencedirect.com/science/article/pii/S0895717704905341
      उम्मीद के विपरीत, queueing theory में सचमुच बहुत सारे open problems हैं
    • कुछ महीने पहले Meta और nVidia के interviews देते समय यह एक बड़ा विषय लगा
      Meta के बारे में ऐसे ठीक-ठाक YouTube videos थे जो इस scale के GPU को संभालने की समस्याओं को समझाते हैं
    • Mark Russinovich लगभग हर साल Azure के अंदरूनी हिस्सों और उसे चलाने वाले systems पर अच्छे talks देते हैं। [1] इसका एक उदाहरण है, और दूसरे वर्षों की talks भी देखने लायक हैं
      Meta भी अपनी engineering site पर papers, blogs, और open source projects बहुत साझा करता है [2]
      AWS के James Hamilton भी लगभग हर साल infrastructure पर talks देते हैं। अलग-अलग वर्षों की talks देखना उपयोगी है [3]
      [1] https://youtu.be/69PrhWQorEM?si=u7vh_Um6SQNoyeFH
      [2] https://engineering.fb.com/category/data-center-engineering/
      [3] https://youtu.be/AyOAjFNPAbA?si=nFRJVcQI4EiamC-O
    • Microsoft का यह paper [1] इस क्षेत्र में मैंने देखी सबसे शानदार चीज़ों में से एक था
      मूल रूप से यह workload, यहाँ deep learning jobs, के स्तर पर optimize करता है ताकि job resizing और preemption संभव हो सके
      [1] https://arxiv.org/pdf/2202.07848.pdf
    • openbmc project और DTMF association को देखना उपयोगी हो सकता है

  • मैंने 2013 में scientific computing की एक class ली थी
    यह computer science और applied mathematics दोनों में cross-listed course था। समस्या यह थी कि यह क्षेत्र कुल मिलाकर इतना व्यापक है कि course में HPC और parallel programming सहित बहुत से विषय बहुत सतही तौर पर कवर किए गए
    मुझे यह course लेने का पछतावा नहीं है, लेकिन जिन applications की मैं तलाश में था उनके लिए यह बहुत व्यापक था
    मैंने कई सालों से नहीं देखा कि कौन से courses offered होते हैं, लेकिन जब मैं graduate student था तब parallel computing पर पूरे semester का dedicated course सचमुच बहुत मददगार होता। खासकर ऐसा class जो parallel/distributed computing के specific algorithms and data structures में गहराई से जाए
    मैंने जो scientific computing class ली थी, उसमें इन बातों को बहुत सरसरी ढंग से लिया गया, मानो पहली कोशिश में ही किसी को ठीक-ठीक पता हो कि parallelization कैसे करनी है। बाद में, कई HPC लोगों की तरह, मैंने वर्षों में खुद से और colleagues से बहुत कुछ सीखा, लेकिन अगर ये किताबें semester-long dedicated course का हिस्सा होतीं तो बहुत मूल्यवान होतीं

  • यह देखकर हैरानी होती है कि लेखक ने C++ और Unix tools की शिक्षा सहित इतनी व्यापक किताबें बनाई और उन्हें मुफ्त में साझा किया
    भले ही यह केवल HPC के लिए न हो, हर programmer के लिए इसमें सीखने जैसा कुछ है
    संबंधित सामग्री के रूप में Jorg Arndt की “Matters Computational” किताब और FXT library भी हैं: https://www.jjj.de/fxt/

  • यहाँ इस्तेमाल किए गए C++ शिक्षण तरीके के बारे में लोग क्या सोचते हैं, यह जानने की जिज्ञासा है। क्या इसमें कोई खास कमी है?
    मैंने Python बहुत लंबे समय तक इस्तेमाल किया है, और C, C++, CUDA भी थोड़ा संभाला है, साथ ही HPC environment में application-level research (ML/DL) कर रहा हूँ। मैं अपनी C++ skill बढ़ाना चाहता हूँ, और इन 3 किताबों को सरसरी तौर पर देखने पर लगा कि ये मेरे level के बिल्कुल अनुकूल हैं। यह बहुत धीमी गति से नहीं चलतीं, और पूरी तरह comprehensive होने के बजाय लेखक जिन best practices की बात करता है, उन्हें सिखाने के तरीके पर चलती हैं

    • एक C++ programmer और educator के नज़रिए से, ये 3 किताबें अच्छी तरह से तैयार की गई शुरुआती शिक्षण सामग्री हैं। शायद आपको इनमें से ज़्यादातर बातें पहले से पता होंगी
      मैंने range-based for loop, std::array, std::span ढूँढे, और अच्छा लगा कि ये सब शामिल हैं
      चूँकि यह किताब HPC से जुड़ी है, मैं कुछ बातें और जोड़ना चाहूँगा। return value optimization, move semantics, और recursive functions वाले section में tail call optimization की व्याख्या भी होनी चाहिए
      शुरुआती सामग्री के रूप में इसे ज़ोरदार तरीके से recommend किया जा सकता है
    • “The Art of HPC” की volume 2, “Parallel Programming for Science Engineering”, में यह बात अलग से दिखती है कि C, Fortran, C++, और MPI के मामले में Python में MPI और OpenMP को भी कवर किया गया है: https://theartofhpc.com/pcse/index.html
      संदर्भ के लिए, MPI सिर्फ Python के साथ HPC करने का एक तरीका है
      अगर मुझे सही याद है, तो ipyparallel अपने खुद के बनाए tunnel के ऊपर MPI jobs चला सकता है
      अगर dask-scheduler, CuDF, CuGraph(NetworkX), DaskML, CuPy, dask-labextension पर chapter होते, तो यह और up-to-date लगता
      Dask data storage को अपने आप संभालता नहीं है, इसलिए हर barrier से पहले data store performance bottleneck न बने, यह सुनिश्चित करना user की ज़िम्मेदारी है
      Dask documentation का High Performance Computers section: https://docs.dask.org/en/stable/deploying-hpc.html
      random number source भी bottleneck हो सकता है। पूरे cluster में jobs को profile किए बिना यह पता नहीं चलता
      eBPF-based tracing tools से संबंधित: https://news.ycombinator.com/item?id=31688180
      उसके बाद GitOps और ChatOps, code review और revision, project resource quotas जैसी चीज़ें भी हों तो अच्छा होगा

  • 10 साल पहले मुझे HPC graduate course में TA की भूमिका बाँटकर संभालने का प्रस्ताव मिला था, लेकिन मैंने मना कर दिया
    अब सरसरी तौर पर देखने के बाद, मैं ईमानदारी से कह सकता हूँ कि अगर उस समय यह किताब होती, तो शायद मैं वह मौका ले लेता
    कला के रूप में framing, जो Knuth-शैली जैसी लगती है, woodworking से की गई तुलना, और अपने DevOps प्रभारी से भी बेहतर DevOps व्यक्ति बनना चाहिए — इस आवश्यकता का मेल, इन सबको मिलाकर यह बात काफ़ी प्रभावशाली बनती है
    लेखक की उपलब्धियों के लिए सराहना। लगता है UT Austin ने कंप्यूटर विज्ञान में कुछ वैसा ही हासिल किया है जैसा North Texas State ने संगीत में किया था

  • UT Austin HPC और computational methodology में सचमुच एक बेहतरीन institution है

    • आप जिस भी BLAS का इस्तेमाल करना चाहें, उनमें से लगभग हर एक किसी न किसी रूप में UT Austin के TACC से जुड़ा हुआ है

  • जब मैं एक छोटी कंपनी में शामिल हुआ जो एक बड़े automobile manufacturer के HPC engineers को support करती थी, तो यह देखकर हैरानी हुई कि scheduler LSF के आसपास in-house scripts की भरमार थी
    काफी बाद में, जब मैंने अपने personal mini-cluster पर SLURM चलाकर देखा, तब समझ आया कि scheduler software के versions आम तौर पर आपस में compatible नहीं होते। यानी cluster के अंदर एक version और बाहर client machine पर दूसरा version इस्तेमाल करना संभव नहीं था
    इसलिए बाहर से scheduler में jobs submit करने और बाद में results वापस लाने के लिए glue software की ज़रूरत पड़ती थी। मेरी नज़र में इससे scheduler की value कम हो जाती है
    अगर कोई 30 साल से high-performance distributed computing कर रहा हो, तो लगा था कि requirements अब तक अच्छी तरह जानी-पहचानी होंगी, और कम-से-कम commands तथा data exchange protocol तो standard हो चुके होंगे। लेकिन शायद ऐसा नहीं है

    • cluster authentication वाकई आज भी हर interaction में सिरदर्द बना हुआ है। ज़्यादातर systems में सबसे न्यूनतम common denominator यही है कि क्या आप login node में SSH से घुस सकते हैं। वहाँ से आगे sbatch/squeue जैसे मुख्य job commands काफ़ी stable हैं
      पहले भी basic job management API को standardize करने की कोशिशें हुई थीं, और DRMAA उसका एक उल्लेखनीय उदाहरण है। लेकिन DRMAA v2 को सिर्फ Grid Engine ने implement किया, और वह भी असल में internal API का हल्का-सा abstraction भर था, इसलिए Slurm/PBS/LSF में उसे first-class support नहीं मिल पाया
      Slurm में REST API को आगे का रास्ता माना जाता है। authentication की समस्या को Apache/NGINX proxy के ज़रिए admin जिस भी तरीके से connection संभालना चाहे, उस पर छोड़ दिया जाता है। basic job submission और status API अब इतने stable हो चुके हैं कि आगे चलकर लगभग किसी भी version के client application उन्हें consume कर सकेंगे