General Question multi-/hyperthreading

[tylor2000]

Hello,

I wanted to ask if orbiter has multi-thread support, will have multi-thread support, or just doesn't really need it because of the size of the program.

It is just a case of curiosity... nothing urgent here.

 

[Saturn V]

Hyperthreading isn't really required for Orbiter, but if you've got a hyperthreading processor or dual/quad core processor and a decent graphic card, it sure runs much smoother and faster. But that's a given since that's what that technology was intended to provide.

 

[Hielor]

Orbiter doesn't make good use of multiple cores. The performance improvement from having additional cores is more from having Orbiter on its own core (and background processes on other cores) than from Orbiter being able to use more than one core.

 

[agentgonzo]

Orbiter addons could be written to use more than one thread (vis core), but AFAIK none have been written to do so. There's a noticeable performance drop when using AerobrakeMFD (due to the numerical integration) and so moving the processing for AerobrakeMFD into a separate thread would help.

 

[Artlav]

Current Orbiter was written back when multicore CPU's were exotic. No specific support for them in it.

Some add-ons do use multiple cores, Orulex for example, where computations are done in a separate thread from Orbiter.
But, synchronizing can be troublesome, since you can't just call OrbiterAPI or receive callbacks from another thread.

 

[tylor2000]

I was reading that most current VC supports threading just has to be compiled so. so that is 1 reason I was asking and then because things are getting more complicated. But I was pretty sure damn small linux.......ah I mean orbiter was not big enough to use more than one core.

 

[agentgonzo]

VC has supported threading since the days that dinosours roamed the earth. That's not the point. The program code needs to be written to support multiple threads in order to take advantage of multiple cores. The orbiter code is not (as it is harder to writer multi-threaded code and get it right) and that's why orbiter does not make use of multiple cores.

 

[Urwumpe]

The latest versions support OpenMP as language extension though, which makes producing multithreaded programs a lot easier...

http://en.wikipedia.org/wiki/OpenMP

 

[Nerull]

I was reading that most current VC supports threading just has to be compiled so. so that is 1 reason I was asking and then because things are getting more complicated. But I was pretty sure damn small linux.......ah I mean orbiter was not big enough to use more than one core.

Threading has absolutely nothing to do with size.

 

[Artlav]

The latest versions support OpenMP as language extension though, which makes producing multithreaded programs a lot easier...
http://en.wikipedia.org/wiki/OpenMP

The simplicity is quite insidious, and getting it efficient and right at once might be rather non-trivial on any project of significant size.

orbiter was not big enough to use more than one core

Big enough in what sense? It's quite easy to make a <1Kb program that will use all 24 cores on the latest 4-socket Intel Nehalem board, and there could be insideously complex multi-mb programs that can't even use one core right.

 

[n122vu]

...and there could be insideously complex multi-mb programs that can't even use one core right.

Microsoft Flight Simulator 2000 comes to mind LOL


Will the new version (current beta), benefit from multi-core technology, since the core and graphic engines will be separate?

 

[tylor2000]

Points taken. And agreed.

 

[Urwumpe]

The simplicity is quite insidious, and getting it efficient and right at once might be rather non-trivial on any project of significant size.

That is rather a multitasking problem in general.

 

[tylor2000]

The simplicity is quite insidious, and getting it efficient and right at once might be rather non-trivial on any project of significant size.


Big enough in what sense? It's quite easy to make a <1Kb program that will use all 24 cores on the latest 4-socket Intel Nehalem board, and there could be insideously complex multi-mb programs that can't even use one core right.

I thought it had four cores and 16 threads. Or did they up it? I think they have 2 socket mobos and notebooks now.

---------- Post added at 06:52 AM ---------- Previous post was at 06:41 AM ----------

I'm not even sure I'd want it to be multi-core. I have a 900 mhz celeron single core anyway. I was really just curious. And I do know how threading fell out of fashion....or whatever you want call it. Unless you know someone who wears silicon earrings I guess it's not a fashion tend stuff......where am I going with this.....:edit:

 

[cjp]

I use multi-threading in my not-yet-released OrbiterProcTer(*) add-on. I noticed something strange: my extra threads have low priority (to not disturb Orbiter too much), but they run faster when they have -1 priority than when they have -2 priority. This is on a single-core machine. From what I know about thread scheduling, I can only explain this if there are other threads with priority -1 in Orbiter.

I think I'll have a look at this in a debugger.

(*) Will be like better Orulex. Currently it's more like wanna-be Orulex.

 

[Saturn V]

However a machine delegates thread/core priority is in the end, irrelevant to me. When I first discovered Orbiter, I was running a single core AMD or Celeron (don't remember which anymore) processor and the concept of hyperthreading/multi-core processors was as Artlav pointed out, exotic.

The program ran, but higher graphic content add-ons stuttered, ran very slowly, or occassionally, froze.

I can't say that I'm a tech-addict and I need all the "whistles & buzzers" for the sake of having them, but running a Pentium 4 quad-core processor with 4GB RAM for the past year and a half, there is absolutely no stutter or graphic glitching of any kind with Orbiter.

Both machines ran/run upper-mid level graphics cards with their own GPUs and the marked difference in performance I have to attribute to the multiple core.

My point was that though Orbiter is not dependent on it and doesn't support it per se, it's still very useful to have.

 

[ar81]

What are best practices to program multithreading?
When should it be used? When shouldn't?

 

[Hielor]

However a machine delegates thread/core priority is in the end, irrelevant to me. When I first discovered Orbiter, I was running a single core AMD or Celeron (don't remember which anymore) processor and the concept of hyperthreading/multi-core processors was as Artlav pointed out, exotic.

The program ran, but higher graphic content add-ons stuttered, ran very slowly, or occassionally, froze.

I can't say that I'm a tech-addict and I need all the "whistles & buzzers" for the sake of having them, but running a Pentium 4 quad-core processor with 4GB RAM for the past year and a half, there is absolutely no stutter or graphic glitching of any kind with Orbiter.

Both machines ran/run upper-mid level graphics cards with their own GPUs and the marked difference in performance I have to attribute to the multiple core.

My point was that though Orbiter is not dependent on it and doesn't support it per se, it's still very useful to have.

Yes, this benefit comes from moving background processes to other cores, so the Orbiter process doesn't experience as many interrupts. In this case, adding additional cores won't particularly help (ie, a dual-core running at 2.4ghz will be effectively the same performance as a quad-core running at 2.4ghz).

Also, how'd you manage to get a quad-core Pentium 4?

 

[Saturn V]

Also, how'd you manage to get a quad-core Pentium 4?

I mis-spoke. The Pentium 4s were hyperthreading weren't they?

The tower says it's an Intel Core2 Quad. I don't remember how many Ghz it runs at, but I've had video rendering in the background while I was running Orbiter and been doing simultaneous up/downloading online as well with no noticable impact on the performance of any of them.

If you've ever done any video editing/rendering with Vegas, you know how processor intensive the operation is, yet I had no dropped frames in the video and Orbiter running as smooth as a baby's behind.

"Works for me" is the bottom line...

 

[cjp]

What are best practices to program multithreading?
When should it be used? When shouldn't?

Simplicity:
There are rare cases where multithreading simplifies a program. This is typically when a program's purpose is inherently multi-threading, and a single-threading implementation would be unnecessarily complicated. However, such cases are rare, and usually multithreading adds a lot of complexity to an application (read: hard-to-solve bugs will occur). This basically means that as long as there is no good reason, you should not use multithreading.

Performance:
When you have a very time-consuming task, involving lots of CPU time, which is allowed to take a long time, but should not disturb more urgent tasks, such as refreshing the simulation + the screen, then the time-consuming task can be placed in a separate background thread. Besides allowing the more urgent task to have a higher refresh rate, it allows multi-core / hyperthreading systems to run both on different cores, which gives higher overall performance.

Performance can also be improved when a certain task does not involve lots of CPU operations, but potentially waits a long time on I/O operations. For instance, when doing time-consuming things on the GPU, it is possible that the rendering thread waits for the GPU to finish a certain frame. If simulation runs in a separate thread, then the simulation can be done on the CPU while rendering waits for the GPU. This way, no CPU time is wasted.

Communication:
Communication between different threads is complicated. The separation into different threads should be such that the interface between them is small and well-defined. Also, the interface should be such that the time different threads wait for each other is reduced to a minimum. Otherwise, performance can easily be worse than in a single-threaded application. Threads should spend most of their time on doing their own job, and not on talking to each other. This means that for some kinds of tasks, a multithreading design makes no sense.