On 2015/05/20 12:20:03, Michael Achenbach wrote:
lgtm
https://codereview.chromium.org/1146073002/diff/1/test/simdjs/SimdJs.json
File test/simdjs/SimdJs.json (right):
https://codereview.chromium.org/1146073002/diff/1/test/simdjs/SimdJs.json#newcode27
test/simdjs/SimdJs.json:27: "flags": ["--harmony-object",
"test/simdjs/harness-adapt.js"],
On 2015/05/20 11:30:05, bradn wrote:
> On 2015/05/20 10:33:17, Michael Achenbach wrote:
> > Should this be benchmark-adapt?
>
> Actually this is right, but that file was from an attempt to approach
this
> differently (invoke run.js once and collect everything), that proved
more
> verbose.
ok
https://codereview.chromium.org/1146073002/diff/1/test/simdjs/SimdJs.json#newcode28
test/simdjs/SimdJs.json:28: "path": ["../../"],
On 2015/05/20 11:30:04, bradn wrote:
> On 2015/05/20 10:33:16, Michael Achenbach wrote:
> > Can the workdir not be "." and all paths be relative to it? Or are
there
> > hardcoded loads in the runner relative to the v8 base dir?
>
> This lets me share the harness-adapt/finish with the testing version of
this.
> I could make another one for this case that's rooted here, but would
need
> slightly different versions of those two.
> Which do you prefer
I'm fine if you keep it like that for now. With harness-adapt/finish, do
you
mean the file test/simdjs/harness-finish.js? If yes, couldn't the relative
path
be left out there as well?
It needs to be rooted that way because the test is run from there.
https://codereview.chromium.org/1146073002/diff/1/test/simdjs/SimdJs.json#newcode32
test/simdjs/SimdJs.json:32: "main": "test/simdjs/harness-finish.js",
On 2015/05/20 11:30:04, bradn wrote:
> On 2015/05/20 10:33:17, Michael Achenbach wrote:
> > It will make a new call to d8 for each "main" file. I guess that's
what
you
> > want. The benchmarks will appear in a hierarchy like this:
> > SIMDJS/kernel-template/SIMD
> > SIMDJS/kernel-template/Non-SIMD
> > etc
>
> I assume this is preferrable, as then then run_perf knows about each?
> I had tried it the other way round (run run.js once), but then it seemed
more
> verbose and then run_perf doesn't know about all the sub -tests.
If the behavior of the benchmark is what you want then this is preferred.
There
are some benchmarks that behave differently when one runner is called,
e.g.
the
different line items influence each other and optimizations from one line
item
might survive into the methods of the next.
Even though this sounds bad, we sometimes keep this kind of behavior if
it's
required to be as close as possible to some publicly existing benchmark.
If
the
benchmark is run by other parties in a different way, you might sometimes
not
see the same results as they do.
That's actually an interesting point in light of a lunch conversation.
It might be worth considering long term if this benchmark suite grows.
My impression is that at the moment each tests is othogonal so it won't
matter.
But that could easily change.
https://codereview.chromium.org/1146073002/diff/20001/test/simdjs/generate.py
File test/simdjs/generate.py (right):
https://codereview.chromium.org/1146073002/diff/20001/test/simdjs/generate.py#newcode56
test/simdjs/generate.py:56: fh.write(json.dumps(output,
separators=(',',': '),
indent=2))
Maybe add sort_keys=True to be deterministic...
https://codereview.chromium.org/1146073002/
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
