کدوم مغز داری در دنیا زندگیش رو صرف دستمزد و حقوق گرفتن کرده تا بجای خلق ارزش افزوده؟؟؟


کدوم یک از صاحب کمپانی‌های بزرگ دنیا بابت دستمزد کار میکنن؟؟

کدوم یک از شرکت داران امروزی بابت دستمزد کار میکنن؟؟؟


حالا این سوال رو از خودت بپرس کدوم شرکتی حاضره بجای حقوق بهتون سهام بده؟؟؟

یکم کتاب‌های رابرت کیوساکی رو بخونید درک کردن حرفاش بهتون کمک میکنه رفتار اقتصادی بهتری انجام بدید


#free

@code_crafters

در ادامه مبحث کتاب همزمانی

زمان تاخیر (latency) و توان عملیاتی

بسته به نگاه ما میتوان عملکرد سیستم را به گونه‌های مختلفی ارزیابی و بررسی کرد، یکی از راه‌های افزایش عملکرد کاهش زمان تسک‌های تکی می باشد

با یک مثال پیش بریم
شما میخواهید از نقطه A به نقطه B بروید شما میتونید این فاصله رو پیاده برید یا با یک موتور، در حالت دوم با استفاده از موتور شما زمان کمتری رو مصرف میکنید

حالا اگه بخواید چند نفر رو در بین این دو نقطه جابجا کنید الزاما شما از یک اتوبوس استفاده خواهید کرد ، در این حالت دیگه شما بفکر زمان نیستید بلکه بفکر جابجایی نفرات بیشتر هستید، به این سناریو توان عملیاتی گفته میشه: تعداد وظایفی که یک سیستم در یک بازه زمانی میتونه انجام بده


درسته یک موتور سریعتر از اتوبوس هستش اما اتوبوس بار عملیاتیش چند برابر موتوره، اگر موتور این مسافت رو یک ساعته بره، اتوبوس دو ساعته میره ، اما موتور یک نفر رو جابجا میکنه اتوبوس ۳۰ نفر رو ،در واقع در ازای هر ساعت اتوبوس ما ۱۵ نفر رو جابجا کرده‌ایم

درک تفاوت تاخیر و توان عملیاتی بسیار مهم هستش

به عبارت دیگر، توان عملیاتی بیشتر سیستم لزوماً به معنای تأخیر کمتر نیست.
هنگام بهینه سازی عملکرد، بهبود یک عامل (مانند توان عملیاتی) ممکن است منجر به بدتر شدن عامل دیگر (مانند تأخیر) شود


همزمانی میتواند تاخیر را کاهش دهد، با شکستن یک تسک طولانی مدت به چند تسک کوچکتر و اجرای آنها بصورت موازی ،موجب کاهش کلی زمان اجرایی میشود ،همزمان همچنین میتواند با اجازه دادن به پردازش چندکار بطور همزمان به افزایش توان عملیاتی کمک کند، علاوه بر این میتواند تاخیر را پنهان کند(خوندن سلسله پست‌های این آموزش در اتوبوس بالا)

بنابراین، استفاده از همزمانی می تواند عملکرد سیستم را به سه روش اصلی بهبود بخشد:

 -کاهش تاخیر (یعنی یک واحد کار را سریعتر کند)

-پنهان کردن تاخیر(یعنی به سیستم اجازه دهد تا در طی عملیاتی با تأخیر بالا چیز دیگری را انجام دهد)

-افزایش توان عملیاتی (یعنی سیستم را قادر به انجام کارهای بیشتر کند)
 

همزمانی چطور در سیستم‌های پیچیده و بزرگ موثر است؟؟؟

حل مسائل بزرگ و پیچیده‌ که هنگام توسعه سیستم با اون سروکار داریم بدون استفاده از یک سیستم ترتیبی غیر ممکن است. پیچیدگی می تواند ناشی از اندازه مشکل یا سختی درک بخشی از سیستم هایی باشد که توسعه می دهیم.


مقیاس پذیری(scalability)
اندازه یک مشکل شامل مقیاس پذیری یا ویژگی یک سیستم است که میتواند با افزودن منابع بیشتر عملکرد را افزایش دهد

اسکیل کردن به دو صورت عمودی و افقی هست

اسکیل عمودی
که شامل بروز رسانی سخت افزاری و افزایش منابع سخت افزاری هستش، هسته قویتر، حافظه بیشتر و ...
که خب همیشه محدودیت داریم و تا جایی میتونیم این کار رو ادامه بدیم

اسکیل افقی
این قسمت بیشتر سمت مهمدسین نرم افزار و توسعه دهندگان هستش که شامل کاهش زمان انجام یک کار خاص و کوچک کردن سیستم‌های خودمون، اسکیل افقی در واقع افزایش عملکرد سیستم با توزیع بار بین منابع موجود هستش اینکار بشدت سختتر و زمانبرتر از اسکیل عمودی هستش

روند ناشی از تقاضای سیستم‌های بلادرنگ، حجم بالای داده، قابلیت اطمینان از طریق افزونگی و بهبود استفاده از طریق استراک‌گذاری منابع به دلیل مهاحرت به محیط‌های ابری (SaaS)، این صنعت تصمیم به رویکرد اسکیل افقی گرفت

جداسازی (decoupling)
موضوع مورد مناقشه بعدی پیچیدگی هستش، که بدون تلاش مهندسان نرم افزار هیچگاه کاهش پیدا نمیکند

وقتی شروع میکنید یک سیستم رو قدرتمندتر و کاربردی تر کنید پیچیدگی اجتناب ناپذیر میشه بالاخص در بیس کد هاتون، زیرساختتون و همچین نگهداری اون سیستم

در نهایت باید یک رویکرد بیابیم که سیستم رو به واحدهای ارتباطی ساده‌تر پیاده سازی کند

معماری میکروسرویس و معماری DDD اینکار رو برامون انجام میدن اما همانطور که دیدیم پیچیدگی درونشون هم اجتناب ناپذیر هست

اصل تقسیم و تسخیر در مهندسی موجب پدید اومدن سیستم‌هایی شده که باهم جفت میشن ، بابت همین در مخمدسی نرم افزار همیشه از تفکیک وظایف استقبال میشه

گروه بندی کدهای مرتبط (tightly coupled components) و جداسازی کدهای نامرتبط (loosely coupled components) درک و آزمایش برنامه ها و تعداد باگ‌ها رو در تئوری کاهش میده


همزمانی استراتژی جداسازی هستش، تقسیم وظایف بین ماژولها یا واحدهای همزمان موجب تمرکز قطعات روی عملکردهای خاص میشه قابلیت نگهداری رو بالا میبره و پیچیدگی رو کاهش میده

مهندسین آنچه را انجام میشود از زمانی که انجام میشود تفکیک میکنند این بشکل چشمگیری موجب افزایش عملکرد، مقیاس پذیری، قایلیت اطمینان و ساختار داخلی رو بهبود میده

لینک وبسایت

#concurrency

@code_crafters

همزمانی جایگاه ویژه و مورد استفاده گسترده‌ای در سیستم‌های محاسباتی مدرن، سیستم عامل و خوشه های توزیع پذیر دارد، این مدل سازی از دیدگاه کاربران و توسعه دهندگان کارایی سیستم رو افزایش میده و به توسعه دهندگان اجازه میده تا مشکلات و پیچیدگی رو حل کنن

لایه‌های همزمانی
تصویر اول در کامنت‌ها
مانند اکثر مشکلات پیچیده طراحی، همزمانی با استفاده از چندین لایه ساخته میشود

در یک معماری چند لایه، یک مفهوم متناقض یا منحصر بفرد ممکن در سطوح مختلفی بصورت همزمان وجود و یا دیده بشه

هر لایه فرآیند یکسانی را در سطوح مختلف توصیف می کند، اما جزئیات متفاوت و گاهی متناقضی داره

تصویر دوم در کامنت‌ها رو ببینید

این اتفاق در همزمانی هم روی میده:
در لایه سخت افزار ما با دستورات ماشینی روبرو‌ هستیم که با استفاده از سیگنالها میتوانیم به دیگر تجهیزات جانبی متصل به سخت افزار دسترسی پیدا کنیم ،معماری مدرن پیچیدگی خاص خودش رو داره به همین دلیل بهینه سازی عملکرد برنامه در این معماری نیاز به درک عمیقی از تعاملات برنامه با سخت افزار داریم


لایه سیستم زمان اجرا، با توجه به قرار گیری الگوریتم‌های زمان بندی ،فراخوانهای سیستمی و درایورها در این لایه تاثیر شگرفی بر همزمانی خواهد داشت این لایه توسط سیستم عامل نشان داده میشه و نیاز به درک کاملی از آن داریم

