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 4E70CBB81 for ; Mon, 6 Mar 2006 17:33:49 +0100 (CET) Received: from conn.mc.mpls.visi.com (conn.mc.mpls.visi.com [208.42.156.2]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id k26GXmOZ009241 for ; Mon, 6 Mar 2006 17:33:48 +0100 Received: from [192.168.42.2] (bhurt.dsl.visi.com [208.42.141.66]) by conn.mc.mpls.visi.com (Postfix) with ESMTP id 68DF9823C; Mon, 6 Mar 2006 10:33:47 -0600 (CST) Date: Mon, 6 Mar 2006 10:34:42 -0600 (CST) From: Brian Hurt X-X-Sender: bhurt@localhost.localdomain To: Jonathan Harrop Cc: 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 In-Reply-To: <200603061511.k26FB8wk031369@nez-perce.inria.fr> Message-ID: References: <200603061511.k26FB8wk031369@nez-perce.inria.fr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Miltered: at nez-perce with ID 440C646C.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; ocaml's:01 iterating:01 arrays:01 ocaml-:01 arrays:01 vectors:01 simd:01 compiler:01 ocaml:01 suboptimal:01 ocaml:01 multiplying:01 non-zero:01 simd:01 usefull: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.0 required=5.0 tests=none autolearn=disabled version=3.0.3 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