Cliff ਕਲਿੱਕ ਕਰੋ — Cratus (ਪ੍ਰਕਿਰਿਆ ਸੁਧਾਰ ਲਈ IoT ਸੈਂਸਰ), ਕਈ ਸਫਲ ਨਿਕਾਸਾਂ ਦੇ ਨਾਲ ਕਈ ਸਟਾਰਟਅੱਪਸ (ਰਾਕੇਟ ਰੀਅਲਟਾਈਮ ਸਕੂਲ, ਨਿਊਰੇਂਸਿਕ ਅਤੇ H2O.ai ਸਮੇਤ) ਦੇ ਸੰਸਥਾਪਕ ਅਤੇ ਸਹਿ-ਸੰਸਥਾਪਕ। ਕਲਿਫ ਨੇ ਆਪਣਾ ਪਹਿਲਾ ਕੰਪਾਈਲਰ 15 ਸਾਲ ਦੀ ਉਮਰ ਵਿੱਚ ਲਿਖਿਆ (ਟੀਆਰਐਸ ਜ਼ੈਡ-80 ਲਈ ਪਾਸਕਲ)! ਉਹ ਜਾਵਾ (ਨੋਡਸ IR ਦਾ ਸਾਗਰ) ਵਿੱਚ C2 'ਤੇ ਆਪਣੇ ਕੰਮ ਲਈ ਸਭ ਤੋਂ ਵੱਧ ਜਾਣਿਆ ਜਾਂਦਾ ਹੈ। ਇਸ ਕੰਪਾਈਲਰ ਨੇ ਦੁਨੀਆ ਨੂੰ ਦਿਖਾਇਆ ਕਿ ਜੇਆਈਟੀ ਉੱਚ-ਗੁਣਵੱਤਾ ਕੋਡ ਤਿਆਰ ਕਰ ਸਕਦੀ ਹੈ, ਜੋ ਕਿ ਜਾਵਾ ਦੇ ਮੁੱਖ ਆਧੁਨਿਕ ਸੌਫਟਵੇਅਰ ਪਲੇਟਫਾਰਮਾਂ ਵਿੱਚੋਂ ਇੱਕ ਦੇ ਰੂਪ ਵਿੱਚ ਉਭਰਨ ਵਿੱਚ ਇੱਕ ਕਾਰਕ ਸੀ। ਫਿਰ Cliff ਨੇ ਸ਼ੁੱਧ Java ਸੌਫਟਵੇਅਰ ਨਾਲ ਇੱਕ 864-ਕੋਰ ਮੇਨਫ੍ਰੇਮ ਬਣਾਉਣ ਵਿੱਚ Azul Systems ਦੀ ਮਦਦ ਕੀਤੀ ਜੋ 500 ਮਿਲੀਸਕਿੰਟ ਦੇ ਅੰਦਰ 10-ਗੀਗਾਬਾਈਟ ਹੀਪ 'ਤੇ GC ਵਿਰਾਮ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ। ਆਮ ਤੌਰ 'ਤੇ, ਕਲਿਫ ਜੇਵੀਐਮ ਦੇ ਸਾਰੇ ਪਹਿਲੂਆਂ 'ਤੇ ਕੰਮ ਕਰਨ ਵਿੱਚ ਕਾਮਯਾਬ ਰਿਹਾ।

 
ਇਹ ਹੈਬਰਾਪੋਸਟ ਕਲਿਫ ਨਾਲ ਇੱਕ ਸ਼ਾਨਦਾਰ ਇੰਟਰਵਿਊ ਹੈ. ਅਸੀਂ ਹੇਠਾਂ ਦਿੱਤੇ ਵਿਸ਼ਿਆਂ 'ਤੇ ਗੱਲ ਕਰਾਂਗੇ:

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

ਇੰਟਰਵਿਊ ਇਹਨਾਂ ਦੁਆਰਾ ਕਰਵਾਏ ਜਾਂਦੇ ਹਨ:

• ਐਂਡਰੀ ਸਤਾਰਿਨ ਐਮਾਜ਼ਾਨ ਵੈੱਬ ਸੇਵਾਵਾਂ ਤੋਂ। ਆਪਣੇ ਕਰੀਅਰ ਵਿੱਚ, ਉਹ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵੱਖ-ਵੱਖ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਕੰਮ ਕਰਨ ਵਿੱਚ ਕਾਮਯਾਬ ਰਿਹਾ: ਉਸਨੇ Yandex ਵਿੱਚ NewSQL ਡਿਸਟ੍ਰੀਬਿਊਟਡ ਡੇਟਾਬੇਸ, Kaspersky ਲੈਬ ਵਿੱਚ ਇੱਕ ਕਲਾਉਡ ਖੋਜ ਪ੍ਰਣਾਲੀ, Mail.ru ਵਿੱਚ ਇੱਕ ਮਲਟੀਪਲੇਅਰ ਗੇਮ ਅਤੇ Deutsche Bank ਵਿੱਚ ਵਿਦੇਸ਼ੀ ਮੁਦਰਾ ਦੀਆਂ ਕੀਮਤਾਂ ਦੀ ਗਣਨਾ ਕਰਨ ਲਈ ਇੱਕ ਸੇਵਾ ਦੀ ਜਾਂਚ ਕੀਤੀ। ਵੱਡੇ ਪੈਮਾਨੇ ਦੇ ਬੈਕਐਂਡ ਅਤੇ ਵਿਤਰਿਤ ਪ੍ਰਣਾਲੀਆਂ ਦੀ ਜਾਂਚ ਕਰਨ ਵਿੱਚ ਦਿਲਚਸਪੀ ਹੈ।
• ਵਲਾਦੀਮੀਰ ਸਿਟਨੀਕੋਵ Netcracker ਤੋਂ. NetCracker OS ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਅਤੇ ਸਕੇਲੇਬਿਲਟੀ 'ਤੇ ਦਸ ਸਾਲਾਂ ਦਾ ਕੰਮ, ਟੈਲੀਕਾਮ ਆਪਰੇਟਰਾਂ ਦੁਆਰਾ ਨੈੱਟਵਰਕ ਅਤੇ ਨੈੱਟਵਰਕ ਉਪਕਰਣ ਪ੍ਰਬੰਧਨ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਸਵੈਚਾਲਿਤ ਕਰਨ ਲਈ ਵਰਤੇ ਜਾਂਦੇ ਸਾਫਟਵੇਅਰ। Java ਅਤੇ Oracle ਡਾਟਾਬੇਸ ਪ੍ਰਦਰਸ਼ਨ ਮੁੱਦਿਆਂ ਵਿੱਚ ਦਿਲਚਸਪੀ ਹੈ। ਅਧਿਕਾਰਤ PostgreSQL JDBC ਡਰਾਈਵਰ ਵਿੱਚ ਇੱਕ ਦਰਜਨ ਤੋਂ ਵੱਧ ਕਾਰਗੁਜ਼ਾਰੀ ਸੁਧਾਰਾਂ ਦਾ ਲੇਖਕ।

ਨਿਮਨ-ਪੱਧਰ ਦੇ ਅਨੁਕੂਲਨ ਵਿੱਚ ਤਬਦੀਲੀ

ਆਂਦਰੇਈ: ਤੁਸੀਂ JIT ਸੰਕਲਨ, ਜਾਵਾ, ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਪ੍ਰਦਰਸ਼ਨ ਦੇ ਕੰਮ ਦੀ ਦੁਨੀਆ ਵਿੱਚ ਇੱਕ ਵੱਡਾ ਨਾਮ ਹੋ, ਠੀਕ ਹੈ? 

ਚੱਟਾਨ: ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਹੈ!

ਆਂਦਰੇਈ: ਆਉ ਪ੍ਰਦਰਸ਼ਨ ਦੇ ਕੰਮ ਬਾਰੇ ਕੁਝ ਆਮ ਸਵਾਲਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੀਏ। ਤੁਸੀਂ CPU ਪੱਧਰ 'ਤੇ ਕੰਮ ਕਰਨ ਵਰਗੇ ਉੱਚ-ਪੱਧਰ ਅਤੇ ਹੇਠਲੇ-ਪੱਧਰ ਦੇ ਅਨੁਕੂਲਨ ਵਿਚਕਾਰ ਚੋਣ ਬਾਰੇ ਕੀ ਸੋਚਦੇ ਹੋ?

ਚੱਟਾਨ: ਹਾਂ, ਇੱਥੇ ਸਭ ਕੁਝ ਸਧਾਰਨ ਹੈ। ਸਭ ਤੋਂ ਤੇਜ਼ ਕੋਡ ਉਹ ਹੈ ਜੋ ਕਦੇ ਨਹੀਂ ਚੱਲਦਾ। ਇਸ ਲਈ, ਤੁਹਾਨੂੰ ਹਮੇਸ਼ਾ ਉੱਚ ਪੱਧਰ ਤੋਂ ਸ਼ੁਰੂ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਐਲਗੋਰਿਦਮ 'ਤੇ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ. ਇੱਕ ਬਿਹਤਰ O ਨੋਟੇਸ਼ਨ ਇੱਕ ਬਦਤਰ O ਨੋਟੇਸ਼ਨ ਨੂੰ ਮਾਤ ਦੇਵੇਗੀ, ਜਦੋਂ ਤੱਕ ਕਿ ਕੁਝ ਕਾਫ਼ੀ ਵੱਡੇ ਸਥਿਰਾਂਕ ਦਖਲ ਨਹੀਂ ਦਿੰਦੇ। ਨੀਵੇਂ ਪੱਧਰ ਦੀਆਂ ਚੀਜ਼ਾਂ ਆਖਰੀ ਜਾਂਦੀਆਂ ਹਨ। ਆਮ ਤੌਰ 'ਤੇ, ਜੇਕਰ ਤੁਸੀਂ ਆਪਣੇ ਬਾਕੀ ਸਟੈਕ ਨੂੰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਅਨੁਕੂਲ ਬਣਾਇਆ ਹੈ ਅਤੇ ਅਜੇ ਵੀ ਕੁਝ ਦਿਲਚਸਪ ਸਮੱਗਰੀ ਬਾਕੀ ਹੈ, ਤਾਂ ਇਹ ਇੱਕ ਨੀਵਾਂ ਪੱਧਰ ਹੈ। ਪਰ ਉੱਚ ਪੱਧਰ ਤੋਂ ਕਿਵੇਂ ਸ਼ੁਰੂ ਕਰੀਏ? ਤੁਸੀਂ ਕਿਵੇਂ ਜਾਣਦੇ ਹੋ ਕਿ ਕਾਫ਼ੀ ਉੱਚ-ਪੱਧਰੀ ਕੰਮ ਕੀਤਾ ਗਿਆ ਹੈ? ਖੈਰ... ਕੋਈ ਤਰੀਕਾ ਨਹੀਂ। ਇੱਥੇ ਕੋਈ ਤਿਆਰ ਪਕਵਾਨ ਨਹੀਂ ਹਨ. ਤੁਹਾਨੂੰ ਸਮੱਸਿਆ ਨੂੰ ਸਮਝਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ, ਇਹ ਫੈਸਲਾ ਕਰੋ ਕਿ ਤੁਸੀਂ ਕੀ ਕਰਨ ਜਾ ਰਹੇ ਹੋ (ਤਾਂ ਕਿ ਭਵਿੱਖ ਵਿੱਚ ਬੇਲੋੜੇ ਕਦਮ ਨਾ ਚੁੱਕਣ) ਅਤੇ ਫਿਰ ਤੁਸੀਂ ਪ੍ਰੋਫਾਈਲਰ ਨੂੰ ਬੇਪਰਦ ਕਰ ਸਕਦੇ ਹੋ, ਜੋ ਕੁਝ ਲਾਭਦਾਇਕ ਕਹਿ ਸਕਦਾ ਹੈ. ਕਿਸੇ ਸਮੇਂ, ਤੁਸੀਂ ਖੁਦ ਮਹਿਸੂਸ ਕਰਦੇ ਹੋ ਕਿ ਤੁਸੀਂ ਬੇਲੋੜੀਆਂ ਚੀਜ਼ਾਂ ਤੋਂ ਛੁਟਕਾਰਾ ਪਾ ਲਿਆ ਹੈ ਅਤੇ ਇਹ ਕੁਝ ਘੱਟ-ਪੱਧਰ ਦੀ ਵਧੀਆ ਟਿਊਨਿੰਗ ਕਰਨ ਦਾ ਸਮਾਂ ਹੈ. ਇਹ ਯਕੀਨੀ ਤੌਰ 'ਤੇ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਕਿਸਮ ਦੀ ਕਲਾ ਹੈ। ਬਹੁਤ ਸਾਰੇ ਲੋਕ ਬੇਲੋੜੇ ਕੰਮ ਕਰ ਰਹੇ ਹਨ, ਪਰ ਇੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵਧ ਰਹੇ ਹਨ ਕਿ ਉਨ੍ਹਾਂ ਕੋਲ ਉਤਪਾਦਕਤਾ ਬਾਰੇ ਚਿੰਤਾ ਕਰਨ ਦਾ ਸਮਾਂ ਨਹੀਂ ਹੈ। ਪਰ ਇਹ ਉਦੋਂ ਤੱਕ ਹੈ ਜਦੋਂ ਤੱਕ ਸਵਾਲ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਨਹੀਂ ਉੱਠਦਾ. ਆਮ ਤੌਰ 'ਤੇ 99% ਸਮਾਂ ਕੋਈ ਵੀ ਇਸ ਗੱਲ ਦੀ ਪਰਵਾਹ ਨਹੀਂ ਕਰਦਾ ਕਿ ਮੈਂ ਕੀ ਕਰਦਾ ਹਾਂ, ਉਸ ਪਲ ਤੱਕ ਜਦੋਂ ਕੋਈ ਮਹੱਤਵਪੂਰਣ ਚੀਜ਼ ਨਾਜ਼ੁਕ ਮਾਰਗ 'ਤੇ ਆਉਂਦੀ ਹੈ ਜਿਸ ਦੀ ਕੋਈ ਪਰਵਾਹ ਨਹੀਂ ਕਰਦਾ। ਅਤੇ ਇੱਥੇ ਹਰ ਕੋਈ ਤੁਹਾਨੂੰ ਇਸ ਬਾਰੇ ਪਰੇਸ਼ਾਨ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦਾ ਹੈ ਕਿ "ਇਹ ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਪੂਰੀ ਤਰ੍ਹਾਂ ਕੰਮ ਕਿਉਂ ਨਹੀਂ ਕਰਦਾ." ਆਮ ਤੌਰ 'ਤੇ, ਪ੍ਰਦਰਸ਼ਨ ਵਿੱਚ ਸੁਧਾਰ ਕਰਨ ਲਈ ਹਮੇਸ਼ਾ ਕੁਝ ਹੁੰਦਾ ਹੈ. ਪਰ 99% ਵਾਰ ਤੁਹਾਡੇ ਕੋਲ ਕੋਈ ਲੀਡ ਨਹੀਂ ਹੈ! ਤੁਸੀਂ ਸਿਰਫ਼ ਕੁਝ ਕੰਮ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹੋ ਅਤੇ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਤੁਸੀਂ ਇਹ ਸਮਝਦੇ ਹੋ ਕਿ ਕੀ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਤੁਸੀਂ ਕਦੇ ਵੀ ਪਹਿਲਾਂ ਤੋਂ ਨਹੀਂ ਜਾਣ ਸਕਦੇ ਹੋ ਕਿ ਇਸ ਟੁਕੜੇ ਨੂੰ ਸੰਪੂਰਨ ਹੋਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ, ਇਸ ਲਈ, ਅਸਲ ਵਿੱਚ, ਤੁਹਾਨੂੰ ਹਰ ਚੀਜ਼ ਵਿੱਚ ਸੰਪੂਰਨ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ. ਪਰ ਇਹ ਅਸੰਭਵ ਹੈ ਅਤੇ ਤੁਸੀਂ ਅਜਿਹਾ ਨਹੀਂ ਕਰਦੇ. ਹਮੇਸ਼ਾ ਠੀਕ ਕਰਨ ਲਈ ਬਹੁਤ ਸਾਰੀਆਂ ਚੀਜ਼ਾਂ ਹੁੰਦੀਆਂ ਹਨ - ਅਤੇ ਇਹ ਪੂਰੀ ਤਰ੍ਹਾਂ ਆਮ ਹੈ।

