[Caml-list] Caml productivity.

[Caml-list] Caml productivity.

[Pal-Kristian Engstad]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 2579 bytes --]

Some proponents of this mailing list seem to be
convinced that Ocaml is so much more productive than
C++. I find this to be a terrible mistake. From an
industry where performance is crucial (games
programming), I find quite a few aspects of Ocaml hard
to unify with productivity.

There is something to be said for syntax. Syntax
should help the programmer, not the compiler. In
games, it is standard to have a huge library of
classes dealing with mathematical concepts. A minimum
requirement is support for matrices, vectors,
quaternions and splines. This usually also entails
inline assembly, taking advantage of SIMD instruction
sets. Operator overloading is very important to games
programmers, especially for AI and behavior code.

Here is a short list of items that I’ve found
illogical and inconvenient for C/C++ programmers in my
field:

1. The lack of operator overloading, especially
floating-point operations.
2. The lack of bit-fiddling operations.
3. The lack of inline assembly constructs.
4. The non-obvious layout of variables (essential for
optimized functions).
5. The non-obvious differences between arrays and
“inline” arrays.
6. The non-obvious behavior of garbage collection.

One has to understand that when performance is
super-important, one cannot just rely on the compiler
anymore. Some sections of the code have to be
optimized by hand, and it is here that Ocaml falls
short of C/C++. 

As an example, imagine that you want to define:

struct Elems {
	u32 handle;
	u16 numData;
	u16 index;
};

struct Data {
	Elems elem[128];
	u8 buffer[16 * 1024];
};

Data *data = (Data *)0xabadbeef;

This is a very clear layout. One wants the data in a
very specific memory configuration. One needs to know
the exact sizes of the data structure. This could for
instance map to special hardware that is laid out in
this way. This is impossible to do with Ocaml.

Now, Ocaml is a great language for some tasks. I’ve
successfully used it with Facile, a constraints
solver. The parsing of the input was a breeze compared
to a similar C/C++ solution. But one can’t go around
claiming that Ocaml is a productivity enhancer for all
tasks. Games programming certainly isn’t one of them.

PKE.



__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.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

[Caml-list] Caml productivity.

[William Chesters]

Pal-Kristian Engstad writes:
 > Some proponents of this mailing list seem to be
 > convinced that Ocaml is so much more productive than
 > C++. I find this to be a terrible mistake. From an
 > industry where performance is crucial (games
 > programming), I find quite a few aspects of Ocaml hard
 > to unify with productivity.

You are saying that for some tasks the superior productivity of ocaml,
in terms of development time, is irrelevant because you cannot achieve
the required level of performance.

I (myself, personally) thought your mail contained several
misconceptions about ocaml.  I work with C++ in HPC, and I've played
with a variety of different languages and coding idioms; I have to say
that ocaml is generally quite competitive with "general purpose" C and
Fortran compilers, if you write your inner loops in a Fortran style.

ocaml will lose in some cases against serious Fortran compilers that
do heavyweight HPC optimisations, but as far as I know very few C++
compilers have that capability (Intel's?).  And for some tasks the
superior performance of Fortran is irrelevant because you cannot
achieve the required level of productivity :-P.

ocaml also loses performances as soon as you start trying to put nice
abstraction features in the inner loops.  This is disappointing but
not specific to ocaml: templated inner loops in C++ are fast if they
only use scalars, but loops involving e.g. lightweight objects as
"iterators" are not, unless you are using the KAI compiler.

(Which has just been bought up and killed off by Intel, grrr.  KAI was
way ahead of its time; it really made it possible to write incredibly
"high level" C++ and get fast code out the back.  I wish all that
effort had been done in a university, put into a more sensible
language, and liberated so that nobody could take it away :( .)

I don't agree that the lack of operator overloading is a problem, per
se.  If you follow the argument (passim ad nauseam in the archives)
you eventually reach the conclusion that the real problem is that the
compiler doesn't inline across module boundaries---and that _is_
serious.

If access to machine-specific instructions is a problem, then ocaml
isn't the right tool.  Of course, if your uses of them occur in
library routines which can naturally be written in C, then you don't
have a problem.

In short, ocaml is really not so bad for high performance, provided
that you take care to write your inner loops in a "dumb" way and save
the nice language features for the rest of the code (and you have to
do that anyway, although maybe not so stringently, with C++).
-------------------
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

RE: [Caml-list] Caml productivity.

[Pal-Kristian Engstad]

I am also quite surprised by ocaml's speed. It's doing quite well on a lot
of platforms. And I would concur that it does quite well when compared to C
and Fortran. However, that is not quite enough. For me, it isn't enough that
the compiler is doing a decent job. I want to have the capability to make
the code even better. To do that, one needs to be able to make use of the
hardware, i.e. get down to the bare bones of your platform. Yes, it will
mean that you are giving up portability. Yes, it might be "unsafe", but then
again, why are there unsafe set and get operations for arrays in ocaml?

Now, I am not saying that C or C++ is inherently that much better. Even
gcc's inline syntax is really awkward in practice. But I would love to see a
superior system in ocaml! So, what is needed in order to support inline
assembly in ocaml? Is it at all possible?

Imagine that there is a special LZWC instruction that counts the number of
leading zeroes in a 64-bit word. I would love to be able to write something
like:

let lzc (x:int64) = inline
regs res : int32 of  (** Work registers **)
lzwc res, x (** Opcodes sent to the assembler **)
return res              (** result of the computation **)

let main =
	Printf.printf "lzc %d = %d\n" 12 (lzc 12)

PKE.

-----Original Message-----
From: owner-caml-list@pauillac.inria.fr
[mailto:owner-caml-list@pauillac.inria.fr]On Behalf Of William Chesters
Sent: Saturday, July 20, 2002 8:16 AM
To: caml-list@inria.fr
Subject: [Caml-list] Caml productivity.

Pal-Kristian Engstad writes:
 > Some proponents of this mailing list seem to be
 > convinced that Ocaml is so much more productive than
 > C++. I find this to be a terrible mistake. From an
 > industry where performance is crucial (games
 > programming), I find quite a few aspects of Ocaml hard
 > to unify with productivity.

You are saying that for some tasks the superior productivity of ocaml,
in terms of development time, is irrelevant because you cannot achieve
the required level of performance.

I (myself, personally) thought your mail contained several
misconceptions about ocaml.  I work with C++ in HPC, and I've played
with a variety of different languages and coding idioms; I have to say
that ocaml is generally quite competitive with "general purpose" C and
Fortran compilers, if you write your inner loops in a Fortran style.

ocaml will lose in some cases against serious Fortran compilers that
do heavyweight HPC optimisations, but as far as I know very few C++
compilers have that capability (Intel's?).  And for some tasks the
superior performance of Fortran is irrelevant because you cannot
achieve the required level of productivity :-P.

ocaml also loses performances as soon as you start trying to put nice
abstraction features in the inner loops.  This is disappointing but
not specific to ocaml: templated inner loops in C++ are fast if they
only use scalars, but loops involving e.g. lightweight objects as
"iterators" are not, unless you are using the KAI compiler.

(Which has just been bought up and killed off by Intel, grrr.  KAI was
way ahead of its time; it really made it possible to write incredibly
"high level" C++ and get fast code out the back.  I wish all that
effort had been done in a university, put into a more sensible
language, and liberated so that nobody could take it away :( .)

I don't agree that the lack of operator overloading is a problem, per
se.  If you follow the argument (passim ad nauseam in the archives)
you eventually reach the conclusion that the real problem is that the
compiler doesn't inline across module boundaries---and that _is_
serious.

If access to machine-specific instructions is a problem, then ocaml
isn't the right tool.  Of course, if your uses of them occur in
library routines which can naturally be written in C, then you don't
have a problem.

In short, ocaml is really not so bad for high performance, provided
that you take care to write your inner loops in a "dumb" way and save
the nice language features for the rest of the code (and you have to
do that anyway, although maybe not so stringently, with C++).
-------------------
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

-------------------
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

Re: [Caml-list] Caml productivity.

[achrist]

Pal-Kristian Engstad wrote:
> 
> ... I want to have the capability to make
> the code even better. To do that, one needs to be able to make use of
> the hardware, i.e. get down to the bare bones of your platform. 
> ...

Isn't this fairly impossible for an applications programmer programming
the popular modern computers?  Don't these machines implement their
features through low-level virtual machines?  Re-order and rewrite
instructions?  Speculatively branch?  Execute sequential instructions
in parallel? Have hierarchical memory caches that they manage
themselves,
impervious to the desires of the programmer?  Etc, etc, etc?


Al
-------------------
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

RE: [Caml-list] Caml productivity.

[Pal-Kristian Engstad]

Yes, it is pretty hard - but the upside is that given a given architecture
that you know well, you can sometimes optimize routines up to a factor of
400 of an already optimized (data and code optimization) routine. In fact,
that I can do this is specifically why my company hires me... As a matter of
fact, the ocaml programs I've written are all tools to aid me in the process
of optimizing for the current architecture. I wouldn't ever dream of ocaml
being able to do something similar, but it does strike me that it is
possible to be able to put some low-level stuff into ocaml itself. Or
perhaps I am mistaken?

PKE.


-----Original Message-----
From: owner-caml-list@pauillac.inria.fr
[mailto:owner-caml-list@pauillac.inria.fr]On Behalf Of
achrist@easystreet.com
Sent: Monday, July 22, 2002 11:41 AM
Cc: Caml-List@Inria.Fr
Subject: Re: [Caml-list] Caml productivity.

Pal-Kristian Engstad wrote:
>
> ... I want to have the capability to make
> the code even better. To do that, one needs to be able to make use of
> the hardware, i.e. get down to the bare bones of your platform.
> ...

Isn't this fairly impossible for an applications programmer programming
the popular modern computers?  Don't these machines implement their
features through low-level virtual machines?  Re-order and rewrite
instructions?  Speculatively branch?  Execute sequential instructions
in parallel? Have hierarchical memory caches that they manage
themselves,
impervious to the desires of the programmer?  Etc, etc, etc?


Al
-------------------
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

-------------------
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

[Caml-list] CamlIDL and function pointers

[Michael Tucker]

Hi,

  How would one annotate the following C struct for camlidl:

typedef struct funp {
   int i;
   void (*funp_fun) ();
} funp_t;

  Is it possible? Looking at the specs I don't see how one can have a
field that is a pointer to a function. Any ideas, or pointers (no pun
intended) to examples?

Thanks,
Mike

-------------------
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

Re: [Caml-list] CamlIDL and function pointers

[Xavier Leroy]

>   How would one annotate the following C struct for camlidl:
> 
> typedef struct funp {
>    int i;
>    void (*funp_fun) ();
> } funp_t;
> 
>   Is it possible? Looking at the specs I don't see how one can have a
> field that is a pointer to a function. Any ideas, or pointers (no pun
> intended) to examples?

CamlIDL, like the DCE and Microsoft IDL from which it derives, doesn't
support exchanging function pointers between C and Caml.  Your best
bet is to declare funp_t as an abstract type in the IDL file:

        typedef [abstract] struct funp * funp_t;

and export C functions that do what you need to do on this funp_t
type, e.g.

        void invoke(funp_t arg);

where "invoke" is defined directly in C somewhere else:

        void invoke(funp_t arg) { arg->funp_fun(arg->i); }

Of course, you won't be able to, say, construct a funp_t where the
function part is actually a Caml function.  If you need that kind of
callback mechanism, you'll have to write some of the stub code by hand,
using Caml's callback functions.  Alternatively, if you can re-shape
your struct funp till it looks like a COM interface, you could then use
the CamlIDL "interface" declaration and get Caml->C and C->Caml calls.

Hope this helps,

- Xavier Leroy
-------------------
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

Re: [Caml-list] CamlIDL and function pointers

[Dmitry Bely]

Xavier Leroy <xavier.leroy@inria.fr> writes:

>>   How would one annotate the following C struct for camlidl:
>> 
>> typedef struct funp {
>>    int i;
>>    void (*funp_fun) ();
>> } funp_t;
>> 
>>   Is it possible? Looking at the specs I don't see how one can have a
>> field that is a pointer to a function. Any ideas, or pointers (no pun
>> intended) to examples?
>
> CamlIDL, like the DCE and Microsoft IDL from which it derives, doesn't
> support exchanging function pointers between C and Caml.  Your best
> bet is to declare funp_t as an abstract type in the IDL file:
>
>         typedef [abstract] struct funp * funp_t;

I was able to make a normal C function pointer form Ocaml closure using the
"trampoline" technique and ffcall library from 
http://clisp.cons.org/~haible/packages-ffcall.html

Here is the working example from my HighGUI binding (a library from OpenCV
distribution):

Original C definition:

void (*HG_on_notify)(int);
int cvvCreateTrackbar( const char* name, const char* window_name,
                                   int* value, int count, HG_on_notify on_notify );

My IDL definition:

typedef [abstract,mltype("int->unit")] void* ON_NOTIFY; // void (*ON_NOTIFY)(int)
quote(c,"\
#include <callback.h>                                \n\
static int _slider_val;                              \n\
static void _ON_NOTIFY (void* cback, va_alist alist) \n\
{                                                    \n\
  int handle;                                        \n\
  va_start_void(alist);                              \n\
  handle = va_arg_int(alist);                        \n\
  callback(*(value*)cback,Val_int(_slider_val));     \n\
  va_return_void(alist);                             \n\
}")

int cvvCreateTrackbar([string] const char* trackbar_name, [string] const char* window_name,
                         [ref,in] int* val, int count, ON_NOTIFY call_back)
quote(call,"\
{                                                                                   \n\
  value* p_call_back;                                                               \n\
  __TR_function cback;                                                              \n\
  p_call_back = stat_alloc(sizeof(value));                                          \n\
  *p_call_back = _v_call_back;                                                      \n\
  register_global_root(p_call_back); /*both caml and C closure will live forever */ \n\
  cback = alloc_callback(_ON_NOTIFY, p_call_back);                                  \n\
  _slider_val = *val;                                                               \n\
  _res = cvvCreateTrackbar(trackbar_name,window_name,&_slider_val,count,cback);     \n\
}");

Now you can pass the normal OCaml closure to C function:

let f_sl1 x = print_string "slider 1:"; print_int x; print_newline ();;
cvvCreateTrackbar "sl1" "test_window" 5 10 f_sl1;;

- Dmitry Bely


-------------------
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

Re: [Caml-list] CamlIDL and function pointers

[Michael Tucker]

Hi,

 Thanks for the help. I have seen another approach mentioned, but have not
been able to get it to work. I thought I could rewrite my struct for the
IDL as:

typedef strcut funp {
   int i;
} funp_t;

But leave the C version intact. Supposedly it would just ignore the other
field when passing it through to Caml. If that's the case, I was thinking
it might be possible to write the following in the IDL:

void myfun ([in, unique] funp_t* f)
   quote(call,
     " _res = f->funp_fun ();");

So, I guess I would like to be able to ignore a field when converting from
C to Caml (and vice versa), but would like to be able to access the field
from all code on the C side (even that generated by camlidl). I naively
tried adding the function pointer field to the structure in the generated
header file, so that my stub code would compile, but that didn't solve my
problem.

When I call myfun, I got a segmentation fault if I pass it a valid
structure. I also tried editing the custom call to check for NULL and
failwith a string, but the only change was that after calling with None it
would raise an exception -- any valid structure still segfaults. I assume
that is because I'm accessing an invalid field in the string, however a
simple C program including the same header file can access it without a
problem. Any ideas on what is going wrong or how I can fix it?

Thanks,
Mike


On Tue, 23 Jul 2002, Xavier Leroy wrote:

> >   How would one annotate the following C struct for camlidl:
> >
> > typedef struct funp {
> >    int i;
> >    void (*funp_fun) ();
> > } funp_t;
> >
> >   Is it possible? Looking at the specs I don't see how one can have a
> > field that is a pointer to a function. Any ideas, or pointers (no pun
> > intended) to examples?
>
> CamlIDL, like the DCE and Microsoft IDL from which it derives, doesn't
> support exchanging function pointers between C and Caml.  Your best
> bet is to declare funp_t as an abstract type in the IDL file:
>
>         typedef [abstract] struct funp * funp_t;
>
> and export C functions that do what you need to do on this funp_t
> type, e.g.
>
>         void invoke(funp_t arg);
>
> where "invoke" is defined directly in C somewhere else:
>
>         void invoke(funp_t arg) { arg->funp_fun(arg->i); }
>
> Of course, you won't be able to, say, construct a funp_t where the
> function part is actually a Caml function.  If you need that kind of
> callback mechanism, you'll have to write some of the stub code by hand,
> using Caml's callback functions.  Alternatively, if you can re-shape
> your struct funp till it looks like a COM interface, you could then use
> the CamlIDL "interface" declaration and get Caml->C and C->Caml calls.
>
> Hope this helps,
>
> - Xavier Leroy
> -------------------
> 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
>

-------------------
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

Re: [Caml-list] CamlIDL and function pointers

[Xavier Leroy]

>  Thanks for the help. I have seen another approach mentioned, but have not
> been able to get it to work. I thought I could rewrite my struct for the
> IDL as:
> 
> typedef strcut funp {
>    int i;
> } funp_t;
> 
> But leave the C version intact. Supposedly it would just ignore the other
> field when passing it through to Caml.

Yes, that's a useful trick.  However, ignoring the other field
entirely doesn't do what you want when converting from Caml to C:

> If that's the case, I was thinking
> it might be possible to write the following in the IDL:
> 
> void myfun ([in, unique] funp_t* f)
>    quote(call,
>      " _res = f->funp_fun ();");

Here, the CamlIDL-generated code will initialize f->i from the Caml
data, and leave f->funp_fun uninitialized.  (Remember, CamlIDL doesn't
even *know* about the funp_fun field.)  Hence, instant crash when you
do f->funp_fun().

- Xavier Leroy
-------------------
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

Games (Re: [Caml-list] Caml productivity.)

[Oleg]

On Monday 22 July 2002 02:22 pm, Pal-Kristian Engstad wrote:
> Now, I am not saying that C or C++ is inherently that much better. Even
> gcc's inline syntax is really awkward in practice. But I would love to see
> a superior system in ocaml! So, what is needed in order to support inline
> assembly in ocaml? Is it at all possible?

I'm just curious: are people developing console games 
(PS2/XBox/Gamesomething) using gcc? Is it even an option?

What about O'Caml?

Thanks
Oleg
-------------------
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

Re: Games (Re: [Caml-list] Caml productivity.)

[Issac Trotts]

On Mon, Jul 22, 2002 at 05:26:04PM -0400, Oleg wrote:
> On Monday 22 July 2002 02:22 pm, Pal-Kristian Engstad wrote:
> > Now, I am not saying that C or C++ is inherently that much better. Even
> > gcc's inline syntax is really awkward in practice. But I would love to see
> > a superior system in ocaml! So, what is needed in order to support inline
> > assembly in ocaml? Is it at all possible?
> 
> I'm just curious: are people developing console games 
> (PS2/XBox/Gamesomething) using gcc? Is it even an option?

Yes, a lot of Playstation2 developers use a modified version of gcc.

> What about O'Caml?

I haven't heard of any console games written with OCaml.  That's not
necessarily because it would be a bad idea.  More likely it's because
not many game developers know OCaml.  

Issac

-------------------
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

Re: Games (Re: [Caml-list] Caml productivity.)

[eijiro_sumii]

From: Issac Trotts <issac@myfirstlink.net>
> > I'm just curious: are people developing console games 
> > (PS2/XBox/Gamesomething) using gcc? Is it even an option?
> 
> Yes, a lot of Playstation2 developers use a modified version of gcc.
> 
> > What about O'Caml?
> 
> I haven't heard of any console games written with OCaml.  That's not
> necessarily because it would be a bad idea.  More likely it's because
> not many game developers know OCaml.  

I often have discussions with a friend and former colleague of mine
(who has very good expertise in many programming languages including
C, C++, Scheme, ML, etc. and is now working in a Japanese game
company) about using OCaml or other high-level languages for
developing console games.

Ignorance may of course be the most significant obstacle, but another
problem is PlayStation2's slow main memory, which is a big challenge
to such languages as ML, in particular to the garbage collector - it
should not pause the real-time 3D graphics animation for any more than
1/60 seconds, you know.

A good news is, even so, the developers (around him, at least) are
_eager_ for garbage collection in order to manage a tremendous number
of 3D objects (or other data structures) with complex dependencies.
For this purpose, he has even tried porting Boehm's conservative
garbage collector.  (Reference counting doesn't work because the
dependencies are often mutual.)

Another is that some 3D graphics people in Hollywood are actually
using LISP because (the major part of) 3D graphics is in fact symbolic
computation, at which "functional" languages are good.

--
Eijiro Sumii (http://www.yl.is.s.u-tokyo.ac.jp/~sumii/)
Research Associate, Department of Computer Science, University of Tokyo
-------------------
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

Re: Games (Re: [Caml-list] Caml productivity.)

[Charles Martin]

At 08:03 PM 7/23/02 +0900, eijiro_sumii@anet.ne.jp wrote:
>problem is PlayStation2's slow main memory, which is a big challenge
>to such languages as ML, in particular to the garbage collector - it

The 16KB scratchpad is very fast.  You could burst the minor heap into the SPR, do the minor collection, then burst it out.  Or make the SPR the default location for the minor heap, bursting it out and in around the rendering component (which probably wants to use SPR to manage VU0/main memory transfers).

Anyone have any experience along these lines?

-------------------
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

Re: Games (Re: [Caml-list] Caml productivity.)

[Andrei de A. Formiga]

----- Original Message -----
From: <eijiro_sumii@anet.ne.jp>
To: <caml-list@inria.fr>
Cc: <sumii@yl.is.s.u-tokyo.ac.jp>
Sent: Tuesday, July 23, 2002 8:03 AM
Subject: Re: Games (Re: [Caml-list] Caml productivity.)


>
> Another is that some 3D graphics people in Hollywood are actually
> using LISP because (the major part of) 3D graphics is in fact symbolic
> computation, at which "functional" languages are good.

    Could you (or someone else) please elaborate more on that ? So far on my
research on computer graphics I could not see it as being mostly symbolic
computation. Some specific algorithms and applications yes, but not most of
it (nor even close). And I've seen some reports on LISP being used for CG,
mostly in procedural techniques. Could you please point out where have you
seen other uses of functional languages on computer graphics ? Thanks.

>
> --
> Eijiro Sumii (http://www.yl.is.s.u-tokyo.ac.jp/~sumii/)
> Research Associate, Department of Computer Science, University of Tokyo

---
[]s, Andrei de A. Formiga




-------------------
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

Re: Games (Re: [Caml-list] Caml productivity.)

[Florian Hars]

Andrei de A. Formiga wrote:
>>Another is that some 3D graphics people in Hollywood are actually
>>using LISP because (the major part of) 3D graphics is in fact symbolic
>>computation, at which "functional" languages are good.
 >
>     Could you (or someone else) please elaborate more on that ? 

http://www.wikipedia.com/wiki/Symbolics

:-)

Yours, Florian.

-------------------
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

Re: Games (Re: [Caml-list] Caml productivity.)

[eijiro_sumii]

> > Another is that some 3D graphics people in Hollywood are actually
> > using LISP because (the major part of) 3D graphics is in fact symbolic
> > computation, at which "functional" languages are good.
> 
>     Could you (or someone else) please elaborate more on that ? So far on my
> research on computer graphics I could not see it as being mostly symbolic
> computation. Some specific algorithms and applications yes, but not most of
> it (nor even close).

I'm not a CG expert and don't have at hand specific pointers to
industrial uses (I wrote the previous sentence from my memory), so
this is just personal impressions that I've had in writing several CG
programs (e.g. in ICFP programming contest 2000, where our OCaml
program won over all C/C++ entries - see www.ocaml.org) and chatting
with friends of mine (some of them are CG experts), but anyway:

The numeric part is of course important and consumes most time, but as
_programming_ (rather than mathematics), the symbolic part seems much
tricker, in particular for compound applications like games and
movies.  By "symbolic part", I mean all parts involving more complex
data structures than float arrays, like managing objects of various
shapes, manipulating trees for grouping those objects, or even
interpreting domain specific languages for describing placement and
movement of such objects.  OCaml is very good at such a kind of
programming, you know!

> And I've seen some reports on LISP being used for CG,
> mostly in procedural techniques. Could you please point out where have you
> seen other uses of functional languages on computer graphics ? Thanks.

This is why I quoted the word "functional".:-) I never claimed that
functional programming in the sense of "no side effects" is good for
ray tracing.  There may well be other factors such as inductive data
types, pattern matching, higher-order functions, garbage collection,
module systems, etc.  I just think that _so-called_ functional
languages like LISP and ML are good at symbolic computation thanks to
_all_ of the features above.

--
Eijiro Sumii (http://www.yl.is.s.u-tokyo.ac.jp/~sumii/)
Research Associate, Department of Computer Science, University of Tokyo
-------------------
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

Re: Games (Re: [Caml-list] Caml productivity.)

[eijiro_sumii]

[Excuse me for citing a personal message without prior permission.
Also, excuse me for repeating all the same points as in my previous
messages...]

> I think you'll find that the emphasis on symbolic programming in ICFP was
> typical of ICFP rather than the supposed application domain.

I very much expected this response.:-) Indeed ICFP must have put
_more_ emphasis, I suppose, but it is of course just one example.
Also in some other CG programs involving Bezier curves, hidden
line/surface removal, radiosity, polygons, meta balls, etc. etc. that
I wrote, most non-trivial parts were symbolic ones.  The numeric parts
were "mathematics" rather than "programming" - once I solved some
equations, the rest of the work was routine: it was just writing down

  let x = (-. b +. sqrt(b *. b -. 4. *. a *. c)) /. (2. *. a)

or things like that.

Chatting with game/CG professionals around me _strengthened_ this
impression: the symbolic parts seem even more non-trivial in realistic
applications.  For instance, just imagine implementing various kinds
of graphics editors or scripting languages for animation description!

Unfortunately, all of these are mere personal experience and
impression: just I believe that CG programs in the real world are more
symbolic than classroom exercises or laboratory experiments, for the
reasons that I wrote above and in my previous messages.  If somebody
doesn't believe this, I have no more means (and time) to convince
him/her - this is just "FYI".

--
Eijiro Sumii (http://www.yl.is.s.u-tokyo.ac.jp/~sumii/)
Research Associate, Department of Computer Science, University of Tokyo
-------------------
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

Re: Games (Re: [Caml-list] Caml productivity.)

[Jonathan Coupe]

> Chatting with game/CG professionals around me _strengthened_ this
> impression: the symbolic parts seem even more non-trivial in realistic
> applications.

I am a games and realtime 3D professional - and I have to tell you, in the
nicest way (I hope) this really isn't how things are. I'd suggest that your
conversations have naturally reflected your own interests. If you want to
make a balanced assessment of what people do in the real world, try looking
at some representative books and collections of conference papers - the
Graphics Gems and Game Gems series would be good starting points.

> For instance, just imagine implementing various kinds
> of graphics editors or scripting languages for animation description!
>

The hard part of a games scripting language is not, generally, the symbol
processing (take a junior programmer and les and yacc) but the runtime. Do a
search for Unrealscript's documentation. Symbol processing barely impacts
graphics editors at all.

- Jonathan




> Eijiro Sumii (http://www.yl.is.s.u-tokyo.ac.jp/~sumii/)
> Research Associate, Department of Computer Science, University of Tokyo
> -------------------
> 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
>

-------------------
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

Re: Games (Re: [Caml-list] Caml productivity.)

[eijiro_sumii]

From: "Jonathan Coupe" <jonathan@meanwhile.freeserve.co.uk>
> Graphics Gems and Game Gems series would be good starting points.

I actually had taken looks of them during the discussions with
friends, but thank you anyway for references.

> The hard part of a games scripting language is not, generally, the symbol
> processing (take a junior programmer and les and yacc) but the runtime. Do a
> search for Unrealscript's documentation. Symbol processing barely impacts
> graphics editors at all.

Oh I see, the problem seems to be that I am saying "symbolic"
computation in a much broader (maybe too broad) sense.  As I wrote,

| By "symbolic part", I mean all parts involving more complex data
| structures than float arrays, like managing objects of various
| shapes, manipulating trees for grouping those objects, or even
| interpreting domain specific languages for describing placement and
| movement of such objects.

Language runtime is a _typical_ instance of symbolic computation in
this sense.  This is just a problem of definition and excuse me if it
was confusing (it seemed to me that many people share this definition,
but maybe not).  On the other hand,

| OCaml is very good at such a kind of programming, you know!

This point is more controversial and far beyond the ability of me
alone - please ask the people in this list!:-)

At the same time, of course, OCaml is not (yet) so good at real-time
processing, which was the first point of my first message in this list
on this topic.

Thanks,

	Eijiro
-------------------
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

Re: Games (Re: [Caml-list] Caml productivity.)

[John Max Skaller]

Jonathan Coupe wrote:

>>Chatting with game/CG professionals around me _strengthened_ this
>>impression: the symbolic parts seem even more non-trivial in realistic
>>applications.
>>
>
>I am a games and realtime 3D professional - and I have to tell you, in the
>nicest way (I hope) this really isn't how things are. I'd suggest that your
>conversations have naturally reflected your own interests. If you want to
>make a balanced assessment of what people do in the real world, try looking
>at some representative books and collections of conference papers - the
>Graphics Gems and Game Gems series would be good starting points.
>
The issue isn't what is done in the real world, by companies that don't 
really know
how to develop a game, but what *ought* to be done.

It would be nice, for example, if a military game had some small 
resemblance to
actual warfare. Military units have intelligence. They operate with 
stranding orders
with some reason to believe the orders are effective. They move from 
point A to
point B with some kind of common sense.

Now look at the utterly abysmal routing in most military games,
the totally absurd actions units take, etc.

Sorry. The real world isn't a very good model: it's driven by greed,
not by a desire for quality.

-- 
John Max Skaller, mailto:skaller@ozemail.com.au
snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850




-------------------
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

Re: Games (Re: [Caml-list] Caml productivity.)

[Markus Mottl]

On Fri, 02 Aug 2002, John Max Skaller wrote:
> Now look at the utterly abysmal routing in most military games,
> the totally absurd actions units take, etc.

Being an involuntary reserve infanterist, I'd suggest you better look at
the utterly abysmal routing in most _real_ military "games", the totally
absurd actions units take, etc. And then, please, tell me again that
AI-players perform worse than the average human reserve officer :-)

I wonder what this has to do with OCaml, but anyway, I couldn't resist...

Regards,
Markus Mottl

-- 
Markus Mottl                                             markus@oefai.at
Austrian Research Institute
for Artificial Intelligence                  http://www.oefai.at/~markus
-------------------
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

Re: Games (Re: [Caml-list] Caml productivity.)

[Jonathan Coupe]

----- Original Message -----
From: John Max Skaller <skaller@ozemail.com.au>
To: Jonathan Coupe <jonathan@meanwhile.freeserve.co.uk>
Cc: <caml-list@inria.fr>
Sent: Thursday, August 01, 2002 4:39 PM
Subject: Re: Games (Re: [Caml-list] Caml productivity.)


> >>Chatting with game/CG professionals around me _strengthened_ this
> >>impression: the symbolic parts seem even more non-trivial in realistic
> >>applications.

> >I am a games and realtime 3D professional - and I have to tell you, in
the
> >nicest way (I hope) this really isn't how things are. I'd suggest that
your
> >conversations have naturally reflected your own interests. If you want to
> >make a balanced assessment of what people do in the real world, try
looking
> >at some representative books and collections of conference papers - the
> >Graphics Gems and Game Gems series would be good starting points.
> >
> The issue isn't what is done in the real world, by companies that don't
> really know
> how to develop a game, but what *ought* to be done.

It might be your issue; it wasn't *the* one Eijiro and I were discussing.
Eijiro was under the mistaken impression that symbolic problems are dominant
in the graphics industry.

>
> It would be nice, for example, if a military game had some small
> resemblance to
> actual warfare. Military units have intelligence. They operate with
> stranding orders
> with some reason to believe the orders are effective. They move from
> point A to
> point B with some kind of common sense.
>
> Now look at the utterly abysmal routing in most military games,
> the totally absurd actions units take, etc.

Yes, routing is often poor. It's possible to vastly improve on it. Language
change isn't necessary, it's purely a matter of algorithms. People just
don't bother. It's easily done with a few heuristics and possibly some
stochastic evaluation.

- Jonathan


-------------------
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

Re: Games (Re: [Caml-list] Caml productivity.)

[Jonathan Coupe]

> 
>     >> Now look at the utterly abysmal routing in most military games,
>     >> the totally absurd actions units take, etc.
> 
>     jc> Yes, routing is often poor. It's possible to vastly improve on
>     jc> it. Language change isn't necessary, it's purely a matter of
>     jc> algorithms. People just don't bother. It's easily done with a
>     jc> few heuristics and possibly some stochastic evaluation.
>
John Prevost wrote:
 
> I'm pretty sure the implication was that real military units behave
> almost as poorly as simulated military units, if not more poorly.  :)

And even more entertainingly.

- Jonathan

-------------------
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

Re: Games (Re: [Caml-list] Caml productivity.)

[John Max Skaller]

Jonathan Coupe wrote:

>>The issue isn't what is done in the real world, by companies that don't
>>really know
>>how to develop a game, but what *ought* to be done.
>>
>
>It might be your issue; it wasn't *the* one Eijiro and I were discussing.
>Eijiro was under the mistaken impression that symbolic problems are dominant
>in the graphics industry.
>
I thought the reference was to the GAMES industry.
My apologies. CG=Computer Games. CG=Computer Graphics.
Sorry.

-- 
John Max Skaller, mailto:skaller@ozemail.com.au
snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850




-------------------
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

Re: Games (Re: [Caml-list] Caml productivity.)

[Chris Hecker]

>I'm just curious: are people developing console games
>(PS2/XBox/Gamesomething) using gcc? Is it even an option?

If you're talking about professional quality games using caml as the main 
language (as opposed to as a scripting language), it's not really an option 
on this generation of consoles.  Memory in a commercial console game is 
tightly managed, and caml doesn't give much control over memory management 
at all.

Still, you could probably port caml to PS2 Linux and play around with 
it.  On the PS2 you'd only use it on the CPU, and you'd still upload hand 
coded asm to the VUs.  Even on the more conventional machines like GC and 
Xbox, there's a lot of packing things in DMA buffers and accessing memory 
mapped registers and memory blocks, which caml is not great at.  Caml 
doesn't really have a way to take a pointer to a block of memory and cast a 
struct with heterogeneous data types onto it.  You could kind of hack this 
with bigarrays, but it'd be a mess.

You could use caml as a scripting language, but it is missing a lot of 
dynamic features that you want for game scripting, like introspection and 
coroutines.

Chris


-------------------
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

Re: Games (Re: [Caml-list] Caml productivity.)

[Jonathan Coupe]

> If you're talking about professional quality games using caml as the main
> language (as opposed to as a scripting language), it's not really an
option
> on this generation of consoles.  Memory in a commercial console game is
> tightly managed, and caml doesn't give much control over memory management
> at all.

Even on a PC, I would have thought that the GC might need some re-writing? I
haven't seen any suggestion in the docs that it's compatible with realtime
requirements, ie preventing long periods of garbage collection. That said,
people ship games with bigger bugs.

The main thing I've taken from OCaml is using a mixed object/functional
style with C++ in games. This works well enough so that we'll probably spend
some money later this year using OpenC++ (an advanced preprocessor developed
at Xerox) to add closures on top of the C++ compilers we use.

Finally, although it is a fine language I don't think that OCaml supports
the right feature mix for game programming. The combination of a more
sophisticated ObjectiveC language (reflection for modules on top of a C
style base language, but with Smalltalk debugger and workspace, and C's
syntactical faults removed), an object library like Unrealscript's and
reasonable support for FP would seem optimum. I'd insist that it be easier
to parse than C++, even at the cost of removing a lot of syntactical sugar -
that way I might actually get a compiler that matches the language spec,
which still hasn't happened with C++.


- Jonathan Coupe

-------------------
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

Re: Games (Re: [Caml-list] Caml productivity.)

[Michael Vanier]

> From: "Jonathan Coupe" <jonathan@meanwhile.freeserve.co.uk>
> Date: Sun, 28 Jul 2002 14:45:50 +0100
> 
> > If you're talking about professional quality games using caml as the main
> > language (as opposed to as a scripting language), it's not really an
> option
> > on this generation of consoles.  Memory in a commercial console game is
> > tightly managed, and caml doesn't give much control over memory management
> > at all.
> 
> Even on a PC, I would have thought that the GC might need some re-writing? I
> haven't seen any suggestion in the docs that it's compatible with realtime
> requirements, ie preventing long periods of garbage collection. That said,
> people ship games with bigger bugs.
> 
> The main thing I've taken from OCaml is using a mixed object/functional
> style with C++ in games. This works well enough so that we'll probably spend
> some money later this year using OpenC++ (an advanced preprocessor developed
> at Xerox) to add closures on top of the C++ compilers we use.
> 
> Finally, although it is a fine language I don't think that OCaml supports
> the right feature mix for game programming. The combination of a more
> sophisticated ObjectiveC language (reflection for modules on top of a C
> style base language, but with Smalltalk debugger and workspace, and C's
> syntactical faults removed), an object library like Unrealscript's and
> reasonable support for FP would seem optimum. I'd insist that it be easier
> to parse than C++, even at the cost of removing a lot of syntactical sugar -
> that way I might actually get a compiler that matches the language spec,
> which still hasn't happened with C++.
> 
> 
> - Jonathan Coupe
> 

Well, why not write that language in ocaml yourself?  Whatever else you can
say about ocaml, it is a superb language for writing other languages in.
Jason Hickey's group here at Caltech use ocaml to write all their compilers
(actually one big compiler with multiple front ends for different
languages).  I know this is a lot of work, but I'm not being totally
tongue-in-cheek here.

Mike
-------------------
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

Re: [Caml-list] Caml productivity.

[Alexander V.Voinov]

Hi All,

From: "Pal-Kristian Engstad" <engstad@naughtydog.com>
Subject: RE: [Caml-list] Caml productivity.
Date: Mon, 22 Jul 2002 11:22:32 -0700

> Now, I am not saying that C or C++ is inherently that much better. Even
> gcc's inline syntax is really awkward in practice. But I would love to see a
> superior system in ocaml! So, what is needed in order to support inline
> assembly in ocaml? Is it at all possible?

Arity/Prolog had inline C. It was very, _very_ useful.

Alexander
-------------------
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

Re: [Caml-list] Caml productivity.

[Oleg]

On Monday 15 July 2002 05:22 pm, Pal-Kristian Engstad wrote:
> struct Elems {
>         u32 handle;
>         u16 numData;
>         u16 index;
> };
>
> struct Data {
>         Elems elem[128];
>         u8 buffer[16 * 1024];
> };
>
> Data *data = (Data *)0xabadbeef;

I understand that single-player game programs consist of roughly three parts:

1) Low-level graphics
2) "World" model
3) Bot AI

