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 <warplayer@free.fr> 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