14 ਮਈ 2025·8 ਮਿੰਟ
Intel, x86 ਦਾ ਪ੍ਰਭਾਅ ਅਤੇ ਪਲੇਟਫਾਰਮ ਬਦਲਣਾ ਕਿਉਂ ਮੁਸ਼ਕਲ ਹੈ
ਇੱਕ ਸਪਸ਼ਟ ਇਤਿਹਾਸ ਕਿ ਕਿਵੇਂ Intel x86 ਨੇ ਦਹਾਕਿਆਂ ਦੀ ਅਨੁਕੂਲਤਾ ਬਣਾਈ, ਕਿਉਂ ਇਕੋਸਿਸਟਮ ਲਾਕ-ਇਨ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਉਦਯੋਗ ਲਈ ਪਲੇਟਫਾਰਮ ਬਦਲਣਾ ਕਿਉਂ ਮੁਸ਼ਕਲ ਹੈ।
ਇੱਕ ਸਪਸ਼ਟ ਇਤਿਹਾਸ ਕਿ ਕਿਵੇਂ Intel x86 ਨੇ ਦਹਾਕਿਆਂ ਦੀ ਅਨੁਕੂਲਤਾ ਬਣਾਈ, ਕਿਉਂ ਇਕੋਸਿਸਟਮ ਲਾਕ-ਇਨ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਉਦਯੋਗ ਲਈ ਪਲੇਟਫਾਰਮ ਬਦਲਣਾ ਕਿਉਂ ਮੁਸ਼ਕਲ ਹੈ।
ਜਦ ਲੋਕ 'x86' ਕਹਿੰਦੇ ਹਨ, ਉਹ ਆਮ ਤੌਰ 'ਤੇ CPU ਹੁਕਮਾਂ ਦੇ ਉਹ ਪਰਿਵਾਰ ਮੰਨਦੇ ਹਨ ਜੋ Intel ਦੇ 8086 ਚਿਪ ਨਾਲ ਸ਼ੁਰੂ ਹੋਏ ਅਤੇ ਦਹਾਕਿਆਂ ਵਿੱਚ ਵਿਕਸਿਤ ਹੋਏ। ਇਹ ਹੁਕਮ ਉਹ ਮੂਲ ਕਿਰਿਆਵਾਂ ਹਨ ਜੋ ਇੱਕ ਪ੍ਰੋਸੈਸਰ ਸਮਝਦਾ ਹੈ—ਜੋੜਨਾ, ਤੁਲਨਾ ਕਰਨਾ, ਡੈਟਾ ਹਿਲਾਉਣਾ, ਆਦਿ। ਇਸ instruction set ਨੂੰ ISA (instruction set architecture) ਕਿਹਾ ਜਾਂਦਾ ਹੈ। ਤੁਸੀਂ ISA ਨੂੰ ਉਸ "ਭਾਸ਼ਾ" ਵਜੋਂ ਸੋਚ ਸਕਦੇ ਹੋ ਜੋ ਸਾਫਟਵੇਅਰ ਨੂੰ ਕਿਸੇ ਖ਼ਾਸ CPU 'ਤੇ ਚਲਣ ਲਈ ਆਖ਼ਰੀ ਤੌਰ 'ਤੇ ਬੋਲਣੀ ਪੈਂਦੀ ਹੈ.
x86: ਪਿਛਲੇ ਤਕਰੀਬਨ 40 ਸਾਲਾਂ ਵਿਚ PCs ਵਿੱਚ ਸਭ ਤੋਂ ਆਮ ISA, ਮੁੱਖ ਤੌਰ 'ਤੇ Intel ਅਤੇ AMD ਵੱਲੋਂ ਲਾਗੂ ਕੀਤਾ ਗਿਆ।
ਬੈਕਵਰਡ ਕੰਪੈਟਿਬਿਲਟੀ: ਨਵੀਂ ਮਸ਼ੀਨਾਂ ਦੀ ਯੋਜਨਾ ਇਹ ਯੋਗਤਾ ਰੱਖਦੀ ਹੈ ਕਿ ਪੁਰਾਣਾ ਸਾਫਟਵੇਅਰ (ਕਈ ਵਾਰੀ ਦਹਾਕਿਆਂ ਪੁਰਾਣੇ ਪ੍ਰੋਗਰਾਮ ਵੀ) ਵੱਡੇ ਪੂਨਰਲਿਖਤਾਂ ਦੀ ਲੋੜ ਬਿਨਾਂ ਚੱਲਦਾ ਰਹੇ। ਹਰ ਹੱਲੇ-ਮੁਕੰਮਲ ਤਰੀਕੇ ਨਾਲ ਨਹੀਂ, ਪਰ ਇਹ PC ਦੁਨੀਆਂ ਦੀ ਇੱਕ ਮੁੱਖ ਉਮੀਦ ਬਣ ਗਈ: “ਤੁਹਾਡੀ ਚੀਜ਼ਾਂ ਹੋਰ ਵੀ ਕੰਮ ਕਰਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ।”
"ਪ੍ਰਭਾਅ" ਸਿਰਫ ਪ੍ਰਦਰਸ਼ਨ ਦੀ ਦਾਅਵਾ ਨਹੀਂ; ਇਹ ਕਈ ਪੱਖਾਂ 'ਤੇ ਇੱਕ ਪ੍ਰਯੋਗਿਕ, ਜੁੜਦਾ ਹੋਇਆ ਫਾਇਦਾ ਹੈ:
ਇਹ ਮਿਲਾਪ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਹਰ ਪਰਤ ਦੂਜੀ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦੀ ਹੈ। ਵੱਧ ਮਸ਼ੀਨਾਂ ਵੱਧ ਸਾਫਟਵੇਅਰ ਨੂੰ ਪ੍ਰੇਰਿਤ ਕਰਦੀਆਂ ਹਨ; ਵੱਧ ਸਾਫਟਵੇਅਰ ਵੱਧ ਮਸ਼ੀਨਾਂ ਨੂੰ ਅਪੀਲ ਕਰਦਾ ਹੈ।
ਰਾਜਮਦਾ ISA ਨੂੰ ਬਦਲਣਾ ਸਿਰਫ਼ ਇੱਕ ਹਿੱਸਾ ਬਦਲਣ ਵਰਗਾ ਨਹੀਂ ਹੈ। ਇਹ ਐਪਲੀਕੇਸ਼ਨਾਂ, ਡ੍ਰਾਈਵਰਾਂ (ਪਰਿੰਟਰ, GPU, ਆਡੀਓ ਡਿਵਾਈਸز, ਨਿਸ਼ ਪੈਰੀਫੇਰਲ), ਡਿਵੈਲਪਰ ਟੂਲਚੇਨ ਅਤੇ ਦਿਨ-ਚੜ੍ਹਦੀ ਆਦਤਾਂ (ਇਮੇਜਿੰਗ ਪ੍ਰਕਿਰਿਆਵਾਂ, IT ਸਕ੍ਰਿਪਟਾਂ, ਸੁਰੱਖਿਆ ਏਜੈਂਟ, ਡਿਪਲੋਯਮੈਂਟ ਪਾਈਪਲਾਈਨ) ਨੂੰ ਟੋਰ-ਟੋਰ ਪ੍ਰਭਾਵਤ ਕਰ ਸਕਦਾ ਹੈ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਬਹੁਤ ਤੋਂ Dependencies ਅਪਰਾਖੀਤ ਰਹਿੰਦੇ ਹਨ ਜਦ ਤੱਕ ਕੁਝ ਗਲਤ ਨਹੀਂ ਹੁੰਦਾ।
ਇਹ ਪੋਸਟ ਮੁੱਖ ਤੌਰ 'ਤੇ PCs ਅਤੇ ਸਰਵਰਾਂ 'ਤੇ ਕੇਂਦਰਿਤ ਹੈ, ਜਿੱਥੇ x86 ਲੰਮੇ ਸਮੇਂ ਤੋਂ ਡਿਫਾਲਟ ਰਿਹਾ। ਅਸੀਂ ਹਾਲੀਆ ਬਦਲਾਵਾਂ—ਖ਼ਾਸ ਕਰਕੇ ARM ਟ੍ਰਾਂਜਿਸ਼ਨਜ਼—ਨੂੰ ਵੀ ਉਧਾਰਣ ਵਜੋਂ ਲਿਆਵਾਂਗੇ, ਕਿਉਂਕਿ ਇਹ ਦਿਖਾਉਂਦੇ ਹਨ ਕਿ ਕਿਹੜੀਆਂ ਚੀਜ਼ਾਂ ਸੌਖੀਆਂ, ਕਿਹੜੀਆਂ ਨਹੀਂ, ਅਤੇ ਕਿਉਂ "ਸਿਰਫ਼ ਰੀਕੰਪਾਇਲ ਕਰੋ" ਅਕਸਰ ਪੂਰਾ ਕਹਿਰਾ ਨਹੀਂ ਹੁੰਦਾ।
ਸ਼ੁਰੂਆਤੀ PC ਬਜ਼ਾਰ ਕਿਸੇ ਮਹਾਨ ਆਰਕੀਟੈਕਚਰਿਕ ਯੋਜਨਾ ਨਾਲ ਸ਼ੁਰੂ ਨਹੀਂ ਹੋਇਆ—ਇਹ ਵਿਅਵਹਾਰਕ ਬੰਧਨਾਂ ਨਾਲ ਸ਼ੁਰੂ ਹੋਇਆ। ਕਾਰੋਬਾਰ ਸਸਤੇ, ਵੋਲਿਊਮ ਵਿੱਚ ਉਪਲਬਧ ਅਤੇ ਆਸਾਨੀ ਨਾਲ ਸੇਵਾ ਯੋਗ ਮਸ਼ੀਨਾਂ ਚਾਹੁੰਦੇ ਸਨ। ਇਹ ਵਿਕਰੇਤਿਆਂ ਨੂੰ ਉਹ 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 ਲਕੜੀ ਦੇ ਨਿਸ਼ਾਨ ਦੇ ਨਤੀਜੇ:
ਚਾਹੇ ਨਵਾਂ ਪਲੇਟਫਾਰਮ ਘੱਟ ਲਾਗਤ ਜਾਂ ਬਿਹਤਰ ਪ੍ਰਦਰਸ਼ਨ ਦਾ ਵਾਅਦਾ ਕਰਦਾ ਹੋਵੇ, ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਰੈਵਨਿਊ-ਉਤਪਾਦਕ ਵਰਕਫਲੋ ਨੂੰ ਤੋੜਨ ਦਾ ਖਤਰਾ ਵਧੇਰੇ ਲਾਭ ਤੋਂ ਵੱਧ ਹੁੰਦਾ ਹੈ।
ਡਿਵੈਲਪਰ ਅਕਸਰ ਖਾਲੀ ਝੰਡੇ ਲਈ "ਸਰਵੇਸ਼੍ਰੇଷਠ" ਪਲੇਟਫਾਰਮ 'ਤੇ ਅਭਿਆਸ ਨਹੀਂ ਕਰਦੇ। ਉਹ ਉਸ ਪਲੇਟਫਾਰਮ ਲਈ ਅਭਿਆਸ ਕਰਦੇ ਹਨ ਜੋ ਸਹਿਯੋਗ ਭਾਰ ਘਟਾਓ ਅਤੇ ਪਹੁੰਚ ਵਧਾਓ।
ਜੇ ਤੁਹਾਡੇ 90% ਗਾਹਕ x86 Windows 'ਤੇ ਹਨ, ਉਹੀ ਥਾਂ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਪਹਿਲਾਂ ਟੈਸਟ ਕਰਦੇ ਹੋ, ਪਹਿਲਾਂ ਸ਼ਿਪ ਕਰਦੇ ਹੋ, ਅਤੇ ਸਭ ਤੋਂ ਤੇਜ਼ੀ ਨਾਲ ਬੱਗ ਫਿਕਸ ਕਰਦੇ ਹੋ। ਦੂਜੇ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਸਮਰਥਨ ਦੇਣ ਦੇ ਮਤਲਬ ਵੱਧ ਬਿਲਡ ਪਾਈਪਲਾਈਨ, ਵੱਧ QA, ਅਤੇ ਵੱਧ ਸਪੋਰਟ ਟਿਕਟ—ਜੋ ਬਹੁਤਾਂ ਦੀਆਂ ਟੀਮਾਂ ਲਈ ਇਕ ਭਾਰ ਹੈ।
ਨਤੀਜਾ ਇੱਕ ਆਪਸੀ-ਪੁਸ਼ਟੀ ਕਰਨ ਵਾਲਾ ਫ਼ਰਕ ਹੈ: ਆਗੂ ਪਲੇਟਫਾਰਮ ਨੂੰ ਅਕਸਰ ਤੇਜ਼ ਤੇ ਵਧੀਆ ਸਾਫਟਵੇਅਰ ਮਿਲਦਾ ਹੈ।
ਇੱਕ ਛੋਟੇ ਕਾਰੋਬਾਰ ਦੀ ਤਸਵੀਰ ਕਰੋ। ਉਹਨਾਂ ਦਾ ਅਕਾਊਂਟਿੰਗ ਪੈਕੇਜ x86-ਕੇਵਲ ਹੈ, ਇੱਕ ਦਹਾਕੇ ਦੀ ਟੈਮਪਲੇਟ ਲਾਇਬ੍ਰੇਰੀ ਨਾਲ ਅਤੇ ਪੇਰੋਲ ਲਈ ਇੱਕ ਪਲੱਗਇਨ ਨਾਲ ਇਕੂਠਾ। ਉਹ ਇੱਕ ਖਾਸ ਲੇਬਲ ਪ੍ਰਿੰਟਰ ਅਤੇ ਦਸਤਾਵੇਜ਼ ਸਕੈਨਰ ਤੇ ਵੀ ਨਿਰਭਰ ਹਨ ਜਿਨ੍ਹਾਂ ਦੇ ਡ੍ਰਾਈਵਰ ਖਾਸ ਹਨ।
ਹਣੇ ਹੀ ਤੁਸੀਂ ਇਕ ਪਲੇਟਫਾਰਮ ਬਦਲਾਅ ਸੁਝਾਓ। ਭਾਵੇਂ ਮੁੱਖ ਐਪ ਮੌਜੂਦ ਹੋਵੇ, ਪਰ ਕਿਨਾਰੇ ਦੇ ਟੁਕੜੇ ਮਹੱਤਵਪੂਰਨ ਹਨ: ਪ੍ਰਿੰਟਰ ਡ੍ਰਾਈਵਰ, ਸਕੈਨਰ ਯੂਟਿਲਿਟੀ, PDF ਪਲੱਗਇਨ, ਬੈਂਕ-ਇੰਪੋਰਟ ਮੋਡੀਊਲ। ਇਹ 'ਬੋਰਿੰਗ' ਨਿਰਭਰਤਾਵਾਂ ਜ਼ਰੂਰੀ ਬਣ ਜਾਂਦੀਆਂ ਹਨ—ਅਤੇ ਜਦ ਉਹ ਗ਼ੈਰਮੌਜੂਦ ਜਾਂ ਠੀਕ ਨਹੀਂ ਹੁੰਦੀਆਂ, ਤਾਂ ਪੂਰਾ ਮਾਈਗ੍ਰੇਸ਼ਨ ਰੁਕ ਜਾਂਦਾ ਹੈ।
ਏਹੀ ਫਲਾਈਵੀਲ ਹੈ: ਜਿੱਤੂ ਪਲੇਟਫਾਰਮ ਲੰਬੇ-ਪੂਛ ਦੀ ਅਨੁਕੂਲਤਾ ਅਕੰਸ਼ਿਤ ਕਰਦਾ ਹੈ ਜਿਸ 'ਤੇ ਹਰ ਕੋਈ ਚੁਪਚਾਪ ਨਿਰਭਰ ਹੁੰਦਾ ਹੈ।
ਬੈਕਵਰਡ ਕੰਪੈਟਿਬਿਲਟੀ ਸਿਰਫ x86 ਦੀ ਇੱਕ ਵਧੀਆ ਵਿਸ਼ੇਸ਼ਤਾ ਨਹੀਂ ਰਹੀ—ਇਹ ਦਿਲਚਸਪੀ ਨਾਲ ਬਣਾਈ ਗਈ ਪ੍ਰੋਡਕਟ ਰਣਨੀਤੀ ਬਣ ਗਈ। Intel ਨੇ x86 ISA ਨੂੰ ਇਸਤਰਾ ਸਥਿਰ ਰੱਖਿਆ ਕਿ ਸਾਲਾਂ ਪਹਿਲਾਂ ਲਿਖਿਆ ਸਾਫਟਵੇਅਰ ਅਜੇ ਵੀ ਚੱਲ ਸਕੇ, ਜਦਕਿ ਹੇਠਾਂ ਵਾਲੀਆਂ ਚੀਜ਼ਾਂ ਨੂੰ ਬਦਲ ਦਿਤਾ ਗਿਆ।
ਮੁੱਖ ਫਰਕ ਇਹ ਹੈ ਕਿ ਕੀ ਚੀਜ਼ ਅਨੁਕੂਲ ਰਹੀ। ISA ਉਹ ਮਸ਼ੀਨ ਹੁਕਮਾਂ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦੀ ਹੈ ਜਿਨ੍ਹਾਂ 'ਤੇ ਪ੍ਰੋਗਰਾਮ ਨਿਰਭਰ ਹੁੰਦੇ ਹਨ; ਮਾਈਕ੍ਰੋਆਰਕੀਟੈਕਚਰ ਉਹ ਹੈ ਕਿ ਇੱਕ ਚਿਪ ਉਹਨਾਂ ਨੂੰ ਕਿਵੇਂ ਚਲਾਉਂਦੀ ਹੈ।
Intel ਸਧਾਰਨ ਪਾਈਪਲਾਈਨਾਂ ਤੋਂ ਲੈ ਕੇ out-of-order ਇਕਜ਼ਿਕਿਊਸ਼ਨ, ਵੱਡੇ caches, ਬਿਹਤਰ branch prediction, ਜਾਂ ਨਵੇਂ ਫੈਬ੍ਰਿਕੇਸ਼ਨ ਪ੍ਰਕ੍ਰਿਆਵਾਂ ਤੱਕ ਜਾ ਸਕਦਾ ਸੀ—ਬਿਨਾਂ ਵਿਕਾਸਕਾਰਾਂ ਨੂੰ ਆਪਣੀਆਂ ਐਪਸ ਦੁਬਾਰਾ ਲਿਖਣ ਲਈ ਕਿਹਾ।
ਇਹ ਸਥਿਰਤਾ ਇੱਕ ਸ਼ਕਤੀਸ਼ਾਲੀ ਉਮੀਦ ਬਣਾਉਂਦੀ ਸੀ: ਨਵੇਂ PCs ਨੂੰ ਪਹਿਲੇ ਦਿਨ ਹੀ ਪੁਰਾਣਾ ਸੌਫਟਵੇਅਰ ਚਲਾਉਣਾ ਚਾਹੀਦਾ।
x86 ਨੇ ਨਵੀਆਂ ਯੋਗਤਾਵਾਂ ਨੂੰ ਤਹਾਂ-ਤਹਾਂ ਜੋੜਿਆ। MMX, SSE, AVX ਵਰਗੀਆਂ instruction set ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਐਡੇਟਿਵ ਰਹੀਆਂ: ਪੁਰਾਣੇ ਬਾਈਨਰੀ ਅਜੇ ਵੀ ਕੰਮ ਕਰਦੇ, ਤੇ ਨਵੀਆਂ ਐਪਾਂ ਨਵੇਂ ਹੁਕਮਾਂ ਦੀ ਜਾਣਕਾਰੀ ਪ੍ਰਾਪਤ ਕਰਕੇ ਇਸਤੇਮਾਲ ਕਰ ਸਕਦੀਆਂ।
ਇeven major transitions were smoothed by compatibility mechanisms:
ਨੁਕਸਾਨ ਇਹ ਹੈ ਕਿ ਜਟਿਲਤਾ ਵਧਦੀ ਹੈ। ਦਹਾਕਿਆਂ ਦੀ ਹਾਬੀਅਤ ਦਾ ਸਮਰਥਨ ਕਰਨ ਦਾ ਮਤਲਬ ਹੋਰ CPU ਮੋਡ, ਹੋਰ ਐਡਜ ਕੇਸ, ਅਤੇ ਵੱਧ ਵੈਧਤਾ ਬੋਝ ਹੋਣਾ। ਹਰ ਨਵੀਂ ਪੀੜ੍ਹੀ ਨੂੰ ਇਹ ਸਾਬਤ ਕਰਨਾ ਪੈਂਦਾ ਹੈ ਕਿ ਉਹ ਅਜੇ ਵੀ ਕੱਲ ਦੀ ਬਿਜ਼ਨਸ ਐਪ, ਡ੍ਰਾਈਵਰ, ਜਾਂ ਇੰਸਟਾਲਰ ਚਲਦੀ ਹੈ।
ਸਮਾਂ ਦੇ ਨਾਲ, "ਮੌਜੂਦਾ ਐਪ ਨੂੰ ਨਾ ਤੋੜੋ" ਇੱਕ ਦਿਸ਼ਾ-ਨਿਰਦੇਸ਼ ਤੋਂ ਰਣਨੀਤੀਿਕ ਪਾਬੰਦੀ ਬਣ ਜਾਂਦਾ ਹੈ: ਇਹ ਇੰਸਟਾਲਡ ਬੇਸ ਦੀ ਰੱਖਿਆ ਕਰਦਾ ਹੈ, ਪਰ ਇਹ ਵੀ ਨਵੇਂ ISA, ਨਵੇਂ ਸਿਸਟਮ ਡਿਜ਼ਾਈਨਾਂ, ਅਤੇ ਨਵੇਂ ਅਨੁਮਾਨਾਂ ਨੂੰ ਬਹੁਤ ਮੁਸ਼ਕਲ ਕਰ ਦਿੰਦਾ ਹੈ।
"Wintel" ਸਿਰਫ Windows ਅਤੇ Intel ਚਿਪਾਂ ਲਈ ਇੱਕ ਚਟਕੀਲੇ ਨਾਂ ਨਹੀਂ ਸੀ। ਇਹ ਇੱਕ ਆਪਸੀ-ਪੁਸ਼ਟੀ ਕਰਨ ਵਾਲੇ ਲੂਪ ਦਾ ਵਰਣਨ ਕਰਦਾ ਸੀ ਜਿੱਥੇ ਪੀਸੀ ਉਦਯੋਗ ਦਾ ਹਰ ਹਿੱਸਾ ਇਕੋ ਡਿਫਾਲਟ ਟਾਰਗੇਟ 'ਤੇ ਟਿਕਣ ਤੋਂ ਲਾਭ ਵਿੱਚ ਸੀ: Windows on x86।
ਅਧਿਕਤਰ ਉਪਭੋਗਤਾ ਅਤੇ ਕਾਰੋਬਾਰੀ ਸਾਫਟਵੇਅਰ ਵਿਕਰੇਤਿਆਂ ਲਈ ਪ੍ਰਯੋਗਿਕ ਸਵਾਲ ਇਹ ਨਹੀਂ ਸੀ ਕਿ "कਿਹੜੀ ਆਰਕੀਟੈਕਚਰ ਸ਼੍ਰੇਸ਼ਠ ਹੈ?" ਸਗੋਂ "ਗਾਹਕ ਕਿੱਥੇ ਹਨ, ਅਤੇ ਸਹਾਇਤਾ ਕਾਲਾਂ ਕਿਵੇਂ ਹੋਣਗੀਆਂ?"।
Windows PCs ਘਰਾਂ, ਦਫਤਰਾਂ, ਅਤੇ ਸਕੂਲਾਂ ਵਿੱਚ ਵਿਸ਼ਾਲ ਤੌਰ 'ਤੇ ਤੈਅ ਹੋਏ ਹੋਏ ਸਨ, ਅਤੇ ਉਹ ਆਮ ਤੌਰ 'ਤੇ x86-ਅਧਾਰਤ ਸਨ। ਇਸ ਜੋੜੇ ਲਈ ਸ਼ਿਪ ਕਰਨਾ ਪਹੁੰਚ ਨੂੰ ਘੱਟ ਕਰਕੇ ਵੱਧ ਤੋਂ ਵੱਧ ਬਣਾਉਂਦਾ ਸੀ।
ਜਦ ਇੱਕ ਆਲੋਚਨਾਤਮਕ ਗਿਣਤੀ ਐਪਸ Windows + x86 'ਤੇ ਨਿਰਭਰ ਹੋ ਗਈ, ਨਵੇਂ ਖਰੀਦਦਾਰਾਂ ਕੋਲ ਇੱਕ ਹੋਰ ਕਾਰਨ ਸੀ ਇਸਨੂੰ ਚੁਣਨ ਦਾ: ਉਹਨਾਂ ਦੇ ਲਾਜ਼ਮੀ ਪ੍ਰੋਗਰਾਮ ਪਹਿਲਾਂ ਹੀ ਉੱਥੇ ਕੰਮ ਕਰਦੇ ਸਨ। ਇਸ ਨੇ ਆਗਲੇ ਤਹਲਦੇ ਵਿਕਾਸਕਾਰਾਂ ਲਈ ਪਲੇਟਫਾਰਮ ਨੂੰ ਹੋਰ ਆਕਰਸ਼ਕ ਬਣਾਇਆ।
PC ਨਿਰਮਾਤੇ (OEMs) ਤਦ ਜ਼ਿਆਦਾ ਕਾਮਯਾਬ ਹੁੰਦੇ ਹਨ ਜਦ ਉਹ ਬਹੁਤ ਸਾਰੇ ਮਾਡਲ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾ ਸਕਣ, ਕਈ ਸਪਲਾਇਰਾਂ ਤੋਂ ਕੰਪੋਨੈਂਟ ਲੈ ਸਕਣ, ਅਤੇ ਅਜਿਹੇ ਮਸ਼ੀਨਾਂ ਸ਼ਿਪ ਕਰ ਸਕਣ ਜੋ "ਸਿਰਫ਼ ਕੰਮ ਕਰਨ"। ਇੱਕ ਸਾਂਝਾ Windows + x86 ਬੇਸਲਾਈਨ ਇਸਨੂੰ ਸਹੂਲਤ-ਪੂਰਨ ਬਣਾਉਂਦਾ ਸੀ।
ਪੈਰੀਫੇਰਲ ਕੰਪਨੀਆਂ ਨੇ ਭੋਲਕੇ ਵਾਲਿਊਮ ਦਾ ਪਾਲਣ ਕੀਤਾ। ਜੇ ਜ਼ਿਆਦਾਤਰ ਖਰੀਦਦਾਰ Windows PCs ਵਰਤ ਰਹੇ ਸਨ, ਤਾਂ ਪ੍ਰਿੰਟਰ, ਸਕੈਨਰ, ਆਡੀਓ ਇੰਟਰਫੇਸ, Wi‑Fi ਚਿਪ, ਅਤੇ ਹੋਰ ਡਿਵਾਈਸ ਪਹਿਲਾਂ Windows ਡ੍ਰਾਈਵਰਾਂ ਨੂੰ ਤਰਜੀਹ ਦੇਣਗੇ। ਵਧੀਆ ਡ੍ਰਾਈਵਰ ਉਪਲਬਧਤਾ ਨੇ Windows PC ਅਨੁਭਵ ਨੂੰ ਸੁਧਾਰਿਆ, ਜਿਸ ਨੇ OEMs ਨੂੰ ਵੱਧ ਯੂਨਿਟ ਵੇਚਣ ਵਿੱਚ ਮਦਦ ਕੀਤੀ, ਜਿਸ ਨਾਲ ਵਾਲਿਊਮ ਉੱਚੀ ਰਹੀ।
ਕਾਰਪੋਰੇਟ ਅਤੇ ਸਰਕਾਰੀ ਖਰੀਦਦਾਰ ਅਕਸਰ ਪੇਸ਼ਗੋਈਯੋਗਤਾ ਨੂੰ ਇਨਾਮ ਦਿੰਦੇ ਹਨ: ਮੌਜੂਦਾ ਐਪਸ ਨਾਲ ਅਨੁਕੂਲਤਾ, ਸਹਾਇਤਾ ਲਾਗਤਾਂ ਦਾ ਪ੍ਰਬੰਧ, ਵੇਂਡਰ ਦੀਆਂ ਵਾਰੰਟੀ, ਅਤੇ ਪਰਖੀ ਗਈ ਡਿਪਲੋਯਮੈਂਟ ਟੂਲ।
ਭਾਵੇਂ ਵਿਕਲਪ ਆਕਰਸ਼ਕ ਹੋ, ਪਰ ਘੱਟ-ਖਤਰਾ ਚੋਣ ਅਕਸਰ ਜਿੱਤਦੀ ਹੈ ਕਿਉਂਕਿ ਇਹ ਟ੍ਰੇਨਿੰਗ ਘਟਾਉਂਦਾ, ਐਜ-ਕੇਸ ਫੇਲਿਆਂ ਤੋਂ ਬਚਾਅ ਕਰਦਾ, ਅਤੇ ਸਥਾਪਤ IT ਪ੍ਰਕਿਰਿਆਵਾਂ ਵਿੱਚ ਫਿੱਟ ਹੁੰਦੀ ਹੈ।
ਨਤੀਜਾ ਕੋਈ ਸਾਜ਼ਿਸ਼ ਨਹੀਂ ਸੀ; ਇਹ ਮਿਲੀ-ਮਿਲਾਈ ਪ੍ਰੇਰਣਾਵਾਂ ਦਾ ਖੇਤਰ ਸੀ—ਹਰ ਭਾਗ ਫ਼ੈਸਲਾ ਕਰ ਰਿਹਾ ਸੀ ਉਹ ਰਾਹ ਚੁਣੇ ਜੋ ਘੱਟ ਰੁਕਾਵਟ ਕਰੇ—ਜਿਸ ਨੇ ਐਸਾ ਗਤੀਸ਼ੀਲ ਬਣਾਇਆ ਕਿ ਪਲੇਟਫਾਰਮ ਬਦਲਣਾ ਬਹੁਤ ਮੁਸ਼ਕਲ ਹੋ ਗਿਆ।
ਇੱਕ "ਪਲੇਟਫਾਰਮ ਟ੍ਰਾਂਜ਼ੀਸ਼ਨ" ਸਿਰਫ਼ ਇੱਕ CPU ਨੂੰ ਬਦਲਣ ਦੀ ਗੱਲ ਨਹੀਂ। ਇਹ ਇੱਕ ਗੁਠਲੀ ਚਲ ਹੈ: CPU ISA, ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ, ਕੰਪਾਇਲਰ/ਟੂਲਚੇਨ ਜੋ ਐਪ ਬਣਾਉਂਦਾ ਹੈ, ਅਤੇ ਡ੍ਰਾਈਵਰ ਸਟੈਕ ਜੋ ਹਾਰਡਵੇਅਰ ਨੂੰ ਕੰਮ ਕਰਾਉਂਦਾ ਹੈ। ਕਿਸੇ ਵੀ ਇਕ ਨੂੰ ਬਦਲੋ ਅਤੇ ਤੁਸੀਂ ਅਕਸਰ ਹੋਰਾਂ ਨੂੰ ਡਿਸਟर्ब ਕਰ ਦਿੰਦੇ ਹੋ।
ਜ਼ਿਆਦਾਤਰ ਤੋੜ-ਛਾੜ ਨਾਟਕੀਆ ਨਹੀਂ ਹੁੰਦੀ "ਐਪ ਲਾਂਚ ਹੀ ਨਹੀਂ ਹੁੰਦਾ" ਵਾਲੀ; ਇਹ ਹਜ਼ਾਰਾਂ ਛੋਟੀ-ਛੋਟੀ ਸਮੱਸਿਆਵਾਂ ਹੁੰਦੀਆਂ ਹਨ:
ਘਰਗੀਰ ਐਪ ਨੂੰ ਨਵਾਂ ਬਿਲਡ ਮਿਲੇ, ਪਰ ਉਸ ਦਾ ਗਿਰਦਾ "ਗਲੂ" ਸ਼ਾਇਦ ਨਾ ਮਿਲੇ।
ਪਰਿੰਟਰ, ਸਕੈਨਰ, ਲੇਬਲ ਮੇਕਰ, ਵਿਸ਼ੇਸ਼ PCIe/USB ਕਾਰਡ, ਮੈਡੀਕਲ ਡਿਵਾਈਸ, ਪੌਇੰਟ-ਆਫ-ਸੇਲ ਗੇਅਰ, ਅਤੇ USB ਡੋਂਗਲ ਡ੍ਰਾਈਵਰਾਂ 'ਤੇ ਜੀਵਨ ਅਤੇ ਮੌਤ ਨਿਰਭਰ ਕਰਦੇ ਹਨ। ਜੇ ਵੇਂਡਰ ਚਲਾ ਗਿਆ ਹੋਵੇ—ਜਾਂ ਸਿਰਫ਼ ਰੁਚੀ ਨਹੀਂ ਰੱਖਦਾ—ਤਾਂ ਨਵੇਂ OS ਜਾਂ ਆਰਕੀਟੈਕਚਰ ਲਈ ਡ੍ਰਾਈਵਰ ਨਾਂ ਹੋ ਸਕਦਾ।
ਅਕਸਰ ਇੱਕ $200 ਦਾ ਡਿਵਾਈਸ $2,000 PCs ਦੀ ਫਲੀਟ ਨੂੰ ਪੰਗੁ ਕਰ ਸਕਦਾ ਹੈ।
ਸਭ ਤੋਂ ਵੱਡਾ ਰੋਕ ਉਹ ਹੁੰਦਾ ਹੈ "ਛੋਟੇ" ਅੰਦਰੂਨੀ ਟੂਲ: ਇੱਕ ਕਸਟਮ Access ਡੇਟਾਬੇਸ, ਇੱਕ Excel ਮੈਕਰੋ ਵਰਕਬੁੱਕ, 2009 ਵਿੱਚ ਲਿਖਿਆ VB ਐਪ, ਤਿੰਨ ਲੋਕਾਂ ਵਲੋਂ ਵਰਤਿਆ ਇੱਕ ਨਿਸ਼ ਮੈਨੂਫੈਕਚਰਿੰਗ ਯੂਟਿਲਿਟੀ।
ਇਹ ਕਿਸੇ ਦੇ ਵੀ ਉਤਪਾਦ ਰੋਡਮੈਪ 'ਤੇ ਨਹੀਂ ਹੁੰਦੇ, ਪਰ ਇਹ ਮਿਸ਼ਨ-ਸ kritikal ਹੁੰਦੇ ਹਨ। ਜਦ ਲੰਬੇ-ਪੂਛ ਨੂੰ ਮਾਈਗ੍ਰੇਟ, ਟੈਸਟ ਅਤੇ ਕਿਸੇ ਵਿਅਕਤੀ ਨੇ ਢਕਿਆ ਨਾ ਹੋਵੇ ਤਾਂ ਟ੍ਰਾਂਜ਼ੀਸ਼ਨ ਫੇਲ ਹੋ ਜਾਂਦੀ ਹੈ।
ਇੱਕ ਪਲੇਟਫਾਰਮ ਬਦਲਾਅ ਸਿਰਫ਼ ਬੈਨਚਮਾਰਕ 'ਤੇ ਅੰਕ ਨਹੀਂ ਲਗਦਾ। ਇਹ ਇਸ ਗੱਲ 'ਤੇ ਅੰਕ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ ਕਿ ਕੁੱਲ ਬਿਲ—ਪੈਸਾ, ਸਮਾਂ, ਜੋਖਿਮ, ਅਤੇ ਖੋਇਆ ਹੋਇਆ ਰੁਝਾਨ—ਉਸ ਲਾਭ ਤੋਂ ਘੱਟ ਹੈ ਜੋ ਨਵਾਂ ਪਲੇਟਫਾਰਮ ਮੁਹੱਈਆ ਕਰਦਾ ਹੈ। ਬਹੁਤ ਸਾਰੇ ਲੋਕਾਂ ਅਤੇ ਸੰਸਥਾਵਾਂ ਲਈ, ਉਹ ਬਿਲ ਬਾਹਰੋਂ ਵੇਖਣ 'ਤੇ ਵੱਧ ਹੁੰਦਾ ਹੈ।
ਉਪਭੋਗਤਿਆਂ ਲਈ ਸਵਿੱਚ ਦੀਆਂ ਲਾਗਤਾਂ ਮੁੱਖ (ਨਵੇਂ ਹਾਰਡਵੇਅਰ, ਨਵੇਂ ਪੈਰੀਫੇਰਲ, ਨਵੇਂ ਵਾਰੰਟੀ) ਤੋਂ ਸ਼ੁਰੂ ਹੁੰਦੀਆਂ ਅਤੇ ਫਿਰ ਗੰਦੀਆਂ ਚੀਜ਼ਾਂ ਵੱਲ ਵਧਦੀਆਂ ਹਨ: ਮਾਸਪੇਸ਼ੀ ਯਾਦ, ਵਰਕਫਲੋਜ਼ ਦੀ ਦੁਬਾਰਾ-ਕੰਫਿਗਰ, ਅਤੇ ਰੋਜ਼ਾਨਾ ਵਰਤੇ ਜਾਨ ਵਾਲੇ ਟੂਲਾਂ ਦੀ ਦੁਬਾਰਾ-ਪਰਖ।
ਭਾਵੇਂ ਇੱਕ ਐਪ "ਚੱਲਦਾ" ਹੋਵੇ, ਵੇਰਵੇ ਬਦਲ ਸਕਦੇ ਹਨ: ਇੱਕ ਪਲੱਗਇਨ ਲੋਡ ਨਹੀਂ ਹੁੰਦਾ, ਇੱਕ ਪ੍ਰਿੰਟਰ ਡ੍ਰਾਈਵਰ ਗੈਰ-ਮੌਜੂਦ ਹੈ, ਇੱਕ ਮੈਕਰੋ ਵੱਖਰੀ ਤਰ੍ਹਾਂ ਵਰਤਦਾ ਹੈ, ਇੱਕ ਗੇਮ ਐਂਟੀ-ਚੀਟ ਕੁਝ ਫਲੇਗ ਕਰਦਾ ਹੈ, ਜਾਂ ਇੱਕ ਨਿਸ਼ ਐਕਸੈਸਰੀ ਕੰਮ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੰਦੀ ਹੈ। ਹਰ ਇੱਕ ਨੁਕਤਾ ਛੋਟਾ ਹੁੰਦਾ ਹੈ; ਪਰ ਮਿਲ ਕੇ ਇਹ ਅਪਗਰੇਡ ਦਾ ਮੁੱਲ ਬਰਬਾਦ ਕਰ ਸਕਦੇ ਹਨ।
ਵੇਂਡਰ ਪਲੇਟਫਾਰਮ ਬਦਲਾਅ ਦਾ ਭੁਗਤਾਨ ਵਧ ਰਹੀ ਟੈਸਟ ਮੈਟ੍ਰਿਕਸ ਰਾਹੀਂ ਕਰਦੇ ਹਨ। ਇਹ ਸਿਰਫ਼ "ਕੀ ਇਹ ਲਾਂਚ ਹੁੰਦਾ ਹੈ?" ਹੀ ਨਹੀਂ ਹੈ। ਇਹ ਹੈ:
ਹਰ ਇਕ ਕੰਬੀਨੇਸ਼ਨ QA ਸਮਾਂ ਵਧਾਉਂਦਾ, ਹੋਰ ਡੌਕਯੂਮੈਂਟੇਸ਼ਨ ਜੋੜਦਾ, ਅਤੇ ਹੋਰ ਸਪੋਰਟ ਟਿਕਟ ਪੈਦਾ ਕਰਦਾ। ਇੱਕ ਟ੍ਰਾਂਜ਼ੀਸ਼ਨ ਇੱਕ ਪੇਸ਼ਗੋਈਯੋਗ ਰਿਲੀਜ਼ ਟ੍ਰੇਨ ਨੂੰ ਇੱਕ ਸਥਾਈ ਇਂਸੀਡੈਂਟ-ਰਿਸਪਾਂਸ ਚੱਕਰ ਵਿੱਚ ਬਦਲ ਸਕਦਾ ਹੈ।
ਡਿਵੈਲਪਰ ਲਾਇਬ੍ਰੇਰੀਆਂ ਪੋਰਟ ਕਰਨ, ਪ੍ਰਦਰਸ਼ਨ-ਸੰਵੇਦਨਸ਼ੀਲ ਕੋਡ ਦੁਬਾਰਾ ਲਿਖਣ (ਅਕਸਰ ISA ਲਈ ਹੈਂਡ-ਟਿਊਨ ਕੀਤੇ), ਅਤੇ ਆਟੋਮੇਟਡ ਟੈਸਟ ਦੁਬਾਰਾ ਬਣਾਉਣ ਦੀ ਲਾਗਤ ਸਹੇਤ ਹਨ। ਸਭ ਤੋਂ ਔਖਾ ਹਿੱਸਾ ਯਕੀਨ ਮੁੜ ਪ੍ਰਾਪਤ ਕਰਨਾ ਹੈ: ਨਵੀਂ ਬਿਲਡ ਸਹੀ, ਤੇਜ਼, ਅਤੇ ਅਸਲੀ ਵਰਕਲੋਡਾਂ ਹੇਠਾਂ ਸਥਿਰ ਹੈ ਇਹ ਸਾਬਤ ਕਰਨਾ।
ਮਾਈਗ੍ਰੇਸ਼ਨ ਕੰਮ ਨਵੇਂ ਫੀਚਰਾਂ ਨਾਲ ਸਿੱਧਾ ਮੁਕਾਬਲਾ ਕਰਦਾ ਹੈ। ਜੇ ਇੱਕ ਟੀਮ ਦੋ ਕ਼ਵਾਰਟਰ ਲਗਾਉਂਦੀ ਹੈ ਸਿਰਫ ਚੀਜ਼ਾਂ ਨੂੰ "ਮੁੜ ਠੀਕ ਕਰਨ" ਲਈ, ਤਾਂ ਇਹ ਦੋ ਕ਼ਵਾਰਟਰ ਉਹਨਾਂ ਨੇ ਉਤਪਾਦ ਸੁਧਾਰਨ ਵਿੱਚ ਨਹੀਂ ਗੁਜ਼ਾਰੇ।
ਬਹੁਤ ਸਾਰੀਆਂ ਸੰਸਥਾਵਾਂ ਸਿਰਫ਼ ਉਸ ਵੇਲਾਂ ਸਵਿੱਚ ਕਰਦੀਆਂ ਹਨ ਜਦ ਪੁਰਾਣਾ ਪਲੇਟਫਾਰਮ ਉਨ੍ਹਾਂ ਨੂੰ ਰੋਕਦਾ ਹੈ—ਜਾਂ ਨਵਾਂ ਬਹੁਤ ਆਕਰਸ਼ਕ ਹੋ ਜਾਏ ਕਿ ਉਹ ਇਸ ਤਰ੍ਹਾਂ ਦੀ ਬਦਲੀ ਦਾ ਭੁਗਤਾਨ ਕਰ ਲੈਂ।
ਜਦ ਇੱਕ ਨਵੀਂ CPU ਆਰਕੀਟੈਕਚਰ ਆਉਂਦੀ ਹੈ, ਉਪਭੋਗਤਾ instruction sets ਬਾਰੇ ਨਹੀਂ ਪੁੱਛਦੇ—ਉਹ ਪੁੱਛਦੇ ਹਨ ਕਿ ਕੀ ਉਹਨਾਂ ਦੀਆਂ ਐਪਸ ਹੁਣ ਵੀ ਖੁਲ੍ਹਾਂਗੀਆਂ। ਇਸ ਲਈ "ਪੁਲ" ਮ੍ਹਤਵਪੂਰਨ ਹਨ: ਉਹ ਨਵੀਆਂ ਮਸ਼ੀਨਾਂ ਨੂੰ ਪੁਰਾਣੇ ਸਾਫਟਵੇਅਰ ਚਲਾਉਣ ਦੇ ਯੋਗ ਬਣਾਉਂਦੇ ਹਨ ਜਦ ਤੱਕ ਇਕੋਸਿਸਟਮ ਫੈਟ ਨਹੀਂ ਲੈਂਦਾ।
ਏਮੂਲੇਸ਼ਨ ਸਾਫਟਵੇਅਰ ਵਿੱਚ ਪੂਰੇ CPU ਦੀ ਨਕਲ ਕਰਦਾ ਹੈ। ਇਹ ਸਭ ਤੋਂ ਅਨੁਕੂਲ ਵਿਕਲਪ ਹੈ, ਪਰ ਆਮ ਤੌਰ 'ਤੇ ਸਭ ਤੋਂ ਧੀਮਾ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਹਰ ਹੁਕਮ "ਅਭਿਨਯ" ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਬਜਾਏ ਇਸਦੇ ਕਿ ਉਹ ਸਿੱਧਾ ਚਲੇ।
ਬਾਈਨਰੀ ਤਰਜਮਾ (ਅਕਸਰ ਡਾਇਨਾਮਿਕ) x86 ਕੋਡ ਦੇ ਟੁਕੜੇ ਨੂੰ ਨਵੀ CPU ਦੀ ਮੂਲ ਹੁਕਮ-ਭਾਸ਼ਾ ਵਿੱਚ ਦੌਰਾਉਂਦਾ ਹੈ ਜਦ ਪ੍ਰੋਗਰਾਮ ਚੱਲਦਾ ਹੈ। ਇਹ ਕਈ ਆਧੁਨਿਕ ਟ੍ਰਾਂਜ਼ੀਸ਼ਨਾਂ ਦਾ ਦਿਨ-ਇੱਕ ਕਹਾਣੀ ਕੀਤਾ ਹੈ: ਆਪਣੇ ਮੌਜੂਦਾ ਐਪ ਇੰਸਟਾਲ ਕਰੋ, ਅਤੇ ਇੱਕ ਅਨੁਕੂਲਤਾ ਲੇਅਰ ਚੁਪਚਾਪ ਤਰਜਮਾ ਕਰ ਦਿੰਦੀ ਹੈ।
ਮੁੱਲ ਸਧਾਰਨ ਹੈ: ਤੁਸੀਂ ਨਵਾਂ ਹਾਰਡਵੇਅਰ ਖਰੀਦ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਹਰ ਵੇਂਡਰ ਦਾ ਰੀਕੰਪਾਈਲ ਹੋਣ ਦੀ ਉਡੀਕ ਕੀਤੇ।
ਅਨੁਕੂਲਤਾ ਪਰਤ ਆਮ ਤੌਰ 'ਤੇ ਮੱਖੀ, ভাল-ਵਿਵਹਾਰ ਵਾਲੀਆਂ ਐਪਾਂ ਲਈ ਸਾਸ਼ਤੀ ਕੰਮ ਕਰਦੀ ਹੈ—ਪਰ ਐਜ 'ਤੇ ਸੰਘਰਸ਼ ਕਰਦੀ ਹੈ:
ਹਾਰਡਵੇਅਰ ਸਹਿਯੋਗ ਅਕਸਰ ਅਸਲ ਰੋਕ ਹੈ।
ਵਰਚੁਅਲਾਈਜ਼ੇਸ਼ਨ ਉਨ੍ਹਾਂ ਹਾਲਾਤਾਂ ਵਿੱਚ ਮਦਦ ਕਰਦੀ ਹੈ ਜਦ ਤੁਹਾਨੂੰ ਪੂਰਾ ਲੇਗਸੀ ਮਾਹੌਲ ਚਾਹੀਦਾ ਹੈ (ਕਿਸੇ ਖਾਸ Windows ਵਰਜ਼ਨ, ਇੱਕ ਪੁਰਾਣਾ Java ਸਟੈਕ, ਇੱਕ ਲਾਈਨ-ਆਫ-ਬਿਜ਼ਨਸ ਐਪ)। ਇਹ ਪ੍ਰਚਲਿਤ ਤਰੀਕੇ ਨਾਲ ਸੁਥਰਾ ਹੈ—ਸਨੈਪਸ਼ਾਟ, ਆਈਸੋਲੇਸ਼ਨ, ਆਸਾਨ ਰੋਲਬੈਕ—ਪਰ ਇਹ ਇਸ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਕੀ ਵਰਚੁਅਲਾਈਜ਼ ਕਰ ਰਹੇ ਹੋ।
ਉਸੇ ਆਰਕੀਟੈਕਚਰ VM ਨੇਟਿਵ ਨਜ਼ਦੀਕੀ ਹੋ ਸਕਦੇ ਹਨ; ਆਰਕੀਟੈਕਚਰ-ਪਾਰ VM ਅਕਸਰ ਏਮੂਲੇਸ਼ਨ 'ਤੇ ਆ ਕੇ ਧੀਮੇ ਹੋ ਜਾਂਦੇ ਹਨ।
ਇੱਕ ਪੁਲ ਆਮ ਤੌਰ 'ਤੇ ਦਫ਼ਤਰ ਐਪ, ਬ੍ਰਾਊਜ਼ਰ ਅਤੇ ਹਰ-ਰੋਜ਼ ਦੀ ਪ੍ਰੋਡਕਟੀਵਿਟੀ ਲਈ ਕਾਫ਼ੀ ਹੁੰਦਾ ਹੈ—ਜਿੱਥੇ "ਤੇਜ਼ੀ ਨਾਲ ਕਾਫ਼ੀ" ਜਿੱਤਦੀ ਹੈ। ਇਹ ਖਤਰਨਾਕ ਹੈ ਜੇ:
ਅਮਲ ਵਿੱਚ, ਪੁਲ ਸਮਾਂ ਖਰੀਦਦੇ ਹਨ—ਪਰ ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਮਾਈਗ੍ਰੇਸ਼ਨ ਕੰਮ ਨੂੰ ਮੁਕੰਮਲ ਤੌਰ 'ਤੇ ਹਟਾਉਂਦੇ ਨਹੀਂ।
CPU ਬਾਰੇ ਤਰਕਬਾਜ਼ੀ ਅਕਸਰ ਇਕ ਹੀ ਸਕੋਰਬੋਰਡ ਵਰਗੀ ਲੱਗਦੀ ਹੈ: "ਤੇਜ਼ੀ ਜਿੱਤਦੀ ਹੈ"। ਅਸਲ ਵਿੱਚ, ਪਲੇਟਫਾਰਮ ਉਹੀ ਜਿੱਤਦਾ ਹੈ ਜੋ ਡਿਵਾਈਸਾਂ ਦੀਆਂ ਸੀਮਾਵਾਂ ਅਤੇ ਲੋਕ ਜਿਸ ਵਰਕਲੋਡ ਨੂੰ ਚਲਾਉਂਦੇ ਹਨ, ਨਾਲ ਮਿਲਦਾ ਹੈ।
x86 PCs ਲਈ ਡਿਫਾਲਟ ਬਣਿਆ ਕਿਉਂਕਿ ਇਸਨੇ ਵਾਲ-ਪਾਵਰ 'ਤੇ ਮਜ਼ਬੂਤ ਪੀਕ ਪ੍ਰਦਰਸ਼ਨ ਦਿੱਤਾ, ਅਤੇ ਉਦਯੋਗ ਨੇ ਬਾਕੀ ਸਭ ਕੁਝ ਉਸ ਅਨੁਮਾਨ ਦੇ ਆਸ-ਪਾਸ ਤਿਆਰ ਕੀਤਾ।
ਡੈਸਕਟਾਪ ਅਤੇ ਲੈਪਟਾਪ ਖਰੀਦਦਾਰਾਂ ਨੇ ਇਤਿਹਾਸਕ ਤੌਰ 'ਤੇ ਤੇਜ਼ ਰਿਸਪਾਂਸਿਵ ਇੰਟਰਐਕਟਿਵ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਇਨਾਮ ਦਿੱਤਾ: ਐਪ ਖੋਲ੍ਹਣਾ, ਕੋਡ ਕੰਪਾਈਲ ਕਰਨਾ, ਗੇਮਿੰਗ, ਭਾਰੀ ਸਪ੍ਰੈਡਸ਼ੀਟ। ਇਹ ਵੀਟਾਂ ਨੂੰ ਉੱਚ ਬੂਸਟ ਘੜੀਆਂ, ਵਿਆਪਕ ਕੋਰ, ਅਤੇ aggressive turbo ਵਿਹਾਰ ਵੱਲ ਧਕਿਆ—ਜੋ ਵਾਟਸ ਖਰਚਣ 'ਤੇ ਬਹੁਤ ਚੰਗਾ ਹੈ।
ਪਾਵਰ ਕੁਸ਼ਲਤਾ ਇੱਕ ਵੱਖਰਾ ਖੇਡ ਹੈ। ਜੇ ਤੁਹਾਡਾ ਉਤਪਾਦ ਬੈਟਰੀ, ਤਾਪ, ਫੈਨ ਸ਼ੋਰ, ਜਾਂ ਪਤਲੇ ਚੇਸਿਸ ਦੁਆਰਾ ਸੀਮਤ ਹੈ, ਤਾਂ ਸਭ ਤੋਂ ਵਧੀਆ CPU ਉਹ ਹੈ ਜੋ ਹਰ ਵਾਟ ਲਈ "ਕਾਫ਼ੀ" ਕੰਮ ਕਰਦਾ ਹੈ, ਲਗਾਤਾਰ, ਬਿਨਾਂ throttling ਦੇ।
ਕੁਸ਼ਲਤਾ ਸਿਰਫ਼ ਊਰਜਾ ਬਚਾਉਣ ਬਾਰੇ ਨਹੀਂ; ਇਹ ਇਸ ਬਾਰੇ ਹੈ ਕਿ ਤਾਪਮਾਨ ਸੀਮਾਵਾਂ ਦੇ ਅੰਦਰ ਰਹਿ ਕੇ ਪ੍ਰਦਰਸ਼ਨ ਕਾਇਮ ਰਹੇ।
ਫੋਨ ਅਤੇ ਟੈਬਲੈਟ ਸਖ਼ਤ ਪਾਵਰ ਘੇਰੇ ਵਿੱਚ ਰਹਿੰਦੇ ਹਨ ਅਤੇ ਵੱਡੇ ਵੋਲਿਊਮ 'ਤੇ ਲਾਗਤ-ਸੰਵੇਦਨਸ਼ੀਲ ਰਹੇ ਹਨ। ਇਹ ਉਸ ਡਿਜ਼ਾਈਨ ਨੂੰ ਤਰਜੀਹ ਦਿੱਤਾ ਜਿਹੜੀ ਕੁਸ਼ਲਤਾ ਉੱਤੇ ਕੇਂਦਰਿਤ ਸੀ, ਇੰਟੀਗ੍ਰੇਟਡ ਕੰਪੋਨੈਂਟਸ, ਅਤੇ ਪੂਰੇ ਤੌਰ 'ਤੇ ਭਵਿੱਖ-ਕਦਮ OS ਅਤੇ ਐਪ ਸਟੈਕ ਨਾਲ ਵਿਕਸਿਤ ਹੋਈ।
ਇਸ ਨਾਲ ਐਕੋਸਿਸਟਮ ਤਿਆਰ ਹੋਇਆ ਜਿੱਥੇ OS, ਐਪਸ ਅਤੇ ਸਿਲੀਕਨ ਮਿਲ ਕੇ ਮੋਬਾਇਲ-ਪਹਿਲੇ ਅਨੁਮਾਨਾਂ ਹੇਠਾਂ ਵਿਕਸਤ ਹੋਏ।
ਡੇਟאַסੈਂਟਰਾਂ ਵਿੱਚ CPU ਚੋਣ ਆਮ ਤੌਰ 'ਤੇ ਸਿਰਫ਼ ਬੈਨਚਮਾਰਕ ਨਹੀਂ ਹੁੰਦੀ। অপਰੇਟਰ ਨਿਰਭਰਤਾ ਫੀਚਰਾਂ, ਲੰਮੀ ਸਪੋਰਟ ਵਿੰਡੋ, ਸਥਿਰ ਫਰਮਵੇਅਰ, ਮੋਨੀਟਰੀੰਗ, ਅਤੇ ਡ੍ਰਾਈਵਰ/ਹਾਇਪਰਵਾਈਜ਼ਰ/ਮੈਨੇਜਮੈਂਟ ਟੂਲ ਦੇ ਵਿਕਸਤ ਇਕੋਸਿਸਟਮ 'ਤੇ ਧਿਆਨ ਦਿੰਦੇ ਹਨ।
ਇਕ ਨਵੀਂ ਆਰਕੀਟੈਕਚਰ perf/watt 'ਤੇ ਆਕਰਸ਼ਕ ਲੱਗੇ, ਪਰ ਆਪਰੇਸ਼ਨਲ ਅਚਾਨਕੀ ਖਤਰੇ ਲਾਭ ਨੂੰ ਓਵਰਵੇਟ ਕਰ ਸਕਦੇ ਹਨ।
ਆਧੁਨਿਕ ਸਰਵਰ ਵਰਕਲੋਡ ਵੱਖ-ਵੱਖ ਹਨ: ਵੈੱਬ ਸਰਵਿੰਗ ਉੱਚ throughput ਅਤੇ ਕੁਸ਼ਲ ਸਕੇਲਿੰਗ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦੀ; ਡੇਟਾਬੇਸ ਮੈਮੋਰੀ bandwidth, ਲੇਟੈਂਸੀ ਸੁਚਿੱਤਤਾ ਅਤੇ ਟਿਊਨਿੰਗ ਨੂੰ ਇਨਾਮ ਦਿੰਦੇ ਹਨ; AI ਤੇਜ਼ੀ ਨਾਲ ਐਕਸਲੇਰੇਟਰ ਅਤੇ ਸਾਫਟਵੇਅਰ ਸਟੈਕ ਦੀ ਕੀਮਤ ਵਾਧਾ ਕਰ ਰਿਹਾ ਹੈ।
ਜਿਵੇਂ-ਜਿਵੇਂ ਮਿਸ਼ਰਣ ਬਦਲਦਾ ਹੈ, ਜਿੱਤੂ ਪਲੇਟਫਾਰਮ ਵੀ ਬਦਲ ਸਕਦਾ ਹੈ—ਪਰ ਇਹ ਸਿਰਫ਼ ਤਦ ਹੀ ਹੋ ਸਕਦਾ ਹੈ ਜਦ ਆਸ-ਪਾਸ ਦਾ ਇਕੋਸਿਸਟਮ ਨਾਲ ਕਦਮ ਮਿਲਾ ਲਏ।
ਇੱਕ ਨਵੀਂ CPU ਆਰਕੀਟੈਕਚਰ ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ ਸ਼ਾਨਦਾਰ ਹੋ ਸਕਦੀ ਹੈ ਫਿਰ ਵੀ ਫੇਲ ਹੋ ਸਕਦੀ ਹੈ ਜੇ ਰੋਜ਼ਾਨਾ ਦੀਆਂ ਟੂਲਾਂ ਇਸਨੂੰ ਬਿਲਡ, ਸ਼ਿਪ ਅਤੇ ਸਪੋਰਟ ਕਰਨਾ ਆਸਾਨ ਨਾ ਬਣਾਉਣ। ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਲਈ, "ਪਲੇਟਫਾਰਮ" ਸਿਰਫ ISA ਨਹੀਂ—ਇਹ ਪੂਰਾ ਡਿਲਿਵਰੀ ਪਾਈਪਲਾਈਨ ਹੈ।
ਕੰਪਾਇਲਰ, ਡੀਬੱਗਰ, ਪ੍ਰੋਫ਼ਾਈਲਰ, ਅਤੇ ਕੋਰ ਲਾਇਬ੍ਰੇਰੀਆਂ ਚੁਪਚਾਪ ਡਿਵੈਲਪਰ ਰਿਵਾਇਤ ਨੂੰ ਆਕਾਰ ਦਿੰਦੀਆਂ ਹਨ। ਜੇ ਸਭ ਤੋਂ ਵਧੀਆ ਕੰਪਾਇਲਰ ਫਲੈਗ, ਸਟੈਕ ਟਰੇਸ, ਸੈਨਿਟਾਈਜ਼ਰ, ਜਾਂ ਪ੍ਰਦਰਸ਼ਨ ਟੂਲ ਦੇਰ ਨਾਲ ਆਉਂਦੇ ਹਨ (ਜਾਂ ਵੱਖਰੇ ਤਰੀਕੇ ਨਾਲ ਚਲਦੇ ਹਨ), ਟੀਮਾਂ ਨਵੇਂ ਪਲੇਟਫਾਰਮ 'ਤੇ ਜ਼ੋਰ ਨਾਲ ਨਹੀਂ ਸ਼ੁਰੂ ਕਰਦੀਆਂ।
ਛੋਟੇ ਗੈਪ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹਨ: ਇੱਕ ਗੁੰਮ ਲਾਇਬ੍ਰੇਰੀ, ਇੱਕ ਫਲੇਕੀ ਡੀਬੱਗਰ ਪਲੱਗਇਨ, ਜਾਂ ਇੱਕ ਹੌਲੀ CI ਬਿਲਡ "ਅਸੀਂ ਇਸ ਕੌਰਟਰ ਵਿੱਚ ਪੋਰਟ ਨਹੀਂ ਕਰਾਂਗੇ" ਨੂੰ ਬਦਲ ਸਕਦਾ ਹੈ। ਜਦ x86 ਟੂਲਚੇਨ IDEs, ਬਿਲਡ ਸਿਸਟਮ ਅਤੇ CI ਟੈਮਪਲੇਟਸ ਵਿੱਚ ਡਿਫਾਲਟ ਹੁੰਦੀ ਹੈ, ਆਸਾਨ ਰਾਹ ਮੁੜ-ਮੁੜ ਵਾਪਸ ਖਿੱਚਦਾ ਹੈ।
ਸਾਫਟਵੇਅਰ ਇੰਸਟਾਲਰ, ਅਪਡੇਟਰ, ਰਿਪੋਜ਼ਟਰੀ, ਐਪ ਸਟੋਰ, ਕੰਟੇਨਰ, ਅਤੇ ਸਾਈਨ ਕੀਤੇ ਬਾਈਨਰੀਆਂ ਵਰਗੀਆਂ ਪੈਕਿੰਗ ਪ੍ਰਥਾਵਾਂ ਰਾਹੀਂ ਉਪਭੋਗਤਿਆਂ ਤੱਕ ਪਹੁੰਚਦੀ ਹੈ। ਇੱਕ ਪਲੇਟਫਾਰਮ ਬਦਲਾਅ ਇਹ ਸਵਾਲ ਖੜੇ ਕਰਦਾ ਹੈ:
ਜੇ ਡਿਸਟ੍ਰਿਬਿਊਸ਼ਨ ਗੰਦੀ ਹੋ ਜਾਂਦੀ ਹੈ, ਸਪੋਰਟ ਲਾਗਤ ਤੇਜ਼ੀ ਨਾਲ ਵੱਧ ਜਾਂਦੀ ਹੈ—ਅਤੇ ਕਈ ਵੇਂਡਰ ਇਸ ਤੋਂ ਬਚਣਗੇ।
ਕਾਰੋਬਾਰ ਉਹ ਪਲੇਟਫਾਰਮ ਖਰੀਦਦੇ ਹਨ ਜੋ ਉਹ ਸਕੇਲ 'ਤੇ ਪ੍ਰਬੰਧ ਕਰ ਸਕਦੇ ਹਨ: ਇਮੇਜਿੰਗ, ਡਿਵਾਈਸ ਐਨਰੋਲਮੈਂਟ, ਨੀਤੀਆਂ, ਐਂਡਪਾਇੰਟ ਸੁਰੱਖਿਆ, EDR ਏਜੰਟ, VPN ਕਲਾਇੰਟ, ਅਤੇ ਅਨੁਕੂਲਤਾ ਰਿਪੋਰਟਿੰਗ। ਜੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਨਵੀਂ ਆਰਕੀਟੈਕਚਰ 'ਤੇ ਪਿੱਛੇ ਰਹਿ ਜਾਂਦੀ ਹੈ, ਪਾਇਲਟ ਰੁਕ ਜਾਂਦਾ ਹੈ।
"ਮੇਰੀ ਮਸ਼ੀਨ 'ਤੇ ਚੱਲਦਾ ਹੈ" ਅਣਭੇਦਿਆ ਹੈ ਜੇ IT ਇਹ ਤੈਅ ਨਹੀਂ ਕਰ ਸਕਦੀ ਕਿ ਕਿਵੇਂ ਡਿਪਲੋਯ ਕਰਨਾ ਅਤੇ ਸੁਰੱਖਿਅਤ ਕਰਨਾ ਹੈ।
ਡਿਵੈਲਪਰ ਅਤੇ IT ਇਕ ਵਿਅਵਹਾਰਕ ਸਵਾਲ 'ਤੇ ਇਕਠੇ ਹੁੰਦੇ ਹਨ: ਅਸੀਂ ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਅਤੇ ਸਪੋਰਟ ਕਰ ਸਕਦੇ ਹਾਂ? ਟੂਲਿੰਗ ਅਤੇ ਡਿਸਟ੍ਰਿਬਿਊਸ਼ਨ ਅਕਸਰ ਇਸ ਸਵਾਲ ਨੂੰ ਕੱਚੀ ਬੈਨਚਮਾਰਕਸ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਨਿਰਣਾਇਕ ਬਣਾਉਂਦੇ ਹਨ।
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਤਰੀਕਾ ਟੀਮਾਂ ਨੂੰ ਮਾਈਗ੍ਰੇਸ਼ਨ ਘਟਾਉਣ ਲਈ ਹੈ ਸੌਖੇ ਨਾਲ ਵਿਚਾਰ ਤੋਂ ਇੱਕ ਟੈਸਟੇਬਲ ਬਿਲਡ ਤੱਕ ਦਾ ਸਮਾਂ ਘੱਟ ਕਰਨਾ—ਖ਼ਾਸ ਕਰਕੇ ਜਦ ਇਕੋ ਐਪ ਨੂੰ ਵੱਖ-ਵੱਖ ਵਾਤਾਵਰਣਾਂ (x86 v/s ARM, ਵੱਖ-ਵੱਖ OS ਇਮੇਜ, ਜਾਂ ਵੱਖ-ਵੱਖ ਡਿਪਲੋਯ ਟਾਰਗੇਟ) 'ਤੇ ਜਾਂਚਣਾ ਹੋਵੇ।
Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ ਇਸ ਵਰਕਫਲੋ ਵਿੱਚ ਫਿੱਟ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਟੀਮਾਂ ਨੂੰ ਇੱਕ ਚੈਟ ਇੰਟਰਫੇਸ ਰਾਹੀਂ ਅਸਲ ਐਪ ਬਣਾਉਣ ਅਤੇ ਇਤਰੈਸ਼ਨ ਕਰਨ ਦੀ ਆਸਾਨੀ ਦਿੰਦੇ ਹਨ—ਅਕਸਰ React-ਆਧਾਰਿਤ ਵੇੱਬ ਫਰੰਟਐਂਡ, Go ਬੈਕਐਂਡ, ਅਤੇ PostgreSQL ਡੇਟਾਬੇਸ (ਤੇ ਮੋਬਾਈਲ ਲਈ Flutter)। ਪਲੇਟਫਾਰਮ-ਟ੍ਰਾਂਜ਼ੀਸ਼ਨ ਕੰਮ ਲਈ ਦੋ ਖ਼ਾਸ ਯੋਗਤਾਵਾਂ ਮਹੱਤਵਪੂਰਨ ਹਨ:
ਕਿਉਂਕਿ Koder.ai source code export ਨੂੰ ਸਮਰਥਨ ਕਰਦਾ ਹੈ, ਇਹ ਪ੍ਰਯੋਗ ਅਤੇ ਇੱਕ ਪ੍ਰਵਾਨਗੀ ਇੰਜਣ ਦੇ درمیان ਇੱਕ ਪੁਲ ਵਜੋਂ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ—ਜਦ ਤੁਹਾਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਆਜ਼ਮਾਉਣਾ ਹੋਵੇ, ਪਰ ਫਿਰ ਵੀ ਰੱਖ ਰਹਿਣ ਯੋਗ ਕੋਡ ਆਪਣੇ ਰੇਪੋ ਵਿੱਚ ਚਾਹੀਦਾ ਹੋਵੇ।
ARM ਦਾ ਲੈਪਟਾਪਾਂ ਅਤੇ ਡੈਸਕਟਾਪਾਂ ਵਿੱਚ ਦਾਖ਼ਲਾ ਇਹ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਪਲੇਟਫਾਰਮ ਟ੍ਰਾਂਜ਼ੀਸ਼ਨ ਅਸਲ ਵਿੱਚ ਕਿੰਨੇ ਮੁਸ਼ਕਲ ਹਨ। ਕਾਗਜ਼ 'ਤੇ ਪਿਚ ਸਧਾਰਣ ਹੈ: ਵਧੀਆ performance-per-watt, ਸ਼ਾਂਤ ਮਸ਼ੀਨਾਂ, ਲੰਬੀ ਬੈਟਰੀ ਲਾਈਫ। ਹਰਅਸਲ, ਸਫਲਤਾ CPU ਕੋਰ ਤੋਂ ਘੱਟ ਅਤੇ ਉਸਦੇ ਆਲੇ-ਦੁਆਲੇ ਦੀ ਹਰ ਚੀਜ਼—ਐਪਸ, ਡ੍ਰਾਈਵਰ, ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨ, ਅਤੇ ਜੋ ਪ੍ਰੇਰਨਾ ਇਕੱਠਾ ਕਰਦੀ ਹੈ—ਉੱਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ।
Apple ਦਾ Intel ਤੋਂ Apple Silicon ਤੱਕ ਦਾ ਮੂਵ ਇਸ ਲਈ ਕਾਰਗਰ ਰਿਹਾ ਕਿਉਂਕਿ Apple ਪੂਰੇ ਸਟੈਕ 'ਤੇ ਕਾਬੂ ਰੱਖਦਾ ਹੈ: ਹਾਰਡਵੇਅਰ ਡਿਜ਼ਾਈਨ, ਫਰਮਵੇਅਰ, ਓਐਸ, ਡਿਵੈਲਪਰ ਟੂਲ, ਅਤੇ ਮੁੱਖ ਐਪ-distribution ਚੈਨਲ।
ਇਸ ਕਾਬੂ ਨੇ ਕੰਪਨੀ ਨੂੰ ਇੱਕ ਸਾਫ਼ ਤਬਦੀਲੀ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੱਤੀ ਬਿਨਾਂ ਦਰਜਨਾਂ ਅਜ਼ਾਦ ਭਾਗੀਦਾਰਾਂ ਦੇ ਇਕੱਠੇ ਹੋਣ ਦੀ ਉਡੀਕ ਕੀਤੇ।
ਇਸ ਨੇ ਇੱਕ ਸੰਯੋਜਿਤ "ਪੁਲ" ਅਵਧੀ ਵੀ ਯੋਜਿਤ ਕੀਤੀ: ਵਿਕਾਸਕਾਰਾਂ ਨੂੰ ਸਪਸ਼ਟ ਟਾਰਗੇਟ ਮਿਲੇ, ਉਪਭੋਗਤਿਆਂ ਨੂੰ ਅਨੁਕੂਲਤਾ ਰਾਹ ਮਿਲੇ, ਅਤੇ Apple ਕੁਝ ਮੁੱਖ ਵੇਂਡਰਾਂ ਤੇ ਦਬਾਅ ਰੱਖ ਕੇ ਨੈਟਿਵ ਬਿਲਡ ਲੈਣ ਲਈ ਪ੍ਰੇਰਿਤ ਕਰ ਸਕਦਾ ਸੀ। ਜੇਕਰ ਕੁਝ ਐਪ ਨੈਟਿਵ ਨਹੀਂ ਵੀ ਸੀ, ਤਦ ਵੀ ਉਪਭੋਗਤਾ ਅਨੁਭਵ ਲੋਕਾਂ ਲਈ ਕਈ ਵਾਰੀ ਕਬੂਲਯੋਗ ਰਹਿੰਦਾ ਕਿਉਂਕਿ ਟ੍ਰਾਂਜ਼ੀਸ਼ਨ ਯੋਜਨਾ ਇੱਕ ਪ੍ਰੋਡਕਟ ਵਜੋਂ ਡਿਜ਼ਾਇਨ ਕੀਤੀ ਗਈ ਸੀ, ਸਿਰਫ ਪ੍ਰੋਸੈਸਰ ਸਵੈਪ ਨਹੀਂ।
Windows-on-ARM ਦੂਜੀ ਪਾਸੀ ਵਧੀਆ ਉਦਾਹਰਨ ਹੈ। Microsoft ਪੂਰੇ ਹਾਰਡਵੇਅਰ ਇਕੋਸਿਸਟਮ 'ਤੇ ਪੂਰਾ ਕਾਬੂ ਨਹੀਂ ਰੱਖਦਾ, ਅਤੇ Windows PCs OEM ਚੋਣਾਂ ਅਤੇ ਲੰਬੇ-ਪੂਛ ਵਾਲੇ ਡ੍ਰਾਈਵਰਾਂ 'ਤੇ ਬਹੁਤ ਨਿਰਭਰ ਹਨ।
ਇਸ ਨਾਲ ਆਮ ਤੋੜ-ਛਾੜ ਪੈਦਾ ਹੁੰਦੇ ਹਨ:
ARM ਦੀਆਂ ਹਾਲੀਆ ਤਰੱਕੀਆਂ ਇੱਕ ਮੁੱਖ ਪਾਠ ਨੂੰ ਪੁਸ਼ਟ ਕਰਦੀਆਂ ਹਨ: ਜੇ ਤੁਸੀਂ ਸਟੈਕ ਦੇ ਹੋਰ ਹਿੱਸਿਆਂ 'ਤੇ ਵੱਧ ਕਾਬੂ ਰੱਖਦੇ ਹੋ ਤਾਂ ਟ੍ਰਾਂਜ਼ੀਸ਼ਨ ਤੇਜ਼ ਅਤੇ ਘੱਟ ਵਿਖੰਡਿਤ ਬਣਦੀ ਹੈ।
ਜੇ ਤੁਸੀਂ ਭਾਗੀਦਾਰਾਂ 'ਤੇ ਨਿਰਭਰ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਬਹੁਤ ਮਜ਼ਬੂਤ ਸਹਿਕਾਰ, ਸਪਸ਼ਟ ਅਪਗਰੇਡ ਰਾਹ, ਅਤੇ ਹਰ ਭਾਗੀਦਾਰ (ਚਿਪ ਵੇਂਡਰ, OEM, ਡਿਵੈਲਪਰ, ਅਤੇ IT ਖਰੀਦਦਾਰ) ਲਈ ਪ੍ਰੇਰਣਾ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਕਿ ਉਹ ਇੱਕੋ ਸਮੇਂ ਤੇ ਸਰਗਰਮ ਹੋਣ।
ਪਲੇਟਫਾਰਮ ਸ਼ਿਫਟ ਅਕਸਰ ਨਿਰਾਸ਼ਜਨਕ ਕਾਰਨਾਂ ਕਰਕੇ ਫੇਲ ਹੁੰਦੇ ਹਨ: ਪੁਰਾਣਾ ਪਲੇਟਫਾਰਮ ਅਜੇ ਵੀ ਕੰਮ ਕਰਦਾ ਹੈ, ਹਰ ਕੋਈ ਪਹਿਲਾਂ ਹੀ ਇਸ 'ਤੇ ਪੈਸਾ ਅਤੇ ਆਦਤਾਂ ਦੀ ਰੂਪ ਵਿੱਚ ਭੁਗਤਾਨ ਕਰ ਚੁੱਕਾ ਹੈ, ਅਤੇ "ਐਜ-ਕੇਸ" ਉਹیں ਹਨ ਜਿੱਥੇ ਵਾਸਤਵਿਕ ਕਾਰੋਬਾਰ ਰਹਿੰਦੇ ਹਨ।
ਇੱਕ ਨਵਾਂ ਪਲੇਟਫਾਰਮ ਮੁਕੰਮਲ ਤੌਰ 'ਤੇ ਤਬ ਜਿੱਤਦਾ ਹੈ ਜਦ ਤਿੰਨ ਚੀਜ਼ਾਂ ਇਕੱਠੇ ਹੋਣ:
ਸਫਲ ਟ੍ਰਾਂਜ਼ੀਸ਼ਨ ਸਵਿੱਚ ਦੀ ਤਰ੍ਹਾਂ ਨਹੀਂ ਲੱਗਦੇ; ਉਹ ਨਿਯੰਤਰਿਤ ਓਵਰਲੈਪ ਵਾਂਗ ਹੁੰਦੇ ਹਨ। ਪੇਸ਼ਕ ਐਲਾਨ (pilot groups), ਦੋਹਾਂ ਬਿਲਡ (ਪੁਰਾਣਾ + ਨਵਾਂ), ਅਤੇ ਟੈਲੀਮੇਟਰੀ (ਕ੍ਰੈਸ਼ ਦਰ, ਪ੍ਰਦਰਸ਼ਨ, ਫੀਚਰ ਉਪਯੋਗ) ਟੀਮਾਂ ਨੂੰ ਸ਼ੁਰੂ਼ ਵਿੱਚ ਸਮੱਸਿਆਵਾਂ ਫੜਨ ਲਈ ਆਸਾਨੀ ਦਿੰਦੇ ਹਨ।
ਇਸ ਨਾਲੋਂ ਮਹੱਤਵਪੂਰਨ: ਪੁਰਾਣੇ ਪਲੇਟਫਾਰਮ ਲਈ ਪ੍ਰਕਾਸ਼ਿਤ ਸਪੋਰਟ ਵਿਂਡੋ, ਅੰਦਰੂਨੀ ਅਸੀਂ-ਕਦਮਾਂ ਦੇ ਨਿਰਧਾਰਤ ਸਮਾਂ-सीਮਾ, ਅਤੇ "ਹਾਲੇ ਨਹੀਂ ਜਾ ਸਕਦਿਆਂ" ਉਪਭੋਗਤਿਆਂ ਲਈ ਯੋਜਨਾ।
ਇਸਨੂੰ ਇੱਕ ਨਿਯੰਤਰਿਤ ਰੋਲਆਊਟ ਦੇ ਤੌਰ 'ਤੇ ਇਲਾਜ ਕਰੋ, ਨਾ ਕਿ ਇੱਕ ਵੱਡਾ ਇਕ-ਛੱਡਿਆ-ਵਾਰ Swap ਵਜੋਂ।
x86 ਅਜੇ ਵੀ ਵੱਡਾ ਗਤੀਸ਼ੀਲ ਹੈ: ਦਹਾਕਿਆਂ ਦੀ ਅਨੁਕੂਲਤਾ, ਗੁੰਝਲਦਾਰ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਵਰਕਫ਼ਲੋਜ਼, ਅਤੇ ਵਿਸ਼ਾਲ ਹਾਰਡਵੇਅਰ ਵਿਕਲਪ।
ਪਰ ਦਬਾਅ ਵੀ ਬਣਦਾ ਜਾ ਰਿਹਾ ਹੈ: ਨਵੀਆਂ ਲੋੜਾਂ—ਪਾਵਰ ਕੁਸ਼ਲਤਾ, ਵਧੀਕ ਇੰਟੀਗ੍ਰੇਸ਼ਨ, AI-ਕੇਂਦਰਿਤ ਕੰਪਿਊਟ, ਅਤੇ ਸਧਾਰਣ ਡਿਵਾਈਸ ਫਲੀਟ। ਸਭ ਤੋਂ ਔਖੇ ਜੰਗਾਂ ਕਚੀ ਰਫ਼ਤਾਰ ਜ਼ਿੰਦਾ ਨਹੀਂ ਰਹਿੰਦੀਆਂ; ਇਹ ਉਸ ਬਾਰੇ ਹਨ ਕਿ ਪਲੇਟਫਾਰਮ ਬਦਲਣ ਨੂੰ ਸੁਰੱਖਿਅਤ, ਪੇਸ਼ਗੋਈਯੋਗ, ਅਤੇ ਕਿਮਤੀ ਕਿਵੇਂ ਬਣਾਇਆ ਜਾਵੇ।
x86 ਇੱਕ CPU instruction set architecture (ISA) ਹੈ: ਉਹ ਮਸ਼ੀਨ-ਭਾਸ਼ਾ ਹੁਕਮਾਂ ਦਾ ਸੈੱਟ ਜਿਨ੍ਹਾਂ 'ਤੇ ਸਾਫਟਵੇਅਰ ਆਖ਼ਰੀ ਤੌਰ 'ਤੇ ਚਲਦਾ ਹੈ।
“Dominance” ਇਸ ਪੋਸਟ ਵਿੱਚ ਮਾਤਰ ਬੇੰਚਮਾਰਕ ਲੀਡਰਸ਼ਿਪ ਨਹੀਂ ਦੱਸਦਾ; ਇਹ ਕਈ ਪੱਖਾਂ ਦੀ ਕੁਟੇ-ਫਾਇਦਾ ਹੈ: ਵੱਡੀ ਸ਼ਿਪਮੈਂਟ ਵੋਲਿਊਮ, ਸਭ ਤੋਂ ਵੱਡੀ ਐਪ ਕੈਟਾਲੌਗ, ਅਤੇ ਡਿਫਾਲਟ ਮਨਸ਼ੇਅਰ।
ਇਕ ISA ਉਹ “ਭਾਸ਼ਾ” ਹੈ ਜੋ CPU ਸਮਝਦਾ ਹੈ।
ਜੇ ਕੋਈ ਐਪ x86 ਲਈ ਕੰਪਾਇਲ ਹੈ, ਤਾਂ ਉਹ x86 CPUs 'ਤੇ ਨੈਟਿਵ ਤੌਰ 'ਤੇ ਚਲਦੀ ਹੈ। ਜੇ ਤੁਸੀਂ ਕਿਸੇ ਹੋਰ ISA (ਜਿਵੇਂ ARM) 'ਤੇ ਵੱਧਦੇ ਹੋ, ਤਾਂ ਆਮ ਤੌਰ 'ਤੇ ਤੁਹਾਨੂੰ ਇੱਕ ਨੈਟਿਵ ਰੀਬਿਲਡ ਦੀ ਲੋੜ ਪਵੇਗੀ, ਜਾਂ ਤੁਸੀਂ ਪੁਰਾਣੇ ਬਾਈਨਰੀ ਨੂੰ ਚਲਾਉਣ ਲਈ {translation/emulation} 'ਤੇ ਨਿਰਭਰ ਹੋਵੋਗੇ।
ਬੈਕਵਰਡ ਕੰਪੈਟਿਬਿਲਟੀ ਨਵੇਂ ਮਸ਼ੀਨਾਂ ਨੂੰ ਘੱਟ ਬਦਲਾਅ ਦੇ ਨਾਲ ਪੁਰਾਣਾ ਸਾਫਟਵੇਅਰ ਚਲਾਉਣ ਦੇ ਯੋਗ ਬਨਾਉਂਦੀ ਹੈ।
PC ਸੰਸਾਰ ਵਿੱਚ ਇਹ ਉਮੀਦ ਇੱਕ ਪ੍ਰੋਡਕਟ ਵਜੋਂ ਬਣ ਗਈ ਹੈ: ਅੱਪਗਰੇਡਾਂ ਨੂੰ ਤੁਹਾਨੂੰ ਐਪ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣ, ਵਰਕਫਲੋਜ਼ ਬਦਲਣ ਜਾਂ ਉਸ ਇੱਕ ਲੇਗਸੀ ਟੂਲ ਨੂੰ ਛੱਡਣ ਲਈ ਮਜ਼ਬੂਰ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ ਜੋ ਹੁਣ ਵੀ ਲਾਜ਼ਮੀ ਹੈ।
ਉਹ ਇਹ ਤਰੀਕਾ ਹੈ ਕਿ ਚਿਪ ਹੁਕਮਾਂ ਨੂੰ ਕਿਵੇਂ ਚਲਾਉਂਦੀ ਹੈ (microarchitecture) ਬਦਲ ਸਕਦੀ ਹੈ ਪਰ ਹੁਕਮਾਂ ਆਪ (ISA) ਨੂੰ ਮੁੱਖ ਤੌਰ 'ਤੇ ਜਿਵੇਂ ਦਾ ਤਿਵੇਂ ਰੱਖ ਸਕਦੀ ਹੈ।
ਇਸ ਲਈ ਤੁਸੀਂ ਪ੍ਰਦਰਸ਼ਨ, cache, ਅਤੇ ਪਾਵਰ ਵਿਵਹਾਰ ਵਿੱਚ ਵੱਡੇ ਬਦਲਾਅ ਵੇਖ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਪੁਰਾਣੇ ਬਾਈਨਰੀਜ਼ ਨੂੰ ਤੋੜੇ।
ਆਮ ਤੋੜ-ਛਾੜ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ:
ਅਕਸਰ “ਮੁੱਖ ਐਪ” ਚੱਲ ਰਹੀ ਹੁੰਦੀ ਹੈ, ਪਰ ਆਸ-ਪਾਸ ਦੀ 'ਗਲੂ' ਕੰਮ ਨਹੀਂ ਕਰਦੀ।
ਅਕਸਰ ਇਹ ਲੋਸਟ ਡ੍ਰਾਈਵਰ ਜਾਂ ਅਨੁਕੂਲ ਨ ਹੋਣ ਵਾਲਾ ਪੈਰੀਫੇਰਲ ਹੁੰਦਾ ਹੈ ਜੋ ਮਾਈਗ੍ਰੇਸ਼ਨ ਨੂੰ ਰੋਕਦਾ ਹੈ।
ਇਕ ਅਨੁਕੂਲਤਾ ਪਰਤ ਐਪ ਨੂੰ ਤਰਜਮਾ ਕਰ ਸਕਦੀ ਹੈ, ਪਰ ਇਹ ਕਿਸੇ ਨਿਸ਼ ਚੀਜ਼ ਲਈ ਇੱਕ ਪੱਕਾ ਕਰਨਲ ਡ੍ਰਾਈਵਰ ਬਣਾਕੇ ਨਹੀਂ ਦੇ ਸਕਦੀ ਜੇ ਵੇਂਡਰ ਉਸ ਨੂੰ ਕਦੇ ਨਹੀਂ ਜਾਰੀ ਕਰਦਾ।
ਇੰਸਟਾਲਡ ਬੇਸ ਵਿਕਾਸਕਾਂ ਦੀ ਕੋਸ਼ਿਸ਼ ਨੂੰ ਦਿਸ਼ਾ ਦਿੰਦਾ ਹੈ।
ਜੇ ਤੁਹਾਡੇ ਜ਼ਿਆਦਾਤਰ ਗਾਹਕ Windows x86 'ਤੇ ਹਨ, ਤਾਂ ਵਿਕਰੇਤਾ ਉਸੀ ਬਿਲਡ, ਟੈਸਟ ਅਤੇ ਸਪੋਰਟ ਪਲੇਅਬੁੱਕ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦੇ ਹਨ। ਹੋਰ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਸਹਿਯੋਗ ਦੇਣ ਦਾ ਮਤਲਬ ਵੱਧ CI ਬਿਲਡ, QA ਮੇਟ੍ਰਿਕਸ, ਡੌਕਯੂਮੈਂਟੇਸ਼ਨ ਅਤੇ ਸਹਾਇਤਾ ਦਾ ਭਾਰ — ਜਿਸ ਨੂੰ ਕਈ ਟੀਮ ਤਦ ਤੱਕ ਮੁੜਦਾ ਹੈ ਜਦ ਤੱਕ ਮੰਗ ਸਪੱਸ਼ਟ ਨਾ ਹੋਵੇ।
ਸਿਰਫ਼ ਰੀਕੰਪਾਇਲ ਕਰਨਾ ਕਾਫ਼ੀ ਨਹੀਂ।
ਰੀਕੰਪਾਇਲਿੰਗ صرف ਇੱਕ ਹਿੱਸਾ ਹੈ। ਤੁਹਾਨੂੰ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ:
ਸਭ ਤੋਂ ਮੁਸ਼ਕਲ ਹਿਸਾ ਇਹ ਸਾਬਤ ਕਰਨਾ ਹੁੰਦਾ ਹੈ ਕਿ ਨਵਾਂ ਬਿਲਡ ਸਹੀ ਅਤੇ ਸਹਾਇਤਯੋਗ ਹੈ ਅਸਲੀ ਮਾਹੌਲ ਵਿੱਚ।
ਉਹ ਬ੍ਰਿਜ ਹਨ, ਇਲਾਜ ਨਹੀਂ:
ਇਹ ਸਮਾਂ ਖਰੀਦਦੇ ਹਨ ਤਾਂ ਜੋ ਇਕੋ-ਵਾਰ ਨਵੇਂ ਹਾਰਡਵੇਅਰ 'ਤੇ ਜਦ ਤੱਕ ਪਰਿਵਰਤਨ ਨਹੀਂ ਹੋ ਜਾਂਦਾ। ਪਰ ਡ੍ਰਾਈਵਰ ਅਤੇ ਨੀਚਲੀ ਸਤਰ ਦੇ ਕੰਪੋਨੈਂਟ ਅਕਸਰ ਅਸਲ ਸੀਮਾਵਾਂ ਬਣੇ ਰਹਿੰਦੇ ਹਨ।
ਪਲੇਟਫਾਰਮ ਸਿਰਫ਼ ਬੈਠਕਾਂ 'ਤੇ ਫਾਸਲਾ ਨਹੀਂ ਹੁੰਦਾ; ਇਹ ਉਹ ਸਭ ਕੁਝ ਹੈ ਜੋ ਲੋਕ ਅਮਲ ਵਿੱਚ ਚਲਾਉਂਦੇ ਹਨ — ਟੂਲਿੰਗ, ਡਿਸਟਰਿਬਿਊਸ਼ਨ ਅਤੇ ਦਿਨ-ਰੋਜ਼ ਦੀ ਡਿਲਿਵਰੀ ਪਾਈਪਲਾਈਨ।
ਹਰ ਚੀਜ਼ ਜੋ ਬਿਲਡ, ਨੈਗੋ, ਡੀਬੱਗ, ਅਤੇ ਟੈਸਟ ਕਰਨਾ ਆਸਾਨ ਬਣਾਉਂਦੀ ਹੈ, ਉਹ ਪ੍ਰਵਾਹਕਾਰੀ ਹੈ। ਜੇ ਸਿੱਧੇ ਟੂਲਚੇਨ ਦੇ ਅੰਸ਼ ਦੇਰ ਨਾਲ ਆਉਂਦੇ ਹਨ ਜਾਂ ਵੱਖਰੇ ਤਰੀਕੇ ਨਾਲ ਕੰਮ ਕਰਦੇ ਹਨ, ਟੀਮ ਨਵੇਂ ਪਲੇਟਫਾਰਮ ’ਤੇ ਸ਼ਰਧਾਂਸ਼ ਨਾਲ ਨਹੀਂ ਜਾਂਦੇ।
ਇੱਕ ਨਵੇਂ ਪਲੇਟਫਾਰਮ ਨੂੰ ਜਿੱਤਣ ਲਈ ਤਿੰਨ ਚੀਜ਼ਾਂ ਮਿਲ ਕੇ ਚਲਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ:
ਜਦ ਇਹ ਤਿੰਨੋਂ ਇਕੱਠੇ ਹੋ ਜਾਂਦੀਆਂ ਹਨ ਤਾਂ ਹੀ ਇਕ ਅਸਲ ਤਬਦੀਲੀ ਲੱਗਦੀ ਹੈ।