Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use only one lookup table? #45

Open
osuushi opened this issue Mar 29, 2016 · 2 comments
Open

Use only one lookup table? #45

osuushi opened this issue Mar 29, 2016 · 2 comments

Comments

@osuushi
Copy link

osuushi commented Mar 29, 2016

Seems to me that cache misses are a potential bottleneck with these lookup tables. You should be able to do a single lookup table, and then do a fairly simple transform on the input before the lookup (and the reverse transform on the result). Much of that single table should then fit in L1, which would plausibly more than make up for the extra time taken to transform the input and output.

@nneonneo
Copy link
Owner

This is an interesting idea. If you are able, could you submit a PR and some timing numbers? I would be very curious to see what could be gained.

I believe the only transforms needed would be transposing the board (rows <-> columns) and flipping the board (left <-> right, up <-> down).

@sicking
Copy link

sicking commented May 20, 2017

I've reimplemented the AI here in rust. It's available here:

https://github.com/sicking/2048-deepsearch

I ended up using two tables. One to "sliding" left and one for "sliding" right. Sliding up and down has implemented by transposing the board, sliding left/right, and then transposing again.

This results in 1/5th as much memory used, while only requiring one extra transpose operation when sliding up/down. I.e. only one half extra transpose operation per tested move on average.

The other thing that should definitely be done is remove the table used for game-scoring, i.e. score_table. Game-scoring is only done once per move and so is not a performance-sensitive operation. Using a table for game-scoring requires more code and increases risk of cache misses, while not improving performance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants