abik wrote:That makes sense. I personally thought Glaurung's "Threads" was a good choice, so I am going with that one.....
Nooo! What about the programs out there that use processes?
I don't like "cores" either. Really the only term that makes sense IMO is "CPUs".
Threads is wrong for some. Processes is wrong for others. CPUs or Processors is the appropriate term. Cores should be dropped from everyone's vocabulary in this context...
Regarding Glaurung "Threads" is the correct one, CPU (or processor) is defenitly the wrong one.
I can set Glaurung to 10 threads also on a single core CPU and it will run with 10 threads.
When Glaurung speaks of threads it actually means threads that are not CPU, are not processors, are not cores and are not processes: are threads.
Interested people can easly google for definitions of the above terms in case of doubts.
IMHO an universal accepted name should asbtract the implementation detail that can (and do) change among programs and should focus on the function.
I think is less wrong something like
- Nr of parallel searchers
- Parallelism count
- You name them
Marco
I agree (for what that's worth). The parameter relates to what the chess engine does to utilitize the machine it's running on; create threads. Whether each thread runs on a dedicated CPU or not is neither here nor there.
Also isn't this the tip of the iceberg when it comes to how parameters are defined with different chess engines? If the UCI is too 'thin' to specify such things then authors have free reign and all authors have chosen different names for every parameter haven't they - apart from the one or two mentioned in the UCI spec. What's the biggy?
Cheers,
Andy
Come on guys. It is most _certainly "here or there". In chess, you use threads for parallel search. You might have another thread for input/output but it does not execute 100% of the time. This discussion has gone so far out into left field it is completely out of the stadium. For _any_ chess program that is currently in existence, you want _exactly_ one parallel search thread per physical CPU... Nothing else works.
What even when that physical CPU has 2 or more cores? My opinion is that the setting should direct the operation of the engine; if it creates threads for its multi-CPU operation then it makes sense to call the parameter 'Threads'. If it spawns/forks processes then call it 'SpawnCPU' or whatever. I don't understand why so much fuss.
Cheers,
Andy
That's the terminology problem Intel has created. A "cpu" can't have "cores". A cpu "chip" can and does have multiple CPUS (aka cores unfortunately). Again, a "CPU" is "Central Processing Unit". Which includes registers, program counter, etc. The proper term here would be "chip" where a single chip actually has multiple cpus (cores)...
The reason for the "fuss" is "common vocabulary". If we have N different meanings for the same word, or N different words with the same meaning, then confusion is unavoidable... The typical user has no clue about what the difference between threads and procecsses really is. And they shouldn't care nor have to go look it up. If they have a 4 cpu system and they want to use the whole thing, they would probably understand telling the chess program to use 4 cpus or 4 processors...
abik wrote:That makes sense. I personally thought Glaurung's "Threads" was a good choice, so I am going with that one.....
Nooo! What about the programs out there that use processes?
I don't like "cores" either. Really the only term that makes sense IMO is "CPUs".
I agree with Zach, Number of CPU's makes a lot more sense than "Threads" or "Cores", Many years ago, When I first read "Threads" I was bit puzzled and thought it was some kind of technical jargon. When I read "Cpu's" - I can understand it all too well, So It helps a newbie testers.
But you will _never_ with any chess program run more processes than you have processors. And I do mean _never_.
I do not agree. This is very useful for testing.
It absolutely is not good for testing, whether you are developing a program or whatever. If this is your idea of a way to test a parallel search, you need to find a better methodology as it is _highly_ inefficient...
abik wrote:That makes sense. I personally thought Glaurung's "Threads" was a good choice, so I am going with that one.....
Nooo! What about the programs out there that use processes?
I don't like "cores" either. Really the only term that makes sense IMO is "CPUs".
I agree with Zach, Number of CPU's makes a lot more sense than "Threads" or "Cores", Many years ago, When I first read "Threads" I was bit puzzled and thought it was some kind of technical jargon. When I read "Cpu's" - I can understand it all too well, So It helps a newbie testers.
That's the point. 99% of the people using the word "thread" do not know what precisely it means compared to processes...
processors or cpus is pretty straightforward if you ignore Intels bastardized terminology.
bob wrote:That's the terminology problem Intel has created. A "cpu" can't have "cores". A cpu "chip" can and does have multiple CPUS (aka cores unfortunately). Again, a "CPU" is "Central Processing Unit". Which includes registers, program counter, etc. The proper term here would be "chip" where a single chip actually has multiple cpus (cores)...
The reason for the "fuss" is "common vocabulary". If we have N different meanings for the same word, or N different words with the same meaning, then confusion is unavoidable... The typical user has no clue about what the difference between threads and procecsses really is. And they shouldn't care nor have to go look it up. If they have a 4 cpu system and they want to use the whole thing, they would probably understand telling the chess program to use 4 cpus or 4 processors...
Actually "chip" is also not synonymous to Intel's concept of "CPU": A Q6600 has 2 chips, each with 2 cores, in one package. So the correct translation of Intel CPU would be "package", but since all other Integrated-Circuit components also are packaged, or even bunled into "modules" (SIMMs, DIMMs), this would need the specifier "CPU package", just as the MM in SIMM stands for "Memory Module".
Note that the term "thread" is also not clearcut: apart from the software meaning of a process with no independent memory space, there is a harware meaning of "instruction sequencer without private execution units". As in "hyper threading", where an (Intel) core contains 2 threads.
But I think this discussion is a bit devoid of reality: if Intel says CPUs from now on are called "cores", they will be called "cores". Wheather we like it or not. Intel will not disappear...
trojanfoe wrote:What even when that physical CPU has 2 or more cores? My opinion is that the setting should direct the operation of the engine; if it creates threads for its multi-CPU operation then it makes sense to call the parameter 'Threads'. If it spawns/forks processes then call it 'SpawnCPU' or whatever. I don't understand why so much fuss.
Cheers,
Andy
That's the terminology problem Intel has created. A "cpu" can't have "cores". A cpu "chip" can and does have multiple CPUS (aka cores unfortunately). Again, a "CPU" is "Central Processing Unit". Which includes registers, program counter, etc. The proper term here would be "chip" where a single chip actually has multiple cpus (cores)...
The reason for the "fuss" is "common vocabulary". If we have N different meanings for the same word, or N different words with the same meaning, then confusion is unavoidable... The typical user has no clue about what the difference between threads and procecsses really is. And they shouldn't care nor have to go look it up. If they have a 4 cpu system and they want to use the whole thing, they would probably understand telling the chess program to use 4 cpus or 4 processors...
This is precisely my point; rather than having settings which tell the engine about the environment (i.e. the number of CPUs) you should tell it what you want it to use. As already stated if the program creates threads then have a setting called 'Threads' or 'NumThreads'; if it spawns/forks processes then have have a setting called 'Processes' or 'Spawn Processes' or whatever. This is already the case with many other settings - you don't tell it how much memory there is, but rather you tell it how much to use for hash tables etc. Engines can already determine their environment using system calls - they need to be told how much of that environment they are allowed to use; the user drives the requirements and if they don't know what they are doing then they wont get optimal performance - but there are so many factors in getting optimal performance that the best you can do, as an engine author, is to allow your engine to be effectively controlled by the user and that is done using settings.
I agree that it would be great to have standardised setting names, but I cannot see how this can be effectively done for many settings; for example suppose an engine has a thread or more for garbage collection or other housekeeping tasks - it would have then have a setting called 'Search Threads' to control the number of threads used to search positions and another called 'Housekeeping Threads' to control the number of garbage collectors and the like. This 'Search Threads' setting is the same as the 'Threads' setting in other engines, which have only one type of thread, and you are already non-standard. Think about the number of variables (settings) involved with the evaluation function, given the massive difference in implementation. Doesn't seem worth the effort.
bob wrote:That's the terminology problem Intel has created. A "cpu" can't have "cores". A cpu "chip" can and does have multiple CPUS (aka cores unfortunately). Again, a "CPU" is "Central Processing Unit". Which includes registers, program counter, etc. The proper term here would be "chip" where a single chip actually has multiple cpus (cores)...
The reason for the "fuss" is "common vocabulary". If we have N different meanings for the same word, or N different words with the same meaning, then confusion is unavoidable... The typical user has no clue about what the difference between threads and procecsses really is. And they shouldn't care nor have to go look it up. If they have a 4 cpu system and they want to use the whole thing, they would probably understand telling the chess program to use 4 cpus or 4 processors...
Actually "chip" is also not synonymous to Intel's concept of "CPU": A Q6600 has 2 chips, each with 2 cores, in one package. So the correct translation of Intel CPU would be "package", but since all other Integrated-Circuit components also are packaged, or even bunled into "modules" (SIMMs, DIMMs), this would need the specifier "CPU package", just as the MM in SIMM stands for "Memory Module".
Note that the term "thread" is also not clearcut: apart from the software meaning of a process with no independent memory space, there is a harware meaning of "instruction sequencer without private execution units". As in "hyper threading", where an (Intel) core contains 2 threads.
But I think this discussion is a bit devoid of reality: if Intel says CPUs from now on are called "cores", they will be called "cores". Wheather we like it or not. Intel will not disappear...
Typically, to most users, a "chip" is a thing that goes into one socket, We now have a single chip that has two internal pieces of silicon and 4 central processing units. When the original pentium pro came out, we had a single chip, with two pieces of silicon (one for CPU one for L2 cache) and just one processor.
However, I challenge _anyone_ to find any computer architecture book that uses the term "core" to mean "processor" or "cpu". The term CPU is the generally accepted technical term which is often shortened to "processor".
trojanfoe wrote:What even when that physical CPU has 2 or more cores? My opinion is that the setting should direct the operation of the engine; if it creates threads for its multi-CPU operation then it makes sense to call the parameter 'Threads'. If it spawns/forks processes then call it 'SpawnCPU' or whatever. I don't understand why so much fuss.
Cheers,
Andy
That's the terminology problem Intel has created. A "cpu" can't have "cores". A cpu "chip" can and does have multiple CPUS (aka cores unfortunately). Again, a "CPU" is "Central Processing Unit". Which includes registers, program counter, etc. The proper term here would be "chip" where a single chip actually has multiple cpus (cores)...
The reason for the "fuss" is "common vocabulary". If we have N different meanings for the same word, or N different words with the same meaning, then confusion is unavoidable... The typical user has no clue about what the difference between threads and procecsses really is. And they shouldn't care nor have to go look it up. If they have a 4 cpu system and they want to use the whole thing, they would probably understand telling the chess program to use 4 cpus or 4 processors...
This is precisely my point; rather than having settings which tell the engine about the environment (i.e. the number of CPUs) you should tell it what you want it to use. As already stated if the program creates threads then have a setting called 'Threads' or 'NumThreads'; if it spawns/forks processes then have have a setting called 'Processes' or 'Spawn Processes' or whatever. This is already the case with many other settings - you don't tell it how much memory there is, but rather you tell it how much to use for hash tables etc. Engines can already determine their environment using system calls - they need to be told how much of that environment they are allowed to use; the user drives the requirements and if they don't know what they are doing then they wont get optimal performance - but there are so many factors in getting optimal performance that the best you can do, as an engine author, is to allow your engine to be effectively controlled by the user and that is done using settings.
I agree that it would be great to have standardised setting names, but I cannot see how this can be effectively done for many settings; for example suppose an engine has a thread or more for garbage collection or other housekeeping tasks - it would have then have a setting called 'Search Threads' to control the number of threads used to search positions and another called 'Housekeeping Threads' to control the number of garbage collectors and the like. This 'Search Threads' setting is the same as the 'Threads' setting in other engines, which have only one type of thread, and you are already non-standard. Think about the number of variables (settings) involved with the evaluation function, given the massive difference in implementation. Doesn't seem worth the effort.
I think the basic idea is "how many processors do you want to use to play chess?" Because those threads/processes are compute-bound...
bob wrote:Typically, to most users, a "chip" is a thing that goes into one socket, We now have a single chip that has two internal pieces of silicon and 4 central processing units. When the original pentium pro came out, we had a single chip, with two pieces of silicon (one for CPU one for L2 cache) and just one processor.
However, I challenge _anyone_ to find any computer architecture book that uses the term "core" to mean "processor" or "cpu". The term CPU is the generally accepted technical term which is often shortened to "processor".
You don't seem very consistent in your argument. Who do you want to please? The users that think a chip is something that goes into a socket, will not be the people reading books on computer architecture. They are the people that read the ads for "Intel inside" computers that talk about "cores".
I don't see why it would be so important what books on computer architectur say. In principle, architecture is an orthogonal dimension to technology. The same architectural design can be distributed over many chips, or integrated in a single chip, depending on the capacity of the technology used, and the complexity of the design. "Socket" and "package" are not concepts from computer architecture, but very useful concepts in the technological implementation. Of course computer architecture has no need to distinguish CPUs sharing a package ("cores") from CPUs that are a package, or even a complete printed-circuit board. Not knowing the concept of "package", it is blind to the difference. But that doesn't mean the difference does not exist...
