Sorry for the delayed response. I also get scores in the same range with
the script, as written, and I didn't see any significant difference due
to the patch. However, when I increase the number of iterations to 10000
though, I see a 4.46% gain.
A problem with Browsermark in general is that each test doesn't really
run long enough to take advantage of Crankshaft; you tend to see the
penalty of the compiler kicking in, but you don't actually spend much
time in optimized code. That may be what we're seeing here. When I
profiled this, I saw about twice as many ticks in Crankshaft code as in
the compiler in the 2000 iteration test.
There's also a difference between the shell and browser results here:
several other library functions get compiled during the test. I see
IsPrimitive, NonNumberToNumber, valueOf, etc. In the browser, I think
these would be optimized ahead of time by earlier tests, so there would
be less compiler overhead and more measurable difference.
On 10/02/2012 09:36 AM, Ulan Degenbaev wrote:
Hi Jay,
I attached a runnable version of the benchmark. Does it compute the
score correctly? If yes, could you please tell me what scores do you get?
My scores are in range 11170-11299 for V8 TOT, the second version of
this CL, and my new CL.
Cheers,
Ulan.
On Mon, Oct 1, 2012 at 10:01 PM, Jay Conrod <[email protected]
<mailto:[email protected]>> wrote:
LGTM. I refactored the original patch, but I think your new CL
came out cleaner.
I've attached stringSHA1.txt (rename to .js; our e-mail system
rejects .js files). We have a shell-based driver script, but it
would take a while to get through legal review, and it's probably
faster if you write your own. Call the "run" method in a loop
which terminates in 2000 iterations or 2000 ms, whichever comes
first. The score is iterations per second.
On 10/01/2012 11:10 AM, [email protected]
<mailto:[email protected]> wrote:
Hi Jay,
While waiting for the new revision of this patch set, I started
prototyping
implementation of ROR for ia32 and x64 architectures, so that
we can
get rid of
the ARM specific #ifdef in hydrogen.cc.
You can review the CL at
https://chromiumcodereview.appspot.com/11033005/
Once you upload new patch set, we can combine both CLs to get
something in
landable state.
I also added some tests and moved detection of the ROR pattern
to the
visitor of
the bitwise OR. This seems cleaner to me than adding a new
hydrogen
phase just
to detect one specific pattern, WDYT?
Please note that I checked the generated code but didn't check
performance on
StringSHA1 yet. How can I do this?
https://chromiumcodereview.appspot.com/10984057/
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
