M3 MacBook अपग्रेड का फैसला करने के लिए डेवलपर बिल्ड टाइम ट्रैकिंग

 (incident.io)
1 पॉइंट द्वारा GN⁺ 2023-12-30 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • incident.io ने यह तय करने के लिए कि डेवलपर laptops को M3 में बदलना है या नहीं, महसूस किए गए अनुभव के बजाय Go build time को आधार बनाया और local development feedback loop का वास्तविक डेटा इकट्ठा किया
  • मौजूदा Go hot reloader से जरूरी values पाना मुश्किल था, इसलिए उन्होंने अपना tool बनाया और platform, memory, power state, build stage, trigger file, total elapsed time जैसे build events को data warehouse में लोड किया
  • लगभग 25k builds में से failed, cancelled और battery power builds को हटाने के बाद 12,525 successful builds का analysis किया गया, और यह statistical difference पुष्टि हुआ कि AC power पर builds battery builds से तेज हैं
  • नतीजे में M1 users अक्सर build पूरा होने तक लगभग 2 मिनट इंतजार करते थे, M2 ने M1 की तुलना में बड़ा सुधार दिखाया, और M3 ने M2 की तुलना में incremental improvement दिखाया
  • कुल build time में memory का फर्क साफ नहीं था, लेकिन linker time में 32–36GB machines बेहतर निकलीं, इसलिए incident.io ने M1 machines को 36GB base M3 Pro से replace करने का फैसला किया

अपग्रेड का निर्णय मानदंड: development feedback loop

  • incident.io के सभी developers development work के लिए MacBook इस्तेमाल करते हैं
  • Apple ने अक्टूबर 2023 में M3 MacBook Pro पेश किया, जिसके बाद CTO Pete ने कहा कि अगर upgrade value data से साबित हो जाए तो devices बदले जाएंगे
  • टीम ने M3 upgrade का फैसला करने के लिए तीन चीजें तैयार कीं
    • custom Go hot reloader
    • developer laptops से build telemetry collection
    • OpenAI के latest model और code interpreter का उपयोग करके data analysis
  • developer productivity को सीधे quantify करना मुश्किल है, लेकिन incident.io मानता है कि तेज feedback loop developer efficiency के लिए महत्वपूर्ण है
  • local development में बार-बार दोहराए जाने वाले feedback loops ये हैं
    • Go monolith compile करना
    • API clients और interfaces जैसे code generation
    • frontend और mobile apps का hot reload
  • incident.io developers अपने laptops पर पूरा incident.io environment locally चलाते हैं, और code change के बाद run होने तक 30 seconds से कम का feedback loop बनाए रखते हैं
  • Go app का codebase लगभग 10 लाख lines के करीब पहुंच रहा है, इसलिए बार-बार होने वाले और महंगे Go compile को MacBook performance comparison metric चुना गया

build telemetry collection का तरीका

  • incident.io ने शुरुआती GitHub repository creation के समय से Go hot reloader के रूप में codegangsta/gin का इस्तेमाल किया है
  • alternate hot reloaders भी देखे गए, लेकिन build time analysis के लिए जरूरी telemetry देने वाला कोई tool नहीं मिला
  • हर build से जो data collect करना था, वह इस प्रकार था
    • system level: M1/M2/M3 platform, total memory आदि
    • runtime metrics: OS, memory usage, power source, battery level आदि
    • build telemetry: total elapsed time, Go build stages, build trigger करने वाली files आदि
  • कोई ready-made alternative न होने से उन्होंने main.go से शुरू किया गया अपना tool बनाया, और Mac के कई binary outputs को run और parse करके जरूरी values निकालीं
    • memory_pressure
    • docker
    • sysctl
    • pmset
  • संबंधित code Gist पर公開 किया गया
  • system और runtime collectors बनाने के बाद Go build command को wrap किया गया ताकि linker, compile आदि stages के time और build trigger files collect किए जा सकें
  • अंतिम hot reloader मौजूदा make run target से चलता है, और engineering team के लिए यह बदलाव दिखाई नहीं देता था
  • हर build खत्म होने पर telemetry event को HTTP endpoint पर भेजा गया, और Fivetran webhook receiver के जरिए data warehouse में लोड किया गया

OpenAI Assistant का उपयोग करके analysis flow

  • कुछ हफ्तों तक पर्याप्त dataset जमा करने के बाद, BigQuery से select * except(payload) from developer__build_events का result CSV में export किया गया
  • OpenAI Assistants को उद्देश्य समझाने वाला prompt और CSV file दी गई
  • experimental model gpt-4-1106-preview और code interpreter enable करके data analysis में इस्तेमाल किया गया
  • build time एक ही system पर भी बहुत variable होता है, और Go compiler cache का असर भी बड़ा होता है, इसलिए सिर्फ platform-wise average compare करना fair नहीं है
    • cache के बिना M3 Max, cache वाले पुराने Intel MacBook से धीमा हो सकता है
  • analysis सिर्फ average comparison नहीं था; build conditions को साफ करके platform, memory और power state के आधार पर अलग-अलग देखने के तरीके से किया गया

data cleanup और fair comparison conditions

  • पूरा dataset लगभग 25k builds का था, और दिन के अलग-अलग समय, laptops और conditions से collect किया गया था
  • fair platform comparison के लिए निम्न builds को exclude किया गया
    • failed या cancelled builds: पूरा न हुआ काम होने के कारण build speed comparison के लिए उपयुक्त नहीं
    • battery power builds: OS X battery life बचाने के लिए performance limit कर सकता है
  • failed builds हटाने के बाद successful builds 12,525 निकले
  • AC power और battery power की build performance difference को मुख्यतः M1 Pro और M2 Max पर compare किया गया
  • statistical test में AC power builds का average time कम निकला, और p-value लगभग 0.0014 रही
  • इसके बाद analysis में केवल successful AC power builds का उपयोग किया गया

Go build time में variability क्यों होती है

  • incident.io का Go monolith build performance की लगातार निगरानी का subject है, और hardware खरीद जितना ही build process को हटाना या tune करना भी महत्वपूर्ण है
  • Go project कई packages से बना होता है, और Go compiler cache का उपयोग करता है ताकि केवल उन packages को recompile करे जिनमें बदलाव माना गया हो
  • incident.io app को wide dependency graph और कम foundational modules के साथ design किया गया है, ताकि ज्यादातर changes पूरे graph के recompilation में न बदलें
  • build types मोटे तौर पर चार हिस्सों में बंटते हैं
    • instant complete, 3 seconds से कम: Go compiler से असंबंधित बदलाव, जिसमें cached binary इस्तेमाल हो सकती है
    • fast build, 30 seconds से कम: कम dependent packages वाले single package में बदलाव; ज्यादातर cache reuse होता है, और time मुख्यतः linking में लगता है
    • medium build, 30 seconds–1 minute: कुछ lower package dependencies वाले feature package को modify किया गया, लेकिन ज्यादातर reuse संभव है
    • slow build, 1 minute से अधिक: foundational domain package में type add करने से app के सभी packages को फिर compile करना पड़ता है
  • platform comparison में इन build characteristics के फर्क को ध्यान में रखना जरूरी है; सभी builds को एक साथ मिला देना apples-to-oranges comparison बन जाता है

M1, M2, M3 comparison results

  • पहले केवल successful AC power builds के आधार पर M1 Pro और M2 Max की तुलना की गई
  • M2 Max build speed में M1 Pro से काफी आगे था, लेकिन दोनों devices सिर्फ chipset में नहीं बल्कि memory configuration में भी अलग थे
  • successful build events का platform और memory-wise distribution इस प्रकार था
    • Apple M1 Pro 16GB: 5,235 builds
    • Apple M2 Pro 16GB: 1,927 builds
    • Apple M2 Max 32GB: 3,842 builds
    • Apple M3 Pro 18GB: 321 builds
    • Apple M3 Pro 36GB: 899 builds
    • Apple M3 Max 36GB: 301 builds
  • M1 Pro 16GB और M2 Max 32GB की comparison memory difference के कारण पूरी तरह fair नहीं थी
  • M2 Pro 16GB और M2 Max 32GB की तुलना करने पर, 32GB memory का total build time पर असर छोटा दिखा
  • M2 Pro और M2 Max broadly वही chip हैं, और Max में 2 additional energy-efficiency cores हैं
    • इन cores को performance cores के लगभग 1/5 level का माना गया, इसलिए Go programs compile करने में उनका contribution छोटा समझा गया
  • M3 evaluation के लिए निम्न तीन machines खरीदी गईं
    • M3 Pro 12-core, 6 performance cores + 6 energy-efficiency cores, 18GB
    • M3 Pro 12-core, 6 performance cores + 6 energy-efficiency cores, 36GB
    • M3 Max 14-core, 10 performance cores + 4 energy-efficiency cores, 36GB
  • M3 Pro 18GB और 36GB के build time graphs समान थे, लेकिन M3 data बाकी platforms से कम था
  • 3 seconds से कम वाले बहुत तेज builds को exclude करके M3 Pro और M3 Max compare करने पर, M3 Max ने base M3 Pro से 60% ज्यादा कीमत justify करने लायक स्पष्ट improvement नहीं दिखाया
  • कुल फैसला इस प्रकार था
    • M1 laptop users अक्सर build complete होने तक लगभग 2 minutes इंतजार करते हैं
    • M2, M1 की तुलना में बड़ा upgrade है
    • M3, M2 की तुलना में incremental improvement है
    • M1 users base M3 Pro पर upgrade करेंगे
    • M2 users को upgrade की जरूरत नहीं है

memory का असर linker time में ज्यादा साफ दिखता है

  • total build time comparison में 16–18GB से 32–36GB पर जाने पर कोई बड़ा meaningful improvement साफ नहीं दिखा
  • उम्मीद के विपरीत memory effect graphs में ज्यादा स्पष्ट नहीं दिखा, इसलिए build stages में से linker time को अलग से analyze किया गया
  • telemetry events में link और compile stage times शामिल थे, और build_stages.link.duration_seconds से linker_time column बनाकर analysis किया गया
  • linker_time को platform और memory configuration के आधार पर compare करने पर अलग pattern दिखा
    • 32–36GB memory वाली M1, M2, M3 machines लगभग हमेशा link 20 seconds से कम में पूरा करती थीं
    • 18GB या कम memory वाली machines में link के 20 seconds से ज्यादा होने के cases अक्सर दिखे
  • additional memory total build time में कम स्पष्ट हो सकती है, लेकिन linker stage में useful साबित हुई
  • development machines से Docker हटाने का option भी review किया जा रहा है, और इसका interpretation यह निकला कि low-memory machines Docker के बिना available system memory बढ़ाकर link time improve कर सकती हैं
  • mobile app development में simulators काफी system memory इस्तेमाल करते हैं, इसलिए memory upgrade को future-proofing cost के रूप में भी reasonable माना गया

final decision और side effects

  • incident.io ने M1 machines को 36GB memory वाले base M3 Pro में upgrade करने का फैसला किया
  • M2 machines पहले से काफी अच्छी performance देती दिखीं, इसलिए फिलहाल उन्हें upgrade नहीं किया जाएगा
  • laptop खरीद का फैसला करने के अलावा development environment और tools की समझ भी बढ़ी
  • टीम को मिले नतीजे ये हैं
    • developer machine performance measure करने के लिए Go build time को अच्छा benchmark पाया
    • जरूरी metrics track करने वाला अपना Go hot reloader बनाया, और usability में अन्य improvements भी मिले
    • Go builds के तेज या धीमे होने के कारणों को बेहतर समझा
    • OpenAI Assistants से इसी तरह की data analysis problems handle की जा सकती हैं, यह confirm हुआ
    • Apple chip lineup-wise improvements को Go developer perspective से quantify किया
    • memory important है, लेकिन total build time की तुलना में linker time में ज्यादा साफ दिखती है

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

1 टिप्पणियां

 
GN⁺ 2023-12-30
Hacker News की टिप्पणियाँ

  • लेख शानदार है और डेटा इकट्ठा करने व विश्लेषण करने के कई तरीके अच्छे लगे, लेकिन हर laptop को साथ-साथ रखकर उसी scenario में timed build चलाना शायद कहीं आसान और ज़्यादा सटीक होता
    full build, हाल के बदलावों की incremental build, और ऐसी incremental build जिसमें किसी खास module को rebuild करना पड़े—ऐसी कुछ चीज़ों की तुलना की जा सकती थी, या हाल के 100 Git commits को क्रम से apply करके incremental build time मापने वाली script एक दिन में बनाई जा सकती थी
    पूरी company के stats इकट्ठा करने से bias बढ़ सकता है। उदाहरण के लिए, नए hires के पास M3 और पुराने कर्मचारियों के पास M1 होने की संभावना ज़्यादा है, और नए लोग छोटे बदलाव ज़्यादा करते हैं जबकि अनुभवी लोग code के गहरे हिस्सों या complex areas पर काम करते हैं, जिससे build time लंबा हो सकता है
    इसलिए analysis अपने-आप में बढ़िया है, लेकिन sample में मौजूद bias को देखते हुए company-wide data collection architecture बनाने से पहले हर laptop पर हाल के commits को benchmark करने जैसे simple तरीके से शुरू करना बेहतर लगता है

    • इस सुझाव से पूरी तरह सहमत हूँ, और लेख लिखने वाले के तौर पर मैंने पहले कुछ आम tasks पर performance की spot check भी की थी
      यह data इकट्ठा करने का कारण सिर्फ devices के बीच तुलना नहीं था, बल्कि developer build times का historical data बनाना और build performance को लगातार मापकर regressions पकड़ना भी था
      जब build time बढ़ता दिखता है, तो हम codebase structure को अक्सर adjust करके builds को फिर तेज़ बनाते हैं
    • M3 के विकल्प के रूप में network build का analysis नहीं दिखा। मेरा project लगभग 4 करोड़ lines का है, और एक तय सीमा के बाद local machine चाहे जितनी तेज़ हो, infra team द्वारा बनाया गया network build उसे हरा नहीं सकती
      M3, M1 से build को 30% तेज़ कर सकता है, लेकिन network build 15 गुना तेज़ है। इसलिए यह देखना चाहिए कि developers को M3 देने के बजाय network build में निवेश करना बेहतर होता या नहीं
    • sample का bias analysis methodology की समस्या है। यह दिखाता है कि अगर आप खुद विषय को पर्याप्त गहराई से नहीं समझते, तो AI assistant पर निर्भर नहीं हुआ जा सकता
      independently sampled न किए गए data पर t-test किया गया, लेकिन कई data points अलग-अलग लोगों से आए थे, और हर व्यक्ति का काम अलग होने से computational demand भी अलग हो सकती है, जिससे confounding factors पैदा होते हैं। यह t-test की बुनियादी assumptions का उल्लंघन है, लेकिन code interpreter ने इसे नहीं पकड़ा
      इसके बजाय laptop owner, tenure जैसी चीज़ों को random effects के रूप में डालकर linear mixed effects model इस्तेमाल किया जा सकता था
      फिर भी data दिलचस्प है, खासकर RAM वाला हिस्सा। cache बहुत ताकतवर होता है, और ज़्यादा RAM का फायदा लोगों की सोच से बड़ा हो सकता है। आम तौर पर ज़रूरत से ज़्यादा RAM वाला MacBook अपनी बची हुई RAM का ज़्यादातर हिस्सा cache से भर देता है
    • किसी वजह से ऐसा लगता है कि सवाल का जवाब देने के लिए जानबूझकर सबसे महँगा तरीका चुना गया। और जब यह निष्कर्ष निकला कि M2 भी काफी है, तो फिर नतीजा M1 users को और महँगे M3 पर upgrade करने का क्यों था, यह भी सवाल है
    • यह capture करना अच्छा होता कि क्या और कैसे build किया गया, जैसे “repository इस commit से शुरू”, “यह diff apply”, “इस command से build run”
      अगर इसे करीब एक हफ्ते तक इकट्ठा किया जाए, तो असली workload का एक cross-section मिल सकता है, और उन builds को हर hardware tier पर बार-बार चलाया जा सकता है, साथ ही बाद में नए hardware पर भी दोबारा इस्तेमाल किया जा सकता है

  • एक scientist के तौर पर यह देखना दिलचस्प है कि computer programmers data को कैसे संभालते हैं
    उन्होंने सुंदर graphs बनाए, ChatGPT से analysis को बहुत तेज़ी से automate किया, और ChatGPT ने काफ़ी plausible t-test भी दे दिया
    लेकिन memory और chip type के हिसाब से variation था, फिर भी linear regression के बारे में नहीं सोचा गया, और ऐसे histogram बनाए गए जिन्हें compare करना मुश्किल है। simple averages और error bars जोड़ सकते थे, या cumulative distribution function (CDF) इस्तेमाल कर सकते थे जिससे overlap या shifts देखना आसान होता

    • computer science researcher के तौर पर मेरी भी यही प्रतिक्रिया थी। undergraduate में biology/computer science double major करते हुए statistics पढ़ी थी, लेकिन data analysis में cumulative distribution function का इस्तेमाल मैंने शायद graduate school में जाकर किया
    • आम तौर पर यह data scientist का काम होता है, और ज़्यादातर engineering infra teams में data scientist नहीं होते, न ही ज़्यादातर समय उनकी सख्त ज़रूरत होती है
      आम तौर पर लोग data को वैसे ही संभालते हैं जैसा tools दिखाते हैं, और यह analysis, performance analysis, तथा observability software products की दुनिया से भी काफ़ी मेल खाता है
      यह उम्मीद करना कि एक औसत software engineer को CDF पता होना चाहिए, वैसा ही है जैसे यह उम्मीद करना कि उसे 3D graphics में quaternion या shader writing की basics भी पता हों
    • distribution साफ़ तौर पर normal distribution जैसी नहीं लगती, और median difference भी काफ़ी महत्वपूर्ण हो सकता था। पहली पसंद के तौर पर मैं शायद Wilcoxon test इस्तेमाल करता
      या फिर quantile regression भी किया जा सकता था। अगर hypothesis यह है कि M3 > M2 > M1, तो ordered medians के लिए मशहूर Jonckheere–Terpstra test इस तरह के pseudo-analysis के लिए बिल्कुल उपयुक्त हो सकता था
    • कुछ जगहों पर box plot इस्तेमाल किए गए थे, जिनसे तुलना ज़्यादा साफ़ होती है। अगर सारे data को box plot में दिखाया जाता, तो शायद वह और प्रभावी होता
    • इस तरह की तुलना के लिए empirical cumulative distribution function graph सुझाना चाहूँगा। हर distribution एक curve बन जाती है, और कई curves को एक ही graph पर रखकर आसानी से compare किया जा सकता है
      उदाहरण के लिए इस page का आख़िरी graph देखें: https://ggplot2.tidyverse.org/reference/stat_ecdf.html

  • विश्लेषण मजबूत है, लेकिन निजी अनुभव के आधार पर मैं एक चेतावनी देना चाहूँगा
    लगभग 2,000 कर्मचारियों वाली एक मझोली software company में हमने developer productivity बढ़ाने की कोशिश की, और नए laptop खरीदने के बजाय development stack को AWS instances पर ले जाने का विकल्प खोजा
    नतीजा यह हुआ कि यह लगभग 4 developers के full-time जुड़ने वाला कई साल का project बन गया, और पीछे मुड़कर देखें तो लागत के मुकाबले फायदा नहीं था। पूरी तरह local development experience को cloud में दोहराना अभी भी बहुत कठिन है
    इसलिए मुझे लगता है कि laptop upgrade करना बेहतर है

    • हमारी team कई सालों से पूरी तरह remote environment में K8s cluster को target करके development कर रही है, और इससे काफ़ी मजबूत developer experience मिलता है
      code laptop पर रहता है, लेकिन Docker build या K8s deployment के बिना remote services के साथ real-time sync होता है, इसलिए यह सचमुच local जैसा लगता है
      खासकर coding के दौरान integration tests से आगे की चीज़ें भी तुरंत चला सकते हैं, इसलिए commit-push-pray cycle से बचा जा सकता है
      इसके लिए हम Garden(https://docs.garden.io) का इस्तेमाल करते हैं। Garden इस्तेमाल करें या न करें, सही tools हों तो internal development loop में cloud की ताकत का इस्तेमाल काफ़ी शानदार हो सकता है
      अनुभव पर और लिखा गया लेख: https://thenewstack.io/one-year-of-remote-kubernetes-develop...
    • इसका संबंध scale से हो सकता है। हमारी company में लगभग 7,000 लोग हैं, और हमने भी कुछ साल पहले ऐसा ही रास्ता शुरू किया था। remote, local से बेहतर बनने में समय लगा, लेकिन अब यह निश्चित रूप से बेहतर है
      local-only version में जो संभव नहीं था, ऐसी कई चीज़ें अब संभव हो गई हैं। उदाहरण के लिए, कई branches के बीच आने-जाने पर local files बदलने के बजाय machine बदल दी जाए तो context switch latency काफ़ी कम हो जाती है
    • मैं पूरी तरह सहमत हूँ। अगर पूरे solution को पूरी तरह local में चलाया नहीं जा सकता, तो उस solution को समझने और उसके बारे में तर्क करने में बहुत friction पैदा होता है
      अगर कुछ करने के लिए 200 से ज़्यादा components उठाने पड़ें, तो सिर्फ़ उस single part पर काम करना भी मुश्किल हो जाता है जो उनमें से कुछ ही parts से interact करता है
      अब जबकि 128-core, 256-thread से ज़्यादा वाले servers का दौर है, मुझे लगने लगा है कि ज़्यादातर software के लिए फिर से monolith बेहतर है
    • हमारी company ने बिना सोचे-समझे cloud developer boxes में Linux antivirus और दूसरी बेकार चीज़ें इतनी भर दी हैं कि बड़े instance types पर भी build, laptop से 10 गुना से ज़्यादा धीमे हैं, और Threadripper जैसी असली development machines से सैकड़ों गुना धीमे
      यह पूरी तरह पैसे और समय की बर्बादी है। अगर हर system call को vendor के घटिया software से hook कर देंगे, तो यह समझना मुश्किल नहीं कि बहुत सारे subprocesses चलाने वाली Unix-style toolchain पर इसका बुरा असर पड़ेगा
    • मुझे लगता है कि यह ज़्यादा staffing issue है
      Google, Meta जैसी बड़ी tech companies में ज़्यादातर software engineers का development environment cloud में होता है
      यह local से काफ़ी बेहतर development experience है

  • iOS development के हिसाब से, लागत को भी ध्यान में रखकर मेरी निजी जांच का निष्कर्ष यह था
    M2 Pro अच्छा है, लेकिन 10-core M1 Pro की तुलना में सुधार बहुत बड़ा नहीं है। XcodeBenchmark के अनुसार 136 सेकंड बनाम 120 सेकंड: https://github.com/devMEremenko/XcodeBenchmark
    M3 Pro ऐसा लगता है मानो उसे M3 Max से अलग बेचने के लिए जानबूझकर कमजोर किया गया हो, और उसमें सिर्फ़ 6 performance cores हैं, इसलिए व्यवहार में यह M2 Pro जैसा ही है
    अंत में मैंने थोड़ा इस्तेमाल किया हुआ 10-core M1 Pro खरीदा और मैं उससे बहुत संतुष्ट हूँ। base M3 Pro की कीमत के आधे से भी कम में मुझे 85% performance मिली, और यह बात भी ध्यान में रखी कि आम तौर पर CPU कम-से-कम 33~50% तेज़ हो तभी अंतर महसूस होता है

    • M3 Pro के कमजोर होने की बात launch के बाद से internet पर बार-बार दोहराई जाती रही है, लेकिन वास्तव में यह एक शानदार विकल्प है
      यह M2 Pro से कहीं ज़्यादा efficient है और performance भी थोड़ी बेहतर है। laptop में मुझे यही चीज़ें चाहिए, और memory bandwidth मेरे किसी खास काम की नहीं है
    • मेरा अनुभव भी ऐसा ही था। actual compile time में M1 Pro अभी भी मौजूदा laptop M2, M3 models के काफ़ी क़रीब बना रहता है
      इस लेख में जितना बड़ा अंतर दिखाया गया, उतना बड़ा अंतर मैंने नहीं देखा। यह language या project पर निर्भर हो सकता है, लेकिन same compile command को side by side benchmark करने पर इतना बड़ा फर्क नहीं दिखा
    • यह दिलचस्प है कि M2 का improvement इस लेख में दिखाए गए से कम था
      compile toolchain अलग है, इसलिए यह चौंकाने वाली बात नहीं है, और Go toolchain में भी देखा जा सकता है कि extra memory linker performance में मदद करती है, यानी अलग-अलग specs build के अलग चरणों पर अलग असर डालते हैं
      M3 performance के अजीब तरह से limited होने की प्रतिक्रिया भी कई बार देखी है, और उम्मीद है कि M4 के बाद के models में यह जारी नहीं रहेगा
    • मैंने भी हाल ही में यही हिसाब लगाया और आखिरकार memory और disk दोनों को max किया हुआ M1 Pro खरीदा। अच्छी deal थी और शानदार computer है
    • iOS development के लिए मुझे M1 MacBook Air पसंद है। Pro line में जो चीज़ मुझे चाहिए, वह display है, खासकर PPI
      120Hz भी अच्छा रहेगा, लेकिन लगता नहीं कि यह Air laptops में आएगा

  • Chromium और Node.js के पूर्व core contributor रहे हैं, और अभी gRPC Core/C++ के core contributor हैं, लेकिन build time की वजह से कभी खास परेशान नहीं हुए
    काम के दौरान संबंधित unit tests फिर से चलाने के लिए incremental build वाला “interactive build” होता है, और non-interactive build भी होता है जिसे चलाकर आप coffee पी सकते हैं या email पढ़ सकते हैं. हार्डवेयर बदलने से non-interactive build का interactive build में बदल जाना उन्होंने कभी नहीं देखा
    उनका personal machine 5 साल से भी पुराना Intel i7 और 16GB memory वाला है, लेकिन WSL में Node.js link करने के लिए ज्यादा memory चाहिए यह जानकर उन्होंने 16GB और जोड़ लिया
    काम का laptop Touch Bar वाला Intel MacBook Pro है, और उन्हें नहीं लगता कि इसका productivity पर बहुत बड़ा असर है. अहम चीजें screen का size और quality, और storage की speed हैं. CPU में प्रगति से ज्यादा असर incremental build speed और distributed build support जैसी build system की चीजों का है. personal projects में वे Bazel इस्तेमाल करते हैं

    • लगता है programmers इस बात के आदी हो गए हैं कि एक single function में बहुत छोटे बदलाव से binary में सिर्फ कुछ bytes बदलते हैं, फिर भी compile और link होने में लंबा समय लगता है
      compile और link लगभग तुरंत खत्म हो जाने चाहिए, और इतने तेज होने चाहिए कि compile step का एहसास ही न हो
      whole-program optimization जैसी तकनीकों वाले release builds का लंबा चलना ठीक है, लेकिन सामान्य compile/debug/test loop तुरंत हो सकता है. system languages का compilation legacy कारणों से अविश्वसनीय रूप से धीमा है, लेकिन यह ज़रूरी नहीं कि ऐसा ही हो
    • मैंने भी Blaze इस्तेमाल किया था और personal project में Bazel आज़माने की कोशिश की थी, लेकिन backend और frontend Dockerized project होने की वजह से build rules जल्दी ही अजीब और बहुत special-case वाले हो गए
      BUILD files छेड़ने में इतना समय लगने लगा कि यह सवाल उठा कि क्या यह साधारण Makefile से सच में ज्यादा क़ीमती है. यह 3 साल पहले की बात है, तो हो सकता है कि अब public ecosystem बेहतर हो गया हो
    • लगता है M series, Intel MBP की तुलना में screen और storage speed में काफी बेहतर है. काम के लिए Intel MBP से M1 पर जाने पर screen तो निश्चित ही बहुत बेहतर थी
      storage speed का ठीक पता नहीं, और हमारे सभी builds ताकतवर remote development machines पर चलते हैं
    • यह Bazel की आदत पड़ जाने की बात है. मेरे साथ भी ऐसा हुआ था
    • Chromium एक बहुत बड़ा project है. अगर project कुछ अधिक सामान्य आकार का हो, तो laptop पर full build उचित समय में किया जा सकता है

  • जैसा लेख में कहा गया है, जो लोग AI से data analysis करना चाहते हैं, उनके लिए data को R या Stata वगैरह में डालकर सीधे query करना कहीं ज्यादा आसान होगा
    commands छोटे और ज्यादा सटीक होंगे, और सबसे अहम बात यह कि reproducibility भी ज्यादा होगी
    data analysis में सबसे कठिन काम data और उसे पैदा करने वाले mechanism को समझना है. इसके लिए problem domain का causal model चाहिए
    अगर AI को पहले उस domain के दूसरे data पर train नहीं किया गया है, तो पता नहीं वह उपयोगी causal model बना पाएगा या नहीं. उस model के बिना data की तर्कसंगत व्याख्या करना असंभव है, और यह भी जिज्ञासा है कि क्या मौजूदा AI models confounding, outliers के अत्यधिक प्रभाव, या रोचक effect modifier variables को पहचान सकते हैं

    • GPT-4 आधारित AI assistant असल में यही काम कर रहा है
      जब मैंने किया था, तब वह Python और pandas था, और आप उससे analysis में इस्तेमाल किया गया code दिखाने के लिए कह सकते हैं
      फर्क बस इतना है कि data को R/Python में डालकर “xyzzzy कैसे करें” खोजते हुए खुद code लिखें, या ChatGPT का इस्तेमाल करें

  • “हर developer laptop पर पूरा incident.io environment local में चला सके, और code change से run तक 30 सेकंड से कम का feedback loop पाए” — यह हिस्सा सबसे बड़ी उपलब्धि लगता है
    startup में थोड़े समय मदद करने के मामलों को छोड़ दें, तो मैंने ऐसी कोई company नहीं देखी जहाँ एक ही machine पर पूरी company का development/local instance चलाया जा सके
    हमेशा कुछ न कुछ inaccessible रहा, और हमेशा traps रहे

    • पिछली नौकरी से पहले तक उस कमबख्त app को local में चलाना संभव नहीं था, और मैं सचमुच पागल हो रहा था
      समझ नहीं आता लोग इस भयानक developer experience पर और ज़्यादा गुस्सा क्यों नहीं होते. आजकल college से निकले लोग शायद जानते ही नहीं कि वे क्या miss कर रहे हैं
    • मैंने ऐसी company में काम किया है, और छोड़ने के बाद उसे बहुत याद किया
      जो लोग उस दुनिया में नहीं रहे, वे यह समझ ही नहीं पाते कि वह कितनी बेहतर है, और हर तरह से उसका rationalization करते रहते हैं
    • इसके बिना रहना कल्पना से बाहर है. हम k3s से सब कुछ local में चलाते हैं और यह बढ़िया काम करता है
      हाँ, पिछले साल Snowflake जोड़ा था, और वह असली समस्या हल करता है, लेकिन उस हिस्से पर iterative development करना तकलीफ़देह है
    • पहले यह संभव था, लेकिन scale बढ़ने पर इसे support करना मुश्किल हो जाता है. इसके लिए लगने वाला effort company के size के साथ कुछ हद तक quadratic बढ़ता है
      support करनी पड़ने वाली services की संख्या के साथ linear, और support करने वाले engineers की संख्या के साथ भी linear. फिर अलग-अलग use cases आने लगते हैं जो ठीक से fit नहीं बैठते, और देखते-देखते infra team feature releases की bottleneck बन जाती है, और लोग अपने-अपने अलग तरीके अपनाने लगते हैं
      एक बार यह Pandora's box खुल जाए, तो इसे वापस बंद करना लगभग असंभव है. फिर भी development cycle को घंटों या दिनों से घटाकर मिनटों में लाना, मिनटों को 25% घटाने से कहीं ज्यादा महत्वपूर्ण है
    • मैं अभी जो app बना रहा हूँ उसमें इसे संभव बनाने की पूरी कोशिश कर रहा हूँ. object detection model और Stable Diffusion चलानी पड़ती है, इसलिए मुझे CEO को समझाना पड़ा कि M2 Max मददगार होगा
      अब तक यह अच्छा चल रहा है

  • लेखक के रूप में, इसे पोस्ट करने के लिए धन्यवाद
    इसमें Go compile profiling, hot reloader बनाना, AI से build dataset का analysis करना जैसी कई बातें शामिल हैं
    निष्कर्ष यह रहा कि M1 से M3 Pro पर upgrade करना सार्थक था, और tests में Max ने बड़ा अंतर नहीं बनाया. M2, M3 के काफी करीब था, इसलिए हमारे लिए upgrade करना उचित नहीं था
    अगर कोई सवाल हो तो मैं जवाब दे सकता हूँ

    • विस्तृत analysis के लिए धन्यवाद, और मैं यह जानना चाहता हूँ कि क्या आपने इस analysis में लगी engineering time cost की गणना की
      और यह भी कि उस cost का payback period पर क्या असर पड़ा
    • मैं जानना चाहता हूँ कि आप इस निष्कर्ष पर कैसे पहुँचे कि Max SKU खास तेज नहीं था. charts की distribution तो ज्यादा तेज लगती है, लेकिन नीचे के text में सिर्फ इतना कहा गया है कि वे समान लगते हैं
    • क्या यह मानना सही होगा कि M3 Max का फायदा कम इसलिए था क्योंकि workload cores का ठीक से उपयोग नहीं कर पाया
      या फिर काम इतने जल्दी खत्म हो गए कि वास्तविक उपयोग में अंतर महसूस ही नहीं हुआ
    • क्या manager ने यह काम करने के लिए कुछ deliverables आगे खिसकाए थे, या यह side hustle की तरह किया गया था
    • दिलचस्प comparison था. अगर संभव हो, तो 8GB memory machine पर build के नतीजे भी अतिरिक्त रूप से देखना चाहूँगा

  • विचार दिलचस्प है, लेकिन डेटा विश्लेषण की गुणवत्ता काफ़ी कम लगती है और यह भी पक्का नहीं कि इससे वास्तव में वही सीखा जा रहा है जो लोग सोच रहे हैं
    खासकर M1 Pro से M2 Pro पर जाने पर 20 सेकंड से कम वाले build इतने नाटकीय रूप से क्यों बढ़ जाते हैं, यह समझना मुश्किल है। code compile workloads में दोनों के बीच वास्तविक performance का अंतर लगभग 20–25% है
    यह भी ज़्यादा तर्कसंगत नहीं लगता कि M3 machine में M2 machine की तुलना में 20 सेकंड से कम वाले build कम हों, या आधे cores वाले M3 Pro में M3 Max से ज़्यादा 20 सेकंड से कम वाले build हों
    इसकी काफ़ी संभावना है कि developer behavior के अंतर — जैसे अलग-अलग laptop इस्तेमाल करने वाले लोग आम तौर पर अलग तरह का काम करते हों — इन फ़र्कों की वजह हों
    सरसरी तौर पर पढ़ने पर मेरी कुछ टिप्पणियाँ यह हैं: Go compiler शायद अतिरिक्त cores का बहुत अच्छा उपयोग नहीं कर पाता, data को मिलाने का तरीका मूल रूप से असुविधाजनक है, और comparison का तरीका भी histogram और binned density graph को मिलाता है, साथ ही y-axis range भी अलग-अलग है, इसलिए consistency की कमी है
    Mac battery state की वजह से CPU performance को throttle नहीं करता। अगर battery पर build वाकई धीमे हैं, तो सिर्फ़ graph से इस पर यक़ीन करना मुश्किल है, लेकिन संभवतः इसकी वजह “Low Power” setting चालू होना है

    • M3 में memory bandwidth कम है, इसलिए कुछ use cases में यह वास्तव में downgrade है

  • थोड़ा अलग मुद्दा है, लेकिन यह जानने की जिज्ञासा है कि दूसरी कंपनियाँ endpoint management और security software का developer productivity के साथ संतुलन कैसे बनाती हैं
    हमारी कंपनी developers के laptops पर Mac और Windows दोनों में 5 से ज़्यादा background services चलाती है। इनमें endpoint management, privilege escalation interception, TLS interception और inspection, anti-malware, और VPN client शामिल हैं
    इस combination का performance पर बड़ा असर पड़ता है। machine पर कुछ भी करें, ये services CPU और I/O performance खा जाती हैं, और developers लगातार random freezes और stuttering की शिकायत करते रहे हैं
    मैं समझता हूँ कि ransomware और intellectual property theft बढ़ने के कारण security ज़रूरी है, लेकिन यह जानना चाहता हूँ कि क्या किसी कंपनी ने ऐसा बेहतर तरीका निकाला है जो developer productivity पर कम असर डालते हुए security दे सके

    • मैंने अब तक जो एकमात्र तरीका देखा है, वह यह था कि जब स्थिति खराब हो जाए तो IT/support team को report किया जाए, और उन्हें उन folders और files के बारे में बताया जाए जिन्हें exclusions में डालना चाहिए ताकि build temporary files जैसी चीज़ें scanning की वजह से धीमी न हों