4 पॉइंट द्वारा GN⁺ 2026-03-13 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • नवीनतम MacBook Neo डेटाबेस वर्कलोड को कितना अच्छी तरह संभालता है, इसे ClickBench और TPC-DS SF300 बेंचमार्क के जरिए मापा गया
  • प्रयोग में 6-कोर Apple A18 Pro चिप, 8GB मेमोरी और 512GB SSD वाला मॉडल इस्तेमाल किया गया, और DuckDB v1.5.0 तथा v1.4.4 LTS वर्ज़न पर टेस्ट चलाए गए
  • ClickBench में cold run पर MacBook Neo ने cloud instance से तेज़ नतीजे दिखाए, जिसका कारण लोकल NVMe SSD की तेज़ access speed माना गया
  • TPC-DS SF300 टेस्ट में कुछ queries में 80GB तक disk spilling हुई, फिर भी सभी queries 79 मिनट के भीतर पूरी हो गईं और सिस्टम स्थिर रहा
  • रोज़मर्रा के big data कामों के लिए इसकी सीमाएँ हैं, लेकिन DuckDB client के लिए laptop के रूप में यह पर्याप्त उपयोगी साबित हुआ

MacBook Neo की स्पेसिफिकेशन्स और टेस्ट का उद्देश्य

  • Apple के MacBook Neo को छात्रों और लेखकों के लिए पेश किया गया था, लेकिन DuckDB टीम ने इसे 'laptop पर big data' की अपनी सोच के अनुसार परखा
    • यूरोप में बिकने वाले मॉडल में charger शामिल नहीं है, और सिर्फ laptop और USB-C cable दी जाती है
    • उपलब्ध विकल्प केवल 256GB या 512GB SSD हैं, और टेस्ट में 512GB मॉडल इस्तेमाल हुआ
  • इसमें 8GB मेमोरी और Apple A18 Pro (6-कोर) चिप है
    • इसी चिप वाले iPhone 16 Pro ने पिछले टेस्ट में TPC-H SF100 को 10 मिनट से कम समय में पूरा किया था

ClickBench बेंचमार्क

  • ClickBench एक analytical database benchmark है, जिसमें 100 मिलियन rows वाली एक single table पर 43 queries चलाई जाती हैं
    • Parquet फ़ॉर्मेट में इसका आकार 14GB और CSV में 75GB है
  • DuckDB v1.5.0 को macOS के लिए port करके चलाया गया, और memory limit 5GB रखी गई ताकि swap पर निर्भरता कम हो
  • तुलना के लिए सिस्टम:
    • MacBook Neo (2P+4E cores, 8GB RAM)
    • AWS c6a.4xlarge (16 vCPU, 32GB RAM)
    • AWS c8g.metal-48xl (192 vCPU, 384GB RAM)

नतीजे और विश्लेषण

  • cold run के नतीजे:
    • MacBook Neo ने सभी queries 1 मिनट के भीतर पूरी कीं, और 0.57 सेकंड के median के साथ सबसे तेज़ प्रदर्शन दिया
    • cloud instances में network storage latency के कारण प्रदर्शन धीमा रहा
  • hot run के नतीजे:
    • MacBook Neo का कुल execution time लगभग 10% बेहतर हुआ
    • c8g.metal-48xl कुल मिलाकर सबसे तेज़ रहा, लेकिन median के आधार पर MacBook Neo, c6a.4xlarge से बेहतर था
    • कुल execution time, c6a.4xlarge की तुलना में लगभग 13% धीमा था

TPC-DS बेंचमार्क

  • DuckDB v1.4.4 LTS वर्ज़न इस्तेमाल किया गया, और memory limit 6GB सेट की गई
  • SF100:
    • median query time 1.63 सेकंड, कुल समय 15.5 मिनट
  • SF300:
    • median query time 6.90 सेकंड
    • अधिकतम 80GB तक disk spilling हुई
    • query 67 को 51 मिनट लगे, और सभी queries 79 मिनट के भीतर पूरी हो गईं

खरीदते समय ध्यान देने योग्य बातें

  • लगातार big data processing के लिए disk I/O (1.5GB/s) और 8GB मेमोरी सीमित कारक हैं
    • Air और Pro मॉडल (3–6GB/s) या किसी दूसरे OS आधारित laptop अधिक उपयुक्त हो सकते हैं
  • लेकिन अगर DuckDB cloud पर चल रहा हो और लोकल मशीन सिर्फ client हो, तो MacBook Neo काफ़ी उपयोगी है
    • कभी-कभार लोकल data processing के लिए भी यह स्थिरता से काम कर सकता है

निष्कर्ष

  • MacBook Neo, एक कम कीमत वाले laptop होने के बावजूद, DuckDB आधारित बड़े data workloads को पूरा कर सकता है
  • cloud environment से तुलना में भी लोकल SSD का लाभ साफ़ दिखाई देता है
  • इसे डेवलपर और data analyst के लिए ऐसा न्यूनतम-स्पेक डिवाइस माना गया है, जो portability और प्रयोग के लिए पर्याप्त performance दोनों देता है

2 टिप्पणियां

 
GN⁺ 2026-03-13
Hacker News की राय
  • मैं इस छोटे MacBook Neo पर ‘असल डेवलपमेंट काम’ करके देखना चाहता था
    मैंने M1 MacBook Air पर कई iOS ऐप बनाए हैं, और दो startup acquisition प्रक्रियाओं से गुज़रा हूँ
    FCP से 4K race footage को 30–45 मिनट के वीडियो में एडिट करने में भी कोई दिक्कत नहीं हुई, और Neo उस Air से भी बेहतर performance दिखाता है

    • पहले मैं Norwegian keyboard वाले एक used laptop पर PHP backend और jQuery front-end डेवलप करता था
      उसी पर बने प्रोजेक्ट्स की वजह से मुझे मेरी पहली डेवलपर नौकरी मिली, और उसी दिन मैंने पहली बार Hacker News के बारे में जाना
      आखिरकार महत्वपूर्ण चीज़ hardware नहीं, execution है
    • छुट्टियों के दौरान मैंने laptop की जगह Galaxy S22 + HDMI adapter + Bluetooth keyboard के combination से डेवलपमेंट किया
      TV से जोड़कर neovim और termux में Elixir development किया, और tests 5 सेकंड में पूरे हो जाते थे
      Rust build धीमे थे, लेकिन portability और battery efficiency की वजह से यह काफ़ी मज़ेदार अनुभव था
    • मैं अभी भी 2019 का Intel MacBook Pro(16GB) इस्तेमाल कर रहा हूँ
      Xcode build, Docker, Claude Code, और Codex एक साथ चलाने पर भी यह अच्छी तरह टिक जाता है
      बस fan noise jet engine जैसी है, इसलिए मैंने नया M5 Max 16" MBP(48GB) ऑर्डर किया है
      मैं 7 साल के cycle पर upgrade करता हूँ, इसलिए लगता है यह भी लंबे समय तक चलेगा
    • मैंने M1 Mac Mini(8GB) पर एक साल तक iOS ऐप build किए
      build के दौरान थोड़ी sluggishness होती थी, और Firefox पर लौटने पर tab switching धीमी हो जाती थी, लेकिन काम पूरी तरह हो जाता था
      वही काम Intel MacBook Pro(16GB) पर करने पर अनुभव कहीं ज़्यादा smooth और comfortable था
      महसूस होने वाला सबसे बड़ा फ़र्क OS की responsiveness में था
    • लोग अक्सर 8GB memory को कम आँकते हैं
      compressed memory की वजह से व्यवहार में इसमें 2–3 गुना ज़्यादा data समा सकता है, और NVMe SSD की वजह से swap reads भी तेज़ रहती हैं
      बल्कि असली कमी तो keyboard backlight न होना है
  • मैं पढ़ाते समय data को इस तरह classify करता हूँ — अगर सब कुछ एक machine की memory में आ जाए तो Small data, disk में आ जाए तो Medium data, और उससे बड़ा हो तो Big data
    हाल ही में 20 साल पुराने Python app को modernize करते हुए मैंने backend को polars या duckDB से replace किए जा सकने लायक बनाया, और speed 40–80 गुना बढ़ गई
    इस काम में सिर्फ़ दो दिन लगे

    • आजकल एक system में 64TB DDR5 RAM तक लगाई जा सकती है, इसलिए अगर data lake scale न हो तो लगभग सब कुछ Small data है
    • यह जानने की जिज्ञासा है कि polars से इतना बड़ा speedup क्यों मिला
      सही तरह इस्तेमाल करने पर यह तेज़ है, लेकिन गलत तरीके से use करने पर performance काफ़ी गिर सकती है
    • पुराना है, लेकिन अब भी प्रासंगिक लिंक: Your Data Fits in RAM
      महँगा ज़रूर है, लेकिन ज़्यादातर समस्याएँ अब भी RAM में समा जाती हैं
    • NVMe की वजह से disk access तेज़ हो गया है, इसलिए ‘Medium data’ की definition भी अब धुंधली हो गई है
      2000s वाली Big Data infrastructure अब पुरानी लगती है
  • मैंने DuckDB की mobile benchmark post देखकर थोड़ा भरोसा खो दिया
    Swift app और CLI app की तुलना करना सेब और केले की तुलना जैसा लगा

    • लेकिन वह experiment smartphone पर local CLI app चलाने का था
      यह iPhone और Android की तुलना नहीं थी, बल्कि vectorized query processing research paper system के साथ तुलना थी
  • यह AWS compute performance पर भी एक आलोचना है

    • AWS ने EBS network storage इस्तेमाल किया, इसलिए local PCIe bus की तुलना में latency काफ़ी ज़्यादा थी
      खासकर random access workloads में इससे बड़ा फ़र्क पड़ता है
    • फिर भी, क्या AWS laptop से तेज़ नहीं था?
      सिर्फ़ network disk के धीमे होने से पूरे AWS की आलोचना करना ठीक नहीं लगता
      AWS में local SSD instances भी हैं
    • लेकिन cloud अब भी बेहद महँगा है
      मेरा M1 Max laptop ज़्यादातर cloud instances को पीछे छोड़ देता है
      bandwidth pricing में 10,000 गुना तक का फ़र्क है, और अब ज़्यादातर डेवलपर पीढ़ी सिर्फ़ cloud SaaS को ही जानती है
      मैंने उस बदलाव को real time में होते देखा है
    • दरअसल article की बात उलटी थी
      “अगर आप रोज़ laptop पर Big Data workload चलाते हैं, तो Neo सही नहीं है”
      “लेकिन अगर आप cloud में DuckDB चलाएँ और laptop को client की तरह इस्तेमाल करें, तो यह शानदार है” — यही उसका सार था
  • मैं एक गरीब ecologist हूँ, लेकिन इस छोटे computer पर अपना सारा R और Word का काम कर सकता हूँ
    price के हिसाब से इसकी build quality और overall finish से मैं बहुत संतुष्ट हूँ

    • क्या आप shellfish research कर रहे हैं?
      हमारे इलाके में government-funded shellfish research program ज़्यादातर बंद हो चुके हैं, जो अफ़सोस की बात है
    • लेकिन क्या आपने यह अभी से खरीद लिया? मुझे लगा यह अभी pre-order stage में है
  • मुझे DuckDB सच में बहुत पसंद है
    मैंने AWS Lambda में S3 पर GZ के रूप में stored data को process करने का एक PoC किया,
    और 400 lines of C# code को 10 lines से replace कर दिया
    यह एक कमाल का open source tool है

    • मुझे लगता है कि यह पिछले कुछ सालों में आई सबसे शानदार open source gifts में से एक है
  • जो लोग कहते हैं, ‘2026 में 8GB से क्या होगा’, उन्हें ऐसी पोस्ट ज़रूर पढ़नी चाहिए

  • काश ज़्यादा कंपनियाँ ऐसे general hardware performance showcases करतीं
    यह दिखाना उपयोगी है कि असल में कितना workload संभाला जा सकता है

  • benchmark करते समय local NVMe instance (c8gd.4xlarge) इस्तेमाल करना चाहिए था

    • यह अच्छी बात उठाई गई, इसलिए मैंने सच में c8gd.4xlarge(950GB NVMe) और c5ad.4xlarge(RAID 0 configuration) पर दोबारा test किया
      अपने local MacBook M1 Max(64GB, 10-core) के results भी साथ compare किए
      नतीजतन M1 Max अब भी cloud instances से तेज़ निकला
      latest M5 Pro/Max हो तो फ़र्क और बड़ा होगा
    • लेकिन AWS का local NVMe volatile storage है, इसलिए हर बार data पहले से upload करना पड़ता है
      फिर भी benchmark के मक़सद से यह शायद और भी आदर्श है
    • हालाँकि region-wide power outage की स्थिति में data persistence guarantee अभी भी अनिश्चित है
      अगर पूरी durability चाहिए, तो अब भी WAL streaming की ज़रूरत है
  • यह बात तुरंत पकड़ लेना अच्छा था कि cloud instances network disk इस्तेमाल कर रहे थे
    ऐसे में यह सवाल बनता है कि फिर local storage instances (c8id.2xlarge, c8id.4xlarge) पर दोबारा benchmark क्यों नहीं किया गया

 
dkang 2026-03-14

लगता है कि गरीब ecologist का ID clamlady होने की वजह से किसी ने यह पूछते हुए कमेंट किया कि क्या वह shellfish researcher हैं। (मैंने सोचा कि "jogae" शायद गलत अनुवाद है, इसलिए मूल पाठ देखने के लिए जाकर देखा।)