Idea #24375
Look into possible performance improvements due to using byte as the basic Fragment data type
0%
Description
In a recent DUNE Application Framework meeting, it came up that many kernel components and system libraries are optimized to deal with bytes as opposed to long words. We should investigate if there are any performance improvements if the artdaq Fragment RawDataType is a uint8_t instead of a uint64_t.
History
#1 Updated by Eric Flumerfelt 2 months ago
I've made a minimal set of changes to artdaq-core to make Fragment use uint8_t as RawDataType on artdaq-core:feature/24375_RawDataType_ByteTest
#2 Updated by Eric Flumerfelt 2 months ago
I have added branches to artdaq (feature/24375_ByteTest_FixesForArtdaq) and artdaq-utilities-daqinterface (feature/24375_ByteTest_SettingsForByteTest) which have some changes needed for the demo system to work with byte-based Fragments.
#3 Updated by Ron Rechenmacher about 2 months ago
Latest tests seem to show that there is no difference when writing ROOT files:
Baseline:
/home/ron/work/artdaqPrj/demo4-e19-s96 ron@mu2edaq13 :^) for xx in `seq 3`;do date;time taskset -c 20 artdaqDriver -c srcs/artdaq_demo/tools/fcl/test_10Mx30000_root3null.fcl | wc -l;done Tue May 19 12:28:25 CDT 2020 152 real 3m1.645s user 2m58.651s sys 0m1.270s Tue May 19 12:31:27 CDT 2020 159 real 3m7.640s user 3m0.215s sys 0m6.134s Tue May 19 12:34:35 CDT 2020 152 real 3m1.612s user 2m59.160s sys 0m1.446s --2020-05-19_12:37:36--
With byte array (via issue 24375 branches:
/home/ron/work/artdaqPrj/demo1-e19-s96-24375_ByteTest-artdaqDriver-null ron@mu2edaq13 :^) for xx in `seq 3`;do date;time taskset -c 20 artdaqDriver -c srcs/artdaq_demo/tools/fcl/test_10Mx30000_root3null.fcl | wc -l;done Tue May 19 14:09:48 CDT 2020 159 real 3m2.602s user 2m59.784s sys 0m1.210s Tue May 19 14:12:51 CDT 2020 152 real 3m1.703s user 2m59.410s sys 0m1.297s Tue May 19 14:15:52 CDT 2020 159 real 3m1.649s user 2m59.495s sys 0m1.264s --2020-05-19_14:18:54--