Simulator sistem komputer: simulator platform lengkap yang familier dan searah jarum jam serta jejak yang tidak diketahui

Pada artikel bagian kedua tentang simulator sistem komputer, saya akan melanjutkan pembahasan secara sederhana tentang simulator komputer, yaitu tentang simulasi full-platform yang paling sering ditemui oleh rata-rata pengguna, serta tentang jam demi jam. -model jam dan jejak, yang lebih umum di kalangan pengembang.

В bagian pertama Saya berbicara tentang apa itu simulator secara umum, serta tentang level-level simulasi. Sekarang, berdasarkan pengetahuan itu, saya mengusulkan untuk menyelami lebih dalam dan berbicara tentang simulasi platform penuh, cara mengumpulkan jejak, apa yang harus dilakukan nanti, serta tentang emulasi mikroarsitektur jam demi jam.

Simulator platform penuh, atau “Sendirian di lapangan bukanlah seorang pejuang”

Jika Anda ingin mempelajari pengoperasian satu perangkat tertentu, misalnya kartu jaringan, atau menulis firmware atau driver untuk perangkat ini, maka perangkat tersebut dapat disimulasikan secara terpisah. Namun, menggunakannya secara terpisah dari infrastruktur lainnya sangatlah tidak nyaman. Untuk menjalankan driver yang sesuai, Anda memerlukan prosesor pusat, memori, akses ke bus data, dll. Selain itu, driver memerlukan sistem operasi (OS) dan tumpukan jaringan agar dapat berfungsi. Selain itu, generator paket dan server respons terpisah mungkin diperlukan.

Simulator platform penuh menciptakan lingkungan untuk menjalankan tumpukan perangkat lunak lengkap, yang mencakup semuanya mulai dari BIOS dan bootloader hingga OS itu sendiri dan berbagai subsistemnya, seperti tumpukan jaringan, driver, dan aplikasi tingkat pengguna yang sama. Untuk melakukan hal ini, ia mengimplementasikan model perangkat lunak dari sebagian besar perangkat komputer: prosesor dan memori, disk, perangkat input/output (keyboard, mouse, layar), serta kartu jaringan yang sama.

Di bawah ini adalah diagram blok chipset x58 dari Intel. Simulator komputer platform penuh pada chipset ini memerlukan implementasi sebagian besar perangkat yang terdaftar, termasuk perangkat di dalam IOH (Input/Output Hub) dan ICH (Input/Output Controller Hub), yang tidak digambarkan secara detail pada diagram blok . Meskipun, seperti yang ditunjukkan oleh praktik, tidak banyak perangkat yang tidak menggunakan perangkat lunak yang akan kita jalankan. Model perangkat tersebut tidak perlu dibuat.

Paling sering, simulator platform penuh diimplementasikan pada tingkat instruksi prosesor (ISA, lihat di bawah). artikel sebelumnya). Hal ini memungkinkan Anda membuat simulator itu sendiri dengan relatif cepat dan murah. Level ISA juga bagus karena kurang lebih konstan, tidak seperti misalnya level API/ABI yang lebih sering berubah. Selain itu, implementasi pada tingkat instruksi memungkinkan Anda menjalankan apa yang disebut perangkat lunak biner yang tidak dimodifikasi, yaitu menjalankan kode yang sudah dikompilasi tanpa perubahan apa pun, persis seperti yang digunakan pada perangkat keras sebenarnya. Dengan kata lain, Anda dapat membuat salinan (“dump”) hard drive Anda, menentukannya sebagai gambar untuk model dalam simulator platform lengkap, dan voila! – OS dan program lain dimuat di simulator tanpa tindakan tambahan apa pun.

Kinerja simulator

Seperti disebutkan di atas, proses simulasi seluruh sistem, yaitu semua perangkatnya, merupakan pekerjaan yang agak lambat. Jika Anda juga menerapkan semua ini pada tingkat yang sangat detail, misalnya mikroarsitektur atau logis, maka eksekusi akan menjadi sangat lambat. Namun tingkat instruksi adalah pilihan yang tepat dan memungkinkan OS dan program dijalankan dengan kecepatan yang cukup agar pengguna dapat berinteraksi dengan nyaman.

Di sini akan tepat untuk menyentuh topik kinerja simulator. Biasanya diukur dalam IPS (instruksi per detik), lebih tepatnya dalam MIPS (jutaan IPS), yaitu jumlah instruksi prosesor yang dieksekusi oleh simulator dalam satu detik. Pada saat yang sama, kecepatan simulasi juga bergantung pada kinerja sistem tempat simulasi itu berjalan. Oleh karena itu, mungkin lebih tepat membicarakan “perlambatan” simulator dibandingkan dengan sistem aslinya.

Simulator platform lengkap yang paling umum di pasaran, seperti QEMU, VirtualBox, atau VmWare Workstation, memiliki kinerja yang baik. Bahkan mungkin tidak terlihat oleh pengguna bahwa pekerjaan sedang berlangsung di simulator. Hal ini terjadi berkat kemampuan virtualisasi khusus yang diterapkan pada prosesor, algoritma terjemahan biner dan hal menarik lainnya. Ini semua adalah topik untuk artikel terpisah, tetapi singkatnya, virtualisasi adalah fitur perangkat keras dari prosesor modern yang memungkinkan simulator untuk tidak mensimulasikan instruksi, tetapi mengirimkannya untuk dieksekusi langsung ke prosesor sebenarnya, kecuali, tentu saja, arsitekturnya. simulator dan prosesornya serupa. Terjemahan biner adalah penerjemahan kode mesin tamu ke dalam kode host dan eksekusi selanjutnya pada prosesor sebenarnya. Akibatnya, simulasi hanya sedikit lebih lambat, 5-10 kali lipat, dan bahkan sering kali berjalan pada kecepatan yang sama dengan sistem sebenarnya. Meskipun hal ini dipengaruhi oleh banyak faktor. Misalnya, jika kita ingin mensimulasikan sistem dengan beberapa lusin prosesor, maka kecepatannya akan langsung turun beberapa puluh kali lipat. Di sisi lain, simulator seperti Simics dalam versi terbaru mendukung perangkat keras host multiprosesor dan secara efektif memparalelkan inti yang disimulasikan ke inti prosesor sebenarnya.

Jika kita berbicara tentang kecepatan simulasi mikroarsitektur, biasanya beberapa kali lipat, sekitar 1000-10000 kali lebih lambat daripada eksekusi pada komputer biasa, tanpa simulasi. Dan implementasi pada tingkat elemen logika lebih lambat beberapa kali lipat. Oleh karena itu, FPGA digunakan sebagai emulator pada level ini, yang dapat meningkatkan kinerja secara signifikan.

Grafik di bawah menunjukkan perkiraan ketergantungan kecepatan simulasi pada detail model.

Simulasi ketukan demi ketukan

Meskipun kecepatan eksekusinya rendah, simulator mikroarsitektur cukup umum. Simulasi blok internal prosesor diperlukan untuk mensimulasikan waktu eksekusi setiap instruksi secara akurat. Kesalahpahaman mungkin muncul di sini - lagi pula, tampaknya mengapa tidak memprogram waktu eksekusi untuk setiap instruksi saja. Tetapi simulator seperti itu akan sangat tidak akurat, karena waktu eksekusi instruksi yang sama mungkin berbeda dari satu panggilan ke panggilan lainnya.

Contoh paling sederhana adalah instruksi akses memori. Jika lokasi memori yang diminta tersedia di cache, maka waktu eksekusi akan menjadi minimal. Jika informasi ini tidak ada dalam cache (“cache miss”), maka ini akan sangat meningkatkan waktu eksekusi instruksi. Oleh karena itu, model cache diperlukan untuk simulasi yang akurat. Namun, masalahnya tidak terbatas pada model cache. Prosesor tidak akan begitu saja menunggu data diambil dari memori saat data tersebut tidak ada dalam cache. Sebaliknya, ia akan mulai menjalankan instruksi selanjutnya, memilih instruksi yang tidak bergantung pada hasil membaca dari memori. Inilah yang disebut eksekusi “out of order” (OOO, eksekusi di luar urutan), yang diperlukan untuk meminimalkan waktu idle prosesor. Memodelkan blok prosesor yang sesuai akan membantu mempertimbangkan semua ini saat menghitung waktu eksekusi instruksi. Di antara instruksi-instruksi ini, yang dijalankan sementara hasil pembacaan dari memori ditunggu, operasi lompatan bersyarat dapat terjadi. Jika hasil dari kondisi tersebut tidak diketahui saat ini, maka sekali lagi prosesor tidak menghentikan eksekusi, namun membuat “tebakan”, melakukan cabang yang sesuai dan terus secara proaktif mengeksekusi instruksi dari titik transisi. Blok seperti itu, yang disebut prediktor cabang, juga harus diimplementasikan dalam simulator mikroarsitektur.

