C++ ਅਨੁਕੂਲਨ: ਗਤੀ ਅਤੇ ਉੱਚ ਪੱਧਰ ਨੂੰ ਜੋੜੋ। Yandex ਰਿਪੋਰਟ

C++ ਪ੍ਰੋਗਰਾਮਾਂ ਦੀ ਗਤੀ ਨੂੰ ਕੀ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ ਅਤੇ ਇਸ ਨੂੰ ਉੱਚ ਪੱਧਰੀ ਕੋਡ ਨਾਲ ਕਿਵੇਂ ਪ੍ਰਾਪਤ ਕਰਨਾ ਹੈ? CatBoost ਲਾਇਬ੍ਰੇਰੀ ਦੇ ਮੁੱਖ ਵਿਕਾਸਕਾਰ, Evgeny Petrov, ਨੇ x86_64 ਲਈ CatBoost 'ਤੇ ਕੰਮ ਕਰਨ ਦੇ ਤਜ਼ਰਬੇ ਤੋਂ ਉਦਾਹਰਣਾਂ ਅਤੇ ਦ੍ਰਿਸ਼ਟਾਂਤ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਇਹਨਾਂ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦਿੱਤੇ।

ਵੀਡੀਓ ਰਿਪੋਰਟ

- ਸਾਰਿਆਂ ਨੂੰ ਸਤਿ ਸ਼੍ਰੀ ਅਕਾਲ. ਮੈਂ CatBoost ਮਸ਼ੀਨ ਲਰਨਿੰਗ ਲਾਇਬ੍ਰੇਰੀ ਲਈ CPU ਓਪਟੀਮਾਈਜੇਸ਼ਨ ਕਰ ਰਿਹਾ/ਰਹੀ ਹਾਂ। ਸਾਡੀ ਲਾਇਬ੍ਰੇਰੀ ਦਾ ਮੁੱਖ ਹਿੱਸਾ C++ ਵਿੱਚ ਲਿਖਿਆ ਹੋਇਆ ਹੈ। ਅੱਜ ਮੈਂ ਤੁਹਾਨੂੰ ਦੱਸਾਂਗਾ ਕਿ ਅਸੀਂ ਕਿਹੜੇ ਆਸਾਨ ਤਰੀਕਿਆਂ ਨਾਲ ਗਤੀ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਾਂ।

ਗਣਨਾ ਦੀ ਗਤੀ ਦੇ ਦੋ ਹਿੱਸੇ ਹੁੰਦੇ ਹਨ। ਪਹਿਲਾ ਭਾਗ ਐਲਗੋਰਿਦਮ ਹੈ। ਜੇਕਰ ਅਸੀਂ ਐਲਗੋਰਿਦਮ ਦੀ ਚੋਣ ਵਿੱਚ ਕੋਈ ਗਲਤੀ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਤੁਸੀਂ ਇਸਨੂੰ ਬਾਅਦ ਵਿੱਚ ਜਲਦੀ ਕੰਮ ਨਹੀਂ ਕਰ ਸਕਦੇ ਹੋ। ਦੂਜਾ ਭਾਗ ਇਹ ਹੈ ਕਿ ਸਾਡੇ ਐਲਗੋਰਿਦਮ ਨੂੰ ਇਸਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਅਤੇ ਥ੍ਰੁਪੁੱਟ ਦੇ ਨਾਲ, ਸਾਡੇ ਕੋਲ ਮੌਜੂਦ ਕੰਪਿਊਟਿੰਗ ਸਿਸਟਮ ਲਈ ਕਿਵੇਂ ਅਨੁਕੂਲ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ।

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

ਇਸ ਅੰਤਰ ਨੂੰ ਸੁਚਾਰੂ ਬਣਾਉਣ ਲਈ, ਆਰਕੀਟੈਕਚਰ ਵਿੱਚ ਕੈਚਿੰਗ ਦੇ ਕਈ ਪੱਧਰ ਹਨ। ਸਭ ਤੋਂ ਤੇਜ਼ ਅਤੇ ਸਭ ਤੋਂ ਛੋਟਾ L1 ਕੈਸ਼ ਹੈ। ਫਿਰ ਇੱਕ ਵੱਡਾ ਅਤੇ ਹੌਲੀ ਕੈਸ਼ ਹੈ, ਦੂਜਾ ਪੱਧਰ. ਅਤੇ ਇੱਥੇ ਇੱਕ ਬਹੁਤ ਵੱਡਾ ਕੈਸ਼ ਹੈ, ਜੋ ਕਿ ਦਸਾਂ ਮੈਗਾਬਾਈਟ ਹੋ ਸਕਦਾ ਹੈ, ਇੱਕ ਤੀਜੇ ਪੱਧਰ ਦਾ ਕੈਸ਼, ਪਰ ਇਹ ਸਭ ਤੋਂ ਹੌਲੀ ਹੈ।

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

ਜ਼ਿਆਦਾਤਰ ਗਣਨਾਤਮਕ ਤੌਰ 'ਤੇ ਭਾਰੀ ਕੋਡ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਲਿਖੇ ਗਏ ਹਨ, ਬਹੁਤ ਵਧੀਆ ਅਨੁਕੂਲਿਤ ਹਨ, ਅਤੇ ਇੱਥੇ ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ ਲਾਇਬ੍ਰੇਰੀਆਂ ਹਨ, ਇਸਲਈ ਇਹ ਸਮਝ ਵਿੱਚ ਆਉਂਦਾ ਹੈ ਕਿ ਜੇਕਰ ਤੁਸੀਂ ਆਪਣੇ ਕੋਡ ਵਿੱਚ ਭਾਰੀ ਗਣਨਾਵਾਂ ਦੇਖਦੇ ਹੋ, ਤਾਂ ਇੱਕ ਲਾਇਬ੍ਰੇਰੀ ਦੀ ਭਾਲ ਕਰੋ ਜੋ ਉਹਨਾਂ ਨੂੰ ਤੁਹਾਡੇ ਲਈ ਕਰ ਸਕੇ।

ਬਾਕੀ ਦੇ, ਕੰਪਾਈਲਰ ਨਹੀਂ ਜਾਣਦੇ ਕਿ ਸਭ ਕੁਝ ਕਿਵੇਂ ਕਰਨਾ ਹੈ, ਕਿਉਂਕਿ ਸਰੋਤਾਂ ਦੀ ਇੱਕ ਬਹੁਤ ਹੀ ਸੀਮਤ ਪ੍ਰਤੀਸ਼ਤਤਾ ਉਹਨਾਂ ਦੇ ਵਿਕਾਸ 'ਤੇ ਖਰਚ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕਿਹੜਾ ਅੱਜ ਵੱਧ ਜਾਂ ਘੱਟ ਸਰਗਰਮੀ ਨਾਲ ਵਿਕਾਸ ਕਰ ਰਿਹਾ ਹੈ, ਯਾਨੀ ਉਹ ਮਿਆਰਾਂ ਦਾ ਸਮਰਥਨ ਕਰਦੇ ਹਨ ਅਤੇ ਉਹਨਾਂ ਦੀ ਪਾਲਣਾ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ? ਇਹ ਫਰੰਟਐਂਡ EDG ਹੈ, ਜੋ ਕਿ ਵੱਖ-ਵੱਖ ਡੈਰੀਵੇਟਿਵਜ਼ ਵਿੱਚ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਉਦਾਹਰਨ ਲਈ, Intel ਕੰਪਾਈਲਰ; LLVM; GNU ਅਤੇ ਫਰੰਟਐਂਡ ਮਾਈਕਰੋਸਾਫਟ।

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

