🔵 عنوان مقاله
Starving, Sleeping, and Yielding: Understanding Go's Scheduler
🟢 خلاصه مقاله:
** این مقاله توضیح می‌دهد که چرا درک رفتار همزمان در Go به شناخت زمان‌بند آن بستگی دارد. زمان‌بند با مدل G‑M‑P، goroutineها را روی نخ‌های سیستم‌عامل اجرا می‌کند، آن‌ها را هنگام بلاک‌شدن پارک می‌کند و با netpoller برای I/O هماهنگ می‌شود. سه وضعیت کلیدی بررسی می‌شود: Starvation وقتی رخ می‌دهد که goroutineهای آماده اجرا به‌دلیل لوپ‌های سنگین CPU، الگوهای ناعادلانه در select، یا قفل‌ها و syscall/cgo طولانی به CPU دسترسی پیدا نمی‌کنند؛ Sleeping با time.Sleep برای توقف کنترل‌شده مفید است اما می‌تواند تأخیر بسازد؛ و Yielding با runtime.Gosched امکان می‌دهد در حلقه‌های CPU‑محور به دیگر goroutineها نوبت بدهیم. از Go 1.14 به بعد، preemption غیرهمکارانه کمک کرده، اما حلقه‌های بدون نقطه توقف هنوز مشکل‌سازند. راهکارها شامل شکستن کارهای سنگین به بخش‌های کوچک، پرهیز از busy‑wait، استفاده از context و timeout، طراحی منصفانه channel/select، کوچک نگه‌داشتن بخش‌های بحرانی و تنظیم GOMAXPROCS است. برای عیب‌یابی نیز از go tool trace، runtime/trace، pprof و GODEBUG=schedtrace استفاده کنید و فقط در صورت نیاز، sleep یا yield موضعی و مستند به کار ببرید.
#Go #Golang #Concurrency #Scheduler #Goroutines #Performance #Parallelism #Systems
🟣لینک مقاله:
https://golangweekly.com/link/175057/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
Starving, Sleeping, and Yielding: Understanding Go's Scheduler
🟢 خلاصه مقاله:
** این مقاله توضیح می‌دهد که چرا درک رفتار همزمان در Go به شناخت زمان‌بند آن بستگی دارد. زمان‌بند با مدل G‑M‑P، goroutineها را روی نخ‌های سیستم‌عامل اجرا می‌کند، آن‌ها را هنگام بلاک‌شدن پارک می‌کند و با netpoller برای I/O هماهنگ می‌شود. سه وضعیت کلیدی بررسی می‌شود: Starvation وقتی رخ می‌دهد که goroutineهای آماده اجرا به‌دلیل لوپ‌های سنگین CPU، الگوهای ناعادلانه در select، یا قفل‌ها و syscall/cgo طولانی به CPU دسترسی پیدا نمی‌کنند؛ Sleeping با time.Sleep برای توقف کنترل‌شده مفید است اما می‌تواند تأخیر بسازد؛ و Yielding با runtime.Gosched امکان می‌دهد در حلقه‌های CPU‑محور به دیگر goroutineها نوبت بدهیم. از Go 1.14 به بعد، preemption غیرهمکارانه کمک کرده، اما حلقه‌های بدون نقطه توقف هنوز مشکل‌سازند. راهکارها شامل شکستن کارهای سنگین به بخش‌های کوچک، پرهیز از busy‑wait، استفاده از context و timeout، طراحی منصفانه channel/select، کوچک نگه‌داشتن بخش‌های بحرانی و تنظیم GOMAXPROCS است. برای عیب‌یابی نیز از go tool trace، runtime/trace، pprof و GODEBUG=schedtrace استفاده کنید و فقط در صورت نیاز، sleep یا yield موضعی و مستند به کار ببرید.
#Go #Golang #Concurrency #Scheduler #Goroutines #Performance #Parallelism #Systems
🟣لینک مقاله:
https://golangweekly.com/link/175057/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
Bitfield Consulting
Starving, sleeping, and yielding: understanding Go's scheduler — Bitfield Consulting
Writing concurrent programs is easy, but understanding why they don’t work is much harder. In our continuing tutorial, we’ll learn about when and why goroutines starve, sleep, or yield.
❤1
🔵 عنوان مقاله
Register Allocation in the Go Compiler
🟢 خلاصه مقاله:
** این یادداشت دو موضوع فنی اما اثرگذار بر کارایی در Go را کنار هم می‌گذارد: نحوه تخصیص ثبات در کامپایلر و این واقعیت که «دمِ Sliceها برای همیشه رشد نمی‌کند». بخش نخست با الهام از تجربه‌های Vladimir Makarov در دنیای تخصیص ثبات توضیح می‌دهد که پشت‌صحنه‌ی SSA در کامپایلر Go چگونه محدوده‌های حیات متغیرها را روی تعداد کمی ثبات سخت‌افزاری نگاشت می‌کند، φها را حل و حرکت‌ها را ادغام می‌کند و در صورت نیاز سرریز به پشته انجام می‌دهد. چالش اصلی، حفظ کیفیت کد (کاهش حرکت‌ها و سرریزها) در کنار سرعت بالای کامپایل است؛ و ایده‌هایی مانند ترکیب رویکردهای linear-scan و coloring، مدیریت دقیق ثبات‌های caller/callee-saved، سرریز در مسیرهای کم‌احتمال و rematerialization انتخابی به ایجاد این توازن کمک می‌کنند.
بخش دوم، با تکیه بر نوشته‌ی Ted Unangst، یادآور می‌شود که Slice در Go تنها وصله‌ای روی یک آرایه مشترک است: append می‌تواند باعث تخصیص دوباره و کپی شود، رشد ظرفیت با بزرگ‌تر شدن Slice کند می‌شود، و با sub-slice ممکن است حافظه‌ی «سرِ» حذف‌شده همچنان نگه داشته شود. «دمِ» Slice بدون ظرفیت کافی گسترش نمی‌یابد و برای رها شدن حافظه‌ی قدیمی باید گاهی به یک آرایه‌ی تازه کپی کنید. راهکارها شامل استفاده از make با ظرفیت مناسب، پرهیز از نگه‌داشتن referenceهای ناخواسته به آرایه‌ی بزرگ و کپی آگاهانه برای آزادسازی حافظه است.
جمع‌بندی: همان‌طور که انتخاب‌های تخصیص ثبات روی تعداد دستورها و سرریز اثر می‌گذارد، الگوهای کار با Slice نیز روی مصرف حافظه و فشار GC اثر دارند. درک این جزئیات به کدی چابک‌تر، تأخیر پایدارتر و رفتار قابل پیش‌بینی‌تر در سرویس‌های Go منجر می‌شود.
#Go #Golang #Compiler #RegisterAllocation #Performance #MemoryManagement #Slices #SystemsProgramming
🟣لینک مقاله:
https://golangweekly.com/link/175064/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
Register Allocation in the Go Compiler
🟢 خلاصه مقاله:
** این یادداشت دو موضوع فنی اما اثرگذار بر کارایی در Go را کنار هم می‌گذارد: نحوه تخصیص ثبات در کامپایلر و این واقعیت که «دمِ Sliceها برای همیشه رشد نمی‌کند». بخش نخست با الهام از تجربه‌های Vladimir Makarov در دنیای تخصیص ثبات توضیح می‌دهد که پشت‌صحنه‌ی SSA در کامپایلر Go چگونه محدوده‌های حیات متغیرها را روی تعداد کمی ثبات سخت‌افزاری نگاشت می‌کند، φها را حل و حرکت‌ها را ادغام می‌کند و در صورت نیاز سرریز به پشته انجام می‌دهد. چالش اصلی، حفظ کیفیت کد (کاهش حرکت‌ها و سرریزها) در کنار سرعت بالای کامپایل است؛ و ایده‌هایی مانند ترکیب رویکردهای linear-scan و coloring، مدیریت دقیق ثبات‌های caller/callee-saved، سرریز در مسیرهای کم‌احتمال و rematerialization انتخابی به ایجاد این توازن کمک می‌کنند.
بخش دوم، با تکیه بر نوشته‌ی Ted Unangst، یادآور می‌شود که Slice در Go تنها وصله‌ای روی یک آرایه مشترک است: append می‌تواند باعث تخصیص دوباره و کپی شود، رشد ظرفیت با بزرگ‌تر شدن Slice کند می‌شود، و با sub-slice ممکن است حافظه‌ی «سرِ» حذف‌شده همچنان نگه داشته شود. «دمِ» Slice بدون ظرفیت کافی گسترش نمی‌یابد و برای رها شدن حافظه‌ی قدیمی باید گاهی به یک آرایه‌ی تازه کپی کنید. راهکارها شامل استفاده از make با ظرفیت مناسب، پرهیز از نگه‌داشتن referenceهای ناخواسته به آرایه‌ی بزرگ و کپی آگاهانه برای آزادسازی حافظه است.
جمع‌بندی: همان‌طور که انتخاب‌های تخصیص ثبات روی تعداد دستورها و سرریز اثر می‌گذارد، الگوهای کار با Slice نیز روی مصرف حافظه و فشار GC اثر دارند. درک این جزئیات به کدی چابک‌تر، تأخیر پایدارتر و رفتار قابل پیش‌بینی‌تر در سرویس‌های Go منجر می‌شود.
#Go #Golang #Compiler #RegisterAllocation #Performance #MemoryManagement #Slices #SystemsProgramming
🟣لینک مقاله:
https://golangweekly.com/link/175064/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
Vladimir Makarov
Register allocation in the Go compiler
As a maintainer of the GCC register allocator (RA), I naturally have a keen interest in the register allocators used in various industrial compilers. For some compilers, like LLVM and Cranelift, there is sufficient documentation, including papers and presentations…
❤1🎉1🍾1
🔵 عنوان مقاله
Building a Coding Agent in Go from Scratch
🟢 خلاصه مقاله:
این مجموعه سه مطلب عملی برای توسعه‌دهندگان Go را کنار هم می‌گذارد: ساخت یک coding agent از صفر در Go، استفاده از Timing Wheels برای انقضای کارآمد ۱۰ میلیون کلید بدون اسکن‌های O(n)، و مروری دقیق بر sync شامل Mutex، RWMutex، WaitGroup، Once، Cond و Pool. بخش agent بر معماری ماژولار، هماهنگی goroutine و channel، sandbox امن و حلقه بازخورد برای اجرای کد و بهبود تدریجی تأکید دارد. نوشته Bill Kennedy نشان می‌دهد چگونه با سطل‌بندی زمان‌سنج‌ها و حرکت چرخ، سربار و نوسان تأخیر کاهش می‌یابد و حتی در مقیاس بزرگ پایدار می‌ماند. در نهایت، مرور sync توصیه‌های عملی برای انتخاب درست بین primitives و channel، کاهش contention، و ارزیابی با benchmark، pprof و race detector ارائه می‌کند تا سامانه‌های Go هم هوشمند و هم سریع باشند.
#Go #Golang #Concurrency #TimingWheels #sync #SystemsProgramming #GoInternals #Performance
🟣لینک مقاله:
https://golangweekly.com/link/175365/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
Building a Coding Agent in Go from Scratch
🟢 خلاصه مقاله:
این مجموعه سه مطلب عملی برای توسعه‌دهندگان Go را کنار هم می‌گذارد: ساخت یک coding agent از صفر در Go، استفاده از Timing Wheels برای انقضای کارآمد ۱۰ میلیون کلید بدون اسکن‌های O(n)، و مروری دقیق بر sync شامل Mutex، RWMutex، WaitGroup، Once، Cond و Pool. بخش agent بر معماری ماژولار، هماهنگی goroutine و channel، sandbox امن و حلقه بازخورد برای اجرای کد و بهبود تدریجی تأکید دارد. نوشته Bill Kennedy نشان می‌دهد چگونه با سطل‌بندی زمان‌سنج‌ها و حرکت چرخ، سربار و نوسان تأخیر کاهش می‌یابد و حتی در مقیاس بزرگ پایدار می‌ماند. در نهایت، مرور sync توصیه‌های عملی برای انتخاب درست بین primitives و channel، کاهش contention، و ارزیابی با benchmark، pprof و race detector ارائه می‌کند تا سامانه‌های Go هم هوشمند و هم سریع باشند.
#Go #Golang #Concurrency #TimingWheels #sync #SystemsProgramming #GoInternals #Performance
🟣لینک مقاله:
https://golangweekly.com/link/175365/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
YouTube
Building a coding agent from scratch - Bill Kennedy
In this talk, Bill will share how AI agents fundamental work and interact with LLMs to perform basic tasks like listing, reading, and editing files. During the talk, Bill will live code an agent and explain all the parts of the code needed to make this work.…
❤3👍1
🔵 عنوان مقاله
CPU Cache-Friendly Data Structures in Go: 10x Speed with Same Algorithm
🟢 خلاصه مقاله:
** این مقاله نشان می‌دهد که در Go می‌توان بدون تغییر الگوریتم و فقط با بهینه‌سازی نحوهٔ دسترسی به حافظه، به بهبودهایی تا ۱۰ برابر رسید. ایدهٔ اصلی این است که با بهره‌گیری از محلیّت در CPU و نگه داشتن داده‌های «داغ» در حافظهٔ پیوسته، تعداد cache miss به شدت کم می‌شود. راهکارهای کلیدی شامل استفاده از sliceهای پیوسته به‌جای ساختارهای پر از pointer، فشرده‌سازی و چیدمان درست فیلدهای struct، انتخاب آگاهانه بین AoS و SoA، کاهش تخصیص‌ها و استفاده از sync.Pool برای بازاستفادهٔ حافظه، و اجتناب از false sharing در برنامه‌های همزمان است. اندازه‌گیری با ابزارهای benchmark و pprof کمک می‌کند ببینیم گلوگاه واقعاً از کجاست. نتیجهٔ عملی طبق تجربهٔ Serge Skoredin: با حفظ همان منطق، تنها با طراحی cache‑friendly در Go می‌توان جهش‌های بزرگ کارایی به‌دست آورد.
#Go #Golang #CPUCache #Performance #DataStructures #SystemsProgramming #Optimization #LowLatency
🟣لینک مقاله:
https://golangweekly.com/link/175636/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
CPU Cache-Friendly Data Structures in Go: 10x Speed with Same Algorithm
🟢 خلاصه مقاله:
** این مقاله نشان می‌دهد که در Go می‌توان بدون تغییر الگوریتم و فقط با بهینه‌سازی نحوهٔ دسترسی به حافظه، به بهبودهایی تا ۱۰ برابر رسید. ایدهٔ اصلی این است که با بهره‌گیری از محلیّت در CPU و نگه داشتن داده‌های «داغ» در حافظهٔ پیوسته، تعداد cache miss به شدت کم می‌شود. راهکارهای کلیدی شامل استفاده از sliceهای پیوسته به‌جای ساختارهای پر از pointer، فشرده‌سازی و چیدمان درست فیلدهای struct، انتخاب آگاهانه بین AoS و SoA، کاهش تخصیص‌ها و استفاده از sync.Pool برای بازاستفادهٔ حافظه، و اجتناب از false sharing در برنامه‌های همزمان است. اندازه‌گیری با ابزارهای benchmark و pprof کمک می‌کند ببینیم گلوگاه واقعاً از کجاست. نتیجهٔ عملی طبق تجربهٔ Serge Skoredin: با حفظ همان منطق، تنها با طراحی cache‑friendly در Go می‌توان جهش‌های بزرگ کارایی به‌دست آورد.
#Go #Golang #CPUCache #Performance #DataStructures #SystemsProgramming #Optimization #LowLatency
🟣لینک مقاله:
https://golangweekly.com/link/175636/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
skoredin.pro
CPU Cache-Friendly Data Structures in Go: 10x Speed
False sharing killed our performance. Data-oriented design saved it.
❤1🔥1
🔵 عنوان مقاله
How Slow is Channel-Based Iteration?
🟢 خلاصه مقاله:
این مقاله پرسش «تکرار مبتنی بر channel در Go چقدر کند است؟» را با یک مثال عملی بررسی می‌کند. تیم Dolt سه الگو را مقایسه کرده است: دو رویکرد مبتنی بر channel و یک روش iterator کشیدنی با iter.Pull. نتیجه کلی این است که هرچند channelها برای همزمانی، مدیریت فشار برگشتی و جداسازی تولیدکننده/مصرف‌کننده عالی‌اند، اما در حلقه‌های محاسباتیِ حساس به کارایی، سربار همگام‌سازی، زمان‌بندی goroutine و تخصیص‌ها محسوس می‌شود. در مقابل، iter.Pull (و حلقه‌های ساده روی داده‌های خطی) معمولاً سبک‌تر و بهینه‌ترند. توصیه نهایی: وقتی به همزمانی واقعی نیاز دارید از channel استفاده کنید؛ برای مسیرهای داغ که فقط پیمایش می‌خواهند، سراغ iterator کشیدنی یا حلقه‌های ساده بروید.
#Go #Golang #Channels #Iteration #Performance #Benchmarking #Concurrency #Dolt
🟣لینک مقاله:
https://golangweekly.com/link/175626/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
How Slow is Channel-Based Iteration?
🟢 خلاصه مقاله:
این مقاله پرسش «تکرار مبتنی بر channel در Go چقدر کند است؟» را با یک مثال عملی بررسی می‌کند. تیم Dolt سه الگو را مقایسه کرده است: دو رویکرد مبتنی بر channel و یک روش iterator کشیدنی با iter.Pull. نتیجه کلی این است که هرچند channelها برای همزمانی، مدیریت فشار برگشتی و جداسازی تولیدکننده/مصرف‌کننده عالی‌اند، اما در حلقه‌های محاسباتیِ حساس به کارایی، سربار همگام‌سازی، زمان‌بندی goroutine و تخصیص‌ها محسوس می‌شود. در مقابل، iter.Pull (و حلقه‌های ساده روی داده‌های خطی) معمولاً سبک‌تر و بهینه‌ترند. توصیه نهایی: وقتی به همزمانی واقعی نیاز دارید از channel استفاده کنید؛ برای مسیرهای داغ که فقط پیمایش می‌خواهند، سراغ iterator کشیدنی یا حلقه‌های ساده بروید.
#Go #Golang #Channels #Iteration #Performance #Benchmarking #Concurrency #Dolt
🟣لینک مقاله:
https://golangweekly.com/link/175626/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
Dolthub
How slow is channel-based iteration?
We benchmarked channel-based iterators v. those provided by the iter package and share the results.
❤1👍1🔥1
🔵 عنوان مقاله
The Speed of Random Number Generators
🟢 خلاصه مقاله:
در این مقاله، Daniel سرعت گزینه‌های رایج تولید اعداد تصادفی در Go را مقایسه می‌کند. او نشان می‌دهد که math/rand/v2 با الگوریتم PCG در سناریوهای غیرامنیتی سریع‌ترین گزینه است و از نسخه قدیمی‌تر math/rand عملکرد بهتری دارد، در حالی که crypto/rand به‌دلیل تمرکز بر امنیت به‌طور قابل‌توجهی کندتر است. جمع‌بندی عملی: برای کارهای غیررمزنگاری که سرعت و قابلیت بازتولید مهم‌اند، از math/rand/v2 (PCG) استفاده کنید؛ اما برای مقاصد امنیتی، با وجود هزینه‌ی عملکرد، crypto/rand انتخاب درست است.
#Go #Golang #RandomNumberGeneration #Performance #Benchmark #PCG #mathrand #cryptorand
🟣لینک مقاله:
https://golangweekly.com/link/175977/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
The Speed of Random Number Generators
🟢 خلاصه مقاله:
در این مقاله، Daniel سرعت گزینه‌های رایج تولید اعداد تصادفی در Go را مقایسه می‌کند. او نشان می‌دهد که math/rand/v2 با الگوریتم PCG در سناریوهای غیرامنیتی سریع‌ترین گزینه است و از نسخه قدیمی‌تر math/rand عملکرد بهتری دارد، در حالی که crypto/rand به‌دلیل تمرکز بر امنیت به‌طور قابل‌توجهی کندتر است. جمع‌بندی عملی: برای کارهای غیررمزنگاری که سرعت و قابلیت بازتولید مهم‌اند، از math/rand/v2 (PCG) استفاده کنید؛ اما برای مقاصد امنیتی، با وجود هزینه‌ی عملکرد، crypto/rand انتخاب درست است.
#Go #Golang #RandomNumberGeneration #Performance #Benchmark #PCG #mathrand #cryptorand
🟣لینک مقاله:
https://golangweekly.com/link/175977/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
Daniel Lemire's blog
Speed of random number generators in Go
We often need to generate random numbers in software. We need them for games, simulations, testing, and so forth. In many of these cases, we would like to use the fastest generator we can find, as long as it is reasonably random-looking. In some instances…
👍1
Forwarded from Linux Labdon
🔵 عنوان مقاله
Ubuntu 25.10's Rust Coreutils Transition Has Uncovered Performance Shortcomings
🟢 خلاصه مقاله:
Ubuntu 25.10 در حال جایگزینی Rustا Coreutils به‌جای GNU Coreutils است. آزمایش‌های اولیه نشان می‌دهد نسخه Rust در برخی سناریوها کندتر از پیاده‌سازی C در GNU Coreutils عمل می‌کند. با این حال هنوز تا انتشار پایدار چند هفته باقی مانده و توسعه‌دهندگان upstream در حال بهینه‌سازی و رفع شکاف‌های کارایی هستند تا ضمن بهره‌مندی از مزایای ایمنی Rust، به کارایی هم‌تراز برسند.
#Ubuntu2510 #Ubuntu #RustCoreutils #GNUCoreutils #Linux #Performance #OpenSource #RustLang
🟣لینک مقاله:
https://www.phoronix.com/news/Ubuntu-Rust-Coreutils-Perf
➖➖➖➖➖➖➖➖
👑 @Linux_Labdon
Ubuntu 25.10's Rust Coreutils Transition Has Uncovered Performance Shortcomings
🟢 خلاصه مقاله:
Ubuntu 25.10 در حال جایگزینی Rustا Coreutils به‌جای GNU Coreutils است. آزمایش‌های اولیه نشان می‌دهد نسخه Rust در برخی سناریوها کندتر از پیاده‌سازی C در GNU Coreutils عمل می‌کند. با این حال هنوز تا انتشار پایدار چند هفته باقی مانده و توسعه‌دهندگان upstream در حال بهینه‌سازی و رفع شکاف‌های کارایی هستند تا ضمن بهره‌مندی از مزایای ایمنی Rust، به کارایی هم‌تراز برسند.
#Ubuntu2510 #Ubuntu #RustCoreutils #GNUCoreutils #Linux #Performance #OpenSource #RustLang
🟣لینک مقاله:
https://www.phoronix.com/news/Ubuntu-Rust-Coreutils-Perf
➖➖➖➖➖➖➖➖
👑 @Linux_Labdon
Phoronix
Ubuntu 25.10's Rust Coreutils Transition Has Uncovered Performance Shortcomings
Ubuntu 25.10's transition to using Rust Coreutils in place of GNU Coreutils has uncovered a few performance issues so far with the Rust version being slower than the C-based GNU Coreutils
❤1
🔵 عنوان مقاله
From 19 Hours to Under a Second: Building a Blazing-Fast TCP Scanner in Go
🟢 خلاصه مقاله:
با یک روایت عملی، مقاله توضیح می‌دهد چگونه یک اسکنر ساده TCP که ۱۹ ساعت طول می‌کشید، با بازطراحی در Go به ابزاری «زیر یک ثانیه» تبدیل شد. ابتدا نشان می‌دهد چرا اسکن مبتنی‌بر net.Dial حتی با همزمانی محدود گرفتار زمان‌های انتظار، محدودیت FD و سربار syscall می‌شود. سپس با گذار از اتصال‌های کامل به اسکن SYN، ساخت بسته‌ها، فیلترکردن پاسخ‌ها با BPF، و نگه‌داری وضعیت سبک‌وزن، سربار کرنل و زمان‌بندی به شدت کاهش می‌یابد. بهینه‌سازی‌هایی مانند batch کردن ارسال/دریافت، پیش‌اختصاص بافرها، کاهش تخصیص‌ها با sync.Pool، و حلقه‌های رویدادی کارا (epoll/kqueue) همراه با تنظیمات سیستم (ulimit، بافرهای سوکتی و sysctl) throughput را به حداکثر می‌رساند. با پروفایل‌کردن مداوم (pprof) و راستی‌آزمایی با ابزاری مانند Nmap، هم دقت و هم کارایی تضمین می‌شود. خروجی نهایی: الگوی عملی برای ساخت ابزارهای پرسرعت شبکه در Go—ترکیبی از انتخاب مدل درست (SYN به‌جای connect)، کاهش سربارها، batch کردن، اندازه‌گیری پیوسته، و پایبندی به اصول ایمنی و اخلاق اسکن. این مطلب در Golang Weekly برجسته شده است.
#Go #Golang #TCP #PortScanning #Networking #Performance #Concurrency #SystemsProgramming
🟣لینک مقاله:
https://golangweekly.com/link/176335/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
From 19 Hours to Under a Second: Building a Blazing-Fast TCP Scanner in Go
🟢 خلاصه مقاله:
با یک روایت عملی، مقاله توضیح می‌دهد چگونه یک اسکنر ساده TCP که ۱۹ ساعت طول می‌کشید، با بازطراحی در Go به ابزاری «زیر یک ثانیه» تبدیل شد. ابتدا نشان می‌دهد چرا اسکن مبتنی‌بر net.Dial حتی با همزمانی محدود گرفتار زمان‌های انتظار، محدودیت FD و سربار syscall می‌شود. سپس با گذار از اتصال‌های کامل به اسکن SYN، ساخت بسته‌ها، فیلترکردن پاسخ‌ها با BPF، و نگه‌داری وضعیت سبک‌وزن، سربار کرنل و زمان‌بندی به شدت کاهش می‌یابد. بهینه‌سازی‌هایی مانند batch کردن ارسال/دریافت، پیش‌اختصاص بافرها، کاهش تخصیص‌ها با sync.Pool، و حلقه‌های رویدادی کارا (epoll/kqueue) همراه با تنظیمات سیستم (ulimit، بافرهای سوکتی و sysctl) throughput را به حداکثر می‌رساند. با پروفایل‌کردن مداوم (pprof) و راستی‌آزمایی با ابزاری مانند Nmap، هم دقت و هم کارایی تضمین می‌شود. خروجی نهایی: الگوی عملی برای ساخت ابزارهای پرسرعت شبکه در Go—ترکیبی از انتخاب مدل درست (SYN به‌جای connect)، کاهش سربارها، batch کردن، اندازه‌گیری پیوسته، و پایبندی به اصول ایمنی و اخلاق اسکن. این مطلب در Golang Weekly برجسته شده است.
#Go #Golang #TCP #PortScanning #Networking #Performance #Concurrency #SystemsProgramming
🟣لینک مقاله:
https://golangweekly.com/link/176335/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
docs.serviceradar.cloud
From 19 Hours to Under a Second: Building a Blazing-Fast TCP Scanner in Go | ServiceRadar
How ServiceRadar turned a 19-hour TCP discovery job into a sub-second SYN scan by leaning on raw sockets, BPF, and Go assembly.
🔵 عنوان مقاله
Go's Green Tea Garbage Collector
🟢 خلاصه مقاله:
** در Go 1.25 یک garbage collector آزمایشی به نام Green Tea معرفی شده که با هدف کاهش تأخیر و نوسان، بهبود کارایی و مصرف حافظه، و مقیاس‌پذیری بهتر ارائه می‌شود. این قابلیت فعلاً به‌صورت opt-in و از طریق فلگ‌های مستند در release notes فعال می‌شود و پیش‌فرض نیست. نتایج اولیه بسته به بار کاری می‌تواند متفاوت باشد؛ در صورت پسرفت می‌توان به GC فعلی بازگشت. تیم Go با تکیه بر بازخورد و سنجش میدانی، در نسخه‌های بعدی آن را بهبود می‌دهد و در صورت موفقیت، می‌تواند بر راهبرد آینده GC در Go اثر بگذارد.
#Go #Golang #GreenTea #GarbageCollection #Go125 #MemoryManagement #Performance #Runtime
🟣لینک مقاله:
https://golangweekly.com/link/176318/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
Go's Green Tea Garbage Collector
🟢 خلاصه مقاله:
** در Go 1.25 یک garbage collector آزمایشی به نام Green Tea معرفی شده که با هدف کاهش تأخیر و نوسان، بهبود کارایی و مصرف حافظه، و مقیاس‌پذیری بهتر ارائه می‌شود. این قابلیت فعلاً به‌صورت opt-in و از طریق فلگ‌های مستند در release notes فعال می‌شود و پیش‌فرض نیست. نتایج اولیه بسته به بار کاری می‌تواند متفاوت باشد؛ در صورت پسرفت می‌توان به GC فعلی بازگشت. تیم Go با تکیه بر بازخورد و سنجش میدانی، در نسخه‌های بعدی آن را بهبود می‌دهد و در صورت موفقیت، می‌تواند بر راهبرد آینده GC در Go اثر بگذارد.
#Go #Golang #GreenTea #GarbageCollection #Go125 #MemoryManagement #Performance #Runtime
🟣لینک مقاله:
https://golangweekly.com/link/176318/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
go.dev
The Green Tea Garbage Collector - The Go Programming Language
Go 1.25 includes a new experimental garbage collector, Green Tea.
🔵 عنوان مقاله
How We Saved 70% CPU and 60% Memory in Refinery’s Go Code
🟢 خلاصه مقاله:
**تیم Refinery روی یک سرویس مهم مبتنی بر Go با مصرف بالای CPU و Memory کار می‌کرد و با پروفایلینگ دقیق (pprof، tracing و بنچمارک‌های انتهابه‌انتها) گلوگاه‌های واقعی را پیدا کرد. بیشترین صرفه‌جویی با حذف کارهای غیرضروری به‌دست آمد: حذف پردازش‌ها و serialization تکراری، دوری از reflection در مسیرهای داغ، جایگزینی JSON در hot path با دسترسی مستقیم/کدگذاری ساده، پیش‌اختصاص slices/maps و بازاستفاده از بافرها برای کاهش allocation و فشار GC. در هم‌روندی، به‌جای goroutineهای بدون‌مهار، از worker poolهای محدود و backpressure استفاده شد، کارها batch و داده‌ها تا حد امکان stream شدند تا قفل‌زنی و جابه‌جایی زمینه کاهش یابد. همچنین چند حلقه O(n^2) با ایندکس‌گذاری مبتنی بر map/set جایگزین شد، نتایج گران با cache کردن تکرار نشد و الگوهای I/O با خواندن/نوشتن تجمیعی بهینه شدند. در نهایت با تکیه بر allocationهای روی stack، استفاده از sync.Pool و روش‌های zero-copy، نیاز به GC پایین آمد. نتیجه: حدود 70% کاهش مصرف CPU و 60% کاهش Memory همراه با بهبود تاخیرهای p95/p99. درس کلیدی: بهینه‌سازی اغلب یعنی کمتر کار کردن—اندازه‌گیری کن، کار زائد را حذف کن و ساده‌سازی را تکرار کن.
#Go #Golang #Performance #Profiling #CPU #Memory #Optimization #pprof
🟣لینک مقاله:
https://golangweekly.com/link/176624/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
How We Saved 70% CPU and 60% Memory in Refinery’s Go Code
🟢 خلاصه مقاله:
**تیم Refinery روی یک سرویس مهم مبتنی بر Go با مصرف بالای CPU و Memory کار می‌کرد و با پروفایلینگ دقیق (pprof، tracing و بنچمارک‌های انتهابه‌انتها) گلوگاه‌های واقعی را پیدا کرد. بیشترین صرفه‌جویی با حذف کارهای غیرضروری به‌دست آمد: حذف پردازش‌ها و serialization تکراری، دوری از reflection در مسیرهای داغ، جایگزینی JSON در hot path با دسترسی مستقیم/کدگذاری ساده، پیش‌اختصاص slices/maps و بازاستفاده از بافرها برای کاهش allocation و فشار GC. در هم‌روندی، به‌جای goroutineهای بدون‌مهار، از worker poolهای محدود و backpressure استفاده شد، کارها batch و داده‌ها تا حد امکان stream شدند تا قفل‌زنی و جابه‌جایی زمینه کاهش یابد. همچنین چند حلقه O(n^2) با ایندکس‌گذاری مبتنی بر map/set جایگزین شد، نتایج گران با cache کردن تکرار نشد و الگوهای I/O با خواندن/نوشتن تجمیعی بهینه شدند. در نهایت با تکیه بر allocationهای روی stack، استفاده از sync.Pool و روش‌های zero-copy، نیاز به GC پایین آمد. نتیجه: حدود 70% کاهش مصرف CPU و 60% کاهش Memory همراه با بهبود تاخیرهای p95/p99. درس کلیدی: بهینه‌سازی اغلب یعنی کمتر کار کردن—اندازه‌گیری کن، کار زائد را حذف کن و ساده‌سازی را تکرار کن.
#Go #Golang #Performance #Profiling #CPU #Memory #Optimization #pprof
🟣لینک مقاله:
https://golangweekly.com/link/176624/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
Honeycomb
How We Saved 70% of CPU and 60% of Memory in Refinery’s Go Code, No Rust Required.
We've just released Refinery 3. 0 , a performance-focused update which significantly improves Refinery's CPU and memory efficiency.
👍2❤1
🔵 عنوان مقاله
A look into how JavaScript source maps work
🟢 خلاصه مقاله:
خلاصه‌ای از ساخت‌وکار source map در JavaScript: کدی که در مرورگر اجرا می‌شود معمولاً پس از transpile، bundle و minify با کد اصلی تفاوت دارد. source map پلی است میان این دو تا بتوانید در DevTools مثل کد اصلی breakpoint بگذارید و خطاها را بخوانید. یک source map فایل JSONی است با فیلدهایی مثل version، file، sources، names، sourcesContent و یک رشته mappings که با Base64 VLQ فشرده شده و با بخش‌های دلتایی موقعیت‌های کد تولید‌شده را به سطر/ستون‌های فایل‌های اصلی (و در صورت وجود، نام‌ها) نگاشت می‌کند. ابزارهایی مثل TypeScript و Babel نگاشت را هنگام تبدیل می‌سازند، Webpack/Rollup/esbuild آن‌ها را ترکیب می‌کنند و Terser در مرحله minify این زنجیره را حفظ می‌کند؛ این همان chain شدن source map است. مرورگر از طریق دستور sourceMappingURL (فایل خارجی یا data URI) map را می‌خواند و با رعایت CORS آن را decode کرده و در DevTools نمایش و دیباگ را بر اساس کد اصلی ممکن می‌سازد؛ همچنین پلتفرم‌هایی مثل Sentry با دریافت map می‌توانند stack traceهای production را de-minify کنند. در عمل، به خاطر اندازه و حریم خصوصی، بهتر است در production از الگوهایی چون hidden-source-map یا nosources-source-map، میزبانی امن، و فشرده‌سازی/کش استفاده کنید. محدودیت‌ها شامل دقت ستونی ناقص در برخی تبدیل‌ها، کدهای dynamic/eval، ناسازگاری مسیرها و سوگیری‌های نگاشت است. بهترین رویه‌ها: فعال‌سازی map در تمام مراحل build، اعتبارسنجی در DevTools، اطمینان از CORS مناسب برای ابزار خطا، کنترل نسخه ابزارها و آزمون remap شدن خطاها در CI.
#JavaScript #SourceMaps #WebDev #Debugging #DevTools #Bundlers #Performance
🟣لینک مقاله:
https://golangweekly.com/link/176649/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
A look into how JavaScript source maps work
🟢 خلاصه مقاله:
خلاصه‌ای از ساخت‌وکار source map در JavaScript: کدی که در مرورگر اجرا می‌شود معمولاً پس از transpile، bundle و minify با کد اصلی تفاوت دارد. source map پلی است میان این دو تا بتوانید در DevTools مثل کد اصلی breakpoint بگذارید و خطاها را بخوانید. یک source map فایل JSONی است با فیلدهایی مثل version، file، sources، names، sourcesContent و یک رشته mappings که با Base64 VLQ فشرده شده و با بخش‌های دلتایی موقعیت‌های کد تولید‌شده را به سطر/ستون‌های فایل‌های اصلی (و در صورت وجود، نام‌ها) نگاشت می‌کند. ابزارهایی مثل TypeScript و Babel نگاشت را هنگام تبدیل می‌سازند، Webpack/Rollup/esbuild آن‌ها را ترکیب می‌کنند و Terser در مرحله minify این زنجیره را حفظ می‌کند؛ این همان chain شدن source map است. مرورگر از طریق دستور sourceMappingURL (فایل خارجی یا data URI) map را می‌خواند و با رعایت CORS آن را decode کرده و در DevTools نمایش و دیباگ را بر اساس کد اصلی ممکن می‌سازد؛ همچنین پلتفرم‌هایی مثل Sentry با دریافت map می‌توانند stack traceهای production را de-minify کنند. در عمل، به خاطر اندازه و حریم خصوصی، بهتر است در production از الگوهایی چون hidden-source-map یا nosources-source-map، میزبانی امن، و فشرده‌سازی/کش استفاده کنید. محدودیت‌ها شامل دقت ستونی ناقص در برخی تبدیل‌ها، کدهای dynamic/eval، ناسازگاری مسیرها و سوگیری‌های نگاشت است. بهترین رویه‌ها: فعال‌سازی map در تمام مراحل build، اعتبارسنجی در DevTools، اطمینان از CORS مناسب برای ابزار خطا، کنترل نسخه ابزارها و آزمون remap شدن خطاها در CI.
#JavaScript #SourceMaps #WebDev #Debugging #DevTools #Bundlers #Performance
🟣لینک مقاله:
https://golangweekly.com/link/176649/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
Do more with less. | Polar Signals
The Inner Workings of JavaScript Source Maps
A deep dive into how JavaScript source maps work under the hood, with examples showing how all the pieces fit together.
👍1