Diffrent speed in UX and Linux

[sangvv]

Hi all,

I have small project have two thread.
Thread one put message to queue (lock – put – unlock)
Thread two get message from queue (lock – get – unlock)

This project run in Linux (build with GCC in Netbean) run faster than run in HP UX (buil with aCC in Netbean) six times.

Show Can you explain it for me, or have you a tip code in HP UX run faster as Linux.

[kbw]

What hardware?

[sangvv]

In Linux I have run on:
Linux 2.6.32-300.3.1.el6uek.x86_64 #1 SMP Fri Dec 9 18:57:35 EST 2011 x86_64 x86_64 x86_64 GNU/Linux

In Hp UX i hav run on:

HP-UX B.11.31 U ia64 3494992138 unlimited-user license

Regards.

[kbw]

That's software. Again, what hardware? Are they real boxes or virtual boxes ...

[Zaita]

This could come down to a million different things.
1. Hardware
2. Compiler
3. Processor (ia64 vs x64)
4. How busy the system was at the time
5. Operating System

[UldisK]

6. default/and compiler optimizations

[rapidcoder]

Thread one put message to queue (lock – put – unlock)

To be honest, that doesn't sound very efficient right from the start... So probably both runs are terribly slow.

Anyway, except hardware, probably the things that matter in this example most are:
1. quality of your OS process scheduler
2. quality of memory allocator in your C runtime libraries

[Zaita]

@rapidcoder care to explain why that sounds inefficient? That gives an indication that he is locking only the minimal amount of code required to manipulate the container.

[rapidcoder]

Because he is locking the container. By definition locking means "slow" and "doesn't scale". If he want it to be fast, it must not use locking at all.

And don't judge performance by "minimal amount of code", please... Any amount of locking hurts performance more than switching to Python...

[Zaita]

@rapidcoder of course he is locking access to the container, it's multi-threaded. Without locking he is subject to race conditions or unexpected behavior. Unless he is using only atomic operations (highly unlikely)

[rapidcoder]

@rapidcoder of course he is locking access to the container, it's multi-threaded. Without locking he is subject to race conditions or unexpected behavior.

Yep, and that is slow. The faster is to use atomic operations or better use an immutable queue.