Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Short-circuiting in C

Reply
Thread Tools

Short-circuiting in C

 
 
Dr Nick
Guest
Posts: n/a
 
      06-11-2011
Eric Sosman <(E-Mail Removed)> writes:

> On 5/31/2011 3:22 PM, Edward A. Falk wrote:
>> In article<irmuo5$u9t$(E-Mail Removed)>,
>> Eric Sosman<(E-Mail Removed)> wrote:
>>>
>>> C has no way to express the computation you desire. ...

>>
>> See my previous post. OP is working with a cpu that doesn't
>> have multiple threads of execution, per se, but does have
>> parallel threads of computation.

>
> C has no way to express "parallel threads of computation"
> (except in the restrictive senses of volatile variables and
> asynchronous signals).
>
>> Imagine:
>>
>> a = x1 * x2 + x3;
>> b = y1 * y2 + y3;
>> c = z1 * z2 + z3;
>>
>> I've worked on a CPU that could compute those three expressions
>> in perfect parallel. We made sure our compiler recognized cases
>> like this and optimized accordingly.

>
> Fine: Your compiler made promises that are not made by C and
> are not expressible in C. There's nothing preventing you from
> making such promises, and in the right circumstances such promises
> are useful and laudable. But they're *your* promises, not C's,
> and compilers other than your own are under no obligation to pay
> the slightest heed to them. C has no way to tell those other
> compilers about a desire for parallelism, nor any means to detect
> a promise broken.
>
>> I think OP's problem is that the (a&& b&& c) short-circuiting
>> is preventing the compiler from computing those values in
>> parallel. That's really a failure on the compiler's part, but
>> OP is hoping there's a way to hint to the compiler that
>> short-circuiting is not necessary.
>>
>> And yes, without extending the language, there's no way to
>> *force* the compiler to compute that stuff in parallel.

>
> Exactly. The O.P. needs something other than C, or something
> in addition to C.


To be fair, and I know I'm coming late to the party, the OP was asking
"is there a way to express what C usually does by a && b && c that
doesn't do the short-circuiting behaviour" and then explained why. That
seemed an entirely reasonable question about C. People suggested
several ways and all pointed out that this couldn't guarantee it (and
also that a really good compiler for his platform could cope with a && b
&& c in the way he wanted).
--
Online waterways route planner | http://canalplan.eu
Plan trips, see photos, check facilities | http://canalplan.org.uk
 
Reply With Quote
 
 
 
 
Shao Miller
Guest
Posts: n/a
 
      06-11-2011
On 6/11/2011 11:07 AM, Dr Nick wrote:
>
> To be fair, and I know I'm coming late to the party, the OP was asking
> "is there a way to express what C usually does by a&& b&& c that
> doesn't do the short-circuiting behaviour" and then explained why. That
> seemed an entirely reasonable question about C. People suggested
> several ways and all pointed out that this couldn't guarantee it (and
> also that a really good compiler for his platform could cope with a&& b
> && c in the way he wanted).


"Couldn't guarantee it" <- what is "it?" Avoiding the short-circuiting
behaviour? Examples were given for constructs which evaluate all of
'a', 'b', 'c' and then choose a path based on the truth of 'a && b &&
c', even though that expression is not used in the constructs.
 
Reply With Quote
 
 
 
 
88888 Dihedral
Guest
Posts: n/a
 
      08-28-2012
Billy Mays於 2011年5月27日星期五UTC+8上午2時51分20秒 寫道:
> On 05/26/2011 02:22 PM, Thomas Richter wrote:
> > On 26.05.2011 20:09, Ben Pfaff wrote:
> >> Billy Mays<(E-Mail Removed)> writes:
> >>
> >>> I was wondering if there is a way to avoid the C short circuiting for
> >>> boolean expressions such as the following:
> >>>
> >>> if(a&& b&& c) {
> >>> /* Do stuff */
> >>> }
> >>
> >> x = a;
> >> y = b;
> >> z = c;
> >> if (x&& y&& z) {
> >> /* Do stuff */
> >> }

> >
> > Sorry, I fail to see how this should work. Actually, a sufficiently
> > smart compiler would reduce this to just the above, and in fact, a
> > compiler can modify the code always on the basis of the "as-if" rule.
> >
> > So the question goes back to the OP what the intent of disabling the
> > short-circuiting is. If it is to avoid two branches, then if a,b and c
> > are always 0 or 1 (or any other number, identical for all three
> > variables), you could simply write:
> >
> > if (a & b & c) {
> > }
> >
> > If the intent is that an actual access of the variables happen, probably
> > because they are hardware registers, then you would also suggest to
> > declare them as volatile.
> >
> > However, typically the impact of such micro-optimizations is negligible..
> > Question to the OP: Did you actually measure?
> >
> > Greetings,
> > Thomas

>
>
> I did not, but I suspect using an & instead of an && would fail if a was
> 1 and b was 2. The programming guide I was using mentioned that the
> short-circuiting behavior would force all the threads to serialize
> rather than run in lockstep.
>
> --
> Bill


If the integer mutltiplication * is as fast as a jump, then
I'll write if (a*b*c) {... };//, but this is too platform dependent.
 
Reply With Quote
 
88888 Dihedral
Guest
Posts: n/a
 
      08-28-2012


Sorry, there is no closure assumed in C.
I am thinking in Python and Pike mostly nowadays in 201X.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off




Advertisments