.Net and Multi-Core Systems

[Fred]

We all agree that multi-core is where the industry is headed.
Can the .NET framework take advantage of multi-cores? are the programs
written in .NET multi-threaded by default or is additional tweaking
required? Will there be any new features in the new version of the .NET
framework to extend multi-core capabilities?

Fred

[Henning Krause [MVP - Exchange]]

Hello,

well, Garbage Collection runs on a seperate thread by default. But to get
all out of the new cores you have to build your applications accordingly.

..NET 3.5 introduces LINQ (Language integrated query), some of object
manipulation technique. What they are working on is PLINQ, where P stands
for paralell. This might make it easier to take advantage of multi-core.

But in the meantime you'll have to design your programs accordingly using
multiple threads where appropiate.

Kind regards,
Henning Krause

"Fred" <fr*******@yahoo.comwrote in message
news:e8**************@TK2MSFTNGP05.phx.gbl...

We all agree that multi-core is where the industry is headed.
Can the .NET framework take advantage of multi-cores? are the programs
written in .NET multi-threaded by default or is additional tweaking
required? Will there be any new features in the new version of the .NET
framework to extend multi-core capabilities?

Fred

[james]

Hey Fred,

The runtime is also tackling the issue of cache coherancy for you
( since each chip has its own cache, values may not get reported back
to RAM for a while ). On a multi-core system, the runtime makes all
writes violatile (meaning straight back to RAM), while reads can come
from the cache. This means that most programs written for a single
CPU should work fine on multiple CPUs without a significant
performance penalty. You can use
System.Threading.Thread.ViolatileRead or VIolatileWrite if you want
more control, and C# offers a violatile keyword. Interlocked methods
( used for mutexes, semaphores, etc ) use violatile so they still work
on multi core systems.

Regards,
James

[Chris Mullins [MVP]]

Do you have cites for the info you're saying?

The cache write-through doesn't sound right to me, and I would like to know
more. How would this work?

- Variable "x" has a value in ram of 100.
- Core 1 & Core 2 each decide they need "x" and load it into their local
cache.
- Core 1 does a write of "500". This updates core1 cache, and (according to
you) main memory.
- Core 2 reads x, and gets a stale value.

It just doesn't sound quite right.

I do recommend against using Thread.VolatileRead/Write, due to the 2-way
memory fence it imposes. It's not at all the same as a volatile variable.

Interlocked methods certainly don't use volatile variables - they use a
different mechanism, that has different behavior. They are safe for multiple
cores though, and in many ways are similar to volatile variables.

--
Chris Mullins, MCSD.NET, MCPD:Enterprise, Microsoft C# MVP
http://www.coversant.com/blogs/cmullins

"james" <ja********@gmail.comwrote in message
news:11**********************@m3g2000hsh.googlegro ups.com...

Hey Fred,

The runtime is also tackling the issue of cache coherancy for you
( since each chip has its own cache, values may not get reported back
to RAM for a while ). On a multi-core system, the runtime makes all
writes violatile (meaning straight back to RAM), while reads can come
from the cache. This means that most programs written for a single
CPU should work fine on multiple CPUs without a significant
performance penalty. You can use
System.Threading.Thread.ViolatileRead or VIolatileWrite if you want
more control, and C# offers a violatile keyword. Interlocked methods
( used for mutexes, semaphores, etc ) use violatile so they still work
on multi core systems.

Regards,
James