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

وقتی ویکی پدیاش رو خوندم دیدم ۱۳ سالگیش کار x رو انجام داده که به y ختم شده و این y رو توی معادله های بعدی زندگیش استفاده کرده، فکر کنین زندگی بقیمون هم همینه، شاید کاری که الان میکنیم کم ارزش باشه ولی ممکنه خروجیش توی مراحل بعدی زندگیمون به عنوان یه ورودی استفاده بشه.

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

@knowpow

درود دوستان

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

یه مدته فعالیتم کم شده ولی دیگه خیلی پست میزام و میترکونم اینجارو 🚀🤘


@knowpow

اینم تارگت امسالمون 🚀

@knowpow

🔷 انتگرال‌گیرهای کلوین و ماکسول

داشتم دربارهٔ تاریخچهٔ کامپیوترهای آنالوگ جست‌وجو می‌کردم که به مقاله‌هایی از کلوین و ماکسول برخوردم. آن‌قدر نکات جالب و هیجان‌انگیز در این مقاله‌ها و مرتبط با این مقاله‌ها پیدا کردم که حیفم آمد آن‌ها را با همراهان دِرَنــگ در میان نگذارم.

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

▪️مقالهٔ کلوین در سال ۱۸۷۶ در مجله‌ٔ
Proceedings of the Royal Society of London
چاپ شد. عنوان مقاله‌اش این است: «دربارهٔ ابزاری برای محاسبهٔ انتگرال حاصل‌ضرب دو تابع داده‌شده».

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

«ماشین پیشنهادی خود را چند روز پیش برای برادرم پروفسور جیمز تامسون توضیح دادم و او در پاسخ دربارهٔ نوعی انتگرال‌گیر مکانیکی برایم صحبت کرد که سال‌ها پیش به ذهنش رسیده بود ولی هیچ شرحی از آن منتشر نکرده بود. فوراً متوجه شدم که ماشین او خیلی ساده‌تر از هرآنچه قبلاً به آن فکر کرده بودم مرا به هدفم می‌رساند. گزارشی از انتگرال‌گیر او در همین شماره از مجله‌ٔ انجمن سلطنتی همراه با مقالهٔ‌ حاضر منتشر می‌شود.»


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

▪️گزارش جیمز تامسون دربارهٔ ماشین انتگرال‌گیری‌اش هم در همین شماره از مجله و قبل از مقالهٔ کلوین آمده است: «دربارهٔ یک ماشین انتگرال‌گیری با یک اصل سینماتیکی جدید». در همین مقاله به کارهای ماکسول و مقالهٔ او در این زمینه اشاره شده است. مقالهٔ ماکسول بیش از بیست سال قبل از آن، یعنی در سال ۱۸۵۵، در مجله‌ٔ
Transactions of the Royal Scottish Society of Arts
چاپ شده بود. تامسون می‌گوید که ماکسول ایدهٔ کارش را از ماشین انتگرال‌گیری دیگری گرفته بود که در سال ۱۸۵۱ در نمایشگاه بزرگ لندن دیده بود. آن ماشین از نظر ماکسول ایرادهایی داشت و برای رفع آ‌ن‌ها خودش شروع کرده بود به طراحی یک ماشین دیگر.

▪️نمایشگاه بزرگ (Great Exhibition) که جیمز تامسون از آن یاد می‌کند نمایشگاهی بین‌المللی از اختراعات و تولیدات صنعتی بود که در سال ۱۸۵۱ در هایدپارک لندن برگزار شد. نمایشگاه بیش از پنج ماه دایر بود و بیش از شش میلیون نفر از آن بازدید کردند. (لطفاً یک بار دیگر به عددها توجه کنید!)

▪️نکته‌ای که در همه‌ٔ این مقاله‌ها جلب‌توجه می‌کند این است که متن آن‌ها را تقریباً به راحتی متن‌های امروزی می‌توان خواند. بازهٔ زمانی میان انتشار این دو مقاله (۱۸۵۵ تا ۱۸۷۶) حدوداً مقارن است با نیمهٔ اول دوره‌ٔ سلطنت ناصرالدین‌شاه. بعید می‌دانم متن‌‌های فارسی آن دوره را بتوان به راحتی متن‌های فارسی امروزی خواند.

▪️حالا که داریم تاریخ‌ها را مقایسه می‌کنیم، شاید بد نباشد به این هم اشاره کنیم که نمایشگاه بزرگ لندن در همان سالی برگزار شد که دارالفنون تأسیس شد.

▪️مقاله‌های کلوین و برادرش را می‌توانید در این فایل پی‌دی‌اف ببینید. در این فایل دو مقالهٔ کوتاه دیگر هم هست که در آن‌ها کلوین به کاربرد ماشین انتگرال‌گیر برای حل معادله‌های دیفرانسیل می‌پردازد.

▪️مقالهٔ ماکسول در کتابی که دانشگاه کمبریج از مجموعه‌ٔ مقاله‌های علمی او منتشر کرده بازنشر شده است (مقالهٔ شمارهٔ ۹). سال چاپ نخست این مجموعه ۱۸۹۰ است؛ یازده سال پس از درگذشت ماکسول. طرح‌وارهٔ ماشین پیشنهادی ماکسول را هم در انتهای همین مجموعه می‌توانید پیدا کنید.

▫️مطالعه‌ٔ تاریخ علم همیشه آموزنده و هیجان‌انگیز است. واینبرگ هم در چهار درس طلایی‌اش تأکید می‌کند که از مطالعه‌ٔ تاریخ علم غافل نشوید.

