RE: [Caml-list] Caml productivity.

RE: [Caml-list] Caml productivity.

[Arturo Borquez]

"Pal-Kristian Engstad" <engstad@naughtydog.com> wrote:

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

OCaml not too bad?
If you want more I suggest to compile with ocamlopt with the switch -S
(keep intermediate assembly source output) and take a look. Maybe you'll
find the way to strip out some cpu cycles, or maybe you have a better
'faster' GC system. 

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

You can do such thing in OCaml calling a 'C' function, I don't see
where is the problem, even more inside 'C' functions you can code
inline assembler. So you can build your own critical time massive
cpu crunching code that way and use OCaml on the top (where C is bad)

-- 
Arturo Borquez



__________________________________________________________________
Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/

Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.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.

[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

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