Multithreading

[mkarg]

Using TaskManager I have seen that on Hyperthreading-enabled CPUs one "virtual CPU" is idle while the other is at 100%. So I assume that JKDefrag 3.16 is single-thread. Since even on my 3200+ MHz PC JKDefrag 3.16 needs lots of hours to run in the "-a 9" mode, it might be beneficial to implement more multi threading?

[jeroen]

Thanks for sharing your thoughts, I appreciate it! Yes, the JkDefrag library is single-threaded. The Windows version uses threads to update the screen, but files are moved only 1 at a time. Usually the CPU time used by JkDefrag is very little, most of the time is spent waiting for the harddisk (disk I/O). Only when moving a lot of very small files will JkDefrag use a lot of CPU. Do you have a virus scanner? On some virus scanners the time spend in the virus scanner shows up in the task manager as time spent in JkDefrag. Try turning off the virus scanner while defragging.

Most of the work that JkDefrag does depend on the results of previous work. For example, if it wants to defrag a file then it will look for a free gap on disk. But gaps are created and filled all the time, by the program itself. So threads will have to communicate somehow, and that will make it very difficult and complex to use mulithreading. This is just one example, there are many other programming problems.

Tip: You can run multiple JkDefrag's by making copies of the executable. The program checks if it's already running by looking for "jkdefrag" (and some variations) in the task list, and does not start if it finds that it's already running. By renaming the program you can negate the test. Please note that you should only run 1 instance of JkDefrag per volume, that is, every instance should be started with options so it processes only 1 disk.

[mkarg]

Thank you for your kind answer. Actually the virus scanner is on but I cannot switch it off -- it is centrally regulated by the master admin. :-(

I once wrote a explorer.exe replacement years back and used multi threading intensively, e. g. to copy many files in parallel instead of in sequence, and it was interesting to see that actually it was possible to move 10 files in parallel in the same time than a single file. So in fact, at least SOME hardware out there seems to be multi-threading-able.

For the synchronization: I know that problematic, since I am a software engineer, too, and deal with multi threading since years. In most places where programmers said, it is impossible to use multithreading, it actually WAS possible after thinking again. :-)

If you like my idea, we could share our brains about this item. Because, what people mostly do not know, multithreading is not about the CPU doing multiple things in parallel, but about the CPU not waiting for something else (like RAM, disk, etc.) ;-)

For example, I could imagine that there could be multiple threads used in this way:
* Everything that has to do with CPU-Power (Analysis, Sorting, Searching) often can split up perfectly into parallel search and sort algorithms using all N cores of modern CPUs. --> One thread per CPU core.
* Everthing that has to do with Hard Disk can be done by one or two other threads (it should at least be possible to have two threads working down a "movement tasks queue", since you can read from disk cache while the second thread waits for a movement to finish). Also I could imagine that it is possible in SCSI environments, to run multiple writes agains a single disk thanks to command queueing etc. (Certainly the threads will block but with multiple commands getting queued the disk can decide to run them out-of-sequence which speeds up the common process).
* Logging in a single thread: We do not need to wait until the log is written. Especially with detailed log levels, this can be a long time.
* Screen is already a single thread.
The synchronization certainly must be the disk image (or a copy in memory) but I do not see that it will be too hard to code the communication / synchronization.

[jeroen]

Thanks for your offer to work on this, I appreciate it! I have some experience with multithreading myself, and I'm sorry but have to respectfully disagree. Adding multithreading in the case of JkDefrag is no small task. Also, at the moment I am working on other improvements for JkDefrag that I feel are more important, such as direct disk scanning and the scripting language. So thanks again for your offer! But not right now, maybe in the future.

[Soichiro]

For a program that does more disk access than CPU usage, multithreading would be a bad thing. By having more than one file moved at a time, you're forcing the disk head to move back and forth between different parts of the disk more often than it would normally, and although most drives have only an 8-10ms seek time, when you have the head moving all over the place all the time, this adds up to several extra minutes for a defrag.

[jeroen]

I'm not entirely sure, but I think the Microsoft defragmentation api on which JkDefrag is based, goes through the disk cache. In that case the cache can execute the requests out-of-sequence, as mkarg suggested.

[Soichiro]

If that's the case, then what happens when the cache is full? Most hard drives only have 8 MB cache, with some large ones having 16 or 32MB, and some smaller ones only having 2MB. During IO-heavy activities such as defragmenting, that cache is going to fill up very quickly, and then there's no choice but to write to the disk. I don't want to say I'm sure just how much of a hit this would cause to performance, but at the very least, I'd say the benefits of multithreading in JkDefrag would be questionable.

[jeroen]

Most hard drives only have 8 MB cache

No, I meant the Windows cache. JkDefrag does not access the harddisk directly, it sends instructions to the Windows defragmentation api. I'm not sure at which level the api functions, but I suspect it's just above the Windows cache, since it's universal for all filesystems. If that is the case then multithreading could perhaps speed up JkDefrag considerably for small files. Not for big files, because for those files the disk I/O speed is the bottleneck.