Hi,

I have a single-process solution for a server that, I feel, could be implementet

in a more concurrent fashion. Its internal state is a vector that consists of n numbers.

It receives casts without parameters. Every cast is basically a matrix multiplication.

The matrices are known in advance. So, if the internal state is v, and the server

process receives a cast, and it has the matrix M associated with that cast, then the

new state will be M*v (M is a matrix, * is matrix multiplication, and v is a column vector

representing the previous internal state of the server process).

My problem is that the size of v (and the matrices) can be very large, and my

server runs in a single process. It would be great to split it apart and use several

smaller processes to calculate the new state. I would like to use separate

processes for each number in v. But because of the nature of matrix multiplication,

that's not so easy to achieve, because in order to be able to calculate a single

number in the new state, I need to know all the numbers in the previous state.

The prev state could be shared between processes in advance, but that would

require large messages containing all the old values to all the processes around.

I believe that is a wrong idea and there must be a better one.

My question is how would you crach this problem if efficiency matters?

I have one possible solution in mind, and would like to know your opinion: there

could be a main server process and size(v) calculator processes, one for every

number in v. The server process handles the casts, and it has the whole v vector

in it. The calculator processes have only one number from v, and they have the

proper lines from M. When a cast arrives, the server process builds a fun that has

the whole v encoded in it as a clojure, and this anon function gets sent to the

calculator processes. Then the calculator processes apply the fun to the

appropriate line of M, and they have the new number that they have to send

back to the server. I'm not sure if sending a huge function with a large body is

cheaper than sending a large list of numbers, but I hope there's some optimisation

going on in BEAM with funs... Am I right with all this?

THX

_______________________________________________

erlang-questions mailing list

[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions