TSV Utilities release with LTO and PGO enabled

Jon Degenhardt jond at noreply.com
Wed Jan 17 04:37:04 UTC 2018


On Tuesday, 16 January 2018 at 22:04:52 UTC, Johan Engelen wrote:
> Because PGO optimizes for the given profile, it would help a 
> lot if you clarified how you do your PGO benchmarking. What 
> kind of test load profile you used for optimization and what 
> test load you use for the time measurement.

The profiling used is checked into the repo and run as part of a 
PGO build, it is available for inspection. The benchmarks used 
for deltas are also documented, they the ones used in the 
benchmark comparison to similar tools done in March 2017. This 
report is in the repo 
(https://github.com/eBay/tsv-utils-dlang/blob/master/docs/Performance.md).

However, it's hard to imagine anyone perusing the repo for this 
stuff, so I'll try to summarize what I did below.

Benchmarks - Six different tests of rather different but common 
operations run on large data files. The six tests were chosen 
because for each I was able to find at least three other tools, 
written in native compiled languages, with similar functionality. 
There are other valuable benchmarks, but I haven't published them.

Profiling - Profiling was developed separately for each tool. For 
each I generated several data files with data representative of 
typical uses cases. Generally numeric or text data in several 
forms and distributions. The data was unrelated to the data used 
in benchmarks, which is from publicly available machine learning 
data sets. However, personal judgement was used in the generation 
of the data sets, so it's not free from bias.

After generating the data, I generated a set of run options 
specific to each tool. As an example, tsv-filter selects data 
file lines based on various numeric and text criteria (e.g. 
less-than). There are a bit over 50 comparison operations, plus a 
few meta operations. The profiling runs ensure all the operations 
are run at least once, but that the most important overweighted. 
The ldc.profile.resetAll call was used to exclude all the initial 
setup code (command line argument processing). This was nice 
because it meant the data files could be small relative to 
real-world sets, and it runs fast enough to do at part of the 
build step (ie. on Travis-CI).

Look at 
https://github.com/eBay/tsv-utils-dlang/tree/master/tsv-filter/profile_data to see a concrete example (tsv-filter). In that directory are five data files and a shell script that runs the commands and collects the data.

This was done for four of the tools covering five of the 
benchmarks. I skipped one of the tools (tsv-join), as it's harder 
to come up with a concise set of profile operations for it.

I then ran the standard benchmarks I usually report on in various 
D venues.

Clearly personal judgment played a role. However, the tools are 
reasonably task focused, and I did take basic steps to ensure the 
benchmark data and tests were separate from the training 
data/tests. For these reasons, my confidence is good that the 
results are reasonable and well founded.

--Jon


More information about the Digitalmars-d-announce mailing list