Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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?

share|improve this question

migrated from stackoverflow.com May 28 '13 at 14:07

This question came from our site for professional and enthusiast programmers.

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. –  jim mcnamara May 28 '13 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? –  Mike Dunlavey May 28 '13 at 14:21

1 Answer 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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.