代写CS257、c/c++编程设计代做
- 首页 >> C/C++编程 CS257 Advanced Computer Architecture
Coursework Assignment
Term 2, 2023/24
Contents
1 Introduction 2
2 Submission 2
3 Introduction to ACACGS 3
4 Compiling and Running the Code 4
4.1 Visualisation Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5 Hardware Details 6
6 How will my code be tested for performance? 7
7 Rules 7
8 Where do I start? 7
9 Instructions for Submission 7
10 Support 7
1
1 Introduction
The purpose of this coursework is to give you some hands-on experience in code optimisation. By the time you read
this, you will have encountered a variety of code optimisation techniques including loop unrolling and vectorisation.
2 Submission
Your submission will consist of two parts:
1. Optimised Code (60%)
A piece of C code based on the initial implementation provided. This C code will be assessed with respect
to your selection and understanding of optimisations, functional correctness, i.e., producing the right answer,
and execution speed.
2. Written Report (40%)
A report (4 pages maximum, excluding references) detailing your design and implementation decisions. Your
report will be evaluated with respect to your understanding of code optimisation techniques and the optimisations you attempted. This means that your report should explain:
(a) which optimisations you did and did not use;
(b) why your chosen optimisations improve performance; and
(c) how your chosen optimisations affect floating-point correctness.
Given that you may apply many different optimisations, a sensible approach is to build your solution incrementally, saving each partial solution and documenting the impact of each optimisation you make. This means that it
is in your interest to attempt as many different optimisations or combinations of optimisations as you can.
You may discuss optimisation techniques with others but you are not allowed to collaborate on solutions to this
assignment. Please remember that the University takes all forms of plagiarism seriously.
2
3 Introduction to ACACGS
ACSCGS is a conjugate gradient proxy application for a 3D mesh. The simulation will execute for either a fixed
number of timesteps or alternatively until the residual value falls below a given threshold. This is done for a given
mesh size, which is passed in at runtime through command-line arguments.
In this proxy application, a force is applied to each edge boundary of the cuboid, which is then propagated
throughout the mesh. As each time step passes, the force is dissipated within the mesh, until the amount of residual
is significantly small that the simulation stops (as there are no more calculations to perform), or a set number of
time steps have passed.
In addition to providing numeric solutions, the code can also generate visuals which depict the pressure within
the mesh throughout the simulation run. Creating the visualisations relies on two optional packages, Silo and VisIt,
which are available on the DCS systems.
Figure 1: Pressure Matrix Visualisation
3
4 Compiling and Running the Code
The code includes a Makefile file to build the program. You can compile all of the code using the command make.
You should not modify the Makefile file, but examining it may prove helpful in some situations.
While the DCS machines do include a version of gcc, it is preferable to use a more recent version. On the DCS
systems, you can make version 9 the default by using the module load gcc9 command. Once this is loaded you
can simply type make to build the code, which will create an executable named acacgs in the directory. To clean
up the directory, you can run make clean.
To run the code, you need to provide the three dimensions for the mesh as three parameters to the executable.
For example to execute the provided code on a small 10x10x10 mesh you would enter ./acacgs 10 10 10. On my
system the output for the code is below. This information is also stored in a file, which is named after the wallclock
date and time of when the program was first executed (for example, 2023_01_26_12_00_00.txt).
===== Final Statistics =====
Executable name: ./acacgs
Dimensions: 10 10 10
Number of iterations: 149
Final residual: 2.226719e-92
=== Time ==
Total: 1.126600e-02 seconds
ddot Kernel: 8.390000e-04 seconds
waxpby Kernel: 1.087000e-03 seconds
sparsemv Kernel: 9.123000e-03 seconds
=== FLOP ==
Total: 9.536000e+06 floating point operations
ddot Kernel: 5.960000e+05 floating point operations
waxpby Kernel: 8.940000e+05 floating point operations
sparsemv Kernel: 8.046000e+06 floating point operations
=== MFLOP/s ==
Total: 8.464406e+02 MFLOP/s
ddot Kernel: 7.103695e+02 MFLOP/s
waxpby Kernel: 8.224471e+02 MFLOP/s
sparsemv Kernel: 8.819467e+02 MFLOP/s
Difference between computed and exact = 1.110223e-15
You will find more detailed instructions to build the code in the README.md file, including flags to turn on
verbose mode, which will output details for each timestep in the simulation, and flags for enabling visualisation.
4.1 Visualisation Generation
To enable visualisation outputs, you must build your code using make SILO=1. This will then compile your code
in a way which produces files suitable for visualisation in VisIt. If you are working remotely and want to visualise
the coursework, it will be quicker and easier for you to copy the files to your local machine, then utilise VisIt on
the local machine to visualise the cuboid. Before you make the program, make sure you load the SILO module
(module load cs257-silo).
When the program is ran with visualisations, each timestep will produce a SILO file within a directory named
after the wallclock date and time (for example: 2023_01_26_12_00_00). In this directory will be a collection of
.silo files, each named outputXXXX.silo, where XXXX represents the timestep it relates to.
Once the program has finished, these can be utilised in Visit. To do so, load the VisIt module (module load
cs257-visit) and open VisIt using the command visit. From here, you will get 2 windows. The smaller, skinner
one is the control window and is used to manage everything that will be displayed. The larger window is the display
window. In the control window, select Open, and navigate to the directory with the SILO files. You should then
be able to select these SILO files.
4
Now that the SILO files have been loaded, we can now draw some given variables. To do this, click on the Add
and select a mode and a variable that should be viewed. One of the nicest ones to use is Volume and either x_nodal
or p_nodal. When you have finished adding elements, click on Draw. This will generate an image in the display
window, that can be dragged around so that the cuboid can be viewed from different angles. The control window
has a play button, which will run through each timestep.
Visualisations are nice to have, but for performance purposes we turn them off as they write a significant amount
of data to disk.
Table 1: Visualisation Data File Sizes
x y z Cells Approximate Data Size
10 10 10 1000 4MB
25 25 25 15,625 39MB
50 50 50 125,000 301MB
100 100 100 1,000,000 2.4GB
200 200 200 8,000,000 19.3GB
There is the potential to go significantly over your DCS disk quota with large meshes. I recommend that you
do not exceed 30x30x30 for producing visualisations on the DCS machines. If you are developing your solution on
your personal machine then you may wish to produce larger visualisations.
5
5 Hardware Details
On a Linux system, you can read the processor information using the command cat /proc/cpuinfo or lscpu.
This will provide full details on the CPU in the machine, including the CPU model, number of cores, the clock
frequency and supported extensions. I strongly recommend taking a look at this on your development machine.
For the purposes of assessment, your code will be run on a DCS machine with 4 cores. The output from lscpu
can be seen below:
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Thread(s) per core: 1
Core(s) per socket: 4
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 158
Model name: Intel(R) Core(TM) i5-7500 CPU @ 3.40GHz
Stepping: 9
CPU MHz: 3400.000
CPU max MHz: 3800.0000
CPU min MHz: 800.0000
BogoMIPS: 6816.00
Virtualization: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 6144K
NUMA node0 CPU(s): 0-3
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36
clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm
constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid
aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3
sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes
xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault invpcid_single pti ssbd
ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1
avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec
xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear
flush_l1d arch_capabilities
Machines matching this specification are available in the cs257 queue of the Batch Compute System in the
Department (referred to as kudu in the labs). You will learn how to use this system during the lab sessions, so
there will be time to get used to it.
6
6 How will my code be tested for performance?
Your submission will be tested on a range of input sizes to evaluate how robust your performance improvements
are. It is recommended that you try testing your solution on inputs that are not cubes to see if there are any
weaknesses in your optimisation strategies. The 7-pt stencil option will not be used for testing your code.
Your code will be executed five times for each problem size on the target hardware. The highest and lowest
runtimes will be discarded, and the mean of the three remaining values will be taken as your runtime for that
problem size.
7 Rules
Your submitted solution must:
• Compile on the DCS workstations.
Your submitted solution must not:
• Alter the Makefile or add or edit any compiler flags;
• Use instruction sets not supported by the DCS machines;
• Require additional hardware e.g., GPUs;
• Add relaxed math options to the compile line, e.g., -ffast-math. Note: Manual use of approximate math
functions is acceptable.
8 Where do I start?
This can seem like a daunting project, but we can break it down into a number of steps.
1. Compile and run the code as provided. This is a quick easy check to make sure your environment is setup
correctly.
2. Read the code. Start in main.c and follow it through. The functions are well documented with Doxygen
comments. Don’t panic - you are not expected to understand the physics in the code.
3. Measure the runtime of the code for reference purposes.
4. Figure our where the most intensive sections of code are.
5. Develop a small optimisation.
6. Run the code and review the impact of your changes.
7. Repeat steps 5 and 6 until you have exhausted your performance ideas.
9 Instructions for Submission
Your solution should be submitted using Tabula. Please ensure that your code works on DCS machines prior to
submission.
Submission Deadline: Wednesday 20th March 2024 @ 12 Noon
Files Required: A single file named coursework.zip which should contain all of your code at the top-level (i.e.
no subdirectories) and the report file as a PDF. All files should be submitted through Tabula.
10 Support
Support can be found from one of your Teaching Assistants: Stephen Xu (stephen.xu@warwick.ac.uk), James
Macer-Wright james.macer-wright@warwick.ac.uk or the module organiser via email.
7
Coursework Assignment
Term 2, 2023/24
Contents
1 Introduction 2
2 Submission 2
3 Introduction to ACACGS 3
4 Compiling and Running the Code 4
4.1 Visualisation Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5 Hardware Details 6
6 How will my code be tested for performance? 7
7 Rules 7
8 Where do I start? 7
9 Instructions for Submission 7
10 Support 7
1
1 Introduction
The purpose of this coursework is to give you some hands-on experience in code optimisation. By the time you read
this, you will have encountered a variety of code optimisation techniques including loop unrolling and vectorisation.
2 Submission
Your submission will consist of two parts:
1. Optimised Code (60%)
A piece of C code based on the initial implementation provided. This C code will be assessed with respect
to your selection and understanding of optimisations, functional correctness, i.e., producing the right answer,
and execution speed.
2. Written Report (40%)
A report (4 pages maximum, excluding references) detailing your design and implementation decisions. Your
report will be evaluated with respect to your understanding of code optimisation techniques and the optimisations you attempted. This means that your report should explain:
(a) which optimisations you did and did not use;
(b) why your chosen optimisations improve performance; and
(c) how your chosen optimisations affect floating-point correctness.
Given that you may apply many different optimisations, a sensible approach is to build your solution incrementally, saving each partial solution and documenting the impact of each optimisation you make. This means that it
is in your interest to attempt as many different optimisations or combinations of optimisations as you can.
You may discuss optimisation techniques with others but you are not allowed to collaborate on solutions to this
assignment. Please remember that the University takes all forms of plagiarism seriously.
2
3 Introduction to ACACGS
ACSCGS is a conjugate gradient proxy application for a 3D mesh. The simulation will execute for either a fixed
number of timesteps or alternatively until the residual value falls below a given threshold. This is done for a given
mesh size, which is passed in at runtime through command-line arguments.
In this proxy application, a force is applied to each edge boundary of the cuboid, which is then propagated
throughout the mesh. As each time step passes, the force is dissipated within the mesh, until the amount of residual
is significantly small that the simulation stops (as there are no more calculations to perform), or a set number of
time steps have passed.
In addition to providing numeric solutions, the code can also generate visuals which depict the pressure within
the mesh throughout the simulation run. Creating the visualisations relies on two optional packages, Silo and VisIt,
which are available on the DCS systems.
Figure 1: Pressure Matrix Visualisation
3
4 Compiling and Running the Code
The code includes a Makefile file to build the program. You can compile all of the code using the command make.
You should not modify the Makefile file, but examining it may prove helpful in some situations.
While the DCS machines do include a version of gcc, it is preferable to use a more recent version. On the DCS
systems, you can make version 9 the default by using the module load gcc9 command. Once this is loaded you
can simply type make to build the code, which will create an executable named acacgs in the directory. To clean
up the directory, you can run make clean.
To run the code, you need to provide the three dimensions for the mesh as three parameters to the executable.
For example to execute the provided code on a small 10x10x10 mesh you would enter ./acacgs 10 10 10. On my
system the output for the code is below. This information is also stored in a file, which is named after the wallclock
date and time of when the program was first executed (for example, 2023_01_26_12_00_00.txt).
===== Final Statistics =====
Executable name: ./acacgs
Dimensions: 10 10 10
Number of iterations: 149
Final residual: 2.226719e-92
=== Time ==
Total: 1.126600e-02 seconds
ddot Kernel: 8.390000e-04 seconds
waxpby Kernel: 1.087000e-03 seconds
sparsemv Kernel: 9.123000e-03 seconds
=== FLOP ==
Total: 9.536000e+06 floating point operations
ddot Kernel: 5.960000e+05 floating point operations
waxpby Kernel: 8.940000e+05 floating point operations
sparsemv Kernel: 8.046000e+06 floating point operations
=== MFLOP/s ==
Total: 8.464406e+02 MFLOP/s
ddot Kernel: 7.103695e+02 MFLOP/s
waxpby Kernel: 8.224471e+02 MFLOP/s
sparsemv Kernel: 8.819467e+02 MFLOP/s
Difference between computed and exact = 1.110223e-15
You will find more detailed instructions to build the code in the README.md file, including flags to turn on
verbose mode, which will output details for each timestep in the simulation, and flags for enabling visualisation.
4.1 Visualisation Generation
To enable visualisation outputs, you must build your code using make SILO=1. This will then compile your code
in a way which produces files suitable for visualisation in VisIt. If you are working remotely and want to visualise
the coursework, it will be quicker and easier for you to copy the files to your local machine, then utilise VisIt on
the local machine to visualise the cuboid. Before you make the program, make sure you load the SILO module
(module load cs257-silo).
When the program is ran with visualisations, each timestep will produce a SILO file within a directory named
after the wallclock date and time (for example: 2023_01_26_12_00_00). In this directory will be a collection of
.silo files, each named outputXXXX.silo, where XXXX represents the timestep it relates to.
Once the program has finished, these can be utilised in Visit. To do so, load the VisIt module (module load
cs257-visit) and open VisIt using the command visit. From here, you will get 2 windows. The smaller, skinner
one is the control window and is used to manage everything that will be displayed. The larger window is the display
window. In the control window, select Open, and navigate to the directory with the SILO files. You should then
be able to select these SILO files.
4
Now that the SILO files have been loaded, we can now draw some given variables. To do this, click on the Add
and select a mode and a variable that should be viewed. One of the nicest ones to use is Volume and either x_nodal
or p_nodal. When you have finished adding elements, click on Draw. This will generate an image in the display
window, that can be dragged around so that the cuboid can be viewed from different angles. The control window
has a play button, which will run through each timestep.
Visualisations are nice to have, but for performance purposes we turn them off as they write a significant amount
of data to disk.
Table 1: Visualisation Data File Sizes
x y z Cells Approximate Data Size
10 10 10 1000 4MB
25 25 25 15,625 39MB
50 50 50 125,000 301MB
100 100 100 1,000,000 2.4GB
200 200 200 8,000,000 19.3GB
There is the potential to go significantly over your DCS disk quota with large meshes. I recommend that you
do not exceed 30x30x30 for producing visualisations on the DCS machines. If you are developing your solution on
your personal machine then you may wish to produce larger visualisations.
5
5 Hardware Details
On a Linux system, you can read the processor information using the command cat /proc/cpuinfo or lscpu.
This will provide full details on the CPU in the machine, including the CPU model, number of cores, the clock
frequency and supported extensions. I strongly recommend taking a look at this on your development machine.
For the purposes of assessment, your code will be run on a DCS machine with 4 cores. The output from lscpu
can be seen below:
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Thread(s) per core: 1
Core(s) per socket: 4
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 158
Model name: Intel(R) Core(TM) i5-7500 CPU @ 3.40GHz
Stepping: 9
CPU MHz: 3400.000
CPU max MHz: 3800.0000
CPU min MHz: 800.0000
BogoMIPS: 6816.00
Virtualization: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 6144K
NUMA node0 CPU(s): 0-3
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36
clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm
constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid
aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3
sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes
xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault invpcid_single pti ssbd
ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1
avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec
xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear
flush_l1d arch_capabilities
Machines matching this specification are available in the cs257 queue of the Batch Compute System in the
Department (referred to as kudu in the labs). You will learn how to use this system during the lab sessions, so
there will be time to get used to it.
6
6 How will my code be tested for performance?
Your submission will be tested on a range of input sizes to evaluate how robust your performance improvements
are. It is recommended that you try testing your solution on inputs that are not cubes to see if there are any
weaknesses in your optimisation strategies. The 7-pt stencil option will not be used for testing your code.
Your code will be executed five times for each problem size on the target hardware. The highest and lowest
runtimes will be discarded, and the mean of the three remaining values will be taken as your runtime for that
problem size.
7 Rules
Your submitted solution must:
• Compile on the DCS workstations.
Your submitted solution must not:
• Alter the Makefile or add or edit any compiler flags;
• Use instruction sets not supported by the DCS machines;
• Require additional hardware e.g., GPUs;
• Add relaxed math options to the compile line, e.g., -ffast-math. Note: Manual use of approximate math
functions is acceptable.
8 Where do I start?
This can seem like a daunting project, but we can break it down into a number of steps.
1. Compile and run the code as provided. This is a quick easy check to make sure your environment is setup
correctly.
2. Read the code. Start in main.c and follow it through. The functions are well documented with Doxygen
comments. Don’t panic - you are not expected to understand the physics in the code.
3. Measure the runtime of the code for reference purposes.
4. Figure our where the most intensive sections of code are.
5. Develop a small optimisation.
6. Run the code and review the impact of your changes.
7. Repeat steps 5 and 6 until you have exhausted your performance ideas.
9 Instructions for Submission
Your solution should be submitted using Tabula. Please ensure that your code works on DCS machines prior to
submission.
Submission Deadline: Wednesday 20th March 2024 @ 12 Noon
Files Required: A single file named coursework.zip which should contain all of your code at the top-level (i.e.
no subdirectories) and the report file as a PDF. All files should be submitted through Tabula.
10 Support
Support can be found from one of your Teaching Assistants: Stephen Xu (stephen.xu@warwick.ac.uk), James
Macer-Wright james.macer-wright@warwick.ac.uk or the module organiser via email.
7