You could have a huge number of goroutines (and yes they are coroutines) in
a single process, which itself can be multi-threaded.
If you can use Go, then a lot of your life will be easier than it is with
C. You could use channels, though I wouldn’t necessarily recommend it for
performance critical code (channels turn out to be kind of slow), but you
could build your own thing using net.Pipe(). In fact, you could use mangos
today, which is probably not perfectly performance optimal, but this would
give you the ability to use nanomsg’s messaging patterns (including
patterns for broadcasting via BUS or mangos’ custom STAR protocol), as well
as some extras that mangos gives you that nanomsg lacks. (For example, it
*is* possible to terminate a particular connection, or a whole endpoint —
in mangos at any time.)
Mangos will be changing to use net.Pipe for inproc as well, doing more to
accelerate the performance of inproc. (Sadly it still does data copies,
but at least we will be eliminating the use of channels.)
One other advantage of using mangos is that you can then use this with
multiple real-world computers, which might make it reasonable to use the
same messaging for real-world robots in the future. It would also let you
use multiple-process & multiple-system concurrency to let you build really
massive systems (limited only by how many computers you can bring to bear.)
- Garrett
On Mon, Dec 5, 2016 at 11:35 AM, Karan, Cem F CIV USARMY RDECOM ARL (US) <
cem.f.karan.civ@xxxxxxxx> wrote:
-----Original Message-----On
From: nanomsg-bounce@xxxxxxxxxxxxx [mailto:nanomsg-bounce@xxxxxxxxxxxxx]
Behalf Of Jason E. Atenrun
Sent: Monday, December 05, 2016 1:52 PM
To: nanomsg <nanomsg@xxxxxxxxxxxxx>
Subject: [nanomsg] Re: [Non-DoD Source] Re: Modifications necessary to
nanomsg on a simulatorfor at
Hi Cem,
For a simulation I don't see why any actual networking code is called
all. With a dissertation the conclusion/theory matters and the
implementation should rarely be fully fleshed out.
You're right, I just wanted to make my dissertation really stand out. If
it
is difficult to get nanomsg to do what I want, I'll continue with what I
have
and fake it.
I would skip the implementation details and simply model the mathematicsof
the simulation using matrices in Matlab or R.
Matlab and R are too slow (I tried python and Numpy at one point, it still
couldn't handle it).
Only if more is required, then model it in Go using channels andgoroutines
(1-3 goroutines per robot), but -- really -- only if required.
Again you can do this on a single host, and still be modeling 100K robots
(300K goroutines) without a problem.
Goroutines are coroutines, correct? I've got something pretty close to
that
in C by storing all current state information about a robot within its own
struct (fake class instance). When a robot is activated, it first checks
its
state, and then decides what to do next. That said, if I was writing the
simulator from scratch today, goroutines (or any other language that had
good
coroutine support) would DEFINITELY make some aspects easier!
Anyway, just a friendly observation. Best of luck with the work howeveryou
go at it.
Thank you!
Thanks,
Cem Karan
