caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Jonathan Harrop <jdh30@jdh30.plus.com>
To: Caml-list@yquem.inria.fr, Asfand Yar Qazi <email@asfandyar.cjb.net>
Subject: Re: [Caml-list] I'm sure it's been discussed a few times, but here we go.... single-precision floats
Date: Mon, 06 Mar 2006 15:22:34 +0000	[thread overview]
Message-ID: <200603061511.k26FB8wk031369@nez-perce.inria.fr> (raw)

On Mon Mar  6 12:23 , Asfand Yar Qazi <email@asfandyar.cjb.net> 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.


             reply	other threads:[~2006-03-06 15:11 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-06 15:22 Jonathan Harrop [this message]
2006-03-06 16:34 ` Brian Hurt
  -- strict thread matches above, loose matches on Subject: below --
2006-03-06 12:23 Asfand Yar Qazi
2006-03-06 13:13 ` [Caml-list] " skaller
2006-03-06 17:01   ` Asfand Yar Qazi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200603061511.k26FB8wk031369@nez-perce.inria.fr \
    --to=jdh30@jdh30.plus.com \
    --cc=Caml-list@yquem.inria.fr \
    --cc=email@asfandyar.cjb.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).