ਡਿਵੈਲਪਰਾਂ ਲਈ ਕੀ ਬਚਿਆ ਹੈ? ਇਸ ਨੂੰ ਮੋਟੇ ਤੌਰ 'ਤੇ ਚਾਰ ਭਾਗਾਂ ਵਿਚ ਵੰਡਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਪਹਿਲਾ ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਆਰਕੀਟੈਕਚਰ ਹੈ, ਕੰਪਾਈਲਰ ਸਾਡੇ ਲਈ ਇਸ ਦੇ ਨਾਲ ਆਉਣ ਦੇ ਯੋਗ ਨਹੀਂ ਹਨ.

ਕੰਪਾਈਲਰਾਂ ਲਈ ਸਮਾਨਤਾ ਵੀ ਇੱਕ ਮੁਸ਼ਕਲ ਚੀਜ਼ ਹੈ. ਮੈਮੋਰੀ ਦੇ ਨਾਲ ਕੰਮ ਕਰਨਾ - ਕਿਉਂਕਿ ਇਹ ਅਸਲ ਵਿੱਚ ਮੁਸ਼ਕਲ ਹੈ: ਤੁਹਾਨੂੰ ਆਰਕੀਟੈਕਚਰ, ਅਤੇ ਸਮਾਨਤਾ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ, ਅਤੇ ਸਾਰੇ ਇਕੱਠੇ. ਇਸ ਤੋਂ ਇਲਾਵਾ, ਕੰਪਾਈਲਰ ਇਹ ਨਹੀਂ ਜਾਣਦੇ ਕਿ ਅਨੁਕੂਲਤਾ ਦੀ ਗੁਣਵੱਤਾ ਦਾ ਸਹੀ ਢੰਗ ਨਾਲ ਮੁਲਾਂਕਣ ਕਿਵੇਂ ਕਰਨਾ ਹੈ, ਕੋਡ ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਨਿਕਲਦਾ ਹੈ. ਅਸੀਂ, ਡਿਵੈਲਪਰਾਂ ਨੂੰ, ਇਹ ਵੀ ਕਰਨਾ ਹੈ, ਇੱਕ ਫੈਸਲਾ ਕਰਨਾ ਹੈ - ਅੱਗੇ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਣ ਲਈ ਜਾਂ ਬੰਦ ਕਰਨ ਲਈ.

ਆਰਕੀਟੈਕਚਰ ਦੇ ਹਿੱਸੇ ਵਿੱਚ, ਅਸੀਂ ਓਵਰਹੈੱਡ, ਵਰਚੁਅਲ ਕਾਲਾਂ ਦੇ ਅਮੋਰਟਾਈਜ਼ੇਸ਼ਨ ਨੂੰ ਦੇਖਾਂਗੇ, ਜਿਸ 'ਤੇ ਆਰਕੀਟੈਕਚਰ ਬਹੁਤ ਸਾਰੇ ਮਾਮਲਿਆਂ ਵਿੱਚ ਅਧਾਰਤ ਹੈ।

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

ਇੰਟਰਫੇਸ ਅਤੇ ਐਬਸਟਰੈਕਟ ਡੇਟਾ ਕਿਸਮਾਂ ਦੀ ਵਰਤੋਂ ਮੁੱਖ ਡਿਜ਼ਾਈਨ ਵਿਧੀਆਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ। ਮਸ਼ੀਨ ਲਰਨਿੰਗ ਤੋਂ ਸਮਾਨ ਕੰਪਿਊਟੇਸ਼ਨਲ ਕੋਡ 'ਤੇ ਵਿਚਾਰ ਕਰੋ। ਇਹ ਇੱਕ ਕੰਡੀਸ਼ਨਲ ਕੋਡ ਹੈ ਜੋ ਗਰੇਡੀਐਂਟ ਵਿਧੀ ਨਾਲ ਪੂਰਵ ਅਨੁਮਾਨ ਨੂੰ ਅੱਪਡੇਟ ਕਰਦਾ ਹੈ।

ਜੇਕਰ ਅਸੀਂ ਥੋੜਾ ਅੰਦਰ ਵੇਖੀਏ ਅਤੇ ਇਹ ਸਮਝਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੀਏ ਕਿ ਅੰਦਰ ਕੀ ਹੋ ਰਿਹਾ ਹੈ, ਤਾਂ ਸਾਡੇ ਕੋਲ ਨੁਕਸਾਨ ਫੰਕਸ਼ਨ ਦੇ ਡੈਰੀਵੇਟਿਵਜ਼ ਦੀ ਗਣਨਾ ਕਰਨ ਲਈ ਇੱਕ IDerCalcer ਇੰਟਰਫੇਸ ਹੈ, ਅਤੇ ਇੱਕ ਫੰਕਸ਼ਨ ਜੋ ਨੁਕਸਾਨ ਫੰਕਸ਼ਨ ਦੇ ਗਰੇਡੀਐਂਟ ਦੇ ਅਨੁਸਾਰ ਪੂਰਵ ਅਨੁਮਾਨ (ਸਾਡੀ ਭਵਿੱਖਬਾਣੀ) ਨੂੰ ਬਦਲਦਾ ਹੈ।

ਸਲਾਈਡ ਦੇ ਸੱਜੇ ਪਾਸੇ ਤੁਸੀਂ ਦੇਖਦੇ ਹੋ ਕਿ 10D ਕੇਸ ਲਈ ਇਸਦਾ ਕੀ ਅਰਥ ਹੈ। ਅਤੇ ਮਸ਼ੀਨ ਸਿਖਲਾਈ ਵਿੱਚ, ਪੂਰਵ-ਅਨੁਮਾਨ ਦਾ ਆਕਾਰ ਦੋ ਜਾਂ ਤਿੰਨ ਨਹੀਂ, ਬਲਕਿ ਲੱਖਾਂ, ਲੱਖਾਂ ਤੱਤ ਹਨ। ਆਓ ਦੇਖੀਏ ਕਿ ਇਹ ਕੋਡ ਲਗਭਗ XNUMX ਮਿਲੀਅਨ ਤੱਤਾਂ ਵਾਲੇ ਵੈਕਟਰ ਲਈ ਕਿੰਨਾ ਵਧੀਆ ਹੈ।

ਆਉ ਮਿਆਰੀ ਵਿਵਹਾਰ ਨੂੰ ਉਦੇਸ਼ ਫੰਕਸ਼ਨ ਵਜੋਂ ਲੈਂਦੇ ਹਾਂ ਅਤੇ ਮਾਪਦੇ ਹਾਂ ਕਿ ਇਹ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ, ਇਹ ਇਸ ਪੂਰਵ ਅਨੁਮਾਨ ਨੂੰ ਕਿੰਨਾ ਬਦਲ ਦੇਵੇਗਾ। ਇਸ ਉਦੇਸ਼ ਫੰਕਸ਼ਨ ਦਾ ਡੈਰੀਵੇਟਿਵ ਸਲਾਈਡ 'ਤੇ ਦਿਖਾਇਆ ਗਿਆ ਹੈ। ਕੰਡੀਸ਼ਨਲ ਮਸ਼ੀਨ 'ਤੇ ਚੱਲਣ ਦਾ ਸਮਾਂ, ਜੋ ਫਿਰ ਸਥਿਰ ਰਹਿੰਦਾ ਹੈ, 40 ms ਹੈ।

