is having a complex type as built-in the languages vs. being in standard package makes performance difference?

is having a complex type as built-in the languages vs. being in standard package makes performance difference?

[Nasser M. Abbasi]

Just a basic question for the experts.

Ada provides complex data types by a package:

http://progopedia.com/language/ada/

"Ada provides complex datatype, which requires using
packages Generic_Complex_Types and Generic_Complex_Elementary_Functions
and instantiating them with the type of complex number to use"

While a language like Fortran, complex type is 'built-in' the
language, i.e. part of the language intrinsic data types.

What I wondered about is: would this makes a difference when it comes
to the performance of generated code that uses these types in
computations?

i.e. Would the code generated by the compiler by more 'efficient'
somehow if complex was built-in vs. being provided by a package,
or do you think by the time the compiler is done with the code
generation and optimization, then this all becomes irrelevant
'similar' compiler backend generated code will eventually
result in terms of efficiency of the computation?

(It might be possible actually to see this using gcc since
it supports both gnat and gfortran as front end?).

On a side-note, any one knows why when Ada was originally designed
in late 1970's, why complex type was not included as part of its
basic data types?

thanks,
--Nasser

Re: is having a complex type as built-in the languages vs. being in standard package makes performance difference?

[Georg Bauhaus]

On 16.05.12 20:25, Nasser M. Abbasi wrote:

> "Ada provides complex datatype, which requires using
> packages Generic_Complex_Types and Generic_Complex_Elementary_Functions
> and instantiating them with the type of complex number to use"
...
> i.e. Would the code generated by the compiler by more 'efficient'
> somehow if complex was built-in vs. being provided by a package,

Not a definitive statement on compilers, but some guesses based
on evidence:
If the two components could be cleverly used by the compiler so that
GCCs auto-vectorization becomes effective, maybe. To see advantages
in manipulating (re, im) explicitly and separately now,
these programs demonstrate by computing the same output
at very different speed.

http://shootout.alioth.debian.org/u64/program.php?test=mandelbrot&lang=gnat&id=3
http://shootout.alioth.debian.org/u64/program.php?test=mandelbrot&lang=gnat&id=2
http://shootout.alioth.debian.org/u64/program.php?test=mandelbrot&lang=gnat&id=1

Re: is having a complex type as built-in the languages vs. being in standard package makes performance difference?

[Jerry]

On May 16, 12:23 pm, Georg Bauhaus <rm.dash-bauh...@futureapps.de>
wrote:
> If the two components could be cleverly used by the compiler so that
> GCCs auto-vectorization becomes effective, maybe. To see advantages
> in manipulating (re, im) explicitly and separately now,
> these programs demonstrate by computing the same output
> at very different speed.
>
> http://shootout.alioth.debian.org/u64/program.php?test=mandelbrot&lan...http://shootout.alioth.debian.org/u64/program.php?test=mandelbrot&lan...http://shootout.alioth.debian.org/u64/program.php?test=mandelbrot&lan...

The third of these has no table of results.
Jerry

Re: is having a complex type as built-in the languages vs. being in standard package makes performance difference?

[georg bauhaus]

Jerry <lanceboyle@qwest.net> wrote:
>
>> http://shootout.alioth.debian.org/u64/program.php?test=mandelbrot&lan...http://shootout.alioth.debian.org/u64/program.php?test=mandelbrot&lan...http://shootout.alioth.debian.org/u64/program.php?test=mandelbrot&lan...
> 
> The third of these has no table of results.
> Jerry

They do not always measure all programs ever submitted, in this case you
might need to run the compiler yourself ;-)

Re: is having a complex type as built-in the languages vs. being in standard package makes performance difference?

[Isaac Gouy]

On May 16, 2:33 pm, georg bauhaus <rmhost.bauh...@maps.arcor.de>
wrote:
> Jerry <lancebo...@qwest.net> wrote:
>
> >>http://shootout.alioth.debian.org/u64/program.php?test=mandelbrot&lan......
>
> > The third of these has no table of results.
> > Jerry
>
> They do not always measure all programs ever submitted, in this case you
> might need to run the compiler yourself ;-)


"They" did (back in July 2009) but as faster programs become
available, slower programs are removed.

Re: is having a complex type as built-in the languages vs. being in standard package makes performance difference?

[gautier_niouzes]

Le mercredi 16 mai 2012 20:25:38 UTC+2, Nasser M. Abbasi a écrit :

> Just a basic question for the experts.
> 
> Ada provides complex data types by a package:
> 
> http://progopedia.com/language/ada/
> 
> "Ada provides complex datatype, which requires using
> packages Generic_Complex_Types and Generic_Complex_Elementary_Functions
> and instantiating them with the type of complex number to use"
> 
> While a language like Fortran, complex type is 'built-in' the
> language, i.e. part of the language intrinsic data types.
> 
> What I wondered about is: would this makes a difference when it comes
> to the performance of generated code that uses these types in
> computations?
> 
> i.e. Would the code generated by the compiler by more 'efficient'
> somehow if complex was built-in vs. being provided by a package,
> or do you think by the time the compiler is done with the code
> generation and optimization, then this all becomes irrelevant
> 'similar' compiler backend generated code will eventually
> result in terms of efficiency of the computation?

The chances are better to have efficient machine code when operations on those types are built-in. The good news is that is is possible even by having to reference a package, thanks to the pragma Intrinsic; see GNAT's package Interfaces. The fact that a type is immediatly visible or not doesn't change things.
For what matters the Complex types, the pragma Inline on the operators, plus the optimizations, are probably sufficient. Did you try to time the same algorithms with gfortran and gnat (with -gnatpn) and switch on -O3, the SSE options etc. on both ?

> (It might be possible actually to see this using gcc since
> it supports both gnat and gfortran as front end?).

Sure: compile with -S compile option to keep the assembler output.
_________________________ 
Gautier's Ada programming 
http://sf.net/users/gdemont

Re: is having a complex type as built-in the languages vs. being in standard package makes performance difference?

[Randy Brukardt]

"Nasser M. Abbasi" <nma@12000.org> wrote in message 
news:jp0rf3$5kq$1@speranza.aioe.org...
...
> On a side-note, any one knows why when Ada was originally designed
> in late 1970's, why complex type was not included as part of its
> basic data types?

I think it was considered much less frequently used than the other 
datatypes, and probably that it had a high overhead for small embedded 
systems. So not including it by default made sense.

(Our early Janus/Ada compilers had floating point optional, because of the 
high overhead on small machines like the Z80 CP/M machines that we started 
out on. The float library took up 20% of the code space on those machines, 
so it was rarely used. Complex is used a lot less often than basic floats.)

                                          Randy.