در قسمت دوم مقاله در مورد شبیه سازهای سیستم کامپیوتری، من به صورت مقدماتی ساده در مورد شبیه سازهای کامپیوتری صحبت خواهم کرد، یعنی در مورد شبیه سازی تمام پلتفرم، که کاربر معمولی اغلب با آن مواجه می شود، و همچنین در مورد ساعت ساعت. -مدل ساعت و ردیابی که بیشتر در محافل توسعه دهندگان رایج است.
В من در مورد اینکه شبیه سازها به طور کلی چیست و همچنین در مورد سطوح شبیه سازی صحبت کردم. اکنون، بر اساس آن دانش، پیشنهاد می‌کنم کمی عمیق‌تر غواصی کنیم و در مورد شبیه‌سازی تمام پلتفرم، نحوه جمع‌آوری ردپاها، کارهایی که بعداً با آنها انجام دهیم، و همچنین در مورد شبیه‌سازی ریزمعماری ساعت به ساعت صحبت کنیم.
شبیه ساز کامل پلت فرم یا "تنها در میدان جنگجو نیست"
اگر می خواهید عملکرد یک دستگاه خاص، به عنوان مثال، یک کارت شبکه را مطالعه کنید، یا سیستم عامل یا درایور را برای این دستگاه بنویسید، می توانید چنین دستگاهی را جداگانه شبیه سازی کنید. با این حال، استفاده از آن جدا از بقیه زیرساخت ها چندان راحت نیست. برای اجرای درایور مربوطه، به یک پردازنده مرکزی، حافظه، دسترسی به گذرگاه داده و غیره نیاز دارید. علاوه بر این، درایور برای عملکرد به یک سیستم عامل (OS) و یک پشته شبکه نیاز دارد. علاوه بر این، ممکن است به یک مولد بسته و سرور پاسخ جداگانه نیاز باشد.
یک شبیه‌ساز تمام پلتفرم، محیطی را برای اجرای یک پشته نرم‌افزاری کامل ایجاد می‌کند که شامل همه چیز از بایوس و بوت‌لودر گرفته تا خود سیستم‌عامل و زیرسیستم‌های مختلف آن، مانند پشته شبکه، درایورها و برنامه‌های کاربردی در سطح کاربر است. برای انجام این کار، مدل‌های نرم‌افزاری اکثر دستگاه‌های کامپیوتری را پیاده‌سازی می‌کند: پردازنده و حافظه، دیسک، دستگاه‌های ورودی/خروجی (صفحه‌کلید، ماوس، نمایشگر)، و همچنین همان کارت شبکه.
در زیر بلوک دیاگرام چیپست x58 اینتل را مشاهده می کنید. یک شبیه‌ساز کامپیوتری تمام پلتفرم در این چیپست به پیاده‌سازی بیشتر دستگاه‌های فهرست‌شده، از جمله دستگاه‌هایی که در داخل IOH (هاب ورودی/خروجی) و ICH (هاب کنترل‌کننده ورودی/خروجی) هستند، نیاز دارد که در نمودار بلوک به‌طور دقیق نشان داده نشده‌اند. . اگرچه، همانطور که تمرین نشان می دهد، دستگاه های زیادی وجود ندارد که توسط نرم افزاری که قرار است اجرا کنیم استفاده نمی شود. مدل های چنین دستگاه هایی نیازی به ایجاد ندارند.
اغلب، شبیه‌سازهای تمام پلتفرم در سطح دستورالعمل پردازنده پیاده‌سازی می‌شوند (ISA، زیر را ببینید). ). این به شما امکان می دهد تا خود شبیه ساز را نسبتاً سریع و ارزان ایجاد کنید. سطح ISA نیز خوب است زیرا بر خلاف مثلاً سطح API/ABI که اغلب تغییر می کند، کم و بیش ثابت می ماند. علاوه بر این، پیاده سازی در سطح دستورالعمل به شما امکان می دهد نرم افزار باینری به اصطلاح اصلاح نشده را اجرا کنید، یعنی کدهای از قبل کامپایل شده را بدون هیچ تغییری اجرا کنید، دقیقاً همانطور که در سخت افزار واقعی استفاده می شود. به عبارت دیگر، شما می توانید یک کپی ("dump") از هارد دیسک خود ایجاد کنید، آن را به عنوان یک تصویر برای یک مدل در یک شبیه ساز تمام پلتفرم مشخص کنید، و voila! - سیستم عامل و سایر برنامه ها بدون هیچ گونه اقدام اضافی در شبیه ساز بارگذاری می شوند.
عملکرد شبیه ساز
همانطور که در بالا ذکر شد، فرآیند شبیه سازی کل سیستم، یعنی تمام دستگاه های آن، کاری نسبتا کند است. اگر همه اینها را در یک سطح بسیار دقیق، به عنوان مثال، ریزمعماری یا منطقی، پیاده سازی کنید، اجرا بسیار کند می شود. اما سطح دستورالعمل انتخاب مناسبی است و به سیستم‌عامل و برنامه‌ها اجازه می‌دهد تا با سرعت کافی برای تعامل راحت کاربر با آنها اجرا شوند.
در اینجا مناسب است که به موضوع عملکرد شبیه ساز بپردازیم. معمولاً بر حسب IPS (دستورالعمل در ثانیه)، به طور دقیق تر با MIPS (میلیون IPS) اندازه گیری می شود، یعنی تعداد دستورالعمل های پردازشگر که توسط شبیه ساز در یک ثانیه اجرا می شود. در عین حال، سرعت شبیه‌سازی به عملکرد سیستمی که شبیه‌سازی روی آن اجرا می‌شود نیز بستگی دارد. بنابراین، ممکن است صحبت در مورد "کندی" شبیه ساز در مقایسه با سیستم اصلی صحیح تر باشد.
رایج ترین شبیه سازهای تمام پلتفرم موجود در بازار، مانند QEMU، VirtualBox یا VmWare Workstation، عملکرد خوبی دارند. حتی ممکن است برای کاربر قابل توجه نباشد که کار در شبیه ساز در حال انجام است. این به لطف قابلیت‌های مجازی‌سازی ویژه‌ای که در پردازنده‌ها، الگوریتم‌های ترجمه باینری و چیزهای جالب دیگر پیاده‌سازی شده‌اند، اتفاق می‌افتد. همه اینها موضوعی برای یک مقاله جداگانه است، اما به طور خلاصه، مجازی سازی یک ویژگی سخت افزاری پردازنده های مدرن است که به شبیه سازها اجازه می دهد دستورالعمل ها را شبیه سازی نکنند، بلکه آنها را برای اجرا مستقیماً به یک پردازنده واقعی ارسال کنند، البته اگر معماری شبیه ساز و پردازنده شبیه هم هستند. ترجمه باینری ترجمه کد ماشین مهمان به کد میزبان و اجرای بعدی بر روی یک پردازنده واقعی است. در نتیجه، شبیه سازی فقط کمی کندتر است، 5-10 بار، و اغلب حتی با همان سرعت سیستم واقعی اجرا می شود. اگرچه این تحت تأثیر عوامل زیادی است. به عنوان مثال، اگر بخواهیم یک سیستم را با چند ده پردازنده شبیه سازی کنیم، سرعت آن بلافاصله چند ده برابر کاهش می یابد. از سوی دیگر، شبیه‌سازهایی مانند Simics در آخرین نسخه‌ها از سخت‌افزار میزبان چند پردازنده پشتیبانی می‌کنند و به طور موثر هسته‌های شبیه‌سازی شده را با هسته‌های یک پردازنده واقعی موازی می‌کنند.
اگر در مورد سرعت شبیه‌سازی ریزمعماری صحبت کنیم، معمولاً چندین مرتبه بزرگی است، حدود 1000-10000 برابر کندتر از اجرا در یک رایانه معمولی، بدون شبیه‌سازی. و پیاده سازی در سطح عناصر منطقی با چندین مرتبه بزرگی کندتر است. بنابراین در این سطح از FPGA به عنوان شبیه ساز استفاده می شود که می تواند عملکرد را به میزان قابل توجهی افزایش دهد.
نمودار زیر یک وابستگی تقریبی سرعت شبیه‌سازی به جزئیات مدل را نشان می‌دهد.
شبیه سازی ضرب به ضرب
با وجود سرعت اجرای کم، شبیه سازهای ریزمعماری بسیار رایج هستند. شبیه سازی بلوک های داخلی پردازنده به منظور شبیه سازی دقیق زمان اجرای هر دستور ضروری است. ممکن است سوء تفاهم در اینجا ایجاد شود - به هر حال، به نظر می رسد، چرا به سادگی زمان اجرا را برای هر دستورالعمل برنامه ریزی نکنیم. اما چنین شبیه‌سازی بسیار نادرست خواهد بود، زیرا زمان اجرای همان دستورالعمل ممکن است از تماسی به تماس دیگر متفاوت باشد.
ساده ترین مثال یک دستورالعمل دسترسی به حافظه است. اگر مکان حافظه درخواستی در حافظه پنهان موجود باشد، زمان اجرا حداقل خواهد بود. اگر این اطلاعات در حافظه پنهان نباشد ("کَش از دست رفته")، زمان اجرای دستور را بسیار افزایش می دهد. بنابراین، یک مدل کش برای شبیه سازی دقیق مورد نیاز است. با این حال، موضوع به مدل کش محدود نمی شود. پردازنده به سادگی منتظر نمی ماند تا داده ها در حافظه پنهان بازیابی شوند. در عوض، شروع به اجرای دستورالعمل‌های بعدی می‌کند و دستورالعمل‌هایی را انتخاب می‌کند که به نتیجه خواندن از حافظه بستگی ندارند. این به اصطلاح اجرای "خارج از نظم" (OOO، اجرای خارج از دستور) است که برای به حداقل رساندن زمان بیکاری پردازنده ضروری است. مدل سازی بلوک های پردازنده مربوطه به در نظر گرفتن همه این موارد هنگام محاسبه زمان اجرای دستورالعمل ها کمک می کند. در میان این دستورالعمل‌ها، که در حالی اجرا می‌شوند که نتیجه خواندن از حافظه در انتظار است، ممکن است یک عملیات پرش شرطی رخ دهد. اگر نتیجه شرط در حال حاضر ناشناخته باشد، دوباره پردازنده اجرا را متوقف نمی کند، بلکه "حدس می زند"، شاخه مناسب را انجام می دهد و به اجرای فعال دستورالعمل ها از نقطه انتقال ادامه می دهد. چنین بلوکی که پیش‌بینی‌کننده شاخه نامیده می‌شود، باید در شبیه‌ساز ریزمعماری نیز پیاده‌سازی شود.
تصویر زیر بلوک های اصلی پردازنده را نشان می دهد، نیازی به دانستن آن نیست، فقط برای نشان دادن پیچیدگی اجرای ریزمعماری نشان داده شده است.
عملکرد همه این بلوک ها در یک پردازنده واقعی با سیگنال های ساعت خاصی هماهنگ می شود و در مدل نیز همین اتفاق می افتد. چنین شبیه ساز ریزمعماری سیکل دقیق نامیده می شود. هدف اصلی آن پیش بینی دقیق عملکرد پردازنده در حال توسعه و/یا محاسبه زمان اجرای یک برنامه خاص، به عنوان مثال، یک معیار است. اگر مقادیر کمتر از مقدار مورد نیاز باشد، لازم است الگوریتم‌ها و بلوک‌های پردازنده را اصلاح کرده یا برنامه را بهینه کنید.
همانطور که در بالا نشان داده شد، شبیه سازی ساعت به ساعت بسیار کند است، بنابراین فقط در هنگام مطالعه لحظات خاصی از عملکرد یک برنامه استفاده می شود، جایی که لازم است سرعت واقعی اجرای برنامه را دریابید و عملکرد آینده دستگاهی را ارزیابی کنید که نمونه اولیه در حال شبیه سازی است.
در این حالت از یک شبیه ساز عملکردی برای شبیه سازی زمان باقی مانده اجرای برنامه استفاده می شود. این ترکیب استفاده در واقعیت چگونه اتفاق می افتد؟ ابتدا شبیه ساز عملکردی راه اندازی می شود که روی آن سیستم عامل و هر آنچه برای اجرای برنامه مورد مطالعه لازم است بارگیری می شود. از این گذشته ، ما نه به خود سیستم عامل علاقه مندیم و نه به مراحل اولیه راه اندازی برنامه ، پیکربندی آن و غیره. با این حال، ما نیز نمی توانیم از این قسمت ها بگذریم و بلافاصله به اجرای برنامه از وسط برویم. بنابراین، تمام این مراحل اولیه بر روی یک شبیه ساز عملکردی اجرا می شود. پس از اجرای برنامه تا لحظه مورد علاقه ما، دو گزینه امکان پذیر است. می توانید مدل را با مدل ساعت به چرخه جایگزین کنید و اجرا را ادامه دهید. حالت شبیه سازی که از کدهای اجرایی (یعنی فایل های برنامه کامپایل شده معمولی) استفاده می کند، شبیه سازی مبتنی بر اجرا نامیده می شود. این رایج ترین گزینه شبیه سازی است. روش دیگری نیز امکان پذیر است - شبیه سازی مبتنی بر ردیابی.
شبیه سازی مبتنی بر ردیابی
از دو مرحله تشکیل شده است. با استفاده از یک شبیه ساز عملکردی یا در یک سیستم واقعی، گزارشی از اقدامات برنامه جمع آوری شده و در یک فایل نوشته می شود. به این لاگ Trace می گویند. بسته به آنچه مورد بررسی قرار می گیرد، ردیابی ممکن است شامل دستورالعمل های اجرایی، آدرس حافظه، شماره پورت و اطلاعات وقفه باشد.
مرحله بعدی "بازی" ردیابی است، زمانی که شبیه ساز ساعت به ساعت ردیابی را می خواند و تمام دستورالعمل های نوشته شده در آن را اجرا می کند. در پایان، زمان اجرای این قطعه از برنامه و همچنین ویژگی های مختلف این فرآیند، به عنوان مثال، درصد بازدید در کش را دریافت می کنیم.
یکی از ویژگی‌های مهم کار با ردیابی‌ها، جبرگرایی است، یعنی با اجرای شبیه‌سازی به روشی که در بالا توضیح داده شد، ما بارها و بارها همان توالی اقدامات را بازتولید می‌کنیم. این امکان را فراهم می کند که با تغییر پارامترهای مدل (اندازه های حافظه پنهان، بافر و صف) و استفاده از الگوریتم های داخلی مختلف یا تنظیم آنها، بررسی شود که چگونه یک پارامتر خاص بر عملکرد سیستم تأثیر می گذارد و کدام گزینه بهترین نتایج را می دهد. همه اینها را می توان با یک مدل دستگاه نمونه اولیه قبل از ایجاد یک نمونه اولیه سخت افزاری واقعی انجام داد.
پیچیدگی این رویکرد در نیاز به اجرای برنامه و جمع آوری ردیابی و همچنین حجم عظیم فایل ردیابی نهفته است. از مزایا می توان به این واقعیت اشاره کرد که برای شبیه سازی تنها بخشی از دستگاه یا پلت فرم مورد نظر کافی است، در حالی که شبیه سازی با اجرا معمولاً نیاز به یک مدل کامل دارد.
بنابراین، در این مقاله به بررسی ویژگی‌های شبیه‌سازی تمام پلتفرم، سرعت پیاده‌سازی در سطوح مختلف، شبیه‌سازی ساعت به چرخه و ردیابی پرداختیم. در مقاله بعدی سناریوهای اصلی استفاده از شبیه سازها را هم برای اهداف شخصی و هم از نقطه نظر توسعه در شرکت های بزرگ شرح خواهم داد.
منبع: www.habr.com