Scaling - Revision history

K Siegmund: /* Introduction */

2025-03-21T16:06:40Z

Introduction

← Older revision		Revision as of 18:06, 21 March 2025
Line 1:		Line 1:
	= Introduction =

	Before you submit large production runs on a bwHPC cluster you should define an optimal number of resources required for your compute job. Poor job efficiency means that hardware resources are wasted and a similar overall result could have been achieved using fewer hardware resources, leaving those for other jobs and reducing the queue wait time for all users.		Before you submit large production runs on a bwHPC cluster you should define an optimal number of resources required for your compute job. Poor job efficiency means that hardware resources are wasted and a similar overall result could have been achieved using fewer hardware resources, leaving those for other jobs and reducing the queue wait time for all users.

J Steuer at 11:26, 4 July 2023

2023-07-04T11:26:38Z

← Older revision		Revision as of 13:26, 4 July 2023
Line 5:		Line 5:
	The main advantage of today‘s compute clusters is that they are able to perform calculations in parallel. If and how your code is able to be parallelized is of fundamental importance for achieving good job efficiency and performance on an HPC cluster. A scaling analysis is done by identifying the number of resources (such as the number of cores, nodes, or GPUs) that enable the best performance for a given compute job.		The main advantage of today‘s compute clusters is that they are able to perform calculations in parallel. If and how your code is able to be parallelized is of fundamental importance for achieving good job efficiency and performance on an HPC cluster. A scaling analysis is done by identifying the number of resources (such as the number of cores, nodes, or GPUs) that enable the best performance for a given compute job.

	~~See also~~ [[Energy Efficient Cluster Usage]].		[[Energy Efficient Cluster Usage]] offers additional information on how to make the most out of the available HPC resources.

	= Considering Resources vs. Queue Time =		= Considering Resources vs. Queue Time =

J Steuer: /* Introduction */

2023-07-04T08:39:25Z

Introduction

← Older revision		Revision as of 10:39, 4 July 2023
Line 5:		Line 5:
	The main advantage of today‘s compute clusters is that they are able to perform calculations in parallel. If and how your code is able to be parallelized is of fundamental importance for achieving good job efficiency and performance on an HPC cluster. A scaling analysis is done by identifying the number of resources (such as the number of cores, nodes, or GPUs) that enable the best performance for a given compute job.		The main advantage of today‘s compute clusters is that they are able to perform calculations in parallel. If and how your code is able to be parallelized is of fundamental importance for achieving good job efficiency and performance on an HPC cluster. A scaling analysis is done by identifying the number of resources (such as the number of cores, nodes, or GPUs) that enable the best performance for a given compute job.

			See also [[Energy Efficient Cluster Usage]].

	= Considering Resources vs. Queue Time =		= Considering Resources vs. Queue Time =

K Siegmund: /* Scaling Efficiency */

2023-06-13T10:15:03Z

Scaling Efficiency

← Older revision		Revision as of 12:15, 13 June 2023
Line 21:		Line 21:

	When you run a parallel program, the problem has to be cut into several independent pieces. For some problems, this is easier than for others - but in every case, this produces an overhead of time used to divide the problem, distribute parts of it to tasks, and stitch the results together.		When you run a parallel program, the problem has to be cut into several independent pieces. For some problems, this is easier than for others - but in every case, this produces an overhead of time used to divide the problem, distribute parts of it to tasks, and stitch the results together.
	For a theoretical amount of "infinite calculations", calculating each problem on one single core would be the most efficient way to use the hardware		For a theoretical amount of "infinite calculations", calculating each problem on one single core would be the most efficient way to use the hardware.
	In extreme cases, when the problem is very hard to divide, using more compute cores, can even make the job finish later.		In extreme cases, when the problem is very hard to divide, using more compute cores, can even make the job finish later.

J Steuer: /* Basic Recipe to Determine Core Numbers */

2023-06-06T08:24:00Z

Basic Recipe to Determine Core Numbers

← Older revision		Revision as of 10:24, 6 June 2023
Line 92:		Line 92:

	(4b) IF the speedup is worse than a factor of 1.7, THEN using N cores wastes too many resources and N/2 cores should be used.		(4b) IF the speedup is worse than a factor of 1.7, THEN using N cores wastes too many resources and N/2 cores should be used.




	= Better Resource Usage by Increasing the System Size =		= Better Resource Usage by Increasing the System Size =

J Steuer: /* Scaling Efficiency */

2023-06-06T07:34:26Z

Scaling Efficiency

← Older revision		Revision as of 09:34, 6 June 2023
Line 40:		Line 40:

	However, there is a theoretical upper limit on how much faster you can solve the original problem by using additional cores ([[Wikipedia:Amdahl%27s_law\|Amdahl's Law]]).		However, there is a theoretical upper limit on how much faster you can solve the original problem by using additional cores ([[Wikipedia:Amdahl%27s_law\|Amdahl's Law]]).
	While a considerable part of a compute job might parallelize nicely, there is always some portion of time spent on I/O, such as saving or reading from disc, network limitations, communication overhead, or performing calculations that cannot be parallelized, thus reducing the speedup that I possible by simply adding more computational resources.		While a considerable part of a compute job might parallelize nicely, there is always some portion of time spent on I/O, such as saving or reading from disc, network limitations, communication overhead, or performing calculations that cannot be parallelized, thus reducing the speedup that is possible by simply adding more computational resources.

	From the speedup, a useful definition of efficiency can be derived:		From the speedup, a useful definition of efficiency can be derived:

J Steuer: /* Reasons for poor job efficiency */

2023-05-09T07:06:27Z

Reasons for poor job efficiency

← Older revision		Revision as of 09:06, 9 May 2023
Line 107:		Line 107:
	With increases in computational power, researchers can be increasingly ambitious about the scale and complexity of their programs.		With increases in computational power, researchers can be increasingly ambitious about the scale and complexity of their programs.

	= Reasons ~~for~~ ~~poor~~ ~~job~~ ~~efficiency~~ =		= Reasons For Poor Job Efficiency =

	Some simple causes for poor overall job efficiency are:		Some simple causes for poor overall job efficiency are:

J Steuer: /* Scaling Efficiency */

2023-05-08T16:10:49Z

Scaling Efficiency

J Steuer: /* Time to Finish: Considering Resources vs. Queue Time */

2023-05-08T16:06:16Z

Time to Finish: Considering Resources vs. Queue Time

← Older revision		Revision as of 18:06, 8 May 2023
Line 6:		Line 6:


	= ~~Time to Finish:~~ Considering Resources vs. Queue Time =		= Considering Resources vs. Queue Time =

	When a job is submitted to the scheduler of an HPC cluster, the job first waits in the queue before being executed on the compute nodes.		When a job is submitted to the scheduler of an HPC cluster, the job first waits in the queue before being executed on the compute nodes.

J Steuer: /* Scaling Efficiency */

2023-05-08T16:05:38Z

Scaling Efficiency

← Older revision		Revision as of 18:05, 8 May 2023
Line 52:		Line 52:

	This shows that for this example, only 30% of the resources are used to solve the problem, while 70% of our resources are spent on parallelization overhead.		This shows that for this example, only 30% of the resources are used to solve the problem, while 70% of our resources are spent on parallelization overhead.
	A semi-arbitrary cut-off for determining if a job is well-scaled is if ~~they waste~~ 50% of the computation or ~~less~~ on parallelization overhead.		A semi-arbitrary cut-off for determining if a job is well-scaled is if 50% or less of the computation is wasted on parallelization overhead.

	In many cases, the time needed for calculating a given code in serial, on a single core, is not accessible, as this would take a very long time and is usually the reason why an HPC cluster is needed in the first place.		In many cases, the time needed for calculating a given code in serial, on a single core, is not accessible, as this would take a very long time and is usually the reason why an HPC cluster is needed in the first place.
Line 68:		Line 68:

	A relative speedup of 1,76 is considered acceptable, so we could go ahead and run our example job on 100 cores on the HPC cluster.		A relative speedup of 1,76 is considered acceptable, so we could go ahead and run our example job on 100 cores on the HPC cluster.


	In the following a scaling analysis from a real example using the program VASP is shown.		In the following a scaling analysis from a real example using the program VASP is shown.
Line 75:		Line 74:

	[[File:Fig_speedup_and_efficiency_2.png\|700px\|center]]		[[File:Fig_speedup_and_efficiency_2.png\|700px\|center]]


	= Basic Recipe to Determine Core Numbers =		= Basic Recipe to Determine Core Numbers =

← Older revision		Revision as of 18:10, 8 May 2023
Line 49:		Line 49:
	Coming back to the previous example, we can now use the time of a serial calculation (1000 hours), the time our parallelized code took to finish (30 hours), the number of cores we used (100 cores), and calculate the efficiency.		Coming back to the previous example, we can now use the time of a serial calculation (1000 hours), the time our parallelized code took to finish (30 hours), the number of cores we used (100 cores), and calculate the efficiency.

	Efficiency = 1000 / (30 * 100)=0.3		Efficiency = 1000 / (30 * 100) = 0.3

	This shows that for this example, only 30% of the resources are used to solve the problem, while 70% of our resources are spent on parallelization overhead.		This shows that for this example, only 30% of the resources are used to solve the problem, while 70% of our resources are spent on parallelization overhead.
	A semi-arbitrary cut-off for determining if a job is well-scaled is if 50% or less of the computation is wasted on parallelization overhead.		A semi-arbitrary cut-off for determining if a job is well-scaled is if 50% or less of the computation is wasted on parallelization overhead.
			Therefore, we can determine that for this example too many resources are used.

	In many cases, the time needed for calculating a given code in serial, on a single core, is not accessible, as this would take a very long time and is usually the reason why an HPC cluster is needed in the first place.		In many cases, the time needed for calculating a given code in serial, on a single core, is not accessible, as this would take a very long time and is usually the reason why an HPC cluster is needed in the first place.
Line 63:		Line 64:
	Above 1.7 is considered acceptable, while a relative speedup of less than 1.7 should usually be avoided.		Above 1.7 is considered acceptable, while a relative speedup of less than 1.7 should usually be avoided.
	We can illustrate this by using our simple parallelization example from above.		We can illustrate this by using our simple parallelization example from above.
	If we assume that our code would have finished in 53 hours when using 50 cores, we can calculate the relative speedup:		If we assume that our code would have finished in 45 hours when using 50 cores, we can calculate the relative speedup:

	Relative Speedup (50 Cores -> 100 Cores) = Time(50 Cores) / Time(100 Cores) = 53 h / 30 h = ~1,76		Relative Speedup (50 Cores -> 100 Cores) = Time(50 Cores) / Time(100 Cores) = 45 h / 30 h = 1,5

	A relative speedup of 1,76 is considered ~~acceptable~~, so we ~~could go ahead and~~ run our example ~~job~~ on 100 cores on the HPC cluster.		A relative speedup of 1,5 is considered undesirable, so we should run our example code using 50 rather than 100 cores on the HPC cluster.

	In the following a scaling analysis from a real example using the program VASP is shown.		In the following a scaling analysis from a real example using the program VASP is shown.