Aside from maintenance and code understandability, a clear separation between 
parts 1 and 2 is necessary for portability. OTOH a clear separation (and 
carefully filtered information traffic) between parts 2 and 3 is crucial for 
playability [1]

>From your code snippet it looks like you were basically referring to part 1, 
yes?

Regards,
Oleg

[1] When you hide behind a stone making sure no one sees [or hears and 
smells] you, but an alien bot finds you anyway, it's clear that you've been 
cheated.
-------------------
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

Re: [Caml-list] Caml productivity.

[Tom]

> Some proponents of this mailing list seem to be
> convinced that Ocaml is so much more productive than
> C++.

It is.  For many problems.  Yours may not be one of them.

> I find this to be a terrible mistake. 

The terrible mistake is thinking that there is one programming
language that works really well for everything.  There isn't.
There never will be because it's a logical impossibility.

> From an
> industry where performance is crucial (games
> programming), I find quite a few aspects of Ocaml hard
> to unify with productivity.

That's a silly generalization.  There are many excellent
games that do not require high performance computing in
any form.

However, even those games that do require high-performance
computing (say, for 3D graphics or AI) can generally be
partitioned into a small computational kernel and a large
set of high-level constructs.  And you don't even have
to reinvent the wheel--many such kernels alreay exist
and are easy to hook up to OCAML: BLAS, LAPACK, OpenGL,
various game and object graph libraries (CrystalSpace, etc.),
neural networks, and many others.

