I almost puked on the keyboard when I read this thread.
Anybody trying to use more than a handful of threads should not be programming or at least learn the basics of how a computer works. Seriously no offence but your idea is utter crap and you are not using threads properly at all and not only are you confusing the design but also because of overhead and context switches your performance will be utterly poor. The maximum number of threads you should be using (and by this I mean the utter maximum in most cases) is NumberOfPhysicalCPU * 2, and ideally you only want one per physical although in some cases (single core processors) you will want to use a background thread for resource loading, etc.
One more doubt in thread.
Quote:Original post by Anonymous Poster
I tryed a code similar to this one, in java, and what happens? Was able to start 50000+ threads on this machine(256MB)!
Wow, thats actually kinda impressive, in a sick sort of way.
Now do something useful with it. [rolleyes]
There are very few reasons to create an OS thread:
1) Multiple tasks executing simultaneously (1 thread per CPU/core)
2) Block until alerted, then respond and repeat (ex: I/O Completion Ports, or having a GUI thread that keeps the interface responsive while other threads do long processing)
There might be a few more situations where threads are appropriate, but in most other cases threads just make your program run slower. Each time a cpu switches threads, cache coherency can be lost, which can be a HUGE slowdown if your program access a lot of data.
If you want to simulate independant objects updating in a 'nearly simultaneous' manner, do something like:and just let them update sequentially.
As for why you get different results from java, are you sure it's actually creating the threads and not simply adding them to a 'list of threads to create soon' or even 'list of functions to run to simulate threads'? No telling how the VM handles the threads - they might even get optimized out, or they might run immediately then exit to make room for new threads, etc. It really depends on _exactly_ what is going on everywhere, which is why threads are something you don't often see in program proofs (similar to the way globals are frowned upon)
1) Multiple tasks executing simultaneously (1 thread per CPU/core)
2) Block until alerted, then respond and repeat (ex: I/O Completion Ports, or having a GUI thread that keeps the interface responsive while other threads do long processing)
There might be a few more situations where threads are appropriate, but in most other cases threads just make your program run slower. Each time a cpu switches threads, cache coherency can be lost, which can be a HUGE slowdown if your program access a lot of data.
If you want to simulate independant objects updating in a 'nearly simultaneous' manner, do something like:
for_each( AllObjects.begin(), AllObjects.end(), mem_fun(&Object::Logic));//orfor_each( AllObjects.begin(), AllObjects.end(), bind2nd(mem_fun(&Object::Logic), LogicParameter));As for why you get different results from java, are you sure it's actually creating the threads and not simply adding them to a 'list of threads to create soon' or even 'list of functions to run to simulate threads'? No telling how the VM handles the threads - they might even get optimized out, or they might run immediately then exit to make room for new threads, etc. It really depends on _exactly_ what is going on everywhere, which is why threads are something you don't often see in program proofs (similar to the way globals are frowned upon)
Author
Quote:Original post by Extrarius
As for why you get different results from java, are you sure it's actually creating the threads and not simply adding them to a 'list of threads to create soon' or even 'list of functions to run to simulate threads'? No telling how the VM handles the threads - they might even get optimized out, or they might run immediately then exit to make room for new threads, etc. It really depends on _exactly_ what is going on everywhere, which is why threads are something you don't often see in program proofs (similar to the way globals are frowned upon)
I was thinking in something like that. Maybe this is correct, so, I'll use the class this manner. Just put more memory if more threads is needed :)
OK, so now, a more cplicated task(I think): How to put the class cspr in a vector(or other thing), to make things dinamically loadable? What I want is make an array of objects that can be easily modificated. Some members(objects in the array in any index) will destructed, while new others will be appended. The std::vector does not work very well for this task as I saw.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
