> Sorry, but it strikes me as an unimpressive proposal to improve the
> efficiency of badly written code.  I took your code and made only four
> changes:
>
> 1. Added operator = (double)
> 2. Added operator += (const complex&)
> 3. Rewrote operator + in terms of operator +=
> 4. Changed a, b, c to file-scope extern so the compiler couldn't optimize
> them away.
>
> Compiled with MSVC7.1 the statements that concern you so much boil down to
> the following (note that I added code to main() to force the results of all
> assignments to be observable so the compiler didn't completely optimize them
> away, so there are gaps in the addresses in the code snippets below).

<snip>

>
> ; 42   :   // more difficult
> ; 43   :   j=a+b+c;
>
>   00071 dd 05 00 00 00 00   fld  QWORD PTR ?a@@3Vcomplex@@A
>   0007b dd 05 08 00 00 00   fld  QWORD PTR ?a@@3Vcomplex@@A+8
>   00082 dd 05 00 00 00 00   fld  QWORD PTR ?b@@3Vcomplex@@A
>   00088 d8 c2   fadd  ST(0), ST(2)
>   0008a dd 5c 24 20  fstp  QWORD PTR _returnvalue$425[esp+48]
>   0008e dd 05 08 00 00 00   fld  QWORD PTR ?b@@3Vcomplex@@A+8
>   00094 d8 c1   fadd  ST(0), ST(1)
>   00096 dd 5c 24 28  fstp  QWORD PTR _returnvalue$425[esp+56]
>   0009a dd d8   fstp  ST(0)
>   0009c dd d8   fstp  ST(0)
>   0009e dd 05 00 00 00 00   fld  QWORD PTR ?c@@3Vcomplex@@A
>   000a4 dc 44 24 20  fadd  QWORD PTR _returnvalue$425[esp+48]
>   000a8 dd 05 08 00 00 00   fld  QWORD PTR ?c@@3Vcomplex@@A+8
>   000ae dc 44 24 28  fadd  QWORD PTR _returnvalue$425[esp+56]
>   000b2 d9 c9   fxch  ST(1)
>   000b4 dd 5c 24 10  fstp  QWORD PTR _j$[esp+48]
>   000b8 dd 5c 24 18  fstp  QWORD PTR _j$[esp+56]
>
> --> A little worse.  The compiler could have done better with a bit more
> dataflow analysis and code-rearranging (to separate the real & imaginary
> parts of the equation & computing each separately).  Still, far from the
> explosion of copying and temporary construction that your paper proposes.

The less than optimal code demonstrated here has little or nothing to do with
deficiencies in the C++ language itself. Probably the biggest hurdle for the
compiler is the stack based nature of the x87 FPU. With MSVC 6.0 I noticed that
the compiler prefers to load and store values from&to memory, rather than
keeping those on the FPU stack. It would be interesting to see what the Intel
compiler makes of all of this. Especially with SSE optimizations enabled.

--
Peter van Merkerk
peter.van.merkerk(at)dse.nl



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <20030524235857.53371e53.mjulier@camembertfree.fr>, Michel de
Montpellier <mjulier@camembertfree.fr> writes
>Hello everybody,
>
>Like many people, I am upset because it is very difficult to do
>efficient calculations in C++. However, C++ is much more convenient
>than C or Fortran, so what can I do?
>
>My solution is a proposal: I suggest inventing a couple a new reserved
>words in order to make C++ much faster for numerical calculation, and
>I call that "Direct C++".
>
>Please read my description (written just today), it is available in
>English (as well as French and Spanish):
>
>       http://mjulier.free.fr/directcxx
>
>And tell me what you think of it!

Have you actually tried using a numerically optimised version of the
Standard C++ Library? Instead of providing your own version of complex
types have you tried the Standard Library version?

C++ provides some extra-ordinarily powerful tools for library
designers/implementors. There are certainly some holes in the Standard
Library's numerical support, but that is because library design for
numerically intense applications requires a kind of domain knowledge
that was not available to the WG21 in the second half of the 1990s.

Well written C++ is always at least as good as well written C. However
the use of such techniques as expression templates can result in the
best C++ leaving C dead in the water for heavy numerical work.

Please demonstrate your need with sample code that uses tools already
available in C++.



--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Michel de Montpellier wrote:
> Hello everybody,
>=20
> Like many people, I am upset because it is very difficult to do
> efficient calculations in C++. However, C++ is much more convenient
> than C or Fortran, so what can I do?

I think that the true-ness of that claim is a classical debate. I=20
recently read an article about type based pointer aliasing analysis that=20
shows that in C++, some computations might actually be faster because=20
the compiler have extra information to perform optimizations.

However, your provided example are convincing indeed!

> My solution is a proposal: I suggest inventing a couple a new reserved
> words in order to make C++ much faster for numerical calculation, and
> I call that "Direct C++".
>=20
> Please read my description (written just today), it is available in
> English (as well as French and Spanish):
>=20
>  http://mjulier.free.fr/directcxx
>=20
> And tell me what you think of it!

Seems interesting to me. I would use it. Let's see what the people say=20
are good reasons for not having them.

>=20
> Michel (physicist, now electronic engineer)
> Montpellier, France
>=20
> ---
> [ comp.std.c++ is moderated.  To submit articles, try just posting with=
 ]
> [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu   =
 ]
> [              --- Please see the FAQ before posting. ---              =
 ]
> [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                      =
 ]
>=20

--=20
+-------------------------------------------------+
| Xavier D=E9coret - Post Doct     |
| Graphics Lab (LCS) - MIT     |
| mailto: decoret@graphics.lcs.mit.edu    |
| home  : http://www.graphics.lcs.mit.edu/~decoret|
+-------------------------------------------------+

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

I am a new programmer, but i have learned a few things about c++. It was
developed in a time were a few megs of ram or less was the standard and it
ran quite well. Why should we be concerned with ram intake when 256 megs is
standard. The only time when you should be concerned with efficientancy is
when you have this massive program. C++ is fine, there are techniques and
many ways to make it more efficent. There is no need to mess with a good
thing.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <JJcAa.23616$A17.1712521@twister.austin.rr.com>, johnncyber
<johnncyber@elp.rr.com> writes
>I am a new programmer, but i have learned a few things about c++. It was
>developed in a time were a few megs of ram or less was the standard and it
>ran quite well. Why should we be concerned with ram intake when 256 megs is
>standard. The only time when you should be concerned with efficientancy is
>when you have this massive program. C++ is fine, there are techniques and
>many ways to make it more efficent. There is no need to mess with a good
>thing.
That may be true for your programs but it is the nature of some
engineering and scientific programs that they have very large amounts of
numerical data and are intensively computational.

A recent trivial example is the recent computation of pi to so many
places that it would take hundreds of CD's to store the result. Of
course there is no practical value in calculating pi to so many places
(other than some obscure reasons in mathematical philosophy concerning
the validity of certain definitions) but the point is that real problems
such as weather forecasting use both large quantities of data and vast
computations, and the results are time sensitive.

--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

> My solution is a proposal: I suggest inventing a couple a new reserved
> words in order to make C++ much faster for numerical calculation, and
> I call that "Direct C++".

Speaking of which-- C++ is a bit behind the times, support for packed
datatypes seem to becoming really commonplace everywhere, except in generic
purpose programming languages. But there is a very little point for adding
them, as would have to choose architechture statically at compile time, and
a lot of C++ compilers already do this with extensions and intrinsics.

A nice language. Maybe in next 20 years it will be upgraded to VectorC++ or
similiar. We'll see. ;-)


Here's example of what generic purpose language, I would prefer to use over
C++, C#, Java... would look like for packed float[4] ;

float4 a = ...;
float4 b = ...;
float4 v = a.xyzw * b.xxyy / 2.0 + a.xxxw;

-- Just a simple example ; notice component selection, this is something
that virtually all SIMD ISA's support. I grown to this syntax lately in GPU
programming world with Cg and HLSL. Same for generic purpose programming
language would be a great productivity enhancer regarding vector algorithm
implementations. There are a lot of programming tasks where this would
be -very- useful, image processing, video encoding/decoding, and other
real-time algorithms. C++ purists would prefer that their language is not
touched, but kept as it is, but on the other hand, if C++ was kept "what it
was", it wouldn't have templates for example in it. That would have been a
great shame...

