Program running too slowly? Just give it another core! (NOT!)

[Paulo]

US nuke boffins: Multicore CPU gains stop at eight

More core ? Moore's Law

Rodrigues and his colleagues ran simulations which indicated that a
16-core unit would actually perform "barely as well" as a dual-core one.

More at...

http://www.theregister.co.uk/2009/01/15/sandia_boffins_multicore_dropoff/





__________ Information from ESET Smart Security, version of virus signature database 3599 (20081110) __________

The message was checked by ESET Smart Security.

http://www.eset.com

 

[RayLopez99]

US nuke boffins: Multicore CPU gains stop at eight

More core ? Moore's Law

Rodrigues and his colleagues ran simulations which indicated that a
16-core unit would actually perform "barely as well" as a dual-core one.

More at...

I bet because in reality multi-core apps don't exist.

I think that a compiler has to be invented that automatically 'de-
threads' or "makes parallel" your program, akin to automatic garbage
collection in OOP. Until that happens, multicores are not going to
happen. And writing your code to be parallel compatible is a pipe
dream seems to me. Better a switch you can add to your compiler and
be done with it.

RL

 

[Ken Foskey]

I bet because in reality multi-core apps don't exist.

I think that a compiler has to be invented that automatically 'de-
threads' or "makes parallel" your program, akin to automatic garbage
collection in OOP. Until that happens, multicores are not going to
happen. And writing your code to be parallel compatible is a pipe dream
seems to me. Better a switch you can add to your compiler and be done
with it.

Which is why the Unix method of implementing different programs and then
combining them is so effective. Creating new processes in Windows is too
expensive for it to work the same.

To find a sorted list of something:

grep something * | sort | uniq > newfile

Grep would run on one core, sort on another and uniq on the third.
Very easy for the operating system to handle this. When you do this as a
pipe inside your program you capture output and process it.

It has multiple benefits:

a) Testability: each program is simpler and testable
b) Isolation: Each program is protected from errors in the others
c) separation of logic: You can separate out a simple text interface
then overlay a GUI over it.

Ken

 

[Arne Vajhøj]

US nuke boffins: Multicore CPU gains stop at eight

More core ? Moore's Law

Rodrigues and his colleagues ran simulations which indicated that a
16-core unit would actually perform "barely as well" as a dual-core one.

More at...

http://www.theregister.co.uk/2009/01/15/sandia_boffins_multicore_dropoff/

Considering that 8, 16, 32 and 64 CPU servers has been used
for years, then it should be obvious that the limit they see
does not apply to all types of usage.

And since they do not write in the article exactly what
apps they have used for the test, then it seems likely
that their results may not even apply to the majority.

The real point is probably in the:

<quote>
The Sandia boffins say that the Jaguar is based on their Red Storm
design, and that they have a "large investment in message-passing
programs" which "may help solve the multicore dilemma".
</quote>

which I interpret as "we are doing useful stuff here please
send more money".

Arne

 

[Arne Vajhøj]

I bet because in reality multi-core apps don't exist.

I think that a compiler has to be invented that automatically 'de-
threads' or "makes parallel" your program, akin to automatic garbage
collection in OOP. Until that happens, multicores are not going to
happen. And writing your code to be parallel compatible is a pipe
dream seems to me. Better a switch you can add to your compiler and
be done with it.

Apps that runs fine in parallel do exist and have so for
many years.

ASP.NET should not have any problems scaling to many cores.

Arne

 

[Arne Vajhøj]

Which is why the Unix method of implementing different programs and then
combining them is so effective. Creating new processes in Windows is too
expensive for it to work the same.

Since Windows has had threads since the beginning (excluding
the 9x stuff) then that does not mean much.

It has multiple benefits:

a) Testability: each program is simpler and testable
b) Isolation: Each program is protected from errors in the others
c) separation of logic: You can separate out a simple text interface
then overlay a GUI over it.

That is true but it is also slow and cumbersome.

Arne

 

[bruce barker]

the problem their test show is contention for memory access on the chip.
this is a well understood problem, and just requires multiple memory
paths to the cache, better scoreboarding and parallel memory fetches.
current memory chips usually are only single or dual ported, this also
needs to be updated but not worth it until core counts bump up higher.
see the sony/ibm cpu/memory structure for the cell processor as an up to
date design.


-- bruce (sqlwork.com)

 

[Ken Foskey]

Ken Foskey wrote:
Since Windows has had threads since the beginning (excluding the 9x
stuff) then that does not mean much.

Threads do not offer the memory protection of totally different
applications.

Threading is extremely difficult to get right. I have years of
experience and I still trip myself up occasionally. Totally separate
applications talking through a defined interface is so much simpler.

That is true but it is also slow and cumbersome.

Have you written applications this way? I have and I have not found this
to be the case.