در نهایت، در لایه کاربرد، انتزاعاتی که از نظر روحی به نحوه عملکرد دنیای فیزیکی نزدیک‌تر هستند، در دسترس قرار می‌گیرند. مهندسان نرم افزار کد منبعی را می نویسند که می تواند الگوریتم های پیچیده را پیاده سازی کند و منطق تجاری را نشان دهد. این کد همچنین می تواند جریان اجرا را با استفاده از ویژگی های زبان برنامه نویسی تغییر دهد و به طور کلی مفاهیم بسیار انتزاعی را نشان می دهد که فقط یک مهندس نرم افزار می تواند به آن فکر کند.


لینک وبسایت

#concurrency

@code_crafters

بنچمارکینگ ( benchmark test) چیست؟؟؟

همیشه بحث بر سر کدهامون هست
مدام و مدام کد میزنیم چه در قالب فردی، چه در قالب گروهی و موضوع اصلی همیشه پابرجاست کد ما چقدر خوب و سریع هستش

یک کد رو از دیدگاه‌های مختلفی میشه بررسی کرد سرعت اجرایی اون در حالت‌های مختلف، محک گذاری برای یافتن تنگناها، ناکارآمدی ها و رگرسیون‌ها

تست عملکرد (benchmark) شامل قراردادن کد در معرض عوامل استرس زا و سناریوهای مختلف جهت سنجش پاسخگویی، ثبات و مقیاس پذیری است

از طرفی هم معیارسنجی فرآیند اندازه‌گیری زمان اجرای کد یا استفاده از منابع برای ایجاد یک خط پایه عملکرد و پیگیری تغییرات در طول زمان است

در خصوص موضوع این پست pytest متحد ما خواهد بود و در کنار آن pytest benchmark همراه ما خواهد بود


چرا باید کدهای خود را محک بزنیم؟؟؟

۱-برای بهینه سازی الگوریتم‌ها و تکه‌های کد، شناسایی تنگناهای عملکرد و اعتبارسنجی پیشرفت‌ها 

۲-در مقایسه نسخه‌های متفاوت کمک میکند و اطمینان حاصل میکند که نسخه‌های جدید عملکرد را حفظ یا بهبود داده

۳-به تست سازگاری سخت افزار و پلتفرم کمک میکند و اختلافات را در محیط‌های مختلف برجسته میکند

۴-در خطوط لوله یکپارچه سازی پیوسته،  محک زدن بعنوان یک سیستم هشدار اولیه عمل میکند و از رگرسیون عملکرد جلوگیری میکند(به این معنی که کد جدید بر عملکرد قبلی تاثیر منفی نمیگذارد)

۵-در نهایت کمک میکند تا با مقایسه عملکرد کتابخانه‌ها مختلف، انتخاب‌های فناوری آگاهانه داشته باشیم

و اما BIG O NOTATION (درک این قسمت مناسب مهندسین نرم افزار)
یکی از مسائل بشدت مهم ساختمان داده‌ها و الگوریتم‌ها تحلیل زمانی کد می‌باشد ،این موضوع به ما مهندسین نرم افزار در درک بهتر معیارها و درک اصول اولیه کمک میکند

این نماد بر مهمترین عوامل موثر بر زمان اجرا یا استفاده از منابع الگوریتم تمرکز میکند و جزئیات دقیق‌تر را انتزاع میکند

بعنوان مثال با توجه به ورودی بزرگتر، آیا انتظار می‌رود زمان اجرا کد بصورت خطی، نمایی یا لگاریتمی مقیاس شود
یا زمان اجرا مستقل از اندازه ورودی است؟یعنی صرف نظر از اینکه ورودی چقدر بزرگ است همان زمان را می‌گیرد

دانش BIG O و عملکرد میتونه به ما قدرتی بده که انتخاب‌های آگاهانه‌ای داشته باشیم که در حوزه تست عملکرد ضروری است

پیش نیازها

دانش پایه‌ای از پایتون و ساختارهای داده‌(list, tuple, string)

دانش پایه‌ای از pytest

اندکی دانش از الگوریتم‌ها

pip install pytest
pip install pytest-benchmark

این کتابخونه به ما امکان این رو میده که کدهامون رو تو حالت‌های مختلف و تعداد بالا محک بزنیم با استفاده از pytest گروه بندی کنیم خروجی هارو نگه داریم و هنگام توسعه خروجی‌ها رو با هم مقایسه کنه و اینکه هیستوگرام بنچمارک رو هم برامون رسم کنه


به طور پیش فرض، pytest-benchmark محک گذاری مبتنی بر زمان را انجام می دهد. زمان اجرای کد مورد آزمایش را اندازه گیری می کند و آماری در مورد زمان بندی هر اجرا ارائه می دهد.
که موارد زیر رو شامل میشه

Min
Max
Mean
StdDev
Median
IQR
Outliers
OPS (Mops/s)
Rounds
Iterations

توضیحات رو در کامنت‌ها براتون میزارم

در پست بعدی یک نمونه عملی رو باهم انجام میدیم

لینک وبسایت
#monitoring

@code_crafters

خب بیاید با یک پروژه ساده پیش بریم دایرکتوری کاری ما به شکل زیر خواهد بود

Plbenchmark-test
├── src
│   └── sorting_examples.py
└── test
    ├── conftest.py
    └── test_benchmark.p

از این ریپوزیتوری میتونید دریافت کنید

توضیحات

در داخل فایل sorting_example.py سه الگوریتم مرتب سازی قرار دادیم

در فایل conftest.py دو نوع داده ورودی کوچک و بزرگ برای تست‌هامون ساختیم

در فایل test_benchmark.py تست‌هامون رو نوشتیم

با دستور زیر گروه sort_small رو اجرا میکنیم

pytest -m sort_small -v -s 

و خروجی سه تستی که برای اون نوشتیم رو میبینیم که شامل موارد ذکر شده در پست قبلی میباشد

با دستور زیر میتونیم هیستوگرام اون رو هم ببینیم

pip install pygal

pytest --benchmark-histogram -m sort-larg

هیستوگرام رو در یک تصویر در مسیر جاریتون خواهد ساخت هر تابع تست شده رو به شکل یک کندل نشون میده 

در پست قبلی گفته بودیم که این کتابخونه پیش فرض بر روی زمان اجرا تمرکز دارد با دستور زیر و احرا کردن یک قسمت خاص از کدهای تست میتونید این مورد رو مشاهده کنید

pytest --benchmark-histogram -m benchmark

خروجی تست عملکرد در خط فرمان و هیستوگرام در یک فایل تصویری بصورت کندل

و با دستور زیر در هربار اجرا میتوانید بنچمارک رو ذخیره کنید

pytest -m sort_large --benchmark-autosave

در مسیر جاری و در دایرکتوری benchmarks. این فایل‌هارو مطابق با ورژن پایتون ذخیره میکند در ابتدای هر فایل یک مقدار چهر عددی قرار میده که بعدا از این برای مقابسه دو بنچمارک باهم استفاده میکنیم

جالبه بدونید که مشخصات سخت افزار و نود ،تاریخ و ورژن ، مشخصات پردازنده بصورت و ... روکامل هم ذخیره میکنه تا در هربار بنچمارک بتونید مقایسه کاملی انجام دهید

و اخرین دستور جهت مقایسه دو مقدار بنچمارک ذخیره شده

pytest-benchmark compare 0001 0002

نتایج خروجی رو در خط فرمان میتونید مشاهده کنید


و اما یک سوال
ایا اگر در تابع تستی نیاز به خوندن داده از کسیر خاصی یا دیتابیس خاصی باشد آیا این تایم صرف شده رو در بررسی سطح عملکر و محک تاثیر میده؟؟؟ طبق اسناد این کتابخونه خیر

تصاویر خروجی دستورات در کامنت‌ها

لینک وبسایت

#monitoring

@code_crafters

در ادامه مبحث بنچمارکینگ روی یک پروژه جنگویی پیاده سازی میکنیم و در نهایت با تست عملکرد برای ویوهای ساخته شده با FBV ,CBV بررسی میکنیم عملکرد و محک زدن کدوم بهتره

ابتدا یک پروژه جنگویی همراه یک اپ core ایجاد میکنیم

pip install django

django-admin startproject config .

python manage.py startapp core

در دایرکتوری config

فایل settings.py
INSTALLED_APPS = [
...    
"core",
]

فایل urls.py  
path('', include('core.urls')),

در اپ core کدهای زیر رو وارد میکنیم


models.py

class CategoryModel(models.Model):
    title = models.CharField(max_length=255)

views.py

from django.views.generic import DetailView, ListView
from .models import CategoryModel


def category_list_view(request):
    objs = CategoryModel.objects.all()
    return render(request, 'core/list.html', {"objs":objs})

def category_detail_view(request, pk):
    obj = CategoryModel.objects.get(id=pk)
    return render(request, 'core/detail.html', {"obj":obj})

class CategoryListView(ListView):
    model = CategoryModel
    template_name = 'core/list.html'
    context_object_name = 'objs'

class CategoryDetailView(DetailView):
    model = CategoryModel
    template_name='core/detail.html'
    context_object_name = 'obj'

urls.py

from .views import category_list_view, category_detail_view, CategoryDetailView, CategoryListView

app_name = 'core'

urlpatterns = [
    path('fbv/', category_list_view),
    path('fbv/<pk>/', category_detail_view),
    path('cbv/', CategoryListView.as_view()),
    path('cbv/<pk>/', CategoryDetailView.as_view()),
]

دستورات makemigrations و migrate رو فراموش نکنید

الزامات مربوط به templates در settings و فایلهای list.html , detail.html رو برای اپ core بصورت ساده انجام دهید


جهت راه اندازی بنچمارکینگ نیاز به نصب سه کتابخانه داریم

pip install pytest pytest-benchmark pytest-django

در دایرکتوری root پروژه یک فایل با نام pytest.ini ساخته کدهای زیر رو در ان قرار دهید

[pytest]
DJANGO_SETTINGS_MODULE = config.settings

دلیل اینکار ازین بابت هست که بخشی از کدهای ما وابسته به اجرا شدن پروژه جنگویی می‌باشد و اجرا کردن پروژه جنگویی با صدا زدن فایل تنظیمات آن می‌باشد و به این صورت pytest اینکار رو انجام میدهد


دایرکتوری tests ساخته و داخل ان فایل test_view.py رو میسازیم و کدهای زیر رو داخل اون میزاریم

import pytest
from core.models import CategoryModel
from django.test import RequestFactory
from core.views import category_list_view, category_detail_view, CategoryListView, CategoryDetailView


@pytest.fixture
def rf():
    return RequestFactory()

@pytest.mark.fbv
def test_fbv_list(benchmark, rf):
    request = rf.get('/fbv/')
    result = benchmark(category_list_view, request)
    assert result.status_code == 200

@pytest.mark.fbv
@pytest.mark.django_db
def test_fbv_detail(benchmark, rf):
    blog_comment = CategoryModel.objects.create(title='Test')
    request = rf.get(f'/fbv/{blog_comment.pk}/')
    result = benchmark(category_detail_view, request, pk=blog_comment.pk)
    assert result.status_code == 200

@pytest.mark.cbv
def test_cbv_list(benchmark, rf):
    request = rf.get('/cbv/')
    view = CategoryListView.as_view()
    result = benchmark(view, request)
    assert result.status_code == 200

@pytest.mark.cbv
@pytest.mark.django_db
def test_cbv_detail(benchmark, rf):
    blog_comment = CategoryModel.objects.create(title='Test')
    request = rf.get(f'/cbv/{blog_comment.pk}/')  
    view = CategoryDetailView.as_view()
    result = benchmark(view, request, pk=blog_comment.pk)
    assert result.status_code == 200

دستورات زیر رو در خط فرمان بزنید

pytest -m cbv --benchmark-autosave

pytest -m fbv --benchmark-autosave

pytest-benchmark compare 0001 0002

خروجی بنچمارکینگ و تست عملکرد رو برای ویوهای FBV و CBV در جنگو رو باهم مقایسه کنید


لینک وبسایت

#monitoring

@code_crafters

گرچه بلوچستان در تبعید یکعده هست، اما وجب به وجب خاک آن سرزمین مادری ماست

ممنون از کارخانه x tak بابت فراهم کردن ماشین جهت انتقال کمک‌های مردمی و تمامی مردمان عزیزی که خون در خون انسانیت دارند

فصل دوم کتاب از فصل‌های بشدت محبوب برای من هستش که سعی داره هر اصطلاحی رو در برنامه بنویس بصورت دقیق توصیف کنه


اجرای سریالی و موازی سازی

از بزرگترین معضلات همزمانی و دنیای مهندسی کامپیوتر میتوان به نام گذاری های بد برای توصیف‌ها اشاره کرد ،اسامی نامربوط یا چند اسم داشتن یک موضوع

قبل از بررسی اجرا لازم است خود آنچه اجرا میشود و اصطلاحات مربوط به آن را بشناسیم

یک برنامه بطور کل به مجموعه‌ای از دستورالعمل‌ها گفته میشود که بصورت متوالی اجرا میشود

پردازنده قدرت تحلیل معنایی ندارد، نمیتواند یک جستجو با معنی انجام دهد یا نمیتواند مرتب سازی کند، پردازنده فقط میتونه محدود کارهای ساده‌ای رو انجام بده و تمام تفکر حاصل اون رو برنامه شما مشخص میکنه، تبدیل یک کار به مجموعه‌ای از دستورالعمل‌ها جهت اجرا کاریست که یک توسعه دهنده انجام میدهد

توسعه دهندگان از زبانهای مختلفی جهت پیش برد اهداف خود استفاده میکنن اما پردازنده درکی از کد منبع شما ندارد و تنها زبان ماشین را میفهمد پس لازم هست بیس کدهای شما بوسیله کامپایلر به زبان مناسبی برای پردازنده تبدیل گردد، پردازنده هنگام اجرای کد ماشین میتواند چندین رویکرد داشته باشد که اساسی ترین آن جهت اجرای یک مجموعه دستورالعمل بصورت سریالی است

اجرای سریالی
یک برنامه لیستی از دستورالعمل هاست و البته ترتیب اجرای آن مهم هست

در خصوص برنامه نویسی هم به همین روال هست یک مسئله رو ابتدا به وظایف کوچکی تقسیم میکنیم و سپس آنرا بصورت یکی پس از دیگری یا بصورت سریالی اجرا خواهیم کرد

برنامه نویسی بصورت وظیفه این امکان رو بهمون میده که بصورت مستقل از زبان ماشین محاسبات خود را انجام دهیم که به آن برنامه نویسی ماژولار میگوییم

یک تسک میتواند بخشی از یک کار باشد، اگر جامعه کلامی ما پردازنده باشد میتونیم اون رو یک دستورالعمل بنامیم
یک تسک میتونه یک توالی از عملیات باشه که انتزاعی از یک مدل در دنیای واقعی هست (مثه نوشتن متن در یک فایل)

اما در نهایت میتونیم task رو بعنوان یک واحد اجرا از انتزاع کلی دانست تصویر اول

اجرای سریالی مجموعه‌ای از تسک‌ها هستش که بصورت زنجیروار قرار گرفتن تسک دوم تسک اول رو دنبال میکنه، و تسک دوم توسط تسک سوم دنبال میشه


محاسبات متوالی
برای توصیف پدیده‌های پویا مرتبط با زمان از اصطلاح متوالی استفاده میکنیم تصویر دوم کامنت‌ها برای درک بیشتر یک بازی دونفره رو تصور کنید که نفرات به نوبت و پس از بازی نفر دیگری حق بازی دارند برای درک بهتر بازی شطرنج رو تصور کنید

برنامه دارای مراحل سریال برای حل مشکل است. هر مرحله متکی به نتیجه مرحله قبل است. از این رو، هر مرحله مانع از اجرای مراحل بعدی می شود. ما فقط می توانیم چنین برنامه ای را با استفاده از رویکرد برنامه نویسی متوالی پیاده سازی کنیم. وابستگی آشکاری بین وظایف وجود دارد که به هیچ وجه قابل تجزیه نیست

نقطه مقابل برنامه نویسی متوالی، برنامه ریزی همزمان است. همزمانی بر این ایده استوار است که محاسبات مستقلی وجود دارد که می‌توانند به ترتیب دلخواه با نتیجه یکسان اجرا شوند.

مزایا و معایب محاسبات متوالی
سادگی: هر برنامه ای را میتوان در این پارادایم نوشت یک مفهوم ساده و قابل پیش بینی و رایج است
محاسبات متوالی یک رویکرد ساده با محمچعه‌ای واضح از دستورالعمل‌های گام به گام در مورد اینکه چه باید کرد و در چه زمانی انجام داد هستش

مقیاس پذیری: توانایی یک سیستم برای رسیدگی به مقدار فزاینده‌ای از کار، یا پتانسیل افزایش توانایی سیستم برای رسیدگی به کار برای سازگاری با رشد، با افزودن منابع سخت افزاری اگر بهبودی در سیستم دیده شود سیستم مقیاس پذیر می‌باشد ،اسکیل عمودی تنها راه افزایش مقیاس در محاسبات متوالی هستش

سربار: در محاسبات متوالی هیچ‌ ارتباط یا هماهنگی بین مراحل برنامه مورد نیاز نیست اما یک سربار وجود دارد که ممکن هست از همه منابع استفاده نکنیم


اجرای موازی(parallel)
همانطور که دیدیم، در اجرای سریال، تنها یک دستور در یک زمان اجرا می شود.
برنامه نویسی متوالی همان چیزی است که بیشتر مردم ابتدا یاد می گیرند و اکثر برنامه ها به این صورت نوشته می شوند: اجرا از ابتدای تابع اصلی شروع می شود و به صورت سریالی ادامه می یابد، یک کار/تابع، فراخوانی/عملیات در یک زمان.

وقتی این فرض را حذف می‌کنیم که می‌توانیم فقط یک کار را در یک زمان انجام دهیم، امکان کار موازی را باز می‌کنیم

لینک وب‌سایت

#concurrency

@code_crafters

تصور کنید با شما تماس گرفته و باید سریع به مسافرت برید چهار دست لباس دارید که باید شسته بشن میتونید شروع به شستن کنید اما اگر در نزدیکی شما یک خشکشویی وجود داشته باشد چه؟؟؟سریع به آنجا میروید و همه لباس‌هاتون رو باهم توسط دستگاه‌های متعدد آماده میکنن

در برنامه نویسی زمان لازم برای برای اجرای برنامه متوالی به سرعت پردازنده و سرعت اجرای ان سری از دستورالعمل‌ها محدود میشود مانند شستن لباس توسط خودتون، اما اگر خشکویی وجود داشته باشه چی؟؟؟همه لباس‌ها بصورت موازی شستشو داده میشوند توان عملیاتی شما افزایش می یابد ،در اینجا همان رویکرد اسکیل افقی رو در پیش گرفتیم

اجرای موازی به این معنی است که اجرای کار از نظر فیزیکی همزمان است. اجرای موازی برعکس اجرای سریال است. موازی بودن را می توان با تعداد کارهایی که می توان به صورت موازی اجرا کرد اندازه گیری کرد تصویر اول در کامنت‌ها

استقلال وظیفه در مبحث محاسبات متوالی ما فقط نیاز به پردازنده با کلاک بالاتر بودیم، اما در محاسبات موازی عمدتاً برای کاهش تأخیر با تقسیم یک مسئله به وظایفی که می‌توانند به طور همزمان و مستقل از یکدیگر اجرا شوند، استفاده می‌شود.

استفاده از محاسبات موازی مشکل خاصی است. برای اعمال محاسبات موازی برای یک مسئله، باید این امکان وجود داشته باشد که مسئله به مجموعه ای از وظایف مستقل تجزیه شود تا هر منبع پردازش بتواند بخشی از الگوریتم را به طور همزمان با بقیه اجرا کند. استقلال در اینجا به این معنی است که منابع پردازش می توانند وظایف را به هر ترتیبی که دوست دارند و هر کجا که دوست دارند پردازش کنند، تا زمانی که نتیجه یکسان باشد.
عدم انطباق با این الزام، مشکل را غیرقابل موازی سازی می کند.
کلید درک اینکه آیا یک برنامه می تواند به صورت موازی اجرا شود این است که تجزیه و تحلیل شود که کدام وظایف را می توان تجزیه کرد و کدام وظایف را می توان به طور مستقل اجرا کرد

 برنامه ای که می تواند به صورت موازی اجرا شود، همیشه می تواند متوالی شود، اما یک برنامه متوالی همیشه نمی تواند موازی شود

استقلال کار همیشه امکان پذیر نیست زیرا هر برنامه یا الگوریتمی را نمی توان از ابتدا تا انتها به وظایف مستقل تقسیم کرد. برخی از کارها می توانند مستقل باشند، و برخی نمی توانند اگر به وظایفی که قبلاً اجرا شده اند وابسته باشند.این امر به توسعه دهندگان نیاز دارد تا قطعات مختلف وابسته یک برنامه را برای به دست آوردن نتایج صحیح همگام سازی کنند
همگام سازی به معنای مسدود کردن اجرای وظیفه در انتظار وابستگی است(مثال بازی شطرنج)
هماهنگ کردن محاسبات موازی وابسته به هم از طریق همگام سازی می تواند موازی بودن برنامه را به شدت محدود کند و چالش مهمی را در نوشتن برنامه های موازی در مقایسه با برنامه های متوالی ساده ایجاد می کند.

پشتیبانی سخت افزاری محاسبات موازی نیاز به پشتیبانی سخت افزاری دارد. برنامه های موازی به سخت افزار با منابع پردازشی متعدد نیاز دارند. بدون حداقل دو منبع پردازش، ما نمی توانیم به موازی کاری واقعی دست یابیم

محاسبات موازی
محاسبات موازی از تجزیه برای تقسیم مسائل بزرگ یا پیچیده به وظایف کوچک استفاده می کند و سپس از اجرای موازی سیستم زمان اجرا برای حل موثر آنها استفاده می کند.(برای مثال رویکرد معروف به brute-force)

قانون امدال
اگر فکر میکنید با افزودن منابع بیشتر و موازی سازی کردن بیشتر سرعت رو مدام و مدام افزایش میدهید سخت در اشتباه هستید
تصور کنید سه تسک دارید که زمان اجرایی آنها متفاوت هستش (۱,۴,۳) تسک ۴ رو میتونید به دو تسک دوتایی بشکنید و موازی کنید اما تسک ۳ یک تسک متوالی هست پس هرکاری کنید نمیتونید زمان برنامه رو به کمتر از ۳ برسونید

یک برنامه موازی به سرعت کندترین قسمت متوالی آن اجرا می شود یک فرمول هم داره در تصویر دوم کامنت‌ها

قانون گوستافسون
قانون امدال نباید شما رو نا امید کنه، گوستافسون دیدگاه خوش بینانه تری از محدودیت های موازی ارائه می دهد. اگر مدام حجم کار را افزایش دهیم، قسمت های متوالی اثر کمتر و کمتری خواهند داشت و متناسب با تعداد پردازنده هایی که در اختیار داریم، می توانیم سرعت را مشاهده کنیم
بنابراین اگر زمانی شنیدید که قانون امدال به عنوان دلیلی برای عدم کارایی موازی در مورد شما ذکر شده است، می توانید مشاهده کنید که گوستافسون توضیحی برای آنچه باید انجام دهید داشت.

همزمانی (concurrency) و موازی سازی (parallelism)

همزمانی در مورد وظایف متعددی است که بدون ترتیب خاصی در بازه های زمانی همپوشانی شروع، اجرا و تکمیل میشند

موازی بودن یک ویژگی اجرایی است. این اجرای فیزیکی همزمان وظایف در زمان اجرا است و به سخت افزار با منابع محاسباتی متعدد نیاز دارد روی لایه سخت افزاری قرار دارد

همزمانی و موازی بودن یک چیز نیستند

لینک وب‌سایت

#concurrency

@code_crafters

تفاوت پروفایلینگ و بنچمارکینگ

در چند پست قبلی راجب دو‌موضوع profiling و benchmarking صحبت کردیم
با ابزارهای اون آشنا و بصورت عملی هم اجرا کردیم

تفاوت این دو در چیست؟؟؟
اندازه گیری و بررسی پرفورمنس معمولا شامل دو فرآیند متفاوت است پروفایلینگ و بنچمارکینگ، هر دو روش‌های ضروری برای بهبود عملکرد یک برنامه کاربردی هستند و بسته به موقعیت، تنها تنها یکی از این دو ممکن است اجرا بشه، در حالیکه در موارد دیگر این دو مکمل همدیگه هستند


پروفایلینگ
پروفایلینگ یا نمایه سازی فرآیند جمع اوری معیارها در مورد یک برنامه است. مانند زمان اجرا، حافظه مورد استفاده، تعداد توابع فراخوانی شده و ... در حین اجرای برنامه است. این میتواند زمانی مفید باشد که به دنبال بهینه سازی بخش‌هایی از برنامه هستید


بنچمارکینگ
بنچمارکینگ یا محک زدن فرآیندی است که برای مقایسه دو یا چند سیستم با استفاده از یک اندازه گیری مشترک استفاده میشود تا بتوانید تشخیص دهید کدامیک در برابر آن تست خاص عملکرد بهتری دارد، این برای مقایسه راه حل‌های مختلف نرم افزار یا برای مقایسه تغییرات در نسخه‌های مختلف یک نرم افزار مفید است


در سطح بالایی، تفاوت بین پروفایلینگ و بنچمارکینگ، به بهترین وجه با سوالی که هر تمرین به ترتیب به آن پاسخ میدهد توضیح داده میشود:

پروفایلینگ به شما کمک میکند تا دریابید چرا یک نرم افزار یا زیر سیستم به روش خاصی عمل میکند
بنچمارکینگ به شما کمک میکند تا میزان عملکرد یک نرم افزار یا زیرسیستم را ارزیابی کنید

از آنجایی که هم پروفایلینگ و هم بنچمارکینگ عملکرد را در برخی ظرفیت ها اندازه گیری می کنند، این دو تعریف «چرا در مقابل چقدر خوب» ممکن است هنوز به طور کامل تفاوت آنها را روشن نکنند. نگاه کردن به موقعیت‌های نمونه باید به انتقال تفاوت بین آنها کمک کند:

فرض کنید می‌خواهیم راه‌هایی برای بهبود عملکرد پروژه خود تا آنجا که ممکن است پیدا کنیم:

 برای این کار، باید پروفایل‌سازی را انجام دهیم. ما باید بررسی کنیم که کدام عملکردها طولانی‌ترین زمان را برای اجرا می‌برند تا بتوانیم روی بهبود عملکرد آنهایی که بدترین گلوگاه‌ها هستند تمرکز کنیم. 

فرض کنید می خواهیم عملکرد را بین دو نسخه اصلی پروژه خود مقایسه کنیم تا ببینیم چرخه انتشار دوم چگونه بر عملکرد تأثیر می گذارد. برای این کار، باید بنچمارکینگ انجام دهیم:

 آنها را در مقابل یکدیگر قرار می دهیم و برای مثال، زمان بارگذاری محتوای خاصی را در یک نسخه پروژه خود با زمان بارگذاری همان محتوا در نسخه دیگر مقایسه می کنیم

اساساً، بنچمارک همیشه شامل نوعی مقایسه است:
اگر عملکرد یک نسخه اصلی پروژه را معیار قرار دهیم و هرگز آن را با چیزی مقایسه نکنیم، واقعاً ارزش زیادی ارائه نمی دهد. تا زمانی که آن را با یک نقطه مرجع مقایسه نکنیم، نمی‌توانیم بگوییم که انتشار به‌ویژه خوب است یا نه
با این حال، پروفایل کردن فقط از نگاه یک نسخه ارزشمند است، ما مجبور نیستیم نتایج پروفایل را با مجموعه دیگری از نتایج مقایسه کنیم تا ارزشی از آن بدست آوریم.

یکی دیگر از رابطه‌های بین پروفایلینگ و بنچمارکینگ در توالی آن‌ها است:
در حالی که در برخی موقعیت‌ها، تنها یکی از این دو ممکن است اعمال شود
به طور کلی، پروفایلینگ قبل از اقدام در مورد تغییرات کد اتفاق می‌افتد، در حالی که بنچمارک پس از آن اتفاق می‌افتد

وضعیت زیر را در نظر بگیرید:

-ما می‌خواهیم زمان پاسخ‌دهی سرور اصلی پروژه خود را بهبود بخشیم، بنابراین پروژه را نمایه (profile) می‌کنیم و تشخیص می‌دهیم که یک عملکرد خاص 10٪ از زمان کلی را تشکیل می‌دهد

 -بنابراین ما تصمیم داریم بر روی بهبود عملکرد آن عملکرد تمرکز کنیم، ما منطق را در آن تابع بهبود می‌دهیم تا کارآمدتر باشد، به این امید که تاثیر کلی عملکرد منفی آن را کاهش دهیم

پس از تکمیل تغییر کد، با مقایسه زمان پاسخ سرور قبل از تغییر با زمان پاسخ سرور پس از تغییر، پروژه خود را محک (benchmark) می زنیم تا تأیید کنیم که تغییر (امیدوارم) تا چه اندازه باعث بهبود آن شده است.

لینک وب‌سایت

#monitoring

@code_crafters

اکنون بخش دشوار اینجاست:
بر اساس موارد بالا، ممکن است استدلال کنید که اگر از پروفایل برای شناسایی عملکرد استفاده کنیم، می‌توانیم دوباره نمایه نماییم تا مقایسه کنیم. این از نظر فنی امکان پذیر است، اما بستگی به این دارد که شما در حال تلاش برای رسیدن به این معیار هستید. از آنجایی که ابزارهای نمایه سازی عملکرد تک تک عملکردها را در حین اجرای برنامه ردیابی می کنند، مقداری سربار اضافه می کنند که زمان اجرا را کاهش می دهد، که می تواند تأثیر مربوط به تغییر را تغییر دهد.

یک راه بهتر برای ارزیابی تأثیر کلی عملکرد یک تغییر، گرفتن معیارها با استفاده از ابزارهایی است که استانداردهای عمومی صنعت مانند TTFB را اندازه گیری می کند.

خلاصه بگم TTFB مخفف Time to First Byte است. اگر بخواهیم به دور از هرگونه پیچیدگی معنای آن را بگوییم، یعنی مدت‌زمانی که طول می‌کشد تا اولین بایت از پاسخ سرور به سیستم کاربر درخواست‌کننده برسد. بگذارید قضیه را کمی باز کنیم. یکی از مهم‌ترین کارایی‌های TTFB این است که کند بودن بیش‌ازحد سرور را معلوم می‌کند.

از طرف دیگر، ابزارهای محک‌زدن عملکرد تک تک عملکردها را ردیابی نمی کنند، بلکه فقط قطعات خاصی را که باید به طور صریح پیکربندی شوند، بررسی می کنند.

بنابراین آنها برای شناسایی تنگناهای عملکرد بتن برای بهبود در نرم افزار یا زیر سیستم شما مناسب نیستند.

به طور کلی در نظر داشته باشید که از ابزار مناسب برای کار استفاده کنید. صرف نظر از نمایه سازی یا محک زدن، باید توجه داشت که ابزارها اعداد مختلفی را بین اجراهای مختلف تولید می کنند که به عوامل مختلفی مانند ظرفیت دستگاه شما، حافظه در دسترس و ... بستگی دارد.

یکی از بهترین روش ها برای توضیح این تنوع مورد انتظار، انجام چندگانه است.

بررسی می کند تا تأیید کند که یک رعایت خاص به دلیل ویژگی های محیطی فقط "تصادفی" نبوده است


لینک وب‌سایت

#monitoring

@code_crafters

فصل سوم کتاب همزمانی در پایتون

در این فصل نگاهی عمیقتر به سخت افزار بالاخص cpu انداخته

در سیستم‌های قدیمی پردازنده بسیار ساده بود اما امروز در ساده ترین دستگاه‌ها چند پردازنده وجود دارد، این مارو سوق میده تا برنامه‌های موازی بنویسیم ،لذا درک پردازنده به ما کمک شایانی خواهد کرد تا بتونیم برنامه‌های کاراتری بنویسیم

پردازنده (CPU)
پردازنده‌ها قدیمی مدارهایی بودن که کارهای متفاوتی رو انجام میدادن و عملیات برای دستگاه‌های جانبی پیش میبردن
اما امروز به شکل مدرنتر خودش بر وظیفه اصلی خودش که همون اجرای دستورالعمل‌ هاست متمرکز شده، پردازنده از اجزای مختلفی تشکیل شده

واحدکنترل CU که وظیفه تفسیر دستورالعمل‌های ماشین را دارد

واحد منطق حسابی ALU عملیات حسابی و بیتی رو انجام میده 

به لطف این دو بخش پردازنده امروزی برنامه‌های پیچیده‌تری رو پردازش میکنه

علاوه بر این واحد cache نیز که موجب افزایش بیشتر سرعت در پردازنده شده

زمانیکه یک برنامه رو اجرا میکنید داده‌های اون بر روی RAM قرار میگیرد که در اتصال با پردازنده هستش اما پردازنده بطور مستقیم به RAM دسترسی ندارد توانایی پردازنده برای محاسبه بسیار سریعتر از توانایی RAM برای انتقال داده به پردازنده هستش، به همین دلیل در پردازنده‌های مدرن یک یا چند سطح حافظه کش برای افزایش سرعت قرار دارد

در پست‌های قبلی گفتیم که هنگام خرید دستگاهی اندازه پردازنده یکی از عوامل مهم و تاثیر گذار در قدرت اون دستگاه در کنار فرکانس پردازنده هستش، یکی دیگر از موارد مهم در هنگام خرید همین کش هستش که با نمادهای L1,L2,L3 بر روی دستگاه‌ها نوشته شده و بالا بودن مقدار آن که مقداری مگابایتی هستش یکی موضوعات حائز اهمیت در انتخاب دستگاه بهتر به شمار می رود

کش بعنوان یک میز کار برای پردازنده در نظر بگیرید تصویر اول در کامنت‌ها

کش بسیار سریعتر از RAM هستش و بر روی تراشه پرادزنده قرار دارد ، دستورالعملها رو جهت اجرا در پردازنده را در خود نگه میدارد آنها را بررسی و تحزیه و تحلیل میکند و در صورت نیاز از RAM بازیابی و در حافظه پنهان خود نگه میدارد

تمام دسترسی‌ها و انتقالات موجب تاخیر میشود و کش بابت کاهش این تاخیر قرار گرفته

چرخه اجرای پردازنده
پردازنده یک فرایند مداوم از اجرای دستورالعمل را در مراحل مختلف انجام میده که به عنوان چرخه پردازنده شناخته میشه و در ساده ترین شکل خود در چهار مرحله مختلف به شکل زیر هستش تصویر دوم در کامنت‌ها

۱- واکشی.  CU دستورالعمل را از RAM یا کش واکشی می کند و آن را در CPU کپی می کند.  در این فرآیند، CU از شمارنده‌های مختلفی استفاده می‌کند تا بفهمد چه دستورالعملی باید واکشی شود و کجا آن را پیدا کند

 ۲- دستورالعمل که قبلاً واکشی شده رمزگشایی شده و برای پردازش ارسال می شود
 انواع مختلف دستورالعمل ها کارهای متفاوتی انجام می دهند، بنابراین بسته به نوع دستورالعمل و کد عملیات، باید بدانیم دستورالعمل ها به کدام واحدهای پردازشی ارسال می شود

 ۳- سپس دستور محاسبات به ALU منتقل می شود و اجرا را شروع می کند

۴- پس از تکمیل دستورالعمل، نتیجه در RAM نوشته می شود و دستور بعدی اجرای خود را آغاز می کند

  سپس پردازنده به مرحله 1 برمی گردد تا زمانی که دیگر دستورالعملی برای واکشی باقی نماند

توسعه دهندگان دوست دارن همه چیز رو خودشون کنترل کنن(سخت افزار، خطاها، مدیریت‌ها و اشتراک منابع)
با توجه به رشد سخت افزار متناسب با مدیریت‌های گوناگون اینکار به یک مسئله پیچیده تبدیل شده، لذا امروزه ما از یک مدیر سیستم عامل که یک رابط بین توسعه دهنده و سخت افزار هست بهره میبریم به مجموعه این رابط‌ها فراخوانی سیستم مینامیم که با در اختیار گذاشتن خدمات و ابزارهایی که با سخت افزار در تعامل هستند برنامه‌های کاربردی میتوانند از آن استفاده کنند

سیستم عامل از طریق گذرگاه به منابع سخت افزاری دسترسی دارد، ما دو نوع سطح دسترسی داری فضای کاربر که در اختیار کاربر است و فضای سیستم عامل که زیر آن سخت افزار قرار دارد ، کاربر و برنامه های کاربر نمیتوانند مستقیم با سخت افزار ارتباط بگیرن سخت افزار بشکل کامل در کنترل و احاطه کرنل می باشد


با این درک بیایید نگاهی به ساختار موازی سخت افزار بندازیم، پردازنده دارای تعداد زیادی ALU هستش که میتوانند عملیات حسابی رو شکسته و تجزیه کرده و بصورت موازی با هم پیش ببرند گاهی این موازی سازی در سطح عمیقتر تا یک بیت هم پیش میرود

پردازنده چند هسته‌ای نوعی دیگر از همزمانی هستش که هسته‌ها درون یک تراشه هستند و عملکرد انها جدا از هم هستش حتی هنگام دسترسی به حافظه، سیستم عامل هرکدام را مستقل میبیند تفاوت جزیی با چندپردازندگی دارد و در طول این متن‌ها هردو رو یکسان در نظر میگیریم تصویر سوم کامنت‌ها

لینک وبسایت

#concurrency

@code_crafters

معماری متقارن چند پردازشی SMP
حافظه معمولا سرعت پایینتری نسبت به پردازنده‌ها دارن که این خود موجب تاخیر میشود به همین دلیل امروزه از سیستم‌های چندپردازنده‌ای از SMP استفاده میکنند که با یک فضای آدرس واحد به حافظه مشترک متصل شده و تحت یک سیستم عامل کار میکند، در این معماری پردازنده‌ها توسط یک شبکه ارتباطی از طریق گذرگاه سیستم به هم متصل میشن، هرچند این شبکه‌ها سریع هستن اما اگه پردازنده‌ها نیاز به تبادل با هم داشته باشند از طریق چندکانال صورت میگیرد که انی نیست و در صورت افزایش تعداد منابع در حال تعامل فاصله بینشون موجب تاخیر میشه مجدد، بنابراین در این معماری هر پردازنده کش خصوصی خود را دارد تا ترافیک system bus را کاهش داده و تاخیر کمتری روی میده تصویر اول در کامنت‌ها

جالب ترین ویژگی SMP این است که وجود چندین پردازنده برای کاربر نهایی شفاف است.  سیستم عامل از زمان‌بندی فرآیندها در تک تک پردازنده‌ها و همگام‌سازی بین آن پردازنده‌ها مراقبت می‌کند، با این حال، در چنین سیستم هایی، افزایش تعداد پردازنده های متصل به یک گذرگاه سیستم مشترک، آن را به یک گلوگاه تبدیل می کند.  این مشکل با انسجام کش بدتر می شود، جایی که چندین هسته پردازشگر سلسله مراتب حافظه یکسانی را به اشتراک می گذارند اما کش های داده و دستورالعمل L1 خود را دارند

توسعه پروتکل MESI مشکل انسجام حافظه رو حل کرد ،با ردیابی وضعیت هر کش موجب میشه همه پردازنده‌ها دید ثابتی از داده داشته باشند


تنها راه فراتر رفتن از SMP سیستم‌های توزیع شده هست که در یک شبکه باهم در ارتباط داشته باشند و بدین شکل هر سیستم بعنوان یک خوشه حافظه و کش خودش رو داره و بر بقیه تاثیر نمیزاره


تصویر دوم در کامنت‌ها
طبقه بندی رایانه های موازی بر اساس دستورالعمل ها و جریان داده ها.
دو دسته SISD , MISD مناسب مواری سازی نیستند کار کرده انها بگونه‌ای هستش که یک بلوک از دستورالعمل‌هارو میگیرن و تنها همون رو پیش میبرند

در دسته سوم، یک دستورالعمل، داده های متعدد (SIMD) است که دارای واحدهای کنترل مشترک در چندین هسته است، با این طراحی، تنها یک دستور را می توان به طور همزمان بر روی تمام منابع پردازشی موجود اجرا کرد، که اجازه می دهد همان عملیات روی مجموعه بزرگی از عناصر داده به طور همزمان انجام شود، با این حال، مجموعه دستورالعمل در ماشین‌های SIMD محدود است، و آنها را برای حل مسائل خاصی که نیاز به قدرت محاسباتی بالایی دارند اما تطبیق‌پذیری زیادی ندارند، مناسب می‌سازد، واحدهای پردازش گرافیکی (GPU) نمونه شناخته شده SIMD امروزه هستند
دسته چهارم دستورالعمل های چندگانه، داده های چندگانه (MIMD) است، در اینجا، هر منبع پردازش یک واحد کنترل مستقل دارد
بنابراین، به انواع خاصی از دستورالعمل ها محدود نمی شود و دستورالعمل های مختلف را به طور مستقل بر روی یک بلوک جداگانه از داده ها اجرا می کند، بنابراین، شامل معماری هایی با چندین هسته، چندین CPU یا حتی چندین ماشین می شود تا وظایف مختلف را بتوان به طور همزمان در چندین دستگاه مختلف اجرا کرد

