From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=HTML_MESSAGE autolearn=disabled version=3.1.3 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id ADC12BBC1 for ; Fri, 11 Apr 2008 05:44:35 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmMBAJp7/kdA6aawc2dsb2JhbACCQDWOWgEMAwQFCRSVMoN2 X-IronPort-AV: E=Sophos;i="4.25,638,1199660400"; d="scan'208";a="24869763" Received: from py-out-1112.google.com ([64.233.166.176]) by mail4-smtp-sop.national.inria.fr with ESMTP; 11 Apr 2008 05:44:35 +0200 Received: by py-out-1112.google.com with SMTP id a73so376192pye.33 for ; Thu, 10 Apr 2008 20:44:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; bh=Wl4vEJDUi5rRwmmYpdRaq47uNLwJ1e0PkpGilb+ROCs=; b=w9fIm4lpt4RAzmsdySqVKOFRTsJNilfi2wDvRIRRqtwzbYra+h4wB93wyND5n07pFrNu1VbBQ8c9QHrbG/GkMMTBcEJX/v0laHy0BqTrhh2JAlI7N+3k8yl8p5XtKsKw2EzLPrN/5hNTNJI8eVx5tgSOvzAOWTGJB2qwSgJQZpk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=lqRKXpOiohSUy2gRB9kDzT6SmzTQKuiDCf/aDXG2vOVVWZDTvDUujDwtCWz0N6hHI3lrCmBfP+OXaq1MR1BCGBny4r6dRqPdtuBVF8GXX8O7AMF9NANwBluRTgzR84RgMZN2wIYovUTXR9UhOA4qBAry8irMyZA5IJfbuHjIexU= Received: by 10.141.63.20 with SMTP id q20mr1208710rvk.258.1207885473832; Thu, 10 Apr 2008 20:44:33 -0700 (PDT) Received: by 10.140.158.1 with HTTP; Thu, 10 Apr 2008 20:44:33 -0700 (PDT) Message-ID: Date: Thu, 10 Apr 2008 23:44:33 -0400 From: "Andrew I. Schein" Sender: drandrewschein@gmail.com To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] break and continue for OCaml MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_28190_26414289.1207885473830" X-Google-Sender-Auth: ef4be39d1407b464 X-Spam: no; 0.00; ocaml:01 camlp:01 wiki:01 0200,:01 camlp:01 compiler:01 bytecodes:01 moderately:01 wiki:01 0200,:01 compiler:01 bytecodes:01 moderately:01 10,:98 10,:98 ------=_Part_28190_26414289.1207885473830 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I took the exception approach in a camlp4 macro: pa_breakcont http://code.google.com/p/ocaml-break-continue/ There are timings before/after on the wiki section of that page that demonstrate the overhead. Also, pa_breakcont changes rather than adds to the grammar increasing likelihood of conflict with other extensions. Hopefully, Sanghyeon can fix both of these drawbacks with his approach. -Andy > On Thu, Apr 10, 2008 at 04:12:49PM +0200, David Allsopp wrote: > > Is there therefore any reasonable performance gain over implementing > > break/continue as a camlp4 extension rather than as a compiler patch? > > The posted patch turns the break/continue into jump instructions > (well, jump bytecodes), which should be moderately faster than pushing > an exception stack frame / unwinding the stack. > > Rich. > > -- > Richard Jones > Red Hat > > -- Andrew I. Schein web: www.andrewschein.com ------=_Part_28190_26414289.1207885473830 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

I took the exception approach in a camlp4 macro: pa_breakcont

http://code.google.com/p/ocaml-break-continue/

There are timings before/after on the wiki section of that page that demonstrate the overhead.

Also, pa_breakcont changes rather than adds to the grammar increasing likelihood of conflict with other extensions. 

Hopefully, Sanghyeon can fix both of these drawbacks with his approach.

-Andy

 
On Thu, Apr 10, 2008 at 04:12:49PM +0200, David Allsopp wrote:
> Is there therefore any reasonable performance gain over implementing
> break/continue as a camlp4 extension rather than as a compiler patch?

The posted patch turns the break/continue into jump instructions
(well, jump bytecodes), which should be moderately faster than pushing
an exception stack frame / unwinding the stack.

Rich.

--
Richard Jones
Red Hat




--
Andrew I. Schein


web: www.andrewschein.com
------=_Part_28190_26414289.1207885473830--