Re: [Caml-list] I'm sure it's been discussed a few times, but here we go.... single-precision floats

[Brian Hurt <bhurt@spnz.org>]

On Mon, 6 Mar 2006, Jonathan Harrop wrote:

> OCaml's advantages center around the ability to design and use 
> sophisticated data structures easily - the precise opposite of iterating 
> over long arrays.

Which is why, were I writting a video game in Linux, I'd be writting the 
game logic in Ocaml- and the rendering logic in C/assembly.  Or at least 
I'd be looking to write some sort of C/assembly library to handle large 
arrays of vectors of single precision floats, and do operations on them 
using the various SIMD extensions.

The problems that Jak and Daxter ran into doing pretty much precisely this 
mostly came from one of two problems: 1) they were inventing, and 
maintaining, their own language- and thus had the usual assortment of 
compiler bugs to work out.  Using a mature, debugged language like Ocaml 
would solve this.  And 2) Unfamiliarity of the development staff with 
Functional programming and it's patterns.  See:
http://www.gamasutra.com/features/20020710/white_02.htm

A couple of other, generic, comments on this topic:

1) IMHO, most game developers are focusing too much on technology, and not 
enough on game play.  Games with great game play, but even very low 
CPU/Graphics requirements, like Tetris, SpaceWar, Asteroids, PacMan, 
Nethack, etc., are still great fun to play, and are still played by large 
numbers of people.  This is despite the exceptionally crude aspects of 
lots of them (Nethack and Tetris can even be played on text consoles).
  Games which are technical acheivements but weaker on the game play tend 
to be flash in the pans, at best- who still plays Myst in any serious way? 
Spending your time adding even more realistic blood splatter to a first 
person shooter strikes me as being a suboptimal use of time.

2) If Ocaml isn't the best possible language to use for game design, so 
what?  Outside of game design, the vast majority of numerical programs are 
much more about data structures and algorithms (two things that Ocaml 
kicks ass on) than they are raw FLOPS.  A classic example- two programs (A 
and B), both solving the same program.  Program A has 10x the FLOPS rate 
as program B- and yet program B is 10x faster?  Why?  Because the problem 
is multiplying two sparse matricies, each matrix having only 10% non-zero 
elements.  Program A is doing it as dense multiplication, taking full 
advantage of all SIMD extensions, etc., while program B has implemented a 
sparse matrix data structure.  And while program B is boxing it's floats, 
and doing a lot of data structure overhead, which means it's only issuing 
1 floating point instruction for every 10 FP instructions program A is 
issuing, it's only needing to issue 0.1 * 0.1 = 1/100th the number of 
floating point instructions, and thus is still 10x faster.  That's a 
simple case, but it illustrates the real advantage Ocaml has.

But there is a wider point here.  A number of languages (and C++ is 
particularly bad for this) trying to be golden hammers.  They're a floor 
wax and a dessert topping!  I disbeleive in golden hammers- in my 
experience, languages that try to be all things to all people end up being 
the wrong tool for all jobs.  Numeric programming and game programming put 
together are a small corner of programming.  By any measure you want to 
apply, business logic programming is at least 10 times as big as both of 
those put together- wether it be the number of programmers working on that 
code, the amount of money spent on it, the number of users, the total time 
of all users spent using that code, etc.  In this market, absolute 
performance is less of an issue (witness Java) than is things like 
correctness, ease of maintainability, speed of development, etc.  I 
wouldn't try to write the rendering image for a video game in Java either- 
but that doesn't mean that Java isn't a successfull and usefull language.

Brian