Hi all,
I would like to report the following two findings in regard to ARM SVE +
Ruby + FS/SE:
A) When trying to run C STREAM benchmark v5.10
(https://www.cs.virginia.edu/stream/FTP/Code/stream.c), compiled for ARM
SVE,
I get the following assert error:
*gem5.opt: build/ARM/mem/packet.hh:1093: T* Packet::getPtr() [with T =
unsigned char]: Assertion `!isMaskedWrite()' failed.*
I have tried with both gcc/armclang:
a) aarch64-linux-gnu-gcc (GNU Toolchain for the A-profile Architecture
8.2-2019.01 (arm-rel-8.28)) 8.2.1 20180802
e.g.: aarch64-linux-gnu-gcc -Ofast --static
*-march=armv8.2-a+sve*-DNTIMES=5 -DSTREAM_ARRAY_SIZE=200000
-I../gem5/include/ -I../gem5/include/gem5 stream.c -L./ -o
sve_stream.exe -lm5
b) armclang (arm-hpc-compiler/19.3)
Stream runs OK, in the following 3 cases:
a) build without SVE flags
b) When I comment out the assert(But this could lead to errors ?)
c) Without Ruby/NoC (But we are currently interested in Ruby-NoC Systems).
The complete output is the following:
command line: ./build/ARM/gem5.opt --outdir=m5out/batch502_0001
configs/example/se.py --cpu-type=DerivO3CPU --caches --num-cpus=4
--num-dirs=4 --l2cache --mem-type=DDR4_2400_8x8 --num-l2caches=4
--mem-size=2GB --ruby --topology=Mesh_XY --mesh-rows=2
--network=garnet2.0 -c sve_stream.exe
Global frequency set at 1000000000000 ticks per second
warn: DRAM device capacity (16384 Mbytes) does not match the address
range assigned (512 Mbytes)
warn: DRAM device capacity (16384 Mbytes) does not match the address
range assigned (512 Mbytes)
warn: DRAM device capacity (16384 Mbytes) does not match the address
range assigned (512 Mbytes)
warn: DRAM device capacity (16384 Mbytes) does not match the address
range assigned (512 Mbytes)
0: system.remote_gdb: listening for remote gdb on port 7004
0: system.remote_gdb: listening for remote gdb on port 7005
0: system.remote_gdb: listening for remote gdb on port 7006
0: system.remote_gdb: listening for remote gdb on port 7007
**** REAL SIMULATION ****
info: Entering event queue @ 0. Starting simulation...
warn: Replacement policy updates recently became the responsibility of
SLICC state machines. Make sure to setMRU() near callbacks in .sm files!
info: Increasing stack size by one page.
gem5.opt: build/ARM/mem/packet.hh:1093: T* Packet::getPtr() [with T =
unsigned char]: Assertion `!isMaskedWrite()' failed.
Program aborted at tick 24589000
--- BEGIN LIBC BACKTRACE ---
./build/ARM/gem5.opt(_Z15print_backtracev+0x19)[0x55976cece499]
./build/ARM/gem5.opt(_Z12abortHandleri+0x3d)[0x55976cee013d]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x12730)[0x7f12b2d18730]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x10b)[0x7f12b1b0a7bb]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x121)[0x7f12b1af5535]
/lib/x86_64-linux-gnu/libc.so.6(+0x2240f)[0x7f12b1af540f]
/lib/x86_64-linux-gnu/libc.so.6(+0x30102)[0x7f12b1b03102]
./build/ARM/gem5.opt(_ZN9Sequencer12issueRequestEP6Packet15RubyRequestType+0x5e9)[0x55976c2c2119]
./build/ARM/gem5.opt(_ZN9Sequencer11makeRequestEP6Packet+0x203)[0x55976c2c2513]
./build/ARM/gem5.opt(_ZN8RubyPort12MemSlavePort13recvTimingReqEP6Packet+0x37f)[0x55976c2b299f]
./build/ARM/gem5.opt(_ZN7LSQUnitI9O3CPUImplE13trySendPacketEbP6Packet+0xd8)[0x55976d3e0c58]
./build/ARM/gem5.opt(_ZN3LSQI9O3CPUImplE16SplitDataRequest17sendPacketToCacheEv+0x6c)[0x55976d3d7f3c]
./build/ARM/gem5.opt(_ZN7LSQUnitI9O3CPUImplE15writebackStoresEv+0x862)[0x55976d3e7992]
./build/ARM/gem5.opt(_ZN3LSQI9O3CPUImplE15writebackStoresEv+0x84)[0x55976d3de564]
./build/ARM/gem5.opt(_ZN10DefaultIEWI9O3CPUImplE4tickEv+0x144)[0x55976d3ca994]
./build/ARM/gem5.opt(_ZN9FullO3CPUI9O3CPUImplE4tickEv+0x137)[0x55976d39f0b7]
./build/ARM/gem5.opt(_ZN10EventQueue10serviceOneEv+0xd9)[0x55976ced62e9]
./build/ARM/gem5.opt(_Z9doSimLoopP10EventQueue+0x77)[0x55976cef6157]
./build/ARM/gem5.opt(_Z8simulatem+0xccd)[0x55976cef718d]
./build/ARM/gem5.opt(+0x1e399ca)[0x55976cfdd9ca]
./build/ARM/gem5.opt(+0xcbd5f1)[0x55976be615f1]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x60f2)[0x7f12b2e720a2]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x732)[0x7f12b2e6b852]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x62e9)[0x7f12b2e72299]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x732)[0x7f12b2e6b852]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x62e9)[0x7f12b2e72299]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x732)[0x7f12b2e6b852]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x62e9)[0x7f12b2e72299]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x732)[0x7f12b2e6b852]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCode+0x19)[0x7f12b2e6be69]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x6992)[0x7f12b2e72942]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x732)[0x7f12b2e6b852]
--- END LIBC BACKTRACE ---
Aborted (core dumped)
B) Additionally, when I disable the previous assert and run:
FS with multi-threaded SVE-Stream + OpenMP + DerivO3CPU + 2x2 Mesh +
garnet2.0 + MOESI_hammer/MOESI_CMP_directory + (4 cpu / 4 dirs / 4
L2-caches),
I observe:
a) Atomicity (+ OpenMP ) seems problematic?
The following code (from stream.c) prints garbage values:
/ pragma omp atomic//
// k++;//
// printf ("Number of Threads counted = %i\n",k);/
b) STREAM Benchmark finishes, but results contain errors,
when*OMP_NUM_THREADS > 1*.
I guess (a) could explain (b). The results get verified for some array
sizes (e.g.: 200,000), for 1/2/4 threads.
When running multi-threaded***OpenMP**STREAM without SVE*, all results
get verified (e.g.: array sizes = [43690, 252134, 243431, 151690,
200000] for 1/2/4 threads), although problem (a) persists.
STREAM + SVE (+ OpenMP) finish with errors, even with Classic Memory
System (without Ruby). I could do more runs to verify this, if needed.
I would like to ask about the current status of atomicity in Ruby, as
well as atomicity in regard to SVE.
( I have seen the relative status matrix in
http://www.gem5.org/Status_Matrix, but maybe it is outdated? )
Any information or help to resolve these issues is welcome.
Thanks in advance,
Polydoros Petrakis
-------
Institute of Computer Science (ICS),
Foundation for Research & Technology - Hellas (FORTH),
Heraklion, Crete, Greece.
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