Many high-performance games are programmed in an interpreter 
coupled to a bunch of those libraries.  OCAML gives you a leg up
because of better compile-time type checking, a good foreign
function interface, and the ability to do modestly high
performance computing in OCAML itself in a pinch.

Two specific points:

> 6. The non-obvious behavior of garbage collection.

Anything you don't understand is "non-obvious".  However,
GC is no more "non-obvious" than manual storage allocators:
you have to learn how to write high performance code in
either of them.  GC'ed languages are different: what
you are used to in C/C++ will not work well.  (That is
not to say that the OCAML collector couldn't be improved
for soft real time problems.)

> As an example, imagine that you want to define:
> [packed data structure layout example follows]

Yes, control over layout is nice for high performance
computing.  It could be added to OCAML.  Are you volunteering?

Note, incidentally, that neither C nor C++ make a lot of 
actual guarantees about layout of data in memory; code
that actually depends on it is, in most cases, unportable.
Some compilers will even change layout under different
optimization options, so beware.

C and C++ are great languages.  I write a lot of C++
code.  But C and C++ should really be considered niche languages,
for specific, low-level system tasks, computational kernels,
or certain high-performance numerical uses.  Most code people 
write in C or C++ (GUI software, many games, etc.) would be much 
better, and more productively, written in something else.

