Academic nonsense. Elementary types can "behave like objects" at language level, but you'll find no object-related opcodes in CIL for integers of course.

Academic nonsense? Thats what you just did. Words have meaning. In C#, Integers are objects, and inherit from object. The only way this is controversial is if you confuse being an object with being a reference. Pretty sure you didnt know there was a difference at this point. While I was reserving judgment before... I am no longer.

While you may enjoy sesse speaking for you, YOU WONT GET TO ENJOY TELLING ME WHAT TO DO.

Not only a language bigot... but also a caps lock cop... yeah... you've got real strong arguments. If you reply, it will go ignored by me, because your goals here are not to be instructive or informative, but instead to masturbate your self-esteem. Not sorry that your goals didnt pan out.

Doing that together with favouring captures a lot (that could be merged in a similar fashion maybe) will lead to much better play where the engine will learn by itself. One nice property will be that generating an opening database will be very easy and you would actually more or less steal the opening databases from the opponents you play against.

Hmm, why should favoring captures help the learning?

Not saying the theory is wrong, just that I dont see the justification.

Doing that together with favouring captures a lot (that could be merged in a similar fashion maybe) will lead to much better play where the engine will learn by itself. One nice property will be that generating an opening database will be very easy and you would actually more or less steal the opening databases from the opponents you play against.

Hmm, why should favoring captures help the learning?

Not saying the theory is wrong, just that I dont see the justification.

The justification is simple. It will reduce the search space and shorten the games so more games can be played. Actually the statistics can be updated without prior knowledge and shortening games can be factored into the end result

Intrinsics in .NET have been a long time coming for sure. It is still not official, and I wouldnt be all that surprised if it takes several years for finalization of any of it. Thats just how Microsoft rolls.

Once upon a time they were previewing some experimental GPU processing support for .NET, called Microsoft Research Accelerator. Ultimately it was abandoned rather than finalized. Probably still works but also probably requires being limited to the 2.0 framework circa 2007 and the abilities of DX9 pixel shaders. I played around with it at some point when it was "news", and decided that my video card at the time made it pointless.

Intrinsics in .NET have been a long time coming for sure. It is still not official, and I wouldnt be all that surprised if it takes several years for finalization of any of it.

Trying this has been on my to-do list for a few weeks now. I finally got around to it tonight. It was surprisingly easy to integrate the intrinsics package into my engine. Of course it helps that my engine is built on .NET Core. It was a simple matter of adding the package (like you said, not from NuGet but from MyGet at https://dotnet.myget.org/F/dotnet-core/ ... index.json) then replacing this code:

And similar. While this might not slow me down a lot (I am not sure about though) it is ugly and I would like to get rid of it.

In your (Java) engine, how do you get around this kind of checking?

Kind regards,
Louis

There isn't anything you can do ni this code by itself. This kind of stuff is absurdly fast, no matter how you write it it will end up the same in both jvm bytecode and x86_64.

I'm sorry, i didn't read much of the thread as it seems it escalated quickly and seemed totally offtopic.
as a side note : ternary operator is evil and doesn't change the compiled code in any way, it's translated to if/then internally and it's a single instruction in both x86_64 instruction set and jvm instruction set. (i didn't play with JVM "assembly" in a long time, it was fun. https://github.com/ker2x/MiouLang/blob/ ... mioulang.j )

With the exception of some very specific, like intrinsic of moderately modern cpu instruction set, the speed at which an instruction is executing doesn't really matter.

In this very specific case of some intrinsic like popcnt :
stockfish_64: 1764951
stockfish_64_popcnt: 1813557
stockfish_64_bmi2: 1886284

But it's an absurdly specific case since we're talking about a replacing an conditional loop by a single instruction. Which lead me to my point :

I suggest your guys read both AMD and Intel programmer guide.
If it's too much, and it seriously is, i suggest reading this one : https://www.agner.org/optimize/microarchitecture.pdf
"The microarchitecture of Intel, AMD and VIA CPUs -- An optimization guide for assembly programmers and compiler makers"
It's a bible.

The good old days of CPU doing exactly what you wrote in ASM are long gone. Since the first pentium, CPU are using micro-operations and even do instruction level parallelism. the X86_64 instruction set is pretty much just an API now.

Trying to trick the compiler and cpu to do something that seems optimized (eg : replacing some math with some bit shifting) may force the compiler to use your optimisation instead of a better optimisation you didn't think about.