Author: Bob Durrett
Date: 12:41:48 11/11/02
Go up one level in this thread
On November 11, 2002 at 15:25:42, Robert Hyatt wrote: >On November 11, 2002 at 13:39:08, Vincent Diepeveen wrote: > >>On November 11, 2002 at 13:18:12, Russell Reagan wrote: >> >>That's how the OS reports it to you. In fact i have >>different statements here from different OS experts. >> >>One of them said for example: "in console this OS (without quoting >>which OS he referred to) i measured for my application A that >>i saved out up to 10% in speed". >> >>I am no expert here, but at least his words made sense. > >I _am_ an O/S expert. And I can't imagine how such a thing would happen. Yes, >if you are doing graphics to the screen, then overhead might be high. But for a >chess engine, running in "console mode" I don't believe _any_ O/S will use any >significant amount of system resources. Even 1% would be way high for any >system I have tested. I'd be happy to compare windows 98, Windows NT, windows >ME, Windows 2000, Windows XP, Linux, Solaris, IRIX, Unicos, HPUX, AIX >and probably some others I have forgotten that are laying around here. Crafty >runs >on all of them. The only difference is compilers and processor speed. The O/S >simply does _not_ affect a console-mode program that I can measure. > >> >>If many threads are running at an OS, then i can imagine that switching >>each 0.002 seconds to another thread is going to cause damage. > >That is called context switching overhead, and it is constant for each specific >processor architecture. The operating system should have no real influence here >at all. > >> >>Context switching of the processor etcetera. >> >>At todays processors however it won't be 10% i bet. > >It won't even be 1% for a console app. > > > >> >>So taking that into account, basically the compiler matters a lot. >> >>Nowadays however compilers work for different OSes. I do not know how >>good compilers are for mckinley/R14000/alpha/Sun when compared to X86 >>compilers. >> >>I get impression that the x86 compilers have made up a lot of terrain. >> >>the alpha compiler was said to be very very good, but it never impressed >>upon DIEP in fact. Speeds at alpha were horrible. On the other hand others >>reported the Sun to be a horrible processor/compiler combination, but >>DIEP ran fine at SUN cpu's. McKinley is very fast for DIEP (1Ghz Mckinley >>like a 1.33Ghz K7 even) but i have no idea how well its compiler is >>compared to other processors. >> >>If i compare the specs from the K7/P3 versus the McKinley, we see >>a major difference in specifications: >> K7 + P3 can do up to 3 instructions a clock >> McKinley is doing 6 instructions a bundle (if i understand well) >> >> K7 + P3 have horrible small L2 cache >> McKinley has *huge* L3 cache 3 MB even >> >> Yet it is only 33% faster or so. With some more fine tuning i might >> get it bigger. I wasn't capable yet to check out what branch prediction >> means for it. >> >>In general i have *no* idea what the OS eats from those processors. I get >>impression however that the OS gets more important at SMP machines than it >>is at single cpu machines. >> > >No reason for that to be true. All an SMP OS has to do is to run the process >scheduler when a current process blocks. The overhead is no worse for using >N processors or 1 Processor, since the process scheduler does the same work, >basically. > > > > > >>Basically these compilers which usually only works for 1 or 2 OSes, >>determine what speed you get under that OS, because even if it would be >>an incredible 10% which the OS eats (hard to believe for me it would be >>that high for todays OSes) then that still means peanuts compared to what >>a good compiler can save you out. >> > > >Good statement. The speed of the processor, and the quality of the optimizer >in the compiler are _the_ important details. The O/S is irrelevant as far as >performance goes. > > I am a non-programmer but assume that all professional programmers know all about optimizers. Sounds like a good thing to have, anyway. : ) So far, we have been talking about the case where there is only one big program running on the computer and that is the chess engine [& GUI maybe]. But many people [I presume] also run Office or Word and maybe other software. I almost always have CB8 running when using Fritz, for example. Perhaps running several big programs at once would cause the operating system to be more busy? We have also been assuming that the computer would have ample RAM. However, maybe not everybody has an expensive computer with tons of RAM. There may be competition for the available RAM, and the OS would be one of the competitors. So, can the conclusions reached so far be extended to these cases too? Incidentally, why would the Fritz people write their program in assembly language, essentially bypassing an "optimizer"? Does it make enough difference to go to that much trouble? [Maybe the Fritz people think only in assembly language? : ) ] P.S. Note that I am trying to use plenty of smileys whenever I intend humor. Bob D. > > > > > >>>On November 11, 2002 at 13:02:44, Bob Durrett wrote: >>> >>>>Would the engine perform significantly better using that dedicated operating >>>>system? [As compared to using a commercially available OS] >>> >>>You can get an idea of how much time is used by the OS. On my computer I look >>>under Task Manager and it says: >>> >>>Image Name CPU Time >>>System Idle Process 6:19:14 >>>IEXPLORE.EXE 0:02:16 >>>msdev.exe 0:01:22 >>>Explorer.exe 0:00:53 >>>System 0:00:22 >>> >>>And so on. So I have over 6 hours of idle time, and the next biggest chunk of >>>CPU usage time was by Internet Explorer, of a whole 2 minutes. That means there >>>is 99.5% of the CPU time that could have been used by a chess program. So the >>>question is whether or not a 0.5% increase in speed is going to mean >>>"significantly better" results. I think not.
This page took 0.02 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.