ਪਹਿਲੀ C++ (m) ਵੰਡ ਹਮੇਸ਼ਾ 72 KB ਕਿਉਂ ਹੁੰਦੀ ਹੈ?

ਤੁਹਾਡੀ ਪਹਿਲੀ C++ ਵੰਡ ਦੇ ਪਿੱਛੇ ਦਾ ਰਹੱਸ

ਤੁਸੀਂ ਇੱਕ ਸਧਾਰਨ C++ ਪ੍ਰੋਗਰਾਮ ਲਿਖਦੇ ਹੋ। ਇੱਕ ਸਿੰਗਲ ਨਵਾਂ ਇੰਟ। ਚਾਰ ਬਾਈਟ। ਤੁਸੀਂ ਸਟਰੇਸ ਜਾਂ ਆਪਣੇ ਮਨਪਸੰਦ ਮੈਮੋਰੀ ਪ੍ਰੋਫਾਈਲਰ ਨੂੰ ਅੱਗ ਲਗਾਉਂਦੇ ਹੋ, ਅਤੇ ਇਹ ਉੱਥੇ ਹੈ — ਤੁਹਾਡੀ ਪ੍ਰਕਿਰਿਆ ਨੇ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਤੋਂ ਲਗਭਗ 72 KB ਦੀ ਬੇਨਤੀ ਕੀਤੀ ਹੈ। 4 ਬਾਈਟ ਨਹੀਂ। 64 ਬਾਈਟ ਨਹੀਂ। ਇੱਕ ਪੂਰਾ 72 KB। ਜੇ ਤੁਸੀਂ ਕਦੇ ਉਸ ਨੰਬਰ 'ਤੇ ਨਜ਼ਰ ਮਾਰੀ ਹੈ ਅਤੇ ਸੋਚਿਆ ਹੈ ਕਿ ਕੀ ਤੁਹਾਡੀ ਟੂਲਿੰਗ ਤੁਹਾਡੇ ਨਾਲ ਝੂਠ ਬੋਲ ਰਹੀ ਸੀ, ਤਾਂ ਤੁਸੀਂ ਇਕੱਲੇ ਨਹੀਂ ਹੋ. ਇਹ ਪ੍ਰਤੀਤ ਹੁੰਦਾ ਅਜੀਬੋ-ਗਰੀਬ ਵਿਵਹਾਰ ਪਹਿਲੀ ਵਾਰ ਮੈਮੋਰੀ ਇੰਟਰਨਲਜ਼ ਵਿੱਚ ਖੁਦਾਈ ਕਰਨ ਵਾਲੇ C++ ਡਿਵੈਲਪਰਾਂ ਵਿੱਚ ਸਭ ਤੋਂ ਵੱਧ ਅਕਸਰ ਪੁੱਛੇ ਜਾਣ ਵਾਲੇ ਸਵਾਲਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ, ਅਤੇ ਜਵਾਬ ਸਾਨੂੰ ਤੁਹਾਡੇ ਕੋਡ ਅਤੇ ਅਸਲ ਹਾਰਡਵੇਅਰ ਦੇ ਵਿਚਕਾਰ ਬੈਠਣ ਵਾਲੀਆਂ ਪਰਤਾਂ ਰਾਹੀਂ ਇੱਕ ਦਿਲਚਸਪ ਯਾਤਰਾ 'ਤੇ ਲੈ ਜਾਂਦਾ ਹੈ।

ਜਦੋਂ ਤੁਸੀਂ ਨਵਾਂ

72 KB ਚਿੱਤਰ ਨੂੰ ਸਮਝਣ ਲਈ, ਤੁਹਾਨੂੰ ਪੂਰੀ ਵੰਡ ਲੜੀ ਨੂੰ ਟਰੇਸ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਜਦੋਂ ਤੁਹਾਡਾ C++ ਕੋਡ ਨਵਾਂ ਇੰਟ ਚਲਾਉਂਦਾ ਹੈ, ਤਾਂ ਕੰਪਾਈਲਰ ਇਸਨੂੰ ਓਪਰੇਟਰ ਨਿਊ ਨੂੰ ਕਾਲ ਵਿੱਚ ਅਨੁਵਾਦ ਕਰਦਾ ਹੈ, ਜੋ ਕਿ ਜ਼ਿਆਦਾਤਰ ਲੀਨਕਸ ਸਿਸਟਮਾਂ 'ਤੇ glibc ਤੋਂ malloc ਨੂੰ ਸੌਂਪਦਾ ਹੈ। ਪਰ malloc ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਕਰਨਲ ਨੂੰ 4 ਬਾਈਟ ਮੈਮੋਰੀ ਲਈ ਨਹੀਂ ਪੁੱਛਦਾ। ਕਰਨਲ ਪੰਨਿਆਂ ਵਿੱਚ ਕੰਮ ਕਰਦਾ ਹੈ — ਆਮ ਤੌਰ 'ਤੇ x86_64 ਉੱਤੇ 4 KB — ਅਤੇ ਇੱਕ ਸਿਸਟਮ ਕਾਲ ਦੀ ਲਾਗਤ ਇੱਕ ਸਧਾਰਨ ਮੈਮੋਰੀ ਪਹੁੰਚ ਦੇ ਮੁਕਾਬਲੇ ਬਹੁਤ ਜ਼ਿਆਦਾ ਹੈ। ਹਰੇਕ ਵਿਅਕਤੀਗਤ ਵੰਡ ਲਈ brk() ਜਾਂ mmap() ਨੂੰ ਕਾਲ ਕਰਨ ਨਾਲ ਕੋਈ ਵੀ ਗੈਰ-ਮਾਮੂਲੀ ਪ੍ਰੋਗਰਾਮ ਰੁਕ ਜਾਵੇਗਾ।

ਇਸਦੀ ਬਜਾਏ, glibc ਦਾ ਮੈਮੋਰੀ ਅਲੋਕੇਟਰ — ਇੱਕ ਲਾਗੂਕਰਨ ਜਿਸਨੂੰ ptmalloc2 ਕਿਹਾ ਜਾਂਦਾ ਹੈ, ਆਪਣੇ ਆਪ ਵਿੱਚ ਡੌਗ ਲੀ ਦੇ ਕਲਾਸਿਕ dlmalloc ਤੋਂ ਉਤਰਿਆ ਹੈ — ਇੱਕ ਵਿਚੋਲੇ ਵਜੋਂ ਕੰਮ ਕਰਦਾ ਹੈ। ਇਹ ਕਰਨਲ ਅੱਪਫ੍ਰੰਟ ਤੋਂ ਮੈਮੋਰੀ ਦੇ ਵੱਡੇ ਬਲਾਕਾਂ ਦੀ ਬੇਨਤੀ ਕਰਦਾ ਹੈ, ਫਿਰ ਉਹਨਾਂ ਨੂੰ ਛੋਟੇ ਟੁਕੜਿਆਂ ਵਿੱਚ ਬਣਾ ਦਿੰਦਾ ਹੈ ਕਿਉਂਕਿ ਤੁਹਾਡੇ ਪ੍ਰੋਗਰਾਮ ਨੂੰ ਉਹਨਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇਹ ਬੁਨਿਆਦੀ ਕਾਰਨ ਹੈ ਕਿ ਤੁਹਾਡੀ ਪਹਿਲੀ 4-ਬਾਈਟ ਵੰਡ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਲਈ ਬਹੁਤ ਵੱਡੀ ਬੇਨਤੀ ਨੂੰ ਚਾਲੂ ਕਰਦੀ ਹੈ। ਐਲੋਕਟਰ ਫਾਲਤੂ ਨਹੀਂ ਹੋ ਰਿਹਾ ਹੈ। ਇਹ ਰਣਨੀਤਕ ਹੈ।

72 KB ਨੂੰ ਵੱਖ ਕਰਨਾ: ਬਾਈਟਸ ਕਿੱਥੇ ਜਾਂਦੇ ਹਨ

ਸ਼ੁਰੂਆਤੀ ਐਲੋਕੇਸ਼ਨ ਓਵਰਹੈੱਡ ਕਈ ਵੱਖੋ-ਵੱਖਰੇ ਹਿੱਸਿਆਂ ਤੋਂ ਆਉਂਦਾ ਹੈ ਜੋ ਰਨਟਾਈਮ ਨੂੰ ਸ਼ੁਰੂ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਇਹ ਤੁਹਾਨੂੰ ਵਰਤੋਂ ਯੋਗ ਮੈਮੋਰੀ ਦਾ ਇੱਕ ਬਾਈਟ ਵੀ ਸੌਂਪ ਸਕਦਾ ਹੈ। ਹਰੇਕ ਕੰਪੋਨੈਂਟ ਨੂੰ ਸਮਝਣਾ ਇਹ ਦੱਸਦਾ ਹੈ ਕਿ ਨੰਬਰ ਉੱਥੇ ਕਿਉਂ ਆਉਂਦਾ ਹੈ।

ਪਹਿਲਾਂ, glibc ਦਾ malloc ਮੁੱਖ ਅਖਾੜੇ ਨੂੰ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ — ਪ੍ਰਾਇਮਰੀ ਬੁੱਕਕੀਪਿੰਗ ਢਾਂਚਾ ਜੋ ਮੁੱਖ ਥ੍ਰੈੱਡ 'ਤੇ ਸਾਰੀਆਂ ਵੰਡਾਂ ਨੂੰ ਟਰੈਕ ਕਰਦਾ ਹੈ। ਇਸ ਅਖਾੜੇ ਵਿੱਚ ਹੀਪ ਲਈ ਮੈਟਾਡੇਟਾ, ਫ੍ਰੀ-ਲਿਸਟ ਪੁਆਇੰਟਰ, ਅਤੇ ਵੱਖ-ਵੱਖ ਅਲੋਕੇਸ਼ਨ ਆਕਾਰਾਂ ਲਈ ਬਿਨ ਸਟ੍ਰਕਚਰ ਸ਼ਾਮਲ ਹਨ। ਅਲੋਕੇਟਰ ਪ੍ਰੋਗਰਾਮ ਬਰੇਕ ਨੂੰ sbrk() ਰਾਹੀਂ ਵਧਾਉਂਦਾ ਹੈ, ਅਤੇ ਸ਼ੁਰੂਆਤੀ ਐਕਸਟੈਂਸ਼ਨ ਨੂੰ M_TOP_PAD ਕਹਿੰਦੇ ਹਨ, ਜੋ ਕਿ 128 KB ਪੈਡਿੰਗ ਤੱਕ ਡਿਫੌਲਟ ਹੁੰਦਾ ਹੈ। ਹਾਲਾਂਕਿ, ਅਸਲ ਸ਼ੁਰੂਆਤੀ ਬੇਨਤੀ ਨੂੰ ਪੰਨਾ ਅਲਾਈਨਮੈਂਟ ਅਤੇ ਮੌਜੂਦਾ ਬਰੇਕ ਸਥਿਤੀ ਲਈ ਐਡਜਸਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜਿਸਦਾ ਨਤੀਜਾ ਅਕਸਰ ਇੱਕ ਛੋਟੀ ਪਹਿਲੀ ਬੇਨਤੀ ਵਿੱਚ ਹੁੰਦਾ ਹੈ — ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਤਾਜ਼ਾ ਸ਼ੁਰੂ ਕੀਤੀ ਪ੍ਰਕਿਰਿਆ 'ਤੇ ਉਸ 72 KB ਅੰਕੜੇ ਦੇ ਨੇੜੇ ਪਹੁੰਚਣਾ।

