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 DAA07733; Sat, 2 Jun 2001 03:47:29 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id DAA07678 for ; Sat, 2 Jun 2001 03:47:25 +0200 (MET DST) Received: from staff.gtmd.com (adsl-63-195-80-23.dsl.snfc21.pacbell.net [63.195.80.23]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id f521lN101122 for ; Sat, 2 Jun 2001 03:47:24 +0200 (MET DST) Received: from aria.chasm.org (aria [192.168.0.3]) by staff.gtmd.com (8.9.3/8.9.3) with ESMTP id SAA41743 for ; Fri, 1 Jun 2001 18:46:07 -0700 (PDT) (envelope-from charles@chasm.org) Message-Id: <5.1.0.14.0.20010601182845.03bdc020@chasm.org> X-Sender: charles@chasm.org X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 01 Jun 2001 18:49:29 -0700 To: caml-list@inria.fr From: Charles Martin Subject: [Caml-list] compiler storage choice optimization? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Here's a simple version of the code that sparks my question: type t = { mutable value : float } let double x = { value = x.value *. x.value } let double_in_place x = let x' = double x in x.value <- x'.value When I ocamlopt this code, double_in_place inlines the call to double, but nevertheless x' gets allocated in the heap. I was hoping that the compiler might choose stack allocation instead. The motivation is to be able to write side-effecting in-place operations primarily in terms of side-effect-free functions. Although collecting the youngest generation is very fast, stack allocation should still be faster, and in numerically intense code having this kind of storage optimization might allow me to have my functional cake and eat it quickly, too. So I guess my question is, is this kind of optimization in the cards? ------------------- To unsubscribe, mail caml-list-request@inria.fr. Archives: http://caml.inria.fr