memory performance

hi!
im in a middle of a research project that compare OS’s .
i found out that the memory management at QNX (RTP 6.0) is worse than
the Linux Suse (7.0) in a large factor (up to 10 times worse). This fact
came as a surprise to me :slight_smile:.

The same test run at both OS’s under the same computer.
The tests were memory allocations : big vector containing pointers .
First i allocate the same amount of memory chunks to all the pointers.
Then i release all memory chunks allocated at even places, and
immediately allocating a bigger chunk to each pointer (trying to
generate a significant external fragmentation).
Then i do the same thing to the pointers at the odd places (with bigger
chunks of memory).

can anyone tell me what are the memory management implementations done
at both OS’s ??
I would like to know about the causes for this.
thanks in advance.
omer.

This sounds very inline with my own experiments. I did that long time
ago and malloc() performance was up to 20 times worse than in QNX4 :wink:

  • igor

Omer Yehezkely wrote:

hi!
im in a middle of a research project that compare OS’s .
i found out that the memory management at QNX (RTP 6.0) is worse than
the Linux Suse (7.0) in a large factor (up to 10 times worse). This fact
came as a surprise to me > :slight_smile:> .

The same test run at both OS’s under the same computer.
The tests were memory allocations : big vector containing pointers .
First i allocate the same amount of memory chunks to all the pointers.
Then i release all memory chunks allocated at even places, and
immediately allocating a bigger chunk to each pointer (trying to
generate a significant external fragmentation).
Then i do the same thing to the pointers at the odd places (with bigger
chunks of memory).

can anyone tell me what are the memory management implementations done
at both OS’s ??
I would like to know about the causes for this.
thanks in advance.
omer.

Omer Yehezkely <omery@actcom.co.il> wrote:
: hi!
: im in a middle of a research project that compare OS’s .
: i found out that the memory management at QNX (RTP 6.0) is worse than
: the Linux Suse (7.0) in a large factor (up to 10 times worse). This fact
: came as a surprise to me :slight_smile:.

: The same test run at both OS’s under the same computer.
: The tests were memory allocations : big vector containing pointers .
: First i allocate the same amount of memory chunks to all the pointers.
: Then i release all memory chunks allocated at even places, and
: immediately allocating a bigger chunk to each pointer (trying to
: generate a significant external fragmentation).
: Then i do the same thing to the pointers at the odd places (with bigger
: chunks of memory).

: can anyone tell me what are the memory management implementations done
: at both OS’s ??
: I would like to know about the causes for this.
: thanks in advance.

GNU/Linux memory management allocator is based on Doug’s lea public
allocator. It has a lot of buckets.

QNX/Neutrino is trying to be less wastefull in term of memory.

On a desktop like GNU/Linux, Doug lea’s allocator
uses a few Megs here and there to be efficient, is a trade-off that
most desktop users can live with happily. If they need a few more
simms it’s not a big deal.

Again it is a trade off. For example when I start Mozilla on GNU/Linux
it starts with ~20 Megs and more. On QNX/NTO, it starts with ~10 Megs.
Meaning the memory footpring for Mozilla on Neutrino is smaller.

The allocator on Neutrino is small and relatively fast for its purpose,
but applications with different memory patterns may need a different scheme.

\

alain

So what about having the choice on QNX RTP - high efficiency for desktop
people and low footprint for embedded targets?
Markus

“Alain Magloire” <alain@qnx.com> wrote in message
news:9k6vrq$6cs$1@nntp.qnx.com

Omer Yehezkely <> omery@actcom.co.il> > wrote:
: hi!
: im in a middle of a research project that compare OS’s .
: i found out that the memory management at QNX (RTP 6.0) is worse than
: the Linux Suse (7.0) in a large factor (up to 10 times worse). This fact
: came as a surprise to me > :slight_smile:> .

: The same test run at both OS’s under the same computer.
: The tests were memory allocations : big vector containing pointers .
: First i allocate the same amount of memory chunks to all the pointers.
: Then i release all memory chunks allocated at even places, and
: immediately allocating a bigger chunk to each pointer (trying to
: generate a significant external fragmentation).
: Then i do the same thing to the pointers at the odd places (with bigger
: chunks of memory).

: can anyone tell me what are the memory management implementations done
: at both OS’s ??
: I would like to know about the causes for this.
: thanks in advance.

GNU/Linux memory management allocator is based on Doug’s lea public
allocator. It has a lot of buckets.

QNX/Neutrino is trying to be less wastefull in term of memory.

On a desktop like GNU/Linux, Doug lea’s allocator
uses a few Megs here and there to be efficient, is a trade-off that
most desktop users can live with happily. If they need a few more
simms it’s not a big deal.

Again it is a trade off. For example when I start Mozilla on GNU/Linux
it starts with ~20 Megs and more. On QNX/NTO, it starts with ~10 Megs.
Meaning the memory footpring for Mozilla on Neutrino is smaller.

The allocator on Neutrino is small and relatively fast for its purpose,
but applications with different memory patterns may need a different
scheme.

\

alain

Markus Loffler a écrit :

So what about having the choice on QNX RTP - high efficiency for desktop
people and low footprint for embedded targets?
Markus

“Alain Magloire” <> alain@qnx.com> > wrote in message
news:9k6vrq$6cs$> 1@nntp.qnx.com> …
Omer Yehezkely <> omery@actcom.co.il> > wrote:
: hi!
: im in a middle of a research project that compare OS’s .
: i found out that the memory management at QNX (RTP 6.0) is worse than
: the Linux Suse (7.0) in a large factor (up to 10 times worse). This fact
: came as a surprise to me > :slight_smile:> .

: The same test run at both OS’s under the same computer.
: The tests were memory allocations : big vector containing pointers .
: First i allocate the same amount of memory chunks to all the pointers.
: Then i release all memory chunks allocated at even places, and
: immediately allocating a bigger chunk to each pointer (trying to
: generate a significant external fragmentation).
: Then i do the same thing to the pointers at the odd places (with bigger
: chunks of memory).

: can anyone tell me what are the memory management implementations done
: at both OS’s ??
: I would like to know about the causes for this.
: thanks in advance.

GNU/Linux memory management allocator is based on Doug’s lea public
allocator. It has a lot of buckets.

QNX/Neutrino is trying to be less wastefull in term of memory.

On a desktop like GNU/Linux, Doug lea’s allocator
uses a few Megs here and there to be efficient, is a trade-off that
most desktop users can live with happily. If they need a few more
simms it’s not a big deal.

Again it is a trade off. For example when I start Mozilla on GNU/Linux
it starts with ~20 Megs and more. On QNX/NTO, it starts with ~10 Megs.
Meaning the memory footpring for Mozilla on Neutrino is smaller.

The allocator on Neutrino is small and relatively fast for its purpose,
but applications with different memory patterns may need a different
scheme.

\

alain

I suppose that QNX is not designed to run large desktop application with huge
memory requirement. It’s difficult to do everything, the system could waste its
time to figure out what is the best choice for each application or to test all
the parameters.

Alain.

Yes Bill, but the question here is rather desktop environment vs. embedded
environment. I think you should somehow have the choice which memory
algorithm to use. I disagree with Alain that QNX RTP was not designed to run
large desktop applications with huge memory requirements. Just look at our
most important tool, the C compiler, and it’s memory requirements. Also look
at the fact that RTP supports virtual memory. Factor 10 slower, that’s a
significant difference. It would be nice to have applications like GNU C
running faster.
Markus


“Bill Caroselli (Q-TPS)” <qtps@earthlink.net> wrote in message
news:9k94td$hia$1@inn.qnx.com

In a real-time environment memory allocation/deallocation is always going
to
slow you down. It is best to try to pre-allocate whatever memory you
think
you might need and keep your own table of what is currently in use and
what
is free. It isn’t all that hard.

Bill Caroselli

“Alain Bonnefoy” <> alain.bonnefoy@icbt.com> > wrote in message
news:> 3B67F152.4B638126@icbt.com> …
Markus Loffler a écrit :

So what about having the choice on QNX RTP - high efficiency for
desktop
people and low footprint for embedded targets?
Markus

“Alain Magloire” <> alain@qnx.com> > wrote in message
news:9k6vrq$6cs$> 1@nntp.qnx.com> …
Omer Yehezkely <> omery@actcom.co.il> > wrote:
: hi!
: im in a middle of a research project that compare OS’s .
: i found out that the memory management at QNX (RTP 6.0) is worse
than
: the Linux Suse (7.0) in a large factor (up to 10 times worse).
This
fact
: came as a surprise to me > :slight_smile:> .

: The same test run at both OS’s under the same computer.
: The tests were memory allocations : big vector containing pointers

: First i allocate the same amount of memory chunks to all the
pointers.
: Then i release all memory chunks allocated at even places, and
: immediately allocating a bigger chunk to each pointer (trying to
: generate a significant external fragmentation).
: Then i do the same thing to the pointers at the odd places (with
bigger
: chunks of memory).

: can anyone tell me what are the memory management implementations
done
: at both OS’s ??
: I would like to know about the causes for this.
: thanks in advance.

GNU/Linux memory management allocator is based on Doug’s lea public
allocator. It has a lot of buckets.

QNX/Neutrino is trying to be less wastefull in term of memory.

On a desktop like GNU/Linux, Doug lea’s allocator
uses a few Megs here and there to be efficient, is a trade-off that
most desktop users can live with happily. If they need a few more
simms it’s not a big deal.

Again it is a trade off. For example when I start Mozilla on
GNU/Linux
it starts with ~20 Megs and more. On QNX/NTO, it starts with ~10
Megs.
Meaning the memory footpring for Mozilla on Neutrino is smaller.

The allocator on Neutrino is small and relatively fast for its
purpose,
but applications with different memory patterns may need a different
scheme.

\

alain

I suppose that QNX is not designed to run large desktop application with
huge
memory requirement. It’s difficult to do everything, the system could
waste its
time to figure out what is the best choice for each application or to
test
all
the parameters.

Alain.
\

The fact that QNX4 is also 10 times faster does not help the perceptions as
well :wink:

  • igor

“Markus Loffler” <loffler@ces.clemson.edu> wrote in message
news:9k996k$k3s$1@inn.qnx.com

Yes Bill, but the question here is rather desktop environment vs. embedded
environment. I think you should somehow have the choice which memory
algorithm to use. I disagree with Alain that QNX RTP was not designed to
run
large desktop applications with huge memory requirements. Just look at our
most important tool, the C compiler, and it’s memory requirements. Also
look
at the fact that RTP supports virtual memory. Factor 10 slower, that’s a
significant difference. It would be nice to have applications like GNU C
running faster.
Markus


“Bill Caroselli (Q-TPS)” <> qtps@earthlink.net> > wrote in message
news:9k94td$hia$> 1@inn.qnx.com> …
In a real-time environment memory allocation/deallocation is always
going
to
slow you down. It is best to try to pre-allocate whatever memory you
think
you might need and keep your own table of what is currently in use and
what
is free. It isn’t all that hard.

Bill Caroselli

“Alain Bonnefoy” <> alain.bonnefoy@icbt.com> > wrote in message
news:> 3B67F152.4B638126@icbt.com> …
Markus Loffler a écrit :

So what about having the choice on QNX RTP - high efficiency for
desktop
people and low footprint for embedded targets?
Markus

“Alain Magloire” <> alain@qnx.com> > wrote in message
news:9k6vrq$6cs$> 1@nntp.qnx.com> …
Omer Yehezkely <> omery@actcom.co.il> > wrote:
: hi!
: im in a middle of a research project that compare OS’s .
: i found out that the memory management at QNX (RTP 6.0) is worse
than
: the Linux Suse (7.0) in a large factor (up to 10 times worse).
This
fact
: came as a surprise to me > :slight_smile:> .

: The same test run at both OS’s under the same computer.
: The tests were memory allocations : big vector containing
pointers
.
: First i allocate the same amount of memory chunks to all the
pointers.
: Then i release all memory chunks allocated at even places, and
: immediately allocating a bigger chunk to each pointer (trying to
: generate a significant external fragmentation).
: Then i do the same thing to the pointers at the odd places (with
bigger
: chunks of memory).

: can anyone tell me what are the memory management
implementations
done
: at both OS’s ??
: I would like to know about the causes for this.
: thanks in advance.

GNU/Linux memory management allocator is based on Doug’s lea
public
allocator. It has a lot of buckets.

QNX/Neutrino is trying to be less wastefull in term of memory.

On a desktop like GNU/Linux, Doug lea’s allocator
uses a few Megs here and there to be efficient, is a trade-off
that
most desktop users can live with happily. If they need a few more
simms it’s not a big deal.

Again it is a trade off. For example when I start Mozilla on
GNU/Linux
it starts with ~20 Megs and more. On QNX/NTO, it starts with ~10
Megs.
Meaning the memory footpring for Mozilla on Neutrino is smaller.

The allocator on Neutrino is small and relatively fast for its
purpose,
but applications with different memory patterns may need a
different
scheme.

\

alain

I suppose that QNX is not designed to run large desktop application
with
huge
memory requirement. It’s difficult to do everything, the system could
waste its
time to figure out what is the best choice for each application or to
test
all
the parameters.

Alain.


\

I am sure QSSL will get around to having an optional allocator at some
point (after paging is working well), I just don’t think it is (or
should be) a high priority at this point (how much of a big desktop
applications time is spent in the memory allocator - I would guess that
it is not much as a percentage of application lifetime CPU utilization).

-----Original Message-----
From: Markus Loffler [mailto:loffler@ces.clemson.edu]
Posted At: Tuesday, July 31, 2001 1:38 PM
Posted To: os
Conversation: memory performance
Subject: Re: memory performance


So what about having the choice on QNX RTP - high efficiency for desktop
people and low footprint for embedded targets?
Markus

“Alain Magloire” <alain@qnx.com> wrote in message
news:9k6vrq$6cs$1@nntp.qnx.com

Omer Yehezkely <> omery@actcom.co.il> > wrote:
: hi!
: im in a middle of a research project that compare OS’s .
: i found out that the memory management at QNX (RTP 6.0) is worse
than
: the Linux Suse (7.0) in a large factor (up to 10 times worse). This
fact
: came as a surprise to me > :slight_smile:> .

: The same test run at both OS’s under the same computer.
: The tests were memory allocations : big vector containing pointers .
: First i allocate the same amount of memory chunks to all the
pointers.
: Then i release all memory chunks allocated at even places, and
: immediately allocating a bigger chunk to each pointer (trying to
: generate a significant external fragmentation).
: Then i do the same thing to the pointers at the odd places (with
bigger
: chunks of memory).

: can anyone tell me what are the memory management implementations
done
: at both OS’s ??
: I would like to know about the causes for this.
: thanks in advance.

GNU/Linux memory management allocator is based on Doug’s lea public
allocator. It has a lot of buckets.

QNX/Neutrino is trying to be less wastefull in term of memory.

On a desktop like GNU/Linux, Doug lea’s allocator
uses a few Megs here and there to be efficient, is a trade-off that
most desktop users can live with happily. If they need a few more
simms it’s not a big deal.

Again it is a trade off. For example when I start Mozilla on
GNU/Linux
it starts with ~20 Megs and more. On QNX/NTO, it starts with ~10
Megs.
Meaning the memory footpring for Mozilla on Neutrino is smaller.

The allocator on Neutrino is small and relatively fast for its
purpose,
but applications with different memory patterns may need a different
scheme.

\

alain

Markus Loffler <loffler@ces.clemson.edu> wrote:
: Yes Bill, but the question here is rather desktop environment vs. embedded
: environment. I think you should somehow have the choice which memory
: algorithm to use.

I’m not aware of any work on this area right now.
It certainly does not hurt to push :sunglasses:.

: I disagree with Alain that QNX RTP was not designed to run
: large desktop applications with huge memory requirements. Just look at our

I’ve said no such thing.
QNX RTP is certainly able of running large desktop applications, XFree86
and Mozilla are proof :sunglasses:.

The tradeoff made on the allocator was bias toward low memory footprint.
Obviously the allocator scheme will not be efficient for all memory
patterns of applications.

For example, a web browser doing agressive caching (maintaining
images etc …), in this case they(web browser dev.) are better of fine
tuning there own allocator or grab one from the net wich will make better use
of the memory usage. In this case, doug lea’s allocator will
probably have a bigger footprint but may be better in term of fragmentation
and efficiency.

: most important tool, the C compiler, and it’s memory requirements. Also look
: at the fact that RTP supports virtual memory. Factor 10 slower, that’s a
: significant difference. It would be nice to have applications like GNU C
: running faster.

I’m not sure of what you are taking here: Demand paging/Swapping ?
which is a different issue.


alain

Igor Kovalenko <kovalenko@home.com> wrote:
: The fact that QNX4 is also 10 times faster does not help the perceptions as
: well :wink:

Another issue, lets not go this path for now.
Some tradeoffs were made.

Do you feel RTP 6.1.0 being that slow that it is unusable ?
There were a lot of improvements.

In a real-time environment memory allocation/deallocation is always going to
slow you down. It is best to try to pre-allocate whatever memory you think
you might need and keep your own table of what is currently in use and what
is free. It isn’t all that hard.

Bill Caroselli

“Alain Bonnefoy” <alain.bonnefoy@icbt.com> wrote in message
news:3B67F152.4B638126@icbt.com

Markus Loffler a écrit :

So what about having the choice on QNX RTP - high efficiency for desktop
people and low footprint for embedded targets?
Markus

“Alain Magloire” <> alain@qnx.com> > wrote in message
news:9k6vrq$6cs$> 1@nntp.qnx.com> …
Omer Yehezkely <> omery@actcom.co.il> > wrote:
: hi!
: im in a middle of a research project that compare OS’s .
: i found out that the memory management at QNX (RTP 6.0) is worse
than
: the Linux Suse (7.0) in a large factor (up to 10 times worse). This
fact
: came as a surprise to me > :slight_smile:> .

: The same test run at both OS’s under the same computer.
: The tests were memory allocations : big vector containing pointers .
: First i allocate the same amount of memory chunks to all the
pointers.
: Then i release all memory chunks allocated at even places, and
: immediately allocating a bigger chunk to each pointer (trying to
: generate a significant external fragmentation).
: Then i do the same thing to the pointers at the odd places (with
bigger
: chunks of memory).

: can anyone tell me what are the memory management implementations
done
: at both OS’s ??
: I would like to know about the causes for this.
: thanks in advance.

GNU/Linux memory management allocator is based on Doug’s lea public
allocator. It has a lot of buckets.

QNX/Neutrino is trying to be less wastefull in term of memory.

On a desktop like GNU/Linux, Doug lea’s allocator
uses a few Megs here and there to be efficient, is a trade-off that
most desktop users can live with happily. If they need a few more
simms it’s not a big deal.

Again it is a trade off. For example when I start Mozilla on
GNU/Linux
it starts with ~20 Megs and more. On QNX/NTO, it starts with ~10
Megs.
Meaning the memory footpring for Mozilla on Neutrino is smaller.

The allocator on Neutrino is small and relatively fast for its
purpose,
but applications with different memory patterns may need a different
scheme.

\

alain

I suppose that QNX is not designed to run large desktop application with
huge
memory requirement. It’s difficult to do everything, the system could
waste its
time to figure out what is the best choice for each application or to test
all
the parameters.

Alain.

Agreed absolutely!

Especially the way RPT make use of shared libs. It should be an easy thing
to drop in an memory management algorithm shared library that
behaves/performs as desired. I think this was spoken of as much as 6 months
ago.

My comment was a recommendation to Alain on how to best deal with the RPT
environment as it currently exists.

Bill Caroselli

“Markus Loffler” <loffler@ces.clemson.edu> wrote in message
news:9k996k$k3s$1@inn.qnx.com

Yes Bill, but the question here is rather desktop environment vs. embedded
environment. I think you should somehow have the choice which memory
algorithm to use. I disagree with Alain that QNX RTP was not designed to
run
large desktop applications with huge memory requirements. Just look at our
most important tool, the C compiler, and it’s memory requirements. Also
look
at the fact that RTP supports virtual memory. Factor 10 slower, that’s a
significant difference. It would be nice to have applications like GNU C
running faster.
Markus

Besides of my OS Comparison project I’m also involved in a project of
building a RAM-based DB using QNX RTP and it seems to me that the allocator
algorithm in 6.1 is worse than 6.0 when many (large) allocations are needed.

I compiled the same code under both versions and the 6.1 performs badly when
compared to 6.0. - The memory allocation became the bottleneck of the database.
Sometimes it takes few minutes to complete memory allocations! - while it takes
few seconds for the same database to sort millions of records (as an example).

The 6.0 version did the same memory allocations job faster.

Adding Doug Lea’s algorithm to the database might be a solution, but it
wouldn’t be an elegant one. This kind of things should be performed at the OS
level, and if needed several options should be offered by the compiler/OS, while
the default might be the currently used allocator.

Thanks,

Omer.


P.S. Thank you all for the info.


Alain Magloire wrote:

Igor Kovalenko <> kovalenko@home.com> > wrote:
: The fact that QNX4 is also 10 times faster does not help the perceptions as
: well > :wink:

Another issue, lets not go this path for now.
Some tradeoffs were made.

Do you feel RTP 6.1.0 being that slow that it is unusable ?
There were a lot of improvements.

Omer Yehezkely <omery@actcom.co.il> wrote:
: Besides of my OS Comparison project I’m also involved in a project of
: building a RAM-based DB using QNX RTP and it seems to me that the allocator
: algorithm in 6.1 is worse than 6.0 when many (large) allocations are needed.

: I compiled the same code under both versions and the 6.1 performs badly when
: compared to 6.0. - The memory allocation became the bottleneck of the database.
: Sometimes it takes few minutes to complete memory allocations! - while it takes
: few seconds for the same database to sort millions of records (as an example).

: The 6.0 version did the same memory allocations job faster.

The only difference between 6.0 and 6.1 was the change of the free list
to be a FIFO instead of LIFO. May be you will want to dig a little deeper on
this, before pointing a the memory allocator.

: Adding Doug Lea’s algorithm to the database might be a solution, but it
: wouldn’t be an elegant one. This kind of things should be performed at the OS
: level, and if needed several options should be offered by the compiler/OS, while
: the default might be the currently used allocator.

Many specialised applications, especially databases, comes with there
own well-tuned allocator. There are many tradeoffs to be made, coalescing,
speed, footprint, suceptible to bursty usage etc … Especially on
applications like a DB where the memory pattern/model is
not at all similar to a utility program, DB implementors will usually fine
tune there allocator scheme to get the most.

Now it is behond me, why you find this … inelegant …
You are the developer of the DB and know the memory footprint and pattern
and can do the most clear decision of what type of allocator scheme to use.
Memory allocation is a big field, you may want to check out HOARD
an allocator optimize for SMP and threads, the speed numbers were impressive.

If we go to the other side of the pound(forget embedded), Oracle, for example
running on Solaris, comes with its allocator, certainly will not let such
and important task to a general purpose allocator that comes from libc.
Well … they also fine tune the kernel and replace the entire filesystem :sunglasses:

\

alain

Alain, you’re right wrt databases. However practical considerations
suggest that your current policy of making ‘embedded’ allocator the
default one does not serve you well.

Most people will get to know QNX by installing it on their desktop
first, that seems to be QSSL’s own goal. They wil play with it and if
they like it then there might be an embedded project. Now chances are
with allocator like current one they may simply find it slow which
won’t really inspire anyone to go ahead with embedded project. Keep in
mind that many of people will be shallow enough to not bother with
figuring the issue.

IMHO having a Doug Lea’s or another ‘sacrifice-memory-for-speed’
allocator as default for desktop version would be much more useful. When
and if people need to conserve memory on embedded systems, they will
switch to embedded allocator.

Botoom line, allocator for more common usage should be default one.
Unless you suggest that RTP free download is targeted directly to
embedded systems, the current allocator is simply unsuitable.

  • igor

Alain Magloire wrote:

Many specialised applications, especially databases, comes with there
own well-tuned allocator. There are many tradeoffs to be made, coalescing,
speed, footprint, suceptible to bursty usage etc … Especially on
applications like a DB where the memory pattern/model is
not at all similar to a utility program, DB implementors will usually fine
tune there allocator scheme to get the most.

Now it is behond me, why you find this … inelegant …
You are the developer of the DB and know the memory footprint and pattern
and can do the most clear decision of what type of allocator scheme to use.
Memory allocation is a big field, you may want to check out HOARD
an allocator optimize for SMP and threads, the speed numbers were impressive.

If we go to the other side of the pound(forget embedded), Oracle, for example
running on Solaris, comes with its allocator, certainly will not let such
and important task to a general purpose allocator that comes from libc.
Well … they also fine tune the kernel and replace the entire filesystem > :sunglasses:

\

alain

Couldn’t be better said
Markus

“Igor Kovalenko” <Igor.Kovalenko@motorola.com> wrote in message
news:3B69B5FB.1091970F@motorola.com

Alain, you’re right wrt databases. However practical considerations
suggest that your current policy of making ‘embedded’ allocator the
default one does not serve you well.

Most people will get to know QNX by installing it on their desktop
first, that seems to be QSSL’s own goal. They wil play with it and if
they like it then there might be an embedded project. Now chances are
with allocator like current one they may simply find it slow which
won’t really inspire anyone to go ahead with embedded project. Keep in
mind that many of people will be shallow enough to not bother with
figuring the issue.

IMHO having a Doug Lea’s or another ‘sacrifice-memory-for-speed’
allocator as default for desktop version would be much more useful. When
and if people need to conserve memory on embedded systems, they will
switch to embedded allocator.

Botoom line, allocator for more common usage should be default one.
Unless you suggest that RTP free download is targeted directly to
embedded systems, the current allocator is simply unsuitable.

  • igor

Alain Magloire wrote:

Many specialised applications, especially databases, comes with
there
own well-tuned allocator. There are many tradeoffs to be made,
coalescing,
speed, footprint, suceptible to bursty usage etc … Especially on
applications like a DB where the memory pattern/model is
not at all similar to a utility program, DB implementors will usually
fine
tune there allocator scheme to get the most.

Now it is behond me, why you find this … inelegant …
You are the developer of the DB and know the memory footprint and
pattern
and can do the most clear decision of what type of allocator scheme to
use.
Memory allocation is a big field, you may want to check out HOARD
an allocator optimize for SMP and threads, the speed numbers were
impressive.

If we go to the other side of the pound(forget embedded), Oracle, for
example
running on Solaris, comes with its allocator, certainly will not let
such
and important task to a general purpose allocator that comes from libc.
Well … they also fine tune the kernel and replace the entire filesystem
:sunglasses:

\

alain

Hello Omer

I was wondering if your company could use an experienced QNX programmer.
You may
have seen my posts in qdn.public.qnxjobs. I have over 14 years experience
working with QNX in several different industries.

In March 2001 I left a good job for what I thought would be a great job as
head of operations and software development for Sattel Global Networks.
Unfortunately I was not aware that the person whos place I was taking was
leaving for a good reason. In June they went out of business.

I have enclosed a copy of my resume in case you might be intersted. If you
are you can call me at 1-530-510-7292.

Sincerely
Bill Caroselli


“Omer Yehezkely” <omery@actcom.co.il> wrote in message
news:3B699EFD.B783DA53@actcom.co.il

Besides of my OS Comparison project I’m also involved in a project of
building a RAM-based DB using QNX RTP and it seems to me that the
allocator
algorithm in 6.1 is worse than 6.0 when many (large) allocations are
needed.

I compiled the same code under both versions and the 6.1 performs
badly when
compared to 6.0. - The memory allocation became the bottleneck of the
database.
Sometimes it takes few minutes to complete memory allocations! - while it
takes
few seconds for the same database to sort millions of records (as an
example).

The 6.0 version did the same memory allocations job faster.

Adding Doug Lea’s algorithm to the database might be a solution, but
it
wouldn’t be an elegant one. This kind of things should be performed at the
OS
level, and if needed several options should be offered by the compiler/OS,
while
the default might be the currently used allocator.

Thanks,

Omer.


P.S. Thank you all for the info.

begin 666 resume.doc
MT,\1X*&Q&N$/@`#`/[_"0`&```````````````! M````/0``````````$ ``/P````$```#^____`````#P```#_____________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M_______________________LI<$`60`)! ```!*_````````$ ``````! `` M"3L```X`8FIB:O-7\U<````````````````````````)!!8`'D8``)$]`0"1 M/0$`"3<```````````````````````````````````````#__P\````````` M``#__P\```````````#__P\``````````````````````%T``````)(````` M````D@```)(`````````D@````````"2`````````)(`````````D@```!0` M`````````````*8`````````I@````````"F`````````*8`````````I@`` M``P```"R````% ```*8`````````;0$``+8```#2`````````-(````````` MT@````````#2`````````-(`````````T@````````#2`````````-(````` M````,@$```(````T`0```````#0!````````- $````````T`0```````#0! M````````- $``"0````C`@``] $``!<$``!&````6 $``!4````````````` M````````````D@````````#2``````````````````````````````#2```` M`````-(`````````T@````````#2`````````%@!````````T@````````"2 M`````````)(`````````T@```````````````````-(`````````T@`````` M``#2`````````-(`````````T@````````#2`````````)(`````````T@`` M``````"2`````````-(`````````,@$````````````````````````````` MI@````````"F`````````)(`````````D@````````"2`````````)(````` M````T@`````````R`0```````-(```!@````T@```````````````````#(! M````````D@````````"2```````````````````````````````````````` M````````````````````````````````````````````,@$```````#2```` M`````,8````,````X*N??,D;P0&F`````````*8`````````T@`````````R M`0`````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M````````4F5S=6UE"U=I;&QI86T@0V%R;W-E;&QI"S0S,C @061E;'!H:2!! M=F4N#4QA<R!696=A<RP@3E8@(#@Y,3(P#5!H;VYE(#$M*#4S,"D@-3$P+3<R M.3(+12U-86EL("T@45104T!%87)T:$QI;FLN;F5T#0T-5$5#2$Y)0T%,(%-+ M24Q,4PL-22!H879E(&)E96X@=V]R:VEN9R!E>&-L=7-I=F5L>2!I;B!T:&4@ M44Y8(&5N=FER;VYM96YT(&9O<B Q-"!Y96%R<RX@22!H879E(&1E=F5L;W!E M9"!N=6UE<F]U<R!C;&EE;G0O<V5R=F5R(&%P<&QI8V%T:6]N<R!W:71H(')E M9'5N9&%N8WDL(&9A=6QT('1O;&5R86YC92!A;F0@875T;VUA=&EC(&UI<G)O M<FEN9RX@22!H879E(&1E=F5L;W!E9"!M86YY(&AA<F1W87)E(&1E=FEC92!D M<FEV97)S("AM=6QT:7!L92!A=61I;R!C87)D<R!I;F-L=61I;F<@4$-)+"!% M25-!(&%N9"!)4T$L($-$($IU:V4@0F]X97,@86YD('-P96-I86P@:6YP=70@ M9&5V:6-E<RD@86YD('-E=F5R86P@=F5R>2!H:6=H('-P965D($1A=&$@0F%S M92!-86YA9V5M96YT(%-Y<W1E;7,N($D@:&%V92!D979E;&]P960@;&EB<F%R M:65S(&]F('5S969U;"!R;W5T:6YE<R!I;F-L=61I;F<@;V)J96-T(&]R:65N M=&5D(&QI8G)A<FEE<RX@22!H879E('5S960@=FER='5A;&QY(&5V97)Y(&QO M=R!L979E;"!13E@@9F5A='5R92!I;F-L=61I;F<@;65M;W)Y(&UA;F%G96UE M;G0L('!R;V-E<W,@;6%N86=E;65N="P@=&EM92!M86YA9V5M96YT(&%N9"!4 M0U O25 @86YD(&YA=&EV92!13E@@;F5T=V]R:VEN9R!A<'!L:6-A=&EO;G,N M($D@:&%V92!U<V5D(&UA;GD@;V8@=&AE(&%D9"UO;B!P<F]D=6-T<R!F;W(@ M44Y8(&EN8VQU9&EN9R!0:&]T;VXL(%%.6"!7:6YD;W=S+"!40U O25 L(%9O M>6%G97(@86YD('1H92!7871C;VT@8V]M<&EL97)S(&%N9"!D96)U9V=E<G,N M#0U!="!T:&ES('!O:6YT($D@:&%V92!D86)B;&5D('=I=&@@44Y8DG,@4E10 M('!R;V1U8W0@8G5T(&AA=F4@;F]T(&AA9"!T:&4@;W!P;W)T=6YI='D@=&\@ M9&5V96QO<"!S;V9T=V%R92!P<F]F97-S:6]N86QL>2!F;W(@:70N("!)(&AA M=F4@<F5A9"!A;&P@;V8@=&AE('1E8VAN:6-A;"!D;V-U;65N=&%T:6]N(&]N M(%)44"!A;F0@<W1A>2!C=7)R96YT(&%N9"!A8W1I=F4@:6X@=&AE(%)44"!N M97=S9W)O=7!S+@L-#5=/4DL@15A015))14Y#10L-4V%T=&5L($=L;V)A;"!. M971W;W)K<R M(#(P,#$@=&\@,C P,0M#:&%T<W=O<G1H+"!#86QI9F]R;FEA M"T1I<F5C=&]R(&]F($]P97)A=&EO;G,@86YD(%-O9G1W87)E($1E=F5L;W!M M96YT"PM)('1O;VL@;W9E<B!A<R!D:7)E8W1O<B!O9B!O<&5R871I;VYS(&%N M9"!S96YI;W(@<V]F='=A<F4@87)C:&ET96-T('=H97)E('=E(&UA:6YT86EN M960@82!S871E;&QI=&4@=&5L97!H;VYY('-Y<W1E;2!T:&%T('=A<R!D979E M;&]P960@86YD('-O;&0@=&\@9&5V96QO<&EN9R!C;W5N=')I97,N("!792!A M<F4@86-T:79E;'D@96YG86=E9"!I;B!C;VYV97)T:6YG(&]U<B!S>7-T96T@ M9G)O;2!O;&1E<B!8+5=I;F1O=W,@=&5C:&YO;&]G>2!T;R!T:&4@;6]R92!F M;&5X:6)L92!A;F0@;&EG:'0@=V5I9VAT(%!H;W1O;BX@(%1H:7,@<')O:F5C M="!R96QI97,@:&5A=FEL>2!O;B!R96%L+71I;64@9&%T82UB87-E(&EN<75I M<FEE<R!T;R!C<F]S<R!C;VYN96-T('1E;&5P:&]N92!C86QL<R!A;F0@;F5T M=V]R:VEN9R!T;R!C;VYN96-T(&UU;'1I<&QE(&=E;V=R87!H:6-A;&QY(&1I M=F5R<V4@8V]M;75N:6-A=&EO;G,@97%U:7!M96YT+@T-4VEE<G)A($1E<VEG M;B!'<F]U<" M(#(P,# @=&\@,C P,0M,87,@5F5G87,L($YE=F%D80M396YI M;W(@1FER;7=A<F4@16YG:6YE97(-"U=O<FME9"!T;R!D979E;&]P(&QO='1E M<GD@9V%M92!C;VYT<F]L;&5R<R!F;W(@=&AE(&=A;6EN9R!I;F1U<W1R>2X@ M(%1H97-E(&-O;G1R;VQL97)S(&-O;6UU;FEC871E9"!W:71H(&%N9"!C;VYT M<F]L;&5D(&UA;GD@=FED96\@9V%M:6YG('1E<FUI;F%L<R H<VQO="!M86-H M:6YE<RDN("!4:&4@8V]N=')O;&QE<G,@<V5R=F5D(&%S(&AU8G,@=&\@=&AE M(&=A;6EN9R!T97)M:6YA;',@86YD('=E<F4@=7-E9"!T;R!C;VQL96-T(&%C M8V]U;G1I;F<@:6YF;W)M871I;VX@*&1O;&QA<G,@:6XL(&1O;&QA<G,@<&%I M9"!O=70L(&=A;65S('!L87EE9"DL('!L87EE<B!T<F%C:VEN9R!I;F9O<FUA M=&EO;B!A;F0@<F5P;W)T960@=&AI<R!I;F9O<FUA=&EO;B!B86-K('1O(&UA M:6YF<F%M92!C;VUP=71E<G,@=&AR;W5G:"!O=7(@;W=N('!R;W!R:65T87)Y M($E0('!R;W1O8V]L+B @5&AE(&-O;G1R;VQL97)S(&%L<V\@8V]M;75N:6-A M=&5D('1H<F]U9V@@25 @=&\@<')O9W)E<W-I=F4@8V]N=')O;&QE<G,@=&\@ M<&%R=&EC:7!A=&4@:6X@=VED92UA<F5A(&IA8VMP;W1S(&%N9"!T:')O=6=H M('-E<FEA;"!D979I8V4@9')I=F5R<R!T;R!C;VUM=6YI8V%T92!T;R!E>'1E M<FYA;"!J86-K<&]T('-I9VYS+B M+2!)(&1E=F5L;W!E9"!A;B!E<G)O<B]A M8W1I=FET>2!L;V=G:6YG('-Y<W1E;2!A;F0@<F5A;"UT:6UE(&1I<W!L87D@ M=&5C:&YI<75E<R!T:&%T(&AE;'!E9"!D:6%G;F]S92!N971W;W)K('!R;V)L M96US('1H870@=V5R92!P<F5V:6]U<VQY('5N=')A8VMA8FQE(&1U92!T;R!T M:&4@96UB961D960@;F%T=7)E(&]F('1H92!D979I8V4@*&YO(&AA<F0@9')I M=F4I+@T-42U44%,@0V]N=')A8W0@=&\@061V86YC960@4W1E<FEL:7IA=&EO M;B!0<F]D=6-T<R M(#$Y.3D+27)V:6YE+"!#86QI9F]R;FEA"T-O;G1R86-T M($-O;G-U;'1A;G0+"TD@9&ED(&EN:71I86P@9&5V96QO<&UE;G0@;V8@82!1 M3E@@<WES=&5M('1O(&%U=&]M871E('1H96ER(%-T97)R860@,C P(%-T97)I M;&EZ871I;VX@4')O8V5S<V]R(&9O<B!H;W-P:71A;"!E;G9I<F]N;65N=',N M(%-Y<W1E;2!I;F-L=61E9"!M=6QT:2UP;VEN="!A8V-E<W,@86YD(&-O;G1R M;VP@;V8@<W1E<FEL:7IA=&EO;B!P<F]C97-S;W(@=7-I;F<@=&]U8V@@<V-R M965N<R!U;F1E<B!P:&]T;VXN(%1H92!P<F]C97-S(&AA9"!T;R!A8V-U<F%T M96QY(&-O;G1R;VP@86YD(&UO;FET;W(@4D8@<&]W97(@96UI<W-I;VYS+"!A M:7(@<')E<W-U<F4L('!E<F-E;G1A9V4@;V8@:'ED<F]G96XM<&5R;WAI9&4@ M96UI<W-I;VX@86YD(&AE870@:6X@82!R96%L+71I;64@9F%S:&EO;B!T:')O M=6=H($$O1"!A;F0@1"]!(&1E=FEC97,N("!4:&ES('!R;VIE8W0@86QS;R!I M;F-L=61E9"!E9'5C871I;F<@=&AE($%34"!S=&%F9B!O;B!P<F]G<F%M;6EN M9R!I;B!T:&4@44Y8(&5N=FER;VYM96YT+@L+42U44%,@0V]N=')A8W0@=&\@ M5DE302 M(#$Y.3@@=&\@,3DY.0M386X@1G)A;F-I<V-O+"!#86QI9F]R;FEA M"T-O;G1R86-T($-O;G-U;'1A;G0+"U!R;W9I9&EN9R!C;VYT<F%C="!C;VYS M=6QT:6YG('1O(%9I<V$@8W)E9&ET(&-A<F1S+B!297-P;VYS:6)I;&ET:65S M(&EN8VQU9&5D('%U86QI9GEI;F<@82!S;V9T=V%R92!/4R!U<&=R861E(&9O M<B!9,DL@8V]M<&QI86YC92!A;F0@8V%T86QO9VEN9R!A;GD@:6YC;VYS:7-T M96YC:65S(&)E='=E96X@=&AE(&5X<&5C=&5D(&)E:&%V:6]R(&]F('1H92!O M;&1E<B!/4R!S;V9T=V%R92!B96EN9R!U<V5D(&%N9"!T:&4@;F5W97(@<V]F M='=A<F4@=&\@=VAI8V@@=&AE>2!W97)E('5P9W)A9&EN9RX+"U$M5%!3("T@ M,3DY."!T;R R,# P"U)E9&1I;F<L($-A;&EF;W)N:6$+1F]U;F1E9"!#;VYS M=6QT:6YG($9I<FT+"U$M5%!3('=A<R!F;W5N9&5D('1O('!R;W9I9&4@:&EG M:"!Q=6%L:71Y('1E8VAN:6-A;"!S=7!P;W)T(&9O<B!D979E;&]P97)S(&EN M('1H92!13E@@8V]M;75N:71Y+B!1+5104R!A;'-O('!R;W9I9&5S(&5D=6-A M=&EO;F%L('-E<G9I8V5S('1O(&-L:65N=',@=VES:&EN9R!T;R!T<F%I;B!T M:&5I<B!L;V-A;"!S=&%F9B!O;B!T:&4@8F5N969I=',@;V8@=7-I;F<@44Y8 M(&%N9"!H;W<@=&\@=&%K92!B97-T(&%D=F%N=&%G92!O9B!T:&4@9F5A='5R M97,@=&AA="!13E@@:&%S('1O(&]F9F5R+B!792!A;'-O('!R;W9I9&5D('1E M8VAN:6-A;"!S=7!P;W)T('1O(&UA;GD@;V8@=&AE(')A9&EO(&%N9"!45B!S M=&%T:6]N<R!F;W(@=&AE($%I<E1I;64@<')O9'5C="!T:&%T($]R8F%N(&%B M86YD;VYD960N("!4:&ES(&-O;G-U;'1I;F<@:7,@8V]N8W5R<F5N="!W:71H M(&1E=F5L;W!I;F<@<V5V97)A;"!N:6-H92!P<F]D=6-T<R!F;W(@=&AE(%%. M6"!C;VUM=6YI='DN( L-4&AI;&EP<R!$:6=I=&%L(%9I9&5O(%-Y<W1E;7,@ M+2 Q.3DX"T-A;7!B96QL+"!#86QI9F]R;FEA"U!R;VIE8W0@3&5A9&5R+"!$ M:6=I=&%L(%16($%U=&]M871I;VX@4WES=&5M<PL+4F5S96%R8V@@;F5W(&1I M9VET86P@=&5L979I<VEO;B!M=6QT:2UD871A("AI;G1E9W)A=&5D('9I9&5O M+"!A=61I;RP@96QE8W1R:6,@<')O9W)A;2!G=6EL9"P@(&-O;F1I=&EO;F%L M(&%C8V5S<RP@;W1H97(@9&%T82D@=')A;G-M:7-S:6]N('-P96-I9FEC871I M;VYS('1O(&EN=&5R9F%C92!W:71H('1H92!0:&EL:7!S('1E;&5V:7-I;VX@ M875T;VUA=&EO;B!S>7-T96TN(%)E<W!O;G-I8FEL:71I97,@:6YC;'5D92!T M<F%V96QI;F<@=&\@54LL('1O('-P96,@;W5T('1H92!P<F]J96-T+"!C;V]R M9&EN871I;F<@:&%R9'=A<F4@86YD('-O9G1W87)E(&1E=F5L;W!M96YT('=I M=&@@;75L=&EP;&4@=F5N9&]R<R!A;F0@:6YT97)F86-I;F<@=&\@;W5R('1E M;&5V:7-I;VX@875T;VUA=&EO;B!S>7-T96TN"PM/<F)A;B M(#$Y.38@=&\@ M,3DY. M386X@3&5A;F1R;RP@0V%L:69O<FYI80M#:&EE9B!3;V9T=V%R92!! M<F-H:71E8W0@;V8@075D:6\@1&5L:79E<GD@4')O9'5C=',+"T]R8F%N('!U M<F-H87-E9"!T:&4@1$13('!R;V1U8W0@;&EN92!F<F]M(%)A9&EO(%-Y<W1E M;7,@*%-E92!N97AT(&5N=')Y*2X@(%1H870@<V%L92!W87,@8V]N=&EN9V5N M="!O;B!M>2!S:6=N:6YG(&]N(&%S('-E;FEO<B!S;V9T=V%R92!A<F-H:71E M8W0@9F]R('1H92!P<F]J96-T+B!!="!/<F)A;B!W92!C;VUP;&5T96QY(')E M9&5S:6=N960@=&AE($=522!M86MI;F<@:70@9F%S=&5R(&%N9"!M;W)E(&QI M9VAT('=E:6=H="!A;F0@;6%K:6YG('1H92!N97<@<')O9'5C="!C86QL960@ M06ER5&EM92!L;V]K(&QI:V4@=&AE(&]T:&5R($]R8F%N(&9A;6EL>2!O9B!P M<F]D=6-T<RX@02!N97<@=6QT<F$M9F%S="!D871A(&)A<V4@=V%S(&1E<VEG M;F5D(&%N9"!A(&-O;7!L971E(&YE=R!S96-U<FET>2!S>7-T96TN(%1H92!M M:7)R;W)I;F<@<WES=&5M('=A<R!E;FAA;F-E9"!T;R!I;G1E;&QI9V5N=&QY M(&1E=&5R;6EN92!W:&%T(&1A=&$@;F5E9&5D('1O(&)E(&UI<G)O<F5D(&%N M9"!W:&5R92X@06QL(&1E=FEC92!D<FEV97)S('=E<F4@<F5W<FET=&5N('1O M(&)E(&UO<F4@969F:6-I96YT(&%N9"!I;F-L=61E('9E<F)O<V4@8G5T(&5F M9FEC:65N="!E<G)O<B!A;F0@86-T:79I='D@;&]G9VEN9RX@5V4@=V]R:V5D M(&]N(&EN=&5R;F%T:6]N86QI>FEN9R!A;&P@;V8@;W5R(%5)<RX@22!A;2!A M;'-O(')E<W!O;G-I8FQE(&9O<B!T<F%I;FEN9R!C=7-T;VUE<B!S=7!P;W)T M(&%N9"!T96-H;FEC86P@<W5P<&]R="!P96]P;&4@870@3W)B86X@86YD(&YE M=R!S;V9T=V%R92!D979E;&]P97)S+B!)(&%M(&%L<V\@=&AE('!R:6UA<GD@ M=&5C:&YI8V%L(&QI86ES;VX@9F]R('1H92!M87)K971I;F<@9&5P87)T;65N M="X+"U)A9&EO(%-Y<W1E;7,L($EN8RX@+2 Q.3DS('1O(#$Y.38+0G)I9&=E M<&]R="P@3DH+1&ER96-T;W(@;V8@4V]F='=A<F4@16YG:6YE97)I;F<+"T1E M<VEG;F5D(&%N9"!I;7!L96UE;G1E9"!A(&1I9VET86P@875D:6\@9&5L:79E M<GD@<WES=&5M("AC86QL960@1$13*2P@96YA8FQI;F<@<F%D:6\@<W1A=&EO M;G,@=&\@96YJ;WD@=&AE('%U86QI='D@;V8@9&EG:71A;"!A=61I;R!A;F0@ M=&AE(&-O;G9E;FEE;F-E(&]F(&9I;&4@<V5R=F5R('-T;W)A9V4N(%1H:7,@ M<WES=&5M(&EN=F]L=F5D('=R:71I;F<@;G5M97)O=7,@9&5V:6-E(&1R:79E M<G,@9F]R(&%U9&EO(&-A<F1S+"!30U-)(&1E=FEC97,L($-$(&IU:V4@8F]X M97,@86YD('-E=F5R86P@<F5M;W1E(&-O;G1R;VP@86YD(&-O;G1R;VQL:6YG M(&1E=FEC97,N($]R:6=I;F%L;'D@:&ER960@87,@82!C;VYS=6QT86YT+"!) M(&1E;&EV97)E9"!A('-Y<W1E;2!T:&%T('=A<R!D96UO;G-T<F%T960@870@ M82!N871I;VYA;"!T<F%D92!S:&]W(&EN(&IU<W0@=&AR964@;6]N=&AS+B!) M(&-O;W)D:6YA=&5D('1H92!E9F9O<G1S(&]F(&]T:&5R('-O9G1W87)E(&%N M9"!H87)D=V%R92!D979E;&]P97)S(&%N9"!S<&5C)V5D('-E=F5R86P@;F5W M(&AA<F1W87)E(&1E=FEC97,@:6YC;'5D:6YG(&$@4$-)(&UU;'1I+6-H86YN M96P@875D:6\@8V%R9"X@22!A;'-O(&EN<W1A;&QE9"!A;F0@8W5S=&]M(&-O M;F9I9W5R960@;6%N>2!S>7-T96US(&%T(')A9&EO('-T871I;VYS(&%C<F]S M<R!T:&4@8V]U;G1R>2X@02!S96-O;F0@<&AA<V4@;V8@=&AE('!R;VIE8W0@ M:6YC;'5D960@9&5V96QO<&EN9R!A($=522!I;G1E<F9A8V4@=&AA="!C;W5L M9"!R97!L86-E('1H92!R96UO=&4@8V]N=')O;"!H87)D=V%R92X@375L=&EP M;&4@:&%R9'=A<F4@86YD($=522!D979I8V5S(&-O=6QD(&)E('5S960@:6X@ M<&%R86QL96P@9F]R(&5A<VEE<B!C;VYT<F]L(&]F('1H92!S>7-T96TN(%1H M92!F:6YA;"!P:&%S92!I;F-L=61E9"!D979E;&]P:6YG('-A=&5L;&ET92!A M;F0@<')E+7!R;V=R86UM960@875T;VUA=&EO;B!F;W(@<F%D:6\@<W1A=&EO M;G,N($EN('1W;R!A;F0@82!H86QF('EE87)S('1H:7,@<')O9'5C="!W87,@ M<V]L9"!T;R!/<F)A;B H<V5E(&%B;W9E*2X@3VYE(&EN;F]V871I=F4@9F5A M='5R92!T:&%T($D@:6YC;W)P;W)A=&5D(&EN=&\@1$13('=A<R!F875L="!T M;VQE<F%N="]R961U;F1A;G0@<WES=&5M<R!W:71H(&%U=&]M871I8R!M:7)R M;W)I;F<N"PU&86ER;&5Y+41I<VMI;G-O;B!5;FEV97)S:71Y("T@,3DX-B!T M;R Q.3DY"TUA9&ES;VXL($Y*( M'=65S="!,96-T=7)E<@L+22!W87,@82!F M<F5Q=65N="!G=65S="!L96-T=7)E<B!A="!&1%4@9F]R(&9E;&QO=R!0875L M($ET<FDN("!,96-T=7)E<R!W97)E(&]N('=A>7,@=&AA="!C;VUP=71E<G,@ M87)E(&-H86YG:6YG(&]U<B!L:79E<R!A;F0@:&4@=V4@8V%N('5S92!T:&5M M(&]R(&9A;&P@8F5H:6YD+@T,"U!R;V9E<W-I;VYA;"!%>'!E<G0@5')A9&EN M9R!3>7-T96US+"!);F,N("T@,3DX,B!T;R Q.3DS"U!A<F%M=7,L($YE=R!* M97)S97D+5FEC92!0<F5S:61E;G0@;V8@3W!E<F%T:6]N<R!A;F0@4V]F='=A M<F4@1&5V96QO<&UE;G0+"U!%5%,@<V5L;',@82!S97)V:6-E('1O('1H92!P M<F]F97-S:6]N86P@:6YV97-T;65N="!C;VUM=6YI='D@=&AA="!C:&%R=',@ M<W1O8VMS+"!A;F%L>7IE<R!S=')E;F=T:',@86YD('=E86MN97-S97,L(&%N M9"!D96QI=F5R<R!R96%L+71I;64@=6YS;VQI8VET960@86QE<G0@;65S<V%G M97,@=&\@82!C=7-T;VUE<B!W:&5N979E<B!A;GD@<W1O8VL@;65E=',@:&ES M+VAE<B!P<F4M97-T86)L:7-H960@8W)I=&5R:6$N($EN(#$Y.#(@22!D979E M;&]P960@=&AA="!S>7-T96T@9F]R('1W;R!S=&]C:R!T<F%D97)S+B!/;F4@ M>65A<B!L871E<BP@22!C;VYV:6YC960@=&AE('1R861E<G,@=&\@;6%R:V5T M('1H870@<WES=&5M+B!&;W(@9F]U<B!Y96%R<R!W92!H860@82!G<F]W=&@@ M<F%T92!I;B!E>&-E<W,@;V8@,3 P)2!P97(@>65A<BX@26X@,3DX-B!T:&%T M('-Y<W1E;2!W87,@<V]L9"!T;R!A(&=R;W5P(&]F(&EN=F5S=&]R<R!F;W(@ M)#0L,# P+# P,"!I;B!C87-H(&%N9"!S96-U<FET:65S+@L+061M:6YI<W1R M871I=F4@<F5S<&]N<VEB:6QI=&EE<SH@4F5S<&]N<VEB;&4@9F]R('1H92!E M9F9I8VEE;G0@86YD(')E;&EA8FQE(&]P97)A=&EO;B!O9B!O=7(@1&%T82!# M96YT97(@86YD(&-O;6UU;FEC871I;VYS(&9A8VEL:71I97,N($D@96UP:&%S M:7IE('1E86T@=V]R:R!W:&5N(&AI<FEN9R!A;F0@=')A:6YI;F<@;7D@<')O M9W)A;6UI;F<L(&]P97)A=&EO;G,L(&-O;6UU;FEC871I;VYS+"!T96-H;FEC M86P@86YD(&9I96QD('-U<'!O<G0@<W1A9F8N"PM0<F]G<F%M;6EN9R!R97-P M;VYS:6)I;&ET:65S.B!$979E;&]P960@86YD(&EM<&QE;65N=&5D(&$@<F5A M;"UT:6UE('-T;V-K(&%N86QY<VES('-Y<W1E;2!F;W(@4$544RX@5&AI<R!I M;F-L=61E<R!D979E;&]P:6YG(&]U<B!O=VX@25-!32!W:&EC:"!I<R!C87!A M8FQE(&]F('!R;V-E<W-I;F<@-3 @=&\@,S P('1R861E<R!A;F0@<75O=&5S M(&$@<V5C;VYD(&9R;VT@86QL('1H92!L:7-T960@<W1O8VL@97AC:&%N9V5S M(&%N9"!T:&4@;W9E<BUT:&4M8V]U;G1E<B!M87)K970N(%1H:7,@:7,@;W9E M<B U('1I;65S('1H92!T:')O=6=H<'5T(&]F(&%N>2!C;VUM97)C:6%L;'D@ M879A:6QA8FQE($E304T@;VX@=&AE(&UA<FME="X@5&AI<R!S>7-T96T+:7,@ M:6UP;&5M96YT960@=7-I;F<@0R F($,K*R!O;B!A(&YE='=O<FL@;V8@-#@V M)W,@0U!5<RP@=7-I;F<@:6YT97(M<')O8V5S<R!C;VUM=6YI8V%T:6]N<RP@ M86-T:6YG(&%S(&$@<VEN9VQE(&-O;7!U=&EN9R!S>7-T96TN(%1H:7,@;F5T M=V]R:R!S97)V97,@87,@8F]T:"!H;W-T('!R;V-E<W-O<B!A;F0@9G)O;G0@ M96YD(&-L:65N="!S97)V97)S+B!);F-R96%S960@<')O9W)A;6UI;F<@<')O M9'5C=&EV:71Y(&)Y(#,P,"!P97)C96YT(&)Y('5S:6YG(&]B:F5C="!O<FEE M;G1E9"!P<F]G<F%M;6EN9R!M971H;V1S+B @26UP;&5M96YT960@5$-0+TE0 M(&%N9"!8+U=I;F1O=W,@=&\@:6UP<F]V92!T:&4@9&5L:79E<GD@;W5R('-E M<G9I8V4@=&\@;W5R(&-U<W1O;65R(&)A<V4N"PM#;VUM=6YI8V%T:6]N<R!R M97-P;VYS:6)I;&ET:65S.B!-86YA9V4@82!N971W;W)K(&]F(#0P,"!L96%S M960@;&EN92!C:7)C=6ET<RP@8F]T:"!A;F%L;V<@86YD(&1I9VET86PL(&%T M('-P965D<R!U<"!T;R U-B!K8G!S+B!-86YA9V4@-B!E=&AE<FYE=',@*#0@ M:6XM:&]U<V4@86YD(#(@870@8W5S=&]M97(@<VET97,I(&-A<G)Y:6YG(%%N M970@86YD(%1#4"])4"!T<F%F9FEC(&%N9" T,"!33$E0(&-O;FYE8W1I;VYS M+B!297-E87)C:&5D(&9R86UE(')E;&%Y(&9O<B!O=7(@9FER;2X+"U!U<F-H M87-I;F<@<F5S<&]N<VEB:6QI=&EE<SH@4V]L96QY(')E<W!O;G-I8FQE(&9O M<B!A;&P@8V]M<'5T97(L(&-O;6UU;FEC871I;VYS(&%N9"!N971W;W)K:6YG M(&5Q=6EP;65N="!P=7)C:&%S97,N($)Y(&)U>6EN9R!T:')O=6=H(&UU;'1I M<&QE('-O=7)C97,@22!H879E(&)E96X@86)L92!T;R!S879E(%!%5%,@;F5A M<FQY(#4P)2!O;B!P=7)C:&%S:6YG(&5Q=6EP;65N="!C;W-T<RX+"TUI;FDM M4&%K+"!);F,N("T@,3DW.2!T;R Q.3@R"TYE=R!9;W)K+"!.97<@66]R:PM$ M:7)E8W1O<B!O9B!496-H;FEC86P@4W5P<&]R="X+07!P;&EC871I;VYS(%!R M;V=R86UM97(O4WES=&5M<R!0<F]G<F%M;65R+@L+2&ER960@87,@86X@87!P M;&EC871I;VYS('!R;V=R86UM97(@;VX@86X@24)-(%-E<FEE<R\Q('5S:6YG M(&%S<V5M8FQE<B!A;F0@0U!3+B!)('=A<R!S;V]N('!R;V=R86UM:6YG(&QO M=V5R(&QE=F5L(&QI8G)A<GD@<F]U=&EN97,@=&\@8F4@=7-E9"!B>2!O=&AE M<B!P<F]G<F%M;65R<RX@36%D92!A('!R;V=R86UM97)S(&1E8G5G9V5R(&%I M9"!A;F0@<W!E;G0@;75C:"!O9B!M>2!T:6UE(&AE;'!I;F<@;W1H97(@<')O M9W)A;6UE<G,@9&5B=6<@=&AE:7(@<')O9W)A;7,N($%S('1H92!L:6%I<V]N M(&)E='=E96X@=&AE('!R;V=R86UM:6YG('1E86T@86YD(&-U<W1O;65R('-U M<'!O<G0@22!W87,@<F5S<&]N<VEB;&4@9F]R('1R86EN:6YG('1H96T@:6X@ M=&AE(&5F9FEC:65N="!U<V4@;V8@;W5R('-O9G1W87)E+@L+4F5A;&EZ:6YG M('1H870@=&AE('!R;V=R86UM:6YG('-T869F('=A<R!C;VYS=&%N=&QY(&)E M:6YG(&EN=&5R<G5P=&5D('=I=&@@=&5C:&YI8V%L('-U<'!O<G0@<75E<W1I M;VYS(&%N9"!P<F]B;&5M<RP@22!S=6=G97-T960@=&AA="!-:6YI+5!A:R!H M879E(&$@=&5C:&YI8V%L('-U<'!O<G0@9&5P87)T;65N="!A;F0@=V%S('!R M;VUO=&5D('1O(&)E(&ET<R!H96%D+B!(:7)E9"!A;F0@=')A:6YE9"!O=7(@ M=&5C:&YI8V%L('-U<'!O<G0@<W1A9F8@:6X@=&AE('5S92!A;F0@;6%I;G1E M;F%N8V4@;V8@;W5R('-O9G1W87)E+"!H87)D=V%R92!A;F0@8V]M;75N:6-A M=&EO;G,@9F%C:6QI=&EE<RX@37D@9&5P87)T;65N="!W87,@<F5S<&]N<VEB M;&4@9F]R('1H92 B:6YV:7-I8FQE(B!M86EN=&5N86YC92!O9B!O=7(@8W5S M=&]M97(G<R!C;VUP=71E<B!C96YT97)S+B!">2!C;&]S96QY(&UO;FET;W)I M;F<@=&AE:7(@<WES=&5M<RP@=V4@=V5R92!A8FQE('1O(')E8V]G;FEZ92!A M;F0@8V]R<F5C="!S:71U871I;VYS(&)E9F]R92!T:&5Y(&)E8V%M92!P<F]B M;&5M<RX@1'5R:6YG(&UY(&5M<&QO>2!A<R!$:7)E8W1O<GD@;V8@5&5C:&YI M8V%L(%-U<'!O<G0@;F]N92!O9B!O=7(@8W5S=&]M97)S(&5V97)Y(&5X<&5R M:65N8V5D(&%N>2!U;G!L86YN960@9&]W;B!T:6UE+@L-1&EG:71A;"!3>7-T M96US+"!);F,N("T@,3DW."!T;R Q.3<Y"T-O;'5M8FEA+"!3;W5T:"!#87)O M;&EN80M!<'!L:6-A=&EO;G,@4')O9W)A;6UE<B]3>7-T96US(%!R;V=R86UM M97(N"PM$:6=I=&%L(%-Y<W1E;7,@<V]L9"!S;V9T=V%R92!T;R!E;&5C=')I M8R!U=&EL:71I97,N(%-T86YD87)D:7IE9"!T:&4@(DQO;VL@86YD($9E96PB M(&]F(&]U<B!S;V9T=V%R92X@4')O=FED960@=&5C:&YI8V%L(&%S<VES=&%N M8V4@=&\@=&AE('-A;&5S(&9O<F-E('=H96X@<&]T96YT:6%L(&-U<W1O;65R M<R!H860@=&5C:&YI8V%L('%U97-T:6]N<RX@4F5S<&]N<VEB;&4@9F]R(&EN M=&5R9F%C:6YG(&]U<B!B:6QL:6YG(&9I;&5S('1O('1H92!E;F=I;F5E<FEN M9R!S>7-T96T@9FEL97,@;V8@4V-O='0@)@M38V]T="!%;F=I;F5E<FEN9R!O M9B!3="X@3&]U:7,L($UI<W-O=7)I+"!W:&5N($1322!F;W)M960@82!P87)T M;F5R<VAI<"!W:71H('1H96TN"PM$86)L97(@4W1E96PL($EN8RX@+2 Q.3<W M('1O(#$Y-S<+0F5R:V5L97D@2&5I9VAT<RP@3F5W($IE<G-E>0M#;VYS=6QT M86YT+@L+0V]M;6ES<VEO;F5D('1O(&1E<VEG;B!A;F0@:6UP;&5M96YT(&$@ M;75L=&DM=7-E<B!C;VUP=71E<B!S>7-T96T@9F]R('1E;&5P:&]N92!S86QE M<R!O9B!I;F1U<W1R:6%L('-T965L+B!4:&ES('=A<R!D;VYE(&]N(&$@:&]B M8GD@8V]M<'5T97(@8GD@=W)I=&EN9R!M>2!O=VX@:6YT97)R=7!T(&1R:79E M;B!O<&5R871I;F<@<WES=&5M(&%N9"!E;F%B;&EN9R]D:7-A8FQI;F<@;65M M;W)Y(&)O87)D<R!W:&5N(&$@=&%S:R!N965D960@=&\@8F4@<W=A<'!E9"X+ M#0U%1%5#051)3TX-#4YU;65R;W5S(%=O<FMS:&]P<R!F<F]M('9A<FEO=7,@ M<&QA8V5S(&EN(&1A=&$@8V]M;75N:6-A=&EO;G,@86YD(&YE='=O<FMI;F<N M#4YU;65R;W5S(%=O<FMS:&]P<R!F<F]M($E"32!O;B!T:&4@4V5R:6%S+S$@ M)B!I;B!T:&4@1418(&]P97)A=&EN9R!S>7-T96TN#4YU;65R;W5S(%=O<FMS M:&]P<R!F<F]M($1I9VET86P@0V]M<'5T97(@0V]R<"!I;B!24U13+V4@)B!2 M5"\Q,0U"4R!I;B!#;VUP=71E<B!38VEE;F-E("T@56YI;VX@0V]U;G1Y($-O M;&QE9V4L(%!L86EN9FEE;&0L($Y*#0M33T945T%212!%6%!%4DE%3D-%("T@ M3$%.1U5!1T53"PM'3E4@0R]#*RL-5V%T8V]M+"!#+T,K*R!V."XU("T@,3 N M-B H86YD('1H92!D969U;F-T(#$Q+C I"TEN=&5K($,K*R!V,BXP,0M";W)L M86YD(%!R;V9E<W-I;VYA;"!#*RLL(%1U<F)O($,@)B!4=7)B;R!!<W-E;6)L M97(+36EC<F]3;V9T($,L(%%U:6-K($,L($UA8W)O($%S<V5M8FQE<BP@475I M8VL@0F%S:6,L($9O<G1R86XL"TE"32!%1$P@86YD($UA8W)O($%S<V5M8FQE M<B!F;W(@=&AE(%-E<FEE<R\Q"T1%0R!$24)/3"P@07-S96UB;&5R+"!A;F0@ M<WES=&5M($)A<VEC(&9O<B!01% M,3$G<PL+#%-/1E1705)%($584$52245. M0T4@+2!/4$52051)3D<@4UE35$5-4PL+45-33))S(%)E86Q4:6UE(%!L871F M;W)M(%8@-BXP#5%34TR2<R!13E@@=C,N,34@)B T+C$@+2 T+C(U"TE"32!% M1%@L($-04RP@4E!3.R!O<&5R871I;F<@<WES=&5M<R!F;W(@=&AE(%-E<FEE M<R\Q"T1%0R!24U13+V4@86YD(%)4+3$Q(&]P97)A=&EN9R!S>7-T96US(&9O M<B!01% M,3$G<PM)0DT@4$,M1$]3+"!-:6-R;R!3;V9T($U3+41/4RP@4V]F M='=A<F4M3&EN:R!00RU-3U,+5&5C:&YI8V%L(%-Y<W1E;7,@0V]N<W5L=&%N M=',@1DQ%6"!$3U,@9F]R(%-75%!#)W,+"U-/1E1705)%($584$52245.0T4@ M+2!!4%!,24-!5$E/3E,@04Y$($]42$52"PM14U-,(%!H;W1O;B!-:6-R;RU' M54D+5$-0+TE0(%-O8VME="!L979E;"!P<F]G<F%M;6EN9PM534P@*%5N:79E M<G-A;"!-;V1E;&EN9R!,86YG=6%G92D+0TU-("A#87!A8FEL:71Y($UA='5R M:71Y($UO9&5L:6YG*0U625-)3PM&5% @26YC+B!00U1#4 M-:6-R;U-O9G0@ M4')O:F5C= U-:6-R;U-O9G0@5VEN9&]W<R!V,RXQ(%=I;F1O=W,Y-2\Y. M$ M97-Q5FEE=RU8('8R+C(+2'5M;6EN9V)I<F0@6"]7:6X+4V]F='=A<F4M3&EN M:R!,86Y,:6YK+"!%;75,:6YK"TUI8W)O4V]F="!7;W)D+"!-:6-R;RU0<F\@ M5V]R9%-T87(L(%=O<F1097)F96-T+"!/=&AE<B!7;W)D(%!R;V-E<W-O<G,+ M36EC<F]3;V9T($5X8VAA;F=E"TYU='-H96QL(%9E<G-I;VX@,BXQ,#L@9"U" M87-E($E)23L@4V5V97)A;"!'<F%P:&EC<R!086-K86=E<PM";W)L86YD(%!A M<F%D;W@@)B!1=6%T=')O+5!R;PL+2$%21%=!4D4@15A015))14Y#10L+26YT M96P@>#@V("8@4&5N=&EU;2!0<F]C97-S;W)S(&)A<V5D($-052=S(&EN(')E M86PL('9I<G1U86P@)B!P<F]T96-T960+;6]D97,+4$-)+"!%25-!+"!)4T$@ M)B!-:6-R;RU#:&%N;F5L(&)U<W-E<R!B=7,@8V%R9',@:6YC;'5D:6YG(&UA M;F%G:6YG(&%N9 MC;VYF:6=U<FEN9R!)4E$G<RP@1$U!(&-H86YN96QS(&%N M9"!)+T\@4&]R=',+4T-322!P97)I<&AE<F%L<PM!=61I;R!#87)D<R!F<F]M M($%N=&5X($5L96-T<F]N:6-S(&%N9"!$:6=I1W)A;2P@4F%D:6\@4WES=&5M M<R!A;F0@3W)B86X+24)-(%-E<FEE<R\Q("@T.34V+VLP," O93$P("]B,# I M(&%N9" H-#DU-2]F*2!A;F0@<&5R:7!H97)A;',+1$5#(%!$4" H,3$O,S0I M+" H,3$O-S I(%9A>"!A;F0@<&5R:7!H97)A;',+24)-(%!#)W,@*%!#(%A4 M($%4(%!3,B\R-2 O,S @86YD(&-L;VYE<RD@86YD('!E<FEP:&5R86QS"U-O M=71H(%=E<W0@5&5C:&YI8V%L(%!R;V1U8W1S(#8X,# @*$UO=&]R;VQA($U# M+38X,# I"PL,0T]-355.24-!5$E/3E,@15A015))14Y#10L-17AT96YS:79E M(%1#4"])4"!S;V-K970@;&5V96P@<')O9W)A;6UI;F<-44Y8($9L965T($YE M='=O<FMI;F<+5$-0+TE0('5T:6QI=&EE<R!I;F-L=61I;F<@1E10+"!496QN M970L($Y&4R F(')L;V=I;BP+6"U7:6YD;W=S( U%=&AE<FYE=" H,3 O,3 P M+4)A<V4M5"P@8V]A>"D@4VUA<G0@86YD($1U;6(@2'5B<RP@42U.970L"T%R M8VYE=" H06-T:79E+U!A<W-I=F4@:'5B<RDL"T9R86UE(%)E;&%Y+ M33$E0 M+"!04% L"T%S>6YC:')O;F]U<RP@4WEN8VAR;VYO=7,L($)I<WEN8VAR;VYO M=7,@86YD(#,R-S @<')O=&]C;VQS+ M!;F%L;V<@86YD(&1I9VET86P@8V]M M;75N:6-A=&EO;G,N"TA$6"!A;F0@1D18(&AA;F1S:&%K:6YG+ M$:6%L+55P M($UO9&5M<R!%>'1E<FYA;"]);G1E<FYA;" H,S P("T@-38@2T)04RDN"U8N M,CDL(%8N,S(L(%8N-#(@)B!8,BP+3&5A<V5D($QI;F4@36]D96US("A096YR M:6PL(%!A<F%D>6YE+"!!<FLL($-O;F-O<F0L($%45"DL"U1I;64@1&EV:7-I M;VX@375L=&EP;&5X97)S("A!<FLI+ M3=&%T:7-T:6-A;"!-=6QT:7!L97AE M<G,@*$UI8V]M*2P+07-Y;F-H('1O(%-Y;F-H($-O;G9E<G1E<G,@*$%R:R F M(%)!1"DL"TUO9&5M($5L:6UI;F%T;W)S("A!<FLI+ M$:6=I;&]G(#0P,"!D M:6=I=&%L($1A=&$@3&EN92!-;VYI=&]R+ M"<F%D;&5Y(%!"+3%#+6(@86YA M;&]G($QI;F4@06YA;'EZ97(+#0U2149%4D5.0T53($%604E,04),12!54$]. M(%)%455%4U0+#0`````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````$``!U! ``A@0``&P(``!\" ``?0@``*,(``"Z" ``Z@@``,D*``#L M"@``_@H``!<+``!?#@``F X``*L.``"_#@``O1 ``.,0``#]$ ``$1$``"\2 M``!$$@``6!(``' 2``!B% ``AQ0``)P4``#*% ``7Q8``'06``",%@``P!8` M`"0:``!'&@``5AH``'<:```4'P``0!\``$T?``!<'P```" ``#D@``!-( `` M@R ``(4H``"C* ``MB@```$I``#(+ ``/"T``#TM``!B+0``>RT``*<M```? M+P``02\``%XO``!J+P``=3 ``'\P``"8,0``N#$``-@R````,P``$#0``#TT M``#[-0``#S8```LX```F. ``YCH```@[```).P```/T`_0#[`/D`^P#Y`/L` M^0#[`/D`^P#Y`/L`^0#[`/D`^P#Y`/L`^0#[`/D`^P#Y`/4`^P#Y`/L`^0#] M`/T`_0#]`/T`_0#]```````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````& M-0B!-@B!``,V"($#/BH!`S4(@0!)``0``"L$``! ! ``<P0``'0$``!U! `` MAP0``'\'``" !P``:P@``&P(``!]" ``R H``,D*```7"P``7@X``%\.``!B M% ``%!\``/X?```]+0``=# ``'4P``!_, ``@# ``,XP```9,0``63$``)<Q M``##,0``_ ```````````````/P```````````````#\```````````````` M^@```````````````/H```````````````#Z````````````````^@`````` M`````````/H```````````````#Z````````````````^@`````````````` M`/H```````````````#Z````````````````^@```````````````/H````` M``````````#Z````````````````^@```````````````/H````````````` M``#Z````````````````^@```````````````/H```````````````#Z```` M````````````^@```````````````/H```````````````#Z```````````` M````^@```````````````/H```````````````#Z````````````````^@`` M`````````````/H``````````````````````0```P```R0!`!T`! ``*P0` M`$ $``!S! ``= 0``'4$``"'! ``?P<``( '``!K" ``; @``'T(``#("@`` MR0H``!<+``!>#@``7PX``&(4```4'P``_A\``#TM``!T, ``=3 ``'\P``" M, ``SC ``!DQ``!9,0``ES$``,,Q```@,P``N30``. T```F. ``4#@``*8X M``#E.@``YCH```D[```````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M````````````)L,Q```@,P``N30``. T```F. ``4#@``*8X``#E.@``YCH` M``D[``#]````````````````_0```````````````/T```````````````#] M````````````````_0```````````````/T```````````````#]```````` M````````_0```````````````/H````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` MPR0!``$````)' `?L- O(+#@/2&P" <BL @' M(Y"@!220H 4EL `````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````2 M``\`"@`!`%L`#P`"`````````"0``$#Q_P(`) ````8`3@!O`'(`;0!A`&P` M"! !M2 D$````````````````````````/ !!0/+_H0`\%@!$
M&49@!A'4; !T" 4 !A'(80!G'(80!P&@( !&&\;@!T M```````````````````)-P``! ``1@#_____0```D[```?``````0` M`,,Q```).P( "(`````! ``"3L``"$#__P(.`$(`:0!L`&P` M( !#`&$`<@!O`',`90!L`&P`:0`=`$,`.@!<`%<`20!.`$0`3P!7`%,`7 !$ M`&4`<P!K`'0`;P!P`%P`<@!E`',`=0!M`&4`+@!D`&\`8P#_0 & `0!(
M2 -@*YP`!``$`2 ````````!&``````````(0``````````DW``! (
M$ ```,```!'%I !```"@8#!00%@,$ASH``````````````````/\````` M````5 !I&T90!S" 3@!E'<( !2&`;0!A&X````U%I !@%!0$" M0<&@4'`````````! ``````````````( `````4P!Y&T8@!O&PS M)I !```""P8$`@("`@($ASH``````````````````/\`````````00!R`&D` M80!L```````$``$`" ```- "``````````#)Y%?&!Q58A@`````#``````#V M!P``82T```$`%P````````!@```````````````!``$!"0# M````A `````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M`*4&P >T`+0`@ `2, ``````````````````NC<````````````````````` M```````````````````````````````````````````````````````````` M``````````````#__Q(```````````````````````X`0@!I`&P`; `@`$,` M80!R`&\`<P!E`&P`; !I```````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M_O\```0*`@```````````````````````0```."%G_+Y3V@0JY$(`"LGL]DP M````6 $``! ````!````B ````(```"0`````P```)P````$````J ````4` M``"T````!P```, ````(````U ````D```#L````$@```/@````*````% $` M``P````@`0``#0```"P!```.````. $```\```! `0``$ ```$@!```3```` M4 $```(```#D! ``'@````$``````',`'@````$``````',`'@````$````` M`',`'@````$``````',`'@````L```!.;W)M86PN9&]T```>````#P```$)I M;&P@0V%R;W-E;&QI```>`````@```#,`;&P>````$P```$UI8W)O<V]F="!7 M;W)D(#@N, ``0 ``````````````0 ````#&66[3%\$!0 ````!BJ%S)&\$! M`P````$````#````]@<```,```!A+0```P`````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M`/[_```$"@(```````````````````````(````"U<W5G"X;$).7" `K+/FN M1 ````75S=6<+AL0DY<(`"LL^:Y$`0````$```P````!````: ````\```!P M````!0```)0````&````G ```!$```"D````%P```*P````+````M ```! ` M``"\````$P```,0````6````S ````T```#4````# ```.$````"````Y 0` M`!X````9````36EC<F]N($5L96-T<F]N:6-S+"!);F,N```Q``,```!@```` M`P```!<````#````NC<```,```#H$ @`"P+``````````L M````"P`````````>$ ```0````$#! (````>````!@%1I=&QE
M,````!`````)@````#`````````" ````!````-@````(````^`````0
M(````*````7U!)1%]'54E$(#D! ``00$X![`# `-0`S`#@` M- `T`#D`0@`M`#<`- !!`#0`+0`T`#D`,0`T`"T`00`S`#$`10`M`#8`,P`U M`$4`1 `T`$4`0P`R`#@`1@!%`'T````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M!@````,````$````!0````8````'````" ````D````*````"P`` M``P````-````#@````\````0````$0```!(````3````% ```!4````6```` M%P```!@````9````&@```!L````<````'0```!X````?````( ```"$````B M````(P```/[___\E````)@```"<````H````*0```"H````K````_O___RT` M```N````+P```# ````Q````,@```#,```#^____-0```#8````W````. `` M`#D````Z````.P```/[____]____/@```/[____^_____O______________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M_________________________U(`;P!O`'0`( !%`&X`= !R`'D````````` M```````````````````````````````````````````````````6``4!____ M______\#````!@D"``````# ````````1@````" NKR47!/!`8"<N7S)&\$! M0 ```( `````````,0!4`&$`8@!L`&4````````````````````````````` M``````````````````````````````````````````X``@#_____________ M__\````````````````````````````````````````````````D! M``````!7&`<@!D$0;P!C'4;0!E&X= ``````````````````````
M&@`"`04```#__________P`````` M```````````````````````````````````````````````>1@````````4` M4P!U`&T`;0!A`'(`>0!)`&X`9@!O`'(`;0!A`'0`:0!O`&X````````````` M```````````````````````H``(!`@````0```#_____```````````````` M+ 0````````!0!$`&\`8P!U M`&T`90!N`'0`4P!U`&T`;0!A`'(`>0!)`&X`9@!O`'(`;0!A`'0`:0!O`&X` M`````````````#@``@'_______________\````````````````````````` M```````````````````````T! ````````!$,;P!M' 3P!B&H
M M````$@`"`0$````&````_____P`````````````````````````````````` M``````````````````!:`````````$\`8@!J`&4`8P!T`% `;P!O`&P````` M```````````````````````````````````````````````````````6``$` M________________``````````````````````````" G+E\R1O!`8"<N7S) M&\$!```````````````````````````````````````````````````````` M``````````````````````````````````````````````````#_________ M______\````````````````````````````````````````````````````` M```````````!````_O__________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M_________________________________P$`_O\#"@``_____P8)`@`````` MP ```````$88````36EC<F]S;V9T(%=O<F0@1&]C=6UE;G0`"@```$U35V]R M9$1O8P``````]#FR<0`````````````````````````````````````````` M
M M
M M
M M
M````````````````````````````````````````````````````````````
J````````````````````````````````````````````````````````
`
end

Oh well. That was supposed to have been sent by private mail. My Oops!

Bill Caroselli

Omer & Igor, im sympathetic to your side at this case.
Im sure that QSSL policy is not having anyone who wishes to code a complex
application, to bring their own mem. allocator that will suit their needs.
As it seems to be now, _if im not in favour of a low footprint, _and all i
realy care about is speed (RAM’s prices declined significantly :wink: ) _then i
need to start looking for an allocator …
It doesnt sound good.
hope for better days in year 6.2 :slight_smile:)

peace, Ram.

Igor Kovalenko <Igor.Kovalenko@motorola.com> wrote in message
news:3B69B5FB.1091970F@motorola.com

Alain, you’re right wrt databases. However practical considerations
suggest that your current policy of making ‘embedded’ allocator the
default one does not serve you well.

Most people will get to know QNX by installing it on their desktop
first, that seems to be QSSL’s own goal. They wil play with it and if
they like it then there might be an embedded project. Now chances are
with allocator like current one they may simply find it slow which
won’t really inspire anyone to go ahead with embedded project. Keep in
mind that many of people will be shallow enough to not bother with
figuring the issue.

IMHO having a Doug Lea’s or another ‘sacrifice-memory-for-speed’
allocator as default for desktop version would be much more useful. When
and if people need to conserve memory on embedded systems, they will
switch to embedded allocator.

Botoom line, allocator for more common usage should be default one.
Unless you suggest that RTP free download is targeted directly to
embedded systems, the current allocator is simply unsuitable.

  • igor

Alain Magloire wrote:

Many specialised applications, especially databases, comes with
there
own well-tuned allocator. There are many tradeoffs to be made,
coalescing,
speed, footprint, suceptible to bursty usage etc … Especially on
applications like a DB where the memory pattern/model is
not at all similar to a utility program, DB implementors will usually
fine
tune there allocator scheme to get the most.

Now it is behond me, why you find this … inelegant …
You are the developer of the DB and know the memory footprint and
pattern
and can do the most clear decision of what type of allocator scheme to
use.
Memory allocation is a big field, you may want to check out HOARD
an allocator optimize for SMP and threads, the speed numbers were
impressive.

If we go to the other side of the pound(forget embedded), Oracle, for
example
running on Solaris, comes with its allocator, certainly will not let
such
and important task to a general purpose allocator that comes from libc.
Well … they also fine tune the kernel and replace the entire filesystem
:sunglasses:

\

alain

Igor,

from a previous discussions … here some statements from Steve
Furr:

There are some promisses at the end of his posting :slight_smile:

Armin


Okay, Armin, I’ll give you an update and a little more detail
on what is happening when the GNU library allocator is used. Look
at the
end of the message for an update on changes that will appear in
the C library.

My conclusion: there is something deadly wrong
with the Python library implementation!

As Colin indicated, Python keeps a list that grows monotonicly and
regularly. When it reallocs the list, it only grows it by one.

So that’s the behavior, but why is it so pathological?

You may wonder if QNX realloc() is just not doing anything
intelligent
with realloc(), right?

In point of fact, as long as the list fits in one of the small
blocks
– under 64 bytes if you haven’t altered malloc-config.o – and
doesn’t
have to move to the next block size (8-12 bytes difference),
realloc
is a no-op.

If the buffer a large block, things are a little different. The
free list version of realloc() will attempt to coalesce the
adjacent
block if it is on the free list. In fact, this is usually
successful
until you reach an _amblksiz boundary (16k or 32k by default, I
can’t
recall). Its success rate can be influenced somewhat depending
on
the free list strategy. (We doubled its performance by using
FIFO
ordering of the free list).

As a consequence, things are okay, except that every 32k or so
you
have to memcpy() the whole block. What Colin didn’t tell you
was
that this cost only started to become really significant when
the
block got to be greater than 1M!


What’s going on with GNU malloc?

The fact that the realloc() in glibc didn’t degrade under these
circumstances is more an artifact of the implementation than by
design. The GNU library malloc always uses simple segmented
power of
two free lists for fast lookups – as opposed to the hybrid
strategy of QNX.

This means that every allocation request is satisfied from a
bucket
that holds blocks that are a power of two in size. If an
allocation
can’t be satisfied with an existing bucket, a new one is
created.
This means that you can have up to 50% internal fragmentation in
any given block regardless of size. There is also external
fragmentation
as the heap info block is increased to have as many buckets as
are
required to accomodate the largest block size. A side effect is
that
the doubling that takes place every time you cross a power of
two
boundary reduces the number of times the block will need to be
copied to satisfy a realloc.

A direct consequence is that fragmentation of the heap increases
substantially. What’s more, the high water mark balloons when
big
realloc requests take place. Since GNU malloc doesn’t restore
memory
to the system, this is pretty significant. The heap grew to 32M
to
complete the Python new syntax test.

You can confirm this by linking Python against other allocators
that don’t do segmented allocation and they exhibit pathological
behavior as well. We did this with Hoard (an excellent
multi-threading
allocator) and we gave up and slayed the process after about ten
minutes.

How does this compare for memory usage?

The University of Texas has done a lot of studies of allocation
behavior. In one of these they defined four measures of
fragmentation.
With eight programs – representative of different programming
styles and fields of use (e.g. GCC ghostscript, Perl), they
defined
four measures – whose allocation patterns had previously
been studied and shown to be distinctively different, they took
two of the measures for each program.

The results are summarized below for segmented power-of-two free
lists
for first fit, FIFO ordered free lists (the policy used in QNX
malloc for big blocks as of now), and first fit LIFO (the
original
QNX policy for big blocks).

Method 3 compared the high water mark to the amount of live
memory
at the time of the program’s final allocation.

Method 4 compared the high water mark to the maximum memory
requested
by the program at the point of maximum live memory usage.

Method 3:
Allocator Average Frag. Std. Dev.
segmented 2^^N 1818% 4654%
first fit LIFO 50.7% 62.3%
first fit FIFO 4.97% 6.13%

Method 4:
Allocator Average Frag. Std. Dev.
segmented 2^^N 73.6% 42.7%
first fit LIFO 36.3% 61.2%
first fit FIFO 3.14% 3.81%

As you can see the ratcheting effect is quite evident (in
measurement
method 3), and the behavior is wildly erratic.

The trade-off in creating internal fragmentation throughout
the application doesn’t make sense in response to some poor
assumptions made about allocation behavior in part of the
application.

So what’s wrong about Python?

It’s really only bad if performance of the list object in
question
is critical – such as if it’s part of the tokenizer and is run
constantly.

The reasoning is that the application writer knows the
allocation pattern, but chooses to rely on assumptions that
are dependent on the implementation w.r.t. block granularity
that dramatically impact performance. This is compounded by
that fact that in this instance the poorly performing code
is encapsulated in an object, where the allocation pattern
of the object is well-understood. When it is known that
the object will regularly double in size, it should increase
its capacity accordingly, rather than assuming that the
implementation does so, or pressuring the implementation to
do so, when that negatively impacts internal fragmentation
for everything else in the heap.


What has changed in QNX malloc?

The nature of the allocator remains unchanged. Segmented
allocations are done for small blocks where there is a
profound performance benefit with minimal internal
fragmentation.

Big block handling has changed slightly. The first fit LIFO
policy has been changed to first fit FIFO. The rationale is
that this gives blocks more opportunity to coalesce to satisfy
larger requests, keeping fragmentation down and increasing the
probability that realloc requests succeed in situ. A side
benefit
is that there should be a greater likelihood that coalesced
blocks are
returned to the sytem.

We also made a minor change to realloc() requests on big blocks.
If a block is grown, and the block is already large, we assume
it will grow further and grow it by at least 50%. The only
reason we were prepared to go this far was because
realloc(ptr,size+1) incidences are too frequent to ignore, and
this policy is far more limited in its overall impact on
the granularity of blocks in general.

Further to this, we added a malloc option that lets you turn
this behavior off.

i.e. malloc_opt(MALLOC_MONOTONIC_GROWTH, 1);

===============================================================================<<<<<
Armin
Barring any unforeseen circumstances, these changes should
be in a future release of libc, and you should see performance
on par with GNU malloc, but with substantially less
fragmentation,
and the ability to restore memory to the system.
================================================================================<<<<<
Armin


Steve Furr email: furr@qnx.com
QNX Software Systems, Ltd.




Igor Kovalenko wrote:

Alain, you’re right wrt databases. However practical considerations
suggest that your current policy of making ‘embedded’ allocator the
default one does not serve you well.

Most people will get to know QNX by installing it on their desktop
first, that seems to be QSSL’s own goal. They wil play with it and if
they like it then there might be an embedded project. Now chances are
with allocator like current one they may simply find it slow which
won’t really inspire anyone to go ahead with embedded project. Keep in
mind that many of people will be shallow enough to not bother with
figuring the issue.

IMHO having a Doug Lea’s or another ‘sacrifice-memory-for-speed’
allocator as default for desktop version would be much more useful. When
and if people need to conserve memory on embedded systems, they will
switch to embedded allocator.

Botoom line, allocator for more common usage should be default one.
Unless you suggest that RTP free download is targeted directly to
embedded systems, the current allocator is simply unsuitable.

  • igor

Alain Magloire wrote:

Many specialised applications, especially databases, comes with there
own well-tuned allocator. There are many tradeoffs to be made, coalescing,
speed, footprint, suceptible to bursty usage etc … Especially on
applications like a DB where the memory pattern/model is
not at all similar to a utility program, DB implementors will usually fine
tune there allocator scheme to get the most.

Now it is behond me, why you find this … inelegant …
You are the developer of the DB and know the memory footprint and pattern
and can do the most clear decision of what type of allocator scheme to use.
Memory allocation is a big field, you may want to check out HOARD
an allocator optimize for SMP and threads, the speed numbers were impressive.

If we go to the other side of the pound(forget embedded), Oracle, for example
running on Solaris, comes with its allocator, certainly will not let such
and important task to a general purpose allocator that comes from libc.
Well … they also fine tune the kernel and replace the entire filesystem > :sunglasses:

\

alain