Saat ini, ketika jaringan saraf membajak hamparan Big Data, dan kecerdasan buatan sedang mempertimbangkan apakah menguntungkan baginya untuk mendapatkan bayaran untuk pekerjaannya di Bitcoin, tugas yang saya dapatkan untuk menemukan perpustakaan lintas platform terbuka tercepat untuk mengunduh, menyimpan, dan mentranskode file grafik tampak seperti anakronisme nyata . Namun pada kenyataannya, tugas ini lebih relevan dari sebelumnya - untuk semua teknologi visi komputer dan pembelajaran mesin, gigabyte gambar harus diunduh, dan kadang-kadang data perantara harus disimpan sebagai gambar. Jadi untuk melakukan ini dengan cara tercepat sangat diinginkan. Pada artikel ini kita akan menemukan perpustakaan yang kita cari, dan, yang paling penting, kita akan berurusan dengan produk yang sangat berguna yang sangat menyederhanakan tugas serupa dan banyak lainnya - Google Benchmark.
Jadi, pernyataan yang tepat dari masalah menyatakan: dalam aplikasi, file jpeg dan tiff dengan kedalaman warna 24 dan 8 bit, serta bmp 32-bit dimuat ke dalam memori. Ukuran gambar berkisar dari kecil (32x32 piksel) hingga besar, dengan resolusi 15K. Dalam prosesnya, file dimodifikasi, setelah itu mereka harus disimpan ke disk dalam format yang ditentukan. Dan ini harus dilakukan oleh pustaka sumber terbuka lintas-platform yang memiliki kinerja maksimum pada prosesor Intel modern dengan dukungan untuk instruksi vektor AVX2. Perpustakaan juga mendukung perpustakaan format tekstur terkompresi DirectX DXT1.
Komponen Pencitraan Windows diambil sebagai tolok ukur untuk kinerja - kerangka kerja standar untuk bekerja dengan gambar pada Windows, yaitu, Anda perlu menemukan perpustakaan yang bekerja dengan pijakan yang sama atau lebih cepat dari WIC.
Tetapi persyaratan yang paling penting adalah bahwa solusi diperlukan saat ini, tetapi lebih baik kemarin.
Temui perpustakaan untuk bekerja dengan bmp, tiff, jpeg
Solusinya dimulai dengan langkah yang jelas dan tidak rumit, meskipun bukan langkah yang sangat cepat - studi menyeluruh tentang
Wikileaks github ,
stackoverflow dan google lainnya untuk mencari kandidat yang cocok untuk peran perpustakaan yang diinginkan. Ada beberapa di antaranya:
- FreeImage . Cangkang di atas perpustakaan terkenal LibJPEG, LibPNG, LibTIFF. Dukungan DXT1 hadir melalui plugin. Kerugiannya adalah bahwa kualitas penghematan jpeg di API diatur terlalu rahasia - 100, 75,50 dan 25%. Untuk mengubah parameter ini, Anda harus memahami dan mengedit kode. Proyek ini hidup dan berkembang - versi terbaru 3.18.0 dirilis pada 31 Juli 2018. Perakitan di bawah Windows sepele, semua komponen dibangun secara otomatis.
- Cimg Merupakan file bungkus header C ++ di atas paket ImageMagick
artefak kuno. Paket ini membutuhkan instalasi build terpisah, juga memungkinkan untuk menggunakannya secara langsung, melewati Cimg. Ini memiliki banyak kemungkinan untuk bekerja dengan gambar: filter, transformasi, definisi morfologi, dll. Mendukung HDR, tidak mendukung DXT1. - DevIL ( Perpustakaan Gambar Pengembang ). Pustaka C gaya OpenGL yang sangat sederhana. Ini berisi shell lebih dari LibJPEG, LibPNG, LibTIFF, tetapi juga memiliki fungsi built-in yang luas, juga mendukung banyak format gambar, termasuk DXT1. Untuk perakitan menggunakan CMake. Sebagian besar dependensi, termasuk LibJPEG, LibPNG, LibTIFF, tidak termasuk dalam DevIL dan harus diunduh dan dikompilasi secara terpisah. Pembaruan DevIL terbaru mengenai sistem pembangunan bertanggal 01/01/2017, dan yang sebelumnya umumnya terjadi pada tahun 2014, jadi jika ada masalah dengan perpustakaan, mungkin ada masalah dengan solusi mereka.
- OpenImageIO . Ini diposisikan sebagai alat pengembang untuk perangkat lunak profesional untuk bekerja dengan gambar. Ini mendukung dalam bentuk pekerjaan plug-in dengan banyak format foto eksotis dan bahkan video. Build for Windows memerlukan Boost yang sudah dikompilasi dan Qt 4. Tidak ada versi rakitan yang siap pakai untuk pengujian.
- Tingkatkan GIL (Pustaka Gambar Umum) Tingkatkan dan itu saja. Meskipun tidak semuanya. Perpustakaan ini juga berisi pembungkus lebih dari LibJPEG, LibPNG, dan LibTIFF.
- SDL_image 2.0 Digunakan bersama-sama dengan perpustakaan SDL dan, Anda akan tertawa, tetapi juga berisi shell di atas LibJPEG, LibPNG dan LibTIFF.
Semua pustaka yang ditemukan dikompilasi di bawah Windows menggunakan tingkat optimalisasi tertinggi dari kompiler Visual Studio dan / arch: AVX2 switch.
Hal yang sama berlaku untuk perpustakaan LibJPEG, LibPNG dan LibTIFF, untuk mempercepat pekerjaan yang diambil dari paket
perpustakaan OpenCV baru.
Temui Google Benchmark
Langkah solusi berikutnya juga jelas - menciptakan tolok ukur untuk membandingkan kinerja perpustakaan yang ditemukan, dan penggunaan perpustakaan microbenchmarking Google Benchmark, yang dikenal luas di kalangan sempit, membuatnya sederhana dan cepat.
Benchmark Google dapat secara akurat mengukur kinerja potongan-potongan kode yang Anda masukkan ke dalam tubuh siklus C ++ 11.
static void BM_foo1(benchmark::State& state) {
dalam fungsi yang terdaftar sebagai patokan
Dan jalankan mereka:
BENCHMARK_MAIN();
Kemudian terbitkan laporan dalam format yang ditentukan - keluaran konsol, json, csv.
Laporan tersebut akan berisi data tentang sistem eksekusi (prosesor, konfigurasi cache), total waktu operasi global dari masing-masing fungsi yang diukur, serta waktu mereka mengambil prosesor. Waktu-waktu ini umumnya berbeda - yang pertama, misalnya, termasuk penundaan baca / tulis, dan yang kedua untuk tolok ukur multi-utas adalah jumlah dari waktu operasi semua inti.
Parameter terakhir yang ditampilkan oleh tolok ukur Google adalah jumlah iterasi yang dilakukan untuk fungsi tersebut, yang diperlukan untuk pengukuran akurat akurat waktu operasinya. Sistem memilihnya sendiri, secara otomatis, melakukan pengukuran awal.
Apa itu "pengukuran akurat" runtime? Anda dapat menulis disertasi tentang topik ini, tetapi dalam hal ini cukup untuk mengatakan bahwa:
- Secara default, pengukuran ada di kluster prosesor, yaitu, urutan akurasi teoretis persis seperti ini. Output default dalam nanodetik;
- hasil dalam semua tes yang saya lihat sangat stabil dari peluncuran ke peluncuran;
- menurut data intelijen saya, tolok ukur Google digunakan dan sepenuhnya tepercaya oleh hasilnya oleh pengembang perangkat lunak komputer terpasang dari salah satu perhatian mobil terbesar di dunia. Jadi kita akan percaya.
Satu-satunya hal yang patut diperhatikan: benchmark Google tidak menyediakan "pembersihan" cache antara awal iterasi benchmark. Jika perlu, Anda harus mengurusnya sendiri.
Tetapi tolok ukur Google dapat melakukan banyak hal lain:
- menghitung kompleksitas algoritma asimtotik (O);
- bekerja dengan benar dengan tolok ukur multi-utas, mengukur durasinya tidak dalam kutu prosesor, tetapi dalam mode "waktu nyata" (jam dinding);
- gunakan fungsi Anda sendiri pengukuran waktu "manual", yang mungkin berguna, misalnya, ketika mengukur pekerjaan pada GPU;
- secara otomatis menetapkan tolok ukur dengan serangkaian argumen berbeda untuk badan tertentu dari fungsi yang diukur;
- menunjukkan nilai rata-rata, median, dan standar deviasi untuk beberapa permulaan patokan;
- Tetapkan penghitung dan tag Anda sendiri yang akan tercermin dalam laporan tolok ukur Google.
Patokan Google diunduh dari
repositori github , dirakit untuk platform yang sesuai menggunakan Cmake (perakitan Visual Studio tersedia untuk Windows), pustaka yang dihasilkan akan ditautkan ke proyek Anda (dalam kasus Windows, tautan dengan pustaka shlwapi juga akan diperlukan), file header benchmark akan ditambahkan ke kode Anda .h, setelah itu semuanya berfungsi seperti dijelaskan di atas.
Jika tidak berhasil, maka satu-satunya tempat, selain situs yang
sudah ditunjukkan , di mana Anda bisa mendapatkan setidaknya beberapa informasi dan bantuan tentang tolok ukur Google adalah
forum produk khusus .
Dalam kasus kami, semuanya bekerja tanpa masalah. Setelah berkomunikasi dengan pelanggan, 4 tolok ukur ditentukan, yang memuat dan menyimpan dengan nama yang berbeda:
- File jpeg 8-bit dengan resolusi 15k
- File jpeg 24-bit dengan resolusi 15k
- File tiff 24-bit dengan resolusi 15k
- File bmp 32-bit dengan resolusi 32x32
Temui hasilnya
Pada awalnya direncanakan bahwa semua perpustakaan yang ditemukan, yaitu, FreeImage, Cimg, DevIL, OpenImageIO, BoIL GIL dan SDL_image 2.0, akan mengambil bagian dalam pengujian-perbandingan dengan Windows Imaging Component (WIC). Tetapi tiga perpustakaan terakhir, tergantung pada "monster" seperti Boost dan SDL, diminta oleh pelanggan untuk pergi dengan cadangan jika terjadi keadaan darurat, jika perpustakaan yang diinginkan tidak ditemukan di antara tiga perpustakaan pertama. Dan, untungnya, dia ditemukan. Meski tidak segera.
Berikut ini adalah laporan yang dihasilkan oleh tolok ukur Google, yang menunjukkan bahwa:
- FreeImage sepenuhnya dengan skor menghancurkan kehilangan WIC di semua tes, sehingga tidak bisa lagi dipertimbangkan.
- Cimg kehilangan WIC dengan bersih di mana-mana kecuali untuk memuat tiff, di mana ia sedikit (kurang dari 5%) lebih cepat. Sayangnya, ia juga harus dihapus. Selain itu, ini berlaku untuk penggunaan langsung paket ImageMagick.
Tetap menggunakan perpustakaan DevIL. Ini menunjukkan hasil yang sangat baik dalam kasus memuat bmp dan tiff (3 dan 2,8 kali lebih tinggi dari WIC!), Hitam dan putih jpeg (1,75x lebih baik dari WIC), tetapi sedikit melambat saat memuat jpeg 24-bit biasa - ia melakukannya dengan 3 % lebih lambat dari WIC.
08/15/18 11:15:44
Running c:\WIC\WIC_test\Release\WIC_test.exe
Run on (8 X 4008 MHz CPU s)
CPU Caches:
L1 Data 32K (x4)
L1 Instruction 32K (x4)
L2 Unified 262K (x4)
L3 Unified 8388K (x1) |
Benchmark | Time | CPU | Iterations |
BM_WIC8jpeg | 72 ms | 70 ms | 11 |
BM_cimg8jpeg | 562 ms | 52 ms | 10 |
BM_FreeImage8jpeg | 147 ms | 144 ms | 5 |
BM_devIL8jpeg | 41 ms | 41 ms | 17 |
|
BM_WIC24jpeg | 266 ms | 260 ms | 3 |
BM_cimg24jpeg | 656 ms | 128 ms | 6 |
BM_FreeImage24jpeg | 594 ms | 594 ms | 1 |
BM_devIL24jpeg | 276 ms | 276 ms | 3 |
|
BM_WIC24tiff | 844 ms | 844 ms | 1 |
BM_cimg24tiff | 808 ms | 131 ms | 5 |
BM_FreeImage24tiff | 953 ms | 938 ms | 1 |
BM_devIL24tiff | 305 ms | 305 ms | 2 |
|
BM_WIC32 | 3 ms | 3 ms | 236 |
BM_cimg32 | 71 ms | 7 ms | 90 |
BM_FreeImage32 | 6 ms | 5 ms | 112 |
BM_devIL32 | 1 ms | 1 ms | 747 |
Tentu saja, DevIL juga dapat ditolak pada tahap ini, tetapi di sini perpustakaan lain muncul dalam bingkai -
Libjpeg-turbo .
Keluarannya dapat dengan mudah dipenuhi dengan tepuk tangan -
Libjpeg-turbo adalah pustaka lintas platform yang sepenuhnya mengimplementasikan fungsionalitas libjpeg (API) dan menambahkan fungsionalitasnya sendiri (misalnya, bekerja dengan buffer 32-bit). Pada saat yang sama, untuk arsitektur x86 Libjpeg-turbo aktif menggunakan instruksi vektor (SSE2, AVX2) dan, menurut penciptanya, adalah 2-6 kali lebih cepat daripada libjpeg (!)
Karena itu, langkah selanjutnya adalah membangun Iblis dengan Libjpeg-turbo bukan libjpeg. Libjpeg-turbo dengan bantuan CMake membangun Visual Studio tanpa masalah, dan kemudian segera (dengan penggantian hanya #define, yang menentukan versi libjpeg dalam file header DevIL) mulai berfungsi sebagai bagian dari DevIL.
Akibatnya, laporan tolok ukur Google terlihat seperti ini:
Benchmark | Time | CPU | Iterations |
BM_WIC8jpeg | 72 ms | 68 ms | 9 |
BM_cimg8jpeg | 565 ms | 39 ms | 10 |
BM_FreeImage8jpeg | 148 ms | 141 ms | 5 |
BM_devIL8jpeg | 31 ms | 31 ms | 24 |
|
BM_WIC24jpeg | 269 ms | 266 ms | 2 |
BM_cimg24jpeg | 675 ms | 131 ms | 5 |
BM_FreeImage24jpeg | 604 ms | 594 ms | 1 |
BM_devIL24jpeg | 149 ms | 150 ms | 5 |
|
BM_WIC24tiff | 833 ms | 828 ms | 1 |
BM_cimg24tiff | 785 ms | 138 ms | 5 |
BM_FreeImage24tiff | 943 ms | 938 ms | 1 |
BM_devIL24tiff | 318 ms | 320 ms | 2 |
|
BM_WIC32 | 4 ms | 3 ms | 236 |
BM_cimg32 | 74 ms | 8 ms | 56 |
BM_FreeImage32 | 6 ms | 5 ms | 100 |
BM_devIL32 | 1 ms | 1 ms | 747 |
Tentu saja, peningkatan kinerja dengan jpeg bahkan tidak dua kali lipat dibandingkan dengan libjpeg, tetapi harus begitu - karena kecepatan superioritas hanya berlaku untuk pengkodean / decoding jpeg, dan tes ini mencakup overhead membaca / menulis file.
Tetapi dapat dilihat bahwa rata-rata DevIL lebih cepat daripada WIC dalam kasus 8-bit jpeg
2,3 kali, 24-bit jpeg
1,8 kali, tiff 24-bit -
2,7 kali, 32-bit bmp -
3,5 kali.
Masalahnya terpecahkan. Tiga hari kerja sebelum liburan musim panas dihabiskan sepenuhnya untuk keputusan tersebut. Tentu saja, jika ada sedikit lebih banyak, akan ada kemungkinan bahwa akan ada perpustakaan dengan hasil yang lebih mengesankan, dan jika jauh lebih banyak, maka mungkin saya akan menulis perpustakaan yang saya cari sendiri.
Tetapi bahkan apa yang mengesankan. Karena itu, jika Anda mencari pustaka lintas platform untuk bekerja dengan file grafik yang cepat dan mudah dalam segala hal, maka perhatikan
DevIL , dan jika Anda perlu dengan cepat dan akurat melakukan pengukuran komparatif dari kode, maka
tolok ukur Google siap melayani Anda.