ਦੂਜਾ, glibc 2.26 ਤੋਂ ਬਾਅਦ, ਅਲੋਕੇਟਰ ਪਹਿਲੀ ਵਰਤੋਂ 'ਤੇ ਇੱਕ ਥਰਿੱਡ-ਲੋਕਲ ਕੈਸ਼ (tcache) ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ। tcache ਵਿੱਚ 64 ਬਿਨ (ਇੱਕ ਪ੍ਰਤੀ ਛੋਟੇ-ਅਲੋਕੇਸ਼ਨ ਆਕਾਰ ਵਰਗ) ਹੁੰਦੇ ਹਨ, ਹਰੇਕ ਵਿੱਚ 7 ​​ਕੈਸ਼ ਕੀਤੇ ਟੁਕੜੇ ਰੱਖਣ ਦੇ ਸਮਰੱਥ ਹੁੰਦੇ ਹਨ। tcache_perthread_struct ਆਪਣੇ ਆਪ ਵਿੱਚ ਲਗਭਗ 1 KB ਦੀ ਖਪਤ ਕਰਦਾ ਹੈ, ਪਰ ਇਸਨੂੰ ਸ਼ੁਰੂ ਕਰਨ ਦੀ ਕਿਰਿਆ ਵਿਆਪਕ ਅਰੇਨਾ ਸੈੱਟਅੱਪ ਨੂੰ ਚਾਲੂ ਕਰਦੀ ਹੈ। ਤੀਜਾ, C++ ਰਨਟਾਈਮ ਤੁਹਾਡੇ main() ਦੇ ਚੱਲਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਨਿਰਧਾਰਤ ਕਰ ਚੁੱਕਾ ਹੈ — ਸਥਿਰ ਕੰਸਟਰਕਟਰ, std::cout ਅਤੇ ਦੋਸਤਾਂ ਲਈ iostream ਬਫਰ ਅਰੰਭਕਰਨ, ਅਤੇ ਲੋਕੇਲ ਸੈੱਟਅੱਪ ਸਭ ਉਸ ਸ਼ੁਰੂਆਤੀ ਹੀਪ ਫੁੱਟਪ੍ਰਿੰਟ ਵਿੱਚ ਯੋਗਦਾਨ ਪਾਉਂਦੇ ਹਨ।

ਅਰੇਨਾ ਸਿਸਟਮ ਅਤੇ ਕਿਉਂ ਪ੍ਰੀ-ਅਲੋਕੇਸ਼ਨ ਸਮਾਰਟ ਹੈ

ਮੈਮੋਰੀ ਦਾ ਇੱਕ ਵੱਡਾ ਹਿੱਸਾ ਪਹਿਲਾਂ ਤੋਂ ਨਿਰਧਾਰਤ ਕਰਨ ਦਾ ਫੈਸਲਾ ਇਸ ਨੂੰ ਟੁਕੜੇ-ਟੁਕੜੇ ਕਰਨ ਦੀ ਬੇਨਤੀ ਕਰਨ ਦੀ ਬਜਾਏ ਲਾਗੂ ਕਰਨ ਦਾ ਇੱਕ ਹਾਦਸਾ ਨਹੀਂ ਹੈ। ਇਹ ਇੱਕ ਜਾਣਬੁੱਝ ਕੇ ਇੰਜੀਨੀਅਰਿੰਗ ਟ੍ਰੇਡਆਫ ਹੈ ਜੋ ਸਿਸਟਮ ਪ੍ਰੋਗਰਾਮਿੰਗ ਦੇ ਦਹਾਕਿਆਂ ਦੇ ਤਜ਼ਰਬੇ ਵਿੱਚ ਜੜਿਆ ਹੋਇਆ ਹੈ। brk() ਜਾਂ mmap() ਨੂੰ ਹਰੇਕ ਕਾਲ ਵਿੱਚ ਉਪਭੋਗਤਾ ਸਪੇਸ ਤੋਂ ਕਰਨਲ ਸਪੇਸ ਵਿੱਚ ਇੱਕ ਸੰਦਰਭ ਸਵਿੱਚ, ਪ੍ਰਕਿਰਿਆ ਦੀ ਵਰਚੁਅਲ ਮੈਮੋਰੀ ਮੈਪਿੰਗ ਵਿੱਚ ਸੋਧ, ਅਤੇ ਸੰਭਾਵੀ ਪੇਜ ਟੇਬਲ ਅੱਪਡੇਟ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ। ਆਧੁਨਿਕ ਹਾਰਡਵੇਅਰ 'ਤੇ, ਇੱਕ ਸਿੰਗਲ ਸਿਸਟਮ ਕਾਲ ਦੀ ਕੀਮਤ ਲਗਭਗ 100-200 ਨੈਨੋ ਸਕਿੰਟ ਹੁੰਦੀ ਹੈ — ਆਈਸੋਲੇਸ਼ਨ ਵਿੱਚ ਮਾਮੂਲੀ, ਪੈਮਾਨੇ 'ਤੇ ਘਾਤਕ।