@k1samani_channel

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

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

این پیاده سازی چند تا دلیل اصلی داره:

۱- من دارم کتابخونه توسعه میدم، پس نباید جای کاربر استفاده کننده تصمیم بگیرم که کدوم ورکر باید روی کدوم ترد اجرا بشه، باید تصمیم گیری روش تردینگ رو به خودش واگذار کنم، شاید بخواد اصلا همه ی feed هاش روی یه هسته باشه. شایدم بخواد بگه binance بره رو هسته ی اول، نوبیتکس بره روی هسته ی دوم و...

۲- الان داریم میگیم که binance_feed که روی هسته ی اول پین شدی بیا و فقط جفت btcusdt رو شما داشته باشه، بعد یه binance_feed_2 بسازیم حالا پینش کنیم روی هسته ی دوم بعد بیاییم بگیم که اوکی تو بیا فقط ethusdt رو داشته باش. اینجوری ما اومدیم یه کانکشن مخصوص ethusdt ساختیم که همه چیش روی یه هسته اس و اصلا context switch نداره، و بدون دخالت با btcusdt داره کارش رو انجام میده.

برای ورژن اول فقط میخوام کار کنه و بعد بریم توی عمق پرفورمنس و سی++

سوالی بود بپرسید، بریم ببینیم چی میشه

این پروژه در راستای این پیامه.

#market_data_handler

@knowpow

نحوه ی observe کردن یه جفت توی پیاده سازی جدید:

این پروژه در راستای این پیامه.

#market_data_handler

@knowpow

نیازه که برای پایین‌ اوردن Context Switching کرنل رو تغییر بدیم؟!

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

‏هدف من تو این فاز اینه که برنامه‌ ی خودم رو طوری طراحی کنم که خودش باعث Context Switch نشه، یعنی با thread migration یا lock contention کش CPU رو reset نکنه. فقط در صورتی میرم سمت کانفیگ کرنل که بدونم سیستم نهایی قراره روی سرور خاصی مثل multi-socket بیاد دیپلوی بشه یا بخوام واقعا بوست کنم سیستم رو (که توی دنیای واقعی هم میشه و انجام میدن)

‏مورد بعدی که میشه باهاش بازی کرد همین Preemption هست، همون ماجرایی که کرنل وسط اجرای یه thread میاد اونو متوقف میکنه تا یه task با اولویت بالاتر رو اجرا کنه، شاید بگین مگه مریضه؟ نه اقا این رفتار ذاتیه توی کرنل‌هایی مثل لینوکس که Preemptive Scheduling هستن. که اونم با pthread میشه تنظیم کرد

سوالی بود بپرسید، بریم ببینیم چی میشه

این پروژه در راستای این پیامه.

#market_data_handler

@knowpow

یعنی اگه اینجوری ادامه پیدا کنه بدبخت میشیم و ورشکسته میشیم 🤷‍♂️

راستی این ریپو خیلی قشنگ و تمیزه، برای یادگیری

یکی از بهترین سورسا برای یادگیری معماری‌های async و سیستم‌های real-time با performance بالا، مخصوصاً وقتی بخواین درک عمیقی از memory management، threading، و IO داشته باشین.

این Seastar یکی از خفن‌ترین انجین‌های event-driven برای C++ هست. طراحی‌ شده تا با حداکثر performance روی ماشین‌های چند هسته‌ای کار کنه، مخصوصاً با zero-copy و thread-per-core architecture. همین باعث شده پایهٔ ScyllaDB باشه، که یه جایگزین سریع‌تر برای Cassandra محسوب میشه.

معماری thread-per-core architecture همون معماریه که ما هم برای پروژه ی market استفاده میکنیم. بهش Shared-nothing هم میگن. در موردش مینویسم حتما خیلی خفنه

https://github.com/scylladb/seastar

@knowpow

فعلا اینو گوش کنین تا بشوره ببره:

https://open.spotify.com/track/0M8rrUcBYXa24y3AIKQ19z?si=707e9ff78a544c1d

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

داستان اینه که میخوام پروژه ای که برای یه برد arm embedded linux نوشتم رو کامپایل کنم، چون زور چیپست خود برد به کامپایل نمیرسه میاییم روی یه سیستم قوی تر با معماری متفاوت حتی بیلد و کامپایل میکنیم و بعد باینری رو به معماری مدنظرمون انتقال میدیم.

@knowpow

زیون ابزاره، تکنیک یاد بگیرید

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

چرا میگم راحت؟ چون اکثر پروژه های اینجوری رو کسی دانلود و بیلد نمیکنه مگه اینکه واقعا بخواد مشارکت کنه، اوناییم که مشارکت میکنن فکر میکنن مشکل بیلد نشدن با اسکریپت های خود پروژه فقط مختص سیستم خودشونه و بقیه ندارنش و اگه داشتن حتما جامعه حلش میکرد. در حالی که یه اسکریپت خوب برای بیلد باید بتونه ورژن کتابخونه های استفاده شده رو با ماشینی که داره روش بیلد میشه تطبیق بده و اگه مشکلی یا کانفلیکتی هست اعلام کنه، مثلا ریپوی redpanda اصلا برای آرچ کامند نداره و کسی هم چیزی اضافه نکرده. یه عالمه باهاش سر و کله زدم اخرش سر نسخه‌ی ssl ترکید، حالا من باید برم همه داکیومنتا رو زیر و رو کنم ببینم چه ورژنی استفاده میکنن، در حالی که همین کارو اسکریپت install-deps میتونست خیلی بهتر انجام بده


@knowpow