Use structs instead of tuples

[Host32]

Sample:
defmodule Vec2 do
def x: 0.0, y: 0,0
end

I'm not sure about the cost of performance when using that, but we will have to use practicalities for example vec.x or vec.y

[crertel]

So, sadly for us, erlang never does consecutive storage of terms (so, likely, no SIMD).

Elixir structs are implemented as Erlang maps, which are like tuples of tuples.

For now, let's stick with tuples, and then if we get a chance to do performance testing (and the penalty is sufficiently small), let's go ahead with structs. Sound fair?

[galfaroi]

Hi guys,

Maybe I would be a bit of the context, but I have interest on HPC in
Elixir, I know it is possible to call C from Erlang so.. why not implement
a Elixir Macro to call it?

On Thu, Jan 22, 2015 at 5:39 PM, crertel notifications@github.com wrote:

So, sadly for us, erlang never does consecutive storage of terms (so,
likely, no SIMD).

Elixir structs are implemented as Erlang maps, which are like tuples of
tuples.

For now, let's stick with tuples, and then if we get a chance to do
performance testing (and the penalty is sufficiently small), let's go ahead
with structs. Sound fair?

—
Reply to this email directly or view it on GitHub
#2 (comment).

[crertel]

So, the concern that I've got is that, when handling a whole bunch of vectors and matrices, it absolutely makes sense to batch everything and send it over to C for execution.

However, I'm not sure that the sort of piecemeal "add a vector here, cross it there" across many concurrent erlang procs lends itself to that--and I'm concerned that marshaling out to C and back again would eat up any major performance benefits we'd see.

Ultimately, we just need to write the code and profile it; until then, let's focus on getting 1.0.0 out the door. Fair?

[Host32]

then, at now, we see this project as a helper to deal with vector calculations without relying on them to pass by a core in C. Is not a complete solution for physical simulators but a great helper to work with one.
And depending on the project size, it can even be enough
Right?

[galfaroi]

fair enough... I guess opening a thread will break the Erlang concurrency
process,.

On Fri, Jan 23, 2015 at 10:45 AM, Ivan notifications@github.com wrote:

then, at now, we see this project as a helper to deal with vector
calculations without relying on them to pass by a core in C is not a
complete solution for physical simulators but a great helper to work with
one.
And depending on the project size, it can even be enough

—
Reply to this email directly or view it on GitHub
#2 (comment).

[crertel]

@Host32: So, I think it'd still be useful for a physics simulator--it is a complete solution for the math that it tries to cover...I just simply can't claim that it'll beat a raw C implementation. Even with a raw C implementation, though, I think you'd find that the overhead of pulling a vector or matrix out, sending it to the C, doing work on it, and pulling it back into the erlang/elxir space would prove prohibitive.

Unlike @galfaroi's use case of HPC, where we have big honking matrics and vectors (thousands and millions of rows) and where the overhead of moving them between languages is trivial compared to the actual computation time, smaller vectors and matrices like in games tend to be used by themselves.

All that said, again, I think there could be a way of doing this--maybe if we offered another interface that just used packed bitstrings/binaries? That'd almost certainly make life easier.

I don't want to let you guys down. :(

[crertel]

Gah, accidental closing. Sorry!

[Host32]

@crertel I think I understand your idea and agree with you on many points, I still have little experience in this area and I am learning a lot lately, I may be mistaken, but I thought about a way that HTC would be the following situation:

If you want to host a game with a great physics system with support for multi player online, the most efficient way would be to use NIFS or ports between Erlang and the real physical simulator in C, but this would be responsible only for the calculation of the virtual environment and not by the exchange of shares of the players at this point that his tool would be fantastic, I could reduce significantly the number of events that I would send to the core in C sue if the Elixir for own account could do simple calculations.

In cases where the game has a simple system with only collision detection, it is not necessary to use a core in C, as you said, the exchange of messages between languages to process so little is not worth the performance gain, however if we want to go further and propose a virtual environment more complex, and make true simulations, I believe there is no escape, and this tool will be extremely useful in situations that we can work around a call to the core in C

and do not worry about me at least, I myself am extremely excited about this project and want to see how far we get :)
will be even more at the end leaving this solution was more efficient than a core C for all hehe

[Host32]

ha, one more thing, my English is very bad... :P
if you can write more technically will facilitate much hehe

[galfaroi]

I once took a Parallel Computing course with the director of the San Diego
Supercomputer Center, he created some time ago a Cosmological simulator
called "Diablo" as far I remember, and he and his team were porting the
thing from MPI to something call Charm++ which is a C++ parallel computing
framework, is suppose to be the most performance framework everywhere. I
researched a little bit deeper, and guess what I found... that what they
use is an "actor" model, the have something call: "chares" that
distributes in a cluster and has load balancing capabilities but is really
hard to use I found. Scala has the actor model too "Akka" but I believe
that the actors there are constrained by the JVM. So, to finalize looking
for something that has that capabilities but without the drawbacks was why
I went to look to Erlang/Elixir, and then found you guys project. I think
if ... it would be possible to have the actor model with numerical
performance and beautiful Elixir syntax would be something awesome..!

On Fri, Jan 23, 2015 at 2:30 PM, Ivan notifications@github.com wrote:

@crertel https://github.com/crertel I think I understand your idea and
agree with you on many points, I still have little experience in this area
and I am learning a lot lately, I may be mistaken, but I thought about a
way that HTC would be the following situation:

If you want to host a game with a great physics system with support for
multi player online, the most efficient way would be to use NIFS or ports
between Erlang and the real physical simulator in C, but this would be
responsible only for the calculation of the virtual environment and not by
the exchange of shares of the players at this point that his tool would be
fantastic, I could reduce significantly the number of events that I would
send to the core in C sue if the Elixir for own account could do simple
calculations.

In cases where the game has a simple system with only collision detection,
it is not necessary to use a core in C, as you said, the exchange of
messages between languages to process so little is not worth the
performance gain, however if we want to go further and propose a virtual
environment more complex, and make true simulations, I believe there is no
escape, and this tool will be extremely useful in situations that we can
work around a call to the core in C

and do not worry about me at least, I myself am extremely excited about
this project and want to see how far we get :)
will be even more at the end leaving this solution was more efficient than
a core C for all hehe

—
Reply to this email directly or view it on GitHub
#2 (comment).

[Host32]

nice,
I did a performance test between tuples and structs and got the results:

• struct_simulation: 13.4 sec 1 iterations 1.3403e7 µs/op
• tuple_simulation: 5.4 sec 1 iterations 5.475e6 µs/op

so, we're on the right way using tuples :)

the complete source is here:
https://github.com/Host32/Elixir-TupleVsStruct

[Host32]

if all are in agreement, i think that we can close this issue, was proven that tuples are most fast that structs

[crertel]

Sir, thank you for your work!

I'll go ahead and close this. Good sleuthing. 👍