0

I am profiling the speed at which a certain Linux program reads a certain input file using different amount of threads by doing this:

time ~/src/myprogram -t $t inputfile 1>/dev/null 2>/dev/null

It seems like no matter what number of threads I use, starting from 12 down to 1, the time is exactly the same. Is there any other way to test this to make sure it is not influenced by the speed that data is sent to /dev/null?

2
  • 2
    I would look at your /src/myprogram rather than bash not doing what you think it is doing. /dev/null is a kernel device, I/O to it is as fast as I/O can get on your system. Please post your code if you want help. May 28, 2013 at 12:32
  • 2
    Threads can only make code faster if it can spread CPU-bound operations across multiple cores. If your code is reading a file from disk, how are threads supposed to make it faster? May 28, 2013 at 14:21

1 Answer 1

1

The kernel caches I/O read from incoming block devices in free RAM. Unless your file is very large you are probably hitting the cached data in RAM and not actually causing any I/O.

A very quick search and reading this Stack Overflow answer reveals that this might do it:

sync && echo 1 > /proc/sys/vm/drop_caches

so I would try issuing those command before the command that performs the I/O.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .