macOS VM कितनी तेज़ हो सकती है, और कितनी छोटी बनाई जा सकती है?

 (eclecticlight.co)
1 पॉइंट द्वारा GN⁺ 1 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Mac mini M4 Pro पर macOS 26.4.1 VM को फिर से मापने पर पता चला कि 5 virtual core और 16GB vRAM कॉन्फ़िगरेशन में भी CPU single-core और GPU performance होस्ट के काफ़ी करीब है
  • Geekbench 6.7.1 के अनुसार single-core CPU VM 3,855 / host 3,948, और GPU Metal VM 106,896 / host 111,970 रहा, यानी क्रमशः होस्ट का लगभग 98% और 95%
  • multi-core CPU VM 13,222 / host 23,342 था; host में 14 core (10 P + 4 E) हैं और VM में 5 virtual core, इसलिए सीधी तुलना कठिन है, फिर भी VM performance काफ़ी अच्छी है
  • सबसे कमज़ोर हिस्सा virtual Neural Engine रहा, जो CoreML half-precision और quantization test में host से काफ़ी धीमा था; VM में AI workload के CPU और GPU पर चलने की उम्मीद की जा सकती है
  • न्यूनतम कॉन्फ़िगरेशन टेस्ट में सिर्फ 2 virtual core और 4GB memory के साथ भी Safari और Settings के storage analysis जैसे हल्के काम सामान्य रूप से चले, और macOS update को देखते हुए VM storage कम से कम 60GB होना उचित है

टेस्ट की पृष्ठभूमि

  • Apple silicon पर macOS virtualisation review में इस्तेमाल किए गए performance numbers पुराने माप थे, और उपयोगी VM की न्यूनतम spec पर बात नहीं की गई थी
  • MacBook Neo पर VM चलाने में बढ़ती दिलचस्पी के बीच, macOS Tahoe के आधार पर performance और minimum configuration को फिर से जाँचा गया

प्रदर्शन मापन और व्याख्या

  • टेस्ट host Mac mini M4 Pro है, जिसमें macOS 26.4.1, 14 core (10 P + 4 E), 48GB RAM, और 2TB internal SSD है
  • guest VM को 5 virtual core और 16GB virtual RAM दी गई
  • Geekbench 6.7.1 score host और VM दोनों में पहले से थोड़ा तेज़ निकला
  • मापन के नतीजे इस प्रकार हैं
    • single-core CPU: VM 3,855, host 3,948
    • multi-core CPU: VM 13,222, host 23,342
    • GPU Metal: VM 106,896, host 111,970
    • Neural Engine CoreML: VM 5,291 / 8,577 / 6,877, host 5,973 / 41,251 / 56,616
  • Neural Engine CoreML के ये तीन आँकड़े क्रमशः single precision, half precision, और quantization test के परिणाम हैं
  • multi-core CPU result की सीधी तुलना कठिन है, क्योंकि host में VM से दोगुने से अधिक core हैं और उनमें से 4 E-core हैं
  • GPU performance comparison उस स्थिति का परिणाम है जहाँ host GPU को प्रतिस्पर्धी रूप से साथ में इस्तेमाल नहीं कर रहा था
  • VM में चलाते समय उम्मीद की जा सकती है कि macOS AI workload को Neural Engine की बजाय CPU और GPU पर प्रोसेस करे

न्यूनतम कॉन्फ़िगरेशन टेस्ट

  • MacBook Neo के आने के बाद इस डिवाइस पर VM चल सकेगा या नहीं, इसको लेकर रुचि थी
  • Linux host उपयोग के लिए यह ठीक लग रहा था, लेकिन macOS VM के रूप में उपयोगी काम हो पाएगा या नहीं इस पर संदेह था; वास्तविक टेस्ट में यह संभव निकला
  • minimum configuration देखने के लिए, उसी macOS 26.4.1 VM को Viable में धीरे-धीरे कम CPU core और memory allocation के साथ चलाया गया
  • VM display window को मानक 1600 × 1000 पर सेट किया गया
  • Safari को कई तरीकों से इस्तेमाल किया गया, और Settings के storage analysis सहित हल्के रोज़मर्रा के काम किए गए
  • कॉन्फ़िगरेशन के अनुसार परिणाम इस प्रकार रहे
    • 4 virtual core और 8GB vRAM पर VM पूरी तरह फुर्तीला चला, और memory usage लगभग 5GB रहा
    • 3 core और 6GB पर memory usage घटकर 3.9GB हो गया और सभी काम अच्छे से चले
    • 2 core और 4GB memory पर सिर्फ 3.1GB उपयोग हुई, और हल्के काम लगातार सामान्य रूप से चलते रहे
  • सिर्फ 2 virtual core और 4GB memory दी गई macOS VM भी MacBook Neo पर संभव लगती है, और रोज़मर्रा के काम पर्याप्त रूप से कर सकती है
  • यह VM LLM चलाने की जगह नहीं है, लेकिन हल्के macOS कामों के लिए पर्याप्त उपयोगी है

स्टोरेज और अपडेट की सीमाएँ

  • छोटी internal SSD वाले Mac में VM बनाते समय VM का आकार ध्यान से तय करना चाहिए
  • 50GB से काफ़ी छोटी macOS VM पर macOS update करना संभव नहीं रहेगा
  • थोड़ा margin और सुरक्षा के लिए कम से कम 60GB का लक्ष्य रखना बेहतर है
  • APFS में VM sparse file के रूप में स्टोर होती है, इसलिए default 100GB VM भी वास्तविक disk पर लगभग 54GB ही लेती है
  • ऐसी कॉन्फ़िगरेशन 512GB SSD वाले MacBook Neo में ज़्यादा व्यावहारिक रूप से समा सकती है

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

1 टिप्पणियां

 
GN⁺ 1 시간 전
Hacker News की राय

  • यह एक अच्छा reminder है कि कुछ मेमोरी हर core से बंधी होती है। शायद यह ज़्यादातर page cache या concurrency handling जैसी चीज़ों की वजह से हो

    • मैं null hypothesis पर दांव लगाऊँगा। अगर core count को स्थिर रखकर सिर्फ VM memory size बदली जाती, तो शायद मेमोरी उपयोग में वही बदलाव दिखता
    • आम तौर पर कंप्यूटर में लगी physical memory capacity भी CPU द्वारा दिए गए hardware threads की संख्या के अनुपात में होनी चाहिए
      सिर्फ operating system ही हर thread को कुछ मेमोरी allocate नहीं करता, बल्कि बड़े software project compile करने जैसी स्थितियों में सभी threads का उपयोग करने वाले multithreaded apps भी अक्सर worker threads की संख्या के अनुपात में working memory लेते हैं
      मैंने कई multithreaded apps देखे हैं जो ठीक से चलने के लिए प्रति thread लगभग 2GB तक चाहते हैं, और Ryzen 9 9950X जैसे 32-thread desktop CPU के लिए 64GB ठीक बैठता है
      जब Chrome/Chromium जैसे project compile करते हैं, तो 16-core/32-thread CPU के साथ अगर सिर्फ 32GB है, तो make -j जैसे उचित parameter से concurrent compile count घटाकर कुछ cores को खाली छोड़ना पड़ता है। नहीं तो out-of-memory error मिल सकता है
    • per-core overhead होना सही है, लेकिन यह usage drop ज़्यादा इस वजह से लगता है कि available memory कम होने पर kernel का memory allocation behavior बदल जाता है
      मेमोरी ज़्यादा हो तो kernel read cache को ज़्यादा देर तक रखता है, disk swap की तुलना में memory compression को प्राथमिकता देता है, और reclaimable memory cleanup कम बार करता है। internal buffer sizes और vnode table भी total memory के हिसाब से adjust होते हैं
      available resources का dynamic रूप से अधिकतम उपयोग करना अच्छी बात है, लेकिन इसकी कीमत यह है कि असली runtime के लिए ज़रूरी minimum baseline देखना कठिन हो जाता है
      जाँचने के लिए मज़ेदार command vm_stat है, जिसमें free/active/inactive/wired/purgeable pages, compressor, pagein/pageout, swapin/swapout जैसे मान देखे जा सकते हैं। संपादन: पता नहीं code fence Markdown support नहीं है, या मुझसे ही कुछ गलत हुआ

  • मैंने हाल ही में M5 Air खरीदा है, और macOS मेरे लिए नया है, इसलिए मैं यह समझने की कोशिश कर रहा हूँ; लेकिन pytorch, GPU acceleration, और VM/container-level isolation तीनों को एक साथ पाना लगभग असंभव लगता है
    virtio-gpu layer सबसे करीब लगती है, लेकिन लगता है कि यह compute GPU नहीं बल्कि सिर्फ graphics GPU पास करती है, इसलिए pytorch नहीं चलता

    • मुझे भी इसकी ज़रूरत थी, इसलिए मैंने एक साल पहले काफी खोजबीन की थी। हाल के Docker Model Runner(vllm-metal) या podman libkrun में जो बदलाव आए हैं, उन्हें देखने का अभी समय नहीं मिला; क्या दोनों में भी काम नहीं हुआ?
    • मैं Cirruslabs Tart instance पर torch चलाने में सफल रहा हूँ

  • macOS पर मैंने VM के रूप में सिर्फ colima+docker इस्तेमाल किया है, और यह काफ़ी तकलीफ़देह और अक्षम है। फिर भी इस्तेमाल किया जा सकता है

    • Apple का container CLI आज़माना अच्छा रहेगा। कुछ हफ्ते पहले मैंने एक weekend में अपना एक project colima+docker से काफ़ी आसानी से migrate कर लिया था
      https://github.com/apple/container
    • local CI के लिए मैंने Mac Mini खरीदा था और Forgejo Actions के साथ इस्तेमाल करने हेतु पूरे ecosystem को व्यापक रूप से देखा, लेकिन आखिरकार मैं host पर build करने वाले रास्ते पर गया
      signing और notarization setup को host से isolate करना agent के साथ भी संभालना मुश्किल लगा। फिर भी अब macOS build सचमुच तेज़ है, और signing/notarization भी लगभग 200 lines of Bash में हो जाती है
    • OrbStack काफ़ी अच्छा है। मुझे यह खास तौर पर अक्षम नहीं लगा

  • https://github.com/trycua/cua/tree/main/libs/lume ने इस समस्या पर एक दिलचस्प approach दिखाई थी

  • अगर VM start होते समय सिर्फ 5GB इस्तेमाल करता है, तब भी VM के अंदर app चलाते ही क्या वह startup के 5GB के बजाय allocate किए गए पूरे 8GB की मांग नहीं करेगा?

    • मुझे नहीं लगा था कि macOS virtualization memory ballooning support करने जितना advanced है; क्या बात वही है?
      संपादन: मैं गलत था

  • लगता है मेरे पास सबसे छोटा वाला है। docker.io/gotson/crossbuild latest d96ea9b7054b 3 years ago 6.71 GB है, और मैं इसे Darwin cross build के लिए इस्तेमाल कर रहा हूँ

  • सच कहूँ तो macOS को VM में जिन चीज़ों की सख्त ज़रूरत नहीं है उन्हें बंद कर दिया जाए, तो यह इससे कहीं नीचे जा सकता है
    पहले iPhone में सिर्फ 128MiB RAM थी, और मेरी जानकारी में वह stripped-down macOS Tiger का एक version चलाता था। अब तक RAM काफ़ी भरपूर रही है, इसलिए इसे घटाने की ज़रूरत नहीं पड़ी; लेकिन यह निश्चित रूप से संभव है, और शायद इतना मुश्किल भी नहीं। बस इसे फिर से आज़माने की ज़रूरत है

    • शुरुआती iPhone में app multitasking नहीं थी, इसलिए फर्क काफ़ी बड़ा है। app बंद होने पर पूरी तरह terminate हो जाता था

  • क्या PC पर macOS चलाना संभव है? या कम से कम PC पर किसी तरह Mac के लिए development किया जा सकता है?

    • QEMU से macOS boot किया जा सकता है, लेकिन hardware-accelerated graphics और कुछ features उपलब्ध नहीं होते

  • थोड़ा अजीब सवाल है, लेकिन क्या macOS VM को निजी डिवाइस के रूप में Intune enrollment में जोड़ना संभव होगा?

  • मुझे हैरानी है कि कोई macOS-only agent environment क्यों नहीं बनाता। अच्छा होता अगर agents Mac environment के भीतर spawn होते