Intel, x86 ਦਾ ਪ੍ਰਭਾਅ ਅਤੇ ਪਲੇਟਫਾਰਮ ਬਦਲਣਾ ਕਿਉਂ ਮੁਸ਼ਕਲ ਹੈ

ਇਸ ਪੋਸਟ ਵਿੱਚ x86 ਪ੍ਰਭਾਵ ਦਾ ਕੀ ਮਤਲਬ ਹੈ

ਜਦ ਲੋਕ 'x86' ਕਹਿੰਦੇ ਹਨ, ਉਹ ਆਮ ਤੌਰ 'ਤੇ CPU ਹੁਕਮਾਂ ਦੇ ਉਹ ਪਰਿਵਾਰ ਮੰਨਦੇ ਹਨ ਜੋ Intel ਦੇ 8086 ਚਿਪ ਨਾਲ ਸ਼ੁਰੂ ਹੋਏ ਅਤੇ ਦਹਾਕਿਆਂ ਵਿੱਚ ਵਿਕਸਿਤ ਹੋਏ। ਇਹ ਹੁਕਮ ਉਹ ਮੂਲ ਕਿਰਿਆਵਾਂ ਹਨ ਜੋ ਇੱਕ ਪ੍ਰੋਸੈਸਰ ਸਮਝਦਾ ਹੈ—ਜੋੜਨਾ, ਤੁਲਨਾ ਕਰਨਾ, ਡੈਟਾ ਹਿਲਾਉਣਾ, ਆਦਿ। ਇਸ instruction set ਨੂੰ ISA (instruction set architecture) ਕਿਹਾ ਜਾਂਦਾ ਹੈ। ਤੁਸੀਂ ISA ਨੂੰ ਉਸ "ਭਾਸ਼ਾ" ਵਜੋਂ ਸੋਚ ਸਕਦੇ ਹੋ ਜੋ ਸਾਫਟਵੇਅਰ ਨੂੰ ਕਿਸੇ ਖ਼ਾਸ CPU 'ਤੇ ਚਲਣ ਲਈ ਆਖ਼ਰੀ ਤੌਰ 'ਤੇ ਬੋਲਣੀ ਪੈਂਦੀ ਹੈ.

ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਪਰਿਭਾਸ਼ਾਵਾਂ

x86: ਪਿਛਲੇ ਤਕਰੀਬਨ 40 ਸਾਲਾਂ ਵਿਚ PCs ਵਿੱਚ ਸਭ ਤੋਂ ਆਮ ISA, ਮੁੱਖ ਤੌਰ 'ਤੇ Intel ਅਤੇ AMD ਵੱਲੋਂ ਲਾਗੂ ਕੀਤਾ ਗਿਆ।

ਬੈਕਵਰਡ ਕੰਪੈਟਿਬਿਲਟੀ: ਨਵੀਂ ਮਸ਼ੀਨਾਂ ਦੀ ਯੋਜਨਾ ਇਹ ਯੋਗਤਾ ਰੱਖਦੀ ਹੈ ਕਿ ਪੁਰਾਣਾ ਸਾਫਟਵੇਅਰ (ਕਈ ਵਾਰੀ ਦਹਾਕਿਆਂ ਪੁਰਾਣੇ ਪ੍ਰੋਗਰਾਮ ਵੀ) ਵੱਡੇ ਪੂਨਰਲਿਖਤਾਂ ਦੀ ਲੋੜ ਬਿਨਾਂ ਚੱਲਦਾ ਰਹੇ। ਹਰ ਹੱਲੇ-ਮੁਕੰਮਲ ਤਰੀਕੇ ਨਾਲ ਨਹੀਂ, ਪਰ ਇਹ PC ਦੁਨੀਆਂ ਦੀ ਇੱਕ ਮੁੱਖ ਉਮੀਦ ਬਣ ਗਈ: “ਤੁਹਾਡੀ ਚੀਜ਼ਾਂ ਹੋਰ ਵੀ ਕੰਮ ਕਰਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ।”

ਇਸ ਪੋਸਟ ਵਿੱਚ "ਪ੍ਰਭਾਅ" ਦਾ ਕੀ ਅਰਥ ਹੈ

"ਪ੍ਰਭਾਅ" ਸਿਰਫ ਪ੍ਰਦਰਸ਼ਨ ਦੀ ਦਾਅਵਾ ਨਹੀਂ; ਇਹ ਕਈ ਪੱਖਾਂ 'ਤੇ ਇੱਕ ਪ੍ਰਯੋਗਿਕ, ਜੁੜਦਾ ਹੋਇਆ ਫਾਇਦਾ ਹੈ:

• ਵਾਲਿਊਮ: ਡੈਸਕਟਾਪ, ਲੈਪਟਾਪ ਅਤੇ ਸਰਵਰਾਂ ਵਿੱਚ ਵੱਡੀ ਸੰਖਿਆ ਵਿੱਚ x86 ਚਿਪ ਭੇਜੇ ਗਏ।
• ਸਾਫਟਵੇਅਰ ਸਹਿਯੋਗ: ਐਪਸ, ਗੇਮਾਂ, ਐਂਟਰਪ੍ਰਾਈਜ਼ ਸਾਫਟਵੇਅਰ ਅਤੇ ਡਿਵੈਲਪਰ ਟੂਲਜ਼ ਦਾ ਸਭ ਤੋਂ ਵੱਡਾ ਕੈਟਾਲੌਗ ਜੋ ਪਹਿਲਾਂ (ਜਾਂ ਸਭ ਤੋਂ ਵਧੀਆ) x86 ਲਈ ਬਣਿਆ।
• ਮਾਇਡਸ਼ੇਅਰ: ਖਰੀਦਦਾਰਾਂ, IT ਵਿਭਾਗਾਂ ਅਤੇ ਡਿਵੈਲਪਰਾਂ ਦੀ ਮਾਨਤਾ ਕਿ "ਆਮ ਕੰਪਿਊਟਰ" ਆਮ ਤੌਰ 'ਤੇ x86 ਹੁੰਦਾ ਹੈ ਜਦ ਤੱਕ ਦੱਸਿਆ ਨਾ ਜਾਵੇ।

ਇਹ ਮਿਲਾਪ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਹਰ ਪਰਤ ਦੂਜੀ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦੀ ਹੈ। ਵੱਧ ਮਸ਼ੀਨਾਂ ਵੱਧ ਸਾਫਟਵੇਅਰ ਨੂੰ ਪ੍ਰੇਰਿਤ ਕਰਦੀਆਂ ਹਨ; ਵੱਧ ਸਾਫਟਵੇਅਰ ਵੱਧ ਮਸ਼ੀਨਾਂ ਨੂੰ ਅਪੀਲ ਕਰਦਾ ਹੈ।

ਪਲੇਟਫਾਰਮ ਬਦਲਣਾ ਕਿਉਂ ਮੁਸ਼ਕਲ ਹੁੰਦਾ ਹੈ (ਸਾਰ)

ਰਾਜਮਦਾ ISA ਨੂੰ ਬਦਲਣਾ ਸਿਰਫ਼ ਇੱਕ ਹਿੱਸਾ ਬਦਲਣ ਵਰਗਾ ਨਹੀਂ ਹੈ। ਇਹ ਐਪਲੀਕੇਸ਼ਨਾਂ, ਡ੍ਰਾਈਵਰਾਂ (ਪਰਿੰਟਰ, GPU, ਆਡੀਓ ਡਿਵਾਈਸز, ਨਿਸ਼ ਪੈਰੀਫੇਰਲ), ਡਿਵੈਲਪਰ ਟੂਲਚੇਨ ਅਤੇ ਦਿਨ-ਚੜ੍ਹਦੀ ਆਦਤਾਂ (ਇਮੇਜਿੰਗ ਪ੍ਰਕਿਰਿਆਵਾਂ, IT ਸਕ੍ਰਿਪਟਾਂ, ਸੁਰੱਖਿਆ ਏਜੈਂਟ, ਡਿਪਲੋਯਮੈਂਟ ਪਾਈਪਲਾਈਨ) ਨੂੰ ਟੋਰ-ਟੋਰ ਪ੍ਰਭਾਵਤ ਕਰ ਸਕਦਾ ਹੈ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਬਹੁਤ ਤੋਂ Dependencies ਅਪਰਾਖੀਤ ਰਹਿੰਦੇ ਹਨ ਜਦ ਤੱਕ ਕੁਝ ਗਲਤ ਨਹੀਂ ਹੁੰਦਾ।

ਚਰਚਾ ਦਾ ਦਾਇਰਾ

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

ਕਿਵੇਂ PC ਯੁੱਗ ਨੇ x86 ਲਈ ਮੌਕਾ ਪੈਦਾ ਕੀਤਾ

ਸ਼ੁਰੂਆਤੀ PC ਬਜ਼ਾਰ ਕਿਸੇ ਮਹਾਨ ਆਰਕੀਟੈਕਚਰਿਕ ਯੋਜਨਾ ਨਾਲ ਸ਼ੁਰੂ ਨਹੀਂ ਹੋਇਆ—ਇਹ ਵਿਅਵਹਾਰਕ ਬੰਧਨਾਂ ਨਾਲ ਸ਼ੁਰੂ ਹੋਇਆ। ਕਾਰੋਬਾਰ ਸਸਤੇ, ਵੋਲਿਊਮ ਵਿੱਚ ਉਪਲਬਧ ਅਤੇ ਆਸਾਨੀ ਨਾਲ ਸੇਵਾ ਯੋਗ ਮਸ਼ੀਨਾਂ ਚਾਹੁੰਦੇ ਸਨ। ਇਹ ਵਿਕਰੇਤਿਆਂ ਨੂੰ ਉਹ CPU ਅਤੇ ਪартਸ ਚੁਣਨ ਵੱਲ ਧਕਾ ਦਿੰਦਾ ਗਿਆ ਜੋ ਭਰੋਸੇਯੋਗ ਸਰੋਤ ਤੋਂ ਮਿਲ ਸਕਦੇ, ਸਧਾਰਨ ਪੈਰੀਫੇਰਲ ਨਾਲ ਜੋੜੇ ਜਾ ਸਕਦੇ, ਅਤੇ ਨਿਰਧਾਰਿਤ ਸੋਫਟਵੇਅਰ ਸਟੈਕ ਨਾਲ ਸਿਸਟਮ ਤਿਆਰ ਕੀਤਾ ਜਾ ਸਕਦਾ।

ਸਸਤੇ CPU + ਸਟੈਂਡਰਡ ਕੰਪੋਨੈਂਟ

IBM ਦੀ ਅਸਲ PC ਡਿਜ਼ਾਈਨ ਨੇ ਅਕਸਰ ਛੇਤੀ ਮਿਲਣ ਵਾਲੇ ਹਿੱਸਿਆਂ ਅਤੇ ਤਨਖਾਹ Intel 8088-ਕਲਾਸ ਪ੍ਰੋਸੈਸਰ 'ਤੇ ਨਿਰਭਰਤਾ ਦਿਖਾਈ। ਇਹ ਚੋਣ ਮਹੱਤਵਪੂਰਨ ਸੀ ਕਿਉਂਕਿ ਇਸ ਨਾਲ "PC" ਇੱਕ ਇਕੱਲੇ ਉਤਪਾਦ ਦੀ ਭਾਂਤੀ ਨਹੀਂ ਲੱਗਿਆ ਬਲਕਿ ਇੱਕ ਨੁਸਖੇ ਵਾਂਗ ਬਣ ਗਿਆ: ਇੱਕ CPU ਪਰਿਵਾਰ, ਵਿਸਥਾਰ ਸਲਾਟਾਂ ਦਾ ਸੈੱਟ, ਕੀਬੋਰਡ/ਡਿਸਪਲੇਅ ਦਿਸ਼ਾ ਅਤੇ ਇੱਕ ਸਾਫਟਵੇਅਰ ਸਟੈਕ ਜੋ ਦੁਹਰਾਇਆ ਜਾ ਸਕਦਾ ਸੀ।

