Parallel I/O: file per process vs libraries like HDF5

56 Views Asked by At

For high performance computing applications with parallel I/O onto Lustre file systems, does file-per-process output give the upper limit to performance? I had always used HDF5, assuming it was some sort of high performance library, until I realized how terrible the parallel I/O performance was compared to file-per-process for my specific application. Sure, file-per-process is not as beautiful, and may require some (cheap) postprocessing to get into a useful format, but after wasting so much time trying to optimize HDF5 and getting terrible performance in the end I am wondering why anyone would use such a library for parallel I/O for high performance computing. What is wrong with file-per-process output and why is it common to discourage it? For bandwidth, is there any way to beat it?

1

There are 1 best solutions below

0
Squirrel On

optimizing I/O is very code dependant and even use case dependant with the same code.

Generally speaking, "file per process" approach is discouraged when the number of file created by each process become large since it can introduce latency on the MDS (metadata server). The other problems is also the number of inode (the number of files you can create, on super computer for example, user can not create an unlimited amount of files). Still, it can achieved high I/O throughput compare to parallel under a certain number of process.

I recommand you to take a look on that documentation PRACE-parallel I/O, section 2 and 3.