ਉਸ ਪ੍ਰੋਗਰਾਮ 'ਤੇ ਵਿਚਾਰ ਕਰੋ ਜੋ ਸ਼ੁਰੂਆਤ ਦੇ ਦੌਰਾਨ 10,000 ਛੋਟੀਆਂ ਵੰਡ ਕਰਦਾ ਹੈ। ਪੂਰਵ-ਅਲੋਕੇਸ਼ਨ ਤੋਂ ਬਿਨਾਂ, ਇਸਦਾ ਮਤਲਬ ਹੋਵੇਗਾ 10,000 ਸਿਸਟਮ ਕਾਲਾਂ, ਜਿਸਦੀ ਕੀਮਤ ਲਗਭਗ 1-2 ਮਿਲੀਸਕਿੰਟ ਸ਼ੁੱਧ ਓਵਰਹੈੱਡ ਹੋਵੇਗੀ। ਇੱਕ ਅਰੇਨਾ-ਅਧਾਰਿਤ ਅਲੋਕੇਟਰ ਦੇ ਨਾਲ, ਪਹਿਲੀ ਅਲੋਕੇਸ਼ਨ ਇੱਕ ਸਿੰਗਲ ਸਿਸਟਮ ਕਾਲ ਨੂੰ ਚਾਲੂ ਕਰਦੀ ਹੈ, ਅਤੇ ਬਾਅਦ ਵਿੱਚ 9,999 ਅਲਾਟਮੈਂਟਾਂ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਯੂਜ਼ਰ ਸਪੇਸ ਵਿੱਚ ਪੁਆਇੰਟਰ ਅੰਕਗਣਿਤ ਅਤੇ ਲਿੰਕਡ-ਲਿਸਟ ਓਪਰੇਸ਼ਨਾਂ ਦੁਆਰਾ ਸਰਵਿਸ ਕੀਤਾ ਜਾਂਦਾ ਹੈ - ਹਰ ਇੱਕ ਲਗਭਗ 10-50 ਨੈਨੋ ਸਕਿੰਟ ਲੈਂਦਾ ਹੈ। ਗਣਿਤ ਅਸਪਸ਼ਟ ਹੈ: ਪੂਰਵ-ਅਲਾਟਮੈਂਟ ਤੀਬਰਤਾ ਦੇ ਆਦੇਸ਼ਾਂ ਦੁਆਰਾ ਜਿੱਤਦਾ ਹੈ।

ਤੁਹਾਡੀ ਪਹਿਲੀ ਵੰਡ 'ਤੇ ਤੁਸੀਂ ਜੋ 72 KB ਦੇਖਦੇ ਹੋ, ਉਹ ਮੈਮੋਰੀ ਦੀ ਬਰਬਾਦੀ ਨਹੀਂ ਹੈ — ਇਹ ਇੱਕ ਪ੍ਰਦਰਸ਼ਨ ਨਿਵੇਸ਼ ਹੈ। ਅਲੋਕੇਟਰ ਸੱਟੇਬਾਜ਼ੀ ਕਰ ਰਿਹਾ ਹੈ ਕਿ ਤੁਹਾਡਾ ਪ੍ਰੋਗਰਾਮ ਜਲਦੀ ਹੀ ਹੋਰ ਅਲਾਟਮੈਂਟ ਕਰੇਗਾ, ਅਤੇ ਅਸਲ ਵਿੱਚ ਹਰ ਅਸਲ-ਸੰਸਾਰ ਦ੍ਰਿਸ਼ ਵਿੱਚ, ਇਹ ਬਾਜ਼ੀ ਸ਼ਾਨਦਾਰ ਢੰਗ ਨਾਲ ਭੁਗਤਾਨ ਕਰਦੀ ਹੈ। ਆਧੁਨਿਕ 64-ਬਿੱਟ ਸਿਸਟਮਾਂ 'ਤੇ ਅਣਵਰਤੀ ਵਰਚੁਅਲ ਐਡਰੈੱਸ ਸਪੇਸ ਦੀ ਕੀਮਤ ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ ਜ਼ੀਰੋ ਹੈ।

ਵਰਚੁਅਲ ਮੈਮੋਰੀ ਬਨਾਮ ਫਿਜ਼ੀਕਲ ਮੈਮੋਰੀ: ਇਹ ਮਾਇਨੇ ਕਿਉਂ ਨਹੀਂ ਰੱਖਦਾ

ਪਹਿਲੀ ਵਾਰ ਇਸ ਵਿਵਹਾਰ ਦਾ ਸਾਹਮਣਾ ਕਰਨ ਵਾਲੇ ਡਿਵੈਲਪਰਾਂ ਵਿੱਚ ਇੱਕ ਆਮ ਚਿੰਤਾ ਸਰੋਤ ਦੀ ਬਰਬਾਦੀ ਹੈ। ਜੇਕਰ ਮੈਨੂੰ ਸਿਰਫ਼ 4 ਬਾਈਟਾਂ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਮੇਰਾ ਪ੍ਰੋਗਰਾਮ 72 KB ਕਿਉਂ ਵਰਤ ਰਿਹਾ ਹੈ? ਨਾਜ਼ੁਕ ਸਮਝ ਇਹ ਹੈ ਕਿ ਵਰਚੁਅਲ ਮੈਮੋਰੀ ਭੌਤਿਕ ਮੈਮੋਰੀ ਨਹੀਂ ਹੈ। ਜਦੋਂ glibc ਪ੍ਰੋਗਰਾਮ ਬਰੇਕ ਨੂੰ 72 KB ਤੱਕ ਵਧਾਉਂਦਾ ਹੈ, ਕਰਨਲ ਪ੍ਰਕਿਰਿਆ ਦੀ ਵਰਚੁਅਲ ਮੈਮੋਰੀ ਮੈਪਿੰਗ ਨੂੰ ਅੱਪਡੇਟ ਕਰਦਾ ਹੈ, ਪਰ ਇਹ ਉਹਨਾਂ ਪੰਨਿਆਂ ਨੂੰ ਭੌਤਿਕ RAM ਨਾਲ ਤੁਰੰਤ ਬੈਕ ਨਹੀਂ ਕਰਦਾ ਹੈ। ਅਸਲ ਭੌਤਿਕ ਪੰਨਿਆਂ ਨੂੰ ਪੇਜ ਫਾਲਟਸ ਦੁਆਰਾ ਮੰਗ 'ਤੇ ਨਿਰਧਾਰਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ — ਜਦੋਂ ਤੁਹਾਡਾ ਪ੍ਰੋਗਰਾਮ ਕਿਸੇ ਖਾਸ ਪਤੇ 'ਤੇ ਲਿਖਦਾ ਹੈ ਤਾਂ ਕਰਨਲ ਇਸ ਨੂੰ ਮੈਮੋਰੀ ਦਾ ਅਸਲ ਪੰਨਾ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ।

ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਭਾਵੇਂ ਤੁਹਾਡੀ ਪ੍ਰਕਿਰਿਆ ਦਾ ਵਰਚੁਅਲ ਆਕਾਰ 72 KB ਵਧਦਾ ਹੈ, ਇਸਦਾ ਨਿਵਾਸੀ ਸੈੱਟ ਆਕਾਰ (RSS) — ਅਸਲ ਵਿੱਚ ਖਪਤ ਕੀਤੀ ਗਈ ਭੌਤਿਕ RAM ਦੀ ਮਾਤਰਾ — ਸਿਰਫ਼ ਉਹਨਾਂ ਪੰਨਿਆਂ ਦੁਆਰਾ ਵਧਦੀ ਹੈ ਜਿਹਨਾਂ ਨੂੰ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਛੂਹਦੇ ਹੋ। ਇੱਕ ਇੱਕਲੇ ਨਵੇਂ ਇੰਟ ਲਈ, ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ 4 KB ਪੰਨਾ ਹੁੰਦਾ ਹੈ, ਨਾਲ ਹੀ ਅਰੇਨਾ ਮੈਟਾਡੇਟਾ ਵਿੱਚ ਜੋ ਵੀ ਪੰਨੇ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ। ਬਾਕੀ ਬਚੀ ਵਰਚੁਅਲ ਸਪੇਸ ਉੱਥੇ ਬੈਠਦੀ ਹੈ, ਵਰਤੋਂ ਲਈ ਤਿਆਰ, ਐਡਰੈੱਸ ਸਪੇਸ ਤੋਂ ਇਲਾਵਾ ਕੁਝ ਵੀ ਖਰਚ ਨਹੀਂ ਹੁੰਦਾ — ਜਿਸ ਵਿੱਚੋਂ ਤੁਹਾਡੇ ਕੋਲ 64-ਬਿੱਟ ਲੀਨਕਸ ਸਿਸਟਮ 'ਤੇ 128 TB ਹੈ।

ਉਤਪਾਦਨ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੀ ਪ੍ਰੋਫਾਈਲਿੰਗ ਅਤੇ ਨਿਗਰਾਨੀ ਕਰਨ ਵੇਲੇ ਇਹ ਅੰਤਰ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦਾ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਅਜਿਹਾ ਸੌਫਟਵੇਅਰ ਬਣਾ ਰਹੇ ਹੋ ਜਿਸ ਨੂੰ ਅਸਲ ਸਰੋਤ ਦੀ ਖਪਤ ਨੂੰ ਟਰੈਕ ਕਰਨ ਦੀ ਲੋੜ ਹੈ — ਭਾਵੇਂ ਇਹ SaaS ਬੈਕਐਂਡ, ਇੱਕ ਮਾਈਕ੍ਰੋਸਰਵਿਸ, ਜਾਂ ਵਪਾਰਕ ਕਾਰਜਾਂ ਲਈ Mewayz ਵਰਗੇ ਪਲੇਟਫਾਰਮਾਂ 'ਤੇ ਚੱਲਣ ਵਾਲੀ ਵਿਸ਼ਲੇਸ਼ਕੀ ਪਾਈਪਲਾਈਨ ਹੋਵੇ — ਤੁਹਾਨੂੰ ਹਮੇਸ਼ਾ ਵਰਚੁਅਲ ਆਕਾਰ ਦੀ ਬਜਾਏ RSS ਦੀ ਨਿਗਰਾਨੀ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ। /proc/[pid]/smaps, valgrind --tool=massif, ਅਤੇ pmap ਵਰਗੇ ਟੂਲ ਤੁਹਾਨੂੰ ਵਰਚੁਅਲ ਮੈਮੋਰੀ ਅੰਕੜਿਆਂ ਨੂੰ ਗੁੰਮਰਾਹ ਕਰਨ ਦੀ ਬਜਾਏ ਸਹੀ ਭੌਤਿਕ ਮੈਮੋਰੀ ਫੁਟਪ੍ਰਿੰਟ ਦੇ ਸਕਦੇ ਹਨ।

ਵਿਭਿੰਨ ਅਲੋਕੇਟਰ ਪਹਿਲੀ ਵੰਡ ਨੂੰ ਕਿਵੇਂ ਸੰਭਾਲਦੇ ਹਨ

72 KB ਚਿੱਤਰ glibc ਦੇ ptmalloc2 ਲਈ ਖਾਸ ਹੈ। ਹੋਰ ਐਲੋਕਟਰ ਵੱਖੋ-ਵੱਖਰੇ ਟ੍ਰੇਡਆਫ ਕਰਦੇ ਹਨ, ਅਤੇ ਸ਼ੁਰੂਆਤੀ ਅਲਾਟਮੈਂਟ ਓਵਰਹੈੱਡ ਉਸ ਅਨੁਸਾਰ ਬਦਲਦਾ ਹੈ। ਪ੍ਰਦਰਸ਼ਨ-ਸੰਵੇਦਨਸ਼ੀਲ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਅਲੋਕੇਟਰ ਦੀ ਚੋਣ ਕਰਦੇ ਸਮੇਂ ਇਹਨਾਂ ਅੰਤਰਾਂ ਨੂੰ ਸਮਝਣਾ ਮਹੱਤਵਪੂਰਣ ਹੈ।

• jemalloc (Facebook, FreeBSD ਦੁਆਰਾ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ) — ਥਰਿੱਡ-ਲੋਕਲ ਕੈਚਾਂ ਦੇ ਨਾਲ ਇੱਕ ਹੋਰ ਦਾਣੇਦਾਰ ਅਰੇਨਾ ਢਾਂਚੇ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਸ਼ੁਰੂਆਤੀ ਓਵਰਹੈੱਡ ਉੱਚਾ ਹੁੰਦਾ ਹੈ (ਅਕਸਰ 200+ KB) ਪਰ ਘੱਟ ਲਾਕ ਵਿਵਾਦ ਦੇ ਕਾਰਨ ਬਿਹਤਰ ਮਲਟੀ-ਥ੍ਰੈਡਡ ਪ੍ਰਦਰਸ਼ਨ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।
• tcmalloc (Google ਦਾ ਥ੍ਰੈਡ-ਕੈਚਿੰਗ ਮੈਲੋਕ) — ਹਮਲਾਵਰ ਪੂਰਵ-ਅਲੋਕੇਸ਼ਨ ਦੇ ਨਾਲ, ਮੂਲ ਰੂਪ ਵਿੱਚ ਲਗਭਗ 2 MB ਦਾ ਪ੍ਰਤੀ-ਥ੍ਰੈਡ ਕੈਸ਼ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ। ਸ਼ੁਰੂਆਤੀ ਓਵਰਹੈੱਡ ਉੱਚਾ ਹੈ, ਪਰ ਬਾਅਦ ਵਿੱਚ ਛੋਟੀਆਂ ਵੰਡਾਂ ਬਹੁਤ ਤੇਜ਼ ਹਨ।
• musl libc's malloc — ਸਾਰੀਆਂ ਵੰਡਾਂ ਲਈ mmap 'ਤੇ ਆਧਾਰਿਤ ਬਹੁਤ ਸਰਲ ਡਿਜ਼ਾਈਨ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਸ਼ੁਰੂਆਤੀ ਓਵਰਹੈੱਡ ਨਿਊਨਤਮ ਹੈ (ਅਕਸਰ ਸਿਰਫ਼ 4 KB ਪ੍ਰਤੀ ਨਿਰਧਾਰਨ), ਪਰ ਵਧੇਰੇ ਵਾਰ-ਵਾਰ ਸਿਸਟਮ ਕਾਲਾਂ ਕਾਰਨ ਪ੍ਰਤੀ-ਅਲੋਕੇਸ਼ਨ ਲਾਗਤ ਵੱਧ ਹੈ।
• mimalloc (Microsoft) — 64 MB ਖੰਡਾਂ ਦੇ ਨਾਲ ਖੰਡ-ਅਧਾਰਿਤ ਵੰਡ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਪਹਿਲੀ ਵੰਡ ਇੱਕ 64 MB ਵਰਚੁਅਲ ਰਿਜ਼ਰਵੇਸ਼ਨ (ਘੱਟੋ-ਘੱਟ ਭੌਤਿਕ ਵਚਨਬੱਧਤਾ ਦੇ ਨਾਲ), ਬੇਮਿਸਾਲ ਸਥਾਨ ਅਤੇ ਥ੍ਰੁਪੁੱਟ ਲਈ ਵਪਾਰ ਪਤਾ ਸਪੇਸ ਨੂੰ ਚਾਲੂ ਕਰਦੀ ਹੈ।

ਇਨ੍ਹਾਂ ਅਲੋਕੇਟਰਾਂ ਵਿਚਕਾਰ ਚੋਣ ਪੂਰੀ ਤਰ੍ਹਾਂ ਤੁਹਾਡੇ ਕੰਮ ਦੇ ਬੋਝ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ। ਹੈਵੀ ਮਲਟੀ-ਥ੍ਰੈਡਡ ਅਲੋਕੇਸ਼ਨ ਦੇ ਨਾਲ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਚੱਲ ਰਹੇ ਸਰਵਰ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ, ਜੇਮੈਲੋਕ ਜਾਂ tcmalloc ਆਮ ਤੌਰ 'ਤੇ glibc ਦੇ ਡਿਫੌਲਟ ਨਾਲੋਂ ਵਧੀਆ ਪ੍ਰਦਰਸ਼ਨ ਕਰਦੇ ਹਨ। ਮੈਮੋਰੀ-ਸੀਮਤ ਏਮਬੈਡਡ ਸਿਸਟਮਾਂ ਲਈ, ਘੱਟ ਥ੍ਰੁਪੁੱਟ ਦੇ ਬਾਵਜੂਦ ਮਸਲ ਦੀ ਸਰਲ ਪਹੁੰਚ ਤਰਜੀਹੀ ਹੋ ਸਕਦੀ ਹੈ। ਜ਼ਿਆਦਾਤਰ ਆਮ-ਉਦੇਸ਼ ਵਾਲੇ ਡੈਸਕਟਾਪ ਅਤੇ ਸਰਵਰ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ, ptmalloc2 ਦਾ 72 KB ਸ਼ੁਰੂਆਤੀ ਓਵਰਹੈੱਡ ਇੱਕ ਵਾਜਬ ਡਿਫੌਲਟ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ ਜੋ ਟਿਊਨਿੰਗ ਤੋਂ ਬਿਨਾਂ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ।

ਸ਼ੁਰੂਆਤੀ ਅਲੋਕੇਸ਼ਨ ਵਿਵਹਾਰ ਨੂੰ ਟਿਊਨਿੰਗ

ਜੇਕਰ ਡਿਫੌਲਟ 72 KB ਸ਼ੁਰੂਆਤੀ ਓਵਰਹੈੱਡ ਤੁਹਾਡੇ ਵਰਤੋਂ ਦੇ ਕੇਸ ਲਈ ਅਸਲ ਵਿੱਚ ਸਮੱਸਿਆ ਵਾਲਾ ਹੈ — ਸ਼ਾਇਦ ਤੁਸੀਂ ਹਜ਼ਾਰਾਂ ਥੋੜ੍ਹੇ ਸਮੇਂ ਲਈ ਪ੍ਰਕਿਰਿਆਵਾਂ ਪੈਦਾ ਕਰ ਰਹੇ ਹੋ, ਹਰ ਇੱਕ ਮੁੱਠੀ ਭਰ ਅਲਾਟਮੈਂਟ ਬਣਾ ਰਿਹਾ ਹੈ — glibc mallopt() ਅਤੇ MALLOC__ ਪਰਵਾਰ ਦੇ ਵੈਰੀਏਬਲ ਦੁਆਰਾ ਕਈ ਟਿਊਨੇਬਲ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।

