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=1.2 required=5.0 tests=AWL,SPF_NEUTRAL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr 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 15F51BBAF for ; Sun, 22 Feb 2009 22:41:08 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AogCAP9UoUlDWxLCe2dsb2JhbACBbZJvAQEWIgSyN4QHiEqEDwY X-IronPort-AV: E=Sophos;i="4.38,251,1233529200"; d="scan'208";a="35582721" Received: from ip67-91-18-194.z18-91-67.customer.algx.net (HELO server1.bertec.net) ([67.91.18.194]) by mail4-smtp-sop.national.inria.fr with ESMTP; 22 Feb 2009 22:41:07 +0100 Received: from [IPv6:::1] (server2.bertec.net [192.168.2.6]) by server1.bertec.net (Postfix) with ESMTP id E0DC010575D for ; Sun, 22 Feb 2009 16:41:05 -0500 (EST) Message-Id: <17FAD835-1612-4ADA-B6D7-1B84CC52CC38@osu.edu> From: Kuba Ober To: caml-list@yquem.inria.fr In-Reply-To: <20090222112614.GA14473@philou.ch> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: [Caml-list] ocaml garbage collector_S_ Date: Sun, 22 Feb 2009 16:41:04 -0500 References: <20090222112614.GA14473@philou.ch> X-Mailer: Apple Mail (2.930.3) X-Spam: no; 0.00; ocaml:01 compiler:01 ocaml:01 compilation:01 statically:01 compiler:01 runtime:01 polymorphism:01 functors:01 runtime:01 inherently:01 compilation:01 garbage:01 garbage:01 stack:01 > industrial control process, audio processing share a need for others > pattern of allocation, solved using pools > of memory range of various size. I think that there is a big class of realtime signal processing where dynamic memory allocation is not only uncalled for, but would be a performance disaster. A good compiler for OCaml (or any other "dynamic" language) should be able to recognize where static allocation is applicable. Unfortunately, most compilers do not do whole-project compilation, they only deal with one file at a time. There is a large class of programs where memory can be completely statically allocated, and where you don't even need stack for anything but storage of function return addresses. Some time ago I have done a rather bastardized and godawful Lisp compiler for eZ8 and SX microcontrollers, solely for use in realtime signal processing. Everything is type-inferred and statical types are assigned to all variables; there's no runtime polymorphism (the compiler barfs if any type would not be a constant after all type equations are derived and simplified). Even then, I can use many high- level constructs (currying, generic functions, functors) -- they end up having zero runtime overhead. The approach is perhaps similar to what ocamldefun would do, it's just taken one step further. I posit that dynamic memory allocation and garbage collection are a secondary problem. The primary problem is doing code analysis at such a level that the amount of dynamic memory allocation is reduced only to places where it's inherently needed. Same goes for boxing: unless OCaml would do whole-program compilation, some boxing is inevitable in light of the compiler being unable to reason about all of the code. Kuba