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 SAA29969; Fri, 11 Apr 2003 18:35:43 +0200 (MET DST) 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 SAA30083 for ; Fri, 11 Apr 2003 18:35:41 +0200 (MET DST) Received: from xanadu.ece.ucsb.edu (xanadu.ece.ucsb.edu [128.111.56.51]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id h3BGZdX08802 for ; Fri, 11 Apr 2003 18:35:40 +0200 (MET DST) Received: from ece.ucsb.edu (cbshost-12-107-11-68.sbcox.net [12.107.11.68]) by xanadu.ece.ucsb.edu (8.11.6+Sun/8.11.6) with ESMTP id h3BGZce04789 for ; Fri, 11 Apr 2003 09:35:38 -0700 (PDT) Date: Fri, 11 Apr 2003 09:35:39 -0700 Subject: Re: [Caml-list] Slow GC problem Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Shivkumar Chandrasekaran To: caml-list@inria.fr Content-Transfer-Encoding: quoted-printable In-Reply-To: <3E9675AF.60308@univ-savoie.fr> Message-Id: X-Mailer: Apple Mail (2.552) X-Spam: no; 0.00; shivkumar:01 shiv:01 caml-list:01 solver:01 blas:01 lapack:01 --shiv--:01 raffalli:01 hecker:01 malloc:01 gc'd:01 soundness:01 savoie:01 chablais:01 73376:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Hmmm. I thought I had posted the profile and the reason why it was not=20= useful. But apparently that email went to /dev/null. I will post it=20 again as soon as I have a chance. The in-core and out-of-core solver are "identical" and all=20 floating-point operations are done by BLAS/LAPACK. So I don't think=20 ocaml compiler optimizations are an issue. --shiv-- On Friday, April 11, 2003, at 12:58 AM, Christophe Raffalli wrote: > Chris Hecker wrote: >>> What if I modified bigarray_stubs.c to use the malloc and free calls=20= >>> of the Boehm gc (6.1-4) garbage collector? My reasoning is that=20 >>> malloc is performing poorly due to fragmentation, and switching to a=20= >>> gc'd version might help out. >>> Before I try this I would like some feedback from the list on the=20 >>> soundness of this idea. >> I don't mean to be a nag, but did you profile your application yet? =20= >> A very wise programmer once said, "Assume Nothing". >> Chris > > Always remember that if you do anything preventing the compiler to use=20= > float optimizations, you will pay sometimes a 10 factor in speed and=20= > there may be other reasons (may be your second algorithm is really=20 > more efficient because you were more clever than you expected ?). > > GC problem are in fact not so common. So "Assume Nothing" because I=20 > suspect you are wrong ... > > --=20 > Christophe Raffalli > Universit=E9 de Savoie > Batiment Le Chablais, bureau 21 > 73376 Le Bourget-du-Lac Cedex > > t=E9l: (33) 4 79 75 81 03 > fax: (33) 4 79 75 87 42 > mail: Christophe.Raffalli@univ-savoie.fr > www: http://www.lama.univ-savoie.fr/~RAFFALLI > --------------------------------------------- > IMPORTANT: this mail is signed using PGP/MIME > At least Enigmail/Mozilla, mutt or evolution > can check this signature > --------------------------------------------- > = ------------------- 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