🔵 عنوان مقاله
Gojekyll: A Fast Go Implementation of Jekyll
🟢 خلاصه مقاله:
Gojekyll یک کلون سریع و «نسبتاً سازگار» از Jekyll است که به‌جای Ruby با Go پیاده‌سازی شده و با ارائه یک باینری تک‌فایلی، ساخت سایت‌های استاتیک را سریع‌تر و قابل‌حمل‌تر می‌کند. بسیاری از سایت‌های رایج Jekyll بدون تغییرات جدی اجرا می‌شوند، اما اگر به افزونه‌ها یا ویژگی‌های خاص متکی باشید، ممکن است نیاز به جایگزین یا اصلاح داشته باشید. برای تیم‌هایی که می‌خواهند Ruby را از استک خود حذف کرده و زمان ساخت و پیچیدگی CI/CD را کاهش دهند، Gojekyll گزینه‌ای قابل بررسی است.
#Jekyll #Gojekyll #Go #Ruby #StaticSiteGenerator #Performance #Portability #Jamstack
🟣لینک مقاله:
https://golangweekly.com/link/174653/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
Gojekyll: A Fast Go Implementation of Jekyll
🟢 خلاصه مقاله:
Gojekyll یک کلون سریع و «نسبتاً سازگار» از Jekyll است که به‌جای Ruby با Go پیاده‌سازی شده و با ارائه یک باینری تک‌فایلی، ساخت سایت‌های استاتیک را سریع‌تر و قابل‌حمل‌تر می‌کند. بسیاری از سایت‌های رایج Jekyll بدون تغییرات جدی اجرا می‌شوند، اما اگر به افزونه‌ها یا ویژگی‌های خاص متکی باشید، ممکن است نیاز به جایگزین یا اصلاح داشته باشید. برای تیم‌هایی که می‌خواهند Ruby را از استک خود حذف کرده و زمان ساخت و پیچیدگی CI/CD را کاهش دهند، Gojekyll گزینه‌ای قابل بررسی است.
#Jekyll #Gojekyll #Go #Ruby #StaticSiteGenerator #Performance #Portability #Jamstack
🟣لینک مقاله:
https://golangweekly.com/link/174653/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
GitHub
GitHub - osteele/gojekyll: A fast Go implementation of the Jekyll blogging engine
A fast Go implementation of the Jekyll blogging engine - osteele/gojekyll
❤2
🔵 عنوان مقاله
Go Allocations Explorer Extension for VSCode
🟢 خلاصه مقاله:
این افزونه با نام Go Allocations Explorer Extension برای VS Code به برنامه‌نویسان Go کمک می‌کند تا محل و میزان تخصیص حافظه را بر پایه بنچمارک‌های موجودشان مستقیماً داخل ویرایشگر ببینند. با اجرای go test -bench و استفاده از -benchmem، نتایج تخصیص‌ها جمع‌آوری و به فهرستی قابل پیمایش تبدیل می‌شود تا بتوانید به‌سرعت هات‌اسپات‌ها را یافته و از همان ورودی‌ها به کد مربوطه بپرید. امکان اجرا و تکرار بنچمارک‌ها، مشاهده و مقایسه سریع نتایج، و مرتب‌سازی/فیلتر کردن بر اساس پکیج، تست یا تابع فراهم است. راه‌اندازی ساده است، فقط نیاز به ابزار Go دارد و روی macOS، Linux و Windows کار می‌کند. خروجی‌ها در خود VS Code به شکل قابل فهم ارائه می‌شوند تا کاهش تخصیص‌ها، کم شدن فشار GC و بهبود تأخیر به‌صورت مستمر و در جریان کدنویسی انجام شود.
#Go #VSCode #Golang #Performance #Benchmarking #MemoryAllocations #Profiling #DeveloperTools
🟣لینک مقاله:
https://golangweekly.com/link/174659/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
Go Allocations Explorer Extension for VSCode
🟢 خلاصه مقاله:
این افزونه با نام Go Allocations Explorer Extension برای VS Code به برنامه‌نویسان Go کمک می‌کند تا محل و میزان تخصیص حافظه را بر پایه بنچمارک‌های موجودشان مستقیماً داخل ویرایشگر ببینند. با اجرای go test -bench و استفاده از -benchmem، نتایج تخصیص‌ها جمع‌آوری و به فهرستی قابل پیمایش تبدیل می‌شود تا بتوانید به‌سرعت هات‌اسپات‌ها را یافته و از همان ورودی‌ها به کد مربوطه بپرید. امکان اجرا و تکرار بنچمارک‌ها، مشاهده و مقایسه سریع نتایج، و مرتب‌سازی/فیلتر کردن بر اساس پکیج، تست یا تابع فراهم است. راه‌اندازی ساده است، فقط نیاز به ابزار Go دارد و روی macOS، Linux و Windows کار می‌کند. خروجی‌ها در خود VS Code به شکل قابل فهم ارائه می‌شوند تا کاهش تخصیص‌ها، کم شدن فشار GC و بهبود تأخیر به‌صورت مستمر و در جریان کدنویسی انجام شود.
#Go #VSCode #Golang #Performance #Benchmarking #MemoryAllocations #Profiling #DeveloperTools
🟣لینک مقاله:
https://golangweekly.com/link/174659/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
Visualstudio
Go Allocations Explorer - Visual Studio Marketplace
Extension for Visual Studio Code - An extension that helps locate Go allocations, using your benchmarks.
❤2👍1
🔵 عنوان مقاله
3 Critical TTL Patterns for In-Memory Caching
🟢 خلاصه مقاله:
این مقاله سه الگوی کلیدی TTL برای کش درون‌حافظه‌ای را توضیح می‌دهد و نشان می‌دهد چگونه انتخاب درست میان تازگی داده، کارایی و پایداری را ممکن می‌کند. الگوی اول، TTL ثابت است: هر مقدار پس از مدت مشخص منقضی می‌شود؛ ساده و قابل‌پیش‌بینی است، اما نزدیک انقضا می‌تواند داده قدیمی ارائه کند و پس از انقضا به «thundering herd» منجر شود مگر اینکه با jitter و هم‌گرایی درخواست‌ها مدیریت شود. الگوی دوم، TTL لغزشی است: هر دسترسی عمر آیتم را تمدید می‌کند، برای کلیدهای پرترافیک عالی است اما بدون «حداکثر عمر» ممکن است بعضی مقادیر عملاً هرگز تازه‌سازی نشوند. الگوی سوم، stale-while-revalidate (و refresh-ahead) است: مقدار کمی کهنه فوراً سرو می‌شود و تازه‌سازی در پس‌زمینه انجام می‌گیرد؛ با single-flight از هجوم درخواست‌های همسان جلوگیری می‌کند و در صورت خطا می‌توان با stale-if-error موقتاً از آخرین مقدار سالم استفاده کرد. در عمل ترکیب این الگوها—به‌همراه TTLهای متفاوت برای هر کلید، jitter، backoff و رصد دقیق نرخ hit/miss—به تعادل بهینه می‌انجامد. نویسنده برای نمایش پیاده‌سازی‌های عملی از کتابخانه Hot در اکوسیستم Go بهره می‌گیرد تا استفاده از این الگوها ساده و کارا شود.
#Caching #TTL #InMemoryCache #Go #Golang #StaleWhileRevalidate #Performance #CacheStampede
🟣لینک مقاله:
https://golangweekly.com/link/175058/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
3 Critical TTL Patterns for In-Memory Caching
🟢 خلاصه مقاله:
این مقاله سه الگوی کلیدی TTL برای کش درون‌حافظه‌ای را توضیح می‌دهد و نشان می‌دهد چگونه انتخاب درست میان تازگی داده، کارایی و پایداری را ممکن می‌کند. الگوی اول، TTL ثابت است: هر مقدار پس از مدت مشخص منقضی می‌شود؛ ساده و قابل‌پیش‌بینی است، اما نزدیک انقضا می‌تواند داده قدیمی ارائه کند و پس از انقضا به «thundering herd» منجر شود مگر اینکه با jitter و هم‌گرایی درخواست‌ها مدیریت شود. الگوی دوم، TTL لغزشی است: هر دسترسی عمر آیتم را تمدید می‌کند، برای کلیدهای پرترافیک عالی است اما بدون «حداکثر عمر» ممکن است بعضی مقادیر عملاً هرگز تازه‌سازی نشوند. الگوی سوم، stale-while-revalidate (و refresh-ahead) است: مقدار کمی کهنه فوراً سرو می‌شود و تازه‌سازی در پس‌زمینه انجام می‌گیرد؛ با single-flight از هجوم درخواست‌های همسان جلوگیری می‌کند و در صورت خطا می‌توان با stale-if-error موقتاً از آخرین مقدار سالم استفاده کرد. در عمل ترکیب این الگوها—به‌همراه TTLهای متفاوت برای هر کلید، jitter، backoff و رصد دقیق نرخ hit/miss—به تعادل بهینه می‌انجامد. نویسنده برای نمایش پیاده‌سازی‌های عملی از کتابخانه Hot در اکوسیستم Go بهره می‌گیرد تا استفاده از این الگوها ساده و کارا شود.
#Caching #TTL #InMemoryCache #Go #Golang #StaleWhileRevalidate #Performance #CacheStampede
🟣لینک مقاله:
https://golangweekly.com/link/175058/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
Substack
3 Critical TTL Patterns for In-Memory Caching
Most caching libraries get TTL expiration wrong. They focus on per-key complexity while missing the patterns that actually prevent production outages.
👍1
🔵 عنوان مقاله
Slice Tails Don't Grow Forever
🟢 خلاصه مقاله:
** این مطلب از Golang Weekly توضیح می‌دهد که در Go، وقتی از یک slice یک “tail” مثل s[i:] می‌سازیم، رشد آن به capacity وابسته است و پایدار و بی‌نهایت نیست. تا وقتی capacity اجازه دهد، append روی همان آرایه‌ی پشتی انجام می‌شود؛ اما به‌محض عبور از capacity، runtime آرایه‌ی جدیدی می‌سازد و داده‌ها را کپی می‌کند، در نتیجه اشتراک حافظه با sliceهای قبلی از بین می‌رود. این رفتار هم می‌تواند باعث شگفتی در منطق اشتراک‌گذاری داده‌ها شود و هم روی کارایی و مصرف حافظه اثر بگذارد (مثلاً نگه‌داشتن یک زیر-slice کوچک می‌تواند یک آرایه‌ی بزرگ را در حافظه زنده نگه دارد). نتیجهٔ عملی: روی رشد بی‌نهایت tail حساب نکنید، خروجی append را یک slice بالقوه با آرایه‌ی پشتی جدید در نظر بگیرید، برای آزادسازی حافظه از copy استفاده کنید، در صورت نیاز capacity مناسب را از قبل با make در نظر بگیرید و حتماً با benchmark تصمیم بگیرید.
#Go #Golang #Slices #Append #MemoryManagement #Performance #GolangWeekly
🟣لینک مقاله:
https://golangweekly.com/link/175065/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
Slice Tails Don't Grow Forever
🟢 خلاصه مقاله:
** این مطلب از Golang Weekly توضیح می‌دهد که در Go، وقتی از یک slice یک “tail” مثل s[i:] می‌سازیم، رشد آن به capacity وابسته است و پایدار و بی‌نهایت نیست. تا وقتی capacity اجازه دهد، append روی همان آرایه‌ی پشتی انجام می‌شود؛ اما به‌محض عبور از capacity، runtime آرایه‌ی جدیدی می‌سازد و داده‌ها را کپی می‌کند، در نتیجه اشتراک حافظه با sliceهای قبلی از بین می‌رود. این رفتار هم می‌تواند باعث شگفتی در منطق اشتراک‌گذاری داده‌ها شود و هم روی کارایی و مصرف حافظه اثر بگذارد (مثلاً نگه‌داشتن یک زیر-slice کوچک می‌تواند یک آرایه‌ی بزرگ را در حافظه زنده نگه دارد). نتیجهٔ عملی: روی رشد بی‌نهایت tail حساب نکنید، خروجی append را یک slice بالقوه با آرایه‌ی پشتی جدید در نظر بگیرید، برای آزادسازی حافظه از copy استفاده کنید، در صورت نیاز capacity مناسب را از قبل با make در نظر بگیرید و حتماً با benchmark تصمیم بگیرید.
#Go #Golang #Slices #Append #MemoryManagement #Performance #GolangWeekly
🟣لینک مقاله:
https://golangweekly.com/link/175065/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
🤝1
🔵 عنوان مقاله
Do 2.0: Type-Safe Dependency Injection Toolkit
🟢 خلاصه مقاله:
Do 2.0 یک ابزار مدرن برای پیاده‌سازی الگوی Dependency Injection است که با تکیه بر generics به‌جای reflection، یک API کاملاً type-safe ارائه می‌دهد. این تغییر، خطاها را از زمان اجرا به زمان کامپایل منتقل می‌کند، عملکرد و زمان راه‌اندازی را بهبود می‌دهد و با امکانات IDE مثل تکمیل خودکار و بازآرایی کد سازگارتر است. در Do 2.0 اتصال وابستگی‌ها صریح و قابل‌ردگیری است، بنابراین نگهداشت، آزمون‌پذیری و اطمینان از درستی گراف وابستگی‌ها ساده‌تر می‌شود. برای کاربران فعلی Do، راهنمای ارتقا از نسخه v1 فراهم است و تغییرات کلیدی و نمونه‌ها را برای مهاجرت آسان توضیح می‌دهد.
#DependencyInjection #TypeSafe #Generics #NoReflection #APIDesign #SoftwareArchitecture #Maintainability #Performance
🟣لینک مقاله:
https://golangweekly.com/link/175066/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
Do 2.0: Type-Safe Dependency Injection Toolkit
🟢 خلاصه مقاله:
Do 2.0 یک ابزار مدرن برای پیاده‌سازی الگوی Dependency Injection است که با تکیه بر generics به‌جای reflection، یک API کاملاً type-safe ارائه می‌دهد. این تغییر، خطاها را از زمان اجرا به زمان کامپایل منتقل می‌کند، عملکرد و زمان راه‌اندازی را بهبود می‌دهد و با امکانات IDE مثل تکمیل خودکار و بازآرایی کد سازگارتر است. در Do 2.0 اتصال وابستگی‌ها صریح و قابل‌ردگیری است، بنابراین نگهداشت، آزمون‌پذیری و اطمینان از درستی گراف وابستگی‌ها ساده‌تر می‌شود. برای کاربران فعلی Do، راهنمای ارتقا از نسخه v1 فراهم است و تغییرات کلیدی و نمونه‌ها را برای مهاجرت آسان توضیح می‌دهد.
#DependencyInjection #TypeSafe #Generics #NoReflection #APIDesign #SoftwareArchitecture #Maintainability #Performance
🟣لینک مقاله:
https://golangweekly.com/link/175066/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
do.samber.dev
⚙️ do: Type-safe dependency injection for Go | do
A dependency injection toolkit based on Go 1.18+ Generics.
🔥2👍1
🔵 عنوان مقاله
'We Tried Go's Experimental Green Tea Garbage Collector and It Didn't Help Performance'
🟢 خلاصه مقاله:
** تیم Dolt در Go 1.25 جمع‌آورنده زباله آزمایشی Green Tea را فعال و ارزیابی کرد، اما در سناریوی خاص خود بهبود محسوسی در کارایی مشاهده نکرد. با این حال، از آنجا که رفتار GC به نوع بار کاری وابسته است و Green Tea همچنان آزمایشی و اختیاری است، توصیه می‌شود هر تیم آن را در محیط و بنچمارک‌های خود امتحان کرده و بر اساس شاخص‌های واقعی تصمیم بگیرد.
#Go #Golang #GarbageCollector #GreenTea #Performance #Benchmarking #Dolt #Go1_25
🟣لینک مقاله:
https://golangweekly.com/link/175055/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
'We Tried Go's Experimental Green Tea Garbage Collector and It Didn't Help Performance'
🟢 خلاصه مقاله:
** تیم Dolt در Go 1.25 جمع‌آورنده زباله آزمایشی Green Tea را فعال و ارزیابی کرد، اما در سناریوی خاص خود بهبود محسوسی در کارایی مشاهده نکرد. با این حال، از آنجا که رفتار GC به نوع بار کاری وابسته است و Green Tea همچنان آزمایشی و اختیاری است، توصیه می‌شود هر تیم آن را در محیط و بنچمارک‌های خود امتحان کرده و بر اساس شاخص‌های واقعی تصمیم بگیرد.
#Go #Golang #GarbageCollector #GreenTea #Performance #Benchmarking #Dolt #Go1_25
🟣لینک مقاله:
https://golangweekly.com/link/175055/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
Dolthub
We tried Go's experimental Green Tea garbage collector and it didn't help performance
Go 1.25 includes support for an experimental new garbage collector called Green Tea. We tried it out with Dolt's main performance benchmarks and summarize what difference it made (not much).
❤1
🔵 عنوان مقاله
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.