Time flows forward, it seems that the SIMD isn't going to disappear anytime
soon. C++ could well support the programming paradigms of  SIMD instruction
sets without sacrificing performance on non-SIMD architechtures ; component
selection for instance is just simple offsetting, and easily machine code
generatable on any architechture that has indexing, and since array[] syntax
requires support for it, well, that's pretty much it as far as efficiency is
concerned. Only, this would allow to write the code in vector syntax and the
compiler to vectorize the computation: superior to letting compiler
automatically generating swizzling (though I don't see why it wouldn't be
allowed when compiler detects more optimal instructions can be generated).

...*cough* ... then the truth is, that compiler would be well equiped to
vectorize the code from any conventional input, if it just was written
vectorization mind... things brings us nicely to "normal" vector classes,
and everything remains the same.. but.. never mind.. I shall press "Send"
button now, since wrote this and it was "thoughts of a C++ programmer
today", even if it's bullshit and doesn't make any sense & the writer has
now come to his senses. Anyway, it's my PUNISHMENT for anyone who is
gullible enough to read whatever they can find in the Usenet. Suffer!!! HA
HA HA MAKE YOUR TIME


--
-xXx-


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <JJcAa.23616$A17.1712521@twister.austin.rr.com>,
 on Mon, 26 May 2003 00:46:21 +0000 (UTC),
 johnncyber@elp.rr.com ("johnncyber") wrote:

> I am a new programmer, but i have learned a few things about c++. It was
> developed in a time were a few megs of ram or less was the standard and it
> ran quite well. Why should we be concerned with ram intake when 256 megs is
> standard. The only time when you should be concerned with efficientancy is
> when you have this massive program. C++ is fine, there are techniques and
> many ways to make it more efficent. There is no need to mess with a good
> thing.

You're making the somewhat rash assumption that all environments are
similar to those you are familiar with. Some of use develop for
platforms where 256MB of Ram is not "standard", but a physical
impossibility.

Regards,
 Andy
--
"Light thinks it travels faster than anything but it is wrong. No matter
 how fast light travels it finds the darkness has always got there first,
 and is waiting for it."                  -- Terry Pratchett, Reaper Man

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

johnncyber@elp.rr.com ("johnncyber") wrote in message news:<JJcAa.23616$A17.1712521@twister.austin.rr.com>...
> I am a new programmer, but i have learned a few things about c++. It was
> developed in a time were a few megs of ram or less was the standard and it
> ran quite well. Why should we be concerned with ram intake when 256 megs is
> standard. The only time when you should be concerned with efficientancy is
> when you have this massive program.

... or if you have a battery-powered device, or if you have a CPU with
less than 8Mb cache, or if your program is running concurrently with
a lot of other programs, possibly other instances of the same program ...

Still, the same old rule applies: Write clear code first, measure, then
optimize. Proper C++ techniques (like only private data) allow you to do
so efficiently. A good case is the std::string. Vendors have been able to
optimize it based on actual data, and some implementations now has a more
efficient memory usage for the same interface. I therefore agree there is
no need to rewrite the language from scracth.

Regards,
--
Michiel Salters

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

johnncyber wrote:

> I am a new programmer, but i have learned a few things about c++. It was
> developed in a time were a few megs of ram or less was the standard and it
> ran quite well. Why should we be concerned with ram intake when 256 megs
> is standard.

Every computer in the world doesn't come with 256MB RAM. Some have only a
few bytes of memory to work with, so your what you said is a bit of an
overstatement. (Of course, you seldom program tiny microcontrollers with
C++, but that's another topic...)

--

JP

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Michel de Montpellier wrote:
> Hello everybody,
>
> Like many people, I am upset because it is very difficult to do
> efficient calculations in C++. However, C++ is much more convenient
> than C or Fortran, so what can I do?
>
> My solution is a proposal: I suggest inventing a couple a new reserved
> words in order to make C++ much faster for numerical calculation, and
> I call that "Direct C++".
>
> Please read my description (written just today), it is available in
> English (as well as French and Spanish):
>
> http://mjulier.free.fr/directcxx
>
> And tell me what you think of it!

Sorry, but it strikes me as an unimpressive proposal to improve the
efficiency of badly written code.  I took your code and made only four
changes:

1. Added operator = (double)
2. Added operator += (const complex&)
3. Rewrote operator + in terms of operator +=
4. Changed a, b, c to file-scope extern so the compiler couldn't optimize
them away.

Compiled with MSVC7.1 the statements that concern you so much boil down to
the following (note that I added code to main() to force the results of all
assignments to be observable so the compiler didn't completely optimize them
away, so there are gaps in the addresses in the code snippets below).

; 33   :   complex j(0,1);

  00003 dd 05 00 00 00 00   fld  QWORD PTR __real@0000000000000000
  0000c dd 1c 24  fstp  QWORD PTR _j$[esp+16]
  00010 dd 05 00 00 00 00   fld  QWORD PTR __real@3ff0000000000000
  00016 dd 5c 24 0c  fstp  QWORD PTR _j$[esp+28]

--> that's about as simply as this code can be expressed on x86

; 35   :   // redefine j as 1
; 36   :   j=1;

  0001f dd 05 00 00 00 00   fld  QWORD PTR __real@3ff0000000000000
  00029 dd 5c 24 04  fstp  QWORD PTR _j$[esp+20]
  0002e dd 05 00 00 00 00   fld  QWORD PTR __real@0000000000000000
  00034 dd 5c 24 10  fstp  QWORD PTR _j$[esp+32]

--> likewise


; 39   :   // simple operation
; 40   :   j=a+b;

  0003d dd 05 00 00 00 00   fld  QWORD PTR ?a@@3Vcomplex@@A
  00047 dd 05 08 00 00 00   fld  QWORD PTR ?a@@3Vcomplex@@A+8
  0004e dd 5c 24 24  fstp  QWORD PTR _returnvalue$394[esp+52]
  00052 dc 05 00 00 00 00   fadd  QWORD PTR ?b@@3Vcomplex@@A
  00058 dd 05 08 00 00 00   fld  QWORD PTR ?b@@3Vcomplex@@A+8
  0005e dc 44 24 24  fadd  QWORD PTR _returnvalue$394[esp+52]
  00062 d9 c9   fxch  ST(1)
  00064 dd 5c 24 0c  fstp  QWORD PTR _j$[esp+44]
  00068 dd 5c 24 14  fstp  QWORD PTR _j$[esp+52]

--> Not bad.  Compiler could have done a little better (by not storing the
real part in a temporary), but certinaly not the horrific excess of copying
that your paper proposes.

; 42   :   // more difficult
; 43   :   j=a+b+c;

  00071 dd 05 00 00 00 00   fld  QWORD PTR ?a@@3Vcomplex@@A
  0007b dd 05 08 00 00 00   fld  QWORD PTR ?a@@3Vcomplex@@A+8
  00082 dd 05 00 00 00 00   fld  QWORD PTR ?b@@3Vcomplex@@A
  00088 d8 c2   fadd  ST(0), ST(2)
  0008a dd 5c 24 20  fstp  QWORD PTR _returnvalue$425[esp+48]
  0008e dd 05 08 00 00 00   fld  QWORD PTR ?b@@3Vcomplex@@A+8
  00094 d8 c1   fadd  ST(0), ST(1)
  00096 dd 5c 24 28  fstp  QWORD PTR _returnvalue$425[esp+56]
  0009a dd d8   fstp  ST(0)
  0009c dd d8   fstp  ST(0)
  0009e dd 05 00 00 00 00   fld  QWORD PTR ?c@@3Vcomplex@@A
  000a4 dc 44 24 20  fadd  QWORD PTR _returnvalue$425[esp+48]
  000a8 dd 05 08 00 00 00   fld  QWORD PTR ?c@@3Vcomplex@@A+8
  000ae dc 44 24 28  fadd  QWORD PTR _returnvalue$425[esp+56]
  000b2 d9 c9   fxch  ST(1)
  000b4 dd 5c 24 10  fstp  QWORD PTR _j$[esp+48]
  000b8 dd 5c 24 18  fstp  QWORD PTR _j$[esp+56]

--> A little worse.  The compiler could have done better with a bit more
dataflow analysis and code-rearranging (to separate the real & imaginary
parts of the equation & computing each separately).  Still, far from the
explosion of copying and temporary construction that your paper proposes.

>
> Michel (physicist, now electronic engineer)
> Montpellier, France
>
> ---
> [ comp.std.c++ is moderated.  To submit articles, try just posting
> with ] [ your news-reader.  If that fails, use
> mailto:std-c++@ncar.ucar.edu    ] [              --- Please see the
> FAQ before posting. ---               ] [ FAQ:
> http://www.jamesd.demon.co.uk/csc/faq.html                       ]

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Michel de Montpellier wrote:
>
> Please read my description (written just today), it is available in
> English (as well as French and Spanish):
>
> http://mjulier.free.fr/directcxx
>
> And tell me what you think of it!

I think the most relevant part is...

    My proposal: two new reserved words, "direct" and "result"

    direct: a prefix to define a constructor, an operator, or a
      function (that returns an object), in order to tell the
      compiler that it must transmit the code an object already
      created that will contain the result.

    result: for an operator or a function, that returns an object
      and defined with the reserved word "direct", "result" points
      to the object that must contains the result of the operator
      or of the function. This is just like "this", except that
      instead of pointing to the current object, it points to the
      result. The operators and functions that use "direct" return
      their result with "result", and consequently do not return
      anything with "return".

I think GNU C++ had something like this about ten years ago. Presumably
there are standard arguments for why it isn't needed. Perhaps someone
can remember them, but I'm afraid I can't.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Michel de Montpellier wrote:

> Hello everybody,
>
> Like many people, I am upset because it is very difficult to do
> efficient calculations in C++. However, C++ is much more convenient
> than C or Fortran, so what can I do?
>
> My solution is a proposal: I suggest inventing a couple a new reserved
> words in order to make C++ much faster for numerical calculation, and
> I call that "Direct C++".
>
> Please read my description (written just today), it is available in
> English (as well as French and Spanish):
>
>  http://mjulier.free.fr/directcxx
>
> And tell me what you think of it!

It is quite interesting.. however you should look at the assembler code
that is produced (For such a tiny problem, even if you don't know
assembler it is resonably easy to follow). Actually g++ will do
something quite similar to what you suggest in your "faster C++", as it
will inline tiny functions and if they do nothing, they will disappear.
However in your case it can't do this, as you have filled them with
print statements :)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

K.Hagan@thermoteknix.co.uk ("Ken Hagan") writes:

> Michel de Montpellier wrote:
> >
> > Please read my description (written just today), it is available in
> > English (as well as French and Spanish):
> >
> > http://mjulier.free.fr/directcxx
> >
> > And tell me what you think of it!
>
> I think the most relevant part is...
>
>     My proposal: two new reserved words, "direct" and "result"
>
>     direct: a prefix to define a constructor, an operator, or a
>       function (that returns an object), in order to tell the
>       compiler that it must transmit the code an object already
>       created that will contain the result.
>
>     result: for an operator or a function, that returns an object
>       and defined with the reserved word "direct", "result" points
>       to the object that must contains the result of the operator
>       or of the function. This is just like "this", except that
>       instead of pointing to the current object, it points to the
>       result. The operators and functions that use "direct" return
>       their result with "result", and consequently do not return
>       anything with "return".
>
> I think GNU C++ had something like this about ten years ago. Presumably
> there are standard arguments for why it isn't needed. Perhaps someone
> can remember them, but I'm afraid I can't.
[snip]

Because today g++ can do the same optimization without requiring the
    programmer to put hints in  the code.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hello everybody,

Like many people, I am upset because it is very difficult to do
efficient calculations in C++. However, C++ is much more convenient
than C or Fortran, so what can I do?

My solution is a proposal: I suggest inventing a couple a new reserved
words in order to make C++ much faster for numerical calculation, and
I call that "Direct C++".

Please read my description (written just today), it is available in
English (as well as French and Spanish):

 http://mjulier.free.fr/directcxx

And tell me what you think of it!

Michel (physicist, now electronic engineer)
Montpellier, France

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]