Anda bukan seorang budak!
Kursus pendidikan tertutup untuk anak-anak elit: "Pengaturan dunia yang sebenarnya."
http://noslave.org
Bahan dari Wikipedia - ensiklopedia gratis
| Kesalahan Lua di Modul:Wikidata pada baris 170: mencoba mengindeks bidang "wikibase" (nilai nihil). | ||||||||||||||||||||||||||||||||||||
| Jenis | ||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Pengarang |
Kesalahan Lua di Modul:Wikidata pada baris 170: mencoba mengindeks bidang "wikibase" (nilai nihil). |
|||||||||||||||||||||||||||||||||||
| Pengembang | ||||||||||||||||||||||||||||||||||||
| Pengembang |
Kesalahan Lua di Modul:Wikidata pada baris 170: mencoba mengindeks bidang "wikibase" (nilai nihil). |
|||||||||||||||||||||||||||||||||||
| Ditulis pada |
Kesalahan Lua di Modul:Wikidata pada baris 170: mencoba mengindeks bidang "wikibase" (nilai nihil). |
|||||||||||||||||||||||||||||||||||
| Antarmuka |
Kesalahan Lua di Modul:Wikidata pada baris 170: mencoba mengindeks bidang "wikibase" (nilai nihil). |
|||||||||||||||||||||||||||||||||||
| sistem operasi | ||||||||||||||||||||||||||||||||||||
| Bahasa antarmuka |
Kesalahan Lua di Modul:Wikidata pada baris 170: mencoba mengindeks bidang "wikibase" (nilai nihil). |
|||||||||||||||||||||||||||||||||||
| Edisi pertama |
Kesalahan Lua di Modul:Wikidata pada baris 170: mencoba mengindeks bidang "wikibase" (nilai nihil). |
|||||||||||||||||||||||||||||||||||
| Platform perangkat keras | ||||||||||||||||||||||||||||||||||||
| Versi terbaru | ||||||||||||||||||||||||||||||||||||
| Pelepasan Kandidat |
Kesalahan Lua di Modul:Wikidata pada baris 170: mencoba mengindeks bidang "wikibase" (nilai nihil). |
|||||||||||||||||||||||||||||||||||
| Versi beta |
Kesalahan Lua di Modul:Wikidata pada baris 170: mencoba mengindeks bidang "wikibase" (nilai nihil). |
|||||||||||||||||||||||||||||||||||
| Versi alfa |
Kesalahan Lua di Modul:Wikidata pada baris 170: mencoba mengindeks bidang "wikibase" (nilai nihil). |
|||||||||||||||||||||||||||||||||||
| Versi uji |
Kesalahan Lua di Modul:Wikidata pada baris 170: mencoba mengindeks bidang "wikibase" (nilai nihil). |
|||||||||||||||||||||||||||||||||||
| Format file yang dapat dibaca |
Kesalahan Lua di Modul:Wikidata pada baris 170: mencoba mengindeks bidang "wikibase" (nilai nihil). |
|||||||||||||||||||||||||||||||||||
| Format file yang dihasilkan |
Kesalahan Lua di Modul:Wikidata pada baris 170: mencoba mengindeks bidang "wikibase" (nilai nihil). |
|||||||||||||||||||||||||||||||||||
| Negara |
Kesalahan Lua di Modul:Wikidata pada baris 170: mencoba mengindeks bidang "wikibase" (nilai nihil). |
|||||||||||||||||||||||||||||||||||
| Lisensi |
Fitur utama:
Kompiler mendukung standar OpenMP 3.0 untuk menulis program paralel. Juga berisi modifikasi OpenMP yang disebut Cluster OpenMP, yang dengannya Anda dapat menjalankan aplikasi yang ditulis sesuai dengan OpenMP pada cluster menggunakan MPI. Intel C++ Compiler menggunakan frontend (bagian kompiler yang mem-parsing program yang dikompilasi) dari Edison Design Group. Frontend yang sama digunakan oleh kompiler SGI MIPSpro, Comeau C++, dan Portland Group. Kompiler ini banyak digunakan untuk mengkompilasi benchmark SPEC CPU. Ada 4 seri produk dari Intel yang berisi compiler:
Kerugian dari kompiler versi Linux termasuk ketidakcocokan sebagian dengan ekstensi GNU dari bahasa C (didukung oleh kompiler GCC), yang dapat menyebabkan masalah saat mengkompilasi beberapa program.
Opsi eksperimentalVersi eksperimental kompiler berikut telah diterbitkan:
Bendera dasar
Tulis ulasan tentang artikel "Kompilator Intel C++"CatatanLihat jugaTautan
Kutipan yang mencirikan kompiler Intel C++Dan juga, dia kembali menemui Magus Putih untuk terakhir kalinya... Suaminya dan sahabat sejatinya, yang tidak akan pernah bisa dia lupakan. Dalam hatinya dia memaafkannya. Tapi, yang sangat disesalkannya, dia tidak bisa memberinya pengampunan Magdalena.... Jadi, seperti yang Anda lihat, Isidora, dongeng besar Kristen tentang "pengampunan" hanyalah kebohongan kekanak-kanakan bagi orang-orang percaya yang naif, untuk membiarkan mereka untuk melakukan Kejahatan apa pun, mengetahui bahwa apa pun yang mereka lakukan, pada akhirnya mereka akan diampuni. Tapi Anda hanya bisa memaafkan orang yang benar-benar layak untuk dimaafkan. Seseorang harus memahami bahwa dia harus bertanggung jawab atas setiap Kejahatan yang dilakukan... Dan bukan di hadapan Tuhan yang misterius, tetapi di hadapan dirinya sendiri, memaksa dirinya untuk menderita dengan kejam. Magdalena tidak memaafkan Vladyka, meskipun dia sangat menghormati dan dengan tulus mencintainya. Sama seperti dia gagal memaafkan kita semua atas kematian Radomir yang mengerikan. Bagaimanapun, DIA mengerti lebih baik daripada orang lain - kami bisa membantunya, kami bisa menyelamatkannya dari kematian yang kejam... Tapi kami tidak mau. Mengingat kesalahan Magus Putih terlalu kejam, dia membiarkannya hidup dengan rasa bersalah ini, tidak melupakannya sejenak... Dia tidak ingin memberinya pengampunan dengan mudah. Kami tidak pernah melihatnya lagi. Sama seperti mereka tidak pernah melihat bayi mereka. Melalui salah satu ksatria Kuilnya - penyihir kami - Magdalena menyampaikan jawaban Vladyka atas permintaannya untuk kembali kepada kami: “Matahari tidak terbit dua kali pada hari yang sama... Kegembiraan duniamu (Radomir) akan tidak pernah kembali kepadamu, sama seperti aku tidak akan kembali kepadamu dan aku... Aku menemukan IMAN dan KEBENARANku, mereka HIDUP, tetapi milikmu MATI... Berdukalah atas putra-putramu - mereka mencintaimu. Aku tidak akan pernah memaafkanmu atas kematian mereka selama aku masih hidup. Dan semoga rasa bersalahmu tetap ada padamu. Mungkin suatu hari nanti dia akan membawakanmu Cahaya dan Pengampunan... Tapi bukan dariku.” Kepala Magus John tidak dibawa ke Meteora karena alasan yang sama - tidak ada Ksatria Kuil yang ingin kembali kepada kami... Kami kehilangan mereka, karena kami telah kehilangan banyak orang lain lebih dari sekali, yang tidak mau memahami dan menerima korban kami... Siapa yang melakukan hal yang sama seperti Anda - mereka pergi, mengutuk kami.Kepalaku pusing!.. Seperti orang yang haus, memuaskan rasa lapar abadiku akan pengetahuan, aku dengan rakus menyerap aliran informasi luar biasa yang dengan murah hati diberikan oleh Utara... Dan aku ingin lebih banyak lagi!.. Aku ingin tahu segalanya untuk tamat. Itu adalah embusan air segar di gurun yang hangus karena kesakitan dan kesulitan! Dan aku tidak pernah merasa cukup dengan itu... – Saya punya ribuan pertanyaan! Tapi tidak ada waktu lagi... Apa yang harus aku lakukan, Utara?.. - Tanyakan, Isidora!.. Tanyakan, saya akan mencoba menjawab Anda... – Katakan padaku, Sever, mengapa bagiku cerita ini seolah-olah menggabungkan dua kisah hidup, terjalin dengan peristiwa serupa, dan disajikan sebagai kehidupan satu orang? Atau aku tidak benar? – Anda benar sekali, Isidora. Seperti yang saya katakan sebelumnya, “kekuatan dunia ini,” yang menciptakan sejarah palsu umat manusia, “mengenakan” kehidupan Kristus yang sebenarnya, kehidupan asing dari nabi Yahudi Yosua, yang hidup satu setengah ribu tahun yang lalu ( dari masa cerita Utara). Dan bukan hanya dirinya sendiri, tetapi juga keluarganya, kerabat dan sahabatnya, sahabat dan pengikutnya. Bagaimanapun, itu adalah istri nabi Yosua, Maria Yahudi, yang memiliki saudara perempuan Marta dan saudara laki-laki Lazarus, saudara perempuan ibunya Maria Yakobe, dan orang lain yang tidak pernah dekat dengan Radomir dan Magdalena. Sama seperti tidak ada “rasul” lain di samping mereka – Paulus, Matius, Petrus, Lukas dan yang lainnya… Keluarga nabi Yosualah yang pindah satu setengah ribu tahun yang lalu ke Provence (yang pada masa itu disebut Transalpine Gaul), ke kota Massalia di Yunani (sekarang Marseille), karena Massalia pada waktu itu adalah kota “pintu gerbang” antara Eropa dan Asia, dan ini adalah cara termudah bagi mereka yang “teraniaya” untuk menghindari penganiayaan dan masalah.
| |||||||||||||||||||||||||||||||||||
PendahuluanPada akhir tahun 2003, Intel memperkenalkan versi 8.0 dari koleksi kompilernya. Kompiler baru dirancang untuk meningkatkan kinerja aplikasi yang berjalan di server, PC desktop, dan sistem seluler(laptop, ponsel dan PDA) berbasis Prosesor Intel. Menarik untuk dicatat bahwa produk ini dibuat dengan partisipasi aktif karyawan Pusat Pengembangan Perangkat Lunak Intel Nizhny Novgorod dan spesialis Intel dari Sarov.
Seri baru ini mencakup kompiler Intel C++ dan Fortran untuk Windows dan Linux, serta kompiler Intel C++ untuk Windows CE .NET. Kompiler ditargetkan pada sistem berdasarkan prosesor Intel berikut: Intel Itanium 2, Intel Xeon, Intel Pentium 4, prosesor dengan Arsitektur Klien Internet Pribadi Intel untuk ponsel dan Pocket PC serta Prosesor Seluler Intel Pentium M (komponen Teknologi Seluler Intel Centrino).
Intel Visual Fortran Compiler untuk Windows menyediakan teknologi kompilasi generasi berikutnya untuk solusi komputasi performa tinggi. Ini menggabungkan fungsionalitas bahasa Compaq Visual Fortran (CVF) dengan peningkatan kinerja yang dimungkinkan oleh kompilasi Intel dan teknologi pengoptimalan pembuatan kode untuk menyederhanakan tugas porting Kode sumber, dikembangkan menggunakan CVF, ke dalam lingkungan Intel Visual Fortran. Kompiler ini memperkenalkan fungsi CVF untuk pertama kalinya untuk sistem Intel 32-bit dan sistem berbasis prosesor keluarga Intel Itanium yang berjalan di Lingkungan Windows. Selain itu, kompiler ini memungkinkan Anda mengimplementasikan fungsi bahasa CVF pada sistem Linux berdasarkan prosesor Intel 32-bit dan prosesor keluarga Intel Itanium. Pada tahun 2004, direncanakan untuk merilis versi yang diperluas dari kompiler ini - Intel Visual Fortran Compiler Professional Edition untuk OS Windows, yang akan mencakup Perpustakaan IMSL Fortran 5.0 yang dikembangkan oleh Visual Numerics, Inc.
“Kompiler baru ini juga mendukung prosesor Intel masa depan, dengan nama kode Prescott, yang mencakup perintah kinerja grafis dan video baru serta peningkatan kinerja lainnya. Mereka juga mendukung teknologi baru Mobile MMX(tm), yang juga meningkatkan kinerja aplikasi grafis, audio dan video untuk ponsel dan PC genggam, kata salah satu direktur Intel Software Engineering Center. Nizhny Novgorod Alexei Odinokov. - Kompiler ini memberi pengembang aplikasi satu set alat untuk membangun aplikasi baru jaringan nirkabel berdasarkan arsitektur Intel. Kompiler Intel baru juga mendukung teknologi Hyper-Threading Intel dan spesifikasi industri OpenMP 2.0 yang mendefinisikan penggunaan arahan level tinggi untuk mengontrol aliran instruksi dalam aplikasi."
Alat baru yang disertakan dalam kompiler mencakup Cakupan Kode Intel dan Prioritas Pengujian Intel. Bersama-sama, alat-alat ini memungkinkan Anda mempercepat pengembangan aplikasi dan meningkatkan kualitas aplikasi dengan meningkatkan proses pengujian perangkat lunak.
Alat Cakupan Kode memberikan informasi lengkap tentang penggunaan logika aplikasi dan lokasi area yang digunakan dalam kode sumber aplikasi selama pengujian aplikasi. Jika perubahan dilakukan pada aplikasi atau jika pengujian ini tidak memungkinkan pemeriksaan bagian aplikasi yang menarik minat pengembang, alat Prioritas Pengujian memungkinkan Anda memeriksa pengoperasian bagian yang dipilih kode program.
Kompiler Intel baru tersedia dalam konfigurasi berbeda, dengan harga mulai dari $399 hingga $1,499. Mereka dapat dibeli hari ini dari Intel atau dari pengecer di seluruh dunia, daftarnya terdapat di situs web http://www.intel.com/software/products/reseller.htm#Russia.
Dukungan prosesor Prescott
Dukungan untuk prosesor Intel Pentium 4 (Prescott) pada compiler versi kedelapan adalah sebagai berikut:1. Dukungan untuk perintah SSE3 (atau PNI, Instruksi Baru Prescott). Ada tiga cara untuk membedakannya di sini:
A. Sisipan rakitan (Perakitan sebaris). Misalnya, kompiler mengenali penggunaan perintah SSE3 berikut _asm(addsubpd xmm0, xmm1). Dengan cara ini, pengguna yang tertarik dengan optimasi tingkat rendah bisa mendapatkan akses langsung ke perintah perakitan.
B. Dalam kompiler C/C++, instruksi baru tersedia dari tingkat yang lebih tinggi daripada penggunaan sisipan rakitan. Yaitu melalui fungsi bawaan (fungsi intrinsik):
Fungsi bawaan
| Fungsi bawaan | Perintah yang dihasilkan |
|---|---|
| _mm_addsub_ps | Tambahkan subps |
| _mm_hadd_ps | Haddps |
| _mm_hsub_ps | Msubps |
| _mm_moveldup_ps | Bergerak |
| _mm_movehdup_ps | Bergerak |
| _mm_addsub_pd | Tambahkan subpd |
| _mm_hadd_pd | Haddpd |
| _mm_hsub_pd | Hsubpd |
| _mm_loaddup_pd | movddup xmm, m64 |
| _mm_movedup_pd | movddup reg, reg |
| _mm_lddqu_si128 | Lddqu |
Tabel menunjukkan fungsi bawaan dan instruksi perakitan terkait dari set SSE3. Dukungan yang sama ada untuk perintah dari set MMX\SSE\SSE2. Hal ini memungkinkan pemrogram untuk melakukan optimasi kode tingkat rendah tanpa menggunakan pemrograman bahasa rakitan: kompiler sendiri menangani pemetaan fungsi bawaan ke instruksi prosesor yang sesuai dan penggunaan register secara optimal. Pemrogram dapat berkonsentrasi pada pembuatan algoritma yang efisien menggunakan set instruksi baru.
V. Pembuatan perintah baru secara otomatis oleh kompiler. Dua metode sebelumnya mengharuskan programmer untuk menggunakan perintah baru. Namun kompiler juga mampu (menggunakan opsi yang sesuai - lihat bagian 3 di bawah) untuk secara otomatis menghasilkan perintah baru dari kumpulan SSE3 untuk kode program dalam C/C++ dan Fortran. Misalnya, perintah pemuatan tidak selaras (lddqu) yang dioptimalkan, yang penggunaannya memungkinkan Anda mencapai peningkatan kinerja hingga 40% (misalnya, dalam tugas pengkodean video dan audio). Perintah lain di set SSE3 memungkinkan Anda mendapatkan kecepatan yang signifikan dalam tugas grafis 3D atau masalah perhitungan menggunakan bilangan kompleks. Misalnya, grafik di bagian 3.1 di bawah menunjukkan bahwa untuk aplikasi 168.wupwise dari rangkaian SPEC CPU2000 FP, kecepatan yang diperoleh dari pembuatan instruksi SSE3 otomatis adalah ~25%. Kinerja aplikasi ini sangat bergantung pada kecepatan aritmatika bilangan kompleks.
2. Menggunakan keunggulan mikroarsitektur dari prosesor Prescott. Saat membuat kode, kompiler memperhitungkan perubahan mikroarsitektur pada prosesor baru. Misalnya, beberapa operasi (seperti pergeseran bilangan bulat, perkalian bilangan bulat, atau konversi angka antara format titik-mengambang yang berbeda di SSE2) lebih cepat pada prosesor baru dibandingkan versi sebelumnya (misalnya, pergeseran bilangan bulat sekarang memerlukan satu siklus prosesor versus empat untuk versi sebelumnya prosesor Intel Pentium 4). Penggunaan perintah tersebut secara lebih intensif dapat mempercepat aplikasi secara signifikan.
Contoh lain dari perubahan mikroarsitektur adalah peningkatan mekanisme penerusan penyimpanan (pemuatan cepat data yang sebelumnya disimpan dalam memori); penyimpanan aktual bahkan tidak terjadi di memori cache, namun di beberapa buffer penyimpanan perantara, yang kemudian memungkinkan akses sangat cepat ke data. Fitur arsitektur ini memungkinkan, misalnya, penerapan vektorisasi otomatis kode program yang lebih agresif.
Kompiler juga memperhitungkan peningkatan ukuran cache tingkat pertama dan kedua.
3. Peningkatan dukungan untuk teknologi Hyper-Threading. Poin ini mungkin terkait dengan poin sebelumnya - perubahan mikroarsitektur dan penggunaannya dalam kompiler. Misalnya, perpustakaan runtime yang mengimplementasikan dukungan untuk spesifikasi industri OpenMP telah dioptimalkan untuk berjalan pada prosesor baru.
Pertunjukan
Menggunakan kompiler itu sederhana dan metode yang efektif memanfaatkan arsitektur prosesor Intel. Di bawah ini, secara kondisional (sangat) dua cara menggunakan kompiler disorot: a) mengkompilasi ulang program dengan kemungkinan perubahan pengaturan compiler, b) kompilasi ulang dengan perubahan baik pada pengaturan compiler maupun teks sumber, serta penggunaan diagnostik compiler untuk optimasi yang dilakukan dan kemungkinan penggunaan yang lain perangkat lunak(misalnya, profiler).1.1 Mengoptimalkan program menggunakan kompilasi ulang dan mengubah pengaturan kompiler
Seringkali langkah pertama dalam bermigrasi ke kompiler pengoptimalan baru adalah menggunakannya dengan pengaturan defaultnya. Langkah logis berikutnya adalah menggunakan opsi untuk optimasi yang lebih agresif. Gambar 1, 2, 3 dan 4 menunjukkan efek peralihan ke kompiler Intel versi 8.0 dibandingkan dengan menggunakan produk industri terkemuka lainnya (-O2 - pengaturan kompiler default, basis - pengaturan untuk penampilan maksimal). Perbandingan dilakukan pada arsitektur Intel 32 dan 64-bit. Aplikasi dari SPEC CPU2000 digunakan sebagai set pengujian.
Gambar 1
Gambar 2
Gambar 3
Gambar 4
Beberapa opsi tercantum di bawah (opsi berikut adalah untuk keluarga OS Windows; untuk keluarga OS Linux terdapat opsi dengan efek yang sama, namun namanya mungkin berbeda; misalnya, -Od atau QxK untuk Windows memiliki efek yang mirip dengan - O0 atau -xK untuk Linux; lebih lanjut Informasi rinci dapat ditemukan di manual kompiler) yang didukung oleh kompiler Intel.
Mengontrol tingkat pengoptimalan: Opsi -Od (tidak ada optimasi; digunakan untuk debugging program), -O1 ( kecepatan maksimum ketika meminimalkan ukuran kode), -O2 (optimasi untuk kecepatan eksekusi kode; diterapkan secara default), -O3 (mengaktifkan optimasi paling agresif untuk kecepatan eksekusi kode; dalam beberapa kasus dapat menyebabkan efek sebaliknya, yaitu. untuk memperlambat; Perlu dicatat bahwa pada IA-64 penggunaan -O3 menyebabkan akselerasi dalam banyak kasus, sedangkan efek positif pada IA-32 kurang terasa). Contoh pengoptimalan yang diaktifkan oleh -O3: pertukaran loop, fusi loop, distribusi loop (optimasi, fusi loop terbalik), pengambilan data perangkat lunak. Alasan mengapa mungkin terjadi perlambatan saat menggunakan -O3 mungkin karena kompiler menggunakan pendekatan heuristik dalam memilih optimasi yang agresif untuk kasus tertentu, tanpa memiliki informasi yang memadai tentang program (misalnya, menghasilkan instruksi pengambilan awal untuk data yang digunakan dalam satu perulangan, dengan keyakinan bahwa perulangan tersebut dieksekusi berkali-kali, padahal sebenarnya hanya memiliki beberapa iterasi). Optimalisasi antarprosedural untuk pembuatan profil, serta berbagai “tip” pemrogram (lihat bagian 3.2) dapat membantu dalam situasi ini.
Optimasi antarprosedural: -Qip (dalam satu file) dan -Qipo (dalam beberapa atau semua file proyek). Mencakup pengoptimalan seperti, misalnya, substitusi sebaris kode yang sering digunakan (mengurangi biaya pemanggilan fungsi/prosedur). Memberikan informasi ke tahap pengoptimalan lainnya - misalnya, informasi tentang batas atas loop (misalnya, jika konstanta waktu kompilasi ditentukan dalam satu file tetapi digunakan di banyak file) atau informasi tentang penyelarasan data di memori (banyak MMX\SSE\SSE2 Perintah \SSE3 bekerja lebih cepat jika operan disejajarkan dalam memori ke batas 8 atau 16 byte). Analisis prosedur alokasi memori (diimplementasikan/dipanggil di salah satu file proyek) diteruskan ke fungsi/prosedur di mana memori ini digunakan (ini dapat membantu kompiler untuk mengabaikan asumsi konservatif bahwa data tidak disejajarkan dengan benar dalam memori; dan asumsinya harus konservatif ketika kurangnya informasi tambahan). Contoh lainnya adalah disambiguasi, analisis aliasing data: dengan tidak adanya informasi tambahan dan ketidakmungkinan membuktikan tidak adanya persimpangan, penyusun membuat asumsi konservatif bahwa terdapat persimpangan. Keputusan seperti itu dapat berdampak negatif pada kualitas pengoptimalan seperti vektorisasi otomatis pada IA-32 atau software pipelining (SWP) pada IA-64. Optimalisasi antarprosedural dapat membantu menganalisis keberadaan persimpangan memori.
Optimasi dengan membuat profil: Termasuk tiga tahap. 1) pembuatan kode berinstrumen menggunakan opsi -Qprof_gen. 2) kode yang dihasilkan dijalankan pada data yang representatif, sementara informasi dikumpulkan tentang berbagai karakteristik eksekusi kode (misalnya, probabilitas transisi atau nilai tipikal untuk jumlah iterasi loop). 3) Kompilasi ulang dengan opsi -Qprof_use, yang memastikan bahwa kompiler menggunakan informasi yang dikumpulkan pada langkah sebelumnya. Dengan demikian, kompiler tidak hanya dapat menggunakan perkiraan statis dari karakteristik program yang penting, tetapi juga data yang diperoleh selama pelaksanaan program yang sebenarnya. Hal ini dapat membantu pemilihan optimasi tertentu selanjutnya (misalnya, pengaturan yang lebih efisien dari berbagai cabang program dalam memori, berdasarkan informasi tentang cabang mana yang dieksekusi pada frekuensi berapa; atau menerapkan optimasi ke loop berdasarkan informasi tentang nomor tipikal. iterasi di dalamnya). Optimalisasi dengan pembuatan profil sangat berguna dalam kasus di mana dimungkinkan untuk memilih kumpulan data yang kecil namun representatif (untuk langkah #2) yang menggambarkan dengan baik kasus paling umum dari penggunaan program di masa depan. Di beberapa bidang studi, memilih kumpulan perwakilan seperti itu sangatlah mungkin. Misalnya, optimasi profiling digunakan oleh pengembang DBMS.
Pengoptimalan yang tercantum di atas adalah tipe generik, yaitu. kode yang dihasilkan akan bekerja pada semua prosesor yang berbeda dalam keluarga (misalnya, dalam kasus arsitektur 32-bit - pada semua prosesor berikut: Intel Pentium-III, Pentium 4, termasuk inti Prescott, Intel Pentium M). Ada juga optimasi untuk prosesor tertentu.
Pengoptimalan khusus prosesor: -QxK (Pentium-III; penggunaan perintah SSE, fitur mikroarsitektur), -QxW dan -QxN (Pentium 4; penggunaan perintah SSE dan SSE2, fitur mikroarsitektur), -QxB (Pentium M; penggunaan perintah SSE dan SSE2, fitur mikroarsitektur ), QxP (Prescott; penggunaan perintah SSE, SSE2, dan SSE3, fitur mikroarsitektur). Dalam hal ini, kode yang dihasilkan menggunakan opsi tersebut mungkin tidak berfungsi pada perwakilan lain dari lini prosesor (misalnya, kode -QxW dapat mengakibatkan eksekusi perintah yang tidak valid jika dijalankan pada sistem berbasis prosesor Intel Pentium-III). Atau tidak bekerja dengan efisiensi maksimal (misalnya kode -QxB pada prosesor Pentium 4 karena perbedaan mikroarsitektur). Dengan opsi ini, dimungkinkan juga untuk menggunakan pustaka runtime yang dioptimalkan untuk prosesor tertentu menggunakan set instruksinya. Untuk mengontrol agar kode benar-benar dieksekusi pada prosesor target, mekanisme pengiriman (cpu-dispatch) diterapkan: memeriksa prosesor selama eksekusi program. Dalam situasi yang berbeda, mekanisme ini dapat diaktifkan atau tidak. Dispatch selalu digunakan jika variasi opsi -Qax(KWNP) digunakan. Dalam hal ini, dua versi kode dihasilkan: dioptimalkan untuk prosesor tertentu dan "umum" (generik), pilihan terjadi selama eksekusi program. Jadi, dengan meningkatkan ukuran kode, eksekusi program dapat dicapai pada semua prosesor di lini dan eksekusi optimal pada prosesor target. Pilihan lainnya adalah menggunakan pengoptimalan kode untuk perwakilan lini sebelumnya dan menggunakan kode ini pada prosesor ini dan prosesor selanjutnya. Misalnya, kode -QxN dapat dijalankan pada Pentium 4 dengan inti Northwood atau Prescott. Tidak ada peningkatan ukuran kode. Dengan pendekatan ini, Anda bisa mendapatkan performa yang baik, namun masih belum optimal pada sistem dengan prosesor Prescott (karena SSE3 tidak digunakan dan perbedaan mikroarsitektur tidak diperhitungkan) dengan performa optimal di Northwood. Opsi serupa juga tersedia untuk prosesor berarsitektur IA-64. Saat ini ada dua di antaranya: -G1 (Itanium) dan -G2 (Itanium 2; opsi default).
Grafik di bawah (Gambar 5) menunjukkan percepatan (berdasarkan satu - tidak adanya percepatan apa pun) dari penggunaan beberapa optimasi yang tercantum di atas (yaitu -O3 -Qipo -Qprof_use -Qx(N,P)) pada prosesor Prescott dibandingkan dengan pengaturan default (-O2). Menggunakan -QxP membantu dalam beberapa kasus untuk mendapatkan percepatan dibandingkan dengan -QxN. Percepatan terbesar dicapai dalam aplikasi 168.wupwise, yang telah disebutkan di bagian sebelumnya (karena optimalisasi intensif aritmatika kompleks menggunakan instruksi SSE3).
Gambar 5
Gambar 6 di bawah menunjukkan rasio (dalam waktu) kecepatan kode dengan pengaturan optimal dibandingkan dengan kode yang sepenuhnya tidak dioptimalkan (-Od) pada prosesor Pentium 4 dan Itanium 2. Terlihat bahwa Itanium 2 lebih bergantung pada kualitas optimasi. Hal ini terutama berlaku untuk penghitungan floating point (FP), yang rasionya kira-kira 36 kali. Perhitungan floating point adalah titik kuat arsitektur IA-64, tetapi pada saat yang sama Anda perlu mendekati penggunaan pengaturan kompiler yang paling efektif dengan hati-hati. Peningkatan produktivitas yang dihasilkan membayar biaya tenaga kerja untuk mencarinya.
Gambar 6. Speedup dengan Opsi Optimasi SPEC CPU200 Terbaik
Kompiler Intel mendukung spesifikasi industri OpenMP untuk membuat aplikasi multi-thread. Mode paralelisasi eksplisit (opsi -Qopenmp) dan otomatis (-Qparallel) didukung. Dalam mode eksplisit, pemrogram bertanggung jawab atas penggunaan alat standar OpenMP yang benar dan efisien. Dalam kasus paralelisasi otomatis, kompiler memiliki beban tambahan terkait dengan analisis kode program. Oleh karena itu, saat ini, paralelisasi otomatis hanya berfungsi efektif pada kode yang cukup sederhana.
Grafik pada Gambar 7 menunjukkan akselerasi dari penggunaan paralelisasi eksplisit pada sistem sampel praproduksi berbasis prosesor Intel Pentium 4 (Prescott) dengan dukungan teknologi Hyper-Threading: 2,8GHz, RAM 2GB, 8K L1-Cache, 512K L2 -Cache . Test suite yang digunakan adalah SPEC OMPM2001. Set ini ditujukan untuk sistem SMP kecil dan menengah, konsumsi memori hingga dua gigabyte. Aplikasi dikompilasi menggunakan Intel 8.0 C/C++ dan Fortran dengan dua rangkaian opsi: -Qopenmp -Qipo -O3 -QxN dan -Qopenmp -Qipo -O3 -QxP, yang masing-masing menjalankan aplikasi dengan teknologi Hyper-Threading diaktifkan dan dinonaktifkan. Nilai akselerasi pada grafik dinormalisasi ke kinerja versi single-threaded dengan teknologi Hyper-Threading dinonaktifkan.
Gambar 7: Aplikasi SPEC OMPM2001 pada Prosesor Prescott
Terlihat bahwa dalam 9 dari 11 kasus, penggunaan paralelisasi eksplisit menggunakan OpenMP memberikan peningkatan kinerja ketika teknologi Hyper-Threading diaktifkan. Salah satu aplikasi (312.swim) mengalami pelambatan. Ini adalah fakta yang diketahui: aplikasi ini ditandai dengan tingkat ketergantungan yang tinggi lebar pita Penyimpanan. Sama seperti SPEC CPU2000, aplikasi wupwise mendapat manfaat besar dari penerapan optimasi untuk Prescott (-QxP).
1.2 Mengoptimalkan program dengan melakukan perubahan pada teks sumber dan menggunakan diagnostik compiler
Di bagian sebelumnya, kita melihat pengaruh kompiler (dan pengaturannya) terhadap kecepatan eksekusi kode. Pada saat yang sama, kompiler Intel memberikan peluang yang lebih luas untuk pengoptimalan kode daripada sekadar mengubah pengaturan. Secara khusus, kompiler memungkinkan pemrogram untuk membuat "petunjuk" dalam kode program, yang memungkinkan pembuatan kode yang lebih efisien dalam hal kinerja. Di bawah ini adalah beberapa contoh untuk bahasa C/C++ (untuk bahasa Fortran ada tools serupa yang hanya berbeda pada sintaksisnya saja).
#pragma ivdep (di mana ivdep berarti abaikan ketergantungan vektor) digunakan sebelum perulangan program untuk memberi tahu kompiler bahwa tidak ada ketergantungan data di dalamnya. Petunjuk ini berfungsi ketika kompiler (berdasarkan analisis) secara konservatif berasumsi bahwa ketergantungan tersebut mungkin ada (jika kompiler, sebagai hasil analisis, dapat membuktikan bahwa ketergantungan tersebut ada, maka "petunjuk" tidak berpengaruh), sedangkan pembuat kode mengetahui bahwa ketergantungan seperti itu tidak dapat muncul. Dengan petunjuk ini, kompiler dapat menghasilkan kode yang lebih efisien: vektorisasi otomatis untuk IA-32 (menggunakan instruksi vektor dari set MMX\SSE\SSE2\SSE3 untuk loop program di C/C++ dan Fortran; Anda dapat mengenal teknik ini di lebih detailnya, misalnya pada berikutnya artikel di Jurnal Teknologi Intel), pipeline perangkat lunak (SWP) untuk IA-64.
#pragma vektor selalu digunakan agar kompiler mengubah keputusan tentang inefisiensi vektorisasi loop (otomatis untuk IA-32 dan SWP untuk IA-64), dibuat berdasarkan analisis karakteristik kuantitatif dan kualitatif pekerjaan di masing-masing pengulangan.
#pragma novector selalu memiliki efek kebalikan dari #pragma vector.
#pragma vector aligned digunakan untuk memberi tahu kompiler bahwa data yang digunakan dalam loop selaras dengan batas 16 byte. Hal ini memungkinkan Anda menghasilkan kode yang lebih efisien dan/atau ringkas (karena kurangnya pemeriksaan runtime).
#pragma vector unaligned memiliki efek kebalikan dari #pragma aligned. Sulit untuk membicarakan peningkatan kinerja dalam kasus ini, tetapi Anda dapat mengandalkan kode yang lebih ringkas.
#pragma titik distribusi digunakan di dalam perulangan program sehingga kompiler dapat membagi perulangan (distribusi perulangan) pada titik ini menjadi beberapa perulangan yang lebih kecil. Misalnya, "petunjuk" seperti itu dapat digunakan jika kompiler gagal memvektorisasi loop sumber secara otomatis (misalnya, karena ketergantungan data yang tidak dapat diabaikan bahkan dengan #pragma ivdep), sedangkan masing-masing (atau bagian) dari siklus yang baru terbentuk dapat divektorisasi secara efektif.
#pragma loop count (N), digunakan untuk memberi tahu kompiler bahwa nilai yang paling mungkin untuk jumlah iterasi loop adalah N. Informasi ini membantu menentukan optimasi yang paling efektif untuk loop ini (misalnya, apakah akan membuka gulungan, apakah untuk SWP atau vektorisasi otomatis, apakah perlu menggunakan perintah prefetch data software, ...)
"Petunjuk" _assume_aligned(p, base) digunakan untuk memberi tahu kompiler bahwa wilayah memori yang terkait dengan penunjuk p sejajar dengan batas base = 2^n byte.
Ini jauh dari daftar lengkap berbagai "petunjuk" kepada kompiler yang secara signifikan dapat mempengaruhi efisiensi kode yang dihasilkan. Anda mungkin bertanya-tanya bagaimana cara menentukan bahwa kompiler memerlukan petunjuk.
Pertama, Anda dapat menggunakan diagnostik kompiler dalam bentuk laporan yang diberikannya kepada pemrogram. Misalnya, menggunakan opsi -Qvec_reportN (dengan N berkisar dari 0 hingga 3 dan mewakili tingkat detail), Anda bisa mendapatkan laporan vektorisasi otomatis. Pemrogram akan memiliki akses ke informasi tentang loop mana yang telah di-vektorisasi dan mana yang belum. Dalam kasus negatif, kompiler menunjukkan dalam laporan alasan mengapa vektorisasi gagal. Mari kita asumsikan bahwa penyebabnya adalah hubungan yang diasumsikan secara konservatif dalam data. Dalam hal ini, jika programmer yakin tidak akan timbul ketergantungan, maka #pragma ivdep dapat digunakan. Kompiler menyediakan kemampuan serupa (dibandingkan dengan Qvec_reportN untuk IA-32) pada IA-64 untuk memantau keberadaan dan efektivitas SWP. Secara umum, kompiler Intel memberikan kemampuan ekstensif untuk mendiagnosis pengoptimalan.
Kedua, produk perangkat lunak lain (seperti profiler Intel VTune) dapat digunakan untuk menemukan hambatan kinerja dalam kode. Hasil analisis dapat membantu pemrogram melakukan perubahan yang diperlukan.
Anda juga dapat menggunakan daftar kode perakitan yang dihasilkan oleh kompiler untuk analisis.
Angka 8
Gambar 8 di atas menunjukkan proses langkah demi langkah dalam mengoptimalkan aplikasi menggunakan compiler (dan lainnya produk perangkat lunak) Intel dalam bahasa Fortran untuk arsitektur IA-64. Sebagai contoh, kami mempertimbangkan skema perkiraan regional non-adiabatik selama 48 jam dari Roshydrometcenter (Anda dapat membacanya, misalnya, di artikel ini. Artikel tersebut membahas tentang waktu perhitungan sekitar 25 menit, tetapi perubahan signifikan telah terjadi sejak saat itu. telah ditulis. Kinerja kode diambil sebagai titik referensi pada sistem Cray-YMP. Kode yang tidak dimodifikasi dengan opsi kompiler default (-O2) menunjukkan peningkatan kinerja sebesar 20% pada sistem empat prosesor berbasis Intel Itanium 2900 Prosesor MHz. Penerapan pengoptimalan yang lebih agresif (-O3) menghasilkan kecepatan ~2,5 kali lipat tanpa perubahan kode, terutama karena SWP dan pengambilan data sebelumnya. Analisis menggunakan diagnostik kompiler dan profiler Intel VTune mengungkapkan beberapa hambatan. Misalnya, kompiler tidak menggunakan perangkat lunak untuk menyalurkan beberapa loop yang sangat penting bagi kinerja, melaporkan dalam laporan bahwa hal itu menunjukkan ketergantungan data Perubahan kode kecil (arahan ivdep) membantu mencapai pemipaan yang efisien. Dengan menggunakan profiler VTune, kami dapat menemukan (dan laporan kompiler mengonfirmasi hal ini) bahwa kompiler tidak mengubah urutan loop bersarang (pertukaran loop) untuk penggunaan memori cache yang lebih efisien. Alasannya sekali lagi adalah asumsi konservatif mengenai ketergantungan data. Perubahan telah dilakukan pada kode sumber program. Hasilnya, kami berhasil mencapai akselerasi 4 kali lipat dibandingkan versi awal. Menggunakan paralelisasi eksplisit menggunakan arahan standar OpenMP, dan kemudian berpindah ke sistem dengan lebih banyak prosesor frekuensi tinggi memungkinkan kami mengurangi waktu penghitungan menjadi kurang dari 8 menit, yang memberikan kecepatan lebih dari 16 kali lipat dibandingkan versi awal.
Intel Visual Fortran
Intel Visual Fortran 8.0 menggunakan front-end (bagian kompiler yang bertanggung jawab untuk mengubah program dari teks dalam bahasa pemrograman menjadi representasi kompiler internal, yang sebagian besar tidak bergantung pada bahasa pemrograman atau mesin target) Teknologi dan komponen kompiler CVF kompiler Intel, yang bertanggung jawab atas serangkaian pengoptimalan dan pembuatan kode.
Gambar 9
Gambar 10
Gambar 9 dan 10 menunjukkan grafik perbandingan kinerja Intel Visual Fortran 8.0 dengan versi sebelumnya Intel Fortran 7.1 dan dengan kompiler populer industri lainnya dari bahasa ini yang berjalan di bawah OS Keluarga Windows dan Linux. Sebagai perbandingan, tes digunakan, teks sumber yang memenuhi standar F77 dan F90, tersedia di situs web http://www.polyhedron.com/. Di situs yang sama, informasi lebih rinci tersedia tentang membandingkan kinerja kompiler (Perbandingan Kompiler Win32 -> Fortran (77, 90) Tolok Ukur Waktu Eksekusi dan Perbandingan Kompiler Linux -> Fortran (77, 90) Tolok Ukur Waktu Eksekusi): lebih berbeda kompiler ditampilkan, dan mean geometrik diberikan dalam kombinasi dengan hasil individual dari setiap pengujian.
Pada majalah edisi sebelumnya, kami membahas produk dari keluarga Intel VTune Performance Analyzer - alat analisis kinerja yang sangat populer di kalangan pengembang aplikasi dan memungkinkan deteksi dalam kode aplikasi tim, yang menghabiskan terlalu banyak sumber daya CPU, memberikan kesempatan kepada pengembang untuk mengidentifikasi dan menghilangkan potensi kemacetan yang terkait dengan bagian kode tersebut, sehingga mempercepat proses pengembangan aplikasi. Namun perlu diperhatikan bahwa kinerja aplikasi sangat bergantung pada seberapa efisien kompiler yang digunakan untuk mengembangkannya, dan fitur perangkat keras apa yang mereka gunakan untuk menghasilkan kode mesin.
Versi terbaru kompiler Intel Intel C++ dan Intel Fortran untuk sistem operasi Windows dan Linux memungkinkan Anda memperoleh kinerja aplikasi hingga 40% untuk sistem yang berbasis prosesor Intel Itanium 2, Intel Xeon, dan Intel Pentium 4 dibandingkan dengan kompiler yang sudah ada dari prosesor lain produsen melalui penggunaan fitur-fitur prosesor ini, seperti teknologi Hyper-Threading.
Perbedaan yang terkait dengan optimasi kode oleh keluarga kompiler ini termasuk penggunaan tumpukan untuk melakukan operasi floating-point, optimasi antarprosedural (IPO), optimasi sesuai dengan profil aplikasi (Profile Guided Optimization (PGO), preloading data ke dalam cache ( Pengambilan data sebelumnya), yang menghindari latensi yang terkait dengan akses memori, dukungan untuk fitur karakteristik prosesor Intel (misalnya, ekstensi untuk pemrosesan data streaming Intel Streaming SIMD Extensions 2, karakteristik Intel Pentium 4), paralelisasi otomatis eksekusi kode, aplikasi penciptaan, berjalan pada beberapa jenis yang berbeda prosesor ketika mengoptimalkan salah satunya, alat untuk "memprediksi" kode berikutnya (prediksi cabang), memperluas dukungan untuk bekerja dengan thread eksekusi.
Perhatikan bahwa kompiler Intel digunakan di perusahaan terkenal seperti Alias/Wavefront, Oracle, Fujitsu Siemens, ABAQUS, Silicon Graphics, IBM. Menurut pengujian independen yang dilakukan oleh sejumlah perusahaan, kinerja kompiler Intel secara signifikan lebih tinggi dibandingkan kinerja kompiler dari produsen lain (lihat, misalnya, http://intel.com/software/products/compilers/techtopics/compiler_gnu_perf .pdf).
Di bawah ini kita akan melihat beberapa fitur versi terbaru Kompiler Intel untuk desktop dan server sistem operasi.
Kompiler untuk platform Microsoft Windows
Kompiler Intel C++ 7.1 untuk Windows
Intel C++ Compiler 7.1 adalah kompiler yang dirilis awal tahun ini yang memungkinkan Anda mencapainya tingkat tinggi optimasi kode untuk prosesor Intel Itanium, Intel Itanium 2, Intel Pentium 4 dan Intel Xeon, serta untuk prosesor Intel Pentium M menggunakan teknologi Intel Centrino dan dimaksudkan untuk digunakan pada perangkat seluler.
Kompiler yang ditentukan sepenuhnya kompatibel dengan Microsoft Visual C++ 6.0 dan Microsoft Visual Studio .NET: Dapat dibangun ke dalam lingkungan pengembangan yang sesuai.
Kompiler ini mendukung standar ANSI dan ISO C/C++.
Kompiler Intel Fortran 7.1 untuk Windows
Intel Fortran Compiler 7.1 untuk Windows, juga dirilis awal tahun ini, memungkinkan Anda membuat kode yang dioptimalkan untuk prosesor Intel Itanium, Intel Itanium 2, Intel Pentium 4 dan Intel Xeon, Intel Pentium M.
Kompiler ini sepenuhnya kompatibel dengan alat pengembangan Microsoft Visual C++ 6.0 dan Microsoft Visual Studio .NET, sehingga dapat dibangun ke dalam lingkungan pengembangan yang sesuai. Selain itu, kompiler ini memungkinkan Anda mengembangkan aplikasi 64-bit untuk sistem operasi yang berjalan pada prosesor Itanium/Itanium 2, dengan menggunakan Microsoft Visual Studio pada prosesor Pentium 32-bit menggunakan Intel Fortran Compiler 64-bit. Saat men-debug kode, kompiler ini memungkinkan Anda menggunakan debugger untuk platform Microsoft .NET.
Jika Anda menginstal Compaq Visual Fortran 6.6, Anda dapat menggunakannya sebagai pengganti Intel Fortran Compiler 7.1 asli, karena kompiler ini kompatibel pada tingkat kode sumber.
Intel Fortran Compiler 7.1 untuk Windows sepenuhnya kompatibel dengan standar ISO Fortran 95 dan mendukung pembuatan dan debugging aplikasi yang berisi kode dalam dua bahasa: C dan Fortran.
Kompiler untuk platform Linux
Kompiler Intel C++ 7.1 untuk Linux
Kompiler lain yang dirilis pada awal tahun, Intel C++ Compiler 7.1 untuk Linux, memungkinkan Anda mencapai optimalisasi kode tingkat tinggi untuk prosesor Intel Itanium, Intel Itanium 2, Intel Pentium 4, Intel Pentium M. Kompiler ini sepenuhnya kompatibel dengan kompiler GNU C pada kode sumber dan modul objek, yang memungkinkan aplikasi yang dibuat menggunakan GNU C untuk dimigrasi ke sana tanpa biaya tambahan.Intel C++ Compiler mendukung C++ ABI (tambahan pada kernel Linux yang memungkinkan kode yang dikompilasi untuk platform lain, seperti sistem operasi SCO awal, versi awal Sun Solaris, dll.), yang berarti kompatibilitas penuh dengan kompiler gcc 3.2 pada tingkat kode biner. Terakhir, dengan Intel C++ Compiler 7.1 untuk Linux, Anda bahkan dapat mengkompilasi ulang kernel Linux dengan membuat beberapa perubahan kecil pada kode sumbernya.
Kompiler Intel Fortran 7.1 untuk Linux
Intel Fortran Compiler 7.1 untuk Linux memungkinkan Anda membuat kode yang dioptimalkan untuk prosesor Intel Itanium, Intel Itanium 2, Intel Pentium 4, Intel Pentium M. Kompiler ini sepenuhnya kompatibel dengan kompiler Compaq Visual Fortran 6.6 pada tingkat kode sumber, memungkinkan Anda untuk mengkompilasi ulang aplikasi yang dibuat menggunakan Compaq Visual Fortran, sehingga meningkatkan kinerjanya.
Selain itu, kompiler yang ditentukan kompatibel dengan utilitas yang digunakan oleh pengembang seperti editor emacs, debugger gdb, dan utilitas pembuatan aplikasi make.
Seperti versi Windows dari kompiler ini, Intel Fortran Compiler 7.1 untuk Linux sepenuhnya kompatibel dengan standar ISO Fortran 95 dan mendukung pembuatan dan debugging aplikasi yang berisi kode dalam dua bahasa: C dan Fortran.
Perlu ditekankan secara khusus bahwa kontribusi signifikan terhadap pembuatan kompiler Intel yang terdaftar dibuat oleh para spesialis Pusat Rusia Pengembangan perangkat lunak Intel di Nizhny Novgorod. Informasi lebih lanjut tentang kompiler Intel dapat ditemukan di situs Web Intel di www.intel.com/software/products/.
Bagian kedua artikel ini akan dikhususkan untuk kompiler Intel yang membuat aplikasi untuk perangkat seluler.
Contoh peretasan nyata: Kompiler Intel C++ 7.0 - Arsip WASM.RU
...kompiler Intel C++ 7.0 diunduh pada larut malam, sekitar pukul lima pagi. Aku sangat ingin tidur, tapi aku juga diliputi rasa penasaran: apakah perlindungannya sudah diperkuat atau belum. Memutuskan bahwa sampai aku menemukan perlindungannya, aku masih belum bisa tertidur, aku membukanya konsol baru, dan menyetel ulang variabel sistem TEMP dan TMP ke direktori C:\TEMP, segera mengetikkan nama penginstal W_CC_P_7.0.073.exe yang panjangnya tidak senonoh ke dalam garis komando(kebutuhan untuk mengatur variabel TEMP dan TMP dijelaskan oleh fakta bahwa pada Windows 2000 variabel tersebut secara default menunjuk ke direktori yang sangat bersarang, dan penginstal Intel C++ - dan bukan hanya itu - tidak mendukung jalur dengan ukuran sebesar itu ).
Segera menjadi jelas bahwa kebijakan perlindungan telah direvisi secara radikal dan sekarang keberadaan lisensi sudah diperiksa pada tahap instalasi program (dalam versi 5.x instalasi dilakukan tanpa masalah). Oke, kita berikan perintah dir dan lihat isi dari apa yang sekarang harus kita lawan:
Isi folder C:\TMP\IntelC++Compiler70
17.03.2003 05:10
html 17.03.2003 05:11
x86 17.03.2003 05:11
Itanium 17.03.2003 05:11
catatan 06/05/2002 10:35 45 056 AutoRun.exe
07/10/2001 12:56 27 autorun.inf
29.10.2002 11:25 2 831 ccompindex.htm
24/10/2002 08:12 126 976 ChkLic.dll
18/10/2002 22:37 552 960 chklic.exe
17/10/2002 16:29 28 663 CLIcense.rtf
17.10.2002 16:35 386 kredit.txt
16.10.2002 17:02 34 136 Crellnotes.htm
19/03/2002 14:28 4 635 PLSuite.htm
21/02/2002 12:39 2 478 daftar.htm
02.10.2002 14:51 40 960 Setup.exe
02.10.2002 10:40 151 Pengaturan.ini
07/10/2001 12:56 184 pengaturan.mwg
19 file 2.519.238 byte
6 folder 886.571.008 byte gratis
Ya! Program instalasi setup.exe hanya membutuhkan empat puluh kilobyte. Sangat bagus! Kecil kemungkinan Anda dapat menyembunyikan perlindungan serius dalam volume sebesar itu, dan meskipun demikian, file kecil ini tidak ada gunanya untuk dianalisis secara keseluruhan - hingga byte terakhir dari daftar disassembler. Namun, bukan fakta bahwa kode keamanan terletak secara khusus di setup.exe; kode keamanan dapat ditempatkan di tempat lain, misalnya... ChkLic.dll/ChkLic.exe, yang jika digabungkan menempati kurang dari tujuh ratus kilobyte . Tunggu, apa itu ChkLic? Apakah ini kependekan dari Check License atau apa?! Hmm, orang-orang dari Intel jelas punya masalah serius dengan selera humornya. Akan lebih baik jika mereka menyebut file ini "Hack Me" dengan jujur! Oke, dilihat dari volumenya, ChkLic adalah FLEX lm yang sama, dan kita telah menemukannya (lihat "Intel C++ 5.0 Compiler") dan memiliki gambaran kasar tentang cara memecahkannya.
Kami memberikan perintah "dumpbin /EXPORTS ChkLic.dll" untuk memeriksa fungsi yang diekspor dan... berpegangan erat pada Klava agar tidak jatuh dari kursi:
Buang file ChkLic.dll
Bagian berisi ekspor berikut untuk ChkLic.dll
0 karakteristik
Stempel tanggal waktu 3DB438B4 Sen 21 Okt 21:26:12 2002
1 nomor fungsi
1 nomor nama
petunjuk ordinal nama RVA
1 0 000010A0 _PeriksaValidLicense
Brengsek! Perlindungan hanya mengekspor satu fungsi dengan nama bagus CheckValidLicense. “Hebat” - karena tujuan fungsi menjadi jelas dari namanya dan menjadi mungkin untuk menghindari analisis kode disassembler yang melelahkan. Yah, mereka sudah kehilangan minat... akan lebih baik jika mereka mengekspornya secara biasa atau semacamnya, atau setidaknya menamainya dengan nama yang mengintimidasi seperti DES Decrypt.
... melamun! Oke, mari kita kembali ke domba kita. Mari kita berpikir secara logis: jika seluruh kode keamanan terkonsentrasi langsung di ChkLic.dll (dan, dilihat dari sifat perlindungan "berengsel", memang demikian), maka semua "perlindungan" direduksi menjadi panggilan CheckValidLicense dari Setup. exe dan memeriksa hasil yang dikembalikan olehnya. Oleh karena itu, untuk "meretas" cukup dengan kehilangan ChkLic.dll, memaksa fungsi ChekValidLicense untuk selalu kembali... dan, omong-omong, apa yang harus dikembalikan? Lebih tepatnya: berapa sebenarnya nilai pengembalian yang sesuai dengan pemeriksaan lisensi yang berhasil? Tidak, jangan terburu-buru membongkar setup.exe untuk menentukannya, karena pilihan yang memungkinkan tidak banyak: FALSE atau TRUE. Apakah Anda bertaruh pada BENAR? Ya, dalam arti tertentu, ini logis, tetapi di sisi lain: mengapa kita sebenarnya memutuskan bahwa fungsi CheckValidLicense mengembalikan tanda keberhasilan operasi, dan bukan kode kesalahan? Lagi pula, ini entah bagaimana harus memotivasi alasan penolakan untuk menginstal kompiler: file dengan lisensi tidak ditemukan, file rusak, lisensi telah kedaluwarsa, dan sebagainya? Oke, mari kita coba kembalikan nol, dan jika tidak berhasil, kita kembalikan satu.
Oke, kencangkan sabuk pengaman, ayo berangkat! Kami meluncurkan HIEW, buka file ChkLic.dll (jika tidak terbuka, ingat akan menghubungkan tiga kali, salin sementara ke root atau direktori lain yang tidak mengandung karakter khusus dalam namanya yang tidak disukai hiew) . Kemudian, kembali ke tabel ekspor yang diperoleh dengan menggunakan dumpbin, kita menentukan alamat fungsi CheckValidLicense (dalam hal ini 010A0h) dan melalui "10A0" kita pergi ke awal. Sekarang, kita memotongnya menjadi "hidup", menimpanya kode lama “XOR EAX, EAX/RETN 4". Mengapa sebenarnya "REN 4" dan bukan hanya "RET"? Ya, karena fungsinya mendukung konvensi stdcall, yang dapat Anda ketahui dengan melihat epilognya di HIEW"e ( cukup gulir ke bawah layar disassembler sampai bertemu RET).
Mari kita periksa... Berhasil!!! Meskipun tidak memiliki lisensi, penginstal memulai penginstalan tanpa mengajukan pertanyaan apa pun! Oleh karena itu, pertahanannya jatuh. Oh, kami tidak percaya semuanya begitu sederhana dan, agar tidak duduk bodoh menatap monitor menunggu proses instalasi program selesai, kami menggunakan disassembler IDA favorit kami di setup.exe. Hal pertama yang menarik perhatian Anda adalah tidak adanya CheckValidLicense dalam daftar fungsi yang diimpor. Mungkin itu meluncurkan file ChkLic.exe? Kami mencoba menemukan tautan yang sesuai di antara baris yang dikenali secara otomatis: “~View aNames”, “ChkLic”... ya, baris “Chklic.exe” tidak ada sama sekali, tetapi “Chklic.dll” terdeteksi. Ya, begitu, itu berarti perpustakaan ChkLic dimuat dengan tautan eksplisit melalui LoadLibrary. Dan mengikuti referensi silang menegaskan hal ini:
Teks: 0040175D dorong offset aChklic_dll ; lpLibFileName
Teks:00401762 panggilan ds:LoadLibraryA
Teks:00401762 ; memuat ChkLic.dll ^^^^^^^^^^^^^^^^
Teks:00401762 ;
Teks:00401768 mov esi, eax
Teks:0040176A dorong offset a_checkvalidlic ; lpProcName
Teks: 0040176F tekan esi; hModul
Teks:00401770 hubungi ds:GetProcAddress
Teks:00401770 ; dapatkan alamat fungsi CheckValidLicense
Teks:00401770 ;
Teks: 00401776 cmp esi, ebx
Teks:00401778 jz loc_40192E
Teks:00401778 ; jika tidak ada perpustakaan seperti itu, keluar dari program instalasi
Teks:00401778 ;
Teks:0040177E cmp eax, ebx
Teks:00401780 jz loc_40192E
Teks:00401780 ; jika tidak ada fungsi seperti itu di perpustakaan, keluar dari instalasi
Teks:00401780 ;
Teks: 00401786 tekan ebx
Teks: 00401787 telepon eax
Teks:00401787 ; panggil fungsi ChekValidLicense
Teks:00401787 ;
Teks: 00401789 tes eax, eax
Teks:0040178B jnz loc_4019A3
Teks:0040178 ; jika fungsi yang dikembalikan bukan nol, keluar dari program instalasi
Hebatnya, pertahanan yang sangat primitif ini dibangun persis seperti ini! Selain itu, file setengah meter ChkLic.exe tidak diperlukan sama sekali! Dan mengapa perlu menyeretnya dari Internet? Omong-omong, jika Anda memutuskan untuk menyimpan distribusi kompiler (perhatian: Saya tidak mengatakan "distribusikan"!), maka untuk menghemat ruang disk, ChkLic.* dapat dihapus: baik dengan menghapus setup.exe, selamanya menyapihnya dari mengaksesnya, atau cukup dengan membuat ChkLic.dll Anda sendiri, mengekspor fungsi stdcall CheckValidLicence dalam bentuk: int CheckValidLicence(int some_flag) ( return 0;)
Nah, saat kita mendiskusikan semua ini, penginstal selesai menginstal kompiler dan berhasil menyelesaikan pekerjaannya. Apakah menarik apakah kompiler akan mulai atau semua kesenangan baru saja dimulai? Kami buru-buru turun ke hierarki subfolder yang bercabang, temukan icl.exe, yang, seperti yang diharapkan, terletak di direktori bin, klik dan... Kompiler secara alami tidak memulai, dengan alasan bahwa "icl: error: tidak dapat memeriksa lisensi FLEX lm", yang tanpanya dia tidak dapat melanjutkan pekerjaannya.
Ternyata Intel menggunakan perlindungan multi-level dan tingkat pertama ternyata merupakan perlindungan kasar terhadap orang bodoh. Dengan baik! Kami menerima tantangan ini dan, berdasarkan pengalaman kami sebelumnya, secara otomatis mencari file LMGR*.DLL di direktori compiler. Tidak berguna! Kali ini tidak ada file seperti itu di sini, tetapi ternyata icl.exe bertambah berat, melebihi angka enam ratus kilobyte... Berhenti! Bukankah pengembang kompiler menghubungkan FLEX lm yang sama dengan tautan statis? Mari kita lihat: di Intel C++ 5.0, jumlah ukuran lmgr327.dll dan icl.exe adalah 598 KB, dan sekarang icl.exe sendiri menempati 684 KB. Dengan mempertimbangkan penyesuaian terhadap “obesitas pikun” alami, angka-angka tersebut sangat sesuai. Jadi, FLEX lm! Oh oh! Tapi sekarang, tanpa nama fungsi simbolis, akan jauh lebih sulit untuk menghancurkan perlindungannya... Namun, jangan panik terlebih dahulu! Mari kita berpikir, dengan tenang! Kecil kemungkinannya tim pengembangan akan sepenuhnya menulis ulang semua kode yang berinteraksi dengan perlindungan “amplop” ini. Kemungkinan besar, “perbaikannya” berakhir hanya dengan perubahan jenis tata letak. Dan jika demikian, maka kemungkinan meretas program tersebut masih besar!
Mengingat terakhir kali kode keamanan masuk fungsi utama, setelah menentukan alamatnya, kami cukup menetapkan breakpoint dan, menunggu debugger muncul, kami dengan bodohnya melacak kodenya, secara bergantian melihat debugger dan kemudian ke jendela keluaran program: apakah ada pesan kasar yang muncul di sana? Pada saat yang sama, kami menandai semua transisi bersyarat yang kami temui pada selembar kertas terpisah (atau menyimpannya dalam memori kami sendiri, jika Anda mau), jangan lupa untuk menunjukkan apakah setiap transisi bersyarat telah dilakukan atau tidak... Berhenti! Anda dan saya sedang mengobrol tentang sesuatu, tetapi pesan kasar telah muncul! Baiklah! Mari kita lihat transisi bersyarat apa yang berhubungan dengannya. Catatan kami menunjukkan bahwa lompatan terakhir yang ditemui adalah lompatan bersyarat JNZ, terletak di alamat 0401075h dan "bereaksi" terhadap hasil yang dikembalikan oleh sub_404C0E:
Teks:0040107F loc_40107F: ; KODE XREF: _main+75^j
Teks:0040107F mov eax, offset aFfrps ; "FFrps"
Teks:00401084 mov edx, 21 jam
Teks:00401089 hubungi sub_404C0E
Teks: tes 0040108E eax, eax
Teks:00401090 jnz short loc_40109A
Jelas sekali, sub_404C0E adalah prosedur yang sangat protektif yang memeriksa keberadaan lisensi. Bagaimana cara menipunya? Ya, ada banyak pilihan... Pertama, Anda dapat menganalisis konten sub_404C0E dengan cermat dan cermat untuk mengetahui apa sebenarnya yang diperiksa dan bagaimana sebenarnya pemeriksaannya. Kedua, Anda cukup mengganti JNZ short loc_40107F dengan JZ short loc_40107F atau bahkan NOP, NOP. Ketiga, perintah pengecekan hasil kembali TEST EAX, EAX dapat diubah menjadi perintah nol: XOR EAX, EAX. Keempat, Anda dapat menghilangkan sub_404C0E sendiri sehingga selalu mengembalikan nol. Saya tidak tahu tentang Anda, tapi saya paling menyukai metode nomor tiga. Kami mengubah dua byte dan meluncurkan kompiler. Jika tidak ada pemeriksaan lain atas “lisensi” dalam perlindungan, maka program akan berfungsi dan, karenanya, sebaliknya. (Seperti yang kita ingat, di versi kelima ada dua pemeriksaan seperti itu). Hebatnya, kompiler tidak lagi mengeluh dan berfungsi!!! Memang, seperti yang diharapkan, pengembangnya tidak memperkuat perlindungan sama sekali, tetapi sebaliknya, malah melemahkannya! Chris Kaspersky
Memuat...