From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: Caml-list@yquem.inria.fr Delivered-To: Caml-list@yquem.inria.fr Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 8AD6FBBBC for ; Mon, 6 Mar 2006 16:11:08 +0100 (CET) Received: from ptb-cgirelay02.plus.net (ptb-cgirelay02.plus.net [195.166.130.41]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id k26FB8wk031369 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Mon, 6 Mar 2006 16:11:08 +0100 Message-Id: <200603061511.k26FB8wk031369@nez-perce.inria.fr> Received: from [212.159.6.129] (helo=ptn-atmail04.plus.net) by ptb-cgirelay02.plus.net with esmtp (Exim 4.34) id 1FGHMZ-0005eN-Co; Mon, 06 Mar 2006 15:11:07 +0000 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: binary Mime-Version: 1.0 From: Jonathan Harrop To: Caml-list@yquem.inria.fr, Asfand Yar Qazi Subject: Re: [Caml-list] I'm sure it's been discussed a few times, but here we go.... single-precision floats Reply-To: jdh30@jdh30.plus.com X-Mailer: AtMail 4.01 X-Origin: 217.36.231.62 X-Uidl: 440C29DC4000701@asfandyarcjbnet Date: Mon, 06 Mar 2006 15:22:34 +0000 X-j-chkmail-Score: MSGID : 440C510C.000 on nez-perce : j-chkmail score : X : 0/20 1 X-Miltered: at nez-perce with ID 440C510C.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; ocaml:01 reloaded:01 iterated:01 error-prone:01 ocaml:01 ocaml's:01 low-level:01 ocaml's:01 iterating:01 arrays:01 arrays:01 pointers:01 cheers:01 cjb:98 caml-list:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.5 required=5.0 tests=FROM_ENDS_IN_NUMS, MSGID_FROM_MTA_HEADER autolearn=disabled version=3.0.3 On Mon Mar 6 12:23 , Asfand Yar Qazi sent: >All the OCaml discussions about floating point precision I have seen so far >evolve around how fast operations are performed on them - but the critical >thing for things like collision detection, etc. in games is the amount of data >that can fit into the CPU cache and be operated on before the cache must be >reloaded. Obviously, twice as many single precision floats can fit into any >CPU's cache than double precision floats. Yes. >We're talking huge dynamic data structures with millions of floating point >coordinates that all have to be iterated over many times a second - preferably >by using multithreaded algorithms, so that multiple CPUs can be used >efficiently. Since doing this sort of work (i.e. parallel computing) in C++ >is a pain in the **** ('scuse my French :-), I want to learn a language that >will make it easy and less error-prone - hence my study of OCaml. Due to OCaml's lack of a concurrent GC, there is no good way to low-level parallelise OCaml programs. You can, of course, use message passing between separate OCaml processes to parallelise at a higher level. OCaml's advantages center around the ability to design and use sophisticated data structures easily - the precise opposite of iterating over long arrays. >So, is there any way (I'm thinking similar to 'nativeint') to use floats in >OCaml to maximize the data that can be stored and operated on in the CPUs >cache such that system memory is accessed as little as possible? Currently, your only choice is to use big arrays of 32-bit floats. There is no other way to store a single 32-bit float in an OCaml data structure. Such functionality would be useful in the case of my ray tracer, for example: http://www.ffconsultancy.com/free/ray_tracer where efficient use of a big array would require fundamental alterations. However, my AMD64 wastes a lot of memory on pointers as well... Cheers, Jon.