use pipe instead of cin and c++ version detection fix

[JRPan]

Because the std::cin is unique, when printing out the trace to cin, the cin must be drained first before the next kernel is printed to the cin
i.e.
cin is serialized.

Currently, the trace parser first parses the first several lines, looking for kernel info. Then, the rest of the traces are loaded TB by TB (get_next_threadblock_traces).

This works fine when only 1 kernel is running. The cin looks like:

kernel_1 name
kernel_1 id
.... <-----------------------------break here after parsing kernel info
#TB1 traces <----------------------`get_next_threadblock_traces` continues here
...
#TB2 traces
...more

But when there is 2+ kernels, for example, multi-stream concurrent, the kernel 2 info is after the kernel 1 traces in the cin buffer. The parser cannot parse kernel 2 info before kernel1 traces are drained. But kernel 2 must be able to be parsed at any time.

To fix this, we removed cin, fstream, and load from pipe directly. Each kernel has it's own pipe.

Also, Ubuntu 22.04 comes with C++ version 11, the old version detection only looks for 1 digit. This is addressed as well.

[JRPan]

I have no idea why the CI is failing. It runs perfectly fine on the raid.

57690     	tgrogers-bigram-01            	backprop-rodinia-2.0	4096___data_result_4	accelsim-commit-d595	QV100-SASS	UNKNOWN        	UNKNOWN	COMPLETE_NO_OTHER_INFO        	SIMRATE_IPS=282 K	SIM_TIME=33 sec (33 sec)	TOT_IPC=626	TOT_INSN=9 M	TOT_CYCLE=15 K	
57691     	tgrogers-bigram-01            	bfs-rodinia-2.0-ft  	__data_graph4096_txt	accelsim-commit-d595	QV100-SASS	UNKNOWN        	UNKNOWN	COMPLETE_NO_OTHER_INFO        	SIMRATE_IPS=22 K	SIM_TIME=54 sec (54 sec)	TOT_IPC=10	TOT_INSN=1 M	TOT_CYCLE=122 K	
57692     	tgrogers-bigram-01            	hotspot-rodinia-2.0-	30_6_40___data_resul	accelsim-commit-d595	QV100-SASS	UNKNOWN        	UNKNOWN	COMPLETE_NO_OTHER_INFO        	SIMRATE_IPS=607 K	SIM_TIME=51 sec (51 sec)	TOT_IPC=569	TOT_INSN=31 M	TOT_CYCLE=54 K	
57693     	tgrogers-bigram-01            	heartwall-rodinia-2.	__data_test_avi_1___	accelsim-commit-d595	QV100-SASS	UNKNOWN        	UNKNOWN	COMPLETE_NO_OTHER_INFO        	SIMRATE_IPS=428 K	SIM_TIME=16 sec (16 sec)	TOT_IPC=734	TOT_INSN=7 M	TOT_CYCLE=9 K	
57694     	tgrogers-bigram-01            	lud-rodinia-2.0-ft  	_v__b__i___data_64_d	accelsim-commit-d595	QV100-SASS	UNKNOWN        	UNKNOWN	COMPLETE_NO_OTHER_INFO        	SIMRATE_IPS=7 K	SIM_TIME=1 min, 17 sec (77 sec)	TOT_IPC=3	TOT_INSN=554 K	TOT_CYCLE=169 K	
57695     	tgrogers-bigram-01            	nw-rodinia-2.0-ft   	128_10___data_result	accelsim-commit-d595	QV100-SASS	UNKNOWN        	UNKNOWN	COMPLETE_NO_OTHER_INFO        	SIMRATE_IPS=8 K	SIM_TIME=1 min, 10 sec (70 sec)	TOT_IPC=4	TOT_INSN=572 K	TOT_CYCLE=138 K	
57696     	tgrogers-bigram-01            	nn-rodinia-2.0-ft   	__data_filelist_4_3_	accelsim-commit-d595	QV100-SASS	UNKNOWN        	UNKNOWN	COMPLETE_NO_OTHER_INFO        	SIMRATE_IPS=131 K	SIM_TIME=50 sec (50 sec)	TOT_IPC=225	TOT_INSN=7 M	TOT_CYCLE=29 K	
57697     	tgrogers-bigram-01            	pathfinder-rodinia-2	1000_20_5___data_res	accelsim-commit-d595	QV100-SASS	UNKNOWN        	UNKNOWN	COMPLETE_NO_OTHER_INFO        	SIMRATE_IPS=56 K	SIM_TIME=16 sec (16 sec)	TOT_IPC=29	TOT_INSN=888 K	TOT_CYCLE=31 K	
57698     	tgrogers-bigram-01            	srad_v2-rodinia-2.0-	__data_matrix128x128	accelsim-commit-d595	QV100-SASS	UNKNOWN        	UNKNOWN	COMPLETE_NO_OTHER_INFO        	SIMRATE_IPS=255 K	SIM_TIME=37 sec (37 sec)	TOT_IPC=317	TOT_INSN=9 M	TOT_CYCLE=30 K	
57699     	tgrogers-bigram-01            	streamcluster-rodini	3_6_16_1024_1024_100	accelsim-commit-d595	QV100-SASS	UNKNOWN        	UNKNOWN	COMPLETE_NO_OTHER_INFO        	SIMRATE_IPS=52 K	SIM_TIME=5 min, 51 sec (351 sec)	TOT_IPC=16	TOT_INSN=18 M	TOT_CYCLE=1 M

[JRPan]

I tested compressed .xz as well.

[FJShen]

According to Linux man page for free(3p), no action happens if the argument is a null pointer... Nice job exploiting that characteristic.

[JRPan]

power of chatgpt. Most of this is written by ChatGPT. lol

[FJShen]

Please take a look at my comments, mainly regarding the constructor of class PipeReader. Thanks!

[FJShen]

looks good to me

[FJShen]

I just realized, after adding this PipeReader class we should probably take extra care when copying/moving the PipeReader or kernel_trace_t objects. The code in its current form has no guardrails that prevent somebody from copying a PipeReader and thus duplicating the pipe handle. I can open an issue and work on a PR if necessary.