Scaling - Revision history

Pysdlb at 15:56, 16 November 2022

2022-11-16T15:56:19Z

Pysdlb: /* Scaling Measurement Guidelines */

2022-11-16T09:42:27Z

‎Scaling Measurement Guidelines

Pysdlb: /* Scaling Measurement Guidelines */

2022-11-16T09:40:45Z

‎Scaling Measurement Guidelines

Pysdlb at 14:46, 9 June 2022

2022-06-09T14:46:08Z

Pysdlb at 11:06, 3 May 2022

2022-05-03T11:06:03Z

Pysdlb at 11:25, 2 January 2020

2020-01-02T11:25:12Z

Pysdlb at 11:24, 2 January 2020

2020-01-02T11:24:36Z

Pysdlb at 11:53, 18 December 2019

2019-12-18T11:53:22Z

Pysdlb at 11:30, 18 December 2019

2019-12-18T11:30:46Z

Pysdlb: Created page with "TOC ==Scaling Jobs== HPC by its very nature can use multiple cores and nodes to scale (and speed up a job) by using more processing units. This is an assumption which..."

2019-12-18T09:49:07Z

Created page with "__TOC__ ==Scaling Jobs== HPC by its very nature can use multiple cores and nodes to scale (and speed up a job) by using more processing units. This is an assumption which..."

New page

__TOC__

==Scaling Jobs==

HPC by its very nature can use multiple cores and nodes to scale (and speed up a job) by using more processing units.

This is an assumption which can be seriously flawed once we understand the nature of the software and hardware combination.

* This page will look more deeply into this area by splitting the potential issues down:

@@ Line 34: / Line 34: @@
 ===GPU considerations===
-GPUs are very good at using the thousands of streaming processors contained with the units, so are ideal for large parallel computations (such as matrix mathematics). However, there is a cost of moving data from the CPU memory to GPU memory which is costly in terms of computation time. So, creating the data on the GPU or using large data sets which offset the transfer cost is preferable in terms of a more efficient resource.
+GPUs are very good at using the thousands of streaming processors contained within the units, so are ideal for large parallel computations (such as matrix mathematics). However, there is a cost of moving data from the CPU memory to GPU memory which is costly in terms of computation time. So, creating the data on the GPU or using large data sets which offset the transfer cost is preferable in terms of a more efficient resource.
 * GPU can provide very fast speed-ups, but beware you may find your codes going slower if the problem isn't properly understood.

← Older revision		Revision as of 09:42, 16 November 2022
Line 56:		Line 56:


