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=AWL autolearn=disabled version=3.1.3 Received: from discorde.inria.fr (discorde.inria.fr [192.93.2.38]) by yquem.inria.fr (Postfix) with ESMTP id 1A5A4BC0A for ; Fri, 12 Jan 2007 13:18:31 +0100 (CET) Received: from ptb-relay01.plus.net (ptb-relay01.plus.net [212.159.14.212]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l0CCIUBQ027677 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 12 Jan 2007 13:18:30 +0100 Received: from [80.229.56.224] (helo=[10.0.0.5]) by ptb-relay01.plus.net with esmtp (Exim) id 1H5LMb-0001gD-Le for caml-list@yquem.inria.fr; Fri, 12 Jan 2007 12:18:29 +0000 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Announce: glome-0.2 (ocaml-based raytracer) Date: Fri, 12 Jan 2007 12:16:40 +0000 User-Agent: KMail/1.9.5 References: <45A6E34A.6040007@cs.pdx.edu> In-Reply-To: <45A6E34A.6040007@cs.pdx.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701121216.40859.jon@ffconsultancy.com> X-Miltered: at discorde with ID 45A77C96.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; renders:01 tog:01 ocaml:01 compiler:01 ocaml:01 arrays:01 inference:01 mutation:01 mutation:01 triangles:01 intersection:01 verbose:01 triangles:01 acceleration:01 tolerate:01 On Friday 12 January 2007 01:24, Jim Snow wrote: > I've been working on a raytracer for awhile, and recently decided to > remove a lot of experimental code that doesn't work well anyways and > release the rest under the gpl version 2. Currently, glome renders some > of the scenes from the standard procedural database > (http://www.acm.org/tog/resources/SPD/). I thought that, aside from the > practical utility of generating pretty pictures, some people on this > list might be interested in using it to benchmark the quality of code > generated by various versions of the ocaml compiler. I have altered the code to be more idiomatic OCaml, although it is still very not-OCaml. I've removed OOP from the hot path and virtual function dispatch has been replaced with pattern matches. http://www.ffconsultancy.com/temp/glome.tar.bz2 The code is now 1390LOC instead of 1746 (20% shorter). Performance is also better. Building the Kd-tree is down from 7.0s to 6.3s. I have many suggestions for what to do next: 1. Use records instead of float arrays: stronger type inference, more concise, purely functional. 2. Get rid of almost all mutation. The core ray tracer has no reason to use mutation and all those refs and assignments are confusing and probably slow. 3. Restructure the program again: put independent definitions related to triangles in Triangle, put related definitions like the intersection routine in Intersect. Primarily, the program is far too verbose and convoluted. As an algorithm, ray tracing is very functional in nature. I think the functionality provided by this program could be achieved in half as many lines of code. It could also be a lot faster. > Supported primitives are spheres and triangles. It uses a kd-tree as an > acceleration structure. There is limited joystick support (moving works > fine, but turning can have unexpected results) for those patient enough > to tolerate the low framerates. > > I use lablgl for screen output, but there aren't any other libraries > required outside of the standard ocaml distribution. Rather than rendering dots, you could generate a polygon mesh. To make things more interesting, you could include the depth value in the mesh, so when you rotate the scene it gets distorted by OpenGL without needing to ray trace anything. > I'm not a very experienced ocaml programmer, so I'm sure there are some > things I'm doing inefficiently just because I don't know better. I > welcome any suggestions that would make my code faster, or reduce the > memory footprint of my scene representation. My impression is that you are optimising prematurely. Get the program <1/2 the size that it is before you even think about optimising anything. You're doing all sorts of manual resource allocation and mutation thinking that it will make things faster when, I think, it just makes the program unnecessarily complicated. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. Objective CAML for Scientists http://www.ffconsultancy.com/products/ocaml_for_scientists