And how would that work? Would the AV s/w simply pick one of your
cores and use it 90% of the time at 90% (or 75%) load factor? If so,
that would make your PC more secure I guess but at the cost of
'slowing down' your machine overall (not at peak times but if there
was no AV sw). On the other hand, if the AV sw does not pick a core,
then having a multiple core machine is of no advantage and
paradoxically you can slow down your machine when the AV s/w hogs
resources on both cores (rather than one) during peak loads.

I guess I'm asking whether AV s/w is optimized for today's multicore
PCs.Same question for firewall s/w.

RL

On May 27, 11:10*pm, RayLopez99 <raylope...@gmail.com> wrote:
> And how would that work? *Would the AV s/w simply pick one of your
> cores and use it 90% of the time at 90% (or 75%) load factor? *If so,
> that would make your PC more secure I guess but at the cost of
> 'slowing down' your machine overall (not at peak times but if there
> was no AV sw). *On the other hand, if the AV sw does not pick a core,
> then having a multiple core machine is of no advantage and
> paradoxically you can slow down your machine when the AV s/w hogs
> resources on both cores (rather than one) during peak loads.
>
> I guess I'm asking whether AV s/w is optimized for today's multicore
> PCs.Same question for firewall s/w.
>
> RL

On a related note (which is not what my original question asks) here's
a graphic that shows how much faster an AV sw will run, in parallel,
when using all cores of a multi-core PC:
http://www.tomshardware.com/reviews/...pu,2280-9.html

Not exactly what I'm asking, since I'm talking about 'background'
tasks and where the program resides. Whether it takes over a core or
just allows the OS to decide where to place it. Now that I think
about it, perhaps for background stuff you only need one core, and the
program can let the OS decide which core (in a multi-core) to pick,
then, when the user clicks on "scan my computer" icon (or some such),
then the AV program can decide how many cores it can or wants to use
(and override the OS).

RL

RayLopez99 wrote:

> I guess I'm asking whether AV s/w is optimized for today's
> multicore PCs.Same question for firewall s/w.

I don't know.

Why don't you ask Lipman?

RayLopez99 wrote:
> And how would that work? Would the AV s/w simply pick one of your
> cores and use it 90% of the time at 90% (or 75%) load factor? If so,
> that would make your PC more secure I guess but at the cost of
> 'slowing down' your machine overall (not at peak times but if there
> was no AV sw). On the other hand, if the AV sw does not pick a core,
> then having a multiple core machine is of no advantage and
> paradoxically you can slow down your machine when the AV s/w hogs
> resources on both cores (rather than one) during peak loads.
>
> I guess I'm asking whether AV s/w is optimized for today's multicore
> PCs.Same question for firewall s/w.

You'll have to ask the vendors.

If they are multithreaded, they can at least take advantage of some
parallel processing. If they aren't multithreaded, the OS can do *some*
things to make parallel processing work anyway.

It is best if the multithreaded program was designed from the ground up
with parallel processing in mind.

RayLopez99 wrote:
> On May 27, 11:10 pm, RayLopez99<raylope...@gmail.com> wrote:
>> And how would that work? Would the AV s/w simply pick one of your
>> cores and use it 90% of the time at 90% (or 75%) load factor? If so,
>> that would make your PC more secure I guess but at the cost of
>> 'slowing down' your machine overall (not at peak times but if there
>> was no AV sw). On the other hand, if the AV sw does not pick a core,
>> then having a multiple core machine is of no advantage and
>> paradoxically you can slow down your machine when the AV s/w hogs
>> resources on both cores (rather than one) during peak loads.
>>
>> I guess I'm asking whether AV s/w is optimized for today's multicore
>> PCs.Same question for firewall s/w.
>>
>> RL
>
> On a related note (which is not what my original question asks) here's
> a graphic that shows how much faster an AV sw will run, in parallel,
> when using all cores of a multi-core PC:
> http://www.tomshardware.com/reviews/...pu,2280-9.html
>
> Not exactly what I'm asking, since I'm talking about 'background'
> tasks and where the program resides. Whether it takes over a core or
> just allows the OS to decide where to place it. Now that I think
> about it, perhaps for background stuff you only need one core, and the
> program can let the OS decide which core (in a multi-core) to pick,
> then, when the user clicks on "scan my computer" icon (or some such),
> then the AV program can decide how many cores it can or wants to use
> (and override the OS).

You may find this of interest if you haven't read it already.

http://www.intel.com/intelpress/samp...samplech01.pdf

On May 28, 5:09*am, Virus Guy <Vi...@Guy.com> wrote:
> RayLopez99 wrote:
> > I guess I'm asking whether AV s/w is optimized for today's
> > multicore PCs.Same question for firewall s/w.
>
> I don't know.
>
> Why don't you ask Lipman?

What does he know that you don't? Why do you always prostrate and
toady yourself to others, putting them first? Why don't you stop
crawling on your hands and knees and stand up for yourself?

RL

On May 28, 3:55*pm, FromTheRafters <erra...@nomail.afraid.org> wrote:

> You'll have to ask the vendors.
>

Yes, I figured that, but they won't talk under the hood proprietary
stuff.

> If they are multithreaded, they can at least take advantage of some
> parallel processing. If they aren't multithreaded, the OS can do *some*
> things to make parallel processing work anyway.

What would that be? Other than of course allocating which programs
get which cores and for how long.

>
> It is best if the multithreaded program was designed from the ground up
> with parallel processing in mind.

That is true. And scanning a hard drive for viruses is a task that
lends itself easily to parallel processing, with no need to even run
semaphores or otherwise coordinate separate threads.

RL

On May 28, 4:19*pm, FromTheRafters <erra...@nomail.afraid.org> wrote:

> You may find this of interest if you haven't read it already.
>
> http://www.intel.com/intelpress/samp...samplech01.pdf

Just read it, thanks. Amdahl's law was interesting, as well as the
below passage. Regarding the below passage, this is very true in
searching the chess tree in a chess playing software for example. You
don't 'solve' for the 'best' move any faster with parallel processing
and multiple cores, but you get a higher quality 'best' move, since in
a given tree your search, when using multiple cores, is deeper than
with a single core, and hence your 'quality' of 'best' move (which is
never known to be 100% certain to be the best move) goes up.

RL

Perhaps the biggest weakness, however, is the assumption that
Amdahl’s Law makes about the problem size. Amdahl’s Law assumes that
as the number of processor cores increases, the problem size stays the
same. In most cases, this is not valid. Generally speaking, when given
more computing resources, the problem generally grows to meet the
resources available. In fact, it is more often the case that the run
time of
the application is constant.

RayLopez99 wrote:
> On May 28, 3:55 pm, FromTheRafters<erra...@nomail.afraid.org> wrote:
>
>> You'll have to ask the vendors.
>>
>
> Yes, I figured that, but they won't talk under the hood proprietary
> stuff.

They shouldn't be reluctant to disclose how well they optimize their
program for multiple processors or multicore processors.

>> If they are multithreaded, they can at least take advantage of some
>> parallel processing. If they aren't multithreaded, the OS can do *some*
>> things to make parallel processing work anyway.
>
> What would that be? Other than of course allocating which programs
> get which cores and for how long.

The OS keeps track of what resources are being used or not currently
being used and can allocate those resources where needed.

>> It is best if the multithreaded program was designed from the ground up
>> with parallel processing in mind.
>
> That is true. And scanning a hard drive for viruses is a task that
> lends itself easily to parallel processing, with no need to even run
> semaphores or otherwise coordinate separate threads.

Indeed, if you are considering the active component being on one
processor and the background filesystem scanning being done on another.
However, that might not be the case. Both aspects may be using both
resources for different parts of their respective execution.