simple multi-thread question

[GambitMR]

got a simple question on multi-threaded programming/applications: can a multi-threaded application be run on a singlecore sys. and IF ..how is it handled? Does the OS determine how much cpu-time which thread needs ?
Is one thread eating up all the performance while the other dries out ? Would there be a need for a single-threaded version of the app. ?

thanks in advance for your answers

[rg3]

Threads are no more than "execution flows" for the same program. You can have three programs, with one execution flow each (single-threaded applications) run at the same time on your computer, right? The same way, you can have one program with three execution flows. Long story short (partially false): the OS handles execution flows and distributes CPU time among them. In Unix, for example, it's typical to have several priorities for them. Their priority is raised or lowered according to the thread's behaviour, if they took all the CPU "slice" it was assigned or dropped it before it finished, etc. If you write a program with two CPU-intensive threads, chances are they both get 50% of CPU time (aprox).

[GambitMR]

thanks for the answer http://forums.3drealms.com/ubbthreads/images/graemlins/smile.gif

if I remember right Q3 was multithreaded .. ...no ? [was on a LAN once ..back when Q3 was released .. .and one guy always booted into NT because it could utlize both celeron 300@450 he had http://forums.3drealms.com/ubbthreads/images/graemlins/wink.gif] (I ask this because I'm curious on how multi-threaded games work on single cpus)

[rg3]

No idea about the Windows version. The Linux one has an SMP (Symmetric Multi-Processor) binary suitable to machines with several CPUs. I suppose the Windows version is capable of doing the same thing. In any case, I don't know if the application is multithreaded or multiprocess. Multithreaded sounds apropiate for a game, multiprocess doesn't make a lot of sense.

[DudeMiester]

Only the Pro and Server versions of windows support SMP, that's why he was using NT and not Win98 or whatever what out at the time.

[tony]

The windows versions of q3 could have SMP enabled via a config file optiom. r_smp =1, if i remember correctly.

[CronoMan]

Seems like you mix up multi-threading and multi-processor. A computer does not need more CPU's to manage several processes, this is managed through a "virtual multiplexer", which means the processor switches between tasks to make it look like it does everything simultanously. The multi-processor support for both Windows and Unix sucks donkey penix, better to use processors with hardware multi-threading.
In windows, you can use the task-manager to "tell each program which processor to use", which can seem very nifty, but doesn't utilize both processors right. I don't know how Unix handles this, but I have been told it's just as silly. As far as I know, BeOS is the only OS that manages multiple processors good, acquiring about 98% of max (with a good mainboard that is) while Windows and Unix can utilize about 40-60%.

[rg3]

CronoMan said:
Mostly bullshit.


What? I'll pass on the Windows comments because I don't know how good is the SMP support in that system.

First, what's hardware multi-threading? If you mean Intel's HyperThreading thingy, it works and is handled like a SMP machine, for the most part. They are not "better" that SMP systems (what for?). In any case, the scheduler thread affinity comments about Unix are plain wrong. In fact, it usually works the opposite way. Threads are usually scheduled for execution in any free CPU, with practically non-existan affinity. They work that way from Linux to FreeBSD to Solaris. In the real world, optimal performance is achieved if you make a thread run always in the same CPU, taking advantage of CPU caches, as long as you don't screw scheduling for the rest of threads.

40-60% performance is just a plain wrong figure. You don't get that silly performance even with a 2.4 Linux kernel. Saying that BeOS makes CPUs perform at 98% of max theoretical power *may* be a right figure (I don't know the system), but then it should be the same for Linux, FreeBSD or Solaris, to name the same three as above.

Edit: given the proper conditions, of course. You won't gain a lot of performance if you run a single-threaded CPU intensive program in a SMP system. But given two CPU intensive threads/processes I can tell you a dual CPU system will give you double the performance of a single CPU, believe me.

[CronoMan]

rg3 said:

CronoMan said:
Mostly bullshit.


What? I'll pass on the Windows comments because I don't know how good is the SMP support in that system.

First, what's hardware multi-threading? If you mean Intel's HyperThreading thingy, it works and is handled like a SMP machine, for the most part. They are not "better" that SMP systems (what for?). In any case, the scheduler thread affinity comments about Unix are plain wrong. In fact, it usually works the opposite way. Threads are usually scheduled for execution in any free CPU, with practically non-existan affinity. They work that way from Linux to FreeBSD to Solaris. In the real world, optimal performance is achieved if you make a thread run always in the same CPU, taking advantage of CPU caches, as long as you don't screw scheduling for the rest of threads.

40-60% performance is just a plain wrong figure. You don't get that silly performance even with a 2.4 Linux kernel. Saying that BeOS makes CPUs perform at 98% of max theoretical power *may* be a right figure (I don't know the system), but then it should be the same for Linux, FreeBSD or Solaris, to name the same three as above.

Edit: given the proper conditions, of course. You won't gain a lot of performance if you run a single-threaded CPU intensive program in a SMP system. But given two CPU intensive threads/processes I can tell you a dual CPU system will give you double the performance of a single CPU, believe me.




HyperThreading :
http://www.guygraphics.com/index2.html


To be correct, two processors can not double the performance, that's almost impossible (due to BUSes and memory access).
And talking about SMP; the SMP model makes it so all I/O actions are made by CPU#1, any I/O that has to be done must be done by CPU#1, this includes disk access, network, graphics, etc. All the other processors are very high priced calculators which can only modify stack and memory.

When you assign each processor its own thread, this ensures that the CPU's don't "***** up", and will be reliable. But this should be an automatic action taken by the OS itself. Always make sure the applications that need the most CPU use the processor with the least amount of load.
In Windows or Linux, this is not automatic as far as I know, and therefore downs system performance.

[rg3]

HyperThreading :
http://www.guygraphics.com/index2.html


To be correct, two processors can not double the performance, that's almost impossible (due to BUSes and memory access).


Sure, that's a realistic statement.


And talking about SMP; the SMP model makes it so all I/O actions are made by CPU#1, any I/O that has to be done must be done by CPU#1, this includes disk access, network, graphics, etc. All the other processors are very high priced calculators which can only modify stack and memory.


Not at all. Access to other hardware (including memory) from the CPUs is handled by the hardware and both cannot access memory at the same time. In any case, memory is slow and a bottleneck even for UP systems.


When you assign each processor its own thread, this ensures that the CPU's don't "***** up", and will be reliable. But this should be an automatic action taken by the OS itself. Always make sure the applications that need the most CPU use the processor with the least amount of load.
In Windows or Linux, this is not automatic as far as I know, and therefore downs system performance.


Yet again the same point. You divide your program the way you want. If you want to make a thread to handle all IO, so be it. If all threads handle their own IO, so be it. Suppose you make a program that multiplies two matrices. You can make two threads. The first thread will calculate the upper half result matrix and the second one will calculate the lower half result matrix, using the traditional inefficient algorithm. Run it in a UP system and then in a SMP system with two CPUs of the same kind as in the UP system. The program will run in, more or less, half the time it took in the UP system. And, at least in modern Unices, threads will be assigned whatever CPU is free (the ready queue is unique), but the OS will use some subtle and simple affinity algorithms while scheduling to try to maximize performance taking advance of the CPU caches.

[CronoMan]

rg3 said:
Yet again the same point. You divide your program the way you want. If you want to make a thread to handle all IO, so be it. If all threads handle their own IO, so be it. Suppose you make a program that multiplies two matrices. You can make two threads. The first thread will calculate the upper half result matrix and the second one will calculate the lower half result matrix, using the traditional inefficient algorithm. Run it in a UP system and then in a SMP system with two CPUs of the same kind as in the UP system. The program will run in, more or less, half the time it took in the UP system. And, at least in modern Unices, threads will be assigned whatever CPU is free (the ready queue is unique), but the OS will use some subtle and simple affinity algorithms while scheduling to try to maximize performance taking advance of the CPU caches.



And still, as far as I know, Windows and Linux does not handle multiple processors this way, that's why I said they only utilize 40-60% of possible load.

[SippyCup]

I dunno about in C++, I haven't gotten that far, but I know in VB .NET you can actually set the priority of each specific thread to give it more or less of the processor's attention during a cycle.

[rg3]

CronoMan said:
And still, as far as I know, Windows and Linux does not handle multiple processors this way, that's why I said they only utilize 40-60% of possible load.


In that case, please inform yourself before making those comments. I'll pass on the Windows case (but I very much doubt it's *that* bad) and head straight to the Linux case, which is very very similar to other modern Unices out there:

This test (http://kerneltrap.org/node/514) conducted by Con Kolivas comprises several kind of programs. cacherun is the most CPU greedy one. Read those figures. Pay attention to the ones in kernel 2.5, the predecesor of the current 2.6 kernel which performs a little better according to my benchmarks.

This article (http://www.samspublishing.com/articles/article.asp?p=101760&rl=1) explains the internal workings of the Linux scheduler. As you can see, when one CPU is free, the kernel fixes the imbalances between runqueues and schedules tasks in free CPUs, so as to achieve perfect SMP scalability. Still, proccesses are pushed into the queue of the last CPU they used, to achieve some sort of CPU affinity.

[CronoMan]

rg3 said:
[QUOTE]
CronoMan said:

This test (http://kerneltrap.org/node/514) conducted by Con Kolivas comprises several kind of programs. cacherun is the most CPU greedy one. Read those figures. Pay attention to the ones in kernel 2.5, the predecesor of the current 2.6 kernel which performs a little better according to my benchmarks.

This article (http://www.samspublishing.com/articles/article.asp?p=101760&rl=1) explains the internal workings of the Linux scheduler. As you can see, when one CPU is free, the kernel fixes the imbalances between runqueues and schedules tasks in free CPUs, so as to achieve perfect SMP scalability. Still, proccesses are pushed into the queue of the last CPU they used, to achieve some sort of CPU affinity.



You could be right, I'm not known for having the most updated information on every field :P