Re: [Caml-list] assertions and branch prediction

[Xavier Leroy <xavier.leroy@inria.fr>]

> 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