From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id PAA21666; Mon, 18 Feb 2002 15:00:10 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id PAA21007 for ; Mon, 18 Feb 2002 15:00:10 +0100 (MET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g1IE07524090; Mon, 18 Feb 2002 15:00:07 +0100 (MET) Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id PAA21551; Mon, 18 Feb 2002 15:00:07 +0100 (MET) Date: Mon, 18 Feb 2002 15:00:07 +0100 From: Xavier Leroy To: james woodyatt Cc: The Trade Subject: Re: [Caml-list] assertions and branch prediction Message-ID: <20020218150007.A20887@pauillac.inria.fr> References: <9A15D2B8-2235-11D6-B866-000502DB38F5@wetware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <9A15D2B8-2235-11D6-B866-000502DB38F5@wetware.com>; from jhw@wetware.com on Fri, Feb 15, 2002 at 09:01:06AM -0800 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > 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