6
  • Anti-virus: Microsoft Security Essentials
  • OS : Windows 7 x64

Silly question perhaps, but somehow I was under the impression that multiple cores would mean the anti-virus scanner would be able to handle multiple files concurrently by allocating them to different cores.

As it turns out I'm wrong. The attempt to scan two disparate folders concurrently brings up a message to the effect that the scanner is already occupied. So I'm curious (+:

On a true dual-processor board, would my virus scanner be able to scan multiple files concurrently, or is this just a design quirk with the scanner?

1
  • 6
    Something important to note is that your processor is orders of magnitude faster than your hard drive, and it's quite possible that you can already scan files faster than you can read them from the disk. In this case, running multiple scans at the same time could be highly detrimental to performance, given that seek time on a traditional hard drive is incredibly slow.
    – Phoshi
    May 24, 2011 at 11:25

4 Answers 4

7

The short answer is: a design quirk of the scanner.

The ability to scan multiple files concurrently has more to do with how your virus scanner is programmed. To do what you want, the software has to be made to run parallel reads. I don't know of any virus scanner that does this.

2
  • Any idea why AV don't run parallel processes? Is it just a legacy, or is there some design constraint?
    – Everyone
    May 24, 2011 at 12:51
  • After reading your comment, I realized I used a poor choice of words. I don't know of a virus scanner that does parallel reads. I've edited my answer to reflect that. I'm not sure why they don't do parallel reads. As AndrejaKo states, it might be possible on different physical harddrives. I've never tried that.
    – Chris Ting
    May 24, 2011 at 13:25
8

From the software side in 99% of all cases, multicore processor is no different than multiprocessor system.

In some cases, there could be an advantage in the multicore camp because the communication between cores is quicker than it is for multiprocessor systems.

On the other hand in computers which need huge amounts of RAM, multiprocessor systems may be better because you can assign RAM to each processor to control for its own tasks and in that way increase the amount of available RAM.

Once again, multicore processors such as ones used by today's personal computers are fully capable or running several tasks at the same time and there would be almost no advantage of having multiprocessor system.

Also do note that the load is controlled by OS kernel. It may decide that in a multicore or multiprocessor system (which are same from OS and application point of view) it will be better for the whole system to dedicate the rest of the cores to some task other than virus scanning.

Another point of view is HDD. It can't physically read two files at the same time, so it's going to be a major limiting factor. Some AV software may copy files to RAM first and them try to scan them in parallel, but there would be no performance improvement because usually the limiting factor is HDD speed, so there's no need to take up RAM.

You could always scan in parallel files on different hard disks and improve performance that way. I had no problems with scanning in parallel two directories on two different HDDs using Avast 6.

7
  • Thank you (+: The notes on multi-processor RAM allocation were an eye-opener for me. The same with using multiple HDD; I'll try it out when my other HDD returns home
    – Everyone
    May 24, 2011 at 12:50
  • I wouldn't say the HDD is the limiting factor - checking for viruses can involve a lot of CPU too - there's no technical reason a virus scanner couldn't be scanning on multiple threads. I suspect it's just a design decision (eg. Maybe because there's one central UI with a cancel button) or laziness. May 24, 2011 at 21:10
  • Also - I'm almost certain two different disks will be no different to two locations on the same disk. If someone programmed their virus scanner to support multiple scanning processes and made it not work on a single disk, I'll eat my hat :-) May 24, 2011 at 21:11
  • @Danny Tuppeny The main thing is that on a single disk you have a reading head which can't be at two places at the same time. With TWO DIFFERENT hard disks, you can in fact read two files at the same time. On some computers (like mine, to which I was referring) virus scanning may not be limited by CPU speed. In such cases, using different drives (or even better different drives on different controllers) can in fact bring performance improvements.
    – AndrejaKo
    May 24, 2011 at 21:38
  • @Danny Tuppeny As for multithreading, most antiviruses I've seen can run separate scans on separate threads. The whole discussion related to this question is that there's going to be little improvement in scanning speed by adding multithreaded to a single scan process because the scanning is limited by HDD speed and not CPU speed, so the antivirus spends most of its time waiting for data to come from the HDD.
    – AndrejaKo
    May 24, 2011 at 21:41
2

"Any idea why AV don't run parallel processes? Is it just a legacy, or is there some design constraint?"

Writing multi-threaded code is an order of magnitude harder than writing single-threaded code, so we tend to avoid it unless it provides a great benefit.

In this case, the speed of the anti-virus scan is bottle-necked by the speed of the hard-drive/memory reads, not the speed of the CPU, so multi-threading would offer very little benefit.

5
  • If your two threads can remain entirely separate (As in, both scanning different files, rather than two working on the same file) then it wouldn't be particularly hard to thread it. Whether there are any benefits, on the other hand...
    – Phoshi
    May 24, 2011 at 17:21
  • @Phoshi: The threads need to be able to communicate somehow to make sure they're not working on the same file to begin with, and they both need to write to the log, to the list of quaranteened files, etc. They can't remain entirely separate. May 24, 2011 at 17:41
  • Sure they can, have a control thread hand out files to scan to a thread pool of (number of cores) threads, and have those threads signal the control thread when they're done. The control thread can handle all of the log writing itself. The actual scanning threads don't need to care about each other at all, they just need to scan a file and report back whether it's safe.
    – Phoshi
    May 24, 2011 at 18:00
  • @Phoshi: Yes, I know how it would be done. But the point is that is clearly more complex than having a single thread, and if there is no speed-benefit, then why bother? May 24, 2011 at 18:20
  • Yeah, I see no major benefit to threading it, but not threading it is more easily attributable to there being no benefit, rather than the difficulty of threading it.
    – Phoshi
    May 24, 2011 at 18:26
1

AV scanners also tend to be designed to work alongside other programs with minimal intrusion (McAfee never seemed to get this memo, though) into what you are trying to do with the system besides scanning for viruses. For this reason, they may be designed not to utilize more than one core concurrently in order to leave the other cores available for your use.

It may be a good idea for AV programmers to offer a "full power" option for dedicated scans that employ caching and all processor cores to do super-thorough, super-speed scans of possibly infected systems.

Thinking about this, I really like this idea. Sure the scanner could be much faster than the HDD, but utilizing massive amounts of memory and multiple threads in an on-demand scan situation could allow incredibly intense scanning of the system in relatively short periods of time.

You must log in to answer this question.

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