M_TOP_PAD ਪੈਰਾਮੀਟਰ ਨਿਯੰਤਰਿਤ ਕਰਦਾ ਹੈ ਕਿ ਅਲੋਕੇਟਰ ਕਿੰਨੀ ਵਾਧੂ ਮੈਮੋਰੀ ਦੀ ਬੇਨਤੀ ਕਰਦਾ ਹੈ ਜਿਸਦੀ ਤੁਰੰਤ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇਸਨੂੰ mallopt(M_TOP_PAD, 0) ਦੇ ਨਾਲ 0 'ਤੇ ਸੈੱਟ ਕਰਨ ਨਾਲ ਅਲੋਕੇਟਰ ਨੂੰ ਸਿਰਫ਼ ਉਹੀ ਬੇਨਤੀ ਕਰਨ ਲਈ ਕਿਹਾ ਜਾਂਦਾ ਹੈ ਜਿਸਦੀ ਲੋੜ ਹੈ, ਸ਼ੁਰੂਆਤੀ ਓਵਰਹੈੱਡ ਨੂੰ ਮਹੱਤਵਪੂਰਨ ਤੌਰ 'ਤੇ ਘਟਾਉਂਦਾ ਹੈ। M_MMAP_THRESHOLD ਪੈਰਾਮੀਟਰ ਉੱਪਰਲੇ ਆਕਾਰ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਦਾ ਹੈ ਜਿਸ ਦੀ ਵੰਡ ਅਰੇਨਾ ਦੀ ਬਜਾਏ mmap ਦੀ ਵਰਤੋਂ ਕਰਦੀ ਹੈ। M_TRIM_THRESHOLD ਕੰਟਰੋਲ ਕਰਦਾ ਹੈ ਜਦੋਂ ਖਾਲੀ ਕੀਤੀ ਮੈਮੋਰੀ OS ਨੂੰ ਵਾਪਸ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਅਤੇ glibc 2.26 ਤੋਂ, glibc.malloc.tcache_count ਅਤੇ glibc.malloc.tcache_max ਟਿਊਨੇਬਲ ਤੁਹਾਨੂੰ ਥਰਿੱਡ ਕੈਸ਼ ਵਿਹਾਰ ਨੂੰ ਕੰਟਰੋਲ ਕਰਨ ਦਿੰਦੇ ਹਨ।

ਹਾਲਾਂਕਿ, ਸਾਵਧਾਨੀ ਦਾ ਇੱਕ ਸ਼ਬਦ: ਇਹਨਾਂ ਮਾਪਦੰਡਾਂ ਨੂੰ ਸਾਵਧਾਨ ਬੈਂਚਮਾਰਕਿੰਗ ਤੋਂ ਬਿਨਾਂ ਟਿਊਨ ਕਰਨਾ ਲਗਭਗ ਹਮੇਸ਼ਾ ਚੀਜ਼ਾਂ ਨੂੰ ਹੋਰ ਵਿਗੜਦਾ ਹੈ। ਪੂਰਵ-ਨਿਰਧਾਰਤ ਵਿਆਪਕ ਅਸਲ-ਸੰਸਾਰ ਪ੍ਰੋਫਾਈਲਿੰਗ ਦੇ ਆਧਾਰ 'ਤੇ ਚੁਣੇ ਗਏ ਸਨ, ਅਤੇ ਉਹ ਬਹੁਤ ਸਾਰੇ ਵਰਕਲੋਡਾਂ ਲਈ ਇੱਕ ਮਿੱਠੇ ਸਥਾਨ ਨੂੰ ਦਰਸਾਉਂਦੇ ਹਨ। ਜਦੋਂ ਤੱਕ ਤੁਹਾਡੇ ਕੋਲ ਉਤਪਾਦਨ ਪ੍ਰੋਫਾਈਲਿੰਗ ਤੋਂ ਮਜ਼ਬੂਤ ​​​​ਸਬੂਤ ਨਹੀਂ ਹੈ ਕਿ malloc ਓਵਰਹੈੱਡ ਇੱਕ ਰੁਕਾਵਟ ਹੈ - ਅਤੇ ਤੁਸੀਂ ਆਪਣੀਆਂ ਤਬਦੀਲੀਆਂ ਦੇ ਪ੍ਰਭਾਵ ਨੂੰ ਮਾਪਿਆ ਹੈ - ਡਿਫੌਲਟ ਨੂੰ ਇਕੱਲੇ ਛੱਡੋ। ਅਲੋਕੇਟਰ ਦਾ ਅਚਨਚੇਤੀ ਅਨੁਕੂਲਨ ਯਾਕ ਸ਼ੇਵਿੰਗ ਦਾ ਇੱਕ ਖਾਸ ਤੌਰ 'ਤੇ ਧੋਖਾਧੜੀ ਵਾਲਾ ਰੂਪ ਹੈ ਜਿਸ ਨੇ ਅਣਗਿਣਤ ਇੰਜੀਨੀਅਰਿੰਗ ਘੰਟਿਆਂ ਨੂੰ ਅਣਗਿਣਤ ਲਾਭ ਲਈ ਵਰਤਿਆ ਹੈ।

ਇਹ ਸਾਨੂੰ ਸਿਸਟਮ ਪ੍ਰੋਗਰਾਮਿੰਗ ਬਾਰੇ ਕੀ ਸਿਖਾਉਂਦਾ ਹੈ

