GUMP Member Posts: 1335 From: Melbourne, FL USA Registered: 11-09-2002 |
I worked on this topic further, refining it a bit more and adding more information, and I'll be publishing it as an article. Feel free to discuss it here and suggest more information. [This message has been edited by Gump (edited January 18, 2005).] |
bennythebear Member Posts: 1225 From: kentucky,usa Registered: 12-13-2003 |
in the simplest way possible can somebody tell me what concurrent programming is? i have a very begginer knowledge of programming, so all the technical stuff will be about 8ft over my head. ------------------ www.gfa.org - Gospel for Asia www.persecution.com - Voice of the Martyrs |
|
GUMP Member Posts: 1335 From: Melbourne, FL USA Registered: 11-09-2002 |
Concurrent programming is writing multiple threads that run in parallel on different CPU cores. Though multiple CPUs are not necessary it will run a lot faster compared to a single CPU. |
goop2 Member Posts: 1059 From: Registered: 06-30-2004 |
Im 6 foot tall so its only 2 feet over MY head  ------------------ I dont like siggys. They are to hard to think up :( |
|
bennythebear Member Posts: 1225 From: kentucky,usa Registered: 12-13-2003 |
i'm 5'9 so it's actually 7'9 over over your head  ------------------ www.gfa.org - Gospel for Asia www.persecution.com - Voice of the Martyrs |
|
bennythebear Member Posts: 1225 From: kentucky,usa Registered: 12-13-2003 |
it's took me a long time to realize how much bad coding can effect a program/game. thief 3 requires a really high video card, and yet looks no where near as good as other games that require the same. so concurrent programming makes better use of what's there(on the hardware side)? my analogy(a bad one prob'ly)...it's like a vehicle. say the motor is the program/game, and it's exaust would be what the processors handle. it would be like having dual exaust and using both pipes for maximum airflow. where normal programming would be trying to force it all down one of the pipes...ok...i lost myself on that one...i still think i get it though. ------------------ www.gfa.org - Gospel for Asia www.persecution.com - Voice of the Martyrs |
Briant Member Posts: 742 From: Stony Plain, Alberta, Canada Registered: 01-20-2001 |
I'm not sure, but I don't think concurrent programming is going to be the end-programmer's responsibility. Yes knowledge of how it works can only help you write more efficient code (as knowledge of how internal caching works now) but for the average programmer on the average project, I think it's going to be largely invisible, and handled behind the scenes by the operating system. We'll see, though. ------------------ |
|
GUMP Member Posts: 1335 From: Melbourne, FL USA Registered: 11-09-2002 |
When I first heard about multi-core CPUs I was hoping that was going to be the case but unfortunately each core is going to be treated as a separate CPU by the OS. While splitting up the threads among the cores will be transparent to the programmer it apparently will still require the programmer to write a multi-threaded app in the first place. BTW, what did you think about my article? I realized afterwards the title is kind of a misnomer considering I barely talk about concurrent programming and largely leave it up to that other article I link to. [This message has been edited by Gump (edited January 23, 2005).] |
Klumsy Administrator Posts: 1061 From: Port Angeles, WA, USA Registered: 10-25-2001 |
yep but in reality you'd be writing such multithreaded apps already? i love multithreaded coding, but hate multithreading debugging , following the tracing can be a pain.. not too much of an issue when different threads are just different and unique subsystems, but when you got a complicated network of worker threads starting and ending , being queued and processed - it can get a bit hairy. Then lets say you use some resources/libraries/apis that don't work well in multithreaded enviroments - painful.------------------ |
|
Briant Member Posts: 742 From: Stony Plain, Alberta, Canada Registered: 01-20-2001 |
quote: Only if they want to take advantage of multithreading on multiple CPUs. Single thread programming isn't going to go away People can do single- or multi-threaded programming now, on a single- or multi-CPU system. Of course mult-threading is generally going to be the better performer, but I think concurrency programming is likely going to make multi-threaded programming more common, but that's about it - except for maybe the high-end professional who is carefully optimizing and taking full control over which threads run on which CPU and when. I don't know though, I may be out to lunch.
quote: I think it's pretty good. I have a strong interest in optimizing. Brian ------------------ |
Wacko4X Member Posts: 92 From: Bellvue, WA, USA Registered: 08-21-2002 |
I agree with BrianT, excellent article... If only I knew how to do it |
