TalkChess.com

lucasart wrote: ↑

Sat Jul 04, 2020 12:38 am

Compilation (same for both GCC and Clang):

-O3 isn't always the fastest. What if you try -O2 instead?

jauska wrote: ↑

Thu Jul 02, 2020 12:04 pm

Interesting - what do you think I should do with it?

The -0.01 in the eval output looks suspiciously like the 0.01 in that part of the code. How do you notice if you get an unexpected fail-low or fail-high? The window isn't re-opened, and there's no assert for that case.

Things are worse than I thought. I tried to compile the new Raven 1.00. With GCC 8.1 everything's OK. With GCC 10.1.0-3 I get a 200 kB error file, the start of which is this: That's new with GCC 10 and actually caused by sloppy code. External variables should be declared as "external". Try compilin...

I think the problem is with the handling of the root aspiration window.

Is -O2 faster? -O3 often bloats the code so that the optimisations turn out to be slower.

I coded a radical solution to this problem in Demolito: I fixed that issue by having a "legal move was pruned" flag, initialised to false. After the node move loop, I both check whether the legal main move counter (pseudo legal move generator used) is still at 0 AND the flag is false. Only in that ...

a fairly portable engine than can be ported to different microcontrollers. Cool - my CT800 is running on a Cortex-M4! So occasionally it's making some pretty dumb moves. I suspect this is an issue with my hash table implementation. Try to disable the hash and see whether the problem goes away. Anot...

Ick. If I have to disable optimizations, then the profiler cannot tell me what I want to know (which is when compiled for optimization, what are the bottlenecks in the code) The bottlenecks with optimisations will be the same as without, except if you have code parts that can be optimised away enti...

But with optimizations disabled and the nonsense code disabled the engine doesn't crash and no errors are reported. Yes, that's typical for undefined behaviour. With optimisations enabled, the compiler is just more likely to make assumptions that no undefined behaviour exists and omit code parts or...

So it looks to be a problem with the compiler optimizations, witch is what I've been seeing on all these years. It's a problem with your code that has undefined behaviour somewhere, and not necessarily in the function where things finally crash. Introducing nonsense code does not fix anything, it's...