Every few months the open-source community mints another AI framework. Most of them wrap Python bindings around heavy C++ kernels, or they stack abstraction layers so high that the runtime alone weighs more than the models they serve. CatAI moves in the opposite direction. It is a native AI engine written entirely in C++, built from the tensor math upward. The point is not to create yet another friendly skin over PyTorch. The point is to own every byte of memory and every cycle of compute, starting at the hardware boundary.

Why Another Engine?

If you have shipped anything to production, you already know the pain. Pull a standard deep-learning stack into a container and watch the image bloat to multiple gigabytes. Dependencies fight each other. The Python interpreter adds latency. The dispatcher that routes ops to CUDA or CPU introduces subtle overhead that becomes impossible to profile once it disappears into a dozen nested frameworks. For edge devices, embedded robotics, or latency-sensitive backends, that tax is real. A pure C++ engine eliminates the middleman. It talks to the operating system and the silicon directly, with no garbage collection, no global interpreter lock, and no serialization dance between languages.

CatAI treats this as a feature, not a compromise. The project is being written from scratch in C++ because the author wants to decide exactly how tensors live in RAM, how they move through cache hierarchies, and how kernels are scheduled across threads. That is not masochism. It is the only way to guarantee that behavior is predictable when you are squeezing performance out of limited hardware.

What “From Scratch” Actually Means

In most modern frameworks, tensor math is handled by opaque calls into vendor libraries like cuDNN, oneMKL, or MPS. That is perfectly sensible for shipping fast, but it hides the mechanics of the operation. CatAI is writing its own core tensor math and memory layouts. That means designing the fundamental data structures that hold multi-dimensional arrays, choosing how strides and offsets are calculated, and deciding whether to store data in row-major, column-major, or custom tiled formats depending on the access pattern.

This is deep systems work. When you write a matrix-multiply kernel by hand, you stop thinking in terms of torch.matmul and start thinking about L1 cache lines, register pressure, and loop tiling. You decide whether to block for 32x32 tiles or 64x64 based on the SIMD width of the target CPU. You align allocations to 64-byte boundaries so AVX-512 loads do not cross cache lines. You question whether std::vector is the right container for tensor storage, or whether a custom arena allocator gives you better locality and zero fragmentation across an entire inference graph.

Memory layout is equally critical. A naive naïve n-dimensional array can kill performance if the channels-last image data is accessed in a channels-first pattern. In CatAI, these layouts are first-class citizens, not afterthoughts handled by a graph optimizer running at export time.

The Optimization Mindset

Bare-metal optimization sounds like a buzzword until you start counting nanoseconds. It means fusing operations so intermediate results never leave the CPU registers or L1 cache. It means implementing a layer-norm followed by a GELU as a single kernel, saving an entire round-trip to DRAM. It means writing your own thread pool instead of leaning on OpenMP defaults, because you know your workload is bursty and you do not want the runtime spawning and joining threads every forward pass.

It also means understanding when not to write assembly. Sometimes the compiler vectorizes a loop better than hand-written intrinsics. The discipline ismeasurement: profile, hypothesize, change one variable, and profile again. This engine is being built by people who enjoy that grind. If you have ever spent an afternoon rewriting a convolution loop to shave two milliseconds off a batch, you already understand the culture.

Who We Need

This is not a one-person show. Building a backend from zero requires distinct skills that rarely overlap in a single brain. If you are reading this and considering whether to jump in, here is where you might fit:

  • مطورو C++ الذين يتقنون المعايير الحديثة ويعرفون أيضاً متى تسبب القوالب (templates) تضخماً في عملية التجميع (compilation bloat). يجب أن تكون مرتاحاً في التعامل مع المؤشرات الخام (raw pointers) عند الضرورة والمؤشرات الذكية (smart pointers) عند الاقتضاء، ويجب أن تهتم بحجم الملف الثنائي (binary size) بقدر اهتمامك بالتسهيلات اللغوية (syntax sugar).

  • خبراء الرياضيات الذين يمكنهم اشتقاق تدرجات التمرير العكسي (backward-pass gradients) لدوال التنشيط غير القياسية، وتحليل الاستقرار العددي في التدريب بدقة مختلطة (mixed-precision training)، وتحسين الخوارزميات قبل تحويلها إلى كود. إذا كنت تستطيع شرح سبب أهمية خدعة log-sum-exp، فأنت في المسار الذهني الصحيح.

  • متخصصو الذاكرة منخفضة المستوى الذين يفكرون في المخصصات (allocators)، وأخطاء الصفحات (page faults)، وطوبولوجيا NUMA. يحتاج المحرك إلى مجمعات ذاكرة (memory pools) لتنفيذ الرسم البياني (graph execution)، ومخازن مؤقتة (scratch buffers) للنوى (kernels)، واستراتيجيات لإعادة استخدام تخزين الموترات (tensor storage) عبر خطوات التدريب دون حدوث تسريب أو تجزئة.

  • مهندسو الأنظمة الذين يدركون كيف يمكن لاستدعاء نظام (syscall) في غير محله أن يعطل حلقة تدريب كاملة. فالجدولة، والإدخال/الإخراج (I/O)، وبدائيات المزامنة (synchronization primitives) هي الغراء الذي يربط الرياضيات معاً.

لست بحاجة لأن تكون متخصصاً عالمياً في المجالات الأربعة جميعها. سيبدأ معظم المساهمين بامتلاك نواة واحدة أو مخصص واحد ويتعلمون البقية مع ترسيخ البنية التحتية.

البنية التحتية والرياضيات المخصصة

يتم بناء منطق الخلفية (backend logic) بشكل تعاوني، ويبدأ ذلك بنقاشات حول البنية التحتية. هل سيستخدم المحرك رسماً بيانياً حسابياً ثابتاً (static computation graph)، حيث يتم تحديد النموذج بالكامل وتحسينه قبل وقت التشغيل؟ أم سيدعم التنفيذ الفوري (eager execution) مع شريط (tape) للتفاضل التلقائي؟ وكيف سيتم تمثيل التفاضل التلقائي (autodiff) — هل عبر تحميل العمليات الزائد (operator overloading)، أم تحويل المصدر، أم عبر تمثيل وسيط للرسم البياني (graph IR)؟ هذه القرارات تشكل كل شيء آخر.

الرياضيات المخصصة للشبكات العصبية تعني أكثر من مجرد إعادة تنفيذ الطبقات القياسية؛ إنها تعني الحرية في ابتكار طبقات جديدة. إذا كنت تريد نوعاً من الالتفاف (convolution) بنواة متفرقة (sparse kernel) غير قياسية، أو دالة تنشيط ليس لها اسم في الأدبيات العلمية، يمكنك كتابة عمليات التمرير الأمامي والعكسي بلغة C++ ودمجها مباشرة في المحرك. لا توجد واجهة برمجة تطبيقات Python لتصارعها، ولا حاجة للتعديل الديناميكي (monkey-patching). الرياضيات هي الكود، والكود هو الواجهة.

كيف تشارك

إذا كان هذا يثير اهتمامك، فإن تفاصيل المشروع الكاملة وخارطة الطريق الحالية موثقة بالتفصيل في منشور المؤلف على Dev.to. يمكنك قراءة التفاصيل، ورؤية ما تم بناؤه حتى الآن، وفهم المكان الذي تشتد فيه الحاجة إلى المساعدة بالضبط.

تفاصيل المشروع: https://dev.to/banana_cool/building-a-native-c-ai-engine-catai-from-scratch-looking-for-collaborators-l8m

توجد أيضاً مجموعة على Telegram لأي شخص يرغب في التواصل، أو طرح الأسئلة، أو متابعة التقدم دون الالتزام بتقديم طلب سحب (pull request) على الفور.

المجتمع: https://t.me/GyaanSetuAi

الخلاصة الحقيقية

لقد أصبح مكدس الذكاء الاصطناعي الحديث عبارة عن صندوق أسود. نحن نتعامل مع أطر العمل كأنها أجهزة سحرية: تدخل البيانات، يخرج النموذج، ونأمل ألا تؤثر عدم الشفافية علينا عند النشر. يرفض CatAI هذه الراحة. بناء المشروع بهذه الطريقة أبطأ؛ ستكتب المزيد من الكود، وتصلح المزيد من أخطاء التجزئة (segfaults)، وتعيد التفكير في الافتراضات التي تخفيها عنك أطر العمل عالية المستوى. لكنك ستفهم أيضاً لماذا يتصرف الجهاز بالطريقة التي يتصرف بها. في صناعة يتسابق فيها الجميع لتجريد العتاد (abstract away the hardware)، تكمن القيمة الحقيقية في السير في الاتجاه المعاكس والتعامل المباشر مع العتاد (touching the metal). هذا الفهم هو ما يميز الشخص الذي يستدعي واجهات برمجة التطبيقات (APIs) عن الشخص الذي يبني الأنظمة.