Enhancement: Make p4c-bm2-ss's bmv2 JSON config file output consistent across runs

[jafingerhut]

Maybe it is something strange in my environment (and if so I would like to change it), but when I run p4c-bm2-ss repeatedly on the same P4-16 program, I get bmv2 JSON config file output that varies, usually in the id's assigned to things, and thus often the order they occur in that file.

This is not incorrect, I understand. That is why this issue title starts with "Enhancement", not "Bug".

However, it seems like it should be straightforward to change this to a consistent order across runs, at least for the same version of the compiler source code and the same P4-16 source program.

Why am I asking? Because sometimes it is useful to 'diff' two bmv2 JSON config files after making a small compiler change, and this would be far more useful and quick if the order of objects in that file was more consistent.

[jafingerhut]

At least with Python's default implementation, I know that dict's use a hash function with some kind of randomization in it. This can be disabled with a command line option, or you can write code to sort the keys whenever printing the contents of a dict. I wonder whether something like that is happening here, too.

[ChrisDodd]

We generally go out of our way in the compiler code to use `ordered_map` and `ordered_set` (instead of `std::map` and `std::set`) for precisely this reason (the `ordered` versions preserve/remember the order of insertion and always iterate over that order rather than in a random order.)

…

On Thu, May 25, 2017 at 10:41 AM, Andy Fingerhut ***@***.***> wrote: At least with Python's default implementation, I know that dict's use a hash function with some kind of randomization in it. This can be disabled with a command line option, or you can write code to sort the keys whenever printing the contents of a dict. I wonder whether something like that is happening here, too. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#667 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AD4c8ULOpBL-5OiIeMUh5m5QHtZs8voxks5r9b1TgaJpZM4Nmqn_> .

[jafingerhut]

@ChrisDodd Do you see different bmv2 JSON file for any medium-sized P4-16 program across multiple runs? I can put an example program and commands I used here with my results if others do not see this behavior.

[jafingerhut]

Example command:

p4c-bm2-ss issue298-bmv2.p4 -o tmp1.json

where the program is this one: https://github.com/p4lang/p4c/blob/master/testdata/p4_16_samples/issue298-bmv2.p4

I run that 5 times with 5 different JSON output file names. 3 of the files are the same. I get 3 different unique output files out of those 5.

It happens less often with smaller programs, so is probably related to the number of some kind of language construct in the programs.

[mihaibudiu]

@hanw : can we assign you this issue, since you seem to have taken ownership of the bmv2 back-end?
As @ChrisDodd says, it is most likely this can be fixed by replacing a set or map with the ordered equivalent. This is only important when you iterate over the object.

[hanw]

Yes. Please assign the issue to me.

[sethfowler]

See #406.

[mihaibudiu]

Yes, but in this case it may be that this is a set of JSON objects.

[hanw]

Fixed with #669

[sethfowler]

It turns out that the patch in #406 would indeed have caught this.

[jafingerhut]

@hanw Thanks! I've tried out your change on several different programs, and it appears to have nailed it.