[Caml-list] real-time ocaml RE: ocaml, simd, & fftwgel

[Caml-list] real-time ocaml RE: ocaml, simd, & fftwgel

[Gurr, David (MED, self)]

Travis Bemann:
> 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).   ...

I chop my code into real and non-real time parts.  The real 
time part does no allocation.  At initialization time
I call a C function that mallocs all the memory the real time
portion will use and returns a slew of pointers.  The pointers
will not be followed by GC since they are outside the heap.  That
is good since the stuff they point to will never contain pointers
to memory allocated at run time and thus no pointers to OCaml 
allocated memory. This is what I would do in any language.  If
you use Camoflage, you can even use OCaml type defs to do the
memory layout.  By doing this, I dont care about the GC or
compaction or finialization or ... . The only time there is a
problem is if ocamlopt heap allocs a float and the work arounds
for that are no worse than writing a small chunk of code in C.
It is less painful than handwritten C.  -D

-------------------
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] 'real-time' ocaml RE: ocaml, simd, & fftwgel

[Travis Bemann]

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

On Thu, Aug 01, 2002 at 09:56:05PM -0500, Gurr, David (MED, self) wrote:
> 
> 
> John Max Skaller:
> > Frankly, Ocaml would improve games enormously by allowing
> > programmers to concentrate on what really matters: algorithms
> > and programmer structure.
> 
> I think you are correct.  If I were faced with writting a game
> I would certainly give it a go.  

I agree completely.  For example, having something like an OO scene
graph system in OCaml would make world management much easier than if
someone were directly coding for OpenGL, without a high level
structure and language that allows them to concentrate on what they're
trying to do, rather than how to get OpenGL to do what they want it to
do.  By creating higher level abstractions, the programmer can
concentrate on higher level matters; scene graph systems eliminate
much complexity in light, camera, and composite object management;
physics systems eliminate having code for every different sort of
object to individually micromanage the behavior of instances; and so
forth.  OCaml only helps in this respect, by making the creation and
usage of such abstractions more abstract in itself.

-- 
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: 1499 bytes --]

[Caml-list] 'real-time' ocaml RE: ocaml, simd, & fftwgel

[Gurr, David (MED, self)]

John Max Skaller:
> Gurr, David (MED, self) wrote:
> 
> >About memory allocation, real time code should not be doing memory
> >allocation in the real time section.  
> >
> Huh? Which parts of a real time interactive game aren't real time??
> The whole thing, from gameplay interaction to graphics and sound,
> must be done in 'real-time'.
 
(My previous statement was prefixed by IMHO, as is the following.)

I agree with Damien that games are not real time.  As
for 'real-time' in quotes, games and real-time programs have 
initialization, finialization, and reconfiguration code that is
not 'real-time'.  This code can easily be more complex than 
the 'real-time' section.  Also, if you know that your 'real-time'
code will only allocate a finite amount of memory between these
sections, you can allocate in the 'real-time' section, but 
when you get back to a non-'real-time' section force a garbage 
collection, check to see that there is enough free memory to 
get you through to the next non-'real-time' section
and continue (or fail).  In short, pretty much what I would
do when doing it in C.

> Frankly, Ocaml would improve games enormously by allowing
> programmers to concentrate on what really matters: algorithms
> and programmer structure.

I think you are correct.  If I were faced with writting a game
I would certainly give it a go.  

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