Author: Robert Hyatt
Date: 18:16:30 03/09/00
Go up one level in this thread
On March 09, 2000 at 13:54:05, Bruce Ramsey wrote: >I'd like to thank all who replied. My top 2 questions were about when SMP >versions of chess programs might be available (thanks again for the replies), >yet question 3 on priorities/CPU-sharing got more play. I'm not sure it's worth >it, but I'll add a little more below, including responses to more than Robert >Hyatt's reply. > >On March 08, 2000 at 20:33:37, Robert Hyatt wrote: > >>I don't see how a program can control this. IE in unix, I can self-nice my >>process to a lower priority, but I am not aware of such facilities on other >>systems, as it is normally done by a sysadmin-type decision. With Crafty, >>you can choose the number of processors to use. IE if you run on a quad, >>you can use 1,2,3 or 4 cpus... 3 leaves one for normal stuff. :) > >I think it was Eugene who pointed out WinNT/Win2k's SetThreadPriority API, which >was the mechanism I had in mind when I first posted. This API allows the >programmer to adjust priority all the way up to real-time/critical, which will >totally hog the CPU the thread is on. As Eugene mentioned, use of this API >impacts portability. > >>3 leaves one for normal stuff. :) >This is the kind of thing I was after. I'd like 1 of my 2 CPUs optimally >employed doing chess, and the other CPU available for normal stuff. But one >twist is I'd like that second CPU to run a chess thread at regular priority, >maybe one notch lower than regular/normal, so that any available cycles not >being used for "normal stuff" can get used for chess. Don't do this with crafty... crafty's design assumes that if it is using multiple threads, the threads get 100% of the cpu cycles. If you specify two threads, and one can't get all of a cpu, overall performance can actually be worse than with a single cpu version. Don't try that if you are going to rob big chunks of CPU time... > >>This typically isn't possible, except for an admin-type account. IE in Unix, >>I can _lower_ my priority, but I can't even raise it back to 'normal' once I >>do, only super-user can do that. > >Perhaps this has changed in Win2k, I haven't studied WinNT threading since >before 4.0, but before NT 4.0, any program could adjust priority of its own >threads all the way up to the max. If I recall the history, this feature was >put into NT in response to vehement demands made by programmers who wanted to >write real-time apps running on NT. They considered this feature to be not only >a good feature, but utterly necessary for real-time apps. > If that is true, it is just another reason I wouldn't use windows. Users have no business making scheduling policy decisions on a machine others might be using. The O/S is far better at doing this than a human. I can only imagine the chaos in our labs if everyone fiddled with priorities. :) >>I can't imagine an O/S that bad in scheduling. An I/O bound process, namely >>one running the chess server interface to your engine, would easily have a >>priority high enough to get the few cycles needed to do the I/O. > >Again, "that bad in scheduling" is considered by some programmers to be a very >fine thing. One man's meat is another man's poison... > >>I don't understand why you would want 'real-time priority' for _any_ chess >>thread. Let the engine run normally and suck up all available cycles. On >>ICC, I run on my normal quad xeon that is in my office. Where I am compiling >>linux kernels, doing testing on crafty, etc, all while crafty is playing on the >>server... Let the O/S handle the scheduling... it can do it better than you or >>I can. > >Well, on a 2-CPU system running WinNT/Win2k, if one of the engine threads is >running real-time/critical/top-priority, then WinNT/Win2k never (never - yes >really: never) takes that CPU away from that thread until >A) that thread blocks on a request *it* makes to the OS or otherwise makes >itself not ready to keep running, or >B) it's time to give another ready thread that has that same maximum top >priotity a turn. >This is what the real-time programmers demanded: total CPU control. >(Note: therefore do not create very many top-priority threads as you will waste >CPU having the OS swap them around. One top-priority thread on a 2-CPU system >is good. 12 identical chess engine threads running top priority in a 2-CPU box >is not optimal because you pay to swap the 12 top-but-equal-priority-threads on >and off the 2 CPUs). However, the idea behind real-time is _not_ compute-bound processes. It is all about the time from when a real-time process _should_ be scheduled, until the time when the first instruction in that process is executed... using this as suggested makes an old O/S developer 'cringe'. :) About like a surgeon using a pair of vice-grips in the operating theatre. :) > >The disadvantage has already been mentioned: Programmers who do not understand >the priority model, or who abuse it, can make the system appear to be hung. >Although it is not hung, the end user will think it is. > >The advantage is that on a 2-CPU system running WinNT/Win2k, if one of the >engine threads is running real-time/critical/top-priority, then that one CPU is >optimally employed doing chess calculations. If on the other hand that one >engine thread is not running at top priority, then the OS is going to swap that >thread out from time to time to service other equal-or-higher-priority threads. >Which means less chess calculations will get done. the problem in crafty is that that thread (real-time) might be spinning waiting on a lock to be cleared, while the thread that owns the lock (and will clear it later) is blocked waiting on a CPU. > >This may not matter in today's world - like I said at the top of this post: I'm >not sure it's worth it... In the past, some chess programmers used to howl that >they will never leave DOS behind, that Windows sucks up too much CPU, and that >they can deliver better chess on DOS than on Windows because of that. But >today, CPUs are very fast, perhaps optimal CPU utilization no longer matters in >chess programming. I don't mean this sarcastically at all - I'm not a chess >programmer and am just saying I don't know about this. > >Eugene wrote: >>On NT/Win2k there are many services running (typical user would not turn them >>off). By starting Crafty "start/realtime crafty.exe" you can squeeze several >>more percents of performance - of course, you'll notice that. as even GUI would >>be noticeable slower. > >Yup. That's why I asked about thread priority controls. If as the end-user I'm >allowed to jack 1 of my chess engine threads to the max on a 2-CPU box, or jack >3 up on a 4-CPU box, or if the developer has done this for me, then all but one >of my CPUs will at all times be doing chess and nothing but chess. Optimal, but >as mentioned above it might be >optimal-but-doesn't-really-make-measurable-difference. > >franz wrote: >>actually I would lower it (even to idle time processing) to have a snappier >>interface and better communications, the engine would squeeze all the free >flops out of the CPU and the total performance would not deop significantly. > >Well, if you do it that way watch out for those services Eugene mentioned. In >any modern-day OS there is a lot going on. TCP/IP session maintenance, the >system's side of GUI interface maintenance, and on and on. This is true, but these services (at least in unix) aren't taking much cpu time. They are almost always sleeping except when woken up to handle very short-duration event... > >franz wrote: >>Even if you drop 2% of the CPU time it is not an issue at all. > >Although at one time I knew quite a lot about thread priority in WinNT and >making optimal use of CPU's, I'm really not qualified to say whether making >optimal use of CPUs makes a worthwhile difference in computer chess today. >And I repeat my caveat about my expertise: I worked NT in the pre-4.0 days - >anyone know if thread priority API programming has changed since? > >thanks, Bruce
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.