ਇੱਕ ਵੱਡੀ ਰੀਫੈਕਟਰਿੰਗ ਕਿਵੇਂ ਕਰਨੀ ਹੈ

ਆਂਦਰੇਈ: ਤੁਸੀਂ ਪ੍ਰਦਰਸ਼ਨ 'ਤੇ ਕਿਵੇਂ ਕੰਮ ਕਰਦੇ ਹੋ? ਇਹ ਇੱਕ ਕਰਾਸ-ਕਟਿੰਗ ਸਮੱਸਿਆ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਕੀ ਤੁਹਾਨੂੰ ਕਦੇ ਅਜਿਹੀਆਂ ਸਮੱਸਿਆਵਾਂ 'ਤੇ ਕੰਮ ਕਰਨਾ ਪਿਆ ਹੈ ਜੋ ਬਹੁਤ ਸਾਰੀਆਂ ਮੌਜੂਦਾ ਕਾਰਜਸ਼ੀਲਤਾਵਾਂ ਦੇ ਲਾਂਘੇ ਤੋਂ ਪੈਦਾ ਹੁੰਦੀਆਂ ਹਨ?

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

ਲਾਗਤ ਮਾਡਲ

ਆਂਦਰੇਈ: ਇੱਕ ਪੋਡਕਾਸਟ ਵਿੱਚ ਤੁਸੀਂ ਉਤਪਾਦਕਤਾ ਦੇ ਸੰਦਰਭ ਵਿੱਚ ਲਾਗਤ ਮਾਡਲਾਂ ਬਾਰੇ ਗੱਲ ਕੀਤੀ ਸੀ। ਕੀ ਤੁਸੀਂ ਸਮਝਾ ਸਕਦੇ ਹੋ ਕਿ ਇਸ ਤੋਂ ਤੁਹਾਡਾ ਕੀ ਮਤਲਬ ਹੈ?

ਚੱਟਾਨ: ਯਕੀਨਨ। ਮੇਰਾ ਜਨਮ ਉਸ ਯੁੱਗ ਵਿੱਚ ਹੋਇਆ ਸੀ ਜਦੋਂ ਪ੍ਰੋਸੈਸਰ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਸੀ। ਅਤੇ ਇਹ ਯੁੱਗ ਦੁਬਾਰਾ ਵਾਪਸ ਆਉਂਦਾ ਹੈ - ਕਿਸਮਤ ਵਿਅੰਗ ਤੋਂ ਬਿਨਾਂ ਨਹੀਂ ਹੈ. ਮੈਂ ਅੱਠ-ਬਿੱਟ ਮਸ਼ੀਨਾਂ ਦੇ ਦਿਨਾਂ ਵਿੱਚ ਰਹਿਣਾ ਸ਼ੁਰੂ ਕੀਤਾ; ਮੇਰਾ ਪਹਿਲਾ ਕੰਪਿਊਟਰ 256 ਬਾਈਟਾਂ ਨਾਲ ਕੰਮ ਕਰਦਾ ਸੀ। ਬਿਲਕੁਲ ਬਾਈਟ. ਸਭ ਕੁਝ ਬਹੁਤ ਛੋਟਾ ਸੀ। ਹਿਦਾਇਤਾਂ ਨੂੰ ਗਿਣਿਆ ਜਾਣਾ ਸੀ, ਅਤੇ ਜਿਵੇਂ ਹੀ ਅਸੀਂ ਪ੍ਰੋਗਰਾਮਿੰਗ ਭਾਸ਼ਾ ਦੇ ਸਟੈਕ ਨੂੰ ਅੱਗੇ ਵਧਾਉਣਾ ਸ਼ੁਰੂ ਕੀਤਾ, ਭਾਸ਼ਾਵਾਂ ਹੋਰ ਅਤੇ ਹੋਰ ਵੱਧ ਗਈਆਂ। ਉੱਥੇ ਅਸੈਂਬਲਰ, ਫਿਰ ਬੇਸਿਕ, ਫਿਰ C, ਅਤੇ C ਨੇ ਬਹੁਤ ਸਾਰੇ ਵੇਰਵਿਆਂ ਦਾ ਧਿਆਨ ਰੱਖਿਆ, ਜਿਵੇਂ ਕਿ ਰਜਿਸਟਰ ਅਲੋਕੇਸ਼ਨ ਅਤੇ ਹਦਾਇਤਾਂ ਦੀ ਚੋਣ। ਪਰ ਉਥੇ ਸਭ ਕੁਝ ਬਿਲਕੁਲ ਸਪੱਸ਼ਟ ਸੀ, ਅਤੇ ਜੇ ਮੈਂ ਇੱਕ ਵੇਰੀਏਬਲ ਦੀ ਇੱਕ ਉਦਾਹਰਣ ਲਈ ਇੱਕ ਪੁਆਇੰਟਰ ਬਣਾਇਆ, ਤਾਂ ਮੈਨੂੰ ਲੋਡ ਮਿਲੇਗਾ, ਅਤੇ ਇਸ ਹਦਾਇਤ ਦੀ ਕੀਮਤ ਜਾਣੀ ਜਾਂਦੀ ਹੈ. ਹਾਰਡਵੇਅਰ ਮਸ਼ੀਨ ਚੱਕਰਾਂ ਦੀ ਇੱਕ ਨਿਸ਼ਚਿਤ ਗਿਣਤੀ ਪੈਦਾ ਕਰਦਾ ਹੈ, ਇਸਲਈ ਵੱਖ-ਵੱਖ ਚੀਜ਼ਾਂ ਦੀ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਸਪੀਡ ਨੂੰ ਸਿਰਫ਼ ਉਹਨਾਂ ਸਾਰੀਆਂ ਹਦਾਇਤਾਂ ਨੂੰ ਜੋੜ ਕੇ ਗਿਣਿਆ ਜਾ ਸਕਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਚਲਾਉਣ ਜਾ ਰਹੇ ਹੋ। ਹਰੇਕ ਤੁਲਨਾ/ਟੈਸਟ/ਸ਼ਾਖਾ/ਕਾਲ/ਲੋਡ/ਸਟੋਰ ਨੂੰ ਜੋੜਿਆ ਜਾ ਸਕਦਾ ਹੈ ਅਤੇ ਕਿਹਾ ਜਾ ਸਕਦਾ ਹੈ: ਇਹ ਤੁਹਾਡੇ ਲਈ ਲਾਗੂ ਕਰਨ ਦਾ ਸਮਾਂ ਹੈ। ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਣ 'ਤੇ ਕੰਮ ਕਰਦੇ ਸਮੇਂ, ਤੁਸੀਂ ਨਿਸ਼ਚਤ ਤੌਰ' ਤੇ ਧਿਆਨ ਦੇਵੋਗੇ ਕਿ ਕਿਹੜੇ ਨੰਬਰ ਛੋਟੇ ਗਰਮ ਚੱਕਰਾਂ ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਹਨ. 
ਪਰ ਜਿਵੇਂ ਹੀ ਤੁਸੀਂ Java, Python ਅਤੇ ਸਮਾਨ ਚੀਜ਼ਾਂ 'ਤੇ ਸਵਿਚ ਕਰਦੇ ਹੋ, ਤੁਸੀਂ ਬਹੁਤ ਜਲਦੀ ਹੇਠਲੇ ਪੱਧਰ ਦੇ ਹਾਰਡਵੇਅਰ ਤੋਂ ਦੂਰ ਚਲੇ ਜਾਂਦੇ ਹੋ। Java ਵਿੱਚ ਇੱਕ ਗੈਟਰ ਨੂੰ ਕਾਲ ਕਰਨ ਦੀ ਕੀਮਤ ਕੀ ਹੈ? ਜੇਕਰ ਹੌਟਸਪੌਟ ਵਿੱਚ ਜੇ.ਆਈ.ਟੀ ਇਨਲਾਈਨ, ਇਹ ਲੋਡ ਹੋ ਜਾਵੇਗਾ, ਪਰ ਜੇਕਰ ਇਸਨੇ ਅਜਿਹਾ ਨਹੀਂ ਕੀਤਾ, ਤਾਂ ਇਹ ਇੱਕ ਫੰਕਸ਼ਨ ਕਾਲ ਹੋਵੇਗੀ। ਕਿਉਂਕਿ ਕਾਲ ਇੱਕ ਗਰਮ ਲੂਪ 'ਤੇ ਹੈ, ਇਹ ਉਸ ਲੂਪ ਵਿੱਚ ਹੋਰ ਸਾਰੇ ਅਨੁਕੂਲਤਾਵਾਂ ਨੂੰ ਓਵਰਰਾਈਡ ਕਰ ਦੇਵੇਗਾ। ਇਸ ਲਈ, ਅਸਲ ਲਾਗਤ ਬਹੁਤ ਜ਼ਿਆਦਾ ਹੋਵੇਗੀ. ਅਤੇ ਤੁਸੀਂ ਤੁਰੰਤ ਕੋਡ ਦੇ ਇੱਕ ਟੁਕੜੇ ਨੂੰ ਵੇਖਣ ਦੀ ਯੋਗਤਾ ਗੁਆ ਦਿੰਦੇ ਹੋ ਅਤੇ ਇਹ ਸਮਝਦੇ ਹੋ ਕਿ ਸਾਨੂੰ ਇਸਨੂੰ ਪ੍ਰੋਸੈਸਰ ਕਲਾਕ ਸਪੀਡ, ਮੈਮੋਰੀ ਅਤੇ ਵਰਤੀ ਗਈ ਕੈਸ਼ ਦੇ ਰੂਪ ਵਿੱਚ ਲਾਗੂ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਇਹ ਸਭ ਤਾਂ ਹੀ ਦਿਲਚਸਪ ਬਣ ਜਾਂਦਾ ਹੈ ਜੇਕਰ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਪ੍ਰਦਰਸ਼ਨ ਵਿੱਚ ਆਉਂਦੇ ਹੋ.
ਹੁਣ ਅਸੀਂ ਆਪਣੇ ਆਪ ਨੂੰ ਅਜਿਹੀ ਸਥਿਤੀ ਵਿੱਚ ਪਾਉਂਦੇ ਹਾਂ ਜਿੱਥੇ ਪ੍ਰੋਸੈਸਰ ਦੀ ਗਤੀ ਇੱਕ ਦਹਾਕੇ ਤੋਂ ਮੁਸ਼ਕਿਲ ਨਾਲ ਵਧੀ ਹੈ। ਪੁਰਾਣੇ ਦਿਨ ਵਾਪਸ ਆ ਗਏ ਹਨ! ਤੁਸੀਂ ਹੁਣ ਚੰਗੇ ਸਿੰਗਲ-ਥ੍ਰੈਡਡ ਪ੍ਰਦਰਸ਼ਨ 'ਤੇ ਭਰੋਸਾ ਨਹੀਂ ਕਰ ਸਕਦੇ। ਪਰ ਜੇ ਤੁਸੀਂ ਅਚਾਨਕ ਸਮਾਨਾਂਤਰ ਕੰਪਿਊਟਿੰਗ ਵਿੱਚ ਆ ਜਾਂਦੇ ਹੋ, ਤਾਂ ਇਹ ਬਹੁਤ ਮੁਸ਼ਕਲ ਹੈ, ਹਰ ਕੋਈ ਤੁਹਾਨੂੰ ਜੇਮਸ ਬਾਂਡ ਵਾਂਗ ਦੇਖਦਾ ਹੈ। ਇੱਥੇ ਦਸ ਗੁਣਾ ਪ੍ਰਵੇਗ ਆਮ ਤੌਰ 'ਤੇ ਉਨ੍ਹਾਂ ਥਾਵਾਂ 'ਤੇ ਹੁੰਦੇ ਹਨ ਜਿੱਥੇ ਕਿਸੇ ਨੇ ਕੁਝ ਗੜਬੜ ਕੀਤੀ ਹੈ। ਇਕਸਾਰਤਾ ਲਈ ਬਹੁਤ ਕੰਮ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ. ਉਸ XNUMXx ਸਪੀਡਅੱਪ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਲਾਗਤ ਮਾਡਲ ਨੂੰ ਸਮਝਣ ਦੀ ਲੋੜ ਹੈ। ਇਸਦੀ ਕੀਮਤ ਕੀ ਅਤੇ ਕਿੰਨੀ ਹੈ? ਅਤੇ ਅਜਿਹਾ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਇਹ ਸਮਝਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਕਿ ਜੀਭ ਅੰਡਰਲਾਈੰਗ ਹਾਰਡਵੇਅਰ 'ਤੇ ਕਿਵੇਂ ਫਿੱਟ ਹੈ.
ਮਾਰਟਿਨ ਥਾਮਸਨ ਨੇ ਆਪਣੇ ਬਲੌਗ ਲਈ ਇੱਕ ਵਧੀਆ ਸ਼ਬਦ ਚੁਣਿਆ ਹੈ ਮਕੈਨੀਕਲ ਹਮਦਰਦੀ! ਤੁਹਾਨੂੰ ਇਹ ਸਮਝਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਕਿ ਹਾਰਡਵੇਅਰ ਕੀ ਕਰਨ ਜਾ ਰਿਹਾ ਹੈ, ਇਹ ਅਸਲ ਵਿੱਚ ਇਹ ਕਿਵੇਂ ਕਰੇਗਾ, ਅਤੇ ਇਹ ਉਹੀ ਕਿਉਂ ਕਰਦਾ ਹੈ ਜੋ ਇਹ ਪਹਿਲਾਂ ਕਰਦਾ ਹੈ। ਇਸਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਨਿਰਦੇਸ਼ਾਂ ਨੂੰ ਗਿਣਨਾ ਸ਼ੁਰੂ ਕਰਨਾ ਅਤੇ ਇਹ ਪਤਾ ਲਗਾਉਣਾ ਕਾਫ਼ੀ ਆਸਾਨ ਹੈ ਕਿ ਅਮਲ ਦਾ ਸਮਾਂ ਕਿੱਥੇ ਜਾ ਰਿਹਾ ਹੈ। ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਢੁਕਵੀਂ ਸਿਖਲਾਈ ਨਹੀਂ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਸਿਰਫ਼ ਇੱਕ ਹਨੇਰੇ ਕਮਰੇ ਵਿੱਚ ਇੱਕ ਕਾਲੀ ਬਿੱਲੀ ਦੀ ਭਾਲ ਕਰ ਰਹੇ ਹੋ। ਮੈਂ ਲੋਕਾਂ ਨੂੰ ਹਰ ਸਮੇਂ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਂਦੇ ਹੋਏ ਦੇਖਦਾ ਹਾਂ ਜਿਨ੍ਹਾਂ ਨੂੰ ਇਹ ਨਹੀਂ ਪਤਾ ਹੁੰਦਾ ਕਿ ਉਹ ਕੀ ਕਰ ਰਹੇ ਹਨ. ਉਹ ਬਹੁਤ ਦੁਖੀ ਹਨ ਅਤੇ ਬਹੁਤ ਤਰੱਕੀ ਨਹੀਂ ਕਰ ਰਹੇ ਹਨ. ਅਤੇ ਜਦੋਂ ਮੈਂ ਕੋਡ ਦਾ ਉਹੀ ਟੁਕੜਾ ਲੈਂਦਾ ਹਾਂ, ਕੁਝ ਛੋਟੇ ਹੈਕਾਂ ਵਿੱਚ ਖਿਸਕ ਜਾਂਦਾ ਹਾਂ ਅਤੇ ਪੰਜ- ਜਾਂ ਦਸ ਗੁਣਾ ਸਪੀਡਅੱਪ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹਾਂ, ਉਹ ਇਸ ਤਰ੍ਹਾਂ ਹਨ: ਠੀਕ ਹੈ, ਇਹ ਸਹੀ ਨਹੀਂ ਹੈ, ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ ਜਾਣਦੇ ਸੀ ਕਿ ਤੁਸੀਂ ਬਿਹਤਰ ਹੋ। ਹੈਰਾਨੀਜਨਕ। ਮੈਂ ਕਿਸ ਬਾਰੇ ਗੱਲ ਕਰ ਰਿਹਾ ਹਾਂ... ਲਾਗਤ ਮਾਡਲ ਇਸ ਬਾਰੇ ਹੈ ਕਿ ਤੁਸੀਂ ਕਿਸ ਕਿਸਮ ਦਾ ਕੋਡ ਲਿਖਦੇ ਹੋ ਅਤੇ ਇਹ ਵੱਡੀ ਤਸਵੀਰ ਵਿੱਚ ਔਸਤਨ ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਚੱਲਦਾ ਹੈ।

ਆਂਦਰੇਈ: ਅਤੇ ਤੁਸੀਂ ਆਪਣੇ ਸਿਰ ਵਿੱਚ ਅਜਿਹੀ ਮਾਤਰਾ ਕਿਵੇਂ ਰੱਖ ਸਕਦੇ ਹੋ? ਕੀ ਇਹ ਵਧੇਰੇ ਅਨੁਭਵ ਨਾਲ ਪ੍ਰਾਪਤ ਕੀਤਾ ਗਿਆ ਹੈ, ਜਾਂ? ਅਜਿਹਾ ਅਨੁਭਵ ਕਿੱਥੋਂ ਆਉਂਦਾ ਹੈ?

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

ਘੱਟ-ਪੱਧਰੀ ਓਪਟੀਮਾਈਜੇਸ਼ਨ ਸਿਖਲਾਈ

ਆਂਦਰੇਈ: ਕੀ ਅੰਦਰ ਜਾਣ ਦਾ ਕੋਈ ਆਸਾਨ ਤਰੀਕਾ ਹੈ?

ਚੱਟਾਨ: ਹਾਂ ਅਤੇ ਨਹੀਂ। ਜੋ ਹਾਰਡਵੇਅਰ ਅਸੀਂ ਸਾਰੇ ਵਰਤਦੇ ਹਾਂ ਉਹ ਸਮੇਂ ਦੇ ਨਾਲ ਇੰਨਾ ਜ਼ਿਆਦਾ ਨਹੀਂ ਬਦਲਿਆ ਹੈ। ਆਰਮ ਸਮਾਰਟਫ਼ੋਨਾਂ ਨੂੰ ਛੱਡ ਕੇ, ਹਰ ਕੋਈ x86 ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਕਿਸੇ ਕਿਸਮ ਦੀ ਹਾਰਡਕੋਰ ਏਮਬੈਡਿੰਗ ਨਹੀਂ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਉਹੀ ਕੰਮ ਕਰ ਰਹੇ ਹੋ। ਠੀਕ ਹੈ, ਅਗਲਾ। ਹਦਾਇਤਾਂ ਵੀ ਸਦੀਆਂ ਤੋਂ ਨਹੀਂ ਬਦਲੀਆਂ। ਤੁਹਾਨੂੰ ਵਿਧਾਨ ਸਭਾ ਵਿੱਚ ਜਾ ਕੇ ਕੁਝ ਲਿਖਣ ਦੀ ਲੋੜ ਹੈ। ਬਹੁਤ ਜ਼ਿਆਦਾ ਨਹੀਂ, ਪਰ ਸਮਝਣ ਲਈ ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਕਾਫ਼ੀ ਹੈ. ਤੁਸੀਂ ਮੁਸਕਰਾ ਰਹੇ ਹੋ, ਪਰ ਮੈਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਗੰਭੀਰਤਾ ਨਾਲ ਬੋਲ ਰਿਹਾ ਹਾਂ। ਤੁਹਾਨੂੰ ਭਾਸ਼ਾ ਅਤੇ ਹਾਰਡਵੇਅਰ ਵਿਚਕਾਰ ਪੱਤਰ ਵਿਹਾਰ ਨੂੰ ਸਮਝਣ ਦੀ ਲੋੜ ਹੈ। ਉਸ ਤੋਂ ਬਾਅਦ ਤੁਹਾਨੂੰ ਥੋੜਾ ਜਿਹਾ ਲਿਖਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਇੱਕ ਛੋਟੀ ਖਿਡੌਣੇ ਦੀ ਭਾਸ਼ਾ ਲਈ ਇੱਕ ਛੋਟਾ ਜਿਹਾ ਖਿਡੌਣਾ ਕੰਪਾਈਲਰ ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ. ਖਿਡੌਣੇ-ਵਰਗੇ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇਸਨੂੰ ਵਾਜਬ ਸਮੇਂ ਵਿੱਚ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ। ਇਹ ਬਹੁਤ ਸਰਲ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਇਸ ਨੂੰ ਹਦਾਇਤਾਂ ਤਿਆਰ ਕਰਨੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ। ਇੱਕ ਹਿਦਾਇਤ ਬਣਾਉਣ ਦੀ ਕਿਰਿਆ ਤੁਹਾਨੂੰ ਉੱਚ-ਪੱਧਰੀ ਕੋਡ ਜੋ ਹਰ ਕੋਈ ਲਿਖਦਾ ਹੈ ਅਤੇ ਹਾਰਡਵੇਅਰ 'ਤੇ ਚੱਲਣ ਵਾਲੇ ਮਸ਼ੀਨ ਕੋਡ ਦੇ ਵਿਚਕਾਰ ਪੁਲ ਲਈ ਲਾਗਤ ਮਾਡਲ ਨੂੰ ਸਮਝਣ ਵਿੱਚ ਤੁਹਾਡੀ ਮਦਦ ਕਰੇਗਾ। ਕੰਪਾਈਲਰ ਲਿਖੇ ਜਾਣ ਸਮੇਂ ਇਹ ਪੱਤਰ ਵਿਹਾਰ ਦਿਮਾਗ ਵਿੱਚ ਸਾੜ ਦਿੱਤਾ ਜਾਵੇਗਾ। ਇੱਥੋਂ ਤੱਕ ਕਿ ਸਭ ਤੋਂ ਸਧਾਰਨ ਕੰਪਾਈਲਰ. ਉਸ ਤੋਂ ਬਾਅਦ, ਤੁਸੀਂ ਜਾਵਾ ਅਤੇ ਇਸ ਤੱਥ ਨੂੰ ਦੇਖਣਾ ਸ਼ੁਰੂ ਕਰ ਸਕਦੇ ਹੋ ਕਿ ਇਸਦਾ ਅਰਥਵਾਦੀ ਖੱਡ ਬਹੁਤ ਡੂੰਘਾ ਹੈ, ਅਤੇ ਇਸ ਉੱਤੇ ਪੁਲ ਬਣਾਉਣਾ ਬਹੁਤ ਮੁਸ਼ਕਲ ਹੈ. ਜਾਵਾ ਵਿੱਚ, ਇਹ ਸਮਝਣਾ ਬਹੁਤ ਮੁਸ਼ਕਲ ਹੈ ਕਿ ਸਾਡਾ ਪੁਲ ਚੰਗਾ ਜਾਂ ਮਾੜਾ ਨਿਕਲਿਆ, ਇਸ ਦੇ ਟੁੱਟਣ ਦਾ ਕਾਰਨ ਕੀ ਹੋਵੇਗਾ ਅਤੇ ਕੀ ਨਹੀਂ ਹੋਵੇਗਾ। ਪਰ ਤੁਹਾਨੂੰ ਕਿਸੇ ਕਿਸਮ ਦੇ ਸ਼ੁਰੂਆਤੀ ਬਿੰਦੂ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਕੋਡ ਨੂੰ ਦੇਖਦੇ ਹੋ ਅਤੇ ਸਮਝਦੇ ਹੋ: "ਹਾਂ, ਇਹ ਪ੍ਰਾਪਤਕਰਤਾ ਹਰ ਵਾਰ ਇਨਲਾਈਨ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।" ਅਤੇ ਫਿਰ ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਕਈ ਵਾਰ ਅਜਿਹਾ ਹੁੰਦਾ ਹੈ, ਸਥਿਤੀ ਨੂੰ ਛੱਡ ਕੇ ਜਦੋਂ ਵਿਧੀ ਬਹੁਤ ਵੱਡੀ ਹੋ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਜੇਆਈਟੀ ਹਰ ਚੀਜ਼ ਨੂੰ ਇਨਲਾਈਨ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦੀ ਹੈ. ਅਜਿਹੇ ਸਥਾਨਾਂ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਦਾ ਤੁਰੰਤ ਅੰਦਾਜ਼ਾ ਲਗਾਇਆ ਜਾ ਸਕਦਾ ਹੈ. ਆਮ ਤੌਰ 'ਤੇ ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੇ ਵਧੀਆ ਕੰਮ ਕਰਦੇ ਹਨ, ਪਰ ਫਿਰ ਤੁਸੀਂ ਵੱਡੇ ਹੌਟ ਲੂਪਸ ਨੂੰ ਦੇਖਦੇ ਹੋ ਅਤੇ ਮਹਿਸੂਸ ਕਰਦੇ ਹੋ ਕਿ ਇੱਥੇ ਕੁਝ ਫੰਕਸ਼ਨ ਕਾਲਾਂ ਹਨ ਜੋ ਇਹ ਨਹੀਂ ਜਾਣਦੇ ਕਿ ਉਹ ਕੀ ਕਰ ਰਹੇ ਹਨ। ਇਹ ਗੈਟਰਾਂ ਦੀ ਵਿਆਪਕ ਵਰਤੋਂ ਨਾਲ ਸਮੱਸਿਆ ਹੈ, ਉਹਨਾਂ ਦੇ ਇਨਲਾਈਨ ਨਾ ਹੋਣ ਦਾ ਕਾਰਨ ਇਹ ਹੈ ਕਿ ਇਹ ਸਪੱਸ਼ਟ ਨਹੀਂ ਹੈ ਕਿ ਕੀ ਉਹ ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੇ ਹਨ। ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਸੁਪਰ ਸਮਾਲ ਕੋਡ ਬੇਸ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਇਸਨੂੰ ਯਾਦ ਰੱਖ ਸਕਦੇ ਹੋ ਅਤੇ ਫਿਰ ਕਹਿ ਸਕਦੇ ਹੋ: ਇਹ ਇੱਕ ਗੈਟਰ ਹੈ, ਅਤੇ ਇਹ ਇੱਕ ਸੇਟਰ ਹੈ। ਇੱਕ ਵੱਡੇ ਕੋਡ ਬੇਸ ਵਿੱਚ, ਹਰੇਕ ਫੰਕਸ਼ਨ ਦਾ ਆਪਣਾ ਇਤਿਹਾਸ ਰਹਿੰਦਾ ਹੈ, ਜੋ ਆਮ ਤੌਰ 'ਤੇ, ਕਿਸੇ ਨੂੰ ਪਤਾ ਨਹੀਂ ਹੁੰਦਾ। ਪ੍ਰੋਫਾਈਲਰ ਕਹਿੰਦਾ ਹੈ ਕਿ ਅਸੀਂ ਕੁਝ ਲੂਪ 'ਤੇ 24% ਸਮਾਂ ਗੁਆ ਦਿੱਤਾ ਹੈ ਅਤੇ ਇਹ ਸਮਝਣ ਲਈ ਕਿ ਇਹ ਲੂਪ ਕੀ ਕਰ ਰਿਹਾ ਹੈ, ਸਾਨੂੰ ਹਰੇਕ ਫੰਕਸ਼ਨ ਨੂੰ ਅੰਦਰ ਦੇਖਣ ਦੀ ਲੋੜ ਹੈ। ਫੰਕਸ਼ਨ ਦਾ ਅਧਿਐਨ ਕੀਤੇ ਬਿਨਾਂ ਇਸਨੂੰ ਸਮਝਣਾ ਅਸੰਭਵ ਹੈ, ਅਤੇ ਇਹ ਸਮਝਣ ਦੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਗੰਭੀਰਤਾ ਨਾਲ ਹੌਲੀ ਕਰ ਦਿੰਦਾ ਹੈ। ਇਸ ਲਈ ਮੈਂ ਗੈਟਰਾਂ ਅਤੇ ਸੇਟਰਾਂ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰਦਾ, ਮੈਂ ਇੱਕ ਨਵੇਂ ਪੱਧਰ 'ਤੇ ਪਹੁੰਚ ਗਿਆ ਹਾਂ!
ਲਾਗਤ ਮਾਡਲ ਕਿੱਥੇ ਪ੍ਰਾਪਤ ਕਰਨਾ ਹੈ? ਠੀਕ ਹੈ, ਤੁਸੀਂ ਕੁਝ ਪੜ੍ਹ ਸਕਦੇ ਹੋ, ਬੇਸ਼ੱਕ... ਪਰ ਮੈਨੂੰ ਲੱਗਦਾ ਹੈ ਕਿ ਸਭ ਤੋਂ ਵਧੀਆ ਤਰੀਕਾ ਕੰਮ ਕਰਨਾ ਹੈ। ਇੱਕ ਛੋਟਾ ਕੰਪਾਈਲਰ ਬਣਾਉਣਾ ਲਾਗਤ ਮਾਡਲ ਨੂੰ ਸਮਝਣ ਅਤੇ ਇਸਨੂੰ ਤੁਹਾਡੇ ਆਪਣੇ ਸਿਰ ਵਿੱਚ ਫਿੱਟ ਕਰਨ ਦਾ ਸਭ ਤੋਂ ਵਧੀਆ ਤਰੀਕਾ ਹੋਵੇਗਾ। ਇੱਕ ਛੋਟਾ ਕੰਪਾਈਲਰ ਜੋ ਇੱਕ ਮਾਈਕ੍ਰੋਵੇਵ ਪ੍ਰੋਗਰਾਮਿੰਗ ਲਈ ਢੁਕਵਾਂ ਹੋਵੇਗਾ ਇੱਕ ਸ਼ੁਰੂਆਤ ਕਰਨ ਵਾਲੇ ਲਈ ਇੱਕ ਕੰਮ ਹੈ। ਖੈਰ, ਮੇਰਾ ਮਤਲਬ ਹੈ, ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਪ੍ਰੋਗਰਾਮਿੰਗ ਹੁਨਰ ਹਨ, ਤਾਂ ਇਹ ਕਾਫ਼ੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ. ਇਹ ਸਾਰੀਆਂ ਚੀਜ਼ਾਂ ਜਿਵੇਂ ਕਿ ਇੱਕ ਸਤਰ ਨੂੰ ਪਾਰਸ ਕਰਨਾ ਜੋ ਤੁਹਾਡੇ ਕੋਲ ਕਿਸੇ ਕਿਸਮ ਦੇ ਬੀਜਗਣਿਤ ਸਮੀਕਰਨ ਦੇ ਰੂਪ ਵਿੱਚ ਹੈ, ਸਹੀ ਕ੍ਰਮ ਵਿੱਚ ਗਣਿਤਿਕ ਕਾਰਵਾਈਆਂ ਲਈ ਨਿਰਦੇਸ਼ਾਂ ਨੂੰ ਉਥੋਂ ਕੱਢਣਾ, ਰਜਿਸਟਰਾਂ ਤੋਂ ਸਹੀ ਮੁੱਲ ਲੈਣਾ - ਇਹ ਸਭ ਇੱਕ ਵਾਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਅਤੇ ਜਦੋਂ ਤੁਸੀਂ ਇਹ ਕਰਦੇ ਹੋ, ਇਹ ਤੁਹਾਡੇ ਦਿਮਾਗ ਵਿੱਚ ਛਾਪਿਆ ਜਾਵੇਗਾ. ਮੈਨੂੰ ਲਗਦਾ ਹੈ ਕਿ ਹਰ ਕੋਈ ਜਾਣਦਾ ਹੈ ਕਿ ਕੰਪਾਈਲਰ ਕੀ ਕਰਦਾ ਹੈ. ਅਤੇ ਇਹ ਲਾਗਤ ਮਾਡਲ ਦੀ ਸਮਝ ਦੇਵੇਗਾ.

ਪ੍ਰਦਰਸ਼ਨ ਸੁਧਾਰ ਦੀਆਂ ਵਿਹਾਰਕ ਉਦਾਹਰਣਾਂ

ਆਂਦਰੇਈ: ਉਤਪਾਦਕਤਾ 'ਤੇ ਕੰਮ ਕਰਦੇ ਸਮੇਂ ਤੁਹਾਨੂੰ ਹੋਰ ਕਿਸ ਵੱਲ ਧਿਆਨ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ?

ਚੱਟਾਨ: ਡਾਟਾ ਬਣਤਰ। ਵੈਸੇ, ਹਾਂ, ਮੈਂ ਇਹਨਾਂ ਕਲਾਸਾਂ ਨੂੰ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਨਹੀਂ ਪੜ੍ਹਾਇਆ ਹੈ... ਰਾਕੇਟ ਸਕੂਲ. ਇਹ ਮਜ਼ੇਦਾਰ ਸੀ, ਪਰ ਇਸ ਲਈ ਬਹੁਤ ਮਿਹਨਤ ਦੀ ਲੋੜ ਸੀ, ਅਤੇ ਮੇਰੀ ਵੀ ਇੱਕ ਜ਼ਿੰਦਗੀ ਹੈ! ਠੀਕ ਹੈ. ਇਸ ਲਈ, ਇੱਕ ਵੱਡੀ ਅਤੇ ਦਿਲਚਸਪ ਕਲਾਸ ਵਿੱਚ, "ਤੁਹਾਡਾ ਪ੍ਰਦਰਸ਼ਨ ਕਿੱਥੇ ਜਾਂਦਾ ਹੈ," ਮੈਂ ਵਿਦਿਆਰਥੀਆਂ ਨੂੰ ਇੱਕ ਉਦਾਹਰਨ ਦਿੱਤੀ: ਇੱਕ CSV ਫਾਈਲ ਤੋਂ ਢਾਈ ਗੀਗਾਬਾਈਟ ਫਿਨਟੇਕ ਡੇਟਾ ਪੜ੍ਹਿਆ ਗਿਆ ਅਤੇ ਫਿਰ ਉਹਨਾਂ ਨੂੰ ਵੇਚੇ ਗਏ ਉਤਪਾਦਾਂ ਦੀ ਗਿਣਤੀ ਦੀ ਗਣਨਾ ਕਰਨੀ ਪਈ। . ਨਿਯਮਤ ਟਿਕ ਮਾਰਕੀਟ ਡੇਟਾ। UDP ਪੈਕੇਟ 70 ਦੇ ਦਹਾਕੇ ਤੋਂ ਟੈਕਸਟ ਫਾਰਮੈਟ ਵਿੱਚ ਬਦਲ ਗਏ ਹਨ। ਸ਼ਿਕਾਗੋ ਮਰਕੈਂਟਾਈਲ ਐਕਸਚੇਂਜ - ਹਰ ਤਰ੍ਹਾਂ ਦੀਆਂ ਚੀਜ਼ਾਂ ਜਿਵੇਂ ਮੱਖਣ, ਮੱਕੀ, ਸੋਇਆਬੀਨ, ਇਸ ਤਰ੍ਹਾਂ ਦੀਆਂ ਚੀਜ਼ਾਂ। ਇਹਨਾਂ ਉਤਪਾਦਾਂ, ਲੈਣ-ਦੇਣ ਦੀ ਗਿਣਤੀ, ਫੰਡਾਂ ਅਤੇ ਮਾਲ ਦੀ ਆਵਾਜਾਈ ਦੀ ਔਸਤ ਮਾਤਰਾ, ਆਦਿ ਦੀ ਗਿਣਤੀ ਕਰਨਾ ਜ਼ਰੂਰੀ ਸੀ. ਇਹ ਬਹੁਤ ਸਧਾਰਨ ਵਪਾਰਕ ਗਣਿਤ ਹੈ: ਉਤਪਾਦ ਕੋਡ ਲੱਭੋ (ਜੋ ਹੈਸ਼ ਟੇਬਲ ਵਿੱਚ 1-2 ਅੱਖਰ ਹਨ), ਰਕਮ ਪ੍ਰਾਪਤ ਕਰੋ, ਇਸਨੂੰ ਵਪਾਰਕ ਸੈੱਟਾਂ ਵਿੱਚੋਂ ਇੱਕ ਵਿੱਚ ਜੋੜੋ, ਵਾਲੀਅਮ ਜੋੜੋ, ਮੁੱਲ ਜੋੜੋ, ਅਤੇ ਕੁਝ ਹੋਰ ਚੀਜ਼ਾਂ। ਬਹੁਤ ਸਧਾਰਨ ਗਣਿਤ. ਖਿਡੌਣਾ ਲਾਗੂ ਕਰਨਾ ਬਹੁਤ ਸਿੱਧਾ ਸੀ: ਸਭ ਕੁਝ ਇੱਕ ਫਾਈਲ ਵਿੱਚ ਹੈ, ਮੈਂ ਫਾਈਲ ਨੂੰ ਪੜ੍ਹਦਾ ਹਾਂ ਅਤੇ ਇਸ ਵਿੱਚੋਂ ਲੰਘਦਾ ਹਾਂ, ਵਿਅਕਤੀਗਤ ਰਿਕਾਰਡਾਂ ਨੂੰ ਜਾਵਾ ਸਤਰ ਵਿੱਚ ਵੰਡਦਾ ਹਾਂ, ਉਹਨਾਂ ਵਿੱਚ ਲੋੜੀਂਦੀਆਂ ਚੀਜ਼ਾਂ ਦੀ ਭਾਲ ਕਰਦਾ ਹਾਂ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਉੱਪਰ ਦੱਸੇ ਗਏ ਗਣਿਤ ਦੇ ਅਨੁਸਾਰ ਜੋੜਦਾ ਹਾਂ. ਅਤੇ ਇਹ ਕੁਝ ਘੱਟ ਗਤੀ 'ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ.

ਇਸ ਪਹੁੰਚ ਨਾਲ, ਇਹ ਸਪੱਸ਼ਟ ਹੈ ਕਿ ਕੀ ਹੋ ਰਿਹਾ ਹੈ, ਅਤੇ ਸਮਾਨਾਂਤਰ ਕੰਪਿਊਟਿੰਗ ਮਦਦ ਨਹੀਂ ਕਰੇਗੀ, ਠੀਕ ਹੈ? ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਕਾਰਗੁਜ਼ਾਰੀ ਵਿੱਚ ਪੰਜ ਗੁਣਾ ਵਾਧਾ ਸਿਰਫ਼ ਸਹੀ ਡੇਟਾ ਢਾਂਚੇ ਦੀ ਚੋਣ ਕਰਕੇ ਪ੍ਰਾਪਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਅਤੇ ਇਹ ਤਜਰਬੇਕਾਰ ਪ੍ਰੋਗਰਾਮਰਾਂ ਨੂੰ ਵੀ ਹੈਰਾਨ ਕਰਦਾ ਹੈ! ਮੇਰੇ ਖਾਸ ਕੇਸ ਵਿੱਚ, ਚਾਲ ਇਹ ਸੀ ਕਿ ਤੁਹਾਨੂੰ ਇੱਕ ਗਰਮ ਲੂਪ ਵਿੱਚ ਮੈਮੋਰੀ ਵੰਡ ਨਹੀਂ ਕਰਨੀ ਚਾਹੀਦੀ. ਖੈਰ, ਇਹ ਪੂਰੀ ਸੱਚਾਈ ਨਹੀਂ ਹੈ, ਪਰ ਆਮ ਤੌਰ 'ਤੇ - ਤੁਹਾਨੂੰ "ਐਕਸ ਵਿੱਚ ਇੱਕ ਵਾਰ" ਨੂੰ ਉਜਾਗਰ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ ਜਦੋਂ X ਕਾਫ਼ੀ ਵੱਡਾ ਹੁੰਦਾ ਹੈ। ਜਦੋਂ X ਢਾਈ ਗੀਗਾਬਾਈਟ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ “ਇੱਕ ਵਾਰ ਪ੍ਰਤੀ ਅੱਖਰ”, ਜਾਂ “ਇੱਕ ਵਾਰ ਪ੍ਰਤੀ ਲਾਈਨ”, ਜਾਂ “ਇੱਕ ਵਾਰ ਪ੍ਰਤੀ ਖੇਤਰ”, ਅਜਿਹਾ ਕੁਝ ਵੀ ਨਿਰਧਾਰਤ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਸਮਾਂ ਬਿਤਾਇਆ ਜਾਂਦਾ ਹੈ. ਇਹ ਵੀ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ? ਕਲਪਨਾ ਕਰੋ ਕਿ ਮੈਂ ਇੱਕ ਕਾਲ ਕਰ ਰਿਹਾ ਹਾਂ String.split() ਜ BufferedReader.readLine(). Readline ਬਾਈਟਾਂ ਦੇ ਇੱਕ ਸੈੱਟ ਤੋਂ ਇੱਕ ਸਤਰ ਬਣਾਉਂਦਾ ਹੈ ਜੋ ਨੈੱਟਵਰਕ ਉੱਤੇ ਆਉਂਦੇ ਹਨ, ਹਰੇਕ ਲਾਈਨ ਲਈ ਇੱਕ ਵਾਰ, ਲੱਖਾਂ ਲਾਈਨਾਂ ਵਿੱਚੋਂ ਹਰੇਕ ਲਈ। ਮੈਂ ਇਹ ਲਾਈਨ ਲੈਂਦਾ ਹਾਂ, ਇਸਨੂੰ ਪਾਰਸ ਕਰਦਾ ਹਾਂ ਅਤੇ ਇਸਨੂੰ ਸੁੱਟ ਦਿੰਦਾ ਹਾਂ. ਮੈਂ ਇਸਨੂੰ ਕਿਉਂ ਸੁੱਟ ਰਿਹਾ/ਰਹੀ ਹਾਂ - ਠੀਕ ਹੈ, ਮੈਂ ਪਹਿਲਾਂ ਹੀ ਇਸ 'ਤੇ ਕਾਰਵਾਈ ਕਰ ਚੁੱਕਾ ਹਾਂ, ਬੱਸ ਇਹੀ ਹੈ। ਇਸ ਲਈ, ਇਹਨਾਂ 2.7G ਤੋਂ ਪੜ੍ਹੇ ਗਏ ਹਰੇਕ ਬਾਈਟ ਲਈ, ਲਾਈਨ ਵਿੱਚ ਦੋ ਅੱਖਰ ਲਿਖੇ ਜਾਣਗੇ, ਯਾਨੀ ਪਹਿਲਾਂ ਹੀ 5.4G, ਅਤੇ ਮੈਨੂੰ ਉਹਨਾਂ ਦੀ ਹੋਰ ਕਿਸੇ ਚੀਜ਼ ਲਈ ਲੋੜ ਨਹੀਂ ਹੈ, ਇਸਲਈ ਉਹਨਾਂ ਨੂੰ ਸੁੱਟ ਦਿੱਤਾ ਗਿਆ ਹੈ। ਜੇ ਤੁਸੀਂ ਮੈਮੋਰੀ ਬੈਂਡਵਿਡਥ ਨੂੰ ਵੇਖਦੇ ਹੋ, ਅਸੀਂ 2.7G ਲੋਡ ਕਰਦੇ ਹਾਂ ਜੋ ਪ੍ਰੋਸੈਸਰ ਵਿੱਚ ਮੈਮੋਰੀ ਅਤੇ ਮੈਮੋਰੀ ਬੱਸ ਵਿੱਚੋਂ ਲੰਘਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਮੈਮੋਰੀ ਵਿੱਚ ਪਈ ਲਾਈਨ ਨੂੰ ਦੁੱਗਣਾ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਇਹ ਸਭ ਕੁਝ ਭੜਕ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਹਰ ਨਵੀਂ ਲਾਈਨ ਬਣ ਜਾਂਦੀ ਹੈ। ਪਰ ਮੈਨੂੰ ਇਸਨੂੰ ਪੜ੍ਹਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ, ਹਾਰਡਵੇਅਰ ਇਸਨੂੰ ਪੜ੍ਹਦਾ ਹੈ, ਭਾਵੇਂ ਸਭ ਕੁਝ ਬਾਅਦ ਵਿੱਚ ਭੜਕਿਆ ਹੋਵੇ. ਅਤੇ ਮੈਨੂੰ ਇਸਨੂੰ ਲਿਖਣਾ ਪਏਗਾ ਕਿਉਂਕਿ ਮੈਂ ਇੱਕ ਲਾਈਨ ਬਣਾਈ ਹੈ ਅਤੇ ਕੈਚ ਭਰ ਗਏ ਹਨ - ਕੈਸ਼ 2.7G ਨੂੰ ਅਨੁਕੂਲ ਨਹੀਂ ਕਰ ਸਕਦਾ ਹੈ। ਇਸ ਲਈ, ਹਰ ਬਾਈਟ ਲਈ ਜੋ ਮੈਂ ਪੜ੍ਹਦਾ ਹਾਂ, ਮੈਂ ਦੋ ਹੋਰ ਬਾਈਟ ਪੜ੍ਹਦਾ ਹਾਂ ਅਤੇ ਦੋ ਹੋਰ ਬਾਈਟ ਲਿਖਦਾ ਹਾਂ, ਅਤੇ ਅੰਤ ਵਿੱਚ ਉਹਨਾਂ ਦਾ 4:1 ਅਨੁਪਾਤ ਹੁੰਦਾ ਹੈ - ਇਸ ਅਨੁਪਾਤ ਵਿੱਚ ਅਸੀਂ ਮੈਮੋਰੀ ਬੈਂਡਵਿਡਥ ਨੂੰ ਬਰਬਾਦ ਕਰ ਰਹੇ ਹਾਂ। ਅਤੇ ਫਿਰ ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਜੇ ਮੈਂ ਕਰਦਾ ਹਾਂ String.split() - ਇਹ ਆਖਰੀ ਵਾਰ ਨਹੀਂ ਹੈ ਜਦੋਂ ਮੈਂ ਅਜਿਹਾ ਕਰ ਰਿਹਾ ਹਾਂ, ਅੰਦਰ 6-7 ਹੋਰ ਖੇਤਰ ਹੋ ਸਕਦੇ ਹਨ। ਇਸ ਲਈ CSV ਨੂੰ ਪੜ੍ਹਨ ਦਾ ਕਲਾਸਿਕ ਕੋਡ ਅਤੇ ਫਿਰ ਸਟਰਿੰਗਾਂ ਨੂੰ ਪਾਰਸ ਕਰਨ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਲਗਭਗ 14:1 ਦੀ ਮੈਮੋਰੀ ਬੈਂਡਵਿਡਥ ਦੀ ਬਰਬਾਦੀ ਹੁੰਦੀ ਹੈ ਜੋ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਪ੍ਰਾਪਤ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ। ਜੇਕਰ ਤੁਸੀਂ ਇਹਨਾਂ ਚੋਣਾਂ ਨੂੰ ਸੁੱਟ ਦਿੰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਪੰਜ ਗੁਣਾ ਸਪੀਡਅੱਪ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ।

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

ਸਮੱਸਿਆ ਡੇਟਾ ਸਟਰਕਚਰ ਵਿੱਚ ਹੈ: ਜੋ ਕੁਝ ਵੀ ਵਾਪਰਦਾ ਹੈ, ਉਹ ਬਹੁਤ ਵੱਡਾ ਹੈ, ਇਹ ਡਿਸਕ 'ਤੇ 2.7G ਹੈ, ਇਸ ਲਈ ਇਸ ਚੀਜ਼ ਦੀ ਕਾਪੀ ਬਣਾਉਣਾ ਬਹੁਤ ਅਣਚਾਹੇ ਹੈ - ਤੁਸੀਂ ਇਸਨੂੰ ਤੁਰੰਤ ਨੈੱਟਵਰਕ ਬਾਈਟ ਬਫਰ ਤੋਂ ਲੋਡ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ। ਰਜਿਸਟਰਾਂ ਵਿੱਚ, ਤਾਂ ਜੋ ਲਾਈਨ ਨੂੰ ਪੰਜ ਵਾਰ ਅੱਗੇ-ਪਿੱਛੇ ਨਾ ਪੜ੍ਹਿਆ-ਲਿਖਿਆ ਜਾਵੇ। ਬਦਕਿਸਮਤੀ ਨਾਲ, Java ਤੁਹਾਨੂੰ ਮੂਲ ਰੂਪ ਵਿੱਚ JDK ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਅਜਿਹੀ ਲਾਇਬ੍ਰੇਰੀ ਨਹੀਂ ਦਿੰਦਾ ਹੈ। ਪਰ ਇਹ ਮਾਮੂਲੀ ਹੈ, ਠੀਕ ਹੈ? ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ, ਇਹ ਕੋਡ ਦੀਆਂ 5-10 ਲਾਈਨਾਂ ਹਨ ਜੋ ਤੁਹਾਡੇ ਆਪਣੇ ਬਫਰਡ ਸਟ੍ਰਿੰਗ ਲੋਡਰ ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ ਵਰਤੀਆਂ ਜਾਣਗੀਆਂ, ਜੋ ਕਿ ਸਟ੍ਰਿੰਗ ਕਲਾਸ ਦੇ ਵਿਵਹਾਰ ਨੂੰ ਦੁਹਰਾਉਂਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਅੰਡਰਲਾਈੰਗ ਬਾਈਟ ਬਫਰ ਦੇ ਦੁਆਲੇ ਇੱਕ ਰੈਪਰ ਹੁੰਦਾ ਹੈ। ਨਤੀਜੇ ਵਜੋਂ, ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਲਗਭਗ ਇਸ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰ ਰਹੇ ਹੋ ਜਿਵੇਂ ਕਿ ਸਟ੍ਰਿੰਗਜ਼ ਨਾਲ, ਪਰ ਅਸਲ ਵਿੱਚ ਬਫਰ ਲਈ ਪੁਆਇੰਟਰ ਉੱਥੇ ਜਾ ਰਹੇ ਹਨ, ਅਤੇ ਕੱਚੇ ਬਾਈਟਾਂ ਨੂੰ ਕਿਤੇ ਵੀ ਨਕਲ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਉਹੀ ਬਫਰਾਂ ਨੂੰ ਬਾਰ ਬਾਰ ਦੁਬਾਰਾ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਉਹਨਾਂ ਚੀਜ਼ਾਂ ਨੂੰ ਲੈ ਕੇ ਖੁਸ਼ ਹੁੰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਲਈ ਇਹ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਗਿਆ ਹੈ, ਜਿਵੇਂ ਕਿ ਇਹਨਾਂ ਬਾਈਟ ਬਫਰਾਂ ਦੀ ਛੁਪੀ ਹੋਈ ਡਬਲ-ਬਫਰਿੰਗ, ਅਤੇ ਤੁਸੀਂ ਹੁਣ ਬੇਲੋੜੇ ਡੇਟਾ ਦੀ ਇੱਕ ਬੇਅੰਤ ਧਾਰਾ ਨੂੰ ਪੀਸ ਨਹੀਂ ਰਹੇ ਹੋ। ਤਰੀਕੇ ਨਾਲ, ਕੀ ਤੁਸੀਂ ਸਮਝਦੇ ਹੋ ਕਿ GC ਨਾਲ ਕੰਮ ਕਰਦੇ ਸਮੇਂ, ਇਹ ਗਾਰੰਟੀ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ ਕਿ ਆਖਰੀ GC ਚੱਕਰ ਤੋਂ ਬਾਅਦ ਹਰੇਕ ਮੈਮੋਰੀ ਵੰਡ ਪ੍ਰੋਸੈਸਰ ਨੂੰ ਦਿਖਾਈ ਨਹੀਂ ਦੇਵੇਗੀ? ਇਸ ਲਈ, ਇਹ ਸਭ ਸੰਭਵ ਤੌਰ 'ਤੇ ਕੈਸ਼ ਵਿੱਚ ਨਹੀਂ ਹੋ ਸਕਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਇੱਕ 100% ਗਾਰੰਟੀਸ਼ੁਦਾ ਮਿਸ ਹੁੰਦੀ ਹੈ। ਪੁਆਇੰਟਰ ਨਾਲ ਕੰਮ ਕਰਦੇ ਸਮੇਂ, x86 'ਤੇ, ਮੈਮੋਰੀ ਤੋਂ ਰਜਿਸਟਰ ਨੂੰ ਘਟਾਉਣ ਲਈ 1-2 ਘੜੀ ਦੇ ਚੱਕਰ ਲੱਗ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਜਿਵੇਂ ਹੀ ਇਹ ਹੁੰਦਾ ਹੈ, ਤੁਸੀਂ ਭੁਗਤਾਨ ਕਰੋ, ਭੁਗਤਾਨ ਕਰੋ, ਭੁਗਤਾਨ ਕਰੋ, ਕਿਉਂਕਿ ਮੈਮੋਰੀ ਚਾਲੂ ਹੈ ਨੌ ਕੈਸ਼ - ਅਤੇ ਇਹ ਮੈਮੋਰੀ ਵੰਡ ਦੀ ਲਾਗਤ ਹੈ। ਅਸਲ ਮੁੱਲ।

ਦੂਜੇ ਸ਼ਬਦਾਂ ਵਿਚ, ਡੇਟਾ ਢਾਂਚੇ ਨੂੰ ਬਦਲਣਾ ਸਭ ਤੋਂ ਔਖਾ ਹੈ. ਅਤੇ ਇੱਕ ਵਾਰ ਜਦੋਂ ਤੁਸੀਂ ਇਹ ਮਹਿਸੂਸ ਕਰਦੇ ਹੋ ਕਿ ਤੁਸੀਂ ਗਲਤ ਡਾਟਾ ਢਾਂਚਾ ਚੁਣਿਆ ਹੈ ਜੋ ਬਾਅਦ ਵਿੱਚ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਖਤਮ ਕਰ ਦੇਵੇਗਾ, ਤਾਂ ਆਮ ਤੌਰ 'ਤੇ ਬਹੁਤ ਸਾਰਾ ਕੰਮ ਕਰਨਾ ਹੁੰਦਾ ਹੈ, ਪਰ ਜੇਕਰ ਤੁਸੀਂ ਅਜਿਹਾ ਨਹੀਂ ਕਰਦੇ, ਤਾਂ ਚੀਜ਼ਾਂ ਵਿਗੜ ਜਾਣਗੀਆਂ। ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਤੁਹਾਨੂੰ ਡਾਟਾ ਢਾਂਚੇ ਬਾਰੇ ਸੋਚਣ ਦੀ ਲੋੜ ਹੈ, ਇਹ ਮਹੱਤਵਪੂਰਨ ਹੈ. ਇੱਥੇ ਮੁੱਖ ਲਾਗਤ ਚਰਬੀ ਡਾਟਾ ਢਾਂਚੇ 'ਤੇ ਆਉਂਦੀ ਹੈ, ਜੋ ਕਿ "ਮੈਂ ਡਾਟਾ ਢਾਂਚੇ X ਨੂੰ ਡਾਟਾ ਢਾਂਚੇ Y ਵਿੱਚ ਕਾਪੀ ਕੀਤਾ ਹੈ ਕਿਉਂਕਿ ਮੈਨੂੰ Y ਦੀ ਸ਼ਕਲ ਬਿਹਤਰ ਪਸੰਦ ਹੈ।" ਪਰ ਕਾਪੀ ਓਪਰੇਸ਼ਨ (ਜੋ ਸਸਤਾ ਲੱਗਦਾ ਹੈ) ਅਸਲ ਵਿੱਚ ਮੈਮੋਰੀ ਬੈਂਡਵਿਡਥ ਨੂੰ ਬਰਬਾਦ ਕਰਦਾ ਹੈ ਅਤੇ ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਸਾਰਾ ਬਰਬਾਦ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਸਮਾਂ ਦੱਬਿਆ ਜਾਂਦਾ ਹੈ। ਜੇ ਮੇਰੇ ਕੋਲ JSON ਦੀ ਇੱਕ ਵਿਸ਼ਾਲ ਸਤਰ ਹੈ ਅਤੇ ਮੈਂ ਇਸਨੂੰ POJOs ਜਾਂ ਕਿਸੇ ਹੋਰ ਚੀਜ਼ ਦੇ ਇੱਕ ਸਟ੍ਰਕਚਰਡ DOM ਟ੍ਰੀ ਵਿੱਚ ਬਦਲਣਾ ਚਾਹੁੰਦਾ ਹਾਂ, ਤਾਂ ਉਸ ਸਤਰ ਨੂੰ ਪਾਰਸ ਕਰਨ ਅਤੇ POJO ਨੂੰ ਬਣਾਉਣ ਦੀ ਕਾਰਵਾਈ, ਅਤੇ ਫਿਰ ਬਾਅਦ ਵਿੱਚ POJO ਨੂੰ ਦੁਬਾਰਾ ਐਕਸੈਸ ਕਰਨ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਬੇਲੋੜੀ ਲਾਗਤ ਆਵੇਗੀ - ਇਹ ਸਸਤਾ ਨਹੀਂ। ਸਿਵਾਏ ਜੇਕਰ ਤੁਸੀਂ POJOs ਦੇ ਦੁਆਲੇ ਇੱਕ ਸਤਰ ਦੇ ਦੁਆਲੇ ਦੌੜਨ ਨਾਲੋਂ ਬਹੁਤ ਜ਼ਿਆਦਾ ਵਾਰ ਦੌੜਦੇ ਹੋ। ਔਫਹੈਂਡ, ਤੁਸੀਂ ਇਸ ਦੀ ਬਜਾਏ ਸਟ੍ਰਿੰਗ ਨੂੰ ਡੀਕ੍ਰਿਪਟ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਇਸ ਨੂੰ ਕਿਸੇ POJO ਵਿੱਚ ਬਦਲੇ ਬਿਨਾਂ, ਉਥੋਂ ਸਿਰਫ਼ ਉਹੀ ਕੱਢ ਸਕਦੇ ਹੋ ਜੋ ਤੁਹਾਨੂੰ ਚਾਹੀਦਾ ਹੈ। ਜੇ ਇਹ ਸਭ ਉਸ ਮਾਰਗ 'ਤੇ ਵਾਪਰਦਾ ਹੈ ਜਿੱਥੋਂ ਵੱਧ ਤੋਂ ਵੱਧ ਪ੍ਰਦਰਸ਼ਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਤੁਹਾਡੇ ਲਈ ਕੋਈ POJO ਨਹੀਂ, ਤੁਹਾਨੂੰ ਕਿਸੇ ਤਰ੍ਹਾਂ ਸਿੱਧੇ ਲਾਈਨ ਵਿੱਚ ਖੋਦਣ ਦੀ ਜ਼ਰੂਰਤ ਹੁੰਦੀ ਹੈ।

ਆਪਣੀ ਖੁਦ ਦੀ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਭਾਸ਼ਾ ਕਿਉਂ ਬਣਾਓ

ਆਂਦਰੇਈ: ਤੁਸੀਂ ਕਿਹਾ ਕਿ ਲਾਗਤ ਮਾਡਲ ਨੂੰ ਸਮਝਣ ਲਈ, ਤੁਹਾਨੂੰ ਆਪਣੀ ਛੋਟੀ ਭਾਸ਼ਾ ਲਿਖਣ ਦੀ ਲੋੜ ਹੈ...

ਚੱਟਾਨ: ਇੱਕ ਭਾਸ਼ਾ ਨਹੀਂ, ਪਰ ਇੱਕ ਕੰਪਾਈਲਰ। ਇੱਕ ਭਾਸ਼ਾ ਅਤੇ ਇੱਕ ਕੰਪਾਈਲਰ ਦੋ ਵੱਖ-ਵੱਖ ਚੀਜ਼ਾਂ ਹਨ। ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਅੰਤਰ ਤੁਹਾਡੇ ਸਿਰ ਵਿੱਚ ਹੈ. 

ਆਂਦਰੇਈ: ਵੈਸੇ, ਜਿੱਥੋਂ ਤੱਕ ਮੈਨੂੰ ਪਤਾ ਹੈ, ਤੁਸੀਂ ਆਪਣੀਆਂ ਭਾਸ਼ਾਵਾਂ ਬਣਾਉਣ ਦਾ ਪ੍ਰਯੋਗ ਕਰ ਰਹੇ ਹੋ। ਕਾਹਦੇ ਲਈ?

ਚੱਟਾਨ: ਕਿਉਂਕਿ ਮੈਂ ਕਰ ਸਕਦਾ ਹਾਂ! ਮੈਂ ਅਰਧ-ਰਿਟਾਇਰਡ ਹਾਂ, ਇਸ ਲਈ ਇਹ ਮੇਰਾ ਸ਼ੌਕ ਹੈ। ਮੇਰੀ ਸਾਰੀ ਉਮਰ ਮੈਂ ਦੂਜੇ ਲੋਕਾਂ ਦੀਆਂ ਭਾਸ਼ਾਵਾਂ ਨੂੰ ਲਾਗੂ ਕਰਦਾ ਰਿਹਾ ਹਾਂ। ਮੈਂ ਆਪਣੀ ਕੋਡਿੰਗ ਸ਼ੈਲੀ 'ਤੇ ਵੀ ਬਹੁਤ ਕੰਮ ਕੀਤਾ। ਅਤੇ ਇਹ ਵੀ ਕਿਉਂਕਿ ਮੈਂ ਦੂਜੀਆਂ ਭਾਸ਼ਾਵਾਂ ਵਿੱਚ ਸਮੱਸਿਆਵਾਂ ਦੇਖਦਾ ਹਾਂ। ਮੈਂ ਦੇਖਦਾ ਹਾਂ ਕਿ ਜਾਣੇ-ਪਛਾਣੇ ਕੰਮ ਕਰਨ ਦੇ ਬਿਹਤਰ ਤਰੀਕੇ ਹਨ। ਅਤੇ ਮੈਂ ਉਹਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਾਂਗਾ. ਮੈਂ ਆਪਣੇ ਆਪ ਵਿੱਚ, ਜਾਵਾ ਵਿੱਚ, ਪਾਈਥਨ ਵਿੱਚ, ਕਿਸੇ ਹੋਰ ਭਾਸ਼ਾ ਵਿੱਚ ਸਮੱਸਿਆਵਾਂ ਦੇਖ ਕੇ ਥੱਕ ਗਿਆ ਹਾਂ। ਮੈਂ ਹੁਣ ਰੀਐਕਟ ਨੇਟਿਵ, ਜਾਵਾ ਸਕ੍ਰਿਪਟ ਅਤੇ ਐਲਮ ਵਿੱਚ ਇੱਕ ਸ਼ੌਕ ਵਜੋਂ ਲਿਖਦਾ ਹਾਂ ਜੋ ਰਿਟਾਇਰਮੈਂਟ ਬਾਰੇ ਨਹੀਂ ਹੈ, ਪਰ ਸਰਗਰਮ ਕੰਮ ਬਾਰੇ ਹੈ। ਮੈਂ ਪਾਈਥਨ ਵਿੱਚ ਵੀ ਲਿਖਦਾ ਹਾਂ ਅਤੇ, ਸੰਭਾਵਤ ਤੌਰ 'ਤੇ, Java ਬੈਕਐਂਡ ਲਈ ਮਸ਼ੀਨ ਸਿਖਲਾਈ 'ਤੇ ਕੰਮ ਕਰਨਾ ਜਾਰੀ ਰੱਖਾਂਗਾ। ਇੱਥੇ ਬਹੁਤ ਸਾਰੀਆਂ ਪ੍ਰਸਿੱਧ ਭਾਸ਼ਾਵਾਂ ਹਨ ਅਤੇ ਉਹਨਾਂ ਸਾਰੀਆਂ ਵਿੱਚ ਦਿਲਚਸਪ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਹਨ। ਹਰ ਕੋਈ ਆਪਣੇ ਤਰੀਕੇ ਨਾਲ ਚੰਗਾ ਹੈ ਅਤੇ ਤੁਸੀਂ ਇਹਨਾਂ ਸਾਰੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਇਕੱਠੇ ਲਿਆਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਸਕਦੇ ਹੋ। ਇਸ ਲਈ, ਮੈਂ ਉਹਨਾਂ ਚੀਜ਼ਾਂ ਦਾ ਅਧਿਐਨ ਕਰ ਰਿਹਾ ਹਾਂ ਜੋ ਮੇਰੀ ਦਿਲਚਸਪੀ, ਭਾਸ਼ਾ ਦਾ ਵਿਵਹਾਰ, ਵਾਜਬ ਅਰਥ ਵਿਗਿਆਨ ਦੇ ਨਾਲ ਆਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਿਹਾ ਹੈ। ਅਤੇ ਹੁਣ ਤੱਕ ਮੈਂ ਸਫਲ ਰਿਹਾ ਹਾਂ! ਇਸ ਸਮੇਂ ਮੈਂ ਮੈਮੋਰੀ ਸਿਮੈਨਟਿਕਸ ਨਾਲ ਸੰਘਰਸ਼ ਕਰ ਰਿਹਾ ਹਾਂ, ਕਿਉਂਕਿ ਮੈਂ ਇਸਨੂੰ C ਅਤੇ Java ਵਿੱਚ ਪ੍ਰਾਪਤ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹਾਂ, ਅਤੇ ਲੋਡ ਅਤੇ ਸਟੋਰਾਂ ਲਈ ਇੱਕ ਮਜ਼ਬੂਤ ​​ਮੈਮੋਰੀ ਮਾਡਲ ਅਤੇ ਮੈਮੋਰੀ ਸਿਮੈਂਟਿਕਸ ਪ੍ਰਾਪਤ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹਾਂ। ਉਸੇ ਸਮੇਂ, ਹਾਸਕੇਲ ਵਾਂਗ ਆਟੋਮੈਟਿਕ ਕਿਸਮ ਦਾ ਅਨੁਮਾਨ ਰੱਖੋ। ਇੱਥੇ, ਮੈਂ ਸੀ ਅਤੇ ਜਾਵਾ ਦੋਵਾਂ ਵਿੱਚ ਮੈਮੋਰੀ ਵਰਕ ਦੇ ਨਾਲ ਹਾਸਕੇਲ-ਵਰਗੇ ਕਿਸਮ ਦੇ ਅਨੁਮਾਨ ਨੂੰ ਮਿਲਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਿਹਾ ਹਾਂ। ਇਹ ਉਹ ਹੈ ਜੋ ਮੈਂ ਪਿਛਲੇ 2-3 ਮਹੀਨਿਆਂ ਤੋਂ ਕਰ ਰਿਹਾ ਹਾਂ, ਉਦਾਹਰਣ ਵਜੋਂ.