پردازنده‌های گرافیکی برای کارهای محاسباتی تکراری و موازی مانند پردازش تصویر و ویدئو، یادگیری ماشین، شبیه‌سازی‌های مالی و بسیاری دیگر از محاسبات علمی مناسب هستند. عملیاتی مانند جمع و ضرب ماتریس به راحتی با استفاده از یک GPU انجام می شود زیرا اکثر این عملیات در سلول های ماتریس مستقل از یکدیگر و مشابه هستند و بنابراین می توان آنها را موازی کرد تصویر سوم در کامنت‌ها



لینک وبسایت

#concurrency

@code_crafters

کارفرما ازم میپرسه این کد چکاری میکنه و من شروع میکنم به توضیح دادن

#fun

@code_crafters

مراسم پیشوازی از نوروز در مناطق کردستان، فرهنگی دیرینه

پیاپیش نوروز پیروز

#free

@code_crafters

یچی جالب راجب فرهنگ رنگ لباس زنان بهتون بگم

در این مراسمات سه نوع رنگ لباس برای زنان حائز اهمیت هست که صد البته پسر

رنگ لباس سیاه برای دختران به معنای عزادار بودن بابت یکی از نزدیکانش می‌باشد که میتونه شوهرش یا معشوقه‌ش باشه و با پوشیدن این لباس به بقیه اعلان میکنه که فعلا در دسترس برقراری ارتباط نیست و علاقه‌ای نداره

رنگ لباس زرد برای دختران به معنای داشتن معشوقه و یا نامزد هستش و این رو به بقیه میرسونه که نسبت به یکنفر تعهد عاشقانه داره

رنگ قرمز برای لباس دختران به معنای مجرد بودن و آمادگی انتخاب برای یک رابطه عاشقانه و ازدواج هستش (پسرها برن شانس خودشون رو امتحان کنن) نکته جالب اینجا اگه دختری لباس قرمز بپوشه و در این مراسمات خودش رو به پسری نشون بده و جلوش چندبار ظاهر بشه به این معناست که نسبت به اون پسر علاقه داره و ازش میخواد که اگه اون هم حسی داره بابت پیشنهاد پیش قدم بشه

دیگه از خاطرات این فرهنگ دیرینه نگیم براتون😅😅😅😅

داکر و ۱۳ ترفند مهم در آن


داکر به یک ابزار مهم خط لوله برای توسعه، استقرار و تست برنامه در دنیای مدرن مهندسی تبدیل شده، در حالیکه بیشتر کاربران با مسائل پایه و دستورات اولیه آن اشنا هستند اینجا وجود داره یکسری ویژگی‌ها و ترفندهایی که کار کردن رو ساده و توسعه رو بهتر میکنه

در اینجا 13 ترفند داکر رو با موضوعیتی برای مهندسین ارشد بررسی میکنیم که فراتر از اصول اولیه هستند و راه های قدرتمند و کمتر شناخته شده ای را برای استفاده از داکر ارائه معرفی میکنیم


1-ساخت چند مرحله‌ای برای تصاویر (image) کارآمد
ساخت‌های چند مرحله‌ای در داکر یک تکنیک قدرتمند برای ایجاد تصاویری ناب و ایمن‌تر با جدا کردن محیط ساخت از محیط تولید در همان داکرفایل است

ساخت چندمرحله‌ای چیست
ساخت چندمرحله‌ای در ساخت تصاویر این امکان رو به ما میدن که در داکر فایل از چند دستور FROM استفاده کنیم، هر دستورالعمل FROM میتونه از بیس متفاوتی استفاده کنه و هر استیج نام خودش رو داشته باشه، بدینگونه شما میتونید مصنوعات رو از یک استیج به دیگری کپی کرده و هر قسمت رو که لازم ندارید پشت سر بگذارید

# Syntax for multi-stage builds
# Stage 1: Build the application
FROM golang:1.15 AS builder
WORKDIR /app
COPY . .
RUN go build -o myapp .

# Stage 2: Create the final image
FROM alpine:latest
COPY --from=builder /app/myapp /app/myapp
ENTRYPOINT ["/app/myapp"]

این مثال یک ساخت ساده چند مرحله ای برای یک برنامه Go را نشان می دهد. مرحله ساخت از یک تصویر گولنگ برای کامپایل برنامه استفاده می کند و مرحله نهایی یک تصویر سبک وزن alpine رو می سازه که فقط شامل باینری کامپایل شده هستش


چه وقتی شما از ساخت چند مرحله‌ای استفاده میکنید

کاهش اندازه تصویر: زمانی که فرآیند ساخت برنامه شما شامل کامپایل کد یا شامل وابستگی های زمان ساخت است که در زمان اجرا مورد نیاز نیستند

افزایش امنیت: برای به حداقل رساندن سطح حمله تصویر نهایی خود با حذف ابزارها و فایل هایی که برای اجرای برنامه مورد نیاز نیستند

جداسازی محیط های ساخت: زمانی که نیاز به ساخت برنامه های کاربردی در یک محیط خاص دارید اما می خواهید آنها را در محیط دیگری اجرا کنید.

بهترین رویکرد

بهینه سازی استفاده از کش ساخت:
دستورات کپی را سفارشی کنید و با دقت اجرا کنید تا ذخیره لایه ها به حداکثر برسد

کوچک کردن اندازه تصویر نهایی: فقط مصنوعات مورد نیاز برای اجرای برنامه را در تصویر نهایی کپی کنید

مراحل ساخت برچسب: از مراحل نامگذاری شده برای بهبود خوانایی و قابلیت نگهداری داکرفایل خود استفاده کنید

دام‌های رایج
پیچیدگی بیش از حد: از ساخت‌های پیچیده چند مرحله‌ای غیرضروری که می‌تواند منجر به نگهداری داکرفایل دشوار شود، اجتناب کنید

نادیده گرفتن زمینه ساخت: حواستان به زمینه ساختی باشد که به daemon داکر ارسال می کنید، زیرا زمینه های بزرگ غیر ضروری می توانند روند ساخت را کند کنند

لینک وبسایت

#docker

@code_crafters

2-له کردن (Squashing) لایه‌های ایمیج داکر
له کردن لایه های تصویر در داکر تکنیکی است که می تواند اندازه تصاویر داکر شما را به میزان قابل توجهی کاهش دهد.با ترکیب تمام لایه های تولید شده در طول ساخت تصویر در یک لایه، می‌توانید ذخیره سازی و توزیع تصاویر داکر خود را بهینه کنید

له کردن چیست
هنگامی که یک تصویر داکر می سازید، هر دستورالعمل در داکرفایل یک لایه جدید ایجاد می کند.این لایه‌ها می‌توانند داده‌های غیرضروری را جمع‌آوری کنند که منجر به ایجاد تصاویر متورم می‌شود. (له کردن) Squashing تعداد لایه ها را در تصاویر داکر با ادغام آنها در یک لایه کاهش می دهد، که می تواند به حداقل رساندن اندازه تصویر کمک کند

چگونه از له کردن استفاده کنیم
برای له کردن لایه‌های تصویر، می‌توانید هنگام ساخت تصاویر خود با فعال کردن Docker BuildKit از فلگ sqash-- استفاده کنید

# Enable Docker BuildKit
export DOCKER_BUILDKIT=1

# Build and squash the image
docker build --tag myapp:latest --squash .

چه وقتی از له کردن استفاده کنیم
بهینه سازی اندازه تصویر: زمانی که نیاز به کاهش اندازه تصویر نهایی داکر خود دارید، از squashing استفاده کنید، به خصوص هنگام توزیع تصاویر در یک شبکه یا ذخیره آنها در یک رجیستری

ساده سازی لایه های تصویر: اگر داکرفایل شما حاوی دستورالعمل های اجرا یا کپی زیادی است که تعداد لایه ها و اندازه کلی تصویر را افزایش می دهد


بهترین رویکرد
له کردن انتخابی: در نظر بگیرید که کدام تصاویر بیشتر از له کردن سود می برند. ممکن است برخی از لایه‌ها برای اهداف ذخیره‌سازی، به‌ویژه در حین توسعه، بدون شکست باقی بمانند.

مراقب ذخیره سازی باشید: Squashing می تواند بر مکانیسم کش لایه Docker تأثیر بگذارد. له کردن مکرر ممکن است منجر به زمان ساخت طولانی‌تر شود، زیرا داکر نمی‌تواند لایه‌های میانی را به طور موثر کش کند.

پیامدهای امنیتی: بدانید که له کردن ممکن است تاریخچه یک تصویر را پنهان کند. اطمینان حاصل کنید که لایه نهایی له شده سهوا حاوی داده های حساسی نیست که در لایه های میانی دور ریخته می شوند.

دام‌های رایج
استفاده بیش از حد در طول توسعه: له کردن پس از هر ساخت در طول توسعه می تواند به دلیل از بین رفتن مزایای ذخیره سازی، زمان ساخت را به طور قابل توجهی کاهش دهد.

نادیده گرفتن وضعیت آزمایشی: به یاد داشته باشید که ویژگی squash آزمایشی است و ممکن است در نسخه‌ها یا پیکربندی‌های مختلف داکر به طور مداوم رفتار نکند

لینک وبسایت

#docker

@code_crafters

3-docker buildkit secret

داکر BuildKit راه امن تری را برای رسیدگی به سکرت‌ها در طول فرآیند ساخت معرفی می کند و چالش استفاده از منابع خصوصی را بدون افشای آنها در تصویر نهایی برطرف می کند. قابلیت‌های مدیریت مخفی BuildKit به شما این امکان را می‌دهد که اطلاعات حساس را در طول ساخت بدون باقی ماندن ردی در لایه‌های تصویر ارسال کنید.

داکر buildkit سکرت چیست
یک ویژگی سیستم ساخت داکر buildkit است. این به شما این امکان رو میده تا اطلاعات مخفی و سکرت (مانند رمزهای عبور، کلیدهای خصوصی یا نشانه های API) را به طور ایمن به فرآیند ساخت منتقل کنید. این سکرت‌ها در تصویر نهایی یا در لایه‌های میانی ذخیره نمی‌شوند و فرآیند ساخت شما را امن‌تر می‌کنند


چگونه از داکر buildkit سکرت استفاده کنیم
برای استفاده از داکر BuildKit سکرت، ابتدا مطمئن شوید که Docker BuildKit فعال است.می توانید این کار را با تنظیم متغیر محیطی DOCKER_BUILDKIT=1 انجام دهید. سپس، از فلگ secret-- در طول فرآیند ساخت برای ارائه رازها استفاده کنید

# Enable Docker BuildKit
export DOCKER_BUILDKIT=1

# Build with a secret
docker build --secret id=mysecret,src=/path/to/secret/file.txt -t myapp:latest .

چه وقتی از داکر buildkit سکرت استفاده کنیم
دسترسی به مخازن خصوصی Git: زمانی که ساخت شما نیاز به pull کردن وابستگی ها از مخازن خصوصی دارد(یک پکیج خصوصی توسعه داده‌اید و در اکانت خودتون گذاشته‌اید)

استفاده از کلیدهای خصوصی: زمانی که نیاز به استفاده از کلیدهای خصوصی برای دسترسی SSH یا رمزگشایی فایل ها در حین ساخت دارید

توکن های API: زمانی که فرآیند ساخت شما شامل دسترسی به API هایی است که نیاز به احراز هویت دارند


بهترین رویکرد
به حداقل رساندن قرار گرفتن در معرض مخفیانه: فقط در صورت لزوم از اسرار استفاده کنید و از ثبت یا افشای آنها در مراحل میانی خودداری کنید

اسکوپ‌های سکرت: اسرار را به وضوح تعریف کرده و به مراحل ساخت خاصی که در آن مورد نیاز است، بسط دهید و خطر مواجهه را کاهش دهید

نسخه pinning : همیشه هنگام استفاده از ویژگی‌های BuildKit، نسخه نحو را در داکر خود پین کنید تا از سازگاری و پیش‌بینی‌پذیری اطمینان حاصل کنید.

دام‌های رایج:
کدگذاری بصورت سخت (hardcoding): از کدگذاری بصورتسخت یا استفاده از روش‌های منسوخ (مثلاً ARG برای انتقال سکرت) که ممکن است اطلاعات حساسی را در لایه‌های تصویر باقی بگذارند، خودداری کنید

در شرف پاکسازی: با بازرسی لایه‌های نهایی یا ایجاد سهوا لایه‌های ذخیره‌سازی با داده‌های مخفی، مطمئن شوید که هیچ باقی‌مانده مخفی در تصویر باقی نمانده است

توضیحات تکمیلی
ویژگی buildkit در نسخه‌های جدید داکر و داکرکامپوز بصورت پیش فرض فعال می باشد که با تکنیک‌های خاصی سرعت ایجاد تصاویر رو افزایش میده

در خصوص pinning قابلیتی که به شما این امکان رو میده تا از نسخه‌های خاصی از ابزارها و وابستگی‌ها استفاده کنند، که در یک فایل با نام build.yml نوشته میشه و در کنار داکرفایل قرار میگیرد برای مثال در پایتون و جنگو داکرفایل ما بصورت زیر می باشد

FROM python:3.9

RUN pip install --upgrade pip

RUN pip install django==4.1.5

COPY . /app

CMD python manage.py runserver 0.0.0.0:8000

و فایل build.yml ما بصورت زیر خواهد بود

build:
  pins:
    - name: python
      version: "3.9"
    - name: pip
      version: "22.3.1"
    - name: django
      version: "4.1.5"

این فایل محدودیت استفاده از ابزار و نسخه خاص رو بر روی داکر ایجاد میکند، موجب افزایش امنیت و رعایت وابستگی‌ها میشه و ایمیج‌های تکرار شونده رو براتون بوجود میاره ، اما انعطاف شمارو در ساخت ایمیج پایین میاره

لینک وبسایت

#docker

@code_crafters

4-اهرم dockerignore.
فایل .dockerignore نقش مهمی در بهینه‌سازی ساخت‌های Docker بازی می‌کند، زیرا به شما امکان می‌دهد الگوهایی را مشخص کنید که فایل‌ها و دایرکتوری‌ها را از متن ارسال شده به Daemon داکر حذف می‌کند. این مکانیسم می تواند به طور قابل توجهی روند ساخت را سرعت ببخشد، اندازه زمینه ساخت را کاهش دهد و با حذف فایل های حساس، امنیت را افزایش دهد

این dockerignore چیست
مانند gitignore.، فایل .dockerignore به داکر می‌گوید کدام فایل‌ها و دایرکتوری‌ها را هنگام ساختن یک تصویر نادیده بگیرد.این امر به ویژه مهم است زیرا هر فایلی که به عنوان بخشی از زمینه ساخت به Daemon داکر ارسال می شود، می تواند زمان ساخت و پیچیدگی غیر ضروری را به خصوص در پروژه های بزرگ افزایش دهد.

استفاده از dockerignore
یک فایل .dockerignore در ریشه پروژه خود، جایی که Dockerfile شما قرار دارد، ایجاد کنید. در این فایل، الگوهایی را برای فایل‌ها و دایرکتوری‌ها مشخص کنید تا از زمینه ساخت Docker حذف شوند.

نمونه ای از فایل .dockerignore

.git
.gitignore
Dockerfile*
*.md
node_modules
temp/

چه وقتی از dockerignore استفاده کنیم
مخازن بزرگ: برای پروژه هایی با حجم زیاد داده، به خصوص آنهایی که برای ساخت یا زمان اجرا مورد نیاز نیستند

اطلاعات حساس: برای حذف فایل‌های حاوی سکرت‌ها(env.) یا اطلاعات حساسی که نباید در زمینه ساخت Docker گنجانده شوند

دایرکتوری‌های وابستگی: برای زبان‌هایی که وابستگی‌ها را در فهرست‌های محلی دانلود می‌کنند (مانند venv در پایتون)، که اگر در حین ساخت، وابستگی‌ها را نصب می‌کنید، در زمینه ساخت مورد نیاز نیستند

بهترین رویکرد
مرتباً مرور کنید: به‌طور دوره‌ای فایل .dockerignore خود را بررسی کنید تا مطمئن شوید که با ساختار و الزامات پروژه شما به‌روز است

الگوهای واضح: از الگوهای صریح استفاده کنید تا فایل ها و دایرکتوری های مورد نظر را دقیقاً مطابقت دهند و از حذف ناخواسته اجتناب کنید

حفظ امنیت: از .dockerignore برای تقویت امنیت با اطمینان از اینکه فقط فایل های لازم در زمینه ساخت شما گنجانده شده است، استفاده کنید

دام‌های رایج
نادیده گرفتن .dockerignore: عدم استفاده یا پیکربندی صحیح فایل .dockerignore می تواند منجر به ساخت کند، اندازه تصویر بزرگتر و گنجاندن احتمالی اطلاعات حساس شود

حذف بیش از حد: در حالی که حذف فایل‌های غیر ضروری مهم است، مراقب باشید فایل‌هایی را که برای فرآیند ساخت ضروری هستند حذف نکنید، که می‌تواند منجر به شکست ساخت یا رفتار نادرست تصویر شود.

لینک وبسایت

#docker

@code_crafters