caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Charles Martin <martin@chasm.org>
To: caml-list@inria.fr
Subject: Re: single-precision floats, etc.
Date: Mon, 23 Oct 2000 09:28:52 -0400	[thread overview]
Message-ID: <5.0.0.25.0.20001023090935.00a698c0@chasm.org> (raw)
In-Reply-To: <20001019111110.49008@pauillac.inria.fr>


>I'm curious to why you need single floats.  It's certainly not for
>speed, because most processors nowadays do not compute over single

I would want single floats for space, not speed!  The history of video game 
development is a fight for space on a limited memory processor.  Single 
versus double is a factor of two in the space requirements for vertex data 
and etc.

I, too, am deeply interested in using FP for video game development.  I 
have seen far too many pages and pages of C/C++ code that could have been 
reduced to a few higher-order functions.  I went so far as to drop by ICFP 
in Montreal for a day this year to meet some of the Scheme/OCaml/ML 
implementors.

On the subject of GC, the GC pause times are the obvious first problem with 
FP in video game development, but the space overhead is important as 
well.  I was interested in the earlier thread on memory overhead for 
various GC schemes; Damien Doligez mentioned that OCaml has a 1.42 times 
overhead.  If your average data structure is three words (two-word pairs 
are half of most FP allocations, I recall reading somewhere), with the 
header word you are paying [(3+1)*1.42=5.68] almost a 90% space overhead.

So using double instead of single floats means that your game as a whole 
will require approximately twice as much space as a non-FP 
implementation.  Of course, you will gain since you (presumeably) won't 
have to engage in typical video game coding stunts like allocating large 
data structures at the maximum possible size used by the game, only to have 
the majority of levels or whatever only require half your allocation.  How 
it all balances out in the mix is an open question.



  reply	other threads:[~2000-10-24  5:17 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Chris Hecker's message of "Mon, 16 Oct 2000 11:20:59 -0700">
2000-10-16 18:20 ` Chris Hecker
2000-10-18 13:53   ` Pierre.Boulet
2000-10-18 15:20     ` Chris Hecker
2000-10-19 11:28       ` Stephan Houben
2000-10-19 12:31         ` String.map ? Christophe Raffalli
2000-10-23 18:33           ` Anton Moscal
2000-10-19 11:37       ` single-precision floats, etc Xavier Leroy
2000-10-20  2:18         ` Chris Hecker
2000-10-19  9:11   ` Xavier Leroy
2000-10-23 13:28     ` Charles Martin [this message]
2000-10-25  3:22       ` Chris Hecker
2000-10-17 16:10 Damien Doligez
2000-10-18  8:39 ` Remi VANICAT
2000-10-18  8:41 ` Fermin Reig
2000-10-18  9:51 ` Chris Hecker
2000-10-18  1:17 David Gurr
2000-10-18  9:56 ` Chris Hecker
2000-10-19 23:50 David Gurr
2000-10-20 13:02 ` jean-marc alliot
2000-10-27 21:39 ortmann
2000-10-29  6:18 ` Chris Hecker

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=5.0.0.25.0.20001023090935.00a698c0@chasm.org \
    --to=martin@chasm.org \
    --cc=caml-list@inria.fr \
    /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).