Dann Corbit wrote: ↑Wed Apr 12, 2023 4:13 pm
The next big thing will be when the GPUs and CPUs transparently share memory resources so that we do not have to copy to and from GPU memory.
Suddenly, engines like LC0 will become unbeatable.
It's not just the copy time that we save, it is a whole new programming paradigm.
How about... enabling the GPU to run programs independently?
Apple M1 chips CPU+GPU+the other stuff are sharing the memory resources.
After some optimizations LC0 should be unbeatable on Apple hardware.
No. Apple CPU cores are state of the art. Their GPUs are fair. Not only that, but they are designed to operate within certain power/heat envelopes (with a good portion of that going to the CPU). They are not remotely close in performance to a dedicated GPU.
jhellis3 wrote: ↑Fri Aug 11, 2023 5:19 pmThey are not remotely close in performance to a dedicated GPU.
Unlike x86 integrated GPUs, the Apple approach allows the CPU and iGPU to directly operate on the same memory so that no copy to/from the iGPU RAM space is required, and no copy over a PCIe bus, either. By consequence, while the raw performance isn't top notch, the latency is much reduced, and that might allow programming approaches that wouldn't work on x86 at all.
smatovic wrote: ↑Thu Aug 10, 2023 4:33 pm
Larry Kaufman mentioned in another post 97% draws between SF 16 and SF 15 with 2"+1' TC in a 620 games match with standard opening and 2 threads, he estimated 99% draws for Rapid TC. How much Elo is still to gain on CCRL Blitz? Time's running, finish line in sight.
--
Srdja
Engines need to use selective search in order to cause the opponent to fall to designed traps and this is not the way they work today.
If you want to find what is possible to achieve you need to build anti-stockfish engine when the target is beating stockfish when you get more time.
Anti-stockfish with white is going to work in the following way:
For white search every possible legal move but for black do not search every possible legal move but simply calculate the move that stockfish is going to play and prune the rest of the moves.
After part of your time(for example half of the target time but maybe different percentage is optimal) you do not calculate stockfish's moves because calculating stockfish's move is too expensive but you remember the stockfish's moves that you already calculated in order to prune the rest of the moves in your search.
In this way the engine may prefer lines when stockfish does mistakes so there is a bigger probability to win and the question is what is the percentage of wins that you can get against stockfish 2''+1' TC in this way(I guess clearly more than using unequal time control).
In today's world, designing an engine specifically to beat Stockfish is actually a damn good idea!
That's how Go engines were built that could beat the derivatives of Alpha Go - and from that knowledge, a human (who is a moderately strong player) was able to teach himself to beat such an engine without computer assistance (this would be fanciful in chess because the game of chess has a much lower branching factor).
Human chess is partly about tactics and strategy, but mostly about memory
Unlike x86 integrated GPUs, the Apple approach allows the CPU and iGPU to directly operate on the same memory so that no copy to/from the iGPU RAM space is required, and no copy over a PCIe bus, either. By consequence, while the raw performance isn't top notch, the latency is much reduced, and that might allow programming approaches that wouldn't work on x86 at all.
I am aware of this. I tend to deal in reality as it exists though. IOW, one might say the same for video games or a whole host of other applications, but the results speak for themselves.
jhellis3 wrote: ↑Fri Aug 11, 2023 6:02 pmI tend to deal in reality as it exists though.
Yeah, it's more of a potential for now, and it's not clear whether the much reduced latency could be a relevant point for chess programming.
IOW, one might say the same for video games
Comparing consoles and PC gaming, the PS5 is roughly on a par with an RX 6700 and has 16GB total RAM. However, an 8GB dedicated GPU such as RTX 3070 or 4060 8GB doesn't cut it even in 1080p anymore with quite some games, despite being faster than an RX 6700, because the bus latency is too much. The solution on PC: use cards with at least 12GB, better 16GB. Then the latency of asset loading is masked with enough buffer.
Means: yes, the latency impact is visible in other domains as well, here and now.
Seriously now, you're not thinking far enough into the future. At the very earliest we'll see AVX-1024 on a 14 nm process in 2015. It's currently the biggest but not the last prerequisite to make homogeneous graphics a reality. By the end of the decade even some of the most power constrained CPUs will achieve 1 TFLOP. So it would be a real shame if by then graphics hasn't become fully programmable. If you look back at the previous progress it becomes instantly obvious that GPUs and CPUs have been converging for many years. And the end result can be nothing other than an architecture where any form of programmable computing is performed by homogeneous cores.
Only a few years ago a lot of people would have claimed discrete graphics cards to be the dominant graphics solution for all eternity. But now it has become clear that integrating graphics into the CPU is the new mainstream. So don't act surprised if the next major shift will be the unification of CPU and GPU cores...
An impressive quote by a brilliant programmer who had some very wrong views despite other very smart people doing their best to dissuade him of his delusions. His work was/is used by Intel, Microsoft, and Google where he worked for some time.
jhellis3 wrote: ↑Fri Aug 11, 2023 7:04 pmReminds me of this thread over a decade ago
That has nothing to do with this discussion and isn't even comparable. He talked about HW features that he thought would come while this discussion is about HW features that are already here right now, available on the market. The question hence is a completely different one. Not whether the HW will come, but whether chess programming can leverage an existing HW property in a useful way, i.e. leveraging low latency while also not suffering from unimpressive raw performance behind that.
Obviously, this can only work if latency, not raw throughput, is the bottleneck factor in the first place. I don't think this is the case e.g. for LC0, which is easily proven by the additional performance LC0 gets out of a more powerful graphics card, which would hardly be possible if it were stalling on latency.
a lot of simple x64 cores + wide vector-units to be used for compute shaders, current GPUs have scalar units included, from my programming point of view, I would prefer a fast scalar-unit with a broad vector-unit with low offload latency, to be coded independently, instead of current state of GPGPU.
The article also mentions the IBM Cell processor, the PowerXCell8i, which powered the IBM Roadrunner, one super-scalar CPU+8 SIMD units, but IBM abandoned that approach in ~2009:
