[erlang-questions] Erlang math libraries

[Kenneth Lundin]

Hi,

See comments below.

On 5/22/07, Jason Dusek <jsnx@REDACTED> wrote:
> I just joined the list, so I've had to follow most of this thread from
> the web interface. The earlier post about interfacing Erlang with
> Fortran seems to be spot on to me -- I'm a big fan of sharp tools
> doing one job well. Why try to re-implement Fortran's many
> achievements in Erlang?

I agree with you in this.
>
> 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).
If you can call Fortran from C which I assume there are lots of solutions for,
there should be no problem making a linked in driver which does the job.
>
> I'm interested in developing distributed game engines with Erlang. As
> things stand now, numerical performance in Erlang is not a strong
> selling point -- nor is the FFI. However, (a) demands only a nice way
> to send data -- presumably binary is okay -- from one process to
> another. What does the list think? I don't have a lot of experience
> with this stuff, so criticism is definitely appreciated.

I don't really understand why you think you need more numerical performance
than Erlang can handle for a distributed game engine.

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


>
> --
> _jsn
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>
/Kenneth (OTP Team at Ericsson)