slow gcc

Is there any reason why gcc compiles slowly with qnx? I’m finding that a 450MHz linux machine can compile significantly faster than a 1.8GHz qnx 6.2 machine…
It’s not a problem, I’m just curious…

Try do a “ln -sP /x86/usr/bin/ntox86-gcc /usr/bin/gcc”, see if that
helps you.

I suspect it has to do with the fact that qnx’s disk io is much slower than linux’s. If you watch the CPU meter in the shelf, you will see that the CPU is not what is making the difference. QSS recently sped up the disk io quite a bit, but it still has a way to go. You also may want to look at what mode your eide controller is running in (assuming that is what your disk is). You may not be able to fix it, but it should account for some of the performance loss.

The ln -s didn’t seem to help - its still slow. The CPU in shelf is always up to 100 percent while compiling… but this could well be due to devb-eide…

maybe you should try “spin” (available on the 3rd party CD, or QNX online repository) to find out who to blame :slight_smile:
Based on previous talkings with cdm, I suspect fs-pkg may also be a “contributing” factor.

If the CPU is at 100% all the time when doing compiles then it is likely that your IDE chipset is not supported in UDMA mode by devb-eide. This really slows down disk access.

Where are you doing the builds from? Your /home directory? /usr/src?

Other then the support of your IDE chipset in more then DMA2 mode, fs-pkg is the other culrpit of build speeds. When doing the compile run a “hogs -n -%1” and see where the time is being lost. You will see that fs-pkg is eating a decent amount of CPU time.

Which brings the interesting question is the fs-pkg feature really worth cost in performance. I don’t think it servers the customer.

I don’t think so either, and hopefully the bugs/issues with it will be fixed.

Yes, I think fs-pkg is the problem - hog reveals it taking over 80 percent of cpu.

Doing the following:

BASH:>>> cat > hi.c
#include <stdio.h>
int main(void){
printf(“Hello world\n”);
return 0;
BASH:>>> gcc hi.c -o hi

takes 5 seconds for the compile… and fs-pkg takes most of this… what is it actually doing?

Oh - forgot to mention - my chipset does support udma (intel D845GRGL)

5 seconds wow, that seems excessive to me. Fs-pkg does add overhead but that sounds like to much. Don’t have any idea to offer sorry.Basicaly what fs-pkg does is present a virtual file system that map files to specific version. Hence in theory you could have version 6.0, 6.1, 6.2, … and switch between them or have the x86 version and PowerPC version on the same HD and move the HD from machine to machine. For example /bin/ls is physically located deep in a directory under /pkgs. I personnaly know of NO one that uses these feature. If some people do benefit from it, it’s a shame that most QNX6 user have to pay the price in performance for the need of the few. Unless of course the few has lots of money ;-)

Not that excessive I think - my 14MHz amiga used to take almost that long!!! ;-)
I’m finding that qnx seems to be slow at most things. e.g. if I type “ech” then on the command line, it takes about a second for completion (ie echo) to complete… Also if I use - it takes about 2 seconds for qnx to switch applications… so in general it seems a lot slower then linux…
So I suspect that its just a general qnx lack of efficiency type thing…


agb32 - just because your CHIPSET supports it doesn’t mean we support your chipset. :slight_smile: You can check the output of sloginfo right after you boot your machine to see what DMA/UDMA modes are being used.

In fact, it isn’t about QNX being inefficent. On my dual MP1500 box, Linux is a DOG. The UI is slow, things are slow to react. I cannot stand it. And yes I have the pre-emptable kernel patch and yes I have the frequency patch, etc, etc. Doesn’t matter, the Linux kernel is slow compared to QNX. It beats us on disk access due to it’s buffer cache, but man, on my workstation there is so much more then simply hitting the disc to have an enjoyable work environment.

All of your troubles relate to fs-pkg.

I can fix the problem you see with alt-tab, just get the wmswitch.bz2 from, decompress it with bzip2 and copy it into /usr/photon/bin, log out and log back in.

The issue you are seeing with the completion on the command line just shows that you do not have a chipset that supports UDMA.

If you want to see things run a little faster compile time wise, try using qcc instead of gcc. The way gcc is installed forces fs-pkg into a brain-dead behavior. If you look you will see that gcc is a symlink, which means that fs-pkg will get the request for the gcc file, look for it and not find it and then pass the request to the next resource manager. Unfortunatly fs-pkg doesn’t keep a miss-cache, so it does a complete search each and every time. The qcc binary isn’t a symlink and is managed by fs-pkg so it doesn’t suffer from this problem.

You can use this trick when building stuff with ./configure script as well…

CC=qcc CXX=QCC ./configure

…is MUCH faster. And now for some times…

–cdm@bigbox–> time gcc hi.c -o hi
real 0m1.793s
user 0m0.037s
sys 0m0.010s
–cdm@bigbox–> time qcc hi.c -o hi
real 0m0.502s
user 0m0.039s
sys 0m0.008s

thanks - thats been a big improvement… though means I don’t have time to think while compiling anymore!!! :slight_smile:
The sloginfo says udma -1 for my harddrives, so presumably this means no udma as you said…

If I repeat this a few times on my PC, the difference is only the first time that big.
Afterwards it is much smaller.
I’m suspecting disk caching effects.

It depends on how many packages you have installed, etc.

This may be because of sticky bit set on the executable. If it is set, then for the first time (per session) you run the command, it gets hoarded in the swap space and hence successive executions will be faster.

I am not sure whether Neutrino reads the sticky bit on files.