Closed maawad closed 4 years ago
I can generate avg-process-time
easily but I'd like @neoblizz to chime in simply because this is gonna be confusing for any future person who ever wants to benchmark/compare against our stuff. One option might be moving the stats-compute code out of the enactor (there's no proximate reason why it should be there) and into some sort of standalone postprocess call.
Also, surprising amount of variability in process-times
.
Question is: Do you need the
avg-process-time
field to be correct? or can we use theprocess-times
array? We will be computing average edge insertion/update throughput.
No, we don't need that field to be correct. I think as long as the methodology for our measurements is clearly defined we are fine. Use what you care about.
In the refactored version, the JSON class is separate from the actual statistics you collect (so, a stats class and a JSON class), which means each algorithm, application, or test gets to define what stats it needs to show in its JSON output.
Okay I can do that for now then and avoid modifying that file :)
Also, surprising amount of variability in
process-times
.
Numbers are not exactly correct here. I was inserting edges twice. Will double check after fixing that.
I have a sample of a json file that I output after performing a graph bulk build operation below (I will have similar ones for other graph update operations). Gunrock computes
avg-process-time
in a function that assumes there is a graph problem running (it requires anEnactor
to compute statistics) so I can't really call that but I can do a PR to change it if needed. So the main fields in the output json file that I care about/correct are:load-factor: float
,undirected: bool
,process-times: array of floats
anddataset: string
. There will be an additionalbatch-size: uint
for other update operations as well.Question is: Do you need the
avg-process-time
field to be correct? or can we use theprocess-times
array? We will be computing average edge insertion/update throughput.