I am running QNX 6.3.2 on single core systems so far but we are thinking of changing the computer to Intel Core 2 Duo. We are not prepared to change the software to fully utilize the dual core or do some fancy scheduling. I guess my question is, can I expect my software to run on dual processor without much work? What are some of the common problems migrating software from sigle to dual core machines?
Thanks.
Jinma,
We’ve been running our software on single (PC 104 boards) and dual core (PC’s) for years and never noticed any difference (we run same code on both machines).
I believe that with 6.3.2 (we use 6.3 SP3) that unless you enable symetric multiprocessor support that QNX just uses a single core and hence there is no difference between single and dual core.
Tim
In that case, would the OS utilize both core or just one core? I was running 3Ghz single core but moving to to 1.8Ghz dual core, can I expect same performance or better?
Thanks
Unless you use InterruptDisable() the code will work just fine. If you rely on FIFO scheduling to create critical section, you are screwed.
If you are running on a 3Ghz single core and moving to 1.8 dual ( let`s forget about differences in processor architecture), unless your design is highly parallel, it will be almost half as slow, reflecting reduction in CPU clock. A single thread is not divided amongst the cores, you have to have multiple threads running concurrently to get the benifit of multiple cpu/core.
got it, so let me summary my understanding:
If I just use procnto on multicore system, I don’t have to worry about anything because it will just use one core, which means I can lose performance depending on the CPU speed (assuming all others are same)
If I use procnto-smp then I have to use InterruptLock() and worry about FIFO scheduling and use BMP if I don’t want to change my code. What about clockcycles()? Is there other function() calls that I have to becareful?
Yeah that’s correct.
The main issue with multi-core is that things really run in parallel now. So if you think this causes trouble, you can use BMP (very simple, from command line) to make sure your application only run on one core. Leave all OS services as is, they will use any free core then. This alone already will give you a good performance improvement. Later you can step by step allow your processes to run on any available core and test if it causes problems.
It’s not only FIFO scheduling that may be in an issue. If you use priority levels to exclude resource access, this may become a problem. E.g. if you have thread A on prio 10 accessing a resource, and thread B on prio 20 accessing the same resource, you could be sure that on single CPU, if thread B runs, it owns the resource because thread A would not access it while thread B runs. But with two CPU cores, you can have thread B running on prio 20 on Core0 and thread A running at prio 10 on Core1, both accessing the same resource. Bang! So in that case, use BMP to bind this process (its threads) to Core0, so they will not run at the same time. OR, make clean code by using Mutex protection to sync the access to the resource (which you should have done anyway ).
On the question of performance, assuming all your code is Multi-Core safe, the difference is not easy to predict. To begin with most systems are not cpu bound at all. There are other interactions that complicate the matter. Consider a 2.0 processor scheduling two threads vs. two 1.0 processors running one thread each. One would think it would be an even race, but if the processor cache gets filled, the 2.0 processor will be constantly refilling it, whereas the 1.0 processors will not need to. On the other hand, insert a very occasional third thread in the multi-core machine. This can cause the two other threads to have to switch core, requiring a complete cache dump.
I think the best argument for multi-core on a QNX system is that interrupt latency will always be kept to a minimum.
appreciate all the input, thanks
It can get even uglier, depending on the model of processor, certain cores share cache, while other dont. Plus you have cache sizes that can make a big difference. Its gotten so complicated that IMHO it`s now even worth spending energy trying to figure it out 
I would agree Mario, or rather I think the only way to figure it out is to do a statistically valid test. In other words, run your software and see how long it takes. Even this may not tell you much, but it will tell you if the processor(s) are fast enough for what you want to do.
The IDE system profiler is an awesome tools to figure out exactly what is going on. In my case turns out that thread migration didn`t hurt performance as much as I was expecting, even when migrating from processor to processor ( not core to core )