Earl J wrote in the "NEW: Rendertest-2010" thread:
"I believe the term core is also interchangeable with thread"
The answer is No. But they are very related and worthy of understanding.
Earl J's post spurred me to write the following for anyone interested in understanding CPU cores, hyper-threading, program threads, program processes, and how they relate to rendering in Vegas and adjusting the number of rendering threads in the Vegas preferences window.
HARDWARE
CPU (Central Processing Unit): The part of a computer system that carries out the instructions in a computer program to perform arithmetic, logic, and input/output functions.
Core: Essentially, a 'core' has the same definition as CPU. Any CPU contains some ancillary electronics and the core is the actual part where programs are executed. The term 'core' isn't traditionally applied to single-core CPU's and gained use with the advent of multiple-core CPU's. A multi-core CPU is basically the same as multiple CPUs and can execute multiple programs at once.
THINK OF YOUR CPU OR CORES AS YOUR AVAILABLE MANPOWER. EACH CPU OR CORE IS ONE 'MAN' ABLE TO PERFORM WORK.[/B]. Vegas is a program. Software, like speech, is not physical--though (again, like speech) it can only be delivered on physical media (CD, electronic signals, sound waves, etc.). Software is simply a list of instructions that tell the CPU to do something. An application like Vegas contains millions of instructions. The instructions all software are built upon are extremely small and simple operations: Move '34' to this memory location. Subtract 3. Subtract again until the answer is an even number. -- It takes MILLIONS of instructions to simply move your mouse pointer across the screen! At 3 GHz (3 billion operations per second) these millions of instructions happen in milliseconds.
Process: A process is a program, but the term is technically very specific. A process is a single program that is allocated its own unique memory space in which to execute. The operating system (Windows/Linux/Mac) performs the allocation of memory (and other resources) and then launches the program within that space. Each process is separate from all others on the machine. Task Manager displays PROCESSES. If you open three copies (called instances) of a process -- say, Internet Explorer -- you will see three separate Internet Explorer processes in Task Manager. You can kill a process without affecting other processes, as long as the two processes don't rely upon each other.
Each process does it's own thing, but processes may communicate with each other towards a common goal. A process may spawn (create and launch) other processes or sub-processes owned by the parent process.
THINK OF PROCESSES AS A LIST OF INSTRUCTIONS ON HOW TO BUILD A HOUSE. YOU'LL NEED MANPOWER TO DO THE WORK (THE CPU!) TWO MEN (CORES) GETS THE HOUSE BUILT TWICE AS FAST! YOUR PROGRAM MIGHT SPAWN A SEPARATE PROCESS TO DO THE LANDSCAPING (ANOTHER LIST OF INSTRUCTIONS AND MORE MANPOWER).
Sidebar -- Vegas processes: Opening Vegas allocates and launches a main process (vegas100.exe) as well as several sub-processes which can be seen in Task Manager: ErrorReportLauncher.exe, FileIOSurrogate.exe, sfvstserver.exe. Each process is a SEPARATE program. It is their combined functionality that comprises the Vegas application. Multiple processes are common with larger and more complex software applications. Most applications only have one process.
- - - - -
NEITHER HARDWARE NOT SOFTWARE
Context (or State): To understand threads we must understand something called context, also called state. Imagine you are a CPU core (a worker man) and you are pounding a nail. To be specific (and computers are VERY specific), you are on the sixth swing of your hammer out of the eight necessary blows needed to drive nail #34,751 in our house. Suddenly, you are interrupted by a call from your wife on your cell phone (the operating system, in this case). Your wife has a question she needs help with (the operating system needs your help to move the mouse arrow pointer one pixel over on the screen). After your interruption is over... What were you doing? Where were you at? In order to return to your previous task you must pick up from EXACTLY were you left off. Oh, that's right! Your arm was on the upswing of blow number 6 on nail #34,751. The precise position you were in is called your state. To resume blow number 6 on nail #34,751 after the interruption, you must be returned to the same state or context you were in previously--kneeling, nail in your left hand, hammer in your right, raised over your head--in order to continue.
The operating system interrupts the worker men (cores) thousands of times per second. This is because there are dozens of things that go on all at once in your computer that can't wait (or the mouse cursor freezes--you've seen that, right?)
The operating system stops a worker and SAVES THE CONTEXT of what he was doing so that he can return to that job a few millionths of a second later. This is called a context switch.
Thread: A thread is simply a task that is in the middle of being done (driving a nail -- or -- rendering a frame of a video). Threads are tasks that are in progress--threads are not hardware (the CPU or cores provide men to DO THE WORK); NOR are threads software (which provide the INSTRUCTIONS for the work). Rather, threads are the tasks embarked upon.
Let's try to illustrate better: You put one man (one CPU) to work building a house. The software is the list of instructions to complete the job. A single task is embarked upon at a time, completed, then a new task started. This is called single-threaded execution. All processes have at least one thread. Without a thread, the program just sits and takes up memory with nothing going on (no work on the house).
But now, let's say, you have four men (four CPU cores) available. If we operate in single-threaded fashion only one man is working at a time, so 75% of our manpower is sitting around drinking beer! No good. Thus, we utilize multiple-threaded execution to take advantage of all the available manpower. Now, our program (process) spawns four separate tasks (threads) at a time and puts everyone to work --- you pound nails, you hang drywall, you paint, etc.
In reality, Vegas spawns DOZENS of threads. Each thread of execution gets a small task done. Moreover, the operating system is juggling dozens of processes each with their own set of threads--THERE ARE LITERALLY HUNDREDS OF THREADS OF EXECUTION in existence on your machine at any given time.
IMPORTANT CONCEPT: ONLY
Thus, out of hundreds of threads, your fancy-dancy quad-core i7 only has FOUR HYPER-THREADED WORKER MEN available at once. Only EIGHT threads are being worked on out of hundreds!!??? How does anything get done??? The answer is the context-switching we talked about above. Each thread gets a 'man' assigned to work on it (by the operating system) for a few microseconds at a time, dozens of times per second. Thus, the entire work of all threads in all processes in all the programs running on your computer makes progress in tiny time-slice intervals.
But importantly: To YOU, the user, it appears all your programs are running at once! In reality, the 'worker men' in your CPU are dividing up their time amongst all the threads. The 'worker men' are interrupted by context-switches thousands of times per second to achieve this apparent parallelism.
Now, imagine if your wife interrupted you a thousand times per second?
- - - - -
VEGAS RENDERING THREADS (ALL THREADS ARE NOT EQUAL)
If you open Task Manager, you will notice that the "Processes" tab has a column for "CPU". This is the percentage of CPU time that is being spent servicing all of the threads that belong to that process. You'll notice a lot of the processes have a big fat 0% next to them. This is because the threads within that process are idle and don't have any task to do. Maybe our house painting task is waiting for the drywall task to finish (or your printer is waiting for a print job). In any case, when the CPU context-switches to idle threads, the thread simply cedes control back to the CPU so that valuable worker man time isn't wasted.
When your computer is idle, the "System Idle Process" spins away to use up excess CPU time and you'll see a substantial percentage of time next to it in Task Manager (the CPU cannot stop working just like your car motor doesn't shut off at a stop light, though it does use less power at idle).
When you start a rendering job in Vegas, it spawns multiple threads, giving each a part of the task. The reason for this is to ensure that there are enough concurrent tasks (threads) to keep the manpower in your CPU cores busy and the job gets done more quickly.
Vegas allows you to adjust the number of threads spawned for rendering work. There are many reasons (and theories) why you might want to adjust this. In general, you want at least the same number of threads as you have CPU cores so that all cores have work to do. If you have a hyper-threading CPU (Intel) then you might want twice as many threads as CPU cores.
But, remember our discussion about hyper-threading? If two threads are doing the exact same work hyper-threading is less effective and can even slow things down. Experimentation would likely reveal that hyper-threaded cores do not double CPU output (halve rendering times).
It would be very useful to do some test renders with each of the various output codecs using different numbers of rendering threads. One codec might utilize hyper-threading effectively, and another might be hindered by hyper-threading. One user suggested on this forum to spawn one less rendering thread than CPU cores available to leave time for the main program to run. Is this effective? It would be interesting to test!
What if Vegas is slowing your computer down too much? Say you want to render in the background, but still have other applications (processes) that need substantial CPU time. In Vegas you can adjust the number of rendering threads down so that you leave CPU cores not working and available to threads belonging to other processes.
"I believe the term core is also interchangeable with thread"
The answer is No. But they are very related and worthy of understanding.
Earl J's post spurred me to write the following for anyone interested in understanding CPU cores, hyper-threading, program threads, program processes, and how they relate to rendering in Vegas and adjusting the number of rendering threads in the Vegas preferences window.
HARDWARE
CPU (Central Processing Unit): The part of a computer system that carries out the instructions in a computer program to perform arithmetic, logic, and input/output functions.
Core: Essentially, a 'core' has the same definition as CPU. Any CPU contains some ancillary electronics and the core is the actual part where programs are executed. The term 'core' isn't traditionally applied to single-core CPU's and gained use with the advent of multiple-core CPU's. A multi-core CPU is basically the same as multiple CPUs and can execute multiple programs at once.
THINK OF YOUR CPU OR CORES AS YOUR AVAILABLE MANPOWER. EACH CPU OR CORE IS ONE 'MAN' ABLE TO PERFORM WORK.[/B]. Vegas is a program. Software, like speech, is not physical--though (again, like speech) it can only be delivered on physical media (CD, electronic signals, sound waves, etc.). Software is simply a list of instructions that tell the CPU to do something. An application like Vegas contains millions of instructions. The instructions all software are built upon are extremely small and simple operations: Move '34' to this memory location. Subtract 3. Subtract again until the answer is an even number. -- It takes MILLIONS of instructions to simply move your mouse pointer across the screen! At 3 GHz (3 billion operations per second) these millions of instructions happen in milliseconds.
Process: A process is a program, but the term is technically very specific. A process is a single program that is allocated its own unique memory space in which to execute. The operating system (Windows/Linux/Mac) performs the allocation of memory (and other resources) and then launches the program within that space. Each process is separate from all others on the machine. Task Manager displays PROCESSES. If you open three copies (called instances) of a process -- say, Internet Explorer -- you will see three separate Internet Explorer processes in Task Manager. You can kill a process without affecting other processes, as long as the two processes don't rely upon each other.
Each process does it's own thing, but processes may communicate with each other towards a common goal. A process may spawn (create and launch) other processes or sub-processes owned by the parent process.
THINK OF PROCESSES AS A LIST OF INSTRUCTIONS ON HOW TO BUILD A HOUSE. YOU'LL NEED MANPOWER TO DO THE WORK (THE CPU!) TWO MEN (CORES) GETS THE HOUSE BUILT TWICE AS FAST! YOUR PROGRAM MIGHT SPAWN A SEPARATE PROCESS TO DO THE LANDSCAPING (ANOTHER LIST OF INSTRUCTIONS AND MORE MANPOWER).
Sidebar -- Vegas processes: Opening Vegas allocates and launches a main process (vegas100.exe) as well as several sub-processes which can be seen in Task Manager: ErrorReportLauncher.exe, FileIOSurrogate.exe, sfvstserver.exe. Each process is a SEPARATE program. It is their combined functionality that comprises the Vegas application. Multiple processes are common with larger and more complex software applications. Most applications only have one process.
- - - - -
NEITHER HARDWARE NOT SOFTWARE
Context (or State): To understand threads we must understand something called context, also called state. Imagine you are a CPU core (a worker man) and you are pounding a nail. To be specific (and computers are VERY specific), you are on the sixth swing of your hammer out of the eight necessary blows needed to drive nail #34,751 in our house. Suddenly, you are interrupted by a call from your wife on your cell phone (the operating system, in this case). Your wife has a question she needs help with (the operating system needs your help to move the mouse arrow pointer one pixel over on the screen). After your interruption is over... What were you doing? Where were you at? In order to return to your previous task you must pick up from EXACTLY were you left off. Oh, that's right! Your arm was on the upswing of blow number 6 on nail #34,751. The precise position you were in is called your state. To resume blow number 6 on nail #34,751 after the interruption, you must be returned to the same state or context you were in previously--kneeling, nail in your left hand, hammer in your right, raised over your head--in order to continue.
The operating system interrupts the worker men (cores) thousands of times per second. This is because there are dozens of things that go on all at once in your computer that can't wait (or the mouse cursor freezes--you've seen that, right?)
The operating system stops a worker and SAVES THE CONTEXT of what he was doing so that he can return to that job a few millionths of a second later. This is called a context switch.
Thread: A thread is simply a task that is in the middle of being done (driving a nail -- or -- rendering a frame of a video). Threads are tasks that are in progress--threads are not hardware (the CPU or cores provide men to DO THE WORK); NOR are threads software (which provide the INSTRUCTIONS for the work). Rather, threads are the tasks embarked upon.
Let's try to illustrate better: You put one man (one CPU) to work building a house. The software is the list of instructions to complete the job. A single task is embarked upon at a time, completed, then a new task started. This is called single-threaded execution. All processes have at least one thread. Without a thread, the program just sits and takes up memory with nothing going on (no work on the house).
But now, let's say, you have four men (four CPU cores) available. If we operate in single-threaded fashion only one man is working at a time, so 75% of our manpower is sitting around drinking beer! No good. Thus, we utilize multiple-threaded execution to take advantage of all the available manpower. Now, our program (process) spawns four separate tasks (threads) at a time and puts everyone to work --- you pound nails, you hang drywall, you paint, etc.
In reality, Vegas spawns DOZENS of threads. Each thread of execution gets a small task done. Moreover, the operating system is juggling dozens of processes each with their own set of threads--THERE ARE LITERALLY HUNDREDS OF THREADS OF EXECUTION in existence on your machine at any given time.
IMPORTANT CONCEPT: ONLY
Thus, out of hundreds of threads, your fancy-dancy quad-core i7 only has FOUR HYPER-THREADED WORKER MEN available at once. Only EIGHT threads are being worked on out of hundreds!!??? How does anything get done??? The answer is the context-switching we talked about above. Each thread gets a 'man' assigned to work on it (by the operating system) for a few microseconds at a time, dozens of times per second. Thus, the entire work of all threads in all processes in all the programs running on your computer makes progress in tiny time-slice intervals.
But importantly: To YOU, the user, it appears all your programs are running at once! In reality, the 'worker men' in your CPU are dividing up their time amongst all the threads. The 'worker men' are interrupted by context-switches thousands of times per second to achieve this apparent parallelism.
Now, imagine if your wife interrupted you a thousand times per second?
- - - - -
VEGAS RENDERING THREADS (ALL THREADS ARE NOT EQUAL)
If you open Task Manager, you will notice that the "Processes" tab has a column for "CPU". This is the percentage of CPU time that is being spent servicing all of the threads that belong to that process. You'll notice a lot of the processes have a big fat 0% next to them. This is because the threads within that process are idle and don't have any task to do. Maybe our house painting task is waiting for the drywall task to finish (or your printer is waiting for a print job). In any case, when the CPU context-switches to idle threads, the thread simply cedes control back to the CPU so that valuable worker man time isn't wasted.
When your computer is idle, the "System Idle Process" spins away to use up excess CPU time and you'll see a substantial percentage of time next to it in Task Manager (the CPU cannot stop working just like your car motor doesn't shut off at a stop light, though it does use less power at idle).
When you start a rendering job in Vegas, it spawns multiple threads, giving each a part of the task. The reason for this is to ensure that there are enough concurrent tasks (threads) to keep the manpower in your CPU cores busy and the job gets done more quickly.
Vegas allows you to adjust the number of threads spawned for rendering work. There are many reasons (and theories) why you might want to adjust this. In general, you want at least the same number of threads as you have CPU cores so that all cores have work to do. If you have a hyper-threading CPU (Intel) then you might want twice as many threads as CPU cores.
But, remember our discussion about hyper-threading? If two threads are doing the exact same work hyper-threading is less effective and can even slow things down. Experimentation would likely reveal that hyper-threaded cores do not double CPU output (halve rendering times).
It would be very useful to do some test renders with each of the various output codecs using different numbers of rendering threads. One codec might utilize hyper-threading effectively, and another might be hindered by hyper-threading. One user suggested on this forum to spawn one less rendering thread than CPU cores available to leave time for the main program to run. Is this effective? It would be interesting to test!
What if Vegas is slowing your computer down too much? Say you want to render in the background, but still have other applications (processes) that need substantial CPU time. In Vegas you can adjust the number of rendering threads down so that you leave CPU cores not working and available to threads belonging to other processes.