From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id XAA25319; Fri, 26 Jul 2002 23:06:52 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id XAA25328 for caml-list@pauillac.inria.fr; Fri, 26 Jul 2002 23:06:51 +0200 (MET DST) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id MAA01907 for ; Wed, 24 Jul 2002 12:05:26 +0200 (MET DST) Received: from web13303.mail.yahoo.com (web13303.mail.yahoo.com [216.136.175.39]) by nez-perce.inria.fr (8.11.1/8.11.1) with SMTP id g6OA0oX28741 for ; Wed, 24 Jul 2002 12:00:50 +0200 (MET DST) Message-ID: <20020724100049.38290.qmail@web13303.mail.yahoo.com> Received: from [64.166.109.241] by web13303.mail.yahoo.com via HTTP; Wed, 24 Jul 2002 03:00:49 PDT Date: Wed, 24 Jul 2002 03:00:49 -0700 (PDT) From: Pal-Kristian Engstad Subject: Re: [Caml-list] Caml productivity. To: Nicolas Cannasse , OCaml In-Reply-To: <002201c232e8$707284f0$0700a8c0@warp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk I guess milage may vary. My company (www.naughtydog.com) is very performance oriented. When I first started, I was shocked at the amount of optimizations people did. It really does make a difference. As far as productivity vs. performance vs. complexity goes, obviously complexity is a huge part of the perfomance. However, when you have come up with an 'optimal' algorithm - you are not done! It is still possible to optimize the routine to achieve ~400 times speed improvements. Yes, these are constant improvements, but they are still important. It is the difference between spitting out 10,000 polys per frame to 4,000,000 polys per frame. [How can one achieve these results? By carefully laying out the data structures in a cache-friendly way, 10 times improvement, by careful layout of code, ~10 times improvement, by paralellizing code (SIMD and multimedia instructions) ~4 times improvement.] You do have a very valid point about portability and maintainability of optimized code. There's always a prize... Ah well, PKE. --- Nicolas Cannasse wrote: > > Nicolas Cannasse seems to believe that > "productivity" > > and "performance" are orthogonal concepts. They > are > > not always. For some tasks the performance of the > > algorithm determins if the program can be put into > the > > application. Hence, if the program executes too > > slowly, the program is useless and the time spent > on > > it was a waste. In other words, there was no > > productivity at all. > > Sorry but i don't call that "performance" but > "complexity". > Theses terms are quite differents. Using algorithm > with a lower complexity > leads to a massive gain of performances, while > increasing performances by > performing "by-hand" optimizations can result in > loss of portability, > clarity and so make the code maintenance almost > impossible, resulting a loss > of productivity. > > > I commend Nicolas for trying to use O'Caml in a > games > > setting. > > That's quite funny because i'm actually doing it :) > We ( my company ) are actually building a real-time > 3D game almost entirely > written in OCaml. > Currently the game is running in bytecode, without > any performance > consideration (except algorithm complexity) and even > on a low-CPU testing > PC, all is working very well ( great FPS, > multithreading , etc... ) > > > We, however, can not afford this - instead > > the company designed and implemented a specific > > language in order to be able to optimize _and_ be > > productive. This language has high-level > constructs as > > well as low-level constructs --- and they can be > > freely mixed. > > Once again, OCaml can be easily mixed with C to > enable at the same time high > performances for time-critical operations and high > productivity for top > level operations ( means : control the low-level > game engine ). All the > current games are using such a top-level called > "script" : most of the time > this langage is developped by the company itself for > its own use, resulting > a large amount of work and at the end you'll have a > more-or-less well > designed langage with more-or-less bugs and > more-or-less performances. > That's why Ocaml is good choice :) > > Nicolas Cannasse > __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners