- Introduction
- Caches
- Virtual Memory Issues
- Memory
- Input/Output Devices
- I/O Performance Tips for Application Writers
- Summary
- References
This chapter is from the book
This chapter is from the book
This chapter is from the book
3.6 I/O Performance Tips for Application Writers
3.6.1 The I/O Routines You Use Will Make a Difference
Let’s start this section with a simple question—do you travel to the supermarket and purchase two slices of bread each time you make a sandwich? Well, we certainly hope not. You probably buy a loaf of bread at a time and take two slices of bread from it each time you make a sandwich. The time and economics involved in travelling to the supermarket for individual items are not practical.
In an effort to duplicate this efficiency of getting several things with each trip to the more remote storage devices, buffered I/O mechanisms were developed. The most common is that found in the C programming language with the fread() and fwrite() subroutines.
This mechanism, described as buffered binary I/O to a stream file, works roughly as follows. A file is opened with the fopen() subroutine call instead of the open() system call. In the process of opening this file, fopen() also initializes data structures to maintain a buffer, allocated in the user’s address space (as opposed to the kernel’s address space). This buffer varies in size and the user can actually manipulate how this buffer is allocated and what its size will be. Subsequent to the fopen() call, transfers to and from the file are accomplished with calls to the subroutines fwrite() and fread(), respectively. These subroutines first check to see if the data being requested is already in the buffer. If it is, then the data is simply copied from the buffer into the destination specified by the procedure call. Thus, no system call is made and no transfer of data is made to or from the kernel’s address space (i.e., buffer cache). If the data is not already in the buffer, then the subroutines make the necessary system call to move blocks of data into and out of the buffer from the file.
Some implementations of these buffered binary I/O routines use relatively small buffers. As a result, these routines can be slower than system calls for large transfers. One way to improve this situation is to make use of the setvbuf() routine. This routine allows the user to specify another buffer that can be much larger in size. For example, to change the internal buffer used by buffered I/O, one might use the following C code:
work_buffer = (char *)malloc(65536);
fp = fopen( workfile, "r+" );
if( fp == NULL ) { perror("fopen"); exit(-1); }
setvbuf( fp, work_buffer, _IOFBF, (size_t)65536 );
This sequence assigns the 64 KB array work_buffer to the file pointer fp to be used for its buffering. The performance benefit of doing this will be shown below.
Using language-specific I/O routines such as the Fortran I/O statements (e.g., open(), read(), write(), etc.) can be extremely detrimental to performance. Implementations vary, but in many cases these routines are built on top of the buffered binary I/O mechanisms (fopen(), fread(), fwrite(), etc.) discussed above. Fortran provides for some additional functionality in these I/O routines, which leads to yet more overhead for doing the actual I/O transfers. Fortran read performance is typically worse than either using the system call interface or the buffered binary I/O mechanisms.
To illustrate this, a comparison of reading a file using the read() system call, fread(), fread() with a 64 KB transfer size, and Fortran I/O was made on a HP N-4000 server using HP-UX 11.0 operating system. The Fortran I/O was performed with an implied DO loop using the following calls:
OPEN( FILDES, FORM='UNFORMATTED', FILE='./tmp/temp.test' ); ... READ( FILDES ) ( BUFFER(J),J=1,BUFFER_SIZE );
Note that the default buffer size for HP-UX’s buffered binary I/O is eight KB. The time to make transfers of various sizes is given in Table 3-5. The times shown are the milliseconds per transfer for using various I/O interfaces. A 100 MB file was read sequentially starting from the beginning of the file to produce these times. The file system buffer cache was configured to be roughly 500 MB in size so that the file would fit entirely in the buffer cache. So, the times reflect transfers from the buffer cache and not from magnetic disk.
Table 3-5. Average Time, in Microseconds, to Read Data From Files Using Three Common Interfaces as a Function of Transfer Size.
|
Transfer Size (bytes) |
read system call |
fread |
Fortran unformatted read |
|---|---|---|---|
|
8 |
5.76 |
0.27 |
2.87 |
|
64 |
6.47 |
0.43 |
3.09 |
|
1 K |
9.09 |
3.13 |
5.41 |
|
8 K |
20.11 |
23.48 |
30.30 |
|
64 K |
115.74 |
198.05 |
244.34 |
From the table, one can draw many conclusions. Note that the buffered binary I/O mechanism is very efficient for small (less than four KB) transfers. For transfers of eight KB or more, the binary I/O interface (fread) benefits from a larger I/O buffer; in this case, 64 KB was used. However, note that using a system call to perform the I/O is substantially faster than the other methods for transfers of eight KB or more. Under no circumstances is the Fortran I/O faster than any of the other interfaces.
One word of warning with regard to the use of large (more than 64 KB) transfer sizes and system calls. Some file systems are capable of being configured so that transfers exceeding a certain size will bypass the file system buffer cache. This is referred to as direct I/O or buffer cache bypass. The intent is to keep extremely large files from occupying the entire buffer cache and/or to reduce the load on the memory system by eliminating the additional copy from buffer cache memory to user memory. The downside to this approach is that the operating system cannot perform read-ahead. Hence, the user will not benefit from memory-to-memory copy speeds.
There’s actually another lesson in Table 3-5. If we divide the transfer sizes by the time, we can get bandwidth performance. Table 3-6 contains a variation of Table 3-5 modified to reflect bandwidth rather than the amount of time per transfer. Note that the read system call delivers roughly twice the performance of other common interfaces. Thus if an application can do its own buffering, that is, read in 64 KB of data at a time, then the benefits can be tremendous.
Table 3-6. Effective Bandwidth in MB/Second for Various I/O Interfaces as a Function of Transfer Size.
|
Transfer Size (bytes) |
read system call |
fread |
Fortran unformatted read |
|---|---|---|---|
|
8 |
1.33 |
28.30 |
2.66 |
|
64 |
9.43 |
142.31 |
19.73 |
|
1 K |
107.43 |
312.41 |
180.44 |
|
8 K |
388.43 |
332.72 |
257.82 |
|
64 K |
539.99 |
315.57 |
244.34 |
The poor performance of Fortran I/O is now clear. Note that the read system call using large transfers delivers the best bandwidth. So, if your application can do its own buffering and use system calls to transfer data between your buffer and files, then that could well be the best performance option.
3.6.2 Asynchronous I/O
The Portable Operating System Interface (POSIX) standard defines a set of interfaces that enables the programmer to perform I/O asynchronous to program execution. Basically, an asynchronous read or write is accomplished by creating or using an additional flow of control to perform the actual I/O while the user’s program continues to execute. This is illustrated for an asynchronous read in Figure 3-5 below. Note the use of the aio_suspend() routine to cause the calling program to suspend processing until the read completes.
)
Figure 3-5. Asynchronous I/O enables processing to continue without waiting for file transfers to complete.
Asynchronous I/O provides the benefits of system call performance with parallelism. Details of the POSIX asynchronous I/O facility will be discussed in Chapter 8, and it should be considered for use in I/O intensive applications. There are some downsides to use of asynchronous I/O functions. Some implementations of asynchronous I/O actually create an additional flow of control in the operating system and then destroy it upon the function’s completion. This can add a tremendous amount of time to that required to actually transfer the data. SGI’s IRIX operating system provides the aio_sgi_init() function to alleviate this problem. The user can identify the number of asynchronous operations to be used by the program, allowing the operating system to more efficiently service those operations.