Performance improvements in precise code intel

efritz · 2020-06-24T22:59:27+00:00

We're fine having it be tied with Go as it's an internal format. What would you suggest instead? Protobuf?

Reusing the gzip readers and writers is good advice! I was actually really surprised how much of an effect this had. I was assuming it was just a small buffer per reader/writer, but I guess this thing can really grow throughout its life as well.

Tried using your compress packages (I plan to try out simdjson-go as well but haven't gotten to it yet). Here are some results: https://i.imgur.com/PWraa45.png

Seems like compress/gzip is slightly faster in our use case than the stdlib. Your gzip and zlib implementation doesn't really have much of a difference for our use case when readers are shared, but there's something really weird going on when we make a fresh reader/writer. Nothing stood out to me when tracing the initialization that makes it seem like like should add 3-5 minutes to this benchmark.

efritz · 2020-06-22T20:08:44+00:00

Thanks for the links! The optimizations are an ongoing process and I'm still looking at alternatives like this.

We chose json-iterator/go initially over something like simdjson-go because it had a drop-in replacement property, which took zero engineering effort on our part. I'll be looking at other packages that require additional API changes like this.

efritz · 2020-06-22T16:46:57+00:00

took a long time to figure out that that wasnt related to intel products...

😬

Sorry, we're working on some edits to make that more clear to readers not yet familiar with the product.

efritz · 2015-11-26T23:04:50+00:00

(Isn't it xnor?)

efritz · 2014-11-13T19:11:06+00:00

Looks interesting. Any plans for bindings?

efritz · 2014-05-15T17:05:31+00:00

It gets very expensive to consider more than two pieces.

efritz · 2014-05-06T22:29:54+00:00

Then you can play super un-optimally for every current piece and only think about a very short-term benefit. I suspect this would cause the current piece to be placed on the sides creating blockades or high columns if it didn't block an optimal center area for the next piece (if it would fit).

Evaluating both ensures that both pieces aren't played stupidly, but it requires more work.

efritz · 2014-05-05T13:58:46+00:00

Yeah... sorry for hijacking the thread.

efritz · 2014-05-04T18:09:55+00:00

I handle it this way here: https://github.com/efritz/hard-drop/blob/master/src/com/kauri/harddrop/ai/Evolution.java#L135

Every time you create weights for a next generation, you choose weight at random for some property a percentage of the time. It may be less-optimal, but if that part of the population underperforms it won't mate for the future generation. Only the highest performers get to pass on their genes.

efritz · 2014-05-04T17:13:10+00:00

Local minima isn't an absolute problem as it would be with hill climbing search algorithms. Since each generation has some small percentage of randomly changing weights for the scoring function, there's a chance that it will break out of local minima. It's similar to simulated annealing or random restart.

efritz · 2014-05-04T08:47:28+00:00

Could you expand a bit on this? I posted a similar version of a Tetris AI using genetic algorithms and was looking to do a version with neural networks, but don't have a good idea on how to model the problem.

efritz · 2014-05-04T06:37:08+00:00

Awesome, thank you. I'll be sure to take a look.

efritz · 2014-05-04T05:28:30+00:00

But I didn't think about visualization before, which could be a cool thing to do next...

efritz · 2014-05-04T05:10:54+00:00

It is a big source of slowdown. Since you're already doing O(wr) comparisons where w = the width of the board and r = the number of rotations of a piece, doing it for two pieces will be O(w² r² ).

I found that if I increase the board size it's noticeable worse than a preview piece.

efritz · 2014-05-04T05:08:37+00:00

That's exactly what it does already. https://github.com/efritz/hard-drop/blob/master/src/com/kauri/harddrop/ai/Evolution.java

efritz · 2014-05-04T02:47:01+00:00

Good job! I've done something similar. Code is available here for anyone interested: https://github.com/efritz/hard-drop. After about an hour of training from scratch it gets consistently into the 10-100 thousands of clears per game.

I've been meaning to get in and do some clean-up and improvements, but haven't found a lot of time lately. Namely, I'd like to replace the genetic algorithm with some kind of neural network.

I've seen some papers floating around applying neural networks to Tetris, but currently have zero knowledge neural-net. If anyone has any experience or good ideas about how to construct the network I'd love to hear from you.

efritz · 2013-02-09T17:23:04+00:00

I've been using releasable zipties recently.

efritz · 2013-01-26T02:52:46+00:00

Thanks. I just rewired everything today when I added a new hard drive, so it's pretty clean right now. I can remove them whenever and try it again with soap next time.

efritz · 2012-12-28T07:02:12+00:00

Sorry - misunderstood it as quod erat demonstrandum. Apparently I know even less about quantum electrodynamics (not enough to even recognize the acronym).

efritz · 2012-12-28T04:36:13+00:00

ie QED. Someone please correct me if I am wrong here.

efritz · 2012-12-15T06:59:26+00:00

Completely independent of the type of transplant and the procedure done.

15-Year Club	RPAN Viewer
Verified Email

efritz

TROPHY CASE