Forwarded from DevTwitter | توییت برنامه نویسی
مقایسه PostgreSQL در برابر MySQL — رقابتی میان دقت و سادگی
در تصویر اول، ستونی از نوع JSONB به همراه ایندکس GIN به جدول کاربران در پایگاهدادهی PostgreSQL اضافه شده است.
در تصویر دوم، اجرای یک کوئری بر روی ۵۰٬۰۰۰ رکورد در PostgreSQL حدود ۷ برابر سریعتر از MySQL انجام شد.
در اکوسیستم پایگاهدادههای رابطهای این دو نام بیش از همه در کانون توجهاند، هر دو از ستونهای اصلی دنیای متنباز به شمار میآیند، اما فلسفهی طراحی و نوع نگاهشان به داده، دو مسیر کاملاً متفاوت را دنبال میکند.
معماری و انضباط داده
پستگرسکیوال از ابتدا با رویکردی «استانداردمحور» طراحی شده است.
انطباق دقیق با استاندارد SQL و رفتار سختگیرانه در برابر نوع دادهها، قیدها و تراکنشها باعث میشود کیفیت دادهها در سطح سازمانی حفظ شود.
این ویژگی در پروژههایی که دادهی نادرست میتواند هزینهزا باشد، ارزش حیاتی دارد.
در مقابل، MySQL در برخورد با دادهها انعطافپذیرتر است و در بسیاری از سناریوها دادههای ناسازگار را بدون خطا ذخیره میکند ، ویژگیای که توسعهی سریعتر را ممکن میکند، اما ممکن است در مقیاس بزرگ چالشبرانگیز شود.
کارایی و الگوی مصرف
معمولاً در بارهای کاری سبکتر و اپلیکیشنهای مبتنی بر خواندن زیاد MySQL عملکرد بهتری نشان میدهد.
ساختار سادهتر و تنظیمات ابتدایی بهینهاش باعث میشود برای استارتاپها، MVPها و پروژههای با معماری ساده انتخابی طبیعی باشد.
در سوی دیگر، PostgreSQL در سناریوهای تحلیلی، تراکنشهای پیچیده و Queryهای چندلایه قدرت واقعی خود را نشان میدهد.
پشتیبانی از قابلیتهایی مانند CTE، Window Function و نوع دادهی JSONB آن را به گزینهای ایدهآل برای سیستمهای دادهمحور تبدیل کرده است.
قابلیت گسترش و انعطافپذیری فنی
پستگرسکیوال فراتر از یک دیتابیس کلاسیک عمل میکند.
تعریف نوع دادهی سفارشی، توابع دلخواه و حتی افزونهنویسی درون خود موتور، آن را به بستری برای طراحی معماریهای دادهای پیچیده بدل کرده است.
در مقابل، MySQL سادهتر و مینیمالتر است — رویکردی که هم نقطهی قوت است و هم محدودیت.
در نهایت، انتخاب میان PostgreSQL و MySQL نه بر اساس «بهتر بودن»، بلکه بر اساس اولویتهای معماری و نیازهای پروژه تعیین میشود.
اگر پروژهتان حول محور دقت، استاندارد و توسعهپذیری بلندمدت میچرخد، PostgreSQL انتخابی استراتژیک است.
اما اگر به دنبال سادگی، سرعت پیادهسازی و پایداری در نیازهای روزمرهی وب هستید، MySQL همچنان گزینهای درخشان و اثباتشده است.
@DevTwitter | <Babak Mirhosseini/>
در تصویر اول، ستونی از نوع JSONB به همراه ایندکس GIN به جدول کاربران در پایگاهدادهی PostgreSQL اضافه شده است.
در تصویر دوم، اجرای یک کوئری بر روی ۵۰٬۰۰۰ رکورد در PostgreSQL حدود ۷ برابر سریعتر از MySQL انجام شد.
در اکوسیستم پایگاهدادههای رابطهای این دو نام بیش از همه در کانون توجهاند، هر دو از ستونهای اصلی دنیای متنباز به شمار میآیند، اما فلسفهی طراحی و نوع نگاهشان به داده، دو مسیر کاملاً متفاوت را دنبال میکند.
معماری و انضباط داده
پستگرسکیوال از ابتدا با رویکردی «استانداردمحور» طراحی شده است.
انطباق دقیق با استاندارد SQL و رفتار سختگیرانه در برابر نوع دادهها، قیدها و تراکنشها باعث میشود کیفیت دادهها در سطح سازمانی حفظ شود.
این ویژگی در پروژههایی که دادهی نادرست میتواند هزینهزا باشد، ارزش حیاتی دارد.
در مقابل، MySQL در برخورد با دادهها انعطافپذیرتر است و در بسیاری از سناریوها دادههای ناسازگار را بدون خطا ذخیره میکند ، ویژگیای که توسعهی سریعتر را ممکن میکند، اما ممکن است در مقیاس بزرگ چالشبرانگیز شود.
کارایی و الگوی مصرف
معمولاً در بارهای کاری سبکتر و اپلیکیشنهای مبتنی بر خواندن زیاد MySQL عملکرد بهتری نشان میدهد.
ساختار سادهتر و تنظیمات ابتدایی بهینهاش باعث میشود برای استارتاپها، MVPها و پروژههای با معماری ساده انتخابی طبیعی باشد.
در سوی دیگر، PostgreSQL در سناریوهای تحلیلی، تراکنشهای پیچیده و Queryهای چندلایه قدرت واقعی خود را نشان میدهد.
پشتیبانی از قابلیتهایی مانند CTE، Window Function و نوع دادهی JSONB آن را به گزینهای ایدهآل برای سیستمهای دادهمحور تبدیل کرده است.
قابلیت گسترش و انعطافپذیری فنی
پستگرسکیوال فراتر از یک دیتابیس کلاسیک عمل میکند.
تعریف نوع دادهی سفارشی، توابع دلخواه و حتی افزونهنویسی درون خود موتور، آن را به بستری برای طراحی معماریهای دادهای پیچیده بدل کرده است.
در مقابل، MySQL سادهتر و مینیمالتر است — رویکردی که هم نقطهی قوت است و هم محدودیت.
در نهایت، انتخاب میان PostgreSQL و MySQL نه بر اساس «بهتر بودن»، بلکه بر اساس اولویتهای معماری و نیازهای پروژه تعیین میشود.
اگر پروژهتان حول محور دقت، استاندارد و توسعهپذیری بلندمدت میچرخد، PostgreSQL انتخابی استراتژیک است.
اما اگر به دنبال سادگی، سرعت پیادهسازی و پایداری در نیازهای روزمرهی وب هستید، MySQL همچنان گزینهای درخشان و اثباتشده است.
@DevTwitter | <Babak Mirhosseini/>
Forwarded from GitHub Trending Daily
🔥 New GitHub Trending Repositories 🔥
Found 4 new trending repositories:
1. claude-relay-service by Wei-Shaw
📝 CRS-自建Claude Code镜像,一站式开源中转服务,让 Claude、OpenAI、Gemini、Droid 订阅统一接入,支持拼车共享,更高效分摊成本,原生工具无缝使用。
💻 JavaScript | ⭐ 4,645 | 🌟 Today: 39
🔗 Link
2. Ventoy by ventoy
📝 A new bootable USB solution.
💻 C | ⭐ 71,834 | 🌟 Today: 203
🔗 Link
3. BettaFish by 666ghj
📝 微舆:人人可用的多Agent舆情分析助手,打破信息茧房,还原舆情原貌,预测未来走向,辅助决策!从0实现,不依赖任何框架。
💻 Python | ⭐ 2,245 | 🌟 Today: 148
🔗 Link
4. LLaMA-Factory by hiyouga
📝 Unified Efficient Fine-Tuning of 100+ LLMs & VLMs (ACL 2024)
💻 Python | ⭐ 61,415 | 🌟 Today: 146
🔗 Link
🔘 @github_trending_daily
Found 4 new trending repositories:
1. claude-relay-service by Wei-Shaw
📝 CRS-自建Claude Code镜像,一站式开源中转服务,让 Claude、OpenAI、Gemini、Droid 订阅统一接入,支持拼车共享,更高效分摊成本,原生工具无缝使用。
💻 JavaScript | ⭐ 4,645 | 🌟 Today: 39
🔗 Link
2. Ventoy by ventoy
📝 A new bootable USB solution.
💻 C | ⭐ 71,834 | 🌟 Today: 203
🔗 Link
3. BettaFish by 666ghj
📝 微舆:人人可用的多Agent舆情分析助手,打破信息茧房,还原舆情原貌,预测未来走向,辅助决策!从0实现,不依赖任何框架。
💻 Python | ⭐ 2,245 | 🌟 Today: 148
🔗 Link
4. LLaMA-Factory by hiyouga
📝 Unified Efficient Fine-Tuning of 100+ LLMs & VLMs (ACL 2024)
💻 Python | ⭐ 61,415 | 🌟 Today: 146
🔗 Link
🔘 @github_trending_daily
Forwarded from Reza Jafari
📖 The Smol Training Playbook
The Secrets to Building World-Class LLMs
Authors:
#HuggingFace
📌 Year: 2025
📌 Edition: 1
📌 Publisher: #HuggingFace
📌 Language: #English
📌 Pages: 214
📌 File: #PDF 24 MB
#book
@reza_jafari_ai
The Secrets to Building World-Class LLMs
Authors:
#HuggingFace
📌 Year: 2025
📌 Edition: 1
📌 Publisher: #HuggingFace
📌 Language: #English
📌 Pages: 214
📌 File: #PDF 24 MB
#book
@reza_jafari_ai
Forwarded from Reza Jafari
the_smol_training_playbook_the_secrets_to_building_world_class_llms.pdf
24 MB
دیروز Hugging Face یه مسترکلاس ۲۱۴ صفحهای منتشر کرد با عنوان The Smol Training Playbook که همهچیز دربارهی آموزش LLMها رو قدمبهقدم توضیح میده. این فایل از دلیل آموزش مدل تا نحوه اجرای واقعی اون رو پوشش میده و تجربهی ساخت LLMهای پیشرفته رو به اشتراک میذاره.
از مرحلهی pre-training گرفته تا mid-training و post-training، تمام مفاهیم رو به شکل گامبهگام باز میکنه. مفاهیمی مثل architecture، tokenization، data strategy و infrastructure بهجای اینکه فقط یه سری اصطلاح مبهم باشن، به تصمیمهای واقعی و کاربردی تبدیل شدن. این راهنما حتی به مشکلات دنیای واقعی هم میپردازه؛ از بیثباتیها و دردسرهای scaling گرفته تا کابوسهای debugging، و نکتهی جذابش اینه که بر اساس تجربهی ساخت LLMهای واقعی و پیشرفته نوشته شده، نه مدلهای تمرینی ساده.
در بخش ساختار مدل، همه چیز از tokenization تا attention mechanisms و positional encoding بررسی شده. انواع مکانیزمها، ترفندهای پایداری و روشهای scaling مثل mixture-of-experts و مدلهای hybrid (Transformer + SSM) آموزش داده شده تا مدل در عمل پایدار و کارآمد باشه.
بخش داده روی data curation تمرکز داره؛ کیفیت واقعی مدل به ترکیب داده بستگی داره و صرفاً جمعآوری داده از وب کافی نیست. روشهایی مثل curriculum learning و adaptive data mixes برای بهبود یادگیری معرفی شده و نمونهای مثل SmolLM3 ارائه شده که دادههای متعادل، چندزبانه، کد باکیفیت و ریاضی رو ترکیب میکنه.
در مرحلهی آموزش یا training marathon، همه چیز از بررسی زیرساخت و pipeline ارزیابی تا مانیتورینگ GPU metrics توضیح داده شده. مشکلاتی مثل throughput پایین، loss نویزی، باگهای parallelism و خطاهای data shuffling تحلیل شده و روشهای رفعشون ارائه شده. نکتهی کلیدی اینه که mid-training اصلاً خودکار نیست و باید دائما داده و استراتژیها بهینه بشن.
در بخش post-training، مدل خام تبدیل به دستیار واقعی میشه. اول SFT (supervised fine-tuning) برای پایهی پایدار، بعد بهینهسازی برای ترجیحات کاربر با روشهایی مثل DPO و نهایتاً on-policy RLHF یا distillation برای رفتار قابل اعتماد. این مرحله تعیینکنندهی کیفیت، ایمنی و قابلیت هدایت مدل هست.
بخش زیرساخت یا infra مهمترین و پیچیدهترین بخشه. داخل GPU واحدهای محاسباتی و سلسلهمراتب حافظه تعیینکنندهی سرعت هستن و بیرون از GPU اتصالات PCIe، NVLink، Infiniband و GPUDirect Storage اهمیت دارن. باید parallelism درست انتخاب و زیرساخت مقاوم ساخته بشه تا از توقف آموزش و bottleneck جلوگیری بشه.
در نهایت، همیشه با «چرا» شروع کن، معماری، اندازه مدل، ترکیب داده و نوع دستیار رو مشخص کن، زیرساخت مناسب بساز، برای خطاها آماده باش و از ترفندهای پایداری استفاده کن. کلید موفقیت، آزمایش سیستماتیک، debugging هوشمندانه، تسلط روی نرمافزار و سختافزار و کنجکاوی مستمره.
این یه کتاب جامع و کامل هست و اگر تو حوزه GenAI کار میکنید حتما بهش یه نگاه بندازید.
🔤 🔤 🔤 🔤 🔤 🔤 🔤
🥇 اهورا اولین اپراتور هوش مصنوعی راهبردی ایران در حوزه ارائه خدمات و سرویسهای زیرساخت هوش مصنوعی
🌐 لینک ارتباط با اهورا
@reza_jafari_ai
از مرحلهی pre-training گرفته تا mid-training و post-training، تمام مفاهیم رو به شکل گامبهگام باز میکنه. مفاهیمی مثل architecture، tokenization، data strategy و infrastructure بهجای اینکه فقط یه سری اصطلاح مبهم باشن، به تصمیمهای واقعی و کاربردی تبدیل شدن. این راهنما حتی به مشکلات دنیای واقعی هم میپردازه؛ از بیثباتیها و دردسرهای scaling گرفته تا کابوسهای debugging، و نکتهی جذابش اینه که بر اساس تجربهی ساخت LLMهای واقعی و پیشرفته نوشته شده، نه مدلهای تمرینی ساده.
در بخش ساختار مدل، همه چیز از tokenization تا attention mechanisms و positional encoding بررسی شده. انواع مکانیزمها، ترفندهای پایداری و روشهای scaling مثل mixture-of-experts و مدلهای hybrid (Transformer + SSM) آموزش داده شده تا مدل در عمل پایدار و کارآمد باشه.
بخش داده روی data curation تمرکز داره؛ کیفیت واقعی مدل به ترکیب داده بستگی داره و صرفاً جمعآوری داده از وب کافی نیست. روشهایی مثل curriculum learning و adaptive data mixes برای بهبود یادگیری معرفی شده و نمونهای مثل SmolLM3 ارائه شده که دادههای متعادل، چندزبانه، کد باکیفیت و ریاضی رو ترکیب میکنه.
در مرحلهی آموزش یا training marathon، همه چیز از بررسی زیرساخت و pipeline ارزیابی تا مانیتورینگ GPU metrics توضیح داده شده. مشکلاتی مثل throughput پایین، loss نویزی، باگهای parallelism و خطاهای data shuffling تحلیل شده و روشهای رفعشون ارائه شده. نکتهی کلیدی اینه که mid-training اصلاً خودکار نیست و باید دائما داده و استراتژیها بهینه بشن.
در بخش post-training، مدل خام تبدیل به دستیار واقعی میشه. اول SFT (supervised fine-tuning) برای پایهی پایدار، بعد بهینهسازی برای ترجیحات کاربر با روشهایی مثل DPO و نهایتاً on-policy RLHF یا distillation برای رفتار قابل اعتماد. این مرحله تعیینکنندهی کیفیت، ایمنی و قابلیت هدایت مدل هست.
بخش زیرساخت یا infra مهمترین و پیچیدهترین بخشه. داخل GPU واحدهای محاسباتی و سلسلهمراتب حافظه تعیینکنندهی سرعت هستن و بیرون از GPU اتصالات PCIe، NVLink، Infiniband و GPUDirect Storage اهمیت دارن. باید parallelism درست انتخاب و زیرساخت مقاوم ساخته بشه تا از توقف آموزش و bottleneck جلوگیری بشه.
در نهایت، همیشه با «چرا» شروع کن، معماری، اندازه مدل، ترکیب داده و نوع دستیار رو مشخص کن، زیرساخت مناسب بساز، برای خطاها آماده باش و از ترفندهای پایداری استفاده کن. کلید موفقیت، آزمایش سیستماتیک، debugging هوشمندانه، تسلط روی نرمافزار و سختافزار و کنجکاوی مستمره.
این یه کتاب جامع و کامل هست و اگر تو حوزه GenAI کار میکنید حتما بهش یه نگاه بندازید.
@reza_jafari_ai
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Shayan GeeDook🐧
درود بچه ها، امیرحسین کمندلو یکی از بچه های فعال حوزه تک یه رباتی زده که دانلود سریع آهنگ از SoundCloud با ربات. دوست داشتید میتونید از بات استفاده کنید.
آهنگ مورد علاقتو مستقیم روی تلگرام دریافت کن 🎧
✅ کیفیت بالا MP3
✅ نمایش کاور و نام خواننده
✅ فقط با ارسال لینک آهنگ
➡️ ربات: @SoundCloudDownl0aderBot
آهنگ مورد علاقتو مستقیم روی تلگرام دریافت کن 🎧
✅ کیفیت بالا MP3
✅ نمایش کاور و نام خواننده
✅ فقط با ارسال لینک آهنگ
➡️ ربات: @SoundCloudDownl0aderBot
Forwarded from محتوای آزاد سهراب (Sohrab)
امشب یک بندهخدایی رو دیدم که توهم خود دانا و خود برتر پنداریش با هوش مصنوعی ده برابر از دوستان دیگه بود.
البته امیدوارم اینکارها اقتضای سن این عزیزان باشه که با استفاده از هوش مصنوعی میخوان سیستمعامل بهتری از لینوکس بسازن و خودشون رو دست بالاتر از بقیه میگیرن.
امیدوارم با گذشت زمان و بالاتر رفتن سنشون این مشکل هم برطرف بشه.
@SohrabContents
البته امیدوارم اینکارها اقتضای سن این عزیزان باشه که با استفاده از هوش مصنوعی میخوان سیستمعامل بهتری از لینوکس بسازن و خودشون رو دست بالاتر از بقیه میگیرن.
امیدوارم با گذشت زمان و بالاتر رفتن سنشون این مشکل هم برطرف بشه.
@SohrabContents
Forwarded from محتوای آزاد سهراب (Sohrab)
البته به این میگن اثر دانینگ کروگر
https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
@SohrabContents
https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
اثر دانینگ-کروگر یک تعصب شناختیه که افراد ناآشنا با موضوع، کمبود دانش خودشون رو تشخیص نمیدن و اعتماد به نفسشون بیجا بالا میره، بعد با کسب کمی دانش نقصها رو میبینن و اعتماد به نفس افت میکنه، و در نهایت با تخصص واقعی، اعتماد به نفس متعادل و واقعبینانه برمیگرده.
@SohrabContents
Forwarded from نوشتههای ترمینالی
این چنل آرشیو کتابها، برگه تقلب، پادکست و وبینار برای دولپرهاست، بدردتون میخوره
t.iss.one/+M4QujCyYc9E1N2Rk
t.iss.one/+M4QujCyYc9E1N2Rk
Telegram
Archive Developers
رسالت ما – ارائه محتوای کاربردی شامل کتاب، برگه تقلب، وبینار و پادکست برای توسعهدهندگان و علاقهمندان به برنامهنویسی و فناوریهای مرتبط، همراه با ذکر منابع!
👨🏻💻 | @Afsh6n
✍🏽 | @DevYara
🍓 | @TopicsDev
👨🏻💻 | @Afsh6n
✍🏽 | @DevYara
🍓 | @TopicsDev
Forwarded from محتوای آزاد سهراب (Sohrab)
یادمه با Bash و Dialog یک اسکریپت داشتم برای تعمیر گراب و قرار بود هوشمندترش کنم.
از اونجایی که برای خودم یک تمپلیت adw/gtk4 روی پایتون ساخته بودم، لاجیکش رو آوردم روی همین پیادهسازی کردم.
البته که این کارآمد نیست، صرفاً الان فقط ui طراحی کردم. تا تکمیل بشه زمان زیاد میبره.
@SohrabContents
از اونجایی که برای خودم یک تمپلیت adw/gtk4 روی پایتون ساخته بودم، لاجیکش رو آوردم روی همین پیادهسازی کردم.
البته که این کارآمد نیست، صرفاً الان فقط ui طراحی کردم. تا تکمیل بشه زمان زیاد میبره.
@SohrabContents
Forwarded from ASafaeirad
Forwarded from Golden Code (@lix)
یه روش برای اینکه کارهای تکراریه مثل ساخت یه سری کلاسهای خاص (مثلا DTO) رو خودکار کنید
اولش ببینیم چرا custom artisan command مفیده؟
صرفهجویی در زمان
کاهش خطا: از نوشتن دستی کد جلوگیری میکنین
وقت بیشتری برای کدنویسی بخشهای مهم پروژه دارید.
📌 چطوری custom artisan command بسازیم؟
1. ایجاد کامند جدید:
با دستور زیر، یک کامند جدید ایجاد کنین:
2. نوشتن منطق دستور:
در کلاس جدید،دستور مورد نظرتونو بنویسین (مثل ساخت یک DTO جدید).
یه مثال:
3. اجرای دستور:
حالا با این دستور میتونین بسادگی کلاسهای DTO جدید بسازید:
خلاصش که:
با استفاده از custom artisan command، میتونین کارهای تکراریتون رو خودکار کنین و توسعه پروژتون رو هم سرعت بدید.
#Laravel #Laravel_tip #لاراول
@GoldenCodeir 🔥
(بهمنبع و مثالش دقت کنید 👇🏾)
https://x.com/mmartin_joo/status/1982797695568707742?t=EQ-hdRBX3rRgGuPH2EyA9Q&s=19
اولش ببینیم چرا custom artisan command مفیده؟
صرفهجویی در زمان
کاهش خطا: از نوشتن دستی کد جلوگیری میکنین
وقت بیشتری برای کدنویسی بخشهای مهم پروژه دارید.
📌 چطوری custom artisan command بسازیم؟
1. ایجاد کامند جدید:
با دستور زیر، یک کامند جدید ایجاد کنین:
php artisan make:command CreateDto
2. نوشتن منطق دستور:
در کلاس جدید،دستور مورد نظرتونو بنویسین (مثل ساخت یک DTO جدید).
یه مثال:
<?php
protected $signature = 'make:dto {name}';
protected $description = 'Create a new DTO class';
public function handle() {
$name = $this->argument('name');
file_put_contents(app_path("Dtos/{$name}.php"), "<?php\n\nclass {$name} {}\n");
$this->info("DTO {$name} created successfully!");
}
3. اجرای دستور:
حالا با این دستور میتونین بسادگی کلاسهای DTO جدید بسازید:
php artisan make:dto MyDto
خلاصش که:
با استفاده از custom artisan command، میتونین کارهای تکراریتون رو خودکار کنین و توسعه پروژتون رو هم سرعت بدید.
#Laravel #Laravel_tip #لاراول
@GoldenCodeir 🔥
(بهمنبع و مثالش دقت کنید 👇🏾)
https://x.com/mmartin_joo/status/1982797695568707742?t=EQ-hdRBX3rRgGuPH2EyA9Q&s=19
X (formerly Twitter)
Martin Joo (@mmartin_joo) on X
💡 Did you know you can create custom artisan generator commands for your classes?
If you find yourself creating the same type of class over and over again (for example, DTOs), you might want to take a look at it:
If you find yourself creating the same type of class over and over again (for example, DTOs), you might want to take a look at it:
Forwarded from Gopher Academy
🔵 عنوان مقاله
The Concurrency Conundrum: A Story of Curiosity and Code
🟢 خلاصه مقاله:
**این مقاله داستان برخورد با یک مشکل رایج در همزمانی است: سرویس ظاهراً سالمی که زیر بار گاهی قفل میکرد و درخواستها معطل میماندند. با افزودن لاگهای ساختیافته، ابزارهای رهگیری و یک تست حداقلیِ قابلبازتولید، ریشه مشخص شد: ترتیبگیری نادرست قفلها و بخشهای بحرانی طولانی که به بنبست و گاهی رقابت در دسترسی به متغیرها منجر میشد. راهحل با تعریف نظم ثابت در ترتیب اخذ قفلها، جایگزینی قفل سراسری با قفلهای ریزدانه و read-write، کوچککردن بخشهای بحرانی و پرهیز از I/O زیر قفل، بهکارگیری try-lock با backoff و timeout، و در مسیرهای پرتردد، حرکت به سمت پیاممحوری بهجای وضعیت مشترک اجرا شد. سپس با Thread Sanitizer و ابزارهای تشخیص بنبست در CI، تستهای تنشی و مبتنی بر ویژگی، و سنجههای مربوط به تراکم قفل، سامانه سختجانتر شد. جمعبندی: مدل همزمانی را ساده نگه دارید، دادههای نامتغیر و عملیات idempotent را ترجیح دهید، از سازوکارهای سطحبالا استفاده کنید، و ترتیب قفلها و ناورداییها را مستند و پایشپذیر کنید.
#Concurrency #Locking #Deadlock #RaceConditions #Multithreading #Debugging #SoftwareEngineering #Reliability
🟣لینک مقاله:
https://golangweekly.com/link/176333/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
The Concurrency Conundrum: A Story of Curiosity and Code
🟢 خلاصه مقاله:
**این مقاله داستان برخورد با یک مشکل رایج در همزمانی است: سرویس ظاهراً سالمی که زیر بار گاهی قفل میکرد و درخواستها معطل میماندند. با افزودن لاگهای ساختیافته، ابزارهای رهگیری و یک تست حداقلیِ قابلبازتولید، ریشه مشخص شد: ترتیبگیری نادرست قفلها و بخشهای بحرانی طولانی که به بنبست و گاهی رقابت در دسترسی به متغیرها منجر میشد. راهحل با تعریف نظم ثابت در ترتیب اخذ قفلها، جایگزینی قفل سراسری با قفلهای ریزدانه و read-write، کوچککردن بخشهای بحرانی و پرهیز از I/O زیر قفل، بهکارگیری try-lock با backoff و timeout، و در مسیرهای پرتردد، حرکت به سمت پیاممحوری بهجای وضعیت مشترک اجرا شد. سپس با Thread Sanitizer و ابزارهای تشخیص بنبست در CI، تستهای تنشی و مبتنی بر ویژگی، و سنجههای مربوط به تراکم قفل، سامانه سختجانتر شد. جمعبندی: مدل همزمانی را ساده نگه دارید، دادههای نامتغیر و عملیات idempotent را ترجیح دهید، از سازوکارهای سطحبالا استفاده کنید، و ترتیب قفلها و ناورداییها را مستند و پایشپذیر کنید.
#Concurrency #Locking #Deadlock #RaceConditions #Multithreading #Debugging #SoftwareEngineering #Reliability
🟣لینک مقاله:
https://golangweekly.com/link/176333/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
Wawandco
The Concurrency Conundrum: A Story of Curiosity and Code | Wawandco
Building a simple reservation system sounds easy—until concurrency steps in. As a product grows, naive checks break down. This post unpacks why atomicity isn’t enough, and how pessimistic vs. optimistic locking prevent overbooking at scale.
Forwarded from DevTwitter | توییت برنامه نویسی
This media is not supported in your browser
VIEW IN TELEGRAM
کمپانی HuggingFace اومده و یک بلاگ (که میتونید به صورت یک کتاب هم دانلود کنید و بخونید) از تمام مراحل training تا post training و fine tuning مدلهای کوچک LLM و VLM که خودشون انجام دادند را درست کردند. یعنی تمام نکات و قلق ها را توضیح میدند.
Link: https://huggingface.co/spaces/HuggingFaceTB/smol-training-playbook
@DevTwitter | <Mehdi Allahyari/>
Link: https://huggingface.co/spaces/HuggingFaceTB/smol-training-playbook
@DevTwitter | <Mehdi Allahyari/>
Forwarded from Linuxor ?
علت اینکه هوش مصنوعی بعد از ده ها سال یهویی پیشرفت کرد بخاطر این بود هوش مصنوعی گیر کرده بود توی گلوگاه خودش و تونست با ظهور چهارتا کارت گرافیک قوی و یه الگوریتم ترنسفورمر گلوگاه رو بشکنه، حالا صد ها میلیارد دلار روش سرمایه گذاری شده و قراره براش کلی زیرساخت بسازن، یک درصد فکر کنید یه گلوگاه دیگه جلوی پیشرفت باشه و همه پول هایی که خرج هوش مصنوعی شده هدر بره (گلوگاه یعنی مثلا از اینی که وجود داره خیلی پیشرفت نکنه و اگرم کنه یه درصد خیلی کم، و این محتمله، گلوگاه میتونه مثلا عدم کیفیت داده ها و یا حتی انرژی باشه)
@Linuxor
@Linuxor