|
|
 Up |
  |
Author: DamianDamian Date: Jul 12, 2008 08:49
This is a slightly modified reposting of an earlier posting that
received no replies:
C++ has a construct referred to as expression templates that make it
possible to greatly increase the speed and decrease the memory
utilization of programs that use overloaded arithmetic ("defined
operators and assignments" in Fortran). While I don't know enough to
advocate adopting the C++ approach, I do think that not having a
solution to the problem expression templates solves puts Fortran at a
very significant disadvantage in performance and it seems to me that
performance is one of the most cited reasons for using Fortran.
Consider the following:
type(foo) :: a,b,c,d
d = a + b*c
where =, +, and * are a defined assignment and two defined operators.
Since many (most?) modern microprocessors can perform a multiply/add
combination in a single clock cycle, it's a travesty to have separate
procedures for + and *. But combining them into one procedure such
as
d = add_multiply(a,b,c)
|
| Show full article (2.77Kb) |
| 24 Comments |
|
|
Author: Dick HendricksonDick Hendrickson Date: Jul 12, 2008 11:27
Damian wrote:
> This is a slightly modified reposting of an earlier posting that
> received no replies:
>
> C++ has a construct referred to as expression templates that make it
> possible to greatly increase the speed and decrease the memory
> utilization of programs that use overloaded arithmetic ("defined
> operators and assignments" in Fortran). While I don't know enough to
> advocate adopting the C++ approach, I do think that not having a
> solution to the problem expression templates solves puts Fortran at a
> very significant disadvantage in performance and it seems to me that
> performance is one of the most cited reasons for using Fortran.
>
> Consider the following:
>
> type(foo) :: a,b,c,d
>
> d = a + b*c
>
> where =, +, and * are a defined assignment and two defined operators. ...
|
| Show full article (3.89Kb) |
| no comments |
|
|
Author: nospamnospam Date: Jul 12, 2008 11:44
Dick Hendrickson att.net> wrote:
> But, why do you think that expression will resolve into a
> combined multiply add? Surely in any reasonable program
> the derived types will have complicated insides and the
> operating procedures will do more than just multiply
> or add a single component.
Particularly when, as
> Damian wrote:
>> ...especially important when each object contains large amounts of
>> data (gigabytes in my applications).
...
>> But combining them into one procedure such as
>>
>> d = add_multiply(a,b,c)
>>
>> is a travesty in terms of notational clarity in my view (particularly
>> for much longer expressions).
|
| Show full article (1.10Kb) |
| no comments |
|
|
Author: dpbdpb Date: Jul 12, 2008 14:07
Damian wrote:
> This is a slightly modified reposting of an earlier posting that
> received no replies:
...
> Consider the following:
>
> type(foo) :: a,b,c,d
>
> d = a + b*c
>
> where =, +, and * are a defined assignment and two defined operators.
> Since many (most?) modern microprocessors can perform a multiply/add
> combination in a single clock cycle, it's a travesty to have separate
> procedures for + and *. ...
...
Where I'm confused mostly is that if the expression at the TYPE level
resolves at the implementation level to a combined multiply/add and the
processor has the facility, why wouldn't you expect the compiler
optimizer to recognize that anyway?
|
| Show full article (0.72Kb) |
| no comments |
|
|
Author: DamianDamian Date: Jul 12, 2008 19:12
On Jul 12, 11:44 am, nos...@see.signature (Richard Maine) wrote:
> Dick Hendrickson att.net> wrote:>> But, why do you think that expression will resolve into a
>> combined multiply add? Surely in any reasonable program
>> the derived types will have complicated insides and the
>> operating procedures will do more than just multiply
>> or add a single component.
>
> Particularly when, as
>
>
>
>> Damian wrote:
>>> ...especially important when each object contains large amounts of
>>> data (gigabytes in my applications).
> ...
>>> But combining them into one procedure such as
>
>>> d = add_multiply(a,b,c)
> ...
|
| Show full article (4.57Kb) |
| no comments |
|
|
Author: DamianDamian Date: Jul 12, 2008 20:16
On Jul 12, 2:07 pm, dpb non.net> wrote:> Damian wrote:
>> This is a slightly modified reposting of an earlier posting that
>> received no replies:
> ...
>> Consider the following:
>
>> type(foo) :: a,b,c,d
>
>> d = a + b*c
>
>> where =, +, and * are a defined assignment and two defined operators.
>> Since many (most?) modern microprocessors can perform a multiply/add
>> combination in a single clock cycle, it's a travesty to have separate
>> procedures for + and *. ...
>
> ...
>
> Where I'm confused mostly is that if the expression at the TYPE level
> resolves at the implementation level to a combined multiply/add and the ...
|
| Show full article (1.58Kb) |
| no comments |
|
|
Author: dpbdpb Date: Jul 12, 2008 21:19
Damian wrote:
...
> ... I guess I'm assuming
> that if the compilers could generally be trusted to do this no matter
> how complicated the expression, then the whole notion of expression
> templates would not exist in C++, but maybe there are specific reasons
> why it's harder for C++ compilers to do the desired interprocedural
> optimizations than it is for Fortran compilers. ...
I'll admit I'm not that up on C++ templates but it wasn't my
understanding their purpose was for optimization but for generalization
of code at the source level???
--
|
| |
| no comments |
|
|
Author: Tim PrinceTim Prince Date: Jul 12, 2008 22:30
Damian wrote:
> On Jul 12, 2:07 pm, dpb non.net> wrote:>> Damian wrote:
>>> This is a slightly modified reposting of an earlier posting that
>>> received no replies:
>> ...
>>> Consider the following:
>>> type(foo) :: a,b,c,d
>>> d = a + b*c
>>> where =, +, and * are a defined assignment and two defined operators.
>>> Since many (most?) modern microprocessors can perform a multiply/add
>>> combination in a single clock cycle, it's a travesty to have separate
>>> procedures for + and *. ...
>> ...
>>
>> Where I'm confused mostly is that if the expression at the TYPE level
>> resolves at the implementation level to a combined multiply/add and the
>> processor has the facility, why wouldn't you expect the compiler
>> optimizer to recognize that anyway?
>> ...
|
| Show full article (2.79Kb) |
| no comments |
|
|
Author: Tim PrinceTim Prince Date: Jul 12, 2008 23:03
dpb wrote:
> Damian wrote:
> ...
>> ... I guess I'm assuming
>> that if the compilers could generally be trusted to do this no matter
>> how complicated the expression, then the whole notion of expression
>> templates would not exist in C++, but maybe there are specific reasons
>> why it's harder for C++ compilers to do the desired interprocedural
>> optimizations than it is for Fortran compilers. ...
>
> I'll admit I'm not that up on C++ templates but it wasn't my
> understanding their purpose was for optimization but for generalization
> of code at the source level???
>
> --
Certain C++ templates can be an advantage for optimization, at least
inner_product(), when seen as a partial equivalent of Fortran dot_product.
If these things can't be optimized, there's no hope for C++ to be
competitive.
The usual template practice of "loop until reaching object past end of ...
|
| Show full article (2.05Kb) |
| no comments |
|
|
Author: DamianDamian Date: Jul 13, 2008 03:18
On Jul 12, 10:30 pm, Tim Prince nospamcomputer.org> wrote:> Damian wrote:
>> On Jul 12, 2:07 pm, dpb non.net> wrote:>>> Damian wrote:
>>>> This is a slightly modified reposting of an earlier posting that
>>>> received no replies:
>>> ...
>>>> Consider the following:
>>>> type(foo) :: a,b,c,d
>>>> d = a + b*c
>>>> where =, +, and * are a defined assignment and two defined operators.
>>>> Since many (most?) modern microprocessors can perform a multiply/add
>>>> combination in a single clock cycle, it's a travesty to have separate
>>>> procedures for + and *. ...
>>> ...
>
>>> Where I'm confused mostly is that if the expression at the TYPE level
>>> resolves at the implementation level to a combined multiply/add and the
>>> processor has the facility, why wouldn't you expect the compiler
>>> optimizer to recognize that anyway? ...
|
| Show full article (5.92Kb) |
| no comments |
|
|
|
|
