Systems engineering (asosan database/storage systems) uchun asosiy til sifatida qaysi tilga ko'proq fokus qilishni tavsiya qilasizlar?
C/C++, Rust yoki Go?
C/C++, Rust yoki Go?
👍1👎1
Ba'zi ustozlar yoniga 1 ta savol bilan borib, yangi 2 ta savol bilan qaytasiz. Ular sizga shunchaki javobni emas, balki javobga yo'nalishni ko'rsatadi. Bu yo'lda esa yangi savollarga duch kelasiz. Bu esa original savolga javob topgandan keyin ham yana ko'proq o'rganishga undaydi.
Shunday ustozlar mening qahramonim.
Shunday ustozlar mening qahramonim.
👍77👎1
When parallelism is serialized into a single CPU core, it's called multiprocessing.
When parallelism is serialized into a single process, it's called multithreading.
When parallelism is serialized into a single thread, it's called asynchronous execution.
When parallelism is serialized into a single process, it's called multithreading.
When parallelism is serialized into a single thread, it's called asynchronous execution.
👍44🍾2
Muammolar takrorlanadi
Avvallari 1 ta komputerda 1 ta processgina run bo'la olgan. Keyinroq 1 ta CPU coreda bir nechta "virtual process"(bizga tanish software process)larni qisqa interval bilan navbatma-navbat run qilish orqali CPU coredan effektivroq foydalanish imkoniyati paydo bo'ldi va multiprocessing deb nomlandi.
Ba'zida qisqa vaqt ichida tez-tez yangi process ochib-yopish, bir processdan boshqasiga ma'lumot yuborish kerak bo'ladi. Processlar og'irligi va o'zaro ma'lumot almashish qiyinligi sabab bitta processning o'zida ham bir nechta "tipa process" – thread yaratishga ehtiyoj tug'ildi.
Dizayn jihatdan hammasi yaxshi edi, lekin implementatsiyaga kelganda boshqa bir qancha jiddiy savollar (process forking, signal handling, ...) bilan birga yana bir qiziq savol paydo bo'ldi: threadlarni kernel levelda implement qilish kerakmi yoki user leveldami?
Kernel levelda implement qilish threadga qo'yilgan asosiy talab – yengillik va tezlikni ta'minlab bera olmaydi. User levelda implement qilishda esa scheduling bilan jiddiy muammo chiqadi: agar biror thread I/O call qilsa OS faqat o'sha threadning o'zini emas, butun processni (ya'ni o'sha processdagi hamma threadlarni) bloklaydi. Sababi, kernelda joylashgan scheduler user spacedagi thread nimaligini ham bilmaydi.
Muammoni hal qilish uchun esa user spaceda ishlaydigan va muhimi har bitta threadni alohida schedule qilish imkonini beradigan yechim kerak bo'ldi va qaysidir darajada topildi ham.
***
Qizig'i, xuddi shunga o'xshash jarayon dasturlashning umuman boshqa bir yo'nalishi – network engineeringda ham sodir bo'lgan.
HTTP 1.0 protocolida bir vaqtda faqatgina bitta connection ochish mumkin edi. Bir vaqtda bir nechta resurslarni olishga ehtiyoj tug'ilgani sabab HTTP 1.1 versiyasida bir vaqtda 6 tagacha har biri alohida TCP connection ustiga qurilgan HTTP connection ochish mumkin bo'ldi. Bu yechim ancha omadli chiqqan bo'lsa-da bir qancha sabablar (connectionlarni ochish/yopish og'irligi, asinxron ishlashning imkoni yo'qligi) tufayli yana yangi nimadir o'ylab topish kerak bo'ldi.
HTTP 2.0 bitta TCP connection ustiga ko'plab yengil HTTP connectionlar ochish imkoniyatini taqdim etdi. Endi connectionlar sonini dinamik qilish va asinxron ishlash mumkin bo'ldi. Lekin kutilmaganda bir muammo chiqdi: birorta HTTP connection tarkibidagi birorta paket yetib kelmasa retransmission uchun butun TCP connection (demakki qolgan HTTP connectionlar ham) bloklanadi. Sababi, TCP transport layerda joylashgan va application layerdagi connection nimaligini bilmaydi. Bu muammo HOL Blocking deyiladi.
Bu muammoni hal qilish uchun application leyer va transport layerdagi connectionlar bir-birini "taniydigan" yangi mexanizm – QUIC va HTTP 3 ishlab chiqildi.
@boboshersnotes
Avvallari 1 ta komputerda 1 ta processgina run bo'la olgan. Keyinroq 1 ta CPU coreda bir nechta "virtual process"(bizga tanish software process)larni qisqa interval bilan navbatma-navbat run qilish orqali CPU coredan effektivroq foydalanish imkoniyati paydo bo'ldi va multiprocessing deb nomlandi.
Ba'zida qisqa vaqt ichida tez-tez yangi process ochib-yopish, bir processdan boshqasiga ma'lumot yuborish kerak bo'ladi. Processlar og'irligi va o'zaro ma'lumot almashish qiyinligi sabab bitta processning o'zida ham bir nechta "tipa process" – thread yaratishga ehtiyoj tug'ildi.
Dizayn jihatdan hammasi yaxshi edi, lekin implementatsiyaga kelganda boshqa bir qancha jiddiy savollar (process forking, signal handling, ...) bilan birga yana bir qiziq savol paydo bo'ldi: threadlarni kernel levelda implement qilish kerakmi yoki user leveldami?
Kernel levelda implement qilish threadga qo'yilgan asosiy talab – yengillik va tezlikni ta'minlab bera olmaydi. User levelda implement qilishda esa scheduling bilan jiddiy muammo chiqadi: agar biror thread I/O call qilsa OS faqat o'sha threadning o'zini emas, butun processni (ya'ni o'sha processdagi hamma threadlarni) bloklaydi. Sababi, kernelda joylashgan scheduler user spacedagi thread nimaligini ham bilmaydi.
Muammoni hal qilish uchun esa user spaceda ishlaydigan va muhimi har bitta threadni alohida schedule qilish imkonini beradigan yechim kerak bo'ldi va qaysidir darajada topildi ham.
***
Qizig'i, xuddi shunga o'xshash jarayon dasturlashning umuman boshqa bir yo'nalishi – network engineeringda ham sodir bo'lgan.
HTTP 1.0 protocolida bir vaqtda faqatgina bitta connection ochish mumkin edi. Bir vaqtda bir nechta resurslarni olishga ehtiyoj tug'ilgani sabab HTTP 1.1 versiyasida bir vaqtda 6 tagacha har biri alohida TCP connection ustiga qurilgan HTTP connection ochish mumkin bo'ldi. Bu yechim ancha omadli chiqqan bo'lsa-da bir qancha sabablar (connectionlarni ochish/yopish og'irligi, asinxron ishlashning imkoni yo'qligi) tufayli yana yangi nimadir o'ylab topish kerak bo'ldi.
HTTP 2.0 bitta TCP connection ustiga ko'plab yengil HTTP connectionlar ochish imkoniyatini taqdim etdi. Endi connectionlar sonini dinamik qilish va asinxron ishlash mumkin bo'ldi. Lekin kutilmaganda bir muammo chiqdi: birorta HTTP connection tarkibidagi birorta paket yetib kelmasa retransmission uchun butun TCP connection (demakki qolgan HTTP connectionlar ham) bloklanadi. Sababi, TCP transport layerda joylashgan va application layerdagi connection nimaligini bilmaydi. Bu muammo HOL Blocking deyiladi.
Bu muammoni hal qilish uchun application leyer va transport layerdagi connectionlar bir-birini "taniydigan" yangi mexanizm – QUIC va HTTP 3 ishlab chiqildi.
@boboshersnotes
👍28
Engineering Notes
https://youtu.be/-UrdExQW0cs
Bu yerda berilgan ma'lumotlar ancha yuzaki, lekin agar bu mavzular sizga qiziq bo'lsa eng kamida videoda ishlatilgan terminlardan foydalanib ham ancha ma'lumot izlab topishingiz mumkin.
Engineering Notes
Photo
Rust iloji boricha immutabilityni saqlab qolish uchun ko'p ish qilgan ekan.
Hatto loopni ham statement emas, expression sifatida ishlab chiqqanini ko'rib tilning falsafasiga ancha qiziqib qoldim.
Hatto loopni ham statement emas, expression sifatida ishlab chiqqanini ko'rib tilning falsafasiga ancha qiziqib qoldim.
👍26