On Tue, Jul 30, 2002 at 12:58:02PM -0500, Gurr, David (MED, self) wrote:
> 
> 
> 
> > From: Travis Bemann:
> > 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.
> 
> About memory allocation, real time code should not be doing memory
> allocation in the real time section.  For many things that you need
> to do in realtime, the ocaml code does not allocate so allocation
> is not issue.  If you need allocation control, write a C allocator.
> You lose some of the safety of ocaml but it is better than writting
> the whole thing in C.  And there is the possiblity of GC-free functional
> programming as done in MLKit4.  This is SML not ocaml.  I would imagine
> that the technique could be used in ocaml.

Note that there is no such thing as a C allocator in OCaml, even
though you can have "custom blocks" that have custom C finalization
code (and which are also not looked inside by OCaml itself).  In OCaml
there's three classes of allocated data structures - small blocks,
large blocks, and custom blocks, all of which are handled differently
by the OCaml garbage collector; also note that custom blocks have data
on non-heap resources which is used to influence the garbage collector
in how often it garbage collects such blocks.

Note that overall, the OCaml garbage collector is a incremental
generational garbage collector, with only *two* generations - new
blocks and old blocks.  The garbage collector only tries to
aggressively garbage collect new blocks, and does not necessarily try
to do all garbage collection at once, which is useful for realtime
performance.

However, there is one thing that particularly disturbs me about OCaml
- the way that it handles floating point values.  In OCaml a floating
point value is always 64 bit, and because only values that are always
the size of a machine word internally are not allocated, floating
point values in OCaml are ALWAYS allocated on the heap!!  Even though
benchmarks of OCaml seem to say that it is pretty damn fast, this
particular aspect keeps me up at night.  I at least hope OCaml has
something like a specialized internal heap for ONLY floating point
values that would keep floating point computations from being horridly
slow...

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