حین اینکه منتظر ماشین فرودگاه بودم دوست ترکم “باران” برام یه کلیپ از یه پیج فارسی فرستاد که داشت اموزش کلمات فارسی رو میداد و بهم گفت یه سری کلمات مثل: جنگ، صلح و مذاکره توی ترکی هم استفاده میشدن… دلیلی شد براش شاهنامه رو فرستادم و داستان فردوسی رو توضیح دادم، ناخوداگاه خودم رو وسط ویکیپدیا گردی دیدم و به شخص عجیبی رسیدم:

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

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

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

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

بیش باد!

@knowpow

سورس Seastar رو بریم تو کارش یا چی؟!

https://github.com/scylladb/seastar

@knowpow

خب رسیدیم به محبوب اینروزای من: Seastar

تو این مجموعه پست ها میخوام تلاش کنم یه دید کلی از پروژه seastar بهتون بدم طوری که بدونین چرا با وجود کتابخونه های async نیاز بوده که برن و چیزی مثل seastar رو بنویسن؟! کاراییش کجاست؟ معماری shared nothing چیه و چرا داره استفاده میکنه؟ معماریش چطور میتونه کمکش کنه که high performance باشه و اصلا چرا باید همچین چیزی وجود داشته باشه؟

پست اول، مقدمه ای بر Seastar

استارت فریمورک Seastar توسط Avi Kivity توی سال ۲۰۱۵ زده شد، هدف اصلی نوشتن الهام و کاربرد اولیه Seastar بازنویسی Cassandra بود و دیتابیس ScyllaDB رو توسعه دادن. حتی توی مقاله ‌ای که درباره ی ScyllaDB نوشتن گفتن که ادعای افزایش ده برابری پرفورمنس(نسبت به کدنویسی جاوا و استفاده از قفل‌ ها و روش‌های معمولی که برای ترد ها استفاده میشد) به کل برگرفته از قدرت استفاده از Seastar عه.

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

حالا چرا پرفورمنسش بالاست؟!
بخش عمده‌ی افت پرفورمنس زمانی اتفاق می‌افته که CPU به‌جای اجرای دستور(حتی شده یه فورلوپ) تو حالت idle منتظر completion یه عملیات I/O یا آزاد شدن یه قفل بمونه.
هر نوع synchronization بین هسته‌ها چه از طریق mutex و چه cache line sharing باعث stall شدن pipeline و افت کارایی شدید میشه! درسته توی فریمورکای معمول مثل اسپرینگ بوت و... به چشم نمیاد ولی اگه قراره یه سیستم های پرفورمنس بسازیم اینجا اولین نقطه ایه که باید اصلاح بشه!
این تأخیرهای ظاهرا کوچک تو مقیاس بالا به latency بالا و عملکرد پایین ختم میشن.

یعنی فرض کنید ما یه برنامه ی مولتی ترد داریم که دارن روی یه پورت گوش میدن و منتظرن کانکشن جدید بیاد تا accept کنن و بعد شروع کنن به خوندن ازش و جواب دادن بهش! تا اینجا همه چی زیباست و خوب کار میکنه ولی مشکل اینجاست که همشون دارن کانکشن های جدید رو توی یه لیست مشترک نگهداری میکنن، ممکنه دوتا کلاینت توی یه لحظه وصل بشن و دوتا ترد همزمان بخوان لیست رو تغییر بدن پس مجبورن از قفل روی لیست استفاده کنن و بوم! اینجا پرفومنسمون ترکید! درسته این روش کار میکنه و خیلی هم زیباست و خیلی از فریمورکا دارن همین الان همینکارو میکنن ولی ما نمیخواییم که یه فریمورک عمومی باشیم! میخواییم یه فریمورک های پروفومنس بسازیم، پس چیکار کنیم؟ راه حل: معماری Shared Nothing

معماری Shared Nothing
قبلا اینجا صحبت کردم در موردش که چرا نیاز داریم

خب گفتم که هدفم zero context switch هست و باید برای اون معماری رو تغییر میدادم، حالا کاری که کردم اینه که اومدم یه io_context تعریف کردم که هر فید برای خودش، تایمراش و کانکشنایی که داره با این context کار میکنن، یعنی فرض کنین من میخوام با binance_feed وصل بشم به بایننس و مجبورم براش یه io context بسازم، هر io context یه ترد داره که میاد boost::asio::io_context رو روی یه ترد پین میکنه و روی اون اجرا میکنه.

حالا قسمت زیبای ماجرا اینجاست که این io context رو حتما باید به یه هسته ی cpu پین کنیم تا کرنل نیاد با عشق خودش بین هسته ها این ترد رو بازی بده، پس تا اینجا داریم که یه io context میسازیم و به یه هسته پینش میکنیم و بعد پاس میدیم به یه feed.

