[Caml-list] assertions and branch prediction

[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

Re: [Caml-list] assert false and -noassert

[james woodyatt]

On Monday, February 18, 2002, at 06:00 , Xavier Leroy wrote:
> [I wrote:]
>> 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.

It *is* appropriate to map conceptually fatal errors (such as failed 
assertions) to exceptions.  I have a library.  It contains assertions.  
I want to test it.  I have a list of thirty test functions.  I iterate 
the list to apply all the functions to test the library, wrapping each 
one in a "try ... with x -> ..." clause.  Result: all thirty functions 
are applied, and I know how many of them raise the Assert_failure 
exception.

At some point, I want to turn off the assertions.  My expectation is 
that -noassert would then compile the library so that it never raises 
the Assert_failure exception.  Unfortunately, the "assert false" case 
is... well, an exception to the general rule.

That's why, when the -noassert flag is used, I would prefer that "assert 
false" map to an immediate program termination, á la "abort()" in the C 
language.  In fact, if that's what ocamlopt inserted in this case, i.e. 
a call to abort() in the C library, I would find that optimal.


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

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

RE: [Caml-list] assert false and -noassert

[Mattias Waldau]

I totally support the current implementation, you NEVER want
a program to just terminate. At least you should be able to say
something like "Internal Error" and log it, and then terminate.

/mattias

P.s. I have observed that users really hate internal error 
messages, so nowadays I just log the error, and then try to 
restart the application. In this way the users will not even
detect that the application failed.

In most cases, they will not report this as an error, they
will just tell you when you ask, that the application behaved
strange, and that they found a workaround.

There exists probably some kind of psychological explanation
for their behaviour. For example that people are used to 
that other people sometimes behave strange, like lying, 
and they tolerate that. However, people would find it 
very strange if instead of answering, you just run away.



> -----Original Message-----
> From: owner-caml-list@pauillac.inria.fr 
> [mailto:owner-caml-list@pauillac.inria.fr] On Behalf Of james woodyatt
> Sent: Wednesday, February 20, 2002 5:36 PM
> To: Xavier Leroy
> Cc: The Trade
> Subject: Re: [Caml-list] assert false and -noassert
> 
> 
> On Monday, February 18, 2002, at 06:00 , Xavier Leroy wrote:
> > [I wrote:]
> >> 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.
> 
> It *is* appropriate to map conceptually fatal errors (such as failed 
> assertions) to exceptions.  I have a library.  It contains 
> assertions.  
> I want to test it.  I have a list of thirty test functions.  
> I iterate 
> the list to apply all the functions to test the library, 
> wrapping each 
> one in a "try ... with x -> ..." clause.  Result: all thirty 
> functions 
> are applied, and I know how many of them raise the Assert_failure 
> exception.
> 
> At some point, I want to turn off the assertions.  My expectation is 
> that -noassert would then compile the library so that it never raises 
> the Assert_failure exception.  Unfortunately, the "assert false" case 
> is... well, an exception to the general rule.
> 
> That's why, when the -noassert flag is used, I would prefer 
> that "assert 
> false" map to an immediate program termination, á la 
> "abort()" in the C 
> language.  In fact, if that's what ocamlopt inserted in this 
> case, i.e. 
> a call to abort() in the C library, I would find that optimal.
> 
> 
> --
> j h woodyatt <jhw@wetware.com>
> "...the antidote to misinformation is more information, not less."
>                                                       --vinton cerf
> 
> -------------------
> 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

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

Re: [Caml-list] assert false and -noassert

[james woodyatt]

On Sunday, February 24, 2002, at 01:08 AM, Mattias Waldau wrote:
>
> I totally support the current implementation, you NEVER want
> a program to just terminate. At least you should be able to say
> something like "Internal Error" and log it, and then terminate.

Perhaps I have the special exception case.  Consider my hypothetical 
scenario:

I'm writing a network server.  It's a Unix daemon.  It has no windows, 
and it responds to no keyboard or mouse events.  It has no input or 
output terminals.  It writes no log files.  It has no interface 
whatsoever for users to interact with it directly.

If it encounters a fatal exception condition, it will send a well-formed 
notification message to a remote management system and execute a 
reasonably graceful termination.

If there is a programming error that prevents it from properly notifying 
its management system of a fatal exception condition, then I want a core 
file dropped into /tmp for later analysis.

In actual fact, I'm writing a library that I hope will be useful in such 
daemons.

The library is in an implementation of RFC 3195 "Reliable Delivery for 
syslog".  I want to use the assert construct for testing the library.  
When the library is proven correct, I want to turn off the 
Assert_failure exceptions completely.

How do I get what I want here?  Do I just have to lump it?  I can do the 
"assert (not true)" kludge... but I'm not sure what we're getting in 
trade for making me have to do that.


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

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