ਆਂਦਰੇਈ: ਜੇ ਤੁਸੀਂ ਅਜਿਹੀ ਭਾਸ਼ਾ ਬਣਾਉਂਦੇ ਹੋ ਜੋ ਦੂਜੀਆਂ ਭਾਸ਼ਾਵਾਂ ਤੋਂ ਬਿਹਤਰ ਪਹਿਲੂਆਂ ਨੂੰ ਲੈਂਦੀ ਹੈ, ਤਾਂ ਕੀ ਤੁਸੀਂ ਸੋਚਦੇ ਹੋ ਕਿ ਕੋਈ ਇਸ ਦੇ ਉਲਟ ਕਰੇਗਾ: ਆਪਣੇ ਵਿਚਾਰ ਲਓ ਅਤੇ ਉਹਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰੋ?

ਚੱਟਾਨ: ਬਿਲਕੁਲ ਇਸ ਤਰ੍ਹਾਂ ਨਵੀਆਂ ਭਾਸ਼ਾਵਾਂ ਦਿਖਾਈ ਦਿੰਦੀਆਂ ਹਨ! Java C ਦੇ ਸਮਾਨ ਕਿਉਂ ਹੈ? ਕਿਉਂਕਿ C ਕੋਲ ਇੱਕ ਵਧੀਆ ਸੰਟੈਕਸ ਸੀ ਜੋ ਹਰ ਕੋਈ ਸਮਝਦਾ ਸੀ ਅਤੇ Java ਇਸ ਸੰਟੈਕਸ ਤੋਂ ਪ੍ਰੇਰਿਤ ਸੀ, ਟਾਈਪ ਸੇਫਟੀ, ਐਰੇ ਬਾਉਂਡ ਚੈਕਿੰਗ, GC, ਅਤੇ ਉਹਨਾਂ ਨੇ C ਤੋਂ ਕੁਝ ਚੀਜ਼ਾਂ ਵਿੱਚ ਸੁਧਾਰ ਵੀ ਕੀਤਾ। ਉਹਨਾਂ ਨੇ ਆਪਣੇ ਆਪ ਨੂੰ ਜੋੜਿਆ। ਪਰ ਉਹ ਬਹੁਤ ਜ਼ਿਆਦਾ ਪ੍ਰੇਰਿਤ ਸਨ, ਠੀਕ ਹੈ? ਹਰ ਕੋਈ ਤੁਹਾਡੇ ਤੋਂ ਪਹਿਲਾਂ ਆਏ ਦੈਂਤਾਂ ਦੇ ਮੋਢਿਆਂ 'ਤੇ ਖੜ੍ਹਾ ਹੈ - ਇਸ ਤਰ੍ਹਾਂ ਤਰੱਕੀ ਹੁੰਦੀ ਹੈ.

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

ਚੱਟਾਨ: ਖੈਰ, ਮੈਂ ਯੁੱਗਾਂ ਤੋਂ C ਲਿਖ ਰਿਹਾ ਹਾਂ, ਇਸ ਸਾਰੇ ਮੈਲੋਕ ਅਤੇ ਮੁਫਤ ਦੇ ਨਾਲ, ਅਤੇ ਜੀਵਨ ਭਰ ਦਾ ਪ੍ਰਬੰਧਨ ਹੱਥੀਂ ਕਰ ਰਿਹਾ ਹਾਂ. ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ, ਹੱਥੀਂ ਨਿਯੰਤਰਿਤ ਜੀਵਨ ਕਾਲ ਦੇ 90-95% ਵਿੱਚ ਇੱਕੋ ਬਣਤਰ ਹੈ। ਅਤੇ ਇਸ ਨੂੰ ਹੱਥੀਂ ਕਰਨਾ ਬਹੁਤ, ਬਹੁਤ ਦਰਦਨਾਕ ਹੈ। ਮੈਂ ਚਾਹੁੰਦਾ ਹਾਂ ਕਿ ਕੰਪਾਈਲਰ ਤੁਹਾਨੂੰ ਇਹ ਦੱਸੇ ਕਿ ਉੱਥੇ ਕੀ ਹੋ ਰਿਹਾ ਹੈ ਅਤੇ ਤੁਸੀਂ ਆਪਣੀਆਂ ਕਾਰਵਾਈਆਂ ਨਾਲ ਕੀ ਪ੍ਰਾਪਤ ਕੀਤਾ ਹੈ। ਕੁਝ ਚੀਜ਼ਾਂ ਲਈ, ਉਧਾਰ ਚੈਕਰ ਇਸ ਨੂੰ ਬਾਕਸ ਤੋਂ ਬਾਹਰ ਕਰਦਾ ਹੈ। ਅਤੇ ਇਸ ਨੂੰ ਆਪਣੇ ਆਪ ਹੀ ਜਾਣਕਾਰੀ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ, ਹਰ ਚੀਜ਼ ਨੂੰ ਸਮਝਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਇਸ ਸਮਝ ਨੂੰ ਪੇਸ਼ ਕਰਨ ਲਈ ਮੇਰੇ 'ਤੇ ਬੋਝ ਵੀ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ। ਇਸ ਨੂੰ ਘੱਟੋ-ਘੱਟ ਸਥਾਨਕ ਬਚਣ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਕੇਵਲ ਜੇਕਰ ਇਹ ਅਸਫਲ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਟਾਈਪ ਐਨੋਟੇਸ਼ਨ ਜੋੜਨ ਦੀ ਜ਼ਰੂਰਤ ਹੁੰਦੀ ਹੈ ਜੋ ਜੀਵਨ ਭਰ ਦਾ ਵਰਣਨ ਕਰੇਗੀ - ਅਤੇ ਅਜਿਹੀ ਸਕੀਮ ਇੱਕ ਉਧਾਰ ਚੈਕਰ, ਜਾਂ ਅਸਲ ਵਿੱਚ ਕਿਸੇ ਵੀ ਮੌਜੂਦਾ ਮੈਮੋਰੀ ਚੈਕਰ ਨਾਲੋਂ ਬਹੁਤ ਜ਼ਿਆਦਾ ਗੁੰਝਲਦਾਰ ਹੈ। "ਸਭ ਕੁਝ ਠੀਕ ਹੈ" ਅਤੇ "ਮੈਨੂੰ ਕੁਝ ਵੀ ਸਮਝ ਨਹੀਂ ਆਉਂਦਾ" ਵਿਚਕਾਰ ਚੋਣ - ਨਹੀਂ, ਕੁਝ ਬਿਹਤਰ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। 
ਇਸ ਲਈ, ਕਿਸੇ ਵਿਅਕਤੀ ਦੇ ਰੂਪ ਵਿੱਚ ਜਿਸਨੇ C ਵਿੱਚ ਬਹੁਤ ਸਾਰਾ ਕੋਡ ਲਿਖਿਆ ਹੈ, ਮੈਂ ਸੋਚਦਾ ਹਾਂ ਕਿ ਆਟੋਮੈਟਿਕ ਲਾਈਫਟਾਈਮ ਨਿਯੰਤਰਣ ਲਈ ਸਮਰਥਨ ਹੋਣਾ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਚੀਜ਼ ਹੈ. ਮੈਂ ਇਸ ਗੱਲ ਤੋਂ ਵੀ ਅੱਕ ਗਿਆ ਹਾਂ ਕਿ ਜਾਵਾ ਕਿੰਨੀ ਮੈਮੋਰੀ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ ਅਤੇ ਮੁੱਖ ਸ਼ਿਕਾਇਤ ਜੀ.ਸੀ. ਜਦੋਂ ਤੁਸੀਂ Java ਵਿੱਚ ਮੈਮੋਰੀ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਉਹ ਮੈਮੋਰੀ ਵਾਪਸ ਨਹੀਂ ਮਿਲੇਗੀ ਜੋ ਪਿਛਲੇ GC ਚੱਕਰ ਵਿੱਚ ਲੋਕਲ ਸੀ। ਇਹ ਵਧੇਰੇ ਸਟੀਕ ਮੈਮੋਰੀ ਪ੍ਰਬੰਧਨ ਵਾਲੀਆਂ ਭਾਸ਼ਾਵਾਂ ਵਿੱਚ ਨਹੀਂ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ malloc ਨੂੰ ਕਾਲ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਤੁਰੰਤ ਮੈਮੋਰੀ ਮਿਲਦੀ ਹੈ ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਹੁਣੇ ਵਰਤੀ ਜਾਂਦੀ ਸੀ। ਆਮ ਤੌਰ 'ਤੇ ਤੁਸੀਂ ਮੈਮੋਰੀ ਨਾਲ ਕੁਝ ਅਸਥਾਈ ਕੰਮ ਕਰਦੇ ਹੋ ਅਤੇ ਤੁਰੰਤ ਇਸਨੂੰ ਵਾਪਸ ਕਰ ਦਿੰਦੇ ਹੋ। ਅਤੇ ਇਹ ਤੁਰੰਤ malloc ਪੂਲ ਵਿੱਚ ਵਾਪਸ ਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਅਗਲਾ malloc ਚੱਕਰ ਇਸਨੂੰ ਦੁਬਾਰਾ ਬਾਹਰ ਕੱਢਦਾ ਹੈ। ਇਸ ਲਈ, ਅਸਲ ਮੈਮੋਰੀ ਦੀ ਵਰਤੋਂ ਨੂੰ ਇੱਕ ਦਿੱਤੇ ਸਮੇਂ 'ਤੇ ਜੀਵਿਤ ਵਸਤੂਆਂ ਦੇ ਸੈੱਟ ਤੱਕ ਘਟਾਇਆ ਜਾਂਦਾ ਹੈ, ਨਾਲ ਹੀ ਲੀਕ ਵੀ ਹੁੰਦੀ ਹੈ। ਅਤੇ ਜੇ ਸਭ ਕੁਝ ਪੂਰੀ ਤਰ੍ਹਾਂ ਅਸ਼ਲੀਲ ਤਰੀਕੇ ਨਾਲ ਲੀਕ ਨਹੀਂ ਹੁੰਦਾ, ਤਾਂ ਜ਼ਿਆਦਾਤਰ ਮੈਮੋਰੀ ਕੈਚ ਅਤੇ ਪ੍ਰੋਸੈਸਰ ਵਿੱਚ ਖਤਮ ਹੋ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਇਹ ਤੇਜ਼ੀ ਨਾਲ ਕੰਮ ਕਰਦੀ ਹੈ। ਪਰ malloc ਦੇ ਨਾਲ ਬਹੁਤ ਸਾਰੇ ਮੈਨੂਅਲ ਮੈਮੋਰੀ ਪ੍ਰਬੰਧਨ ਦੀ ਲੋੜ ਹੈ ਅਤੇ ਸਹੀ ਕ੍ਰਮ ਵਿੱਚ, ਸਹੀ ਥਾਂ 'ਤੇ ਮੁਫਤ ਕਾਲ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਜੰਗਾਲ ਆਪਣੇ ਆਪ ਇਸ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਸੰਭਾਲ ਸਕਦਾ ਹੈ, ਅਤੇ ਬਹੁਤ ਸਾਰੇ ਮਾਮਲਿਆਂ ਵਿੱਚ ਇਸ ਤੋਂ ਵੀ ਵਧੀਆ ਕਾਰਗੁਜ਼ਾਰੀ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, ਕਿਉਂਕਿ ਮੈਮੋਰੀ ਦੀ ਖਪਤ ਸਿਰਫ਼ ਮੌਜੂਦਾ ਗਣਨਾ ਤੱਕ ਸੀਮਤ ਹੈ - ਜਿਵੇਂ ਕਿ ਮੈਮੋਰੀ ਖਾਲੀ ਕਰਨ ਲਈ ਅਗਲੇ GC ਚੱਕਰ ਦੀ ਉਡੀਕ ਕਰਨ ਦੇ ਉਲਟ। ਨਤੀਜੇ ਵਜੋਂ, ਸਾਨੂੰ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਣ ਦਾ ਇੱਕ ਬਹੁਤ ਹੀ ਦਿਲਚਸਪ ਤਰੀਕਾ ਮਿਲਿਆ ਹੈ। ਅਤੇ ਕਾਫ਼ੀ ਸ਼ਕਤੀਸ਼ਾਲੀ - ਮੇਰਾ ਮਤਲਬ ਹੈ, ਮੈਂ ਫਿਨਟੈਕ ਲਈ ਡੇਟਾ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਦੇ ਸਮੇਂ ਅਜਿਹੀਆਂ ਚੀਜ਼ਾਂ ਕੀਤੀਆਂ, ਅਤੇ ਇਸਨੇ ਮੈਨੂੰ ਲਗਭਗ ਪੰਜ ਗੁਣਾ ਦੀ ਗਤੀ ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੱਤੀ. ਇਹ ਇੱਕ ਬਹੁਤ ਵੱਡਾ ਹੁਲਾਰਾ ਹੈ, ਖਾਸ ਤੌਰ 'ਤੇ ਅਜਿਹੀ ਦੁਨੀਆ ਵਿੱਚ ਜਿੱਥੇ ਪ੍ਰੋਸੈਸਰ ਤੇਜ਼ ਨਹੀਂ ਹੋ ਰਹੇ ਹਨ ਅਤੇ ਅਸੀਂ ਅਜੇ ਵੀ ਸੁਧਾਰਾਂ ਦੀ ਉਡੀਕ ਕਰ ਰਹੇ ਹਾਂ।

ਪ੍ਰਦਰਸ਼ਨ ਇੰਜੀਨੀਅਰ ਕਰੀਅਰ

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

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

