Difference between revisions of "HPC-Dictionary"
|Line 78:||Line 78:|
== Thread ==
== Thread ==
; Hardware Threads:
; Hardware Threads
; Software Threads: A process may have several threads, sharing the same address space, but each thread having its own stack. Threads can be seen as "parallel execution pathes" ''within the same program'' (eg. to work
: the same processor core can (and is configured to) execute more than one execution path in parallel ().
; Software Threads
: A process may have several threads, sharing the same address space, but each thread having its own stack . Threads can be seen as "parallel execution pathes" ''within the same program'' (eg. to work through different and independant data arrays ).
== Random Access Memory (RAM) ==
== Random Access Memory (RAM) ==
Revision as of 12:48, 3 June 2019
Unix describes a family of operating systems. Popular representatives include Ubuntu, CentOS and even MacOS, although the latter is not common on HPC systems. Main key features are its shell and file system.
The file system describes the directory structure of an operating system. On Unix-based systems the top most directory is
/, which is called the root directory. As the name may suggest the file system is organized hierarchically (like a tree) from there on out. Most of the time you will be working in directories starting with
/home/<username>, which represents the user's home directory. All directories starting with
/home/<username> can freely be modified to the will of the user.
An environment variable is a dynamic object on a computer, which stores a value. On Unix-based operating systems you can:
- set the value of a variable with:
- read the value of a variable with:
Environment variables can be referenced by software (or the user) to get or set information about the system. Down below are a few examples of environment variables, which might give you an idea for their use and usefulness.
||your current username|
||the directory you are currently in|
||hostname of the computer you are on|
||your home directory|
||list of directories searched for when a command is executed|
A cluster in the HPC sense refers to a collection of multiple nodes, usually connected via a network providing high bandwidth and low latency communication. Accessing a cluster is possible by connecting to its specific login nodes.
A node is an individual computer consisting of one or more sockets.
Backend nodes (compute nodes) are reserved for executing the actual (scientific) calculation computations (memory demanding and long running applications). These compute nodes are the most powerful, but also most power consuming part of a cluster as they make up around 98% of it. Since these nodes are not directly accessible by the user, a scheduler manages their access. In order to run on these nodes, a batch job needs to be submitted to the batch system via a scheduler specific command.
Copy nodes are reserved for transfering data to or from a cluster. They usually offer a better connection than other nodes and minimize the disturbance of other users on the system. Depending on the facility, software installed on these nodes may differ from other ones due to their restricted use case, though not every facility chooses to install a designated copy node at all. As an alternative login nodes may be used to move data between systems.
Synonym for login node.
Login nodes are reserved for connecting to the cluster of a facility. Most of the time they can also be used for testing and performing interactive tasks (e.g. the analysis of previously collected application profiles). These test runs should generally not exceed execution times of just a few minutes and may only be used to verify that your software is running correctly on the system and its environment before submitting batch jobs to the batch system.
Central Processing Unit (CPU)
The term "CPU" is widely used in the field of HPC, yet it lacks a precise definition. It is mostly used to describe the concrete hardware architecture of a node, but should generally be avoided due to possible misunderstandings and ambiguities - see below.
A socket is the physical package (processor) which contains multiple cores sharing the same memory.
A core is the smallest unit of computing, having one or more hardware threads (if Multithreading configured) and is responsible for executing instructions. In the "pre multicore" era, a processor had just one core.
- Hardware Threads
- If the same processor core can (and is configured to) execute more than one execution path in parallel (Hyperthreading, a hardware setting).
- Software Threads
- A process may have several threads, all sharing the same memory address space, but each thread having its own stack (Multithreading, eg. via OpenMP). Threads can be seen as "parallel execution pathes" within the same program (eg. to work through different and independant data arrays in parallel).
Software threads are not dependent on hardware threads -- you can run multithreaded applications on systems without Hyperthreading.
Random Access Memory (RAM)
The RAM is used as working memory for the cores. This is volatile memory meaning, that after a process ends the data in the RAM is no longer available. The RAM is shared between all sockets on a node, though it is physically separated for each socket.
A cache is a relatively small amount of fast memory (compared to RAM), on the CPU chip. A modern CPU has three cache levels: L1 and L2 are specific to each core, while L3 (or Last Level Cache (LLC)) is shared among all cores of a CPU.
Scalability describes how well an application can use an increasing amount of hardware resources. Good scalability in general means reduced runtimes when more and more cores are used to solve the same or larger problems.
Typically, applications will hit an upper limit of cores beyond they don't scale further, ie. more cores don't lead to lower runtimes (or even increase it again).
However, good scalability can also imply that the execution time remains the same, when the problem size grows similarly to the hardware resources.
By involving more and more processor cores to solve the same problem (size), the application still achieves reduced runtimes.
By involving more and more processor cores, the application can tackle larger problems (size), though you can no longer achieve reduced runtimes on the same problem (size).