−	[[Main Page ~~#Support~~\| Main Page]] / [[FurtherTopics/FurtherTopics #~~Support~~\| Further Topics]]	+	[[Main Page\| Main Page]] / [[FurtherTopics/FurtherTopics #Further Reading\| Further Topics]]

← Older revision		Revision as of 09:40, 16 November 2022
Line 52:		Line 52:
	* measure multiple independent runs per job size (average results and remove outliers as appropriate).		* measure multiple independent runs per job size (average results and remove outliers as appropriate).
	* use a problem state or configuration that best matches your intended production runs (scaling should be measured based on the overall performance of the application, no simplified models or preferential configurations).		* use a problem state or configuration that best matches your intended production runs (scaling should be measured based on the overall performance of the application, no simplified models or preferential configurations).
		+
		+
		+
		+
		+	[[Main Page #Support\| Main Page]] / [[FurtherTopics/FurtherTopics #Support\| Further Topics]]

@@ Line 34: / Line 34: @@
 ===GPU considerations===
-GPU are very good at using the thousands of streaming processors contained with the units, so are ideal for large parallel computations (such as matrix mathematics). However, there is a cost of moving data from the CPU memory to GPU memory which is costly in terms of computation time. So, creating the data on the GPU or using large data sets which offset the transfer cost is preferable in terms of a more efficient resource.
+GPUs are very good at using the thousands of streaming processors contained with the units, so are ideal for large parallel computations (such as matrix mathematics). However, there is a cost of moving data from the CPU memory to GPU memory which is costly in terms of computation time. So, creating the data on the GPU or using large data sets which offset the transfer cost is preferable in terms of a more efficient resource.
 * GPU can provide very fast speed-ups, but beware you may find your codes going slower if the problem isn't properly understood.

@@ Line 3: / Line 3: @@
 ==Scaling Jobs==
-HPC by its very nature can use multiple cores and nodes to scale (and speed up a job) by using more processing units.  A common task in HPC is measuring the scalability (also referred to as the scaling efficiency) of an application. This measurement indicates how efficient an application is when using increasing numbers of parallel processing elements (CPUs / cores / processes / threads / etc.).
+HPC by its very nature can use multiple cores and nodes to scale (and speed up a job) by using more processing units.  A common task in HPC is measuring the scalability (also referred to as the scaling efficiency) of an application. This measurement indicates how efficient an application is when using increasing numbers of parallel processing elements (CPUs / cores/processes/threads / etc.).
 This is an assumption which can be seriously flawed once we understand the nature of the software and hardware combination.
@@ Line 15: / Line 15: @@
 ===Node Interconnect Bandwith===
-When using MPI across many nodes remember your program needs to send and receive data across the interconnect (the fast network which connects all the nodes together). Again, it is only a very few programs that can scale to a large number of nodes effeciently. Most programs will have a 'sweet spot' (for example 16 nodes), or they will provide very little improvement (< 1% say) for doubling the amount of computing resource deployed to them. In most cases this can only be observed through benchtesting, and is difficult to theoretically calculate.
+When using MPI across many nodes remember your program needs to send and receive data across the interconnect (the fast network which connects all the nodes together). Again, it is only a very few programs that can scale to a large number of nodes efficiently. Most programs will have a 'sweet spot' (for example 16 nodes), or they will provide very little improvement (< 1% say) for doubling the amount of computing resource deployed to them. In most cases, this can only be observed through bench-testing and is difficult to theoretically calculate.
@@ Line 26: / Line 26: @@
 ===Disk I/O Bandwidth===
-Programs that generate alot of disk accesses can be magnified when multiple processing cores are being used.
+Programs that generate a lot of disk accesses can be magnified when multiple processing cores are being used.
 [[File:beegfs.jpg]]
@@ Line 34: / Line 34: @@
 ===GPU considerations===
-GPU are very good at using the thousands of streaming processors contained with the units, so are ideal for large parallel computations (such as matrix mathematics). However there is a cost of moving data from the CPU memory to GPU memory which is costly in terms of computation time. So, creating the data on the GPU or using large data sets which offset the transfer cost are preferable in terms of a more efficient resource.
+GPU are very good at using the thousands of streaming processors contained with the units, so are ideal for large parallel computations (such as matrix mathematics). However, there is a cost of moving data from the CPU memory to GPU memory which is costly in terms of computation time. So, creating the data on the GPU or using large data sets which offset the transfer cost is preferable in terms of a more efficient resource.
-* GPU can provide very fast speed-ups; but beware you may find your codes going slower if the problem isn't properly understood.
+* GPU can provide very fast speed-ups, but beware you may find your codes going slower if the problem isn't properly understood.
 [[File:GPU-accelerators.png]]
@@ Line 42: / Line 42: @@
 ==Scaling Measurement Guidelines==
-Further to basic code performance and optimization concerns (ie. the single thread performance), one should consider the following when timing their application:
+Further to basic code performance and optimization concerns (ie. the single-thread performance), one should consider the following when timing their application:
 * use wallclock time units or equivalent (eg. timesteps completed per second, etc.)
-* measure using multiple computer systems (most importantly ones that have significantly different processor / network balances (ie. CPU speed vs. interconnect speed).
+* measure using multiple computer systems (most important ones that have significantly different processor/network balances (ie. CPU speed vs. interconnect speed).
 * measure using job sizes that span:
-** from 1 to the number of processing elements per node for threaded jobs
+** From 1 to the number of processing elements per node for threaded jobs
-** from 1 to the total number of processes requested for MPI
+** From 1 to the total number of processes requested for MPI
 ** job size increments should be in power-of-2 or equivalent (cube powers for weak-scaling 3D simulations, for example)
 * measure multiple independent runs per job size (average results and remove outliers as appropriate).
 * use a problem state or configuration that best matches your intended production runs (scaling should be measured based on the overall performance of the application,  no simplified models or preferential configurations).

← Older revision		Revision as of 11:25, 2 January 2020
Line 39:		Line 39:

	[[File:GPU-accelerators.png]]		[[File:GPU-accelerators.png]]
		+
		+	==Scaling Measurement Guidelines==

	Further to basic code performance and optimization concerns (ie. the single thread performance), one should consider the following when timing their application:		Further to basic code performance and optimization concerns (ie. the single thread performance), one should consider the following when timing their application:

← Older revision		Revision as of 11:30, 18 December 2019
Line 8:		Line 8:

	* This page will look more deeply into this area by splitting the potential issues down:		* This page will look more deeply into this area by splitting the potential issues down:
		+
		+	===Memory Bandwidth===
		+
		+	When running on many cores with memory access there is only a finite bandwidth of memory access (even with modern memory channels), so acceleration even with a node is not linear and with the effect of [https://en.wikipedia.org/wiki/False_sharing false caching]; performance can be degraded significantly more.
		+
		+	===Node Interconnect Bandwith===
		+
		+	When using MPI across many nodes remember your program needs to send and receive data across the interconnect (the fast network which connects all the nodes together). Again, it is only a very few programs that can scale to a large number of nodes effeciently. Most programs will have a 'sweet spot' (for example 16 nodes), or they will provide very little improvement (< 1% say) for doubling the amount of computing resource deployed to them. In most cases this can only be observed through benchtesting, and is difficult to theoretically calculate.
		+
		+	[[File:Scaling_amdahl.png]]
		+
		+	* '''s''' is the amount of time spent in not parallel tasks which could include data transfers like MPI and disk
		+
		+	===Disk I/O Bandwidth===
		+
		+	===GPU considerations===

Scaling - Revision history

Pysdlb at 15:56, 16 November 2022

Pysdlb: /* Scaling Measurement Guidelines */

Pysdlb: /* Scaling Measurement Guidelines */

Pysdlb at 14:46, 9 June 2022

Pysdlb at 11:06, 3 May 2022

Pysdlb at 11:25, 2 January 2020

Pysdlb at 11:24, 2 January 2020

Pysdlb at 11:53, 18 December 2019

Pysdlb at 11:30, 18 December 2019

Pysdlb: Created page with "__TOC__ ==Scaling Jobs== HPC by its very nature can use multiple cores and nodes to scale (and speed up a job) by using more processing units. This is an assumption which..."

Pysdlb: Created page with "TOC ==Scaling Jobs== HPC by its very nature can use multiple cores and nodes to scale (and speed up a job) by using more processing units. This is an assumption which..."