Re: [racket-users] Re: Futures vs. Places for parallelizing a simple game engine

[Brian Adkins]

On Thursday, September 3, 2015 at 12:27:01 PM UTC-4, Jens Axel Søgaard wrote:
> [...]
> 
> For this task places will be the perfect choice.
> 
> [...] 

Great - thanks for the advice. I'll create a non-parallel version first as a 
baseline, and then a version with places. Once I have some code to share, I'll 
post back here with a github repo.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Re: Futures vs. Places for parallelizing a simple game engine

[Jens Axel Søgaard]

Hi Brian,

For this task places will be the perfect choice.

Two reasons:
  i) each place can work a on its own board (and there is no need for
shared data)
   [at least if you are not using transposition tables]
 ii) the amount of data needed to start a task from a given board is only a
few bytes,
 so the communication overhead is small

For most boards you can do this:
  for a board B and a player P to move:
generate all boards B1, B2, ... resulting from player P making one move
on board B
place the boards in a job queue
when a place signals it is ready, send a board to the place

In some situations there are very few moves available for P. In that case
you will need to
generate boards resulting from two (or more) moves before placing them in
the job queue.

/Jens Axel






2015-09-03 18:04 GMT+02:00 Brian Adkins :

> On Monday, August 31, 2015 at 1:27:42 PM UTC-4, Brian Adkins wrote:
> > I'm writing a Reversi/Othello game engine in Racket as a learning
> exercise. Since my macbook pro has 4 cores and 8 hardware threads, I'd like
> to see what sort of speedup I can get by parallelizing it.
> >
> > I read through chapter 20 of the Racket Guide, and I *think* places may
> be more suitable than futures for this task due to the fact that each
> compute unit will be allocating memory for the next set of moves, etc.
> >
> > Does that sound right?
>
> No opinions on this? For you experienced Racketeers, which approach would
> you choose for maximum speed?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
-- 
Jens Axel Søgaard

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Re: Futures vs. Places for parallelizing a simple game engine

[Brian Adkins]

On Monday, August 31, 2015 at 1:27:42 PM UTC-4, Brian Adkins wrote:
> I'm writing a Reversi/Othello game engine in Racket as a learning exercise. 
> Since my macbook pro has 4 cores and 8 hardware threads, I'd like to see what 
> sort of speedup I can get by parallelizing it.
> 
> I read through chapter 20 of the Racket Guide, and I *think* places may be 
> more suitable than futures for this task due to the fact that each compute 
> unit will be allocating memory for the next set of moves, etc. 
> 
> Does that sound right?

No opinions on this? For you experienced Racketeers, which approach would you 
choose for maximum speed?

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.