Hi Kent,
Thanks! We reran our test set with the new SDK on JLSE, and saw a few changes:
1. For two tests (in directories /soft/restricted/intel_csa/apps/testing/source/xgc_get_acoef and HPCCG_888_8worker_ilpl), we got compile-time errors that looked like:
```
# icx -c -fopenmp -fopenmp-targets=csa='-O3 -fiopenmp' ./get_acoef_vec_csa.c
# graph tool import time: 1.05
# No handlers could be found for logger "dfglib2.visa_arch"
# icx -c -fopenmp -fopenmp-targets=csa='-O3 -fiopenmp' ./get_acoef_vec.c
# warning: use of .module/.endmodule will become mandatory in the future
# graph tool import time: 1.05
# vpr: failed to complete successfully, saying: Error: vpr_exit(VPR_EXIT_FATAL) called from 'check_netlist.c' at line 173 (thread 0)
#
# csasim error: vpr tool failed. Rerun with CSASIM_SAVE_TEMPS=1 if the logfile might help diagnose this.
#
# processing Module at /tmp/csa_lt_20190408_190250_IGSev8/csa_graph_csa_graph_csa_visa.mod_dumped.s failed
# error: failed to process the vISA module for V1-in-vISA
```
2. For the load/reduction bandwidth tests (in directory /soft/restricted/intel_csa/apps/testing/source/qsub_mem_cache_stream/, files cache_test_load.cpp and memory_test_load.cpp), the BW changed significantly:
Cache BW testing:
2018-Nov-07: csa_cache_bandwidth_bytes_per_cycle 247.869630
2018-Nov-15: csa_cache_bandwidth_bytes_per_cycle 245.337194
2019-Feb-27: csa_cache_bandwidth_bytes_per_cycle 244.601992
2019-Apr-08: csa_cache_bandwidth_bytes_per_cycle 56.398571
Memory BW testing:
2018-Nov-07: memory_bandwidth_bytes_per_cycle 106.283933
2018-Nov-15: memory_bandwidth_bytes_per_cycle 106.296054
2019-Feb-27: memory_bandwidth_bytes_per_cycle 106.339173
2019-Apr-08: memory_bandwidth_bytes_per_cycle 56.643857
(All other memory/cache BW values (for triad, copy, store-only) stayed the same.)
A snippet of the load/reduction BW source is below if anyone is interested. All test code is in /soft/restricted/intel_csa/apps/testing/source, and output in /soft/restricted/intel_csa/apps/testing/result/2019-Apr-08/.
If you weren't already aware of the issues mentioned above, and you are interested, then let Thomas or me know and we will open a bug report.
Thanks,
Colleen
Code snippet:
For the load/reduction cache BW tests, this was done with 32 workers, size of array was 262144 doubles.
For the load/reduction memory BW tests, the was done with 32 workers, size of array was 1048576 doubles.
#pragma omp parallel for num_threads(NUM_CSA_WORKERS) schedule(static) reduction(+:temp)
for (int j=0; j< ARRAY_SIZE; j++)
temp += b[j];
sum_csa = temp;
P.S. I'm still waiting for some of the longer tests to finish, and if anything different comes out of that, I'll update later.
________________________________
From: anl-intel-lrz-knr <anl-intel-lrz-knr-bounces(a)lists.jlse.anl.gov> on behalf of Glossop, Kent via anl-intel-lrz-knr <anl-intel-lrz-knr(a)lists.jlse.anl.gov>
Sent: Monday, April 8, 2019 12:56 PM
To: Glossop, Kent
Subject: [anl-intel-lrz-knr] SDK release notes
A new preview release of SDK components has been installed, and is now the default on both the co-design server and JLSE.
Please see $CSA_ROOT/doc/CSA-Release-Notes-2019-04-06.txt for details.
This is a significant release, with the compiler default switching to generate binary Virtual ISA, running the late tools, and the simulator now defaulting to more realistic buffering that is very close to the projected hardware.
Kent
