Interesting, but it seems like the article might be very old. It mentions 2010 in the future tense:

By the middle of 2010, Intel Labs anticipates having dozens of industry and academic research partners conducting advanced software research on the SCC hardware platform.

I hate so much when the article cannot be bothered to write down a timestamp. I think it's kinda basic, common sense to stamp ones writings with time... or it's just me.

Edit: Sorry about the OT. An interesting thing I found from the article is that while having 12 times more cores on the chips, it uses about the same (as max) or 5 times less power than my current cpu :/ I think that I should upgrade my system.

“The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet.” - Michael A. Jackson

Seems like those researchers are quite similar to game programmers, taking pride in small improvements in algorithms:

Quote

Our performance evaluation reveals that on average our wait-free MCAS algorithm performs 8.3% faster than other practicalapproaches in all tested scenarios.

I've heard that GPU processors have been massively multicore for some time. I would have thought that most of the multi-core and multi-threading programming issues would have been sorted out and fully optimised already. It's interesting that these authors find new ways to squeeze out more performance from the software.

GPU's are (currently) only useful for massively parallel...which is the easier nut to crack. The big issues are coming up with good languages (or language features) which are easy to use and can fill a massive set of processors for general computing. And the other is improving concurrent data-structures. The reason I hit this page was for the "wait-free" MCAS. Before about 5 years ago there little to no useful wait-free methods...but they are now starting to "happen"....and that is massively awesome even for few cores.

My question is what happens when all these cores hit the same word in memory at the same time. We're going to get diminishing returns after a while just adding cores. This article does talk as if it might be multiple computers on a chip rather than cores, meaning more than one memory.

Java could be useful here. Unlike in C# (don't know about C or C++), a Java thread has to lock the same monitor to be sure of seeing changes in another thread's synch block. This could let Java run a lot faster on such a system, because data only has to be copied from one memory to another rather than to all memories. (Of course, it could just break the code of millions of programmers who did not pay attention to the fine points of Java multithreading, or just never imagined their code would run on such a machine.)

Current languages aren't really very good at a huge number of cores. On locks...ideally we'd like to have very fast "wait-free" versions of everything and better versions of "lock-free" while we're waiting for very clever folks to invent the wait-free methods....we want locks to die! die! die!

These types of cores and architectures, like the transputer does not share memory. It has communication buses between cores and you pass messages to share data and synchronize. The general "mesh" like arrangement is quite popular for study at the moment and was back in 2010 as well. I reviewed a few papers on it. There is even hardware around.

I have no special talents. I am only passionately curious.--Albert Einstein

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org