Wall and Regression

[Rebel]

What do you do, if you hit repeatedly a wall and intended optimizations end up in regression?

Take the second wall --> ASM

Time for a break?

Probably wiser.

[brtzsnr]

Happened to me several times in the last year and my engine is well under 3000 Elo on CCRL. Some suggestions:

* Take a break and come back with new approaches.
* Spend the time and the testing resources to simplify your code. Many Elos come unexpectedly from simpler code.
* Browse open source engines for inspiration.
* Profile your code and see what slows it down. Try to remove, to simplify or just fix the issues.

[cdani]

Happened to me several times in the last year and my engine is well under 3000 Elo on CCRL.

It happened to me also several times, but since I found that just reviewing a few fast lost games you find ideas, almost never again.

[mar]

First you must have proof a solution exists. Then find it. If you cannot find it you searched in the wrong direction. Sampling may help and you need to know the search space. Maybe finding a solution can be too expensive. Other things to do that are more worthwhile.

Thanks,
maybe i have to redefine the optimum i am looking for....

--
Srdja

Don't let this lowly troll bug you, you can do better.

One of the options is to forget computer chess, once you know who is who it boils down to worthy people, copycats/scavengers and idiot-trolls.

[smatovic]

What do you do, if you hit repeatedly a wall and intended optimizations end up in regression?

Take the second wall --> ASM

Time for a break?

Probably wiser.

Okay Ed, I got it, take the second wall. The first wall was probably to write an engine in C, I thought first you meant to write an engine in ASM, that won't work with GPGPU development, here I rely on OpenCL, supported on over a dozen architectures, but meanwhile I get that to optimize for an architecture you really have to take a closer look into the assembly generated by the compiler, you need to know the register-width, the register-file size, the ASM instructions of the architecture, the latency, the throughput. I started writing in C for CPU, then in OpenCL for GPU, now again on CPU but with vector-unit. With thanks to tuscr I am now aware of GCC vector-extensions, so I do not need to use intrinsics, and with thanks to dangi I am now aware of the online compile explorer, to view the concrete assembly generated by different compilers for different architectures. There is (or was?) CodeXL by AMD for GPU architectures, but the compile explorer is a really neat tool.

--
Srdja

[lithander]

The original post resonates strongly with me. I've just had a few weeks vacation that I could have spent on a thousand things but instead I've invested my spare time mostly into making zero progress with Leorik. I tried dozens of things that seem to work for everyone else but for me nothing sticks. Now the sunk cost fallacy causes me to orbit my computer in ever shrinking intervals. I'm desperate to get *something* working so that it doesn't feel like I wasted a huge part of my vacation on nothing. My wife is losing patience with my "hobby" at inflationary speed and I can't blame her.

I think there needs to be a public health warning to not get involved with chess programming.

[chrisw]

What do you do, if you hit repeatedly a wall and intended optimizations end up
in regression?

Time for a break?

--
Srdja

Depends what parameters you’re optimising, but I often find it useful to visualise (graph) the data and try to work out what it’s telling me

[KhepriChess]

I thought I hit a wall recently. I thought I hit a limit of my implementation.

Then, in testing out a different feature, I discovered a major bug that basically rendered my transposition tables useless. Fixed that and got a ~130 Elo bump.

But there's a number of things:

* Make the smallest and fewest number of changes you can and test. Sometimes a larger change has a bug that makes testing appear worse than it actually would be if it was bug-free. And sometimes a feature will work, but the addition of one variable makes it all pointless.
* Try variations of features. Mess around with margins and numbers.
* Try simpler things. SEE doesn't appear to work for me. But I think I'm able to get some benefit from a much more simplified version that really just checks whether the capture is good or bad based on piece values.

[algerbrex]

The original post resonates strongly with me. I've just had a few weeks vacation that I could have spent on a thousand things but instead I've invested my spare time mostly into making zero progress with Leorik. I tried dozens of things that seem to work for everyone else but for me nothing sticks. Now the sunk cost fallacy causes me to orbit my computer in ever shrinking intervals. I'm desperate to get *something* working so that it doesn't feel like I wasted a huge part of my vacation on nothing. My wife is losing patience with my "hobby" at inflationary speed and I can't blame her.

I think there needs to be a public health warning to not get involved with chess programming.

If you don't mind sharing, I'd be curious to know what you've tried that hasn't worked for you.