<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
	<id>https://wiki.expertiza.ncsu.edu/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Lreddy</id>
	<title>Expertiza_Wiki - User contributions [en]</title>
	<link rel="self" type="application/atom+xml" href="https://wiki.expertiza.ncsu.edu/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Lreddy"/>
	<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=Special:Contributions/Lreddy"/>
	<updated>2026-07-14T05:46:34Z</updated>
	<subtitle>User contributions</subtitle>
	<generator>MediaWiki 1.41.0</generator>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki4_helperThreads&amp;diff=10476</id>
		<title>CSC/ECE 506 Fall 2007/wiki4 helperThreads</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki4_helperThreads&amp;diff=10476"/>
		<updated>2007-12-04T01:42:09Z</updated>

		<summary type="html">&lt;p&gt;Lreddy: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''''A helper thread is a thread that does some of the work of the main thread in advance of the main thread so that the main thread can work more quickly. The Olukotun text only scratches the surface on all the different ways that helper threads can be used. Survey these ways, making sure to include the Slipstream approach developed at NCSU.'''''&lt;br /&gt;
&lt;br /&gt;
'''What is a helper thread?'''&lt;br /&gt;
&lt;br /&gt;
It has been experienced that enhancing the speed of microprocessors is becoming an increasingly difficult &lt;br /&gt;
task. It is because of various reasons of which few are stated below:&lt;br /&gt;
&lt;br /&gt;
1) Typical instruction streams have only limited parallelism. So a superscalar pipeline which can issue more than four         instruction per cycle is of little benefit compared to the cost it incurs.&lt;br /&gt;
&lt;br /&gt;
2) As the depth of the pipeline increases, the cost of pipeline flushes during branch mispredictions becomes intolerable.&lt;br /&gt;
&lt;br /&gt;
3) As the speed and number of transistors on chip increase, the power required to drive complex logic circuits at high clock rate also increases beyond tolerable limit.&lt;br /&gt;
&lt;br /&gt;
So, processor manufacturers are switching to a new design paradigm: the chip microprocessors, which is also known as multicore microprocessors or manycore microprocessors. As the name implies, a chip multiprocessor is simply a group of uniprocessors integrated onto the same processor chip so that they may act as a team, filling the area that would have originally been filled with a single large processors with several smaller cores.&lt;br /&gt;
&lt;br /&gt;
The depth of the pipeline of the uniprocessor cores used will be just enough to exploit the limited instruction level parallelism present in programs inorder to keep power utilization low.So to better exploit the potential of chip multiprocessors (CMPs)the applications are divided into semi - independent parts, or threads that can operate simultaneously across the processors within a system. &lt;br /&gt;
&lt;br /&gt;
The simplest way to use parallel threads within a CMP to increase the performance of a single thread is to have helper threads. A 'helper' thread performs work on behalf of main thread in an effort to accelerate its performance. Helper threads run ahead of main thread because all the instructions that are not absolutely necessary for performing the function that the helper thread is meant for is removed from the program that the helper thread executes. Hence they can accuarately predict branches, start the long latency operations early, prefect the data needed by the main thread etc which are explained in detail below.&lt;br /&gt;
&lt;br /&gt;
The following figure shows the  main thread and helper thread in a two core chip multiprocessor.Main thread spawns the helper thread. Helper thread has the instructions that form a subset of the instructions in the main thread. As a result helper thread executes less instructions than the main thread and hence effectively executes ahead of main thread. As a result, it can start a long latency operations early and provide the result to the main thread by the time main thread starts executing that long latency operation.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:Helper threads.png]] &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Uses of helper threads'''&lt;br /&gt;
&lt;br /&gt;
'''Predicting branch at early stages:'''&lt;br /&gt;
&lt;br /&gt;
As mentioned earlier, helper threads are made up of program copies of the main thread stripped of all unessential parts which are not of absolute necessity for the helper thread to achieve it tasks. Hence helper threads runs ahead of main thread. Hence helper threads can do computations that are necessary to decide the direction of the branch. As the branch direction is decided using the result of actual computation and not just prediction, the branch predictor will be trained in favour to the actual branch direction taken by the helper thread. So, branch predictions will be more accuarate. This will inturn remove branch mispredictions which may occur when branch predictions are used.&lt;br /&gt;
&lt;br /&gt;
'''Prefetching of Data:''' &lt;br /&gt;
&lt;br /&gt;
Since helper threads run ahead of main thread, they can predict which data in memory is needed in&lt;br /&gt;
future by the main thread.they prefetch the data required by the main thread. The helper thread prefetches&lt;br /&gt;
the data and places it in the nearest cache accessible to the main thread. This avoids most of the L1 cache&lt;br /&gt;
misses that would have been encountered by the main thread had if helper thread was not present. As the &lt;br /&gt;
memory latency is reduced, the execution of main thread speeds up.&lt;br /&gt;
   &lt;br /&gt;
'''Memory Bug Reduction:'''&lt;br /&gt;
&lt;br /&gt;
Memory related bugs such as reads from unitialised memory, read or writes using dangling pointers or &lt;br /&gt;
memory leaks are difficult to detect by code inspection because they may invoive different code fragments &lt;br /&gt;
and exist in differnt modules or source code files. Compilers are of little help becuase it fails to &lt;br /&gt;
disambiguate pointers. Hence, in practice memory bug detection relies on run time checkers that insert&lt;br /&gt;
monitor code to the application during testing. In CMPs, the program which detects the memory bugs can run&lt;br /&gt;
as a helper thread.&lt;br /&gt;
&lt;br /&gt;
Ex: Heapmon, a memory bug checker monitors application heap space to detect heap memory bugs. The memory &lt;br /&gt;
access events in the application thread are automatically forwarded to helper thread using appropriate &lt;br /&gt;
hardware mechanisms. Also the redundant and unnecessary  memory accessess are filtered out. Hence the helper&lt;br /&gt;
thread approach completely decouples bug monitoring from appication execution and the filtering mechanism reduces&lt;br /&gt;
bug - check frequency. Conseqently, HeapMon achieves a very low performance overhead.&lt;br /&gt;
&lt;br /&gt;
'''Slipstream approach for helper threads:'''&lt;br /&gt;
&lt;br /&gt;
Slipstream approach is developed at North Carolina State University. &lt;br /&gt;
Slipstream execution provides a simple means to use a second processor in a CMP to accelerate a single program.Slipstream execution involves running two redundant copies of the program. A significant number of dynamic instructions are speculatively removed from one of the program copies, without sacrificing its ability to make correct forward progress. The second program verifies the forward progress of the first and is also sped up in the process.  &lt;br /&gt;
&lt;br /&gt;
The speculative reduced program is called A-stream (Advanced Stream) and runs ahead of the unreduced program (main thread or Redundant stream).The R-stream exploits the A-stream to get an accurate picture of the future. For example, the A-stream &lt;br /&gt;
provides very accurate branch and value predictions. The predictions are more accurate than predictions made by conventional history-based predictors because they are produced by future program computation. speculative A-stream occasionally (but&lt;br /&gt;
infrequently) goes astray. The R-stream serves as a checker of the speculative A-stream and redirects it when needed.&lt;br /&gt;
&lt;br /&gt;
Synchronization between an R-stream and its corresponding A-stream is required for two reasons.First, an A-stream that has taken a completely wrong control path and is generating useless data access predictions has to be corrected. Second, limit how far the A-stream gets ahead, so that its prefetches are not issued so early that the prefetched lines are often replaced or invalidated in the L2 cache before the R-stream uses them. A single semaphore is required between each A-stream/&lt;br /&gt;
R-stream pair to control their synchronization. It can be a shared hardware register, but any shared location that supports an atomic read-modify-write operation is sufficient. Using this semaphore, the following are controlled&amp;lt;br/&amp;gt;&lt;br /&gt;
(a) how many synchronization events the A-stream can skip without waiting for the R-stream&amp;lt;br/&amp;gt;&lt;br /&gt;
(b) whether the synchronization is local (involving only the companion R-stream) or global (involving all R-streams). The initial value of the semaphore indicates how many sessions the A-stream may proceed ahead of the Rstream. &amp;lt;br/&amp;gt;&lt;br /&gt;
This can be viewed as creating an initial pool of tokens that are consumed as the A-stream enters a new session. When there are no tokens, the A-stream may not proceed. The R-stream issues tokens by incrementing the semaphore counter.Once the A thread gets the semaphore, A threads advances and gets past the R thread.&lt;br /&gt;
&lt;br /&gt;
'''Disadvantages of helper threads:'''&lt;br /&gt;
&lt;br /&gt;
A very tight synchronisation is needed between the main thread and the helper threads in oder to keep them the proper distance ahead of main thread. If the helper threads are too far ahead, then they will cause cache thrashing by prefetching data and then replaing it with subsequent prefetches beofre the main thread can even use it. If they are not far enough ahead, they might not be able to prefetch cache lines in time. &lt;br /&gt;
&lt;br /&gt;
Only certain types of single threaded programs can be speeded up with these techniques. Most integer applications have regular data access patterns and hence there will be only few misses to eliminate. The applications with larger memory footprints are easily parellelisable and hence doesn't run on a single main thread. Most floating point applications the data access patterns are fairly regular and hence can be prefetched easily using hardware or software prefetch mechanisms. Hence the range of programs that can be accelerated using helper threads is fairly limited.&lt;br /&gt;
&lt;br /&gt;
'''References'''&lt;br /&gt;
&lt;br /&gt;
1)ChipMultiprocessor Architecture:Techniques to Improve Throughput and Latency by Kunle Olukotun, Lance Hammond, and James Laudon&lt;br /&gt;
&lt;br /&gt;
2)Slipstream Execution Mode for CMP-Based Multiprocessors by Khaled Z. Ibrahim, Gregory T. Byrd, and Eric Rotenberg&lt;br /&gt;
&lt;br /&gt;
3)http://www.research.ibm.com/journal/rd/502/shetty.html&lt;br /&gt;
&lt;br /&gt;
4)http://www.tinker.ncsu.edu/ericro/research/slipstream.htm&lt;br /&gt;
&lt;br /&gt;
5)A Survey of Helper Threads And Their Implementation by Ahren Studer&lt;br /&gt;
&lt;br /&gt;
6)Design and Implementation of a Compiler Framework for Helper Threading on Multicore Processors http://pact05.ce.ucsc.edu/datacentric.pdf&lt;/div&gt;</summary>
		<author><name>Lreddy</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki4_2_helperThreads&amp;diff=10475</id>
		<title>CSC/ECE 506 Fall 2007/wiki4 2 helperThreads</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki4_2_helperThreads&amp;diff=10475"/>
		<updated>2007-12-04T01:31:47Z</updated>

		<summary type="html">&lt;p&gt;Lreddy: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''''A helper thread is a thread that does some of the work of the main thread in advance of the main thread so that the main thread can work more quickly. The Olukotun text only scratches the surface on all the different ways that helper threads can be used. Survey these ways, making sure to include the Slipstream approach developed at NCSU.'''''&lt;br /&gt;
&lt;br /&gt;
'''What is a helper thread?'''&lt;br /&gt;
&lt;br /&gt;
It has been experienced that enhancing the speed of microprocessors is becoming an increasingly difficult &lt;br /&gt;
task. It is because of various reasons of which few are stated below:&lt;br /&gt;
&lt;br /&gt;
1) Typical instruction streams have only limited parallelism. So a superscalar pipeline which can issue more than four         instruction per cycle is of little benefit compared to the cost it incurs.&lt;br /&gt;
&lt;br /&gt;
2) As the depth of the pipeline increases, the cost of pipeline flushes during branch mispredictions becomes intolerable.&lt;br /&gt;
&lt;br /&gt;
3) As the speed and number of transistors on chip increase, the power required to drive complex logic circuits at high clock rate also increases beyond tolerable limit.&lt;br /&gt;
&lt;br /&gt;
So, processor manufacturers are switching to a new design paradigm: the chip microprocessors, which is also known as multicore microprocessors or manycore microprocessors. As the name implies, a chip multiprocessor is simply a group of uniprocessors integrated onto the same processor chip so that they may act as a team, filling the area that would have originally been filled with a single large processors with several smaller cores.&lt;br /&gt;
&lt;br /&gt;
The depth of the pipeline of the uniprocessor cores used will be just enough to exploit the limited instruction level parallelism present in programs inorder to keep power utilization low.So to better exploit the potential of chip multiprocessors (CMPs)the applications are divided into semi - independent parts, or threads that can operate simultaneously across the processors within a system. &lt;br /&gt;
&lt;br /&gt;
The simplest way to use parallel threads within a CMP to increase the performance of a single thread is to have helper threads. A 'helper' thread performs work on behalf of main thread in an effort to accelerate its performance. Helper threads run ahead of main thread because all the instructions that are not absolutely necessary for performing the function that the helper thread is meant for is removed from the program that the helper thread executes. Hence they can accuarately predict branches, start the long latency operations early, prefect the data needed by the main thread etc which are explained in detail below.&lt;br /&gt;
&lt;br /&gt;
The following figure shows the  main thread and helper thread in a two core chip multiprocessor.Main thread spawns the helper thread. Helper thread has the instructions that form a subset of the instructions in the main thread. As a result helper thread executes less instructions than the main thread and hence effectively executes ahead of main thread. As a result, it can start a long latency operations early and provide the result to the main thread by the time main thread starts executing that long latency operation.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:Helper threads.png]] &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Uses of helper threads'''&lt;br /&gt;
&lt;br /&gt;
'''Predicting branch at early stages:'''&lt;br /&gt;
&lt;br /&gt;
As mentioned earlier, helper threads are made up of program copies of the main thread stripped of all unessential parts which are not of absolute necessity for the helper thread to achieve it tasks. Hence helper threads runs ahead of main thread. Hence helper threads can do computations that are necessary to decide the direction of the branch. As the branch direction is decided using the result of actual computation and not just prediction, the branch predictor will be trained in favour to the actual branch direction taken by the helper thread. So, branch predictions will be more accuarate. This will inturn remove branch mispredictions which may occur when branch predictions are used.&lt;br /&gt;
&lt;br /&gt;
'''Prefetching of Data:''' &lt;br /&gt;
&lt;br /&gt;
Since helper threads run ahead of main thread, they can predict which data in memory is needed in&lt;br /&gt;
future by the main thread.they prefetch the data required by the main thread. The helper thread prefetches&lt;br /&gt;
the data and places it in the nearest cache accessible to the main thread. This avoids most of the L1 cache&lt;br /&gt;
misses that would have been encountered by the main thread had if helper thread was not present. As the &lt;br /&gt;
memory latency is reduced, the execution of main thread speeds up.&lt;br /&gt;
   &lt;br /&gt;
'''Memory Bug Reduction:'''&lt;br /&gt;
&lt;br /&gt;
Memory related bugs such as reads from unitialised memory, read or writes using dangling pointers or &lt;br /&gt;
memory leaks are difficult to detect by code inspection because they may invoive different code fragments &lt;br /&gt;
and exist in differnt modules or source code files. Compilers are of little help becuase it fails to &lt;br /&gt;
disambiguate pointers. Hence, in practice memory bug detection relies on run time checkers that insert&lt;br /&gt;
monitor code to the application during testing. In CMPs, the program which detects the memory bugs can run&lt;br /&gt;
as a helper thread.&lt;br /&gt;
&lt;br /&gt;
Ex: Heapmon, a memory bug checker monitors application heap space to detect heap memory bugs. The memory &lt;br /&gt;
access events in the application thread are automatically forwarded to helper thread using appropriate &lt;br /&gt;
hardware mechanisms. Also the redundant and unnecessary  memory accessess are filtered out. Hence the helper&lt;br /&gt;
thread approach completely decouples bug monitoring from appication execution and the filtering mechanism reduces&lt;br /&gt;
bug - check frequency. Conseqently, HeapMon achieves a very low performance overhead.&lt;br /&gt;
&lt;br /&gt;
'''Slipstream approach for helper threads:'''&lt;br /&gt;
&lt;br /&gt;
Slipstream approach is developed at North Carolina State University. &lt;br /&gt;
Slipstream execution provides a simple means to use a second processor in a CMP to accelerate a single program.Slipstream execution involves running two redundant copies of the program. A significant number of dynamic instructions are speculatively removed from one of the program copies, without sacrificing its ability to make correct forward progress. The second program verifies the forward progress of the first and is also sped up in the process.  &lt;br /&gt;
&lt;br /&gt;
The speculative reduced program is called A-stream (Advanced Stream) and runs ahead of the unreduced program (main thread or Redundant stream).The R-stream exploits the A-stream to get an accurate picture of the future. For example, the A-stream &lt;br /&gt;
provides very accurate branch and value predictions. The predictions are more accurate than predictions made by conventional history-based predictors because they are produced by future program computation. speculative A-stream occasionally (but&lt;br /&gt;
infrequently) goes astray. The R-stream serves as a checker of the speculative A-stream and redirects it when needed.&lt;br /&gt;
&lt;br /&gt;
Synchronization between an R-stream and its corresponding A-stream is required for two reasons.First, an A-stream that has taken a completely wrong control path and is generating useless data access predictions has to be corrected. Second, limit how far the A-stream gets ahead, so that its prefetches are not issued so early that the prefetched lines are often replaced or invalidated in the L2 cache before the R-stream uses them. A single semaphore is required between each A-stream/&lt;br /&gt;
R-stream pair to control their synchronization. It can be a shared hardware register, but any shared location that supports an atomic read-modify-write operation is sufficient. Using this semaphore, the following are controlled&amp;lt;br/&amp;gt;&lt;br /&gt;
(a) how many synchronization events the A-stream can skip without waiting for the R-stream&amp;lt;br/&amp;gt;&lt;br /&gt;
(b) whether the synchronization is local (involving only the companion R-stream) or global (involving all R-streams). The initial value of the semaphore indicates how many sessions the A-stream may proceed ahead of the Rstream. &amp;lt;br/&amp;gt;&lt;br /&gt;
This can be viewed as creating an initial pool of tokens that are consumed as the A-stream enters a new session. When there are no tokens, the A-stream may not proceed. The R-stream issues tokens by incrementing the semaphore counter.Once the A thread gets the semaphore, A threads advances and gets past the R thread.&lt;br /&gt;
&lt;br /&gt;
'''Disadvantages of helper threads:'''&lt;br /&gt;
&lt;br /&gt;
A very tight synchronisation is needed between the main thread and the helper threads in oder to keep them the proper distance ahead of main thread. If the helper threads are too far ahead, then they will cause cache thrashing by prefetching data and then replaing it with subsequent prefetches beofre the main thread can even use it. If they are not far enough ahead, they might not be able to prefetch cache lines in time. &lt;br /&gt;
&lt;br /&gt;
Only certain types of single threaded programs can be speeded up with these techniques. Most integer applications have regular data access patterns and hence there will be only few misses to eliminate. The applications with larger memory footprints are easily parellelisable and hence doesn't run on a single main thread. Most floating point applications the data access patterns are fairly regular and hence can be prefetched easily using hardware or software prefetch mechanisms. Hence the range of programs that can be accelerated using helper threads is fairly limited.&lt;br /&gt;
&lt;br /&gt;
'''References'''&lt;br /&gt;
&lt;br /&gt;
1)ChipMultiprocessor Architecture:Techniques to Improve Throughput and Latency by Kunle Olukotun, Lance Hammond, and James Laudon&lt;br /&gt;
&lt;br /&gt;
2)Slipstream Execution Mode for CMP-Based Multiprocessors by Khaled Z. Ibrahim, Gregory T. Byrd, and Eric Rotenberg&lt;br /&gt;
&lt;br /&gt;
3)http://www.research.ibm.com/journal/rd/502/shetty.html&lt;br /&gt;
&lt;br /&gt;
4)http://www.tinker.ncsu.edu/ericro/research/slipstream.htm&lt;br /&gt;
&lt;br /&gt;
5)A Survey of Helper Threads And Their Implementation by Ahren Studer&lt;br /&gt;
&lt;br /&gt;
6)Design and Implementation of a Compiler Framework for Helper Threading on Multicore Processors http://pact05.ce.ucsc.edu/datacentric.pdf&lt;/div&gt;</summary>
		<author><name>Lreddy</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki4_2_helperThreads&amp;diff=10474</id>
		<title>CSC/ECE 506 Fall 2007/wiki4 2 helperThreads</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki4_2_helperThreads&amp;diff=10474"/>
		<updated>2007-12-04T01:28:55Z</updated>

		<summary type="html">&lt;p&gt;Lreddy: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''''A helper thread is a thread that does some of the work of the main thread in advance of the main thread so that the main thread can work more quickly. The Olukotun text only scratches the surface on all the different ways that helper threads can be used. Survey these ways, making sure to include the Slipstream approach developed at NCSU.'''''&lt;br /&gt;
&lt;br /&gt;
'''What is a helper thread?'''&lt;br /&gt;
&lt;br /&gt;
It has been experienced that enhancing the speed of microprocessors is becoming an increasingly difficult &lt;br /&gt;
task. It is because of various reasons of which few are stated below:&lt;br /&gt;
&lt;br /&gt;
1) Typical instruction streams have only limited parallelism. So a superscalar pipeline which can issue more than four         instruction per cycle is of little benefit compared to the cost it incurs.&lt;br /&gt;
&lt;br /&gt;
2) As the depth of the pipeline increases, the cost of pipeline flushes during branch mispredictions becomes intolerable.&lt;br /&gt;
&lt;br /&gt;
3) As the speed and number of transistors on chip increase, the power required to drive complex logic circuits at high clock rate also increases beyond tolerable limit.&lt;br /&gt;
&lt;br /&gt;
So, processor manufacturers are switching to a new design paradigm: the chip microprocessors, which is also known as multicore microprocessors or manycore microprocessors. As the name implies, a chip multiprocessor is simply a group of uniprocessors integrated onto the same processor chip so that they may act as a team, filling the area that would have originally been filled with a single large processors with several smaller cores.&lt;br /&gt;
&lt;br /&gt;
The depth of the pipeline of the uniprocessor cores used will be just enough to exploit the limited instruction level parallelism present in programs inorder to keep power utilization low.So to better exploit the potential of chip multiprocessors (CMPs)the applications are divided into semi - independent parts, or threads that can operate simultaneously across the processors within a system. &lt;br /&gt;
&lt;br /&gt;
The simplest way to use parallel threads within a CMP to increase the performance of a single thread is to have helper threads. A 'helper' thread performs work on behalf of main thread in an effort to accelerate its performance. Helper threads run ahead of main thread because all the instructions that are not absolutely necessary for performing the function that the helper thread is meant for is removed from the program that the helper thread executes. Hence they can accuarately predict branches, start the long latency operations early, prefect the data needed by the main thread etc which are explained in detail below.&lt;br /&gt;
&lt;br /&gt;
The following figure shows the  main thread and helper thread in a two core chip multiprocessor.Main thread spawns the helper thread. Helper thread has the instructions that form a subset of the instructions in the main thread. As a result helper thread executes less instructions than the main thread and hence effectively executes ahead of main thread. As a result, it can start a long latency operations early and provide the result to the main thread by the time main thread starts executing that long latency operation.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:Helper threads.png]] &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Uses of helper threads'''&lt;br /&gt;
&lt;br /&gt;
'''Predicting branch at early stages:'''&lt;br /&gt;
&lt;br /&gt;
As mentioned earlier, helper threads are made up of program copies of the main thread stripped of all unessential parts which are not of absolute necessity for the helper thread to achieve it tasks. Hence helper threads runs ahead of main thread. Hence helper threads can do computations that are necessary to decide the direction of the branch. As the branch direction is decided using the result of actual computation and not just prediction, the branch predictor will be trained in favour to the actual branch direction taken by the helper thread. So, branch predictions will be more accuarate. This will inturn remove branch mispredictions which may occur when branch predictions are used.&lt;br /&gt;
&lt;br /&gt;
'''Prefetching of Data:''' &lt;br /&gt;
&lt;br /&gt;
Since helper threads run ahead of main thread, they can predict the which data in memory is needed in&lt;br /&gt;
future by the main thread.they prefetch the data required by the main thread. The helper thread prefetches&lt;br /&gt;
the data and places it in the nearest cache accessible to the main thread. This avoids most of the L1 cache&lt;br /&gt;
misses that would have been encountered by the main thread had if helper thread was not present. As the &lt;br /&gt;
memory latency is reduced, the execution of main thread speeds up.&lt;br /&gt;
   &lt;br /&gt;
'''Memory Bug Reduction:'''&lt;br /&gt;
&lt;br /&gt;
Memory related bugs such as reads from unitialised memory, read or writes using dangling pointers or &lt;br /&gt;
memory leaks are difficult to detect by code inspection because they may invoive different code fragments &lt;br /&gt;
and exist in differnt modules or source code files. Compilers are of little help becuase it fails to &lt;br /&gt;
disambiguate pointers. Hence, in practice memory bug detection relies on run time checkers that insert&lt;br /&gt;
monitor code to the application during testing. In CMPs, the program which detects the memory bugs can run&lt;br /&gt;
as a helper thread.&lt;br /&gt;
&lt;br /&gt;
Ex: Heapmon, a memory bug checker monitors application heap space to detect heap memory bugs. The memory &lt;br /&gt;
access events in the application thread are automatically forwarded to helper thread using appropriate &lt;br /&gt;
hardware mechanisms. Also the redundant and unnecessary  memory accessess are filtered out. Hence the helper&lt;br /&gt;
thread approach completely decouples bug monitoring from appication execution and the filtering mechanism reduces&lt;br /&gt;
bug - check frequency. Conseqently, HeapMon achieves a very low performance overhead.&lt;br /&gt;
&lt;br /&gt;
'''Slipstream approach for helper threads:'''&lt;br /&gt;
&lt;br /&gt;
Slipstream approach is developed at North Carolina State University. &lt;br /&gt;
Slipstream execution provides a simple means to use a second processor in a CMP to accelerate a single program.Slipstream execution involves running two redundant copies of the program. A significant number of dynamic instructions are speculatively removed from one of the program copies, without sacrificing its ability to make correct forward progress. The second program verifies the forward progress of the first and is also sped up in the process.  &lt;br /&gt;
&lt;br /&gt;
The speculative reduced program is called A-stream (Advanced Stream) and runs ahead of the unreduced program (main thread or Redundant stream).The R-stream exploits the A-stream to get an accurate picture of the future. For example, the A-stream &lt;br /&gt;
provides very accurate branch and value predictions. The predictions are more accurate than predictions made by conventional history-based predictors because they are produced by future program computation. speculative A-stream occasionally (but&lt;br /&gt;
infrequently) goes astray. The R-stream serves as a checker of the speculative A-stream and redirects it when needed.&lt;br /&gt;
&lt;br /&gt;
Synchronization between an R-stream and its corresponding A-stream is required for two reasons.First, an A-stream that has taken a completely wrong control path and is generating useless data access predictions has to be corrected. Second, limit how far the A-stream gets ahead, so that its prefetches are not issued so early that the prefetched lines are often replaced or invalidated in the L2 cache before the R-stream uses them. A single semaphore is required between each A-stream/&lt;br /&gt;
R-stream pair to control their synchronization. It can be a shared hardware register, but any shared location that supports an atomic read-modify-write operation is sufficient. Using this semaphore, the following are controlled&amp;lt;br/&amp;gt;&lt;br /&gt;
(a) how many synchronization events the A-stream can skip without waiting for the R-stream&amp;lt;br/&amp;gt;&lt;br /&gt;
(b) whether the synchronization is local (involving only the companion R-stream) or global (involving all R-streams). The initial value of the semaphore indicates how many sessions the A-stream may proceed ahead of the Rstream. &amp;lt;br/&amp;gt;&lt;br /&gt;
This can be viewed as creating an initial pool of tokens that are consumed as the A-stream enters a new session. When there are no tokens, the A-stream may not proceed. The R-stream issues tokens by incrementing the semaphore counter.Once the A thread gets the semaphore, A threads advances and gets past the R thread.&lt;br /&gt;
&lt;br /&gt;
'''Disadvantages of helper threads:'''&lt;br /&gt;
&lt;br /&gt;
A very tight synchronisation is needed between the main thread and the helper threads in oder to keep them the proper distance ahead of main thread. If the helper threads are too far ahead, then they will cause cache thrashing by prefetching data and then replaing it with subsequent prefetches beofre the main thread can even use it. If they are not far enough ahead, they might not be able to prefetch cache lines in time. &lt;br /&gt;
&lt;br /&gt;
Only certain types of single threaded programs can be speeded up with these techniques. Most integer applications have regular data access patterns and hence there will be only few misses to eliminate. The applications with larger memory footprints are easily parellelisable and hence doesn't run on a single main thread. Most floating point applications the data access patterns are fairly regular and hence can be prefetched easily using hardware or software prefetch mechanisms. Hence the range of programs that can be accelerated using helper threads is fairly limited.&lt;br /&gt;
&lt;br /&gt;
'''References'''&lt;br /&gt;
&lt;br /&gt;
1)ChipMultiprocessor Architecture:Techniques to Improve Throughput and Latency by Kunle Olukotun, Lance Hammond, and James Laudon&lt;br /&gt;
&lt;br /&gt;
2)Slipstream Execution Mode for CMP-Based Multiprocessors by Khaled Z. Ibrahim, Gregory T. Byrd, and Eric Rotenberg&lt;br /&gt;
&lt;br /&gt;
3)http://www.research.ibm.com/journal/rd/502/shetty.html&lt;br /&gt;
&lt;br /&gt;
4)http://www.tinker.ncsu.edu/ericro/research/slipstream.htm&lt;br /&gt;
&lt;br /&gt;
5)A Survey of Helper Threads And Their Implementation by Ahren Studer&lt;br /&gt;
&lt;br /&gt;
6)Design and Implementation of a Compiler Framework for Helper Threading on Multicore Processors http://pact05.ce.ucsc.edu/datacentric.pdf&lt;/div&gt;</summary>
		<author><name>Lreddy</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki4_2_helperThreads&amp;diff=10473</id>
		<title>CSC/ECE 506 Fall 2007/wiki4 2 helperThreads</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki4_2_helperThreads&amp;diff=10473"/>
		<updated>2007-12-04T01:27:50Z</updated>

		<summary type="html">&lt;p&gt;Lreddy: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''''A helper thread is a thread that does some of the work of the main thread in advance of the main thread so that the main thread can work more quickly. The Olukotun text only scratches the surface on all the different ways that helper threads can be used. Survey these ways, making sure to include the Slipstream approach developed at NCSU.'''''&lt;br /&gt;
&lt;br /&gt;
'''What is a helper thread?'''&lt;br /&gt;
&lt;br /&gt;
It has been experienced that enhancing the speed of microprocessors is becoming an increasingly difficult &lt;br /&gt;
task. It is because of various reasons of which few are stated below:&lt;br /&gt;
&lt;br /&gt;
1) Typical instruction streams have only limited parallelism. So a superscalar pipeline which can issue more than four         instruction per cycle is of little benefit compared to the cost it incurs.&lt;br /&gt;
&lt;br /&gt;
2) As the depth of the pipeline increases, the cost of pipeline flushes during branch mispredictions becomes intolerable.&lt;br /&gt;
&lt;br /&gt;
3) As the speed and number of transistors on chip increase, the power required to drive complex logic circuits at high clock rate also increases beyond tolerable limit.&lt;br /&gt;
&lt;br /&gt;
So, processor manufacturers are swicthing to a new design paradigm: the chip microprocessors, which is also known as multicore microprocessors or manycore microprocessors. As the name implies, a chip multiprocessor is simply a group of uniprocessors integrated onto the same processor chip so that they may act as a team, filling the area that would have originally been filled with a single large processors with several smaller cores.&lt;br /&gt;
&lt;br /&gt;
The depth of the pipeline of the uniprocessor cores used will be just enough to exploit the limited instruction level parallelism present in programs inorder to keep power utilization low.So to better exploit the potential of chip multiprocessors (CMPs)the applications are divided into semi - independent parts, or threads that can operate simultaneously across the processors within a system. &lt;br /&gt;
&lt;br /&gt;
The simplest way to use parallel threads within a CMP to increase the performance of a single thread is to have helper threads. A 'helper' thread performs work on behalf of main thread in an effort to accelerate its performance. Helper threads run ahead of main thread because all the instructions that are not absolutely necessary for performing the function that the helper thread is meant for is removed from the program that the helper thread executes. Hence they can accuarately predict branches, start the long latency operations early, prefect the data needed by the main thread etc which are explained in detail below.&lt;br /&gt;
&lt;br /&gt;
The following figure shows the  main thread and helper thread in a two core chip multiprocessor.Main thread spawns the helper thread. Helper thread has the instructions that form a subset of the instructions in the main thread. As a result helper thread executes less instructions than the main thread and hence effectively executes ahead of main thread. As a result, it can start a long latency operations early and provide the result to the main thread by the time main thread starts executing that long latency operation.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:Helper threads.png]] &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Uses of helper threads'''&lt;br /&gt;
&lt;br /&gt;
'''Predicting branch at early stages:'''&lt;br /&gt;
&lt;br /&gt;
As mentioned earlier, helper threads are made up of program copies of the main thread stripped of all unessential parts which are not of absolute necessity for the helper thread to achieve it tasks. Hence helper threads runs ahead of main thread. Hence helper threads can do computations that are necessary to decide the direction of the branch. As the branch direction is decided using the result of actual computation and not just prediction, the branch predictor will be trained in favour to the actual branch direction taken by the helper thread. So, branch predictions will be more accuarate. This will inturn remove branch mispredictions which may occur when branch predictions are used.&lt;br /&gt;
&lt;br /&gt;
'''Prefetching of Data:''' &lt;br /&gt;
&lt;br /&gt;
Since helper threads run ahead of main thread, they can predict the which data in memory is needed in&lt;br /&gt;
future by the main thread.they prefetch the data required by the main thread. The helper thread prefetches&lt;br /&gt;
the data and places it in the nearest cache accessible to the main thread. This avoids most of the L1 cache&lt;br /&gt;
misses that would have been encountered by the main thread had if helper thread was not present. As the &lt;br /&gt;
memory latency is reduced, the execution of main thread speeds up.&lt;br /&gt;
   &lt;br /&gt;
'''Memory Bug Reduction:'''&lt;br /&gt;
&lt;br /&gt;
Memory related bugs such as reads from unitialised memory, read or writes using dangling pointers or &lt;br /&gt;
memory leaks are difficult to detect by code inspection because they may invoive different code fragments &lt;br /&gt;
and exist in differnt modules or source code files. Compilers are of little help becuase it fails to &lt;br /&gt;
disambiguate pointers. Hence, in practice memory bug detection relies on run time checkers that insert&lt;br /&gt;
monitor code to the application during testing. In CMPs, the program which detects the memory bugs can run&lt;br /&gt;
as a helper thread.&lt;br /&gt;
&lt;br /&gt;
Ex: Heapmon, a memory bug checker monitors application heap space to detect heap memory bugs. The memory &lt;br /&gt;
access events in the application thread are automatically forwarded to helper thread using appropriate &lt;br /&gt;
hardware mechanisms. Also the redundant and unnecessary  memory accessess are filtered out. Hence the helper&lt;br /&gt;
thread approach completely decouples bug monitoring from appication execution and the filtering mechanism reduces&lt;br /&gt;
bug - check frequency. Conseqently, HeapMon achieves a very low performance overhead.&lt;br /&gt;
&lt;br /&gt;
'''Slipstream approach for helper threads:'''&lt;br /&gt;
&lt;br /&gt;
Slipstream approach is developed at North Carolina State University. &lt;br /&gt;
Slipstream execution provides a simple means to use a second processor in a CMP to accelerate a single program.Slipstream execution involves running two redundant copies of the program. A significant number of dynamic instructions are speculatively removed from one of the program copies, without sacrificing its ability to make correct forward progress. The second program verifies the forward progress of the first and is also sped up in the process.  &lt;br /&gt;
&lt;br /&gt;
The speculative reduced program is called A-stream (Advanced Stream) and runs ahead of the unreduced program (main thread or Redundant stream).The R-stream exploits the A-stream to get an accurate picture of the future. For example, the A-stream &lt;br /&gt;
provides very accurate branch and value predictions. The predictions are more accurate than predictions made by conventional history-based predictors because they are produced by future program computation. speculative A-stream occasionally (but&lt;br /&gt;
infrequently) goes astray. The R-stream serves as a checker of the speculative A-stream and redirects it when needed.&lt;br /&gt;
&lt;br /&gt;
Synchronization between an R-stream and its corresponding A-stream is required for two reasons.First, an A-stream that has taken a completely wrong control path and is generating useless data access predictions has to be corrected. Second, limit how far the A-stream gets ahead, so that its prefetches are not issued so early that the prefetched lines are often replaced or invalidated in the L2 cache before the R-stream uses them. A single semaphore is required between each A-stream/&lt;br /&gt;
R-stream pair to control their synchronization. It can be a shared hardware register, but any shared location that supports an atomic read-modify-write operation is sufficient. Using this semaphore, the following are controlled&amp;lt;br/&amp;gt;&lt;br /&gt;
(a) how many synchronization events the A-stream can skip without waiting for the R-stream&amp;lt;br/&amp;gt;&lt;br /&gt;
(b) whether the synchronization is local (involving only the companion R-stream) or global (involving all R-streams). The initial value of the semaphore indicates how many sessions the A-stream may proceed ahead of the Rstream. &amp;lt;br/&amp;gt;&lt;br /&gt;
This can be viewed as creating an initial pool of tokens that are consumed as the A-stream enters a new session. When there are no tokens, the A-stream may not proceed. The R-stream issues tokens by incrementing the semaphore counter.Once the A thread gets the semaphore, A threads advances and gets past the R thread.&lt;br /&gt;
&lt;br /&gt;
'''Disadvantages of helper threads:'''&lt;br /&gt;
&lt;br /&gt;
A very tight synchronisation is needed between the main thread and the helper threads in oder to keep them the proper distance ahead of main thread. If the helper threads are too far ahead, then they will cause cache thrashing by prefetching data and then replaing it with subsequent prefetches beofre the main thread can even use it. If they are not far enough ahead, they might not be able to prefetch cache lines in time. &lt;br /&gt;
&lt;br /&gt;
Only certain types of single threaded programs can be speeded up with these techniques. Most integer applications have regular data access patterns and hence there will be only few misses to eliminate. The applications with larger memory footprints are easily parellelisable and hence doesn't run on a single main thread. Most floating point applications the data access patterns are fairly regular and hence can be prefetched easily using hardware or software prefetch mechanisms. Hence the range of programs that can be accelerated using helper threads is fairly limited.&lt;br /&gt;
&lt;br /&gt;
'''References'''&lt;br /&gt;
&lt;br /&gt;
1)ChipMultiprocessor Architecture:Techniques to Improve Throughput and Latency by Kunle Olukotun, Lance Hammond, and James Laudon&lt;br /&gt;
&lt;br /&gt;
2)Slipstream Execution Mode for CMP-Based Multiprocessors by Khaled Z. Ibrahim, Gregory T. Byrd, and Eric Rotenberg&lt;br /&gt;
&lt;br /&gt;
3)http://www.research.ibm.com/journal/rd/502/shetty.html&lt;br /&gt;
&lt;br /&gt;
4)http://www.tinker.ncsu.edu/ericro/research/slipstream.htm&lt;br /&gt;
&lt;br /&gt;
5)A Survey of Helper Threads And Their Implementation by Ahren Studer&lt;br /&gt;
&lt;br /&gt;
6)Design and Implementation of a Compiler Framework for Helper Threading on Multicore Processors http://pact05.ce.ucsc.edu/datacentric.pdf&lt;/div&gt;</summary>
		<author><name>Lreddy</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki4_2_helperThreads&amp;diff=10472</id>
		<title>CSC/ECE 506 Fall 2007/wiki4 2 helperThreads</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki4_2_helperThreads&amp;diff=10472"/>
		<updated>2007-12-04T01:26:59Z</updated>

		<summary type="html">&lt;p&gt;Lreddy: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''''A helper thread is a thread that does some of the work of the main thread in advance of the main thread so that the main thread can work more quickly. The Olukotun text only scratches the surface on all the different ways that helper threads can be used. Survey these ways, making sure to include the Slipstream approach developed at NCSU.'''''&lt;br /&gt;
&lt;br /&gt;
'''What is a helper thread?'''&lt;br /&gt;
&lt;br /&gt;
It has been experienced that enhancing the speed of microprocessors is becoming an increasingly difficult &lt;br /&gt;
task. It is because of various reasons of which few are stated below:&lt;br /&gt;
&lt;br /&gt;
1) Typical instruction streams have only limited parallelism. So a superscalar pipeline which can issue more than four         instruction per cycle is of little benefit compared to the cost it incurs.&lt;br /&gt;
2) As the depth of the pipeline increases, the cost of pipeline flushes during branch mispredictions becomes intolerable.&lt;br /&gt;
3) As the speed and number of transistors on chip increase, the power required to drive complex logic circuits at high clock rate also increases beyond tolerable limit.&lt;br /&gt;
&lt;br /&gt;
So, processor manufacturers are swicthing to a new design paradigm: the chip microprocessors, which is also known as multicore microprocessors or manycore microprocessors. As the name implies, a chip multiprocessor is simply a group of uniprocessors integrated onto the same processor chip so that they may act as a team, filling the area that would have originally been filled with a single large processors with several smaller cores.&lt;br /&gt;
&lt;br /&gt;
The depth of the pipeline of the uniprocessor cores used will be just enough to exploit the limited instruction level parallelism present in programs inorder to keep power utilization low.So to better exploit the potential of chip multiprocessors (CMPs)the applications are divided into semi - independent parts, or threads that can operate simultaneously across the processors within a system. &lt;br /&gt;
&lt;br /&gt;
The simplest way to use parallel threads within a CMP to increase the performance of a single thread is to have helper threads. A 'helper' thread performs work on behalf of main thread in an effort to accelerate its performance. Helper threads run ahead of main thread because all the instructions that are not absolutely necessary for performing the function that the helper thread is meant for is removed from the program that the helper thread executes. Hence they can accuarately predict branches, start the long latency operations early, prefect the data needed by the main thread etc which are explained in detail below.&lt;br /&gt;
&lt;br /&gt;
The following figure shows the  main thread and helper thread in a two core chip multiprocessor.Main thread spawns the helper thread. Helper thread has the instructions that form a subset of the instructions in the main thread. As a result helper thread executes less instructions than the main thread and hence effectively executes ahead of main thread. As a result, it can start a long latency operations early and provide the result to the main thread by the time main thread starts executing that long latency operation.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:Helper threads.png]] &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Uses of helper threads'''&lt;br /&gt;
&lt;br /&gt;
'''Predicting branch at early stages:'''&lt;br /&gt;
&lt;br /&gt;
As mentioned earlier, helper threads are made up of program copies of the main thread stripped of all unessential parts which are not of absolute necessity for the helper thread to achieve it tasks. Hence helper threads runs ahead of main thread. Hence helper threads can do computations that are necessary to decide the direction of the branch. As the branch direction is decided using the result of actual computation and not just prediction, the branch predictor will be trained in favour to the actual branch direction taken by the helper thread. So, branch predictions will be more accuarate. This will inturn remove branch mispredictions which may occur when branch predictions are used.&lt;br /&gt;
&lt;br /&gt;
'''Prefetching of Data:''' &lt;br /&gt;
&lt;br /&gt;
Since helper threads run ahead of main thread, they can predict the which data in memory is needed in&lt;br /&gt;
future by the main thread.they prefetch the data required by the main thread. The helper thread prefetches&lt;br /&gt;
the data and places it in the nearest cache accessible to the main thread. This avoids most of the L1 cache&lt;br /&gt;
misses that would have been encountered by the main thread had if helper thread was not present. As the &lt;br /&gt;
memory latency is reduced, the execution of main thread speeds up.&lt;br /&gt;
   &lt;br /&gt;
'''Memory Bug Reduction:'''&lt;br /&gt;
&lt;br /&gt;
Memory related bugs such as reads from unitialised memory, read or writes using dangling pointers or &lt;br /&gt;
memory leaks are difficult to detect by code inspection because they may invoive different code fragments &lt;br /&gt;
and exist in differnt modules or source code files. Compilers are of little help becuase it fails to &lt;br /&gt;
disambiguate pointers. Hence, in practice memory bug detection relies on run time checkers that insert&lt;br /&gt;
monitor code to the application during testing. In CMPs, the program which detects the memory bugs can run&lt;br /&gt;
as a helper thread.&lt;br /&gt;
&lt;br /&gt;
Ex: Heapmon, a memory bug checker monitors application heap space to detect heap memory bugs. The memory &lt;br /&gt;
access events in the application thread are automatically forwarded to helper thread using appropriate &lt;br /&gt;
hardware mechanisms. Also the redundant and unnecessary  memory accessess are filtered out. Hence the helper&lt;br /&gt;
thread approach completely decouples bug monitoring from appication execution and the filtering mechanism reduces&lt;br /&gt;
bug - check frequency. Conseqently, HeapMon achieves a very low performance overhead.&lt;br /&gt;
&lt;br /&gt;
'''Slipstream approach for helper threads:'''&lt;br /&gt;
&lt;br /&gt;
Slipstream approach is developed at North Carolina State University. &lt;br /&gt;
Slipstream execution provides a simple means to use a second processor in a CMP to accelerate a single program.Slipstream execution involves running two redundant copies of the program. A significant number of dynamic instructions are speculatively removed from one of the program copies, without sacrificing its ability to make correct forward progress. The second program verifies the forward progress of the first and is also sped up in the process.  &lt;br /&gt;
&lt;br /&gt;
The speculative reduced program is called A-stream (Advanced Stream) and runs ahead of the unreduced program (main thread or Redundant stream).The R-stream exploits the A-stream to get an accurate picture of the future. For example, the A-stream &lt;br /&gt;
provides very accurate branch and value predictions. The predictions are more accurate than predictions made by conventional history-based predictors because they are produced by future program computation. speculative A-stream occasionally (but&lt;br /&gt;
infrequently) goes astray. The R-stream serves as a checker of the speculative A-stream and redirects it when needed.&lt;br /&gt;
&lt;br /&gt;
Synchronization between an R-stream and its corresponding A-stream is required for two reasons.First, an A-stream that has taken a completely wrong control path and is generating useless data access predictions has to be corrected. Second, limit how far the A-stream gets ahead, so that its prefetches are not issued so early that the prefetched lines are often replaced or invalidated in the L2 cache before the R-stream uses them. A single semaphore is required between each A-stream/&lt;br /&gt;
R-stream pair to control their synchronization. It can be a shared hardware register, but any shared location that supports an atomic read-modify-write operation is sufficient. Using this semaphore, the following are controlled&amp;lt;br/&amp;gt;&lt;br /&gt;
(a) how many synchronization events the A-stream can skip without waiting for the R-stream&amp;lt;br/&amp;gt;&lt;br /&gt;
(b) whether the synchronization is local (involving only the companion R-stream) or global (involving all R-streams). The initial value of the semaphore indicates how many sessions the A-stream may proceed ahead of the Rstream. &amp;lt;br/&amp;gt;&lt;br /&gt;
This can be viewed as creating an initial pool of tokens that are consumed as the A-stream enters a new session. When there are no tokens, the A-stream may not proceed. The R-stream issues tokens by incrementing the semaphore counter.Once the A thread gets the semaphore, A threads advances and gets past the R thread.&lt;br /&gt;
&lt;br /&gt;
'''Disadvantages of helper threads:'''&lt;br /&gt;
&lt;br /&gt;
A very tight synchronisation is needed between the main thread and the helper threads in oder to keep them the proper distance ahead of main thread. If the helper threads are too far ahead, then they will cause cache thrashing by prefetching data and then replaing it with subsequent prefetches beofre the main thread can even use it. If they are not far enough ahead, they might not be able to prefetch cache lines in time. &lt;br /&gt;
&lt;br /&gt;
Only certain types of single threaded programs can be speeded up with these techniques. Most integer applications have regular data access patterns and hence there will be only few misses to eliminate. The applications with larger memory footprints are easily parellelisable and hence doesn't run on a single main thread. Most floating point applications the data access patterns are fairly regular and hence can be prefetched easily using hardware or software prefetch mechanisms. Hence the range of programs that can be accelerated using helper threads is fairly limited.&lt;br /&gt;
&lt;br /&gt;
'''References'''&lt;br /&gt;
&lt;br /&gt;
1)ChipMultiprocessor Architecture:Techniques to Improve Throughput and Latency by Kunle Olukotun, Lance Hammond, and James Laudon&lt;br /&gt;
&lt;br /&gt;
2)Slipstream Execution Mode for CMP-Based Multiprocessors by Khaled Z. Ibrahim, Gregory T. Byrd, and Eric Rotenberg&lt;br /&gt;
&lt;br /&gt;
3)http://www.research.ibm.com/journal/rd/502/shetty.html&lt;br /&gt;
&lt;br /&gt;
4)http://www.tinker.ncsu.edu/ericro/research/slipstream.htm&lt;br /&gt;
&lt;br /&gt;
5)A Survey of Helper Threads And Their Implementation by Ahren Studer&lt;br /&gt;
&lt;br /&gt;
6)Design and Implementation of a Compiler Framework for Helper Threading on Multicore Processors http://pact05.ce.ucsc.edu/datacentric.pdf&lt;/div&gt;</summary>
		<author><name>Lreddy</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki4_2_helperThreads&amp;diff=10454</id>
		<title>CSC/ECE 506 Fall 2007/wiki4 2 helperThreads</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki4_2_helperThreads&amp;diff=10454"/>
		<updated>2007-12-03T23:59:36Z</updated>

		<summary type="html">&lt;p&gt;Lreddy: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''''A helper thread is a thread that does some of the work of the main thread in advance of the main thread so that the main thread can work more quickly. The Olukotun text only scratches the surface on all the different ways that helper threads can be used. Survey these ways, making sure to include the Slipstream approach developed at NCSU.'''''&lt;br /&gt;
&lt;br /&gt;
'''What is a helper thread?'''&lt;br /&gt;
&lt;br /&gt;
The potential of chip multiprocessors (CMPs) can be exploited in a better way if the applications are&lt;br /&gt;
divided into semi - independent parts, or threads that can operate simultaneously across the processors &lt;br /&gt;
within a system. The simplest way to use parallel threads within a CMP to increase the performance of a &lt;br /&gt;
single thread is to have helper threads. A 'helper' thread performs work on behalf of main thread in an &lt;br /&gt;
effort to accelerate its performance.&lt;br /&gt;
&lt;br /&gt;
[[Image:Helper threads.png]] &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Uses of helper threads'''&lt;br /&gt;
&lt;br /&gt;
'''Predicting branch at early stages:'''&lt;br /&gt;
&lt;br /&gt;
Helper threads are made up of program copies of the main thread stripped of all unessential parts &lt;br /&gt;
which are not of absolute necessity for the helper thread to achieve it tasks. Hence helper threads runs &lt;br /&gt;
ahead of main thread. Hence helper threads run ahead of main thread. Hence helper threads can do &lt;br /&gt;
computations that are necessary to decide the direction of the branch. This will inturn remove branch &lt;br /&gt;
mispredictions which may occur when branch predictions are used.&lt;br /&gt;
&lt;br /&gt;
'''Prefetching of Data:''' &lt;br /&gt;
&lt;br /&gt;
Since helper threads run ahead of main thread, they can predict the which data in memory is needed in&lt;br /&gt;
future by the main thread.they prefetch the data required by the main thread. The helper thread prefetches&lt;br /&gt;
the data and places it in the nearest cache accessible to the main thread. This avoids most of the L1 cache&lt;br /&gt;
misses that would have been encountered by the main thread had if helper thread was not present. As the &lt;br /&gt;
memory latency is reduced, the execution of main thread speeds up.&lt;br /&gt;
   &lt;br /&gt;
'''Memory Bug Reduction:'''&lt;br /&gt;
&lt;br /&gt;
Memory related bugs such as reads from unitialised memory, read or writes using dangling pointers or &lt;br /&gt;
memory leaks are difficult to detect by code inspection because they may invoive different code fragments &lt;br /&gt;
and exist in differnt modules or source code files. Compilers are of little help becuase it fails to &lt;br /&gt;
disambiguate pointers. Hence, in practice memory bug detection relies on run time checkers that insert&lt;br /&gt;
monitor code to the application during testing. In CMPs, the program which detects the memory bugs can run&lt;br /&gt;
as a helper thread.&lt;br /&gt;
&lt;br /&gt;
Ex: Heapmon, a memory bug checker monitors application heap space to detect heap memory bugs. The memory &lt;br /&gt;
access events in the application thread are automatically forwarded to helper thread using appropriate &lt;br /&gt;
hardware mechanisms. Also the redundant and unnecessary  memory accessess are filtered out. Hence the helper&lt;br /&gt;
thread approach completely decouples bug monitoring from appication execution and the filtering mechanism reduces&lt;br /&gt;
bug - check frequency. Conseqently, HeapMon achieves a very low performance overhead.&lt;br /&gt;
&lt;br /&gt;
'''Slipstream approach for helper threads:'''&lt;br /&gt;
&lt;br /&gt;
Slipstream approach is developed at North Carolina State University. &lt;br /&gt;
Slipstream execution provides a simple means to use a second processor in a CMP to accelerate a single program.Slipstream execution involves running two redundant copies of the program. A significant number of dynamic instructions are speculatively removed from one of the program copies, without sacrificing its ability to make correct forward progress. The second program verifies the forward progress of the first and is also sped up in the process.  &lt;br /&gt;
&lt;br /&gt;
The speculative reduced program is called A-stream (Advanced Stream) and runs ahead of the unreduced program (main thread or Redundant stream).The R-stream exploits the A-stream to get an accurate picture of the future. For example, the A-stream &lt;br /&gt;
provides very accurate branch and value predictions. The predictions are more accurate than predictions made by conventional history-based predictors because they are produced by future program computation. The speculative A-stream occasionally (but&lt;br /&gt;
infrequently) goes astray. The R-stream serves as a checker of the speculative A-stream and redirects it when needed.&lt;br /&gt;
&lt;br /&gt;
Synchronization between an R-stream and its corresponding A-stream is required for two reasons.First, an A-stream that has taken a completely wrong control path and is generating useless data access predictions has to be corrcted. Second, limit how far the A-stream gets ahead, so that its prefetches are not issued so early that the prefetched lines are often replaced or invalidated in the L2 cache before the R-stream uses them. A single semaphore is required between each Astream/&lt;br /&gt;
R-stream pair to control their synchronization. It can be a shared hardware register, but any shared location that supports an atomic read-modify-write operation is sufficient. Using this semaphore, the following are controlled&amp;lt;br/&amp;gt;&lt;br /&gt;
(a) how many synchronization events the A-stream can skip without waiting for the Rstream&amp;lt;br/&amp;gt;&lt;br /&gt;
(b) whether the synchronization is local (involving only the companion R-stream) or global (involving all R-streams). The initial value of the semaphore indicates how many sessions the A-stream may proceed ahead of the Rstream. &amp;lt;br/&amp;gt;&lt;br /&gt;
This can be viewed as creating an initial pool of tokens that are consumed as the A-stream enters a new session. When there are no tokens, the Astream may not proceed. The R-stream issues tokens by incrementing the semaphore counter.Once the A thread gets the semaphore, A threads advances and gets past the R thread.&lt;br /&gt;
&lt;br /&gt;
'''Disadvantages of helper threads:'''&lt;br /&gt;
&lt;br /&gt;
A very tight synchronisation is needed between the main thread and the helper threads in oder to keep them the proper distance ahead of main thread. If the helper threads are too far ahead, then they will cause cache thrashing by prefetching data and then replaing it with subsequent prefetches beofre the main thread can even use it. If they are not far enough ahead, they might not be able to prefetch cache lines in time. &lt;br /&gt;
&lt;br /&gt;
Only certain types of single threaded programs can be sped up with these techniques. Most integer applications have regular data access patterns and hence there will be only few misses to eliminate. The applications with larger memory footprints are easily parellelisable and hence doesn't run on a single main thread. Most  floating point applications the data access patterns are fairly regular and hence can be prefetched easily using hardware or software prefetch mechanisms. Hence the range of programs that can be accelerated using helper threads is fairly limited.&lt;br /&gt;
&lt;br /&gt;
'''References'''&lt;br /&gt;
&lt;br /&gt;
1)ChipMultiprocessor Architecture:Techniques to Improve Throughput and Latency by Kunle Olukotun, Lance Hammond, and James Laudon&lt;br /&gt;
&lt;br /&gt;
2)Slipstream Execution Mode for CMP-Based Multiprocessors by Khaled Z. Ibrahim, Gregory T. Byrd, and Eric Rotenberg&lt;br /&gt;
&lt;br /&gt;
3)http://www.research.ibm.com/journal/rd/502/shetty.html&lt;br /&gt;
&lt;br /&gt;
4)http://www.tinker.ncsu.edu/ericro/research/slipstream.htm&lt;/div&gt;</summary>
		<author><name>Lreddy</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki4_2_helperThreads&amp;diff=10262</id>
		<title>CSC/ECE 506 Fall 2007/wiki4 2 helperThreads</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki4_2_helperThreads&amp;diff=10262"/>
		<updated>2007-11-29T00:39:04Z</updated>

		<summary type="html">&lt;p&gt;Lreddy: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''''A helper thread is a thread that does some of the work of the main thread in advance of the main thread so that the main thread can work more quickly. The Olukotun text only scratches the surface on all the different ways that helper threads can be used. Survey these ways, making sure to include the Slipstream approach developed at NCSU.'''''&lt;br /&gt;
&lt;br /&gt;
'''What is a helper thread?'''&lt;br /&gt;
&lt;br /&gt;
The potential of chip multiprocessors (CMPs) can be exploited in a better way if the applications are&lt;br /&gt;
divided into semi - independent parts, or threads that can operate simultaneously across the processors &lt;br /&gt;
within a system. The simplest way to use parallel threads within a CMP to increase the performance of a &lt;br /&gt;
single thread is to have helper threads. A 'helper' thread performs work on behalf of main thread in an &lt;br /&gt;
effort to accelerate its performance.&lt;br /&gt;
&lt;br /&gt;
'''Uses of helper threads'''&lt;br /&gt;
&lt;br /&gt;
'''Predicting branch at early stages:'''&lt;br /&gt;
&lt;br /&gt;
Helper threads are made up of program copies of the main thread stripped of all unessential parts &lt;br /&gt;
which are not of absolute necessity for the helper thread to achieve it tasks. Hence helper threads runs &lt;br /&gt;
ahead of main thread. Hence helper threads run ahead of main thread. Hence helper threads can do &lt;br /&gt;
computations that are necessary to decide the direction of the branch. This will inturn remove branch &lt;br /&gt;
mispredictions which may occur when branch predictions are used.&lt;br /&gt;
&lt;br /&gt;
'''Prefetching of Data:''' &lt;br /&gt;
&lt;br /&gt;
Since helper threads run ahead of main thread, they can predict the which data in memory is needed in&lt;br /&gt;
future by the main thread.they prefetch the data required by the main thread. The helper thread prefetches&lt;br /&gt;
the data and places it in the nearest cache accessible to the main thread. This avoids most of the L1 cache&lt;br /&gt;
misses that would have been encountered by the main thread had if helper thread was not present. As the &lt;br /&gt;
memory latency is reduced, the execution of main thread speeds up.&lt;br /&gt;
   &lt;br /&gt;
'''Memory Bug Reduction:'''&lt;br /&gt;
&lt;br /&gt;
Memory related bugs such as reads from unitialised memory, read or writes using dangling pointers or &lt;br /&gt;
memory leaks are difficult to detect by code inspection because they may invoive different code fragments &lt;br /&gt;
and exist in differnt modules or source code files. Compilers are of little help becuase it fails to &lt;br /&gt;
disambiguate pointers. Hence, in practice memory bug detection relies on run time checkers that insert&lt;br /&gt;
monitor code to the application during testing. In CMPs, the program which detects the memory bugs can run&lt;br /&gt;
as a helper thread.&lt;br /&gt;
&lt;br /&gt;
Ex: Heapmon, a memory bug checker monitors application heap space to detect heap memory bugs. The memory &lt;br /&gt;
access events in the application thread are automatically forwarded to helper thread using appropriate &lt;br /&gt;
hardware mechanisms. Also the redundant and unnecessary  memory accessess are filtered out. Hence the helper&lt;br /&gt;
thread approach completely decouples bug monitoring from appication execution and the filtering mechanism reduces&lt;br /&gt;
bug - check frequency. Conseqently, HeapMon achieves a very low performance overhead.&lt;br /&gt;
&lt;br /&gt;
'''Slipstream approach for helper threads:'''&lt;br /&gt;
&lt;br /&gt;
Slipstream approach is developed at North Carolina State University. &lt;br /&gt;
Slipstream execution provides a simple means to use a second processor in a CMP to accelerate a single program.Slipstream execution involves running two redundant copies of the program. A significant number of dynamic instructions are speculatively removed from one of the program copies, without sacrificing its ability to make correct forward progress. The second program verifies the forward progress of the first and is also sped up in the process.  &lt;br /&gt;
&lt;br /&gt;
The speculative reduced program is called A-stream (Advanced Stream) and runs ahead of the unreduced program (main thread or Redundant stream).The R-stream exploits the A-stream to get an accurate picture of the future. For example, the A-stream &lt;br /&gt;
provides very accurate branch and value predictions. The predictions are more accurate than predictions made by conventional history-based predictors because they are produced by future program computation. The speculative A-stream occasionally (but&lt;br /&gt;
infrequently) goes astray. The R-stream serves as a checker of the speculative A-stream and redirects it when needed.&lt;br /&gt;
&lt;br /&gt;
Synchronization between an R-stream and its corresponding A-stream is required for two reasons.First, an A-stream that has taken a completely wrong control path and is generating useless data access predictions has to be corrcted. Second, limit how far the A-stream gets ahead, so that its prefetches are not issued so early that the prefetched lines are often replaced or invalidated in the L2 cache before the R-stream uses them. A single semaphore is required between each Astream/&lt;br /&gt;
R-stream pair to control their synchronization. It can be a shared hardware register, but any shared location that supports an atomic read-modify-write operation is sufficient. Using this semaphore, the following are controlled&amp;lt;br/&amp;gt;&lt;br /&gt;
(a) how many synchronization events the A-stream can skip without waiting for the Rstream&amp;lt;br/&amp;gt;&lt;br /&gt;
(b) whether the synchronization is local (involving only the companion R-stream) or global (involving all R-streams). The initial value of the semaphore indicates how many sessions the A-stream may proceed ahead of the Rstream. &amp;lt;br/&amp;gt;&lt;br /&gt;
This can be viewed as creating an initial pool of tokens that are consumed as the A-stream enters a new session. When there are no tokens, the Astream may not proceed. The R-stream issues tokens by incrementing the semaphore counter.Once the A thread gets the semaphore, A threads advances and gets past the R thread.&lt;br /&gt;
&lt;br /&gt;
'''Disadvantages of helper threads:'''&lt;br /&gt;
&lt;br /&gt;
A very tight synchronisation is needed between the main thread and the helper threads in oder to keep them the proper distance ahead of main thread. If the helper threads are too far ahead, then they will cause cache thrashing by prefetching data and then replaing it with subsequent prefetches beofre the main thread can even use it. If they are not far enough ahead, they might not be able to prefetch cache lines in time. &lt;br /&gt;
&lt;br /&gt;
Only certain types of single threaded programs can be sped up with these techniques. Most integer applications have regular data access patterns and hence there will be only few misses to eliminate. The applications with larger memory footprints are easily parellelisable and hence doesn't run on a single main thread. Most  floating point applications the data access patterns are fairly regular and hence can be prefetched easily using hardware or software prefetch mechanisms. Hence the range of programs that can be accelerated using helper threads is fairly limited.&lt;br /&gt;
&lt;br /&gt;
'''References'''&lt;br /&gt;
&lt;br /&gt;
1)ChipMultiprocessor Architecture:Techniques to Improve Throughput and Latency by Kunle Olukotun, Lance Hammond, and James Laudon&lt;br /&gt;
&lt;br /&gt;
2)Slipstream Execution Mode for CMP-Based Multiprocessors by Khaled Z. Ibrahim, Gregory T. Byrd, and Eric Rotenberg&lt;br /&gt;
&lt;br /&gt;
3)http://www.research.ibm.com/journal/rd/502/shetty.html&lt;br /&gt;
&lt;br /&gt;
4)http://www.tinker.ncsu.edu/ericro/research/slipstream.htm&lt;/div&gt;</summary>
		<author><name>Lreddy</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki2_4_helperThreads&amp;diff=10261</id>
		<title>CSC/ECE 506 Fall 2007/wiki2 4 helperThreads</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki2_4_helperThreads&amp;diff=10261"/>
		<updated>2007-11-29T00:37:14Z</updated>

		<summary type="html">&lt;p&gt;Lreddy: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''''A helper thread is a thread that does some of the work of the main thread in advance of the main thread so that the main thread can work more quickly. The Olukotun text only scratches the surface on all the different ways that helper threads can be used. Survey these ways, making sure to include the Slipstream approach developed at NCSU.'''''&lt;br /&gt;
&lt;br /&gt;
'''What is a helper thread?'''&lt;br /&gt;
&lt;br /&gt;
The potential of chip multiprocessors (CMPs) can be exploited in a better way if the applications are&lt;br /&gt;
divided into semi - independent parts, or threads that can operate simultaneously across the processors &lt;br /&gt;
within a system. The simplest way to use parallel threads within a CMP to increase the performance of a &lt;br /&gt;
single thread is to have helper threads. A 'helper' thread performs work on behalf of main thread in an &lt;br /&gt;
effort to accelerate its performance.&lt;br /&gt;
&lt;br /&gt;
'''Uses of helper threads'''&lt;br /&gt;
&lt;br /&gt;
'''Predicting branch at early stages:'''&lt;br /&gt;
&lt;br /&gt;
Helper threads are made up of program copies of the main thread stripped of all unessential parts &lt;br /&gt;
which are not of absolute necessity for the helper thread to achieve it tasks. Hence helper threads runs &lt;br /&gt;
ahead of main thread. Hence helper threads run ahead of main thread. Hence helper threads can do &lt;br /&gt;
computations that are necessary to decide the direction of the branch. This will inturn remove branch &lt;br /&gt;
mispredictions which may occur when branch predictions are used.&lt;br /&gt;
&lt;br /&gt;
'''Prefetching of Data:''' &lt;br /&gt;
&lt;br /&gt;
Since helper threads run ahead of main thread, they can predict the which data in memory is needed in&lt;br /&gt;
future by the main thread.they prefetch the data required by the main thread. The helper thread prefetches&lt;br /&gt;
the data and places it in the nearest cache accessible to the main thread. This avoids most of the L1 cache&lt;br /&gt;
misses that would have been encountered by the main thread had if helper thread was not present. As the &lt;br /&gt;
memory latency is reduced, the execution of main thread speeds up.&lt;br /&gt;
   &lt;br /&gt;
'''Memory Bug Reduction:'''&lt;br /&gt;
&lt;br /&gt;
Memory related bugs such as reads from unitialised memory, read or writes using dangling pointers or &lt;br /&gt;
memory leaks are difficult to detect by code inspection because they may invoive different code fragments &lt;br /&gt;
and exist in differnt modules or source code files. Compilers are of little help becuase it fails to &lt;br /&gt;
disambiguate pointers. Hence, in practice memory bug detection relies on run time checkers that insert&lt;br /&gt;
monitor code to the application during testing. In CMPs, the program which detects the memory bugs can run&lt;br /&gt;
as a helper thread.&lt;br /&gt;
&lt;br /&gt;
Ex: Heapmon, a memory bug checker monitors application heap space to detect heap memory bugs. The memory &lt;br /&gt;
access events in the application thread are automatically forwarded to helper thread using appropriate &lt;br /&gt;
hardware mechanisms. Also the redundant and unnecessary  memory accessess are filtered out. Hence the helper&lt;br /&gt;
thread approach completely decouples bug monitoring from appication execution and the filtering mechanism reduces&lt;br /&gt;
bug - check frequency. Conseqently, HeapMon achieves a very low performance overhead.&lt;br /&gt;
&lt;br /&gt;
'''Slipstream approach for helper threads:'''&lt;br /&gt;
&lt;br /&gt;
Slipstream approach is developed at North Carolina State University. &lt;br /&gt;
Slipstream execution provides a simple means to use a second processor in a CMP to accelerate a single program.Slipstream execution involves running two redundant copies of the program. A significant number of dynamic instructions are speculatively removed from one of the program copies, without sacrificing its ability to make correct forward progress. The second program verifies the forward progress of the first and is also sped up in the process.  &lt;br /&gt;
&lt;br /&gt;
The speculative reduced program is called A-stream (Advanced Stream) and runs ahead of the unreduced program (main thread or Redundant stream).The R-stream exploits the A-stream to get an accurate picture of the future. For example, the A-stream &lt;br /&gt;
provides very accurate branch and value predictions. The predictions are more accurate than predictions made by conventional history-based predictors because they are produced by future program computation. The speculative A-stream occasionally (but&lt;br /&gt;
infrequently) goes astray. The R-stream serves as a checker of the speculative A-stream and redirects it when needed.&lt;br /&gt;
&lt;br /&gt;
Synchronization between an R-stream and its corresponding A-stream is required for two reasons.First, an A-stream that has taken a completely wrong control path and is generating useless data access predictions has to be corrcted. Second, limit how far the A-stream gets ahead, so that its prefetches are not issued so early that the prefetched lines are often replaced or invalidated in the L2 cache before the R-stream uses them. A single semaphore is required between each Astream/&lt;br /&gt;
R-stream pair to control their synchronization. It can be a shared hardware register, but any shared location that supports an atomic read-modify-write operation is sufficient. Using this semaphore, the following are controlled&amp;lt;br/&amp;gt;&lt;br /&gt;
(a) how many synchronization events the A-stream can skip without waiting for the Rstream&amp;lt;br/&amp;gt;&lt;br /&gt;
(b) whether the synchronization is local (involving only the companion R-stream) or global (involving all R-streams). The initial value of the semaphore indicates how many sessions the A-stream may proceed ahead of the Rstream. &amp;lt;br/&amp;gt;&lt;br /&gt;
This can be viewed as creating an initial pool of tokens that are consumed as the A-stream enters a new session. When there are no tokens, the Astream may not proceed. The R-stream issues tokens by incrementing the semaphore counter.Once the A thread gets the semaphore, A threads advances and gets past the R thread.&lt;br /&gt;
&lt;br /&gt;
'''Disadvantages of helper threads:'''&lt;br /&gt;
&lt;br /&gt;
A very tight synchronisation is needed between the main thread and the helper threads in oder to keep them the proper distance ahead of main thread. If the helper threads are too far ahead, then they will cause cache thrashing by prefetching data and then replaing it with subsequent prefetches beofre the main thread can even use it. If they are not far enough ahead, they might not be able to prefetch cache lines in time. &lt;br /&gt;
&lt;br /&gt;
Only certain types of single threaded programs can be sped up with these techniques. Most integer applications have regular data access patterns and hence there will be only few misses to eliminate. The applications with larger memory footprints are easily parellelisable and hence doesn't run on a single main thread. Most  floating point applications the data access patterns are fairly regular and hence can be prefetched easily using hardware or software prefetch mechanisms. Hence the range of programs that can be accelerated using helper threads is fairly limited.&lt;br /&gt;
&lt;br /&gt;
'''References'''&lt;br /&gt;
&lt;br /&gt;
1)ChipMultiprocessor Architecture:Techniques to Improve Throughput and Latency by Kunle Olukotun, Lance Hammond, and James Laudon&lt;br /&gt;
&lt;br /&gt;
2)Slipstream Execution Mode for CMP-Based Multiprocessors by Khaled Z. Ibrahim, Gregory T. Byrd, and Eric Rotenberg&lt;br /&gt;
&lt;br /&gt;
3)http://www.research.ibm.com/journal/rd/502/shetty.html&lt;br /&gt;
&lt;br /&gt;
4)http://www.tinker.ncsu.edu/ericro/research/slipstream.htm&lt;/div&gt;</summary>
		<author><name>Lreddy</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki2_2_helperThreads&amp;diff=10260</id>
		<title>CSC/ECE 506 Fall 2007/wiki2 2 helperThreads</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki2_2_helperThreads&amp;diff=10260"/>
		<updated>2007-11-29T00:35:58Z</updated>

		<summary type="html">&lt;p&gt;Lreddy: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''''A helper thread is a thread that does some of the work of the main thread in advance of the main thread so that the main thread can work more quickly. The Olukotun text only scratches the surface on all the different ways that helper threads can be used. Survey these ways, making sure to include the Slipstream approach developed at NCSU.'''''&lt;br /&gt;
&lt;br /&gt;
'''What is a helper thread?'''&lt;br /&gt;
&lt;br /&gt;
The potential of chip multiprocessors (CMPs) can be exploited in a better way if the applications are&lt;br /&gt;
divided into semi - independent parts, or threads that can operate simultaneously across the processors &lt;br /&gt;
within a system. The simplest way to use parallel threads within a CMP to increase the performance of a &lt;br /&gt;
single thread is to have helper threads. A 'helper' thread performs work on behalf of main thread in an &lt;br /&gt;
effort to accelerate its performance.&lt;br /&gt;
&lt;br /&gt;
'''Uses of helper threads'''&lt;br /&gt;
&lt;br /&gt;
'''Predicting branch at early stages:'''&lt;br /&gt;
&lt;br /&gt;
Helper threads are made up of program copies of the main thread stripped of all unessential parts &lt;br /&gt;
which are not of absolute necessity for the helper thread to achieve it tasks. Hence helper threads runs &lt;br /&gt;
ahead of main thread. Hence helper threads run ahead of main thread. Hence helper threads can do &lt;br /&gt;
computations that are necessary to decide the direction of the branch. This will inturn remove branch &lt;br /&gt;
mispredictions which may occur when branch predictions are used.&lt;br /&gt;
&lt;br /&gt;
'''Prefetching of Data:''' &lt;br /&gt;
&lt;br /&gt;
Since helper threads run ahead of main thread, they can predict the which data in memory is needed in&lt;br /&gt;
future by the main thread.they prefetch the data required by the main thread. The helper thread prefetches&lt;br /&gt;
the data and places it in the nearest cache accessible to the main thread. This avoids most of the L1 cache&lt;br /&gt;
misses that would have been encountered by the main thread had if helper thread was not present. As the &lt;br /&gt;
memory latency is reduced, the execution of main thread speeds up.&lt;br /&gt;
   &lt;br /&gt;
'''Memory Bug Reduction:'''&lt;br /&gt;
&lt;br /&gt;
Memory related bugs such as reads from unitialised memory, read or writes using dangling pointers or &lt;br /&gt;
memory leaks are difficult to detect by code inspection because they may invoive different code fragments &lt;br /&gt;
and exist in differnt modules or source code files. Compilers are of little help becuase it fails to &lt;br /&gt;
disambiguate pointers. Hence, in practice memory bug detection relies on run time checkers that insert&lt;br /&gt;
monitor code to the application during testing. In CMPs, the program which detects the memory bugs can run&lt;br /&gt;
as a helper thread.&lt;br /&gt;
&lt;br /&gt;
Ex: Heapmon, a memory bug checker monitors application heap space to detect heap memory bugs. The memory &lt;br /&gt;
access events in the application thread are automatically forwarded to helper thread using appropriate &lt;br /&gt;
hardware mechanisms. Also the redundant and unnecessary  memory accessess are filtered out. Hence the helper&lt;br /&gt;
thread approach completely decouples bug monitoring from appication execution and the filtering mechanism reduces&lt;br /&gt;
bug - check frequency. Conseqently, HeapMon achieves a very low performance overhead.&lt;br /&gt;
&lt;br /&gt;
'''Slipstream approach for helper threads:'''&lt;br /&gt;
&lt;br /&gt;
Slipstream approach is developed at North Carolina State University. &lt;br /&gt;
Slipstream execution provides a simple means to use a second processor in a CMP to accelerate a single program.Slipstream execution involves running two redundant copies of the program. A significant number of dynamic instructions are speculatively removed from one of the program copies, without sacrificing its ability to make correct forward progress. The second program verifies the forward progress of the first and is also sped up in the process.  &lt;br /&gt;
&lt;br /&gt;
The speculative reduced program is called A-stream (Advanced Stream) and runs ahead of the unreduced program (main thread or Redundant stream).The R-stream exploits the A-stream to get an accurate picture of the future. For example, the A-stream &lt;br /&gt;
provides very accurate branch and value predictions. The predictions are more accurate than predictions made by conventional history-based predictors because they are produced by future program computation. The speculative A-stream occasionally (but&lt;br /&gt;
infrequently) goes astray. The R-stream serves as a checker of the speculative A-stream and redirects it when needed.&lt;br /&gt;
&lt;br /&gt;
Synchronization between an R-stream and its corresponding A-stream is required for two reasons.First, an A-stream that has taken a completely wrong control path and is generating useless data access predictions has to be corrcted. Second, limit how far the A-stream gets ahead, so that its prefetches are not issued so early that the prefetched lines are often replaced or invalidated in the L2 cache before the R-stream uses them. A single semaphore is required between each Astream/&lt;br /&gt;
R-stream pair to control their synchronization. It can be a shared hardware register, but any shared location that supports an atomic read-modify-write operation is sufficient. Using this semaphore, the following are controlled&amp;lt;br/&amp;gt;&lt;br /&gt;
(a) how many synchronization events the A-stream can skip without waiting for the Rstream&amp;lt;br/&amp;gt;&lt;br /&gt;
(b) whether the synchronization is local (involving only the companion R-stream) or global (involving all R-streams). The initial value of the semaphore indicates how many sessions the A-stream may proceed ahead of the Rstream. &amp;lt;br/&amp;gt;&lt;br /&gt;
This can be viewed as creating an initial pool of tokens that are consumed as the A-stream enters a new session. When there are no tokens, the Astream may not proceed. The R-stream issues tokens by incrementing the semaphore counter.Once the A thread gets the semaphore, A threads advances and gets past the R thread.&lt;br /&gt;
&lt;br /&gt;
'''Disadvantages of helper threads:'''&lt;br /&gt;
&lt;br /&gt;
A very tight synchronisation is needed between the main thread and the helper threads in oder to keep them the proper distance ahead of main thread. If the helper threads are too far ahead, then they will cause cache thrashing by prefetching data and then replaing it with subsequent prefetches beofre the main thread can even use it. If they are not far enough ahead, they might not be able to prefetch cache lines in time. &lt;br /&gt;
&lt;br /&gt;
Only certain types of single threaded programs can be sped up with these techniques. Most integer applications have regular data access patterns and hence there will be only few misses to eliminate. The applications with larger memory footprints are easily parellelisable and hence doesn't run on a single main thread. Most  floating point applications the data access patterns are fairly regular and hence can be prefetched easily using hardware or software prefetch mechanisms. Hence the range of programs that can be accelerated using helper threads is fairly limited.&lt;br /&gt;
&lt;br /&gt;
'''References'''&lt;br /&gt;
&lt;br /&gt;
1)ChipMultiprocessor Architecture:Techniques to Improve Throughput and Latency by Kunle Olukotun, Lance Hammond, and James Laudon&lt;br /&gt;
&lt;br /&gt;
2)Slipstream Execution Mode for CMP-Based Multiprocessors by Khaled Z. Ibrahim, Gregory T. Byrd, and Eric Rotenberg&lt;br /&gt;
&lt;br /&gt;
3)http://www.research.ibm.com/journal/rd/502/shetty.html&lt;br /&gt;
&lt;br /&gt;
4)http://www.tinker.ncsu.edu/ericro/research/slipstream.htm&lt;/div&gt;</summary>
		<author><name>Lreddy</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki4_helperThreads&amp;diff=10201</id>
		<title>CSC/ECE 506 Fall 2007/wiki4 helperThreads</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki4_helperThreads&amp;diff=10201"/>
		<updated>2007-11-28T22:42:26Z</updated>

		<summary type="html">&lt;p&gt;Lreddy: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''''A helper thread is a thread that does some of the work of the main thread in advance of the main thread so that the main thread can work more quickly. The Olukotun text only scratches the surface on all the different ways that helper threads can be used. Survey these ways, making sure to include the Slipstream approach developed at NCSU.'''''&lt;br /&gt;
&lt;br /&gt;
'''What is a helper thread?'''&lt;br /&gt;
&lt;br /&gt;
The potential of chip multiprocessors (CMPs) can be exploited in a better way if the applications are&lt;br /&gt;
divided into semi - independent parts, or threads that can operate simultaneously across the processors &lt;br /&gt;
within a system. The simplest way to use parallel threads within a CMP to increase the performance of a &lt;br /&gt;
single thread is to have helper threads. A 'helper' thread performs work on behalf of main thread in an &lt;br /&gt;
effort to accelerate its performance.&lt;br /&gt;
&lt;br /&gt;
'''Uses of helper threads'''&lt;br /&gt;
&lt;br /&gt;
'''Predicting branch at early stages:'''&lt;br /&gt;
&lt;br /&gt;
Helper threads are made up of program copies of the main thread stripped of all unessential parts &lt;br /&gt;
which are not of absolute necessity for the helper thread to achieve it tasks. Hence helper threads runs &lt;br /&gt;
ahead of main thread. Hence helper threads run ahead of main thread. Hence helper threads can do &lt;br /&gt;
computations that are necessary to decide the direction of the branch. This will inturn remove branch &lt;br /&gt;
mispredictions which may occur when branch predictions are used.&lt;br /&gt;
&lt;br /&gt;
'''Prefetching of Data:''' &lt;br /&gt;
&lt;br /&gt;
Since helper threads run ahead of main thread, they can predict the which data in memory is needed in&lt;br /&gt;
future by the main thread.they prefetch the data required by the main thread. The helper thread prefetches&lt;br /&gt;
the data and places it in the nearest cache accessible to the main thread. This avoids most of the L1 cache&lt;br /&gt;
misses that would have been encountered by the main thread had if helper thread was not present. As the &lt;br /&gt;
memory latency is reduced, the execution of main thread speeds up.&lt;br /&gt;
   &lt;br /&gt;
'''Memory Bug Reduction:'''&lt;br /&gt;
&lt;br /&gt;
Memory related bugs such as reads from unitialised memory, read or writes using dangling pointers or &lt;br /&gt;
memory leaks are difficult to detect by code inspection because they may invoive different code fragments &lt;br /&gt;
and exist in differnt modules or source code files. Compilers are of little help becuase it fails to &lt;br /&gt;
disambiguate pointers. Hence, in practice memory bug detection relies on run time checkers that insert&lt;br /&gt;
monitor code to the application during testing. In CMPs, the program which detects the memory bugs can run&lt;br /&gt;
as a helper thread.&lt;br /&gt;
&lt;br /&gt;
Ex: Heapmon, a memory bug checker monitors application heap space to detect heap memory bugs. The memory &lt;br /&gt;
access events in the application thread are automatically forwarded to helper thread using appropriate &lt;br /&gt;
hardware mechanisms. Also the redundant and unnecessary  memory accessess are filtered out. Hence the helper&lt;br /&gt;
thread approach completely decouples bug monitoring from appication execution and the filtering mechanism reduces&lt;br /&gt;
bug - check frequency. Conseqently, HeapMon achieves a very low performance overhead.&lt;br /&gt;
&lt;br /&gt;
'''Slipstream approach for helper threads:'''&lt;br /&gt;
&lt;br /&gt;
Slipstream approach is developed at North Carolina State University. &lt;br /&gt;
Slipstream execution provides a simple means to use a second processor in a CMP to accelerate a single program.Slipstream execution involves running two redundant copies of the program. A significant number of dynamic instructions are speculatively removed from one of the program copies, without sacrificing its ability to make correct forward progress. The second program verifies the forward progress of the first and is also sped up in the process.  &lt;br /&gt;
&lt;br /&gt;
The speculative reduced program is called A-stream (Advanced Stream) and runs ahead of the unreduced program (main thread or Redundant stream).The R-stream exploits the A-stream to get an accurate picture of the future. For example, the A-stream &lt;br /&gt;
provides very accurate branch and value predictions. The predictions are more accurate than predictions made by conventional history-based predictors because they are produced by future program computation. The speculative A-stream occasionally (but&lt;br /&gt;
infrequently) goes astray. The R-stream serves as a checker of the speculative A-stream and redirects it when needed.&lt;br /&gt;
&lt;br /&gt;
Synchronization between an R-stream and its corresponding A-stream is required for two reasons.First, an A-stream that has taken a completely wrong control path and is generating useless data access predictions has to be corrcted. Second, limit how far the A-stream gets ahead, so that its prefetches are not issued so early that the prefetched lines are often replaced or invalidated in the L2 cache before the R-stream uses them. A single semaphore is required between each Astream/&lt;br /&gt;
R-stream pair to control their synchronization. It can be a shared hardware register, but any shared location that supports an atomic read-modify-write operation is sufficient. Using this semaphore, the following are controlled&amp;lt;br/&amp;gt;&lt;br /&gt;
(a) how many synchronization events the A-stream can skip without waiting for the Rstream&amp;lt;br/&amp;gt;&lt;br /&gt;
(b) whether the synchronization is local (involving only the companion R-stream) or global (involving all R-streams). The initial value of the semaphore indicates how many sessions the A-stream may proceed ahead of the Rstream. &amp;lt;br/&amp;gt;&lt;br /&gt;
This can be viewed as creating an initial pool of tokens that are consumed as the A-stream enters a new session. When there are no tokens, the Astream may not proceed. The R-stream issues tokens by incrementing the semaphore counter.Once the A thread gets the semaphore, A threads advances and gets past the R thread.&lt;br /&gt;
&lt;br /&gt;
'''Disadvantages of helper threads:'''&lt;br /&gt;
&lt;br /&gt;
A very tight synchronisation is needed between the main thread and the helper threads in oder to keep them the proper distance ahead of main thread. If the helper threads are too far ahead, then they will cause cache thrashing by prefetching data and then replaing it with subsequent prefetches beofre the main thread can even use it. If they are not far enough ahead, they might not be able to prefetch cache lines in time. &lt;br /&gt;
&lt;br /&gt;
Only certain types of single threaded programs can be sped up with these techniques. Most integer applications have regular data access patterns and hence there will be only few misses to eliminate. The applications with larger memory footprints are easily parellelisable and hence doesn't run on a single main thread. Most  floating point applications the data access patterns are fairly regular and hence can be prefetched easily using hardware or software prefetch mechanisms. Hence the range of programs that can be accelerated using helper threads is fairly limited.&lt;br /&gt;
&lt;br /&gt;
'''References'''&lt;br /&gt;
&lt;br /&gt;
1)ChipMultiprocessor Architecture:Techniques to Improve Throughput and Latency by Kunle Olukotun, Lance Hammond, and James Laudon&lt;br /&gt;
&lt;br /&gt;
2)Slipstream Execution Mode for CMP-Based Multiprocessors by Khaled Z. Ibrahim, Gregory T. Byrd, and Eric Rotenberg&lt;br /&gt;
&lt;br /&gt;
3)http://www.research.ibm.com/journal/rd/502/shetty.html&lt;br /&gt;
&lt;br /&gt;
4)http://www.tinker.ncsu.edu/ericro/research/slipstream.htm&lt;/div&gt;</summary>
		<author><name>Lreddy</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki2_helperThreads&amp;diff=10035</id>
		<title>CSC/ECE 506 Fall 2007/wiki2 helperThreads</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki2_helperThreads&amp;diff=10035"/>
		<updated>2007-11-28T17:38:04Z</updated>

		<summary type="html">&lt;p&gt;Lreddy: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''''A helper thread is a thread that does some of the work of the main thread in advance of the main thread so that the main thread can work more quickly. The Olukotun text only scratches the surface on all the different ways that helper threads can be used. Survey these ways, making sure to include the Slipstream approach developed at NCSU.'''''&lt;br /&gt;
&lt;br /&gt;
'''What is a helper thread?'''&lt;br /&gt;
&lt;br /&gt;
The potential of chip multiprocessors (CMPs) can be exploited in a better way if the applications are&lt;br /&gt;
divided into semi - independent parts, or threads that can operate simultaneously across the processors &lt;br /&gt;
within a system. The simplest way to use parallel threads within a CMP to increase the performance of a &lt;br /&gt;
single thread is to have helper threads. A 'helper' thread performs work on behalf of main thread in an &lt;br /&gt;
effort to accelerate its performance.&lt;br /&gt;
&lt;br /&gt;
'''Uses of helper threads'''&lt;br /&gt;
&lt;br /&gt;
'''Predicting branch at early stages:'''&lt;br /&gt;
&lt;br /&gt;
Helper threads are made up of program copies of the main thread stripped of all unessential parts &lt;br /&gt;
which are not of absolute necessity for the helper thread to achieve it tasks. Hence helper threads runs &lt;br /&gt;
ahead of main thread. Hence helper threads run ahead of main thread. Hence helper threads can do &lt;br /&gt;
computations that are necessary to decide the direction of the branch. This will inturn remove branch &lt;br /&gt;
mispredictions which may occur when branch predictions are used.&lt;br /&gt;
&lt;br /&gt;
'''Prefetching of Data:''' &lt;br /&gt;
&lt;br /&gt;
Since helper threads run ahead of main thread, they can predict the which data in memory is needed in&lt;br /&gt;
future by the main thread.they prefetch the data required by the main thread. The helper thread prefetches&lt;br /&gt;
the data and places it in the nearest cache accessible to the main thread. This avoids most of the L1 cache&lt;br /&gt;
misses that would have been encountered by the main thread had if helper thread was not present. As the &lt;br /&gt;
memory latency is reduced, the execution of main thread speeds up.&lt;br /&gt;
   &lt;br /&gt;
'''Memory Bug Reduction:'''&lt;br /&gt;
&lt;br /&gt;
Memory related bugs such as reads from unitialised memory, read or writes using dangling pointers or &lt;br /&gt;
memory leaks are difficult to detect by code inspection because they may invoive different code fragments &lt;br /&gt;
and exist in differnt modules or source code files. Compilers are of little help becuase it fails to &lt;br /&gt;
disambiguate pointers. Hence, in practice memory bug detection relies on run time checkers that insert&lt;br /&gt;
monitor code to the application during testing. In CMPs, the program which detects the memory bugs can run&lt;br /&gt;
as a helper thread.&lt;br /&gt;
&lt;br /&gt;
Ex: Heapmon, a memory bug checker monitors application heap space to detect heap memory bugs. The memory &lt;br /&gt;
access events in the application thread are automatically forwarded to helper thread using appropriate &lt;br /&gt;
hardware mechanisms. Also the redundant and unnecessary  memory accessess are filtered out. Hence the helper&lt;br /&gt;
thread approach completely decouples bug monitoring from appication execution and the filtering mechanism reduces&lt;br /&gt;
bug - check frequency. Conseqently, HeapMon achieves a very low performance overhead.&lt;br /&gt;
&lt;br /&gt;
'''Slipstream approach for helper threads:'''&lt;br /&gt;
&lt;br /&gt;
Slipstream approach is developed at North Carolina State University. &lt;br /&gt;
Slipstream execution provides a simple means to use a second processor in a CMP to accelerate a single program.Slipstream execution involves running two redundant copies of the program. A significant number of dynamic instructions are speculatively removed from one of the program copies, without sacrificing its ability to make correct forward progress. The second program verifies the forward progress of the first and is also sped up in the process.  &lt;br /&gt;
&lt;br /&gt;
The speculative reduced program is called A-stream (Advanced Stream) and runs ahead of the unreduced program (main thread or Redundant stream).The R-stream exploits the A-stream to get an accurate picture of the future. For example, the A-stream &lt;br /&gt;
provides very accurate branch and value predictions. The predictions are more accurate than predictions made by conventional history-based predictors because they are produced by future program computation. The speculative A-stream occasionally (but&lt;br /&gt;
infrequently) goes astray. The R-stream serves as a checker of the speculative A-stream and redirects it when needed.&lt;br /&gt;
&lt;br /&gt;
Synchronization between an R-stream and its corresponding A-stream is required for two reasons.First, an A-stream that has taken a completely wrong control path and is generating useless data access predictions has to be corrcted. Second, limit how far the A-stream gets ahead, so that its prefetches are not issued so early that the prefetched lines are often replaced or invalidated in the L2 cache before the R-stream uses them. A single semaphore is required between each Astream/&lt;br /&gt;
R-stream pair to control their synchronization. It can be a shared hardware register, but any shared location that supports an atomic read-modify-write operation is sufficient. Using this semaphore, the following are controlled&amp;lt;br/&amp;gt;&lt;br /&gt;
(a) how many synchronization events the A-stream can skip without waiting for the Rstream&amp;lt;br/&amp;gt;&lt;br /&gt;
(b) whether the synchronization is local (involving only the companion R-stream) or global (involving all R-streams). The initial value of the semaphore indicates how many sessions the A-stream may proceed ahead of the Rstream. &amp;lt;br/&amp;gt;&lt;br /&gt;
This can be viewed as creating an initial pool of tokens that are consumed as the A-stream enters a new session. When there are no tokens, the Astream may not proceed. The R-stream issues tokens by incrementing the semaphore counter.Once the A thread gets the semaphore, A threads advances and gets past the R thread.&lt;br /&gt;
&lt;br /&gt;
'''Disadvantages of helper threads:'''&lt;br /&gt;
&lt;br /&gt;
A very tight synchronisation is needed between the main thread and the helper threads in oder to keep them the proper distance ahead of main thread. If the helper threads are too far ahead, then they will cause cache thrashing by prefetching data and then replaing it with subsequent prefetches beofre the main thread can even use it. If they are not far enough ahead, they might not be able to prefetch cache lines in time. &lt;br /&gt;
&lt;br /&gt;
Only certain types of single threaded programs can be sped up with these techniques. Most integer applications have regular data access patterns and hence there will be only few misses to eliminate. The applications with larger memory footprints are easily parellelisable and hence doesn't run on a single main thread. Most  floating point applications the data access patterns are fairly regular and hence can be prefetched easily using hardware or software prefetch mechanisms. Hence the range of programs that can be accelerated using helper threads is fairly limited.&lt;br /&gt;
&lt;br /&gt;
'''References'''&lt;br /&gt;
&lt;br /&gt;
1)ChipMultiprocessor Architecture:Techniques to Improve Throughput and Latency by Kunle Olukotun, Lance Hammond, and James Laudon&lt;br /&gt;
&lt;br /&gt;
2)Slipstream Execution Mode for CMP-Based Multiprocessors by Khaled Z. Ibrahim, Gregory T. Byrd, and Eric Rotenberg&lt;br /&gt;
&lt;br /&gt;
3)http://www.research.ibm.com/journal/rd/502/shetty.html&lt;br /&gt;
&lt;br /&gt;
4)http://www.tinker.ncsu.edu/ericro/research/slipstream.htm&lt;/div&gt;</summary>
		<author><name>Lreddy</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki2_helperThreads&amp;diff=10034</id>
		<title>CSC/ECE 506 Fall 2007/wiki2 helperThreads</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki2_helperThreads&amp;diff=10034"/>
		<updated>2007-11-28T17:37:44Z</updated>

		<summary type="html">&lt;p&gt;Lreddy: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;''A helper thread is a thread that does some of the work of the main thread in advance of the main thread so that the main thread can work more quickly. The Olukotun text only scratches the surface on all the different ways that helper threads can be used. Survey these ways, making sure to include the Slipstream approach developed at NCSU.''&lt;br /&gt;
&lt;br /&gt;
'''What is a helper thread?'''&lt;br /&gt;
&lt;br /&gt;
The potential of chip multiprocessors (CMPs) can be exploited in a better way if the applications are&lt;br /&gt;
divided into semi - independent parts, or threads that can operate simultaneously across the processors &lt;br /&gt;
within a system. The simplest way to use parallel threads within a CMP to increase the performance of a &lt;br /&gt;
single thread is to have helper threads. A 'helper' thread performs work on behalf of main thread in an &lt;br /&gt;
effort to accelerate its performance.&lt;br /&gt;
&lt;br /&gt;
'''Uses of helper threads'''&lt;br /&gt;
&lt;br /&gt;
'''Predicting branch at early stages:'''&lt;br /&gt;
&lt;br /&gt;
Helper threads are made up of program copies of the main thread stripped of all unessential parts &lt;br /&gt;
which are not of absolute necessity for the helper thread to achieve it tasks. Hence helper threads runs &lt;br /&gt;
ahead of main thread. Hence helper threads run ahead of main thread. Hence helper threads can do &lt;br /&gt;
computations that are necessary to decide the direction of the branch. This will inturn remove branch &lt;br /&gt;
mispredictions which may occur when branch predictions are used.&lt;br /&gt;
&lt;br /&gt;
'''Prefetching of Data:''' &lt;br /&gt;
&lt;br /&gt;
Since helper threads run ahead of main thread, they can predict the which data in memory is needed in&lt;br /&gt;
future by the main thread.they prefetch the data required by the main thread. The helper thread prefetches&lt;br /&gt;
the data and places it in the nearest cache accessible to the main thread. This avoids most of the L1 cache&lt;br /&gt;
misses that would have been encountered by the main thread had if helper thread was not present. As the &lt;br /&gt;
memory latency is reduced, the execution of main thread speeds up.&lt;br /&gt;
   &lt;br /&gt;
'''Memory Bug Reduction:'''&lt;br /&gt;
&lt;br /&gt;
Memory related bugs such as reads from unitialised memory, read or writes using dangling pointers or &lt;br /&gt;
memory leaks are difficult to detect by code inspection because they may invoive different code fragments &lt;br /&gt;
and exist in differnt modules or source code files. Compilers are of little help becuase it fails to &lt;br /&gt;
disambiguate pointers. Hence, in practice memory bug detection relies on run time checkers that insert&lt;br /&gt;
monitor code to the application during testing. In CMPs, the program which detects the memory bugs can run&lt;br /&gt;
as a helper thread.&lt;br /&gt;
&lt;br /&gt;
Ex: Heapmon, a memory bug checker monitors application heap space to detect heap memory bugs. The memory &lt;br /&gt;
access events in the application thread are automatically forwarded to helper thread using appropriate &lt;br /&gt;
hardware mechanisms. Also the redundant and unnecessary  memory accessess are filtered out. Hence the helper&lt;br /&gt;
thread approach completely decouples bug monitoring from appication execution and the filtering mechanism reduces&lt;br /&gt;
bug - check frequency. Conseqently, HeapMon achieves a very low performance overhead.&lt;br /&gt;
&lt;br /&gt;
'''Slipstream approach for helper threads:'''&lt;br /&gt;
&lt;br /&gt;
Slipstream approach is developed at North Carolina State University. &lt;br /&gt;
Slipstream execution provides a simple means to use a second processor in a CMP to accelerate a single program.Slipstream execution involves running two redundant copies of the program. A significant number of dynamic instructions are speculatively removed from one of the program copies, without sacrificing its ability to make correct forward progress. The second program verifies the forward progress of the first and is also sped up in the process.  &lt;br /&gt;
&lt;br /&gt;
The speculative reduced program is called A-stream (Advanced Stream) and runs ahead of the unreduced program (main thread or Redundant stream).The R-stream exploits the A-stream to get an accurate picture of the future. For example, the A-stream &lt;br /&gt;
provides very accurate branch and value predictions. The predictions are more accurate than predictions made by conventional history-based predictors because they are produced by future program computation. The speculative A-stream occasionally (but&lt;br /&gt;
infrequently) goes astray. The R-stream serves as a checker of the speculative A-stream and redirects it when needed.&lt;br /&gt;
&lt;br /&gt;
Synchronization between an R-stream and its corresponding A-stream is required for two reasons.First, an A-stream that has taken a completely wrong control path and is generating useless data access predictions has to be corrcted. Second, limit how far the A-stream gets ahead, so that its prefetches are not issued so early that the prefetched lines are often replaced or invalidated in the L2 cache before the R-stream uses them. A single semaphore is required between each Astream/&lt;br /&gt;
R-stream pair to control their synchronization. It can be a shared hardware register, but any shared location that supports an atomic read-modify-write operation is sufficient. Using this semaphore, the following are controlled&amp;lt;br/&amp;gt;&lt;br /&gt;
(a) how many synchronization events the A-stream can skip without waiting for the Rstream&amp;lt;br/&amp;gt;&lt;br /&gt;
(b) whether the synchronization is local (involving only the companion R-stream) or global (involving all R-streams). The initial value of the semaphore indicates how many sessions the A-stream may proceed ahead of the Rstream. &amp;lt;br/&amp;gt;&lt;br /&gt;
This can be viewed as creating an initial pool of tokens that are consumed as the A-stream enters a new session. When there are no tokens, the Astream may not proceed. The R-stream issues tokens by incrementing the semaphore counter.Once the A thread gets the semaphore, A threads advances and gets past the R thread.&lt;br /&gt;
&lt;br /&gt;
'''Disadvantages of helper threads:'''&lt;br /&gt;
&lt;br /&gt;
A very tight synchronisation is needed between the main thread and the helper threads in oder to keep them the proper distance ahead of main thread. If the helper threads are too far ahead, then they will cause cache thrashing by prefetching data and then replaing it with subsequent prefetches beofre the main thread can even use it. If they are not far enough ahead, they might not be able to prefetch cache lines in time. &lt;br /&gt;
&lt;br /&gt;
Only certain types of single threaded programs can be sped up with these techniques. Most integer applications have regular data access patterns and hence there will be only few misses to eliminate. The applications with larger memory footprints are easily parellelisable and hence doesn't run on a single main thread. Most  floating point applications the data access patterns are fairly regular and hence can be prefetched easily using hardware or software prefetch mechanisms. Hence the range of programs that can be accelerated using helper threads is fairly limited.&lt;br /&gt;
&lt;br /&gt;
'''References'''&lt;br /&gt;
&lt;br /&gt;
1)ChipMultiprocessor Architecture:Techniques to Improve Throughput and Latency by Kunle Olukotun, Lance Hammond, and James Laudon&lt;br /&gt;
&lt;br /&gt;
2)Slipstream Execution Mode for CMP-Based Multiprocessors by Khaled Z. Ibrahim, Gregory T. Byrd, and Eric Rotenberg&lt;br /&gt;
&lt;br /&gt;
3)http://www.research.ibm.com/journal/rd/502/shetty.html&lt;br /&gt;
&lt;br /&gt;
4)http://www.tinker.ncsu.edu/ericro/research/slipstream.htm&lt;/div&gt;</summary>
		<author><name>Lreddy</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki2_helperThreads&amp;diff=10032</id>
		<title>CSC/ECE 506 Fall 2007/wiki2 helperThreads</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki2_helperThreads&amp;diff=10032"/>
		<updated>2007-11-28T17:35:16Z</updated>

		<summary type="html">&lt;p&gt;Lreddy: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;A helper thread is a thread that does some of the work of the main thread in advance of the main thread so that the main thread can work more quickly. The Olukotun text only scratches the surface on all the different ways that helper threads can be used. Survey these ways, making sure to include the Slipstream approach developed at NCSU.&lt;br /&gt;
&lt;br /&gt;
'''What is a helper thread?'''&lt;br /&gt;
&lt;br /&gt;
The potential of chip multiprocessors (CMPs) can be exploited in a better way if the applications are&lt;br /&gt;
divided into semi - independent parts, or threads that can operate simultaneously across the processors &lt;br /&gt;
within a system. The simplest way to use parallel threads within a CMP to increase the performance of a &lt;br /&gt;
single thread is to have helper threads. A 'helper' thread performs work on behalf of main thread in an &lt;br /&gt;
effort to accelerate its performance.&lt;br /&gt;
&lt;br /&gt;
'''Uses of helper threads'''&lt;br /&gt;
&lt;br /&gt;
'''Predicting branch at early stages:'''&lt;br /&gt;
&lt;br /&gt;
Helper threads are made up of program copies of the main thread stripped of all unessential parts &lt;br /&gt;
which are not of absolute necessity for the helper thread to achieve it tasks. Hence helper threads runs &lt;br /&gt;
ahead of main thread. Hence helper threads run ahead of main thread. Hence helper threads can do &lt;br /&gt;
computations that are necessary to decide the direction of the branch. This will inturn remove branch &lt;br /&gt;
mispredictions which may occur when branch predictions are used.&lt;br /&gt;
&lt;br /&gt;
'''Prefetching of Data:''' &lt;br /&gt;
&lt;br /&gt;
Since helper threads run ahead of main thread, they can predict the which data in memory is needed in&lt;br /&gt;
future by the main thread.they prefetch the data required by the main thread. The helper thread prefetches&lt;br /&gt;
the data and places it in the nearest cache accessible to the main thread. This avoids most of the L1 cache&lt;br /&gt;
misses that would have been encountered by the main thread had if helper thread was not present. As the &lt;br /&gt;
memory latency is reduced, the execution of main thread speeds up.&lt;br /&gt;
   &lt;br /&gt;
'''Memory Bug Reduction:'''&lt;br /&gt;
&lt;br /&gt;
Memory related bugs such as reads from unitialised memory, read or writes using dangling pointers or &lt;br /&gt;
memory leaks are difficult to detect by code inspection because they may invoive different code fragments &lt;br /&gt;
and exist in differnt modules or source code files. Compilers are of little help becuase it fails to &lt;br /&gt;
disambiguate pointers. Hence, in practice memory bug detection relies on run time checkers that insert&lt;br /&gt;
monitor code to the application during testing. In CMPs, the program which detects the memory bugs can run&lt;br /&gt;
as a helper thread.&lt;br /&gt;
&lt;br /&gt;
Ex: Heapmon, a memory bug checker monitors application heap space to detect heap memory bugs. The memory &lt;br /&gt;
access events in the application thread are automatically forwarded to helper thread using appropriate &lt;br /&gt;
hardware mechanisms. Also the redundant and unnecessary  memory accessess are filtered out. Hence the helper&lt;br /&gt;
thread approach completely decouples bug monitoring from appication execution and the filtering mechanism reduces&lt;br /&gt;
bug - check frequency. Conseqently, HeapMon achieves a very low performance overhead.&lt;br /&gt;
&lt;br /&gt;
'''Slipstream approach for helper threads:'''&lt;br /&gt;
&lt;br /&gt;
Slipstream approach is developed at North Carolina State University. &lt;br /&gt;
Slipstream execution provides a simple means to use a second processor in a CMP to accelerate a single program.Slipstream execution involves running two redundant copies of the program. A significant number of dynamic instructions are speculatively removed from one of the program copies, without sacrificing its ability to make correct forward progress. The second program verifies the forward progress of the first and is also sped up in the process.  &lt;br /&gt;
&lt;br /&gt;
The speculative reduced program is called A-stream (Advanced Stream) and runs ahead of the unreduced program (main thread or Redundant stream).The R-stream exploits the A-stream to get an accurate picture of the future. For example, the A-stream &lt;br /&gt;
provides very accurate branch and value predictions. The predictions are more accurate than predictions made by conventional history-based predictors because they are produced by future program computation. The speculative A-stream occasionally (but&lt;br /&gt;
infrequently) goes astray. The R-stream serves as a checker of the speculative A-stream and redirects it when needed.&lt;br /&gt;
&lt;br /&gt;
Synchronization between an R-stream and its corresponding A-stream is required for two reasons.First, an A-stream that has taken a completely wrong control path and is generating useless data access predictions has to be corrcted. Second, limit how far the A-stream gets ahead, so that its prefetches are not issued so early that the prefetched lines are often replaced or invalidated in the L2 cache before the R-stream uses them. A single semaphore is required between each Astream/&lt;br /&gt;
R-stream pair to control their synchronization. It can be a shared hardware register, but any shared location that supports an atomic read-modify-write operation is sufficient. Using this semaphore, the following are controlled&amp;lt;br/&amp;gt;&lt;br /&gt;
(a) how many synchronization events the A-stream can skip without waiting for the Rstream&amp;lt;br/&amp;gt;&lt;br /&gt;
(b) whether the synchronization is local (involving only the companion R-stream) or global (involving all R-streams). The initial value of the semaphore indicates how many sessions the A-stream may proceed ahead of the Rstream. &amp;lt;br/&amp;gt;&lt;br /&gt;
This can be viewed as creating an initial pool of tokens that are consumed as the A-stream enters a new session. When there are no tokens, the Astream may not proceed. The R-stream issues tokens by incrementing the semaphore counter.Once the A thread gets the semaphore, A threads advances and gets past the R thread.&lt;br /&gt;
&lt;br /&gt;
'''Disadvantages of helper threads:'''&lt;br /&gt;
&lt;br /&gt;
A very tight synchronisation is needed between the main thread and the helper threads in oder to keep them the proper distance ahead of main thread. If the helper threads are too far ahead, then they will cause cache thrashing by prefetching data and then replaing it with subsequent prefetches beofre the main thread can even use it. If they are not far enough ahead, they might not be able to prefetch cache lines in time. &lt;br /&gt;
&lt;br /&gt;
Only certain types of single threaded programs can be sped up with these techniques. Most integer applications have regular data access patterns and hence there will be only few misses to eliminate. The applications with larger memory footprints are easily parellelisable and hence doesn't run on a single main thread. Most  floating point applications the data access patterns are fairly regular and hence can be prefetched easily using hardware or software prefetch mechanisms. Hence the range of programs that can be accelerated using helper threads is fairly limited.&lt;br /&gt;
&lt;br /&gt;
'''References'''&lt;br /&gt;
&lt;br /&gt;
1)ChipMultiprocessor Architecture:Techniques to Improve Throughput and Latency by Kunle Olukotun, Lance Hammond, and James Laudon&lt;br /&gt;
&lt;br /&gt;
2)Slipstream Execution Mode for CMP-Based Multiprocessors by Khaled Z. Ibrahim, Gregory T. Byrd, and Eric Rotenberg&lt;br /&gt;
&lt;br /&gt;
3)http://www.research.ibm.com/journal/rd/502/shetty.html&lt;br /&gt;
&lt;br /&gt;
4)http://www.tinker.ncsu.edu/ericro/research/slipstream.htm&lt;/div&gt;</summary>
		<author><name>Lreddy</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki2_helperThreads&amp;diff=10031</id>
		<title>CSC/ECE 506 Fall 2007/wiki2 helperThreads</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki2_helperThreads&amp;diff=10031"/>
		<updated>2007-11-28T17:34:51Z</updated>

		<summary type="html">&lt;p&gt;Lreddy: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;A helper thread is a thread that does some of the work of the main thread in advance of the main thread so that the main thread can work more quickly. The Olukotun text only scratches the surface on all the different ways that helper threads can be used. Survey these ways, making sure to include the Slipstream approach developed at NCSU.&lt;br /&gt;
&lt;br /&gt;
'''What is a helper thread?'''&lt;br /&gt;
&lt;br /&gt;
The potential of chip multiprocessors (CMPs) can be exploited in a better way if the applications are&lt;br /&gt;
divided into semi - independent parts, or threads that can operate simultaneously across the processors &lt;br /&gt;
within a system. The simplest way to use parallel threads within a CMP to increase the performance of a &lt;br /&gt;
single thread is to have helper threads. A 'helper' thread performs work on behalf of main thread in an &lt;br /&gt;
effort to accelerate its performance.&lt;br /&gt;
&lt;br /&gt;
'''Uses of helper threads'''&lt;br /&gt;
&lt;br /&gt;
'''Predicting branch at early stages:'''&lt;br /&gt;
&lt;br /&gt;
Helper threads are made up of program copies of the main thread stripped of all unessential parts &lt;br /&gt;
which are not of absolute necessity for the helper thread to achieve it tasks. Hence helper threads runs &lt;br /&gt;
ahead of main thread. Hence helper threads run ahead of main thread. Hence helper threads can do &lt;br /&gt;
computations that are necessary to decide the direction of the branch. This will inturn remove branch &lt;br /&gt;
mispredictions which may occur when branch predictions are used.&lt;br /&gt;
&lt;br /&gt;
'''Prefetching of Data:''' &lt;br /&gt;
&lt;br /&gt;
Since helper threads run ahead of main thread, they can predict the which data in memory is needed in&lt;br /&gt;
future by the main thread.they prefetch the data required by the main thread. The helper thread prefetches&lt;br /&gt;
the data and places it in the nearest cache accessible to the main thread. This avoids most of the L1 cache&lt;br /&gt;
misses that would have been encountered by the main thread had if helper thread was not present. As the &lt;br /&gt;
memory latency is reduced, the execution of main thread speeds up.&lt;br /&gt;
   &lt;br /&gt;
'''Memory Bug Reduction:'''&lt;br /&gt;
&lt;br /&gt;
Memory related bugs such as reads from unitialised memory, read or writes using dangling pointers or &lt;br /&gt;
memory leaks are difficult to detect by code inspection because they may invoive different code fragments &lt;br /&gt;
and exist in differnt modules or source code files. Compilers are of little help becuase it fails to &lt;br /&gt;
disambiguate pointers. Hence, in practice memory bug detection relies on run time checkers that insert&lt;br /&gt;
monitor code to the application during testing. In CMPs, the program which detects the memory bugs can run&lt;br /&gt;
as a helper thread.&lt;br /&gt;
&lt;br /&gt;
Ex: Heapmon, a memory bug checker monitors application heap space to detect heap memory bugs. The memory &lt;br /&gt;
access events in the application thread are automatically forwarded to helper thread using appropriate &lt;br /&gt;
hardware mechanisms. Also the redundant and unnecessary  memory accessess are filtered out. Hence the helper&lt;br /&gt;
thread approach completely decouples bug monitoring from appication execution and the filtering mechanism reduces&lt;br /&gt;
bug - check frequency. Conseqently, HeapMon achieves a very low performance overhead.&lt;br /&gt;
&lt;br /&gt;
'''Slipstream approach for helper threads:'''&lt;br /&gt;
&lt;br /&gt;
Slipstream approach is developed at North Carolina State University. &lt;br /&gt;
Slipstream execution provides a simple means to use a second processor in a CMP to accelerate a single program.Slipstream execution involves running two redundant copies of the program. A significant number of dynamic instructions are speculatively removed from one of the program copies, without sacrificing its ability to make correct forward progress. The second program verifies the forward progress of the first and is also sped up in the process.  &lt;br /&gt;
&lt;br /&gt;
The speculative reduced program is called A-stream (Advanced Stream) and runs ahead of the unreduced program (main thread or Redundant stream).The R-stream exploits the A-stream to get an accurate picture of the future. For example, the A-stream &lt;br /&gt;
provides very accurate branch and value predictions. The predictions are more accurate than predictions made by conventional history-based predictors because they are produced by future program computation. The speculative A-stream occasionally (but&lt;br /&gt;
infrequently) goes astray. The R-stream serves as a checker of the speculative A-stream and redirects it when needed.&lt;br /&gt;
&lt;br /&gt;
Synchronization between an R-stream and its corresponding A-stream is required for two reasons.First, an A-stream that has taken a completely wrong control path and is generating useless data access predictions has to be corrcted. Second, limit how far the A-stream gets ahead, so that its prefetches are not issued so early that the prefetched lines are often replaced or invalidated in the L2 cache before the R-stream uses them. A single semaphore is required between each Astream/&lt;br /&gt;
R-stream pair to control their synchronization. It can be a shared hardware register, but any shared location that supports an atomic read-modify-write operation is sufficient. Using this semaphore, the following are controlled&amp;lt;br/&amp;gt;&lt;br /&gt;
(a) how many synchronization events the A-stream can skip without waiting for the Rstream&amp;lt;br/&amp;gt;&lt;br /&gt;
(b) whether the synchronization is local (involving only the companion R-stream) or global (involving all R-streams). The initial value of the semaphore indicates how many sessions the A-stream may proceed ahead of the Rstream. &amp;lt;br/&amp;gt;&lt;br /&gt;
This can be viewed as creating an initial pool of tokens that are consumed as the A-stream enters a new session. When there are no tokens, the Astream may not proceed. The R-stream issues tokens by incrementing the semaphore counter.Once the A thread gets the semaphore, A threads advances and gets past the R thread.&lt;br /&gt;
&lt;br /&gt;
'''Disadvantages of helper threads:'''&lt;br /&gt;
&lt;br /&gt;
A very tight synchronisation is needed between the main thread and the helper threads in oder to keep them the proper distance ahead of main thread. If the helper threads are too far ahead, then they will cause cache thrashing by prefetching data and then replaing it with subsequent prefetches beofre the main thread can even use it. If they are not far enough ahead, they might not be able to prefetch cache lines in time. &lt;br /&gt;
&lt;br /&gt;
Only certain types of single threaded programs can be sped up with these techniques. Most integer applications have regular data access patterns and hence there will be only few misses to eliminate. The applications with larger memory footprints are easily parellelisable and hence doesn't run on a single main thread. Most  floating point applications the data access patterns are fairly regular and hence can be prefetched easily using hardware or software prefetch mechanisms. Hence the range of programs that can be accelerated using helper threads is fairly limited.&lt;br /&gt;
&lt;br /&gt;
'''References'''&lt;br /&gt;
&lt;br /&gt;
1)ChipMultiprocessor Architecture:Techniques to Improve Throughput and Latency by Kunle Olukotun, Lance Hammond, and James Laudon&lt;br /&gt;
&lt;br /&gt;
2)Slipstream Execution Mode for CMP-Based Multiprocessors by Khaled Z. Ibrahim, Gregory T. Byrd, and Eric Rotenberg&lt;br /&gt;
&lt;br /&gt;
3)http://www.research.ibm.com/journal/rd/502/shetty.html&lt;br /&gt;
&lt;br /&gt;
4)www.tinker.ncsu.edu/ericro/research/slipstream.htm&lt;/div&gt;</summary>
		<author><name>Lreddy</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki2_helperThreads&amp;diff=10028</id>
		<title>CSC/ECE 506 Fall 2007/wiki2 helperThreads</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki2_helperThreads&amp;diff=10028"/>
		<updated>2007-11-28T17:27:59Z</updated>

		<summary type="html">&lt;p&gt;Lreddy: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;A helper thread is a thread that does some of the work of the main thread in advance of the main thread so that the main thread can work more quickly. The Olukotun text only scratches the surface on all the different ways that helper threads can be used. Survey these ways, making sure to include the Slipstream approach developed at NCSU.&lt;br /&gt;
&lt;br /&gt;
'''What is a helper thread?'''&lt;br /&gt;
&lt;br /&gt;
The potential of chip multiprocessors (CMPs) can be exploited in a better way if the applications are&lt;br /&gt;
divided into semi - independent parts, or threads that can operate simultaneously across the processors &lt;br /&gt;
within a system. The simplest way to use parallel threads within a CMP to increase the performance of a &lt;br /&gt;
single thread is to have helper threads. A 'helper' thread performs work on behalf of main thread in an &lt;br /&gt;
effort to accelerate its performance.&lt;br /&gt;
&lt;br /&gt;
'''Uses of helper threads'''&lt;br /&gt;
&lt;br /&gt;
'''Predicting branch at early stages:'''&lt;br /&gt;
&lt;br /&gt;
Helper threads are made up of program copies of the main thread stripped of all unessential parts &lt;br /&gt;
which are not of absolute necessity for the helper thread to achieve it tasks. Hence helper threads runs &lt;br /&gt;
ahead of main thread. Hence helper threads run ahead of main thread. Hence helper threads can do &lt;br /&gt;
computations that are necessary to decide the direction of the branch. This will inturn remove branch &lt;br /&gt;
mispredictions which may occur when branch predictions are used.&lt;br /&gt;
&lt;br /&gt;
'''Prefetching of Data:''' &lt;br /&gt;
&lt;br /&gt;
Since helper threads run ahead of main thread, they can predict the which data in memory is needed in&lt;br /&gt;
future by the main thread.they prefetch the data required by the main thread. The helper thread prefetches&lt;br /&gt;
the data and places it in the nearest cache accessible to the main thread. This avoids most of the L1 cache&lt;br /&gt;
misses that would have been encountered by the main thread had if helper thread was not present. As the &lt;br /&gt;
memory latency is reduced, the execution of main thread speeds up.&lt;br /&gt;
   &lt;br /&gt;
'''Memory Bug Reduction:'''&lt;br /&gt;
&lt;br /&gt;
Memory related bugs such as reads from unitialised memory, read or writes using dangling pointers or &lt;br /&gt;
memory leaks are difficult to detect by code inspection because they may invoive different code fragments &lt;br /&gt;
and exist in differnt modules or source code files. Compilers are of little help becuase it fails to &lt;br /&gt;
disambiguate pointers. Hence, in practice memory bug detection relies on run time checkers that insert&lt;br /&gt;
monitor code to the application during testing. In CMPs, the program which detects the memory bugs can run&lt;br /&gt;
as a helper thread.&lt;br /&gt;
&lt;br /&gt;
Ex: Heapmon, a memory bug checker monitors application heap space to detect heap memory bugs. The memory &lt;br /&gt;
access events in the application thread are automatically forwarded to helper thread using appropriate &lt;br /&gt;
hardware mechanisms. Also the redundant and unnecessary  memory accessess are filtered out. Hence the helper&lt;br /&gt;
thread approach completely decouples bug monitoring from appication execution and the filtering mechanism reduces&lt;br /&gt;
bug - check frequency. Conseqently, HeapMon achieves a very low performance overhead.&lt;br /&gt;
&lt;br /&gt;
'''Slipstream approach for helper threads:'''&lt;br /&gt;
&lt;br /&gt;
Slipstream approach is developed at North Carolina State University. &lt;br /&gt;
Slipstream execution provides a simple means to use a second processor in a CMP to accelerate a single program.Slipstream execution involves running two redundant copies of the program. A significant number of dynamic instructions are speculatively removed from one of the program copies, without sacrificing its ability to make correct forward progress. The second program verifies the forward progress of the first and is also sped up in the process.  &lt;br /&gt;
&lt;br /&gt;
The speculative reduced program is called A-stream (Advanced Stream) and runs ahead of the unreduced program (main thread or Redundant stream).The R-stream exploits the A-stream to get an accurate picture of the future. For example, the A-stream &lt;br /&gt;
provides very accurate branch and value predictions. The predictions are more accurate than predictions made by conventional history-based predictors because they are produced by future program computation. The speculative A-stream occasionally (but&lt;br /&gt;
infrequently) goes astray. The R-stream serves as a checker of the speculative A-stream and redirects it when needed.&lt;br /&gt;
&lt;br /&gt;
Synchronization between an R-stream and its corresponding A-stream is required for two reasons.First, an A-stream that has taken a completely wrong control path and is generating useless data access predictions has to be corrcted. Second, limit how far the A-stream gets ahead, so that its prefetches are not issued so early that the prefetched lines are often replaced or invalidated in the L2 cache before the R-stream uses them. A single semaphore is required between each Astream/&lt;br /&gt;
R-stream pair to control their synchronization. It can be a shared hardware register, but any shared location that supports an atomic read-modify-write operation is sufficient. Using this semaphore, the following are controlled&amp;lt;br/&amp;gt;&lt;br /&gt;
(a) how many synchronization events the A-stream can skip without waiting for the Rstream&amp;lt;br/&amp;gt;&lt;br /&gt;
(b) whether the synchronization is local (involving only the companion R-stream) or global (involving all R-streams). The initial value of the semaphore indicates how many sessions the A-stream may proceed ahead of the Rstream. &amp;lt;br/&amp;gt;&lt;br /&gt;
This can be viewed as creating an initial pool of tokens that are consumed as the A-stream enters a new session. When there are no tokens, the Astream may not proceed. The R-stream issues tokens by incrementing the semaphore counter.Once the A thread gets the semaphore, A threads advances and gets past the R thread.&lt;br /&gt;
&lt;br /&gt;
'''Disadvantages of helper threads:'''&lt;br /&gt;
&lt;br /&gt;
A very tight synchronisation is needed between the main thread and the helper threads in oder to keep them the proper distance ahead of main thread. If the helper threads are too far ahead, then they will cause cache thrashing by prefetching data and then replaing it with subsequent prefetches beofre the main thread can even use it. If they are not far enough ahead, they might not be able to prefetch cache lines in time. &lt;br /&gt;
&lt;br /&gt;
Only certain types of single threaded programs can be sped up with these techniques. Most integer applications have regular data access patterns and hence there will be only few misses to eliminate. The applications with larger memory footprints are easily parellelisable and hence doesn't run on a single main thread. Most  floating point applications the data access patterns are fairly regular and hence can be prefetched easily using hardware or software prefetch mechanisms. Hence the range of programs that can be accelerated using helper threads is fairly limited.&lt;/div&gt;</summary>
		<author><name>Lreddy</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki2_helperThreads&amp;diff=10027</id>
		<title>CSC/ECE 506 Fall 2007/wiki2 helperThreads</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki2_helperThreads&amp;diff=10027"/>
		<updated>2007-11-28T17:27:22Z</updated>

		<summary type="html">&lt;p&gt;Lreddy: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;A helper thread is a thread that does some of the work of the main thread in advance of the main thread so that the main thread can work more quickly. The Olukotun text only scratches the surface on all the different ways that helper threads can be used. Survey these ways, making sure to include the Slipstream approach developed at NCSU.&lt;br /&gt;
&lt;br /&gt;
'''What is a helper thread?'''&lt;br /&gt;
&lt;br /&gt;
The potential of chip multiprocessors (CMPs) can be exploited in a better way if the applications are&lt;br /&gt;
divided into semi - independent parts, or threads that can operate simultaneously across the processors &lt;br /&gt;
within a system. The simplest way to use parallel threads within a CMP to increase the performance of a &lt;br /&gt;
single thread is to have helper threads. A 'helper' thread performs work on behalf of main thread in an &lt;br /&gt;
effort to accelerate its performance.&lt;br /&gt;
&lt;br /&gt;
'''Uses of helper threads'''&lt;br /&gt;
&lt;br /&gt;
'''Predicting branch at early stages:'''&lt;br /&gt;
&lt;br /&gt;
Helper threads are made up of program copies of the main thread stripped of all unessential parts &lt;br /&gt;
which are not of absolute necessity for the helper thread to achieve it tasks. Hence helper threads runs &lt;br /&gt;
ahead of main thread. Hence helper threads run ahead of main thread. Hence helper threads can do &lt;br /&gt;
computations that are necessary to decide the direction of the branch. This will inturn remove branch &lt;br /&gt;
mispredictions which may occur when branch predictions are used.&lt;br /&gt;
&lt;br /&gt;
'''Prefetching of Data:''' &lt;br /&gt;
&lt;br /&gt;
Since helper threads run ahead of main thread, they can predict the which data in memory is needed in&lt;br /&gt;
future by the main thread.they prefetch the data required by the main thread. The helper thread prefetches&lt;br /&gt;
the data and places it in the nearest cache accessible to the main thread. This avoids most of the L1 cache&lt;br /&gt;
misses that would have been encountered by the main thread had if helper thread was not present. As the &lt;br /&gt;
memory latency is reduced, the execution of main thread speeds up.&lt;br /&gt;
   &lt;br /&gt;
'''Memory Bug Reduction:'''&lt;br /&gt;
&lt;br /&gt;
Memory related bugs such as reads from unitialised memory, read or writes using dangling pointers or &lt;br /&gt;
memory leaks are difficult to detect by code inspection because they may invoive different code fragments &lt;br /&gt;
and exist in differnt modules or source code files. Compilers are of little help becuase it fails to &lt;br /&gt;
disambiguate pointers. Hence, in practice memory bug detection relies on run time checkers that insert&lt;br /&gt;
monitor code to the application during testing. In CMPs, the program which detects the memory bugs can run&lt;br /&gt;
as a helper thread.&lt;br /&gt;
&lt;br /&gt;
Ex: Heapmon, a memory bug checker monitors application heap space to detect heap memory bugs. The memory &lt;br /&gt;
access events in the application thread are automatically forwarded to helper thread using appropriate &lt;br /&gt;
hardware mechanisms. Also the redundant and unnecessary  memory accessess are filtered out. Hence the helper&lt;br /&gt;
thread approach completely decouples bug monitoring from appication execution and the filtering mechanism reduces&lt;br /&gt;
bug - check frequency. Conseqently, HeapMon achieves a very low performance overhead.&lt;br /&gt;
&lt;br /&gt;
'''Slipstream approach for helper threads:'''&lt;br /&gt;
&lt;br /&gt;
Slipstream approach is developed at North Carolina State University. &lt;br /&gt;
Slipstream execution provides a simple means to use a second processor in a CMP to accelerate a single program.Slipstream execution involves running two redundant copies of the program. A significant number of dynamic instructions are speculatively removed from one of the program copies, without sacrificing its ability to make correct forward progress. The second program verifies the forward progress of the first and is also sped up in the process.  &lt;br /&gt;
&lt;br /&gt;
The speculative reduced program is called A-stream (Advanced Stream) and runs ahead of the unreduced program (main thread or Redundant stream).The R-stream exploits the A-stream to get an accurate picture of the future. For example, the A-stream &lt;br /&gt;
provides very accurate branch and value predictions. The predictions are more accurate than predictions made by conventional history-based predictors because they are produced by future program computation. The speculative A-stream occasionally (but&lt;br /&gt;
infrequently) goes astray. The R-stream serves as a checker of the speculative A-stream and redirects it when needed.&lt;br /&gt;
&lt;br /&gt;
Synchronization between an R-stream and its corresponding A-stream is required for two reasons.First, an A-stream that has taken a completely wrong control path and is generating useless data access predictions has to be corrcted. Second, limit how far the A-stream gets ahead, so that its prefetches are not issued so early that the prefetched lines are often replaced or invalidated in the L2 cache before the R-stream uses them. A single semaphore is required between each Astream/&lt;br /&gt;
R-stream pair to control their synchronization. It can be a shared hardware register, but any shared location that supports an atomic read-modify-write operation is sufficient. Using this semaphore, the following are controlled&amp;lt;br/&amp;gt;&lt;br /&gt;
(a) how many synchronization events the A-stream can skip without waiting for the Rstream&amp;lt;br/&amp;gt;&lt;br /&gt;
(b) whether the synchronization is local (involving only the companion R-stream) or global (involving all R-streams). The initial value of the semaphore indicates how many sessions the A-stream may proceed ahead of the Rstream. &amp;lt;br/&amp;gt;&lt;br /&gt;
This can be viewed as creating an initial pool of tokens that are consumed as the A-stream enters a new session. When there are no tokens, the Astream may not proceed. The R-stream issues tokens by incrementing the semaphore counter.Once the A thread gets the semaphore, A threads advances and gets past the R thread.&lt;br /&gt;
&lt;br /&gt;
'''Disadvantages of helper threads:'''&lt;br /&gt;
&lt;br /&gt;
A very tight synchronisation is needed between the main thread and the helper threads in oder to keep them the proper distance ahead of main thread. If the helper threads are too far ahead, then they will cause cache thrashing by prefetching data and then replaing it with subsequent prefetches beofre the main thread can even use it. If they are not far enough ahead, they might not be able to prefetch cache lines in time. &lt;br /&gt;
&lt;br /&gt;
Only certain types of single threaded programs can be sped up with these techniques. Most integer applications have regular data access patterns and hence there will be only few misses to eliminate. The applications with larger memory footprints are easily parellelisable and hence doesn't run on a single main thread. I floating point applications the data access patterns are fairly regular and hence can be prefetched easily using hardware or software prefetch mechanisms. Hence the range of programs that can be accelerated using helper threads is fairly limited.&lt;/div&gt;</summary>
		<author><name>Lreddy</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki2_helperThreads&amp;diff=10025</id>
		<title>CSC/ECE 506 Fall 2007/wiki2 helperThreads</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki2_helperThreads&amp;diff=10025"/>
		<updated>2007-11-28T17:25:20Z</updated>

		<summary type="html">&lt;p&gt;Lreddy: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;A helper thread is a thread that does some of the work of the main thread in advance of the main thread so that the main thread can work more quickly. The Olukotun text only scratches the surface on all the different ways that helper threads can be used. Survey these ways, making sure to include the Slipstream approach developed at NCSU.&lt;br /&gt;
&lt;br /&gt;
'''What is a helper thread?'''&lt;br /&gt;
&lt;br /&gt;
The potential of chip multiprocessors (CMPs) can be exploited in a better way if the applications are&lt;br /&gt;
divided into semi - independent parts, or threads that can operate simultaneously across the processors &lt;br /&gt;
within a system. The simplest way to use parallel threads within a CMP to increase the performance of a &lt;br /&gt;
single thread is to have helper threads. A 'helper' thread performs work on behalf of main thread in an &lt;br /&gt;
effort to accelerate its performance.&lt;br /&gt;
&lt;br /&gt;
'''Uses of helper threads'''&lt;br /&gt;
&lt;br /&gt;
'''Predicting branch at early stages:'''&lt;br /&gt;
&lt;br /&gt;
Helper threads are made up of program copies of the main thread stripped of all unessential parts &lt;br /&gt;
which are not of absolute necessity for the helper thread to achieve it tasks. Hence helper threads runs &lt;br /&gt;
ahead of main thread. Hence helper threads run ahead of main thread. Hence helper threads can do &lt;br /&gt;
computations that are necessary to decide the direction of the branch. This will inturn remove branch &lt;br /&gt;
mispredictions which may occur when branch predictions are used.&lt;br /&gt;
&lt;br /&gt;
'''Prefetching of Data:''' &lt;br /&gt;
&lt;br /&gt;
Since helper threads run ahead of main thread, they can predict the which data in memory is needed in&lt;br /&gt;
future by the main thread.they prefetch the data required by the main thread. The helper thread prefetches&lt;br /&gt;
the data and places it in the nearest cache accessible to the main thread. This avoids most of the L1 cache&lt;br /&gt;
misses that would have been encountered by the main thread had if helper thread was not present. As the &lt;br /&gt;
memory latency is reduced, the execution of main thread speeds up.&lt;br /&gt;
   &lt;br /&gt;
'''Memory Bug Reduction:'''&lt;br /&gt;
&lt;br /&gt;
Memory related bugs such as reads from unitialised memory, read or writes using dangling pointers or &lt;br /&gt;
memory leaks are difficult to detect by code inspection because they may invoive different code fragments &lt;br /&gt;
and exist in differnt modules or source code files. Compilers are of little help becuase it fails to &lt;br /&gt;
disambiguate pointers. Hence, in practice memory bug detection relies on run time checkers that insert&lt;br /&gt;
monitor code to the application during testing. In CMPs, the program which detects the memory bugs can run&lt;br /&gt;
as a helper thread.&lt;br /&gt;
&lt;br /&gt;
Ex: Heapmon, a memory bug checker monitors application heap space to detect heap memory bugs. The memory &lt;br /&gt;
access events in the application thread are automatically forwarded to helper thread using appropriate &lt;br /&gt;
hardware mechanisms. Also the redundant and unnecessary  memory accessess are filtered out. Hence the helper&lt;br /&gt;
thread approach completely decouples bug monitoring from appication execution and the filtering mechanism reduces&lt;br /&gt;
bug - check frequency. Conseqently, HeapMon achieves a very low performance overhead.&lt;br /&gt;
&lt;br /&gt;
'''Fault tolerance'''&lt;br /&gt;
&lt;br /&gt;
The helper thread is a subset of main program. This partial redundancy can be used for detecting and recovering&lt;br /&gt;
from transient hardware faults.&lt;br /&gt;
&lt;br /&gt;
'''Slipstream approach for helper threads:'''&lt;br /&gt;
&lt;br /&gt;
Slipstream approach is developed at North Carolina State University. &lt;br /&gt;
Slipstream execution provides a simple means to use a second processor in a CMP to accelerate a single program.Slipstream execution involves running two redundant copies of the program. A significant number of dynamic instructions are speculatively removed from one of the program copies, without sacrificing its ability to make correct forward progress. The second program verifies the forward progress of the first and is also sped up in the process.  &lt;br /&gt;
&lt;br /&gt;
The speculative reduced program is called A-stream (Advanced Stream) and runs ahead of the unreduced program (main thread or Redundant stream).The R-stream exploits the A-stream to get an accurate picture of the future. For example, the A-stream &lt;br /&gt;
provides very accurate branch and value predictions. The predictions are more accurate than predictions made by conventional history-based predictors because they are produced by future program computation. The speculative A-stream occasionally (but&lt;br /&gt;
infrequently) goes astray. The R-stream serves as a checker of the speculative A-stream and redirects it when needed.&lt;br /&gt;
&lt;br /&gt;
Synchronization between an R-stream and its corresponding A-stream is required for two reasons.First, an A-stream that has taken a completely wrong control path and is generating useless data access predictions has to be corrcted. Second, limit how far the A-stream gets ahead, so that its prefetches are not issued so early that the prefetched lines are often replaced or invalidated in the L2 cache before the R-stream uses them. A single semaphore is required between each Astream/&lt;br /&gt;
R-stream pair to control their synchronization. It can be a shared hardware register, but any shared location that supports an atomic read-modify-write operation is sufficient. Using this semaphore, the following are controlled&amp;lt;br/&amp;gt;&lt;br /&gt;
(a) how many synchronization events the A-stream can skip without waiting for the Rstream&amp;lt;br/&amp;gt;&lt;br /&gt;
(b) whether the synchronization is local (involving only the companion R-stream) or global (involving all R-streams). The initial value of the semaphore indicates how many sessions the A-stream may proceed ahead of the Rstream. &amp;lt;br/&amp;gt;&lt;br /&gt;
This can be viewed as creating an initial pool of tokens that are consumed as the A-stream enters a new session. When there are no tokens, the Astream may not proceed. The R-stream issues tokens by incrementing the semaphore counter.Once the A thread gets the semaphore, A threads advances and gets past the R thread.&lt;br /&gt;
&lt;br /&gt;
'''Disadvantages of helper threads:'''&lt;br /&gt;
&lt;br /&gt;
A very tight synchronisation is needed between the main thread and the helper threads in oder to keep them the proper distance ahead of main thread. If the helper threads are too far ahead, then they will cause cache thrashing by prefetching data and then replaing it with subsequent prefetches beofre the main thread can even use it. If they are not far enough ahead, they might not be able to prefetch cache lines in time. &lt;br /&gt;
&lt;br /&gt;
Only certain types of single threaded programs can be sped up with these techniques. Most integer applications have regular data access patterns and hence there will be only few misses to eliminate. The applications with larger memory footprints are easily parellelisable and hence doesn't run on a single main thread. I floating point applications the data access patterns are fairly regular and hence can be prefetched easily using hardware or software prefetch mechanisms. Hence the range of programs that can be accelerated using helper threads is fairly limited.&lt;/div&gt;</summary>
		<author><name>Lreddy</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki2_helperThreads&amp;diff=10024</id>
		<title>CSC/ECE 506 Fall 2007/wiki2 helperThreads</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki2_helperThreads&amp;diff=10024"/>
		<updated>2007-11-28T17:24:15Z</updated>

		<summary type="html">&lt;p&gt;Lreddy: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;A helper thread is a thread that does some of the work of the main thread in advance of the main thread so that the main thread can work more quickly. The Olukotun text only scratches the surface on all the different ways that helper threads can be used. Survey these ways, making sure to include the Slipstream approach developed at NCSU.&lt;br /&gt;
&lt;br /&gt;
'''What is a helper thread?'''&lt;br /&gt;
&lt;br /&gt;
The potential of chip multiprocessors (CMPs) can be exploited in a better way if the applications are&lt;br /&gt;
divided into semi - independent parts, or threads that can operate simultaneously across the processors &lt;br /&gt;
within a system. The simplest way to use parallel threads within a CMP to increase the performance of a &lt;br /&gt;
single thread is to have helper threads. A 'helper' thread performs work on behalf of main thread in an &lt;br /&gt;
effort to accelerate its performance.&lt;br /&gt;
&lt;br /&gt;
'''Uses of helper threads'''&lt;br /&gt;
&lt;br /&gt;
'''Predicting branch at early stages:'''&lt;br /&gt;
&lt;br /&gt;
Helper threads are made up of program copies of the main thread stripped of all unessential parts &lt;br /&gt;
which are not of absolute necessity for the helper thread to achieve it tasks. Hence helper threads runs &lt;br /&gt;
ahead of main thread. Hence helper threads run ahead of main thread. Hence helper threads can do &lt;br /&gt;
computations that are necessary to decide the direction of the branch. This will inturn remove branch &lt;br /&gt;
mispredictions which may occur when branch predictions are used.&lt;br /&gt;
&lt;br /&gt;
'''Prefetching of Data:''' &lt;br /&gt;
&lt;br /&gt;
Since helper threads run ahead of main thread, they can predict the which data in memory is needed in&lt;br /&gt;
future by the main thread.they prefetch the data required by the main thread. The helper thread prefetches&lt;br /&gt;
the data and places it in the nearest cache accessible to the main thread. This avoids most of the L1 cache&lt;br /&gt;
misses that would have been encountered by the main thread had if helper thread was not present. As the &lt;br /&gt;
memory latency is reduced, the execution of main thread speeds up.&lt;br /&gt;
   &lt;br /&gt;
'''Memory Bug Reduction:'''&lt;br /&gt;
&lt;br /&gt;
Memory related bugs such as reads from unitialised memory, read or writes using dangling pointers or &lt;br /&gt;
memory leaks are difficult to detect by code inspection because they may invoive different code fragments &lt;br /&gt;
and exist in differnt modules or source code files. Compilers are of little help becuase it fails to &lt;br /&gt;
disambiguate pointers. Hence, in practice memory bug detection relies on run time checkers that insert&lt;br /&gt;
monitor code to the application during testing. In CMPs, the program which detects the memory bugs can run&lt;br /&gt;
as a helper thread.&lt;br /&gt;
&lt;br /&gt;
Ex: Heapmon, a memory bug checker monitors application heap space to detect heap memory bugs. The memory &lt;br /&gt;
access events in the application thread are automatically forwarded to helper thread using appropriate &lt;br /&gt;
hardware mechanisms. Also the redundant and unnecessary  memory accessess are filtered out. Hence the helper&lt;br /&gt;
thread approach completely decouples bug monitoring from appication execution and the filtering mechanism reduces&lt;br /&gt;
bug - check frequency. Conseqently, HeapMon achieves a very low performance overhead.&lt;br /&gt;
&lt;br /&gt;
'''Fault tolerance'''&lt;br /&gt;
&lt;br /&gt;
The helper thread is a subset of main program. This partial redundancy can be used for detecting and recovering&lt;br /&gt;
from transient hardware faults.&lt;br /&gt;
&lt;br /&gt;
'''Slipstream approach for helper threads:'''&lt;br /&gt;
&lt;br /&gt;
Slipstream approach is developed at North Carolina State University. &lt;br /&gt;
Slipstream execution provides a simple means to use a second processor in a CMP to accelerate a single program.Slipstream execution involves running two redundant copies of the program. A significant number of dynamic instructions are speculatively removed from one of the program copies, without sacrificing its ability to make correct forward progress. The second program verifies the forward progress of the first and is also sped up in the process.  &lt;br /&gt;
&lt;br /&gt;
The speculative reduced program is called A-stream (Advanced Stream) and runs ahead of the unreduced program (main thread or Redundant stream).The R-stream exploits the A-stream to get an accurate picture of the future. For example, the A-stream &lt;br /&gt;
provides very accurate branch and value predictions. The predictions are more accurate than predictions made by conventional history-based predictors because they are produced by future program computation. The speculative A-stream occasionally (but&lt;br /&gt;
infrequently) goes astray. The R-stream serves as a checker of the speculative A-stream and redirects it when needed.&lt;br /&gt;
&lt;br /&gt;
Synchronization between an R-stream and its corresponding A-stream is required for two reasons.First, an A-stream that has taken a completely wrong control path and is generating useless data access predictions has to be corrcted. Second, limit how far the A-stream gets ahead, so that its prefetches are not issued so early that the prefetched lines are often replaced or invalidated in the L2 cache before the R-stream uses them. A single semaphore is required between each Astream/&lt;br /&gt;
R-stream pair to control their synchronization. It can be a shared hardware register, but any shared location that supports an atomic read-modify-write operation is sufficient. Using this semaphore, the following are controlled&lt;br /&gt;
(a) how many synchronization events the A-stream can skip without waiting for the Rstream&lt;br /&gt;
(b) whether the synchronization is local (involving only the companion R-stream) or global (involving all R-streams). The initial value of the semaphore indicates how many sessions the A-stream may proceed ahead of the Rstream. &lt;br /&gt;
This can be viewed as creating an initial pool of tokens that are consumed as the A-stream enters a new session. When there are no tokens, the Astream may not proceed. The R-stream issues tokens by incrementing the semaphore counter.Once the A thread gets the semaphore, A threads advances and gets past the R thread.&lt;br /&gt;
&lt;br /&gt;
'''Disadvantages of helper threads:'''&lt;br /&gt;
&lt;br /&gt;
A very tight synchronisation is needed between the main thread and the helper threads in oder to keep them the proper distance ahead of main thread. If the helper threads are too far ahead, then they will cause cache thrashing by prefetching data and then replaing it with subsequent prefetches beofre the main thread can even use it. If they are not far enough ahead, they might not be able to prefetch cache lines in time. &lt;br /&gt;
&lt;br /&gt;
Only certain types of single threaded programs can be sped up with these techniques. Most integer applications have regular data access patterns and hence there will be only few misses to eliminate. The applications with larger memory footprints are easily parellelisable and hence doesn't run on a single main thread. I floating point applications the data access patterns are fairly regular and hence can be prefetched easily using hardware or software prefetch mechanisms. Hence the range of programs that can be accelerated using helper threads is fairly limited.&lt;/div&gt;</summary>
		<author><name>Lreddy</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki2_helperThreads&amp;diff=10023</id>
		<title>CSC/ECE 506 Fall 2007/wiki2 helperThreads</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki2_helperThreads&amp;diff=10023"/>
		<updated>2007-11-28T17:23:01Z</updated>

		<summary type="html">&lt;p&gt;Lreddy: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;A helper thread is a thread that does some of the work of the main thread in advance of the main thread so that the main thread can work more quickly. The Olukotun text only scratches the surface on all the different ways that helper threads can be used. Survey these ways, making sure to include the Slipstream approach developed at NCSU.&lt;br /&gt;
&lt;br /&gt;
'''What is a helper thread?'''&lt;br /&gt;
&lt;br /&gt;
The potential of chip multiprocessors (CMPs) can be exploited in a better way if the applications are&lt;br /&gt;
divided into semi - independent parts, or threads that can operate simultaneously across the processors &lt;br /&gt;
within a system. The simplest way to use parallel threads within a CMP to increase the performance of a &lt;br /&gt;
single thread is to have helper threads. A 'helper' thread performs work on behalf of main thread in an &lt;br /&gt;
effort to accelerate its performance.&lt;br /&gt;
&lt;br /&gt;
'''Uses of helper threads'''&lt;br /&gt;
&lt;br /&gt;
'''Predicting branch at early stages:'''&lt;br /&gt;
&lt;br /&gt;
Helper threads are made up of program copies of the main thread stripped of all unessential parts &lt;br /&gt;
which are not of absolute necessity for the helper thread to achieve it tasks. Hence helper threads runs &lt;br /&gt;
ahead of main thread. Hence helper threads run ahead of main thread. Hence helper threads can do &lt;br /&gt;
computations that are necessary to decide the direction of the branch. This will inturn remove branch &lt;br /&gt;
mispredictions which may occur when branch predictions are used.&lt;br /&gt;
&lt;br /&gt;
'''Prefetching of Data:''' &lt;br /&gt;
Since helper threads run ahead of main thread, they can predict the which data in memory is needed in&lt;br /&gt;
future by the main thread.they prefetch the data required by the main thread. The helper thread prefetches&lt;br /&gt;
the data and places it in the nearest cache accessible to the main thread. This avoids most of the L1 cache&lt;br /&gt;
misses that would have been encountered by the main thread had if helper thread was not present. As the &lt;br /&gt;
memory latency is reduced, the execution of main thread speeds up.&lt;br /&gt;
   &lt;br /&gt;
'''Memory Bug Reduction:'''&lt;br /&gt;
Memory related bugs such as reads from unitialised memory, read or writes using dangling pointers or &lt;br /&gt;
memory leaks are difficult to detect by code inspection because they may invoive different code fragments &lt;br /&gt;
and exist in differnt modules or source code files. Compilers are of little help becuase it fails to &lt;br /&gt;
disambiguate pointers. Hence, in practice memory bug detection relies on run time checkers that insert&lt;br /&gt;
monitor code to the application during testing. In CMPs, the program which detects the memory bugs can run&lt;br /&gt;
as a helper thread.&lt;br /&gt;
&lt;br /&gt;
Ex: Heapmon, a memory bug checker monitors application heap space to detect heap memory bugs. The memory &lt;br /&gt;
access events in the application thread are automatically forwarded to helper thread using appropriate &lt;br /&gt;
hardware mechanisms. Also the redundant and unnecessary  memory accessess are filtered out. Hence the helper&lt;br /&gt;
thread approach completely decouples bug monitoring from appication execution and the filtering mechanism reduces&lt;br /&gt;
bug - check frequency. Conseqently, HeapMon achieves a very low performance overhead.&lt;br /&gt;
&lt;br /&gt;
'''Fault tolerance'''&lt;br /&gt;
The helper thread is a subset of main program. This partial redundancy can be used for detecting and recovering&lt;br /&gt;
from transient hardware faults.&lt;br /&gt;
&lt;br /&gt;
'''Slipstream approach for helper threads:'''&lt;br /&gt;
&lt;br /&gt;
Slipstream approach is developed at North Carolina State University. &lt;br /&gt;
Slipstream execution provides a simple means to use a second processor in a CMP to accelerate a single program.Slipstream execution involves running two redundant copies of the program. A significant number of dynamic instructions are speculatively removed from one of the program copies, without sacrificing its ability to make correct forward progress. The second program verifies the forward progress of the first and is also sped up in the process.  &lt;br /&gt;
&lt;br /&gt;
The speculative reduced program is called A-stream (Advanced Stream) and runs ahead of the unreduced program (main thread or Redundant stream).The R-stream exploits the A-stream to get an accurate picture of the future. For example, the A-stream &lt;br /&gt;
provides very accurate branch and value predictions. The predictions are more accurate than predictions made by conventional history-based predictors because they are produced by future program computation. The speculative A-stream occasionally (but&lt;br /&gt;
infrequently) goes astray. The R-stream serves as a checker of the speculative A-stream and redirects it when needed.&lt;br /&gt;
&lt;br /&gt;
Synchronization between an R-stream and its corresponding A-stream is required for two reasons.First, an A-stream that has taken a completely wrong control path and is generating useless data access predictions has to be corrcted. Second, limit how far the A-stream gets ahead, so that its prefetches are not issued so early that the prefetched lines are often replaced or invalidated in the L2 cache before the R-stream uses them. A single semaphore is required between each Astream/&lt;br /&gt;
R-stream pair to control their synchronization. It can be a shared hardware register, but any shared location that supports an atomic read-modify-write operation is sufficient. Using this semaphore, the following are controlled&lt;br /&gt;
(a) how many synchronization events the A-stream can skip without waiting for the Rstream&lt;br /&gt;
(b) whether the synchronization is local (involving only the companion R-stream) or global (involving all R-streams). The initial value of the semaphore indicates how many sessions the A-stream may proceed ahead of the Rstream. &lt;br /&gt;
This can be viewed as creating an initial pool of tokens that are consumed as the A-stream enters a new session. When there are no tokens, the Astream may not proceed. The R-stream issues tokens by incrementing the semaphore counter.Once the A thread gets the semaphore, A threads advances and gets past the R thread.&lt;br /&gt;
&lt;br /&gt;
'''Disadvantages of helper threads:'''&lt;br /&gt;
&lt;br /&gt;
A very tight synchronisation is needed between the main thread and the helper threads in oder to keep them the proper distance ahead of main thread. If the helper threads are too far ahead, then they will cause cache thrashing by prefetching data and then replaing it with subsequent prefetches beofre the main thread can even use it. If they are not far enough ahead, they might not be able to prefetch cache lines in time. &lt;br /&gt;
&lt;br /&gt;
Only certain types of single threaded programs can be sped up with these techniques. Most integer applications have regular data access patterns and hence there will be only few misses to eliminate. The applications with larger memory footprints are easily parellelisable and hence doesn't run on a single main thread. I floating point applications the data access patterns are fairly regular and hence can be prefetched easily using hardware or software prefetch mechanisms. Hence the range of programs that can be accelerated using helper threads is fairly limited.&lt;/div&gt;</summary>
		<author><name>Lreddy</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki2_helperThreads&amp;diff=10022</id>
		<title>CSC/ECE 506 Fall 2007/wiki2 helperThreads</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki2_helperThreads&amp;diff=10022"/>
		<updated>2007-11-28T17:22:10Z</updated>

		<summary type="html">&lt;p&gt;Lreddy: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;A helper thread is a thread that does some of the work of the main thread in advance of the main thread so that the main thread can work more quickly. The Olukotun text only scratches the surface on all the different ways that helper threads can be used. Survey these ways, making sure to include the Slipstream approach developed at NCSU.&lt;br /&gt;
&lt;br /&gt;
'''What is a helper thread?'''&lt;br /&gt;
&lt;br /&gt;
The potential of chip multiprocessors (CMPs) can be exploited in a better way if the applications are&lt;br /&gt;
divided into semi - independent parts, or threads that can operate simultaneously across the processors &lt;br /&gt;
within a system. The simplest way to use parallel threads within a CMP to increase the performance of a &lt;br /&gt;
single thread is to have helper threads. A 'helper' thread performs work on behalf of main thread in an &lt;br /&gt;
effort to accelerate its performance.&lt;br /&gt;
&lt;br /&gt;
'''Uses of helper threads'''&lt;br /&gt;
&lt;br /&gt;
'''Predicting branch at early stages'''&lt;br /&gt;
&lt;br /&gt;
Helper threads are made up of program copies of the main thread stripped of all unessential parts &lt;br /&gt;
which are not of absolute necessity for the helper thread to achieve it tasks. Hence helper threads runs &lt;br /&gt;
ahead of main thread. Hence helper threads run ahead of main thread. Hence helper threads can do &lt;br /&gt;
computations that are necessary to decide the direction of the branch. This will inturn remove branch &lt;br /&gt;
mispredictions which may occur when branch predictions are used.&lt;br /&gt;
&lt;br /&gt;
'''Prefetching of Data''' &lt;br /&gt;
Since helper threads run ahead of main thread, they can predict the which data in memory is needed in&lt;br /&gt;
future by the main thread.they prefetch the data required by the main thread. The helper thread prefetches&lt;br /&gt;
the data and places it in the nearest cache accessible to the main thread. This avoids most of the L1 cache&lt;br /&gt;
misses that would have been encountered by the main thread had if helper thread was not present. As the &lt;br /&gt;
memory latency is reduced, the execution of main thread speeds up.&lt;br /&gt;
   &lt;br /&gt;
'''Memory Bug Reduction'''&lt;br /&gt;
Memory related bugs such as reads from unitialised memory, read or writes using dangling pointers or &lt;br /&gt;
memory leaks are difficult to detect by code inspection because they may invoive different code fragments &lt;br /&gt;
and exist in differnt modules or source code files. Compilers are of little help becuase it fails to &lt;br /&gt;
disambiguate pointers. Hence, in practice memory bug detection relies on run time checkers that insert&lt;br /&gt;
monitor code to the application during testing. In CMPs, the program which detects the memory bugs can run&lt;br /&gt;
as a helper thread.&lt;br /&gt;
&lt;br /&gt;
Ex: Heapmon, a memory bug checker monitors application heap space to detect heap memory bugs. The memory &lt;br /&gt;
access events in the application thread are automatically forwarded to helper thread using appropriate &lt;br /&gt;
hardware mechanisms. Also the redundant and unnecessary  memory accessess are filtered out. Hence the helper&lt;br /&gt;
thread approach completely decouples bug monitoring from appication execution and the filtering mechanism reduces&lt;br /&gt;
bug - check frequency. Conseqently, HeapMon achieves a very low performance overhead.&lt;br /&gt;
&lt;br /&gt;
'''Fault tolerance'''&lt;br /&gt;
The helper thread is a subset of main program. This partial redundancy can be used for detecting and recovering&lt;br /&gt;
from transient hardware faults.&lt;br /&gt;
&lt;br /&gt;
'''Slipstream approach for helper threads'''&lt;br /&gt;
&lt;br /&gt;
Slipstream approach is developed at North Carolina State University. &lt;br /&gt;
Slipstream execution provides a simple means to use a second processor in a CMP to accelerate a single program.Slipstream execution involves running two redundant copies of the program. A significant number of dynamic instructions are speculatively removed from one of the program copies, without sacrificing its ability to make correct forward progress. The second program verifies the forward progress of the first and is also sped up in the process.  &lt;br /&gt;
&lt;br /&gt;
The speculative reduced program is called A-stream (Advanced Stream) and runs ahead of the unreduced program (main thread or Redundant stream).The R-stream exploits the A-stream to get an accurate picture of the future. For example, the A-stream &lt;br /&gt;
provides very accurate branch and value predictions. The predictions are more accurate than predictions made by conventional history-based predictors because they are produced by future program computation. The speculative A-stream occasionally (but&lt;br /&gt;
infrequently) goes astray. The R-stream serves as a checker of the speculative A-stream and redirects it when needed.&lt;br /&gt;
&lt;br /&gt;
Synchronization between an R-stream and its corresponding A-stream is required for two reasons.First, an A-stream that has taken a completely wrong control path and is generating useless data access predictions has to be corrcted. Second, limit how far the A-stream gets ahead, so that its prefetches are not issued so early that the prefetched lines are often replaced or invalidated in the L2 cache before the R-stream uses them. A single semaphore is required between each Astream/&lt;br /&gt;
R-stream pair to control their synchronization. It can be a shared hardware register, but any shared location that supports an atomic read-modify-write operation is sufficient. Using this semaphore, the following are controlled&lt;br /&gt;
(a) how many synchronization events the A-stream can skip without waiting for the Rstream&lt;br /&gt;
(b) whether the synchronization is local (involving only the companion R-stream) or global (involving all R-streams). The initial value of the semaphore indicates how many sessions the A-stream may proceed ahead of the Rstream. &lt;br /&gt;
This can be viewed as creating an initial pool of tokens that are consumed as the A-stream enters a new session. When there are no tokens, the Astream may not proceed. The R-stream issues tokens by incrementing the semaphore counter.Once the A thread gets the semaphore, A threads advances and gets past the R thread.&lt;br /&gt;
&lt;br /&gt;
'''Disadvantages of helper threads'''&lt;br /&gt;
&lt;br /&gt;
A very tight synchronisation is needed between the main thread and the helper threads in oder to keep them the proper distance ahead of main thread. If the helper threads are too far ahead, then they will cause cache thrashing by prefetching data and then replaing it with subsequent prefetches beofre the main thread can even use it. If they are not far enough ahead, they might not be able to prefetch cache lines in time. &lt;br /&gt;
&lt;br /&gt;
Only certain types of single threaded programs can be sped up with these techniques. Most integer applications have regular data access patterns and hence there will be only few misses to eliminate. The applications with larger memory footprints are easily parellelisable and hence doesn't run on a single main thread. I floating point applications the data access patterns are fairly regular and hence can be prefetched easily using hardware or software prefetch mechanisms. Hence the range of programs that can be accelerated using helper threads is fairly limited.&lt;/div&gt;</summary>
		<author><name>Lreddy</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki2_helperThreads&amp;diff=10020</id>
		<title>CSC/ECE 506 Fall 2007/wiki2 helperThreads</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki2_helperThreads&amp;diff=10020"/>
		<updated>2007-11-28T17:20:07Z</updated>

		<summary type="html">&lt;p&gt;Lreddy: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;A helper thread is a thread that does some of the work of the main thread in advance of the main thread so that the main thread can work more quickly. The Olukotun text only scratches the surface on all the different ways that helper threads can be used. Survey these ways, making sure to include the Slipstream approach developed at NCSU.&lt;br /&gt;
&lt;br /&gt;
What is a helper thread?&lt;br /&gt;
&lt;br /&gt;
The potential of chip multiprocessors (CMPs) can be exploited in a better way if the applications are&lt;br /&gt;
divided into semi - independent parts, or threads that can operate simultaneously across the processors &lt;br /&gt;
within a system. The simplest way to use parallel threads within a CMP to increase the performance of a &lt;br /&gt;
single thread is to have helper threads. A 'helper' thread performs work on behalf of main thread in an &lt;br /&gt;
effort to accelerate its performance.&lt;br /&gt;
&lt;br /&gt;
Uses of helper threads&lt;br /&gt;
&lt;br /&gt;
Predicting branch at early stages&lt;br /&gt;
&lt;br /&gt;
Helper threads are made up of program copies of the main thread stripped of all unessential parts &lt;br /&gt;
which are not of absolute necessity for the helper thread to achieve it tasks. Hence helper threads runs &lt;br /&gt;
ahead of main thread. Hence helper threads run ahead of main thread. Hence helper threads can do &lt;br /&gt;
computations that are necessary to decide the direction of the branch. This will inturn remove branch &lt;br /&gt;
mispredictions which may occur when branch predictions are used.&lt;br /&gt;
&lt;br /&gt;
Prefetching of Data &lt;br /&gt;
Since helper threads run ahead of main thread, they can predict the which data in memory is needed in&lt;br /&gt;
future by the main thread.they prefetch the data required by the main thread. The helper thread prefetches&lt;br /&gt;
the data and places it in the nearest cache accessible to the main thread. This avoids most of the L1 cache&lt;br /&gt;
misses that would have been encountered by the main thread had if helper thread was not present. As the &lt;br /&gt;
memory latency is reduced, the execution of main thread speeds up.&lt;br /&gt;
   &lt;br /&gt;
Memory Bug Reduction:&lt;br /&gt;
Memory related bugs such as reads from unitialised memory, read or writes using dangling pointers or &lt;br /&gt;
memory leaks are difficult to detect by code inspection because they may invoive different code fragments &lt;br /&gt;
and exist in differnt modules or source code files. Compilers are of little help becuase it fails to &lt;br /&gt;
disambiguate pointers. Hence, in practice memory bug detection relies on run time checkers that insert&lt;br /&gt;
monitor code to the application during testing. In CMPs, the program which detects the memory bugs can run&lt;br /&gt;
as a helper thread.&lt;br /&gt;
&lt;br /&gt;
Ex: Heapmon, a memory bug checker monitors application heap space to detect heap memory bugs. The memory &lt;br /&gt;
access events in the application thread are automatically forwarded to helper thread using appropriate &lt;br /&gt;
hardware mechanisms. Also the redundant and unnecessary  memory accessess are filtered out. Hence the helper&lt;br /&gt;
thread approach completely decouples bug monitoring from appication execution and the filtering mechanism reduces&lt;br /&gt;
bug - check frequency. Conseqently, HeapMon achieves a very low performance overhead.&lt;br /&gt;
&lt;br /&gt;
Fault tolerance:&lt;br /&gt;
The helper thread is a subset of main program. This partial redundancy can be used for detecting and recovering&lt;br /&gt;
from transient hardware faults.&lt;br /&gt;
&lt;br /&gt;
Slipstream approach for helper threads:&lt;br /&gt;
&lt;br /&gt;
Slipstream approach is developed at North Carolina State University. &lt;br /&gt;
Slipstream execution provides a simple means to use a second processor in a CMP to accelerate a single program.Slipstream execution involves running two redundant copies of the program. A significant number of dynamic instructions are speculatively removed from one of the program copies, without sacrificing its ability to make correct forward progress. The second program verifies the forward progress of the first and is also sped up in the process.  &lt;br /&gt;
&lt;br /&gt;
The speculative reduced program is called A-stream (Advanced Stream) and runs ahead of the unreduced program (main thread or Redundant stream).The R-stream exploits the A-stream to get an accurate picture of the future. For example, the A-stream &lt;br /&gt;
provides very accurate branch and value predictions. The predictions are more accurate than predictions made by conventional history-based predictors because they are produced by future program computation. The speculative A-stream occasionally (but&lt;br /&gt;
infrequently) goes astray. The R-stream serves as a checker of the speculative A-stream and redirects it when needed.&lt;br /&gt;
&lt;br /&gt;
Synchronization between an R-stream and its corresponding A-stream is required for two reasons.First, an A-stream that has taken a completely wrong control path and is generating useless data access predictions has to be corrcted. Second, limit how far the A-stream gets ahead, so that its prefetches are not issued so early that the prefetched lines are often replaced or invalidated in the L2 cache before the R-stream uses them. A single semaphore is required between each Astream/&lt;br /&gt;
R-stream pair to control their synchronization. It can be a shared hardware register, but any shared location that supports an atomic read-modify-write operation is sufficient. Using this semaphore, the following are controlled&lt;br /&gt;
(a) how many synchronization events the A-stream can skip without waiting for the Rstream&lt;br /&gt;
(b) whether the synchronization is local (involving only the companion R-stream) or global (involving all R-streams). The initial value of the semaphore indicates how many sessions the A-stream may proceed ahead of the Rstream. &lt;br /&gt;
This can be viewed as creating an initial pool of tokens that are consumed as the A-stream enters a new session. When there are no tokens, the Astream may not proceed. The R-stream issues tokens by incrementing the semaphore counter.Once the A thread gets the semaphore, A threads advances and gets past the R thread.&lt;br /&gt;
&lt;br /&gt;
Disadvantages of helper threads:&lt;br /&gt;
&lt;br /&gt;
A very tight synchronisation is needed between the main thread and the helper threads in oder to keep them the proper distance ahead of main thread. If the helper threads are too far ahead, then they will cause cache thrashing by prefetching data and then replaing it with subsequent prefetches beofre the main thread can even use it. If they are not far enough ahead, they might not be able to prefetch cache lines in time. &lt;br /&gt;
&lt;br /&gt;
Only certain types of single threaded programs can be sped up with these techniques. Most integer applications have regular data access patterns and hence there will be only few misses to eliminate. The applications with larger memory footprints are easily parellelisable and hence doesn't run on a single main thread. I floating point applications the data access patterns are fairly regular and hence can be prefetched easily using hardware or software prefetch mechanisms. Hence the range of programs that can be accelerated using helper threads is fairly limited.&lt;/div&gt;</summary>
		<author><name>Lreddy</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki2_helperThreads&amp;diff=10012</id>
		<title>CSC/ECE 506 Fall 2007/wiki2 helperThreads</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki2_helperThreads&amp;diff=10012"/>
		<updated>2007-11-28T16:08:47Z</updated>

		<summary type="html">&lt;p&gt;Lreddy: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;A helper thread is a thread that does some of the work of the main thread in advance of the main thread so that the main thread can work more quickly. The Olukotun text only scratches the surface on all the different ways that helper threads can be used. Survey these ways, making sure to include the Slipstream approach developed at NCSU.&lt;br /&gt;
&lt;br /&gt;
What is a helper thread?&lt;br /&gt;
&lt;br /&gt;
The potential of chip multiprocessors (CMPs) can be exploited in a better way if the applications are&lt;br /&gt;
divided into semi - independent parts, or threads that can operate simultaneously across the processors &lt;br /&gt;
within a system. The simplest way to use parallel threads within a CMP to increase the performance of a &lt;br /&gt;
single thread is to have helper threads. A 'helper' thread performs work on behalf of main thread in an &lt;br /&gt;
effort to accelerate its performance.&lt;br /&gt;
&lt;br /&gt;
Uses of helper threads&lt;br /&gt;
&lt;br /&gt;
Predicting branch at early stages&lt;br /&gt;
&lt;br /&gt;
Helper threads are made up of program copies of the main thread stripped of all unessential parts &lt;br /&gt;
which are not of absolute necessity for the helper thread to achieve it tasks. Hence helper threads runs &lt;br /&gt;
ahead of main thread. Hence helper threads run ahead of main thread. Hence helper threads can do &lt;br /&gt;
computations that are necessary to decide the direction of the branch. This will inturn remove branch &lt;br /&gt;
mispredictions which may occur when branch predictions are used.&lt;br /&gt;
&lt;br /&gt;
Prefetching of Data &lt;br /&gt;
Since helper threads run ahead of main thread, they can predict the which data in memory is needed in&lt;br /&gt;
future by the main thread.they prefetch the data required by the main thread. The helper thread prefetches&lt;br /&gt;
the data and places it in the nearest cache accessible to the main thread. This avoids most of the L1 cache&lt;br /&gt;
misses that would have been encountered by the main thread had if helper thread was not present. As the &lt;br /&gt;
memory latency is reduced, the execution of main thread speeds up.&lt;br /&gt;
   &lt;br /&gt;
Memory Bug Reduction:&lt;br /&gt;
Memory related bugs such as reads from unitialised memory, read or writes using dangling pointers or &lt;br /&gt;
memory leaks are difficult to detect by code inspection because they may invoive different code fragments &lt;br /&gt;
and exist in differnt modules or source code files. Compilers are of little help becuase it fails to &lt;br /&gt;
disambiguate pointers. Hence, in practice memory bug detection relies on run time checkers that insert&lt;br /&gt;
monitor code to the application during testing. In CMPs, the program which detects the memory bugs can run&lt;br /&gt;
as a helper thread.&lt;br /&gt;
&lt;br /&gt;
Ex: Heapmon, a memory bug checker monitors application heap space to detect heap memory bugs. The memory &lt;br /&gt;
access events in the application thread are automatically forwarded to helper thread using appropriate &lt;br /&gt;
hardware mechanisms. Also the redundant and unnecessary  memory accessess are filtered out. Hence the helper&lt;br /&gt;
thread approach completely decouples bug monitoring from appication execution and the filtering mechanism reduces&lt;br /&gt;
bug - check frequency. Conseqently, HeapMon achieves a very low performance overhead.&lt;br /&gt;
&lt;br /&gt;
Fault tolerance:&lt;br /&gt;
The helper thread is a subset of main program. This partial redundancy can be used for detecting and recovering&lt;br /&gt;
from transient hardware faults.&lt;br /&gt;
&lt;br /&gt;
Slipstream approach for helper threads:&lt;br /&gt;
&lt;br /&gt;
Slipstream approach is developed at North Carolina State University. &lt;br /&gt;
Slipstream execution provides a simple means to use a second processor in a CMP to accelerate a single program.Slipstream execution involves running two redundant copies of the program. A significant number of dynamic instructions are speculatively removed from one of the program copies, without sacrificing its ability to make correct forward progress. The second program verifies the forward progress of the first and is also sped up in the process.  &lt;br /&gt;
&lt;br /&gt;
The speculative reduced program is called A-stream (Advanced Stream) and runs ahead of the unreduced program (main thread or Redundant stream).The R-stream exploits the A-stream to get an accurate picture of the future. For example, the A-stream &lt;br /&gt;
provides very accurate branch and value predictions. The predictions are more accurate than predictions made by conventional history-based predictors because they are produced by future program computation. The speculative A-stream occasionally (but&lt;br /&gt;
infrequently) goes astray. The R-stream serves as a checker of the speculative A-stream and redirects it when needed.&lt;br /&gt;
&lt;br /&gt;
Synchronization between an R-stream and its corresponding A-stream is required for two reasons.First, we must correct an A-stream that has taken a completely wrong control path and is generating useless data access predictions. Second, we want to limit how far the A-stream gets ahead, so that its prefetches are not issued so early that the prefetched lines are often replaced or invalidated in the L2 cache before the R-stream uses them. We require a single semaphore between each Astream/&lt;br /&gt;
R-stream pair to control their synchronization. For our experiments, we have assumed a shared hardware register, but any shared location that supports an atomic read-modify-write operation is sufficient. Using this semaphore, we control (a) how many synchronization events the A-stream can skip without waiting for the Rstream and (b) whether the synchronization is local (involving only the companion R-stream) or global (involving all R-streams). The initial value of the semaphore indicates how&lt;br /&gt;
many sessions the A-stream may proceed ahead of the Rstream. This can be viewed as creating an initial pool of tokens that are consumed as the A-stream enters a new session (Figure 3). When there are no tokens, the Astream may not proceed. The R-stream issues tokens by incrementing the semaphore counter.Once the A thread gets the semaphore, A threads advances and gets past the R thread.&lt;br /&gt;
&lt;br /&gt;
Disadvantages of helper threads:&lt;br /&gt;
&lt;br /&gt;
A very tight synchronisation is needed between the main thread and the helper threads in oder to keep them the proper distance ahead of main thread. If the helper threads are too far ahead, then they will cause cache thrashing by prefetching data and then replaing it with subsequent prefetches beofre the main thread can even use it. If they are not far enough ahead, they might not be able to prefetch cache lines in time. &lt;br /&gt;
&lt;br /&gt;
Only certain types of single threaded programs can be sped up with these techniques. Most integer applications have regular data access patterns and hence there will be only few misses to eliminate. The applications with larger memory footprints are easily parellelisable and hence doesn't run on a single main thread. I floating point applications the data access patterns are fairly regular and hence can be prefetched easily using hardware or software prefetch mechanisms. Hence the range of programs that can be accelerated using helper threads is fairly limited.&lt;/div&gt;</summary>
		<author><name>Lreddy</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki2_helperThreads&amp;diff=10011</id>
		<title>CSC/ECE 506 Fall 2007/wiki2 helperThreads</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki2_helperThreads&amp;diff=10011"/>
		<updated>2007-11-28T16:07:12Z</updated>

		<summary type="html">&lt;p&gt;Lreddy: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;A helper thread is a thread that does some of the work of the main thread in advance of the main thread so that the main thread can work more quickly. The Olukotun text only scratches the surface on all the different ways that helper threads can be used. Survey these ways, making sure to include the Slipstream approach developed at NCSU.&lt;br /&gt;
&lt;br /&gt;
What is a helper thread?&lt;br /&gt;
&lt;br /&gt;
The potential of chip multiprocessors (CMPs) can be exploited in a better way if the applications are&lt;br /&gt;
divided into semi - independent parts, or threads that can operate simultaneously across the processors &lt;br /&gt;
within a system. The simplest way to use parallel threads within a CMP to increase the performance of a &lt;br /&gt;
single thread is to have helper threads. A 'helper' thread performs work on behalf of main thread in an &lt;br /&gt;
effort to accelerate its performance.&lt;br /&gt;
&lt;br /&gt;
Uses of helper threads&lt;br /&gt;
&lt;br /&gt;
Predicting branch at early stages&lt;br /&gt;
&lt;br /&gt;
Helper threads are made up of program copies of the main thread stripped of all unessential parts &lt;br /&gt;
which are not of absolute necessity for the helper thread to achieve it tasks. Hence helper threads runs &lt;br /&gt;
ahead of main thread. Hence helper threads run ahead of main thread. Hence helper threads can do &lt;br /&gt;
computations that are necessary to decide the direction of the branch. This will inturn remove branch &lt;br /&gt;
mispredictions which may occur when branch predictions are used.&lt;br /&gt;
&lt;br /&gt;
Prefetching of Data &lt;br /&gt;
Since helper threads run ahead of main thread, they can predict the which data in memory is needed in&lt;br /&gt;
future by the main thread.they prefetch the data required by the main thread. The helper thread prefetches&lt;br /&gt;
the data and places it in the nearest cache accessible to the main thread. This avoids most of the L1 cache&lt;br /&gt;
misses that would have been encountered by the main thread had if helper thread was not present. As the &lt;br /&gt;
memory latency is reduced, the execution of main thread speeds up.&lt;br /&gt;
   &lt;br /&gt;
Memory Bug Reduction:&lt;br /&gt;
Memory related bugs such as reads from unitialised memory, read or writes using dangling pointers or &lt;br /&gt;
memory leaks are difficult to detect by code inspection because they may invoive different code fragments &lt;br /&gt;
and exist in differnt modules or source code files. Compilers are of little help becuase it fails to &lt;br /&gt;
disambiguate pointers. Hence, in practice memory bug detection relies on run time checkers that insert&lt;br /&gt;
monitor code to the application during testing. In CMPs, the program which detects the memory bugs can run&lt;br /&gt;
as a helper thread.&lt;br /&gt;
&lt;br /&gt;
Ex: Heapmon, a memory bug checker monitors application heap space to detect heap memory bugs. The memory &lt;br /&gt;
access events in the application thread are automatically forwarded to helper thread using appropriate &lt;br /&gt;
hardware mechanisms. Also the redundant and unnecessary  memory accessess are filtered out. Hence the helper&lt;br /&gt;
thread approach completely decouples bug monitoring from appication execution and the filtering mechanism reduces&lt;br /&gt;
bug - check frequency. Conseqently, HeapMon achieves a very low performance overhead.&lt;br /&gt;
&lt;br /&gt;
Fault tolerance:&lt;br /&gt;
The helper thread is a subset of main program. This partial redundancy can be used for detecting and recovering&lt;br /&gt;
from transient hardware faults.&lt;br /&gt;
&lt;br /&gt;
Slipstream approach for helper threads:&lt;br /&gt;
&lt;br /&gt;
Slipstream approach is developed at North Carolina State University. &lt;br /&gt;
Slipstream execution provides a simple means to use a second processor in a CMP to accelerate a single program.Slipstream execution involves running two redundant copies of the program. A significant number of dynamic instructions are speculatively removed from one of the program copies, without sacrificing its ability to make correct forward progress. The second program verifies the forward progress of the first and is also sped up in the process.  &lt;br /&gt;
&lt;br /&gt;
The speculative reduced program is called A-stream (Advanced Stream) and runs ahead of the unreduced program (main thread or Redundant stream).The R-stream exploits the A-stream to get an accurate picture of the future. For example, the A-stream &lt;br /&gt;
provides very accurate branch and value predictions. The predictions are more accurate than predictions made by conventional history-based predictors because they are produced by future program computation. The speculative A-stream occasionally (but&lt;br /&gt;
infrequently) goes astray. The R-stream serves as a checker of the speculative A-stream and redirects it when needed.&lt;br /&gt;
&lt;br /&gt;
Synchronization between an R-stream and its corresponding A-stream is required for two reasons.First, we must correct an A-stream that has taken a completely wrong control path and is generating useless data access predictions. Second, we want to limit how far the A-stream gets ahead, so that its prefetches are not issued so early that the prefetched lines are often replaced or invalidated in the L2 cache before the R-stream uses them. We require a single semaphore between each Astream/&lt;br /&gt;
R-stream pair to control their synchronization. For our experiments, we have assumed a shared hardware register, but any shared location that supports an atomic read-modify-write operation is sufficient. Using this semaphore, we control (a) how many synchronization events the A-stream can skip without waiting for the Rstream and (b) whether the synchronization is local (involving only the companion R-stream) or global (involving all R-streams). The initial value of the semaphore indicates how&lt;br /&gt;
many sessions the A-stream may proceed ahead of the Rstream. This can be viewed as creating an initial pool of tokens that are consumed as the A-stream enters a new session (Figure 3). When there are no tokens, the Astream may not proceed. The R-stream issues tokens by incrementing the semaphore counter.&lt;br /&gt;
&lt;br /&gt;
Disadvantages of helper threads:&lt;br /&gt;
&lt;br /&gt;
A very tight synchronisation is needed between the main thread and the helper threads in oder to keep them the proper distance ahead of main thread. If the helper threads are too far ahead, then they will cause cache thrashing by prefetching data and then replaing it with subsequent prefetches beofre the main thread can even use it. If they are not far enough ahead, they might not be able to prefetch cache lines in time. &lt;br /&gt;
&lt;br /&gt;
Only certain types of single threaded programs can be sped up with these techniques. Most integer applications have regular data access patterns and hence there will be only few misses to eliminate. The applications with larger memory footprints are easily parellelisable and hence doesn't run on a single main thread. I floating point applications the data access patterns are fairly regular and hence can be prefetched easily using hardware or software prefetch mechanisms. Hence the range of programs that can be accelerated using helper threads is fairly limited.&lt;/div&gt;</summary>
		<author><name>Lreddy</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki2_helperThreads&amp;diff=10007</id>
		<title>CSC/ECE 506 Fall 2007/wiki2 helperThreads</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki2_helperThreads&amp;diff=10007"/>
		<updated>2007-11-28T15:54:40Z</updated>

		<summary type="html">&lt;p&gt;Lreddy: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;A helper thread is a thread that does some of the work of the main thread in advance of the main thread so that the main thread can work more quickly. The Olukotun text only scratches the surface on all the different ways that helper threads can be used. Survey these ways, making sure to include the Slipstream approach developed at NCSU.&lt;br /&gt;
&lt;br /&gt;
What is a helper thread?&lt;br /&gt;
&lt;br /&gt;
The potential of chip multiprocessors (CMPs) can be exploited in a better way if the applications are&lt;br /&gt;
divided into semi - independent parts, or threads that can operate simultaneously across the processors &lt;br /&gt;
within a system. The simplest way to use parallel threads within a CMP to increase the performance of a &lt;br /&gt;
single thread is to have helper threads. A 'helper' thread performs work on behalf of main thread in an &lt;br /&gt;
effort to accelerate its performance.&lt;br /&gt;
&lt;br /&gt;
Uses of helper threads&lt;br /&gt;
&lt;br /&gt;
Predicting branch at early stages&lt;br /&gt;
&lt;br /&gt;
Helper threads are made up of program copies of the main thread stripped of all unessential parts &lt;br /&gt;
which are not of absolute necessity for the helper thread to achieve it tasks. Hence helper threads runs &lt;br /&gt;
ahead of main thread. Hence helper threads run ahead of main thread. Hence helper threads can do &lt;br /&gt;
computations that are necessary to decide the direction of the branch. This will inturn remove branch &lt;br /&gt;
mispredictions which may occur when branch predictions are used.&lt;br /&gt;
&lt;br /&gt;
Prefetching of Data &lt;br /&gt;
Since helper threads run ahead of main thread, they can predict the which data in memory is needed in&lt;br /&gt;
future by the main thread.they prefetch the data required by the main thread. The helper thread prefetches&lt;br /&gt;
the data and places it in the nearest cache accessible to the main thread. This avoids most of the L1 cache&lt;br /&gt;
misses that would have been encountered by the main thread had if helper thread was not present. As the &lt;br /&gt;
memory latency is reduced, the execution of main thread speeds up.&lt;br /&gt;
   &lt;br /&gt;
Memory Bug Reduction:&lt;br /&gt;
Memory related bugs such as reads from unitialised memory, read or writes using dangling pointers or &lt;br /&gt;
memory leaks are difficult to detect by code inspection because they may invoive different code fragments &lt;br /&gt;
and exist in differnt modules or source code files. Compilers are of little help becuase it fails to &lt;br /&gt;
disambiguate pointers. Hence, in practice memory bug detection relies on run time checkers that insert&lt;br /&gt;
monitor code to the application during testing. In CMPs, the program which detects the memory bugs can run&lt;br /&gt;
as a helper thread.&lt;br /&gt;
&lt;br /&gt;
Ex: Heapmon, a memory bug checker monitors application heap space to detect heap memory bugs. The memory &lt;br /&gt;
access events in the application thread are automatically forwarded to helper thread using appropriate &lt;br /&gt;
hardware mechanisms. Also the redundant and unnecessary  memory accessess are filtered out. Hence the helper&lt;br /&gt;
thread approach completely decouples bug monitoring from appication execution and the filtering mechanism reduces&lt;br /&gt;
bug - check frequency. Conseqently, HeapMon achieves a very low performance overhead.&lt;br /&gt;
&lt;br /&gt;
Fault tolerance:&lt;br /&gt;
The helper thread is a subset of main program. This partial redundancy can be used for detecting and recovering&lt;br /&gt;
from transient hardware faults.&lt;br /&gt;
&lt;br /&gt;
Slipstream approach for helper threads:&lt;br /&gt;
&lt;br /&gt;
Slipstream approach is developed at North Carolina State University. &lt;br /&gt;
Slipstream execution provides a simple means to use a second processor in a CMP to accelerate a single program.Slipstream execution involves running two redundant copies of the program. A significant number of dynamic instructions are speculatively removed from one of the program copies, without sacrificing its ability to make correct forward progress. The second program verifies the forward progress of the first and is also sped up in the process.  &lt;br /&gt;
&lt;br /&gt;
The speculative reduced program is called A-stream (Advanced Stream) and runs ahead of the unreduced program (main thread or Redundant stream).The R-stream exploits the A-stream to get an accurate picture of the future. For example, the A-stream &lt;br /&gt;
provides very accurate branch and value predictions. The predictions are more accurate than predictions made by conventional history-based predictors because they are produced by future program computation. The speculative A-stream occasionally (but&lt;br /&gt;
infrequently) goes astray. The R-stream serves as a checker of the speculative A-stream and redirects it when needed.&lt;br /&gt;
&lt;br /&gt;
Synchronization between an R-stream and its corresponding A-stream is required for two reasons.First, we must correct an A-stream that has taken a completely wrong control path and is generating useless data access predictions. Second, we want to limit how far the A-stream gets ahead, so that its prefetches are not issued so early that the prefetched lines are often replaced or invalidated in the L2 cache before the R-stream uses them.&lt;br /&gt;
&lt;br /&gt;
Disadvantages of helper threads:&lt;br /&gt;
&lt;br /&gt;
A very tight synchronisation is needed between the main thread and the helper threads in oder to keep them the proper distance ahead of main thread. If the helper threads are too far ahead, then they will cause cache thrashing by prefetching data and then replaing it with subsequent prefetches beofre the main thread can even use it. If they are not far enough ahead, they might not be able to prefetch cache lines in time. &lt;br /&gt;
&lt;br /&gt;
Only certain types of single threaded programs can be sped up with these techniques. Most integer applications have regular data access patterns and hence there will be only few misses to eliminate. The applications with larger memory footprints are easily parellelisable and hence doesn't run on a single main thread. I floating point applications the data access patterns are fairly regular and hence can be prefetched easily using hardware or software prefetch mechanisms. Hence the range of programs that can be accelerated using helper threads is fairly limited.&lt;/div&gt;</summary>
		<author><name>Lreddy</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki2_helperThreads&amp;diff=10006</id>
		<title>CSC/ECE 506 Fall 2007/wiki2 helperThreads</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki2_helperThreads&amp;diff=10006"/>
		<updated>2007-11-28T15:47:42Z</updated>

		<summary type="html">&lt;p&gt;Lreddy: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;A helper thread is a thread that does some of the work of the main thread in advance of the main thread so that the main thread can work more quickly. The Olukotun text only scratches the surface on all the different ways that helper threads can be used. Survey these ways, making sure to include the Slipstream approach developed at NCSU.&lt;br /&gt;
&lt;br /&gt;
What is a helper thread?&lt;br /&gt;
&lt;br /&gt;
The potential of chip multiprocessors (CMPs) can be exploited in a better way if the applications are&lt;br /&gt;
divided into semi - independent parts, or threads that can operate simultaneously across the processors &lt;br /&gt;
within a system. The simplest way to use parallel threads within a CMP to increase the performance of a &lt;br /&gt;
single thread is to have helper threads. A 'helper' thread performs work on behalf of main thread in an &lt;br /&gt;
effort to accelerate its performance.&lt;br /&gt;
&lt;br /&gt;
Uses of helper threads&lt;br /&gt;
&lt;br /&gt;
Predicting branch at early stages&lt;br /&gt;
&lt;br /&gt;
Helper threads are made up of program copies of the main thread stripped of all unessential parts &lt;br /&gt;
which are not of absolute necessity for the helper thread to achieve it tasks. Hence helper threads runs &lt;br /&gt;
ahead of main thread. Hence helper threads run ahead of main thread. Hence helper threads can do &lt;br /&gt;
computations that are necessary to decide the direction of the branch. This will inturn remove branch &lt;br /&gt;
mispredictions which may occur when branch predictions are used.&lt;br /&gt;
&lt;br /&gt;
Prefetching of Data &lt;br /&gt;
Since helper threads run ahead of main thread, they can predict the which data in memory is needed in&lt;br /&gt;
future by the main thread.they prefetch the data required by the main thread. The helper thread prefetches&lt;br /&gt;
the data and places it in the nearest cache accessible to the main thread. This avoids most of the L1 cache&lt;br /&gt;
misses that would have been encountered by the main thread had if helper thread was not present. As the &lt;br /&gt;
memory latency is reduced, the execution of main thread speeds up.&lt;br /&gt;
   &lt;br /&gt;
Memory Bug Reduction:&lt;br /&gt;
Memory related bugs such as reads from unitialised memory, read or writes using dangling pointers or &lt;br /&gt;
memory leaks are difficult to detect by code inspection because they may invoive different code fragments &lt;br /&gt;
and exist in differnt modules or source code files. Compilers are of little help becuase it fails to &lt;br /&gt;
disambiguate pointers. Hence, in practice memory bug detection relies on run time checkers that insert&lt;br /&gt;
monitor code to the application during testing. In CMPs, the program which detects the memory bugs can run&lt;br /&gt;
as a helper thread.&lt;br /&gt;
&lt;br /&gt;
Ex: Heapmon, a memory bug checker monitors application heap space to detect heap memory bugs. The memory &lt;br /&gt;
access events in the application thread are automatically forwarded to helper thread using appropriate &lt;br /&gt;
hardware mechanisms. Also the redundant and unnecessary  memory accessess are filtered out. Hence the helper&lt;br /&gt;
thread approach completely decouples bug monitoring from appication execution and the filtering mechanism reduces&lt;br /&gt;
bug - check frequency. Conseqently, HeapMon achieves a very low performance overhead.&lt;br /&gt;
&lt;br /&gt;
Fault tolerance:&lt;br /&gt;
The helper thread is a subset of main program. This partial redundancy can be used for detecting and recovering&lt;br /&gt;
from transient hardware faults.&lt;br /&gt;
&lt;br /&gt;
Slipstream approach for helper threads:&lt;br /&gt;
&lt;br /&gt;
Slipstream approach is developed at North Carolina State University. &lt;br /&gt;
Slipstream execution provides a simple means to use a second processor in a CMP to accelerate a single program.Slipstream execution involves running two redundant copies of the program. A significant number of dynamic instructions are speculatively removed from one of the program copies, without sacrificing its ability to make correct forward progress. The second program verifies the forward progress of the first and is also sped up in the process.  &lt;br /&gt;
&lt;br /&gt;
The speculative reduced program is called A-stream (Advanced Stream) and runs ahead of the unreduced program (main thread or Redundant stream).The R-stream exploits the A-stream to get an accurate picture of the future. For example, the A-stream &lt;br /&gt;
provides very accurate branch and value predictions. The predictions are more accurate than predictions made by conventional history-based predictors because they are produced by future program computation. The speculative A-stream occasionally (but&lt;br /&gt;
infrequently) goes astray. The R-stream serves as a checker of the speculative A-stream and redirects it when needed.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Disadvantages of helper threads:&lt;br /&gt;
&lt;br /&gt;
A very tight synchronisation is needed between the main thread and the helper threads in oder to keep them the proper distance ahead of main thread. If the helper threads are too far ahead, then they will cause cache thrashing by prefetching data and then replaing it with subsequent prefetches beofre the main thread can even use it. If they are not far enough ahead, they might not be able to prefetch cache lines in time. &lt;br /&gt;
&lt;br /&gt;
Only certain types of single threaded programs can be sped up with these techniques. Most integer applications have regular data access patterns and hence there will be only few misses to eliminate. The applications with larger memory footprints are easily parellelisable and hence doesn't run on a single main thread. I floating point applications the data access patterns are fairly regular and hence can be prefetched easily using hardware or software prefetch mechanisms. Hence the range of programs that can be accelerated using helper threads is fairly limited.&lt;/div&gt;</summary>
		<author><name>Lreddy</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki2_helperThreads&amp;diff=10005</id>
		<title>CSC/ECE 506 Fall 2007/wiki2 helperThreads</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki2_helperThreads&amp;diff=10005"/>
		<updated>2007-11-28T15:46:40Z</updated>

		<summary type="html">&lt;p&gt;Lreddy: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;A helper thread is a thread that does some of the work of the main thread in advance of the main thread so that the main thread can work more quickly. The Olukotun text only scratches the surface on all the different ways that helper threads can be used. Survey these ways, making sure to include the Slipstream approach developed at NCSU.&lt;br /&gt;
&lt;br /&gt;
What is a helper thread?&lt;br /&gt;
&lt;br /&gt;
The potential of chip multiprocessors (CMPs) can be exploited in a better way if the applications are&lt;br /&gt;
divided into semi - independent parts, or threads that can operate simultaneously across the processors &lt;br /&gt;
within a system. The simplest way to use parallel threads within a CMP to increase the performance of a &lt;br /&gt;
single thread is to have helper threads. A 'helper' thread performs work on behalf of main thread in an &lt;br /&gt;
effort to accelerate its performance.&lt;br /&gt;
&lt;br /&gt;
The speculative reduced program is called A-stream (Advanced Stream) and runs ahead of the unreduced program (main thread or Redundant stream).The R-stream exploits the A-stream to get an accurate picture of the future. For example, the A-stream &lt;br /&gt;
provides very accurate branch and value predictions. The predictions are more accurate than predictions made by conventional history-based predictors because they are produced by future program computation. The speculative A-stream occasionally (but&lt;br /&gt;
infrequently) goes astray. The R-stream serves as a checker of the speculative A-stream and redirects it when needed.&lt;br /&gt;
&lt;br /&gt;
Uses of helper threads&lt;br /&gt;
&lt;br /&gt;
Predicting branch at early stages&lt;br /&gt;
&lt;br /&gt;
Helper threads are made up of program copies of the main thread stripped of all unessential parts &lt;br /&gt;
which are not of absolute necessity for the helper thread to achieve it tasks. Hence helper threads runs &lt;br /&gt;
ahead of main thread. Hence helper threads run ahead of main thread. Hence helper threads can do &lt;br /&gt;
computations that are necessary to decide the direction of the branch. This will inturn remove branch &lt;br /&gt;
mispredictions which may occur when branch predictions are used.&lt;br /&gt;
&lt;br /&gt;
Prefetching of Data &lt;br /&gt;
Since helper threads run ahead of main thread, they can predict the which data in memory is needed in&lt;br /&gt;
future by the main thread.they prefetch the data required by the main thread. The helper thread prefetches&lt;br /&gt;
the data and places it in the nearest cache accessible to the main thread. This avoids most of the L1 cache&lt;br /&gt;
misses that would have been encountered by the main thread had if helper thread was not present. As the &lt;br /&gt;
memory latency is reduced, the execution of main thread speeds up.&lt;br /&gt;
   &lt;br /&gt;
Memory Bug Reduction:&lt;br /&gt;
Memory related bugs such as reads from unitialised memory, read or writes using dangling pointers or &lt;br /&gt;
memory leaks are difficult to detect by code inspection because they may invoive different code fragments &lt;br /&gt;
and exist in differnt modules or source code files. Compilers are of little help becuase it fails to &lt;br /&gt;
disambiguate pointers. Hence, in practice memory bug detection relies on run time checkers that insert&lt;br /&gt;
monitor code to the application during testing. In CMPs, the program which detects the memory bugs can run&lt;br /&gt;
as a helper thread.&lt;br /&gt;
&lt;br /&gt;
Ex: Heapmon, a memory bug checker monitors application heap space to detect heap memory bugs. The memory &lt;br /&gt;
access events in the application thread are automatically forwarded to helper thread using appropriate &lt;br /&gt;
hardware mechanisms. Also the redundant and unnecessary  memory accessess are filtered out. Hence the helper&lt;br /&gt;
thread approach completely decouples bug monitoring from appication execution and the filtering mechanism reduces&lt;br /&gt;
bug - check frequency. Conseqently, HeapMon achieves a very low performance overhead.&lt;br /&gt;
&lt;br /&gt;
Fault tolerance:&lt;br /&gt;
The helper thread is a subset of main program. This partial redundancy can be used for detecting and recovering&lt;br /&gt;
from transient hardware faults.&lt;br /&gt;
&lt;br /&gt;
Slipstream approach for helper threads:&lt;br /&gt;
&lt;br /&gt;
Slipstream approach is developed at North Carolina State University. &lt;br /&gt;
Slipstream execution provides a simple means to use a second processor in a CMP to accelerate a single program.Slipstream execution involves running two redundant copies of the program. A significant number of dynamic instructions are speculatively removed from one of the program copies, without sacrificing its ability to make correct forward progress. The second program verifies the forward progress of the first and is also sped up in the process.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Disadvantages of helper threads:&lt;br /&gt;
&lt;br /&gt;
A very tight synchronisation is needed between the main thread and the helper threads in oder to keep them the proper distance ahead of main thread. If the helper threads are too far ahead, then they will cause cache thrashing by prefetching data and then replaing it with subsequent prefetches beofre the main thread can even use it. If they are not far enough ahead, they might not be able to prefetch cache lines in time. &lt;br /&gt;
&lt;br /&gt;
Only certain types of single threaded programs can be sped up with these techniques. Most integer applications have regular data access patterns and hence there will be only few misses to eliminate. The applications with larger memory footprints are easily parellelisable and hence doesn't run on a single main thread. I floating point applications the data access patterns are fairly regular and hence can be prefetched easily using hardware or software prefetch mechanisms. Hence the range of programs that can be accelerated using helper threads is fairly limited.&lt;/div&gt;</summary>
		<author><name>Lreddy</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki2_helperThreads&amp;diff=10004</id>
		<title>CSC/ECE 506 Fall 2007/wiki2 helperThreads</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki2_helperThreads&amp;diff=10004"/>
		<updated>2007-11-28T15:42:35Z</updated>

		<summary type="html">&lt;p&gt;Lreddy: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;A helper thread is a thread that does some of the work of the main thread in advance of the main thread so that the main thread can work more quickly. The Olukotun text only scratches the surface on all the different ways that helper threads can be used. Survey these ways, making sure to include the Slipstream approach developed at NCSU.&lt;br /&gt;
&lt;br /&gt;
What is a helper thread?&lt;br /&gt;
&lt;br /&gt;
The potential of chip multiprocessors (CMPs) can be exploited in a better way if the applications are&lt;br /&gt;
divided into semi - independent parts, or threads that can operate simultaneously across the processors &lt;br /&gt;
within a system. The simplest way to use parallel threads within a CMP to increase the performance of a &lt;br /&gt;
single thread is to have helper threads. A 'helper' thread performs work on behalf of main thread in an &lt;br /&gt;
effort to accelerate its performance.&lt;br /&gt;
&lt;br /&gt;
Uses of helper threads&lt;br /&gt;
&lt;br /&gt;
Predicting branch at early stages&lt;br /&gt;
&lt;br /&gt;
Helper threads are made up of program copies of the main thread stripped of all unessential parts &lt;br /&gt;
which are not of absolute necessity for the helper thread to achieve it tasks. Hence helper threads runs &lt;br /&gt;
ahead of main thread. Hence helper threads run ahead of main thread. Hence helper threads can do &lt;br /&gt;
computations that are necessary to decide the direction of the branch. This will inturn remove branch &lt;br /&gt;
mispredictions which may occur when branch predictions are used.&lt;br /&gt;
&lt;br /&gt;
Prefetching of Data &lt;br /&gt;
Since helper threads run ahead of main thread, they can predict the which data in memory is needed in&lt;br /&gt;
future by the main thread.they prefetch the data required by the main thread. The helper thread prefetches&lt;br /&gt;
the data and places it in the nearest cache accessible to the main thread. This avoids most of the L1 cache&lt;br /&gt;
misses that would have been encountered by the main thread had if helper thread was not present. As the &lt;br /&gt;
memory latency is reduced, the execution of main thread speeds up.&lt;br /&gt;
   &lt;br /&gt;
Memory Bug Reduction:&lt;br /&gt;
Memory related bugs such as reads from unitialised memory, read or writes using dangling pointers or &lt;br /&gt;
memory leaks are difficult to detect by code inspection because they may invoive different code fragments &lt;br /&gt;
and exist in differnt modules or source code files. Compilers are of little help becuase it fails to &lt;br /&gt;
disambiguate pointers. Hence, in practice memory bug detection relies on run time checkers that insert&lt;br /&gt;
monitor code to the application during testing. In CMPs, the program which detects the memory bugs can run&lt;br /&gt;
as a helper thread.&lt;br /&gt;
&lt;br /&gt;
Ex: Heapmon, a memory bug checker monitors application heap space to detect heap memory bugs. The memory &lt;br /&gt;
access events in the application thread are automatically forwarded to helper thread using appropriate &lt;br /&gt;
hardware mechanisms. Also the redundant and unnecessary  memory accessess are filtered out. Hence the helper&lt;br /&gt;
thread approach completely decouples bug monitoring from appication execution and the filtering mechanism reduces&lt;br /&gt;
bug - check frequency. Conseqently, HeapMon achieves a very low performance overhead.&lt;br /&gt;
&lt;br /&gt;
Fault tolerance:&lt;br /&gt;
The helper thread is a subset of main program. This partial redundancy can be used for detecting and recovering&lt;br /&gt;
from transient hardware faults.&lt;br /&gt;
&lt;br /&gt;
Slipstream approach for helper threads:&lt;br /&gt;
&lt;br /&gt;
Slipstream approach is developed at North Carolina State University. &lt;br /&gt;
Slipstream execution provides a simple means to use a second processor in a CMP to accelerate a single program.Slipstream execution involves running two redundant copies of the program. A significant number of dynamic instructions are speculatively removed from one of the program copies, without sacrificing its ability to make correct forward progress. The second program verifies the forward progress of the first and is also sped up in the process.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Disadvantages of helper threads:&lt;br /&gt;
&lt;br /&gt;
A very tight synchronisation is needed between the main thread and the helper threads in oder to keep them the proper distance ahead of main thread. If the helper threads are too far ahead, then they will cause cache thrashing by prefetching data and then replaing it with subsequent prefetches beofre the main thread can even use it. If they are not far enough ahead, they might not be able to prefetch cache lines in time. &lt;br /&gt;
&lt;br /&gt;
Only certain types of single threaded programs can be sped up with these techniques. Most integer applications have regular data access patterns and hence there will be only few misses to eliminate. The applications with larger memory footprints are easily parellelisable and hence doesn't run on a single main thread. I floating point applications the data access patterns are fairly regular and hence can be prefetched easily using hardware or software prefetch mechanisms. Hence the range of programs that can be accelerated using helper threads is fairly limited.&lt;/div&gt;</summary>
		<author><name>Lreddy</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki2_helperThreads&amp;diff=10002</id>
		<title>CSC/ECE 506 Fall 2007/wiki2 helperThreads</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki2_helperThreads&amp;diff=10002"/>
		<updated>2007-11-28T15:39:57Z</updated>

		<summary type="html">&lt;p&gt;Lreddy: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;A helper thread is a thread that does some of the work of the main thread in advance of the main thread so that the main thread can work more quickly. The Olukotun text only scratches the surface on all the different ways that helper threads can be used. Survey these ways, making sure to include the Slipstream approach developed at NCSU.&lt;br /&gt;
&lt;br /&gt;
What is a helper thread?&lt;br /&gt;
&lt;br /&gt;
The potential of chip multiprocessors (CMPs) can be exploited in a better way if the applications are&lt;br /&gt;
divided into semi - independent parts, or threads that can operate simultaneously across the processors &lt;br /&gt;
within a system. The simplest way to use parallel threads within a CMP to increase the performance of a &lt;br /&gt;
single thread is to have helper threads. A 'helper' thread performs work on behalf of main thread in an &lt;br /&gt;
effort to accelerate its performance.&lt;br /&gt;
&lt;br /&gt;
Uses of helper threads&lt;br /&gt;
&lt;br /&gt;
Predicting branch at early stages&lt;br /&gt;
&lt;br /&gt;
Helper threads are made up of program copies of the main thread stripped of all unessential parts &lt;br /&gt;
which are not of absolute necessity for the helper thread to achieve it tasks. Hence helper threads runs &lt;br /&gt;
ahead of main thread. Hence helper threads run ahead of main thread. Hence helper threads can do &lt;br /&gt;
computations that are necessary to decide the direction of the branch. This will inturn remove branch &lt;br /&gt;
mispredictions which may occur when branch predictions are used.&lt;br /&gt;
&lt;br /&gt;
Prefetching of Data &lt;br /&gt;
Since helper threads run ahead of main thread, they can predict the which data in memory is needed in&lt;br /&gt;
future by the main thread.they prefetch the data required by the main thread. The helper thread prefetches&lt;br /&gt;
the data and places it in the nearest cache accessible to the main thread. This avoids most of the L1 cache&lt;br /&gt;
misses that would have been encountered by the main thread had if helper thread was not present. As the &lt;br /&gt;
memory latency is reduced, the execution of main thread speeds up.&lt;br /&gt;
   &lt;br /&gt;
Memory Bug Reduction:&lt;br /&gt;
Memory related bugs such as reads from unitialised memory, read or writes using dangling pointers or &lt;br /&gt;
memory leaks are difficult to detect by code inspection because they may invoive different code fragments &lt;br /&gt;
and exist in differnt modules or source code files. Compilers are of little help becuase it fails to &lt;br /&gt;
disambiguate pointers. Hence, in practice memory bug detection relies on run time checkers that insert&lt;br /&gt;
monitor code to the application during testing. In CMPs, the program which detects the memory bugs can run&lt;br /&gt;
as a helper thread.&lt;br /&gt;
&lt;br /&gt;
Ex: Heapmon, a memory bug checker monitors application heap space to detect heap memory bugs. The memory &lt;br /&gt;
access events in the application thread are automatically forwarded to helper thread using appropriate &lt;br /&gt;
hardware mechanisms. Also the redundant and unnecessary  memory accessess are filtered out. Hence the helper&lt;br /&gt;
thread approach completely decouples bug monitoring from appication execution and the filtering mechanism reduces&lt;br /&gt;
bug - check frequency. Conseqently, HeapMon achieves a very low performance overhead.&lt;br /&gt;
&lt;br /&gt;
Fault tolerance:&lt;br /&gt;
The helper thread is a subset of main program. This partial redundancy can be used for detecting and recovering&lt;br /&gt;
from transient hardware faults.&lt;br /&gt;
&lt;br /&gt;
Slipstream approach for helper threads:&lt;br /&gt;
&lt;br /&gt;
Slipstream approach is developed at North Carolina State University. &lt;br /&gt;
Slipstream execution provides a simple means to use a second processor in a CMP to accelerate a single program.Slipstream execution involves running two redundant copies of the program. Predicted-ineffectual computation is speculatively removed from one of the programs, speeding it up. The second program verifies the forward progress of the first and is also sped up &lt;br /&gt;
in the process.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Disadvantages of helper threads:&lt;br /&gt;
&lt;br /&gt;
A very tight synchronisation is needed between the main thread and the helper threads in oder to keep them the proper distance ahead of main thread. If the helper threads are too far ahead, then they will cause cache thrashing by prefetching data and then replaing it with subsequent prefetches beofre the main thread can even use it. If they are not far enough ahead, they might not be able to prefetch cache lines in time. &lt;br /&gt;
&lt;br /&gt;
Only certain types of single threaded programs can be sped up with these techniques. Most integer applications have regular data access patterns and hence there will be only few misses to eliminate. The applications with larger memory footprints are easily parellelisable and hence doesn't run on a single main thread. I floating point applications the data access patterns are fairly regular and hence can be prefetched easily using hardware or software prefetch mechanisms. Hence the range of programs that can be accelerated using helper threads is fairly limited.&lt;/div&gt;</summary>
		<author><name>Lreddy</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki2_helperThreads&amp;diff=9999</id>
		<title>CSC/ECE 506 Fall 2007/wiki2 helperThreads</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki2_helperThreads&amp;diff=9999"/>
		<updated>2007-11-28T15:33:09Z</updated>

		<summary type="html">&lt;p&gt;Lreddy: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;A helper thread is a thread that does some of the work of the main thread in advance of the main thread so that the main thread can work more quickly. The Olukotun text only scratches the surface on all the different ways that helper threads can be used. Survey these ways, making sure to include the Slipstream approach developed at NCSU.&lt;br /&gt;
&lt;br /&gt;
What is a helper thread?&lt;br /&gt;
&lt;br /&gt;
The potential of chip multiprocessors (CMPs) can be exploited in a better way if the applications are&lt;br /&gt;
divided into semi - independent parts, or threads that can operate simultaneously across the processors &lt;br /&gt;
within a system. The simplest way to use parallel threads within a CMP to increase the performance of a &lt;br /&gt;
single thread is to have helper threads. A 'helper' thread performs work on behalf of main thread in an &lt;br /&gt;
effort to accelerate its performance.&lt;br /&gt;
&lt;br /&gt;
Uses of helper threads&lt;br /&gt;
&lt;br /&gt;
Predicting branch at early stages&lt;br /&gt;
&lt;br /&gt;
Helper threads are made up of program copies of the main thread stripped of all unessential parts &lt;br /&gt;
which are not of absolute necessity for the helper thread to achieve it tasks. Hence helper threads runs &lt;br /&gt;
ahead of main thread. Hence helper threads run ahead of main thread. Hence helper threads can do &lt;br /&gt;
computations that are necessary to decide the direction of the branch. This will inturn remove branch &lt;br /&gt;
mispredictions which may occur when branch predictions are used.&lt;br /&gt;
&lt;br /&gt;
Prefetching of Data &lt;br /&gt;
Since helper threads run ahead of main thread, they can predict the which data in memory is needed in&lt;br /&gt;
future by the main thread.they prefetch the data required by the main thread. The helper thread prefetches&lt;br /&gt;
the data and places it in the nearest cache accessible to the main thread. This avoids most of the L1 cache&lt;br /&gt;
misses that would have been encountered by the main thread had if helper thread was not present. As the &lt;br /&gt;
memory latency is reduced, the execution of main thread speeds up.&lt;br /&gt;
   &lt;br /&gt;
Memory Bug Reduction:&lt;br /&gt;
Memory related bugs such as reads from unitialised memory, read or writes using dangling pointers or &lt;br /&gt;
memory leaks are difficult to detect by code inspection because they may invoive different code fragments &lt;br /&gt;
and exist in differnt modules or source code files. Compilers are of little help becuase it fails to &lt;br /&gt;
disambiguate pointers. Hence, in practice memory bug detection relies on run time checkers that insert&lt;br /&gt;
monitor code to the application during testing. In CMPs, the program which detects the memory bugs can run&lt;br /&gt;
as a helper thread.&lt;br /&gt;
&lt;br /&gt;
Ex: Heapmon, a memory bug checker monitors application heap space to detect heap memory bugs. The memory &lt;br /&gt;
access events in the application thread are automatically forwarded to helper thread using appropriate &lt;br /&gt;
hardware mechanisms. Also the redundant and unnecessary  memory accessess are filtered out. Hence the helper&lt;br /&gt;
thread approach completely decouples bug monitoring from appication execution and the filtering mechanism reduces&lt;br /&gt;
bug - check frequency. Conseqently, HeapMon achieves a very low performance overhead.&lt;br /&gt;
&lt;br /&gt;
Fault tolerance:&lt;br /&gt;
The helper thread is a subset of main program. This partial redundancy can be used for detecting and recovering&lt;br /&gt;
from transient hardware faults.&lt;br /&gt;
&lt;br /&gt;
Slipstream approach for helper threads:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Disadvantages of helper threads:&lt;br /&gt;
&lt;br /&gt;
A very tight synchronisation is needed between the main thread and the helper threads in oder to keep them the proper distance ahead of main thread. If the helper threads are too far ahead, then they will cause cache thrashing by prefetching data and then replaing it with subsequent prefetches beofre the main thread can even use it. If they are not far enough ahead, they might not be able to prefetch cache lines in time. &lt;br /&gt;
&lt;br /&gt;
Only certain types of single threaded programs can be sped up with these techniques. Most integer applications have regular data access patterns and hence there will be only few misses to eliminate. The applications with larger memory footprints are easily parellelisable and hence doesn't run on a single main thread. I floating point applications the data access patterns are fairly regular and hence can be prefetched easily using hardware or software prefetch mechanisms. Hence the range of programs that can be accelerated using helper threads is fairly limited.&lt;/div&gt;</summary>
		<author><name>Lreddy</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki2_helperThreads&amp;diff=9998</id>
		<title>CSC/ECE 506 Fall 2007/wiki2 helperThreads</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki2_helperThreads&amp;diff=9998"/>
		<updated>2007-11-28T15:32:49Z</updated>

		<summary type="html">&lt;p&gt;Lreddy: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;A helper thread is a thread that does some of the work of the main thread in advance of the main thread so that the main thread can work more quickly. The Olukotun text only scratches the surface on all the different ways that helper threads can be used. Survey these ways, making sure to include the Slipstream approach developed at NCSU.&lt;br /&gt;
&lt;br /&gt;
What is a helper thread?&lt;br /&gt;
&lt;br /&gt;
The potential of chip multiprocessors (CMPs) can be exploited in a better way if the applications are&lt;br /&gt;
divided into semi - independent parts, or threads that can operate simultaneously across the processors &lt;br /&gt;
within a system. The simplest way to use parallel threads within a CMP to increase the performance of a &lt;br /&gt;
single thread is to have helper threads. A 'helper' thread performs work on behalf of main thread in an &lt;br /&gt;
effort to accelerate its performance.&lt;br /&gt;
&lt;br /&gt;
Uses of helper threads&lt;br /&gt;
&lt;br /&gt;
Predicting branch at early stages&lt;br /&gt;
&lt;br /&gt;
Helper threads are made up of program copies of the main thread stripped of all unessential parts &lt;br /&gt;
which are not of absolute necessity for the helper thread to achieve it tasks. Hence helper threads runs &lt;br /&gt;
ahead of main thread. Hence helper threads run ahead of main thread. Hence helper threads can do &lt;br /&gt;
computations that are necessary to decide the direction of the branch. This will inturn remove branch &lt;br /&gt;
mispredictions which may occur when branch predictions are used.&lt;br /&gt;
&lt;br /&gt;
Prefetching of Data &lt;br /&gt;
Since helper threads run ahead of main thread, they can predict the which data in memory is needed in&lt;br /&gt;
future by the main thread.they prefetch the data required by the main thread. The helper thread prefetches&lt;br /&gt;
the data and places it in the nearest cache accessible to the main thread. This avoids most of the L1 cache&lt;br /&gt;
misses that would have been encountered by the main thread had if helper thread was not present. As the &lt;br /&gt;
memory latency is reduced, the execution of main thread speeds up.&lt;br /&gt;
   &lt;br /&gt;
Memory Bug Reduction:&lt;br /&gt;
Memory related bugs such as reads from unitialised memory, read or writes using dangling pointers or &lt;br /&gt;
memory leaks are difficult to detect by code inspection because they may invoive different code fragments &lt;br /&gt;
and exist in differnt modules or source code files. Compilers are of little help becuase it fails to &lt;br /&gt;
disambiguate pointers. Hence, in practice memory bug detection relies on run time checkers that insert&lt;br /&gt;
monitor code to the application during testing. In CMPs, the program which detects the memory bugs can run&lt;br /&gt;
as a helper thread.&lt;br /&gt;
 Ex: Heapmon, a memory bug checker monitors application heap space to detect heap memory bugs. The memory &lt;br /&gt;
access events in the application thread are automatically forwarded to helper thread using appropriate &lt;br /&gt;
hardware mechanisms. Also the redundant and unnecessary  memory accessess are filtered out. Hence the helper&lt;br /&gt;
thread approach completely decouples bug monitoring from appication execution and the filtering mechanism reduces&lt;br /&gt;
bug - check frequency. Conseqently, HeapMon achieves a very low performance overhead.&lt;br /&gt;
&lt;br /&gt;
Fault tolerance:&lt;br /&gt;
The helper thread is a subset of main program. This partial redundancy can be used for detecting and recovering&lt;br /&gt;
from transient hardware faults.&lt;br /&gt;
&lt;br /&gt;
Slipstream approach for helper threads:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Disadvantages of helper threads:&lt;br /&gt;
&lt;br /&gt;
A very tight synchronisation is needed between the main thread and the helper threads in oder to keep them the proper distance ahead of main thread. If the helper threads are too far ahead, then they will cause cache thrashing by prefetching data and then replaing it with subsequent prefetches beofre the main thread can even use it. If they are not far enough ahead, they might not be able to prefetch cache lines in time. &lt;br /&gt;
&lt;br /&gt;
Only certain types of single threaded programs can be sped up with these techniques. Most integer applications have regular data access patterns and hence there will be only few misses to eliminate. The applications with larger memory footprints are easily parellelisable and hence doesn't run on a single main thread. I floating point applications the data access patterns are fairly regular and hence can be prefetched easily using hardware or software prefetch mechanisms. Hence the range of programs that can be accelerated using helper threads is fairly limited.&lt;/div&gt;</summary>
		<author><name>Lreddy</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki2_helperThreads&amp;diff=9997</id>
		<title>CSC/ECE 506 Fall 2007/wiki2 helperThreads</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki2_helperThreads&amp;diff=9997"/>
		<updated>2007-11-28T15:32:18Z</updated>

		<summary type="html">&lt;p&gt;Lreddy: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;A helper thread is a thread that does some of the work of the main thread in advance of the main thread so that the main thread can work more quickly. The Olukotun text only scratches the surface on all the different ways that helper threads can be used. Survey these ways, making sure to include the Slipstream approach developed at NCSU.&lt;br /&gt;
&lt;br /&gt;
What is a helper thread?&lt;br /&gt;
&lt;br /&gt;
The potential of chip multiprocessors (CMPs) can be exploited in a better way if the applications are&lt;br /&gt;
divided into semi - independent parts, or threads that can operate simultaneously across the processors &lt;br /&gt;
within a system. The simplest way to use parallel threads within a CMP to increase the performance of a &lt;br /&gt;
single thread is to have helper threads. A 'helper' thread performs work on behalf of main thread in an &lt;br /&gt;
effort to accelerate its performance.&lt;br /&gt;
&lt;br /&gt;
Uses of helper threads&lt;br /&gt;
&lt;br /&gt;
Predicting branch at early stages&lt;br /&gt;
&lt;br /&gt;
Helper threads are made up of program copies of the main thread stripped of all unessential parts &lt;br /&gt;
which are not of absolute necessity for the helper thread to achieve it tasks. Hence helper threads runs &lt;br /&gt;
ahead of main thread. Hence helper threads run ahead of main thread. Hence helper threads can do &lt;br /&gt;
computations that are necessary to decide the direction of the branch. This will inturn remove branch &lt;br /&gt;
mispredictions which may occur when branch predictions are used.&lt;br /&gt;
&lt;br /&gt;
Prefetching of Data &lt;br /&gt;
Since helper threads run ahead of main thread, they can predict the which data in memory is needed in&lt;br /&gt;
future by the main thread.they prefetch the data required by the main thread. The helper thread prefetches&lt;br /&gt;
the data and places it in the nearest cache accessible to the main thread. This avoids most of the L1 cache&lt;br /&gt;
misses that would have been encountered by the main thread had if helper thread was not present. As the &lt;br /&gt;
memory latency is reduced, the execution of main thread speeds up.&lt;br /&gt;
   &lt;br /&gt;
Memory Bug Reduction:&lt;br /&gt;
      Memory related bugs such as reads from unitialised memory, read or writes using dangling pointers or &lt;br /&gt;
memory leaks are difficult to detect by code inspection because they may invoive different code fragments &lt;br /&gt;
and exist in differnt modules or source code files. Compilers are of little help becuase it fails to &lt;br /&gt;
disambiguate pointers. Hence, in practice memory bug detection relies on run time checkers that insert&lt;br /&gt;
monitor code to the application during testing. In CMPs, the program which detects the memory bugs can run&lt;br /&gt;
as a helper thread.&lt;br /&gt;
 Ex: Heapmon, a memory bug checker monitors application heap space to detect heap memory bugs. The memory &lt;br /&gt;
access events in the application thread are automatically forwarded to helper thread using appropriate &lt;br /&gt;
hardware mechanisms. Also the redundant and unnecessary  memory accessess are filtered out. Hence the helper&lt;br /&gt;
thread approach completely decouples bug monitoring from appication execution and the filtering mechanism reduces&lt;br /&gt;
bug - check frequency. Conseqently, HeapMon achieves a very low performance overhead.&lt;br /&gt;
&lt;br /&gt;
Fault tolerance:&lt;br /&gt;
     The helper thread is a subset of main program. This partial redundancy can be used for detecting and recovering&lt;br /&gt;
from transient hardware faults.&lt;br /&gt;
&lt;br /&gt;
Slipstream approach for helper threads:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Disadvantages of helper threads:&lt;br /&gt;
&lt;br /&gt;
  A very tight synchronisation is needed between the main thread and the helper threads in oder to keep them the proper distance ahead of main thread. If the helper threads are too far ahead, then they will cause cache thrashing by prefetching data and then replaing it with subsequent prefetches beofre the main thread can even use it. If they are not far enough ahead, they might not be able to prefetch cache lines in time. &lt;br /&gt;
&lt;br /&gt;
  Only certain types of single threaded programs can be sped up with these techniques. Most integer applications have regular data access patterns and hence there will be only few misses to eliminate. The applications with larger memory footprints are easily parellelisable and hence doesn't run on a single main thread. I floating point applications the data access patterns are fairly regular and hence can be prefetched easily using hardware or software prefetch mechanisms. Hence the range of programs that can be accelerated using helper threads is fairly limited.&lt;/div&gt;</summary>
		<author><name>Lreddy</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki2_helperThreads&amp;diff=9996</id>
		<title>CSC/ECE 506 Fall 2007/wiki2 helperThreads</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki2_helperThreads&amp;diff=9996"/>
		<updated>2007-11-28T15:31:59Z</updated>

		<summary type="html">&lt;p&gt;Lreddy: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;A helper thread is a thread that does some of the work of the main thread in advance of the main thread so that the main thread can work more quickly. The Olukotun text only scratches the surface on all the different ways that helper threads can be used. Survey these ways, making sure to include the Slipstream approach developed at NCSU.&lt;br /&gt;
&lt;br /&gt;
What is a helper thread?&lt;br /&gt;
&lt;br /&gt;
The potential of chip multiprocessors (CMPs) can be exploited in a better way if the applications are&lt;br /&gt;
divided into semi - independent parts, or threads that can operate simultaneously across the processors &lt;br /&gt;
within a system. The simplest way to use parallel threads within a CMP to increase the performance of a &lt;br /&gt;
single thread is to have helper threads. A 'helper' thread performs work on behalf of main thread in an &lt;br /&gt;
effort to accelerate its performance.&lt;br /&gt;
&lt;br /&gt;
Uses of helper threads&lt;br /&gt;
&lt;br /&gt;
Predicting branch at early stages&lt;br /&gt;
&lt;br /&gt;
Helper threads are made up of program copies of the main thread stripped of all unessential parts &lt;br /&gt;
which are not of absolute necessity for the helper thread to achieve it tasks. Hence helper threads runs &lt;br /&gt;
ahead of main thread. Hence helper threads run ahead of main thread. Hence helper threads can do &lt;br /&gt;
computations that are necessary to decide the direction of the branch. This will inturn remove branch &lt;br /&gt;
mispredictions which may occur when branch predictions are used.&lt;br /&gt;
&lt;br /&gt;
Prefetching of Data &lt;br /&gt;
     Since helper threads run ahead of main thread, they can predict the which data in memory is needed in&lt;br /&gt;
 future by the main thread.they prefetch the data required by the main thread. The helper thread prefetches&lt;br /&gt;
 the data and places it in the nearest cache accessible to the main thread. This avoids most of the L1 cache&lt;br /&gt;
 misses that would have been encountered by the main thread had if helper thread was not present. As the &lt;br /&gt;
 memory latency is reduced, the execution of main thread speeds up.&lt;br /&gt;
   &lt;br /&gt;
Memory Bug Reduction:&lt;br /&gt;
      Memory related bugs such as reads from unitialised memory, read or writes using dangling pointers or &lt;br /&gt;
memory leaks are difficult to detect by code inspection because they may invoive different code fragments &lt;br /&gt;
and exist in differnt modules or source code files. Compilers are of little help becuase it fails to &lt;br /&gt;
disambiguate pointers. Hence, in practice memory bug detection relies on run time checkers that insert&lt;br /&gt;
monitor code to the application during testing. In CMPs, the program which detects the memory bugs can run&lt;br /&gt;
as a helper thread.&lt;br /&gt;
 Ex: Heapmon, a memory bug checker monitors application heap space to detect heap memory bugs. The memory &lt;br /&gt;
access events in the application thread are automatically forwarded to helper thread using appropriate &lt;br /&gt;
hardware mechanisms. Also the redundant and unnecessary  memory accessess are filtered out. Hence the helper&lt;br /&gt;
thread approach completely decouples bug monitoring from appication execution and the filtering mechanism reduces&lt;br /&gt;
bug - check frequency. Conseqently, HeapMon achieves a very low performance overhead.&lt;br /&gt;
&lt;br /&gt;
Fault tolerance:&lt;br /&gt;
     The helper thread is a subset of main program. This partial redundancy can be used for detecting and recovering&lt;br /&gt;
from transient hardware faults.&lt;br /&gt;
&lt;br /&gt;
Slipstream approach for helper threads:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Disadvantages of helper threads:&lt;br /&gt;
&lt;br /&gt;
  A very tight synchronisation is needed between the main thread and the helper threads in oder to keep them the proper distance ahead of main thread. If the helper threads are too far ahead, then they will cause cache thrashing by prefetching data and then replaing it with subsequent prefetches beofre the main thread can even use it. If they are not far enough ahead, they might not be able to prefetch cache lines in time. &lt;br /&gt;
&lt;br /&gt;
  Only certain types of single threaded programs can be sped up with these techniques. Most integer applications have regular data access patterns and hence there will be only few misses to eliminate. The applications with larger memory footprints are easily parellelisable and hence doesn't run on a single main thread. I floating point applications the data access patterns are fairly regular and hence can be prefetched easily using hardware or software prefetch mechanisms. Hence the range of programs that can be accelerated using helper threads is fairly limited.&lt;/div&gt;</summary>
		<author><name>Lreddy</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki2_helperThreads&amp;diff=9995</id>
		<title>CSC/ECE 506 Fall 2007/wiki2 helperThreads</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki2_helperThreads&amp;diff=9995"/>
		<updated>2007-11-28T15:31:14Z</updated>

		<summary type="html">&lt;p&gt;Lreddy: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;A helper thread is a thread that does some of the work of the main thread in advance of the main thread so that the main thread can work more quickly. The Olukotun text only scratches the surface on all the different ways that helper threads can be used. Survey these ways, making sure to include the Slipstream approach developed at NCSU.&lt;br /&gt;
&lt;br /&gt;
What is a helper thread?&lt;br /&gt;
&lt;br /&gt;
The potential of chip multiprocessors (CMPs) can be exploited in a better way if the applications are&lt;br /&gt;
divided into semi - independent parts, or threads that can operate simultaneously across the processors &lt;br /&gt;
within a system. The simplest way to use parallel threads within a CMP to increase the performance of a &lt;br /&gt;
single thread is to have helper threads. A 'helper' thread performs work on behalf of main thread in an &lt;br /&gt;
effort to accelerate its performance.&lt;br /&gt;
&lt;br /&gt;
Uses of helper threads&lt;br /&gt;
&lt;br /&gt;
Predicting branch at early stages&lt;br /&gt;
       Helper threads are made up of program copies of the main thread stripped of all unessential parts &lt;br /&gt;
which are not of absolute necessity for the helper thread to achieve it tasks. Hence helper threads runs &lt;br /&gt;
ahead of main thread. Hence helper threads run ahead of main thread. Hence helper threads can do &lt;br /&gt;
computations that are necessary to decide the direction of the branch. This will inturn remove branch &lt;br /&gt;
mispredictions which may occur when branch predictions are used.&lt;br /&gt;
&lt;br /&gt;
Prefetching of Data &lt;br /&gt;
     Since helper threads run ahead of main thread, they can predict the which data in memory is needed in&lt;br /&gt;
 future by the main thread.they prefetch the data required by the main thread. The helper thread prefetches&lt;br /&gt;
 the data and places it in the nearest cache accessible to the main thread. This avoids most of the L1 cache&lt;br /&gt;
 misses that would have been encountered by the main thread had if helper thread was not present. As the &lt;br /&gt;
 memory latency is reduced, the execution of main thread speeds up.&lt;br /&gt;
   &lt;br /&gt;
Memory Bug Reduction:&lt;br /&gt;
      Memory related bugs such as reads from unitialised memory, read or writes using dangling pointers or &lt;br /&gt;
memory leaks are difficult to detect by code inspection because they may invoive different code fragments &lt;br /&gt;
and exist in differnt modules or source code files. Compilers are of little help becuase it fails to &lt;br /&gt;
disambiguate pointers. Hence, in practice memory bug detection relies on run time checkers that insert&lt;br /&gt;
monitor code to the application during testing. In CMPs, the program which detects the memory bugs can run&lt;br /&gt;
as a helper thread.&lt;br /&gt;
 Ex: Heapmon, a memory bug checker monitors application heap space to detect heap memory bugs. The memory &lt;br /&gt;
access events in the application thread are automatically forwarded to helper thread using appropriate &lt;br /&gt;
hardware mechanisms. Also the redundant and unnecessary  memory accessess are filtered out. Hence the helper&lt;br /&gt;
thread approach completely decouples bug monitoring from appication execution and the filtering mechanism reduces&lt;br /&gt;
bug - check frequency. Conseqently, HeapMon achieves a very low performance overhead.&lt;br /&gt;
&lt;br /&gt;
Fault tolerance:&lt;br /&gt;
     The helper thread is a subset of main program. This partial redundancy can be used for detecting and recovering&lt;br /&gt;
from transient hardware faults.&lt;br /&gt;
&lt;br /&gt;
Slipstream approach for helper threads:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Disadvantages of helper threads:&lt;br /&gt;
&lt;br /&gt;
  A very tight synchronisation is needed between the main thread and the helper threads in oder to keep them the proper distance ahead of main thread. If the helper threads are too far ahead, then they will cause cache thrashing by prefetching data and then replaing it with subsequent prefetches beofre the main thread can even use it. If they are not far enough ahead, they might not be able to prefetch cache lines in time. &lt;br /&gt;
&lt;br /&gt;
  Only certain types of single threaded programs can be sped up with these techniques. Most integer applications have regular data access patterns and hence there will be only few misses to eliminate. The applications with larger memory footprints are easily parellelisable and hence doesn't run on a single main thread. I floating point applications the data access patterns are fairly regular and hence can be prefetched easily using hardware or software prefetch mechanisms. Hence the range of programs that can be accelerated using helper threads is fairly limited.&lt;/div&gt;</summary>
		<author><name>Lreddy</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki2_helperThreads&amp;diff=9994</id>
		<title>CSC/ECE 506 Fall 2007/wiki2 helperThreads</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki2_helperThreads&amp;diff=9994"/>
		<updated>2007-11-28T15:30:39Z</updated>

		<summary type="html">&lt;p&gt;Lreddy: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;A helper thread is a thread that does some of the work of the main thread in advance of the main thread so that the main thread can work more quickly. The Olukotun text only scratches the surface on all the different ways that helper threads can be used. Survey these ways, making sure to include the Slipstream approach developed at NCSU.&lt;br /&gt;
&lt;br /&gt;
What is a helper thread?&lt;br /&gt;
&lt;br /&gt;
The potential of chip multiprocessors (CMPs) can be exploited in a better way if the applications are&lt;br /&gt;
divided into semi - independent parts, or threads that can operate simultaneously across the processors &lt;br /&gt;
within a system. The simplest way to use parallel threads within a CMP to increase the performance of a &lt;br /&gt;
single thread is to have helper threads. A 'helper' thread performs work on behalf of main thread in an &lt;br /&gt;
effort to accelerate its performance.&lt;br /&gt;
&lt;br /&gt;
Uses of helper threads:&lt;br /&gt;
&lt;br /&gt;
Predicting branch at early stages: &lt;br /&gt;
       Helper threads are made up of program copies of the main thread stripped of all unessential parts &lt;br /&gt;
which are not of absolute necessity for the helper thread to achieve it tasks. Hence helper threads runs &lt;br /&gt;
ahead of main thread. Hence helper threads run ahead of main thread. Hence helper threads can do &lt;br /&gt;
computations that are necessary to decide the direction of the branch. This will inturn remove branch &lt;br /&gt;
mispredictions which may occur when branch predictions are used.&lt;br /&gt;
&lt;br /&gt;
Prefetching of Data: &lt;br /&gt;
     Since helper threads run ahead of main thread, they can predict the which data in memory is needed in&lt;br /&gt;
 future by the main thread.they prefetch the data required by the main thread. The helper thread prefetches&lt;br /&gt;
 the data and places it in the nearest cache accessible to the main thread. This avoids most of the L1 cache&lt;br /&gt;
 misses that would have been encountered by the main thread had if helper thread was not present. As the &lt;br /&gt;
 memory latency is reduced, the execution of main thread speeds up.&lt;br /&gt;
   &lt;br /&gt;
Memory Bug Reduction:&lt;br /&gt;
      Memory related bugs such as reads from unitialised memory, read or writes using dangling pointers or &lt;br /&gt;
memory leaks are difficult to detect by code inspection because they may invoive different code fragments &lt;br /&gt;
and exist in differnt modules or source code files. Compilers are of little help becuase it fails to &lt;br /&gt;
disambiguate pointers. Hence, in practice memory bug detection relies on run time checkers that insert&lt;br /&gt;
monitor code to the application during testing. In CMPs, the program which detects the memory bugs can run&lt;br /&gt;
as a helper thread.&lt;br /&gt;
 Ex: Heapmon, a memory bug checker monitors application heap space to detect heap memory bugs. The memory &lt;br /&gt;
access events in the application thread are automatically forwarded to helper thread using appropriate &lt;br /&gt;
hardware mechanisms. Also the redundant and unnecessary  memory accessess are filtered out. Hence the helper&lt;br /&gt;
thread approach completely decouples bug monitoring from appication execution and the filtering mechanism reduces&lt;br /&gt;
bug - check frequency. Conseqently, HeapMon achieves a very low performance overhead.&lt;br /&gt;
&lt;br /&gt;
Fault tolerance:&lt;br /&gt;
     The helper thread is a subset of main program. This partial redundancy can be used for detecting and recovering&lt;br /&gt;
from transient hardware faults.&lt;br /&gt;
&lt;br /&gt;
Slipstream approach for helper threads:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Disadvantages of helper threads:&lt;br /&gt;
&lt;br /&gt;
  A very tight synchronisation is needed between the main thread and the helper threads in oder to keep them the proper distance ahead of main thread. If the helper threads are too far ahead, then they will cause cache thrashing by prefetching data and then replaing it with subsequent prefetches beofre the main thread can even use it. If they are not far enough ahead, they might not be able to prefetch cache lines in time. &lt;br /&gt;
&lt;br /&gt;
  Only certain types of single threaded programs can be sped up with these techniques. Most integer applications have regular data access patterns and hence there will be only few misses to eliminate. The applications with larger memory footprints are easily parellelisable and hence doesn't run on a single main thread. I floating point applications the data access patterns are fairly regular and hence can be prefetched easily using hardware or software prefetch mechanisms. Hence the range of programs that can be accelerated using helper threads is fairly limited.&lt;/div&gt;</summary>
		<author><name>Lreddy</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki2_helperThreads&amp;diff=9993</id>
		<title>CSC/ECE 506 Fall 2007/wiki2 helperThreads</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki2_helperThreads&amp;diff=9993"/>
		<updated>2007-11-28T15:28:46Z</updated>

		<summary type="html">&lt;p&gt;Lreddy: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;A helper thread is a thread that does some of the work of the main thread in advance of the main thread so that the main thread can work more quickly. The Olukotun text only scratches the surface on all the different ways that helper threads can be used. Survey these ways, making sure to include the Slipstream approach developed at NCSU.&lt;br /&gt;
&lt;br /&gt;
What is a helper thread?&lt;br /&gt;
&lt;br /&gt;
The potential of chip multiprocessors (CMPs) can be exploited in a better way if the applications are&lt;br /&gt;
divided into semi - independent parts, or threads that can operate simultaneously across the processors &lt;br /&gt;
within a system. The simplest way to use parallel threads within a CMP to increase the performance of a &lt;br /&gt;
single thread is to have helper threads. A 'helper' thread performs work on behalf of main thread in an &lt;br /&gt;
effort to accelerate its performance.&lt;br /&gt;
&lt;br /&gt;
Uses of helper threads:&lt;br /&gt;
&lt;br /&gt;
1) Predicting branch at early stages: &lt;br /&gt;
       Helper threads are made up of program copies of the main thread stripped of all unessential parts &lt;br /&gt;
which are not of absolute necessity for the helper thread to achieve it tasks. Hence helper threads runs &lt;br /&gt;
ahead of main thread. Hence helper threads run ahead of main thread. Hence helper threads can do &lt;br /&gt;
computations that are necessary to decide the direction of the branch. This will inturn remove branch &lt;br /&gt;
mispredictions which may occur when branch predictions are used.&lt;br /&gt;
&lt;br /&gt;
2)Prefetching of Data:  . &lt;br /&gt;
     Since helper threads run ahead of main thread, they can predict the which data in memory is needed in&lt;br /&gt;
 future by the main thread.they prefetch the data required by the main thread. The helper thread prefetches&lt;br /&gt;
 the data and places it in the nearest cache accessible to the main thread. This avoids most of the L1 cache&lt;br /&gt;
 misses that would have been encountered by the main thread had if helper thread was not present. As the &lt;br /&gt;
 memory latency is reduced, the execution of main thread speeds up.&lt;br /&gt;
   &lt;br /&gt;
3)Memory Bug Reduction:&lt;br /&gt;
      Memory related bugs such as reads from unitialised memory, read or writes using dangling pointers or &lt;br /&gt;
memory leaks are difficult to detect by code inspection because they may invoive different code fragments &lt;br /&gt;
and exist in differnt modules or source code files. Compilers are of little help becuase it fails to &lt;br /&gt;
disambiguate pointers. Hence, in practice memory bug detection relies on run time checkers that insert&lt;br /&gt;
monitor code to the application during testing. In CMPs, the program which detects the memory bugs can run&lt;br /&gt;
as a helper thread.&lt;br /&gt;
 Ex: Heapmon, a memory bug checker monitors application heap space to detect heap memory bugs. The memory &lt;br /&gt;
access events in the application thread are automatically forwarded to helper thread using appropriate &lt;br /&gt;
hardware mechanisms. Also the redundant and unnecessary  memory accessess are filtered out. Hence the helper&lt;br /&gt;
thread approach completely decouples bug monitoring from appication execution and the filtering mechanism reduces&lt;br /&gt;
bug - check frequency. Conseqently, HeapMon achieves a very low performance overhead.&lt;br /&gt;
&lt;br /&gt;
4)Fault tolerance:&lt;br /&gt;
     The helper thread is a subset of main program. This partial redundancy can be used for detecting and recovering&lt;br /&gt;
from transient hardware faults.&lt;br /&gt;
&lt;br /&gt;
Slipstream approach for helper threads:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Disadvantages of helper threads:&lt;br /&gt;
1) A very tight synchronisation is needed between the main thread and the helper threads in oder to keep them the proper distance ahead of main thread. If the helper threads are too far ahead, then they will cause cache thrashing by prefetching data and then replaing it with subsequent prefetches beofre the main thread can even use it. If they are not far enough ahead, they might not be able to prefetch cache lines in time. &lt;br /&gt;
&lt;br /&gt;
2)Only certain types of single threaded programs can be sped up with these techniques. Most integer applications have regular data access patterns and hence there will be only few misses to eliminate. The applications with larger memory footprints are easily parellelisable and hence doesn't run on a single main thread. I floating point applications the data access patterns are fairly regular and hence can be prefetched easily using hardware or software prefetch mechanisms. Hence the range of programs that can be accelerated using helper threads is fairly limited.&lt;/div&gt;</summary>
		<author><name>Lreddy</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki2_helperThreads&amp;diff=9990</id>
		<title>CSC/ECE 506 Fall 2007/wiki2 helperThreads</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki2_helperThreads&amp;diff=9990"/>
		<updated>2007-11-28T15:25:44Z</updated>

		<summary type="html">&lt;p&gt;Lreddy: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;A helper thread is a thread that does some of the work of the main thread in advance of the main thread so that the main thread can work more quickly. The Olukotun text only scratches the surface on all the different ways that helper threads can be used. Survey these ways, making sure to include the Slipstream approach developed at NCSU.&lt;br /&gt;
&lt;br /&gt;
What is a helper thread?&lt;br /&gt;
&lt;br /&gt;
The potential of chip multiprocessors (CMPs) can be exploited in a better way if the applications are divided into semi - independent parts, or threads that can operate simultaneously across the processors within a system. The simplest way to use parallel threads within a CMP to increase the performance of a single thread is to have helper threads. A 'helper' thread performs work on behalf of main thread in an effort to accelerate its performance.&lt;br /&gt;
&lt;br /&gt;
Uses of helper threads:&lt;br /&gt;
&lt;br /&gt;
1) Predicting branch at early stages: &lt;br /&gt;
       Helper threads are made up of program copies of the main thread stripped of all unessential parts which are not of absolute necessity for the helper thread to achieve it tasks. Hence helper threads runs ahead of main thread. Hence helper threads run ahead of main thread. Hence helper threads can do computations that are necessary to decide the direction of the branch. This will inturn remove branch mispredictions which may occur when branch predictions are used.&lt;br /&gt;
&lt;br /&gt;
2)Prefetching of Data:  . &lt;br /&gt;
     Since helper threads run ahead of main thread, they can predict the which data in memory is needed in future by the main thread.they prefetch the data required by the main thread. The helper thread prefetches the data and places it in the nearest cache accessible to the main thread. This avoids most of the L1 cache misses that would have been encountered by the main thread had if helper thread was not present. As the memory latency is reduced, the execution of main thread speeds up.&lt;br /&gt;
   &lt;br /&gt;
3)Memory Bug Reduction:&lt;br /&gt;
      Memory related bugs such as reads from unitialised memory, read or writes using dangling pointers or memory leaks are difficult to detect by code inspection because they may invoive different code fragments and exist in differnt modules or source code files. Compilers are of little help becuase it fails to disambiguate pointers. Hence, in practice memory bug detection relies on run time checkers that insert monitor code to the application during testing. In CMPs, the program which detects the memory bugs can run as a helper thread.&lt;br /&gt;
 Ex: Heapmon, a memory bug checker monitors application heap space to detect heap memory bugs. The memory access events in the application thread are automatically forwarded to helper thread using appropriate hardware mechanisms. Also the redundant and unnecessary  memory accessess are filtered out. Hence the helper thread approach completely decouples bug monitoring from appication execution and the filtering mechanism reduces bug - check frequency. Conseqently, HeapMon achieves a very low performance overhead.&lt;br /&gt;
&lt;br /&gt;
4)Fault tolerance:&lt;br /&gt;
     The helper thread is a subset of main program. This partial redundancy can be used for detecting and recovering from transient hardware faults.&lt;br /&gt;
&lt;br /&gt;
Slipstream approach for helper threads:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Disadvantages of helper threads:&lt;br /&gt;
1) A very tight synchronisation is needed between the main thread and the helper threads in oder to keep them the proper distance ahead of main thread. If the helper threads are too far ahead, then they will cause cache thrashing by prefetching data and then replaing it with subsequent prefetches beofre the main thread can even use it. If they are not far enough ahead, they might not be able to prefetch cache lines in time. &lt;br /&gt;
&lt;br /&gt;
2)Only certain types of single threaded programs can be sped up with these techniques. Most integer applications have regular data access patterns and hence there will be only few misses to eliminate. The applications with larger memory footprints are easily parellelisable and hence doesn't run on a single main thread. I floating point applications the data access patterns are fairly regular and hence can be prefetched easily using hardware or software prefetch mechanisms. Hence the range of programs that can be accelerated using helper threads is fairly limited.&lt;/div&gt;</summary>
		<author><name>Lreddy</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki1_1.3.3_1.3.4_chase2007&amp;diff=3488</id>
		<title>CSC/ECE 506 Fall 2007/wiki1 1.3.3 1.3.4 chase2007</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki1_1.3.3_1.3.4_chase2007&amp;diff=3488"/>
		<updated>2007-09-11T02:48:10Z</updated>

		<summary type="html">&lt;p&gt;Lreddy: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==&amp;lt;u&amp;gt;'''Introduction to Parallel Computer Architecture -&amp;gt;Fundamental Design Issues -&amp;gt; Communication and Replication (section 1.3.3)'''&amp;lt;/u&amp;gt;==&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Communication and Replication&amp;lt;/u&amp;gt;&amp;lt;br&amp;gt;===&lt;br /&gt;
'''Communicationa and replication are inherently related.To be clear on the relationship of communication and replication, it is important to distinguish several concepts. When a program performs a write, it binds a data value to an address. The data resides in some physical storage element in the machine. A &amp;lt;u&amp;gt;data transfer&amp;lt;/u&amp;gt; occurs whenever data in one storage element is transferred into another. This doesnot necessarily change the bindings of the addresses and values. The same data may reside in multiple physical locations as it does in the uniprosessor storage heirarchy, but the one nearest to the processor is the only one that the processor can observe. If it is updated, the other hidden replicas including the actual memory location, must eventually be updated.Copying data binds a new set of addresses to the sane set of values. Generally, this will cause data transfers.Once the copy has been made, the two sets of bindings are completely independent.Hence, Replication is the creation of a local copy of data to help enable parallelism. Replication helps to avoid unnecessary communication.&amp;lt;br&amp;gt;'''&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''&amp;lt;u&amp;gt;Communication&amp;lt;/u&amp;gt; occurs when data written from one process is read by another process. This may cause data transfer within the machine, either on the write or the read,or the data transfer may occur for other reasons.Communication may involve establishing a new binding or not doing so, depending on the particular communication abstraction.'''&lt;br /&gt;
&lt;br /&gt;
==&amp;lt;u&amp;gt;'''Introduction to Parallel Computer Architecture -&amp;gt;Fundamental Design Issues -&amp;gt; Performance (section 1.3.4)'''&amp;lt;/u&amp;gt;==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Computer Performance:&amp;lt;/u&amp;gt;&amp;lt;br&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''Computer performance is a measure of the output of a computer with with respect to time and resources used.'''&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Performance metrics:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''Following are the important metrics used to measure a computer's performance:'''&lt;br /&gt;
&lt;br /&gt;
'''1.&amp;lt;u&amp;gt;Latency:'''&amp;lt;/u&amp;gt; '''The time taken to perform an operation'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''2.&amp;lt;u&amp;gt;Bandwidth:'''&amp;lt;/u&amp;gt;'''The rate at which the operations are performed'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''3.&amp;lt;u&amp;gt;Cost:'''&amp;lt;/u&amp;gt; '''The impact these operations have on the execution time of the program'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''4.&amp;lt;u&amp;gt;Saturation Point:&amp;lt;/u&amp;gt; In performance of a parallel system there is a point that is reached where the system can not keep up with the load on it.  At this point response times will go to infinity.  This point is where the load on the system completely utilizes the most scarce resource, often the cpu.&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''5.&amp;lt;u&amp;gt;Scaleability:&amp;lt;/u&amp;gt; Often a parallel system is not rated by its speed alone, but instead based on how it performes with varying loads.  A system that is scaleable will have a gradual increase in response times untill it reaches saturation.&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''6.&amp;lt;u&amp;gt;Load:&amp;lt;/u&amp;gt; The load on a parallel system is the measure of the work/time that is required of the system.  It is relative to the number of actions taking place as well as the time between those actions and the complexity of each action.&amp;lt;BR&amp;gt;'''&lt;br /&gt;
 &lt;br /&gt;
'''In the context of parallel computers, communication and synchonisation between the processors become very important considerations.The communication between the processors that occurs mostly in the form of data transfers between the processors. So, the performance of a parallel computer is modeled considering the follwoing criteria'''&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt; 1.Data Transfer Time:&amp;lt;/u&amp;gt;===&lt;br /&gt;
'''It is the time taken for initiation of a data transfer and the time required for actual data transfer.  So the Data Transfer Time can be given as:'''&lt;br /&gt;
        &lt;br /&gt;
'''Transfer Time (n) = T+(n/B)'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''where'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''n = Amount of Data (in bytes)'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''B = Transfer Rate of the component moving the data (bytes per second)'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''T = Start up cost, a constant'''&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
'''This is a very convinient model, and it is used to describe a diverse collection of operations, including messages, memory accesses, bus transactions, and vector operations. For message passing, the start up cost can be thought of as the time for the first bit to get to the destination. For memory operations, it is essentially the access time. For bus transactions, it reflects the bus arbitration and command phases. For any sort of pipelinedoperation, including pipelined instruction processing or vector operations, it is the time to fill the pipeline.'''&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;2.Overhead and Occupancy:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''The data transfer operations are initiated by the processor through communication assist. The essential components of this operation can be described by the following simple model. This model is very generic and can be used to explain data transfers in many places in modern, highly pipelined computer systems.:'''&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
'''Communication Time = Overhead+Occupancy+Network Delay'''&lt;br /&gt;
&lt;br /&gt;
'''The overhead is the time the processor spends initiating the transfer of data. This may be a fixed cost, if the processor imply has to tell the communication assist to start. The overhead can also be linear with Tranfer time, if the processor has to copy the data into the assist.The key point is that this is time the processor is busy with the communication event; it cannot do other useful work to initiate other communication during this time. Thr ramaining portion of the communication time is considered as network latency; it is the part that can be hidden by other processor operations'''&lt;br /&gt;
&lt;br /&gt;
'''The occupancy is the time it takes for the data to pass through the slowest componant on the communication path.The data wol occupy oyher resources, including buffers,switches, and the communication assist. Often the communication assist is the bottleneck that determines the occupancy. The occupancy limits how frequently communication operations can be initiated.The next data transfer will have to wait untill the critical resource is no longer occupied before it can use the same resource. If there is buffering between the processor and the bottleneck, the processor may be able to issue a burst of transfers at a frequency greater than I/O occupancy; however, once this buffer is full, the processor must slow to the rate set by the occupancy. A new transfer can start only when an older one finishes'''&lt;br /&gt;
&lt;br /&gt;
'''The remaining communication time is lumped into the network dealy,which includes the time  for the bit to be routed across the actual network as well as many other factors, such as the time to get through communication assists. &lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;3.Communication Cost:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''It is the time that the processor spends in communicating with other processors. It can be given by the following:'''&lt;br /&gt;
&lt;br /&gt;
'''Communication Cost = Frequency of Communication * (Communication Time - Overlap)'''&lt;br /&gt;
&lt;br /&gt;
'''&amp;lt;br&amp;gt;Frequency of Communication = Number of communications per unit of work&amp;lt;br&amp;gt;'''&lt;br /&gt;
'''&amp;lt;br&amp;gt;Communication Time = Overhead + Occupancy + Network Delay&amp;lt;br&amp;gt;'''&lt;br /&gt;
'''&amp;lt;br&amp;gt;Overlap = The portion of the communication operation that is performed concurrently with other useful work.&amp;lt;br&amp;gt;'''&lt;br /&gt;
&lt;br /&gt;
'''Frequency of communication depends on many programming factors and many hardware design factors.In particular, hardware may limit the transfer size and thereby determine the minimum number of messages. It may automatically replicate data or migrate it to  where it is used. However, a certain amount of communication is inherent to parallel execution since data must be shared and processors must coordinate their work. In general, for a machine to support programs with a high communication frequency, the other parts of the communication cost equation must be small - low overhead, low network delay, and small occupancy.'''&lt;br /&gt;
&lt;br /&gt;
'''The overlap is the portion of the communication coperation that is performed caoncurrently with other useful work, including computation or other communication time. The reduction of the effective cost is possible because much of the communication time involves work done by the components of the system other than the processor such as the communication assist, the bus, the network, or the remote processor or memory.Overlapping communicationw ith oether work is a form of small-scale parallelism, as is the instruction-level parallelism exploited by fast microprocessors.In effect, some available parallelism will be invested  to hide the actual cost of communication.'''&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;References:&amp;lt;/u&amp;gt;===&lt;br /&gt;
'''Parallel Computer Architecture- A Hardware/Software Approach by David E Culler, Jaswinder Pal Singh and Anoop Guptha'''&amp;lt;br/&amp;gt;&lt;br /&gt;
   &lt;br /&gt;
http://en.wikipedia.org/wiki/Computer_performance&lt;/div&gt;</summary>
		<author><name>Lreddy</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki1_1.3.3_1.3.4_chase2007&amp;diff=3481</id>
		<title>CSC/ECE 506 Fall 2007/wiki1 1.3.3 1.3.4 chase2007</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki1_1.3.3_1.3.4_chase2007&amp;diff=3481"/>
		<updated>2007-09-11T02:44:22Z</updated>

		<summary type="html">&lt;p&gt;Lreddy: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==&amp;lt;u&amp;gt;'''Introduction to Parallel Computer Architecture -&amp;gt;Fundamental Design Issues -&amp;gt; Communication and Replication (section 1.3.3)'''&amp;lt;/u&amp;gt;==&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Communication and Replication&amp;lt;/u&amp;gt;&amp;lt;br&amp;gt;===&lt;br /&gt;
'''Communicationa and replication are inherently related.To be clear on the relationship of communication and replication, it is important to distinguish several concepts. When a program performs a write, it binds a data value to an address. The data resides in some physical storage element in the machine. A &amp;lt;u&amp;gt;data transfer&amp;lt;/u&amp;gt; occurs whenever data in one storage element is transferred into another. This doesnot necessarily change the bindings of the addresses and values. The same data may reside in multiple physical locations as it does in the uniprosessor storage heirarchy, but the one nearest to the processor is the only one that the processor can observe. If it is updated, the other hidden replicas including the actual memory location, must eventually be updated.Copying data binds a new set of addresses to the sane set of values. Generally, this will cause data transfers.Once the copy has been made, the two sets of bindings are completely independent.Hence, Replication is the creation of a local copy of data to help enable parallelism. Replication helps to avoid unnecessary communication.&amp;lt;br&amp;gt;'''&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''&amp;lt;u&amp;gt;Communication&amp;lt;/u&amp;gt; occurs when data written from one process is read by another process. This may cause data transfer within the machine, either on the write or the read,or the data transfer may occur for other reasons.Communication may involve establishing a new binding or not doing so, depending on the particular communication abstraction.'''&lt;br /&gt;
&lt;br /&gt;
==&amp;lt;u&amp;gt;'''Introduction to Parallel Computer Architecture -&amp;gt;Fundamental Design Issues -&amp;gt; Performance (section 1.3.4)'''&amp;lt;/u&amp;gt;==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Computer Performance:&amp;lt;/u&amp;gt;&amp;lt;br&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''Computer performance is a measure of the output of a computer with with respect to time and resources used.'''&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Performance metrics:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''Following are the important metrics used to measure a computer's performance:'''&lt;br /&gt;
&lt;br /&gt;
'''1.&amp;lt;u&amp;gt;Latency:'''&amp;lt;/u&amp;gt; '''The time taken to perform an operation'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''2.&amp;lt;u&amp;gt;Bandwidth:'''&amp;lt;/u&amp;gt;'''The rate at which the operations are performed'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''3.&amp;lt;u&amp;gt;Cost:'''&amp;lt;/u&amp;gt; '''The impact these operations have on the execution time of the program'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''4.&amp;lt;u&amp;gt;Saturation Point:&amp;lt;/u&amp;gt; In performance of a parallel system there is a point that is reached where the system can not keep up with the load on it.  At this point response times will go to infinity.  This point is where the load on the system completely utilizes the most scarce resource, often the cpu.&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''5.&amp;lt;u&amp;gt;Scaleability:&amp;lt;/u&amp;gt; Often a parallel system is not rated by its speed alone, but instead based on how it performes with varying loads.  A system that is scaleable will have a gradual increase in response times untill it reaches saturation.&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''6.&amp;lt;u&amp;gt;Load:&amp;lt;/u&amp;gt; The load on a parallel system is the measure of the work/time that is required of the system.  It is relative to the number of actions taking place as well as the time between those actions and the complexity of each action.&amp;lt;BR&amp;gt;'''&lt;br /&gt;
 &lt;br /&gt;
'''In the context of parallel computers, communication and synchonisation between the processors become very important considerations.The communication between the processors that occurs mostly in the form of data transfers between the processors. So, the performance of a parallel computer is modeled considering the follwoing criteria'''&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Data Transfer Time:&amp;lt;/u&amp;gt;===&lt;br /&gt;
'''It is the time taken for initiation of a data transfer and the time required for actual data transfer.  So the Data Transfer Time can be given as:'''&lt;br /&gt;
        &lt;br /&gt;
'''Transfer Time (n) = T+(n/B)'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''where'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''n = Amount of Data (in bytes)'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''B = Transfer Rate of the component moving the data (bytes per second)'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''T = Start up cost, a constant'''&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
'''This is a very convinient model, and it is used to describe a diverse collection of operations, including messages, memory accesses, bus transactions, and vector operations. For message passing, the start up cost can be thought of as the time for the first bit to get to the destination. For memory operations, it is essentially the access time. For bus transactions, it reflects the bus arbitration and command phases. For any sort of pipelinedoperation, including pipelined instruction processing or vector operations, it is the time to fill the pipeline.'''&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Overhead and Occupancy:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''The data transfer operations are initiated by the processor through communication assist. The essential components of this operation can be described by the following simple model. This model is very generic and can be used to explain data transfers in many places in modern, highly pipelined computer systems.:'''&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
'''Communication Time = Overhead+Occupancy+Network Delay'''&lt;br /&gt;
&lt;br /&gt;
'''The overhead is the time the processor spends initiating the transfer of data. This may be a fixed cost, if the processor imply has to tell the communication assist to start. The overhead can also be linear with Tranfer time, if the processor has to copy the data into the assist.The key point is that this is time the processor is busy with the communication event; it cannot do other useful work to initiate other communication during this time. Thr ramaining portion of the communication time is considered as network latency; it is the part that can be hidden by other processor operations'''&lt;br /&gt;
&lt;br /&gt;
'''The occupancy is the time it takes for the data to pass through the slowest componant on the communication path.The data wol occupy oyher resources, including buffers,switches, and the communication assist. Often the communication assist is the bottleneck that determines the occupancy. The occupancy limits how frequently communication operations can be initiated.The next data transfer will have to wait untill the critical resource is no longer occupied before it can use the same resource. If there is buffering between the processor and the bottleneck, the processor may be able to issue a burst of transfers at a frequency greater than I/O occupancy; however, once this buffer is full, the processor must slow to the rate set by the occupancy. A new transfer can start only when an older one finishes'''&lt;br /&gt;
&lt;br /&gt;
'''The remaining communication time is lumped into the network dealy,which includes the time  for the bit to be routed across the actual network as well as many other factors, such as the time to get through communication assists. &lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Communication Cost:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''It is the time that the processor spends in communicating with other processors. It can be given by the following:'''&lt;br /&gt;
&lt;br /&gt;
'''Communication Cost = Frequency of Communication * (Communication Time - Overlap)'''&lt;br /&gt;
&lt;br /&gt;
'''&amp;lt;br&amp;gt;Frequency of Communication = Number of communications per unit of work&amp;lt;br&amp;gt;'''&lt;br /&gt;
'''&amp;lt;br&amp;gt;Communication Time = Overhead + Occupancy + Network Delay&amp;lt;br&amp;gt;'''&lt;br /&gt;
'''&amp;lt;br&amp;gt;Overlap = The portion of the communication operation that is performed concurrently with other useful work.&amp;lt;br&amp;gt;'''&lt;br /&gt;
&lt;br /&gt;
'''Frequency of communication depends on many programming factors and many hardware design factors.In particular, hardware may limit the transfer size and thereby determine the minimum number of messages. It may automatically replicate data or migrate it to  where it is used. However, a certain amount of communication is inherent to parallel execution since data must be shared and processors must coordinate their work. In general, for a machine to support programs with a high communication frequency, the other parts of the communication cost equation must be small - low overhead, low network delay, and small occupancy.'''&lt;br /&gt;
&lt;br /&gt;
'''The overlap is the portion of the communication coperation that is performed caoncurrently with other useful work, including computation or other communication time. The reduction of the effective cost is possible because much of the communication time involves work done by the components of the system other than the processor such as the communication assist, the bus, the network, or the remote processor or memory.Overlapping communicationw ith oether work is a form of small-scale parallelism, as is the instruction-level parallelism exploited by fast microprocessors.In effect, some available parallelism will be invested  to hide the actual cost of communication.'''&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;BSP Model:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''Bulk Synchronization Parallel Model:&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''The BSP model is a series of supersteps.&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''A superstep on a BSP machine is given by W + G*H + L&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''W is the maximum possible work for a given processor&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''H is the maximum bytes sent or recieved by a processor&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''G is the number of available processors&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''L is the time required for the barrier synchronization&amp;lt;BR&amp;gt;'''&lt;br /&gt;
&amp;lt;BR&amp;gt;&lt;br /&gt;
'''There are other similar variations of BSP like LogP&amp;lt;BR&amp;gt;'''&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;References:&amp;lt;/u&amp;gt;===&lt;br /&gt;
'''Parallel Computer Architecture- A Hardware/Software Approach by David E Culler, Jaswinder Pal Singh and Anoop Guptha'''&amp;lt;br/&amp;gt;&lt;br /&gt;
   &lt;br /&gt;
http://en.wikipedia.org/wiki/Computer_performance&lt;br /&gt;
&lt;br /&gt;
The BSP Model&lt;br /&gt;
http://wwwcs.uni-paderborn.de/fachbereich/AG/agmadh/WWW/bono/paper/nestedbsp/node6.html&lt;br /&gt;
&lt;br /&gt;
LogP: Towards a Realistic Model of Parallel Computation&lt;br /&gt;
http://cs315b-wiki.stanford.edu/images/8/8b/Logp.pdf&lt;/div&gt;</summary>
		<author><name>Lreddy</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki1_1.3.3_1.3.4_chase2007&amp;diff=3479</id>
		<title>CSC/ECE 506 Fall 2007/wiki1 1.3.3 1.3.4 chase2007</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki1_1.3.3_1.3.4_chase2007&amp;diff=3479"/>
		<updated>2007-09-11T02:40:31Z</updated>

		<summary type="html">&lt;p&gt;Lreddy: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==&amp;lt;u&amp;gt;'''Introduction to Parallel Computer Architecture -&amp;gt;Fundamental Design Issues -&amp;gt; Communication and Replication (section 1.3.3)'''&amp;lt;/u&amp;gt;==&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Communication and Replication&amp;lt;/u&amp;gt;&amp;lt;br&amp;gt;===&lt;br /&gt;
'''Communicationa and replication are inherently related.To be clear on the relationship of communication and replication, it is important to distinguish several concepts. When a program performs a write, it binds a data value to an address. The data resides in some physical storage element in the machine. A &amp;lt;u&amp;gt;data transfer&amp;lt;/u&amp;gt; occurs whenever data in one storage element is transferred into another. This doesnot necessarily change the bindings of the addresses and values. The same data may reside in multiple physical locations as it does in the uniprosessor storage heirarchy, but the one nearest to the processor is the only one that the processor can observe. If it is updated, the other hidden replicas including the actual memory location, must eventually be updated.Copying data binds a new set of addresses to the sane set of values. Generally, this will cause data transfers.Once the copy has been made, the two sets of bindings are completely independent.Hence, Replication is the creation of a local copy of data to help enable parallelism. Replication helps to avoid unnecessary communication.&amp;lt;br&amp;gt;'''&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''&amp;lt;u&amp;gt;Communication&amp;lt;/u&amp;gt; occurs when data written from one process is read by another process. This may cause data transfer within the machine, either on the write or the read,or the data transfer may occur for other reasons.Communication may involve establishing a new binding or not doing so, depending on the particular communication abstraction.'''&lt;br /&gt;
&lt;br /&gt;
==&amp;lt;u&amp;gt;'''Introduction to Parallel Computer Architecture -&amp;gt;Fundamental Design Issues -&amp;gt; Performance (section 1.3.4)'''&amp;lt;/u&amp;gt;==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Computer Performance:&amp;lt;/u&amp;gt;&amp;lt;br&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''Computer performance is a measure of the output of a computer with with respect to time and resources used.'''&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Performance metrics:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''Following are the important metrics used to measure a computer's performance:'''&lt;br /&gt;
&lt;br /&gt;
'''1.&amp;lt;u&amp;gt;Latency:'''&amp;lt;/u&amp;gt; '''The time taken to perform an operation'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''2.&amp;lt;u&amp;gt;Bandwidth:'''&amp;lt;/u&amp;gt;'''The rate at which the operations are performed'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''3.&amp;lt;u&amp;gt;Cost:'''&amp;lt;/u&amp;gt; '''The impact these operations have on the execution time of the program'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''4.&amp;lt;u&amp;gt;Saturation Point:&amp;lt;/u&amp;gt; In performance of a parallel system there is a point that is reached where the system can not keep up with the load on it.  At this point response times will go to infinity.  This point is where the load on the system completely utilizes the most scarce resource, often the cpu.&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''5.&amp;lt;u&amp;gt;Scaleability:&amp;lt;/u&amp;gt; Often a parallel system is not rated by its speed alone, but instead based on how it performes with varying loads.  A system that is scaleable will have a gradual increase in response times untill it reaches saturation.&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''6.&amp;lt;u&amp;gt;Load:&amp;lt;/u&amp;gt; The load on a parallel system is the measure of the work/time that is required of the system.  It is relative to the number of actions taking place as well as the time between those actions and the complexity of each action.&amp;lt;BR&amp;gt;'''&lt;br /&gt;
 &lt;br /&gt;
'''In the context of parallel computers, communication and synchonisation between the processors become very important considerations.The communication between the processors that occurs mostly in the form of data transfers between the processors. So, to completely define the performace of a parallel computer, the following metrics are also considered.'''&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Data Transfer Time:&amp;lt;/u&amp;gt;===&lt;br /&gt;
'''It is the time taken for initiation of a data transfer and the time required for actual data transfer.  So the Data Transfer Time can be given as:'''&lt;br /&gt;
        &lt;br /&gt;
'''Transfer Time (n) = T+(n/B)'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''where'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''n = Amount of Data (in bytes)'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''B = Transfer Rate of the component moving the data (bytes per second)'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''T = Start up cost, a constant'''&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
'''This is a very convinient model, and it is used to describe a diverse collection of operations, including messages, memory accesses, bus transactions, and vector operations. For message passing, the start up cost can be thought of as the time for the first bit to get to the destination. For memory operations, it is essentially the access time. For bus transactions, it reflects the bus arbitration and command phases. For any sort of pipelinedoperation, including pipelined instruction processing or vector operations, it is the time to fill the pipeline.'''&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Overhead and Occupancy:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''The data transfer operations are initiated by the processor through communication assist. The essential components of this operation can be described by the following simple model. This model is very generic and can be used to explain data transfers in many places in modern, highly pipelined computer systems.:'''&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
'''Communication Time = Overhead+Occupancy+Network Delay'''&lt;br /&gt;
&lt;br /&gt;
'''The overhead is the time the processor spends initiating the transfer of data. This may be a fixed cost, if the processor imply has to tell the communication assist to start. The overhead can also be linear with Tranfer time, if the processor has to copy the data into the assist.The key point is that this is time the processor is busy with the communication event; it cannot do other useful work to initiate other communication during this time. Thr ramaining portion of the communication time is considered as network latency; it is the part that can be hidden by other processor operations'''&lt;br /&gt;
&lt;br /&gt;
'''The occupancy is the time it takes for the data to pass through the slowest componant on the communication path.The data wol occupy oyher resources, including buffers,switches, and the communication assist. Often the communication assist is the bottleneck that determines the occupancy. The occupancy limits how frequently communication operations can be initiated.The next data transfer will have to wait untill the critical resource is no longer occupied before it can use the same resource. If there is buffering between the processor and the bottleneck, the processor may be able to issue a burst of transfers at a frequency greater than I/O occupancy; however, once this buffer is full, the processor must slow to the rate set by the occupancy. A new transfer can start only when an older one finishes'''&lt;br /&gt;
&lt;br /&gt;
'''The remaining communication time is lumped into the network dealy,which includes the time  for the bit to be routed across the actual network as well as many other factors, such as the time to get through communication assists. &lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Communication Cost:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''It is the time that the processor spends in communicating with other processors. It can be given by the following:'''&lt;br /&gt;
&lt;br /&gt;
'''Communication Cost = Frequency of Communication * (Communication Time - Overlap)'''&lt;br /&gt;
&lt;br /&gt;
'''&amp;lt;br&amp;gt;Frequency of Communication = Number of communications per unit of work&amp;lt;br&amp;gt;'''&lt;br /&gt;
'''&amp;lt;br&amp;gt;Communication Time = Overhead + Occupancy + Network Delay&amp;lt;br&amp;gt;'''&lt;br /&gt;
'''&amp;lt;br&amp;gt;Overlap = The portion of the communication operation that is performed concurrently with other useful work.&amp;lt;br&amp;gt;'''&lt;br /&gt;
&lt;br /&gt;
'''Frequency of communication depends on many programming factors and many hardware design factors.In particular, hardware may limit the transfer size and thereby determine the minimum number of messages. It may automatically replicate data or migrate it to  where it is used. However, a certain amount of communication is inherent to parallel execution since data must be shared and processors must coordinate their work. In general, for a machine to support programs with a high communication frequency, the other parts of the communication cost equation must be small - low overhead, low network delay, and small occupancy.'''&lt;br /&gt;
&lt;br /&gt;
'''The overlap is the portion of the communication coperation that is performed caoncurrently with other useful work, including computation or other communication time. The reduction of the effective cost is possible because much of the communication time involves work done by the components of the system other than the processor such as the communication assist, the bus, the network, or the remote processor or memory.Overlapping communicationw ith oether work is a form of small-scale parallelism, as is the instruction-level parallelism exploited by fast microprocessors.In effect, some available parallelism will be invested  to hide the actual cost of communication.'''&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;BSP Model:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''Bulk Synchronization Parallel Model:&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''The BSP model is a series of supersteps.&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''A superstep on a BSP machine is given by W + G*H + L&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''W is the maximum possible work for a given processor&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''H is the maximum bytes sent or recieved by a processor&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''G is the number of available processors&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''L is the time required for the barrier synchronization&amp;lt;BR&amp;gt;'''&lt;br /&gt;
&amp;lt;BR&amp;gt;&lt;br /&gt;
'''There are other similar variations of BSP like LogP&amp;lt;BR&amp;gt;'''&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;References:&amp;lt;/u&amp;gt;===&lt;br /&gt;
'''Parallel Computer Architecture- A Hardware/Software Approach by David E Culler, Jaswinder Pal Singh and Anoop Guptha'''&amp;lt;br/&amp;gt;&lt;br /&gt;
   &lt;br /&gt;
http://en.wikipedia.org/wiki/Computer_performance&lt;br /&gt;
&lt;br /&gt;
The BSP Model&lt;br /&gt;
http://wwwcs.uni-paderborn.de/fachbereich/AG/agmadh/WWW/bono/paper/nestedbsp/node6.html&lt;br /&gt;
&lt;br /&gt;
LogP: Towards a Realistic Model of Parallel Computation&lt;br /&gt;
http://cs315b-wiki.stanford.edu/images/8/8b/Logp.pdf&lt;/div&gt;</summary>
		<author><name>Lreddy</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki1_1.3.3_1.3.4_chase2007&amp;diff=3476</id>
		<title>CSC/ECE 506 Fall 2007/wiki1 1.3.3 1.3.4 chase2007</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki1_1.3.3_1.3.4_chase2007&amp;diff=3476"/>
		<updated>2007-09-11T02:39:29Z</updated>

		<summary type="html">&lt;p&gt;Lreddy: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==&amp;lt;u&amp;gt;'''Introduction to Parallel Computer Architecture -&amp;gt;Fundamental Design Issues -&amp;gt; Communication and Replication (section 1.3.3)'''&amp;lt;/u&amp;gt;==&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Communication and Replication&amp;lt;/u&amp;gt;&amp;lt;br&amp;gt;===&lt;br /&gt;
'''Communicationa and replication are inherently related.To be clear on the relationship of communication and replication, it is important to distinguish several concepts. When a program performs a write, it binds a data value to an address. The data resides in some physical storage element in the machine. A &amp;lt;u&amp;gt;data transfer&amp;lt;/u&amp;gt; occurs whenever data in one storage element is transferred into another. This doesnot necessarily change the bindings of the addresses and values. The same data may reside in multiple physical locations as it does in the uniprosessor storage heirarchy, but the one nearest to the processor is the only one that the processor can observe. If it is updated, the other hidden replicas including the actual memory location, must eventually be updated.Copying data binds a new set of addresses to the sane set of values. Generally, this will cause data transfers.Once the copy has been made, the two sets of bindings are completely independent.Hence, Replication is the creation of a local copy of data to help enable parallelism. Replication helps to avoid unnecessary communication.&amp;lt;br&amp;gt;'''&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''&amp;lt;u&amp;gt;Communication&amp;lt;/u&amp;gt; occurs when data written from one process is read by another process. This may cause data transfer within the machine, either on the write or the read,or the data transfer may occur for other reasons.Communication may involve establishing a new binding or not doing so, depending on the particular communication abstraction.'''&lt;br /&gt;
&lt;br /&gt;
==&amp;lt;u&amp;gt;'''Introduction to Parallel Computer Architecture -&amp;gt;Fundamental Design Issues -&amp;gt; Performance (section 1.3.4)'''&amp;lt;/u&amp;gt;==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Computer Performance:&amp;lt;/u&amp;gt;&amp;lt;br&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''Computer performance is a measure of the output of a computer with with respect to time and resources used.'''&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Performance metrics:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''Following are the important metrics used to measure a computer's performance:'''&lt;br /&gt;
&lt;br /&gt;
'''1.&amp;lt;u&amp;gt;Latency:'''&amp;lt;/u&amp;gt; '''The time taken to perform an operation'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''2.&amp;lt;u&amp;gt;Bandwidth:'''&amp;lt;/u&amp;gt;'''The rate at which the operations are performed'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''3.&amp;lt;u&amp;gt;Cost:'''&amp;lt;/u&amp;gt; '''The impact these operations have on the execution time of the program'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''4.&amp;lt;u&amp;gt;Saturation Point:&amp;lt;/u&amp;gt; In performance of a parallel system there is a point that is reached where the system can not keep up with the load on it.  At this point response times will go to infinity.  This point is where the load on the system completely utilizes the most scarce resource, often the cpu.&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''5.&amp;lt;u&amp;gt;Scaleability:&amp;lt;/u&amp;gt; Often a parallel system is not rated by its speed alone, but instead based on how it performes with varying loads.  A system that is scaleable will have a gradual increase in response times untill it reaches saturation.&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''6.&amp;lt;u&amp;gt;Load:&amp;lt;/u&amp;gt; The load on a parallel system is the measure of the work/time that is required of the system.  It is relative to the number of actions taking place as well as the time between those actions and the complexity of each action.&amp;lt;BR&amp;gt;'''&lt;br /&gt;
 &lt;br /&gt;
'''In the context of parallel computers, communication and synchonisation between the processors become very important considerations.The communication between the processors that occurs mostly in the form of data transfers between the processors. So, to completely define the performace of a parallel computer, the following metrics are also considered.'''&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Data Transfer Time:&amp;lt;/u&amp;gt;===&lt;br /&gt;
'''It is the time taken for initiation of a data transfer and the time required for actual data transfer.  So the Data Transfer Time can be given as:'''&lt;br /&gt;
        &lt;br /&gt;
'''Transfer Time (n) = T+(n/B)'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''where'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''n = Amount of Data (in bytes)'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''B = Transfer Rate of the component moving the data (bytes per second)'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''T = Start up cost, a constant'''&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
'''This is a very convinient model, and it is used to describe a diverse collection of operations, including messages, memory accesses, bus transactions, and vector operations. For message passing, the start up cost can be thought of as the time for the first bit to get to the destination. For memory operations, it is essentially the access time. For bus transactions, it reflects the bus arbitration and command phases. For any sort of pipelinedoperation, including pipelined instruction processing or vector operations, it is the time to fill the pipeline.'''&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Overhead and Occupancy:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''The data transfer operations are initiated by the processor through communication assist. The essential components of this operation can be described by the following simple model. This model is very generic and can be used to explain data transfers in many places in modern, highly pipelined computer systems.:'''&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
'''Communication Time = Overhead+Occupancy+Network Delay'''&lt;br /&gt;
&lt;br /&gt;
'''The overhead is the time the processor spends initiating the transfer of data. This may be a fixed cost, if the processor imply has to tell the communication assist to start. The overhead can also be linear with Tranfer time, if the processor has to copy the data into the assist.The key point is that this is time the processor is busy with the communication event; it cannot do other useful work to initiate other communication during this time. Thr ramaining portion of the communication time is considered as network latency; it is the part that can be hidden by other processor operations'''&lt;br /&gt;
&lt;br /&gt;
'''The occupancy is the time it takes for the data to pass through the slowest componant on the communication path.The data wol occupy oyher resources, including buffers,switches, and the communication assist. Often the communication assist is the bottleneck that determines the occupancy. The occupancy limits how frequently communication operations can be initiated.The next data transfer will have to wait untill the critical resource is no longer occupied before it can use the same resource. If there is buffering between the processor and the bottleneck, the processor may be able to issue a burst of transfers at a frequency greater than I/O occupancy; however, once this buffer is full, the processor must slow to the rate set by the occupancy. A new transfer can start only when an older one finishes'''&lt;br /&gt;
&lt;br /&gt;
'''The remaining communication time is lumped into the network dealy,which includes the time  for the bit to be routed across the actual network as well as many other factors, such as the time to get through communication assists. &lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Communication Cost:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''It is the time that the processor spends in communicating with other processors. It can be given by the following:'''&lt;br /&gt;
&lt;br /&gt;
'''Communication Cost = Frequency of Communication * (Communication Time - Overlap)'''&lt;br /&gt;
&lt;br /&gt;
'''&amp;lt;br&amp;gt;Frequency of Communication = Number of communications per unit of work&amp;lt;br&amp;gt;'''&lt;br /&gt;
'''&amp;lt;br&amp;gt;Communication Time = Overhead + Occupancy + Network Delay&amp;lt;br&amp;gt;'''&lt;br /&gt;
'''&amp;lt;br&amp;gt;Overlap = The portion of the communication operation that is performed concurrently with other useful work.&amp;lt;br&amp;gt;'''&lt;br /&gt;
&lt;br /&gt;
'''Frequency of communication depends on many programming factors and many hardware design factors.In particular, hardware may limit the transfer size and thereby determine the minimum number of messages. It may automatically replicate data or migrate it to  where it is used. However, a certain amount of communication is inherent to parallel execution since data must be shared and processors must coordinate their work. In general, for a machine to support programs with a high communication frequency, the other parts of the communication cost equation must be small - low overhead, low network delay, and small occupancy.'''&lt;br /&gt;
&lt;br /&gt;
'''The overlap is the portion of the communication coperation that is performed caoncurrently with other useful work, including computation or other communication time. The reduction of the effective cost is possible because much of the communication time involves work done by the components of the system other than the processor such as the communication assist, the bus, the network, or the remote processor or memory.Overlapping communicationw ith oether work is a form of small-scale parallelism, as is the instruction-level parallelism exploited by fast microprocessors.In effect, some available parallelism will be invested  to hide the actual cost of communication.'''&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;BSP Model:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''Bulk Synchronization Parallel Model:&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''The BSP model is a series of supersteps.&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''A superstep on a BSP machine is given by W + G*H + L&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''W is the maximum possible work for a given processor&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''H is the maximum bytes sent or recieved by a processor&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''G is the number of available processors&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''L is the time required for the barrier synchronization&amp;lt;BR&amp;gt;'''&lt;br /&gt;
&amp;lt;BR&amp;gt;&lt;br /&gt;
'''There are other similar variations of BSP like LogP&amp;lt;BR&amp;gt;'''&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Terminology:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;References:&amp;lt;/u&amp;gt;===&lt;br /&gt;
'''Parallel Computer Architecture- A Hardware/Software Approach by David E Culler, Jaswinder Pal Singh and Anoop Guptha'''&amp;lt;br/&amp;gt;&lt;br /&gt;
   &lt;br /&gt;
http://en.wikipedia.org/wiki/Computer_performance&lt;br /&gt;
&lt;br /&gt;
The BSP Model&lt;br /&gt;
http://wwwcs.uni-paderborn.de/fachbereich/AG/agmadh/WWW/bono/paper/nestedbsp/node6.html&lt;br /&gt;
&lt;br /&gt;
LogP: Towards a Realistic Model of Parallel Computation&lt;br /&gt;
http://cs315b-wiki.stanford.edu/images/8/8b/Logp.pdf&lt;/div&gt;</summary>
		<author><name>Lreddy</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki1_1.3.3_1.3.4_chase2007&amp;diff=3472</id>
		<title>CSC/ECE 506 Fall 2007/wiki1 1.3.3 1.3.4 chase2007</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki1_1.3.3_1.3.4_chase2007&amp;diff=3472"/>
		<updated>2007-09-11T02:34:33Z</updated>

		<summary type="html">&lt;p&gt;Lreddy: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==&amp;lt;u&amp;gt;'''Introduction to Parallel Computer Architecture -&amp;gt;Fundamental Design Issues -&amp;gt; Communication and Replication (section 1.3.3)'''&amp;lt;/u&amp;gt;==&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Communication and Replication&amp;lt;/u&amp;gt;&amp;lt;br&amp;gt;===&lt;br /&gt;
'''Communicationa and replication are inherently related.To be clear on the relationship of communication and replication, it is important to distinguish several concepts. When a program performs a write, it binds a data value to an address. The data resides in some physical storage element in the machine. A &amp;lt;u&amp;gt;data transfer&amp;lt;/u&amp;gt; occurs whenever data in one storage element is transferred into another. This doesnot necessarily change the bindings of the addresses and values. The same data may reside in multiple physical locations as it does in the uniprosessor storage heirarchy, but the one nearest to the processor is the only one that the processor can observe. If it is updated, the other hidden replicas including the actual memory location, must eventually be updated.Copying data binds a new set of addresses to the sane set of values. Generally, this will cause data transfers.Once the copy has been made, the two sets of bindings are completely independent.Hence, Replication is the creation of a local copy of data to help enable parallelism. Replication helps to avoid unnecessary communication.&amp;lt;br&amp;gt;'''&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''&amp;lt;u&amp;gt;Communication&amp;lt;/u&amp;gt; occurs when data written from one process is read by another process. This may cause data transfer within the machine, either on the write or the read,or the data transfer may occur for other reasons.Communication may involve establishing a new binding or not doing so, depending on the particular communication abstraction.'''&lt;br /&gt;
&lt;br /&gt;
==&amp;lt;u&amp;gt;'''Introduction to Parallel Computer Architecture -&amp;gt;Fundamental Design Issues -&amp;gt; Performance (section 1.3.4)'''&amp;lt;/u&amp;gt;==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Computer Performance:&amp;lt;/u&amp;gt;&amp;lt;br&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''Computer performance is a measure of the output of a computer with with respect to time and resources used.'''&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Performance metrics:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''Following are the important metrics used to measure a computer's performance:'''&lt;br /&gt;
&lt;br /&gt;
'''1.&amp;lt;u&amp;gt;Latency:'''&amp;lt;/u&amp;gt; '''The time taken to perform an operation'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''2.&amp;lt;u&amp;gt;Bandwidth:'''&amp;lt;/u&amp;gt;'''The rate at which the operations are performed'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''3.&amp;lt;u&amp;gt;Cost:'''&amp;lt;/u&amp;gt; '''The impact these operations have on the execution time of the program'''&amp;lt;br&amp;gt;&lt;br /&gt;
 &lt;br /&gt;
'''All the above metrics can be used to define a uniprocessor systems where a single CPU operates.'''&lt;br /&gt;
&lt;br /&gt;
'''However, in the context of parallel computers, it becomes difficult to express the performance in above stated metrics. The reason for this is the communication between the processors that occurs mostly in the form of data transfers between the processors. So, to completely define the performace of a parallel computer, the following metrics are also considered.'''&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Data Transfer Time:&amp;lt;/u&amp;gt;===&lt;br /&gt;
'''It is the time taken for initiation of a data transfer and the time required for actual data transfer.  So the Data Transfer Time can be given as:'''&lt;br /&gt;
        &lt;br /&gt;
'''Transfer Time (n) = T+(n/B)'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''where'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''n = Amount of Data (in bytes)'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''B = Transfer Rate of the component moving the data (bytes per second)'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''T = Start up cost, a constant'''&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
'''This is a very convinient model, and it is used to describe a diverse collection of operations, including messages, memory accesses, bus transactions, and vector operations. For message passing, the start up cost can be thought of as the time for the first bit to get to the destination. For memory operations, it is essentially the access time. For bus transactions, it reflects the bus arbitration and command phases. For any sort of pipelinedoperation, including pipelined instruction processing or vector operations, it is the time to fill the pipeline.'''&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Overhead and Occupancy:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''The data transfer operations are initiated by the processor through communication assist. The essential components of this operation can be described by the following simple model. This model is very generic and can be used to explain data transfers in many places in modern, highly pipelined computer systems.:'''&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
'''Communication Time = Overhead+Occupancy+Network Delay'''&lt;br /&gt;
&lt;br /&gt;
'''The overhead is the time the processor spends initiating the transfer of data. This may be a fixed cost, if the processor imply has to tell the communication assist to start. The overhead can also be linear with Tranfer time, if the processor has to copy the data into the assist.The key point is that this is time the processor is busy with the communication event; it cannot do other useful work to initiate other communication during this time. Thr ramaining portion of the communication time is considered as network latency; it is the part that can be hidden by other processor operations'''&lt;br /&gt;
&lt;br /&gt;
'''The occupancy is the time it takes for the data to pass through the slowest componant on the communication path.The data wol occupy oyher resources, including buffers,switches, and the communication assist. Often the communication assist is the bottleneck that determines the occupancy. The occupancy limits how frequently communication operations can be initiated.The next data transfer will have to wait untill the critical resource is no longer occupied before it can use the same resource. If there is buffering between the processor and the bottleneck, the processor may be able to issue a burst of transfers at a frequency greater than I/O occupancy; however, once this buffer is full, the processor must slow to the rate set by the occupancy. A new transfer can start only when an older one finishes'''&lt;br /&gt;
&lt;br /&gt;
'''The remaining communication time is lumped into the network dealy,which includes the time  for the bit to be routed across the actual network as well as many other factors, such as the time to get through communication assists. &lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Communication Cost:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''It is the time that the processor spends in communicating with other processors. It can be given by the following:'''&lt;br /&gt;
&lt;br /&gt;
'''Communication Cost = Frequency of Communication * (Communication Time - Overlap)'''&lt;br /&gt;
&lt;br /&gt;
'''&amp;lt;br&amp;gt;Frequency of Communication = Number of communications per unit of work&amp;lt;br&amp;gt;'''&lt;br /&gt;
'''&amp;lt;br&amp;gt;Communication Time = Overhead + Occupancy + Network Delay&amp;lt;br&amp;gt;'''&lt;br /&gt;
'''&amp;lt;br&amp;gt;Overlap = The portion of the communication operation that is performed concurrently with other useful work.&amp;lt;br&amp;gt;'''&lt;br /&gt;
&lt;br /&gt;
'''Frequency of communication depends on many programming factors and many hardware design factors.In particular, hardware may limit the transfer size and thereby determine the minimum number of messages. It may automatically replicate data or migrate it to  where it is used. However, a certain amount of communication is inherent to parallel execution since data must be shared and processors must coordinate their work. In general, for a machine to support programs with a high communication frequency, the other parts of the communication cost equation must be small - low overhead, low network delay, and small occupancy.'''&lt;br /&gt;
&lt;br /&gt;
'''The overlap is the portion of the communication coperation that is performed caoncurrently with other useful work, including computation or other communication time. The reduction of the effective cost is possible because much of the communication time involves work done by the components of the system other than the processor such as the communication assist, the bus, the network, or the remote processor or memory.Overlapping communicationw ith oether work is a form of small-scale parallelism, as is the instruction-level parallelism exploited by fast microprocessors.In effect, some available parallelism will be invested  to hide the actual cost of communication.'''&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;BSP Model:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''Bulk Synchronization Parallel Model:&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''The BSP model is a series of supersteps.&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''A superstep on a BSP machine is given by W + G*H + L&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''W is the maximum possible work for a given processor&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''H is the maximum bytes sent or recieved by a processor&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''G is the number of available processors&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''L is the time required for the barrier synchronization&amp;lt;BR&amp;gt;'''&lt;br /&gt;
&amp;lt;BR&amp;gt;&lt;br /&gt;
'''There are other similar variations of BSP like LogP&amp;lt;BR&amp;gt;'''&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Terminology:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''&amp;lt;u&amp;gt;Saturation Point:&amp;lt;/u&amp;gt; In performance of a parallel system there is a point that is reached where the system can not keep up with the load on it.  At this point response times will go to infinity.  This point is where the load on the system completely utilizes the most scarce resource, often the cpu.&amp;lt;BR&amp;gt;'''&lt;br /&gt;
&lt;br /&gt;
'''&amp;lt;u&amp;gt;Scaleability:&amp;lt;/u&amp;gt; Often a parallel system is not rated by its speed alone, but instead based on how it performes with varying loads.  A system that is scaleable will have a gradual increase in response times untill it reaches saturation.&amp;lt;BR&amp;gt;'''&lt;br /&gt;
&lt;br /&gt;
'''&amp;lt;u&amp;gt;Load:&amp;lt;/u&amp;gt; The load on a parallel system is the measure of the work/time that is required of the system.  It is relative to the number of actions taking place as well as the time between those actions and the complexity of each action.&amp;lt;BR&amp;gt;'''&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;References:&amp;lt;/u&amp;gt;===&lt;br /&gt;
'''Parallel Computer Architecture- A Hardware/Software Approach by David E Culler, Jaswinder Pal Singh and Anoop Guptha'''&amp;lt;br/&amp;gt;&lt;br /&gt;
   &lt;br /&gt;
http://en.wikipedia.org/wiki/Computer_performance&lt;br /&gt;
&lt;br /&gt;
The BSP Model&lt;br /&gt;
http://wwwcs.uni-paderborn.de/fachbereich/AG/agmadh/WWW/bono/paper/nestedbsp/node6.html&lt;br /&gt;
&lt;br /&gt;
LogP: Towards a Realistic Model of Parallel Computation&lt;br /&gt;
http://cs315b-wiki.stanford.edu/images/8/8b/Logp.pdf&lt;/div&gt;</summary>
		<author><name>Lreddy</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki1_1.3.3_1.3.4_chase2007&amp;diff=3471</id>
		<title>CSC/ECE 506 Fall 2007/wiki1 1.3.3 1.3.4 chase2007</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki1_1.3.3_1.3.4_chase2007&amp;diff=3471"/>
		<updated>2007-09-11T02:32:35Z</updated>

		<summary type="html">&lt;p&gt;Lreddy: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==&amp;lt;u&amp;gt;'''Introduction to Parallel Computer Architecture -&amp;gt;Fundamental Design Issues -&amp;gt; Communication and Replication (section 1.3.3)'''&amp;lt;/u&amp;gt;==&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Communication and Replication&amp;lt;/u&amp;gt;&amp;lt;br&amp;gt;===&lt;br /&gt;
'''Communicationa and replication are inherently related.To be clear on the relationship of communication and replication, it is important to distinguish several concepts. When a program performs a write, it binds a data value to an address. The data resides in some physical storage element in the machine. A &amp;lt;u&amp;gt;data transfer&amp;lt;/u&amp;gt; occurs whenever data in one storage element is transferred into another. This doesnot necessarily change the bindings of the addresses and values. The same data may reside in multiple physical locations as it does in the uniprosessor storage heirarchy, but the one nearest to the processor is the only one that the processor can observe. If it is updated, the other hidden replicas including the actual memory location, must eventually be updated.Copying data binds a new set of addresses to the sane set of values. Generally, this will cause data transfers.Once the copy has been made, the two sets of bindings are completely independent.Hence, Replication is the creation of a local copy of data to help enable parallelism. Replication helps to avoid unnecessary communication.&amp;lt;br&amp;gt;'''&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''&amp;lt;u&amp;gt;Communication&amp;lt;/u&amp;gt; occurs when data written from one process is read by another process. This may cause data transfer within the machine, either on the write or the read,or the data transfer may occur for other reasons.Communication may involve establishing a new binding or not doing so, depending on the particular communication abstraction.'''&lt;br /&gt;
&lt;br /&gt;
==&amp;lt;u&amp;gt;'''Introduction to Parallel Computer Architecture -&amp;gt;Fundamental Design Issues -&amp;gt; Performance (section 1.3.4)'''&amp;lt;/u&amp;gt;==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Computer Performance:&amp;lt;/u&amp;gt;&amp;lt;br&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''Computer performance is a measure of the output of a computer with with respect to time and resources used.'''&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Performance metrics:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''Following are the important metrics used to measure a computer's performance:'''&lt;br /&gt;
&lt;br /&gt;
'''1.&amp;lt;u&amp;gt;Latency:'''&amp;lt;/u&amp;gt; '''The time taken to perform an operation'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''2.&amp;lt;u&amp;gt;Bandwidth:'''&amp;lt;/u&amp;gt;'''The rate at which the operations are performed'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''3.&amp;lt;u&amp;gt;Cost:'''&amp;lt;/u&amp;gt; '''The impact these operations have on the execution time of the program'''&amp;lt;br&amp;gt;&lt;br /&gt;
 &lt;br /&gt;
'''All the above metrics can be used to define a uniprocessor systems where a single CPU operates.'''&lt;br /&gt;
&lt;br /&gt;
'''However, in the context of parallel computers, it becomes difficult to express the performance in above stated metrics. The reason for this is the communication between the processors that occurs mostly in the form of data transfers between the processors. So, to completely define the performace of a parallel computer, the following metrics are also considered.'''&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Data Transfer Time:&amp;lt;/u&amp;gt;===&lt;br /&gt;
'''It is the time taken for initiation of a data transfer and the time required for actual data transfer.  So the Data Transfer Time can be given as:'''&lt;br /&gt;
        &lt;br /&gt;
'''Transfer Time (n) = T+(n/B)'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''where'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''n = Amount of Data (in bytes)'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''B = Transfer Rate of the component moving the data (bytes per second)'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''T = Start up cost, a constant'''&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
'''This is a very convinient model, and it is used to describe a diverse collection of operations, including messages, memory accesses, bus transactions, and vector operations. For message passing, the start up cost can be thought of as the time for the first bit to get to the destination. For memory operations, it is essentially the access time. For bus transactions, it reflects the bus arbitration and command phases. For any sort of pipelinedoperation, including pipelined instruction processing or vector operations, it is the time to fill the pipeline.'''&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Overhead and Occupancy:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''The data transfer operations are initiated by the processor through communication assist. The essential components of this operation can be described by the following simple model. This model is very generic and can be used to explain data transfers in many places in modern, highly pipelined computer systems.:'''&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
'''Communication Time = Overhead+Occupancy+Network Delay'''&lt;br /&gt;
&lt;br /&gt;
'''The overhead is the time the processor spends initiating the transfer of data. This may be a fixed cost, if the processor imply has to tell the communication assist to start. The overhead can also be linear with Tranfer time, if the processor has to copy the data into the assist.The key point is that this is time the processor is busy with the communication event; it cannot do other useful work to initiate other communication during this time. Thr ramaining portion of the communication time is considered as network latency; it is the part that can be hidden by other processor operations'''&lt;br /&gt;
&lt;br /&gt;
'''The occupancy is the time it takes for the data to pass through the slowest componant on the communication path.The data wol occupy oyher resources, including buffers,switches, and the communication assist. Often the communication assist is the bottleneck that determines the occupancy. The occupancy limits how frequently communication operations can be initiated.The next data transfer will have to wait untill the critical resource is no longer occupied before it can use the same resource. If there is buffering between the processor and the bottleneck, the processor may be able to issue a burst of transfers at a frequency greater than I/O occupancy; however, once this buffer is full, the processor must slow to the rate set by the occupancy. A new transfer can start only when an older one finishes'''&lt;br /&gt;
&lt;br /&gt;
'''The remaining communication time is lumped into the network dealy,which includes the time  for the bit to be routed across the actual network as well as many other factors, such as the time to get through communication assists. &lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Communication Cost:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''It is the time that the processor spends in communicating with other processors. It can be given by the following:'''&lt;br /&gt;
&lt;br /&gt;
'''Communication Cost = Frequency of Communication * (Communication Time - Overlap)'''&lt;br /&gt;
&lt;br /&gt;
'''Frequency of Communication = Number of communications per unit of work'''&lt;br /&gt;
'''Communication Time = Overhead + Occupancy + Network Delay'''&lt;br /&gt;
'''Overlap = The portion of the communication operation that is performed concurrently with other useful work.'''&lt;br /&gt;
&lt;br /&gt;
'''Frequency of communication depends on many programming factors and many hardware design factors.In particular, hardware may limit the transfer size and thereby determine the minimum number of messages. It may automatically replicate data or migrate it to  where it is used. However, a certain amount of communication is inherent to parallel execution since data must be shared and processors must coordinate their work. In general, for a machine to support programs with a high communication frequency, the other parts of the communication cost equation must be small - low overhead, low network delay, and small occupancy.'''&lt;br /&gt;
&lt;br /&gt;
'''The overlap is the portion of the communication coperation that is performed caoncurrently with other useful work, including computation or other communication time. The reduction of the effective cost is possible because much of the communication time involves work done by the components of the system other than the processor such as the communication assist, the bus, the network, or the remote processor or memory.Overlapping communicationw ith oether work is a form of small-scale parallelism, as is the instruction-level parallelism exploited by fast microprocessors.In effect, some available parallelism will be invested  to hide the actual cost of communication.'''&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;BSP Model:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''Bulk Synchronization Parallel Model:&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''The BSP model is a series of supersteps.&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''A superstep on a BSP machine is given by W + G*H + L&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''W is the maximum possible work for a given processor&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''H is the maximum bytes sent or recieved by a processor&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''G is the number of available processors&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''L is the time required for the barrier synchronization&amp;lt;BR&amp;gt;'''&lt;br /&gt;
&amp;lt;BR&amp;gt;&lt;br /&gt;
'''There are other similar variations of BSP like LogP&amp;lt;BR&amp;gt;'''&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Terminology:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''&amp;lt;u&amp;gt;Saturation Point:&amp;lt;/u&amp;gt; In performance of a parallel system there is a point that is reached where the system can not keep up with the load on it.  At this point response times will go to infinity.  This point is where the load on the system completely utilizes the most scarce resource, often the cpu.&amp;lt;BR&amp;gt;'''&lt;br /&gt;
&lt;br /&gt;
'''&amp;lt;u&amp;gt;Scaleability:&amp;lt;/u&amp;gt; Often a parallel system is not rated by its speed alone, but instead based on how it performes with varying loads.  A system that is scaleable will have a gradual increase in response times untill it reaches saturation.&amp;lt;BR&amp;gt;'''&lt;br /&gt;
&lt;br /&gt;
'''&amp;lt;u&amp;gt;Load:&amp;lt;/u&amp;gt; The load on a parallel system is the measure of the work/time that is required of the system.  It is relative to the number of actions taking place as well as the time between those actions and the complexity of each action.&amp;lt;BR&amp;gt;'''&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;References:&amp;lt;/u&amp;gt;===&lt;br /&gt;
'''Parallel Computer Architecture- A Hardware/Software Approach by David E Culler, Jaswinder Pal Singh and Anoop Guptha'''&amp;lt;br/&amp;gt;&lt;br /&gt;
   &lt;br /&gt;
http://en.wikipedia.org/wiki/Computer_performance&lt;br /&gt;
&lt;br /&gt;
The BSP Model&lt;br /&gt;
http://wwwcs.uni-paderborn.de/fachbereich/AG/agmadh/WWW/bono/paper/nestedbsp/node6.html&lt;br /&gt;
&lt;br /&gt;
LogP: Towards a Realistic Model of Parallel Computation&lt;br /&gt;
http://cs315b-wiki.stanford.edu/images/8/8b/Logp.pdf&lt;/div&gt;</summary>
		<author><name>Lreddy</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki1_1.3.3_1.3.4_chase2007&amp;diff=3470</id>
		<title>CSC/ECE 506 Fall 2007/wiki1 1.3.3 1.3.4 chase2007</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki1_1.3.3_1.3.4_chase2007&amp;diff=3470"/>
		<updated>2007-09-11T02:31:44Z</updated>

		<summary type="html">&lt;p&gt;Lreddy: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==&amp;lt;u&amp;gt;'''Introduction to Parallel Computer Architecture -&amp;gt;Fundamental Design Issues -&amp;gt; Communication and Replication (section 1.3.3)'''&amp;lt;/u&amp;gt;==&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Communication and Replication&amp;lt;/u&amp;gt;&amp;lt;br&amp;gt;===&lt;br /&gt;
'''Communicationa and replication are inherently related.To be clear on the relationship of communication and replication, it is important to distinguish several concepts. When a program performs a write, it binds a data value to an address. The data resides in some physical storage element in the machine. A &amp;lt;u&amp;gt;data transfer&amp;lt;/u&amp;gt; occurs whenever data in one storage element is transferred into another. This doesnot necessarily change the bindings of the addresses and values. The same data may reside in multiple physical locations as it does in the uniprosessor storage heirarchy, but the one nearest to the processor is the only one that the processor can observe. If it is updated, the other hidden replicas including the actual memory location, must eventually be updated.Copying data binds a new set of addresses to the sane set of values. Generally, this will cause data transfers.Once the copy has been made, the two sets of bindings are completely independent.Hence, Replication is the creation of a local copy of data to help enable parallelism. Replication helps to avoid unnecessary communication.&amp;lt;br&amp;gt;'''&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Communication&amp;lt;/u&amp;gt; occurs when data written from one process is read by another process. This may cause data transfer within the machine, either on the write or the read,or the data transfer may occur for other reasons.Communication may involve establishing a new binding or not doing so, depending on the particular communication abstraction.&lt;br /&gt;
&lt;br /&gt;
==&amp;lt;u&amp;gt;'''Introduction to Parallel Computer Architecture -&amp;gt;Fundamental Design Issues -&amp;gt; Performance (section 1.3.4)'''&amp;lt;/u&amp;gt;==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Computer Performance:&amp;lt;/u&amp;gt;&amp;lt;br&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''Computer performance is a measure of the output of a computer with with respect to time and resources used.'''&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Performance metrics:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''Following are the important metrics used to measure a computer's performance:'''&lt;br /&gt;
&lt;br /&gt;
'''1.&amp;lt;u&amp;gt;Latency:'''&amp;lt;/u&amp;gt; '''The time taken to perform an operation'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''2.&amp;lt;u&amp;gt;Bandwidth:'''&amp;lt;/u&amp;gt;'''The rate at which the operations are performed'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''3.&amp;lt;u&amp;gt;Cost:'''&amp;lt;/u&amp;gt; '''The impact these operations have on the execution time of the program'''&amp;lt;br&amp;gt;&lt;br /&gt;
 &lt;br /&gt;
'''All the above metrics can be used to define a uniprocessor systems where a single CPU operates.'''&lt;br /&gt;
&lt;br /&gt;
'''However, in the context of parallel computers, it becomes difficult to express the performance in above stated metrics. The reason for this is the communication between the processors that occurs mostly in the form of data transfers between the processors. So, to completely define the performace of a parallel computer, the following metrics are also considered.'''&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Data Transfer Time:&amp;lt;/u&amp;gt;===&lt;br /&gt;
'''It is the time taken for initiation of a data transfer and the time required for actual data transfer.  So the Data Transfer Time can be given as:'''&lt;br /&gt;
        &lt;br /&gt;
'''Transfer Time (n) = T+(n/B)'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''where'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''n = Amount of Data (in bytes)'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''B = Transfer Rate of the component moving the data (bytes per second)'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''T = Start up cost, a constant'''&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
'''This is a very convinient model, and it is used to describe a diverse collection of operations, including messages, memory accesses, bus transactions, and vector operations. For message passing, the start up cost can be thought of as the time for the first bit to get to the destination. For memory operations, it is essentially the access time. For bus transactions, it reflects the bus arbitration and command phases. For any sort of pipelinedoperation, including pipelined instruction processing or vector operations, it is the time to fill the pipeline.'''&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Overhead and Occupancy:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''The data transfer operations are initiated by the processor through communication assist. The essential components of this operation can be described by the following simple model. This model is very generic and can be used to explain data transfers in many places in modern, highly pipelined computer systems.:'''&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
'''Communication Time = Overhead+Occupancy+Network Delay'''&lt;br /&gt;
&lt;br /&gt;
'''The overhead is the time the processor spends initiating the transfer of data. This may be a fixed cost, if the processor imply has to tell the communication assist to start. The overhead can also be linear with Tranfer time, if the processor has to copy the data into the assist.The key point is that this is time the processor is busy with the communication event; it cannot do other useful work to initiate other communication during this time. Thr ramaining portion of the communication time is considered as network latency; it is the part that can be hidden by other processor operations'''&lt;br /&gt;
&lt;br /&gt;
'''The occupancy is the time it takes for the data to pass through the slowest componant on the communication path.The data wol occupy oyher resources, including buffers,switches, and the communication assist. Often the communication assist is the bottleneck that determines the occupancy. The occupancy limits how frequently communication operations can be initiated.The next data transfer will have to wait untill the critical resource is no longer occupied before it can use the same resource. If there is buffering between the processor and the bottleneck, the processor may be able to issue a burst of transfers at a frequency greater than I/O occupancy; however, once this buffer is full, the processor must slow to the rate set by the occupancy. A new transfer can start only when an older one finishes'''&lt;br /&gt;
&lt;br /&gt;
'''The remaining communication time is lumped into the network dealy,which includes the time  for the bit to be routed across the actual network as well as many other factors, such as the time to get through communication assists. &lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Communication Cost:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''It is the time that the processor spends in communicating with other processors. It can be given by the following:'''&lt;br /&gt;
&lt;br /&gt;
'''Communication Cost = Frequency of Communication * (Communication Time - Overlap)'''&lt;br /&gt;
&lt;br /&gt;
'''Frequency of Communication = Number of communications per unit of work'''&lt;br /&gt;
'''Communication Time = Overhead + Occupancy + Network Delay'''&lt;br /&gt;
'''Overlap = The portion of the communication operation that is performed concurrently with other useful work.'''&lt;br /&gt;
&lt;br /&gt;
'''Frequency of communication depends on many programming factors and many hardware design factors.In particular, hardware may limit the transfer size and thereby determine the minimum number of messages. It may automatically replicate data or migrate it to  where it is used. However, a certain amount of communication is inherent to parallel execution since data must be shared and processors must coordinate their work. In general, for a machine to support programs with a high communication frequency, the other parts of the communication cost equation must be small - low overhead, low network delay, and small occupancy.'''&lt;br /&gt;
&lt;br /&gt;
'''The overlap is the portion of the communication coperation that is performed caoncurrently with other useful work, including computation or other communication time. The reduction of the effective cost is possible because much of the communication time involves work done by the components of the system other than the processor such as the communication assist, the bus, the network, or the remote processor or memory.Overlapping communicationw ith oether work is a form of small-scale parallelism, as is the instruction-level parallelism exploited by fast microprocessors.In effect, some available parallelism will be invested  to hide the actual cost of communication.'''&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;BSP Model:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''Bulk Synchronization Parallel Model:&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''The BSP model is a series of supersteps.&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''A superstep on a BSP machine is given by W + G*H + L&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''W is the maximum possible work for a given processor&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''H is the maximum bytes sent or recieved by a processor&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''G is the number of available processors&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''L is the time required for the barrier synchronization&amp;lt;BR&amp;gt;'''&lt;br /&gt;
&amp;lt;BR&amp;gt;&lt;br /&gt;
'''There are other similar variations of BSP like LogP&amp;lt;BR&amp;gt;'''&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Terminology:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''&amp;lt;u&amp;gt;Saturation Point:&amp;lt;/u&amp;gt; In performance of a parallel system there is a point that is reached where the system can not keep up with the load on it.  At this point response times will go to infinity.  This point is where the load on the system completely utilizes the most scarce resource, often the cpu.&amp;lt;BR&amp;gt;'''&lt;br /&gt;
&lt;br /&gt;
'''&amp;lt;u&amp;gt;Scaleability:&amp;lt;/u&amp;gt; Often a parallel system is not rated by its speed alone, but instead based on how it performes with varying loads.  A system that is scaleable will have a gradual increase in response times untill it reaches saturation.&amp;lt;BR&amp;gt;'''&lt;br /&gt;
&lt;br /&gt;
'''&amp;lt;u&amp;gt;Load:&amp;lt;/u&amp;gt; The load on a parallel system is the measure of the work/time that is required of the system.  It is relative to the number of actions taking place as well as the time between those actions and the complexity of each action.&amp;lt;BR&amp;gt;'''&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;References:&amp;lt;/u&amp;gt;===&lt;br /&gt;
'''Parallel Computer Architecture- A Hardware/Software Approach by David E Culler, Jaswinder Pal Singh and Anoop Guptha'''&amp;lt;br/&amp;gt;&lt;br /&gt;
   &lt;br /&gt;
http://en.wikipedia.org/wiki/Computer_performance&lt;br /&gt;
&lt;br /&gt;
The BSP Model&lt;br /&gt;
http://wwwcs.uni-paderborn.de/fachbereich/AG/agmadh/WWW/bono/paper/nestedbsp/node6.html&lt;br /&gt;
&lt;br /&gt;
LogP: Towards a Realistic Model of Parallel Computation&lt;br /&gt;
http://cs315b-wiki.stanford.edu/images/8/8b/Logp.pdf&lt;/div&gt;</summary>
		<author><name>Lreddy</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki1_1.3.3_1.3.4_chase2007&amp;diff=3469</id>
		<title>CSC/ECE 506 Fall 2007/wiki1 1.3.3 1.3.4 chase2007</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki1_1.3.3_1.3.4_chase2007&amp;diff=3469"/>
		<updated>2007-09-11T02:30:41Z</updated>

		<summary type="html">&lt;p&gt;Lreddy: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==&amp;lt;u&amp;gt;'''Introduction to Parallel Computer Architecture -&amp;gt;Fundamental Design Issues -&amp;gt; Communication and Replication (section 1.3.3)'''&amp;lt;/u&amp;gt;==&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Communication and Replication&amp;lt;/u&amp;gt;&amp;lt;br&amp;gt;===&lt;br /&gt;
'''Communicationa and replication are inherently related.To be clear on the relationship of communication and replication, it is important to distinguish several concepts. When a program performs a write, it binds a data value to an address. The data resides in some physical storage element in the machine. A &amp;lt;u&amp;gt;data transfer&amp;lt;/u&amp;gt; occurs whenever data in one storage element is transferred into another. This doesnot necessarily change the bindings of the addresses and values. The same data may reside in multiple physical locations as it does in the uniprosessor storage heirarchy, but the one nearest to the processor is the only one that the processor can observe. If it is updated, the other hidden replicas including the actual memory location, must eventually be updated.Copying data binds a new set of addresses to the sane set of values. Generally, this will cause data transfers.Once the copy has been made, the two sets of bindings are completely independent.Hence, Replication is the creation of a local copy of data to help enable parallelism. Replication helps to avoid unnecessary communication.&amp;lt;br&amp;gt;'''&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Communication&amp;lt;/u&amp;gt; occurs when data written from one process is read by another process. This may cause data transfer within the machine, either on the write or the read,or the data transfer may occur for other reasons.Communication may involve establishing a new binding or not doing so, depending on the particular communication abstraction.&lt;br /&gt;
&lt;br /&gt;
==&amp;lt;u&amp;gt;'''Introduction to Parallel Computer Architecture -&amp;gt;Fundamental Design Issues -&amp;gt; Performance (section 1.3.4)'''&amp;lt;/u&amp;gt;==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Computer Performance:&amp;lt;/u&amp;gt;&amp;lt;br&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''Computer performance is a measure of the output of a computer with with respect to time and resources used.'''&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Performance metrics:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''Following are the important metrics used to measure a computer's performance:'''&lt;br /&gt;
&lt;br /&gt;
'''1.&amp;lt;u&amp;gt;Latency:'''&amp;lt;/u&amp;gt; '''The time taken to perform an operation'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''2.&amp;lt;u&amp;gt;Bandwidth:'''&amp;lt;/u&amp;gt;'''The rate at which the operations are performed'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''3.&amp;lt;u&amp;gt;Cost:'''&amp;lt;/u&amp;gt; '''The impact these operations have on the execution time of the program'''&amp;lt;br&amp;gt;&lt;br /&gt;
 &lt;br /&gt;
'''All the above metrics can be used to define a uniprocessor systems where a single CPU operates.'''&lt;br /&gt;
&lt;br /&gt;
'''However, in the context of parallel computers, it becomes difficult to express the performance in above stated metrics. The reason for this is the communication between the processors that occurs mostly in the form of data transfers between the processors. So, to completely define the performace of a parallel computer, the following metrics are also considered.'''&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Data Transfer Time:&amp;lt;/u&amp;gt;===&lt;br /&gt;
'''It is the time taken for initiation of a data transfer and the time required for actual data transfer.  So the Data Transfer Time can be given as:'''&lt;br /&gt;
        &lt;br /&gt;
'''Transfer Time (n) = T+(n/B)'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''where'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''n = Amount of Data (in bytes)'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''B = Transfer Rate of the component moving the data (bytes per second)'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''T = Start up cost, a constant'''&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
''This is a very convinient model, and it is used to describe a diverse collection of operations, including messages, memory accesses, bus transactions, and vector operations. For message passing, the start up cost can be thought of as the time for the first bit to get to the destination. For memory operations, it is essentially the access time. For bus transactions, it reflects the bus arbitration and command phases. For any sort of pipelinedoperation, including pipelined instruction processing or vector operations, it is the time to fill the pipeline.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Overhead and Occupancy:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''The data transfer operations are initiated by the processor through communication assist. The essential components of this operation can be described by the following simple model. This model is very generic and can be used to explain data transfers in many places in modern, highly pipelined computer systems.:'''&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
'''Communication Time = Overhead+Occupancy+Network Delay'''&lt;br /&gt;
&lt;br /&gt;
'''The overhead is the time the processor spends initiating the transfer of data. This may be a fixed cost, if the processor imply has to tell the communication assist to start. The overhead can also be linear with Tranfer time, if the processor has to copy the data into the assist.The key point is that this is time the processor is busy with the communication event; it cannot do other useful work to initiate other communication during this time. Thr ramaining portion of the communication time is considered as network latency; it is the part that can be hidden by other processor operations'''&lt;br /&gt;
&lt;br /&gt;
'''The occupancy is the time it takes for the data to pass through the slowest componant on the communication path.The data wol occupy oyher resources, including buffers,switches, and the communication assist. Often the communication assist is the bottleneck that determines the occupancy. The occupancy limits how frequently communication operations can be initiated.The next data transfer will have to wait untill the critical resource is no longer occupied before it can use the same resource. If there is buffering between the processor and the bottleneck, the processor may be able to issue a burst of transfers at a frequency greater than I/O occupancy; however, once this buffer is full, the processor must slow to the rate set by the occupancy. A new transfer can start only when an older one finishes'''&lt;br /&gt;
&lt;br /&gt;
'''The remaining communication time is lumped into the network dealy,which includes the time  for the bit to be routed across the actual network as well as many other factors, such as the time to get through communication assists. &lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Communication Cost:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''It is the time that the processor spends in communicating with other processors. It can be given by the following:'''&lt;br /&gt;
&lt;br /&gt;
'''Communication Cost = Frequency of Communication * (Communication Time - Overlap)'''&lt;br /&gt;
&lt;br /&gt;
'''Frequency of Communication = Number of communications per unit of work'''&lt;br /&gt;
'''Communication Time = Overhead + Occupancy + Network Delay'''&lt;br /&gt;
'''Overlap = The portion of the communication operation that is performed concurrently with other useful work.'''&lt;br /&gt;
&lt;br /&gt;
'''Frequency of communication depends on many programming factors and many hardware design factors.In particular, hardware may limit the transfer size and thereby determine the minimum number of messages. It may automatically replicate data or migrate it to  where it is used. However, a certain amount of communication is inherent to parallel execution since data must be shared and processors must coordinate their work. In general, for a machine to support programs with a high communication frequency, the other parts of the communication cost equation must be small - low overhead, low network delay, and small occupancy.'''&lt;br /&gt;
&lt;br /&gt;
'''The overlap is the portion of the communication coperation that is performed caoncurrently with other useful work, including computation or other communication time. The reduction of the effective cost is possible because much of the communication time involves work done by the components of the system other than the processor such as the communication assist, the bus, the network, or the remote processor or memory.Overlapping communicationw ith oether work is a form of small-scale parallelism, as is the instruction-level parallelism exploited by fast microprocessors.In effect, some available parallelism will be invested  to hide the actual cost of communication.'''&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;BSP Model:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''Bulk Synchronization Parallel Model:&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''The BSP model is a series of supersteps.&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''A superstep on a BSP machine is given by W + G*H + L&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''W is the maximum possible work for a given processor&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''H is the maximum bytes sent or recieved by a processor&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''G is the number of available processors&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''L is the time required for the barrier synchronization&amp;lt;BR&amp;gt;'''&lt;br /&gt;
&amp;lt;BR&amp;gt;&lt;br /&gt;
'''There are other similar variations of BSP like LogP&amp;lt;BR&amp;gt;'''&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Terminology:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''&amp;lt;u&amp;gt;Saturation Point:&amp;lt;/u&amp;gt; In performance of a parallel system there is a point that is reached where the system can not keep up with the load on it.  At this point response times will go to infinity.  This point is where the load on the system completely utilizes the most scarce resource, often the cpu.&amp;lt;BR&amp;gt;'''&lt;br /&gt;
&lt;br /&gt;
'''&amp;lt;u&amp;gt;Scaleability:&amp;lt;/u&amp;gt; Often a parallel system is not rated by its speed alone, but instead based on how it performes with varying loads.  A system that is scaleable will have a gradual increase in response times untill it reaches saturation.&amp;lt;BR&amp;gt;'''&lt;br /&gt;
&lt;br /&gt;
'''&amp;lt;u&amp;gt;Load:&amp;lt;/u&amp;gt; The load on a parallel system is the measure of the work/time that is required of the system.  It is relative to the number of actions taking place as well as the time between those actions and the complexity of each action.&amp;lt;BR&amp;gt;'''&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;References:&amp;lt;/u&amp;gt;===&lt;br /&gt;
'''Parallel Computer Architecture- A Hardware/Software Approach by David E Culler, Jaswinder Pal Singh and Anoop Guptha'''&amp;lt;br/&amp;gt;&lt;br /&gt;
   &lt;br /&gt;
http://en.wikipedia.org/wiki/Computer_performance&lt;br /&gt;
&lt;br /&gt;
The BSP Model&lt;br /&gt;
http://wwwcs.uni-paderborn.de/fachbereich/AG/agmadh/WWW/bono/paper/nestedbsp/node6.html&lt;br /&gt;
&lt;br /&gt;
LogP: Towards a Realistic Model of Parallel Computation&lt;br /&gt;
http://cs315b-wiki.stanford.edu/images/8/8b/Logp.pdf&lt;/div&gt;</summary>
		<author><name>Lreddy</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki1_1.3.3_1.3.4_chase2007&amp;diff=3439</id>
		<title>CSC/ECE 506 Fall 2007/wiki1 1.3.3 1.3.4 chase2007</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki1_1.3.3_1.3.4_chase2007&amp;diff=3439"/>
		<updated>2007-09-11T02:06:55Z</updated>

		<summary type="html">&lt;p&gt;Lreddy: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==&amp;lt;u&amp;gt;'''Introduction to Parallel Computer Architecture -&amp;gt;Fundamental Design Issues -&amp;gt; Communication and Replication (section 1.3.3)'''&amp;lt;/u&amp;gt;==&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Communication and Replication&amp;lt;/u&amp;gt;&amp;lt;br&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''Communication occurs when data written from one process is read by another process. '''&lt;br /&gt;
&lt;br /&gt;
'''&amp;lt;br&amp;gt;Replication helps to avoid unnecessary communication.'''&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
'''Replication is the creation of a local copy of data to help enable parallelism.'''&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''&lt;br /&gt;
&lt;br /&gt;
==&amp;lt;u&amp;gt;'''Introduction to Parallel Computer Architecture -&amp;gt;Fundamental Design Issues -&amp;gt; Performance (section 1.3.4)'''&amp;lt;/u&amp;gt;==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Computer Performance:&amp;lt;/u&amp;gt;&amp;lt;br&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''Computer performance is a measure of the output of a computer with with respect to time and resources used.'''&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Performance metrics:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''Following are the important metrics used to measure a computer's performance:'''&lt;br /&gt;
&lt;br /&gt;
'''1.&amp;lt;u&amp;gt;Latency:'''&amp;lt;/u&amp;gt; '''The time taken to perform an operation'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''2.&amp;lt;u&amp;gt;Bandwidth:'''&amp;lt;/u&amp;gt;'''The rate at which the operations are performed'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''3.&amp;lt;u&amp;gt;Cost:'''&amp;lt;/u&amp;gt; '''The impact these operations have on the execution time of the program'''&amp;lt;br&amp;gt;&lt;br /&gt;
 &lt;br /&gt;
'''All the above metrics can be used to define a uniprocessor systems where a single CPU operates.'''&lt;br /&gt;
&lt;br /&gt;
'''However, in the context of parallel computers, it becomes difficult to express the performance in above stated metrics. The reason for this is the communication between the processors that occurs mostly in the form of data transfers between the processors. So, to completely define the performace of a parallel computer, the following metrics are also considered.'''&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Data Transfer Time:&amp;lt;/u&amp;gt;===&lt;br /&gt;
'''It is the time taken for initiation of a data transfer and the time required for actual data transfer.  So the Data Transfer Time can be given as:'''&lt;br /&gt;
        &lt;br /&gt;
'''Transfer Time (n) = T+(n/B)'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''where'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''n = Amount of Data (in bytes)'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''B = Transfer Rate of the component moving the data (bytes per second)'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''T = Start up cost, a constant'''&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
''This is a very convinient model, and it is used to describe a diverse collection of operations, including messages, memory accesses, bus transactions, and vector operations. For message passing, the start up cost can be thought of as the time for the first bit to get to the destination. For memory operations, it is essentially the access time. For bus transactions, it reflects the bus arbitration and command phases. For any sort of pipelinedoperation, including pipelined instruction processing or vector operations, it is the time to fill the pipeline.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Overhead and Occupancy:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''The data transfer operations are initiated by the processor through communication assist. The essential components of this operation can be described by the following simple model. This model is very generic and can be used to explain data transfers in many places in modern, highly pipelined computer systems.:'''&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
'''Communication Time = Overhead+Occupancy+Network Delay'''&lt;br /&gt;
&lt;br /&gt;
'''The overhead is the time the processor spends initiating the transfer of data. This may be a fixed cost, if the processor imply has to tell the communication assist to start. The overhead can also be linear with Tranfer time, if the processor has to copy the data into the assist.The key point is that this is time the processor is busy with the communication event; it cannot do other useful work to initiate other communication during this time. Thr ramaining portion of the communication time is considered as network latency; it is the part that can be hidden by other processor operations'''&lt;br /&gt;
&lt;br /&gt;
'''The occupancy is the time it takes for the data to pass through the slowest componant on the communication path.The data wol occupy oyher resources, including buffers,switches, and the communication assist. Often the communication assist is the bottleneck that determines the occupancy. The occupancy limits how frequently communication operations can be initiated.The next data transfer will have to wait untill the critical resource is no longer occupied before it can use the same resource. If there is buffering between the processor and the bottleneck, the processor may be able to issue a burst of transfers at a frequency greater than I/O occupancy; however, once this buffer is full, the processor must slow to the rate set by the occupancy. A new transfer can start only when an older one finishes'''&lt;br /&gt;
&lt;br /&gt;
'''The remaining communication time is lumped into the network dealy,which includes the time  for the bit to be routed across the actual network as well as many other factors, such as the time to get through communication assists. &lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Communication Cost:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''It is the time that the processor spends in communicating with other processors. It can be given by the following:'''&lt;br /&gt;
&lt;br /&gt;
'''Communication Cost = Frequency of Communication * (Communication Time - Overlap)'''&lt;br /&gt;
&lt;br /&gt;
'''Frequency of Communication = Number of communications per unit of work'''&lt;br /&gt;
'''Communication Time = Overhead + Occupancy + Network Delay'''&lt;br /&gt;
'''Overlap = The portion of the communication operation that is performed concurrently with other useful work.'''&lt;br /&gt;
&lt;br /&gt;
'''Frequency of communication depends on many programming factors and many hardware design factors.In particular, hardware may limit the transfer size and thereby determine the minimum number of messages. It may automatically replicate data or migrate it to  where it is used. However, a certain amount of communication is inherent to parallel execution since data must be shared and processors must coordinate their work. In general, for a machine to support programs with a high communication frequency, the other parts of the communication cost equation must be small - low overhead, low network delay, and small occupancy.'''&lt;br /&gt;
&lt;br /&gt;
'''The overlap is the portion of the communication coperation that is performed caoncurrently with other useful work, including computation or other communication time. The reduction of the effective cost is possible because much of the communication time involves work done by the components of the system other than the processor such as the communication assist, the bus, the network, or the remote processor or memory.Overlapping communicationw ith oether work is a form of small-scale parallelism, as is the instruction-level parallelism exploited by fast microprocessors.In effect, some available parallelism will be invested  to hide the actual cost of communication.'''&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;BSP Model:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''Bulk Synchronization Parallel Model:&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''The BSP model is a series of supersteps.&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''A superstep on a BSP machine is given by W + G*H + L&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''W is the maximum possible work for a given processor&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''H is the maximum bytes sent or recieved by a processor&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''G is the number of available processors&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''L is the time required for the barrier synchronization&amp;lt;BR&amp;gt;'''&lt;br /&gt;
&amp;lt;BR&amp;gt;&lt;br /&gt;
'''There are other similar variations of BSP like LogP&amp;lt;BR&amp;gt;'''&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Terminology:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''&amp;lt;u&amp;gt;Saturation Point:&amp;lt;/u&amp;gt; In performance of a parallel system there is a point that is reached where the system can not keep up with the load on it.  At this point response times will go to infinity.  This point is where the load on the system completely utilizes the most scarce resource, often the cpu.&amp;lt;BR&amp;gt;'''&lt;br /&gt;
&lt;br /&gt;
'''&amp;lt;u&amp;gt;Scaleability:&amp;lt;/u&amp;gt; Often a parallel system is not rated by its speed alone, but instead based on how it performes with varying loads.  A system that is scaleable will have a gradual increase in response times untill it reaches saturation.&amp;lt;BR&amp;gt;'''&lt;br /&gt;
&lt;br /&gt;
'''&amp;lt;u&amp;gt;Load:&amp;lt;/u&amp;gt; The load on a parallel system is the measure of the work/time that is required of the system.  It is relative to the number of actions taking place as well as the time between those actions and the complexity of each action.&amp;lt;BR&amp;gt;'''&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;References:&amp;lt;/u&amp;gt;===&lt;br /&gt;
'''Parallel Computer Architecture- A Hardware/Software Approach by David E Culler, Jaswinder Pal Singh and Anoop Guptha'''&amp;lt;br/&amp;gt;&lt;br /&gt;
   &lt;br /&gt;
http://en.wikipedia.org/wiki/Computer_performance&lt;br /&gt;
&lt;br /&gt;
The BSP Model&lt;br /&gt;
http://wwwcs.uni-paderborn.de/fachbereich/AG/agmadh/WWW/bono/paper/nestedbsp/node6.html&lt;br /&gt;
&lt;br /&gt;
LogP: Towards a Realistic Model of Parallel Computation&lt;br /&gt;
http://cs315b-wiki.stanford.edu/images/8/8b/Logp.pdf&lt;/div&gt;</summary>
		<author><name>Lreddy</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki1_1.3.3_1.3.4_chase2007&amp;diff=3392</id>
		<title>CSC/ECE 506 Fall 2007/wiki1 1.3.3 1.3.4 chase2007</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki1_1.3.3_1.3.4_chase2007&amp;diff=3392"/>
		<updated>2007-09-11T01:16:34Z</updated>

		<summary type="html">&lt;p&gt;Lreddy: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==&amp;lt;u&amp;gt;'''Introduction to Parallel Computer Architecture -&amp;gt;Fundamental Design Issues -&amp;gt; Communication and Replication (section 1.3.3)'''&amp;lt;/u&amp;gt;==&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Replication:&amp;lt;/u&amp;gt;&amp;lt;br&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''Replication is the creation of a local copy of data to help enable parallelism.'''&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Communication:&amp;lt;/u&amp;gt;&amp;lt;br&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''Communication occurs when data written from one process is read by another process.  Replication helps to avoid unnecessary communication.'''&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==&amp;lt;u&amp;gt;'''Introduction to Parallel Computer Architecture -&amp;gt;Fundamental Design Issues -&amp;gt; Performance (section 1.3.4)'''&amp;lt;/u&amp;gt;==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Computer Performance:&amp;lt;/u&amp;gt;&amp;lt;br&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''Computer performance is a measure of the output of a computer with with respect to time and resources used.'''&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Performance metrics:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''Following are the important metrics used to measure a computer's performance:'''&lt;br /&gt;
&lt;br /&gt;
'''1.&amp;lt;u&amp;gt;Latency:'''&amp;lt;/u&amp;gt; '''The time taken to perform an operation'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''2.&amp;lt;u&amp;gt;Bandwidth:'''&amp;lt;/u&amp;gt;'''The rate at which the operations are performed'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''3.&amp;lt;u&amp;gt;Cost:'''&amp;lt;/u&amp;gt; '''The impact these operations have on the execution time of the program'''&amp;lt;br&amp;gt;&lt;br /&gt;
 &lt;br /&gt;
'''All the above metrics can be used to define a uniprocessor systems where a single CPU operates.'''&lt;br /&gt;
&lt;br /&gt;
'''However, in the context of parallel computers, it becomes difficult to express the performance in above stated metrics. The reason for this is the communication between the processors that occurs mostly in the form of data transfers between the processors. So, to completely define the performace of a parallel computer, the following metrics are also considered.'''&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Data Transfer Time:&amp;lt;/u&amp;gt;===&lt;br /&gt;
'''It is the time taken for initiation of a data transfer and the time required for actual data transfer.  So the Data Transfer Time can be given as:'''&lt;br /&gt;
        &lt;br /&gt;
'''Transfer Time (n) = T+(n/B)'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''where'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''n = Amount of Data (in bytes)'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''B = Transfer Rate of the component moving the data (bytes per second)'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''T = Start up cost, a constant'''&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Overhead and Occupancy:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''The data transfer operations are initiated by the processor through communication assist'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''The overhead is the time the processor spends initiating the transfer of data. This may be a fixed cost, if the processor imply has to tell the communication assist to start. The overhead can also be linear with Tranfer time, if the processor has to copy the data into the assist.'''&lt;br /&gt;
'''The occupancy is the time it takes for the data to pass through the slowest componant on the communication path. The occupancy limits how frequently communication operations can be initiated.The next data transfer will have to wait untill the critical resource is no longer occupied before it can use the same resource. '''&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Communication Cost:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''It is the time that the processor spends in communicating with other processors. It can be given by the following:'''&lt;br /&gt;
&lt;br /&gt;
'''Communication Cost = Frequency of Communication * (Communication Time - Overlap)'''&lt;br /&gt;
&lt;br /&gt;
'''Frequency of Communication = Number of communications per unit of work'''&lt;br /&gt;
'''Communication Time = Overhead + Occupancy + Network Delay'''&lt;br /&gt;
'''Overlap = The portion of the communication operation that is performed concurrently with other useful work.'''&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;BSP Model:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''Bulk Synchronization Parallel Model:&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''The BSP model is a series of supersteps.&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''A superstep on a BSP machine is given by W + G*H + L&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''W is the maximum possible work for a given processor&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''H is the maximum bytes sent or recieved by a processor&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''G is the number of available processors&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''L is the time required for the barrier synchronization&amp;lt;BR&amp;gt;'''&lt;br /&gt;
&amp;lt;BR&amp;gt;&lt;br /&gt;
'''There are other similar variations of BSP like LogP&amp;lt;BR&amp;gt;'''&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Terminology:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''&amp;lt;u&amp;gt;Saturation Point:&amp;lt;/u&amp;gt; In performance of a parallel system there is a point that is reached where the system can not keep up with the load on it.  At this point response times will go to infinity.  This point is where the load on the system completely utilizes the most scarce resource, often the cpu.&amp;lt;BR&amp;gt;'''&lt;br /&gt;
&lt;br /&gt;
'''&amp;lt;u&amp;gt;Scaleability:&amp;lt;/u&amp;gt; Often a parallel system is not rated by its speed alone, but instead based on how it performes with varying loads.  A system that is scaleable will have a gradual increase in response times untill it reaches saturation.&amp;lt;BR&amp;gt;'''&lt;br /&gt;
&lt;br /&gt;
'''&amp;lt;u&amp;gt;Load:&amp;lt;/u&amp;gt; The load on a parallel system is the measure of the work/time that is required of the system.  It is relative to the number of actions taking place as well as the time between those actions and the complexity of each action.&amp;lt;BR&amp;gt;'''&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;References:&amp;lt;/u&amp;gt;===&lt;br /&gt;
'''Parallel Computer Architecture- A Hardware/Software Approach by David E Culler, Jaswinder Pal Singh and Anoop Guptha'''&amp;lt;br/&amp;gt;&lt;br /&gt;
   &lt;br /&gt;
http://en.wikipedia.org/wiki/Computer_performance&lt;br /&gt;
&lt;br /&gt;
The BSP Model&lt;br /&gt;
http://wwwcs.uni-paderborn.de/fachbereich/AG/agmadh/WWW/bono/paper/nestedbsp/node6.html&lt;br /&gt;
&lt;br /&gt;
LogP: Towards a Realistic Model of Parallel Computation&lt;br /&gt;
http://cs315b-wiki.stanford.edu/images/8/8b/Logp.pdf&lt;/div&gt;</summary>
		<author><name>Lreddy</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki1_1.3.3_1.3.4_chase2007&amp;diff=3364</id>
		<title>CSC/ECE 506 Fall 2007/wiki1 1.3.3 1.3.4 chase2007</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki1_1.3.3_1.3.4_chase2007&amp;diff=3364"/>
		<updated>2007-09-10T23:39:51Z</updated>

		<summary type="html">&lt;p&gt;Lreddy: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==&amp;lt;u&amp;gt;'''Introduction to Parallel Computer Architecture -&amp;gt;Fundamental Design Issues -&amp;gt; Communication and Replication (section 1.3.3)'''&amp;lt;/u&amp;gt;==&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Replication:&amp;lt;/u&amp;gt;&amp;lt;br&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''Replication is the creation of a local copy of data to help enable parallelism.'''&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Communication:&amp;lt;/u&amp;gt;&amp;lt;br&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''Communication occurs when data written from one process is read by another process.  Replication helps to avoid unnecessary communication.'''&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==&amp;lt;u&amp;gt;'''Introduction to Parallel Computer Architecture -&amp;gt;Fundamental Design Issues -&amp;gt; Performance (section 1.3.4)'''&amp;lt;/u&amp;gt;==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Computer Performance:&amp;lt;/u&amp;gt;&amp;lt;br&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''Computer performance is a measure of the output of a computer with with respect to time and resources used.'''&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Performance metrics:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''Following are the important metrics used to measure a computer's performance:'''&lt;br /&gt;
&lt;br /&gt;
'''1.&amp;lt;u&amp;gt;Latency:'''&amp;lt;/u&amp;gt; '''The time taken to perform an operation'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''2.&amp;lt;u&amp;gt;Bandwidth:'''&amp;lt;/u&amp;gt;'''The rate at which the operations are performed'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''3.&amp;lt;u&amp;gt;Cost:'''&amp;lt;/u&amp;gt; '''The impact these operations have on the execution time of the program'''&amp;lt;br&amp;gt;&lt;br /&gt;
 &lt;br /&gt;
'''All the above metrics can be used to define a uniprocessor systems where a single CPU operates.'''&lt;br /&gt;
&lt;br /&gt;
'''However, in the context of parallel computers, it becomes difficult to express the performance in above stated metrics. The reason for this is the communication between the processors that occurs mostly in the form of data transfers between the processors. So, to completely define the performace of a parallel computer, the following metrics are also considered.'''&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Data Transfer Time:&amp;lt;/u&amp;gt;===&lt;br /&gt;
'''It is the time taken for initiation of a data transfer and the time required for actual data transfer.  So the Data Transfer Time can be given as:'''&lt;br /&gt;
        &lt;br /&gt;
'''Transfer Time (n) = T+(n/B)'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''where'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''n = Amount of Data (in bytes)'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''B = Transfer Rate of the component moving the data (bytes per second)'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''T = Start up cost, a constant'''&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Overhead and Occupancy:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''The data transfer operations are initiated by the processor through communication assist'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''The overhead is the time the processor spends initiating the transfer of data. This may be a fixed cost, if the processor imply has to tell the communication assist to start. The overhead can also be linear with Tranfer time, if the processor has to copy the data into the assist.'''&lt;br /&gt;
'''The occupancy is the time it takes for the data to pass through the slowest componant on the communication path. The occupancy limits how frequently communication operations can be initiated.The next data transfer will have to wait untill the critical resource is no longer occupied before it can use the same resource. '''&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Communication Cost:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''It is the time that the processor spends in communicating with other processors. It can be given by the following:'''&lt;br /&gt;
&lt;br /&gt;
'''Communication Cost = Frequency of Communication * (Communication Time - Overlap)'''&lt;br /&gt;
&lt;br /&gt;
'''Frequency of Communication = Number of communications per unit of work'''&lt;br /&gt;
'''Communication Time = Overhead + Occupancy + Network Delay'''&lt;br /&gt;
'''Overlap = The portion of the communication operation that is performed concurrently with other useful work.'''&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;BSP Model:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''Bulk Synchronization Parallel Model:&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''The BSP model is a series of supersteps.&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''A superstep on a BSP machine is given by W + G*H + L&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''W is the maximum possible work for a given processor&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''H is the maximum bytes sent or recieved by a processor&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''G is the number of available processors&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''L is the time required for the barrier synchronization&amp;lt;BR&amp;gt;'''&lt;br /&gt;
&amp;lt;BR&amp;gt;&lt;br /&gt;
'''There are other similar variations of BSP like LogP&amp;lt;BR&amp;gt;'''&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Terminology:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''Saturation Point: In performance of a parallel system there is a point that is reached where the system can not keep up with the load on it.  At this point response times will go to infinity.  This point is where the load on the system completely utilizes the most scarce resource, often the cpu.&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''Scaleability: Often a parallel system is not rated by its speed alone, but instead based on how it performes with varying loads.  A system that is scaleable will have a gradual increase in response times untill it reaches saturation.&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''Load: The load on a parallel system is the measure of the work/time that is required of the system.  It is relative to the number of actions taking place as well as the time between those actions and the complexity of each action.&amp;lt;BR&amp;gt;'''&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;References:&amp;lt;/u&amp;gt;===&lt;br /&gt;
'''Parallel Computer Architecture- A Hardware/Software Approach by David E Culler, Jaswinder Pal Singh and Anoop Guptha'''&amp;lt;br/&amp;gt;&lt;br /&gt;
   &lt;br /&gt;
http://en.wikipedia.org/wiki/Computer_performance&lt;br /&gt;
&lt;br /&gt;
The BSP Model&lt;br /&gt;
http://wwwcs.uni-paderborn.de/fachbereich/AG/agmadh/WWW/bono/paper/nestedbsp/node6.html&lt;br /&gt;
&lt;br /&gt;
LogP: Towards a Realistic Model of Parallel Computation&lt;br /&gt;
http://cs315b-wiki.stanford.edu/images/8/8b/Logp.pdf&lt;/div&gt;</summary>
		<author><name>Lreddy</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki1_1.3.3_1.3.4_chase2007&amp;diff=3354</id>
		<title>CSC/ECE 506 Fall 2007/wiki1 1.3.3 1.3.4 chase2007</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki1_1.3.3_1.3.4_chase2007&amp;diff=3354"/>
		<updated>2007-09-10T23:22:36Z</updated>

		<summary type="html">&lt;p&gt;Lreddy: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==&amp;lt;u&amp;gt;'''Introduction to Parallel Computer Architecture -&amp;gt;Fundamental Design Issues -&amp;gt; Communication and Replication (section 1.3.3)'''&amp;lt;/u&amp;gt;==&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Replication:&amp;lt;/u&amp;gt;&amp;lt;br&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''Replication is the creation of a local copy of data to help enable parallelism.'''&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Communication:&amp;lt;/u&amp;gt;&amp;lt;br&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''Communication occurs when data written from one process is read by another process.  Replication helps to avoid unnecessary communication.'''&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==&amp;lt;u&amp;gt;'''Introduction to Parallel Computer Architecture -&amp;gt;Fundamental Design Issues -&amp;gt; Performance (section 1.3.4)'''&amp;lt;/u&amp;gt;==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Computer Performance:&amp;lt;/u&amp;gt;&amp;lt;br&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''Computer performance is a measure of the output of a computer with with respect to time and resources used.'''&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Performance metrics:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''Following are the important metrics used to measure a computer's performance:'''&lt;br /&gt;
&lt;br /&gt;
'''1.&amp;lt;u&amp;gt;Latency:'''&amp;lt;/u&amp;gt; '''The time taken to perform an operation'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''2.&amp;lt;u&amp;gt;Bandwidth:'''&amp;lt;/u&amp;gt;'''The rate at which the operations are performed'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''3.&amp;lt;u&amp;gt;Cost:'''&amp;lt;/u&amp;gt; '''The impact these operations have on the execution time of the program'''&amp;lt;br&amp;gt;&lt;br /&gt;
 &lt;br /&gt;
'''All the above metrics can be used to define a uniprocessor systems where a single CPU operates.'''&lt;br /&gt;
&lt;br /&gt;
'''However, in the context of parallel computers, it becomes difficult to express the performance in above stated metrics. The reason for this is the communication between the processors that occurs mostly in the form of data transfers between the processors. So, to completely define the performace of a parallel computer, the following metrics are also considered.'''&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Data Transfer Time:&amp;lt;/u&amp;gt;===&lt;br /&gt;
'''It is the time taken for initiation of a data transfer and the time required for actual data transfer.  So the Data Transfer Time can be given as:'''&lt;br /&gt;
        &lt;br /&gt;
'''Transfer Time (n) = T+(n/B)'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''where'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''n = Amount of Data (in bytes)'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''B = Transfer Rate of the component moving the data (bytes per second)'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''T = Start up cost, a constant'''&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Overhead and Occupancy:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''The data transfer operations are initiated by the processor through communication assist'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''The overhead is the time the processor spends initiating the transfer of data. This may be a fixed cost, if the processor imply has to tell the communication assist to start. The overhead can also be linear with Tranfer time, if the processor has to copy the data into the assist.'''&lt;br /&gt;
'''The occupancy is the time it takes for the data to pass through the slowest componant on the communication path. The occupancy limits how frequently communication operations can be initiated.The next data transfer will have to wait untill the critical resource is no longer occupied before it can use the same resource. '''&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Communication Cost:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''It is the time that the processor spends in communicating with other processors. It can be given by the following:'''&lt;br /&gt;
&lt;br /&gt;
'''Communication Cost = Frequency of Communication * (Communication Time - Overlap)'''&lt;br /&gt;
&lt;br /&gt;
'''Frequency of Communication = Number of communications per unit of work'''&lt;br /&gt;
'''Communication Time = Overhead + Occupancy + Network Delay'''&lt;br /&gt;
'''Overlap = The portion of the communication operation that is performed concurrently with other useful work.'''&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;BSP Model:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''Bulk Synchronization Model:&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''The BSP model is a series of supersteps.&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''A superstep on a BSP machine is given by W + G*H + L&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''W is the maximum possible work for a given processor&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''H is the maximum bytes sent or recieved by a processor&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''G is the number of available processors&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''L is the time required for the barrier synchronization&amp;lt;BR&amp;gt;'''&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;LogP Model:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''L is a maximum on the latency&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''o is the overhead of transmission or reception&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''g is the minimum time between consectutive messages&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''P is the number of processors&amp;lt;BR&amp;gt;'''&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;References:&amp;lt;/u&amp;gt;===&lt;br /&gt;
'''Parallel Computer Architecture- A Hardware/Software Approach by David E Culler, Jaswinder Pal Singh and Anoop Guptha'''&amp;lt;br/&amp;gt;&lt;br /&gt;
   &lt;br /&gt;
http://en.wikipedia.org/wiki/Computer_performance&lt;br /&gt;
&lt;br /&gt;
The BSP Model&lt;br /&gt;
http://wwwcs.uni-paderborn.de/fachbereich/AG/agmadh/WWW/bono/paper/nestedbsp/node6.html&lt;br /&gt;
&lt;br /&gt;
LogP: Towards a Realistic Model of Parallel Computation&lt;br /&gt;
http://cs315b-wiki.stanford.edu/images/8/8b/Logp.pdf&lt;/div&gt;</summary>
		<author><name>Lreddy</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki1_1.3.3_1.3.4_chase2007&amp;diff=3350</id>
		<title>CSC/ECE 506 Fall 2007/wiki1 1.3.3 1.3.4 chase2007</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki1_1.3.3_1.3.4_chase2007&amp;diff=3350"/>
		<updated>2007-09-10T23:18:02Z</updated>

		<summary type="html">&lt;p&gt;Lreddy: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==&amp;lt;u&amp;gt;'''Introduction to Parallel Computer Architecture -&amp;gt;Fundamental Design Issues -&amp;gt; Communication and Replication (section 1.3.3)'''&amp;lt;/u&amp;gt;==&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Replication:&amp;lt;/u&amp;gt;&amp;lt;br&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''Replication is the creation of a local copy of data to help enable parallelism.'''&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Communication:&amp;lt;/u&amp;gt;&amp;lt;br&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''Communication occurs when data written from one process is read by another process.  Replication helps to avoid unnecessary communication.'''&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==&amp;lt;u&amp;gt;'''Introduction to Parallel Computer Architecture -&amp;gt;Fundamental Design Issues -&amp;gt; Performance (section 1.3.4)'''&amp;lt;/u&amp;gt;==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Computer Performance:&amp;lt;/u&amp;gt;&amp;lt;br&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''Computer performance is a measure of the output of a computer with with respect to time and resources used.'''&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Performance metrics:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''Following are the important metrics used to measure a computer's performance:'''&lt;br /&gt;
&lt;br /&gt;
'''1.&amp;lt;u&amp;gt;Latency:'''&amp;lt;/u&amp;gt; '''The time taken to perform an operation'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''2.&amp;lt;u&amp;gt;Bandwidth:'''&amp;lt;/u&amp;gt;'''The rate at which the operations are performed'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''3.&amp;lt;u&amp;gt;Cost:'''&amp;lt;/u&amp;gt; '''The impact these operations have on the execution time of the program'''&amp;lt;br&amp;gt;&lt;br /&gt;
 &lt;br /&gt;
'''All the above metrics can be used to define a uniprocessor systems where a single CPU operates.'''&lt;br /&gt;
&lt;br /&gt;
'''However, in the context of parallel computers, it becomes difficult to express the performance in above stated metrics. The reason for this is the communication between the processors that occurs mostly in the form of data transfers between the processors. So, to completely define the performace of a parallel computer, the following metrics are also considered.'''&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Data Transfer Time:&amp;lt;/u&amp;gt;===&lt;br /&gt;
'''It is the time taken for initiation of a data transfer and the time required for actual data transfer.  So the Data Transfer Time can be given as:'''&lt;br /&gt;
        &lt;br /&gt;
'''Transfer Time (n) = T+(n/B)'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''where'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''n = Amount of Data (in bytes)'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''B = Transfer Rate of the component moving the data (bytes per second)'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''T = Start up cost, a constant'''&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Overhead and Occupancy:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''The data transfer operations are initiated by the processor through communication assist'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''The overhead is the time the processor spends initiating the transfer of data. This may be a fixed cost, if the processor imply has to tell the communication assist to start. The overhead can also be linear with Tranfer time, if the processor has to copy the data into the assist.'''&lt;br /&gt;
'''The occupancy is the time it takes for the data to pass through the slowest componant on the communication path. The occupancy limits how frequently communication operations can be initiated.The next data transfer will have to wait untill the critical resource is no longer occupied before it can use the same resource. '''&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Communication Cost:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''It is the time that the processor spends in communicating with other processors. It can be given by the following:'''&lt;br /&gt;
&lt;br /&gt;
'''Communication Cost = Frequency of Communication * (Communication Time - Overlap)'''&lt;br /&gt;
&lt;br /&gt;
'''Frequency of Communication = Number of communications per unit of work'''&lt;br /&gt;
'''Communication Time = Overhead + Occupancy + Network Delay'''&lt;br /&gt;
'''Overlap = The portion of the communication operation that is performed concurrently with other useful work.'''&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;BSP Model:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''Bulk Synchronization Model:&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''The BSP model is a series of supersteps.&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''A superstep on a BSP machine is given by W + G*H + L&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''W is the maximum possible work for a given processor&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''H is the maximum bytes sent or recieved by a processor&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''G is the number of available processors&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''L is the time required for the barrier synchronization&amp;lt;BR&amp;gt;'''&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;LogP Model:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;References:&amp;lt;/u&amp;gt;===&lt;br /&gt;
'''Parallel Computer Architecture- A Hardware/Software Approach by David E Culler, Jaswinder Pal Singh and Anoop Guptha'''&amp;lt;br/&amp;gt;&lt;br /&gt;
   &lt;br /&gt;
http://en.wikipedia.org/wiki/Computer_performance&lt;br /&gt;
&lt;br /&gt;
The BSP Model&lt;br /&gt;
http://wwwcs.uni-paderborn.de/fachbereich/AG/agmadh/WWW/bono/paper/nestedbsp/node6.html&lt;br /&gt;
&lt;br /&gt;
LogP: Towards a Realistic Model of Parallel Computation&lt;br /&gt;
http://cs315b-wiki.stanford.edu/images/8/8b/Logp.pdf&lt;/div&gt;</summary>
		<author><name>Lreddy</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki1_1.3.3_1.3.4_chase2007&amp;diff=3347</id>
		<title>CSC/ECE 506 Fall 2007/wiki1 1.3.3 1.3.4 chase2007</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki1_1.3.3_1.3.4_chase2007&amp;diff=3347"/>
		<updated>2007-09-10T23:17:19Z</updated>

		<summary type="html">&lt;p&gt;Lreddy: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==&amp;lt;u&amp;gt;'''Introduction to Parallel Computer Architecture -&amp;gt;Fundamental Design Issues -&amp;gt; Communication and Replication (section 1.3.3)'''&amp;lt;/u&amp;gt;==&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Replication:&amp;lt;/u&amp;gt;&amp;lt;br&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''Replication is the creation of a local copy of data to help enable parallelism.'''&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Communication:&amp;lt;/u&amp;gt;&amp;lt;br&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''Communication occurs when data written from one process is read by another process.  Replication helps to avoid unnecessary communication.'''&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==&amp;lt;u&amp;gt;'''Introduction to Parallel Computer Architecture -&amp;gt;Fundamental Design Issues -&amp;gt; Performance (section 1.3.4)'''&amp;lt;/u&amp;gt;==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Computer Performance:&amp;lt;/u&amp;gt;&amp;lt;br&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''Computer performance is a measure of the output of a computer with with respect to time and resources used.'''&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Performance metrics:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''Following are the important metrics used to measure a computer's performance:'''&lt;br /&gt;
&lt;br /&gt;
'''1.&amp;lt;u&amp;gt;Latency:'''&amp;lt;/u&amp;gt; '''The time taken to perform an operation'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''2.&amp;lt;u&amp;gt;Bandwidth:'''&amp;lt;/u&amp;gt;'''The rate at which the operations are performed'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''3.&amp;lt;u&amp;gt;Cost:'''&amp;lt;/u&amp;gt; '''The impact these operations have on the execution time of the program'''&amp;lt;br&amp;gt;&lt;br /&gt;
 &lt;br /&gt;
'''All the above metrics can be used to define a uniprocessor systems where a single CPU operates.'''&lt;br /&gt;
&lt;br /&gt;
'''However, in the context of parallel computers, it becomes difficult to express the performance in above stated metrics. The reason for this is the communication between the processors that occurs mostly in the form of data transfers between the processors. So, to completely define the performace of a parallel computer, the following metrics are also considered.'''&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Data Transfer Time:&amp;lt;/u&amp;gt;===&lt;br /&gt;
'''It is the time taken for initiation of a data transfer and the time required for actual data transfer.  So the Data Transfer Time can be given as:'''&lt;br /&gt;
        &lt;br /&gt;
'''Transfer Time (n) = T+(n/B)'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''where'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''n = Amount of Data (in bytes)'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''B = Transfer Rate of the component moving the data (bytes per second)'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''T = Start up cost, a constant'''&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Overhead and Occupancy:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''The data transfer operations are initiated by the processor through communication assist'''&amp;lt;br&amp;gt;&lt;br /&gt;
'''The overhead is the time the processor spends initiating the transfer of data. This may be a fixed cost, if the processor imply has to tell the communication assist to start. The overhead can also be linear with Tranfer time, if the processor has to copy the data into the assist.'''&lt;br /&gt;
'''The occupancy is the time it takes for the data to pass through the slowest componant on the communication path. The occupancy limits how frequently communication operations can be initiated.The next data transfer will have to wait untill the critical resource is no longer occupied before it can use the same resource. '''&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;Communication Cost:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''It is the time that the processor spends in communicating with other processors. It can be given by the following:'''&lt;br /&gt;
&lt;br /&gt;
'''Communication Cost = Frequency of Communication * (Communication Time - Overlap)'''&lt;br /&gt;
&lt;br /&gt;
'''Frequency of Communication = Number of communications per unit of work'''&lt;br /&gt;
'''Communication Time = Overhead + Occupancy + Network Delay'''&lt;br /&gt;
'''Overlap = The portion of the communication operation that is performed concurrently with other useful work.'''&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;BSP Model:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
'''Bulk Synchronization Model:&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''The BSP model is a series of supersteps.  superstep on a BSP machine is given by W + G*H + L&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''W is the maximum possible work for a given processor&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''H is the maximum bytes sent or recieved by a processor&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''G is the number of available processors&amp;lt;BR&amp;gt;'''&lt;br /&gt;
'''L is the time required for the barrier synchronization&amp;lt;BR&amp;gt;'''&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;LogP Model:&amp;lt;/u&amp;gt;===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===&amp;lt;u&amp;gt;References:&amp;lt;/u&amp;gt;===&lt;br /&gt;
'''Parallel Computer Architecture- A Hardware/Software Approach by David E Culler, Jaswinder Pal Singh and Anoop Guptha'''&amp;lt;br/&amp;gt;&lt;br /&gt;
   &lt;br /&gt;
http://en.wikipedia.org/wiki/Computer_performance&lt;br /&gt;
&lt;br /&gt;
The BSP Model&lt;br /&gt;
http://wwwcs.uni-paderborn.de/fachbereich/AG/agmadh/WWW/bono/paper/nestedbsp/node6.html&lt;br /&gt;
&lt;br /&gt;
LogP: Towards a Realistic Model of Parallel Computation&lt;br /&gt;
http://cs315b-wiki.stanford.edu/images/8/8b/Logp.pdf&lt;/div&gt;</summary>
		<author><name>Lreddy</name></author>
	</entry>
</feed>