Java - Maximum Recommended Threads At One Time ?

Started by
10 comments, last by slayemin 9 years, 5 months ago

Usually if your threads are compute threads expected to use as much ressource as you need, then between 1 to 2X number of concurrent hardware threads (core or hyperthreading included) is a good match, in your case if you're just firing events it can handle a "lot" of threads, but as other mentioned it's likely not the solution you should be headed for.

Note that threads as OS ressources have a 1 time cost (creation time) and permanent cost (stack size). While you can change the later it really doesn't make any sense to have 1 thread per event anyway, have 1 thread firing all your events.

Advertisement

On a normal computer ( 2.6 GHZ processor, 2 GB RAM ), how many threads do you think can be running at one time without causing system issues ?

A few years ago in university, I took a distributed networking class, where we break a big problem down into smaller chunks and send those work chunks out to a computer network (30 machines) to work on. Each computer would do a little bit of work and send the results back. I had a brilliant idea: I'd break the work down into really tiny chunks and send them all out. Computers can do small things really fast, right? Wrong. I had a benchmark for how long it would take a single computer to accomplish all of the work (~2 minutes). When I used my scheme, it took 5 minutes or so for 30 computers to complete. Why? Because every single microscopic task came with overhead costs. I had to create the task on my master computer, send it out across the network, the computers accomplish the task and return the results over the network. The cost of creating and distributing the work was more expensive than the work itself. So, I turned my "work" chunks into much larger chunks. Suddenly, I was able to compute all of my stuff in 10 seconds. That was an unintuitive surprise for me which only makes more sense in hindsight.

In your case, you are trying to divide up 40,000 microscopic tasks and distribute them across X number of processor cores. You're going to be at the mercy of the OS thread scheduler. You're going to have overhead costs. Chances are, whatever cost savings you're imagining you'll get are probably going to hinder performance a lot more (especially considering that each thread will take a context switch and require loading data to and from the CPU cache and RAM). Will it work? Who knows. Don't listen to any of us, try it out and measure it and see for yourself. Hard metrics data is going to give you a 100% definitive answer and can tell you if your optimizations actually have an effect on performance.

This topic is closed to new replies.

Advertisement