Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
is having a complex type as built-in the languages vs. being in standard package makes performance difference?
32 views
Skip to first unread message
Nasser M. Abbasi
May 16, 2012, 2:25:38 PM5/16/12
to
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
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
gautier...@hotmail.com
May 16, 2012, 3:26:03 PM5/16/12
to n...@12000.org
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.
> 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?
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?).
_________________________
Gautier's Ada programming
http://sf.net/users/gdemont
Georg Bauhaus
May 16, 2012, 3:23:17 PM5/16/12
to
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"
...
> "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
> somehow if complex was built-in vs. being provided by a package,
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
Jerry
May 16, 2012, 5:08:40 PM5/16/12
to
On May 16, 12:23 pm, Georg Bauhaus <rm.dash-bauh...@futureapps.de>
wrote:
The third of these has no table of results.
Jerry
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...
> 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.
>
The third of these has no table of results.
Jerry
georg bauhaus
May 16, 2012, 5:33:37 PM5/16/12
to
Jerry <lance...@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
>
>> 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
might need to run the compiler yourself ;-)
Randy Brukardt
May 16, 2012, 8:19:48 PM5/16/12
to
"Nasser M. Abbasi" <n...@12000.org> wrote in message
news:jp0rf3$5kq$1...@speranza.aioe.org...
...
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.
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
> in late 1970's, why complex type was not included as part of its
> basic data types?
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.
Isaac Gouy
May 16, 2012, 9:48:15 PM5/16/12
to
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......
available, slower programs are removed.
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
> > 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 ;-)
available, slower programs are removed.
0 new messages