ಕ್ಲಿಫ್ ಕ್ಲಿಕ್ - CTO CTO (ಪ್ರಕ್ರಿಯೆಯ ಸುಧಾರಣೆಗಾಗಿ IoT ಸಂವೇದಕಗಳು), ಹಲವಾರು ಯಶಸ್ವಿ ನಿರ್ಗಮನಗಳೊಂದಿಗೆ ಹಲವಾರು ಸ್ಟಾರ್ಟ್‌ಅಪ್‌ಗಳ (ರಾಕೆಟ್ ರಿಯಲ್‌ಟೈಮ್ ಸ್ಕೂಲ್, ನ್ಯೂರೆನ್ಸಿಕ್ ಮತ್ತು H2O.ai ಸೇರಿದಂತೆ) ಸಂಸ್ಥಾಪಕ ಮತ್ತು ಸಹ-ಸಂಸ್ಥಾಪಕ. ಕ್ಲಿಫ್ ತನ್ನ ಮೊದಲ ಕಂಪೈಲರ್ ಅನ್ನು 15 ನೇ ವಯಸ್ಸಿನಲ್ಲಿ ಬರೆದರು (TRS Z-80 ಗಾಗಿ ಪ್ಯಾಸ್ಕಲ್)! ಜಾವಾದಲ್ಲಿನ C2 (ನೋಡ್ಸ್ IR) ನಲ್ಲಿನ ಅವರ ಕೆಲಸಕ್ಕೆ ಅವರು ಹೆಚ್ಚು ಹೆಸರುವಾಸಿಯಾಗಿದ್ದಾರೆ. ಈ ಕಂಪೈಲರ್ JIT ಉನ್ನತ-ಗುಣಮಟ್ಟದ ಕೋಡ್ ಅನ್ನು ಉತ್ಪಾದಿಸಬಹುದೆಂದು ಜಗತ್ತಿಗೆ ತೋರಿಸಿದೆ, ಇದು ಮುಖ್ಯ ಆಧುನಿಕ ಸಾಫ್ಟ್‌ವೇರ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳಲ್ಲಿ ಒಂದಾಗಿ ಜಾವಾ ಹೊರಹೊಮ್ಮುವ ಅಂಶಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ. ನಂತರ ಕ್ಲಿಫ್ ಅಜುಲ್ ಸಿಸ್ಟಮ್ಸ್‌ಗೆ ಶುದ್ಧ ಜಾವಾ ಸಾಫ್ಟ್‌ವೇರ್‌ನೊಂದಿಗೆ 864-ಕೋರ್ ಮೇನ್‌ಫ್ರೇಮ್ ಅನ್ನು ನಿರ್ಮಿಸಲು ಸಹಾಯ ಮಾಡಿದರು, ಅದು 500 ಮಿಲಿಸೆಕೆಂಡ್‌ಗಳಲ್ಲಿ 10-ಗಿಗಾಬೈಟ್ ರಾಶಿಯಲ್ಲಿ ಜಿಸಿ ವಿರಾಮಗಳನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ. ಸಾಮಾನ್ಯವಾಗಿ, ಕ್ಲಿಫ್ JVM ನ ಎಲ್ಲಾ ಅಂಶಗಳ ಮೇಲೆ ಕೆಲಸ ಮಾಡಲು ನಿರ್ವಹಿಸುತ್ತಿದ್ದರು.

 
ಈ ಹಬ್ರಪೋಸ್ಟ್ ಕ್ಲಿಫ್ ಅವರೊಂದಿಗಿನ ಉತ್ತಮ ಸಂದರ್ಶನವಾಗಿದೆ. ನಾವು ಈ ಕೆಳಗಿನ ವಿಷಯಗಳ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತೇವೆ:

• ಕಡಿಮೆ ಮಟ್ಟದ ಆಪ್ಟಿಮೈಸೇಶನ್‌ಗಳಿಗೆ ಪರಿವರ್ತನೆ
• ದೊಡ್ಡ ರಿಫ್ಯಾಕ್ಟರಿಂಗ್ ಅನ್ನು ಹೇಗೆ ಮಾಡುವುದು
• ವೆಚ್ಚದ ಮಾದರಿ
• ಕಡಿಮೆ ಮಟ್ಟದ ಆಪ್ಟಿಮೈಸೇಶನ್ ತರಬೇತಿ
• ಕಾರ್ಯಕ್ಷಮತೆ ಸುಧಾರಣೆಯ ಪ್ರಾಯೋಗಿಕ ಉದಾಹರಣೆಗಳು
• ನಿಮ್ಮ ಸ್ವಂತ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಭಾಷೆಯನ್ನು ಏಕೆ ರಚಿಸಬೇಕು
• ಕಾರ್ಯಕ್ಷಮತೆ ಇಂಜಿನಿಯರ್ ವೃತ್ತಿ
• ತಾಂತ್ರಿಕ ಸವಾಲುಗಳು
• ರಿಜಿಸ್ಟರ್ ಹಂಚಿಕೆ ಮತ್ತು ಬಹು-ಕೋರ್ಗಳ ಬಗ್ಗೆ ಸ್ವಲ್ಪ
• ಜೀವನದಲ್ಲಿ ದೊಡ್ಡ ಸವಾಲು

ಸಂದರ್ಶನಗಳನ್ನು ಇವರಿಂದ ನಡೆಸಲಾಗುತ್ತದೆ:

• ಆಂಡ್ರೆ ಸಟಾರಿನ್ Amazon ವೆಬ್ ಸೇವೆಗಳಿಂದ. ಅವರ ವೃತ್ತಿಜೀವನದಲ್ಲಿ, ಅವರು ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನ ಯೋಜನೆಗಳಲ್ಲಿ ಕೆಲಸ ಮಾಡಲು ನಿರ್ವಹಿಸುತ್ತಿದ್ದರು: ಅವರು Yandex ನಲ್ಲಿ NewSQL ವಿತರಿಸಿದ ಡೇಟಾಬೇಸ್, ಕ್ಯಾಸ್ಪರ್ಸ್ಕಿ ಲ್ಯಾಬ್‌ನಲ್ಲಿ ಕ್ಲೌಡ್ ಡಿಟೆಕ್ಷನ್ ಸಿಸ್ಟಮ್, Mail.ru ನಲ್ಲಿ ಮಲ್ಟಿಪ್ಲೇಯರ್ ಆಟ ಮತ್ತು ಡಾಯ್ಚ ಬ್ಯಾಂಕ್‌ನಲ್ಲಿ ವಿದೇಶಿ ವಿನಿಮಯ ಬೆಲೆಗಳನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡುವ ಸೇವೆಯನ್ನು ಪರೀಕ್ಷಿಸಿದರು. ದೊಡ್ಡ ಪ್ರಮಾಣದ ಬ್ಯಾಕೆಂಡ್ ಮತ್ತು ವಿತರಣಾ ವ್ಯವಸ್ಥೆಗಳನ್ನು ಪರೀಕ್ಷಿಸಲು ಆಸಕ್ತಿ.
• ವ್ಲಾಡಿಮಿರ್ ಸಿಟ್ನಿಕೋವ್ Netcracker ನಿಂದ. ನೆಟ್‌ಕ್ರ್ಯಾಕರ್ ಓಎಸ್‌ನ ಕಾರ್ಯಕ್ಷಮತೆ ಮತ್ತು ಸ್ಕೇಲೆಬಿಲಿಟಿ ಕುರಿತು ಹತ್ತು ವರ್ಷಗಳ ಕೆಲಸ, ನೆಟ್‌ವರ್ಕ್ ಮತ್ತು ನೆಟ್‌ವರ್ಕ್ ಉಪಕರಣಗಳ ನಿರ್ವಹಣೆ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಲು ಟೆಲಿಕಾಂ ಆಪರೇಟರ್‌ಗಳು ಬಳಸುವ ಸಾಫ್ಟ್‌ವೇರ್. ಜಾವಾ ಮತ್ತು ಒರಾಕಲ್ ಡೇಟಾಬೇಸ್ ಕಾರ್ಯಕ್ಷಮತೆ ಸಮಸ್ಯೆಗಳಲ್ಲಿ ಆಸಕ್ತಿ ಇದೆ. ಅಧಿಕೃತ PostgreSQL JDBC ಡ್ರೈವರ್‌ನಲ್ಲಿ ಒಂದು ಡಜನ್‌ಗಿಂತಲೂ ಹೆಚ್ಚು ಕಾರ್ಯಕ್ಷಮತೆ ಸುಧಾರಣೆಗಳ ಲೇಖಕ.

ಕಡಿಮೆ ಮಟ್ಟದ ಆಪ್ಟಿಮೈಸೇಶನ್‌ಗಳಿಗೆ ಪರಿವರ್ತನೆ

ಆಂಡ್ರಾಯ್ಡ್: ನೀವು ಸಾಮಾನ್ಯವಾಗಿ JIT ಸಂಕಲನ, ಜಾವಾ ಮತ್ತು ಕಾರ್ಯಕ್ಷಮತೆಯ ಕೆಲಸಗಳ ಜಗತ್ತಿನಲ್ಲಿ ದೊಡ್ಡ ಹೆಸರು, ಸರಿ? 

ಕ್ಲಿಫ್: ಅದು ಹಾಗೆ!

ಆಂಡ್ರಾಯ್ಡ್: ಕಾರ್ಯಕ್ಷಮತೆಯ ಕೆಲಸದ ಬಗ್ಗೆ ಕೆಲವು ಸಾಮಾನ್ಯ ಪ್ರಶ್ನೆಗಳೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸೋಣ. CPU ಮಟ್ಟದಲ್ಲಿ ಕೆಲಸ ಮಾಡುವಂತಹ ಉನ್ನತ ಮಟ್ಟದ ಮತ್ತು ಕಡಿಮೆ ಮಟ್ಟದ ಆಪ್ಟಿಮೈಸೇಶನ್‌ಗಳ ನಡುವಿನ ಆಯ್ಕೆಯ ಬಗ್ಗೆ ನೀವು ಏನು ಯೋಚಿಸುತ್ತೀರಿ?

ಕ್ಲಿಫ್: ಹೌದು, ಇಲ್ಲಿ ಎಲ್ಲವೂ ಸರಳವಾಗಿದೆ. ವೇಗವಾದ ಕೋಡ್ ಎಂದಿಗೂ ರನ್ ಆಗುವುದಿಲ್ಲ. ಆದ್ದರಿಂದ, ನೀವು ಯಾವಾಗಲೂ ಉನ್ನತ ಮಟ್ಟದಿಂದ ಪ್ರಾರಂಭಿಸಬೇಕು, ಅಲ್ಗಾರಿದಮ್‌ಗಳಲ್ಲಿ ಕೆಲಸ ಮಾಡಿ. ಕೆಲವು ಸಾಕಷ್ಟು ದೊಡ್ಡ ಸ್ಥಿರಾಂಕಗಳು ಮಧ್ಯಪ್ರವೇಶಿಸದ ಹೊರತು ಉತ್ತಮ O ಸಂಕೇತವು ಕೆಟ್ಟ O ಸಂಕೇತವನ್ನು ಸೋಲಿಸುತ್ತದೆ. ಕೆಳಮಟ್ಟದ ವಿಷಯಗಳು ಕೊನೆಯದಾಗಿ ಹೋಗುತ್ತವೆ. ವಿಶಿಷ್ಟವಾಗಿ, ನಿಮ್ಮ ಉಳಿದ ಸ್ಟಾಕ್ ಅನ್ನು ನೀವು ಸಾಕಷ್ಟು ಉತ್ತಮಗೊಳಿಸಿದ್ದರೆ ಮತ್ತು ಇನ್ನೂ ಕೆಲವು ಆಸಕ್ತಿದಾಯಕ ಸಂಗತಿಗಳು ಉಳಿದಿದ್ದರೆ, ಅದು ಕಡಿಮೆ ಮಟ್ಟವಾಗಿದೆ. ಆದರೆ ಉನ್ನತ ಮಟ್ಟದಿಂದ ಹೇಗೆ ಪ್ರಾರಂಭಿಸುವುದು? ಸಾಕಷ್ಟು ಉನ್ನತ ಮಟ್ಟದ ಕೆಲಸ ಮಾಡಲಾಗಿದೆ ಎಂದು ನಿಮಗೆ ಹೇಗೆ ಗೊತ್ತು? ಸರಿ... ದಾರಿ ಇಲ್ಲ. ಯಾವುದೇ ಸಿದ್ಧ ಪಾಕವಿಧಾನಗಳಿಲ್ಲ. ನೀವು ಸಮಸ್ಯೆಯನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು, ನೀವು ಏನು ಮಾಡಲಿದ್ದೀರಿ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಿ (ಭವಿಷ್ಯದಲ್ಲಿ ಅನಗತ್ಯ ಕ್ರಮಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳದಂತೆ) ಮತ್ತು ನಂತರ ನೀವು ಪ್ರೊಫೈಲರ್ ಅನ್ನು ಬಹಿರಂಗಪಡಿಸಬಹುದು, ಅದು ಉಪಯುಕ್ತವಾದದ್ದನ್ನು ಹೇಳಬಹುದು. ಕೆಲವು ಹಂತದಲ್ಲಿ, ನೀವು ಅನಗತ್ಯ ವಿಷಯಗಳನ್ನು ತೊಡೆದುಹಾಕಿದ್ದೀರಿ ಎಂದು ನೀವೇ ಅರಿತುಕೊಳ್ಳುತ್ತೀರಿ ಮತ್ತು ಕೆಲವು ಕಡಿಮೆ-ಮಟ್ಟದ ಉತ್ತಮವಾದ ಶ್ರುತಿ ಮಾಡುವ ಸಮಯ ಇದು. ಇದು ಖಂಡಿತವಾಗಿಯೂ ವಿಶೇಷ ರೀತಿಯ ಕಲೆಯಾಗಿದೆ. ಬಹಳಷ್ಟು ಜನರು ಅನಗತ್ಯ ಕೆಲಸಗಳನ್ನು ಮಾಡುತ್ತಾರೆ, ಆದರೆ ಉತ್ಪಾದಕತೆಯ ಬಗ್ಗೆ ಚಿಂತಿಸಲು ಅವರಿಗೆ ಸಮಯವಿಲ್ಲದಷ್ಟು ವೇಗವಾಗಿ ಚಲಿಸುತ್ತಿದ್ದಾರೆ. ಆದರೆ ಈ ಪ್ರಶ್ನೆ ನೇರವಾಗಿ ಉದ್ಭವಿಸುವವರೆಗೆ. ಸಾಮಾನ್ಯವಾಗಿ 99% ಸಮಯ ಯಾರೂ ನಾನು ಏನು ಮಾಡುತ್ತೇನೆ ಎಂದು ಕಾಳಜಿ ವಹಿಸುವುದಿಲ್ಲ, ಯಾರೂ ಕಾಳಜಿ ವಹಿಸದ ನಿರ್ಣಾಯಕ ಹಾದಿಯಲ್ಲಿ ಒಂದು ಪ್ರಮುಖ ವಿಷಯ ಬಂದಾಗ ಕ್ಷಣದವರೆಗೆ. ಮತ್ತು ಇಲ್ಲಿ ಪ್ರತಿಯೊಬ್ಬರೂ "ಇದು ಮೊದಲಿನಿಂದಲೂ ಸರಿಯಾಗಿ ಕೆಲಸ ಮಾಡಲಿಲ್ಲ" ಎಂದು ನಿಮ್ಮನ್ನು ಕೆಣಕಲು ಪ್ರಾರಂಭಿಸುತ್ತಾರೆ. ಸಾಮಾನ್ಯವಾಗಿ, ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸುಧಾರಿಸಲು ಯಾವಾಗಲೂ ಏನಾದರೂ ಇರುತ್ತದೆ. ಆದರೆ 99% ಸಮಯ ನಿಮಗೆ ಯಾವುದೇ ಲೀಡ್‌ಗಳಿಲ್ಲ! ನೀವು ಏನನ್ನಾದರೂ ಕೆಲಸ ಮಾಡಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದ್ದೀರಿ ಮತ್ತು ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ನೀವು ಮುಖ್ಯವಾದುದನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡುತ್ತೀರಿ. ಈ ತುಣುಕು ಪರಿಪೂರ್ಣವಾಗಿರಬೇಕು ಎಂದು ನೀವು ಮುಂಚಿತವಾಗಿ ತಿಳಿದಿರುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ, ವಾಸ್ತವವಾಗಿ, ನೀವು ಎಲ್ಲದರಲ್ಲೂ ಪರಿಪೂರ್ಣರಾಗಿರಬೇಕು. ಆದರೆ ಇದು ಅಸಾಧ್ಯ ಮತ್ತು ನೀವು ಅದನ್ನು ಮಾಡಬೇಡಿ. ಸರಿಪಡಿಸಲು ಯಾವಾಗಲೂ ಬಹಳಷ್ಟು ವಿಷಯಗಳಿವೆ - ಮತ್ತು ಇದು ಸಂಪೂರ್ಣವಾಗಿ ಸಾಮಾನ್ಯವಾಗಿದೆ.

ದೊಡ್ಡ ರಿಫ್ಯಾಕ್ಟರಿಂಗ್ ಅನ್ನು ಹೇಗೆ ಮಾಡುವುದು

ಆಂಡ್ರಾಯ್ಡ್: ಪ್ರದರ್ಶನದಲ್ಲಿ ನೀವು ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತೀರಿ? ಇದು ಅಡ್ಡ-ಕತ್ತರಿಸುವ ಸಮಸ್ಯೆಯಾಗಿದೆ. ಉದಾಹರಣೆಗೆ, ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಬಹಳಷ್ಟು ಕಾರ್ಯಚಟುವಟಿಕೆಗಳ ಛೇದಕದಿಂದ ಉದ್ಭವಿಸುವ ಸಮಸ್ಯೆಗಳ ಮೇಲೆ ನೀವು ಎಂದಾದರೂ ಕೆಲಸ ಮಾಡಬೇಕೇ?

ಕ್ಲಿಫ್: ನಾನು ಅದನ್ನು ತಪ್ಪಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತೇನೆ. ಕಾರ್ಯಕ್ಷಮತೆಯು ಒಂದು ಸಮಸ್ಯೆ ಎಂದು ನನಗೆ ತಿಳಿದಿದ್ದರೆ, ನಾನು ಕೋಡಿಂಗ್ ಪ್ರಾರಂಭಿಸುವ ಮೊದಲು ಅದರ ಬಗ್ಗೆ ಯೋಚಿಸುತ್ತೇನೆ, ವಿಶೇಷವಾಗಿ ಡೇಟಾ ರಚನೆಗಳೊಂದಿಗೆ. ಆದರೆ ಆಗಾಗ್ಗೆ ನೀವು ಈ ಎಲ್ಲವನ್ನೂ ಬಹಳ ನಂತರ ಕಂಡುಕೊಳ್ಳುತ್ತೀರಿ. ತದನಂತರ ನೀವು ತೀವ್ರ ಕ್ರಮಗಳಿಗೆ ಹೋಗಬೇಕು ಮತ್ತು ನಾನು "ಪುನಃ ಬರೆಯಿರಿ ಮತ್ತು ವಶಪಡಿಸಿಕೊಳ್ಳಿ" ಎಂದು ಕರೆಯುವದನ್ನು ಮಾಡಬೇಕು: ನೀವು ಸಾಕಷ್ಟು ದೊಡ್ಡ ತುಣುಕನ್ನು ಪಡೆದುಕೊಳ್ಳಬೇಕು. ಕಾರ್ಯಕ್ಷಮತೆಯ ಸಮಸ್ಯೆಗಳು ಅಥವಾ ಯಾವುದೋ ಕಾರಣದಿಂದ ಕೆಲವು ಕೋಡ್ ಅನ್ನು ಇನ್ನೂ ಪುನಃ ಬರೆಯಬೇಕಾಗುತ್ತದೆ. ಕೋಡ್ ಅನ್ನು ಪುನಃ ಬರೆಯುವ ಕಾರಣ ಏನೇ ಇರಲಿ, ಚಿಕ್ಕ ತುಣುಕಿಗಿಂತ ದೊಡ್ಡ ತುಣುಕನ್ನು ಪುನಃ ಬರೆಯುವುದು ಯಾವಾಗಲೂ ಉತ್ತಮವಾಗಿದೆ. ಈ ಕ್ಷಣದಲ್ಲಿ, ಪ್ರತಿಯೊಬ್ಬರೂ ಭಯದಿಂದ ನಡುಗಲು ಪ್ರಾರಂಭಿಸುತ್ತಾರೆ: "ಓ ದೇವರೇ, ನೀವು ತುಂಬಾ ಕೋಡ್ ಅನ್ನು ಮುಟ್ಟಲು ಸಾಧ್ಯವಿಲ್ಲ!" ಆದರೆ ವಾಸ್ತವವಾಗಿ, ಈ ವಿಧಾನವು ಯಾವಾಗಲೂ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ನೀವು ತಕ್ಷಣ ಒಂದು ದೊಡ್ಡ ಸಮಸ್ಯೆಯನ್ನು ತೆಗೆದುಕೊಳ್ಳಬೇಕು, ಅದರ ಸುತ್ತಲೂ ಒಂದು ದೊಡ್ಡ ವೃತ್ತವನ್ನು ಎಳೆಯಿರಿ ಮತ್ತು ಹೇಳಿ: ನಾನು ವೃತ್ತದೊಳಗೆ ಎಲ್ಲವನ್ನೂ ಪುನಃ ಬರೆಯುತ್ತೇನೆ. ಗಡಿಯು ಅದರೊಳಗಿನ ವಿಷಯಕ್ಕಿಂತ ಚಿಕ್ಕದಾಗಿದೆ ಅದನ್ನು ಬದಲಾಯಿಸಬೇಕಾಗಿದೆ. ಮತ್ತು ಗಡಿಗಳ ಅಂತಹ ಚಿತ್ರಣವು ಸಂಪೂರ್ಣವಾಗಿ ಒಳಗೆ ಕೆಲಸವನ್ನು ಮಾಡಲು ನಿಮಗೆ ಅವಕಾಶ ನೀಡಿದರೆ, ನಿಮ್ಮ ಕೈಗಳು ಮುಕ್ತವಾಗಿರುತ್ತವೆ, ನಿಮಗೆ ಬೇಕಾದುದನ್ನು ಮಾಡಿ. ಒಮ್ಮೆ ನೀವು ಸಮಸ್ಯೆಯನ್ನು ಅರ್ಥಮಾಡಿಕೊಂಡರೆ, ಪುನಃ ಬರೆಯುವ ಪ್ರಕ್ರಿಯೆಯು ತುಂಬಾ ಸುಲಭವಾಗಿದೆ, ಆದ್ದರಿಂದ ದೊಡ್ಡ ಬೈಟ್ ತೆಗೆದುಕೊಳ್ಳಿ!
ಅದೇ ಸಮಯದಲ್ಲಿ, ನೀವು ದೊಡ್ಡದಾಗಿ ಪುನಃ ಬರೆಯುವಾಗ ಮತ್ತು ಕಾರ್ಯಕ್ಷಮತೆಯು ಸಮಸ್ಯೆಯಾಗಲಿದೆ ಎಂದು ಅರಿತುಕೊಂಡಾಗ, ನೀವು ತಕ್ಷಣವೇ ಅದರ ಬಗ್ಗೆ ಚಿಂತಿಸುವುದನ್ನು ಪ್ರಾರಂಭಿಸಬಹುದು. ಇದು ಸಾಮಾನ್ಯವಾಗಿ "ಡೇಟಾವನ್ನು ನಕಲಿಸಬೇಡಿ, ಡೇಟಾವನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ಸರಳವಾಗಿ ನಿರ್ವಹಿಸಿ, ಅದನ್ನು ಚಿಕ್ಕದಾಗಿಸಿ" ನಂತಹ ಸರಳ ವಿಷಯಗಳಾಗಿ ಬದಲಾಗುತ್ತದೆ. ದೊಡ್ಡ ಮರುಬರಹಗಳಲ್ಲಿ, ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸುಧಾರಿಸಲು ಪ್ರಮಾಣಿತ ಮಾರ್ಗಗಳಿವೆ. ಮತ್ತು ಅವರು ಯಾವಾಗಲೂ ಡೇಟಾ ಸುತ್ತ ಸುತ್ತುತ್ತಾರೆ.

ವೆಚ್ಚದ ಮಾದರಿ

ಆಂಡ್ರಾಯ್ಡ್: ಪಾಡ್‌ಕಾಸ್ಟ್ ಒಂದರಲ್ಲಿ ನೀವು ಉತ್ಪಾದಕತೆಯ ಸಂದರ್ಭದಲ್ಲಿ ವೆಚ್ಚದ ಮಾದರಿಗಳ ಕುರಿತು ಮಾತನಾಡಿದ್ದೀರಿ. ನೀವು ಇದರ ಅರ್ಥವನ್ನು ವಿವರಿಸುವಿರಾ?