Gambar di bawah ini menunjukkan blok-blok utama prosesor, tidak perlu diketahui, hanya ditampilkan untuk menunjukkan kompleksitas implementasi mikroarsitektur.

Pengoperasian semua blok ini dalam prosesor sebenarnya disinkronkan oleh sinyal jam khusus, dan hal yang sama terjadi pada model. Simulator mikroarsitektur seperti itu disebut siklus akurat. Tujuan utamanya adalah untuk secara akurat memprediksi kinerja prosesor yang sedang dikembangkan dan/atau menghitung waktu eksekusi program tertentu, misalnya benchmark. Jika nilainya lebih rendah dari yang dibutuhkan, maka algoritma dan blok prosesor perlu diubah atau mengoptimalkan program.

Seperti yang ditunjukkan di atas, simulasi jam demi jam sangat lambat, sehingga hanya digunakan ketika mempelajari momen-momen tertentu dari operasi suatu program, di mana perlu untuk mengetahui kecepatan sebenarnya dari eksekusi program dan mengevaluasi kinerja perangkat di masa depan. prototipe sedang disimulasikan.

Dalam hal ini, simulator fungsional digunakan untuk mensimulasikan sisa waktu berjalan program. Bagaimana kombinasi penggunaan ini terjadi dalam kenyataan? Pertama, simulator fungsional diluncurkan, di mana OS dan semua yang diperlukan untuk menjalankan program yang sedang dipelajari dimuat. Lagi pula, kami tidak tertarik pada OS itu sendiri, atau pada tahap awal peluncuran program, konfigurasinya, dll. Namun kita juga tidak bisa melewatkan bagian ini dan langsung melanjutkan mengeksekusi program dari tengah. Oleh karena itu, semua langkah awal ini dijalankan pada simulator fungsional. Setelah program dijalankan hingga momen yang kami minati, ada dua opsi yang mungkin. Anda dapat mengganti model dengan model jam demi siklus dan melanjutkan eksekusi. Mode simulasi yang menggunakan kode yang dapat dieksekusi (yaitu, file program yang dikompilasi secara teratur) disebut simulasi yang didorong oleh eksekusi. Ini adalah opsi simulasi yang paling umum. Pendekatan lain juga dimungkinkan - simulasi berbasis jejak.

Simulasi berbasis jejak

Ini terdiri dari dua langkah. Menggunakan simulator fungsional atau pada sistem nyata, log tindakan program dikumpulkan dan ditulis ke file. Log ini disebut jejak. Tergantung pada apa yang diperiksa, jejaknya mungkin mencakup instruksi yang dapat dieksekusi, alamat memori, nomor port, dan informasi interupsi.

Langkah selanjutnya adalah “memainkan” jejak, ketika simulator jam demi jam membaca jejak dan menjalankan semua instruksi yang tertulis di dalamnya. Pada akhirnya, kami mendapatkan waktu eksekusi bagian program ini, serta berbagai karakteristik proses ini, misalnya persentase hit di cache.

Fitur penting dalam bekerja dengan jejak adalah determinisme, yaitu dengan menjalankan simulasi dengan cara yang dijelaskan di atas, kita mereproduksi urutan tindakan yang sama berulang kali. Hal ini memungkinkan, dengan mengubah parameter model (ukuran cache, buffer, dan antrian) dan menggunakan algoritme internal yang berbeda atau menyetelnya, untuk mempelajari bagaimana parameter tertentu memengaruhi kinerja sistem dan opsi mana yang memberikan hasil terbaik. Semua ini dapat dilakukan dengan model perangkat prototipe sebelum membuat prototipe perangkat keras yang sebenarnya.

Kompleksitas pendekatan ini terletak pada kebutuhan untuk menjalankan aplikasi terlebih dahulu dan mengumpulkan jejak, serta ukuran file jejak yang sangat besar. Keuntungannya termasuk fakta bahwa simulasi hanya bagian dari perangkat atau platform yang diinginkan saja, sedangkan simulasi dengan eksekusi biasanya memerlukan model yang lengkap.

Jadi, dalam artikel ini kita melihat fitur simulasi platform penuh, berbicara tentang kecepatan implementasi di berbagai level, simulasi jam demi siklus, dan penelusuran. Pada artikel selanjutnya saya akan menjelaskan skenario utama penggunaan simulator, baik untuk keperluan pribadi maupun dari sudut pandang pengembangan di perusahaan besar.

Sumber: www.habr.com