Tom


__________________________________________________
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

Re: [Caml-list] Caml productivity.

[Nicolas Cannasse]

> Some proponents of this mailing list seem to be
> convinced that Ocaml is so much more productive than
> C++. I find this to be a terrible mistake. From an
> industry where performance is crucial (games
> programming), I find quite a few aspects of Ocaml hard
> to unify with productivity.

You're mistaking "productivity" and "performances". Theses are two concept
which are not compatible... You can either target performance, by working
alot on the optimization of your code, on you can target productivity
without caring about performance...
OCaml is perhaps one of the best language around to acheive both goals at
the same time with a reasonable ratio. You gain a lot of productivity ( 1:3
compared to C/C++ , in the domain of high-level game scripting ) for a few
loss of performances.

You have to design your game engine to fit OCaml good/weak points. I choose
to write a 3D Engine entirely in C/C++ - based on DirectX8 - with a small
high-level interface with OCaml, which encapsulate Matrix and Quaternions
into shadow types to enable C optimized operations on them. Then the rest of
the game ( which is : manipulation of complexes data structures ) is
entirely written in OCaml, to enable the maximum productivity and SAFETY !
No more patches needed :)

Nicolas Cannasse
www.motion-twin.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

Re: [Caml-list] Caml productivity.

[Pal-Kristian Engstad]

Hi,

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.

I commend Nicolas for trying to use O'Caml in a games
setting. 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.

Take care,

PKE.



--- Nicolas Cannasse <warplayer@free.fr> wrote:
> > Some proponents of this mailing list seem to be
> > convinced that Ocaml is so much more productive
> than
> > C++. I find this to be a terrible mistake. From an
> > industry where performance is crucial (games
> > programming), I find quite a few aspects of Ocaml
> hard
> > to unify with productivity.
> 
> You're mistaking "productivity" and "performances".
> Theses are two concept
> which are not compatible... You can either target
> performance, by working
> alot on the optimization of your code, on you can
> target productivity
> without caring about performance...
> OCaml is perhaps one of the best language around to
> acheive both goals at
> the same time with a reasonable ratio. You gain a
> lot of productivity ( 1:3
> compared to C/C++ , in the domain of high-level game
> scripting ) for a few
> loss of performances.
> 
> You have to design your game engine to fit OCaml
> good/weak points. I choose
> to write a 3D Engine entirely in C/C++ - based on
> DirectX8 - with a small
> high-level interface with OCaml, which encapsulate
> Matrix and Quaternions
> into shadow types to enable C optimized operations
> on them. Then the rest of
> the game ( which is : manipulation of complexes data
> structures ) is
> entirely written in OCaml, to enable the maximum
> productivity and SAFETY !
> No more patches needed :)
> 
> Nicolas Cannasse
> www.motion-twin.com
> 


__________________________________________________
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

Re: [Caml-list] Caml productivity.

[Travis Bemann]

[-- Attachment #1: Type: text/plain, Size: 1901 bytes --]

On Mon, Jul 22, 2002 at 10:46:35AM -0700, Pal-Kristian Engstad wrote:
> Hi,
> 
> 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.
> 
> I commend Nicolas for trying to use O'Caml in a games
> setting. 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.

Actually, speed-wise natively compiled OCaml (on at least x86; I
haven't seen benches for other architectures) is slightly faster than
C++ compiled by gcc 3.0, and slightly slower than C compiled by gcc
3.0.  OCaml does have an excellent C binding facility, which makes it
easy to interface between OCaml and C code (so therefore one can use C
for extremely speed-critical code while writing most other code in
OCaml).  Thus, I see little advantage to writing a whole new natively
compiled language (which would require writing a whole new code
generation and optimization layer, which would be extremely
time-intensive, unless such a language were "compiled to C" as things
such as GCL (GNU Common Lisp) do) rather than simply using OCaml with
speed-critical or otherwise extremely low-level code in C.

-- 
Yes, I know my enemies.
They're the teachers who tell me to fight me.
Compromise, conformity, assimilation, submission, ignorance,
hypocrisy, brutality, the elite.
All of which are American dreams.

              - Rage Against The Machine

[-- Attachment #2: Type: application/pgp-signature, Size: 1820 bytes --]

Re: [Caml-list] Caml productivity.

[Pal-Kristian Engstad]

I agree that the C interface is pretty nice. However,
how do would you use SIMD math instructions on the
x86? Would you always call C-routines just to make use
of SIMD or multimedia-instructions? What is the
overhead for calling a function that is executing a
few assembly instructions? Is it even possible to
create a solid division line between "low-level" and
"high-level" code? 

There's something to be said for premature
optimizations, but don't you think there's something
to be gained from having inline assembly in O'Caml? In
C++, one can create inline SIMD floating point vector
operations. A.I. and behaviour code constantly use 3D
math that would benefit from inline assembly.

PKE.

--- Travis Bemann <bemann@execpc.com> wrote:
> On Mon, Jul 22, 2002 at 10:46:35AM -0700,
> Pal-Kristian Engstad wrote:
> > Hi,
> > 
> > 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.
> > 
> > I commend Nicolas for trying to use O'Caml in a
> games
> > setting. 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.
> 
> Actually, speed-wise natively compiled OCaml (on at
> least x86; I
> haven't seen benches for other architectures) is
> slightly faster than
> C++ compiled by gcc 3.0, and slightly slower than C
> compiled by gcc
> 3.0.  OCaml does have an excellent C binding
> facility, which makes it
> easy to interface between OCaml and C code (so
> therefore one can use C
> for extremely speed-critical code while writing most
> other code in
> OCaml).  Thus, I see little advantage to writing a
> whole new natively
> compiled language (which would require writing a
> whole new code
> generation and optimization layer, which would be
> extremely
> time-intensive, unless such a language were
> "compiled to C" as things
> such as GCL (GNU Common Lisp) do) rather than simply
> using OCaml with
> speed-critical or otherwise extremely low-level code
> in C.
> 
> -- 
> Yes, I know my enemies.
> They're the teachers who tell me to fight me.
> Compromise, conformity, assimilation, submission,
> ignorance,
> hypocrisy, brutality, the elite.
> All of which are American dreams.
> 
>               - Rage Against The Machine

> ATTACHMENT part 2 application/pgp-signature 



__________________________________________________
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

Re: [Caml-list] Caml productivity.

[Chris Hecker]

 > What is the
 > overhead for calling a function that is executing a
 > few assembly instructions?

I don't think inline assembly is a very valuable feature at this 
point.  Function call overhead on modern processors is very small, and 
enabling inline asm messes up a lot of compiler optimizations for 
surrounding code.

It's going to be another generation or two before a higher level language 
like caml is going to be appropriate for console games, and I don't think 
there's any way around that.  I think it's just starting to be okay for PC 
games, but even the next gen consoles are going to be too memory 
constrained and it's always much more cost-effective to super-optimize a 
console game (both memory- and cpu-wise), at least for the next few ship 
cycles.

On the original topic of this thread, I am still withholding judgment on 
caml for game programming until I actually finish my game, but I sincerely 
doubt it will be anywhere near 3x as productive for the kind of imperative 
simulation-y code that makes up a game.  If any game company could actually 
get 3x productivity out of their programmers, they'd retrain everybody in 
an instant.  3x is huge.  I think caml is definitely more fun to program 
with, but if it's at all more productive, it's going to be in the 10-40% 
range at best (and most of that is going to come from the gc).

Chris

-------------------
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

Re: [Caml-list] Caml productivity.

[Issac Trotts]

On Fri, Jul 26, 2002 at 02:42:27PM -0700, Chris Hecker wrote:
> It's going to be another generation or two before a higher level language 
> like caml is going to be appropriate for console games, and I don't think 
> there's any way around that.  I think it's just starting to be okay for PC 
> games, but even the next gen consoles are going to be too memory 
> constrained and it's always much more cost-effective to super-optimize a 
> console game (both memory- and cpu-wise), at least for the next few ship 
> cycles.

There's already strong evidence that it's possible to use a higher 
level language to produce a successful console game: Naughty Dog's Scheme dialect 
(GOAL) on Jak & Daxter for the PS2.  They claim to have used it for most 
of the game.  One thing that isn't clear is how they avoided running 
out of memory from fragmentation.  Maybe Pal-Kristian Engstad can shed 
some light on this.

> On the original topic of this thread, I am still withholding judgment on 
> caml for game programming until I actually finish my game, but I sincerely 
> doubt it will be anywhere near 3x as productive for the kind of imperative 
> simulation-y code that makes up a game.  If any game company could actually 
> get 3x productivity out of their programmers, they'd retrain everybody in 
> an instant.  

The figure of 3x is relative to a particular set of circumstances.  If you're
writing something from scratch that is well matched to OCaml's feature set 
then it's easy to believe that you could write it three times as fast as you
could in some other language, given equal proficiency.  In contrast, a
game company would take a big productivity hit in the short run (as well as 
maybe losing some programmers) if they forced everyone to switch, because 
most likely they already have a large code base written in other languages 
that would need to be converted or interfaced with, as 
well as programmers who are much more effective in these languages than 
they would be as novice OCaml programmers.  Retraining in OCaml wouldn't happen 
in an instant because of OCaml's steep learning curve and relative lack of 
documentation.  (I have yet to find a bookstore in my area that carries 
anything about OCaml.)  Hiring would also be quite a bit more difficult
since so few people are proficient in OCaml compared to other languages
used in games.

> 3x is huge.  I think caml is definitely more fun to program 
> with, but if it's at all more productive, it's going to be in the 10-40% 
> range at best (and most of that is going to come from the gc).

This makes me wonder: have you tried out the Boehm-Demers-Weiser conservative 
garbage collector for C and C++?  

You mentioned that OCaml is more fun to program in.  I agree.  This is important
for its own sake and because happy programmers will tend to produce better work 
and stay around longer.  

-- 
Issac Trotts               

www.issactrotts.net 

-------------------
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

Re: [Caml-list] Caml productivity.

[Chris Hecker]

>There's already strong evidence that it's possible to use a higher
>level language to produce a successful console game: Naughty Dog's Scheme 
>dialect  (GOAL) on Jak & Daxter for the PS2.  They claim to have used it 
>for most  of the game.  One thing that isn't clear is how they avoided running
>out of memory from fragmentation.  Maybe Pal-Kristian Engstad can shed
>some light on this.

My understanding is that the ND stuff is for scripting.  I was talking 
about using caml for the main language, like I mentioned before.  I would 
doubt any of the renderer, animation, physics, core AI routines, core 
object management, control stuff, etc. were written in their language, but 
I would love to be wrong.  I would assume it fits the usual template (or 
maybe goes a bit farther because it's been used at ND for a long time, so 
they've got it very well integrated) for what a scripting language is used 
for in a game, which includes things like higher level AI decisions, traps 
and triggers, win conditions, cut scenes, weapons, UI, etc.  It may be that 
"most" of the code by LOC is in the scripting language, and that's fine 
(although I'd be somewhat surprised, especially if all the VU code is 
included in the count), but my guess is it isn't the "core language".

Having this conversation about the PS2 is kind of ludicrous anyway, since 
it's such a mess, it's hard to even say what language a game is written in.

>In contrast, a game company would take a big productivity hit in the short run

My point is that 3x is simply HUGE for a commercial programming 
effort.  It's easily big enough to overcome inertia and make people switch, 
even if they had a year of downtime...heck, you could make up that year in 
4 months, and then the rest of your ship cycle would happen at 3x the 
rate!  If people could consistently get anywhere close to 3x on most 
programs then everybody would switch quickly.

Anyway, it would be nice if there was more data on this.  I'd love it if 
caml made people 3x more productive on most problems (including, hopefully, 
myself :), I just find it very hard to believe.  Sadly, it's hard to get 
rigorous controlled experiments in this area.

Chris


-------------------
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

Re: [Caml-list] Caml productivity.

[John Max Skaller]

Chris Hecker wrote:

>
> My point is that 3x is simply HUGE for a commercial programming effort.

Yes.

>   It's easily big enough to overcome inertia and make people switch, 
> even if they had a year of downtime...heck, you could make up that 
> year in 4 months, and then the rest of your ship cycle would happen at 
> 3x the rate!  If people could consistently get anywhere close to 3x on 
> most programs then everybody would switch quickly. 

Sorry. No. You're wrong. People use C, when C++ is unequivocably
superior in almost every way. Why?

[Example: Ocaml. Python. Gtk. Etc Etc. Why are all these
fools using C instead of C++? Perhaps they're not fools after all?]

I think you underestimate 'inertia'.
It is worthwhile to consider that being conservative does have
some advantages.

Note also: *business productivity* is more closely related
to predictable performance. Even predictable low performance
of programmers is very attractive compared to risk taking.

-- 
John Max Skaller, mailto:skaller@ozemail.com.au
snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850




-------------------
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

Re: [Caml-list] Caml productivity.

[Oleg]

On Friday 26 July 2002 05:42 pm, Chris Hecker wrote:
> On the original topic of this thread, I am still withholding judgment on
> caml for game programming until I actually finish my game, but I sincerely
> doubt it will be anywhere near 3x as productive for the kind of imperative
> simulation-y code that makes up a game.  If any game company could actually
> get 3x productivity out of their programmers, they'd retrain everybody in
> an instant.  3x is huge.  I think caml is definitely more fun to program
> with, but if it's at all more productive, it's going to be in the 10-40%
> range at best (and most of that is going to come from the gc).

I'm curious, how are you going to be able to establish the productivity 
gain/loss once your game is finished? (I don't suppose you have an identical 
twin next door coding the same game in C++ ;-)  Is it safe to assume you have 
been working on it for many months full-time?

Are you using O'Caml for all of your code in the game? Are you using external 
libraries extensively? 

I happened to look at d6.com web site. It talks about an _original_ game that 
involves climbing a hill online against human competitors. Is this why it is 
original [1]?

Regards,
Oleg
-------------------
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

Re: [Caml-list] Caml productivity.

[Chris Hecker]

>I'm curious, how are you going to be able to establish the productivity
>gain/loss once your game is finished?

It's certainly not going to be scientific, that's for sure.  :)  I just 
figure I'll have a better idea of how caml handles a complete project (or 
at least how I handle a complete project with caml) once I'm done.  It'll 
be more of a personal metric of productivity, but since I work by myself, 
that's fine for me.

 > Are you using O'Caml for all of your code in the game? Are you using 
external
>libraries extensively?

The only external library is gl/d3d, at least I hope to keep it that way 
(well, I'll have to interface to dsound as well, obviously).

>I happened to look at d6.com web site.

This game isn't up there, it's still a long ways from being finished, sadly.

To have some actual potentially list-worthy content in this mail:  I have 
found caml code easier to refactor than C.  Moving blocks of code around is 
pretty easy because of local functions/closures.

Chris

-------------------
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

Re: [Caml-list] Caml productivity.

[Nicolas Cannasse]

> I agree that the C interface is pretty nice. However,
> how do would you use SIMD math instructions on the
> x86? Would you always call C-routines just to make use
> of SIMD or multimedia-instructions? What is the
> overhead for calling a function that is executing a
> few assembly instructions? Is it even possible to
> create a solid division line between "low-level" and
> "high-level" code?

Yes it is.
Actually if you need to perform alot of SIMD instructions each frame
(involving zounds of C calls), you can try to group them in one-C-call that
will do the job in one time. That's matter of architecture and choices...
not always obvious :)

> There's something to be said for premature
> optimizations, but don't you think there's something
> to be gained from having inline assembly in O'Caml? In
> C++, one can create inline SIMD floating point vector
> operations. A.I. and behaviour code constantly use 3D
> math that would benefit from inline assembly.

I don't think OCaml is the best language for that kind of things...
If I remember my Pascal days, the compiler was so bad that i was used to
write asm code directly in Pascal functions to perform all the 2DFx job :)
And even if I enjoyed it because of the great perfs, it's not a good way of
programming.

If you're using OCaml as a top-level scripting langage, you have to put some
barriers on what you can or can't do. Doing alot of "low-level" instructions
needing SIMD optimizations is not the job of a scripting langage. So if you
really need to do them, just move them into a C proc. OCaml code is actually
only doing the following in my implementation :
- moving the Camera
- handling events ( network messages and user mouse/keyb ones )
- setting meshes current position and animation
- same for sprites

Nicolas Cannasse
www.motion-twin.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

Re: [Caml-list] Caml productivity.

[Travis Bemann]

[-- Attachment #1: Type: text/plain, Size: 4015 bytes --]

On Mon, Jul 29, 2002 at 10:13:24AM +0200, Nicolas Cannasse wrote:
> > I agree that the C interface is pretty nice. However,
> > how do would you use SIMD math instructions on the
> > x86? Would you always call C-routines just to make use
> > of SIMD or multimedia-instructions? What is the
> > overhead for calling a function that is executing a
> > few assembly instructions? Is it even possible to
> > create a solid division line between "low-level" and
> > "high-level" code?
>
> Yes it is.
> Actually if you need to perform alot of SIMD instructions each frame
> (involving zounds of C calls), you can try to group them in one-C-call that
> will do the job in one time. That's matter of architecture and choices...
> not always obvious :)

Note that most C or C++ compilers won't do this either, with the
exception of some specialized vector parallelizing compilers (such as
those used to compile code on vector supercomputers).  If you really
need SIMD instructions, you'd probably need to hand-code it in
assembly, no matter what language you're using.

> > There's something to be said for premature
> > optimizations, but don't you think there's something
> > to be gained from having inline assembly in O'Caml? In
> > C++, one can create inline SIMD floating point vector
> > operations. A.I. and behaviour code constantly use 3D
> > math that would benefit from inline assembly.
>
> I don't think OCaml is the best language for that kind of things...
> If I remember my Pascal days, the compiler was so bad that i was used to
> write asm code directly in Pascal functions to perform all the 2DFx job :)
> And even if I enjoyed it because of the great perfs, it's not a good way of
> programming.
>
> If you're using OCaml as a top-level scripting langage, you have to put some
> barriers on what you can or can't do. Doing alot of "low-level" instructions
> needing SIMD optimizations is not the job of a scripting langage. So if you
> really need to do them, just move them into a C proc. OCaml code is actually
> only doing the following in my implementation :
> - moving the Camera
> - handling events ( network messages and user mouse/keyb ones )
> - setting meshes current position and animation
> - same for sprites

Well, according to some rather large sets of benches, code natively
compiled with OCaml 3.04 is often faster than C++ code compiled with
gcc 3.0 (on x86), and a number of 3D games are written in C++, such as
bzflag. And from my experience, bzflag has no speed problems
whatsoever, with 20 AI players all running on the same machine, and
I'm using gcc 2.9-sometyhing, which has far *worse* C++ compilation
(both support and performance-wise) than gcc 3.0.

Therefore, I would think that it would be safe to conclude that
anything in userspace that you can really use C++ for you can use
OCaml for (with the one exception of directly manipulating shared
memory).  And if C++ isn't fast enough, then either your machine is
too slow for the load OR the problem isn't the language, per se, but
rather your algorithms and implementation.  If you aren't doing
embedded programming (or doing something such as original PlayStation
programming), yet feel yourself needing to use hand-optimized C or
assembly for most of your code, you're probably doing something wrong,
whether it's trying to do too much in realtime or it's doing a very
algorithmically inefficient implemntation.  Try to use faster/more
scalable algorithms before you really decided that hand-coded C or
assembly is the only way.  And even still, only use hand-coded C or
assembly at points where it is critical.

(Note: I had earlier accidentally CCed this back to myself, rather
than to caml-list)

-- 
Yes, I know my enemies.
They're the teachers who tell me to fight me.
Compromise, conformity, assimilation, submission, ignorance,
hypocrisy, brutality, the elite.
All of which are American dreams.

              - Rage Against The Machine

[-- Attachment #2: Type: application/pgp-signature, Size: 3104 bytes --]

Re: [Caml-list] Caml productivity.

[Nicolas Cannasse]

> 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

-------------------
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

Re: [Caml-list] Caml productivity.

[Jérôme Marant]

On Wed, Jul 24, 2002 at 10:02:21AM +0200, Nicolas Cannasse wrote:

> > 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.

  I thought you were doing only Flash games ;-)

-- 
Jérôme Marant
-------------------
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

Re: [Caml-list] Caml productivity.

[Pal-Kristian Engstad]

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

Re: [Caml-list] Caml productivity.

[Oleg]

On Wednesday 24 July 2002 06:00 am, Pal-Kristian Engstad wrote:
> It is still
> possible to optimize the routine to achieve ~400 times
> speed improvements.

400x improvement is great. How did it affect the whole game?

Cheers,
Oleg
-------------------
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