Absolutely required reading: http://www.gotw.ca/publications/concurrency-ddj.htm .
Four little words: Long Term Competative Advantage
The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software
mummey
#2
Very interesting. One problem with making 3D software multi-threaded is that 3D apps use a lot of data that would have to be shared. Because of this large amount of shared data, it might be difficult to see a good amount of benefit out of a multi-threaded version of the app.
DaKrunch
#3
very interesting!
i’ll need to take some time to learn concurrency better…
tnx 4 the link!
dotTom
#4
It’s going to be huge in terms of further dividing the programming men from the boys (I use the phrase generically 
. Interestingly there’s no real new runtime or dev tool support from the largest vendor (Microsoft) until “Orca”, Visual Studio 2006. “Whidbey”, Visual Studio 2005 includes OpenMP but that’s about it when it comes to concurrency.
MDuffy
#5
It can be done, it is just a lot tougher. What we will probably see in the future is the locking of data structures needing to get very fine in resolution. For example, you have a 10,000 vertex object that you are doing transforms on. One thread will be assigned verts 0-3000, the second thread assigned verts 3001-6000, and the third thread assigned verts 6001-9999. Destination arrays will likewise need to have territory assigned to each thread, and then semaphores put in place to schedule when each part is done. You won’t have threads doing things largely on their own for a while, but rather you will have threads that work on a lot of smaller parallel tasks. It will take quite a while before coders develop and learn all the little tricks for getting code to run fast in parallel.
Cheers,
Michael Duffy
stew
#6
Well, so far most system APIs haven’t been supporting or encouraging multithreading - Win32, Mac Toolbox, Cocoa, Swing or Motif never did much for multithreading, so programmers never bothered to learn. Large parts of them aren’t even thread-safe. I was lucky enough to start C++ on BeOS, where the system API forces you to use threads in GUI code, whether you like it or not. My programming on other systems has profited from that, as I now tend to use threads a lot more than my coworkers and that I have some experience in dealing with the potential pitfalls.
That’s true. Still, as more and more 3D processing gets handed down to the GPU, which already is parallell processing massively, the stuff that is left for the main CPU to do should stand to gain a reasonable amount from multithreading. AI with multiple computer controlled units can be given separate threads for each group of units and physics simulation can have a separate thread for each active spatial division.
Per-Anders
#9
most 3d apps already multithread quite extensively (of course i can’t talk for all apps api wise, but c4d has pretty decent access to internal threading as and when you need it, i’ll assume the others do too).
stuh505
#10
the author of this paper says that these new multithreading based cpu’s will not benefit single thread applications…but that doesn’t make sense to me
if the computer were only running 1 thread then it would make sense…but right now I have almost 600 threads running and each one of those threads is going to reduce the frequency that a big single thread app is going to have it’s next process evaluated…
so it seems like for even single thread apps, multithreading would have a tremendous increase
am I wrong?
Vertizor
#11
The way you’re wording your theory makes it sound incorrect. Your use of the word “multithreading” is a bit inappropriate. Multi-threading is not a function of a CPU, that responsibility is very much a job for an OS’s kernel. The CPU will execute a thread it is told to execute, the kernel schedules all of that. So your 600 threads (BTW most of them lay dormant so it’s not a big deal) have varying levels of priority which the kernel will manage.
A thread can only be executed by one CPU only. You can have a 128-CPU cluster, but if the app you’re running only executes on one single thread, you have 127 idle CPUs.
Just because there’s another CPU or core there to address the many other threads so that one CPU can completely focus on an intensive task, doesn’t make it automatically faster. You’ll get an overall “preceived” performance increase because the system is more responsive. That preception is what they’re aiming for. So you have to take what the author said litterally - giving 2 executing cores to a program that will only use 1 will not make it run faster… faster than one single CPU that runs at a higher frequency.
maruchan
#12
The article is more alarmist than anything. Same points are covered over and over, as if the author wants to stir people up or something.
Yeah, he’s right that OO was also a revolution of sorts, but it’s not like it came in the back door and took our development skills away.
My prediction: This next revolution will create more jobs, and all the smart software companies will be scrambling to provide your average developer with tools that make it easy to compete. Everyone will have more than enough time to bring their apps up to date.
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.