ਹਾਂ, ਮੈਨੂੰ ਸੱਚਮੁੱਚ ਵਿਤਰਿਤ ਕੰਪਿਊਟਿੰਗ ਪਸੰਦ ਹੈ। ਮੇਰੀ ਪਹਿਲੀ ਨੌਕਰੀ ਸੀ ਵਿੱਚ ਇੱਕ ਵਿਦਿਆਰਥੀ ਵਜੋਂ, ਇੱਕ ਵਿਗਿਆਪਨ ਪ੍ਰੋਜੈਕਟ 'ਤੇ ਸੀ। ਇਹ Zilog Z80 ਚਿੱਪਾਂ 'ਤੇ ਕੰਪਿਊਟਿੰਗ ਵੰਡਿਆ ਗਿਆ ਸੀ ਜੋ ਐਨਾਲਾਗ OCR ਲਈ ਡੇਟਾ ਇਕੱਠਾ ਕਰਦਾ ਸੀ, ਜੋ ਕਿ ਇੱਕ ਅਸਲੀ ਐਨਾਲਾਗ ਵਿਸ਼ਲੇਸ਼ਕ ਦੁਆਰਾ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਸੀ। ਇਹ ਇੱਕ ਠੰਡਾ ਅਤੇ ਪੂਰੀ ਤਰ੍ਹਾਂ ਪਾਗਲ ਵਿਸ਼ਾ ਸੀ। ਪਰ ਸਮੱਸਿਆਵਾਂ ਸਨ, ਕੁਝ ਹਿੱਸੇ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਪਛਾਣਿਆ ਨਹੀਂ ਗਿਆ ਸੀ, ਇਸ ਲਈ ਤੁਹਾਨੂੰ ਇੱਕ ਤਸਵੀਰ ਕੱਢਣੀ ਪਈ ਅਤੇ ਇਸਨੂੰ ਇੱਕ ਵਿਅਕਤੀ ਨੂੰ ਦਿਖਾਉਣਾ ਪਿਆ ਜੋ ਪਹਿਲਾਂ ਹੀ ਆਪਣੀਆਂ ਅੱਖਾਂ ਨਾਲ ਪੜ੍ਹ ਸਕਦਾ ਸੀ ਅਤੇ ਇਸਦੀ ਰਿਪੋਰਟ ਕਰ ਸਕਦਾ ਸੀ, ਅਤੇ ਇਸਲਈ ਡੇਟਾ ਦੇ ਨਾਲ ਨੌਕਰੀਆਂ ਸਨ, ਅਤੇ ਇਹ ਨੌਕਰੀਆਂ ਉਹਨਾਂ ਦੀ ਆਪਣੀ ਭਾਸ਼ਾ ਸੀ। ਇੱਕ ਬੈਕਐਂਡ ਸੀ ਜਿਸਨੇ ਇਸ ਸਭ ਨੂੰ ਪ੍ਰੋਸੈਸ ਕੀਤਾ - Z80s ਚੱਲ ਰਹੇ vt100 ਟਰਮੀਨਲਾਂ ਦੇ ਸਮਾਨਾਂਤਰ ਚੱਲ ਰਹੇ ਸਨ - ਇੱਕ ਪ੍ਰਤੀ ਵਿਅਕਤੀ, ਅਤੇ Z80 'ਤੇ ਇੱਕ ਸਮਾਨਾਂਤਰ ਪ੍ਰੋਗਰਾਮਿੰਗ ਮਾਡਲ ਸੀ। ਇੱਕ ਸਟਾਰ ਕੌਂਫਿਗਰੇਸ਼ਨ ਦੇ ਅੰਦਰ ਸਾਰੇ Z80s ਦੁਆਰਾ ਸਾਂਝੀ ਕੀਤੀ ਗਈ ਮੈਮੋਰੀ ਦਾ ਕੁਝ ਸਾਂਝਾ ਹਿੱਸਾ; ਬੈਕਪਲੇਨ ਵੀ ਸਾਂਝਾ ਕੀਤਾ ਗਿਆ ਸੀ, ਅਤੇ ਅੱਧਾ ਰੈਮ ਨੈੱਟਵਰਕ ਦੇ ਅੰਦਰ ਸਾਂਝਾ ਕੀਤਾ ਗਿਆ ਸੀ, ਅਤੇ ਦੂਜਾ ਅੱਧਾ ਨਿੱਜੀ ਸੀ ਜਾਂ ਕਿਸੇ ਹੋਰ ਚੀਜ਼ 'ਤੇ ਗਿਆ ਸੀ। ਸ਼ੇਅਰਡ... ਅਰਧ-ਸਾਂਝੀ ਮੈਮੋਰੀ ਦੇ ਨਾਲ ਇੱਕ ਅਰਥਪੂਰਨ ਗੁੰਝਲਦਾਰ ਸਮਾਨਾਂਤਰ ਵੰਡਿਆ ਸਿਸਟਮ। ਇਹ ਕਦੋਂ ਸੀ... ਮੈਨੂੰ ਯਾਦ ਵੀ ਨਹੀਂ ਹੈ, 80 ਦੇ ਦਹਾਕੇ ਦੇ ਅੱਧ ਵਿੱਚ। ਕਾਫੀ ਸਮਾਂ ਪਹਿਲਾਂ। 
ਹਾਂ, ਮੰਨ ਲਓ ਕਿ 30 ਸਾਲ ਕਾਫ਼ੀ ਲੰਬਾ ਸਮਾਂ ਪਹਿਲਾਂ ਦੀ ਗੱਲ ਹੈ। ਡਿਸਟ੍ਰੀਬਿਊਟਿਡ ਕੰਪਿਊਟਿੰਗ ਨਾਲ ਸਬੰਧਤ ਸਮੱਸਿਆਵਾਂ ਕਾਫ਼ੀ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਮੌਜੂਦ ਹਨ; ਲੋਕ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਲੜਾਈ ਵਿੱਚ ਹਨ ਬਓਵੌਲਫ- ਕਲੱਸਟਰ. ਅਜਿਹੇ ਕਲੱਸਟਰ ਇਸ ਤਰ੍ਹਾਂ ਦੇ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ... ਉਦਾਹਰਨ ਲਈ: ਇੱਥੇ ਈਥਰਨੈੱਟ ਹੈ ਅਤੇ ਤੁਹਾਡਾ ਤੇਜ਼ x86 ਇਸ ਈਥਰਨੈੱਟ ਨਾਲ ਜੁੜਿਆ ਹੋਇਆ ਹੈ, ਅਤੇ ਹੁਣ ਤੁਸੀਂ ਜਾਅਲੀ ਸ਼ੇਅਰਡ ਮੈਮੋਰੀ ਪ੍ਰਾਪਤ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਕਿਉਂਕਿ ਉਦੋਂ ਕੋਈ ਵੀ ਡਿਸਟ੍ਰੀਬਿਊਟਿਡ ਕੰਪਿਊਟਿੰਗ ਕੋਡਿੰਗ ਨਹੀਂ ਕਰ ਸਕਦਾ ਸੀ, ਇਹ ਬਹੁਤ ਮੁਸ਼ਕਲ ਸੀ ਅਤੇ ਇਸ ਲਈ ਉੱਥੇ x86 'ਤੇ ਸੁਰੱਖਿਆ ਮੈਮੋਰੀ ਪੰਨਿਆਂ ਨਾਲ ਨਕਲੀ ਸਾਂਝੀ ਕੀਤੀ ਗਈ ਮੈਮੋਰੀ ਸੀ, ਅਤੇ ਜੇਕਰ ਤੁਸੀਂ ਇਸ ਪੰਨੇ 'ਤੇ ਲਿਖਿਆ ਸੀ, ਤਾਂ ਅਸੀਂ ਦੂਜੇ ਪ੍ਰੋਸੈਸਰਾਂ ਨੂੰ ਕਿਹਾ ਕਿ ਜੇਕਰ ਉਹ ਉਸੇ ਸਾਂਝੀ ਕੀਤੀ ਮੈਮੋਰੀ ਤੱਕ ਪਹੁੰਚ ਕਰਦੇ ਹਨ, ਤਾਂ ਇਸ ਨੂੰ ਤੁਹਾਡੇ ਤੋਂ ਲੋਡ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੋਏਗੀ, ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਸਹਾਇਤਾ ਲਈ ਇੱਕ ਪ੍ਰੋਟੋਕੋਲ ਵਰਗਾ ਕੁਝ ਕੈਸ਼ ਕੋਹੇਰੈਂਸ ਪ੍ਰਗਟ ਹੋਇਆ ਹੈ ਅਤੇ ਇਸਦੇ ਲਈ ਸੌਫਟਵੇਅਰ. ਦਿਲਚਸਪ ਧਾਰਨਾ. ਅਸਲ ਸਮੱਸਿਆ, ਬੇਸ਼ੱਕ, ਕੁਝ ਹੋਰ ਸੀ. ਇਸ ਸਭ ਨੇ ਕੰਮ ਕੀਤਾ, ਪਰ ਤੁਹਾਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਪ੍ਰਦਰਸ਼ਨ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਆਈਆਂ, ਕਿਉਂਕਿ ਕੋਈ ਵੀ ਇੱਕ ਚੰਗੇ ਪੱਧਰ 'ਤੇ ਪ੍ਰਦਰਸ਼ਨ ਮਾਡਲਾਂ ਨੂੰ ਨਹੀਂ ਸਮਝ ਸਕਿਆ - ਉੱਥੇ ਮੈਮੋਰੀ ਐਕਸੈਸ ਪੈਟਰਨ ਕੀ ਸਨ, ਇਹ ਕਿਵੇਂ ਯਕੀਨੀ ਬਣਾਇਆ ਜਾਵੇ ਕਿ ਨੋਡ ਇੱਕ ਦੂਜੇ ਨੂੰ ਬੇਅੰਤ ਪਿੰਗ ਨਹੀਂ ਕਰਦੇ, ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਹੀ.

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

ਤਕਨੀਕੀ ਚੁਣੌਤੀਆਂ

ਆਂਦਰੇਈ: ਤੁਹਾਡੇ ਪੂਰੇ ਕਰੀਅਰ ਵਿੱਚ ਤੁਹਾਡੀ ਸਭ ਤੋਂ ਵੱਡੀ ਚੁਣੌਤੀ ਕੀ ਰਹੀ ਹੈ?

ਚੱਟਾਨ: ਕੀ ਅਸੀਂ ਮੁੱਦੇ ਦੇ ਤਕਨੀਕੀ ਜਾਂ ਗੈਰ-ਤਕਨੀਕੀ ਹਿੱਸੇ ਦੀ ਚਰਚਾ ਕਰ ਰਹੇ ਹਾਂ? ਮੈਂ ਕਹਾਂਗਾ ਕਿ ਸਭ ਤੋਂ ਵੱਡੀਆਂ ਚੁਣੌਤੀਆਂ ਤਕਨੀਕੀ ਨਹੀਂ ਹਨ। 
ਜਿਵੇਂ ਕਿ ਤਕਨੀਕੀ ਚੁਣੌਤੀਆਂ ਲਈ. ਮੈਂ ਬਸ ਉਹਨਾਂ ਨੂੰ ਹਰਾਇਆ। ਮੈਨੂੰ ਇਹ ਵੀ ਨਹੀਂ ਪਤਾ ਕਿ ਸਭ ਤੋਂ ਵੱਡਾ ਕੀ ਸੀ, ਪਰ ਕੁਝ ਬਹੁਤ ਦਿਲਚਸਪ ਸਨ ਜਿਨ੍ਹਾਂ ਨੇ ਕਾਫ਼ੀ ਸਮਾਂ ਲਿਆ, ਮਾਨਸਿਕ ਸੰਘਰਸ਼। ਜਦੋਂ ਮੈਂ ਸੂਰਜ ਕੋਲ ਗਿਆ, ਮੈਨੂੰ ਯਕੀਨ ਸੀ ਕਿ ਮੈਂ ਇੱਕ ਤੇਜ਼ ਕੰਪਾਈਲਰ ਬਣਾਵਾਂਗਾ, ਅਤੇ ਸੀਨੀਅਰਾਂ ਦੇ ਝੁੰਡ ਨੇ ਜਵਾਬ ਵਿੱਚ ਕਿਹਾ ਕਿ ਮੈਂ ਕਦੇ ਵੀ ਸਫਲ ਨਹੀਂ ਹੋਵਾਂਗਾ. ਪਰ ਮੈਂ ਇਸ ਮਾਰਗ ਦੀ ਪਾਲਣਾ ਕੀਤੀ, ਰਜਿਸਟਰ ਅਲੋਕੇਟਰ ਨੂੰ ਇੱਕ ਕੰਪਾਈਲਰ ਲਿਖਿਆ, ਅਤੇ ਇਹ ਕਾਫ਼ੀ ਤੇਜ਼ ਸੀ. ਇਹ ਆਧੁਨਿਕ C1 ਜਿੰਨਾ ਤੇਜ਼ ਸੀ, ਪਰ ਅਲੋਕੇਟਰ ਉਸ ਸਮੇਂ ਬਹੁਤ ਹੌਲੀ ਸੀ, ਅਤੇ ਪਿੱਛੇ ਨਜ਼ਰ ਵਿੱਚ ਇਹ ਇੱਕ ਵੱਡੀ ਡਾਟਾ ਬਣਤਰ ਸਮੱਸਿਆ ਸੀ। ਮੈਨੂੰ ਇੱਕ ਗ੍ਰਾਫਿਕਲ ਰਜਿਸਟਰ ਅਲੋਕੇਟਰ ਲਿਖਣ ਲਈ ਇਸਦੀ ਲੋੜ ਸੀ ਅਤੇ ਮੈਂ ਕੋਡ ਐਕਸਪ੍ਰੈਸਿਵਨੇਸ ਅਤੇ ਸਪੀਡ ਵਿਚਕਾਰ ਦੁਬਿਧਾ ਨੂੰ ਨਹੀਂ ਸਮਝਿਆ, ਜੋ ਉਸ ਯੁੱਗ ਵਿੱਚ ਮੌਜੂਦ ਸੀ ਅਤੇ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਸੀ। ਇਹ ਪਤਾ ਚਲਿਆ ਕਿ ਡੇਟਾ ਢਾਂਚਾ ਆਮ ਤੌਰ 'ਤੇ ਉਸ ਸਮੇਂ ਦੇ x86s 'ਤੇ ਕੈਸ਼ ਆਕਾਰ ਤੋਂ ਵੱਧ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਇਸ ਲਈ, ਜੇ ਮੈਂ ਸ਼ੁਰੂ ਵਿੱਚ ਇਹ ਮੰਨ ਲਿਆ ਸੀ ਕਿ ਰਜਿਸਟਰ ਅਲੋਕੇਟਰ ਕੁੱਲ ਘੰਟਾ ਵਾਰ ਦਾ 5-10 ਪ੍ਰਤੀਸ਼ਤ ਕੰਮ ਕਰੇਗਾ, ਤਾਂ ਅਸਲ ਵਿੱਚ ਇਹ ਨਿਕਲਿਆ। 50 ਪ੍ਰਤੀਸ਼ਤ।

ਜਿਵੇਂ-ਜਿਵੇਂ ਸਮਾਂ ਬੀਤਦਾ ਗਿਆ, ਕੰਪਾਈਲਰ ਸਾਫ਼ ਅਤੇ ਵਧੇਰੇ ਕੁਸ਼ਲ ਹੋ ਗਿਆ, ਹੋਰ ਮਾਮਲਿਆਂ ਵਿੱਚ ਭਿਆਨਕ ਕੋਡ ਪੈਦਾ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੱਤਾ, ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਵੱਧ ਤੋਂ ਵੱਧ ਇੱਕ C ਕੰਪਾਈਲਰ ਦੇ ਸਮਾਨ ਹੋਣ ਲੱਗਾ। ਜਦੋਂ ਤੱਕ, ਬੇਸ਼ਕ, ਤੁਸੀਂ ਕੁਝ ਬਕਵਾਸ ਲਿਖਦੇ ਹੋ ਜੋ C ਦੀ ਗਤੀ ਵੀ ਨਹੀਂ ਵਧਦੀ। . ਜੇਕਰ ਤੁਸੀਂ C ਵਰਗਾ ਕੋਡ ਲਿਖਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਹੋਰ ਮਾਮਲਿਆਂ ਵਿੱਚ C ਵਰਗਾ ਪ੍ਰਦਰਸ਼ਨ ਮਿਲੇਗਾ। ਅਤੇ ਜਿੰਨਾ ਤੁਸੀਂ ਅੱਗੇ ਵਧਦੇ ਹੋ, ਜਿੰਨੀ ਵਾਰ ਤੁਹਾਨੂੰ ਕੋਡ ਮਿਲਦਾ ਹੈ ਜੋ ਅਸੈਂਪਟੋਟਿਕ ਤੌਰ 'ਤੇ ਪੱਧਰ C ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ, ਰਜਿਸਟਰ ਅਲੋਕੇਟਰ ਕੁਝ ਸੰਪੂਰਨ ਦਿਖਾਈ ਦੇਣ ਲੱਗਾ... ਚਾਹੇ ਤੁਹਾਡਾ ਕੋਡ ਤੇਜ਼ ਜਾਂ ਹੌਲੀ ਚੱਲਦਾ ਹੋਵੇ। ਮੈਂ ਇਸ ਨੂੰ ਬਿਹਤਰ ਚੋਣ ਕਰਨ ਲਈ ਅਲੋਕੇਟਰ 'ਤੇ ਕੰਮ ਕਰਨਾ ਜਾਰੀ ਰੱਖਿਆ। ਉਹ ਹੌਲੀ ਅਤੇ ਹੌਲੀ ਹੋ ਗਿਆ, ਪਰ ਉਸਨੇ ਉਹਨਾਂ ਮਾਮਲਿਆਂ ਵਿੱਚ ਬਿਹਤਰ ਅਤੇ ਵਧੀਆ ਪ੍ਰਦਰਸ਼ਨ ਦਿੱਤਾ ਜਿੱਥੇ ਕੋਈ ਹੋਰ ਨਹੀਂ ਝੱਲ ਸਕਦਾ ਸੀ। ਮੈਂ ਇੱਕ ਰਜਿਸਟਰ ਅਲੋਕੇਟਰ ਵਿੱਚ ਡੁਬਕੀ ਲਗਾ ਸਕਦਾ ਹਾਂ, ਉੱਥੇ ਇੱਕ ਮਹੀਨੇ ਦਾ ਕੰਮ ਦਫਨ ਕਰ ਸਕਦਾ ਹਾਂ, ਅਤੇ ਅਚਾਨਕ ਪੂਰਾ ਕੋਡ 5% ਤੇਜ਼ੀ ਨਾਲ ਚਲਾਉਣਾ ਸ਼ੁਰੂ ਕਰ ਦੇਵੇਗਾ। ਇਹ ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਵਾਪਰਿਆ ਅਤੇ ਰਜਿਸਟਰ ਅਲੋਕੇਟਰ ਕਲਾ ਦਾ ਕੰਮ ਬਣ ਗਿਆ - ਹਰ ਕੋਈ ਇਸ ਨੂੰ ਪਿਆਰ ਕਰਦਾ ਸੀ ਜਾਂ ਇਸ ਨੂੰ ਨਫ਼ਰਤ ਕਰਦਾ ਸੀ, ਅਤੇ ਅਕੈਡਮੀ ਦੇ ਲੋਕਾਂ ਨੇ "ਸਭ ਕੁਝ ਇਸ ਤਰ੍ਹਾਂ ਕਿਉਂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ" ਵਿਸ਼ੇ 'ਤੇ ਸਵਾਲ ਪੁੱਛੇ, ਕਿਉਂ ਨਹੀਂ? ਲਾਈਨ ਸਕੈਨ, ਅਤੇ ਕੀ ਫਰਕ ਹੈ। ਜਵਾਬ ਅਜੇ ਵੀ ਉਹੀ ਹੈ: ਗ੍ਰਾਫ ਕਲਰਿੰਗ ਅਤੇ ਬਫਰ ਕੋਡ ਦੇ ਨਾਲ ਬਹੁਤ ਸਾਵਧਾਨੀ ਨਾਲ ਕੰਮ 'ਤੇ ਅਧਾਰਤ ਇੱਕ ਅਲੋਕੇਟਰ ਜਿੱਤ ਦੇ ਹਥਿਆਰ ਦੇ ਬਰਾਬਰ ਹੈ, ਸਭ ਤੋਂ ਵਧੀਆ ਸੁਮੇਲ ਜਿਸ ਨੂੰ ਕੋਈ ਵੀ ਹਰਾ ਨਹੀਂ ਸਕਦਾ। ਅਤੇ ਇਹ ਇੱਕ ਗੈਰ-ਸਪੱਸ਼ਟ ਚੀਜ਼ ਹੈ. ਹੋਰ ਸਭ ਕੁਝ ਜੋ ਕੰਪਾਈਲਰ ਉੱਥੇ ਕਰਦਾ ਹੈ ਉਹ ਕਾਫ਼ੀ ਚੰਗੀ ਤਰ੍ਹਾਂ ਅਧਿਐਨ ਕੀਤੀਆਂ ਚੀਜ਼ਾਂ ਹਨ, ਹਾਲਾਂਕਿ ਉਨ੍ਹਾਂ ਨੂੰ ਕਲਾ ਦੇ ਪੱਧਰ 'ਤੇ ਵੀ ਲਿਆਂਦਾ ਗਿਆ ਹੈ। ਮੈਂ ਹਮੇਸ਼ਾਂ ਉਹ ਕੰਮ ਕੀਤਾ ਜੋ ਕੰਪਾਈਲਰ ਨੂੰ ਕਲਾ ਦੇ ਕੰਮ ਵਿੱਚ ਬਦਲਣਾ ਚਾਹੀਦਾ ਸੀ. ਪਰ ਇਸ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਅਸਾਧਾਰਣ ਨਹੀਂ ਸੀ - ਰਜਿਸਟਰ ਅਲੋਕਟਰ ਨੂੰ ਛੱਡ ਕੇ। ਚਾਲ ਸਾਵਧਾਨ ਰਹਿਣ ਦੀ ਹੈ ਘਟਾਓੁਣਾ ਲੋਡ ਦੇ ਅਧੀਨ ਅਤੇ, ਜੇਕਰ ਅਜਿਹਾ ਹੁੰਦਾ ਹੈ (ਜੇਕਰ ਮੈਂ ਦਿਲਚਸਪੀ ਰੱਖਦਾ ਹਾਂ ਤਾਂ ਮੈਂ ਵਧੇਰੇ ਵਿਸਤਾਰ ਵਿੱਚ ਵਿਆਖਿਆ ਕਰ ਸਕਦਾ ਹਾਂ), ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਸੀਂ ਪ੍ਰਦਰਸ਼ਨ ਅਨੁਸੂਚੀ ਵਿੱਚ ਕਿਸੇ ਰੁਕਾਵਟ ਦੇ ਡਿੱਗਣ ਦੇ ਜੋਖਮ ਤੋਂ ਬਿਨਾਂ, ਵਧੇਰੇ ਹਮਲਾਵਰ ਢੰਗ ਨਾਲ ਇਨਲਾਈਨ ਕਰ ਸਕਦੇ ਹੋ। ਉਨ੍ਹੀਂ ਦਿਨੀਂ, ਪੂਰੇ ਪੈਮਾਨੇ ਦੇ ਕੰਪਾਈਲਰਾਂ ਦਾ ਇੱਕ ਝੁੰਡ ਸੀ, ਜੋ ਬਾਬਲਾਂ ਅਤੇ ਸੀਟੀਆਂ ਨਾਲ ਲਟਕਿਆ ਹੋਇਆ ਸੀ, ਜਿਸ ਵਿੱਚ ਰਜਿਸਟਰ ਅਲੋਕਟਰ ਸਨ, ਪਰ ਕੋਈ ਹੋਰ ਅਜਿਹਾ ਨਹੀਂ ਕਰ ਸਕਦਾ ਸੀ।

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

ਰਜਿਸਟਰ ਐਲੋਕੇਸ਼ਨ ਅਤੇ ਮਲਟੀ-ਕੋਰ ਬਾਰੇ ਥੋੜ੍ਹਾ ਜਿਹਾ

ਵਲਾਦੀਮੀਰ: ਰਜਿਸਟਰ ਅਲਾਟਮੈਂਟ ਵਰਗੀਆਂ ਸਮੱਸਿਆਵਾਂ ਕਿਸੇ ਸਦੀਵੀ, ਬੇਅੰਤ ਵਿਸ਼ੇ ਵਾਂਗ ਜਾਪਦੀਆਂ ਹਨ। ਮੈਂ ਹੈਰਾਨ ਹਾਂ ਕਿ ਕੀ ਕਦੇ ਅਜਿਹਾ ਵਿਚਾਰ ਆਇਆ ਹੈ ਜੋ ਵਾਅਦਾ ਕਰਨ ਵਾਲਾ ਜਾਪਦਾ ਹੈ ਅਤੇ ਫਿਰ ਅਭਿਆਸ ਵਿੱਚ ਅਸਫਲ ਰਿਹਾ ਹੈ?

ਚੱਟਾਨ: ਯਕੀਨਨ! ਰਜਿਸਟਰ ਐਲੋਕੇਸ਼ਨ ਇੱਕ ਅਜਿਹਾ ਖੇਤਰ ਹੈ ਜਿਸ ਵਿੱਚ ਤੁਸੀਂ ਇੱਕ NP-ਮੁਕੰਮਲ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਕੁਝ ਖੋਜ ਖੋਜਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹੋ। ਅਤੇ ਤੁਸੀਂ ਕਦੇ ਵੀ ਇੱਕ ਸੰਪੂਰਨ ਹੱਲ ਪ੍ਰਾਪਤ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਠੀਕ ਹੈ? ਇਹ ਸਿਰਫ਼ ਅਸੰਭਵ ਹੈ. ਦੇਖੋ, ਸਮੇਂ ਦੇ ਸੰਕਲਨ ਤੋਂ ਅੱਗੇ - ਇਹ ਵੀ ਮਾੜਾ ਕੰਮ ਕਰਦਾ ਹੈ. ਇੱਥੇ ਗੱਲਬਾਤ ਕੁਝ ਔਸਤ ਮਾਮਲਿਆਂ ਬਾਰੇ ਹੈ। ਆਮ ਪ੍ਰਦਰਸ਼ਨ ਬਾਰੇ, ਤਾਂ ਜੋ ਤੁਸੀਂ ਜਾ ਕੇ ਉਸ ਚੀਜ਼ ਨੂੰ ਮਾਪ ਸਕੋ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਚੰਗੀ ਆਮ ਕਾਰਗੁਜ਼ਾਰੀ ਸਮਝਦੇ ਹੋ - ਆਖਰਕਾਰ, ਤੁਸੀਂ ਇਸਨੂੰ ਸੁਧਾਰਨ ਲਈ ਕੰਮ ਕਰ ਰਹੇ ਹੋ! ਰਜਿਸਟਰ ਐਲੋਕੇਸ਼ਨ ਪ੍ਰਦਰਸ਼ਨ ਦੇ ਬਾਰੇ ਵਿੱਚ ਇੱਕ ਵਿਸ਼ਾ ਹੈ। ਇੱਕ ਵਾਰ ਜਦੋਂ ਤੁਹਾਡੇ ਕੋਲ ਪਹਿਲਾ ਪ੍ਰੋਟੋਟਾਈਪ ਹੁੰਦਾ ਹੈ, ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਪੇਂਟ ਕਰਦਾ ਹੈ ਜੋ ਲੋੜੀਂਦਾ ਹੈ, ਪ੍ਰਦਰਸ਼ਨ ਦਾ ਕੰਮ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ। ਤੁਹਾਨੂੰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਮਾਪਣ ਲਈ ਸਿੱਖਣ ਦੀ ਲੋੜ ਹੈ. ਇਹ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹੈ? ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਸਪਸ਼ਟ ਡੇਟਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਵੱਖ-ਵੱਖ ਖੇਤਰਾਂ ਨੂੰ ਦੇਖ ਸਕਦੇ ਹੋ ਅਤੇ ਦੇਖ ਸਕਦੇ ਹੋ: ਹਾਂ, ਇਸਨੇ ਇੱਥੇ ਮਦਦ ਕੀਤੀ, ਪਰ ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਸਭ ਕੁਝ ਟੁੱਟ ਗਿਆ! ਕੁਝ ਚੰਗੇ ਵਿਚਾਰ ਆਉਂਦੇ ਹਨ, ਤੁਸੀਂ ਨਵੇਂ ਖੋਜਾਂ ਨੂੰ ਜੋੜਦੇ ਹੋ ਅਤੇ ਅਚਾਨਕ ਸਭ ਕੁਝ ਔਸਤਨ ਥੋੜਾ ਬਿਹਤਰ ਕੰਮ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦਾ ਹੈ. ਜਾਂ ਇਹ ਸ਼ੁਰੂ ਨਹੀਂ ਹੁੰਦਾ. ਮੇਰੇ ਕੋਲ ਬਹੁਤ ਸਾਰੇ ਕੇਸ ਸਨ ਜਿੱਥੇ ਅਸੀਂ ਪੰਜ ਪ੍ਰਤੀਸ਼ਤ ਪ੍ਰਦਰਸ਼ਨ ਲਈ ਲੜ ਰਹੇ ਸੀ ਜੋ ਸਾਡੇ ਵਿਕਾਸ ਨੂੰ ਪਿਛਲੇ ਅਲੋਕਟਰ ਨਾਲੋਂ ਵੱਖਰਾ ਕਰਦਾ ਸੀ। ਅਤੇ ਹਰ ਵਾਰ ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ: ਕਿਤੇ ਤੁਸੀਂ ਜਿੱਤ ਜਾਂਦੇ ਹੋ, ਕਿਤੇ ਤੁਸੀਂ ਹਾਰ ਜਾਂਦੇ ਹੋ. ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਚੰਗੇ ਪ੍ਰਦਰਸ਼ਨ ਵਿਸ਼ਲੇਸ਼ਣ ਟੂਲ ਹਨ, ਤਾਂ ਤੁਸੀਂ ਗੁਆਚਣ ਵਾਲੇ ਵਿਚਾਰਾਂ ਨੂੰ ਲੱਭ ਸਕਦੇ ਹੋ ਅਤੇ ਸਮਝ ਸਕਦੇ ਹੋ ਕਿ ਉਹ ਅਸਫਲ ਕਿਉਂ ਹੁੰਦੇ ਹਨ। ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਇਹ ਸਭ ਕੁਝ ਇਸ ਤਰ੍ਹਾਂ ਛੱਡਣ ਦੇ ਯੋਗ ਹੈ, ਜਾਂ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਫਾਈਨ-ਟਿਊਨਿੰਗ ਲਈ ਵਧੇਰੇ ਗੰਭੀਰ ਪਹੁੰਚ ਅਪਣਾਉਣ, ਜਾਂ ਬਾਹਰ ਜਾ ਕੇ ਕਿਸੇ ਹੋਰ ਚੀਜ਼ ਨੂੰ ਠੀਕ ਕਰਨਾ. ਇਹ ਚੀਜ਼ਾਂ ਦਾ ਪੂਰਾ ਝੁੰਡ ਹੈ! ਮੈਂ ਇਹ ਸ਼ਾਨਦਾਰ ਹੈਕ ਬਣਾਇਆ ਹੈ, ਪਰ ਮੈਨੂੰ ਇਸ ਦੀ ਵੀ ਲੋੜ ਹੈ, ਅਤੇ ਇਹ ਇੱਕ, ਅਤੇ ਇਹ ਇੱਕ - ਅਤੇ ਉਹਨਾਂ ਦਾ ਕੁੱਲ ਸੁਮੇਲ ਕੁਝ ਸੁਧਾਰ ਦਿੰਦਾ ਹੈ। ਅਤੇ ਇਕੱਲੇ ਫੇਲ ਹੋ ਸਕਦੇ ਹਨ। ਇਹ NP-ਪੂਰੀ ਸਮੱਸਿਆਵਾਂ 'ਤੇ ਪ੍ਰਦਰਸ਼ਨ ਦੇ ਕੰਮ ਦੀ ਪ੍ਰਕਿਰਤੀ ਹੈ।

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

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

ਵਲਾਦੀਮੀਰ: ਤੁਸੀਂ ਮਲਟੀ-ਕੋਰ ਬਾਰੇ ਕੀ ਸੋਚਦੇ ਹੋ, ਜਦੋਂ ਇੱਕੋ ਸਮੇਂ ਹਜ਼ਾਰਾਂ ਕੋਰ ਹੁੰਦੇ ਹਨ? ਕੀ ਇਹ ਇੱਕ ਲਾਭਦਾਇਕ ਚੀਜ਼ ਹੈ?

ਚੱਟਾਨ: GPU ਦੀ ਸਫਲਤਾ ਦਰਸਾਉਂਦੀ ਹੈ ਕਿ ਇਹ ਕਾਫ਼ੀ ਉਪਯੋਗੀ ਹੈ!

ਵਲਾਦੀਮੀਰ: ਉਹ ਕਾਫ਼ੀ ਵਿਸ਼ੇਸ਼ ਹਨ. ਆਮ ਉਦੇਸ਼ ਪ੍ਰੋਸੈਸਰਾਂ ਬਾਰੇ ਕੀ?

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

ਜ਼ਿੰਦਗੀ ਦੀ ਸਭ ਤੋਂ ਵੱਡੀ ਚੁਣੌਤੀ

ਵਲਾਦੀਮੀਰ: ਗੈਰ-ਤਕਨੀਕੀ ਚੁਣੌਤੀਆਂ ਬਾਰੇ ਕੀ?

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

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

ਆਂਦਰੇਈ: ਹੁਣੇ ਹੁਣੇ ਹਰ ਕਿਸੇ ਨੇ ਅੰਦਰੂਨੀ ਲੋਕਾਂ ਲਈ ਸਵੈ-ਜਾਗਰੂਕਤਾ, ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਨਰਮ ਹੁਨਰ ਬਾਰੇ ਗੱਲ ਕਰਨੀ ਸ਼ੁਰੂ ਕੀਤੀ ਹੈ। ਤੁਸੀਂ ਇਸ ਬਾਰੇ ਕੀ ਕਹਿ ਸਕਦੇ ਹੋ?

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

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

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

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

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

ਸਰੋਤ: www.habr.com