ਆਓ ਇਹ ਸਮਝਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੀਏ ਕਿ ਇੱਥੇ ਕੀ ਗਲਤ ਹੈ. ਪਹਿਲੀ ਚੀਜ਼ ਜੋ ਧਿਆਨ ਖਿੱਚਦੀ ਹੈ ਉਹ ਹੈ ਵਰਚੁਅਲ ਕਾਲਾਂ। ਜੇ ਤੁਸੀਂ ਪ੍ਰੋਫਾਈਲਰ 'ਤੇ ਨਜ਼ਰ ਮਾਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ ਕਿ, ਪੈਰਾਮੀਟਰਾਂ ਦੀ ਗਿਣਤੀ 'ਤੇ ਨਿਰਭਰ ਕਰਦਿਆਂ, ਇਹ ਲਗਭਗ ਪੰਜ ਤੋਂ ਦਸ ਨਿਰਦੇਸ਼ ਹਨ. ਅਤੇ ਜੇਕਰ, ਜਿਵੇਂ ਕਿ ਸਾਡੇ ਕੇਸ ਵਿੱਚ, ਡੈਰੀਵੇਟਿਵ ਦੀ ਗਣਨਾ ਆਪਣੇ ਆਪ ਵਿੱਚ ਸਿਰਫ਼ ਦੋ ਅੰਕਗਣਿਤ ਕਿਰਿਆਵਾਂ ਹਨ, ਤਾਂ ਇਹ ਆਸਾਨੀ ਨਾਲ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਓਵਰਹੈੱਡ ਬਣ ਸਕਦਾ ਹੈ। ਡੈਰੀਵੇਟਿਵਜ਼ ਦੀ ਗਣਨਾ ਕਰਦੇ ਸਮੇਂ ਇੱਕ ਵੱਡੇ ਸਰੀਰ ਲਈ, ਇਹ ਲਗਭਗ ਹੈ। ਇੱਕ ਛੋਟੇ ਸਰੀਰ ਲਈ ਜੋ ਇੱਕ ਡੈਰੀਵੇਟਿਵ ਦੀ ਗਣਨਾ ਕਰਦਾ ਹੈ - ਕਹੋ, 500 ਹਦਾਇਤਾਂ ਵੀ ਨਹੀਂ, ਪਰ 20, 50 ਜਾਂ ਇਸ ਤੋਂ ਵੀ ਘੱਟ - ਇਹ ਪਹਿਲਾਂ ਹੀ ਸਮੇਂ ਦਾ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਪ੍ਰਤੀਸ਼ਤ ਹੋਵੇਗਾ। ਮੈਂ ਕੀ ਕਰਾਂ? ਆਉ ਇੰਟਰਫੇਸ ਨੂੰ ਬਦਲ ਕੇ ਵਰਚੁਅਲ ਫੰਕਸ਼ਨ ਕਾਲ ਨੂੰ ਬਫਰ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੀਏ।

ਸ਼ੁਰੂ ਵਿੱਚ, ਅਸੀਂ ਵੈਕਟਰ ਦੇ ਹਰੇਕ ਤੱਤ ਲਈ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਡੈਰੀਵੇਟਿਵ ਪੁਆਇੰਟ ਦੀ ਗਣਨਾ ਕਰਦੇ ਹਾਂ। ਆਉ ਐਲੀਮੈਂਟ-ਬਾਈ-ਐਲੀਮੈਂਟ ਪ੍ਰੋਸੈਸਿੰਗ ਤੋਂ ਵੈਕਟਰ ਦੁਆਰਾ ਪ੍ਰੋਸੈਸਿੰਗ ਤੱਕ ਪਾਸ ਕਰੀਏ। ਆਉ ਸਟੈਂਡਰਡ C++ ਟੈਂਪਲੇਟ ਲੈਂਦੇ ਹਾਂ, ਜੋ ਤੁਹਾਨੂੰ ਵੈਕਟਰ 'ਤੇ ਇੱਕ ਦ੍ਰਿਸ਼ ਨਾਲ ਕੰਮ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਜਾਂ, ਜੇਕਰ ਤੁਹਾਡਾ ਕੰਪਾਈਲਰ ਨਵੀਨਤਮ ਸਟੈਂਡਰਡ ਦਾ ਸਮਰਥਨ ਨਹੀਂ ਕਰਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਇੱਕ ਸਧਾਰਨ ਘਰੇਲੂ ਕਲਾਸ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ ਜੋ ਡੇਟਾ ਅਤੇ ਆਕਾਰ ਲਈ ਇੱਕ ਪੁਆਇੰਟਰ ਰੱਖਦਾ ਹੈ। ਕੋਡ ਕਿਵੇਂ ਬਦਲੇਗਾ? ਸਾਡੇ ਕੋਲ ਇੱਕ ਕਾਲ ਬਚੀ ਹੈ ਜੋ ਡੈਰੀਵੇਟਿਵਜ਼ ਦੀ ਗਣਨਾ ਕਰਦੀ ਹੈ, ਅਤੇ ਫਿਰ ਸਾਨੂੰ ਇੱਕ ਲੂਪ ਜੋੜਨਾ ਪਵੇਗਾ ਜੋ ਅਸਲ ਵਿੱਚ ਪੂਰਵ ਅਨੁਮਾਨ ਨੂੰ ਅਪਡੇਟ ਕਰੇਗਾ।

ਇੱਕ ਚੱਕਰ ਜੋੜਨ ਤੋਂ ਇਲਾਵਾ, ਸਾਨੂੰ ਅਜੇ ਵੀ ਡੇਟਾ ਨੂੰ ਦੂਜੀ ਵਾਰ ਵੇਖਣਾ ਪਏਗਾ, ਯਾਨੀ, ਪੂਰਵ ਅਨੁਮਾਨ ਵੈਕਟਰ ਅਤੇ ਗਰੇਡੀਐਂਟ ਵੈਕਟਰ ਨੂੰ ਪੜ੍ਹਨਾ ਹੈ ਜਿਸਦੀ ਅਸੀਂ ਹੁਣੇ ਦੂਜੀ ਵਾਰ ਗਣਨਾ ਕੀਤੀ ਹੈ।

ਅਸੀਂ ਉਸੇ ਮਸ਼ੀਨ 'ਤੇ ਦੁਬਾਰਾ ਮਾਪਾਂਗੇ ਅਤੇ ਦੇਖਾਂਗੇ ਕਿ ਕੀ ਖਰਾਬ ਹੋਇਆ, ਕੁਝ ਗਲਤ ਹੋਇਆ. ਆਓ ਸਮਝੀਏ ਕਿ ਕੋਡ ਦਾ ਕੀ ਹੋਇਆ।

ਕਿਸੇ ਚੀਜ਼ ਦੇ ਚੱਕਰ 'ਤੇ ਸ਼ੱਕ ਕਰਨਾ ਕੋਈ ਅਰਥ ਨਹੀਂ ਰੱਖਦਾ, ਕਿਉਂਕਿ ਇਹ ਬਿਲਕੁਲ ਉਹੀ ਬਾਰੰਬਾਰਤਾ ਪੈਟਰਨ ਹੈ ਜਿਸ ਨੂੰ ਕੰਪਾਈਲਰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਪਛਾਣਦੇ ਅਤੇ ਅਨੁਕੂਲ ਬਣਾਉਂਦੇ ਹਨ। ਪ੍ਰਤੀ ਡਾਟਾ ਤੱਤ ਓਪਰੇਸ਼ਨਾਂ ਦੀ ਗਿਣਤੀ ਇੱਕ ਵਰਚੁਅਲ ਕਾਲ ਦੀ ਲਾਗਤ ਤੋਂ ਘੱਟ ਹੋਵੇਗੀ।

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

ਜਦੋਂ ਡੈਰੀਵੇਟਿਵਜ਼ ਦੇ ਵੈਕਟਰ ਦੀ ਗਣਨਾ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਇਹ ਇੱਕ ਚੱਕਰ ਵਿੱਚ ਆਉਂਦਾ ਹੈ ਜੋ ਪੂਰਵ ਅਨੁਮਾਨ ਨੂੰ ਬਦਲਦਾ ਹੈ। ਇਸ ਚੱਕਰ ਤੋਂ ਪਹਿਲਾਂ, ਡੇਟਾ ਦਾ ਸਿਰਫ ਇੱਕ ਬਹੁਤ ਛੋਟਾ ਹਿੱਸਾ ਤੇਜ਼ LXNUMX ਕੈਸ਼ ਵਿੱਚ ਰਹੇਗਾ, ਜੋ ਪ੍ਰੋਸੈਸਰ ਦੀ ਬਾਰੰਬਾਰਤਾ 'ਤੇ ਚੱਲਦਾ ਹੈ। ਸਲਾਈਡ 'ਤੇ, ਇਹ ਟ੍ਰੈਫਿਕ ਲਾਈਟ 'ਤੇ ਹਰਾ ਹੈ। ਬਾਕੀ ਦਾ ਡੇਟਾ ਕੈਸ਼ ਤੋਂ ਬਾਹਰ ਮੈਮੋਰੀ ਵਿੱਚ ਧੱਕਿਆ ਜਾਵੇਗਾ, ਅਤੇ ਜਦੋਂ ਲੂਪ ਪੂਰਵ ਅਨੁਮਾਨਾਂ ਨੂੰ ਅਪਡੇਟ ਕਰਨ ਲਈ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਡੇਟਾ ਨੂੰ ਦੂਜੀ ਵਾਰ ਮੈਮੋਰੀ ਤੋਂ ਪੜ੍ਹਨਾ ਹੋਵੇਗਾ। ਅਤੇ ਇਹ ਸਾਡੇ ਲਈ ਕੰਮ ਕਰਦਾ ਹੈ, ਆਮ ਤੌਰ 'ਤੇ, ਬਹੁਤ ਹੌਲੀ ਹੌਲੀ, ਇੱਕ ਪੈਦਲ ਦੀ ਗਤੀ 'ਤੇ.

ਜਦੋਂ ਅਸੀਂ ਪੂਰਵ ਅਨੁਮਾਨ ਨੂੰ ਅੱਪਡੇਟ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਸਾਨੂੰ ਇੱਕੋ ਵਾਰ ਸਾਰੇ ਡੈਰੀਵੇਟਿਵਜ਼ ਨੂੰ ਪੜ੍ਹਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ ਹੈ। ਵਰਚੁਅਲ ਕਾਲਾਂ ਨੂੰ ਜਜ਼ਬ ਕਰਨ ਲਈ ਉਹਨਾਂ ਨੂੰ ਵੱਡੇ ਬੰਡਲਾਂ ਵਿੱਚ ਗਿਣਨਾ ਕਾਫ਼ੀ ਹੈ. ਇਸ ਲਈ, ਡੈਰੀਵੇਟਿਵਜ਼ ਦੀ ਗਣਨਾ ਨੂੰ ਵੰਡਣਾ ਅਤੇ ਪੂਰਵ ਅਨੁਮਾਨ ਨੂੰ ਛੋਟੇ ਬਲਾਕਾਂ ਵਿੱਚ ਅੱਪਡੇਟ ਕਰਨਾ ਅਤੇ ਇਹਨਾਂ ਦੋ ਕਿਰਿਆਵਾਂ ਨੂੰ ਮਿਲਾਉਣਾ ਸਮਝਦਾਰ ਹੈ। ਇਸ ਨਾਲ ਕੀ ਹੋਵੇਗਾ ਜੇਕਰ ਤੁਸੀਂ ਦੇਖਦੇ ਹੋ ਕਿ ਡੇਟਾ ਕਿੱਥੋਂ ਪੜ੍ਹਿਆ ਜਾਵੇਗਾ?

ਇਹ ਇਸ ਤੱਥ ਵੱਲ ਲੈ ਜਾਵੇਗਾ ਕਿ ਅਸੀਂ ਹਰ ਸਮੇਂ ਡੇਟਾ ਲਵਾਂਗੇ, ਅਤੇ ਇਸ ਤੱਥ ਵੱਲ ਕਿ ਡੇਟਾ L1 ਕੈਸ਼ ਵਿੱਚ ਰਹੇਗਾ ਅਤੇ ਹੌਲੀ ਮੈਮੋਰੀ ਵਿੱਚ ਜਾਣ ਦਾ ਸਮਾਂ ਨਹੀਂ ਹੋਵੇਗਾ. ਅਤੇ ਫਿਰ ਸਾਨੂੰ ਇਹ ਸਮਝਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਕਿ ਸਾਨੂੰ ਇਹ ਬਲਾਕ ਆਕਾਰ ਕੌਣ ਦੱਸੇਗਾ.

ਡੈਰੀਵੇਟਿਵ ਕੈਲਕੁਲੇਟਰ ਨੂੰ ਸੌਂਪਣਾ ਲਾਜ਼ੀਕਲ ਹੈ, ਕਿਉਂਕਿ ਸਿਰਫ ਉਹ ਹੀ ਜਾਣਦਾ ਹੈ ਕਿ ਉਸਨੂੰ ਕਿੰਨੀ ਕੈਸ਼ ਦੀ ਲੋੜ ਹੈ। ਅੱਗੇ, ਤੁਹਾਨੂੰ ਲੂਪ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣ ਦੀ ਲੋੜ ਹੈ ਜੋ ਅਸੀਂ ਐਰੇ ਰਾਹੀਂ ਦੇਖਿਆ ਸੀ। ਇਸ ਨੂੰ ਦੋ ਵਿੱਚ ਵੰਡਣ ਦੀ ਲੋੜ ਹੈ. ਬਾਹਰੀ ਲੂਪ ਬਲਾਕਾਂ ਵਿੱਚੋਂ ਲੰਘੇਗਾ, ਅਤੇ ਅੰਦਰ ਅਸੀਂ ਬਲਾਕ ਦੇ ਤੱਤਾਂ ਵਿੱਚੋਂ ਦੋ ਵਾਰ ਜਾਵਾਂਗੇ।

