Re: [Caml-list] assertions and branch prediction

Re: [Caml-list] assertions and branch prediction

[Damien Doligez]

>From: james woodyatt <jhw@wetware.com>

>	match p with
>	| A -> ...; ()
>	| B -> ...; ()
>	| _ -> assert false
>
>Then I hit upon the idea of rewriting it this way:
>
>	assert (p = A || p = B);
>	match p with
>	| A -> ...; ()
>	| B -> ...; ()
>	| C -> ()
>
>My thinking was that I would rather pay up front with a more expensive 
>assertion, one that can be stripped out later with the -noassert option, 
>rather than pay at deployment with code (for raising the Assert_failure 
>exception) that I've eventually proven will not be executed.

You can have the best of both worlds by writing it like this:

	match p with
	| A -> ...; ()
	| B -> ...; ()
	| _ -> assert (not true); ()


As for "assert false" with -noassert, you're not really supposed to
catch the Assert_failure exception (unless you really know what
you're doing), so it should result in the immediate termination of
your program anyway.

-- Damien
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] assertions and branch prediction

[Christopher Quinn]

May I ask how 
| _ -> assert (not true); ()

is different from 

| _ -> assert false; ()

???

Thanks,
chris









Damien Doligez wrote:

>>From: james woodyatt <jhw@wetware.com>
>>
>
>>	match p with
>>	| A -> ...; ()
>>	| B -> ...; ()
>>	| _ -> assert false
>>
>>Then I hit upon the idea of rewriting it this way:
>>
>>	assert (p = A || p = B);
>>	match p with
>>	| A -> ...; ()
>>	| B -> ...; ()
>>	| C -> ()
>>
>>My thinking was that I would rather pay up front with a more expensive 
>>assertion, one that can be stripped out later with the -noassert option, 
>>rather than pay at deployment with code (for raising the Assert_failure 
>>exception) that I've eventually proven will not be executed.
>>
>
>You can have the best of both worlds by writing it like this:
>
>	match p with
>	| A -> ...; ()
>	| B -> ...; ()
>	| _ -> assert (not true); ()
>
>
>As for "assert false" with -noassert, you're not really supposed to
>catch the Assert_failure exception (unless you really know what
>you're doing), so it should result in the immediate termination of
>your program anyway.
>
>-- Damien
>-------------------
>Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
>To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr
>

-- 
rgrds,
Chris Quinn



-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] assertions and branch prediction

[Damien Doligez]

>From cq@htec.demon.co.uk  Mon Feb 18 14:34:41 2002

>May I ask how 
>| _ -> assert (not true); ()
>
>is different from 
>
>| _ -> assert false; ()
>
>???

>From the manual:

> As a special case, "assert false" is reduced to "raise (Assert_failure
> ...)", which is polymorphic (and is not turned off by the -noassert
> option). 

In contrast, "assert (not true)" is not polymorphic (but you don't
care when it is followed by a semicolon), and it is turned off by
-noassert like all normal assertions.

-- Damien
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] assertions and branch prediction

[james woodyatt]

folks--

After awhile, I noticed I was writing a fair amount of code that looks 
like this:

	match p with
	| A -> ...; ()
	| B -> ...; ()
	| _ -> assert false

Then I hit upon the idea of rewriting it this way:

	assert (p = A || p = B);
	match p with
	| A -> ...; ()
	| B -> ...; ()
	| C -> ()

My thinking was that I would rather pay up front with a more expensive 
assertion, one that can be stripped out later with the -noassert option, 
rather than pay at deployment with code (for raising the Assert_failure 
exception) that I've eventually proven will not be executed.

This morning, I realized I might be defeating the branch prediction 
optimizer in ocamlopt by doing it this way.

So.  I wonder: is branch prediction affected by the assert construct?  
If so, how can I use that to my advantage?  Does anyone here know?

While we are on the subject of the assert function, it occurs to me that 
it might be nice if -noassert together with "assert false" were to 
bypass all exception handling and go right into program termination.  It 
seems to me that if I've used the -noassert option, I've made a promise 
that the code compiled with it will never raise the Assert_failure 
exception.

Or am I not sufficiently educated about how exception flow works in 
Ocaml?  I haven't looked at the generated code, because that would mean 
having to learn another machine assembly language... and I am too old to 
do that for fun anymore.


--
j h woodyatt <jhw@wetware.com>
"...the antidote to misinformation is more information, not less."
                                                      --vinton cerf

-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] assertions and branch prediction

[Xavier Leroy]

> After awhile, I noticed I was writing a fair amount of code that looks 
> like this:
> 
> (1)	match p with
> 	| A -> ...; ()
> 	| B -> ...; ()
> 	| _ -> assert false
> 
> Then I hit upon the idea of rewriting it this way:
> 
> (2)	assert (p = A || p = B);
> 	match p with
> 	| A -> ...; ()
> 	| B -> ...; ()
> 	| C -> ()
> 
> My thinking was that I would rather pay up front with a more expensive 
> assertion, one that can be stripped out later with the -noassert option, 
> rather than pay at deployment with code (for raising the Assert_failure 
> exception) that I've eventually proven will not be executed.

With -noassert, (1) generates slightly bigger code than (2) (because
of the code that raises Assert_failure), however both will run at the
same speed since the C case never happens.  On the other hand, (1) is
smaller and faster than (2) if you leave assertion checking on
(because (2) performs redundant tests on p).

> This morning, I realized I might be defeating the branch prediction 
> optimizer in ocamlopt by doing it this way.

Don't worry, ocamlopt performs essentially no static branch prediction
except the obvious (e.g. branches to the garbage collector when the
minor heap is exhausted are generated with a "not taken" hint as far
as the processor permits).  The dynamic branch predictors in modern
processors do a much better job than what we could predict statically!

> While we are on the subject of the assert function, it occurs to me that 
> it might be nice if -noassert together with "assert false" were to 
> bypass all exception handling and go right into program termination.  It 
> seems to me that if I've used the -noassert option, I've made a promise 
> that the code compiled with it will never raise the Assert_failure 
> exception.

This is a topic that we've discussed at some point: is it appropriate
to map (conceptually) fatal errors (such as a failed assertion) to an
exception?  There is one pitfall with this approach, namely that a
catch-all "try ... with x -> ..." might inadvertently hide the fatal
error.  On the other hand, the strenght of this approach is that it
enables your program to clean up and possibly log a detailed error
message before termination.

- Xavier Leroy
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr