[erlang-questions] Erlang math libraries

[Jason Dusek]

On 5/22/07, Kenneth Lundin <kenneth.lundin@REDACTED> wrote:
> On 5/22/07, Jason Dusek <jsnx@REDACTED> wrote:
> > I see a couple of 'patterns' for developing Fortran-backed Erlang applications:
> >
> >  a) write single machine Fortran 'servers' that talk with an Erlang node
> >     through a socket connection. That way, you can take full advantage
> >     of Fortran's multi-processor support without having to deal with it's
> >     approach to concurrency/parallelization. The Erlang node on the
> >     server is responsible for restarting the Fortran app as needed, as
> >     well as feeding it work and data.
> >
> >  b) write Fortran math libraries and work out a solid FFI for Fortran stuff.
> >     I personally think of this as the ugly way, although it does protect one
> >     from the data replication and complicated request translation that might
> >     result from (a).
>
> What about the FFI?, I agree that the linked in driver interface (C) or the
> Erl_interface (C over socket) or the Jinterface (Java over socket) are
> not the easiest to use or program for.

These are complicated and they don't hook to Fortran. What is the best
way to handle communication with an independent process, following the
Fortran server pattern I outlined above? Is that just a bad idea? The
thing I like about an independent Fortran server approach is
  a) independence from Erlang -- I can test and run the Fortran by itself
  b) repeatable, generic technique -- I can use this technique later for
     Erlang & C, Erlang & Ruby, &c.

> > I'm interested in developing distributed game engines with Erlang. As
> > things stand now, numerical performance in Erlang is not a strong
> > selling point...
>
> I don't really understand why you think you need more numerical performance
> than Erlang can handle for a distributed game engine.

Basically, game engines as a rule need as much numerical performance
as you can get. Of course, there are some game engines that are pretty
light on that stuff -- distributed gaming used to be a pretty much 2d
affair -- but it's not that way any more. I need an engine that will
handle all the collision detection, fluid dynamics and rigid body
dynamics of the whole world, at once. So high numerical performance,
and good multi-processor support, is an absolute must. For the term
'game engine' you may substitute 'flight simulator'.

> ...a generic FFI like you have for other languages where you can
> call almost any function residing in a shared library is not suitable
> for Erlang since we have to think about concurrency and overall
> performance as well. A call to a foreign language function might
> take a long time before it returns and during that time the whole
> Erlang VM must not block. To be sure that this does not happen
> each call which potentially can execute for a long time must be
> run in a separate thread.

Thanks for explaining that.

-- 
_jsn