From -1145061277386419945
X-Google-Thread: f78e5,52112cea9d2ccd4a
X-Google-Attributes: gidf78e5,public
X-Google-Language: ENGLISH,ASCII-7-bit
Path: g2news1.google.com!news2.google.com!newsfeed.gamma.ru!Gamma.RU!skynet.be!peer-uk.news.demon.net!kibo.news.demon.net!news.demon.co.uk!demon!stump.algebra.com!devnull
From: hyrosen@mail.com (Hyman Rosen)
Newsgroups: comp.std.c++
Subject: Re: =?ISO-8859-1?Q?=A75=2E2=2E2/8_unspecified_evluation_od?=
 =?ISO-8859-1?Q?er=3F?=
Date: Mon,  1 Aug 2005 22:05:03 GMT
Lines: 39
Sender: mail2news@demon.net
Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++)
Message-ID: <200508011747.j71HlbuC069360@horus.isnic.is>
References: <CsidnX1xcd4C73_fRVn-tA@speakeasy.net>
 <42E4EB01.9020700@alumina.nl> <42E64CCE.7030708@cs.york.ac.uk>
 <42E68BDD.1050701@alumina.nl>
 <1122649512.879866.38000@g44g2000cwa.googlegroups.com>
 <3l12o0F10nuusU1@individual.net> <0RfHe.2500$%a2.1721@trndny03>
 <3l5u7qFvrvk8U1@individual.net>
NNTP-Posting-Host: news.news.demon.net
Mime-Version: 1.0
Content-Type: text/plain; format=flowed; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Trace: news.demon.co.uk 1122933917 21935 158.152.254.254 (1 Aug 2005 22:05:17 GMT)
X-Complaints-To: abuse@demon.net
NNTP-Posting-Date: Mon, 1 Aug 2005 22:05:17 +0000 (UTC)
X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov)
X-User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU
X-Received: (from fjh@localhost)
	by mulga.cs.mu.OZ.AU (8.12.10+Sun/8.12.9/Submit) id j71M53ij001506;
	Tue, 2 Aug 2005 08:05:03 +1000 (EST)
X-Path: comp-std-cpp-robomod!not-for-mail
X-Delivered-To: std-c++@ucar.edu
X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f
X-Newsgroups: comp.std.c++
Xref: g2news1.google.com comp.std.c++:1592

Bo Persson wrote:
> The problem is not so much for the silly p(f(), f(), f()), but for 
> p(f(), g(), h()), where it might be expensive to store some of the 
> intermediate results, while calculating the others.

There are no intermediate results, only function parameters being
initialized. Assuming an architecture that doesn't pass them in
registers anyway, it is possibly the difference between
     call h; push $r; call g; push $r; call f; push $r; call p;
and
     sub 12, $sp;
     call f; mov $r 8($sp);
     call g; mov $r 4($sp);
     call h; mov $r 0($sp);
     call p;

Now, maybe that's significantly slower. But that assumes nearly
no time taken by the calls themselves, nor does it take cognizance
of the modern CPUs which prefetch addresses, execute speculatively,
and have extensive caches. In fact, the Pentium has to take special
pains to make the push instruction efficient, because normally using
a register as an address immediately after modifying it causes a
pipeline stall.

 > If we specify a certain order, just becase some of us belive that it
 > will sometimes be handy

No, the handiness is just a convenient side effect of the real reason
we must specify the order, which is that no one understands the current
rules or gets them right, when they even realize that there is something
to worry about. And that goes for experts and novices alike, as we have
seen over and over again in this newsgroup.

---
[ 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                       ]