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
Forwarded from Nodir's notebook
Hi all. I've recently transitioned from AWS ECS to Infrastructure as Code organization. We own CFN, CDK, SAM, AWS Copilot, but also AppComposer. Basically various ways to define infrastructure. Other IaC tools, including Terraform, Pulumi, Bicep, Serverless and SST, are on my radar as well.
I'd love to hear about your IaC needs, which IaC tool you use, what you like about it and what could be better, how you will choose an IaC tool for your next project. Specifically I am interested in how you 1/ author IaC and 2/ what workflows do you have, for example run my lambda locally. Feel free to leave comments or DM me. Thank you
I'd love to hear about your IaC needs, which IaC tool you use, what you like about it and what could be better, how you will choose an IaC tool for your next project. Specifically I am interested in how you 1/ author IaC and 2/ what workflows do you have, for example run my lambda locally. Feel free to leave comments or DM me. Thank you
👍1
TCP slow start algorithm actually increases the number of packets in each round trip exponentially (if you're not familiar, that means veeeery quickly). Now go to sleep.
😁2
Yegor aka anchagina og'riqli mavzuda lecture series qilayapti. Ko'rib borishni tavsiya qilaman:
https://youtube.com/playlist?list=PLaIsQH4uc08ytf8POIIAkkR4ZsRq8DFiV
https://youtube.com/playlist?list=PLaIsQH4uc08ytf8POIIAkkR4ZsRq8DFiV
👍6
Kanalda AM(A) qilmoqchiman. Dasturlash sohasiga oid savollaringiz bo'lsa commentda qoldirishingiz mumkin. Iloji boricha javob berishga harakat qilaman.
P.S. Anchadan beri uzunroq post yozmaganimga hozir qo'l kelishmayapti. Bu savollar bilan "warm-up" qilib olamiz ))
P.S. Anchadan beri uzunroq post yozmaganimga hozir qo'l kelishmayapti. Bu savollar bilan "warm-up" qilib olamiz ))
Yolg'onlar shahri
O'ylab qarasam, jamiyatda mumkin bo'lgan hamma sinovlarni aldab, aslimizdan ko'ra yaxshiroq ko'rinishga harakat qilish normaga aylanib bo'libdi.
Abituriyent bo'lib fanni o'rganishga emas, qanday qilib testda ko'proq ball yig'ishni o'rganishga harakat qilamiz. Vaholanki, testning maqsadi aslida fanni qanchalik bilishni tekshirish bo'lishi kerak. Universitetga kirgandan keyin nima bo'lishi esa qiziq emas.
Ingliz tilini emas, IELTSda qanday qilib yuqori ball olish "sirlari"ni o'rganamiz. IELTS 7-7.5 ball olib qo'ygan, lekin eplab inglizcha matn o'qiy olmaydiganlar oramizda ancha ko'payib qoldi.
O'qishda butun semester davomida fanni emas, 2 kun oldin imtihondan qanday yaxshiroq ball olishni o'rganamiz. Fan nega o'tilayotgani umuman qiziq emas.
Hayotda yaxshiroq odamga aylanishga emas, uchrashuvda yaxshi odam bo'lib ko'rinishga harakat qilamiz. Turmushdan keyingi hayot ikkinchi darajali.
Ishda kerakli bilimlarni o'rganishga emas, kirish intervyularini qanday qilib "yorib tashlash"ni o'rganamiz. Yana bunda psixologiyadan tortib statistikagacha hamma narsani ishga solamiz. Intervyudan zo'r o'tib keyin ishni eplay olmayotganlar normal qabul qilinishni boshladi (yaqingacha o'zim ham shu toifada edim).
Mening fikrimcha esa imtihonlar "qozonda bori cho'michga chiqadigan" vaqt bo'lishi kerak.
Kimni aldayapmiz? Jamiyatnimi? Yaqinlarimiznimi? Yo o'zimiznimi?
O'ylab ko'ring.
P.S. Non-technical post uchun uzr.
O'ylab qarasam, jamiyatda mumkin bo'lgan hamma sinovlarni aldab, aslimizdan ko'ra yaxshiroq ko'rinishga harakat qilish normaga aylanib bo'libdi.
Abituriyent bo'lib fanni o'rganishga emas, qanday qilib testda ko'proq ball yig'ishni o'rganishga harakat qilamiz. Vaholanki, testning maqsadi aslida fanni qanchalik bilishni tekshirish bo'lishi kerak. Universitetga kirgandan keyin nima bo'lishi esa qiziq emas.
Ingliz tilini emas, IELTSda qanday qilib yuqori ball olish "sirlari"ni o'rganamiz. IELTS 7-7.5 ball olib qo'ygan, lekin eplab inglizcha matn o'qiy olmaydiganlar oramizda ancha ko'payib qoldi.
O'qishda butun semester davomida fanni emas, 2 kun oldin imtihondan qanday yaxshiroq ball olishni o'rganamiz. Fan nega o'tilayotgani umuman qiziq emas.
Hayotda yaxshiroq odamga aylanishga emas, uchrashuvda yaxshi odam bo'lib ko'rinishga harakat qilamiz. Turmushdan keyingi hayot ikkinchi darajali.
Ishda kerakli bilimlarni o'rganishga emas, kirish intervyularini qanday qilib "yorib tashlash"ni o'rganamiz. Yana bunda psixologiyadan tortib statistikagacha hamma narsani ishga solamiz. Intervyudan zo'r o'tib keyin ishni eplay olmayotganlar normal qabul qilinishni boshladi (yaqingacha o'zim ham shu toifada edim).
Mening fikrimcha esa imtihonlar "qozonda bori cho'michga chiqadigan" vaqt bo'lishi kerak.
Kimni aldayapmiz? Jamiyatnimi? Yaqinlarimiznimi? Yo o'zimiznimi?
O'ylab ko'ring.
P.S. Non-technical post uchun uzr.
👍68😢2