Re^2: MCE: Slow IPC between child and gather process in parent

Yes, you could be correct. When developing parallelized programs like this one, I use two tools to help me identify how well or poorly my code is working. They are htop and iostat. htop is variation of the venerable top command that orignated on VMS and found its way to Linux and the Mac. It lets me monitor processor core utilization and near real time performance statistics of my process(es). iostat monitors the read and write rates to my hard disks. I run it as iostat 1 and it provides IO statistics on a second by second basis.

Given my personal experience, these output from these tools indicated that I was no IO bound when running at the longer times - the disk transfer rate was too low for IO to have been a factor. Now, with the reduced times, I am seeing much higher IO rates and IO is definitely the limiting process

Thanks!, lbe

Comment on Re^2: MCE: Slow IPC between child and gather process in parent

Replies are listed 'Best First'.
Re^3: MCE: Slow IPC between child and gather process in parent by jeffenstein (Hermit) on May 03, 2018 at 09:26 UTC
It could still be IO bound. Disk throughput is just one factor, there is also the wait times for the disks to serve the requests. On linux, use iostat -x to add the disk queue, wait, and service times to see if they increase significantly while your program is running. It can even be a factor on SSD disks, if there are many small reads and writes. In this case the SSD may lag behind because internally it has a minimum block size that it must read or write. For example, if you are reading / writing 8k blocks, but the SSD has a 128k internal block size, the effective top throughput can be 1/16th of the SSD's top throughput.	[reply]
A reply falls below the community's threshold of quality. You may see it by logging in.
Re^3: MCE: Slow IPC between child and gather process in parent by Anonymous Monk on May 02, 2018 at 22:17 UTC
I would make the number of workers easily-adjustable and experiment with reducing it one-by-one to find the sweet spot.	[reply]