پس کاری که میکنیم اینه که میاییم جای اینکه یه ترد پول باز کنیم به تعداد هسته های ماشینمون ترد باز میکنیم و اونارو به هر هسته پین میکنیم، بعد روی هر هسته ایونت لوپ رو باز میکنیم و روی هر ترد به یک پورت واحد گوش میدیم(کرنل اینجا خودش هندل میکنه و اجازه میده از چندین ترد روی یه پورت گوش بدم که اینجا در موردش گفتم) و بعد هر کانکشنی که میاد با توجه به کانفیگ کرنل بین کانکشنا توزیع میشه و هر ترد هم لیست کانکشنایی که خودش نگهداشته رو داره، دیگه نیازی به این نیست که ترد ها بین همدیگه لیست کانکشن نگهدارن!
هیچی نباید بینشون رد و بدل بشه، مگر اینکه روی یه مدل از lock-free data structure باشه!

خلاصه اینکه Seastar اومده همه‌ی اون چیزایی که همیشه پرفورمنس رو می‌کشتن مثل قفل، context switch و اشتراک حافظه رو بندازه دور.
هر هسته کار خودشو می‌کنه، بدون اینکه مزاحم بقیه بشه و نتیجه‌اش یه فریمورکه که می‌تونه از هر CPU تا آخرین سیکلش استفاده کنه.

تو پست بعدی می‌رم سراغ این که Seastar دقیقاً چجوری این کارو می‌کنه، با reactor و futureهاش که مغز سیستمن

@knowpow

همیشه خطر از درون زبان ساطع نمیشه! در طرز پیاده‌سازی ما و نحوهٔ بیان به وجود میاد:

https://www.youtube.com/watch?v=PcerWZRm_eA

در ++C خودِ bool خطرناک نیست؛ خطر اصلی اینه که bool خیلی راحت و بی‌صدا وارد جاهایی می‌شه که معنی کد رو مبهم، شکننده و اشتباه‌پذیر می‌کنه. عنوان ویدیو هم همین را می‌گوید: Bool - Implicitly Dangerous؛ یعنی «بولین، به‌خاطر ضمنی بودنش خطرناک است». ویدیو جزو Lightning Talkهای CppCon 2025 است و مدت کوتاهی دارد.

به این کد دقت کنید:

createUser("Kambiz", true, false, true);

این کد از نظر کامپایلر کاملاً درست است، ولی برای انسان فاجعه است.
true یعنی چی؟ ادمین است؟ فعال است؟ ایمیل تأیید شده؟ لاگ بگیرد؟ رونویسی کند؟ چه کار کند؟

مشکل وقتی بدتر می‌شود که جای true و false را اشتباه بزنی و کامپایلر هیچ چیزی نگوید:

setWindow(true, false);

پس یکی از پیام‌های اصلی این است: bool در API عمومی، مخصوصاً به‌عنوان پارامتر تابع، اغلب بوی بد طراحی است.

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

enum class Fullscreen : bool { no, yes };
enum class Resizable  : bool { no, yes };

void setWindow(Fullscreen fullscreen, Resizable resizable);

setWindow(Fullscreen::yes, Resizable::no);

اینجا دیگر کد خودش توضیح می‌دهد چه می‌کند و اشتباه جابه‌جا کردن پارامترها هم سخت‌تر می‌شود.

یا مثلاً به‌جای این:

save(file, true);

بهتر است این باشد:

enum class Overwrite {
    no,
    yes
};

save(file, Overwrite::yes);

یک خطر دیگر bool در ++C، تبدیل‌های ضمنی است. چیزهای مختلف می‌توانند به bool تبدیل شوند: pointerها، عددها، بعضی objectها با operator bool و غیره. این گاهی مفید است:

if (ptr) {
    // pointer is not null
}

ولی در طراحی API می‌تواند باعث رفتارهای ناخواسته شود؛ مخصوصاً وقتی overloadها یا constructorها درگیر شوند.

جمع‌بندی ساده‌اش:

از bool برای state داخلی ساده مشکلی نیست.

برای مثال:

bool isConnected = false;

ولی برای APIهایی که خوانایی و امنیت مهم است، مخصوصاً وقتی تابع چند تا bool می‌گیرد، بهتر است از enum class، type wrapper، یا option struct استفاده کنی.

مثلاً این:

connect(server, true, false, true);

بهتر است اینگونه باشد:

struct ConnectionOptions {
    bool enableTls = true;
    bool allowReconnect = false;
    bool verboseLogging = true;
};

connect(server, ConnectionOptions{
    .enableTls = true,
    .allowReconnect = false,
    .verboseLogging = true
});

حرف نهایی Jeff Garland این است:
نوع bool ساده‌ترین type به نظر می‌رسد، اما چون معنی را حمل نمی‌کند، در طراحی API می‌تواند یکی از مبهم‌ترین و خطرناک‌ترین انتخاب‌ها باشد.

#cpp #cplusplus #notes #api #design

Failure is an option here. If things are not failing, you are not innovating enough.

@knowpow

هرچیزی که به عنوان برنامه نویس باید از حافظه‌ی سیستم بدونید:
https://people.freebsd.org/~lstewart/articles/cpumemory.pdf

🐈‍⬛ Learning Theory Circle — Session 3

We're holding a biweekly reading group on the theory of deep learning. Every other Sunday, one person presents a paper followed by an open discussion.

🗓 Sunday, Aug 30 · 7:00 PM
(Tehran, UTC+3:30)

🎤 Shayan Shahrabi-Farahani

📄 "The Lottery Ticket Hypothesis: Finding Sparse, Trainable Neural Networks"

🎥 On Google Meet

🔗 Schedule, links & past talks: learning-theory-circle.github.io

Want to present a future session? Get in touch or open a PR on the webpage. See you Sunday!

@SingularThinker

بچه ها واقعا توصیه میکنم که این ارائه ها رو از دست ندید و برای دوستاتون و تو گروه ها هم بفرستید.
پیپری که شایان داره ارائه میده ۶ هزار ارجاع داره از سال ۲۰۱۹ که نشونه اهمیت زیاد این موضوع هست.
و ارزش افزوده این جلسه صرفا ارائه ما نیستش اون گفتگویی هست که بعدش شکل میگیره و در نهایت داریم سعی میکنی در مسیر community شدن هم پیش بریم.
تازه کسایی که جلسات رو فعالانه شرکت میکنن و تا آخر میمونن به After party هم دعوت میشن.

فیلم جلسات قبلی رو در یوتیوب میتونید ببینید:
https://www.youtube.com/watch?v=8z3oVPGt3eA&t=17s

https://www.youtube.com/watch?v=Kp-tXx1AMBE&t=2737s&pp=0gcJCRMMAYcqIYzv

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

https://www.youtube.com/watch?v=9GSH8tVnCqs

خب مسئله چی بود؟

فرض کنین یه HTTP server داریم که فقط یه رکویست می‌گیره و مثلا زمان فعلی رو برمیگردونه.

رکویست وارد ماشین میشه و از NIC و TCP stack رد میشه، میرسه به لایه ی اپلیکیشن و در نهایت میوفته توی controller فریمورک ما.
حالا دقیقا همون‌جا breakpoint می‌ذاریم و پروسس رو pause می‌کنیم. فرض هم می‌کنیم هیچ timeout، proxy یا مکانیزم دیگه‌ای توی این فاصله کانکشن رو نبنده، پس TCP connection همچنان بازه.

حالا سوال اینه: اگه به هر روشی از یه پروسس دیگه به همون سوکت دسترسی پیدا کنیم، میتونیم قبل از اینکه پروسس اصلی ادامه پیدا کنه، یه HTTP response فیک روی همون کانکشن برای کلاینت بفرستیم؟

در حالت عادی نه، چون fdها داخل هر پروسس معنی دارن. یعنی fd شماره‌ی 10 توی پروسس A لزوما هیچ ربطی به fd شماره‌ی 10 توی پروسس B نداره. ولی اگه پروسس دوم واقعا reference همون socket رو داشته باشه، مثلا از طریق fork، پاس دادن fd با SCM_RIGHTS یا مکانیزم‌هایی مثل pidfd_getfd، اون پروسس هم می‌تونه روی همون socket send() یا write() انجام بده.

اینجا TCP هیچ مشکلی با قضیه نداره؟ معلومه نه، TCP اصلا نمی‌دونه این write() رو کدوم PID انجام داده و براش مهم هم نیست. هر دو پروسس دارن روی همون سوکت کرنل می‌نویسن و کرنل همون TCP state مشترک رو مدیریت می‌کنه: sequence numberها، ACKها، retransmission، segmentation و بقیه‌ی ماجرا و یعنی اگه پروسس دوم روی همون سوکت واقعی send() بزنه، قرار نیست sequence numberها قاطی بشن و از دید TCP فقط یه byte stream وجود داره.

نکته‌ی مهم اینه که این با raw packet injection فرق داره. اگه از همون سوکت معمولی استفاده کنیم، کرنل کاملا در جریان داده‌ایه که ارسال شده و TCP state رو درست جلو میبره. ولی اگه خارج از اون سوکت با packet دست‌ساز با sequence number دستی تزریقی انجام بشه کرنل ممکنه اصلا ندونه این بایت ها ارسال شدن و وضعیت خودش با کلاینت همگام نباشه.

