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.
next 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