72 KB ਦਾ ਪਹਿਲਾ-ਅਲੋਕੇਸ਼ਨ ਰਹੱਸ, ਇਸਦੇ ਮੂਲ ਰੂਪ ਵਿੱਚ, ਐਬਸਟ੍ਰਕਸ਼ਨ ਲੇਅਰਾਂ ਬਾਰੇ ਇੱਕ ਸਬਕ ਹੈ। C++ ਤੁਹਾਨੂੰ ਇਹ ਭੁਲੇਖਾ ਦਿੰਦਾ ਹੈ ਕਿ ਨਵਾਂ ਇੰਟ 4 ਬਾਈਟ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ। ਭਾਸ਼ਾ ਦਾ ਮਿਆਰ ਅਜਿਹਾ ਕਹਿੰਦਾ ਹੈ। ਤੁਹਾਡਾ ਮਾਨਸਿਕ ਮਾਡਲ ਅਜਿਹਾ ਕਹਿੰਦਾ ਹੈ। ਪਰ ਤੁਹਾਡੇ ਕੋਡ ਅਤੇ ਹਾਰਡਵੇਅਰ ਦੇ ਵਿਚਕਾਰ ਵਧੀਆ ਸਿਸਟਮਾਂ ਦਾ ਇੱਕ ਸਟੈਕ ਬੈਠਦਾ ਹੈ — C++ ਰਨਟਾਈਮ, C ਲਾਇਬ੍ਰੇਰੀ ਅਲੋਕੇਟਰ, ਕਰਨਲ ਦਾ ਵਰਚੁਅਲ ਮੈਮੋਰੀ ਸਬ-ਸਿਸਟਮ, ਅਤੇ ਹਾਰਡਵੇਅਰ ਦਾ MMU ਅਤੇ TLB — ਹਰ ਇੱਕ ਆਪਣੇ ਵਿਹਾਰ, ਅਨੁਕੂਲਤਾ ਅਤੇ ਓਵਰਹੈੱਡ ਜੋੜਦਾ ਹੈ।

ਇਹ ਕੋਈ ਨੁਕਸ ਨਹੀਂ ਹੈ। ਇਹ ਸਿਸਟਮ ਸਾਫਟਵੇਅਰ ਦਾ ਪੂਰਾ ਬਿੰਦੂ ਹੈ। ਅਸਲ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਹਰੇਕ ਪਰਤ ਮੌਜੂਦ ਹੈ: ਅਲੋਕੇਟਰ ਮੌਜੂਦ ਹੈ ਇਸਲਈ ਤੁਹਾਨੂੰ ਹਰੇਕ ਵੰਡ ਲਈ ਸਿਸਟਮ ਕਾਲਾਂ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਵਰਚੁਅਲ ਮੈਮੋਰੀ ਸਿਸਟਮ ਮੌਜੂਦ ਹੈ ਇਸ ਲਈ ਤੁਹਾਨੂੰ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਭੌਤਿਕ ਮੈਮੋਰੀ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਪੇਜ ਫਾਲਟ ਹੈਂਡਲਰ ਮੌਜੂਦ ਹੈ ਇਸਲਈ ਮੈਮੋਰੀ ਆਲਸੀ ਅਤੇ ਕੁਸ਼ਲਤਾ ਨਾਲ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਹਰ ਪਰਤ ਵੱਡੀ ਮਾਤਰਾ ਵਿੱਚ ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਸਹੂਲਤ ਲਈ ਥੋੜ੍ਹੀ ਜਿਹੀ ਪਾਰਦਰਸ਼ਤਾ ਦਾ ਵਪਾਰ ਕਰਦੀ ਹੈ।

ਡਿਵੈਲਪਰ ਜੋ ਸਭ ਤੋਂ ਭਰੋਸੇਮੰਦ, ਉੱਚ-ਪ੍ਰਦਰਸ਼ਨ ਵਾਲੇ ਸਿਸਟਮ ਬਣਾਉਂਦੇ ਹਨ, ਉਹ ਹਨ ਜੋ ਇਹਨਾਂ ਪਰਤਾਂ ਨੂੰ ਸਮਝਦੇ ਹਨ — ਇਸ ਲਈ ਨਹੀਂ ਕਿ ਉਹਨਾਂ ਨੂੰ ਉਹਨਾਂ ਬਾਰੇ ਲਗਾਤਾਰ ਸੋਚਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਪਰ ਕਿਉਂਕਿ ਜਦੋਂ ਕੁਝ ਅਚਾਨਕ ਵਾਪਰਦਾ ਹੈ (ਜਿਵੇਂ ਕਿ ਇੱਕ ਰਹੱਸਮਈ 72 KB ਵੰਡ), ਉਹਨਾਂ ਕੋਲ ਇਹ ਸਮਝਣ ਲਈ ਮਾਨਸਿਕ ਮਾਡਲ ਹੁੰਦਾ ਹੈ ਕਿ ਕਿਉਂ। ਭਾਵੇਂ ਤੁਸੀਂ ਇੱਕ ਰੀਅਲ-ਟਾਈਮ ਵਪਾਰ ਪ੍ਰਣਾਲੀ, ਇੱਕ ਗੇਮ ਇੰਜਣ, ਜਾਂ ਹਜ਼ਾਰਾਂ ਉਪਭੋਗਤਾਵਾਂ ਦੀ ਸੇਵਾ ਕਰਨ ਵਾਲਾ ਇੱਕ ਵਪਾਰਕ ਪਲੇਟਫਾਰਮ ਬਣਾ ਰਹੇ ਹੋ, ਸਿਸਟਮ ਪੱਧਰ 'ਤੇ ਤੁਹਾਡਾ ਕੋਡ ਅਸਲ ਵਿੱਚ ਕੀ ਕਰਦਾ ਹੈ ਇਸ ਬਾਰੇ ਤਰਕ ਕਰਨ ਦੀ ਯੋਗਤਾ ਉਹ ਹੈ ਜੋ ਸਮਰੱਥ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਬੇਮਿਸਾਲ ਲੋਕਾਂ ਤੋਂ ਵੱਖ ਕਰਦੀ ਹੈ। 72 KB ਕੋਈ ਬੱਗ ਨਹੀਂ ਹੈ। ਇਹ ਤੁਹਾਡਾ ਨਿਰਧਾਰਕ ਆਪਣਾ ਕੰਮ ਸ਼ਾਨਦਾਰ ਢੰਗ ਨਾਲ ਕਰ ਰਿਹਾ ਹੈ।