حالا سوال اصلی: کلاینت میفهمه اون پروسسی که قرار بوده جواب بده pause بوده و یه پروسس دیگه جواب رو نوشته؟

در سطح TCP و HTTP نه
کلاینت به یه PID وصل نیست؛ به یه TCP connection وصله. روی سیم هم در نهایت چیزی به اسم PID یا «این bytes رو فلان پروسس که خسته بود نوشته» نداریم. اگه پروسس دوم واقعا به همون سوکت دسترسی داشته باشه و یه HTTP response معتبر بفرسته کلاینت از دید پروتکل نمیتونه بفهمه این response رو پروسس اصلی نوشته یا پروسس دیگه.

یه دلیلی هم که توی اندروید و ای‌او‌اس شما نمیتونی raw سوکت باز کنی همینه!

@knowpow

این raw socket ابزار و مفهوم مهم و کاربردی تو networking محسوب میشه، اگه کارای اداری ولم کنه امروز یه پست دیگه درموردش میزارم عشق کنیم

🎙 گزارش کار #۲ — جونیورها و AI Agentها
این اپیزود از یه سؤال شروع شد:
وقتی AI Agentها دارن بخش بزرگی از کار توسعه نرم‌افزار رو انجام می‌دن، تکلیف جونیورها چی می‌شه؟
بحث فقط این نیست که AI می‌تونه سریع‌تر کد بنویسه. مسئله اینه که بخش زیادی از چیزهایی که یه برنامه‌نویس تازه‌کار قبلاً با انجام‌دادنشون یاد می‌گرفت — سرچ کردن، اشتباه کردن، دیباگ کردن، خوندن کد بقیه و کلنجار رفتن با مسئله — حالا می‌تونه به یک Agent سپرده بشه.
از اون طرف، همین ابزارها می‌تونن یه جونیور رو خیلی زودتر وارد مسئله‌های واقعی و کارهای جدی‌تر کنن.
توی این قسمت درباره همین تناقض حرف می‌زنم؛ اینکه AI Agentها چه تغییری توی مسیر رشد توسعه‌دهنده‌های تازه‌کار ایجاد می‌کنن و شاید سؤال درست دیگه این نباشه که:
«AI جای جونیورها رو می‌گیره؟»
بلکه این باشه:
«جونیوری که قراره کنار AI کار کنه، باید چه چیزهایی بلد باشه؟»
🎧 حدود ۲۲ دقیقه
🎙 گزارش کار — اپیزود دوم
Juniors & AI Agents
اگه با جونیورها کار می‌کنید، خودتون اول مسیر توسعه‌اید، یا این روزها Agentها بخش جدی‌ای از کارتون شدن، خیلی دوست دارم بعد از شنیدنش نظرتون رو بدونم.
#گزارش_کار #هوش_مصنوعی #AIAgents #برنامه_نویسی #توسعه_نرم_افزار

توییتر یه سری پروژه پیشنهاد داده بودم که توشون async io هم بود که یکی از بچه ها گفت هرکسی میخواد async رو بزنه tehrun بزاره اسمش رو، دیدم اسم جالبیه و خودمم همچین چیزی برای پروژه ی سیمکارت نیاز داشتم تا از شر boost خلاص بشم، پس دست بکار شدم و این ریپوی async io رو با سی++ نوشتم و امروز هم بهش با کمک کلاد opus ساپورت darwin و android رو ادد کردم، بسیار زیبا شد:

https://github.com/tehrun-cpp/tio

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

@knowpow

یه نفر عدد RSA-260 رو که ۳۵ سال کسی نتونسته بود بشکنه، فاکتور گرفته.
این عدد ۲۶۰ رقمی که حاصل‌ضرب دو عدد اول مخفی بود و اساس چالش معروف رمزنگاری RSA از سال ۱۹۹۱ بود، الان بزرگ‌ترین عدد RSA شکسته شده تا امروز شده.

سال ۲۰۲۰ عدد قبلی یعنی RSA-250 رو پیدا کردن ولی کامپیوتینگ عظیمی پشتش بود، به عبارتی برای شکستن عدد قبلی حدود ۲۷۰۰ سال/‌هسته لازم شد.
بزارین با عدد حساب کنم تا روشن بشه: اگه بگیم ۱۰۰ تا ماشین ۶۴ هسته ای از امازون بگیریم و اینارو به هم وصل کنیم تا همگی با هم پردازش کنن و هزینه ی network و latency بینشون رو هم نسنجیم میتونیم بگیم برای این کار ۶۴۰۰ هسته داریم، حالا اگه یه هفته (۱۶۸ ساعت) کار کنن همگی با هم حدود ۱۲۳ سال‌/هسته کار میکنن.

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

@knowpow