![]() When running in parallel, GDI+ is only a few seconds behind for 1,000 images. In my testing, LibJpeg-Turbo and JPEGLib V9b are tied, especially for my typical scenario JPEGLib V9b may have a tiny edge. Looking at the numbers, you can also see the choice of JPEG library makes little difference in the overall runtime. ![]() Using parallelism potentially cut the application runtime by more than half. The application happily maxed out all 8 cores on my system when running parallel. This does add a dependency on vcomp120.dll. Process the list of filenames in a loop, along with the #pragma omp parallel for.When iterating the file tree, gather the filenames into a list rather than process immediately.The support for OpenMP is pretty straightforward to apply. ParallelismĪs the application is CPU-bound, the next step was to use parallelism. Having to introduce Managed C++ destroyed performance, so WPF fell by the wayside very quickly. To use WPF, I chose to toggle on /clr and build essentially a Managed C++ application. WPF : WPF is essentially a Managed wrapper around WIC. My implementation was not parallel friendly, so could not gather those numbers. WIC : The "new" way of loading images on Windows. Has the benefit of handling more than just JPEG. Comparatively simple to use, caveat being some extra work required to deal with the Microsoft-specific pixel buffer layout. GDI+ : The "old" way of loading images on Windows. LibJPEG-Turbo : The independently optimized version of LibJPEG. LibJPEG 9 : The latest release of the LibJPEG library. It is relatively simple to swap in LibJPEG 9 and LibJPEG-Turbo instead. LibJPEG 6 : CImg came with the LibJPEG 6 library, so this was tested as the "baseline". Parallel: Using OpenMP to load/process files on separate threads.Network: Loading the files from a remote HD.Local: Loading the files from a local SSD.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |