From 2520657904503507537 X-Google-Thread: f78e5,52112cea9d2ccd4a X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!newsread.com!news-xfer.newsread.com!news.alt.net!comp-std-cpp-robomod!not-for-mail From: "Andrei Alexandrescu (See Website for Email)" Newsgroups: comp.std.c++ Subject: Re: =?ISO-8859-1?Q?=A75=2E2=2E2/8_unspecified_evluation_od?= =?ISO-8859-1?Q?er=3F?= Date: 3 Aug 2005 15:40:22 GMT Organization: Computer Science & Engineering, U of Washington, Seattle Lines: 53 Approved: Fergus Henderson , moderator of comp.std.c++ Message-ID: <42F0DC02.9030402@moderncppdesign.com> References: <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> <1122984019.538752.167550@g43g2000cwa.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.9) Gecko/20050711 Thunderbird/1.0.5 Mnenhy/0.7.1 X-Nntp-Posting-Host: cpe-24-29-158-198.nyc.res.rr.com X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU Xref: g2news1.google.com comp.std.c++:1632 kanze@gabi-soft.fr wrote: > IMHO, the whole argument is becoming ridiculous. On one hand, > some people are claiming that there might be a machine somewhere > where the freedom to reorder might make a difference, and far > more unlikely, that this difference will be measurable in code > where the compiler could not reorder simply under the as if > rule. Claiming -- to date, no one has ever really shown a case > where it's true. What those people might not know is that modern compiler and processor technology does enable reordering in a lot of the cases that matter. The existing rule only allowed the compiler to not spend time on proving that reordering is safe; that would have slowed compilation down. In the case of function calls, the function call and execution overhead would dwarf put the overhead (if any!) of putting things on the stack in a different order. As Hyman has noted, "push" shouldn't be thought of as faster just because it's a machine instruction. Int the RISC core it's still the well-known sequence of operations (decrement stack pointer register and store a register through it). It could actually be argued that adjusting the stack pointer only once and putting everything on the stack via indexed access is faster on many machines. Of course, by today's rule implementations can use a similar code generation strategy. What I'm saying is that "push"ing isn't the fastest way out there. In the case of expressions that could benefit from reordering, there's good news, too - today's compilers routinely reorder code whenever behavior is conserved, in order to reveal and exploit instruction-level parallelism. Mostly cases that would be undefined by today's rule - such as f(++i, ++i) - would be executed "conservatively". In addition, some cases in which the compiler can't prove lack of aliasing might generate more conservative code. I'd think those cases are in minority, and that the performance loss in those cases is also exceedingly small. > On the other, you have people arguing for simple predictability, > and meeting intuitive programmer expectations. And it's about time to increase awareness about these issues. So, James and I are pulling the same direction... now don't tell me you gave up on SESE. :o) Andrei --- [ 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 ]