Multithreading Programming...Usefull?

Is multithreading useful? Most. Definitely. Is it necessary? Not necessarily, depending on what you're trying to accomplish. If you want to make the next big MMORPGNDSODI then yeah, you'll find it necessary. If you want to make a networked application such as a chat client or tic-tac-toe, then you'll probably find it necessary. (As you said. One thread is created for each person you chat with, so that you can listen for messages from them at the same time you're listening for messages from the keyboard, for instance). If, however, you're trying to make a utility to change the ID3 tags of your MP3 collection, you probably won't need to multithread anything. The same goes for plenty of games, applications, and utilities. It's possible to work without it, but why not learn it just in case you want to use it? You may be surprised by how much a difference it can make, both in your programs and your understanding of how things work.

Let me know if you're having trouble finding a tutorial if you want to get into it, and best of luck!
-jouley

Quote:

Original post by Chad Smith Also, I do know that networking applicatoins use it...don't they?

Um, well, a server could be written to be multithreaded. Or not.

Most modern application are not written to be multithreaded. Many games could take advantage of multithreading, and many do but it is not an absolute requirement.

The future is in multithreading. With multicore CPUs becoming the new normal, the ability to cope with multithreaded programming will be your ticket to the interesting jobs.

Meanwhile, most jobs will still be programming basic single-threaded code.

That's how I see it. Then again, I write and maintain multithreaded servers and single-threaded clients all day every day.

--smw

I laughed out loud when I read the thread title. YES, multithreading is useful. While simple programs that aren't intended to use much CPU or do anything complicated can continue to remain single-threaded, if you want to write anything that soaks up a significant portion of the CPU (games, some types of servers, etc.), multithreading is fast becoming absolutely essential.

We're still in the transition phase, where the ability to write highly optimized, parallel code is relatively rare. Until now, we've been able to follow Moore's law simply by increasing the clock speed of CPUs (just look at how many orders of magnitude there are between the first computers and modern computers), but we are now running into the limits of physics; unless scientists make some major breakthroughs in chip-fabrication technology, we may not ever see CPUs running at even twice the clock speed they're running at now. From here on out (again, assuming no unexpected, revolutionary advances in chip building), the only thing that's gonna increase is parallelism and specialization of hardware, and the need to know how to write good multithreaded code will become absolutely essential for anything that isn't very simple.

My prediction is that within a decade, almost all programming positions will require competency at writing efficient multithreaded code.

Quote:

Original post by Catafriggm My prediction is that within a decade, almost all programming positions will require competency at writing efficient multithreaded code.

I agree, but my prediction is that within 2 decades most programmers will no longer need to worry about multithreading because it will be mostly handled by the compiler.

Thank you all so much! It really helped


Also, usefull was the wrong word to use there. I didn't really mean it that way.

Quote:

You have a pretty extreme friend.

What do ya mean by that? lol, sorry.

I thank all of y'all for clearing some of this up to me. Thank you very much. I just wasn't sure what to believe cause my friend is someone who just think he knows everything about programming and who thinks he is the best programmer ever, so I just wasn't sure.


Anyway thanks a lot!

Chad.

If you want to be able to get the most performance out of your customers' processors, then you WILL need to know how to write multithreaded applications. There are no ifs, ands or buts about it. The biggest performance gains are going to be gotten by taking advantage of multicore processors.

You can look at the thread count for each process in the task manager (win2k and later) by going to view -> select columns -> thread count.

Firefox is using 24 for 14 tabs, winamp 6, trillian 18.... I wouldn't go so far as to say you'll fail without threading even in modern games, but it is a useful if dangerous tool.

Quote:

Original post by Telastyn Firefox is using 24 for 14 tabs, winamp 6, trillian 18.... I wouldn't go so far as to say you'll fail without threading even in modern games, but it is a useful if dangerous tool.

Depends on what you mean by "modern". If you mean today, you can juuust barely squeak by without multithreading, as double-core CPUs are still significantly outnumbered by single-cores. But in even 5 years the typical desktop will have four cores, and we might even have eight cores in high-end gaming computers. If you write a game as single-threaded, that means you can, at most, use 25% (or 12.5%) of the CPU. That's a catastrophic waste of power.

Also, if you write PS3 or XBox 360 games today, you WILL be using highly parallel code. There are eight nonsymmetric cores in the PS3, and if you don't want to get your ass handed to you by your competitors, you WILL be using at least half of those. XBox 360 has three cores, so even there you can't get away with single-thread games right now.

Raw processing power does not make a game good or even financially viable.

Quote:

Original post by Telastyn Raw processing power does not make a game good or even financially viable.

Your mission: make a blockbuster PS3 game that uses only the PPE. Ready? Go!

Quote:

Original post by Anonymous Poster i think its also important to ask: what is multithreading ?

Yes. The generally accepted definition of multithreading is to have several threads of execution within a single address space in the context of a single "process" (which is an address space associated with a single entry in the system "process table"). Each "thread" uses a separate execution "stack". I put those words in quotes because they are generalized difinitions, not necessary implementation requirements.

What goes on inside the OS, including interruopt mechanism, is not accepted as multithreaded programming, and neither is writing a program that runs on a multitasking operating system.

Just because a machine has multiple procesors does not mean you have to write multithreaded applications to take advantage of it. The Amiga, for example, had multiple processors (a CPU, a GPU, disk I/O, and sound) and yet you didn't see much (any?) multithreaded programming for it. My PC has a pipelined graphics processor and many peripheral processors more powerful than the PC XT I used in the eighties, but I don't need to write multithreaded applications to do disk I/O, play music, or make opengl calls.

A lot of programs couldn't take advantage of multiple processors even if they could be multithreaded, because their data manipulation is not paralellizable. The real trick is in being able to recognize when you can take advantage if multiple threads and what thread model would give the most benefit (worker pool, independent parallel, bucket brigade, etc) and what data organization would minimize the synchronization overhead.

No amount of threading support in the compiler could possibly understand the application and data sufficiently to make the kind of architectural design decisions required to take advantage of a multithreaded processor. A good designer can, and they'll be a valuable commodity in the near future. Kids, pay attention.

--smw

Quote:

Original post by Anonymous Poster Quote: Original post by Bregma Quote: Original post by Chad Smith Also, I do know that networking applicatoins use it...don't they? Um, well, a server could be written to be multithreaded. Or not. Most modern application are not written to be multithreaded. Many games could take advantage of multithreading, and many do but it is not an absolute requirement. The future is in multithreading. With multicore CPUs becoming the new normal, the ability to cope with multithreaded programming will be your ticket to the interesting jobs. Meanwhile, most jobs will still be programming basic single-threaded code. That's how I see it. Then again, I write and maintain multithreaded servers and single-threaded clients all day every day. --smw You poor person lol. Learning to write GOOD, CLEAN multithreaded code will not hinder you in any future endeavors. Knowledge is never a bad thing. I say learn it now with test projects/games. Great for the resume in the very near future if not already. But by far it is not NEEDED. Nor will you fail without it. You have a pretty extreme friend. My car does not fail to work even though it does not have 650hp ;-)

I bet you're proud of your answer. But if your read Bregma's post again, he actually implies that knowledge of multithread programming is a good thing (The future is in multithreading), but he also states that most jobs are still not multithread-programming oriented (most jobs will still be programming basic single-threaded code). Now, if you still want to call him a "poor person", you'd better read all his very valuable posts out there - and that's not something you did, obviously. So next time, open your eyes, read carefully, and don't forget to shut up.

To continue the discussion:

• The very very important article from Herb Sutter"The free lunch is over and a video of his talk on this subject at the Intel Research Berkeley Seminar.
• Gamasutra's "Multithreaded game Engine Architecture".
• Again on Gamasutra, "Programming the Cell Broadband Engine" and "A Glimpse Inside the Cell Processor"

Of course, you'll find more articles about multi-core CPU on intel and AMD web sites, so feel free to dig them up and post their link here [smile].

Regards,

Not to discount what everyone is saying. I agree somewhat. What I wanted to add is that some processes are by nature sequential...100 cores/better OS/and multithreading won't change that. And in something as complex as a game even if parts are threaded the program will only run as fast as the slowest thread need for sequential operation. What lies possibly in future might be more predictive algorithms and specialized cores.

Quote:

Original post by Emmanuel Deloget Quote: Original post by Anonymous Poster Quote: Original post by Bregma Quote: Original post by Chad Smith Also, I do know that networking applicatoins use it...don't they? ... That's how I see it. Then again, I write and maintain multithreaded servers and single-threaded clients all day every day. --smw You poor person lol. ... I bet you're proud of your answer. But if your read Bregma's post again, he actually implies that knowledge of multithread programming is a good thing (The future is in multithreading), but he also states that most jobs are still not multithread-programming oriented (most jobs will still be programming basic single-threaded code). ...

I believe the AP response was not what you thought it to be. Actually, it seems like the AP was answering the OP's question AND agreeing with Bregma. At least that's how I saw it.

Multi-threading your game engine to a significant extent is both extremely hard, and in no way necessary for most companies that will be making games in the next 2-3 years. It is necessary for people making the absolutely best technology for PC and cnosole (and any company doing anything complicated on a PS3), for games like whatever will come after "Gears of War" or game engines like "Unreal Engine 3".

That said, multithreading SOME parts of your application is ALMOST a necesity now. I say almost for 2 reasons. First, if you don't need to leverage multiple cores in order to increase your processing ability (you know, most games that want to target the mass market want to run really really well on older technology, and ideally a game would not give those users a degraded experience. In which case there is nothing more worth offering to customers who have 5 times the processing power) - than you don't NEED multithreading. What you do abosolutely need is either multithreading, or a system of writing your code in a way that deals with processing a whole lot of very small steps, a very very event driven and responsive processing pipeline.

Years ago I wrote 2D gambling games in DirectX 6 for Windows 98. Midway through the project we encountered serious UI lag times at various stages and also certain cases where operations that needed to be handled within a certain timeframe would occasionally not get processor time quickly enough to meat those needs (getting starved by a long-running process).

There are only 4 solutions to that problem: 1) ignore it, make your application able to handle serious flucuations in responsiveness (terrible option, but the exercise is usefull for helping you handle bad network lag too) 2) Pervasively multithread you application so each subsystem / major entity can run independantly, syncing up as little as possible. (hard in any case where the shared data or amount of interdependence is significant) 3) Break medium to large operations up into multiple steaps that can be mixed in with steps of other large operations (this is like pervasive multithreading, but its pervasive seperation that can be run on a single thread), in this case logical operations are being threaded with each other within the space of only 1 os level thread, the advantages of which are a guarantee that no single step is interuptable with minimal overhead 4) apply selective multithreading to do the large batch processes that don't need to interact with the main application very much.

We decided that only 3 and 4 we're options for us (small and inexperienced game developers), and started researching each method. We concluded that both options we're 100% viable for us, but made quick progress on option 3, and used that. At the end of the cycle we hard encountered this result: The game performed great, the engine was just as responsive as a multithreaded version (moreso since back than there was only 1 CPU anyway and going to process another method in the same thread was faster than switching and syncing OS threads in windows 98) ... but there were certain operations which are not divisible. Certain operations are fed to the OS as 1 command, and if the OS doesn't support a callback mechanism natively, there is nothing you can do about it (opening and closing files and ports, etc). So there we're times at startup and shutdown, and loading screens that the game became less responsive at UI and network processing than a multithreaded version would have, but it was a very small penalty that no clients noticed or had issues with.

Now of course with multi-cores, we would have chosed option 4.

The obvious common elements to put in almost completely seperate threads are: 1) network handling, 2) User input preprocessing.

The reason is that these 2 items are asyncrounous from the game loop. Buttons get pressed and packets arrive whenever the hell they want to.

Others things that are often partially threaded are: AI decision making (it does little good to seperate AI from the game loop completely if the decisions are tied to the game state data, but usually the decisions of each AI don't affect each other, so each AI can run in parallel.

So my main loop looks something like:

1) Compute time passage
2) Kick-off AI threads (release the gate holding them up)
3) Process fully received input (which has been preprocessed by the network and UI input threads)
4) Resync AI threads
5) Perform physics / game turn processing
6) Perform rendering / output

you see theres not much threading there, and of course there is major room for improvement by the minds that can spend the time to really work out all data and time dependencies for the specific engine or game, but in general not a lot of final answers about what can usefully be threaded in a modern game has been done.

This is the main reason cutting edge games released over the next 2-4 years will continue to do more and more - smarter threading for use on multicore systems. So it IS essential for them, just not for everyone doing every game.

Is there a programming methodology that has you send data to the thread as opposed to the threads locking that data?

Quote:

Original post by Alpha_ProgDes Is there a programming methodology that has you send data to the thread as opposed to the threads locking that data?

Message passing. Windows and OS X are heavily based on this (I couldn't say about other OS for sure). And you could sort of say that's how the Cell's SPEs work.

[Edited by - Catafriggm on January 17, 2007 2:07:14 PM]

Quote:

Original post by jouley (As you said. One thread is created for each person you chat with, so that you can listen for messages from them at the same time you're listening for messages from the keyboard, for instance).

No no no no no! Nobody does that. That's the single most retarded thing that someone could possibly do with threads that I've heard in a looooong time.

Quote:

Original post by DrEvil Quote: Original post by jouley (As you said. One thread is created for each person you chat with, so that you can listen for messages from them at the same time you're listening for messages from the keyboard, for instance). No no no no no! Nobody does that. That's the single most retarded thing that someone could possibly do with threads that I've heard in a looooong time.

Rather than thinking up more "interesting" uses, I've decided to ask "Why?"