Hello,

I'm developing the client for a game that is currently working with a lot of threads (10). Basically its done in the way that I created a thread for every task that can run independed.
Surely it turns out in the way that the most of this threads sleep most of the time. The performance at this approach is pretty good.

Now another approach would be that I use a pool of worker threads that fit the count of CPU cores that can be used and have them handling the tasks.

Does anyone has any informations or any experience what way is in general better?

Nitram

Thread creation is usually very costly in heap memory usage. Thus, "worker" Threads are better, because one Thread is handling multiple tasks. usually a java.util.Timer can be used, though it may not be guarranty that the tasks are run in the order they are pushed on.

The creation is not really a issue. All the tasks are repeated. So their threads are created once at startup and remain idle then in case they are not needed and are only destroyed when the program exits.

Nitram

I'd like to point out an issue, which has impact on performance. On multicore systems, each CPU has its own cache, and possibly a local copy of a variable. Writes on one CPU are not immediately visible on another. Thus, doing a job on one thread (CPU), and suddenly turning that job to another thread is not a good solution. I prefer specialized threads each doing a specific job, on specific data. Then no need for synchronization, if it is sure, that some data always belong to a specific thread.

I'd like to point out an issue, which has impact on performance. On multicore systems, each CPU has its own cache, and possibly a local copy of a variable. Writes on one CPU are not immediately visible on another. Thus, doing a job on one thread (CPU), and suddenly turning that job to another thread is not a good solution. I prefer specialized threads each doing a specific job, on specific data. Then no need for synchronization, if it is sure, that some data always belong to a specific thread.

It seems like you are confusing threads with cores. The OS will take care of managing your threads. You never have to do synchronization with data that is only read and written on the same thread. The OS and hardware will take care of moving the data needed to another core, if needed.

Quote from: VeAr on January 05, 2010, 11:35:23

I'd like to point out an issue, which has impact on performance. On multicore systems, each CPU has its own cache, and possibly a local copy of a variable. Writes on one CPU are not immediately visible on another. Thus, doing a job on one thread (CPU), and suddenly turning that job to another thread is not a good solution. I prefer specialized threads each doing a specific job, on specific data. Then no need for synchronization, if it is sure, that some data always belong to a specific thread.

It seems like you are confusing threads with cores. The OS will take care of managing your threads. You never have to do synchronization with data that is only read and written on the same thread. The OS and hardware will take care of moving the data needed to another core, if needed.

I'm not confusing threads with cores, but given a situation where the machine has multiple cores, threads can run on different cores, which has impact on their behaviour.

"You never have to do synchronization with data that is only read and written on the same thread."
Yeah, thats what i'm saying too. Its better to design the program so, that certain data is localised to a certain thread, than to make everything a task and throw it on a thread-pool.

"The OS and hardware will take care of moving the data needed to another core, if needed."
Isn't true. You have to declare variables volatile, and put code into synchronized blocks is you want to maintain integrity. But the goal is to avoid the need for such integrity, by making every thread run as much independently of other threads as possible.

Forget the thread-pool. Data ownership is important. If you read about X10, you will see, that the whole language is about managing the ownership of the data, and managing it manually, by the programmer.

I'm not confusing threads with cores, but given a situation where the machine has multiple cores, threads can run on different cores, which has impact on their behaviour.

"You never have to do synchronization with data that is only read and written on the same thread."
Yeah, thats what i'm saying too. Its better to design the program so, that certain data is localised to a certain thread, than to make everything a task and throw it on a thread-pool.

OK, I misunderstood what you meant.

"The OS and hardware will take care of moving the data needed to another core, if needed."
Isn't true. You have to declare variables volatile, and put code into synchronized blocks is you want to maintain integrity. But the goal is to avoid the need for such integrity, by making every thread run as much independently of other threads as possible.

Sorry, I meant that if the OS is changing the core that a thread is running on, the OS and hardware will handle moving/getting the needed data to run on that core. The programmer doesn't have to worry about which core a thread is running on.

whether cores or threads, it always results to the same bad perfs if the software running on the machine does bad threading-task management.
One thing that I omitted in the first reply, is "synchronization locks" which you have mentioned. I've read some about multi-core hyperthreading by Intel public reviews and those are thinking about how multiple cpu running hyperthreading would boost the multi-threaded softwares.
As a result, multi-core HT is always pushing to more intensive computing on multi-threaded software, like Java is. But it's obvious that reducing synch' times in the Java code will produce better perf.

Thus, doing a job on one thread (CPU), and suddenly turning that job to another thread is not a good solution. I prefer specialized threads each doing a specific job, on specific data.
(...)
by making every thread run as much independently of other threads as possible

And obviously, running one single Thread for a specific task, repeated over time, is good. Anyway, Swing has EDT and you may add your thread's, as long as it doesn't overlaps too often from your Thread to Swing.
 

10 threads including the JVM related threads(GC, JIT etc.)?