مقدمه

با انتشار NET 10. مایکروسافت گام بزرگی در بهبود عملکرد و کارایی برنامه‌ها برداشته است. این نسخه، از مدیریت حافظه هوشمند و JIT پیشرفته گرفته تا بهینه‌سازی محاسبات عددی و threading، امکانات جدید و جذابی برای توسعه‌دهندگان ارائه می‌دهد. اما سوال مهم این است: این بهبودها چقدر واقعی هستند و در مقایسه با رقبای محبوب مثل Node.js و Go چه عملکردی دارند؟
در این پست، ۲۲ مورد از کلیدی‌ترین بهبودهای NET 10. را بررسی کرده و عملکرد آن‌ها را با Node.js و Go مقایسه می‌کنیم. با این بررسی، توسعه‌دهندگان می‌توانند تصمیم بهتری برای انتخاب پلتفرم مناسب پروژه‌های خود بگیرند.

JIT -1

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

JIT چیست؟

 JITیا Just-In-Time Compiler  یک روش اجرای برنامه است که در آن کد سطح بالا (مثل C#, JavaScript یا IL در .NET) در زمان اجرا (runtime) به کد ماشین تبدیل می‌شود.

این روش برخلاف AOT (Ahead-of-Time) که همه‌چیز را قبل از اجرا کامپایل می‌کند، انعطاف بیشتری دارد چون می‌تواند:

• شرایط واقعی اجرای برنامه را ببیند
• داده‌های واقعی (runtime profiling) را در نظر بگیرد
• بر اساس سخت‌افزار (CPU, SIMD, AVX, ARM) کد بهینه بسازد

نتیجه: JIT معمولاً شروع کندتری دارد، اما کارایی بالاتری در طول اجرای طولانی به دست می‌آورد.

 JIT در .NET 10

• استفاده از RyuJIT (نسل جدید JIT)
• پشتیبانی از Tiered Compilation (Tier 0 برای سرعت شروع + Tier 1 برای سرعت اجرای طولانی)
• هماهنگی کامل با PGO (Profile Guided Optimization) → JIT می‌تونه بر اساس داده‌های واقعی اجرای برنامه تصمیم بگیره
• پشتیبانی از SIMD، AVX512، ARM SVE → کد تولیدی روی سخت‌افزار مدرن بسیار سریع‌تر اجرا می‌شه
• قابلیت Inlining گسترده‌تر، Loop Optimizations و Bounds Check Elimination

 نتیجه:

در Net10. در اجرای طولانی و اپلیکیشن‌های سازمانی یا محاسباتی بسیار سریع عمل می‌کنه، و با ترکیب JIT + Native AOT بهترین تعادل بین startup و throughput رو فراهم می‌کنه

 JIT در  Node.js (V8 Engine)

• Node.js از موتور V8 استفاده می‌کنه که JIT مخصوص JavaScript داره.
• V8 دارای دو JIT اصلیه:
  1. Ignition (Interpreter + Baseline JIT) → برای اجرای سریع کد ساده.
  2. TurboFan (Optimizing JIT) → برای بهینه‌سازی در اجرای طولانی.
• توانایی Inline Caches و Speculative Optimization: فرض می‌گیره که نوع داده یا مسیر اجرا ثابت می‌مونه، بعداً اگر تغییر کنه (deoptimization) باید rollback کنه.

 نتیجه:

در node.js برای کدهای JavaScript سبک و متوسط خیلی سریع عمل می‌کنه، ولی در workloadهای محاسباتی سنگین (مثل ML یا پردازش تصویر) نسبت به .NET یا Go ضعیف‌تره چون JavaScript ذاتاً dynamic type هست

 JIT در  Go

• زبان Go به‌طور پیش‌فرض JIT نداره.

• Go از AOT Compilation استفاده می‌کنه: کد Go همیشه قبل از اجرا به باینری native کامپایل می‌شه.

• این یعنی:

  • Startup فوق‌العاده سریع 🚀

  • باینری مستقل بدون وابستگی به runtime حجیم

  • ولی: بهینه‌سازی‌ها به اندازه JIT پویا و تطبیقی نیست (نمی‌تونه در زمان اجرا خودش رو optimize کنه)

نتیجه:

برای سرویس‌های کوچک و مقیاس‌پذیر (microservices, cloud apps) عالیه چون سرعت شروع بالایی داره و memory footprint کمی مصرف می‌کنه، ولی برای workloadهای سنگین که adaptive optimization نیاز دارن، ضعیف‌تر از .NET و Node.js هست

مقایسه نهایی JIT بین سه پلتفرم

PGO (Profile-Guided Optimization) -2
PGO پویا با جمع‌آوری اطلاعات در حین اجرای واقعی برنامه، مسیرهای پرکاربرد و الگوهای ورودی رایج را شناسایی کرده و کد را بر اساس آن بهینه می‌کند. این موضوع باعث کاهش تبدیل‌های غیرضروری (casts) و افزایش کارایی می‌شود.

PGO چیست؟

Profile-Guided Optimization (PGO) یک تکنیک بهینه‌سازی است که در آن اطلاعات واقعی اجرای برنامه (مثل مسیرهای پرتکرار، نوع داده‌ها، شاخه‌های if/else که بیشتر اتفاق می‌افتند) جمع‌آوری می‌شود و سپس کامپایلر یا JIT بر اساس این داده‌ها کد را بهینه می‌کند.

مزیت اصلی:

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

• مسیرهای مهم‌تر سریع‌تر اجرا می‌شوند (hot paths).

• کدهایی که کمتر استفاده می‌شوند، ساده‌تر باقی می‌مانند (cold paths).

PGO در NET 10.

• در NET 10، PGO. به صورت Dynamic PGO و Static PGO پشتیبانی می‌شود:

  1. Static PGO → پروفایل قبلاً جمع می‌شود (مثلاً در محیط تست) و هنگام build استفاده می‌شود.

  2. Dynamic PGO → خود JIT در زمان اجرا پروفایل می‌گیرد و بهینه‌سازی می‌کند.

• بهبودها:
  • بهینه‌سازی Casts و نوع داده‌ها → اگر بیشتر ورودی‌ها از یک نوع خاص باشند، JIT اون مسیر رو سریع‌تر می‌کنه.
  • بهبود inlining بر اساس hot-path
  • بهبود branch prediction

نتیجه: کدهای پرتکرار در NET 10. بسیار سریع‌تر از قبل اجرا می‌شوند.

• موتور V8 چیزی مشابه PGO دارد به نام Speculative Optimization.

• V8 فرض می‌کند که انواع داده یا مسیر اجرای کد ثابت باقی می‌ماند (مثلاً یک متغیر همیشه عدد صحیح است).

• بر اساس این فرض کد را optimize می‌کند.

• اگر فرض اشتباه شود → Deoptimization اتفاق می‌افتد (یعنی برمی‌گردد به حالت ساده‌تر و کندتر).

نتیجه:

Node.jsدر workloadهای عادی وب خیلی سریع است، اما اگر داده‌ها به شدت تغییر کنند، overhead از دست دادن optimizeها زیاد می‌شود.

PGO در Go

• زبان Go به صورت پیش‌فرض PGO ندارد چون JIT ندارد.

• ولی از Go 1.20 به بعد، یک نسخه Profile-Guided Optimization ساده معرفی شد:

  • هنگام build می‌توان پروفایل جمع‌آوری شده از اجرای قبلی را به کامپایلر داد.

  • این باعث می‌شود مسیرهای پرتکرار (hot path) کمی سریع‌تر شوند.

• اما: این PGO هنوز به بلوغ .NET یا V8 نرسیده است.

نتیجه:

Go بیشتر روی سادگی و سرعت ثابت تمرکز دارد تا adaptive optimization.

مقایسه PGO در سه پلتفرم

Tier 0 Optimizations -3
بهبودهای Tier 0 باعث کاهش زمان راه‌اندازی (startup) برنامه‌ها می‌شود. این کار از طریق حذف boxing غیرضروری و بهینه‌سازی عملیات async/await انجام شده است.

Tiered Compilation چیست؟

در پلتفرم‌هایی که JIT دارند، همیشه یک چالش وجود دارد:

• می‌خواهیم سریع اجرا شویم (startup time کوتاه باشد)
• می‌خواهیم بهینه باشیم (execution time سریع باشد)

اما JIT نمی‌تواند همزمان هم خیلی سریع کامپایل کند و هم خیلی بهینه.
اینجاست که مفهوم Tiered Compilation می‌آید:

• Tier 0: نسخه سریع و ساده از کد → فقط برای اینکه برنامه زود شروع شود.
• Tier 1: نسخه بهینه‌تر از کد → بعد از مدتی جایگزین Tier 0 می‌شود.

Tiered Compilation در NET 10.

• در .NET Core 3.0 معرفی شد و درNET 10. بهبود یافته است.
• Tier 0 optimizations درNET 10. شامل:
  • حذف boxing غیرضروری
  • بهینه‌سازی async/await برای startup سریع‌تر
  • اجرای اولیه با ساده‌ترین IL-to-native translation
• وقتی متدی چند بار اجرا شد → JIT پروفایل می‌گیرد → نسخه‌ی Tier 1 optimized تولید می‌شود.

نتیجه:

• Startup خیلی سریع‌تر

• Hot paths خیلی بهینه‌تر

• ترکیب مناسب برای اپلیکیشن‌های طولانی‌مدت (server-side apps)

Tiered Compilation در Node.js (V8)

• V8 چیزی مشابه Tiered Compilation دارد:

  • Ignition → یک مفسر (interpreter) سریع برای شروع کار

  • TurboFan → JIT optimizer که بعد از مشاهده‌ی کد پرتکرار، نسخه سریع‌تر تولید می‌کند

• این همان ایده Tiered Compilation است اما با اسم متفاوت.

تفاوت:

• V8 خیلی aggressive است → به سرعت سراغ TurboFan می‌رود.
• اگر assumptions اشتباه باشند → deoptimization اتفاق می‌افتد.

Tiered Compilation در Go

• زبان Go JIT ندارد، پس چیزی مثل Tiered Compilation هم ندارد.

• همیشه کد از قبل کامپایل شده (AOT) و بهینه است.

• یعنی Go در واقع از همون اول در وضعیت شبیه به Tier 1 کار می‌کند.

مزیت:

• Startup همیشه سریع است.

• هیچ overheadی برای JIT یا re-optimization وجود ندارد.

• ولی بهینه‌سازی به اندازه‌ی JITهای adaptive (مثل .NET یا V8) عمیق نیست

 مقایسه Tiered Compilation در سه پلتفرم

Loop Optimizations -4

بهینه‌سازی حلقه‌ها شامل تکنیک‌هایی مثل strength reduction (جایگزینی عملیات سنگین با ساده‌تر) و شمارش رو به پایین (downward counting) است که اجرای حلقه‌ها را سریع‌تر می‌کند.

Loop Optimizations چیست؟

حلقه‌ها (loops) معمولاً بیشترین زمان اجرای برنامه را مصرف می‌کنند.
برای همین کامپایلرها چند تکنیک مهم بهینه‌سازی حلقه دارند:

1. Strength Reduction

   • جایگزینی یک عملیات پرهزینه با عملیات ساده‌تر.

   • مثال:

for (int i = 0; i < n; i++) 
{
    x = i * 4;
}

در Strength Reduction → ضرب (multiplication) با جمع (addition) جایگزین می‌شود:

x = 0;
for (int i = 0; i < n; i++) {
    x += 4;
}

Loop Unrolling

• اجرای چند iteration از حلقه در یک دور برای کاهش overhead شرط و پرش.
• مثال:

for (int i = 0; i < n; i++) 
{
    sum += arr[i];
}

بعد از Unrolling (مثلاً 4 بار):

for (int i = 0; i < n; i += 4)
 {
    sum += arr[i] + arr[i+1] + arr[i+2] + arr[i+3];
 }

نتیجه:

کاهش هزینه‌ی محاسباتی

بهبود سرعت در حلقه‌های سنگین

Loop Optimizations در .NET 10

• JIT در .NET 10 حتی قوی‌تر از نسخه‌های قبل شده و بهینه‌سازی‌های زیر را انجام می‌دهد:

  • Strength Reduction → ضرب و تقسیم‌های ثابت به جمع و شیفت تبدیل می‌شوند.

  • Downward counting loops → حلقه‌هایی که شمارش رو به پایین دارند کاراتر می‌شوند.

  • Bounds check elimination → وقتی مطمئن باشد که ایندکس از محدوده خارج نمی‌شود، چک‌های اضافی حذف می‌شوند.

  • Loop unrolling پیشرفته‌تر در حلقه‌های کوچک یا hot.

  • ترکیب با Vectorization برای پردازش موازی داده‌ها.

• 📌 نتیجه: کارایی در workloadهای علمی، پردازش تصویر، یادگیری ماشین و دیتابیس به شدت افزایش یافته است.

Loop Optimizations در Node.js (V8)

• V8 هم بهینه‌سازی‌های مشابه دارد:

  • Strength Reduction روی ضرب/تقسیم انجام می‌شود.

  • Loop-Invariant Code Motion → محاسبات ثابت به بیرون حلقه منتقل می‌شوند.

  • Bounds Check Elimination وقتی داده‌ها monomorphic (یک نوع مشخص) باشند.

  • Unrolling محدود بیشتر در hot paths انجام می‌شود.

• 📌 اما به خاطر dynamic typing در جاوااسکریپت، این بهینه‌سازی‌ها همیشه قابل اعتماد نیستند.

  • اگر در یک iteration عدد صحیح بیاید و در دیگری رشته، ممکن است کل حلقه deoptimized شود.

Loop Optimizations در Go

• Go یک زبان AOT compiled است، پس همه‌ی بهینه‌سازی‌ها در زمان build اتفاق می‌افتد.

• Strength Reduction و Loop-Invariant Code Motion به خوبی پشتیبانی می‌شوند.

• Loop Unrolling به صورت محدود استفاده می‌شود (معمولاً برای حلقه‌های خیلی کوچک).

• چون نوع داده‌ها در Go استاتیک هستند → این بهینه‌سازی‌ها پایدارتر از Node.js هستند.
  📌 نقطه ضعف:

• Go به اندازه‌ی JITهای هوشمند مثل .NET یا V8 aggressive نیست.

• تمرکز Go بیشتر روی سادگی و build سریع است تا heavy optimizations.

Bounds Checks -5
NET 10. با بهبود در حذف بررسی مرز آرایه‌ها (bounds check elimination)، امنیت حافظه را حفظ کرده ولی سربار اجرایی را به حداقل رسانده است.

Bounds Checks چیست؟

در زبان‌های امن (مثل C#, Java, Go, JavaScript)، دسترسی به آرایه‌ها یا لیست‌ها همیشه با یک بررسی محدوده (Bounds Check) همراه است.

مثال در C#:

int[] arr = new int[10];
int x = arr[i]; // JIT بررسی می‌کند که 0 <= i < 10

مزیت: از خطاهای حافظه مثل Buffer Overflow جلوگیری می‌کند.
عیب: هر بار یک شرط اضافه اجرا می‌شود → افت کارایی در حلقه‌های بزرگ.

Bounds Checks در NET 10.

در . .NET 10. ، JIT بهبود بزرگی در این زمینه داده است:

• Bounds Check Elimination (BCE):
  وقتی JIT مطمئن باشد که ایندکس از محدوده خارج نمی‌شود، شرط را حذف می‌کند.
  مثال:

for (int i = 0; i < arr.Length; i++)
    sum += arr[i];   // چک‌ها حذف می‌شوند چون i همیشه معتبر است

•  Range Check Hoisting:

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

• Loop Analysis:
  JIT بررسی می‌کند که شرایط حلقه از محدوده تجاوز نمی‌کند و کل چک‌ها را حذف می‌کند.

نتیجه: امنیت + سرعت همزمان → نزدیک به C++ در کارایی، ولی ایمن‌تر.

Bounds Checks در Node.js (V8)

• جاوااسکریپت همیشه Bounds Check دارد چون زبان داینامیک است.
• V8 سعی می‌کند با تکنیک‌های زیر سرعت را بالا ببرد:
  • Bounds Check Elimination اگر ثابت باشد (مثلاً for (let i=0; i<arr.length; i++)).
  • Typed Arrays مثل Int32Array سریع‌ترند چون اندازه‌شان ثابت است.
  • اگر نوع داده‌ها عوض شوند (polymorphic) → دوباره deoptimization اتفاق می‌افتد.

یعنی در حلقه‌های ساده، V8 خیلی سریع می‌شود، ولی در داده‌های پویا، همیشه هزینه‌ی اضافه دارد.

Bounds Checks در Go

• Go یک زبان AOT compiled است → همه چیز در زمان کامپایل بررسی می‌شود.
• در بیشتر موارد، Bounds Check Elimination انجام می‌شود اگر کامپایلر مطمئن باشد.
  مثال:

for i := 0; i < len(arr); i++ {
    sum += arr[i]  // check حذف می‌شود
}

• اما در حلقه‌هایی که شرط پیچیده است، Go چک را نگه می‌دارد.

Go مثل .NET خیلی پیشرفته در BCE نیست، ولی از Node.js پایدارتر است چون نوع‌ها استاتیک هستند.

 مقایسه Bounds Checks در سه پلتفرم 

Arm64 Improvements -6
نسخه جدید با تولید کد بهینه‌تر برای پردازنده‌های Arm64، باعث افزایش کارایی در الگوهای رایج و عملیات موازی روی این معماری می‌شود.

Arm64 چیست؟

• ARM64 (یا AArch64) معماری ۶۴ بیتی پردازنده‌های ARM است.
• امروزه در موبایل‌ها (Android, iOS)، مک‌های جدید (Apple M1/M2/M3)، و حتی سرورهای ابری (AWS Graviton, Azure Ampere) استفاده می‌شود.
• مزیت اصلی: کارایی بالا + مصرف انرژی پایین

بهبودهای Arm64 در NET 10.

مایکروسافت در NET 10. تمرکز زیادی روی ARM64 گذاشته چون:

• ویندوز 11 روی ARM لپ‌تاپ‌ها را هدف گرفته
• سرورهای ARM در کلود در حال رشد هستند

بهبودها:

1. کد جنریشن بهینه‌تر در JIT

   • استفاده بهتر از رجیسترهای ARM64
   • کاهش دستورهای اضافی در ریاضی و منطق
2. بهینه‌سازی برای الگوهای رایج
   • بهینه‌سازی عملیات روی آرایه‌ها و حافظه
   • استفاده از دستورهای ARM64 SIMD
3. پشتیبانی بهتر برای Native AOT روی ARM64
   • اپلیکیشن‌ها می‌توانند مستقیم به کد باینری ARM64 کامپایل شوند

نتیجه:

• اپلیکیشن‌های NET 10. روی ARM64 (مثل Mac M1/M2) ۲x تا ۳x سریع‌تر از نسخه‌های قبلی اجرا می‌شوند.
• مصرف انرژی پایین‌تر در دیوایس‌های پرتابل.

Arm64 در Node.js (V8)

• Node.js روی V8 ساخته شده و V8 سال‌هاست روی ARM64 بهینه‌سازی شده (مخصوصاً به خاطر اندروید و کروم روی موبایل).
• بهبودها:
  • JIT (TurboFan) از رجیسترهای ARM64 بهینه استفاده می‌کند.
  • SIMD برای TypedArray و عملیات ریاضی فعال است.
  • Apple M1/M2: Node.js روی مک‌های ARM خیلی سریع اجرا می‌شود.

ولی:

• Node.js بیشتر روی workloadهای وب تمرکز دارد، پس بهینه‌سازی عمیق برای الگوریتم‌های محاسباتی مثل .NET به اندازه گسترده نیست.

Arm64 در Go

• Go کاملاً AOT compiled است و از مدت‌ها پیش از ARM64 پشتیبانی دارد.
• ویژگی‌ها:
  • Compiler کد ARM64 تمیز و بهینه تولید می‌کند.
  • Runtime و Garbage Collector روی ARM64 بهینه شده‌اند.
  • عملکرد بسیار پایدار روی سرورهای ARM (AWS Graviton).

 اما:

• Go هنوز SIMD optimizations به اندازه .NET یا V8 ندارد.
• تمرکزش بیشتر روی سادگی و پایداری است تا نهایت performance.

 مقایسه Arm64 در سه پلتفرم

ARM SVE (Scalable Vector Extension) -7
پشتیبانی از SVE در معماری ARM امکان اجرای عملیات برداری (vectorized operations) به صورت کارآمدتر و در مقیاس بزرگ‌تر را فراهم می‌کند.

ARM SVE چیست؟

• SVE (Scalable Vector Extension) یک افزونه‌ی جدید برای معماری ARM64 است.
• هدف: اجرای عملیات برداری (SIMD) روی داده‌ها به صورت انعطاف‌پذیر.
• تفاوت اصلی با SIMD معمولی (مثل NEON):
  • طول رجیسترها در SVE ثابت نیست (ممکن است 128 بیت، 256 بیت، 512 بیت یا بیشتر باشند).
  • برنامه‌نویس لازم نیست اندازه دقیق رجیستر را بداند → همان کد می‌تواند روی CPUهای مختلف (با رجیسترهای متفاوت) بهینه اجرا شود.

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

ARM SVE در NET 10.

• NET 10. پشتیبانی اولیه از SVE اضافه کرده است.
• بهبودها:
  1. Vector<T> API در .NET حالا می‌تواند از دستورهای SVE استفاده کند.
  2. الگوریتم‌هایی مثل loop vectorization و mathematical operations می‌توانند با سرعت بیشتری اجرا شوند.
  3. Native AOT روی ARM64 حالا می‌تواند مستقیم از SVE بهره ببرد.

نتیجه: محاسبات سنگین (مانند AI و پردازش داده) در .NET روی ARM خیلی سریع‌تر می‌شود، بدون نیاز به بازنویسی کد.

ARM SVE در Node.js (V8)

• V8 هنوز به شکل کامل از SVE پشتیبانی نمی‌کند.
• پشتیبانی اصلی SIMD در Node.js محدود به TypedArray و دستورهای NEON (قدیمی‌تر) است.
• پروژه‌هایی برای آوردن SVE به V8 در حال بررسی هستند، اما هنوز در نسخه پایدار وارد نشده است.

یعنی: Node.js روی ARM از SIMD پشتیبانی دارد، ولی هنوز SVE-aware نیست.

ARM SVE در Go

• Go کامپایلر AOT دارد و کد ARM64 تمیز تولید می‌کند.
• اما پشتیبانی از SVE هنوز کامل نشده است.
• Go بیشتر تمرکزش روی قابلیت‌های عمومی (GC, Scheduler) است تا SIMD یا برداری‌سازی پیشرفته.
• بعضی لایبرری‌های Go به صورت دستی از intrinsics استفاده می‌کنند، ولی در سطح زبان رسمی پشتیبانی کامل وجود ندارد.

📌 یعنی: Go هم مثل Node.js هنوز SVE-ready نیست، ولی چون کدش استاتیک است، احتمالاً زودتر از Node می‌تواند بهره ببرد.

 مقایسه Arm SVE در سه پلتفرم

AVX10.1 Instructions -8
با اضافه شدن دستورالعمل‌های AVX10.1، کارایی محاسبات سنگین و عملیات پردازشی روی سخت‌افزارهای سازگار افزایش یافته است.

AVX10.1 چیست؟

• AVX (Advanced Vector Extensions) مجموعه دستورالعمل‌های پردازنده‌های x86 (اینـتل و AMD) برای محاسبات برداری (SIMD) است.
• نسخه‌های قبلی: AVX، AVX2، AVX-512
• AVX10 استاندارد جدید اینتل است که نسل بعدی AVX محسوب می‌شود و سازگار با AVX-512 طراحی شده.
• AVX10.1 اولین نسخه این استاندارد است.

مزایا:

1. پشتیبانی از رجیسترهای بزرگ (تا 512 بیت)
2. سازگاری با معماری‌های مختلف (future-proof)
3. افزایش کارایی در محاسبات عددی، هوش مصنوعی، یادگیری ماشین، رمزنگاری

AVX10.1 در NET 10.

• NET 10. به کمک JIT + HWIntrinsics API می‌تواند از دستورهای AVX10.1 استفاده کند.
• بهبودها:
  1. System.Numerics.Vector<T> خودکار از AVX10.1 بهره می‌برد.
  2. الگوریتم‌های ریاضی و رمزنگاری (SHA, AES) سریع‌تر اجرا می‌شوند.
  3. Native AOT روی CPUهای جدید اینتل، مستقیم به AVX10.1 مپ می‌شود.

نتیجه: در اپلیکیشن‌های سنگین (مثل ML.NET, پردازش تصویر, بازی‌ها) سرعت چشمگیری خواهید داشت.

AVX10.1 در Node.js (V8)

• Node.js به صورت مستقیم از AVX10.1 استفاده نمی‌کند.
• ولی V8 JIT می‌تواند از AVX2 و AVX-512 برای TypedArray و بعضی الگوریتم‌ها استفاده کند.
• AVX10.1 هنوز در V8 وارد نشده، اما احتمالا در آینده از طریق LLVM backend یا JIT Intrinsics فعال شود.

یعنی Node.js روی CPUهای جدید، بهبود محدود می‌گیرد (نه به اندازه .NET).

AVX10.1 در Go

• Go به صورت AOT compiled است.
• کامپایلر Go از AVX2 و AVX-512 در بعضی مسیرهای خاص پشتیبانی دارد (مثلاً برای crypto).
• اما AVX10.1 هنوز به طور رسمی در Go پشتیبانی نشده است.
• احتمال زیاد در نسخه‌های آینده (با به‌روزرسانی کامپایلر و toolchain) اضافه خواهد شد.

یعنی در حال حاضر Go هم مثل Node.js فقط از AVX2/AVX-512 بهره می‌برد.

AVX512 Support -9
پشتیبانی از AVX512 اجرای عملیات داده‌محور و محاسبات عددی در مقیاس بالا را بسیار سریع‌تر می‌کند، مخصوصاً در بارهای کاری علمی و محاسباتی.

AVX-512 چیست؟

• AVX-512 (Advanced Vector Extensions 512-bit) مجموعه‌ای از دستورالعمل‌های پردازنده‌های x86 اینتل و AMD برای پردازش برداری و محاسبات موازی است.
• ویژگی‌ها:
  1. طول رجیسترها: 512 بیت → پردازش همزمان 8 عدد double یا 16 عدد float
  2. مناسب برای HPC، ML، AI، رمزنگاری و پردازش تصویر
  3. شامل masking، scatter/gather و fused operations → کاهش تعداد دستورهای حلقه

مزیت: اجرای عملیات داده‌محور با حداکثر بهره‌وری از CPU

AVX-512 در NET 10.

• NET 10. به کمک HWIntrinsics و JIT می‌تواند از AVX-512 استفاده کند.
• قابلیت‌ها:
  • System.Numerics.Vector<T> از AVX-512 بهره می‌برد
  • حلقه‌ها و عملیات برداری بهینه می‌شوند
  • الگوریتم‌های سنگین (ML.NET، پردازش تصویر، محاسبات مالی) سریع‌تر اجرا می‌شوند
  • Native AOT روی پردازنده‌های سازگار → بهترین عملکرد

نتیجه:

• عملکرد نزدیک به حداکثر توان پردازنده x86
• کاهش چرخه‌های CPU و مصرف انرژی نسبت به پردازش معمولی

AVX-512 در Node.js (V8)

• Node.js و V8 به صورت مستقیم از AVX-512 استفاده نمی‌کنند.
• V8 ممکن است بعضی از عملیات ریاضی روی TypedArray را بهینه کند، ولی دستورالعمل‌های برداری کامل AVX-512 هنوز فعال نیستند.

📌 نتیجه: Node.js برای محاسبات سنگین برداری روی CPUهای جدید محدودیت دارد.

🔹 AVX-512 در Go

• Go AOT compiled است.
• برخی الگوریتم‌های خاص مثل crypto می‌توانند از AVX-512 استفاده کنند، ولی پشتیبانی عمومی هنوز کامل نیست.
• یعنی برای بهره‌گیری کامل از AVX-512 در Go نیاز به intrinsics دستی یا کتابخانه‌های C دارید.

نتیجه: Go از پردازش برداری استفاده می‌کند ولی نه در حد .NET

 مقایسه AVX-512 در سه پلتفرم

Vectorization -10

Vectorization یعنی استفاده از دستورالعمل‌های پردازنده (SIMD: Single Instruction, Multiple Data) برای پردازش همزمان چند داده در یک دستور.
به جای اینکه عملیات روی یک عنصر انجام شود، چندین عنصر در یک رجیستر پردازنده به‌صورت موازی پردازش می‌شوند.

📌 مثال ساده:
بدون Vectorization

for (int i = 0; i < n; i++)
 {
    arr[i] = arr[i] * 2;
}

با Vectorization (SIMD):

// هر بار 4 یا 8 عنصر با هم پردازش می‌شوند
Vector v = new Vector(arr, i);
v = v * 2;
v.CopyTo(arr, i);

🔹 Vectorization در .NET 10

• در .NET 10، JIT بهبود بزرگی در Auto-Vectorization دارد:

  • تبدیل خودکار حلقه‌های ساده به SIMD instructions.

  • پشتیبانی از AVX-512 و AVX10.1 روی CPUهای جدید اینتل/AMD.

  • استفاده از ARM SVE (Scalable Vector Extension) در پردازنده‌های ARM.

  • بهینه‌سازی‌های ترکیبی → vectorization + loop unrolling.

• 📌 نتیجه:

  • عملکرد بسیار بالا در پردازش‌های داده‌محور مثل:

    • پردازش تصویر

    • الگوریتم‌های علمی

    • یادگیری ماشین

🔹 Vectorization در Node.js (V8)

• V8 به طور مستقیم vectorization انجام نمی‌دهد.

• اما:

  • کامپایلر TurboFan بعضی حلقه‌های عددی را بهینه می‌کند.

  • برای SIMD واقعی نیاز به WebAssembly SIMD یا کتابخانه‌های مخصوص (مثل TensorFlow.js) است.

• 📌 نتیجه:

  • در پردازش‌های عادی جاوااسکریپت → vectorization به صورت خودکار ضعیف است.

  • در WebAssembly → می‌تواند به سطح C/C++ نزدیک شود.

🔹 Vectorization در Go

• Go یک زبان AOT است و خودش به طور پیش‌فرض auto-vectorization انجام نمی‌دهد.

• اما:

  • با فلگ‌های کامپایلر GCC/LLVM می‌توان بعضی از حلقه‌ها را vectorize کرد.

  • پکیج‌هایی مثل intrinsics یا assembly-level SIMD برای کارهای خاص استفاده می‌شوند.

• 📌 نتیجه:

  • در Go بهینه‌سازی پیش‌فرض محدود است.

  • توسعه‌دهنده باید به صورت دستی (با پکیج یا asm) vectorization را فعال کند.

مقایسه vectorization در سه پلتفرم

Branching Improvements
با بهبود در پیش‌بینی شاخه‌ها (branch prediction)، جریمه ناشی از misprediction کاهش پیدا کرده و کارایی کلی CPU بهتر شده است.

Branching چیست؟

• در برنامه‌نویسی، branch به دستور شرطی یا پرش گفته می‌شود، مثل:

if (x > 0) { doSomething(); } else { doSomethingElse(); }

• یا پیش‌بینی شاخه‌ها، تکنیکی در CPU است تا قبل از دانستن نتیجه شرط، مسیر احتمالی را پیش‌بینی کند.
• اگر پیش‌بینی درست باشد → اجرای سریع
• اگر اشتباه باشد → CPU باید pipeline را flush کند → کندی

📌 مشکل: در حلقه‌ها و برنامه‌های محاسباتی سنگین، branch misprediction می‌تواند کارایی را تا ۳۰–۵۰٪ کاهش دهد

🔹 Branching در .NET 9

• JIT در .NET 9 بهبودهای زیادی در branch prediction hints و hot path optimization دارد:
  • مسیرهای پرتکرار (hot paths) تشخیص داده می‌شوند و اولویت می‌گیرند
  • شرط‌های نادرست یا کم‌استفاده (cold paths) جدا می‌شوند
  • تکنیک likely/unlikely hints در IL اعمال می‌شود

📌 نتیجه:

• کاهش misprediction
• بهبود سرعت اجرای الگوریتم‌های سنگین و حلقه‌های پیچیده

🔹 Branching در Node.js (V8)

• V8 JIT تلاش می‌کند branch prediction را با speculative optimization بهینه کند:
  • فرض می‌کند مسیرهای hot ثابت می‌مانند
  • اگر assumption غلط باشد → deoptimization اتفاق می‌افتد
• در کد JavaScript با dynamic typing و تغییر مداوم نوع داده، احتمال misprediction بالاتر است

📌 نتیجه: برای وب و کدهای سبک خوب، ولی در کدهای محاسباتی سنگین کمتر پایدار

🔹 Branching در Go

• Go AOT compiled است و branch prediction بیشتر بر اساس CPU hints و compiler heuristics انجام می‌شود
• branch‌های پرتکرار (hot loops) توسط کامپایلر شناسایی و بهینه می‌شوند
• اما سطح تحلیل و هوشمندی به اندازه JIT adaptive (.NET) نیست

📌 نتیجه: Go در branch prediction پایدار است ولی نمی‌تواند مسیرهای اجرای dynamic را همانند .NET بهینه کند

Write Barriers Optimization
بهینه‌سازی write barrierها در GC سربار مدیریت حافظه را کاهش داده و کارایی جمع‌آوری زباله (Garbage Collection) را افزایش می‌دهد.

Write Barriers چیست؟

• Write Barrier مکانیزمی در Garbage Collector (GC) است که وقتی یک reference در حافظه تغییر می‌کند، اطلاع‌رسانی می‌کند.
• هدف:
  • حفاظت از حافظه در زمان جمع‌آوری زباله (GC)
  • جلوگیری از از دست رفتن referenceها و memory leak
• بدون write barrier، GC نمی‌تواند درست تشخیص دهد چه اشیایی هنوز استفاده می‌شوند

📌 مشکل: هر write barrier باعث overhead و کندی برنامه می‌شود

🔹 Write Barriers در .NET 9

• .NET 9 بهینه‌سازی‌های زیادی در write barriers انجام داده است:
  1. Optimized Generational GC → فقط نیاز به نوشتن تغییرات برای اشیای نسل قدیمی
  2. Reduced Barrier Overhead → با تکنیک‌های JIT، برخی write barrierهای غیرضروری حذف می‌شوند
  3. Concurrent GC → همزمان با اجرای برنامه، با کمترین وقفه memory cleanup انجام می‌شود

📌 نتیجه:

• کاهش overhead حافظه
• افزایش throughput برنامه
• GC سریع‌تر و کم‌وقفه‌تر → مخصوصاً برای برنامه‌های server-side یا پردازش بزرگ

🔹 Write Barriers در Node.js (V8)

• V8 از incremental و generational GC استفاده می‌کند
• Write barriers در V8 پیاده‌سازی شده ولی ساده‌تر از .NET
• برخی بهینه‌سازی‌ها به صورت adaptive هستند، اما به خاطر dynamic typing و frequent object allocation، هنوز overhead وجود دارد

📌 نتیجه: برای workloadهای وب مناسب است، اما در برنامه‌های memory-heavy عملکرد GC کمتر بهینه است

🔹 Write Barriers در Go

• Go AOT compiled است و Garbage Collector همزمان و generational ندارد (Go GC از نوع concurrent و non-generational است)
• Write barrierهای Go ساده و کارآمد هستند ولی کمتر بهینه‌سازی شده نسبت به .NET
• تمرکز Go روی safety و simplicity است، نه نهایت performance GC

📌 نتیجه: برنامه‌ها پایدار و امن هستند ولی throughput GC به اندازه .NET بالا نیست

Object Stack Allocation
این ویژگی باعث می‌شود اشیای کوتاه‌عمر به جای heap روی stack تخصیص پیدا کنند. نتیجه: کاهش فشار روی GC و افزایش سرعت.

Object Stack Allocation چیست؟

• معمولاً اشیاء در heap ذخیره می‌شوند و نیاز به garbage collection دارند.
• Stack Allocation یعنی بعضی اشیاء به جای heap، در stack frame تابع ایجاد شوند.
• مزایا:
  • بدون overhead GC → سریع‌تر
  • کاهش فشار روی حافظه heap
  • افزایش cache locality → دسترسی سریع‌تر به داده‌ها

📌 محدودیت: فقط برای اشیایی که scope محدودی دارند و طول عمرشان کوتاه است

🔹 Object Stack Allocation در .NET 10

• .NET 10 با کمک Escape Analysis تصمیم می‌گیرد که یک شیء:
  1. اگر فقط در همان متد استفاده شود → روی Stack قرار بگیرد.
  2. اگر به خارج از اسکوپ فرار کند (escape) → روی Heap تخصیص داده شود.
• بهبودها نسبت به نسخه‌های قبل:
  • اختصاص خودکار اشیاء کوچک روی Stack بدون نیاز به Span<T> یا stackalloc دستی.
  • کاهش فشار روی GC → بهبود latency و throughput.
• 📌 نتیجه:
  • کارایی بالاتر مخصوصاً در loopهای سنگین و objectهای کوتاه‌عمر (مثل موقت‌ها در پردازش ریاضی و رشته‌ها).

🔹 Object Stack Allocation در Node.js (V8)

• V8 هم از Escape Analysis استفاده می‌کند:
  • اشیائی که فقط داخل یک تابع باقی می‌مانند → روی Stack قرار می‌گیرند.
  • اشیائی که از محدوده خارج شوند → روی Heap.
• محدودیت‌ها:
  • به خاطر dynamic typing جاوااسکریپت، تشخیص escape سخت‌تر است.
  • اغلب اشیاء در Heap تخصیص داده می‌شوند.
• 📌 نتیجه:
  • بهبود محدود. بیشتر اشیاء در Heap هستند و فشار زیادی روی GC وجود دارد.

🔹 Object Stack Allocation در Go

• Go کامپایل‌شده (AOT) است و Escape Analysis در زمان کامپایل انجام می‌شود:
  • اگر یک متغیر نیازی به نگهداری در Heap نداشته باشد → روی Stack قرار می‌گیرد.
  • مثال: متغیرهای محلی در توابع کوتاه عمر.
• مزایا:
  • بسیار پایدار و قابل پیش‌بینی است چون کامپایلر تصمیم نهایی را می‌گیرد.
  • فشار روی GC کاهش پیدا می‌کند.
• 📌 نتیجه:
  • Go به صورت پیش‌فرض در این زمینه خوب است.
  • اما انعطاف .NET 10 (با JIT adaptive) را ندارد.