8350rocks :
Thought I would share this...
http://www.hotchips.org/
3:20 PM
Processors 2
Hardware-level Thread Migration in a 110-core Shared-Memory Processor
Mieszko Lis, Keun Sup Shim, Brandon Cho, Ilia Lebedev and Srinivas Devadas
MIT
Whoever said 100 core CPUs were way off in the distance may have been entirely wrong...
Seems MIT is working on such a threading solution on large scale super scalar CPUs. Wouldn't that be interesting? The coding would be nightmarish at first, though once the software industry takes a step back, and begins to think about how to solve problems in parallel, it may
eventually* facilitate such solutions.
*Note: I am not saying this is happening, now or tomorrow, or even this year. Merely that we are clearly heading in that direction at the limit of current technology's capabilities. Barring the discovery of room temperature super conductors, there would really be no other obvious way to get x86 architecture to do more work outside of adding the capability to process more threads simultaneously. Obviously this takes a great deal of work to even get to a point where a program could sufficiently use such a massive number of threads. However, I could see something like a HPPC utilizing such a solution for flow dynamics or protein synthesis, or some other massively parallel task that could use such an absurd number of resources now...
Eh, so MIT is trying what it tried, and failed to do, with its 10,000 CPU cluster back in the 80's. And they'll find the same exact problems at the end of the day: After about 16 or so CPU's, performance gains decline to almost nothing, and after 32 or so, you start getting negative performance.
100 threads nightmarish? I'm not sure so sure. Once you've got 4, 6 or 8 threads working correctly, scaling up to 100 threads is not such a big deal - all the technical issues have been solved, you're just doing more of the same.
"Working correctly"? Do you even know how to thread? In a Windows environment:
http://msdn.microsoft.com/en-us/library/kdzttdcb(v=vs.90).aspx
Not that complicated; just an invokation of _beginthread (which itself is just a wrapper around CreateThread(), minus the memory leak).
The real issue is one of thread control.
Anytime you have multiple threads touching the same object, you HAVE to wrap that object around some form of thread control structure (Mutux, CRITICAL_SECTION, etc) that prevents more then one thread from touching it at the same time. Whenever two threads try and touch the structure, one has to wait. The issue then becomes, if you have multiple threads that try and touch the same objects often, threading will likely reduce performance, due to the threads having to constantly wait on eachother to get their work done (a problem that grows orders of magnitudes worse if those threads in question have child threads which are ALSO forced to wait). There have been various ways over the years to improve performance in the best case outcome (Transactional Memory is a good example of such a workaround), but all tend to increase the worst case penalty as a result.
In short: The more threads you have touching the same data structures, the more performance degrades.
Lets take a look at media encoding: You have some form of file in some format that looks something like this at a really high level:
Header data
Media Data
Media Data
Media Data
...
Footer data
In theory, since every chunk of Media Data is the same exact format, you can easily make a multithreaded solution that could (theoretically) scale up to the number of chunks of Media Data that need to be processed. Heck, anything to do with file processing/formatting is trivial to make parallel, and guess what? Productivity software has already gone this route.
Games are harder, much much harder. You can scale within a specific part of a game engine without too much difficulty, but threading the different engines themselves leads to significant deadlock situations.
You run into priority problems too. For example: UI is obvious very low priority (remember: 16ms per frame, and 16ms is an eternity), but what happens if you are ready to render a thread, and you still haven't had a response from the UI thread? Has it run yet, or was there simply no UI for that period? What do you do if you start to render the current frame, and the UI thread finally runs and, guess what, you missed some UI to process? Delay it? Start over from scratch? No real good answers here: Either a FPS drop, or input lag.
You have scheduling issues. Say you have some function that appears to thread well, and you create 8 worker threads to process it. Great, but you still have the Windows scheduler to consider here. The key issue being: You can't continue until all 8 worker threads complete, and if any one gets held up for any reason whatsoever, you come to a screeching halt. So you need to weigh the cost-benefits of using multiple threads over just one, and often, its determined by how much work is being done. If the work is trivial, it often isn't worth it to thread.
Then of course there are the idiotic arguments by some people here. My favorite was in response to these two images:
and
Obviously, the first is threaded better, because the FX-8350 does better then it does in the second, right?
Wrong. You don't code different levels, you code the engine. The FX-8350 does better simply because whatever environment is being processed goes through a part of code that happens to scale well. [Likely the code that was offloaded from the GPU, if i had to guess]. The other levels (Post-Human and the Roof of all Evil) favor Intel, again, simply due to what is being processed. The idea different stages are coded any different (or at all) is laughable, but its what people put out to try and prove their points.
So please, as the only person here who's actually coded and developed on multihreaded software, enough. Creating threads is TRIVIAL, its getting those threads to run in some coherent way thats impossible.
Facebook
Twitter
Instagram