ಕ್ಲಿಫ್: ಖಂಡಿತ. ಪ್ರೊಸೆಸರ್ ಕಾರ್ಯಕ್ಷಮತೆ ಅತ್ಯಂತ ಮುಖ್ಯವಾದ ಯುಗದಲ್ಲಿ ನಾನು ಜನಿಸಿದೆ. ಮತ್ತು ಈ ಯುಗವು ಮತ್ತೆ ಮರಳುತ್ತದೆ - ವಿಧಿ ವ್ಯಂಗ್ಯವಿಲ್ಲದೆ ಅಲ್ಲ. ನಾನು ಎಂಟು-ಬಿಟ್ ಯಂತ್ರಗಳ ದಿನಗಳಲ್ಲಿ ವಾಸಿಸಲು ಪ್ರಾರಂಭಿಸಿದೆ; ನನ್ನ ಮೊದಲ ಕಂಪ್ಯೂಟರ್ 256 ಬೈಟ್‌ಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಿದೆ. ನಿಖರವಾಗಿ ಬೈಟ್‌ಗಳು. ಎಲ್ಲವೂ ತುಂಬಾ ಚಿಕ್ಕದಾಗಿತ್ತು. ಸೂಚನೆಗಳನ್ನು ಎಣಿಕೆ ಮಾಡಬೇಕಾಗಿತ್ತು, ಮತ್ತು ನಾವು ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಭಾಷೆಯ ಸ್ಟಾಕ್ ಅನ್ನು ಮೇಲಕ್ಕೆ ಚಲಿಸಲು ಪ್ರಾರಂಭಿಸಿದಾಗ, ಭಾಷೆಗಳು ಹೆಚ್ಚು ಹೆಚ್ಚು ಪಡೆದುಕೊಂಡವು. ಅಸೆಂಬ್ಲರ್ ಇತ್ತು, ನಂತರ ಬೇಸಿಕ್, ನಂತರ ಸಿ, ಮತ್ತು ಸಿ ರಿಜಿಸ್ಟರ್ ಹಂಚಿಕೆ ಮತ್ತು ಸೂಚನಾ ಆಯ್ಕೆಯಂತಹ ಬಹಳಷ್ಟು ವಿವರಗಳನ್ನು ನೋಡಿಕೊಂಡರು. ಆದರೆ ಅಲ್ಲಿ ಎಲ್ಲವೂ ಸ್ಪಷ್ಟವಾಗಿತ್ತು, ಮತ್ತು ನಾನು ವೇರಿಯಬಲ್‌ನ ನಿದರ್ಶನಕ್ಕೆ ಪಾಯಿಂಟರ್ ಮಾಡಿದರೆ, ನಾನು ಲೋಡ್ ಪಡೆಯುತ್ತೇನೆ ಮತ್ತು ಈ ಸೂಚನೆಯ ವೆಚ್ಚವು ತಿಳಿದಿದೆ. ಯಂತ್ರಾಂಶವು ನಿರ್ದಿಷ್ಟ ಸಂಖ್ಯೆಯ ಯಂತ್ರ ಚಕ್ರಗಳನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ನೀವು ಚಲಾಯಿಸಲು ಹೊರಟಿರುವ ಎಲ್ಲಾ ಸೂಚನೆಗಳನ್ನು ಸೇರಿಸುವ ಮೂಲಕ ವಿಭಿನ್ನ ವಸ್ತುಗಳ ಕಾರ್ಯಗತಗೊಳಿಸುವ ವೇಗವನ್ನು ಸರಳವಾಗಿ ಲೆಕ್ಕಹಾಕಬಹುದು. ಪ್ರತಿಯೊಂದು ಹೋಲಿಕೆ/ಪರೀಕ್ಷೆ/ಶಾಖೆ/ಕರೆ/ಲೋಡ್/ಸ್ಟೋರ್ ಅನ್ನು ಸೇರಿಸಬಹುದು ಮತ್ತು ಹೀಗೆ ಹೇಳಬಹುದು: ಅದು ನಿಮಗೆ ಕಾರ್ಯಗತಗೊಳಿಸುವ ಸಮಯ. ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸುಧಾರಿಸುವಲ್ಲಿ ಕೆಲಸ ಮಾಡುವಾಗ, ಸಣ್ಣ ಬಿಸಿ ಚಕ್ರಗಳಿಗೆ ಯಾವ ಸಂಖ್ಯೆಗಳು ಹೊಂದಿಕೆಯಾಗುತ್ತವೆ ಎಂಬುದರ ಬಗ್ಗೆ ನೀವು ಖಂಡಿತವಾಗಿಯೂ ಗಮನ ಹರಿಸುತ್ತೀರಿ. 
ಆದರೆ ನೀವು ಜಾವಾ, ಪೈಥಾನ್ ಮತ್ತು ಅಂತಹುದೇ ವಿಷಯಗಳಿಗೆ ಬದಲಾಯಿಸಿದ ತಕ್ಷಣ, ನೀವು ಕಡಿಮೆ ಮಟ್ಟದ ಹಾರ್ಡ್‌ವೇರ್‌ನಿಂದ ಬೇಗನೆ ದೂರ ಹೋಗುತ್ತೀರಿ. ಜಾವಾದಲ್ಲಿ ಪಡೆಯುವವರಿಗೆ ಕರೆ ಮಾಡುವ ವೆಚ್ಚ ಎಷ್ಟು? ಹಾಟ್‌ಸ್ಪಾಟ್‌ನಲ್ಲಿ JIT ಸರಿಯಾಗಿದ್ದರೆ ಇನ್ಲೈನ್ಡ್, ಇದು ಲೋಡ್ ಆಗುತ್ತದೆ, ಆದರೆ ಇದನ್ನು ಮಾಡದಿದ್ದರೆ, ಅದು ಫಂಕ್ಷನ್ ಕರೆ ಆಗಿರುತ್ತದೆ. ಕರೆ ಹಾಟ್ ಲೂಪ್‌ನಲ್ಲಿರುವ ಕಾರಣ, ಅದು ಆ ಲೂಪ್‌ನಲ್ಲಿರುವ ಎಲ್ಲಾ ಇತರ ಆಪ್ಟಿಮೈಸೇಶನ್‌ಗಳನ್ನು ಅತಿಕ್ರಮಿಸುತ್ತದೆ. ಆದ್ದರಿಂದ, ನಿಜವಾದ ವೆಚ್ಚವು ಹೆಚ್ಚು ಇರುತ್ತದೆ. ಮತ್ತು ನೀವು ತಕ್ಷಣವೇ ಕೋಡ್‌ನ ತುಣುಕನ್ನು ನೋಡುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತೀರಿ ಮತ್ತು ನಾವು ಅದನ್ನು ಪ್ರೊಸೆಸರ್ ಗಡಿಯಾರದ ವೇಗ, ಮೆಮೊರಿ ಮತ್ತು ಬಳಸಿದ ಸಂಗ್ರಹದ ವಿಷಯದಲ್ಲಿ ಕಾರ್ಯಗತಗೊಳಿಸಬೇಕು ಎಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಿ. ನೀವು ನಿಜವಾಗಿಯೂ ಪ್ರದರ್ಶನಕ್ಕೆ ಬಂದರೆ ಮಾತ್ರ ಇದೆಲ್ಲವೂ ಆಸಕ್ತಿದಾಯಕವಾಗುತ್ತದೆ.
ಒಂದು ದಶಕದಿಂದ ಪ್ರೊಸೆಸರ್ ವೇಗವು ಅಷ್ಟೇನೂ ಹೆಚ್ಚಾಗದ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ ಈಗ ನಾವು ಕಾಣುತ್ತೇವೆ. ಹಳೆಯ ದಿನಗಳು ಹಿಂತಿರುಗಿವೆ! ನೀವು ಇನ್ನು ಮುಂದೆ ಉತ್ತಮ ಸಿಂಗಲ್-ಥ್ರೆಡ್ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಪರಿಗಣಿಸಲಾಗುವುದಿಲ್ಲ. ಆದರೆ ನೀವು ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಸಮಾನಾಂತರ ಕಂಪ್ಯೂಟಿಂಗ್‌ಗೆ ಬಂದರೆ, ಅದು ನಂಬಲಾಗದಷ್ಟು ಕಷ್ಟ, ಎಲ್ಲರೂ ನಿಮ್ಮನ್ನು ಜೇಮ್ಸ್ ಬಾಂಡ್‌ನಂತೆ ನೋಡುತ್ತಾರೆ. ಇಲ್ಲಿ ಹತ್ತುಪಟ್ಟು ವೇಗವರ್ಧನೆಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಯಾರಾದರೂ ಏನನ್ನಾದರೂ ಗೊಂದಲಗೊಳಿಸಿರುವ ಸ್ಥಳಗಳಲ್ಲಿ ಸಂಭವಿಸುತ್ತವೆ. ಏಕಕಾಲಿಕತೆಗೆ ಬಹಳಷ್ಟು ಕೆಲಸ ಬೇಕಾಗುತ್ತದೆ. ಆ XNUMXx ವೇಗವನ್ನು ಪಡೆಯಲು, ನೀವು ವೆಚ್ಚದ ಮಾದರಿಯನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು. ಏನು ಮತ್ತು ಎಷ್ಟು ವೆಚ್ಚವಾಗುತ್ತದೆ? ಮತ್ತು ಇದನ್ನು ಮಾಡಲು, ಆಧಾರವಾಗಿರುವ ಯಂತ್ರಾಂಶದಲ್ಲಿ ನಾಲಿಗೆ ಹೇಗೆ ಹೊಂದಿಕೊಳ್ಳುತ್ತದೆ ಎಂಬುದನ್ನು ನೀವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು.
ಮಾರ್ಟಿನ್ ಥಾಂಪ್ಸನ್ ತನ್ನ ಬ್ಲಾಗ್‌ಗೆ ಉತ್ತಮ ಪದವನ್ನು ಆರಿಸಿಕೊಂಡರು ಯಾಂತ್ರಿಕ ಸಹಾನುಭೂತಿ! ಹಾರ್ಡ್‌ವೇರ್ ಏನು ಮಾಡಲಿದೆ, ಅದು ಹೇಗೆ ನಿಖರವಾಗಿ ಮಾಡುತ್ತದೆ ಮತ್ತು ಅದು ಏಕೆ ಮೊದಲ ಸ್ಥಾನದಲ್ಲಿ ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ನೀವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು. ಇದನ್ನು ಬಳಸುವುದರಿಂದ, ಸೂಚನೆಗಳನ್ನು ಎಣಿಸಲು ಪ್ರಾರಂಭಿಸುವುದು ಮತ್ತು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಸಮಯ ಎಲ್ಲಿಗೆ ಹೋಗುತ್ತಿದೆ ಎಂಬುದನ್ನು ಕಂಡುಹಿಡಿಯುವುದು ತುಂಬಾ ಸುಲಭ. ನೀವು ಸರಿಯಾದ ತರಬೇತಿಯನ್ನು ಹೊಂದಿಲ್ಲದಿದ್ದರೆ, ನೀವು ಕತ್ತಲೆಯ ಕೋಣೆಯಲ್ಲಿ ಕಪ್ಪು ಬೆಕ್ಕನ್ನು ಹುಡುಕುತ್ತಿದ್ದೀರಿ. ಅವರು ಏನು ಮಾಡುತ್ತಿದ್ದಾರೆಂದು ತಿಳಿದಿಲ್ಲದ ಜನರು ಸಾರ್ವಕಾಲಿಕ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಉತ್ತಮಗೊಳಿಸುವುದನ್ನು ನಾನು ನೋಡುತ್ತೇನೆ. ಅವರು ಬಹಳಷ್ಟು ಬಳಲುತ್ತಿದ್ದಾರೆ ಮತ್ತು ಹೆಚ್ಚು ಪ್ರಗತಿ ಸಾಧಿಸುತ್ತಿಲ್ಲ. ಮತ್ತು ನಾನು ಅದೇ ಕೋಡ್ ಅನ್ನು ತೆಗೆದುಕೊಂಡಾಗ, ಒಂದೆರಡು ಸಣ್ಣ ಹ್ಯಾಕ್‌ಗಳಲ್ಲಿ ಸ್ಲಿಪ್ ಮಾಡಿ ಮತ್ತು ಐದು ಅಥವಾ ಹತ್ತು ಪಟ್ಟು ವೇಗವನ್ನು ಪಡೆದಾಗ, ಅವುಗಳು ಹೀಗಿವೆ: ಸರಿ, ಅದು ನ್ಯಾಯೋಚಿತವಲ್ಲ, ನೀವು ಉತ್ತಮ ಎಂದು ನಮಗೆ ಈಗಾಗಲೇ ತಿಳಿದಿತ್ತು. ಅದ್ಭುತ. ನಾನು ಏನು ಮಾತನಾಡುತ್ತಿದ್ದೇನೆ ... ವೆಚ್ಚದ ಮಾದರಿಯು ನೀವು ಯಾವ ರೀತಿಯ ಕೋಡ್ ಅನ್ನು ಬರೆಯುತ್ತೀರಿ ಮತ್ತು ದೊಡ್ಡ ಚಿತ್ರದಲ್ಲಿ ಸರಾಸರಿ ಎಷ್ಟು ವೇಗವಾಗಿ ಚಲಿಸುತ್ತದೆ ಎಂಬುದರ ಬಗ್ಗೆ.

ಆಂಡ್ರಾಯ್ಡ್: ಮತ್ತು ನಿಮ್ಮ ತಲೆಯಲ್ಲಿ ಅಂತಹ ಪರಿಮಾಣವನ್ನು ಹೇಗೆ ಇಟ್ಟುಕೊಳ್ಳಬಹುದು? ಹೆಚ್ಚಿನ ಅನುಭವದೊಂದಿಗೆ ಇದನ್ನು ಸಾಧಿಸಲಾಗಿದೆಯೇ ಅಥವಾ? ಅಂತಹ ಅನುಭವ ಎಲ್ಲಿಂದ ಬರುತ್ತದೆ?

ಕ್ಲಿಫ್: ಸರಿ, ನನ್ನ ಅನುಭವವನ್ನು ನಾನು ಸುಲಭವಾದ ರೀತಿಯಲ್ಲಿ ಪಡೆಯಲಿಲ್ಲ. ನೀವು ಪ್ರತಿಯೊಂದು ಸೂಚನೆಯನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವ ದಿನಗಳಲ್ಲಿ ನಾನು ಅಸೆಂಬ್ಲಿಯಲ್ಲಿ ಪ್ರೋಗ್ರಾಮ್ ಮಾಡಿದ್ದೇನೆ. ಇದು ಮೂರ್ಖ ಎಂದು ತೋರುತ್ತದೆ, ಆದರೆ ಅಂದಿನಿಂದ Z80 ಸೂಚನಾ ಸೆಟ್ ಯಾವಾಗಲೂ ನನ್ನ ತಲೆಯಲ್ಲಿ, ನನ್ನ ನೆನಪಿನಲ್ಲಿ ಉಳಿದಿದೆ. ಮಾತಾಡಿದ ನಿಮಿಷದಲ್ಲಿ ಜನರ ಹೆಸರು ನೆನಪಾಗುವುದಿಲ್ಲ, ಆದರೆ 40 ವರ್ಷಗಳ ಹಿಂದೆ ಬರೆದ ಕೋಡ್ ನೆನಪಿದೆ. ಇದು ತಮಾಷೆಯಾಗಿದೆ, ಇದು ಸಿಂಡ್ರೋಮ್ನಂತೆ ಕಾಣುತ್ತದೆ "ಮೂರ್ಖ ವಿಜ್ಞಾನಿ».

ಕಡಿಮೆ ಮಟ್ಟದ ಆಪ್ಟಿಮೈಸೇಶನ್ ತರಬೇತಿ

ಆಂಡ್ರಾಯ್ಡ್: ಪ್ರವೇಶಿಸಲು ಸುಲಭವಾದ ಮಾರ್ಗವಿದೆಯೇ?

ಕ್ಲಿಫ್: ಹೌದು ಮತ್ತು ಇಲ್ಲ. ನಾವೆಲ್ಲರೂ ಬಳಸುವ ಯಂತ್ರಾಂಶವು ಕಾಲಾನಂತರದಲ್ಲಿ ಹೆಚ್ಚು ಬದಲಾಗಿಲ್ಲ. ಆರ್ಮ್ ಸ್ಮಾರ್ಟ್‌ಫೋನ್‌ಗಳನ್ನು ಹೊರತುಪಡಿಸಿ ಎಲ್ಲರೂ x86 ಅನ್ನು ಬಳಸುತ್ತಾರೆ. ನೀವು ಕೆಲವು ರೀತಿಯ ಹಾರ್ಡ್‌ಕೋರ್ ಎಂಬೆಡಿಂಗ್ ಮಾಡದಿದ್ದರೆ, ನೀವು ಅದೇ ಕೆಲಸವನ್ನು ಮಾಡುತ್ತಿದ್ದೀರಿ. ಸರಿ, ಮುಂದೆ. ಸೂಚನೆಗಳೂ ಶತಮಾನಗಳಿಂದ ಬದಲಾಗಿಲ್ಲ. ನೀವು ಹೋಗಿ ವಿಧಾನಸಭೆಯಲ್ಲಿ ಏನಾದರೂ ಬರೆಯಬೇಕು. ಹೆಚ್ಚು ಅಲ್ಲ, ಆದರೆ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಪ್ರಾರಂಭಿಸಲು ಸಾಕು. ನೀವು ನಗುತ್ತಿರುವಿರಿ, ಆದರೆ ನಾನು ಸಂಪೂರ್ಣವಾಗಿ ಗಂಭೀರವಾಗಿ ಮಾತನಾಡುತ್ತಿದ್ದೇನೆ. ಭಾಷೆ ಮತ್ತು ಯಂತ್ರಾಂಶದ ನಡುವಿನ ಪತ್ರವ್ಯವಹಾರವನ್ನು ನೀವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು. ಅದರ ನಂತರ ನೀವು ಹೋಗಿ ಸ್ವಲ್ಪ ಬರೆಯಬೇಕು ಮತ್ತು ಸ್ವಲ್ಪ ಆಟಿಕೆ ಭಾಷೆಗಾಗಿ ಸ್ವಲ್ಪ ಆಟಿಕೆ ಕಂಪೈಲರ್ ಅನ್ನು ತಯಾರಿಸಬೇಕು. ಆಟಿಕೆ ತರಹ ಎಂದರೆ ಅದನ್ನು ಸಮಂಜಸವಾದ ಸಮಯದಲ್ಲಿ ಮಾಡಬೇಕಾಗಿದೆ. ಇದು ತುಂಬಾ ಸರಳವಾಗಬಹುದು, ಆದರೆ ಇದು ಸೂಚನೆಗಳನ್ನು ರಚಿಸಬೇಕು. ಸೂಚನೆಯನ್ನು ರಚಿಸುವ ಕ್ರಿಯೆಯು ಪ್ರತಿಯೊಬ್ಬರೂ ಬರೆಯುವ ಉನ್ನತ ಮಟ್ಟದ ಕೋಡ್ ಮತ್ತು ಯಂತ್ರಾಂಶದಲ್ಲಿ ಚಲಿಸುವ ಯಂತ್ರದ ಕೋಡ್ ನಡುವಿನ ಸೇತುವೆಯ ವೆಚ್ಚದ ಮಾದರಿಯನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ನಿಮಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಕಂಪೈಲರ್ ಬರೆಯುವ ಸಮಯದಲ್ಲಿ ಈ ಪತ್ರವ್ಯವಹಾರವು ಮೆದುಳಿನಲ್ಲಿ ಸುಟ್ಟುಹೋಗುತ್ತದೆ. ಸರಳವಾದ ಕಂಪೈಲರ್ ಕೂಡ. ಅದರ ನಂತರ, ನೀವು ಜಾವಾವನ್ನು ನೋಡಲು ಪ್ರಾರಂಭಿಸಬಹುದು ಮತ್ತು ಅದರ ಶಬ್ದಾರ್ಥದ ಕಂದರವು ಹೆಚ್ಚು ಆಳವಾಗಿದೆ ಮತ್ತು ಅದರ ಮೇಲೆ ಸೇತುವೆಗಳನ್ನು ನಿರ್ಮಿಸುವುದು ಹೆಚ್ಚು ಕಷ್ಟಕರವಾಗಿದೆ. ಜಾವಾದಲ್ಲಿ, ನಮ್ಮ ಸೇತುವೆ ಒಳ್ಳೆಯದು ಅಥವಾ ಕೆಟ್ಟದ್ದಾಗಿದೆಯೇ, ಅದು ಕುಸಿಯಲು ಏನು ಕಾರಣವಾಗುತ್ತದೆ ಮತ್ತು ಯಾವುದು ಆಗುವುದಿಲ್ಲ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಹೆಚ್ಚು ಕಷ್ಟ. ಆದರೆ ನೀವು ಕೋಡ್ ಅನ್ನು ನೋಡುವ ಮತ್ತು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವ ಕೆಲವು ರೀತಿಯ ಪ್ರಾರಂಭದ ಹಂತವು ನಿಮಗೆ ಬೇಕಾಗುತ್ತದೆ: "ಹೌದು, ಈ ಗೆಟರ್ ಪ್ರತಿ ಬಾರಿಯೂ ಇನ್ಲೈನ್ ​​ಮಾಡಬೇಕು." ತದನಂತರ ಕೆಲವೊಮ್ಮೆ ಇದು ಸಂಭವಿಸುತ್ತದೆ, ವಿಧಾನವು ತುಂಬಾ ದೊಡ್ಡದಾದಾಗ ಪರಿಸ್ಥಿತಿಯನ್ನು ಹೊರತುಪಡಿಸಿ, ಮತ್ತು JIT ಎಲ್ಲವನ್ನೂ ಇನ್ಲೈನಿಂಗ್ ಮಾಡಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ. ಅಂತಹ ಸ್ಥಳಗಳ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ತಕ್ಷಣವೇ ಊಹಿಸಬಹುದು. ಸಾಮಾನ್ಯವಾಗಿ ಪಡೆಯುವವರು ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಾರೆ, ಆದರೆ ನಂತರ ನೀವು ದೊಡ್ಡ ಹಾಟ್ ಲೂಪ್‌ಗಳನ್ನು ನೋಡುತ್ತೀರಿ ಮತ್ತು ಅಲ್ಲಿ ಕೆಲವು ಫಂಕ್ಷನ್ ಕರೆಗಳು ತೇಲುತ್ತಿರುವುದನ್ನು ಅವರು ಏನು ಮಾಡುತ್ತಿದ್ದಾರೆಂದು ತಿಳಿದಿಲ್ಲ ಎಂದು ತಿಳಿದುಕೊಳ್ಳಿ. ಸಿಗುವವರ ವ್ಯಾಪಕ ಬಳಕೆಯಲ್ಲಿನ ಸಮಸ್ಯೆ ಇದು, ಅವರು ಇನ್ಲೈನ್ ​​ಮಾಡದಿರಲು ಕಾರಣ ಅವರು ಪಡೆಯುವವರು ಎಂದು ಸ್ಪಷ್ಟವಾಗಿಲ್ಲ. ನೀವು ಸೂಪರ್ ಸ್ಮಾಲ್ ಕೋಡ್ ಬೇಸ್ ಹೊಂದಿದ್ದರೆ, ನೀವು ಅದನ್ನು ಸರಳವಾಗಿ ನೆನಪಿಟ್ಟುಕೊಳ್ಳಬಹುದು ಮತ್ತು ನಂತರ ಹೇಳಬಹುದು: ಇದು ಗೆಟ್ಟರ್, ಮತ್ತು ಇದು ಸೆಟ್ಟರ್. ದೊಡ್ಡ ಕೋಡ್ ಬೇಸ್ನಲ್ಲಿ, ಪ್ರತಿ ಕಾರ್ಯವು ತನ್ನದೇ ಆದ ಇತಿಹಾಸವನ್ನು ಜೀವಿಸುತ್ತದೆ, ಇದು ಸಾಮಾನ್ಯವಾಗಿ ಯಾರಿಗೂ ತಿಳಿದಿಲ್ಲ. ಕೆಲವು ಲೂಪ್‌ನಲ್ಲಿ ನಾವು 24% ಸಮಯವನ್ನು ಕಳೆದುಕೊಂಡಿದ್ದೇವೆ ಮತ್ತು ಈ ಲೂಪ್ ಏನು ಮಾಡುತ್ತಿದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು, ನಾವು ಒಳಗೆ ಪ್ರತಿ ಕಾರ್ಯವನ್ನು ನೋಡಬೇಕಾಗಿದೆ ಎಂದು ಪ್ರೊಫೈಲರ್ ಹೇಳುತ್ತಾರೆ. ಕಾರ್ಯವನ್ನು ಅಧ್ಯಯನ ಮಾಡದೆ ಇದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಅಸಾಧ್ಯ, ಮತ್ತು ಇದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಗಂಭೀರವಾಗಿ ನಿಧಾನಗೊಳಿಸುತ್ತದೆ. ಅದಕ್ಕಾಗಿಯೇ ನಾನು ಗೆಟ್ಟರ್‌ಗಳು ಮತ್ತು ಸೆಟ್ಟರ್‌ಗಳನ್ನು ಬಳಸುವುದಿಲ್ಲ, ನಾನು ಹೊಸ ಹಂತವನ್ನು ತಲುಪಿದ್ದೇನೆ!
ವೆಚ್ಚದ ಮಾದರಿಯನ್ನು ಎಲ್ಲಿ ಪಡೆಯಬೇಕು? ಸರಿ, ನೀವು ಏನನ್ನಾದರೂ ಓದಬಹುದು, ಸಹಜವಾಗಿ ... ಆದರೆ ನಾನು ಉತ್ತಮ ರೀತಿಯಲ್ಲಿ ವರ್ತಿಸುವುದು ಎಂದು ಭಾವಿಸುತ್ತೇನೆ. ಸಣ್ಣ ಕಂಪೈಲರ್ ಅನ್ನು ತಯಾರಿಸುವುದು ವೆಚ್ಚದ ಮಾದರಿಯನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಮತ್ತು ಅದನ್ನು ನಿಮ್ಮ ಸ್ವಂತ ತಲೆಗೆ ಹೊಂದಿಸಲು ಉತ್ತಮ ಮಾರ್ಗವಾಗಿದೆ. ಮೈಕ್ರೋವೇವ್ ಅನ್ನು ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಮಾಡಲು ಸೂಕ್ತವಾದ ಸಣ್ಣ ಕಂಪೈಲರ್ ಹರಿಕಾರರಿಗೆ ಒಂದು ಕಾರ್ಯವಾಗಿದೆ. ಸರಿ, ನನ್ನ ಪ್ರಕಾರ, ನೀವು ಈಗಾಗಲೇ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಕೌಶಲ್ಯಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ಅದು ಸಾಕು. ಕೆಲವು ರೀತಿಯ ಬೀಜಗಣಿತದ ಅಭಿವ್ಯಕ್ತಿಯಾಗಿ ನೀವು ಹೊಂದಿರುವ ಸ್ಟ್ರಿಂಗ್ ಅನ್ನು ಪಾರ್ಸಿಂಗ್ ಮಾಡುವುದು, ಅಲ್ಲಿಂದ ಸರಿಯಾದ ಕ್ರಮದಲ್ಲಿ ಗಣಿತದ ಕಾರ್ಯಾಚರಣೆಗಳಿಗೆ ಸೂಚನೆಗಳನ್ನು ಹೊರತೆಗೆಯುವುದು, ರೆಜಿಸ್ಟರ್‌ಗಳಿಂದ ಸರಿಯಾದ ಮೌಲ್ಯಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುವುದು - ಇವೆಲ್ಲವನ್ನೂ ಒಂದೇ ಬಾರಿಗೆ ಮಾಡಲಾಗುತ್ತದೆ. ಮತ್ತು ನೀವು ಅದನ್ನು ಮಾಡುವಾಗ, ಅದು ನಿಮ್ಮ ಮೆದುಳಿನಲ್ಲಿ ಅಚ್ಚೊತ್ತುತ್ತದೆ. ಕಂಪೈಲರ್ ಏನು ಮಾಡುತ್ತದೆ ಎಂದು ಎಲ್ಲರಿಗೂ ತಿಳಿದಿದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ಮತ್ತು ಇದು ವೆಚ್ಚದ ಮಾದರಿಯ ತಿಳುವಳಿಕೆಯನ್ನು ನೀಡುತ್ತದೆ.

ಕಾರ್ಯಕ್ಷಮತೆ ಸುಧಾರಣೆಯ ಪ್ರಾಯೋಗಿಕ ಉದಾಹರಣೆಗಳು

ಆಂಡ್ರಾಯ್ಡ್: ಉತ್ಪಾದಕತೆಯ ಮೇಲೆ ಕೆಲಸ ಮಾಡುವಾಗ ನೀವು ಇನ್ನೇನು ಗಮನ ಕೊಡಬೇಕು?

ಕ್ಲಿಫ್: ಡೇಟಾ ರಚನೆಗಳು. ಅಂದಹಾಗೆ, ಹೌದು, ನಾನು ಈ ತರಗತಿಗಳನ್ನು ದೀರ್ಘಕಾಲ ಕಲಿಸಿಲ್ಲ... ರಾಕೆಟ್ ಶಾಲೆ. ಇದು ವಿನೋದವಾಗಿತ್ತು, ಆದರೆ ಇದು ಬಹಳಷ್ಟು ಪ್ರಯತ್ನವನ್ನು ಮಾಡಬೇಕಾಗಿತ್ತು ಮತ್ತು ನನಗೂ ಒಂದು ಜೀವನವಿದೆ! ಸರಿ. ಆದ್ದರಿಂದ, ದೊಡ್ಡ ಮತ್ತು ಆಸಕ್ತಿದಾಯಕ ತರಗತಿಗಳಲ್ಲಿ, "ನಿಮ್ಮ ಕಾರ್ಯಕ್ಷಮತೆ ಎಲ್ಲಿಗೆ ಹೋಗುತ್ತದೆ," ನಾನು ವಿದ್ಯಾರ್ಥಿಗಳಿಗೆ ಒಂದು ಉದಾಹರಣೆಯನ್ನು ನೀಡಿದ್ದೇನೆ: ಎರಡೂವರೆ ಗಿಗಾಬೈಟ್‌ಗಳ ಫಿನ್‌ಟೆಕ್ ಡೇಟಾವನ್ನು CSV ಫೈಲ್‌ನಿಂದ ಓದಲಾಗಿದೆ ಮತ್ತು ನಂತರ ಅವರು ಮಾರಾಟವಾದ ಉತ್ಪನ್ನಗಳ ಸಂಖ್ಯೆಯನ್ನು ಲೆಕ್ಕ ಹಾಕಬೇಕಾಗಿತ್ತು. . ನಿಯಮಿತ ಟಿಕ್ ಮಾರುಕಟ್ಟೆ ಡೇಟಾ. 70 ರ ದಶಕದಿಂದಲೂ UDP ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಪಠ್ಯ ಸ್ವರೂಪಕ್ಕೆ ಪರಿವರ್ತಿಸಲಾಗಿದೆ. ಚಿಕಾಗೋ ಮರ್ಕೆಂಟೈಲ್ ಎಕ್ಸ್‌ಚೇಂಜ್ - ಬೆಣ್ಣೆ, ಕಾರ್ನ್, ಸೋಯಾಬೀನ್, ಮುಂತಾದ ಎಲ್ಲಾ ರೀತಿಯ ವಸ್ತುಗಳು. ಈ ಉತ್ಪನ್ನಗಳು, ವಹಿವಾಟುಗಳ ಸಂಖ್ಯೆ, ಹಣ ಮತ್ತು ಸರಕುಗಳ ಚಲನೆಯ ಸರಾಸರಿ ಪರಿಮಾಣ ಇತ್ಯಾದಿಗಳನ್ನು ಎಣಿಸುವುದು ಅಗತ್ಯವಾಗಿತ್ತು. ಇದು ಬಹಳ ಸರಳವಾದ ವ್ಯಾಪಾರ ಗಣಿತವಾಗಿದೆ: ಉತ್ಪನ್ನ ಕೋಡ್ ಅನ್ನು ಹುಡುಕಿ (ಅದು ಹ್ಯಾಶ್ ಟೇಬಲ್‌ನಲ್ಲಿ 1-2 ಅಕ್ಷರಗಳು), ಮೊತ್ತವನ್ನು ಪಡೆಯಿರಿ, ಅದನ್ನು ವ್ಯಾಪಾರದ ಸೆಟ್‌ಗಳಲ್ಲಿ ಒಂದಕ್ಕೆ ಸೇರಿಸಿ, ಪರಿಮಾಣವನ್ನು ಸೇರಿಸಿ, ಮೌಲ್ಯವನ್ನು ಸೇರಿಸಿ ಮತ್ತು ಒಂದೆರಡು ಇತರ ವಿಷಯಗಳು. ತುಂಬಾ ಸರಳವಾದ ಗಣಿತ. ಆಟಿಕೆ ಅನುಷ್ಠಾನವು ತುಂಬಾ ಸರಳವಾಗಿದೆ: ಎಲ್ಲವೂ ಫೈಲ್‌ನಲ್ಲಿದೆ, ನಾನು ಫೈಲ್ ಅನ್ನು ಓದುತ್ತೇನೆ ಮತ್ತು ಅದರ ಮೂಲಕ ಚಲಿಸುತ್ತೇನೆ, ಪ್ರತ್ಯೇಕ ದಾಖಲೆಗಳನ್ನು ಜಾವಾ ತಂತಿಗಳಾಗಿ ವಿಭಜಿಸುತ್ತೇನೆ, ಅವುಗಳಲ್ಲಿ ಅಗತ್ಯವಾದ ವಸ್ತುಗಳನ್ನು ಹುಡುಕುತ್ತೇನೆ ಮತ್ತು ಮೇಲೆ ವಿವರಿಸಿದ ಗಣಿತದ ಪ್ರಕಾರ ಅವುಗಳನ್ನು ಸೇರಿಸುತ್ತೇನೆ. ಮತ್ತು ಇದು ಸ್ವಲ್ಪ ಕಡಿಮೆ ವೇಗದಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.

ಈ ವಿಧಾನದೊಂದಿಗೆ, ಏನು ನಡೆಯುತ್ತಿದೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ ಮತ್ತು ಸಮಾನಾಂತರ ಕಂಪ್ಯೂಟಿಂಗ್ ಸಹಾಯ ಮಾಡುವುದಿಲ್ಲ, ಸರಿ? ಸರಿಯಾದ ಡೇಟಾ ರಚನೆಗಳನ್ನು ಆರಿಸುವ ಮೂಲಕ ಕಾರ್ಯಕ್ಷಮತೆಯಲ್ಲಿ ಐದು ಪಟ್ಟು ಹೆಚ್ಚಳವನ್ನು ಸಾಧಿಸಬಹುದು ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ. ಮತ್ತು ಇದು ಅನುಭವಿ ಪ್ರೋಗ್ರಾಮರ್ಗಳನ್ನು ಸಹ ಆಶ್ಚರ್ಯಗೊಳಿಸುತ್ತದೆ! ನನ್ನ ನಿರ್ದಿಷ್ಟ ಸಂದರ್ಭದಲ್ಲಿ, ನೀವು ಹಾಟ್ ಲೂಪ್‌ನಲ್ಲಿ ಮೆಮೊರಿ ಹಂಚಿಕೆಗಳನ್ನು ಮಾಡಬಾರದು ಎಂಬುದು ಟ್ರಿಕ್ ಆಗಿತ್ತು. ಸರಿ, ಇದು ಸಂಪೂರ್ಣ ಸತ್ಯವಲ್ಲ, ಆದರೆ ಸಾಮಾನ್ಯವಾಗಿ - X ಸಾಕಷ್ಟು ದೊಡ್ಡದಾದಾಗ ನೀವು "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 ಚಕ್ರಗಳನ್ನು ನೋಡಿದರೆ, ಅವೆಲ್ಲವೂ ಯಂಗ್ ಜನರೇಷನ್ ಮತ್ತು ಸೂಪರ್ ಫಾಸ್ಟ್ - ಮೈಕ್ರೋಸೆಕೆಂಡ್‌ಗಳು ಅಥವಾ ಮಿಲಿಸೆಕೆಂಡ್‌ಗಳು ಗರಿಷ್ಠ. ಎಲ್ಲಾ ನಂತರ, ಈ ಎಲ್ಲಾ ಸ್ಮರಣೆಯು ತಕ್ಷಣವೇ ಸಾಯುತ್ತದೆ. ನೀವು ಶತಕೋಟಿ ಗಿಗಾಬೈಟ್ಗಳನ್ನು ನಿಯೋಜಿಸಿ, ಮತ್ತು ಅವನು ಅವುಗಳನ್ನು ಕತ್ತರಿಸಿ, ಮತ್ತು ಅವುಗಳನ್ನು ಕತ್ತರಿಸಿ, ಮತ್ತು ಅವುಗಳನ್ನು ಮತ್ತೆ ಕತ್ತರಿಸುತ್ತಾನೆ. ಇದೆಲ್ಲವೂ ಬಹಳ ಬೇಗನೆ ಸಂಭವಿಸುತ್ತದೆ. ಅಗ್ಗದ ಜಿಸಿ ಚಕ್ರಗಳು, ಇಡೀ ಚಕ್ರದ ಉದ್ದಕ್ಕೂ ಬೆಚ್ಚಗಿನ ಶಬ್ದಗಳಿವೆ ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ, ಆದರೆ ನಾವು 5x ವೇಗವನ್ನು ಪಡೆಯಲು ಬಯಸುತ್ತೇವೆ. ಈ ಕ್ಷಣದಲ್ಲಿ, ನಿಮ್ಮ ತಲೆಯಲ್ಲಿ ಏನನ್ನಾದರೂ ಮುಚ್ಚಬೇಕು ಮತ್ತು ಧ್ವನಿಸಬೇಕು: "ಇದು ಏಕೆ?!" ಕ್ಲಾಸಿಕ್ ಡೀಬಗರ್‌ನಲ್ಲಿ ಮೆಮೊರಿ ಸ್ಟ್ರಿಪ್ ಓವರ್‌ಫ್ಲೋ ಅನ್ನು ಪ್ರದರ್ಶಿಸಲಾಗುವುದಿಲ್ಲ; ನೀವು ಹಾರ್ಡ್‌ವೇರ್ ಕಾರ್ಯಕ್ಷಮತೆ ಕೌಂಟರ್ ಡೀಬಗರ್ ಅನ್ನು ರನ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ನೀವೇ ಮತ್ತು ನೇರವಾಗಿ ನೋಡಿ. ಆದರೆ ಈ ಮೂರು ಲಕ್ಷಣಗಳಿಂದ ಇದನ್ನು ನೇರವಾಗಿ ಶಂಕಿಸಲಾಗುವುದಿಲ್ಲ. ಮೂರನೆಯ ಲಕ್ಷಣವೆಂದರೆ ನೀವು ಹೈಲೈಟ್ ಮಾಡುವದನ್ನು ನೀವು ನೋಡಿದಾಗ, ಪ್ರೊಫೈಲರ್ ಅನ್ನು ಕೇಳಿ ಮತ್ತು ಅವರು ಉತ್ತರಿಸುತ್ತಾರೆ: "ನೀವು ಒಂದು ಬಿಲಿಯನ್ ಸಾಲುಗಳನ್ನು ಮಾಡಿದ್ದೀರಿ, ಆದರೆ GC ಉಚಿತವಾಗಿ ಕೆಲಸ ಮಾಡಿದೆ." ಇದು ಸಂಭವಿಸಿದ ತಕ್ಷಣ, ನೀವು ಹಲವಾರು ವಸ್ತುಗಳನ್ನು ರಚಿಸಿದ್ದೀರಿ ಮತ್ತು ಸಂಪೂರ್ಣ ಮೆಮೊರಿ ಲೇನ್ ಅನ್ನು ಸುಟ್ಟುಹಾಕಿದ್ದೀರಿ ಎಂದು ನೀವು ತಿಳಿದುಕೊಳ್ಳುತ್ತೀರಿ. ಇದನ್ನು ಕಂಡುಹಿಡಿಯಲು ಒಂದು ಮಾರ್ಗವಿದೆ, ಆದರೆ ಅದು ಸ್ಪಷ್ಟವಾಗಿಲ್ಲ. 

ಸಮಸ್ಯೆಯು ಡೇಟಾ ರಚನೆಯಲ್ಲಿದೆ: ನಡೆಯುವ ಎಲ್ಲದಕ್ಕೂ ಆಧಾರವಾಗಿರುವ ಬೇರ್ ರಚನೆ, ಇದು ತುಂಬಾ ದೊಡ್ಡದಾಗಿದೆ, ಇದು ಡಿಸ್ಕ್ನಲ್ಲಿ 2.7G ಆಗಿದೆ, ಆದ್ದರಿಂದ ಈ ವಿಷಯದ ನಕಲನ್ನು ಮಾಡುವುದು ತುಂಬಾ ಅನಪೇಕ್ಷಿತವಾಗಿದೆ - ನೀವು ಅದನ್ನು ತಕ್ಷಣವೇ ನೆಟ್ವರ್ಕ್ ಬೈಟ್ ಬಫರ್ನಿಂದ ಲೋಡ್ ಮಾಡಲು ಬಯಸುತ್ತೀರಿ ರೆಜಿಸ್ಟರ್‌ಗಳಲ್ಲಿ, ಐದು ಬಾರಿ ಹಿಂದಕ್ಕೆ ಮತ್ತು ಮುಂದಕ್ಕೆ ಓದಲು-ಬರೆಯದಂತೆ. ದುರದೃಷ್ಟವಶಾತ್, ಜಾವಾ ನಿಮಗೆ ಡೀಫಾಲ್ಟ್ ಆಗಿ JDK ನ ಭಾಗವಾಗಿ ಅಂತಹ ಲೈಬ್ರರಿಯನ್ನು ನೀಡುವುದಿಲ್ಲ. ಆದರೆ ಇದು ಕ್ಷುಲ್ಲಕವಾಗಿದೆ, ಸರಿ? ಮೂಲಭೂತವಾಗಿ, ಇವುಗಳು ನಿಮ್ಮ ಸ್ವಂತ ಬಫರ್ಡ್ ಸ್ಟ್ರಿಂಗ್ ಲೋಡರ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು 5-10 ಸಾಲುಗಳ ಕೋಡ್ ಆಗಿದ್ದು, ಇದು ಸ್ಟ್ರಿಂಗ್ ವರ್ಗದ ನಡವಳಿಕೆಯನ್ನು ಪುನರಾವರ್ತಿಸುತ್ತದೆ, ಆದರೆ ಆಧಾರವಾಗಿರುವ ಬೈಟ್ ಬಫರ್ ಸುತ್ತಲೂ ರ್ಯಾಪರ್ ಆಗಿರುತ್ತದೆ. ಪರಿಣಾಮವಾಗಿ, ನೀವು ಬಹುತೇಕ ತಂತಿಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದೀರಿ ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ, ಆದರೆ ವಾಸ್ತವವಾಗಿ ಬಫರ್‌ಗೆ ಪಾಯಿಂಟರ್‌ಗಳು ಅಲ್ಲಿಗೆ ಚಲಿಸುತ್ತಿವೆ ಮತ್ತು ಕಚ್ಚಾ ಬೈಟ್‌ಗಳನ್ನು ಎಲ್ಲಿಯೂ ನಕಲಿಸಲಾಗುವುದಿಲ್ಲ ಮತ್ತು ಆದ್ದರಿಂದ ಅದೇ ಬಫರ್‌ಗಳನ್ನು ಮತ್ತೆ ಮತ್ತೆ ಬಳಸಲಾಗುತ್ತದೆ, ಮತ್ತು ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಈ ಬೈಟ್ ಬಫರ್‌ಗಳ ಗುಪ್ತ ಡಬಲ್-ಬಫರಿಂಗ್‌ನಂತಹ ವಿನ್ಯಾಸಗೊಳಿಸಿದ ವಿಷಯಗಳನ್ನು ನೀವೇ ತೆಗೆದುಕೊಳ್ಳಲು ಸಂತೋಷಪಡುತ್ತದೆ ಮತ್ತು ನೀವು ಇನ್ನು ಮುಂದೆ ಅನಗತ್ಯ ಡೇಟಾದ ಅಂತ್ಯವಿಲ್ಲದ ಸ್ಟ್ರೀಮ್ ಮೂಲಕ ಗ್ರೈಂಡಿಂಗ್ ಮಾಡುತ್ತಿಲ್ಲ. ಮೂಲಕ, GC ಯೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವಾಗ, ಕೊನೆಯ GC ಚಕ್ರದ ನಂತರ ಪ್ರತಿ ಮೆಮೊರಿ ಹಂಚಿಕೆಯು ಪ್ರೊಸೆಸರ್‌ಗೆ ಗೋಚರಿಸುವುದಿಲ್ಲ ಎಂದು ಖಾತರಿಪಡಿಸಲಾಗಿದೆ ಎಂದು ನೀವು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೀರಾ? ಆದ್ದರಿಂದ, ಇದೆಲ್ಲವೂ ಸಂಗ್ರಹದಲ್ಲಿರಲು ಸಾಧ್ಯವಿಲ್ಲ, ಮತ್ತು ನಂತರ 100% ಗ್ಯಾರಂಟಿ ಮಿಸ್ ಸಂಭವಿಸುತ್ತದೆ. ಪಾಯಿಂಟರ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವಾಗ, x86 ನಲ್ಲಿ, ಮೆಮೊರಿಯಿಂದ ರಿಜಿಸ್ಟರ್ ಅನ್ನು ಕಳೆಯುವುದು 1-2 ಗಡಿಯಾರ ಚಕ್ರಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ಮತ್ತು ಇದು ಸಂಭವಿಸಿದ ತಕ್ಷಣ, ನೀವು ಪಾವತಿಸಿ, ಪಾವತಿಸಿ, ಪಾವತಿಸಿ, ಏಕೆಂದರೆ ಮೆಮೊರಿ ಎಲ್ಲಾ ಆನ್ ಆಗಿದೆ ಒಂಬತ್ತು ಸಂಗ್ರಹಗಳು - ಮತ್ತು ಇದು ಮೆಮೊರಿ ಹಂಚಿಕೆಯ ವೆಚ್ಚವಾಗಿದೆ. ನೈಜ ಮೌಲ್ಯ.

ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, ಡೇಟಾ ರಚನೆಗಳನ್ನು ಬದಲಾಯಿಸಲು ಕಠಿಣ ವಿಷಯವಾಗಿದೆ. ಮತ್ತು ಒಮ್ಮೆ ನೀವು ತಪ್ಪಾದ ಡೇಟಾ ರಚನೆಯನ್ನು ಆರಿಸಿದ್ದೀರಿ ಅದು ನಂತರ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ನಾಶಪಡಿಸುತ್ತದೆ, ಸಾಮಾನ್ಯವಾಗಿ ಬಹಳಷ್ಟು ಕೆಲಸಗಳನ್ನು ಮಾಡಬೇಕಾಗಿದೆ, ಆದರೆ ನೀವು ಮಾಡದಿದ್ದರೆ, ವಿಷಯಗಳು ಕೆಟ್ಟದಾಗುತ್ತವೆ. ಮೊದಲನೆಯದಾಗಿ, ನೀವು ಡೇಟಾ ರಚನೆಗಳ ಬಗ್ಗೆ ಯೋಚಿಸಬೇಕು, ಇದು ಮುಖ್ಯವಾಗಿದೆ. ಇಲ್ಲಿ ಮುಖ್ಯ ವೆಚ್ಚವು ಕೊಬ್ಬಿನ ದತ್ತಾಂಶ ರಚನೆಗಳ ಮೇಲೆ ಬೀಳುತ್ತದೆ, ಇದನ್ನು "ನಾನು ಡೇಟಾ ರಚನೆ X ಅನ್ನು ಡೇಟಾ ರಚನೆಯನ್ನು Y ಗೆ ನಕಲಿಸಿದ್ದೇನೆ ಏಕೆಂದರೆ ನಾನು Y ಆಕಾರವನ್ನು ಉತ್ತಮವಾಗಿ ಇಷ್ಟಪಡುತ್ತೇನೆ" ಶೈಲಿಯಲ್ಲಿ ಬಳಸಲು ಪ್ರಾರಂಭಿಸಿದೆ. ಆದರೆ ನಕಲು ಕಾರ್ಯಾಚರಣೆ (ಇದು ಅಗ್ಗವಾಗಿ ತೋರುತ್ತದೆ) ವಾಸ್ತವವಾಗಿ ಮೆಮೊರಿ ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್ ಅನ್ನು ವ್ಯರ್ಥ ಮಾಡುತ್ತದೆ ಮತ್ತು ಅಲ್ಲಿಯೇ ಎಲ್ಲಾ ವ್ಯರ್ಥ ಕಾರ್ಯಗತಗೊಳಿಸುವ ಸಮಯವನ್ನು ಹೂಳಲಾಗುತ್ತದೆ. ನಾನು JSON ನ ದೈತ್ಯ ಸ್ಟ್ರಿಂಗ್ ಅನ್ನು ಹೊಂದಿದ್ದರೆ ಮತ್ತು ಅದನ್ನು POJO ಗಳ ರಚನಾತ್ಮಕ DOM ಟ್ರೀ ಆಗಿ ಪರಿವರ್ತಿಸಲು ನಾನು ಬಯಸಿದರೆ, ಆ ಸ್ಟ್ರಿಂಗ್ ಅನ್ನು ಪಾರ್ಸಿಂಗ್ ಮಾಡುವ ಮತ್ತು POJO ಅನ್ನು ನಿರ್ಮಿಸುವ ಕಾರ್ಯಾಚರಣೆ ಮತ್ತು ನಂತರ POJO ಅನ್ನು ಮತ್ತೆ ಪ್ರವೇಶಿಸುವುದು ಅನಗತ್ಯ ವೆಚ್ಚಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ - ಇದು ಅಗ್ಗದ ಅಲ್ಲ. ನೀವು ಸ್ಟ್ರಿಂಗ್ ಸುತ್ತಲೂ ಓಡುವುದಕ್ಕಿಂತ ಹೆಚ್ಚಾಗಿ POJO ಗಳ ಸುತ್ತಲೂ ಓಡುತ್ತಿದ್ದರೆ ಹೊರತುಪಡಿಸಿ. ಆಫ್‌ಹ್ಯಾಂಡ್, ಬದಲಿಗೆ ನೀವು ಸ್ಟ್ರಿಂಗ್ ಅನ್ನು ಡೀಕ್ರಿಪ್ಟ್ ಮಾಡಲು ಪ್ರಯತ್ನಿಸಬಹುದು ಮತ್ತು ಅದನ್ನು ಯಾವುದೇ POJO ಆಗಿ ಪರಿವರ್ತಿಸದೆ ನಿಮಗೆ ಬೇಕಾದುದನ್ನು ಮಾತ್ರ ಹೊರತೆಗೆಯಬಹುದು. ಗರಿಷ್ಟ ಕಾರ್ಯಕ್ಷಮತೆಯ ಅಗತ್ಯವಿರುವ ಹಾದಿಯಲ್ಲಿ ಇದೆಲ್ಲವೂ ಸಂಭವಿಸಿದಲ್ಲಿ, ನಿಮಗಾಗಿ ಯಾವುದೇ POJO ಗಳಿಲ್ಲ, ನೀವು ಹೇಗಾದರೂ ನೇರವಾಗಿ ಸಾಲಿನಲ್ಲಿ ಡಿಗ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ.

ನಿಮ್ಮ ಸ್ವಂತ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಭಾಷೆಯನ್ನು ಏಕೆ ರಚಿಸಬೇಕು

ಆಂಡ್ರಾಯ್ಡ್: ವೆಚ್ಚದ ಮಾದರಿಯನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು, ನಿಮ್ಮ ಸ್ವಂತ ಚಿಕ್ಕ ಭಾಷೆಯನ್ನು ನೀವು ಬರೆಯಬೇಕು ಎಂದು ನೀವು ಹೇಳಿದ್ದೀರಿ...

ಕ್ಲಿಫ್: ಒಂದು ಭಾಷೆಯಲ್ಲ, ಆದರೆ ಕಂಪೈಲರ್. ಒಂದು ಭಾಷೆ ಮತ್ತು ಕಂಪೈಲರ್ ಎರಡು ವಿಭಿನ್ನ ವಿಷಯಗಳು. ಪ್ರಮುಖ ವ್ಯತ್ಯಾಸವೆಂದರೆ ನಿಮ್ಮ ತಲೆಯಲ್ಲಿ. 

ಆಂಡ್ರಾಯ್ಡ್: ಅಂದಹಾಗೆ, ನನಗೆ ತಿಳಿದಿರುವಂತೆ, ನೀವು ನಿಮ್ಮ ಸ್ವಂತ ಭಾಷೆಗಳನ್ನು ರಚಿಸುವಲ್ಲಿ ಪ್ರಯೋಗ ಮಾಡುತ್ತಿದ್ದೀರಿ. ಯಾವುದಕ್ಕಾಗಿ?

ಕ್ಲಿಫ್: ಏಕೆಂದರೆ ನಾನು ಮಾಡಬಲ್ಲೆ! ನಾನು ಅರೆ ನಿವೃತ್ತಿ ಹೊಂದಿದ್ದೇನೆ, ಆದ್ದರಿಂದ ಇದು ನನ್ನ ಹವ್ಯಾಸವಾಗಿದೆ. ನನ್ನ ಜೀವನದುದ್ದಕ್ಕೂ ನಾನು ಇತರ ಜನರ ಭಾಷೆಗಳನ್ನು ಅನುಷ್ಠಾನಗೊಳಿಸುತ್ತಿದ್ದೇನೆ. ನನ್ನ ಕೋಡಿಂಗ್ ಶೈಲಿಯಲ್ಲಿ ನಾನು ಸಾಕಷ್ಟು ಕೆಲಸ ಮಾಡಿದ್ದೇನೆ. ಮತ್ತು ನಾನು ಇತರ ಭಾಷೆಗಳಲ್ಲಿ ಸಮಸ್ಯೆಗಳನ್ನು ನೋಡುವುದರಿಂದ. ಪರಿಚಿತ ವಿಷಯಗಳನ್ನು ಮಾಡಲು ಉತ್ತಮ ಮಾರ್ಗಗಳಿವೆ ಎಂದು ನಾನು ನೋಡುತ್ತೇನೆ. ಮತ್ತು ನಾನು ಅವುಗಳನ್ನು ಬಳಸುತ್ತಿದ್ದೆ. ನನ್ನಲ್ಲಿ, ಜಾವಾದಲ್ಲಿ, ಪೈಥಾನ್‌ನಲ್ಲಿ, ಬೇರೆ ಯಾವುದೇ ಭಾಷೆಯಲ್ಲಿ ಸಮಸ್ಯೆಗಳನ್ನು ನೋಡಿ ನನಗೆ ಬೇಸರವಾಗಿದೆ. ನಾನು ಈಗ ರಿಯಾಕ್ಟ್ ನೇಟಿವ್, ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಮತ್ತು ಎಲ್ಮ್‌ನಲ್ಲಿ ನಿವೃತ್ತಿಯ ಬಗ್ಗೆ ಅಲ್ಲ, ಆದರೆ ಸಕ್ರಿಯ ಕೆಲಸದ ಬಗ್ಗೆ ಹವ್ಯಾಸವಾಗಿ ಬರೆಯುತ್ತೇನೆ. ನಾನು ಪೈಥಾನ್‌ನಲ್ಲಿ ಸಹ ಬರೆಯುತ್ತೇನೆ ಮತ್ತು ಜಾವಾ ಬ್ಯಾಕೆಂಡ್‌ಗಳಿಗಾಗಿ ಯಂತ್ರ ಕಲಿಕೆಯಲ್ಲಿ ಕೆಲಸ ಮಾಡುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತೇನೆ. ಅನೇಕ ಜನಪ್ರಿಯ ಭಾಷೆಗಳಿವೆ ಮತ್ತು ಅವೆಲ್ಲವೂ ಆಸಕ್ತಿದಾಯಕ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಹೊಂದಿವೆ. ಪ್ರತಿಯೊಬ್ಬರೂ ತಮ್ಮದೇ ಆದ ರೀತಿಯಲ್ಲಿ ಒಳ್ಳೆಯವರಾಗಿದ್ದಾರೆ ಮತ್ತು ಈ ಎಲ್ಲಾ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಒಟ್ಟಿಗೆ ತರಲು ನೀವು ಪ್ರಯತ್ನಿಸಬಹುದು. ಆದ್ದರಿಂದ, ನಾನು ನನಗೆ ಆಸಕ್ತಿಯಿರುವ ವಿಷಯಗಳನ್ನು ಅಧ್ಯಯನ ಮಾಡುತ್ತಿದ್ದೇನೆ, ಭಾಷೆಯ ನಡವಳಿಕೆ, ಸಮಂಜಸವಾದ ಶಬ್ದಾರ್ಥಗಳೊಂದಿಗೆ ಬರಲು ಪ್ರಯತ್ನಿಸುತ್ತೇನೆ. ಮತ್ತು ಇಲ್ಲಿಯವರೆಗೆ ನಾನು ಯಶಸ್ವಿಯಾಗಿದ್ದೇನೆ! ಈ ಸಮಯದಲ್ಲಿ ನಾನು ಮೆಮೊರಿ ಸೆಮ್ಯಾಂಟಿಕ್ಸ್‌ನೊಂದಿಗೆ ಹೋರಾಡುತ್ತಿದ್ದೇನೆ, ಏಕೆಂದರೆ ನಾನು ಅದನ್ನು ಸಿ ಮತ್ತು ಜಾವಾದಲ್ಲಿ ಹೊಂದಲು ಬಯಸುತ್ತೇನೆ ಮತ್ತು ಲೋಡ್‌ಗಳು ಮತ್ತು ಸ್ಟೋರ್‌ಗಳಿಗಾಗಿ ಬಲವಾದ ಮೆಮೊರಿ ಮಾದರಿ ಮತ್ತು ಮೆಮೊರಿ ಸೆಮ್ಯಾಂಟಿಕ್ಸ್ ಅನ್ನು ಪಡೆಯಲು ಬಯಸುತ್ತೇನೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಹ್ಯಾಸ್ಕೆಲ್‌ನಲ್ಲಿರುವಂತೆ ಸ್ವಯಂಚಾಲಿತ ಪ್ರಕಾರದ ತೀರ್ಮಾನವನ್ನು ಹೊಂದಿರಿ. ಇಲ್ಲಿ, ನಾನು C ಮತ್ತು Java ಎರಡರಲ್ಲೂ ಮೆಮೊರಿ ಕೆಲಸದೊಂದಿಗೆ ಹ್ಯಾಸ್ಕೆಲ್ ತರಹದ ತೀರ್ಮಾನವನ್ನು ಮಿಶ್ರಣ ಮಾಡಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದ್ದೇನೆ. ಉದಾಹರಣೆಗೆ ಕಳೆದ 2-3 ತಿಂಗಳಿಂದ ನಾನು ಮಾಡುತ್ತಿರುವುದು ಇದನ್ನೇ.

ಆಂಡ್ರಾಯ್ಡ್: ನೀವು ಇತರ ಭಾಷೆಗಳಿಂದ ಉತ್ತಮ ಅಂಶಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುವ ಭಾಷೆಯನ್ನು ನಿರ್ಮಿಸಿದರೆ, ಯಾರಾದರೂ ವಿರುದ್ಧವಾಗಿ ಮಾಡುತ್ತಾರೆ ಎಂದು ನೀವು ಭಾವಿಸುತ್ತೀರಾ: ನಿಮ್ಮ ಆಲೋಚನೆಗಳನ್ನು ತೆಗೆದುಕೊಂಡು ಅವುಗಳನ್ನು ಬಳಸಿ?

ಕ್ಲಿಫ್: ಹೊಸ ಭಾಷೆಗಳು ಹೇಗೆ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತವೆ! ಜಾವಾ C ಗೆ ಏಕೆ ಹೋಲುತ್ತದೆ? ಏಕೆಂದರೆ ಸಿ ಎಲ್ಲರಿಗೂ ಅರ್ಥವಾಗುವ ಉತ್ತಮ ಸಿಂಟ್ಯಾಕ್ಸ್ ಅನ್ನು ಹೊಂದಿತ್ತು ಮತ್ತು ಜಾವಾ ಈ ಸಿಂಟ್ಯಾಕ್ಸ್‌ನಿಂದ ಪ್ರೇರಿತವಾಗಿದೆ, ಟೈಪ್ ಸುರಕ್ಷತೆ, ಅರೇ ಬೌಂಡ್‌ಗಳ ಪರಿಶೀಲನೆ, ಜಿಸಿ ಸೇರಿಸಿ, ಮತ್ತು ಅವರು ಸಿ ಯಿಂದ ಕೆಲವು ವಿಷಯಗಳನ್ನು ಸುಧಾರಿಸಿದರು. ಅವರು ತಮ್ಮದೇ ಆದದನ್ನು ಸೇರಿಸಿದರು. ಆದರೆ ಅವರು ಸಾಕಷ್ಟು ಸ್ಫೂರ್ತಿ ಪಡೆದರು, ಸರಿ? ಎಲ್ಲರೂ ನಿಮಗಿಂತ ಮೊದಲು ಬಂದ ದೈತ್ಯರ ಹೆಗಲ ಮೇಲೆ ನಿಂತಿದ್ದಾರೆ - ಹೀಗೆಯೇ ಪ್ರಗತಿ ಸಾಧಿಸಲಾಗುತ್ತದೆ.

ಆಂಡ್ರಾಯ್ಡ್: ನಾನು ಅರ್ಥಮಾಡಿಕೊಂಡಂತೆ, ನಿಮ್ಮ ಭಾಷೆ ಮೆಮೊರಿ ಸುರಕ್ಷಿತವಾಗಿರುತ್ತದೆ. ರಸ್ಟ್‌ನಿಂದ ಎರವಲು ಪರೀಕ್ಷಕವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಬಗ್ಗೆ ನೀವು ಯೋಚಿಸಿದ್ದೀರಾ? ನೀವು ಅವನನ್ನು ನೋಡಿದ್ದೀರಾ, ಅವನ ಬಗ್ಗೆ ನಿಮಗೆ ಏನನಿಸುತ್ತದೆ?

ಕ್ಲಿಫ್: ಸರಿ, ನಾನು ಈ ಎಲ್ಲಾ malloc ಮತ್ತು ಉಚಿತ, ಮತ್ತು ಹಸ್ತಚಾಲಿತವಾಗಿ ಜೀವಿತಾವಧಿಯನ್ನು ನಿರ್ವಹಿಸುವುದರೊಂದಿಗೆ, ವಯಸ್ಸಿನಿಂದಲೂ C ಬರೆಯುತ್ತಿದ್ದೇನೆ. ನಿಮಗೆ ಗೊತ್ತಾ, ಹಸ್ತಚಾಲಿತವಾಗಿ ನಿಯಂತ್ರಿತ ಜೀವಿತಾವಧಿಯಲ್ಲಿ 90-95% ಒಂದೇ ರಚನೆಯನ್ನು ಹೊಂದಿದೆ. ಮತ್ತು ಅದನ್ನು ಕೈಯಾರೆ ಮಾಡಲು ತುಂಬಾ ನೋವುಂಟು. ಕಂಪೈಲರ್ ಅಲ್ಲಿ ಏನು ನಡೆಯುತ್ತಿದೆ ಮತ್ತು ನಿಮ್ಮ ಕ್ರಿಯೆಗಳಿಂದ ನೀವು ಏನನ್ನು ಸಾಧಿಸಿದ್ದೀರಿ ಎಂದು ಸರಳವಾಗಿ ಹೇಳಲು ನಾನು ಬಯಸುತ್ತೇನೆ. ಕೆಲವು ವಿಷಯಗಳಿಗಾಗಿ, ಎರವಲು ಪರೀಕ್ಷಕ ಇದನ್ನು ಬಾಕ್ಸ್‌ನ ಹೊರಗೆ ಮಾಡುತ್ತಾರೆ. ಮತ್ತು ಇದು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಮಾಹಿತಿಯನ್ನು ಪ್ರದರ್ಶಿಸಬೇಕು, ಎಲ್ಲವನ್ನೂ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು ಮತ್ತು ಈ ತಿಳುವಳಿಕೆಯನ್ನು ಪ್ರಸ್ತುತಪಡಿಸಲು ನನಗೆ ಹೊರೆಯಾಗಬಾರದು. ಇದು ಕನಿಷ್ಟ ಸ್ಥಳೀಯ ಪಾರು ವಿಶ್ಲೇಷಣೆಯನ್ನು ಮಾಡಬೇಕು, ಮತ್ತು ಅದು ವಿಫಲವಾದರೆ ಮಾತ್ರ, ಜೀವಿತಾವಧಿಯನ್ನು ವಿವರಿಸುವ ಪ್ರಕಾರದ ಟಿಪ್ಪಣಿಗಳನ್ನು ಸೇರಿಸುವ ಅಗತ್ಯವಿದೆ - ಮತ್ತು ಅಂತಹ ಯೋಜನೆಯು ಸಾಲ ಪರೀಕ್ಷಕ ಅಥವಾ ವಾಸ್ತವವಾಗಿ ಯಾವುದೇ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಮೆಮೊರಿ ಪರೀಕ್ಷಕಕ್ಕಿಂತ ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಗಿದೆ. "ಎಲ್ಲವೂ ಚೆನ್ನಾಗಿದೆ" ಮತ್ತು "ನನಗೆ ಏನೂ ಅರ್ಥವಾಗುತ್ತಿಲ್ಲ" ನಡುವಿನ ಆಯ್ಕೆ - ಇಲ್ಲ, ಏನಾದರೂ ಉತ್ತಮವಾಗಿರಬೇಕು. 
ಆದ್ದರಿಂದ, C ಯಲ್ಲಿ ಬಹಳಷ್ಟು ಕೋಡ್ ಅನ್ನು ಬರೆದಿರುವ ವ್ಯಕ್ತಿಯಾಗಿ, ಸ್ವಯಂಚಾಲಿತ ಜೀವಿತಾವಧಿಯ ನಿಯಂತ್ರಣಕ್ಕೆ ಬೆಂಬಲವನ್ನು ಹೊಂದಿರುವುದು ಅತ್ಯಂತ ಮುಖ್ಯವಾದ ವಿಷಯ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ಜಾವಾ ಮೆಮೊರಿಯನ್ನು ಎಷ್ಟು ಬಳಸುತ್ತದೆ ಎಂಬುದರ ಬಗ್ಗೆ ನನಗೆ ಬೇಸರವಾಗಿದೆ ಮತ್ತು ಮುಖ್ಯ ದೂರು GC ಆಗಿದೆ. ನೀವು ಜಾವಾದಲ್ಲಿ ಮೆಮೊರಿಯನ್ನು ನಿಯೋಜಿಸಿದಾಗ, ಕಳೆದ GC ಸೈಕಲ್‌ನಲ್ಲಿ ಸ್ಥಳೀಯವಾಗಿರುವ ಮೆಮೊರಿಯನ್ನು ನೀವು ಮರಳಿ ಪಡೆಯುವುದಿಲ್ಲ. ಹೆಚ್ಚು ನಿಖರವಾದ ಮೆಮೊರಿ ನಿರ್ವಹಣೆಯನ್ನು ಹೊಂದಿರುವ ಭಾಷೆಗಳಲ್ಲಿ ಇದು ಅಲ್ಲ. ನೀವು malloc ಅನ್ನು ಕರೆದರೆ, ನೀವು ತಕ್ಷಣವೇ ಸಾಮಾನ್ಯವಾಗಿ ಬಳಸಿದ ಮೆಮೊರಿಯನ್ನು ಪಡೆಯುತ್ತೀರಿ. ಸಾಮಾನ್ಯವಾಗಿ ನೀವು ಮೆಮೊರಿಯೊಂದಿಗೆ ಕೆಲವು ತಾತ್ಕಾಲಿಕ ಕೆಲಸಗಳನ್ನು ಮಾಡುತ್ತೀರಿ ಮತ್ತು ತಕ್ಷಣವೇ ಅದನ್ನು ಹಿಂತಿರುಗಿಸಿ. ಮತ್ತು ಅದು ತಕ್ಷಣವೇ ಮಲ್ಲೊಕ್ ಪೂಲ್‌ಗೆ ಮರಳುತ್ತದೆ ಮತ್ತು ಮುಂದಿನ ಮಾಲೋಕ್ ಚಕ್ರವು ಅದನ್ನು ಮತ್ತೆ ಎಳೆಯುತ್ತದೆ. ಆದ್ದರಿಂದ, ನಿಜವಾದ ಮೆಮೊರಿ ಬಳಕೆಯು ಒಂದು ನಿರ್ದಿಷ್ಟ ಸಮಯದಲ್ಲಿ ಜೀವಂತ ವಸ್ತುಗಳ ಗುಂಪಿಗೆ ಕಡಿಮೆಯಾಗುತ್ತದೆ, ಜೊತೆಗೆ ಸೋರಿಕೆಯಾಗುತ್ತದೆ. ಮತ್ತು ಎಲ್ಲವೂ ಸಂಪೂರ್ಣವಾಗಿ ಅಸಭ್ಯ ರೀತಿಯಲ್ಲಿ ಸೋರಿಕೆಯಾಗದಿದ್ದರೆ, ಹೆಚ್ಚಿನ ಮೆಮೊರಿಯು ಕ್ಯಾಶ್ ಮತ್ತು ಪ್ರೊಸೆಸರ್ನಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಅದು ತ್ವರಿತವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಆದರೆ malloc ಜೊತೆಗೆ ಸಾಕಷ್ಟು ಹಸ್ತಚಾಲಿತ ಮೆಮೊರಿ ನಿರ್ವಹಣೆ ಅಗತ್ಯವಿರುತ್ತದೆ ಮತ್ತು ಸರಿಯಾದ ಕ್ರಮದಲ್ಲಿ, ಸರಿಯಾದ ಸ್ಥಳದಲ್ಲಿ ಉಚಿತ ಎಂದು ಕರೆಯಲ್ಪಡುತ್ತದೆ. ರಸ್ಟ್ ಇದನ್ನು ತನ್ನದೇ ಆದ ರೀತಿಯಲ್ಲಿ ಸರಿಯಾಗಿ ನಿಭಾಯಿಸಬಲ್ಲದು ಮತ್ತು ಅನೇಕ ಸಂದರ್ಭಗಳಲ್ಲಿ ಇನ್ನೂ ಉತ್ತಮ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ನೀಡುತ್ತದೆ, ಏಕೆಂದರೆ ಮೆಮೊರಿ ಬಳಕೆಯನ್ನು ಕೇವಲ ಪ್ರಸ್ತುತ ಗಣನೆಗೆ ಸಂಕುಚಿತಗೊಳಿಸಲಾಗುತ್ತದೆ - ಮೆಮೊರಿಯನ್ನು ಮುಕ್ತಗೊಳಿಸಲು ಮುಂದಿನ GC ಚಕ್ರಕ್ಕಾಗಿ ಕಾಯುವುದಕ್ಕೆ ವಿರುದ್ಧವಾಗಿ. ಪರಿಣಾಮವಾಗಿ, ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸುಧಾರಿಸಲು ನಾವು ತುಂಬಾ ಆಸಕ್ತಿದಾಯಕ ಮಾರ್ಗವನ್ನು ಪಡೆದುಕೊಂಡಿದ್ದೇವೆ. ಮತ್ತು ಸಾಕಷ್ಟು ಶಕ್ತಿಯುತ - ಅಂದರೆ, ಫಿನ್‌ಟೆಕ್‌ಗಾಗಿ ಡೇಟಾವನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವಾಗ ನಾನು ಅಂತಹ ಕೆಲಸಗಳನ್ನು ಮಾಡಿದ್ದೇನೆ ಮತ್ತು ಇದು ಸುಮಾರು ಐದು ಪಟ್ಟು ವೇಗವನ್ನು ಪಡೆಯಲು ನನಗೆ ಅವಕಾಶ ಮಾಡಿಕೊಟ್ಟಿತು. ಇದು ಬಹಳ ದೊಡ್ಡ ಉತ್ತೇಜನವಾಗಿದೆ, ವಿಶೇಷವಾಗಿ ಪ್ರೊಸೆಸರ್‌ಗಳು ವೇಗವಾಗಿ ಪಡೆಯದ ಜಗತ್ತಿನಲ್ಲಿ ಮತ್ತು ನಾವು ಇನ್ನೂ ಸುಧಾರಣೆಗಳಿಗಾಗಿ ಕಾಯುತ್ತಿದ್ದೇವೆ.

ಕಾರ್ಯಕ್ಷಮತೆ ಇಂಜಿನಿಯರ್ ವೃತ್ತಿ

ಆಂಡ್ರಾಯ್ಡ್: ನಾನು ಸಾಮಾನ್ಯವಾಗಿ ವೃತ್ತಿಜೀವನದ ಬಗ್ಗೆ ಕೇಳಲು ಬಯಸುತ್ತೇನೆ. ಹಾಟ್‌ಸ್ಪಾಟ್‌ನಲ್ಲಿನ ನಿಮ್ಮ JIT ಕೆಲಸದ ಮೂಲಕ ನೀವು ಪ್ರಾಮುಖ್ಯತೆಗೆ ಏರಿದ್ದೀರಿ ಮತ್ತು ನಂತರ JVM ಕಂಪನಿಯೂ ಆಗಿರುವ ಅಜುಲ್‌ಗೆ ಸ್ಥಳಾಂತರಗೊಂಡಿದ್ದೀರಿ. ಆದರೆ ನಾವು ಈಗಾಗಲೇ ಸಾಫ್ಟ್‌ವೇರ್‌ಗಿಂತ ಹಾರ್ಡ್‌ವೇರ್‌ನಲ್ಲಿ ಹೆಚ್ಚು ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದೆವು. ತದನಂತರ ಅವರು ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಬಿಗ್ ಡೇಟಾ ಮತ್ತು ಮೆಷಿನ್ ಲರ್ನಿಂಗ್‌ಗೆ ಬದಲಾಯಿಸಿದರು ಮತ್ತು ನಂತರ ವಂಚನೆ ಪತ್ತೆಗೆ ಬದಲಾಯಿಸಿದರು. ಇದು ಹೇಗಾಯಿತು? ಇವು ಅಭಿವೃದ್ಧಿಯ ವಿಭಿನ್ನ ಕ್ಷೇತ್ರಗಳಾಗಿವೆ.

ಕ್ಲಿಫ್: ನಾನು ಬಹಳ ಸಮಯದಿಂದ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಮಾಡುತ್ತಿದ್ದೇನೆ ಮತ್ತು ಸಾಕಷ್ಟು ವಿಭಿನ್ನ ತರಗತಿಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುವಲ್ಲಿ ಯಶಸ್ವಿಯಾಗಿದ್ದೇನೆ. ಮತ್ತು ಜನರು ಹೇಳಿದಾಗ: "ಓಹ್, ನೀವು ಜಾವಾಕ್ಕಾಗಿ JIT ಮಾಡಿದವರು!", ಇದು ಯಾವಾಗಲೂ ತಮಾಷೆಯಾಗಿರುತ್ತದೆ. ಆದರೆ ಅದಕ್ಕೂ ಮೊದಲು, ನಾನು ಪೋಸ್ಟ್‌ಸ್ಕ್ರಿಪ್ಟ್‌ನ ಕ್ಲೋನ್‌ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದೆ - ಆಪಲ್ ಒಮ್ಮೆ ತನ್ನ ಲೇಸರ್ ಪ್ರಿಂಟರ್‌ಗಳಿಗಾಗಿ ಬಳಸಿದ ಭಾಷೆ. ಮತ್ತು ಅದಕ್ಕೂ ಮೊದಲು ನಾನು ಫೋರ್ತ್ ಭಾಷೆಯ ಅನುಷ್ಠಾನವನ್ನು ಮಾಡಿದೆ. ನನಗೆ ಸಾಮಾನ್ಯ ವಿಷಯವೆಂದರೆ ಸಾಧನ ಅಭಿವೃದ್ಧಿ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ನನ್ನ ಜೀವನದುದ್ದಕ್ಕೂ ನಾನು ಇತರ ಜನರು ತಮ್ಮ ತಂಪಾದ ಕಾರ್ಯಕ್ರಮಗಳನ್ನು ಬರೆಯುವ ಸಾಧನಗಳನ್ನು ತಯಾರಿಸುತ್ತಿದ್ದೇನೆ. ಆದರೆ ನಾನು ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್‌ಗಳು, ಡ್ರೈವರ್‌ಗಳು, ಕರ್ನಲ್-ಲೆವೆಲ್ ಡೀಬಗರ್‌ಗಳು, ಓಎಸ್ ಅಭಿವೃದ್ಧಿಗಾಗಿ ಭಾಷೆಗಳ ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ ತೊಡಗಿಸಿಕೊಂಡಿದ್ದೇನೆ, ಅದು ಕ್ಷುಲ್ಲಕವಾಗಿ ಪ್ರಾರಂಭವಾಯಿತು, ಆದರೆ ಕಾಲಾನಂತರದಲ್ಲಿ ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಯಿತು. ಆದರೆ ಮುಖ್ಯ ವಿಷಯವೆಂದರೆ ಇನ್ನೂ ಉಪಕರಣಗಳ ಅಭಿವೃದ್ಧಿ. ನನ್ನ ಜೀವನದ ಒಂದು ದೊಡ್ಡ ಭಾಗವು ಅಜುಲ್ ಮತ್ತು ಸನ್ ನಡುವೆ ಹಾದುಹೋಯಿತು ಮತ್ತು ಅದು ಜಾವಾ ಬಗ್ಗೆ. ಆದರೆ ನಾನು ಬಿಗ್ ಡೇಟಾ ಮತ್ತು ಮೆಷಿನ್ ಲರ್ನಿಂಗ್‌ನಲ್ಲಿ ತೊಡಗಿಸಿಕೊಂಡಾಗ, ನಾನು ನನ್ನ ಫ್ಯಾನ್ಸಿ ಹ್ಯಾಟ್ ಅನ್ನು ಮತ್ತೆ ಹಾಕಿದೆ ಮತ್ತು "ಓಹ್, ಈಗ ನಮಗೆ ಕ್ಷುಲ್ಲಕವಲ್ಲದ ಸಮಸ್ಯೆ ಇದೆ, ಮತ್ತು ಬಹಳಷ್ಟು ಆಸಕ್ತಿದಾಯಕ ವಿಷಯಗಳು ನಡೆಯುತ್ತಿವೆ ಮತ್ತು ಜನರು ಕೆಲಸಗಳನ್ನು ಮಾಡುತ್ತಿದ್ದಾರೆ." ಇದು ಒಂದು ದೊಡ್ಡ ಅಭಿವೃದ್ಧಿ ಹಾದಿಯಾಗಿದೆ.

ಹೌದು, ನಾನು ವಿತರಣೆ ಕಂಪ್ಯೂಟಿಂಗ್ ಅನ್ನು ನಿಜವಾಗಿಯೂ ಇಷ್ಟಪಡುತ್ತೇನೆ. ನನ್ನ ಮೊದಲ ಕೆಲಸ C ಯಲ್ಲಿ ವಿದ್ಯಾರ್ಥಿಯಾಗಿ, ಜಾಹೀರಾತು ಯೋಜನೆಯಲ್ಲಿ. ಇದು ನೈಜ ಅನಲಾಗ್ ವಿಶ್ಲೇಷಕದಿಂದ ತಯಾರಿಸಲ್ಪಟ್ಟ ಅನಲಾಗ್ OCR ಗಾಗಿ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುವ Zilog Z80 ಚಿಪ್‌ಗಳಲ್ಲಿ ಕಂಪ್ಯೂಟಿಂಗ್ ಅನ್ನು ವಿತರಿಸಲಾಯಿತು. ಇದು ತಂಪಾದ ಮತ್ತು ಸಂಪೂರ್ಣವಾಗಿ ಹುಚ್ಚುತನದ ವಿಷಯವಾಗಿತ್ತು. ಆದರೆ ಸಮಸ್ಯೆಗಳಿವೆ, ಕೆಲವು ಭಾಗವನ್ನು ಸರಿಯಾಗಿ ಗುರುತಿಸಲಾಗಿಲ್ಲ, ಆದ್ದರಿಂದ ನೀವು ಚಿತ್ರವನ್ನು ತೆಗೆದುಕೊಂಡು ಅದನ್ನು ಈಗಾಗಲೇ ಅವರ ಕಣ್ಣುಗಳಿಂದ ಓದುವ ಮತ್ತು ಅದು ಹೇಳಿದ್ದನ್ನು ವರದಿ ಮಾಡುವ ವ್ಯಕ್ತಿಗೆ ತೋರಿಸಬೇಕಾಗಿತ್ತು ಮತ್ತು ಆದ್ದರಿಂದ ಡೇಟಾದೊಂದಿಗೆ ಉದ್ಯೋಗಗಳು ಮತ್ತು ಈ ಉದ್ಯೋಗಗಳು ಇದ್ದವು. ತಮ್ಮದೇ ಆದ ಭಾಷೆಯನ್ನು ಹೊಂದಿದ್ದರು. ಇದೆಲ್ಲವನ್ನೂ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಿದ ಬ್ಯಾಕೆಂಡ್ ಇತ್ತು - Z80s ಚಾಲನೆಯಲ್ಲಿರುವ vt100 ಟರ್ಮಿನಲ್‌ಗಳೊಂದಿಗೆ ಸಮಾನಾಂತರವಾಗಿ ಚಾಲನೆಯಲ್ಲಿದೆ - ಪ್ರತಿ ವ್ಯಕ್ತಿಗೆ ಒಂದು, ಮತ್ತು Z80 ನಲ್ಲಿ ಸಮಾನಾಂತರ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಮಾದರಿ ಇತ್ತು. ಸ್ಟಾರ್ ಕಾನ್ಫಿಗರೇಶನ್‌ನೊಳಗೆ ಎಲ್ಲಾ Z80s ಮೂಲಕ ಹಂಚಿಕೊಳ್ಳಲಾದ ಕೆಲವು ಸಾಮಾನ್ಯ ಮೆಮೊರಿ ತುಣುಕು; ಬ್ಯಾಕ್‌ಪ್ಲೇನ್ ಅನ್ನು ಸಹ ಹಂಚಿಕೊಳ್ಳಲಾಗಿದೆ, ಮತ್ತು ಅರ್ಧದಷ್ಟು RAM ಅನ್ನು ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಹಂಚಿಕೊಳ್ಳಲಾಗಿದೆ, ಮತ್ತು ಇನ್ನೊಂದು ಅರ್ಧ ಖಾಸಗಿಯಾಗಿದೆ ಅಥವಾ ಬೇರೆ ಯಾವುದಕ್ಕೆ ಹೋಯಿತು. ಹಂಚಿದ... ಅರೆ-ಹಂಚಿದ ಮೆಮೊರಿಯೊಂದಿಗೆ ಅರ್ಥಪೂರ್ಣವಾಗಿ ಸಂಕೀರ್ಣವಾದ ಸಮಾನಾಂತರ ವಿತರಣೆ ವ್ಯವಸ್ಥೆ. ಇದು ಯಾವಾಗ... 80 ರ ದಶಕದ ಮಧ್ಯಭಾಗದಲ್ಲಿ ಎಲ್ಲೋ ನನಗೆ ನೆನಪಿಲ್ಲ. ಬಹಳ ಹಿಂದೆಯೇ. 
ಹೌದು, 30 ವರ್ಷಗಳು ಬಹಳ ಹಿಂದೆಯೇ ಎಂದು ಭಾವಿಸೋಣ. ವಿತರಿಸಿದ ಕಂಪ್ಯೂಟಿಂಗ್‌ಗೆ ಸಂಬಂಧಿಸಿದ ಸಮಸ್ಯೆಗಳು ಬಹಳ ಹಿಂದಿನಿಂದಲೂ ಅಸ್ತಿತ್ವದಲ್ಲಿವೆ; ಜನರು ಬಹಳ ಹಿಂದಿನಿಂದಲೂ ಯುದ್ಧದಲ್ಲಿದ್ದಾರೆ ಬಿಯೋವುಲ್ಫ್-ಗುಂಪುಗಳು. ಅಂತಹ ಕ್ಲಸ್ಟರ್‌ಗಳು ಈ ರೀತಿ ಕಾಣುತ್ತವೆ... ಉದಾಹರಣೆಗೆ: ಈಥರ್ನೆಟ್ ಇದೆ ಮತ್ತು ನಿಮ್ಮ ವೇಗದ x86 ಈ ಎತರ್ನೆಟ್‌ಗೆ ಸಂಪರ್ಕಗೊಂಡಿದೆ ಮತ್ತು ಈಗ ನೀವು ನಕಲಿ ಹಂಚಿಕೆಯ ಮೆಮೊರಿಯನ್ನು ಪಡೆಯಲು ಬಯಸುತ್ತೀರಿ, ಏಕೆಂದರೆ ಯಾರೂ ವಿತರಿಸಿದ ಕಂಪ್ಯೂಟಿಂಗ್ ಕೋಡಿಂಗ್ ಮಾಡಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ, ಅದು ತುಂಬಾ ಕಷ್ಟಕರವಾಗಿತ್ತು ಮತ್ತು ಆದ್ದರಿಂದ ಅಲ್ಲಿ x86 ನಲ್ಲಿ ರಕ್ಷಣೆ ಮೆಮೊರಿ ಪುಟಗಳೊಂದಿಗೆ ನಕಲಿ ಹಂಚಿಕೆ ಮೆಮೊರಿ, ಮತ್ತು ನೀವು ಈ ಪುಟಕ್ಕೆ ಬರೆದರೆ, ನಾವು ಇತರ ಪ್ರೊಸೆಸರ್‌ಗಳಿಗೆ ಅವರು ಅದೇ ಹಂಚಿದ ಮೆಮೊರಿಯನ್ನು ಪ್ರವೇಶಿಸಿದರೆ, ಅದನ್ನು ನಿಮ್ಮಿಂದ ಲೋಡ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ ಮತ್ತು ಆದ್ದರಿಂದ ಬೆಂಬಲಿಸುವ ಪ್ರೋಟೋಕಾಲ್‌ನಂತೆ ಸಂಗ್ರಹ ಸುಸಂಬದ್ಧತೆ ಕಾಣಿಸಿಕೊಂಡಿತು ಮತ್ತು ಇದಕ್ಕಾಗಿ ಸಾಫ್ಟ್‌ವೇರ್. ಆಸಕ್ತಿದಾಯಕ ಪರಿಕಲ್ಪನೆ. ನಿಜವಾದ ಸಮಸ್ಯೆ, ಸಹಜವಾಗಿ, ಬೇರೆ ಯಾವುದೋ ಆಗಿತ್ತು. ಇದೆಲ್ಲವೂ ಕೆಲಸ ಮಾಡಿದೆ, ಆದರೆ ನೀವು ಕಾರ್ಯಕ್ಷಮತೆಯ ಸಮಸ್ಯೆಗಳನ್ನು ತ್ವರಿತವಾಗಿ ಪಡೆದುಕೊಂಡಿದ್ದೀರಿ, ಏಕೆಂದರೆ ಕಾರ್ಯಕ್ಷಮತೆಯ ಮಾದರಿಗಳನ್ನು ಸಾಕಷ್ಟು ಉತ್ತಮ ಮಟ್ಟದಲ್ಲಿ ಯಾರೂ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲಿಲ್ಲ - ಯಾವ ಮೆಮೊರಿ ಪ್ರವೇಶ ಮಾದರಿಗಳು ಇದ್ದವು, ನೋಡ್‌ಗಳು ಅಂತ್ಯವಿಲ್ಲದೆ ಪರಸ್ಪರ ಪಿಂಗ್ ಮಾಡುವುದಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವುದು ಹೇಗೆ, ಇತ್ಯಾದಿ.

ನಾನು H2O ನಲ್ಲಿ ಏನನ್ನು ಕಂಡುಕೊಂಡಿದ್ದೇನೆಂದರೆ, ಸಮಾನಾಂತರತೆಯನ್ನು ಎಲ್ಲಿ ಮರೆಮಾಡಲಾಗಿದೆ ಮತ್ತು ಅದು ಎಲ್ಲಿ ಇಲ್ಲ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಲು ಡೆವಲಪರ್‌ಗಳೇ ಜವಾಬ್ದಾರರು. ನಾನು ಹೆಚ್ಚಿನ ಕಾರ್ಯಕ್ಷಮತೆಯ ಕೋಡ್ ಅನ್ನು ಸುಲಭವಾಗಿ ಮತ್ತು ಸರಳವಾಗಿ ಬರೆಯುವ ಕೋಡಿಂಗ್ ಮಾದರಿಯೊಂದಿಗೆ ಬಂದಿದ್ದೇನೆ. ಆದರೆ ನಿಧಾನವಾಗಿ ಚಾಲನೆಯಲ್ಲಿರುವ ಕೋಡ್ ಬರೆಯುವುದು ಕಷ್ಟ, ಅದು ಕೆಟ್ಟದಾಗಿ ಕಾಣುತ್ತದೆ. ನಿಧಾನ ಕೋಡ್ ಬರೆಯಲು ನೀವು ಗಂಭೀರವಾಗಿ ಪ್ರಯತ್ನಿಸಬೇಕು, ನೀವು ಪ್ರಮಾಣಿತವಲ್ಲದ ವಿಧಾನಗಳನ್ನು ಬಳಸಬೇಕಾಗುತ್ತದೆ. ಬ್ರೇಕಿಂಗ್ ಕೋಡ್ ಮೊದಲ ನೋಟದಲ್ಲಿ ಗೋಚರಿಸುತ್ತದೆ. ಪರಿಣಾಮವಾಗಿ, ನೀವು ಸಾಮಾನ್ಯವಾಗಿ ವೇಗವಾಗಿ ಚಲಿಸುವ ಕೋಡ್ ಅನ್ನು ಬರೆಯುತ್ತೀರಿ, ಆದರೆ ಹಂಚಿಕೆಯ ಮೆಮೊರಿಯ ಸಂದರ್ಭದಲ್ಲಿ ಏನು ಮಾಡಬೇಕೆಂದು ನೀವು ಲೆಕ್ಕಾಚಾರ ಮಾಡಬೇಕು. ಇದೆಲ್ಲವನ್ನೂ ದೊಡ್ಡ ಅರೇಗಳಿಗೆ ಜೋಡಿಸಲಾಗಿದೆ ಮತ್ತು ಅಲ್ಲಿನ ನಡವಳಿಕೆಯು ಸಮಾನಾಂತರ ಜಾವಾದಲ್ಲಿ ಬಾಷ್ಪಶೀಲವಲ್ಲದ ದೊಡ್ಡ ಸರಣಿಗಳನ್ನು ಹೋಲುತ್ತದೆ. ಅಂದರೆ, ಎರಡು ಎಳೆಗಳು ಸಮಾನಾಂತರ ರಚನೆಗೆ ಬರೆಯುತ್ತವೆ ಎಂದು ಊಹಿಸಿ, ಅವುಗಳಲ್ಲಿ ಒಂದು ಗೆಲ್ಲುತ್ತದೆ, ಮತ್ತು ಇನ್ನೊಂದು, ಅದರ ಪ್ರಕಾರ, ಕಳೆದುಕೊಳ್ಳುತ್ತದೆ, ಮತ್ತು ಯಾವುದು ಎಂದು ನಿಮಗೆ ತಿಳಿದಿಲ್ಲ. ಅವು ಬಾಷ್ಪಶೀಲವಾಗಿಲ್ಲದಿದ್ದರೆ, ಆದೇಶವು ನಿಮಗೆ ಬೇಕಾದುದನ್ನು ಮಾಡಬಹುದು - ಮತ್ತು ಇದು ನಿಜವಾಗಿಯೂ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಜನರು ಕಾರ್ಯಾಚರಣೆಯ ಕ್ರಮದ ಬಗ್ಗೆ ನಿಜವಾಗಿಯೂ ಕಾಳಜಿ ವಹಿಸುತ್ತಾರೆ, ಅವರು ಸರಿಯಾದ ಸ್ಥಳಗಳಲ್ಲಿ ಬಾಷ್ಪಶೀಲತೆಯನ್ನು ಇರಿಸುತ್ತಾರೆ ಮತ್ತು ಸರಿಯಾದ ಸ್ಥಳಗಳಲ್ಲಿ ಮೆಮೊರಿ-ಸಂಬಂಧಿತ ಕಾರ್ಯಕ್ಷಮತೆಯ ಸಮಸ್ಯೆಗಳನ್ನು ಅವರು ನಿರೀಕ್ಷಿಸುತ್ತಾರೆ. ಇಲ್ಲದಿದ್ದರೆ, ಅವರು 1 ರಿಂದ N ಗೆ ಲೂಪ್‌ಗಳ ರೂಪದಲ್ಲಿ ಕೋಡ್ ಅನ್ನು ಬರೆಯುತ್ತಾರೆ, ಅಲ್ಲಿ N ಕೆಲವು ಟ್ರಿಲಿಯನ್‌ಗಳು, ಎಲ್ಲಾ ಸಂಕೀರ್ಣ ಪ್ರಕರಣಗಳು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಸಮಾನಾಂತರವಾಗುತ್ತವೆ - ಮತ್ತು ಅದು ಅಲ್ಲಿ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ. ಆದರೆ H2O ನಲ್ಲಿ ಇದು ಜಾವಾ ಅಥವಾ ಸ್ಕಾಲಾ ಅಲ್ಲ; ನೀವು ಬಯಸಿದರೆ ಅದನ್ನು "ಜಾವಾ ಮೈನಸ್ ಮೈನಸ್" ಎಂದು ಪರಿಗಣಿಸಬಹುದು. ಇದು ಅತ್ಯಂತ ಸ್ಪಷ್ಟವಾದ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಶೈಲಿಯಾಗಿದೆ ಮತ್ತು ಲೂಪ್‌ಗಳು ಮತ್ತು ಅರೇಗಳೊಂದಿಗೆ ಸರಳವಾದ ಸಿ ಅಥವಾ ಜಾವಾ ಕೋಡ್ ಅನ್ನು ಬರೆಯುವಂತೆಯೇ ಇರುತ್ತದೆ. ಆದರೆ ಅದೇ ಸಮಯದಲ್ಲಿ, ಮೆಮೊರಿಯನ್ನು ಟೆರಾಬೈಟ್‌ಗಳಲ್ಲಿ ಸಂಸ್ಕರಿಸಬಹುದು. ನಾನು ಈಗಲೂ H2O ಬಳಸುತ್ತಿದ್ದೇನೆ. ನಾನು ಅದನ್ನು ಕಾಲಕಾಲಕ್ಕೆ ವಿವಿಧ ಯೋಜನೆಗಳಲ್ಲಿ ಬಳಸುತ್ತೇನೆ - ಮತ್ತು ಇದು ಇನ್ನೂ ವೇಗವಾದ ವಿಷಯವಾಗಿದೆ, ಅದರ ಪ್ರತಿಸ್ಪರ್ಧಿಗಳಿಗಿಂತ ಡಜನ್ ಪಟ್ಟು ವೇಗವಾಗಿರುತ್ತದೆ. ನೀವು ಸ್ತಂಭಾಕಾರದ ಡೇಟಾದೊಂದಿಗೆ ಬಿಗ್ ಡೇಟಾ ಮಾಡುತ್ತಿದ್ದರೆ, H2O ಅನ್ನು ಸೋಲಿಸುವುದು ತುಂಬಾ ಕಷ್ಟ.

ತಾಂತ್ರಿಕ ಸವಾಲುಗಳು

ಆಂಡ್ರಾಯ್ಡ್: ನಿಮ್ಮ ಇಡೀ ವೃತ್ತಿಜೀವನದಲ್ಲಿ ನಿಮ್ಮ ದೊಡ್ಡ ಸವಾಲು ಯಾವುದು?

ಕ್ಲಿಫ್: ನಾವು ಸಮಸ್ಯೆಯ ತಾಂತ್ರಿಕ ಅಥವಾ ತಾಂತ್ರಿಕೇತರ ಭಾಗವನ್ನು ಚರ್ಚಿಸುತ್ತಿದ್ದೇವೆಯೇ? ದೊಡ್ಡ ಸವಾಲುಗಳು ತಾಂತ್ರಿಕವಲ್ಲ ಎಂದು ನಾನು ಹೇಳುತ್ತೇನೆ. 
ತಾಂತ್ರಿಕ ಸವಾಲುಗಳಿಗೆ ಸಂಬಂಧಿಸಿದಂತೆ. ನಾನು ಅವರನ್ನು ಸುಮ್ಮನೆ ಸೋಲಿಸಿದೆ. ದೊಡ್ಡದು ಯಾವುದು ಎಂದು ನನಗೆ ತಿಳಿದಿಲ್ಲ, ಆದರೆ ಕೆಲವು ಆಸಕ್ತಿದಾಯಕವಾದವುಗಳು ಸ್ವಲ್ಪ ಸಮಯ ತೆಗೆದುಕೊಂಡವು, ಮಾನಸಿಕ ಹೋರಾಟ. ನಾನು ಸನ್‌ಗೆ ಹೋದಾಗ, ನಾನು ವೇಗವಾಗಿ ಕಂಪೈಲರ್ ಮಾಡುತ್ತೇನೆ ಎಂದು ನನಗೆ ಖಚಿತವಾಗಿತ್ತು ಮತ್ತು ನಾನು ಎಂದಿಗೂ ಯಶಸ್ವಿಯಾಗುವುದಿಲ್ಲ ಎಂದು ಹಿರಿಯರ ಗುಂಪೇ ಪ್ರತಿಕ್ರಿಯಿಸಿದರು. ಆದರೆ ನಾನು ಈ ಮಾರ್ಗವನ್ನು ಅನುಸರಿಸಿದೆ, ರಿಜಿಸ್ಟರ್ ಅಲೋಕೇಟರ್‌ಗೆ ಕಂಪೈಲರ್ ಅನ್ನು ಬರೆದಿದ್ದೇನೆ ಮತ್ತು ಅದು ತುಂಬಾ ವೇಗವಾಗಿತ್ತು. ಇದು ಆಧುನಿಕ C1 ನಂತೆ ವೇಗವಾಗಿತ್ತು, ಆದರೆ ಹಂಚಿಕೆದಾರರು ಆಗ ನಿಧಾನವಾಗಿತ್ತು, ಮತ್ತು ನಂತರದಲ್ಲಿ ಇದು ದೊಡ್ಡ ಡೇಟಾ ರಚನೆಯ ಸಮಸ್ಯೆಯಾಗಿದೆ. ಗ್ರಾಫಿಕಲ್ ರಿಜಿಸ್ಟರ್ ಅಲೋಕೇಟರ್ ಅನ್ನು ಬರೆಯಲು ನನಗೆ ಇದು ಅಗತ್ಯವಾಗಿತ್ತು ಮತ್ತು ಕೋಡ್ ಅಭಿವ್ಯಕ್ತಿಶೀಲತೆ ಮತ್ತು ವೇಗದ ನಡುವಿನ ಸಂದಿಗ್ಧತೆ ನನಗೆ ಅರ್ಥವಾಗಲಿಲ್ಲ, ಅದು ಆ ಯುಗದಲ್ಲಿ ಅಸ್ತಿತ್ವದಲ್ಲಿತ್ತು ಮತ್ತು ಬಹಳ ಮುಖ್ಯವಾಗಿತ್ತು. ಡೇಟಾ ರಚನೆಯು ಸಾಮಾನ್ಯವಾಗಿ ಆ ಸಮಯದ x86 ಗಳಲ್ಲಿ ಸಂಗ್ರಹ ಗಾತ್ರವನ್ನು ಮೀರುತ್ತದೆ ಮತ್ತು ಆದ್ದರಿಂದ, ರಿಜಿಸ್ಟರ್ ಅಲೋಕೇಟರ್ ಒಟ್ಟು ನಡುಗುವ ಸಮಯದ 5-10 ಪ್ರತಿಶತದಷ್ಟು ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂದು ನಾನು ಆರಂಭದಲ್ಲಿ ಭಾವಿಸಿದರೆ, ವಾಸ್ತವದಲ್ಲಿ ಅದು ಹೊರಹೊಮ್ಮಿತು 50 ರಷ್ಟು.

ಸಮಯ ಕಳೆದಂತೆ, ಕಂಪೈಲರ್ ಕ್ಲೀನ್ ಮತ್ತು ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾಯಿತು, ಹೆಚ್ಚಿನ ಸಂದರ್ಭಗಳಲ್ಲಿ ಭಯಾನಕ ಕೋಡ್ ಉತ್ಪಾದಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿತು, ಮತ್ತು ಕಾರ್ಯಕ್ಷಮತೆಯು ಹೆಚ್ಚೆಚ್ಚು ಸಿ ಕಂಪೈಲರ್ ಉತ್ಪಾದಿಸುವುದನ್ನು ಹೋಲುವಂತೆ ಪ್ರಾರಂಭಿಸಿತು. . ನೀವು C ನಂತಹ ಕೋಡ್ ಅನ್ನು ಬರೆದರೆ, ನೀವು ಹೆಚ್ಚಿನ ಸಂದರ್ಭಗಳಲ್ಲಿ C ನಂತಹ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಪಡೆಯುತ್ತೀರಿ. ಮತ್ತು ನೀವು ಮುಂದೆ ಹೋದಂತೆ, ನೀವು ಹೆಚ್ಚಾಗಿ ಸಿ ಲೆವೆಲ್ ಸಿಗೆ ಹೊಂದಿಕೆಯಾಗುವ ಕೋಡ್ ಅನ್ನು ಪಡೆದುಕೊಂಡಿದ್ದೀರಿ, ರಿಜಿಸ್ಟರ್ ಅಲೋಕೇಟರ್ ಏನೋ ಪೂರ್ಣಗೊಂಡಂತೆ ಕಾಣಲಾರಂಭಿಸಿತು... ನಿಮ್ಮ ಕೋಡ್ ವೇಗವಾಗಿ ಅಥವಾ ನಿಧಾನವಾಗಿ ಚಲಿಸುತ್ತದೆಯೇ ಎಂಬುದನ್ನು ಲೆಕ್ಕಿಸದೆ. ನಾನು ಉತ್ತಮ ಆಯ್ಕೆಗಳನ್ನು ಮಾಡಲು ಹಂಚಿಕೆದಾರರ ಮೇಲೆ ಕೆಲಸ ಮಾಡುವುದನ್ನು ಮುಂದುವರೆಸಿದೆ. ಅವರು ನಿಧಾನವಾಗಿ ಮತ್ತು ನಿಧಾನವಾಗಿ ಆಯಿತು, ಆದರೆ ಬೇರೆ ಯಾರೂ ನಿಭಾಯಿಸಲು ಸಾಧ್ಯವಾಗದ ಸಂದರ್ಭಗಳಲ್ಲಿ ಅವರು ಉತ್ತಮ ಮತ್ತು ಉತ್ತಮ ಪ್ರದರ್ಶನ ನೀಡಿದರು. ನಾನು ರಿಜಿಸ್ಟರ್ ಅಲೋಕೇಟರ್‌ಗೆ ಧುಮುಕಬಹುದು, ಅಲ್ಲಿ ಒಂದು ತಿಂಗಳ ಕೆಲಸವನ್ನು ಹೂತುಹಾಕಬಹುದು ಮತ್ತು ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಇಡೀ ಕೋಡ್ 5% ವೇಗವಾಗಿ ಕಾರ್ಯಗತಗೊಳ್ಳಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ. ಇದು ಕಾಲಾನಂತರದಲ್ಲಿ ಸಂಭವಿಸಿತು ಮತ್ತು ರಿಜಿಸ್ಟರ್ ಅಲೋಕೇಟರ್ ಕಲೆಯ ಕೆಲಸವಾಯಿತು - ಪ್ರತಿಯೊಬ್ಬರೂ ಅದನ್ನು ಇಷ್ಟಪಟ್ಟಿದ್ದಾರೆ ಅಥವಾ ದ್ವೇಷಿಸುತ್ತಿದ್ದರು, ಮತ್ತು ಅಕಾಡೆಮಿಯ ಜನರು "ಎಲ್ಲವನ್ನೂ ಏಕೆ ಹೀಗೆ ಮಾಡಲಾಗಿದೆ" ಎಂಬ ವಿಷಯದ ಕುರಿತು ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳಿದರು, ಏಕೆ ಅಲ್ಲ ಲೈನ್ ಸ್ಕ್ಯಾನ್, ಮತ್ತು ವ್ಯತ್ಯಾಸವೇನು. ಉತ್ತರವು ಇನ್ನೂ ಒಂದೇ ಆಗಿರುತ್ತದೆ: ಗ್ರಾಫ್ ಬಣ್ಣ ಮತ್ತು ಬಫರ್ ಕೋಡ್‌ನೊಂದಿಗೆ ಬಹಳ ಎಚ್ಚರಿಕೆಯಿಂದ ಕೆಲಸ ಮಾಡುವ ಆಧಾರದ ಮೇಲೆ ಅಲೋಕೇಟರ್ ವಿಜಯದ ಆಯುಧಕ್ಕೆ ಸಮಾನವಾಗಿರುತ್ತದೆ, ಯಾರೂ ಸೋಲಿಸಲು ಸಾಧ್ಯವಾಗದ ಅತ್ಯುತ್ತಮ ಸಂಯೋಜನೆಯಾಗಿದೆ. ಮತ್ತು ಇದು ಹೆಚ್ಚು ಸ್ಪಷ್ಟವಲ್ಲದ ವಿಷಯವಾಗಿದೆ. ಕಂಪೈಲರ್ ಮಾಡುವ ಉಳಿದೆಲ್ಲವೂ ಸಾಕಷ್ಟು ಚೆನ್ನಾಗಿ ಅಧ್ಯಯನ ಮಾಡಿದ ವಿಷಯಗಳು, ಆದರೂ ಅವುಗಳನ್ನು ಕಲೆಯ ಮಟ್ಟಕ್ಕೆ ತರಲಾಗಿದೆ. ನಾನು ಯಾವಾಗಲೂ ಕಂಪೈಲರ್ ಅನ್ನು ಕಲಾಕೃತಿಯನ್ನಾಗಿ ಮಾಡಬೇಕಾದ ಕೆಲಸಗಳನ್ನು ಮಾಡಿದ್ದೇನೆ. ಆದರೆ ಇದ್ಯಾವುದೂ ಅಸಾಮಾನ್ಯವಾದುದೇನೂ ಆಗಿರಲಿಲ್ಲ - ರಿಜಿಸ್ಟರ್ ಅಲೋಕೇಟರ್ ಹೊರತುಪಡಿಸಿ. ಹುಷಾರಾಗಿರುವುದೇ ಉಪಾಯ ಕತ್ತರಿಸು ಲೋಡ್ ಅಡಿಯಲ್ಲಿ ಮತ್ತು, ಇದು ಸಂಭವಿಸಿದಲ್ಲಿ (ಆಸಕ್ತಿ ಇದ್ದರೆ ನಾನು ಹೆಚ್ಚು ವಿವರವಾಗಿ ವಿವರಿಸಬಹುದು), ಇದರರ್ಥ ನೀವು ಕಾರ್ಯಕ್ಷಮತೆಯ ವೇಳಾಪಟ್ಟಿಯಲ್ಲಿ ಕಿಂಕ್ ಮೇಲೆ ಬೀಳುವ ಅಪಾಯವಿಲ್ಲದೆ ಹೆಚ್ಚು ಆಕ್ರಮಣಕಾರಿಯಾಗಿ ಇನ್ಲೈನ್ ​​ಮಾಡಬಹುದು. ಆ ದಿನಗಳಲ್ಲಿ, ರಿಜಿಸ್ಟರ್ ಅಲೋಕೇಟರ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದ ಪೂರ್ಣ ಪ್ರಮಾಣದ ಕಂಪೈಲರ್‌ಗಳ ಗುಂಪನ್ನು ಬಾಬಲ್‌ಗಳು ಮತ್ತು ಸೀಟಿಗಳಿಂದ ನೇತುಹಾಕಲಾಗಿತ್ತು, ಆದರೆ ಬೇರೆ ಯಾರೂ ಅದನ್ನು ಮಾಡಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ.

ಸಮಸ್ಯೆಯೆಂದರೆ, ನೀವು ಇನ್ಲೈನಿಂಗ್ ಪ್ರದೇಶವನ್ನು ಹೆಚ್ಚಿಸುವ ಮತ್ತು ಹೆಚ್ಚಿಸುವ ವಿಧಾನಗಳನ್ನು ಸೇರಿಸಿದರೆ, ಬಳಸಿದ ಮೌಲ್ಯಗಳ ಸೆಟ್ ತಕ್ಷಣವೇ ರೆಜಿಸ್ಟರ್‌ಗಳ ಸಂಖ್ಯೆಯನ್ನು ಮೀರಿಸುತ್ತದೆ ಮತ್ತು ನೀವು ಅವುಗಳನ್ನು ಕತ್ತರಿಸಬೇಕಾಗುತ್ತದೆ. ಹಂಚಿಕೆದಾರರು ಬಿಟ್ಟುಕೊಟ್ಟಾಗ ನಿರ್ಣಾಯಕ ಮಟ್ಟವು ಸಾಮಾನ್ಯವಾಗಿ ಬರುತ್ತದೆ, ಮತ್ತು ಸೋರಿಕೆಗಾಗಿ ಒಬ್ಬ ಉತ್ತಮ ಅಭ್ಯರ್ಥಿಯು ಇನ್ನೊಬ್ಬರಿಗೆ ಯೋಗ್ಯವಾಗಿರುತ್ತದೆ, ನೀವು ಸಾಮಾನ್ಯವಾಗಿ ಕೆಲವು ಕಾಡು ವಸ್ತುಗಳನ್ನು ಮಾರಾಟ ಮಾಡುತ್ತೀರಿ. ಇಲ್ಲಿ ಇನ್‌ಲೈನಿಂಗ್‌ನ ಮೌಲ್ಯವೆಂದರೆ ನೀವು ಓವರ್‌ಹೆಡ್‌ನ ಭಾಗವನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತೀರಿ, ಕರೆ ಮಾಡಲು ಮತ್ತು ಉಳಿಸಲು ಓವರ್‌ಹೆಡ್, ನೀವು ಒಳಗೆ ಮೌಲ್ಯಗಳನ್ನು ನೋಡಬಹುದು ಮತ್ತು ಅವುಗಳನ್ನು ಮತ್ತಷ್ಟು ಆಪ್ಟಿಮೈಜ್ ಮಾಡಬಹುದು. ಇನ್‌ಲೈನಿಂಗ್‌ನ ವೆಚ್ಚವೆಂದರೆ ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಲೈವ್ ಮೌಲ್ಯಗಳು ರೂಪುಗೊಳ್ಳುತ್ತವೆ ಮತ್ತು ನಿಮ್ಮ ರಿಜಿಸ್ಟರ್ ಅಲೋಕೇಟರ್ ಅಗತ್ಯಕ್ಕಿಂತ ಹೆಚ್ಚು ಸುಟ್ಟುಹೋದರೆ, ನೀವು ತಕ್ಷಣ ಕಳೆದುಕೊಳ್ಳುತ್ತೀರಿ. ಆದ್ದರಿಂದ, ಹೆಚ್ಚಿನ ಹಂಚಿಕೆದಾರರು ಸಮಸ್ಯೆಯನ್ನು ಹೊಂದಿದ್ದಾರೆ: ಇನ್ಲೈನಿಂಗ್ ಒಂದು ನಿರ್ದಿಷ್ಟ ರೇಖೆಯನ್ನು ದಾಟಿದಾಗ, ಪ್ರಪಂಚದ ಎಲ್ಲವನ್ನೂ ಕಡಿತಗೊಳಿಸಲು ಪ್ರಾರಂಭವಾಗುತ್ತದೆ ಮತ್ತು ಉತ್ಪಾದಕತೆಯನ್ನು ಟಾಯ್ಲೆಟ್ನಿಂದ ತೊಳೆಯಬಹುದು. ಕಂಪೈಲರ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವವರು ಕೆಲವು ಹ್ಯೂರಿಸ್ಟಿಕ್ಸ್ ಅನ್ನು ಸೇರಿಸುತ್ತಾರೆ: ಉದಾಹರಣೆಗೆ, ಇನ್ಲೈನಿಂಗ್ ಅನ್ನು ನಿಲ್ಲಿಸಲು, ಸಾಕಷ್ಟು ದೊಡ್ಡ ಗಾತ್ರದಿಂದ ಪ್ರಾರಂಭಿಸಿ, ಹಂಚಿಕೆಗಳು ಎಲ್ಲವನ್ನೂ ಹಾಳುಮಾಡುತ್ತವೆ. ಕಾರ್ಯಕ್ಷಮತೆಯ ಗ್ರಾಫ್‌ನಲ್ಲಿ ಕಿಂಕ್ ಹೇಗೆ ರೂಪುಗೊಳ್ಳುತ್ತದೆ - ನೀವು ಇನ್‌ಲೈನ್, ಇನ್‌ಲೈನ್, ಕಾರ್ಯಕ್ಷಮತೆ ನಿಧಾನವಾಗಿ ಬೆಳೆಯುತ್ತದೆ - ತದನಂತರ ಬೂಮ್! - ನೀವು ತುಂಬಾ ಸಾಲುಗಟ್ಟಿದ ಕಾರಣ ಅದು ಸ್ವಿಫ್ಟ್ ಜ್ಯಾಕ್‌ನಂತೆ ಕೆಳಗೆ ಬೀಳುತ್ತದೆ. ಜಾವಾ ಬರುವ ಮೊದಲು ಎಲ್ಲವೂ ಹೀಗೆಯೇ ಕೆಲಸ ಮಾಡುತ್ತಿತ್ತು. ಜಾವಾಕ್ಕೆ ಹೆಚ್ಚಿನ ಇನ್‌ಲೈನಿಂಗ್ ಅಗತ್ಯವಿರುತ್ತದೆ, ಆದ್ದರಿಂದ ನಾನು ನನ್ನ ಅಲೋಕೇಟರ್ ಅನ್ನು ಹೆಚ್ಚು ಆಕ್ರಮಣಕಾರಿಯಾಗಿ ಮಾಡಬೇಕಾಗಿತ್ತು, ಇದರಿಂದಾಗಿ ಅದು ಕ್ರ್ಯಾಶ್ ಆಗುವ ಬದಲು ಮಟ್ಟಕ್ಕೆ ಹೋಗುತ್ತದೆ, ಮತ್ತು ನೀವು ಹೆಚ್ಚು ಇನ್ಲೈನ್ ​​ಮಾಡಿದರೆ, ಅದು ಚೆಲ್ಲಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ, ಆದರೆ "ಇನ್ನಷ್ಟು ಚೆಲ್ಲುವುದಿಲ್ಲ" ಕ್ಷಣವು ಇನ್ನೂ ಬರುತ್ತದೆ. ಇದು ಆಸಕ್ತಿದಾಯಕ ಅವಲೋಕನವಾಗಿದೆ ಮತ್ತು ಇದು ನನಗೆ ಎಲ್ಲಿಂದಲೋ ಬಂದಿತು, ಸ್ಪಷ್ಟವಾಗಿಲ್ಲ, ಆದರೆ ಅದು ಚೆನ್ನಾಗಿ ಪಾವತಿಸಿದೆ. ನಾನು ಆಕ್ರಮಣಕಾರಿ ಇನ್ಲೈನಿಂಗ್ ಅನ್ನು ತೆಗೆದುಕೊಂಡೆ ಮತ್ತು ಅದು ನನ್ನನ್ನು ಜಾವಾ ಮತ್ತು ಸಿ ಕಾರ್ಯಕ್ಷಮತೆ ಅಕ್ಕಪಕ್ಕದಲ್ಲಿ ಕೆಲಸ ಮಾಡುವ ಸ್ಥಳಗಳಿಗೆ ಕರೆದೊಯ್ಯಿತು. ಅವರು ನಿಜವಾಗಿಯೂ ಹತ್ತಿರವಾಗಿದ್ದಾರೆ - ನಾನು C ಕೋಡ್ ಮತ್ತು ಅದರಂತಹ ವಿಷಯಗಳಿಗಿಂತ ಗಮನಾರ್ಹವಾಗಿ ವೇಗವಾದ ಜಾವಾ ಕೋಡ್ ಅನ್ನು ಬರೆಯಬಲ್ಲೆ, ಆದರೆ ಸರಾಸರಿ, ವಸ್ತುಗಳ ದೊಡ್ಡ ಚಿತ್ರದಲ್ಲಿ, ಅವುಗಳನ್ನು ಸರಿಸುಮಾರು ಹೋಲಿಸಬಹುದಾಗಿದೆ. ಈ ಅರ್ಹತೆಯ ಭಾಗವು ರಿಜಿಸ್ಟರ್ ಅಲೋಕೇಟರ್ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ, ಇದು ನನಗೆ ಸಾಧ್ಯವಾದಷ್ಟು ಮೂರ್ಖತನದಿಂದ ಇನ್‌ಲೈನ್ ಮಾಡಲು ಅನುಮತಿಸುತ್ತದೆ. ನಾನು ನೋಡುವ ಎಲ್ಲವನ್ನೂ ನಾನು ಇನ್‌ಲೈನ್ ಮಾಡುತ್ತೇನೆ. ಇಲ್ಲಿ ಪ್ರಶ್ನೆಯೆಂದರೆ ಅಲೋಕೇಟರ್ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆಯೇ, ಫಲಿತಾಂಶವು ಬುದ್ಧಿವಂತಿಕೆಯಿಂದ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಕೋಡ್ ಆಗಿದೆಯೇ. ಇದು ಒಂದು ದೊಡ್ಡ ಸವಾಲಾಗಿತ್ತು: ಇದೆಲ್ಲವನ್ನೂ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಮತ್ತು ಅದನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವುದು.

ರಿಜಿಸ್ಟರ್ ಹಂಚಿಕೆ ಮತ್ತು ಬಹು-ಕೋರ್ಗಳ ಬಗ್ಗೆ ಸ್ವಲ್ಪ

Владимир: ರಿಜಿಸ್ಟರ್ ಹಂಚಿಕೆಯಂತಹ ಸಮಸ್ಯೆಗಳು ಕೆಲವು ರೀತಿಯ ಶಾಶ್ವತ, ಅಂತ್ಯವಿಲ್ಲದ ವಿಷಯದಂತೆ ತೋರುತ್ತದೆ. ಭರವಸೆಯ ಮತ್ತು ನಂತರ ಆಚರಣೆಯಲ್ಲಿ ವಿಫಲವಾದ ಕಲ್ಪನೆಯು ಎಂದಾದರೂ ಇದೆಯೇ ಎಂದು ನಾನು ಆಶ್ಚರ್ಯ ಪಡುತ್ತೇನೆ?

ಕ್ಲಿಫ್: ಖಂಡಿತ! ನೋಂದಾವಣೆ ಹಂಚಿಕೆಯು ನೀವು NP-ಸಂಪೂರ್ಣ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು ಕೆಲವು ಹ್ಯೂರಿಸ್ಟಿಕ್‌ಗಳನ್ನು ಹುಡುಕಲು ಪ್ರಯತ್ನಿಸುವ ಪ್ರದೇಶವಾಗಿದೆ. ಮತ್ತು ನೀವು ಎಂದಿಗೂ ಪರಿಪೂರ್ಣ ಪರಿಹಾರವನ್ನು ಸಾಧಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ, ಸರಿ? ಇದು ಸರಳವಾಗಿ ಅಸಾಧ್ಯ. ನೋಡಿ, ಸಮಯದ ಸಂಕಲನದ ಮುಂದೆ - ಇದು ಕಳಪೆಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಇಲ್ಲಿ ಸಂಭಾಷಣೆಯು ಕೆಲವು ಸರಾಸರಿ ಪ್ರಕರಣಗಳ ಬಗ್ಗೆ. ವಿಶಿಷ್ಟವಾದ ಕಾರ್ಯಕ್ಷಮತೆಯ ಬಗ್ಗೆ, ಆದ್ದರಿಂದ ನೀವು ಉತ್ತಮ ವಿಶಿಷ್ಟ ಕಾರ್ಯಕ್ಷಮತೆ ಎಂದು ಭಾವಿಸುವ ಯಾವುದನ್ನಾದರೂ ಅಳೆಯಬಹುದು - ಎಲ್ಲಾ ನಂತರ, ನೀವು ಅದನ್ನು ಸುಧಾರಿಸಲು ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದೀರಿ! ನೋಂದಣಿ ಹಂಚಿಕೆಯು ಕಾರ್ಯಕ್ಷಮತೆಯ ಬಗ್ಗೆ ಒಂದು ವಿಷಯವಾಗಿದೆ. ಒಮ್ಮೆ ನೀವು ಮೊದಲ ಮೂಲಮಾದರಿಯನ್ನು ಹೊಂದಿದ್ದರೆ, ಅದು ಕೆಲಸ ಮಾಡುತ್ತದೆ ಮತ್ತು ಅಗತ್ಯವಿರುವದನ್ನು ಬಣ್ಣಿಸುತ್ತದೆ, ಕಾರ್ಯಕ್ಷಮತೆಯ ಕೆಲಸ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ. ನೀವು ಚೆನ್ನಾಗಿ ಅಳೆಯಲು ಕಲಿಯಬೇಕು. ಇದು ಏಕೆ ಮುಖ್ಯ? ನೀವು ಸ್ಪಷ್ಟವಾದ ಡೇಟಾವನ್ನು ಹೊಂದಿದ್ದರೆ, ನೀವು ವಿವಿಧ ಪ್ರದೇಶಗಳನ್ನು ನೋಡಬಹುದು ಮತ್ತು ನೋಡಬಹುದು: ಹೌದು, ಇದು ಇಲ್ಲಿ ಸಹಾಯ ಮಾಡಿದೆ, ಆದರೆ ಅಲ್ಲಿ ಎಲ್ಲವೂ ಮುರಿದುಹೋಗಿದೆ! ಕೆಲವು ಉತ್ತಮ ವಿಚಾರಗಳು ಬರುತ್ತವೆ, ನೀವು ಹೊಸ ಹ್ಯೂರಿಸ್ಟಿಕ್ಸ್ ಅನ್ನು ಸೇರಿಸುತ್ತೀರಿ ಮತ್ತು ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಎಲ್ಲವೂ ಸರಾಸರಿಯಾಗಿ ಸ್ವಲ್ಪ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ. ಅಥವಾ ಅದು ಪ್ರಾರಂಭವಾಗುವುದಿಲ್ಲ. ನಮ್ಮ ಅಭಿವೃದ್ಧಿಯನ್ನು ಹಿಂದಿನ ಹಂಚಿಕೆಯಿಂದ ಪ್ರತ್ಯೇಕಿಸುವ ಐದು ಶೇಕಡಾ ಕಾರ್ಯಕ್ಷಮತೆಗಾಗಿ ನಾವು ಹೋರಾಡುತ್ತಿರುವ ಪ್ರಕರಣಗಳ ಗುಂಪನ್ನು ನಾನು ಹೊಂದಿದ್ದೇನೆ. ಮತ್ತು ಪ್ರತಿ ಬಾರಿ ಅದು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ: ಎಲ್ಲೋ ನೀವು ಗೆಲ್ಲುತ್ತೀರಿ, ಎಲ್ಲೋ ನೀವು ಕಳೆದುಕೊಳ್ಳುತ್ತೀರಿ. ನೀವು ಉತ್ತಮ ಕಾರ್ಯಕ್ಷಮತೆಯ ವಿಶ್ಲೇಷಣಾ ಸಾಧನಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ನೀವು ಕಳೆದುಕೊಳ್ಳುವ ಆಲೋಚನೆಗಳನ್ನು ಕಂಡುಹಿಡಿಯಬಹುದು ಮತ್ತು ಅವು ಏಕೆ ವಿಫಲವಾಗಿವೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬಹುದು. ಬಹುಶಃ ಎಲ್ಲವನ್ನೂ ಹಾಗೆಯೇ ಬಿಡುವುದು ಯೋಗ್ಯವಾಗಿದೆ, ಅಥವಾ ಉತ್ತಮ-ಶ್ರುತಿಗೆ ಹೆಚ್ಚು ಗಂಭೀರವಾದ ವಿಧಾನವನ್ನು ತೆಗೆದುಕೊಳ್ಳುವುದು, ಅಥವಾ ಹೊರಗೆ ಹೋಗಿ ಬೇರೆ ಯಾವುದನ್ನಾದರೂ ಸರಿಪಡಿಸುವುದು. ಇದು ವಸ್ತುಗಳ ಸಂಪೂರ್ಣ ಗುಂಪೇ! ನಾನು ಈ ತಂಪಾದ ಹ್ಯಾಕ್ ಮಾಡಿದ್ದೇನೆ, ಆದರೆ ನನಗೆ ಇದು ಬೇಕು, ಮತ್ತು ಇದು, ಮತ್ತು ಇದು - ಮತ್ತು ಅವರ ಒಟ್ಟು ಸಂಯೋಜನೆಯು ಕೆಲವು ಸುಧಾರಣೆಗಳನ್ನು ನೀಡುತ್ತದೆ. ಮತ್ತು ಒಂಟಿಯಾಗಿರುವವರು ವಿಫಲರಾಗಬಹುದು. ಇದು NP-ಸಂಪೂರ್ಣ ಸಮಸ್ಯೆಗಳ ಕಾರ್ಯಕ್ಷಮತೆಯ ಕೆಲಸದ ಸ್ವರೂಪವಾಗಿದೆ.

Владимир: ಅಲೋಕೇಟರ್‌ಗಳಲ್ಲಿ ಪೇಂಟಿಂಗ್‌ನಂತಹ ವಿಷಯಗಳು ಈಗಾಗಲೇ ಪರಿಹರಿಸಲ್ಪಟ್ಟ ಸಮಸ್ಯೆ ಎಂಬ ಭಾವನೆ ಬರುತ್ತದೆ. ಸರಿ, ಇದು ನಿಮಗಾಗಿ ನಿರ್ಧರಿಸಲಾಗಿದೆ, ನೀವು ಏನು ಹೇಳುತ್ತಿದ್ದೀರಿ ಎಂಬುದರ ಮೂಲಕ ನಿರ್ಣಯಿಸುವುದು, ಆದ್ದರಿಂದ ಅದು ಯೋಗ್ಯವಾಗಿದೆಯೇ ...

ಕ್ಲಿಫ್: ಇದು ಹಾಗೆ ಬಗೆಹರಿದಿಲ್ಲ. ನೀವು ಅದನ್ನು "ಪರಿಹರಿಸಿದ" ಆಗಿ ಪರಿವರ್ತಿಸಬೇಕು. ಕಷ್ಟಕರ ಸಮಸ್ಯೆಗಳಿವೆ ಮತ್ತು ಅವುಗಳನ್ನು ಪರಿಹರಿಸಬೇಕಾಗಿದೆ. ಇದನ್ನು ಮಾಡಿದ ನಂತರ, ಉತ್ಪಾದಕತೆಯ ಮೇಲೆ ಕೆಲಸ ಮಾಡುವ ಸಮಯ. ನೀವು ಅದಕ್ಕೆ ಅನುಗುಣವಾಗಿ ಈ ಕೆಲಸವನ್ನು ಸಮೀಪಿಸಬೇಕಾಗಿದೆ - ಬೆಂಚ್‌ಮಾರ್ಕ್‌ಗಳನ್ನು ಮಾಡಿ, ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಿ, ನೀವು ಹಿಂದಿನ ಆವೃತ್ತಿಗೆ ಹಿಂತಿರುಗಿದಾಗ, ನಿಮ್ಮ ಹಳೆಯ ಹ್ಯಾಕ್ ಮತ್ತೆ ಕೆಲಸ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿದಾಗ (ಅಥವಾ ಪ್ರತಿಯಾಗಿ, ನಿಲ್ಲಿಸಿದಾಗ) ಸಂದರ್ಭಗಳನ್ನು ವಿವರಿಸಿ. ಮತ್ತು ನೀವು ಏನನ್ನಾದರೂ ಸಾಧಿಸುವವರೆಗೆ ಬಿಟ್ಟುಕೊಡಬೇಡಿ. ನಾನು ಈಗಾಗಲೇ ಹೇಳಿದಂತೆ, ಕೆಲಸ ಮಾಡದ ತಂಪಾದ ವಿಚಾರಗಳಿದ್ದರೆ, ಆದರೆ ಐಡಿಯಾಗಳ ರೆಜಿಸ್ಟರ್‌ಗಳ ಹಂಚಿಕೆ ಕ್ಷೇತ್ರದಲ್ಲಿ ಅದು ಸರಿಸುಮಾರು ಅಂತ್ಯವಿಲ್ಲ. ಉದಾಹರಣೆಗೆ, ನೀವು ವೈಜ್ಞಾನಿಕ ಪ್ರಕಟಣೆಗಳನ್ನು ಓದಬಹುದು. ಈಗ ಈ ಪ್ರದೇಶವು ಹೆಚ್ಚು ನಿಧಾನವಾಗಿ ಚಲಿಸಲು ಪ್ರಾರಂಭಿಸಿದೆ ಮತ್ತು ಅದರ ಯೌವನಕ್ಕಿಂತ ಹೆಚ್ಚು ಸ್ಪಷ್ಟವಾಗಿದೆ. ಆದಾಗ್ಯೂ, ಈ ಕ್ಷೇತ್ರದಲ್ಲಿ ಅಸಂಖ್ಯಾತ ಜನರು ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದಾರೆ ಮತ್ತು ಅವರ ಎಲ್ಲಾ ಆಲೋಚನೆಗಳು ಪ್ರಯತ್ನಿಸಲು ಯೋಗ್ಯವಾಗಿವೆ, ಅವರೆಲ್ಲರೂ ರೆಕ್ಕೆಗಳಲ್ಲಿ ಕಾಯುತ್ತಿದ್ದಾರೆ. ಮತ್ತು ನೀವು ಅವುಗಳನ್ನು ಪ್ರಯತ್ನಿಸದ ಹೊರತು ಅವರು ಎಷ್ಟು ಒಳ್ಳೆಯವರು ಎಂದು ಹೇಳಲು ಸಾಧ್ಯವಿಲ್ಲ. ನಿಮ್ಮ ಅಲೋಕೇಟರ್‌ನಲ್ಲಿರುವ ಎಲ್ಲದರೊಂದಿಗೆ ಅವರು ಎಷ್ಟು ಚೆನ್ನಾಗಿ ಸಂಯೋಜಿಸುತ್ತಾರೆ, ಏಕೆಂದರೆ ಹಂಚಿಕೆದಾರರು ಬಹಳಷ್ಟು ಕೆಲಸಗಳನ್ನು ಮಾಡುತ್ತಾರೆ ಮತ್ತು ಕೆಲವು ಆಲೋಚನೆಗಳು ನಿಮ್ಮ ನಿರ್ದಿಷ್ಟ ಹಂಚಿಕೆಯಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ, ಆದರೆ ಮತ್ತೊಂದು ಹಂಚಿಕೆಯಲ್ಲಿ ಅವು ಸುಲಭವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ. ಹಂಚಿಕೆದಾರರಿಗೆ ಗೆಲ್ಲಲು ಮುಖ್ಯ ಮಾರ್ಗವೆಂದರೆ ನಿಧಾನವಾದ ವಿಷಯವನ್ನು ಮುಖ್ಯ ಮಾರ್ಗದ ಹೊರಗೆ ಎಳೆಯುವುದು ಮತ್ತು ನಿಧಾನ ಮಾರ್ಗಗಳ ಗಡಿಗಳಲ್ಲಿ ವಿಭಜಿಸಲು ಒತ್ತಾಯಿಸುವುದು. ಆದ್ದರಿಂದ ನೀವು GC ಅನ್ನು ಚಲಾಯಿಸಲು ಬಯಸಿದರೆ, ನಿಧಾನವಾದ ಮಾರ್ಗವನ್ನು ತೆಗೆದುಕೊಳ್ಳಿ, ಡಿಆಪ್ಟಿಮೈಜ್ ಮಾಡಿ, ವಿನಾಯಿತಿಯನ್ನು ಎಸೆಯಿರಿ, ಎಲ್ಲಾ ವಿಷಯಗಳು - ಇವುಗಳು ತುಲನಾತ್ಮಕವಾಗಿ ಅಪರೂಪವೆಂದು ನಿಮಗೆ ತಿಳಿದಿದೆ. ಮತ್ತು ಅವರು ನಿಜವಾಗಿಯೂ ಅಪರೂಪ, ನಾನು ಪರಿಶೀಲಿಸಿದ್ದೇನೆ. ನೀವು ಹೆಚ್ಚುವರಿ ಕೆಲಸವನ್ನು ಮಾಡುತ್ತೀರಿ ಮತ್ತು ಇದು ಈ ನಿಧಾನಗತಿಯ ಮಾರ್ಗಗಳ ಮೇಲಿನ ಬಹಳಷ್ಟು ನಿರ್ಬಂಧಗಳನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ, ಆದರೆ ಇದು ನಿಜವಾಗಿಯೂ ಅಪ್ರಸ್ತುತವಾಗುತ್ತದೆ ಏಕೆಂದರೆ ಅವುಗಳು ನಿಧಾನವಾಗಿರುತ್ತವೆ ಮತ್ತು ಅಪರೂಪವಾಗಿ ಪ್ರಯಾಣಿಸುತ್ತವೆ. ಉದಾಹರಣೆಗೆ, ಶೂನ್ಯ ಪಾಯಿಂಟರ್ - ಅದು ಎಂದಿಗೂ ಸಂಭವಿಸುವುದಿಲ್ಲ, ಸರಿ? ವಿಭಿನ್ನ ವಿಷಯಗಳಿಗಾಗಿ ನೀವು ಹಲವಾರು ಮಾರ್ಗಗಳನ್ನು ಹೊಂದಿರಬೇಕು, ಆದರೆ ಅವು ಮುಖ್ಯವಾದವುಗಳೊಂದಿಗೆ ಹಸ್ತಕ್ಷೇಪ ಮಾಡಬಾರದು. 

Владимир: ಏಕಕಾಲದಲ್ಲಿ ಸಾವಿರಾರು ಕೋರ್‌ಗಳಿರುವಾಗ ಬಹು-ಕೋರ್‌ಗಳ ಬಗ್ಗೆ ನಿಮ್ಮ ಅಭಿಪ್ರಾಯವೇನು? ಇದು ಉಪಯುಕ್ತ ವಿಷಯವೇ?

ಕ್ಲಿಫ್: GPU ನ ಯಶಸ್ಸು ಇದು ಸಾಕಷ್ಟು ಉಪಯುಕ್ತವಾಗಿದೆ ಎಂದು ತೋರಿಸುತ್ತದೆ!

Владимир: ಅವರು ಸಾಕಷ್ಟು ವಿಶೇಷ. ಸಾಮಾನ್ಯ ಉದ್ದೇಶದ ಪ್ರೊಸೆಸರ್ಗಳ ಬಗ್ಗೆ ಏನು?

ಕ್ಲಿಫ್: ಸರಿ, ಅದು ಅಜುಲ್‌ನ ವ್ಯವಹಾರ ಮಾದರಿಯಾಗಿತ್ತು. ಜನರು ನಿಜವಾಗಿಯೂ ಊಹಿಸಬಹುದಾದ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಇಷ್ಟಪಡುವ ಯುಗದಲ್ಲಿ ಉತ್ತರವು ಮರಳಿ ಬಂದಿತು. ಆಗ ಸಮಾನಾಂತರ ಕೋಡ್ ಬರೆಯುವುದು ಕಷ್ಟವಾಗಿತ್ತು. H2O ಕೋಡಿಂಗ್ ಮಾದರಿಯು ಹೆಚ್ಚು ಸ್ಕೇಲೆಬಲ್ ಆಗಿದೆ, ಆದರೆ ಇದು ಸಾಮಾನ್ಯ ಉದ್ದೇಶದ ಮಾದರಿಯಲ್ಲ. ಬಹುಶಃ GPU ಅನ್ನು ಬಳಸುವಾಗ ಸ್ವಲ್ಪ ಹೆಚ್ಚು ಸಾಮಾನ್ಯವಾಗಿದೆ. ನಾವು ಅಂತಹ ವಿಷಯವನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವ ಸಂಕೀರ್ಣತೆಯ ಬಗ್ಗೆ ಅಥವಾ ಅದನ್ನು ಬಳಸುವ ಸಂಕೀರ್ಣತೆಯ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತಿದ್ದೇವೆಯೇ? ಉದಾಹರಣೆಗೆ, ಅಜುಲ್ ನನಗೆ ಆಸಕ್ತಿದಾಯಕ ಪಾಠವನ್ನು ಕಲಿಸಿದರು, ಬದಲಿಗೆ ಸ್ಪಷ್ಟವಾಗಿಲ್ಲ: ಸಣ್ಣ ಸಂಗ್ರಹಗಳು ಸಾಮಾನ್ಯವಾಗಿದೆ. 

ಜೀವನದಲ್ಲಿ ದೊಡ್ಡ ಸವಾಲು

Владимир: ತಾಂತ್ರಿಕವಲ್ಲದ ಸವಾಲುಗಳ ಬಗ್ಗೆ ಏನು?

ಕ್ಲಿಫ್: ಜನರೊಂದಿಗೆ ದಯೆ ಮತ್ತು ಒಳ್ಳೆಯವರಾಗಿರಬಾರದು ಎಂಬುದು ದೊಡ್ಡ ಸವಾಲಾಗಿತ್ತು. ಮತ್ತು ಪರಿಣಾಮವಾಗಿ, ನಾನು ನಿರಂತರವಾಗಿ ಅತ್ಯಂತ ಸಂಘರ್ಷದ ಸಂದರ್ಭಗಳಲ್ಲಿ ನನ್ನನ್ನು ಕಂಡುಕೊಂಡೆ. ವಿಷಯಗಳು ತಪ್ಪಾಗುತ್ತಿವೆ ಎಂದು ನನಗೆ ತಿಳಿದಿತ್ತು, ಆದರೆ ಆ ಸಮಸ್ಯೆಗಳೊಂದಿಗೆ ಹೇಗೆ ಮುಂದುವರಿಯುವುದು ಎಂದು ತಿಳಿದಿರಲಿಲ್ಲ ಮತ್ತು ಅವುಗಳನ್ನು ನಿಭಾಯಿಸಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ. ದಶಕಗಳ ಕಾಲ ಉಳಿಯುವ ಅನೇಕ ದೀರ್ಘಕಾಲೀನ ಸಮಸ್ಯೆಗಳು ಈ ರೀತಿಯಲ್ಲಿ ಉದ್ಭವಿಸಿದವು. ಜಾವಾವು C1 ಮತ್ತು C2 ಕಂಪೈಲರ್‌ಗಳನ್ನು ಹೊಂದಿದೆ ಎಂಬುದು ಇದರ ನೇರ ಪರಿಣಾಮವಾಗಿದೆ. ಸತತ ಹತ್ತು ವರ್ಷಗಳ ಕಾಲ ಜಾವಾದಲ್ಲಿ ಬಹು ಹಂತದ ಸಂಕಲನ ಇರಲಿಲ್ಲ ಎಂಬುದೂ ನೇರ ಪರಿಣಾಮವಾಗಿದೆ. ನಮಗೆ ಅಂತಹ ವ್ಯವಸ್ಥೆ ಬೇಕು ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ, ಆದರೆ ಅದು ಏಕೆ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿಲ್ಲ. ಒಬ್ಬ ಇಂಜಿನಿಯರ್ ಅಥವಾ ಇಂಜಿನಿಯರ್‌ಗಳ ಗುಂಪಿನೊಂದಿಗೆ ನನಗೆ ಸಮಸ್ಯೆಗಳಿವೆ. ಒಂದಾನೊಂದು ಕಾಲದಲ್ಲಿ, ನಾನು ಸನ್ ನಲ್ಲಿ ಕೆಲಸ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿದಾಗ, ನಾನು ... ಓಕೆ, ಆಗ ಮಾತ್ರವಲ್ಲ, ನಾನು ಸಾಮಾನ್ಯವಾಗಿ ಯಾವಾಗಲೂ ಎಲ್ಲದರ ಬಗ್ಗೆ ನನ್ನದೇ ಆದ ಅಭಿಪ್ರಾಯವನ್ನು ಹೊಂದಿದ್ದೇನೆ. ಮತ್ತು ನೀವು ನಿಮ್ಮ ಈ ಸತ್ಯವನ್ನು ತೆಗೆದುಕೊಂಡು ಅದನ್ನು ತಲೆಯಲ್ಲಿ ಹೇಳಬಹುದು ಎಂಬುದು ನಿಜ ಎಂದು ನಾನು ಭಾವಿಸಿದೆ. ವಿಶೇಷವಾಗಿ ನಾನು ಆಘಾತಕಾರಿಯಾಗಿ ಹೆಚ್ಚಿನ ಸಮಯ ಸರಿಯಾಗಿದೆ. ಮತ್ತು ನೀವು ಈ ವಿಧಾನವನ್ನು ಇಷ್ಟಪಡದಿದ್ದರೆ ... ವಿಶೇಷವಾಗಿ ನೀವು ನಿಸ್ಸಂಶಯವಾಗಿ ತಪ್ಪು ಮತ್ತು ಅಸಂಬದ್ಧತೆಯನ್ನು ಮಾಡುತ್ತಿದ್ದರೆ ... ಸಾಮಾನ್ಯವಾಗಿ, ಕೆಲವು ಜನರು ಈ ರೀತಿಯ ಸಂವಹನವನ್ನು ಸಹಿಸಿಕೊಳ್ಳಬಲ್ಲರು. ಕೆಲವರು ಸಾಧ್ಯವಾದರೂ, ನನ್ನಂತೆ. ನಾನು ನನ್ನ ಸಂಪೂರ್ಣ ಜೀವನವನ್ನು ಅರ್ಹತಾ ತತ್ವಗಳ ಮೇಲೆ ನಿರ್ಮಿಸಿದ್ದೇನೆ. ನೀವು ಏನಾದರೂ ತಪ್ಪು ತೋರಿಸಿದರೆ, ನಾನು ತಕ್ಷಣ ತಿರುಗಿ ಹೇಳುತ್ತೇನೆ: ನೀವು ಅಸಂಬದ್ಧವಾಗಿ ಹೇಳಿದ್ದೀರಿ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಖಂಡಿತವಾಗಿ, ನಾನು ಕ್ಷಮೆಯಾಚಿಸುತ್ತೇನೆ ಮತ್ತು ಅದೆಲ್ಲವೂ, ಯಾವುದಾದರೂ ಇದ್ದರೆ, ನಾನು ಅರ್ಹತೆಗಳನ್ನು ಗಮನಿಸುತ್ತೇನೆ ಮತ್ತು ಇತರ ಸರಿಯಾದ ಕ್ರಮಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತೇನೆ. ಮತ್ತೊಂದೆಡೆ, ಒಟ್ಟು ಸಮಯದ ಆಘಾತಕಾರಿ ದೊಡ್ಡ ಶೇಕಡಾವಾರು ಬಗ್ಗೆ ನಾನು ಆಘಾತಕಾರಿಯಾಗಿ ಸರಿ. ಮತ್ತು ಜನರೊಂದಿಗಿನ ಸಂಬಂಧಗಳಲ್ಲಿ ಇದು ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ. ನಾನು ಒಳ್ಳೆಯವನಾಗಲು ಪ್ರಯತ್ನಿಸುತ್ತಿಲ್ಲ, ಆದರೆ ನಾನು ಪ್ರಶ್ನೆಯನ್ನು ನೇರವಾಗಿ ಕೇಳುತ್ತಿದ್ದೇನೆ. "ಇದು ಎಂದಿಗೂ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಒಂದು, ಎರಡು ಮತ್ತು ಮೂರು." ಮತ್ತು ಅವರು "ಓಹ್!" ನಿರ್ಲಕ್ಷಿಸಲು ಬಹುಶಃ ಉತ್ತಮವಾದ ಇತರ ಪರಿಣಾಮಗಳು ಇದ್ದವು: ಉದಾಹರಣೆಗೆ, ನನ್ನ ಹೆಂಡತಿಯಿಂದ ವಿಚ್ಛೇದನಕ್ಕೆ ಕಾರಣವಾದವು ಮತ್ತು ಅದರ ನಂತರ ಹತ್ತು ವರ್ಷಗಳ ಖಿನ್ನತೆಗೆ ಕಾರಣವಾಯಿತು.

ಸವಾಲು ಎನ್ನುವುದು ಜನರೊಂದಿಗೆ ಹೋರಾಟವಾಗಿದೆ, ನೀವು ಏನು ಮಾಡಬಹುದು ಅಥವಾ ಮಾಡಬಾರದು, ಯಾವುದು ಮುಖ್ಯ ಮತ್ತು ಯಾವುದು ಅಲ್ಲ ಎಂಬ ಅವರ ಗ್ರಹಿಕೆಯೊಂದಿಗೆ. ಕೋಡಿಂಗ್ ಶೈಲಿಯ ಬಗ್ಗೆ ಹಲವು ಸವಾಲುಗಳಿದ್ದವು. ನಾನು ಇನ್ನೂ ಬಹಳಷ್ಟು ಕೋಡ್ ಅನ್ನು ಬರೆಯುತ್ತೇನೆ ಮತ್ತು ಆ ದಿನಗಳಲ್ಲಿ ನಾನು ಒಂದರ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸುವ ಬದಲು ಹಲವಾರು ಸಮಾನಾಂತರ ಕಾರ್ಯಗಳನ್ನು ಮಾಡುತ್ತಿದ್ದೆ ಮತ್ತು ಅವುಗಳನ್ನು ಕಳಪೆಯಾಗಿ ಮಾಡುತ್ತಿದ್ದ ಕಾರಣ ನಾನು ನಿಧಾನಗೊಳಿಸಬೇಕಾಗಿತ್ತು. ಹಿಂತಿರುಗಿ ನೋಡಿದಾಗ, ನಾನು ಜಾವಾ JIT ಕಮಾಂಡ್, C2 ಆಜ್ಞೆಗೆ ಅರ್ಧದಷ್ಟು ಕೋಡ್ ಅನ್ನು ಬರೆದಿದ್ದೇನೆ. ಮುಂದಿನ ವೇಗದ ಕೋಡರ್ ಅರ್ಧವನ್ನು ನಿಧಾನವಾಗಿ, ಮುಂದಿನ ಅರ್ಧವನ್ನು ನಿಧಾನ ಎಂದು ಬರೆದರು ಮತ್ತು ಅದು ಘಾತೀಯ ಕುಸಿತವಾಗಿದೆ. ಈ ಸಾಲಿನ ಏಳನೇ ವ್ಯಕ್ತಿ ತುಂಬಾ ನಿಧಾನವಾಗಿದ್ದರು - ಅದು ಯಾವಾಗಲೂ ಸಂಭವಿಸುತ್ತದೆ! ನಾನು ಬಹಳಷ್ಟು ಕೋಡ್ ಅನ್ನು ಮುಟ್ಟಿದೆ. ಯಾರು ಏನು ಬರೆದಿದ್ದಾರೆಂದು ನಾನು ನೋಡಿದೆ, ವಿನಾಯಿತಿ ಇಲ್ಲದೆ, ನಾನು ಅವರ ಕೋಡ್ ಅನ್ನು ದಿಟ್ಟಿಸಿ ನೋಡಿದೆ, ಪ್ರತಿಯೊಂದನ್ನೂ ಪರಿಶೀಲಿಸಿದೆ ಮತ್ತು ಅವರಿಗಿಂತ ಹೆಚ್ಚು ನಾನೇ ಬರೆಯುವುದನ್ನು ಮುಂದುವರಿಸಿದೆ. ಈ ವಿಧಾನವು ಜನರೊಂದಿಗೆ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ. ಕೆಲವರಿಗೆ ಇದು ಇಷ್ಟವಾಗುವುದಿಲ್ಲ. ಮತ್ತು ಅವರು ಅದನ್ನು ನಿಭಾಯಿಸಲು ಸಾಧ್ಯವಾಗದಿದ್ದಾಗ, ಎಲ್ಲಾ ರೀತಿಯ ದೂರುಗಳು ಪ್ರಾರಂಭವಾಗುತ್ತವೆ. ಉದಾಹರಣೆಗೆ, ನಾನು ಕೋಡಿಂಗ್ ಅನ್ನು ನಿಲ್ಲಿಸಲು ಹೇಳಿದ್ದೇನೆ ಏಕೆಂದರೆ ನಾನು ಹೆಚ್ಚು ಕೋಡ್ ಅನ್ನು ಬರೆಯುತ್ತಿದ್ದೇನೆ ಮತ್ತು ಅದು ತಂಡಕ್ಕೆ ಅಪಾಯವನ್ನುಂಟುಮಾಡುತ್ತಿದೆ, ಮತ್ತು ಅದು ನನಗೆ ತಮಾಷೆಯಂತೆ ತೋರುತ್ತದೆ: ಗೆಳೆಯ, ತಂಡದ ಉಳಿದವರು ಕಣ್ಮರೆಯಾಗುತ್ತಿದ್ದರೆ ಮತ್ತು ನಾನು ಕೋಡ್ ಬರೆಯುವುದನ್ನು ಮುಂದುವರಿಸಿದರೆ, ನೀವು ಅರ್ಧ ತಂಡಗಳನ್ನು ಮಾತ್ರ ಕಳೆದುಕೊಳ್ಳುತ್ತೇವೆ. ಮತ್ತೊಂದೆಡೆ, ನಾನು ಕೋಡ್ ಬರೆಯುವುದನ್ನು ಮುಂದುವರಿಸಿದರೆ ಮತ್ತು ನೀವು ಅರ್ಧದಷ್ಟು ತಂಡವನ್ನು ಕಳೆದುಕೊಂಡರೆ, ಅದು ತುಂಬಾ ಕೆಟ್ಟ ನಿರ್ವಹಣೆಯಂತೆ ತೋರುತ್ತದೆ. ನಾನು ಅದರ ಬಗ್ಗೆ ಎಂದಿಗೂ ಯೋಚಿಸಲಿಲ್ಲ, ಅದರ ಬಗ್ಗೆ ಮಾತನಾಡಲಿಲ್ಲ, ಆದರೆ ಅದು ಇನ್ನೂ ನನ್ನ ತಲೆಯಲ್ಲಿ ಎಲ್ಲೋ ಇತ್ತು. ನನ್ನ ಮನಸ್ಸಿನಲ್ಲಿ ಆಲೋಚನೆಯು ಸುತ್ತುತ್ತಿದೆ: "ನೀವೆಲ್ಲರೂ ನನ್ನನ್ನು ತಮಾಷೆ ಮಾಡುತ್ತಿದ್ದೀರಾ?" ಆದ್ದರಿಂದ, ದೊಡ್ಡ ಸಮಸ್ಯೆ ಎಂದರೆ ನಾನು ಮತ್ತು ಜನರೊಂದಿಗಿನ ನನ್ನ ಸಂಬಂಧ. ಈಗ ನಾನು ನನ್ನನ್ನು ಹೆಚ್ಚು ಚೆನ್ನಾಗಿ ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇನೆ, ನಾನು ದೀರ್ಘಕಾಲದವರೆಗೆ ಪ್ರೋಗ್ರಾಮರ್‌ಗಳಿಗೆ ತಂಡದ ನಾಯಕನಾಗಿದ್ದೆ ಮತ್ತು ಈಗ ನಾನು ನೇರವಾಗಿ ಜನರಿಗೆ ಹೇಳುತ್ತೇನೆ: ನಿಮಗೆ ತಿಳಿದಿದೆ, ನಾನು ನಾನೇ, ಮತ್ತು ನೀವು ನನ್ನೊಂದಿಗೆ ವ್ಯವಹರಿಸಬೇಕು - ನಾನು ನಿಂತರೆ ಸರಿಯೇ? ಇಲ್ಲಿ? ಮತ್ತು ಅವರು ಅದನ್ನು ನಿಭಾಯಿಸಲು ಪ್ರಾರಂಭಿಸಿದಾಗ, ಎಲ್ಲವೂ ಕೆಲಸ ಮಾಡಿತು. ವಾಸ್ತವವಾಗಿ, ನಾನು ಕೆಟ್ಟವನಲ್ಲ ಅಥವಾ ಒಳ್ಳೆಯವನಲ್ಲ, ನನಗೆ ಯಾವುದೇ ಕೆಟ್ಟ ಉದ್ದೇಶಗಳು ಅಥವಾ ಸ್ವಾರ್ಥಿ ಆಕಾಂಕ್ಷೆಗಳಿಲ್ಲ, ಅದು ನನ್ನ ಮೂಲತತ್ವವಾಗಿದೆ ಮತ್ತು ನಾನು ಹೇಗಾದರೂ ಅದರೊಂದಿಗೆ ಬದುಕಬೇಕು.

