![Lead Image © Ying Feng Johansson, 123RF.com Lead Image © Ying Feng Johansson, 123RF.com](/var/ezflow_site/storage/images/archive/2015/29/improved-performance-with-parallel-i-o/po-23144-123rf-ying_feng_johansson_123rf-abbiegespuren_resized.png/116771-1-eng-US/PO-23144-123RF-Ying_Feng_Johansson_123RF-Abbiegespuren_resized.png_medium.png)
Lead Image © Ying Feng Johansson, 123RF.com
Improved Performance with Parallel I/O
Paths
Lately I've been looking at application timing to find bottlenecks or time-consuming portions of code. I've also been reading articles about improving applications by parallelization. Once again, this has led me to examine application I/O and, in particular, the fact that many applications handle I/O serially – even parallel applications – which can result in an I/O performance bottleneck.
I/O in serial applications is simple: one thread or process does it all. It doesn't have to read data and then pass it along to another process or thread. It doesn't collect data from other processes and threads and perform the I/O on their behalf. One thread. One I/O stream.
To improve application performance or to tackle larger problems, people have turned to parallelism. This means taking parts of the algorithm that can be run at the same time and doing so. Some of these code portions might have to handle I/O, which is where things can get complicated.
What it comes down to is coordinating the I/O from various threads/processes (TPs) to the filesystem. Coordination can include writing data to the appropriate location in the file or files from the various TPs so that the data files are useful and not corrupt. POSIX filesystems don't have mechanisms to help multiple TPs write to the filesystem; therefore, it is up to the application developer to code the logic for I/O with multiple TPs.
I/O from a single TP is straightforward and represents coding in everyday applications. Figure 1 shows one TP handling I/O for a single file. Here, you don't have to worry about coordinating I/O from multiple TPs because there is only one. However, if you want to run applications faster and for larger problems, which usually involves more than one TP, I/O can easily become a bottleneck. Think of Amdahl's Law [1].
...Buy this article as PDF
(incl. VAT)