Age | Commit message (Collapse) | Author | Files | Lines |
|
* Add Word2Vec Benchmark Harness
This change adds an additional scenario benchmark, the Word2Vec
benchmark. The harness pulls down Word2Vec.Net from eabdullin, applies a
patch of changes that we made to work with netcoreapp21, harness the
word training and search, and then runs the benchmark. It also updates
the timeout for running benchmarks, since the training scenario on a
100M file takes about 7 minutes locally.
|
|
- Add result validation
- Add [Benchmark] attributes and appropriate iteration counts
- Minor edits here and there to target .NET Standard 1.4
- Exception: pi-digits rewritten to use managed BitInteger instead of
p/invoke out to GMP.
|
|
For each benchmark, grab the current best C# .NET entry, and also grab
the current best serial implementation (since these are easier to work
with from the benchmarking perspective).
|
|
Changed .gitattributes to set line endings to windows ones for the input
files of this test.
Added two different tests, one with and the other without parallelism.
Used FileStream instead of BufferedStream, since the latter does not
exist in netstandard 1.4
|
|
Based on the "version 6" test base. As with revcomp, keeping the input
files as unix line ending, and relatively small.
|
|
This is based on version 1 of the C# variants. Am not including
the largest input file since it is ~250MB. Instead we iterate
on a smaller file.
Note the text input files are opened as binary and the app looks for
Unix line endings, hence the update to .gitattributes.
The benchmark is setup to look for its input next to the benchmark exe
as run in both normal test and xunit-perf test modes, keying off the
CORE_ROOT environment variable. In the xunit-perf mode the input files
are subsequently copied into the sandbox.
Also updated the ending copyright date on the Benchmark Games
license page.
|
|
A common workflow for some folks on our team is to check out the Git
repository, then share that folder out over to Linux. In this case,
we need the pal test files to have Unix line endings, even in the case
where core.autocrlf = true, which is the case on Windows.
My hunch is that we would also need this even if we didn't do this,
since otherwise changes to this file will be mirrored back to TFS with
DOS line endings, which would break building the TFS version when
checked out, so it's likely a good idea to do this anyway, even if the
leading factor is a somewhat odd workflow.
|
|
[tfs-changeset: 1407945]
|