Performance of GCC

QNX Newsgroups (Archives) qdn.public.qnxrtp.os
21

Colin Burgess wrote:

Armin Steinhoff <A-Steinhoff@web_.de> wrote:

I was implying writing your own allocator, but linking the GNU allocator
would also qualify as a project (especially if you’re a newbie).

It’s just a re-compile ‘project’ … so it’s not
a big issue.

Great - can I have a copy? ;v)

Why not? QSSL is claiming that most LINUX (GNU)
software can be flawless
re-compiled. Isn’t it ?

What makes you think that the malloc module is the only place where a
tradeoff was made in favor of embedded systems that has an effect on
performance?

… messurements and traces with DejaView.

Er, are we talking about the same operating system here?

No … but that doesn’t change the code of the GNU
malloc module :wink:

Deja view is only available for QNX4.

Yes … some sort of ‘availability’.

Armin

22

“Armin Steinhoff” <A-Steinhoff@web_.de> wrote in message
news:3A0FB072.B708A2BA@web_.de…

Colin Burgess wrote:

Armin Steinhoff <A-Steinhoff@web_.de> wrote:

I was implying writing your own allocator, but linking the GNU
allocator
would also qualify as a project (especially if you’re a newbie).

It’s just a re-compile ‘project’ … so it’s not
a big issue.

Great - can I have a copy? ;v)

Why not? QSSL is claiming that most LINUX (GNU)
software can be flawless
re-compiled. Isn’t it ?

What makes you think that the malloc module is the only place where a
tradeoff was made in favor of embedded systems that has an effect on
performance?

… messurements and traces with DejaView.

Er, are we talking about the same operating system here?

No … but that doesn’t change the code of the GNU
malloc module > :wink:

But you said you used “[measurements] and traces with Dejaview” to determine
that the malloc module was the only place in QNX6 where tradeoffs were made
in favor of embedded systems, which has absolutely nothing to do with
measuring and tracing the GNU allocator on some other system. You’re
starting to sound like Al Gore. :slight_smile:


Deja view is only available for QNX4.

Yes … some sort of ‘availability’.

Armin

23

Warren Peece wrote:

“Armin Steinhoff” <A-Steinhoff@web_.de> wrote in message
news:3A0FB072.B708A2BA@web_.de…


Colin Burgess wrote:

Armin Steinhoff <A-Steinhoff@web_.de> wrote:

I was implying writing your own allocator, but linking the GNU
allocator
would also qualify as a project (especially if you’re a newbie).

It’s just a re-compile ‘project’ … so it’s not
a big issue.

Great - can I have a copy? ;v)

Why not? QSSL is claiming that most LINUX (GNU)
software can be flawless
re-compiled. Isn’t it ?

What makes you think that the malloc module is the only place where a
tradeoff was made in favor of embedded systems that has an effect on
performance?

… messurements and traces with DejaView.

Er, are we talking about the same operating system here?

No … but that doesn’t change the code of the GNU
malloc module > :wink:

But you said you used “[measurements] and traces with Dejaview” to determine
that the malloc module was the only place in QNX6 where tradeoffs were made
in favor of embedded systems,

See above … the context of my statement was
quite different … you wrote:

What makes you think that the malloc module is the only place where a
tradeoff was made in favor of embedded systems that has an effect on
performance?

I wrote

… messurements and traces with DejaView.

So I said nothing explicitly about QNX6. DejaViewe
shows all processing details and what resources
are used. Again … execution of Python under QNX4
or QNX6 doesn’t change the executed code and
doesn’t change which resources are used.
If Python does list processing it just use the
memory allocator … and no other system
resources!

So I believe I made a valid conclusion …

which has absolutely nothing to do with
measuring and tracing the GNU allocator on some other system. You’re
starting to sound like Al Gore. > :slight_smile:

I hope he sounds good :slight_smile:

Armin

24

[edited for your viewing pleasure]

Armin, I said:

| What makes you think that the malloc module is the only place where a
| tradeoff was made in favor of embedded systems that has an effect on
| performance?

What this question asks is why you believe that in QNX6 the only place where
they made a tradeoff in consideration of memory constrained (embedded)
systems as opposed to overall execution speed for a general (desktop)
system? I’m insinuating that there may be other areas where they made
tradeoffs as well, which would make inserting the GNU library perhaps a
partial fix, but would be better served by an official QNX library because
they are going to know where all of the tradeoffs were.

You then answered:

… messurements and traces with DejaView.

Which in response to my question means you have analyzed QNX6 with Dejaview
and performed extensive measurements of all system functions and determined
that the malloc module is the one and only place where a tradeoff was made
at the expense of speed. The question does not ask whether or not malloc is
the sole area responsible for slowing down the Python interpreter. If
that’s what you thought it meant, then that would explain why a few other
folks and I were wondering what the heck you were talking about.

It prompted me to say:

| You’re starting to sound like Al Gore. :slight_smile:

And you to reply:

I hope he sounds good > :slight_smile:

Let’s say he’s got an extremely good chance of becoming the next President
of the United States (not that it’s worth anything in my book :wink:.

-Warren

25

Warren Peece wrote:

[edited for your viewing pleasure]

Armin, I said:

| What makes you think that the malloc module is the only place where a
| tradeoff was made in favor of embedded systems that has an effect on
| performance?

What this question asks is why you believe that in QNX6

Where did I a statement that I believe something
? … in did in the context
of ‘Python/list processing/memory allocation’
messurements and traces under QNX4 which is also
an ‘embedded RTOS’. And I did also just the
conclusion the same code using the same system
resources behave in the same way regardless if
QNX4 or QNX6 is used.

the only place where
they made a tradeoff in consideration of memory constrained (embedded)
systems as opposed to overall execution speed for a general (desktop)
system? I’m insinuating that there may be other areas where they made
tradeoffs as well, which would make inserting the GNU library perhaps a
partial fix,

When you do a detailed messurement and traces you
will be able to see all
problems and tradeoffs … there is no magic.

but would be better served by an official QNX library because
they are going to know where all of the tradeoffs were.

You then answered:

… messurements and traces with DejaView.

Which in response to my question means you have analyzed QNX6 with Dejaview
and performed extensive measurements of all system functions

Sorry, it doesn’t means that =:-/ … where did
I such a statement?

and determined
that the malloc module is the one and only place where a tradeoff was made
at the expense of speed.

That’s just your wrong interpretation … I had in
my mind just the initial list processing + malloc
issue.

However … the question ‘where additional
tradeoffs are made in the expense of speed’ is in
general very interesting.

The question does not ask whether or not malloc is
the sole area responsible for slowing down the Python interpreter. If
that’s what you thought it meant, then that would explain why a few other
folks and I were wondering what the heck you were talking about.

Communication based on imputation are not the best
…

Armin

26

Well Armin, it appears that we’re using different versions of english
because I don’t have any idea how you can construe your answer to my
question as even being remotely related. I was asking about QNX6, and you
were answering about Python. I guess we’ll just leave it at that.

Have a good one…

-Warren

27

Warren Peece wrote:

Well Armin, it appears that we’re using different versions of english

Of course we use ‘different versions’ of english
:slight_smile: … but that is not the root of our
‘difficulties’(?) to communicate.

because I don’t have any idea how you can construe your answer to my
question as even being remotely related.
I was asking about QNX6, and you were answering about Python.

The initial posting was related to Python …

I guess we’ll just leave it at that.

OK … we should not waste our time …

Armin