TalkChess.com

most know I am a long-time assembly language user on dozens of architectures. The biggest gains I found in asm programming, thinking about the x86 stuff came from

(1) accessing low-level hardware such as BSF/BSR before compiler intrinsics existed.

(2) knowing more about the program's execution environment than the compilers. IE I knew that some values were always positive, or always negative, or never zero, and such. I could omit many of the checks required for normal compilers to catch execution-time bugs. IE a switch() where I knew that it was impossible for the variable to be anything other than the specific cases I coded for, and I could omit the two checks for out of range to send the switch to the default case. I often looked at the gcc output (and particularly the Cray Fortran output) to see where things were done clumsily. This stuff is handled MUCH better today, and there are a bunch of PRAGMAs one can use to implement much of what I used to do in my optimization stuff.

I've had no asm code in Crafty other than the SMP Lock() code for a long time. Certainly made development easier compared to Cray Blitz where we had parallel pure fortran version and a version with much of the time-critical code written in cray asm. REALLY liked having to write code twice, once in Fortran to make it work correctly, then again in assembler to make it work faster. That was one of the reasons I retired blitz/cray blitz after the last ACM tournament in 1994 and went to a C version that I named Crafty. Was a good decision for me.

Back in 1977 I started working on my first chess engine for the Intel 8080 and 8086, because compilers didn't exist for the Intel architecture there was no other option than to program in assembler. My memory of that time is not so good, but I still remember that my move-generator ran at 15 knps, roughly 4 decades slower as it does nowadays, the program overall ran at 700 nps.

In 1982 I switched to Lattice C, which produced slower executables, but by keeping the time critical routines in assembler I could come very close to the speed of the assembler version, a few years later I switched to Zortech C, around 1990 I switched to C++ and abandoned assembler all together because the ease of programming outweighed the tiny loss of speed.

Nowadays I only use C++. Compared to plain C it is equally efficient and you have a lot of other stuff that you are unable to do in C, for instance: operator-overloading, constant-expressions, templates, variable-templates and lambda-expressions can make your life very easy.

Just a note about overclocking. I finally got a 4.4GHz overclock (3.2GHz is stock) stable across all apps and stress test. The nice thing is that it was done with a lower cpu voltage because I finally got the vitt frequency correct. Because of the lower cpu voltage it runs cooler than before. SF running on all 12 threads ran at 77c with a max of 79c on one core.

Besides some small stuff I have 2 big machines, one with i7-5960X and one with i7-6950X, they can both run stable at 4.4GHz., but when I do that the temperature at full load gets rather high (between 75 and 85 deg. C), something I don't like. Above 3.8 GHz. the temperature starts to rise quickly, usually I run both machines at 3.8 or 4.0 GHz., this keeps the temperature at 65 deg. C max.

I have plans to build a new Intel box pretty soon, it seems that Intel will have a very big price cut on their new HEDT CPU's (Cascade Lake X) next month. If this is really true and they will sell the new 28 core for a price of about $1700 I will certainly buy one.

I've been thinking about AMD, but currently there are so many issues with it that I don't want to go that way. Besides the issues the 3900X is not available anywhere, the 3950X is non existent and the TR3 is not announced at all, this gives me a strong feeling that there are problems with it that AMD wants to keep under the hat. I also don't like the fact that they don't support AVX512 (like the new Intels do) and that they didn't fix the slow PEXT/PDEP instructions.

Joost Buijs wrote: ↑Thu Sep 19, 2019 10:24 am I have plans to build a new Intel box pretty soon, it seems that Intel will have a very big price cut on their new HEDT CPU's (Cascade Lake X) next month. If this is really true and they will sell the new 28 core for a price of about $1700 I will certainly buy one.

I've been thinking about AMD, but currently there are so many issues with it that I don't want to go that way. Besides the issues the 3900X is not available anywhere, the 3950X is non existent and the TR3 is not announced at all, this gives me a strong feeling that there are problems with it that AMD wants to keep under the hat. I also don't like the fact that they don't support AVX512 (like the new Intels do) and that they didn't fix the slow PEXT/PDEP instructions.

Ha, same here! I got a 3900X for testing, it is nice (for the price especially), but the next workstation will be a Cascade Lake X.

AMD CPUs have bugs in the PMU that prevents reverse debugging with rr from working. If you're writing code in C/C++, assembler or Rust, then rr can mean the difference between hours of debugging and logging or getting an answer in minutes. If you don't know this tool, you've been (literally) wasting your life (debugging).

But it doesn't work reliably on AMD CPUs because of those bugs.

It is a bit sad that at this point in time the best choice is still a Skylake derivative...

Gian-Carlo Pascutto wrote: ↑Thu Sep 19, 2019 9:34 pm

Joost Buijs wrote: ↑Thu Sep 19, 2019 10:24 am I have plans to build a new Intel box pretty soon, it seems that Intel will have a very big price cut on their new HEDT CPU's (Cascade Lake X) next month. If this is really true and they will sell the new 28 core for a price of about $1700 I will certainly buy one.

I've been thinking about AMD, but currently there are so many issues with it that I don't want to go that way. Besides the issues the 3900X is not available anywhere, the 3950X is non existent and the TR3 is not announced at all, this gives me a strong feeling that there are problems with it that AMD wants to keep under the hat. I also don't like the fact that they don't support AVX512 (like the new Intels do) and that they didn't fix the slow PEXT/PDEP instructions.

Ha, same here! I got a 3900X for testing, it is nice (for the price especially), but the next workstation will be a Cascade Lake X.

AMD CPUs have bugs in the PMU that prevents reverse debugging with rr from working. If you're writing code in C/C++, assembler or Rust, then rr can mean the difference between hours of debugging and logging or getting an answer in minutes. If you don't know this tool, you've been (literally) wasting your life (debugging).

But it doesn't work reliably on AMD CPUs because of those bugs.

It is a bit sad that at this point in time the best choice is still a Skylake derivative...

Is your latest version of Stoofvlees as strong as Alliestein latest version ?