ಆಂಡ್ರಾಯ್ಡ್: ಇತ್ತೀಚೆಗೆ ಎಲ್ಲರೂ ಅಂತರ್ಮುಖಿಗಳಿಗೆ ಸ್ವಯಂ ಅರಿವು ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ಮೃದು ಕೌಶಲ್ಯಗಳ ಬಗ್ಗೆ ಮಾತನಾಡಲು ಪ್ರಾರಂಭಿಸಿದರು. ಇದರ ಬಗ್ಗೆ ನೀವು ಏನು ಹೇಳಬಹುದು?

ಕ್ಲಿಫ್: ಹೌದು, ಅದು ನನ್ನ ಹೆಂಡತಿಯಿಂದ ನನ್ನ ವಿಚ್ಛೇದನದಿಂದ ನಾನು ಕಲಿತ ಒಳನೋಟ ಮತ್ತು ಪಾಠವಾಗಿತ್ತು. ವಿಚ್ಛೇದನದಿಂದ ನಾನು ಕಲಿತದ್ದು ನನ್ನನ್ನೇ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು. ನಾನು ಇತರ ಜನರನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಪ್ರಾರಂಭಿಸಿದ್ದು ಹೀಗೆ. ಈ ಪರಸ್ಪರ ಕ್ರಿಯೆಯು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಿ. ಇದು ಒಂದರ ನಂತರ ಒಂದರಂತೆ ಸಂಶೋಧನೆಗಳಿಗೆ ಕಾರಣವಾಯಿತು. ನಾನು ಯಾರು ಮತ್ತು ನಾನು ಏನನ್ನು ಪ್ರತಿನಿಧಿಸುತ್ತೇನೆ ಎಂಬ ಅರಿವು ಇತ್ತು. ನಾನು ಏನು ಮಾಡುತ್ತಿದ್ದೇನೆ: ಒಂದೋ ನಾನು ಕಾರ್ಯದಲ್ಲಿ ತೊಡಗಿಸಿಕೊಂಡಿದ್ದೇನೆ, ಅಥವಾ ನಾನು ಸಂಘರ್ಷವನ್ನು ತಪ್ಪಿಸುತ್ತಿದ್ದೇನೆ ಅಥವಾ ಇನ್ನೇನಾದರೂ - ಮತ್ತು ಈ ಮಟ್ಟದ ಸ್ವಯಂ-ಅರಿವು ನಿಜವಾಗಿಯೂ ನನ್ನನ್ನು ನಿಯಂತ್ರಣದಲ್ಲಿಟ್ಟುಕೊಳ್ಳಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಇದರ ನಂತರ ಎಲ್ಲವೂ ಹೆಚ್ಚು ಸುಲಭವಾಗುತ್ತದೆ. ನನ್ನಲ್ಲಿ ಮಾತ್ರವಲ್ಲದೆ ಇತರ ಪ್ರೋಗ್ರಾಮರ್‌ಗಳಲ್ಲಿಯೂ ನಾನು ಕಂಡುಹಿಡಿದ ಒಂದು ವಿಷಯವೆಂದರೆ ನೀವು ಭಾವನಾತ್ಮಕ ಒತ್ತಡದ ಸ್ಥಿತಿಯಲ್ಲಿದ್ದಾಗ ಆಲೋಚನೆಗಳನ್ನು ಮೌಖಿಕವಾಗಿ ಹೇಳಲು ಅಸಮರ್ಥತೆ. ಉದಾಹರಣೆಗೆ, ನೀವು ಹರಿವಿನ ಸ್ಥಿತಿಯಲ್ಲಿ ಕೋಡಿಂಗ್ ಮಾಡುತ್ತಿದ್ದೀರಿ, ಮತ್ತು ನಂತರ ಅವರು ನಿಮ್ಮ ಬಳಿಗೆ ಓಡಿಹೋಗುತ್ತಾರೆ ಮತ್ತು ಏನಾದರೂ ಮುರಿದುಹೋಗಿದೆ ಮತ್ತು ಈಗ ನಿಮ್ಮ ವಿರುದ್ಧ ತೀವ್ರ ಕ್ರಮಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಲಾಗುವುದು ಎಂದು ಉನ್ಮಾದದಲ್ಲಿ ಕಿರುಚಲು ಪ್ರಾರಂಭಿಸುತ್ತಾರೆ. ಮತ್ತು ನೀವು ಒಂದು ಪದವನ್ನು ಹೇಳಲು ಸಾಧ್ಯವಿಲ್ಲ ಏಕೆಂದರೆ ನೀವು ಭಾವನಾತ್ಮಕ ಒತ್ತಡದ ಸ್ಥಿತಿಯಲ್ಲಿರುತ್ತೀರಿ. ಸ್ವಾಧೀನಪಡಿಸಿಕೊಂಡ ಜ್ಞಾನವು ಈ ಕ್ಷಣಕ್ಕೆ ತಯಾರಾಗಲು, ಅದನ್ನು ಬದುಕಲು ಮತ್ತು ಹಿಮ್ಮೆಟ್ಟುವಿಕೆಯ ಯೋಜನೆಗೆ ತೆರಳಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ, ಅದರ ನಂತರ ನೀವು ಏನನ್ನಾದರೂ ಮಾಡಬಹುದು. ಆದ್ದರಿಂದ ಹೌದು, ಅದು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನೀವು ಅರಿತುಕೊಳ್ಳಲು ಪ್ರಾರಂಭಿಸಿದಾಗ, ಇದು ಜೀವನವನ್ನು ಬದಲಾಯಿಸುವ ದೊಡ್ಡ ಘಟನೆಯಾಗಿದೆ. 
ನನಗೆ ಸರಿಯಾದ ಪದಗಳನ್ನು ಕಂಡುಹಿಡಿಯಲಾಗಲಿಲ್ಲ, ಆದರೆ ಕ್ರಿಯೆಗಳ ಅನುಕ್ರಮವನ್ನು ನಾನು ನೆನಪಿಸಿಕೊಂಡಿದ್ದೇನೆ. ಈ ಪ್ರತಿಕ್ರಿಯೆಯು ಮೌಖಿಕವಾಗಿರುವಂತೆಯೇ ಭೌತಿಕವಾಗಿದೆ ಮತ್ತು ನಿಮಗೆ ಸ್ಥಳಾವಕಾಶ ಬೇಕು. ಅಂತಹ ಜಾಗ, ಝೆನ್ ಅರ್ಥದಲ್ಲಿ. ಇದು ನಿಖರವಾಗಿ ವಿವರಿಸಬೇಕಾದದ್ದು, ಮತ್ತು ನಂತರ ತಕ್ಷಣವೇ ಪಕ್ಕಕ್ಕೆ ಸರಿಸಿ - ಸಂಪೂರ್ಣವಾಗಿ ದೈಹಿಕವಾಗಿ ದೂರವಿರಿ. ನಾನು ಮೌಖಿಕವಾಗಿ ಮೌನವಾಗಿದ್ದಾಗ, ನಾನು ಪರಿಸ್ಥಿತಿಯನ್ನು ಭಾವನಾತ್ಮಕವಾಗಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಬಹುದು. ಅಡ್ರಿನಾಲಿನ್ ನಿಮ್ಮ ಮೆದುಳಿಗೆ ತಲುಪಿದಂತೆ, ನಿಮ್ಮನ್ನು ಯುದ್ಧ ಅಥವಾ ಫ್ಲೈಟ್ ಮೋಡ್‌ಗೆ ಬದಲಾಯಿಸಿದಾಗ, ನೀವು ಇನ್ನು ಮುಂದೆ ಏನನ್ನೂ ಹೇಳಲು ಸಾಧ್ಯವಿಲ್ಲ, ಇಲ್ಲ - ಈಗ ನೀವು ಮೂರ್ಖ, ಚಾವಟಿ ಇಂಜಿನಿಯರ್, ಯೋಗ್ಯ ಪ್ರತಿಕ್ರಿಯೆ ನೀಡಲು ಅಥವಾ ದಾಳಿಯನ್ನು ನಿಲ್ಲಿಸಲು ಅಸಮರ್ಥರಾಗಿದ್ದೀರಿ ಮತ್ತು ಆಕ್ರಮಣಕಾರನು ಮುಕ್ತನಾಗಿರುತ್ತಾನೆ. ಮತ್ತೆ ಮತ್ತೆ ದಾಳಿ ಮಾಡಲು. ನೀವು ಮೊದಲು ಮತ್ತೆ ನೀವೇ ಆಗಬೇಕು, ನಿಯಂತ್ರಣವನ್ನು ಮರಳಿ ಪಡೆದುಕೊಳ್ಳಬೇಕು, "ಹೋರಾಟ ಅಥವಾ ಹಾರಾಟ" ಮೋಡ್‌ನಿಂದ ಹೊರಬರಬೇಕು.

ಮತ್ತು ಇದಕ್ಕಾಗಿ ನಮಗೆ ಮೌಖಿಕ ಸ್ಥಳ ಬೇಕು. ಕೇವಲ ಮುಕ್ತ ಸ್ಥಳ. ನೀವು ಏನನ್ನಾದರೂ ಹೇಳಿದರೆ, ನೀವು ಅದನ್ನು ನಿಖರವಾಗಿ ಹೇಳಬಹುದು, ತದನಂತರ ಹೋಗಿ ಮತ್ತು ನಿಮಗಾಗಿ “ಜಾಗವನ್ನು” ಕಂಡುಕೊಳ್ಳಿ: ಉದ್ಯಾನದಲ್ಲಿ ನಡೆಯಲು ಹೋಗಿ, ಶವರ್‌ನಲ್ಲಿ ನಿಮ್ಮನ್ನು ಲಾಕ್ ಮಾಡಿ - ಅದು ಅಪ್ರಸ್ತುತವಾಗುತ್ತದೆ. ಆ ಪರಿಸ್ಥಿತಿಯಿಂದ ತಾತ್ಕಾಲಿಕವಾಗಿ ಸಂಪರ್ಕ ಕಡಿತಗೊಳಿಸುವುದು ಮುಖ್ಯ ವಿಷಯ. ನೀವು ಕನಿಷ್ಟ ಕೆಲವು ಸೆಕೆಂಡುಗಳ ಕಾಲ ಸ್ವಿಚ್ ಆಫ್ ಮಾಡಿದ ತಕ್ಷಣ, ಆದಾಯವನ್ನು ನಿಯಂತ್ರಿಸಿ, ನೀವು ಶಾಂತವಾಗಿ ಯೋಚಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತೀರಿ. "ಸರಿ, ನಾನು ಕೆಲವು ರೀತಿಯ ಮೂರ್ಖನಲ್ಲ, ನಾನು ಅವಿವೇಕಿ ಕೆಲಸಗಳನ್ನು ಮಾಡುವುದಿಲ್ಲ, ನಾನು ಸಾಕಷ್ಟು ಉಪಯುಕ್ತ ವ್ಯಕ್ತಿ." ಒಮ್ಮೆ ನೀವು ನಿಮ್ಮನ್ನು ಮನವರಿಕೆ ಮಾಡಲು ಸಾಧ್ಯವಾದರೆ, ಮುಂದಿನ ಹಂತಕ್ಕೆ ತೆರಳಲು ಸಮಯವಾಗಿದೆ: ಏನಾಯಿತು ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು. ನಿಮ್ಮ ಮೇಲೆ ದಾಳಿ ಮಾಡಲಾಗಿದೆ, ನೀವು ನಿರೀಕ್ಷಿಸದ ಸ್ಥಳದಿಂದ ದಾಳಿ ಬಂದಿದೆ, ಇದು ಅಪ್ರಾಮಾಣಿಕ, ಕೆಟ್ಟ ಹೊಂಚುದಾಳಿಯಾಗಿದೆ. ಇದು ಕೆಟ್ಟದ್ದು. ಆಕ್ರಮಣಕಾರರಿಗೆ ಇದು ಏಕೆ ಬೇಕು ಎಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಮುಂದಿನ ಹಂತವಾಗಿದೆ. ನಿಜವಾಗಿಯೂ, ಏಕೆ? ಬಹುಶಃ ಅವನೇ ಕೋಪಗೊಂಡಿದ್ದರಿಂದ? ಅವನು ಯಾಕೆ ಹುಚ್ಚನಾಗಿದ್ದಾನೆ? ಉದಾಹರಣೆಗೆ, ಅವನು ತನ್ನನ್ನು ತಾನೇ ಕೆಡಿಸಿಕೊಂಡಿದ್ದರಿಂದ ಮತ್ತು ಜವಾಬ್ದಾರಿಯನ್ನು ಸ್ವೀಕರಿಸಲು ಸಾಧ್ಯವಿಲ್ಲವೇ? ಇಡೀ ಪರಿಸ್ಥಿತಿಯನ್ನು ಎಚ್ಚರಿಕೆಯಿಂದ ನಿಭಾಯಿಸುವ ಮಾರ್ಗ ಇದು. ಆದರೆ ಇದಕ್ಕೆ ಕುಶಲತೆ, ಮೌಖಿಕ ಸ್ಥಳಾವಕಾಶ ಬೇಕಾಗುತ್ತದೆ. ಮೌಖಿಕ ಸಂಪರ್ಕವನ್ನು ಮುರಿಯುವುದು ಮೊದಲ ಹಂತವಾಗಿದೆ. ಪದಗಳೊಂದಿಗೆ ಚರ್ಚೆಯನ್ನು ತಪ್ಪಿಸಿ. ಅದನ್ನು ರದ್ದುಗೊಳಿಸಿ, ಸಾಧ್ಯವಾದಷ್ಟು ಬೇಗ ಹೊರನಡೆ. ಇದು ದೂರವಾಣಿ ಸಂಭಾಷಣೆಯಾಗಿದ್ದರೆ, ಕೇವಲ ಸ್ಥಗಿತಗೊಳಿಸಿ - ಇದು ನನ್ನ ಮಾಜಿ ಪತ್ನಿಯೊಂದಿಗೆ ಸಂವಹನದಿಂದ ನಾನು ಕಲಿತ ಕೌಶಲ್ಯ. ಸಂಭಾಷಣೆ ಎಲ್ಲಿಯೂ ಉತ್ತಮವಾಗಿ ನಡೆಯದಿದ್ದರೆ, "ವಿದಾಯ" ಎಂದು ಹೇಳಿ ಮತ್ತು ಸ್ಥಗಿತಗೊಳಿಸಿ. ಫೋನ್‌ನ ಇನ್ನೊಂದು ಬದಿಯಿಂದ: "ಬ್ಲಾ ಬ್ಲಾ ಬ್ಲಾ", ನೀವು ಉತ್ತರಿಸುತ್ತೀರಿ: "ಹೌದು, ಬೈ!" ಮತ್ತು ಸ್ಥಗಿತಗೊಳಿಸಿ. ನೀವು ಸಂಭಾಷಣೆಯನ್ನು ಕೊನೆಗೊಳಿಸುತ್ತೀರಿ. ಐದು ನಿಮಿಷಗಳ ನಂತರ, ಸಂವೇದನಾಶೀಲವಾಗಿ ಯೋಚಿಸುವ ಸಾಮರ್ಥ್ಯವು ನಿಮಗೆ ಮರಳಿದಾಗ, ನೀವು ಸ್ವಲ್ಪ ತಣ್ಣಗಾಗಿದ್ದೀರಿ, ಎಲ್ಲದರ ಬಗ್ಗೆ ಯೋಚಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ, ಏನಾಯಿತು ಮತ್ತು ಮುಂದೆ ಏನಾಗುತ್ತದೆ. ಮತ್ತು ಕೇವಲ ಭಾವನೆಯಿಂದ ಪ್ರತಿಕ್ರಿಯಿಸುವ ಬದಲು ಚಿಂತನಶೀಲ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ರೂಪಿಸಲು ಪ್ರಾರಂಭಿಸಿ. ನನಗೆ, ಸ್ವಯಂ-ಅರಿವಿನ ಪ್ರಗತಿಯು ನಿಖರವಾಗಿ ಭಾವನಾತ್ಮಕ ಒತ್ತಡದ ಸಂದರ್ಭದಲ್ಲಿ ನಾನು ಮಾತನಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ. ಈ ಸ್ಥಿತಿಯಿಂದ ಹೊರಬರುವುದು, ಹೇಗೆ ಪ್ರತಿಕ್ರಿಯಿಸಬೇಕು ಮತ್ತು ಸಮಸ್ಯೆಗಳಿಗೆ ಸರಿದೂಗಿಸುವುದು ಹೇಗೆ ಎಂದು ಯೋಚಿಸುವುದು ಮತ್ತು ಯೋಜಿಸುವುದು - ನೀವು ಮಾತನಾಡಲು ಸಾಧ್ಯವಾಗದಿದ್ದಾಗ ಇವುಗಳು ಸರಿಯಾದ ಕ್ರಮಗಳಾಗಿವೆ. ಭಾವನಾತ್ಮಕ ಒತ್ತಡವು ಸ್ವತಃ ಸ್ಪಷ್ಟವಾಗಿ ಗೋಚರಿಸುವ ಪರಿಸ್ಥಿತಿಯಿಂದ ಓಡಿಹೋಗುವುದು ಮತ್ತು ಈ ಒತ್ತಡದಲ್ಲಿ ಭಾಗವಹಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುವುದು ಸುಲಭವಾದ ಮಾರ್ಗವಾಗಿದೆ. ಅದರ ನಂತರ ನೀವು ಯೋಚಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ, ನೀವು ಯೋಚಿಸಲು ಸಾಧ್ಯವಾದಾಗ, ನೀವು ಮಾತನಾಡಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ, ಇತ್ಯಾದಿ.

ಅಂದಹಾಗೆ, ನ್ಯಾಯಾಲಯದಲ್ಲಿ, ಎದುರಾಳಿ ವಕೀಲರು ಇದನ್ನು ನಿಮಗೆ ಮಾಡಲು ಪ್ರಯತ್ನಿಸುತ್ತಾರೆ - ಈಗ ಏಕೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ. ಏಕೆಂದರೆ ನಿಮ್ಮ ಹೆಸರನ್ನು ಸಹ ನೀವು ಉಚ್ಚರಿಸಲು ಸಾಧ್ಯವಾಗದಂತಹ ಸ್ಥಿತಿಗೆ ನಿಮ್ಮನ್ನು ನಿಗ್ರಹಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಅವನು ಹೊಂದಿದ್ದಾನೆ. ನಿಜವಾದ ಅರ್ಥದಲ್ಲಿ, ನೀವು ಮಾತನಾಡಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ. ಇದು ನಿಮಗೆ ಸಂಭವಿಸಿದರೆ ಮತ್ತು ನೀವು ಮಾತಿನ ಕದನಗಳಿರುವ ಸ್ಥಳದಲ್ಲಿ, ನ್ಯಾಯಾಲಯದಂತಹ ಸ್ಥಳದಲ್ಲಿ ನಿಮ್ಮನ್ನು ಕಂಡುಕೊಳ್ಳುತ್ತೀರಿ ಎಂದು ನಿಮಗೆ ತಿಳಿದಿದ್ದರೆ, ನೀವು ನಿಮ್ಮ ವಕೀಲರೊಂದಿಗೆ ಬರಬಹುದು. ವಕೀಲರು ನಿಮ್ಮ ಪರವಾಗಿ ನಿಲ್ಲುತ್ತಾರೆ ಮತ್ತು ಮೌಖಿಕ ದಾಳಿಯನ್ನು ನಿಲ್ಲಿಸುತ್ತಾರೆ ಮತ್ತು ಅದನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಕಾನೂನು ರೀತಿಯಲ್ಲಿ ಮಾಡುತ್ತಾರೆ ಮತ್ತು ಕಳೆದುಹೋದ ಝೆನ್ ಜಾಗವು ನಿಮಗೆ ಮರಳುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ನಾನು ನನ್ನ ಕುಟುಂಬಕ್ಕೆ ಒಂದೆರಡು ಬಾರಿ ಕರೆ ಮಾಡಬೇಕಾಗಿತ್ತು, ನ್ಯಾಯಾಧೀಶರು ಈ ಬಗ್ಗೆ ಸಾಕಷ್ಟು ಸ್ನೇಹಪರರಾಗಿದ್ದರು, ಆದರೆ ಎದುರಾಳಿ ವಕೀಲರು ಕಿರುಚಿದರು ಮತ್ತು ನನ್ನನ್ನು ಕೂಗಿದರು, ನನಗೆ ಅಂಚಿನಲ್ಲಿ ಒಂದು ಮಾತೂ ಸಿಗಲಿಲ್ಲ. ಈ ಸಂದರ್ಭಗಳಲ್ಲಿ, ಮಧ್ಯವರ್ತಿಯನ್ನು ಬಳಸುವುದು ನನಗೆ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಮಧ್ಯವರ್ತಿಯು ನಿರಂತರ ಸ್ಟ್ರೀಮ್ನಲ್ಲಿ ನಿಮ್ಮ ಮೇಲೆ ಸುರಿಯುತ್ತಿರುವ ಈ ಎಲ್ಲಾ ಒತ್ತಡವನ್ನು ನಿಲ್ಲಿಸುತ್ತಾನೆ, ನೀವು ಅಗತ್ಯವಾದ ಝೆನ್ ಜಾಗವನ್ನು ಕಂಡುಕೊಳ್ಳುತ್ತೀರಿ ಮತ್ತು ಅದರೊಂದಿಗೆ ಮಾತನಾಡುವ ಸಾಮರ್ಥ್ಯವು ಮರಳುತ್ತದೆ. ಇದು ಜ್ಞಾನದ ಸಂಪೂರ್ಣ ಕ್ಷೇತ್ರವಾಗಿದ್ದು, ಇದರಲ್ಲಿ ಅಧ್ಯಯನ ಮಾಡಲು ಬಹಳಷ್ಟು ಇದೆ, ನಿಮ್ಮೊಳಗೆ ಕಂಡುಕೊಳ್ಳಲು ಬಹಳಷ್ಟು ಇದೆ, ಮತ್ತು ಇದೆಲ್ಲವೂ ವಿಭಿನ್ನ ಜನರಿಗೆ ವಿಭಿನ್ನವಾದ ಉನ್ನತ ಮಟ್ಟದ ಕಾರ್ಯತಂತ್ರದ ನಿರ್ಧಾರಗಳಾಗಿ ಬದಲಾಗುತ್ತದೆ. ಕೆಲವು ಜನರು ಮೇಲೆ ವಿವರಿಸಿದ ಸಮಸ್ಯೆಗಳನ್ನು ಹೊಂದಿಲ್ಲ; ಸಾಮಾನ್ಯವಾಗಿ, ವೃತ್ತಿಪರ ಮಾರಾಟದ ಜನರು ಅವುಗಳನ್ನು ಹೊಂದಿರುವುದಿಲ್ಲ. ಪದಗಳಿಂದಲೇ ಜೀವನ ಸಾಗಿಸುವ ಇವರೆಲ್ಲರೂ - ಪ್ರಸಿದ್ಧ ಗಾಯಕರು, ಕವಿಗಳು, ಧಾರ್ಮಿಕ ಮುಖಂಡರು ಮತ್ತು ರಾಜಕಾರಣಿಗಳು, ಅವರು ಯಾವಾಗಲೂ ಹೇಳಲು ಏನನ್ನಾದರೂ ಹೊಂದಿರುತ್ತಾರೆ. ಅವರಿಗೆ ಅಂತಹ ಸಮಸ್ಯೆಗಳಿಲ್ಲ, ಆದರೆ ನನಗೆ ಇದೆ.

ಆಂಡ್ರಾಯ್ಡ್: ಇದು ... ಅನಿರೀಕ್ಷಿತ. ಅದ್ಭುತವಾಗಿದೆ, ನಾವು ಈಗಾಗಲೇ ಸಾಕಷ್ಟು ಮಾತನಾಡಿದ್ದೇವೆ ಮತ್ತು ಈ ಸಂದರ್ಶನವನ್ನು ಕೊನೆಗೊಳಿಸುವ ಸಮಯ ಬಂದಿದೆ. ನಾವು ಖಂಡಿತವಾಗಿಯೂ ಸಮ್ಮೇಳನದಲ್ಲಿ ಭೇಟಿಯಾಗುತ್ತೇವೆ ಮತ್ತು ಈ ಸಂವಾದವನ್ನು ಮುಂದುವರಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ. ಹೈಡ್ರಾದಲ್ಲಿ ನಿಮ್ಮನ್ನು ನೋಡೋಣ!

ಜುಲೈ 2019-11, 12 ರಂದು ಸೇಂಟ್ ಪೀಟರ್ಸ್‌ಬರ್ಗ್‌ನಲ್ಲಿ ನಡೆಯಲಿರುವ ಹೈಡ್ರಾ 2019 ಸಮ್ಮೇಳನದಲ್ಲಿ ಕ್ಲಿಫ್‌ನೊಂದಿಗೆ ನಿಮ್ಮ ಸಂಭಾಷಣೆಯನ್ನು ನೀವು ಮುಂದುವರಿಸಬಹುದು. ಅವರು ವರದಿಯೊಂದಿಗೆ ಬರುತ್ತಾರೆ "ಅಜುಲ್ ಹಾರ್ಡ್‌ವೇರ್ ಟ್ರಾನ್ಸಾಕ್ಷನಲ್ ಮೆಮೊರಿ ಅನುಭವ". ಟಿಕೆಟ್ ಖರೀದಿಸಬಹುದು ಅಧಿಕೃತ ವೆಬ್‌ಸೈಟ್‌ನಲ್ಲಿ.

ಮೂಲ: www.habr.com