What I’m looking for are some choices. If QNX put out an “embedded lib” and a
“desktop lib”, each tuned appropriately for the target environment, I could
choose which way I wanted to go at compile time, and if necessary easily
produce two different executables for two different purposes. As I understand
it from other newsgroups, QNX6 is targeted as an embedded operating system, so
it’s totally understandable that they would make the trade-off choices in favor
of constrained memory systems. I however have an embedded project underway, a
more traditional desktop requirement, and finally a requirement for dual or
quad CPUs and as much memory as I can stuff in a box (12 to 16 gigabytes). I
want to use QNX6 for all of it, and it just plain doesn’t make sense to trade
speed for low memory use when you’ve got 2GB or more to play with. There’s
absolutely no reason why Linux should kick QNX6’s butt in memory allocation
speed when all that’s required is a little library management geared towards
two different end environments. That’s not to say that I’d use the “T” word to
describe the process of supplying two different libraries (perhaps with a
third, common one), but it doesn’t sound insurmountable at the outset now, does
it?
We can certainly supply our own memory allocators, but I think it would be a
lot cleaner and less hassle for those not inclined to undertake that project if
QNX supplied some official libraries. I realize that realloc( ptr, size + 1 )
is a bad idea, but my main point is that it doesn’t have to be as slow as it is
today. IMHO, the desktop world, where QNX6 is playing whether it’s being
targeted or not, will see this as a fairly significant problem that’s going to
draw an awful lot of flak if it’s not addressed in some manner.
Just toss that two-cents worth in the pile by the door… 
-Warren
“Steve Furr” <furr@qnx.com> wrote in message news:8uhlae$d7v$1@nntp.qnx.com…
| In article <8ufaro$68e$1@inn.qnx.com>, Warren Peece <warren@nospam.com>
wrote:
| >So I guess that means if you’re memory constrained, you use the malloc()
family
| >as-is. If you’re looking for speed, then you’re better off doing something
| >custom. As a suggestion, how about a couple of different malloc()
libraries,
| >one for embedded systems (slow but efficient), and one for desktop systems
| >(fast and less efficient)?
| >
|
| No. Don’t read too much into this. What it says is that doing a
| realloc(ptr,size+1) is a bad idea. It doesn’t suggest that malloc
| performance is bad, Igor’s comments aside. Igor’s comments were related
| to the same malloc algorithm on QNX4 and Neutrino some time ago. The
| malloc algorithm has since been improved in any case, and, to the
| best of my knowledge, procnto was also enhanced.
|
| The Neutrino version performed poorly at that time because of the
| manner in which procnto responded to a lot of small mmap() requests.
| On the whole, the malloc performance under QNX4 was actually better
| than the previous Watcom allocator.
|
| Different malloc implementations for different purposes is a good
| idea, but it takes careful consideration. Performance is highly
| dependent on application behaviour and optimizations that you
| assume will be better may hinder throughput in practice, and, iin
| the worst case negatively impact priority behaviour for other threads
| – I hesitate to say realtime, because realtime threads shouldn’t
| be using malloc().
|
| As an example, U. Texas has an allocator for concurrent programs
| that minimizes blocking factors. I mentioned to Peter V. and he
| tried it out. Reportedly, it compiled out of the box and had
| substantial benefit on programs with many threads. I’ll look
| for a URL.
|
| >-Warren
| >
| >
| >“Colin Burgess” <cburgess@qnx.com> wrote in message
| >news:8uf742$s62$1@nntp.qnx.com…
| >| Igor Kovalenko <Igor.Kovalenko@motorola.com> wrote:
| >| > Don’t bother blaming gcc. I can’t say for sure what is the problem now,
but
| >| > back 2 years when we started using Neutrino I did some simple
performance
| >| > tests. One particular problem was performance of malloc() - it used to
be
| >| > about 2 orders of magnitude slower than on QNX4. This correlates quite
well
| >| > with Phyton scripts performance and indeed being interpreted language
| >Phyton
| >| > must be using malloc() heavily, at least under some circumstances.
| >|
| >| > I did not check the status of problem for a while, since we decided at
that
| >| > point to avoid using malloc() in CPU bound code. Would be interesting to
| >see
| >| > QNX comments on this.
| >|
| >| Yup, it was malloc. Or more specifically, realloc.
| >|
| >| The python code is using realloc to grow a list implemented as an
| >| array. It’s doing it a HUGE amount of times, and growing it by 1 element
| >| each time.
| >|
| >| The Linux realloc presumeable notices that you are growing, and gives you
| >| a whole swag of memory to reduce the need to malloc and memcpy.
| >|
| >| The QNX realloc is a lot more conservative wrt memory allocation, and so
| >| it ends up having to malloc and memcpy chunks that are about 4Mb in size
| >| almost every time the list is grown.
| >|
| >| So some would say that our realloc sucks, but most would agree that the
| >| python list implementation sucks even worse, and the Linux realloc is
| >| just covering up for bad code.
| >|
| >| –
| >| cburgess@qnx.com
| >
| >
|
|
| ------------------------------------------------------------------------- |
| Steve Furr email: furr@qnx.com
|
| QNX Software Systems, Ltd. |