ਇਹ ਇੱਥੇ ਹੈ, ਬਲਾਕ ਦੁਆਰਾ ਬਾਹਰੀ.

ਅਤੇ ਇੱਥੇ ਬਲਾਕ ਦਾ ਅੰਦਰੂਨੀ ਤੱਤ ਹੈ.

ਅਸੀਂ ਇਸ ਗੱਲ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹਾਂ ਕਿ ਆਖਰੀ ਬਲਾਕ ਅਧੂਰਾ ਹੋ ਸਕਦਾ ਹੈ।

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

ਦੋ ਕਾਰਨ ਹਨ। ਪਹਿਲਾਂ, ਹੀਪ 'ਤੇ ਵੈਕਟਰ ਨਿਰਧਾਰਤ ਕਰਨਾ। ਸੰਭਾਵਨਾਵਾਂ ਚੰਗੀਆਂ ਹਨ ਕਿ ਇਸ ਵੈਕਟਰ ਨੂੰ ਵਾਰ-ਵਾਰ ਬਣਾਇਆ ਅਤੇ ਨਸ਼ਟ ਕੀਤਾ ਜਾਵੇਗਾ। ਗਤੀ ਦੇ ਸੰਦਰਭ ਵਿੱਚ ਦੂਜਾ ਘਟਾਓ ਇਹ ਹੈ ਕਿ ਹਰ ਵਾਰ ਅਸੀਂ ਮੈਮੋਰੀ ਪ੍ਰਾਪਤ ਕਰਾਂਗੇ, ਸ਼ਾਇਦ ਇੱਕ ਨਵੇਂ ਪਤੇ 'ਤੇ। ਇਹ ਮੈਮੋਰੀ ਕੈਸ਼ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ "ਠੰਡੇ" ਹੋਵੇਗੀ, ਭਾਵ, ਇਸ ਨੂੰ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ, ਪ੍ਰੋਸੈਸਰ ਕੈਸ਼ ਵਿੱਚ ਡੇਟਾ ਨੂੰ ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਇੱਕ ਸਹਾਇਕ ਰੀਡ ਕਰੇਗਾ.

ਇਸ ਨੂੰ ਠੀਕ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਅਲਾਟਮੈਂਟ ਨੂੰ ਲੂਪ ਤੋਂ ਬਾਹਰ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਅਜਿਹਾ ਕਰਨ ਲਈ, ਸਾਨੂੰ ਇੰਟਰਫੇਸ ਨੂੰ ਦੁਬਾਰਾ ਬਦਲਣਾ ਹੋਵੇਗਾ, ਵੈਕਟਰ ਵਾਪਸ ਕਰਨਾ ਬੰਦ ਕਰਨਾ ਹੋਵੇਗਾ ਅਤੇ ਮੈਮੋਰੀ ਵਿੱਚ ਡੈਰੀਵੇਟਿਵਜ਼ ਲਿਖਣਾ ਸ਼ੁਰੂ ਕਰਨਾ ਹੋਵੇਗਾ ਜੋ ਅਸੀਂ ਕਾਲਿੰਗ ਕੋਡ ਤੋਂ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਾਂ।

ਇਹ ਇੱਕ ਮਿਆਰੀ ਤਕਨੀਕ ਹੈ - ਕੰਪਿਊਟੇਸ਼ਨਲ ਕੋਡ ਵਿੱਚ ਰੁਕਾਵਟਾਂ ਤੋਂ ਸਰੋਤਾਂ ਦੇ ਨਾਲ ਸਾਰੀਆਂ ਹੇਰਾਫੇਰੀਆਂ ਨੂੰ ਹਟਾਉਣਾ। ਚਲੋ ਕੈਲਕਡਰ ਵਿਧੀ ਵਿੱਚ ਇੱਕ ਹੋਰ ਪੈਰਾਮੀਟਰ ਜੋੜੀਏ, ਵੈਕਟਰ 'ਤੇ ਵੇਖੋ ਜਿੱਥੇ ਡੈਰੀਵੇਟਿਵਜ਼ ਡਿੱਗਣੇ ਚਾਹੀਦੇ ਹਨ।

ਕੋਡ ਵੀ ਸਪੱਸ਼ਟ ਤਰੀਕੇ ਨਾਲ ਬਦਲ ਜਾਵੇਗਾ। ਡੈਰੀਵੇਟਿਵ ਵੈਕਟਰ ਇੱਕ ਹੋਵੇਗਾ, ਸਾਰੇ ਲੂਪਸ ਤੋਂ ਬਾਹਰ, ਅਤੇ ਇੱਕ ਨਵਾਂ ਪੈਰਾਮੀਟਰ ਬਸ ਢੰਗ ਵਿੱਚ ਜੋੜਿਆ ਜਾਵੇਗਾ।

ਅਸੀਂ ਦੇਖਦੇ ਹਾਂ। ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਅਸੀਂ ਪਿਛਲੇ ਸੰਸਕਰਣ ਦੇ ਮੁਕਾਬਲੇ ਲਗਭਗ ਅੱਠ ਪ੍ਰਤੀਸ਼ਤ ਜਿੱਤੇ ਹਨ, ਅਤੇ ਬੇਸ ਸੰਸਕਰਣ ਦੇ ਮੁਕਾਬਲੇ - ਪਹਿਲਾਂ ਹੀ 15%.

ਇਹ ਸਪੱਸ਼ਟ ਹੈ ਕਿ ਓਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਓਵਰਹੈੱਡ ਲਾਗਤਾਂ ਦੇ ਅਮੋਰਟਾਈਜ਼ੇਸ਼ਨ ਤੱਕ ਸੀਮਿਤ ਨਹੀਂ ਹਨ, ਕਿ ਹੋਰ ਕਿਸਮ ਦੀਆਂ ਰੁਕਾਵਟਾਂ ਹਨ.

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

ਆਉ ਮਾਪੀਏ ਕਿ ਇਹ ਕੋਡ ਕਾਫ਼ੀ ਵੱਡੇ ਮੈਟਰਿਕਸ ਅਤੇ ਇੱਕ ਖਾਸ ਮਸ਼ੀਨ ਤੇ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ।

ਉਦਾਹਰਨ ਲਈ, ਮੈਂ ਕਤਾਰਾਂ ਦੀ ਗਿਣਤੀ 1000, ਕਾਲਮਾਂ ਦੀ ਸੰਖਿਆ 100 ਲਈ। ਮਸ਼ੀਨ ਇੱਕ ਇੰਟੇਲ ਸਰਵਰ, ਇੱਕ ਕੋਰ ਹੈ। ਮੈਮੋਰੀ ਤਾਂ ਉਸੇ ਤਰ੍ਹਾਂ ਦੀ ਹੈ, ਸਾਡੇ ਲਈ ਜ਼ਰੂਰੀ ਹੈ, ਕਿਉਂਕਿ ਮੈਮੋਰੀ ਨਾਲ ਸਾਰਾ ਕੰਮ ਅਤੇ ਗਤੀ ਮੈਮੋਰੀ ਦੀ ਗਤੀ 'ਤੇ ਨਿਰਭਰ ਕਰੇਗੀ। ਅਸੀਂ ਮਾਪਿਆ ਅਤੇ 000 ਐਸ. ਕੀ ਇਹ ਬਹੁਤ ਹੈ ਜਾਂ ਥੋੜਾ? ਇਸ ਸਮੇਂ ਦੌਰਾਨ ਅਸੀਂ ਕੀ ਕਰ ਸਕਦੇ ਹਾਂ?

ਸਾਡੇ ਕੋਲ 800 ਮੈਗਾਬਾਈਟ ਪੜ੍ਹਨ ਦਾ ਸਮਾਂ ਹੈ, ਇਹ ਟ੍ਰਾਂਸਪੋਜ਼ਡ ਮੈਟ੍ਰਿਕਸ ਨਹੀਂ ਹੈ, ਪਰ ਅਸਲੀ ਹੈ। ਅਤੇ 1,6 GB ਪੜ੍ਹੋ ਅਤੇ ਲਿਖੋ, ਇਹ ਪਹਿਲਾਂ ਹੀ ਇੱਕ ਟ੍ਰਾਂਸਪੋਜ਼ਡ ਮੈਟ੍ਰਿਕਸ ਹੈ। ਪ੍ਰੋਸੈਸਰ ਕੈਸ਼ ਵਿੱਚ ਡੇਟਾ ਨੂੰ ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਸਹਾਇਕ ਰੀਡ ਕਰਦਾ ਹੈ।

ਆਓ ਗਣਨਾ ਕਰੀਏ ਕਿ ਅਸੀਂ ਲਾਭ ਦੇ ਨਾਲ ਕਿੰਨੀ ਬੈਂਡਵਿਡਥ ਵਰਤੀ ਹੈ। ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਸਾਡੇ ਕੋਡ ਦਾ ਥ੍ਰੋਪੁੱਟ 1,7 GB / s ਸੀ.

ਇਹ ਇੱਕ ਸਿਧਾਂਤਕ ਗਣਨਾ ਸੀ। ਫਿਰ ਤੁਸੀਂ ਇੱਕ ਪ੍ਰੋਫਾਈਲਰ ਲੈ ਸਕਦੇ ਹੋ ਜੋ ਮੈਮੋਰੀ ਨਾਲ ਕੰਮ ਕਰਨ ਦੀ ਗਤੀ ਨੂੰ ਮਾਪ ਸਕਦਾ ਹੈ. ਮੈਂ VTune ਲਿਆ। ਆਓ ਦੇਖੀਏ ਕਿ ਇਹ ਕੀ ਦਿਖਾਉਂਦਾ ਹੈ। ਇੱਕ ਸਮਾਨ ਚਿੱਤਰ ਦਿਖਾਉਂਦਾ ਹੈ - 1,8 GB. ਸਿਧਾਂਤਕ ਤੌਰ 'ਤੇ, ਇਹ ਚੰਗੀ ਤਰ੍ਹਾਂ ਸਹਿਮਤ ਹੈ, ਕਿਉਂਕਿ ਸਾਡੀ ਗਣਨਾ ਵਿੱਚ ਅਸੀਂ ਇਸ ਗੱਲ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਨਹੀਂ ਰੱਖਿਆ ਕਿ ਸਾਨੂੰ ਕਤਾਰ ਦੇ ਪਤੇ ਅਤੇ ਕਾਲਮ ਪਤੇ ਪੜ੍ਹਣੇ ਹਨ। ਨਾਲ ਹੀ, VTune ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਨਾਲ ਬੈਕਗਰਾਊਂਡ ਗਤੀਵਿਧੀ ਨੂੰ ਰਜਿਸਟਰ ਕਰਦਾ ਹੈ। ਇਸ ਲਈ, ਸਾਡਾ ਮਾਡਲ ਅਸਲੀਅਤ ਨਾਲ ਇਕਸਾਰ ਹੈ.

ਇਹ ਸਮਝਣ ਲਈ ਕਿ ਕੀ 1,7 GB ਬਹੁਤ ਹੈ ਜਾਂ ਥੋੜਾ, ਤੁਹਾਨੂੰ ਇਹ ਪਤਾ ਲਗਾਉਣ ਦੀ ਲੋੜ ਹੈ ਕਿ ਸਾਡੇ ਲਈ ਕਿਹੜੀ ਵੱਧ ਤੋਂ ਵੱਧ ਬੈਂਡਵਿਡਥ ਉਪਲਬਧ ਹੈ।

ਅਜਿਹਾ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਪ੍ਰੋਸੈਸਰ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਪੜ੍ਹਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ. ਇੱਥੇ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਸਾਈਟ ark.intel.com ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਕਿਸੇ ਵੀ ਪ੍ਰੋਸੈਸਰ ਬਾਰੇ ਸਭ ਕੁਝ ਲੱਭ ਸਕਦੇ ਹੋ। ਜੇ ਅਸੀਂ ਖਾਸ ਤੌਰ 'ਤੇ ਸਾਡੇ ਸਰਵਰ ਨੂੰ ਵੇਖਦੇ ਹਾਂ, ਤਾਂ ਅਸੀਂ ਦੇਖਦੇ ਹਾਂ ਕਿ ਇਸ ਵਿੱਚ ਅੱਠ ਕੋਰ ਹਨ ਅਤੇ ਸਭ ਤੋਂ ਤੇਜ਼ DDR3 ਮੈਮੋਰੀ ਲਈ ਇਹ ਸਮਰਥਨ ਕਰਦਾ ਹੈ, ਲਗਭਗ 60 GB / s ਇੱਕ ਤਰੀਕੇ ਨਾਲ ਟ੍ਰਾਂਸਫਰ ਕਰਦਾ ਹੈ.

ਪਰ ਇੱਥੇ ਸਾਨੂੰ ਇਹ ਧਿਆਨ ਵਿੱਚ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਅਸੀਂ ਸਿਰਫ ਇੱਕ ਕੋਰ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ ਅਤੇ ਸਾਡੀ ਮੈਮੋਰੀ ਹੌਲੀ ਹੈ, ਭਾਵ, ਸਾਨੂੰ ਕੋਰ ਅਤੇ ਮੈਮੋਰੀ ਬਾਰੰਬਾਰਤਾ ਦੀ ਸੰਖਿਆ ਦੇ ਅਨੁਪਾਤ ਵਿੱਚ ਇਹਨਾਂ 60 GB ਨੂੰ ਆਪਣੀਆਂ ਸਥਿਤੀਆਂ ਵਿੱਚ ਸਕੇਲ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਸਾਡਾ ਕੋਡ 5,3 GB ਇੱਕ ਤਰਫਾ ਵਰਤ ਸਕਦਾ ਹੈ। ਅਤੇ ਕਿਉਂਕਿ ਤੁਸੀਂ ਸਮਾਨਾਂਤਰ ਵਿੱਚ ਪੜ੍ਹ ਅਤੇ ਲਿਖ ਸਕਦੇ ਹੋ, ਫਿਰ ਆਦਰਸ਼ਕ ਤੌਰ 'ਤੇ, ਜੇਕਰ ਅਸੀਂ ਸਿਰਫ਼ ਇੱਕ ਥਾਂ ਤੋਂ ਡਾਟਾ ਕਾਪੀ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਅਸੀਂ 10,6 ਤੱਕ ਪਹੁੰਚ ਜਾਵਾਂਗੇ। ਕਿਉਂਕਿ ਸਾਡੇ ਕੋਲ ਦੋ ਰੀਡ ਅਤੇ ਇੱਕ ਰਾਈਟ ਹੈ, ਇਹ ਲਗਭਗ 8 GB/s ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਸਾਨੂੰ ਯਾਦ ਹੈ ਕਿ ਸਾਨੂੰ 1,7 ਮਿਲੀ ਹੈ। ਭਾਵ, ਅਸੀਂ ਲਗਭਗ 20% ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਹੈ.

ਅਜਿਹਾ ਕਿਉਂ ਹੈ? ਦੁਬਾਰਾ ਫਿਰ, ਤੁਹਾਨੂੰ ਆਰਕੀਟੈਕਚਰ ਨਾਲ ਨਜਿੱਠਣ ਦੀ ਲੋੜ ਹੈ. ਤੱਥ ਇਹ ਹੈ ਕਿ ਮੈਮੋਰੀ ਅਤੇ ਕੈਸ਼ ਦੇ ਵਿਚਕਾਰ ਡੇਟਾ ਨੂੰ ਮਨਮਾਨੇ ਪੈਕੇਟਾਂ ਵਿੱਚ ਟ੍ਰਾਂਸਫਰ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਪਰ 64 ਬਾਈਟਾਂ ਵਿੱਚ ਬਿਲਕੁਲ, ਹੋਰ ਨਹੀਂ, ਘੱਟ ਨਹੀਂ. ਇਹ ਪਹਿਲਾ ਵਿਚਾਰ ਹੈ।

ਦੂਜਾ ਵਿਚਾਰ ਇਹ ਹੈ ਕਿ ਅਸੀਂ ਟ੍ਰਾਂਸਪੋਜ਼ਡ ਡੇਟਾ ਨੂੰ ਕ੍ਰਮਵਾਰ ਨਹੀਂ, ਸਗੋਂ ਬੇਤਰਤੀਬੇ ਤੌਰ 'ਤੇ ਲਿਖਦੇ ਹਾਂ, ਕਿਉਂਕਿ ਮੈਟ੍ਰਿਕਸ ਦੀਆਂ ਕਤਾਰਾਂ ਇੱਕ ਅਣਪਛਾਤੇ ਤਰੀਕੇ ਨਾਲ ਮੈਮੋਰੀ ਵਿੱਚ ਸਥਿਤ ਹੁੰਦੀਆਂ ਹਨ।

ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਇੱਕ ਅਸਲੀ ਨੰਬਰ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ, ਸਾਨੂੰ 64 ਬਾਈਟ ਡੇਟਾ ਨੂੰ ਘਟਾਉਣਾ ਪੈਂਦਾ ਹੈ। ਜੇਕਰ ਅਸੀਂ ਮੈਟ੍ਰਿਕਸ N ਦੇ ਆਕਾਰ ਨੂੰ ਦਰਸਾਉਂਦੇ ਹਾਂ, ਤਾਂ ਅਨੁਕੂਲ ਓਪਰੇਟਿੰਗ ਸਮੇਂ (N / 5,3 + N / 10,6) ਦੀ ਬਜਾਏ, ਸਾਨੂੰ (8 * N / 5,3 + N / 10,6) ਮਿਲਦਾ ਹੈ। ਕਿਤੇ ਚਾਰ ਤੋਂ ਪੰਜ ਗੁਣਾ ਜ਼ਿਆਦਾ, ਜੋ ਕਿ 20% ਦੀ ਇਸ ਕੁਸ਼ਲਤਾ ਦੀ ਵਿਆਖਿਆ ਕਰਦਾ ਹੈ.

ਇਸ ਨਾਲ ਕੀ ਕਰਨਾ ਹੈ? ਤੁਹਾਨੂੰ ਇੱਕ ਕਾਲਮ ਵਿੱਚ ਡਾਟਾ ਲਿਖਣਾ ਬੰਦ ਕਰਨ ਦੀ ਲੋੜ ਹੈ ਅਤੇ ਇੱਕ ਕੈਸ਼ ਲਾਈਨ (64 ਬਾਈਟ) ਵਿੱਚ ਫਿੱਟ ਹੋਣ ਵਾਲੇ ਬਹੁਤ ਸਾਰੇ ਕਾਲਮ ਲਿਖਣੇ ਸ਼ੁਰੂ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਅਜਿਹਾ ਕਰਨ ਲਈ, ਅਸੀਂ ਕਾਲਮਾਂ ਉੱਤੇ ਚੱਕਰ ਨੂੰ ਕੈਸ਼ ਲਾਈਨਾਂ ਉੱਤੇ ਇੱਕ ਚੱਕਰ ਵਿੱਚ ਅਤੇ ਕੈਸ਼ ਲਾਈਨ ਤੱਤਾਂ ਉੱਤੇ ਇੱਕ ਨੇਸਟਡ ਲੂਪ ਵਿੱਚ ਵੰਡਦੇ ਹਾਂ।

ਇੱਥੇ ਉਹ ਹਨ, ਕੈਸ਼ ਲਾਈਨਾਂ ਉੱਤੇ ਦੁਹਰਾਓ।

ਅਤੇ ਇੱਥੇ ਉਹ ਹਨ, ਕੈਸ਼ ਲਾਈਨ ਦੇ ਅੰਦਰ ਦੁਹਰਾਓ. ਇੱਥੇ, ਸਰਲਤਾ ਲਈ, ਅਸੀਂ ਇਹ ਮੰਨਦੇ ਹਾਂ ਕਿ ਡੇਟਾ ਕੈਸ਼ ਲਾਈਨ ਦੇ ਬਾਰਡਰ ਨਾਲ ਇਕਸਾਰ ਹੈ। ਆਉ ਹੁਣ VTune ਨਾਲ ਜਾਂਚ ਕਰੀਏ ਕਿ ਕੀ ਹੁੰਦਾ ਹੈ।

ਅਸੀਂ ਦੇਖਦੇ ਹਾਂ ਕਿ ਅੱਠ ਗੀਗਾਬਾਈਟ ਪ੍ਰਤੀ ਸਕਿੰਟ - 7,6 ਦੇ ਨੇੜੇ ਕੀ ਹੋਇਆ। ਪਰ ਇਹ ਅਜੇ ਤੱਕ ਇੱਕ ਤੱਥ ਨਹੀਂ ਹੈ ਕਿ ਇਹ ਸਾਰੇ 7,6 ਉਪਯੋਗੀ ਕੰਮ ਹਨ. ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੁਝ ਓਵਰਹੈੱਡ ਹਨ.

ਇਹ ਸਮਝਣ ਲਈ ਕਿ ਸਾਨੂੰ ਕਿੰਨਾ ਲਾਭ ਮਿਲਿਆ, ਆਓ ਆਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਤੋਂ ਬਾਅਦ ਚੱਲ ਰਹੇ ਸਮੇਂ ਨੂੰ ਮਾਪੀਏ। ਇਹ ਉਸੇ ਮਸ਼ੀਨ 'ਤੇ 0,5 ਐੱਸ. ਥ੍ਰੁਪੁੱਟ, ਜੋ ਕਿ ਟਰਾਂਸਪੋਜ਼ੀਸ਼ਨ ਦੁਆਰਾ ਹੀ ਗਿਣਿਆ ਜਾਂਦਾ ਹੈ, 4,8 GB/s ਬਣ ​​ਗਿਆ ਹੈ। ਇਹ ਦੇਖਿਆ ਜਾ ਸਕਦਾ ਹੈ ਕਿ ਅਜੇ ਵੀ ਇੱਕ ਮਾਰਜਿਨ ਹੈ ਜੋ ਅਸੀਂ ਨਹੀਂ ਚੁਣਿਆ, ਪਰ ਕਿਸੇ ਵੀ ਤਰ੍ਹਾਂ, ਅਸੀਂ 20 ਪ੍ਰਤੀਸ਼ਤ ਕੁਸ਼ਲਤਾ ਤੋਂ 60 ਪ੍ਰਤੀਸ਼ਤ ਪ੍ਰਾਪਤ ਕੀਤਾ.

ਪ੍ਰੋਫਾਈਲਰ ਦੀ ਮਦਦ ਨਾਲ, ਤੁਸੀਂ ਇਹ ਪਤਾ ਲਗਾ ਸਕਦੇ ਹੋ ਕਿ ਸਾਨੂੰ 80% ਜਾਂ 95% ਕਿਉਂ ਨਹੀਂ ਮਿਲਿਆ।

ਹਕੀਕਤ ਇਹ ਹੈ ਕਿ ਅਸੀਂ ਮੈਟ੍ਰਿਕਸ ਨੂੰ ਵੈਕਟਰ ਦੇ ਇੱਕ ਵੈਕਟਰ ਦੇ ਤੌਰ ਤੇ ਸਟੋਰ ਕਰਦੇ ਹਾਂ, ਯਾਨੀ ਕਿ ਅਸੀਂ ਡਬਲ ਇਨਡਾਇਰੈਕਸ਼ਨ ਨਾਲ ਮੈਮੋਰੀ ਐਕਸੈਸ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ।

VTune ਨਾਲ, ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ ਕਿ ਐਰੇ ਐਲੀਮੈਂਟਸ ਨੂੰ ਐਕਸੈਸ ਕਰਨ ਲਈ ਕਿਹੜੀਆਂ ਹਦਾਇਤਾਂ ਤਿਆਰ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ। ਟ੍ਰਾਂਸਪੋਜ਼ਡ ਮੈਟ੍ਰਿਕਸ ਦੇ ਕਾਲਮਾਂ ਦੇ ਪਤਿਆਂ ਨੂੰ ਘਟਾਉਣ ਵਾਲੀਆਂ ਹਦਾਇਤਾਂ ਨੂੰ ਖੱਬੇ ਪਾਸੇ ਪੀਲੇ ਰੰਗ ਵਿੱਚ ਉਜਾਗਰ ਕੀਤਾ ਗਿਆ ਹੈ। ਅਤੇ ਇਹ ਹਨ, ਪਹਿਲਾਂ, ਵਾਧੂ ਹਦਾਇਤਾਂ, ਅਤੇ ਦੂਜਾ, ਵਾਧੂ ਡੇਟਾ ਟ੍ਰਾਂਸਫਰ। ਪਰ ਅਸੀਂ ਹੋਰ ਅਨੁਕੂਲ ਨਹੀਂ ਕਰਾਂਗੇ, ਅਸੀਂ ਰੁਕਾਂਗੇ ਅਤੇ ਸੰਖੇਪ ਕਰਾਂਗੇ.

ਮੈਂ ਤੁਹਾਨੂੰ ਅੱਜ ਕੀ ਕਿਹਾ? ਕੰਪਿਊਟੇਸ਼ਨਲ ਕੋਡ ਦੇ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਇੱਕ ਉਪਯੋਗੀ ਟਿਪ ਬਲਾਕਾਂ ਵਿੱਚ ਪ੍ਰਕਿਰਿਆ ਕਰਨਾ ਹੈ, ਓਵਰਹੈੱਡ ਲਾਗਤਾਂ ਨੂੰ ਸੋਧਣਾ ਜੋ ਸੰਬੰਧਿਤ ਹਨ, ਉਦਾਹਰਨ ਲਈ, ਵਰਚੁਅਲ ਕਾਲਾਂ ਨਾਲ। ਨਾਲ ਹੀ, ਬਲੌਕ ਕਰਨ ਦੇ ਕਾਰਨ, ਡਾਟਾ ਸਥਾਨਿਕਤਾ ਵਿੱਚ ਸੁਧਾਰ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਸਾਨੂੰ ਇੱਕ ਉੱਚ ਪਹੁੰਚ ਗਤੀ ਮਿਲਦੀ ਹੈ।

ਅੜਚਨਾਂ ਤੋਂ ਅਲਾਟਮੈਂਟ ਨੂੰ ਦੂਰ ਕਰਨਾ ਵੀ ਉਨ੍ਹਾਂ ਦਾ ਘਟਾਓ ਹੈ। ਅਤੇ ਮੈਮੋਰੀ ਵਿੱਚ ਅਸਥਾਈ ਬਫਰਾਂ ਨੂੰ ਫਿਕਸ ਕਰਕੇ ਐਕਸੈਸ ਸਪੀਡ ਵਿੱਚ ਵਾਧਾ ਵੀ।

ਪਰੋਫਾਈਲਿੰਗ ਬਾਰੇ. ਪਹਿਲਾਂ, "ਆਮ ਕੇਸ ਵਿੱਚ" ਰੁਕਾਵਟਾਂ ਨੂੰ ਲੱਭਣ ਲਈ ਪ੍ਰੋਫਾਈਲਿੰਗ ਇੱਕ ਉਪਯੋਗੀ ਤਕਨੀਕ ਹੈ। ਦੂਜਾ, ਇਹ ਸਾਨੂੰ ਕੋਡ ਦੀ ਕੁਸ਼ਲਤਾ ਦਾ ਮੁਲਾਂਕਣ ਕਰਨ, ਇਹ ਫੈਸਲਾ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਕਿ ਕੀ ਅਸੀਂ ਗਤੀ ਤੋਂ ਸੰਤੁਸ਼ਟ ਹਾਂ ਜਾਂ ਹੋਰ ਅਨੁਕੂਲ ਬਣਾਉਣਾ ਚਾਹੁੰਦੇ ਹਾਂ, ਅਤੇ ਇਹ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਕਿਸ ਦਿਸ਼ਾ ਵਿੱਚ ਜਾਣਾ ਹੈ।

ਇਹ ਸਭ ਮੇਰੇ ਲਈ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ CatBoost ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ ਜਾਂ ਪਹਿਲੀ ਵਾਰ ਇਸ ਬਾਰੇ ਸੁਣਿਆ ਹੈ ਅਤੇ ਇਹ ਜਾਣਨਾ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਇਹ ਕੀ ਹੈ, ਤਾਂ ਪੜ੍ਹੋ Habré 'ਤੇ ਲੇਖਸਾਨੂੰ ਮਿਲਣ ਲਈ ਆਓ GitHub, ਨੂੰ ਲਿਖੋ ਤਾਰ. ਤੁਹਾਡੇ ਧਿਆਨ ਲਈ ਤੁਹਾਡਾ ਬਹੁਤ ਬਹੁਤ ਧੰਨਵਾਦ।

ਸਰੋਤ: www.habr.com