Re: [Caml-list] Caml productivity.

[Travis Bemann <bemann@execpc.com>]

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