On 21/03/2019 13:45, Gilles Sadowski wrote:
Hello.[...]If the user forgets to supply one, the program outputs one, and stops; then the user reissues the command?Yes: > java -jar examples-stress.jar -h Print something helpful > java -jar examples-stress.jar --template Print a template generators list to stdout > java -jar examples-stress.jar --template > list.txt > java -jar examples-stress.jar target/tu_ 4 list.txt BE ./stdin2testu01 BigCrush I've used picocli before. It definitely needs very little extra code due to the use of annotations. One thing I do not know is what happens to the arguments for the stress test program, e.g. /usr/bin/dieharder -a -g 200 -Y 1 -k 2 If they match anything used by the examples-stress.jar program then they will be consumed by a parser. If options match arguments to be passed to the stress test program then the executable program would have to be put into a script. For now we can choose the arguments to not clash. Should be simple given we avoid these: ./stdin2testu01 BigCrush /usr/bin/dieharder -a -g 200 -Y 1 -k 2 So: -h, --help => help --template => print a template I would leave these as mandatory as they are all important to not forget: * output file prefix * int threads * generators list * endianness (an enum of BE or LE) * application * application arguments For picocli that would be: @Parameters(index = "0") File prefix; @Parameters(index = "1") int threadCount; @Parameters(index = "2") File generatorsList; @Parameters(index = "3") Endianness endianness; @Parameters(index = "4") File executable; @Parameters(index = "5..*") String[] executableArguments; So it is very simple. I will make modifications to the updated program to use Picocli.I'd suggest to change the program usage to make it more flexible, i.e. $ java -jar RandomStressTester.jar --prefix prefix --threads 4 --tasks genlist --byteorder BE -- /usr/bin/dieharder -a -g 200 -Y 1 -k 2 Thus, everything tha follows the double-dash is the command-line for the "ProcessBuilder". And there can be default values for * prefix (possibly aborting if the targets already exist) * threads * tasks (a file provided in the JAR (?)) * byteorder ("LE") So, this could work too: $ java -jar RandomStressTester.jar -- /usr/bin/dieharder -a -g 200 -Y 1 -k 2
OK. So we provide defaults for everything. I've just found this snippet to determine the endianness:
|importjava.nio.ByteOrder;if(ByteOrder.nativeOrder().equals(ByteOrder.BIG_ENDIAN)){System.out.println("Big-endian");}else{System.out.println("Little-endian");}|
The JDK will throw an Error if the call to nativeOrder() is not a
recognised form. E.g. a weird mixed/middle-endian platform.
Picocli even supports setting the ByteOrder value using "BIG_ENDIAN" or "LITTLE_ENDIAN".
Why the '--'? Seems mute if using a library to parse the arguments. Without it the bare command line arguments are all used for the test suite.
For reference here are the results of BigCrush with: The correct little-endian byte order: XorShiftXorComposite : 54, 53, 53 : 646.8 +/- 10.9 XorShiftSerialComposite : 40, 39, 39 : 608.2 +/- 3.9 SplitXorComposite : 0, 0, 0 : 625.8 +/- 0.2 The incorrect big-endian byte order: XorShiftXorComposite : 92, 89, 90 : 986.7 +/- 4.3 XorShiftSerialComposite : 75, 74, 76 : 632.0 +/- 2.3 (I did not run the control.) This makes a fair bit of difference as it did for dieharder. So the byte order is important to get correct. I.e. you are not testing the true output of the generator if the bytes are reversed.I wonder whether this is the consequence of correlations. IOW: Would order matter for a good generator?
I don't know. But when the benchmark gets rerun a drop in the number of failures would give evidence that the byte order is important. This may be best observed with the JDK generator as it has a long way to fall.
Regards, GillesAlex--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