ਕਲੋਨਜ਼, ਸਕੈਂਡ-ਸੋਰਸ ਅਤੇ ਵੱਡਾ ਬਜ਼ਾਰ

ਜਿਵੇਂ ਹੀ IBM PC ਨੇ ਮੰਗ ਪ੍ਰਮਾਣਤ ਕੀਤੀ, ਬਜ਼ਾਰ ਕਲੋਨਿੰਗ ਰਾਹੀਂ ਵਧਿਆ। Compaq ਵਰਗੀਆਂ ਕੰਪਨੀਆਂ ਨੇ ਦਿਖਾਇਆ ਕਿ ਤੁਸੀਂ ਉਹੀ ਸਾਫਟਵੇਅਰ ਚਲਾਉਂਦੀਆਂ ਮਸ਼ੀਨਾਂ ਬਣਾਈਆਂ ਜਾਣਗੀਆਂ—ਅਤੇ ਵੱਖ-ਵੱਖ ਕੀਮਤਾਂ 'ਤੇ ਵੇਚ ਸਕਦੇ ਹੋ।

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

"ਇਹ ਉਹੀ ਪ੍ਰੋਗਰਾਮ ਚਲਾਉਂਦਾ ਹੈ" ਖਰੀਦਣ ਦਾ ਨਿਯਮ ਬਣਿਆ

ਇਸ ਵਾਤਾਵਰਣ ਵਿੱਚ, ਅਨੁਕੂਲਤਾ ਉਹ ਫੀਚਰ ਬਣ ਗਈ ਜਿਸ ਨੂੰ ਲੋਕ ਸਮਝਦੇ ਅਤੇ ਮੋਲ ਦਿੰਦੇ ਸਨ। ਖਰੀਦਦਾਰਾਂ ਨੂੰ ਇਹ ਪਤਾ ਹੋਣ ਦੀ ਜ਼ਰੂਰਤ ਨਹੀਂ ਸੀ ਕਿ ISA ਕੀ ਹੈ; ਉਹ ਸਿਰਫ ਇਹ ਜਾਣਦੇ ਸਨ ਕਿ Lotus 1-2-3 (ਅਤੇ بعد ਵਿੱਚ Windows ਐਪਸ) ਚਲਣਗੇ ਜਾਂ ਨਹੀਂ।

ਸਾਫਟਵੇਅਰ ਉਪਲਬਧਤਾ ਜਲਦੀ ਹੀ ਖਰੀਦਦਾਰੀ ਲਈ ਆਸਾਨ ਨਿਯਮ ਬਣ ਗਈ: ਜੇ ਇਹ ਹੋਰ PCs ਵਰਗੇ ਹੀ ਪ੍ਰੋਗਰਾਮ ਚਲਾਉਂਦਾ ਹੈ, ਤਾਂ ਇਹ ਇਕ ਸੁਰੱਖਿਅਤ ਚੋਣ ਹੈ।

ਮਿਆਰੀਕਰਨ ਨੇ ਚੁਪਚਾਪ ਗਤੀ ਮਿਲਾਈ

ਹਾਰਡਵੇਅਰ ਅਤੇ ਫਰਮਵੇਅਰ ਰਿਵਾਜਾਂ ਨੇ ਬਹੁਤ ਅਦ੍ਰਿੱਸ਼ਯ ਕੰਮ ਕੀਤੇ। ਸਾਂਝੇ ਬੱਸ ਅਤੇ ਵਿਸਥਾਰ ਪਹੁੰਚਾਂ—ਨਾਲ-ਨਾਲ BIOS/ਫਰਮਵੇਅਰ ਉਮੀਦਾਂ ਅਤੇ ਸਾਂਝੇ ਸਿਸਟਮ ਵਿਵਹਾਰ—ਨੇ ਹਾਰਡਵੇਅਰ ਨਿਰਮਾਤਿਆਂ ਅਤੇ ਸਾਫਟਵੇਅਰ ਵਿਕਾਸਕਾਰਾਂ ਲਈ "PC" ਨੂੰ ਇੱਕ ਸਥਿਰ ਪਲੇਟਫਾਰਮ ਨਿਸ਼ਾਨ ਬਣਾਉਣ ਆਸਾਨ ਕੀਤਾ।

ਉਸ ਸਥਿਰਤਾ ਨੇ x86 ਨੂੰ ਇੱਕ ਵਧ ਰਹੇ ਇਕੋਸਿਸਟਮ ਦੇ ਅਧਾਰ ਵਜੋਂ ਪੱਕਾ ਕੀਤਾ।

ਸਾਫਟਵੇਅਰ ਇਕੋਸਿਸਟਮ ਫਲਾਈਵੀਲ

x86 ਸਿਰਫ ਕਲਾਕ ਸਪੀਡ ਜਾਂ ਚਿੱਟੜੇ ਚਿਪਾਂ ਕਰਕੇ ਨਹੀਂ ਜਿੱਤਿਆ। ਇਹ ਜਿੱਤਿਆ ਕਿਉਂਕਿ ਸਾਫਟਵੇਅਰ ਉਪਭੋਗਤਿਆਂ ਦੇ ਪਿੱਛੇ ਗਿਆ, ਅਤੇ ਉਪਭੋਗਤਾ ਸਾਫਟਵੇਅਰ ਦੇ ਪਿੱਛੇ। ਇਹ ਇੱਕ ਆਰਥਿਕ "ਨੈਟਵਰਕ ਪ੍ਰਭਾਵ" ਹੈ ਜੋ ਸਮੇਂ دے ਨਾਲ ਵੱਧਦਾ ਹੈ।

ਨੈਟਵਰਕ ਪ੍ਰਭਾਵ: ਵੱਧ ਉਪਭੋਗੀ → ਵੱਧ ਐਪ → ਵੱਧ ਉਪਭੋਗੀ

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

ਇਸ ਲੂਪ ਨੂੰ ਸਾਲਾਂ ਤੱਕ ਦੁਹਰਾਓ ਅਤੇ "ਡਿਫਾਲਟ" ਪਲੇਟਫਾਰਮ ਨੂੰ ਇਹਨਾ ਮੁਸ਼ਕਲ ਬਣ ਜਾਂਦਾ ਹੈ ਕਿ ਇਸਨੂੰ ਬਦਲਣਾ ਔਖਾ ਹੋ ਜਾਂਦਾ ਹੈ—ਭਾਵੇਂ ਵਿਕਲਪ ਤਕਨੀਕੀ ਰੂਪ ਵਿੱਚ ਆਕਰਸ਼ਕ ਹੋਣ।

ਇਸੇ ਲਈ ਪਲੇਟਫਾਰਮ ਬਦਲਣਾ ਸਿਰਫ CPU ਬਣਾਉਣ ਬਾਰੇ ਨਹੀਂ; ਇਹ ਪੂਰੇ ਇਕੋਸਿਸਟਮ ਨੂੰ ਦੁਬਾਰਾ ਬਣਾਉਣ ਬਾਰੇ ਹੈ: ਐਪਸ, ਇੰਸਟਾਲਰ, ਅਪਡੇਟ ਚੈਨਲ, ਪੈਰੀਫੇਰਲ, IT ਪ੍ਰਕਿਰਿਆਵਾਂ, ਅਤੇ ਮਿਲੀਅੰਜ਼ ਦੀ ਸਾਂਝੀ ਜਾਣਕਾਰੀ।

ਕਾਰੋਬਾਰਾਂ ਨੇ ਸਥਿਰ ਪਲੇਟਫਾਰਮਾਂ ਨੂੰ ਕਿਉਂ ਤਰਜੀਹ ਦਿੱਤੀ

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

• ਪੇਸ਼ਗੋਈਯੋਗ ਅੱਪਗਰੇਡ (ਨਵੇਂ PCs ਅਜੇ ਵੀ ਪੁਰਾਣੇ ਸਾਫਟਵੇਅਰ ਚਲਾਉਂਦੇ ਹਨ)
• ਲੰਮੇ ਹਾਰਡਵੇਅਰ ਲਾਈਫਸਾਈਕਲ
• ਹੇਲਪ ਡੈਸਕ ਅਤੇ ਟ੍ਰੇਨਿੰਗ ਬਜਟ ਲਈ ਘੱਟ ਯਕੀਨਨ

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

ਡਿਵੈਲਪਰ ਪ੍ਰਾਥਮਿਕਤਾਵਾਂ ਰੂਪ-ਸਥਿਤ ਬੇਸ ਅਤੇ ਸਹਿਯੋਗ ਲਾਗਤਾਂ ਦੇ ਪਿੱਛੇ ਫੋਲੋ ਕਰਦੀਆਂ ਹਨ

ਡਿਵੈਲਪਰ ਅਕਸਰ ਖਾਲੀ ਝੰਡੇ ਲਈ "ਸਰਵੇਸ਼੍ਰੇଷਠ" ਪਲੇਟਫਾਰਮ 'ਤੇ ਅਭਿਆਸ ਨਹੀਂ ਕਰਦੇ। ਉਹ ਉਸ ਪਲੇਟਫਾਰਮ ਲਈ ਅਭਿਆਸ ਕਰਦੇ ਹਨ ਜੋ ਸਹਿਯੋਗ ਭਾਰ ਘਟਾਓ ਅਤੇ ਪਹੁੰਚ ਵਧਾਓ।

ਜੇ ਤੁਹਾਡੇ 90% ਗਾਹਕ x86 Windows 'ਤੇ ਹਨ, ਉਹੀ ਥਾਂ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਪਹਿਲਾਂ ਟੈਸਟ ਕਰਦੇ ਹੋ, ਪਹਿਲਾਂ ਸ਼ਿਪ ਕਰਦੇ ਹੋ, ਅਤੇ ਸਭ ਤੋਂ ਤੇਜ਼ੀ ਨਾਲ ਬੱਗ ਫਿਕਸ ਕਰਦੇ ਹੋ। ਦੂਜੇ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਸਮਰਥਨ ਦੇਣ ਦੇ ਮਤਲਬ ਵੱਧ ਬਿਲਡ ਪਾਈਪਲਾਈਨ, ਵੱਧ QA, ਅਤੇ ਵੱਧ ਸਪੋਰਟ ਟਿਕਟ—ਜੋ ਬਹੁਤਾਂ ਦੀਆਂ ਟੀਮਾਂ ਲਈ ਇਕ ਭਾਰ ਹੈ।

ਨਤੀਜਾ ਇੱਕ ਆਪਸੀ-ਪੁਸ਼ਟੀ ਕਰਨ ਵਾਲਾ ਫ਼ਰਕ ਹੈ: ਆਗੂ ਪਲੇਟਫਾਰਮ ਨੂੰ ਅਕਸਰ ਤੇਜ਼ ਤੇ ਵਧੀਆ ਸਾਫਟਵੇਅਰ ਮਿਲਦਾ ਹੈ।

ਇੱਕ ਸਧਾਰਣ ਉਦਾਹਰਨ: ਅਕਾਊਂਟਿੰਗ ਸਾਫਟਵੇਅਰ ਅਤੇ ਪ੍ਰਿੰਟਰ ਡ੍ਰਾਈਵਰ

ਇੱਕ ਛੋਟੇ ਕਾਰੋਬਾਰ ਦੀ ਤਸਵੀਰ ਕਰੋ। ਉਹਨਾਂ ਦਾ ਅਕਾਊਂਟਿੰਗ ਪੈਕੇਜ x86-ਕੇਵਲ ਹੈ, ਇੱਕ ਦਹਾਕੇ ਦੀ ਟੈਮਪਲੇਟ ਲਾਇਬ੍ਰੇਰੀ ਨਾਲ ਅਤੇ ਪੇਰੋਲ ਲਈ ਇੱਕ ਪਲੱਗਇਨ ਨਾਲ ਇਕੂਠਾ। ਉਹ ਇੱਕ ਖਾਸ ਲੇਬਲ ਪ੍ਰਿੰਟਰ ਅਤੇ ਦਸਤਾਵੇਜ਼ ਸਕੈਨਰ ਤੇ ਵੀ ਨਿਰਭਰ ਹਨ ਜਿਨ੍ਹਾਂ ਦੇ ਡ੍ਰਾਈਵਰ ਖਾਸ ਹਨ।

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

ਏਹੀ ਫਲਾਈਵੀਲ ਹੈ: ਜਿੱਤੂ ਪਲੇਟਫਾਰਮ ਲੰਬੇ-ਪੂਛ ਦੀ ਅਨੁਕੂਲਤਾ ਅਕੰਸ਼ਿਤ ਕਰਦਾ ਹੈ ਜਿਸ 'ਤੇ ਹਰ ਕੋਈ ਚੁਪਚਾਪ ਨਿਰਭਰ ਹੁੰਦਾ ਹੈ।

ਬੈਕਵਰਡ ਕੰਪੈਟਿਬਿਲਟੀ ਇੱਕ ਪ੍ਰੋਡਕਟ ਰਣਨੀਤੀ ਵਜੋਂ

ਬੈਕਵਰਡ ਕੰਪੈਟਿਬਿਲਟੀ ਸਿਰਫ x86 ਦੀ ਇੱਕ ਵਧੀਆ ਵਿਸ਼ੇਸ਼ਤਾ ਨਹੀਂ ਰਹੀ—ਇਹ ਦਿਲਚਸਪੀ ਨਾਲ ਬਣਾਈ ਗਈ ਪ੍ਰੋਡਕਟ ਰਣਨੀਤੀ ਬਣ ਗਈ। Intel ਨੇ x86 ISA ਨੂੰ ਇਸਤਰਾ ਸਥਿਰ ਰੱਖਿਆ ਕਿ ਸਾਲਾਂ ਪਹਿਲਾਂ ਲਿਖਿਆ ਸਾਫਟਵੇਅਰ ਅਜੇ ਵੀ ਚੱਲ ਸਕੇ, ਜਦਕਿ ਹੇਠਾਂ ਵਾਲੀਆਂ ਚੀਜ਼ਾਂ ਨੂੰ ਬਦਲ ਦਿਤਾ ਗਿਆ।

ਮਾਈਕ੍ਰੋਆਰਕੀਟੈਕਚਰ ਵਿਕਸਤ ਹੁੰਦੀ ਹੈ; ISA ਮੁੱਖ ਤੌਰ 'ਤੇ ਥਾਂ 'ਤੇ ਰਹਿੰਦੀ ਹੈ

ਮੁੱਖ ਫਰਕ ਇਹ ਹੈ ਕਿ ਕੀ ਚੀਜ਼ ਅਨੁਕੂਲ ਰਹੀ। ISA ਉਹ ਮਸ਼ੀਨ ਹੁਕਮਾਂ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦੀ ਹੈ ਜਿਨ੍ਹਾਂ 'ਤੇ ਪ੍ਰੋਗਰਾਮ ਨਿਰਭਰ ਹੁੰਦੇ ਹਨ; ਮਾਈਕ੍ਰੋਆਰਕੀਟੈਕਚਰ ਉਹ ਹੈ ਕਿ ਇੱਕ ਚਿਪ ਉਹਨਾਂ ਨੂੰ ਕਿਵੇਂ ਚਲਾਉਂਦੀ ਹੈ।

Intel ਸਧਾਰਨ ਪਾਈਪਲਾਈਨਾਂ ਤੋਂ ਲੈ ਕੇ out-of-order ਇਕਜ਼ਿਕਿਊਸ਼ਨ, ਵੱਡੇ caches, ਬਿਹਤਰ branch prediction, ਜਾਂ ਨਵੇਂ ਫੈਬ੍ਰਿਕੇਸ਼ਨ ਪ੍ਰਕ੍ਰਿਆਵਾਂ ਤੱਕ ਜਾ ਸਕਦਾ ਸੀ—ਬਿਨਾਂ ਵਿਕਾਸਕਾਰਾਂ ਨੂੰ ਆਪਣੀਆਂ ਐਪਸ ਦੁਬਾਰਾ ਲਿਖਣ ਲਈ ਕਿਹਾ।

ਇਹ ਸਥਿਰਤਾ ਇੱਕ ਸ਼ਕਤੀਸ਼ਾਲੀ ਉਮੀਦ ਬਣਾਉਂਦੀ ਸੀ: ਨਵੇਂ PCs ਨੂੰ ਪਹਿਲੇ ਦਿਨ ਹੀ ਪੁਰਾਣਾ ਸੌਫਟਵੇਅਰ ਚਲਾਉਣਾ ਚਾਹੀਦਾ।

ਨਵੇਂ ਨਿਰਮਾਣ ਸ਼ਕਤੀਆਂ ਨੂੰ ਜੋੜਨਾ ਬਿਨਾਂ ਪੁਰਾਣੇ ਕੋਡ ਨੂੰ ਤੋੜੇ

x86 ਨੇ ਨਵੀਆਂ ਯੋਗਤਾਵਾਂ ਨੂੰ ਤਹਾਂ-ਤਹਾਂ ਜੋੜਿਆ। MMX, SSE, AVX ਵਰਗੀਆਂ instruction set ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਐਡੇਟਿਵ ਰਹੀਆਂ: ਪੁਰਾਣੇ ਬਾਈਨਰੀ ਅਜੇ ਵੀ ਕੰਮ ਕਰਦੇ, ਤੇ ਨਵੀਆਂ ਐਪਾਂ ਨਵੇਂ ਹੁਕਮਾਂ ਦੀ ਜਾਣਕਾਰੀ ਪ੍ਰਾਪਤ ਕਰਕੇ ਇਸਤੇਮਾਲ ਕਰ ਸਕਦੀਆਂ।

ਇeven major transitions were smoothed by compatibility mechanisms:

• ਲੈਗਸੀ ਮੋਡਸ ਜੋ ਪੁਰਾਣੇ execution environments ਨੂੰ ਬਚਾਉਂਦੇ ਹਨ (ਉਦਾਹਰਨ ਲਈ, ਬਾਅਦ ਦੇ ਪ੍ਰੋਸੈਸਰਾਂ ਵਿੱਚ 16-bit ਅਤੇ 32-bit ਕੰਪੈਟਿਬਿਲਟੀ)।
• ਪ੍ਰੋਟੈਕਟਡ ਅਤੇ ਲੰਬ ਮੋਡ ਡਿਜ਼ਾਈਨ ਜੋ ਮਾਡਰਨ OS ਨੂੰ ਵੱਧ ਮੈਮੋਰੀ ਅਤੇ ਸੁਰੱਖਿਆ ਫੀਚਰ ਵਰਤਣ ਦਿੰਦੇ ਹਨ ਜਦੋਂ ਕਿ ਪੁਰਾਣੇ ਐਪਸ ਨੂੰ ਸਹਾਰਾ ਮਿਲਦਾ ਰਹੇ।
• ਵਰਚੁਅਲਾਈਜ਼ੇਸ਼ਨ ਐਕਸਟੈਂਸ਼ਨ (ਜਿਵੇਂ Intel VT-x) ਜਿਨ੍ਹਾਂ ਨੇ ਪੁਰਾਣੇ OSes ਜਾਂ ਆਈਸੋਲੇਟਡ ਵਰਕਲੋਡ ਨੂੰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਤਰੀਕੇ ਨਾਲ ਚਲਾਉਣਾ ਆਸਾਨ ਕੀਤਾ।

ਟਰੇਡ-ਆਫ: ਲੈਗਸੀ ਇੱਕ ਬੰਧਨ ਬਣ ਜਾਂਦਾ ਹੈ

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

ਸਮਾਂ ਦੇ ਨਾਲ, "ਮੌਜੂਦਾ ਐਪ ਨੂੰ ਨਾ ਤੋੜੋ" ਇੱਕ ਦਿਸ਼ਾ-ਨਿਰਦੇਸ਼ ਤੋਂ ਰਣਨੀਤੀਿਕ ਪਾਬੰਦੀ ਬਣ ਜਾਂਦਾ ਹੈ: ਇਹ ਇੰਸਟਾਲਡ ਬੇਸ ਦੀ ਰੱਖਿਆ ਕਰਦਾ ਹੈ, ਪਰ ਇਹ ਵੀ ਨਵੇਂ ISA, ਨਵੇਂ ਸਿਸਟਮ ਡਿਜ਼ਾਈਨਾਂ, ਅਤੇ ਨਵੇਂ ਅਨੁਮਾਨਾਂ ਨੂੰ ਬਹੁਤ ਮੁਸ਼ਕਲ ਕਰ ਦਿੰਦਾ ਹੈ।

Wintel ਲੂਪ: OS, ਹਾਰਡਵੇਅਰ, ਅਤੇ OEM ਪ੍ਰੇਰਣਾਵਾਂ

"Wintel" ਸਿਰਫ Windows ਅਤੇ Intel ਚਿਪਾਂ ਲਈ ਇੱਕ ਚਟਕੀਲੇ ਨਾਂ ਨਹੀਂ ਸੀ। ਇਹ ਇੱਕ ਆਪਸੀ-ਪੁਸ਼ਟੀ ਕਰਨ ਵਾਲੇ ਲੂਪ ਦਾ ਵਰਣਨ ਕਰਦਾ ਸੀ ਜਿੱਥੇ ਪੀਸੀ ਉਦਯੋਗ ਦਾ ਹਰ ਹਿੱਸਾ ਇਕੋ ਡਿਫਾਲਟ ਟਾਰਗੇਟ 'ਤੇ ਟਿਕਣ ਤੋਂ ਲਾਭ ਵਿੱਚ ਸੀ: Windows on x86।

Windows + x86 ਕਿਉਂ ਡਿਫਾਲਟ ਐਪ ਟਾਰਗੇਟ ਬਣ ਗਿਆ

ਅਧਿਕਤਰ ਉਪਭੋਗਤਾ ਅਤੇ ਕਾਰੋਬਾਰੀ ਸਾਫਟਵੇਅਰ ਵਿਕਰੇਤਿਆਂ ਲਈ ਪ੍ਰਯੋਗਿਕ ਸਵਾਲ ਇਹ ਨਹੀਂ ਸੀ ਕਿ "कਿਹੜੀ ਆਰਕੀਟੈਕਚਰ ਸ਼੍ਰੇਸ਼ਠ ਹੈ?" ਸਗੋਂ "ਗਾਹਕ ਕਿੱਥੇ ਹਨ, ਅਤੇ ਸਹਾਇਤਾ ਕਾਲਾਂ ਕਿਵੇਂ ਹੋਣਗੀਆਂ?"।

Windows PCs ਘਰਾਂ, ਦਫਤਰਾਂ, ਅਤੇ ਸਕੂਲਾਂ ਵਿੱਚ ਵਿਸ਼ਾਲ ਤੌਰ 'ਤੇ ਤੈਅ ਹੋਏ ਹੋਏ ਸਨ, ਅਤੇ ਉਹ ਆਮ ਤੌਰ 'ਤੇ x86-ਅਧਾਰਤ ਸਨ। ਇਸ ਜੋੜੇ ਲਈ ਸ਼ਿਪ ਕਰਨਾ ਪਹੁੰਚ ਨੂੰ ਘੱਟ ਕਰਕੇ ਵੱਧ ਤੋਂ ਵੱਧ ਬਣਾਉਂਦਾ ਸੀ।

ਜਦ ਇੱਕ ਆਲੋਚਨਾਤਮਕ ਗਿਣਤੀ ਐਪਸ Windows + x86 'ਤੇ ਨਿਰਭਰ ਹੋ ਗਈ, ਨਵੇਂ ਖਰੀਦਦਾਰਾਂ ਕੋਲ ਇੱਕ ਹੋਰ ਕਾਰਨ ਸੀ ਇਸਨੂੰ ਚੁਣਨ ਦਾ: ਉਹਨਾਂ ਦੇ ਲਾਜ਼ਮੀ ਪ੍ਰੋਗਰਾਮ ਪਹਿਲਾਂ ਹੀ ਉੱਥੇ ਕੰਮ ਕਰਦੇ ਸਨ। ਇਸ ਨੇ ਆਗਲੇ ਤਹਲਦੇ ਵਿਕਾਸਕਾਰਾਂ ਲਈ ਪਲੇਟਫਾਰਮ ਨੂੰ ਹੋਰ ਆਕਰਸ਼ਕ ਬਣਾਇਆ।

OEMs, ਪੈਰੀਫੇਰਲ ਅਤੇ ਡ੍ਰਾਈਵਰ ਫਲਾਈਵੀਲ

PC ਨਿਰਮਾਤੇ (OEMs) ਤਦ ਜ਼ਿਆਦਾ ਕਾਮਯਾਬ ਹੁੰਦੇ ਹਨ ਜਦ ਉਹ ਬਹੁਤ ਸਾਰੇ ਮਾਡਲ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾ ਸਕਣ, ਕਈ ਸਪਲਾਇਰਾਂ ਤੋਂ ਕੰਪੋਨੈਂਟ ਲੈ ਸਕਣ, ਅਤੇ ਅਜਿਹੇ ਮਸ਼ੀਨਾਂ ਸ਼ਿਪ ਕਰ ਸਕਣ ਜੋ "ਸਿਰਫ਼ ਕੰਮ ਕਰਨ"। ਇੱਕ ਸਾਂਝਾ Windows + x86 ਬੇਸਲਾਈਨ ਇਸਨੂੰ ਸਹੂਲਤ-ਪੂਰਨ ਬਣਾਉਂਦਾ ਸੀ।

ਪੈਰੀਫੇਰਲ ਕੰਪਨੀਆਂ ਨੇ ਭੋਲਕੇ ਵਾਲਿਊਮ ਦਾ ਪਾਲਣ ਕੀਤਾ। ਜੇ ਜ਼ਿਆਦਾਤਰ ਖਰੀਦਦਾਰ Windows PCs ਵਰਤ ਰਹੇ ਸਨ, ਤਾਂ ਪ੍ਰਿੰਟਰ, ਸਕੈਨਰ, ਆਡੀਓ ਇੰਟਰਫੇਸ, Wi‑Fi ਚਿਪ, ਅਤੇ ਹੋਰ ਡਿਵਾਈਸ ਪਹਿਲਾਂ Windows ਡ੍ਰਾਈਵਰਾਂ ਨੂੰ ਤਰਜੀਹ ਦੇਣਗੇ। ਵਧੀਆ ਡ੍ਰਾਈਵਰ ਉਪਲਬਧਤਾ ਨੇ Windows PC ਅਨੁਭਵ ਨੂੰ ਸੁਧਾਰਿਆ, ਜਿਸ ਨੇ OEMs ਨੂੰ ਵੱਧ ਯੂਨਿਟ ਵੇਚਣ ਵਿੱਚ ਮਦਦ ਕੀਤੀ, ਜਿਸ ਨਾਲ ਵਾਲਿਊਮ ਉੱਚੀ ਰਹੀ।

ਖਰੀਦਦਾਰੀ ਦੀ ਹਕੀਕਤ: ਸਬ ਤੋਂ ਘੱਟ ਜੋਖਿਮ ਜਿੱਤਦਾ ਹੈ

ਕਾਰਪੋਰੇਟ ਅਤੇ ਸਰਕਾਰੀ ਖਰੀਦਦਾਰ ਅਕਸਰ ਪੇਸ਼ਗੋਈਯੋਗਤਾ ਨੂੰ ਇਨਾਮ ਦਿੰਦੇ ਹਨ: ਮੌਜੂਦਾ ਐਪਸ ਨਾਲ ਅਨੁਕੂਲਤਾ, ਸਹਾਇਤਾ ਲਾਗਤਾਂ ਦਾ ਪ੍ਰਬੰਧ, ਵੇਂਡਰ ਦੀਆਂ ਵਾਰੰਟੀ, ਅਤੇ ਪਰਖੀ ਗਈ ਡਿਪਲੋਯਮੈਂਟ ਟੂਲ।

ਭਾਵੇਂ ਵਿਕਲਪ ਆਕਰਸ਼ਕ ਹੋ, ਪਰ ਘੱਟ-ਖਤਰਾ ਚੋਣ ਅਕਸਰ ਜਿੱਤਦੀ ਹੈ ਕਿਉਂਕਿ ਇਹ ਟ੍ਰੇਨਿੰਗ ਘਟਾਉਂਦਾ, ਐਜ-ਕੇਸ ਫੇਲਿਆਂ ਤੋਂ ਬਚਾਅ ਕਰਦਾ, ਅਤੇ ਸਥਾਪਤ IT ਪ੍ਰਕਿਰਿਆਵਾਂ ਵਿੱਚ ਫਿੱਟ ਹੁੰਦੀ ਹੈ।

ਨਤੀਜਾ ਕੋਈ ਸਾਜ਼ਿਸ਼ ਨਹੀਂ ਸੀ; ਇਹ ਮਿਲੀ-ਮਿਲਾਈ ਪ੍ਰੇਰਣਾਵਾਂ ਦਾ ਖੇਤਰ ਸੀ—ਹਰ ਭਾਗ ਫ਼ੈਸਲਾ ਕਰ ਰਿਹਾ ਸੀ ਉਹ ਰਾਹ ਚੁਣੇ ਜੋ ਘੱਟ ਰੁਕਾਵਟ ਕਰੇ—ਜਿਸ ਨੇ ਐਸਾ ਗਤੀਸ਼ੀਲ ਬਣਾਇਆ ਕਿ ਪਲੇਟਫਾਰਮ ਬਦਲਣਾ ਬਹੁਤ ਮੁਸ਼ਕਲ ਹੋ ਗਿਆ।

ਇੱਕ ਪਲੇਟਫਾਰਮ ਬਦਲਣ ਦੌਰਾਨ ਅਸਲ ਵਿੱਚ ਕੀ ਤੋੜਦਾ ਹੈ

ਇੱਕ "ਪਲੇਟਫਾਰਮ ਟ੍ਰਾਂਜ਼ੀਸ਼ਨ" ਸਿਰਫ਼ ਇੱਕ CPU ਨੂੰ ਬਦਲਣ ਦੀ ਗੱਲ ਨਹੀਂ। ਇਹ ਇੱਕ ਗੁਠਲੀ ਚਲ ਹੈ: CPU ISA, ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ, ਕੰਪਾਇਲਰ/ਟੂਲਚੇਨ ਜੋ ਐਪ ਬਣਾਉਂਦਾ ਹੈ, ਅਤੇ ਡ੍ਰਾਈਵਰ ਸਟੈਕ ਜੋ ਹਾਰਡਵੇਅਰ ਨੂੰ ਕੰਮ ਕਰਾਉਂਦਾ ਹੈ। ਕਿਸੇ ਵੀ ਇਕ ਨੂੰ ਬਦਲੋ ਅਤੇ ਤੁਸੀਂ ਅਕਸਰ ਹੋਰਾਂ ਨੂੰ ਡਿਸਟर्ब ਕਰ ਦਿੰਦੇ ਹੋ।

ਉਹ ਲੁਕਵੇਂ ਨਿਰਭਰਤਾ ਜੋ ਤੁਸੀਂ ਤਦ ਦਿਖਦੇ ਹੋ ਜਦ ਓਹ ਨਾਹ ਚੱਲਣ

ਜ਼ਿਆਦਾਤਰ ਤੋੜ-ਛਾੜ ਨਾਟਕੀਆ ਨਹੀਂ ਹੁੰਦੀ "ਐਪ ਲਾਂਚ ਹੀ ਨਹੀਂ ਹੁੰਦਾ" ਵਾਲੀ; ਇਹ ਹਜ਼ਾਰਾਂ ਛੋਟੀ-ਛੋਟੀ ਸਮੱਸਿਆਵਾਂ ਹੁੰਦੀਆਂ ਹਨ:

• ਇੰਸਟਾਲਰ ਅਤੇ ਅਪਡੇਟਰ ਜੋ ਕਿਸੇ ਵਿਸ਼ੇਸ਼ Windows ਵਰਜ਼ਨ, ਰਜਿਸਟਰੀ ਲੇਅਆਊਟ, ਜਾਂ x86 ਰਨਟਾਈਮ ਦੀ ਉਮੀਦ ਕਰਦੇ ਹਨ।
• ਕਾਪੀ-ਸੁਰੱਖਿਆ ਅਤੇ ਲਾਇਸੰਸ ਮੈਨੇਜਰ ਜੋ ਖਾਸ ਹਾਰਡਵੇਅਰ ID, ਕਰਨਲ ਡ੍ਰਾਈਵਰ, ਜਾਂ ਨੀਚਲੇ-ਸਤਰ ਦੇ ਸਮੇਂ ਨਿਰਭਰ ਹਨ।
• ਪਲੱਗਇਨ, ਐਡ-ਇਨ, ਅਤੇ ਐਕਸਟੇੰਸ਼ਨ (CAD ਪਲੱਗਇਨ, ਆਡੀਓ VSTs, ਬ੍ਰਾਊਜ਼ਰ ਹਲਕਕ) ਜੋ ਇਕ ਆਰਕੀਟੈਕਚਰ ਲਈ ਕੰਪਾਇਲ ਕੀਤੇ ਗਏ।
• ਮੈਕਰੋ ਅਤੇ ਆਟੋਮੇਸ਼ਨ Office ਦਸਤਾਵੇਜ਼ਾਂ, ERP ਸਕ੍ਰੀਨਾਂ, ਜਾਂ ਘਰੇਲੂ ਬਣਾਏ ਸਕ੍ਰਿਪਟਾਂ ਵਿੱਚ ਜੋ ਸਥਿਰ ਫਾਈਲ ਪাথে, COM ਆਬਜੈਕਟ, ਜਾਂ ਡੀਪ੍ਰੇਕੇਟਡ APIs 'ਤੇ ਨਿਰਭਰ ਹੁੰਦੇ ਹਨ।

ਘਰਗੀਰ ਐਪ ਨੂੰ ਨਵਾਂ ਬਿਲਡ ਮਿਲੇ, ਪਰ ਉਸ ਦਾ ਗਿਰਦਾ "ਗਲੂ" ਸ਼ਾਇਦ ਨਾ ਮਿਲੇ।

ਪੈਰੀਫੇਰਲ: ਉਹ ਅਪਗਰੇਡ ਰੋਕਣ ਵਾਲਾ ਜੋ ਕੋਈ ਬਜਟ ਵਿੱਚ ਨਹੀਂ ਰੱਖਦਾ

ਪਰਿੰਟਰ, ਸਕੈਨਰ, ਲੇਬਲ ਮੇਕਰ, ਵਿਸ਼ੇਸ਼ PCIe/USB ਕਾਰਡ, ਮੈਡੀਕਲ ਡਿਵਾਈਸ, ਪੌਇੰਟ-ਆਫ-ਸੇਲ ਗੇਅਰ, ਅਤੇ USB ਡੋਂਗਲ ਡ੍ਰਾਈਵਰਾਂ 'ਤੇ ਜੀਵਨ ਅਤੇ ਮੌਤ ਨਿਰਭਰ ਕਰਦੇ ਹਨ। ਜੇ ਵੇਂਡਰ ਚਲਾ ਗਿਆ ਹੋਵੇ—ਜਾਂ ਸਿਰਫ਼ ਰੁਚੀ ਨਹੀਂ ਰੱਖਦਾ—ਤਾਂ ਨਵੇਂ OS ਜਾਂ ਆਰਕੀਟੈਕਚਰ ਲਈ ਡ੍ਰਾਈਵਰ ਨਾਂ ਹੋ ਸਕਦਾ।

ਅਕਸਰ ਇੱਕ $200 ਦਾ ਡਿਵਾਈਸ $2,000 PCs ਦੀ ਫਲੀਟ ਨੂੰ ਪੰਗੁ ਕਰ ਸਕਦਾ ਹੈ।

ਲੰਬੇ-ਪੂਛ ਸਾਫਟਵੇਅਰ ਸਮੱਸਿਆ

ਸਭ ਤੋਂ ਵੱਡਾ ਰੋਕ ਉਹ ਹੁੰਦਾ ਹੈ "ਛੋਟੇ" ਅੰਦਰੂਨੀ ਟੂਲ: ਇੱਕ ਕਸਟਮ Access ਡੇਟਾਬੇਸ, ਇੱਕ Excel ਮੈਕਰੋ ਵਰਕਬੁੱਕ, 2009 ਵਿੱਚ ਲਿਖਿਆ VB ਐਪ, ਤਿੰਨ ਲੋਕਾਂ ਵਲੋਂ ਵਰਤਿਆ ਇੱਕ ਨਿਸ਼ ਮੈਨੂਫੈਕਚਰਿੰਗ ਯੂਟਿਲਿਟੀ।

ਇਹ ਕਿਸੇ ਦੇ ਵੀ ਉਤਪਾਦ ਰੋਡਮੈਪ 'ਤੇ ਨਹੀਂ ਹੁੰਦੇ, ਪਰ ਇਹ ਮਿਸ਼ਨ-ਸ kritikal ਹੁੰਦੇ ਹਨ। ਜਦ ਲੰਬੇ-ਪੂਛ ਨੂੰ ਮਾਈਗ੍ਰੇਟ, ਟੈਸਟ ਅਤੇ ਕਿਸੇ ਵਿਅਕਤੀ ਨੇ ਢਕਿਆ ਨਾ ਹੋਵੇ ਤਾਂ ਟ੍ਰਾਂਜ਼ੀਸ਼ਨ ਫੇਲ ਹੋ ਜਾਂਦੀ ਹੈ।

ਸਵਿੱਚ ਕਰਨ ਦੀ ਅਸਲ ਆਰਥਿਕੀ

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

ਉਪਭੋਗਤਾ ਦਾ ਬਿੱਲ: ਸਮਾਂ, ਆਦਤਾਂ, ਅਤੇ "ਛੋਟੀਆਂ" ਟੁੱਟ-ਫੁੱਟ

ਉਪਭੋਗਤਿਆਂ ਲਈ ਸਵਿੱਚ ਦੀਆਂ ਲਾਗਤਾਂ ਮੁੱਖ (ਨਵੇਂ ਹਾਰਡਵੇਅਰ, ਨਵੇਂ ਪੈਰੀਫੇਰਲ, ਨਵੇਂ ਵਾਰੰਟੀ) ਤੋਂ ਸ਼ੁਰੂ ਹੁੰਦੀਆਂ ਅਤੇ ਫਿਰ ਗੰਦੀਆਂ ਚੀਜ਼ਾਂ ਵੱਲ ਵਧਦੀਆਂ ਹਨ: ਮਾਸਪੇਸ਼ੀ ਯਾਦ, ਵਰਕਫਲੋਜ਼ ਦੀ ਦੁਬਾਰਾ-ਕੰਫਿਗਰ, ਅਤੇ ਰੋਜ਼ਾਨਾ ਵਰਤੇ ਜਾਨ ਵਾਲੇ ਟੂਲਾਂ ਦੀ ਦੁਬਾਰਾ-ਪਰਖ।

ਭਾਵੇਂ ਇੱਕ ਐਪ "ਚੱਲਦਾ" ਹੋਵੇ, ਵੇਰਵੇ ਬਦਲ ਸਕਦੇ ਹਨ: ਇੱਕ ਪਲੱਗਇਨ ਲੋਡ ਨਹੀਂ ਹੁੰਦਾ, ਇੱਕ ਪ੍ਰਿੰਟਰ ਡ੍ਰਾਈਵਰ ਗੈਰ-ਮੌਜੂਦ ਹੈ, ਇੱਕ ਮੈਕਰੋ ਵੱਖਰੀ ਤਰ੍ਹਾਂ ਵਰਤਦਾ ਹੈ, ਇੱਕ ਗੇਮ ਐਂਟੀ-ਚੀਟ ਕੁਝ ਫਲੇਗ ਕਰਦਾ ਹੈ, ਜਾਂ ਇੱਕ ਨਿਸ਼ ਐਕਸੈਸਰੀ ਕੰਮ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੰਦੀ ਹੈ। ਹਰ ਇੱਕ ਨੁਕਤਾ ਛੋਟਾ ਹੁੰਦਾ ਹੈ; ਪਰ ਮਿਲ ਕੇ ਇਹ ਅਪਗਰੇਡ ਦਾ ਮੁੱਲ ਬਰਬਾਦ ਕਰ ਸਕਦੇ ਹਨ।

ਵੇਂਡਰ ਦਾ ਬਿੱਲ: QA ਸਪ੍ਰੈਡ ਅਤੇ ਸਹਾਇਤਾ ਭਾਰ

ਵੇਂਡਰ ਪਲੇਟਫਾਰਮ ਬਦਲਾਅ ਦਾ ਭੁਗਤਾਨ ਵਧ ਰਹੀ ਟੈਸਟ ਮੈਟ੍ਰਿਕਸ ਰਾਹੀਂ ਕਰਦੇ ਹਨ। ਇਹ ਸਿਰਫ਼ "ਕੀ ਇਹ ਲਾਂਚ ਹੁੰਦਾ ਹੈ?" ਹੀ ਨਹੀਂ ਹੈ। ਇਹ ਹੈ:

• ਵੱਖ-ਵੱਖ OS ਵਰਜ਼ਨ ਅਤੇ ਅਪਡੇਟ ਚੈਨਲ
• ਵੱਖ-ਵੱਖ CPU ਜਨਰੇਸ਼ਨ ਅਤੇ ਫੀਚਰ ਸੈੱਟ
• ਡ੍ਰਾਈਵਰ, ਫਰਮਵੇਅਰ, ਅਤੇ ਸੁਰੱਖਿਆ ਟੂਲ
• ਐਂਟਰਪ੍ਰਾਈਜ਼ ਨੀਤੀਆਂ ਅਤੇ ਲਾਕਡਾਉਨ ਮੋਡ

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

ਡਿਵੈਲਪਰ ਦਾ ਬਿੱਲ: ਪੋਰਟ, ਪ੍ਰਦਰਸ਼ਨ, ਅਤੇ ਭਰੋਸਾ

ਡਿਵੈਲਪਰ ਲਾਇਬ੍ਰੇਰੀਆਂ ਪੋਰਟ ਕਰਨ, ਪ੍ਰਦਰਸ਼ਨ-ਸੰਵੇਦਨਸ਼ੀਲ ਕੋਡ ਦੁਬਾਰਾ ਲਿਖਣ (ਅਕਸਰ ISA ਲਈ ਹੈਂਡ-ਟਿਊਨ ਕੀਤੇ), ਅਤੇ ਆਟੋਮੇਟਡ ਟੈਸਟ ਦੁਬਾਰਾ ਬਣਾਉਣ ਦੀ ਲਾਗਤ ਸਹੇਤ ਹਨ। ਸਭ ਤੋਂ ਔਖਾ ਹਿੱਸਾ ਯਕੀਨ ਮੁੜ ਪ੍ਰਾਪਤ ਕਰਨਾ ਹੈ: ਨਵੀਂ ਬਿਲਡ ਸਹੀ, ਤੇਜ਼, ਅਤੇ ਅਸਲੀ ਵਰਕਲੋਡਾਂ ਹੇਠਾਂ ਸਥਿਰ ਹੈ ਇਹ ਸਾਬਤ ਕਰਨਾ।

ਲੁਕਿਆ ਹੋਇਆ ਕਿਲਰ: ਮੌਕਾ ਲਾਗਤ

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

ਬਹੁਤ ਸਾਰੀਆਂ ਸੰਸਥਾਵਾਂ ਸਿਰਫ਼ ਉਸ ਵੇਲਾਂ ਸਵਿੱਚ ਕਰਦੀਆਂ ਹਨ ਜਦ ਪੁਰਾਣਾ ਪਲੇਟਫਾਰਮ ਉਨ੍ਹਾਂ ਨੂੰ ਰੋਕਦਾ ਹੈ—ਜਾਂ ਨਵਾਂ ਬਹੁਤ ਆਕਰਸ਼ਕ ਹੋ ਜਾਏ ਕਿ ਉਹ ਇਸ ਤਰ੍ਹਾਂ ਦੀ ਬਦਲੀ ਦਾ ਭੁਗਤਾਨ ਕਰ ਲੈਂ।

ਪੁਲ: ਏਮੂਲੇਸ਼ਨ, ਤਰਜਮਾ, ਅਤੇ ਵਰਚੁਅਲਾਈਜ਼ੇਸ਼ਨ

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

ਏਮੂਲੇਸ਼ਨ ਵਿ. ਤਰਜਮਾ: ਪੁਰਾਣੇ ਐਪ ਜਿਊਂਦੇ ਰੱਖਣਾ

ਏਮੂਲੇਸ਼ਨ ਸਾਫਟਵੇਅਰ ਵਿੱਚ ਪੂਰੇ CPU ਦੀ ਨਕਲ ਕਰਦਾ ਹੈ। ਇਹ ਸਭ ਤੋਂ ਅਨੁਕੂਲ ਵਿਕਲਪ ਹੈ, ਪਰ ਆਮ ਤੌਰ 'ਤੇ ਸਭ ਤੋਂ ਧੀਮਾ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਹਰ ਹੁਕਮ "ਅਭਿਨਯ" ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਬਜਾਏ ਇਸਦੇ ਕਿ ਉਹ ਸਿੱਧਾ ਚਲੇ।

ਬਾਈਨਰੀ ਤਰਜਮਾ (ਅਕਸਰ ਡਾਇਨਾਮਿਕ) x86 ਕੋਡ ਦੇ ਟੁਕੜੇ ਨੂੰ ਨਵੀ CPU ਦੀ ਮੂਲ ਹੁਕਮ-ਭਾਸ਼ਾ ਵਿੱਚ ਦੌਰਾਉਂਦਾ ਹੈ ਜਦ ਪ੍ਰੋਗਰਾਮ ਚੱਲਦਾ ਹੈ। ਇਹ ਕਈ ਆਧੁਨਿਕ ਟ੍ਰਾਂਜ਼ੀਸ਼ਨਾਂ ਦਾ ਦਿਨ-ਇੱਕ ਕਹਾਣੀ ਕੀਤਾ ਹੈ: ਆਪਣੇ ਮੌਜੂਦਾ ਐਪ ਇੰਸਟਾਲ ਕਰੋ, ਅਤੇ ਇੱਕ ਅਨੁਕੂਲਤਾ ਲੇਅਰ ਚੁਪਚਾਪ ਤਰਜਮਾ ਕਰ ਦਿੰਦੀ ਹੈ।

ਮੁੱਲ ਸਧਾਰਨ ਹੈ: ਤੁਸੀਂ ਨਵਾਂ ਹਾਰਡਵੇਅਰ ਖਰੀਦ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਹਰ ਵੇਂਡਰ ਦਾ ਰੀਕੰਪਾਈਲ ਹੋਣ ਦੀ ਉਡੀਕ ਕੀਤੇ।

ਕਿਉਂ ਇਹ ਕਦੇ ਪੂਰਾ ਸਮਰਥਕ ਨਹੀਂ ਹੁੰਦਾ

ਅਨੁਕੂਲਤਾ ਪਰਤ ਆਮ ਤੌਰ 'ਤੇ ਮੱਖੀ, ভাল-ਵਿਵਹਾਰ ਵਾਲੀਆਂ ਐਪਾਂ ਲਈ ਸਾਸ਼ਤੀ ਕੰਮ ਕਰਦੀ ਹੈ—ਪਰ ਐਜ 'ਤੇ ਸੰਘਰਸ਼ ਕਰਦੀ ਹੈ:

• ਪ੍ਰਦਰਸ਼ਨ ਕਲਿਫ: ਇੱਕ ਵਰਕਲੋਡ ਠੀਕ ਹੋ ਸਕਦਾ ਹੈ ਜਦ ਤਕ ਇਹ ਭਾਰੀ SIMD, JIT ਕੰਪਾਇਲਰ, ਜਾਂ ਤਣਾਅ ਵਾਲੀਆਂ ਲੂਪਾਂ 'ਤੇ ਨਹੀਂ ਪੁੱਗਦਾ ਜੋ ਮਾੜੀ ਤਰ੍ਹਾਂ ਤਰਜਮਾ ਹੁੰਦੇ ਹਨ।
• ਐਜ-ਕੇਸ: ਕਾਪੀ-ਸੁਰੱਖਿਆ, ਨੀਚ-ਲੈਵਲ ਟਾਈਮਿੰਗ ਅਨੁਮਾਨ, ਜਾਂ ਸਵੈ-ਸੰਪਾਦਨ ਕੋਡ ਟੁੱਟ ਸਕਦੇ ਹਨ।
• ਡ੍ਰਾਈਵਰ ਅਤੇ ਕਰਨਲ ਕੰਪੋਨੈਂਟ: ਤੁਸੀਂ ਇੱਕ ਐਪ ਨੂੰ ਤਰਜਮਾ ਕਰ ਸਕਦੇ ਹੋ, ਪਰ ਇੱਕ ਗੁੰਮ ਹੋਏ ਪ੍ਰਿੰਟਰ ਡ੍ਰਾਈਵਰ ਜਾਂ ਲੇਗਸੀ ਕਰਨਲ ਐਕਸਟੇੰਸ਼ਨ ਨੂੰ "ਤਰਜਮਾ" ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ।

ਹਾਰਡਵੇਅਰ ਸਹਿਯੋਗ ਅਕਸਰ ਅਸਲ ਰੋਕ ਹੈ।

ਵਰਚੁਅਲਾਈਜ਼ੇਸ਼ਨ: ਕਾਰੋਬਾਰ ਸੌਫਟਵੇਅਰ ਲਈ ਇੱਕ ਅੰਸ਼-ਪੁਲ

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

ਉਸੇ ਆਰਕੀਟੈਕਚਰ VM ਨੇਟਿਵ ਨਜ਼ਦੀਕੀ ਹੋ ਸਕਦੇ ਹਨ; ਆਰਕੀਟੈਕਚਰ-ਪਾਰ VM ਅਕਸਰ ਏਮੂਲੇਸ਼ਨ 'ਤੇ ਆ ਕੇ ਧੀਮੇ ਹੋ ਜਾਂਦੇ ਹਨ।

"ਠੀਕ-ਠਾਕ" ਕਦੋਂ ਕਾਫ਼ੀ ਹੁੰਦਾ ਹੈ?

ਇੱਕ ਪੁਲ ਆਮ ਤੌਰ 'ਤੇ ਦਫ਼ਤਰ ਐਪ, ਬ੍ਰਾਊਜ਼ਰ ਅਤੇ ਹਰ-ਰੋਜ਼ ਦੀ ਪ੍ਰੋਡਕਟੀਵਿਟੀ ਲਈ ਕਾਫ਼ੀ ਹੁੰਦਾ ਹੈ—ਜਿੱਥੇ "ਤੇਜ਼ੀ ਨਾਲ ਕਾਫ਼ੀ" ਜਿੱਤਦੀ ਹੈ। ਇਹ ਖਤਰਨਾਕ ਹੈ ਜੇ:

• ਵਿਸ਼ੇਸ਼ ਪੈਰੀਫੇਰਲ ਅਤੇ ਡ੍ਰਾਈਵਰ ਹਨ
• ਘੱਟ-ਦਿਰਘਤਾ ਆਡੀਓ/ਵੀਡੀਓ ਪਾਈਪਲਾਈਨ
• ਹਾਈ-ਪ੍ਰਦਰਸ਼ਨ ਕੰਪਿਊਟਿੰਗ ਜਾਂ ਭਾਰੀ ਗ੍ਰਾਫਿਕਸ

ਅਮਲ ਵਿੱਚ, ਪੁਲ ਸਮਾਂ ਖਰੀਦਦੇ ਹਨ—ਪਰ ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਮਾਈਗ੍ਰੇਸ਼ਨ ਕੰਮ ਨੂੰ ਮੁਕੰਮਲ ਤੌਰ 'ਤੇ ਹਟਾਉਂਦੇ ਨਹੀਂ।

ਪ੍ਰਦਰਸ਼ਨ, ਪਾਵਰ, ਅਤੇ ਵਰਕਲੋਡ ਮਿਸ਼ਰਣ

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

x86 PCs ਲਈ ਡਿਫਾਲਟ ਬਣਿਆ ਕਿਉਂਕਿ ਇਸਨੇ ਵਾਲ-ਪਾਵਰ 'ਤੇ ਮਜ਼ਬੂਤ ਪੀਕ ਪ੍ਰਦਰਸ਼ਨ ਦਿੱਤਾ, ਅਤੇ ਉਦਯੋਗ ਨੇ ਬਾਕੀ ਸਭ ਕੁਝ ਉਸ ਅਨੁਮਾਨ ਦੇ ਆਸ-ਪਾਸ ਤਿਆਰ ਕੀਤਾ।

ਪੀਕ ਪ੍ਰਦਰਸ਼ਨ vs ਪਾਵਰ ਕੁਸ਼ਲਤਾ

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

ਪਾਵਰ ਕੁਸ਼ਲਤਾ ਇੱਕ ਵੱਖਰਾ ਖੇਡ ਹੈ। ਜੇ ਤੁਹਾਡਾ ਉਤਪਾਦ ਬੈਟਰੀ, ਤਾਪ, ਫੈਨ ਸ਼ੋਰ, ਜਾਂ ਪਤਲੇ ਚੇਸਿਸ ਦੁਆਰਾ ਸੀਮਤ ਹੈ, ਤਾਂ ਸਭ ਤੋਂ ਵਧੀਆ CPU ਉਹ ਹੈ ਜੋ ਹਰ ਵਾਟ ਲਈ "ਕਾਫ਼ੀ" ਕੰਮ ਕਰਦਾ ਹੈ, ਲਗਾਤਾਰ, ਬਿਨਾਂ throttling ਦੇ।

ਕੁਸ਼ਲਤਾ ਸਿਰਫ਼ ਊਰਜਾ ਬਚਾਉਣ ਬਾਰੇ ਨਹੀਂ; ਇਹ ਇਸ ਬਾਰੇ ਹੈ ਕਿ ਤਾਪਮਾਨ ਸੀਮਾਵਾਂ ਦੇ ਅੰਦਰ ਰਹਿ ਕੇ ਪ੍ਰਦਰਸ਼ਨ ਕਾਇਮ ਰਹੇ।

ਮੋਬਾਈਲ ਨੇ ਕਿਵੇਂ ਹੋਰ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਤਰਜੀਹ ਦਿੱਤੀ

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

ਇਸ ਨਾਲ ਐਕੋਸਿਸਟਮ ਤਿਆਰ ਹੋਇਆ ਜਿੱਥੇ OS, ਐਪਸ ਅਤੇ ਸਿਲੀਕਨ ਮਿਲ ਕੇ ਮੋਬਾਇਲ-ਪਹਿਲੇ ਅਨੁਮਾਨਾਂ ਹੇਠਾਂ ਵਿਕਸਤ ਹੋਏ।

ਸਰਵਰ: ਭਰੋਸੇਯੋਗੀ ਅਤੇ ਪੱਕੀਤਾ ਰੂਪ ਵਿੱਚ ਕੱਚੀ ਰਫ਼ਤਾਰ ਨੂੰ ਹਰਾ ਦਿੰਦੇ ਹਨ

ਡੇਟאַסੈਂਟਰਾਂ ਵਿੱਚ CPU ਚੋਣ ਆਮ ਤੌਰ 'ਤੇ ਸਿਰਫ਼ ਬੈਨਚਮਾਰਕ ਨਹੀਂ ਹੁੰਦੀ। অপਰੇਟਰ ਨਿਰਭਰਤਾ ਫੀਚਰਾਂ, ਲੰਮੀ ਸਪੋਰਟ ਵਿੰਡੋ, ਸਥਿਰ ਫਰਮਵੇਅਰ, ਮੋਨੀਟਰੀੰਗ, ਅਤੇ ਡ੍ਰਾਈਵਰ/ਹਾਇਪਰਵਾਈਜ਼ਰ/ਮੈਨੇਜਮੈਂਟ ਟੂਲ ਦੇ ਵਿਕਸਤ ਇਕੋਸਿਸਟਮ 'ਤੇ ਧਿਆਨ ਦਿੰਦੇ ਹਨ।

ਇਕ ਨਵੀਂ ਆਰਕੀਟੈਕਚਰ perf/watt 'ਤੇ ਆਕਰਸ਼ਕ ਲੱਗੇ, ਪਰ ਆਪਰੇਸ਼ਨਲ ਅਚਾਨਕੀ ਖਤਰੇ ਲਾਭ ਨੂੰ ਓਵਰਵੇਟ ਕਰ ਸਕਦੇ ਹਨ।

ਵਰਕਲੋਡ ਮਿਸ਼ਰਣ “ਬਹਿਤਰੀਨ” ਪਲੇਟਫਾਰਮ ਫੈਸਲਾ ਕਰਦਾ ਹੈ

ਆਧੁਨਿਕ ਸਰਵਰ ਵਰਕਲੋਡ ਵੱਖ-ਵੱਖ ਹਨ: ਵੈੱਬ ਸਰਵਿੰਗ ਉੱਚ throughput ਅਤੇ ਕੁਸ਼ਲ ਸਕੇਲਿੰਗ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦੀ; ਡੇਟਾਬੇਸ ਮੈਮੋਰੀ bandwidth, ਲੇਟੈਂਸੀ ਸੁਚਿੱਤਤਾ ਅਤੇ ਟਿਊਨਿੰਗ ਨੂੰ ਇਨਾਮ ਦਿੰਦੇ ਹਨ; AI ਤੇਜ਼ੀ ਨਾਲ ਐਕਸਲੇਰੇਟਰ ਅਤੇ ਸਾਫਟਵੇਅਰ ਸਟੈਕ ਦੀ ਕੀਮਤ ਵਾਧਾ ਕਰ ਰਿਹਾ ਹੈ।

ਜਿਵੇਂ-ਜਿਵੇਂ ਮਿਸ਼ਰਣ ਬਦਲਦਾ ਹੈ, ਜਿੱਤੂ ਪਲੇਟਫਾਰਮ ਵੀ ਬਦਲ ਸਕਦਾ ਹੈ—ਪਰ ਇਹ ਸਿਰਫ਼ ਤਦ ਹੀ ਹੋ ਸਕਦਾ ਹੈ ਜਦ ਆਸ-ਪਾਸ ਦਾ ਇਕੋਸਿਸਟਮ ਨਾਲ ਕਦਮ ਮਿਲਾ ਲਏ।

ਟੂਲਿੰਗ ਅਤੇ ਡਿਸਟ੍ਰਿਬਿਊਸ਼ਨ: ਚੁਪਚਾਪ ਦਰਵਾਜ਼ੇ ਵਾਲੇ ਨਿਗਰਾਨ

ਇੱਕ ਨਵੀਂ CPU ਆਰਕੀਟੈਕਚਰ ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ ਸ਼ਾਨਦਾਰ ਹੋ ਸਕਦੀ ਹੈ ਫਿਰ ਵੀ ਫੇਲ ਹੋ ਸਕਦੀ ਹੈ ਜੇ ਰੋਜ਼ਾਨਾ ਦੀਆਂ ਟੂਲਾਂ ਇਸਨੂੰ ਬਿਲਡ, ਸ਼ਿਪ ਅਤੇ ਸਪੋਰਟ ਕਰਨਾ ਆਸਾਨ ਨਾ ਬਣਾਉਣ। ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਲਈ, "ਪਲੇਟਫਾਰਮ" ਸਿਰਫ ISA ਨਹੀਂ—ਇਹ ਪੂਰਾ ਡਿਲਿਵਰੀ ਪਾਈਪਲਾਈਨ ਹੈ।

ਟੂਲਚੇਨ ਇਹ ਫੈਸਲਾ ਕਰਦੇ ਹਨ ਕਿ ਕੀ "ਆਸਾਨ" ਹੈ

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

ਛੋਟੇ ਗੈਪ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹਨ: ਇੱਕ ਗੁੰਮ ਲਾਇਬ੍ਰੇਰੀ, ਇੱਕ ਫਲੇਕੀ ਡੀਬੱਗਰ ਪਲੱਗਇਨ, ਜਾਂ ਇੱਕ ਹੌਲੀ CI ਬਿਲਡ "ਅਸੀਂ ਇਸ ਕੌਰਟਰ ਵਿੱਚ ਪੋਰਟ ਨਹੀਂ ਕਰਾਂਗੇ" ਨੂੰ ਬਦਲ ਸਕਦਾ ਹੈ। ਜਦ x86 ਟੂਲਚੇਨ IDEs, ਬਿਲਡ ਸਿਸਟਮ ਅਤੇ CI ਟੈਮਪਲੇਟਸ ਵਿੱਚ ਡਿਫਾਲਟ ਹੁੰਦੀ ਹੈ, ਆਸਾਨ ਰਾਹ ਮੁੜ-ਮੁੜ ਵਾਪਸ ਖਿੱਚਦਾ ਹੈ।

ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨ ਸਿਧਾਂਤ ਨਹੀਂ, ਘਰਿਆਲ ਹੈ

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

• ਕੀ ਅਸੀਂ ਵੱਖਰੇ ਬਿਲਡ (x86 ਅਤੇ ARM), ਇੱਕ "ਯੂਨੀਵਰਸਲ" ਪੈਕੇਜ, ਜਾਂ ਤਰਜਮਾ 'ਤੇ ਨਿਰਭਰ ਕਰਾਂਗੇ?
• ਕੀ ਮੌਜੂਦਾ ਪਲੱਗਇਨ/ਡ੍ਰਾਈਵਰ ਅਜੇ ਵੀ ਆਸਾਨੀ ਨਾਲ ਇੰਸਟਾਲ ਹੋਣਗੇ?
• ਕੀ ਕੋਡ-ਸਾਇਨਿੰਗ, ਨੋਟਰੀਜ਼ੇਸ਼ਨ, ਅਤੇ ਆਟੋਮੈਟਿਕ ਅਪਡੇਟ ਵੱਖ-ਵੱਖ ਆਰਕੀਟੈਕਚਰਾਂ 'ਤੇ ਇੱਕਸਾਰ ਹਨ?

ਜੇ ਡਿਸਟ੍ਰਿਬਿਊਸ਼ਨ ਗੰਦੀ ਹੋ ਜਾਂਦੀ ਹੈ, ਸਪੋਰਟ ਲਾਗਤ ਤੇਜ਼ੀ ਨਾਲ ਵੱਧ ਜਾਂਦੀ ਹੈ—ਅਤੇ ਕਈ ਵੇਂਡਰ ਇਸ ਤੋਂ ਬਚਣਗੇ।

ਐਂਟਰਪ੍ਰਾਈਜ਼ ਮੈਨੇਜਮੈਂਟ ਇੱਕ ਕਠੋਰ ਬਾਰ

ਕਾਰੋਬਾਰ ਉਹ ਪਲੇਟਫਾਰਮ ਖਰੀਦਦੇ ਹਨ ਜੋ ਉਹ ਸਕੇਲ 'ਤੇ ਪ੍ਰਬੰਧ ਕਰ ਸਕਦੇ ਹਨ: ਇਮੇਜਿੰਗ, ਡਿਵਾਈਸ ਐਨਰੋਲਮੈਂਟ, ਨੀਤੀਆਂ, ਐਂਡਪਾਇੰਟ ਸੁਰੱਖਿਆ, EDR ਏਜੰਟ, VPN ਕਲਾਇੰਟ, ਅਤੇ ਅਨੁਕੂਲਤਾ ਰਿਪੋਰਟਿੰਗ। ਜੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਨਵੀਂ ਆਰਕੀਟੈਕਚਰ 'ਤੇ ਪਿੱਛੇ ਰਹਿ ਜਾਂਦੀ ਹੈ, ਪਾਇਲਟ ਰੁਕ ਜਾਂਦਾ ਹੈ।

"ਮੇਰੀ ਮਸ਼ੀਨ 'ਤੇ ਚੱਲਦਾ ਹੈ" ਅਣਭੇਦਿਆ ਹੈ ਜੇ IT ਇਹ ਤੈਅ ਨਹੀਂ ਕਰ ਸਕਦੀ ਕਿ ਕਿਵੇਂ ਡਿਪਲੋਯ ਕਰਨਾ ਅਤੇ ਸੁਰੱਖਿਅਤ ਕਰਨਾ ਹੈ।

ਅਸਲ ਮਾਪ: ਸ਼ਿਪ ਸਪੀਡ

ਡਿਵੈਲਪਰ ਅਤੇ IT ਇਕ ਵਿਅਵਹਾਰਕ ਸਵਾਲ 'ਤੇ ਇਕਠੇ ਹੁੰਦੇ ਹਨ: ਅਸੀਂ ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਅਤੇ ਸਪੋਰਟ ਕਰ ਸਕਦੇ ਹਾਂ? ਟੂਲਿੰਗ ਅਤੇ ਡਿਸਟ੍ਰਿਬਿਊਸ਼ਨ ਅਕਸਰ ਇਸ ਸਵਾਲ ਨੂੰ ਕੱਚੀ ਬੈਨਚਮਾਰਕਸ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਨਿਰਣਾਇਕ ਬਣਾਉਂਦੇ ਹਨ।

আধੁਨਿਕ "vibe-coding" ਪਲੇਟਫਾਰਮ ਕਿਵੇਂ ਮਦਦ ਕਰ ਸਕਦੇ ਹਨ

ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਤਰੀਕਾ ਟੀਮਾਂ ਨੂੰ ਮਾਈਗ੍ਰੇਸ਼ਨ ਘਟਾਉਣ ਲਈ ਹੈ ਸੌਖੇ ਨਾਲ ਵਿਚਾਰ ਤੋਂ ਇੱਕ ਟੈਸਟੇਬਲ ਬਿਲਡ ਤੱਕ ਦਾ ਸਮਾਂ ਘੱਟ ਕਰਨਾ—ਖ਼ਾਸ ਕਰਕੇ ਜਦ ਇਕੋ ਐਪ ਨੂੰ ਵੱਖ-ਵੱਖ ਵਾਤਾਵਰਣਾਂ (x86 v/s ARM, ਵੱਖ-ਵੱਖ OS ਇਮੇਜ, ਜਾਂ ਵੱਖ-ਵੱਖ ਡਿਪਲੋਯ ਟਾਰਗੇਟ) 'ਤੇ ਜਾਂਚਣਾ ਹੋਵੇ।

Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ ਇਸ ਵਰਕਫਲੋ ਵਿੱਚ ਫਿੱਟ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਟੀਮਾਂ ਨੂੰ ਇੱਕ ਚੈਟ ਇੰਟਰਫੇਸ ਰਾਹੀਂ ਅਸਲ ਐਪ ਬਣਾਉਣ ਅਤੇ ਇਤਰੈਸ਼ਨ ਕਰਨ ਦੀ ਆਸਾਨੀ ਦਿੰਦੇ ਹਨ—ਅਕਸਰ React-ਆਧਾਰਿਤ ਵੇੱਬ ਫਰੰਟਐਂਡ, Go ਬੈਕਐਂਡ, ਅਤੇ PostgreSQL ਡੇਟਾਬੇਸ (ਤੇ ਮੋਬਾਈਲ ਲਈ Flutter)। ਪਲੇਟਫਾਰਮ-ਟ੍ਰਾਂਜ਼ੀਸ਼ਨ ਕੰਮ ਲਈ ਦੋ ਖ਼ਾਸ ਯੋਗਤਾਵਾਂ ਮਹੱਤਵਪੂਰਨ ਹਨ:

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

ਕਿਉਂਕਿ Koder.ai source code export ਨੂੰ ਸਮਰਥਨ ਕਰਦਾ ਹੈ, ਇਹ ਪ੍ਰਯੋਗ ਅਤੇ ਇੱਕ ਪ੍ਰਵਾਨਗੀ ਇੰਜਣ ਦੇ درمیان ਇੱਕ ਪੁਲ ਵਜੋਂ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ—ਜਦ ਤੁਹਾਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਆਜ਼ਮਾਉਣਾ ਹੋਵੇ, ਪਰ ਫਿਰ ਵੀ ਰੱਖ ਰਹਿਣ ਯੋਗ ਕੋਡ ਆਪਣੇ ਰੇਪੋ ਵਿੱਚ ਚਾਹੀਦਾ ਹੋਵੇ।

ARM ਟ੍ਰਾਂਜ਼ੀਸ਼ਨਾਂ ਤੋਂ ਹਾਲੀਆ ਸਬਕ

ARM ਦਾ ਲੈਪਟਾਪਾਂ ਅਤੇ ਡੈਸਕਟਾਪਾਂ ਵਿੱਚ ਦਾਖ਼ਲਾ ਇਹ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਪਲੇਟਫਾਰਮ ਟ੍ਰਾਂਜ਼ੀਸ਼ਨ ਅਸਲ ਵਿੱਚ ਕਿੰਨੇ ਮੁਸ਼ਕਲ ਹਨ। ਕਾਗਜ਼ 'ਤੇ ਪਿਚ ਸਧਾਰਣ ਹੈ: ਵਧੀਆ performance-per-watt, ਸ਼ਾਂਤ ਮਸ਼ੀਨਾਂ, ਲੰਬੀ ਬੈਟਰੀ ਲਾਈਫ। ਹਰਅਸਲ, ਸਫਲਤਾ CPU ਕੋਰ ਤੋਂ ਘੱਟ ਅਤੇ ਉਸਦੇ ਆਲੇ-ਦੁਆਲੇ ਦੀ ਹਰ ਚੀਜ਼—ਐਪਸ, ਡ੍ਰਾਈਵਰ, ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨ, ਅਤੇ ਜੋ ਪ੍ਰੇਰਨਾ ਇਕੱਠਾ ਕਰਦੀ ਹੈ—ਉੱਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ।

Apple: ਪੂਰੇ ਸਟੈਕ 'ਤੇ ਕਾਬੂ ਔਣ ਅਣਜਾਣੀਆਂ ਘਟਾਉਂਦਾ ਹੈ

Apple ਦਾ Intel ਤੋਂ Apple Silicon ਤੱਕ ਦਾ ਮੂਵ ਇਸ ਲਈ ਕਾਰਗਰ ਰਿਹਾ ਕਿਉਂਕਿ Apple ਪੂਰੇ ਸਟੈਕ 'ਤੇ ਕਾਬੂ ਰੱਖਦਾ ਹੈ: ਹਾਰਡਵੇਅਰ ਡਿਜ਼ਾਈਨ, ਫਰਮਵੇਅਰ, ਓਐਸ, ਡਿਵੈਲਪਰ ਟੂਲ, ਅਤੇ ਮੁੱਖ ਐਪ-distribution ਚੈਨਲ।

ਇਸ ਕਾਬੂ ਨੇ ਕੰਪਨੀ ਨੂੰ ਇੱਕ ਸਾਫ਼ ਤਬਦੀਲੀ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੱਤੀ ਬਿਨਾਂ ਦਰਜਨਾਂ ਅਜ਼ਾਦ ਭਾਗੀਦਾਰਾਂ ਦੇ ਇਕੱਠੇ ਹੋਣ ਦੀ ਉਡੀਕ ਕੀਤੇ।

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

Windows on ARM: ਭਾਗੀਦਾਰ, ਸਮਾਂ ਅਤੇ ਗੈਪ

Windows-on-ARM ਦੂਜੀ ਪਾਸੀ ਵਧੀਆ ਉਦਾਹਰਨ ਹੈ। Microsoft ਪੂਰੇ ਹਾਰਡਵੇਅਰ ਇਕੋਸਿਸਟਮ 'ਤੇ ਪੂਰਾ ਕਾਬੂ ਨਹੀਂ ਰੱਖਦਾ, ਅਤੇ Windows PCs OEM ਚੋਣਾਂ ਅਤੇ ਲੰਬੇ-ਪੂਛ ਵਾਲੇ ਡ੍ਰਾਈਵਰਾਂ 'ਤੇ ਬਹੁਤ ਨਿਰਭਰ ਹਨ।

ਇਸ ਨਾਲ ਆਮ ਤੋੜ-ਛਾੜ ਪੈਦਾ ਹੁੰਦੇ ਹਨ:

• ਡ੍ਰਾਈਵਰ: ਪ੍ਰਿੰਟਰ, ਆਡੀਓ ਇੰਟਰਫੇਸ, ਐਂਟਰਪ੍ਰਾਈਜ਼ ਪੈਰੀਫੇਰਲ, ਅਤੇ "ਇਕ-ਵਾਰ" ਕਾਰਪੋਰੇਟ ਡਿਵਾਈਸ ਮਾਈਗ੍ਰੇਸ਼ਨ ਨੂੰ ਰੋਕ ਸਕਦੇ ਹਨ।
• ਐਪ ਗੈਪ: ਕੁਝ ਪ੍ਰੋਫੈਸ਼ਨਲ ਟੂਲ ਦੇਰੀ ਨਾਲ (ਜਾਂ ਕਦੇ) ਆਉਂਦੇ ਹਨ, ਅਤੇ ਪਲੱਗਇਨ/ਐਡ-ਓਨ ਛੁਪੇ ਰੋਕ ਹੋ ਸਕਦੇ ਹਨ।
• ਪ੍ਰੇਰਣਾ timing: OEM ਵੱਡਾ ਸਟੇਕ ਨਹੀਂ ਲਗਾਉਂਦੇ ਜਦ ਤੱਕ ਮੰਗ ਸੁਰੱਖਿਅਤ ਨਾ ਲੱਗੇ, ਪਰ ਉਪਭੋਗੀ ਉਹਨਾਂ ਡਿਵਾਈਸਾਂ ਦੀ ਮੰਗ ਨਹੀਂ ਕਰਦੇ ਜਦ ਤੱਕ ਅਨੁਕੂਲਤਾ ਸੁਰੱਖਿਅਤ ਨਾ ਹੋਵੇ।

ਸਿੱਟਾ: ਜਿੱਤਣ ਵਾਲੀਆਂ ਟ੍ਰਾਂਜ਼ੀਸ਼ਨਸ sangਠਨਾਤਮਕ ਹੁੰਦੀਆਂ ਹਨ, ਸਿਰਫ ਤਕਨੀਕੀ ਨਹੀਂ

ARM ਦੀਆਂ ਹਾਲੀਆ ਤਰੱਕੀਆਂ ਇੱਕ ਮੁੱਖ ਪਾਠ ਨੂੰ ਪੁਸ਼ਟ ਕਰਦੀਆਂ ਹਨ: ਜੇ ਤੁਸੀਂ ਸਟੈਕ ਦੇ ਹੋਰ ਹਿੱਸਿਆਂ 'ਤੇ ਵੱਧ ਕਾਬੂ ਰੱਖਦੇ ਹੋ ਤਾਂ ਟ੍ਰਾਂਜ਼ੀਸ਼ਨ ਤੇਜ਼ ਅਤੇ ਘੱਟ ਵਿਖੰਡਿਤ ਬਣਦੀ ਹੈ।

ਜੇ ਤੁਸੀਂ ਭਾਗੀਦਾਰਾਂ 'ਤੇ ਨਿਰਭਰ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਬਹੁਤ ਮਜ਼ਬੂਤ ਸਹਿਕਾਰ, ਸਪਸ਼ਟ ਅਪਗਰੇਡ ਰਾਹ, ਅਤੇ ਹਰ ਭਾਗੀਦਾਰ (ਚਿਪ ਵੇਂਡਰ, OEM, ਡਿਵੈਲਪਰ, ਅਤੇ IT ਖਰੀਦਦਾਰ) ਲਈ ਪ੍ਰੇਰਣਾ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਕਿ ਉਹ ਇੱਕੋ ਸਮੇਂ ਤੇ ਸਰਗਰਮ ਹੋਣ।

ਪਲੇਟਫਾਰਮ ਬਦਲਣ ਟੈਕ ਵਿੱਚ ਸਭ ਤੋਂ ਔਖੇ ਜੰਗ ਕਿਉਂ ਹਨ

ਪਲੇਟਫਾਰਮ ਸ਼ਿਫਟ ਅਕਸਰ ਨਿਰਾਸ਼ਜਨਕ ਕਾਰਨਾਂ ਕਰਕੇ ਫੇਲ ਹੁੰਦੇ ਹਨ: ਪੁਰਾਣਾ ਪਲੇਟਫਾਰਮ ਅਜੇ ਵੀ ਕੰਮ ਕਰਦਾ ਹੈ, ਹਰ ਕੋਈ ਪਹਿਲਾਂ ਹੀ ਇਸ 'ਤੇ ਪੈਸਾ ਅਤੇ ਆਦਤਾਂ ਦੀ ਰੂਪ ਵਿੱਚ ਭੁਗਤਾਨ ਕਰ ਚੁੱਕਾ ਹੈ, ਅਤੇ "ਐਜ-ਕੇਸ" ਉਹیں ਹਨ ਜਿੱਥੇ ਵਾਸਤਵਿਕ ਕਾਰੋਬਾਰ ਰਹਿੰਦੇ ਹਨ।

ਇਸ਼ਾਰੇ ਜੋ ਦਿਖਾਉਂਦੇ ਹਨ ਕਿ ਇੱਕ ਟ੍ਰਾਂਜ਼ੀਸ਼ਨ ਅਸਲ ਵਿੱਚ ਟਿਕੇਗਾ

ਇੱਕ ਨਵਾਂ ਪਲੇਟਫਾਰਮ ਮੁਕੰਮਲ ਤੌਰ 'ਤੇ ਤਬ ਜਿੱਤਦਾ ਹੈ ਜਦ ਤਿੰਨ ਚੀਜ਼ਾਂ ਇਕੱਠੇ ਹੋਣ:

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

ਕੰਪਨੀਆਂ ਜੋਖਮ ਘਟਾਉਂਦੀਆਂ ਹਨ ਕਿਸ ਤਰ੍ਹਾਂ

ਸਫਲ ਟ੍ਰਾਂਜ਼ੀਸ਼ਨ ਸਵਿੱਚ ਦੀ ਤਰ੍ਹਾਂ ਨਹੀਂ ਲੱਗਦੇ; ਉਹ ਨਿਯੰਤਰਿਤ ਓਵਰਲੈਪ ਵਾਂਗ ਹੁੰਦੇ ਹਨ। ਪੇਸ਼ਕ ਐਲਾਨ (pilot groups), ਦੋਹਾਂ ਬਿਲਡ (ਪੁਰਾਣਾ + ਨਵਾਂ), ਅਤੇ ਟੈਲੀਮੇਟਰੀ (ਕ੍ਰੈਸ਼ ਦਰ, ਪ੍ਰਦਰਸ਼ਨ, ਫੀਚਰ ਉਪਯੋਗ) ਟੀਮਾਂ ਨੂੰ ਸ਼ੁਰੂ਼ ਵਿੱਚ ਸਮੱਸਿਆਵਾਂ ਫੜਨ ਲਈ ਆਸਾਨੀ ਦਿੰਦੇ ਹਨ।

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

ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਚੈਕਲਿਸਟ ਤੁਹਾਡੇ ਲਈ ਜਦ ਤੁਸੀਂ ਸੁਇਚ ਕਰਨ ਦੀ ਸੋਚੋ

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

ਇਸਨੂੰ ਇੱਕ ਨਿਯੰਤਰਿਤ ਰੋਲਆਊਟ ਦੇ ਤੌਰ 'ਤੇ ਇਲਾਜ ਕਰੋ, ਨਾ ਕਿ ਇੱਕ ਵੱਡਾ ਇਕ-ਛੱਡਿਆ-ਵਾਰ Swap ਵਜੋਂ।

ਸੰਤੁਲਿਤ ਨਜ਼ਰੀਆ

x86 ਅਜੇ ਵੀ ਵੱਡਾ ਗਤੀਸ਼ੀਲ ਹੈ: ਦਹਾਕਿਆਂ ਦੀ ਅਨੁਕੂਲਤਾ, ਗੁੰਝਲਦਾਰ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਵਰਕਫ਼ਲੋਜ਼, ਅਤੇ ਵਿਸ਼ਾਲ ਹਾਰਡਵੇਅਰ ਵਿਕਲਪ।

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