comp.lang.ada
 help / color / mirror / Atom feed
* C/Ada performance comparison
@ 2001-06-29 14:19 Tomas Hlavaty
  2001-07-03 16:20 ` Marin David Condic
                   ` (2 more replies)
  0 siblings, 3 replies; 11+ messages in thread
From: Tomas Hlavaty @ 2001-06-29 14:19 UTC (permalink / raw)


Hi,

I have a question about the CPU load of Ada programs. I have a program
reimplemented from C to Ada (Linux, GNAT) and now I've found the Ada
program consumes about 7 times more CPU time than the C one. Is it
common case or does it indicate an error in my Ada implementation (I'm
quite new in Ada)? Is there any comparison/statistics on performance of
C/Ada programs?

I've tried to reduce the CPU time load of the Ada program and I found
some surprising results. I compared rts-fsu and rts-native runtime
environment and I found that rts-fsu is better (lower CPU load and only
one running process per running program compared to rts-native). Why? I
thougth rts-native should be better because it is more oriented towards
the OS (gthreads...). Why is there so many processes when executing
program compiled with rts-native? The Ada program has no tasks.

And the last question: Is there any standard/common way how to implement
synchronous I/O multiplexing like in C (select)?

Thank you,

Tomas

-- 
Tomas Hlavaty                       mailto:hlavaty@labe.felk.cvut.cz
Department of Cybernetics           http://labe.felk.cvut.cz/~hlavaty
Faculty of Electrical Engineering   phone: (+420 2) 2435 7284
Czech Technical University



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: C/Ada performance comparison
  2001-06-29 14:19 C/Ada performance comparison Tomas Hlavaty
@ 2001-07-03 16:20 ` Marin David Condic
  2001-07-03 19:09 ` tmoran
  2001-07-03 22:09 ` Jeffrey Carter
  2 siblings, 0 replies; 11+ messages in thread
From: Marin David Condic @ 2001-07-03 16:20 UTC (permalink / raw)


There shouldn't be any inherent reasons why Ada code should run slower than
C code, but there are lots of problems with comparisons and conversions. You
didn't say what compiler was used for the C program, and this can make a big
difference in performance.

Just mechanically translating C code to Ada may not always give you the best
results. Sometimes this leads to misuse of Ada constructs. You'll want to
try to identify the specific features of the program are consuming all of
the CPU and then re-ask the question. If you have some trace/timing tools to
figure this out, it would help.

Ada provides a lot of runtime checking that C does not - this can lead to a
large slowdown. If the program is working, you may want to eliminate the
runtime checking and see if the performance takes a big jump. Look at
"Pragma Supress" in the ARM and/or your compiler documentation for
appropriate switches to shut off various checks.

If your Ada program has no tasks, it should not (in theory) impose any task
overhead. However, implementations vary. I don't know the answer to this
one, but you may discover a lot if you can do a little bit of timing study.

I'd suggest that you *first* supress all checks and see what that does to
your performance. It is easy to accomplish and may cure most of your ills.
Second, you might want to start throwing in different layers of
optimization - look at the compiler doc for switch values & try some out. If
that doesn't bring the time down significantly, I'd do some timing checks on
major chunks of the code that you think might be consuming the bulk of the
time. If you don't have an analyzer, you can always use Ada.Calendar
features - provided your clock gives you sufficient granularity and you're
not checking at too low a level. Print some start times and stop times &
maybe you'll find something interesting. Repost here with code sections you
think are running unusually slow & maybe we can help you figure out what is
wrong.

On my web page at: http://www.mcondic.com/ and follow the links to:
http://www.mcondic.com/Ada_Programming.html You'll find a section labeled
"Utilities". Look in the code (at: http://www.mcondic.com/util_v3a.txt if
you can't find the link) for a package called: UTIL.Stopwatch - this may be
useful in trying to clock events within your code.

Hope this helps.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Tomas Hlavaty" <hlavaty@labe.felk.cvut.cz> wrote in message
news:3B3C8E6A.39361C75@labe.felk.cvut.cz...
> Hi,
>
> I have a question about the CPU load of Ada programs. I have a program
> reimplemented from C to Ada (Linux, GNAT) and now I've found the Ada
> program consumes about 7 times more CPU time than the C one. Is it
> common case or does it indicate an error in my Ada implementation (I'm
> quite new in Ada)? Is there any comparison/statistics on performance of
> C/Ada programs?
>
> I've tried to reduce the CPU time load of the Ada program and I found
> some surprising results. I compared rts-fsu and rts-native runtime
> environment and I found that rts-fsu is better (lower CPU load and only
> one running process per running program compared to rts-native). Why? I
> thougth rts-native should be better because it is more oriented towards
> the OS (gthreads...). Why is there so many processes when executing
> program compiled with rts-native? The Ada program has no tasks.
>
> And the last question: Is there any standard/common way how to implement
> synchronous I/O multiplexing like in C (select)?
>
> Thank you,
>
> Tomas
>
> --
> Tomas Hlavaty                       mailto:hlavaty@labe.felk.cvut.cz
> Department of Cybernetics           http://labe.felk.cvut.cz/~hlavaty
> Faculty of Electrical Engineering   phone: (+420 2) 2435 7284
> Czech Technical University





^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: C/Ada performance comparison
  2001-06-29 14:19 C/Ada performance comparison Tomas Hlavaty
  2001-07-03 16:20 ` Marin David Condic
@ 2001-07-03 19:09 ` tmoran
  2001-07-03 22:09 ` Jeffrey Carter
  2 siblings, 0 replies; 11+ messages in thread
From: tmoran @ 2001-07-03 19:09 UTC (permalink / raw)


> reimplemented from C to Ada (Linux, GNAT) and now I've found the Ada
> program consumes about 7 times more CPU time than the C one. Is it
> common case or does it indicate an error in my Ada implementation (I'm
> quite new in Ada)?
  Something is seriously screwed up.  Perhaps you are over-using some nice
feature that is actually rather expensive?  Run a profiler to see where
all the time is going.

>Is there any comparison/statistics on performance of C/Ada programs?
  Look in www.adapower.com for some papers on the subject.



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: C/Ada performance comparison
  2001-06-29 14:19 C/Ada performance comparison Tomas Hlavaty
  2001-07-03 16:20 ` Marin David Condic
  2001-07-03 19:09 ` tmoran
@ 2001-07-03 22:09 ` Jeffrey Carter
  2001-07-04 17:27   ` Colin Paul Gloster
  2001-07-05 13:37   ` Marin David Condic
  2 siblings, 2 replies; 11+ messages in thread
From: Jeffrey Carter @ 2001-07-03 22:09 UTC (permalink / raw)


Tomas Hlavaty wrote:
> 
> I have a question about the CPU load of Ada programs. I have a program
> reimplemented from C to Ada (Linux, GNAT) and now I've found the Ada
> program consumes about 7 times more CPU time than the C one. Is it
> common case or does it indicate an error in my Ada implementation (I'm
> quite new in Ada)? Is there any comparison/statistics on performance of
> C/Ada programs?

In general, equivalent Ada and C programs have equivalent run times.
Robert Dewar claims to have a collection of equivalent programs that
produce identical object code when compiled using gcc.

A factor of 7 implies that the programs are not equivalent. I suggest
you unknowingly used an expensive feature of Ada. Different levels of
optimization might also account for the difference.

Although one of the factors for programs to be equivalent is run-time
checks, I would not expect them to give a factor of 7 difference.
Suppressing Ada run-time checks usually does not reduce run times by
more than about 10%.

-- 
Jeffrey Carter



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: C/Ada performance comparison
  2001-07-03 22:09 ` Jeffrey Carter
@ 2001-07-04 17:27   ` Colin Paul Gloster
  2001-07-04 17:43     ` Samuel Tardieu
  2001-07-05 13:37   ` Marin David Condic
  1 sibling, 1 reply; 11+ messages in thread
From: Colin Paul Gloster @ 2001-07-04 17:27 UTC (permalink / raw)


Jeffrey Carter wrote:
"Tomas Hlavaty wrote:
>
> I have a question about the CPU load of Ada programs. I have a program
> reimplemented from C to Ada (Linux, GNAT) and now I've found the Ada
> program consumes about 7 times more CPU time than the C one. Is it
> common case or does it indicate an error in my Ada implementation (I'm
> quite new in Ada)? Is there any comparison/statistics on performance of
> C/Ada programs?

In general, equivalent Ada and C programs have equivalent run times.
Robert Dewar claims to have a collection of equivalent programs that
produce identical object code when compiled using gcc.

A factor of 7 implies that the programs are not equivalent. [..]"

If there is dynamic memory in the program then an Ada83 program
owing to a cautious policy can hog much more memory than an
equivalent C program. However, Ada95 overcame this and if he
is using GNAT (and is new to it) it is extremely unlikely that his
default switches are set to Ada83 so he is probably using Ada95.
Aside from that after writing some of this I looked back and saw
Tomas Hlavaty was talking about processor load and not memory
consumption. Oh well...posting this anyway.




^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: C/Ada performance comparison
  2001-07-04 17:27   ` Colin Paul Gloster
@ 2001-07-04 17:43     ` Samuel Tardieu
  2001-07-05  7:12       ` Colin Paul Gloster
  0 siblings, 1 reply; 11+ messages in thread
From: Samuel Tardieu @ 2001-07-04 17:43 UTC (permalink / raw)
  To: comp.lang.ada

On  4/07, Colin Paul Gloster wrote:

| A factor of 7 implies that the programs are not equivalent. [..]

A typical example of that non-equivalence is a user not turning off exception
checks. An Ada program with exceptions is not the equivalent of a C program
without them.




^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: C/Ada performance comparison
  2001-07-04 17:43     ` Samuel Tardieu
@ 2001-07-05  7:12       ` Colin Paul Gloster
  2001-07-05 11:55         ` Larry Kilgallen
  2001-07-05 21:46         ` Robert Dewar
  0 siblings, 2 replies; 11+ messages in thread
From: Colin Paul Gloster @ 2001-07-05  7:12 UTC (permalink / raw)


Samuel Tardieu <sam@rfc1149.net> wrote: "On  4/07, Colin Paul Gloster wrote:

| A factor of 7 implies that the programs are not equivalent. [..]

A typical example of that non-equivalence is a user not turning
off exception
checks. An Ada program with exceptions is not the equivalent of a
C program
without them."

I do not know of anyone who claimed that an Ada program with
exceptions is equivalent to a C program sans them. I did say that
an equivalent Ada83 program wherein the C and Ada83 versions
use dynamic memory can hog a lot more memory than the C
version. So far as we know, Tomas Hlavaty's Ada source has no
such thing as exception handling. An Ada and a C program can be
equivalent and that Ada(95, and 83) has better optional features which
would impact performance does not mean that an equivalent program
has to use similar resource levels to the C original. The factor of seven
may hint that exceptions are used but a hint is not a proof.




^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: C/Ada performance comparison
  2001-07-05  7:12       ` Colin Paul Gloster
@ 2001-07-05 11:55         ` Larry Kilgallen
  2001-07-05 21:46         ` Robert Dewar
  1 sibling, 0 replies; 11+ messages in thread
From: Larry Kilgallen @ 2001-07-05 11:55 UTC (permalink / raw)


In article <3B44135F.90D9711A@ACM.org>, Colin Paul Gloster <Colin_Paul_Gloster@ACM.org> writes:
> Samuel Tardieu <sam@rfc1149.net> wrote: "On  4/07, Colin Paul Gloster wrote:
> 
> | A factor of 7 implies that the programs are not equivalent. [..]
> 
> A typical example of that non-equivalence is a user not turning
> off exception
> checks. An Ada program with exceptions is not the equivalent of a
> C program
> without them."
> 
> I do not know of anyone who claimed that an Ada program with
> exceptions is equivalent to a C program sans them. I did say that
> an equivalent Ada83 program wherein the C and Ada83 versions
> use dynamic memory can hog a lot more memory than the C
> version. So far as we know, Tomas Hlavaty's Ada source has no
> such thing as exception handling. An Ada and a C program can be
> equivalent and that Ada(95, and 83) has better optional features which
> would impact performance does not mean that an equivalent program
> has to use similar resource levels to the C original. The factor of seven
> may hint that exceptions are used but a hint is not a proof.

Exception checks do not require any specific invocation in the source.
On some processors, there are no hardware functions to detect certain
exceptional conditions, so an Ada compiler will generate extra code
to check for such conditions and raise and exception if necessary.

I don't think there are any processors with hardware functions to
achieve array bounds checking, so things like that will always be
in generated Ada code (unless you run the Ada compiler in a mode
to turn them off).



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: C/Ada performance comparison
  2001-07-03 22:09 ` Jeffrey Carter
  2001-07-04 17:27   ` Colin Paul Gloster
@ 2001-07-05 13:37   ` Marin David Condic
  2001-07-05 14:49     ` Jean-Pierre Rosen
  1 sibling, 1 reply; 11+ messages in thread
From: Marin David Condic @ 2001-07-05 13:37 UTC (permalink / raw)


In general, I'd agree. However, there might be cases where this is not true.
If, for example, I'm doing a lot of computations in a tight loop over a
really large number of iterations, the constraint checking of numeric values
might add a considerable overhead. Imagine you write X := X + 1 ; That ought
to degenerate to a single add instruction with descent optimization, but if
you have to do the computation then check that you have not exceeded the
range of X's subtype and possibly do something to raise Constraint_Error,
that single instruction can expand to quite a few. Do that in a tight loop a
million times or so and you'll see some significant changes in performance.

Just for the record, turning off the checks should result in code just as
tight as what you'd get from a C compiler for a similar operation.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Jeffrey Carter" <jeffrey.carter@boeing.com> wrote in message
news:3B424298.9A7849CF@boeing.com...
> Tomas Hlavaty wrote:
>
> Although one of the factors for programs to be equivalent is run-time
> checks, I would not expect them to give a factor of 7 difference.
> Suppressing Ada run-time checks usually does not reduce run times by
> more than about 10%.
>






^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: C/Ada performance comparison
  2001-07-05 13:37   ` Marin David Condic
@ 2001-07-05 14:49     ` Jean-Pierre Rosen
  0 siblings, 0 replies; 11+ messages in thread
From: Jean-Pierre Rosen @ 2001-07-05 14:49 UTC (permalink / raw)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1326 bytes --]


"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> a �crit dans le message news: 9i1qig$36o$1@nh.pace.co.uk...
> In general, I'd agree. However, there might be cases where this is not true.
> If, for example, I'm doing a lot of computations in a tight loop over a
> really large number of iterations, the constraint checking of numeric values
> might add a considerable overhead. Imagine you write X := X + 1 ; That ought
> to degenerate to a single add instruction with descent optimization, but if
> you have to do the computation then check that you have not exceeded the
> range of X's subtype and possibly do something to raise Constraint_Error,
> that single instruction can expand to quite a few. Do that in a tight loop a
> million times or so and you'll see some significant changes in performance.
>
Sure. But don't forget that you can put a pragma suppress in a declare block, so that it will affect only that sequence which is
truly critical, and not the 99% of the remaining code.

Too often, people think that checks are "on" or "off" for the whole program (which happens if you do that with a compiler option).
Ada provides finer granularity.

--
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr





^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: C/Ada performance comparison
  2001-07-05  7:12       ` Colin Paul Gloster
  2001-07-05 11:55         ` Larry Kilgallen
@ 2001-07-05 21:46         ` Robert Dewar
  1 sibling, 0 replies; 11+ messages in thread
From: Robert Dewar @ 2001-07-05 21:46 UTC (permalink / raw)


Colin Paul Gloster <Colin_Paul_Gloster@ACM.org> wrote in message news:<3B44135F.90D9711A@ACM.org>...
> I did say that
> an equivalent Ada83 program wherein the C and Ada83 versions
> use dynamic memory can hog a lot more memory than the C
> version.

Then the Ada program is NOT equivalent, or else the compiler you are
using is not equivalent, period.



^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2001-07-05 21:46 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-06-29 14:19 C/Ada performance comparison Tomas Hlavaty
2001-07-03 16:20 ` Marin David Condic
2001-07-03 19:09 ` tmoran
2001-07-03 22:09 ` Jeffrey Carter
2001-07-04 17:27   ` Colin Paul Gloster
2001-07-04 17:43     ` Samuel Tardieu
2001-07-05  7:12       ` Colin Paul Gloster
2001-07-05 11:55         ` Larry Kilgallen
2001-07-05 21:46         ` Robert Dewar
2001-07-05 13:37   ` Marin David Condic
2001-07-05 14:49     ` Jean-Pierre Rosen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox