Add back ascii fast path for toupper/tolower

Add back ascii fast path for toupper/tolower

R=yangguo@chromium.org
BUG=

Committed: https://code.google.com/p/v8/source/detail?r=13376

[Yang, 2013-01-14 15:56:51]

LGTM, but I got one comment.

https://codereview.chromium.org/11889007/diff/1/src/runtime.cc
File src/runtime.cc (right):

https://codereview.chromium.org/11889007/diff/1/src/runtime.cc#newcode5910
src/runtime.cc:5910: if ((or_acc & kAsciiMask) != 0) {
Would it be noticeably more expensive to do this check for every word instead of
accumulating the words (bitwise-and, compare and jump as opposed to bitwise-or)?
The tradeoff is that we can terminate early for the non-ascii case.

https://codereview.chromium.org/11889007/diff/1/src/runtime.cc#newcode6001
src/runtime.cc:6001: if (is_ascii) {
It looks like we could save time if Convert failed early if the result is not
ascii.

[Yang, 2013-01-14 16:47:07]

On 2013/01/14 15:56:51, Yang wrote:
> LGTM, but I got one comment.
> 
> https://codereview.chromium.org/11889007/diff/1/src/runtime.cc
> File src/runtime.cc (right):
> 
> https://codereview.chromium.org/11889007/diff/1/src/runtime.cc#newcode5910
> src/runtime.cc:5910: if ((or_acc & kAsciiMask) != 0) {
> Would it be noticeably more expensive to do this check for every word instead
of
> accumulating the words (bitwise-and, compare and jump as opposed to
bitwise-or)?
> The tradeoff is that we can terminate early for the non-ascii case.
> 
> https://codereview.chromium.org/11889007/diff/1/src/runtime.cc#newcode6001
> src/runtime.cc:6001: if (is_ascii) {
> It looks like we could save time if Convert failed early if the result is not
> ascii.

I wrote a micro-benchmark for demonstration:

var a = "a";
for (var i = 0; i < 14; i++) a += a;

function test(str) {
  var start = new Date();
  for (var i = 0; i < 10000; i++) str.toUpperCase();
  var mid = new Date();
  for (var i = 0; i < 10000; i++) str.toLowerCase();
  var end = new Date();
  print("toUpper: " + (mid - start) + "\t toLower: " + (end - start));
}

test(a + "ö");
test(a + "ö" + a);
test("ö" + a);

Without ENABLE_LATIN_1, we get (on ia32)
toUpper: 629     toLower: 690
toUpper: 1256    toLower: 1379
toUpper: 629     toLower: 691

With ENABLE_LATIN1, we get
toUpper: 679     toLower: 796
toUpper: 1350    toLower: 1586
toUpper: 677     toLower: 795

With ENABLE_LATIN1 and early fail (such as "if ((w & kAsciiMask) != 0) return
toUpper: 657     toLower: 793
toUpper: 1250    toLower: 1536
toUpper: 597     toLower: 743

It seems like testing each word for the ascii mask and failing early is not more
expensive than accumulating and checking late. The same can be observed on x64,
but the difference is somewhat smaller.

Unfortunately, a Nexus S (ARM) suffers visibly from early fail:
no early fail:
toUpper: 7438    toLower: 7279
toUpper: 14809   toLower: 14472
toUpper: 7422    toLower: 7269

early fail:
toUpper: 9380    toLower: 9392
toUpper: 15240   toLower: 15149
toUpper: 6228    toLower: 6058


Interestingly - on Intel architectures (my workstation) - if the input string is
all lower case, toUpper is visibly faster than toLower. If the input string is
all upper case, I observe the exact opposite. Apparently it's faster to use the
changed string. The opposite is the case on the Nexus S.

[drcarney, 2013-01-15 08:02:38]

I modelled this after the webkit version of the same functions.  I think leaving
this is okay for now, but I don't care either way.  Everywhere
V8_HOST_CAN_READ_UNALIGNED appears we potentially have big performance
differences on arm. Maybe we should get rid of this difference first.

[Yang, 2013-01-15 09:22:22]

On 2013/01/15 08:02:38, dcarney wrote:
> I modelled this after the webkit version of the same functions.  I think
leaving
> this is okay for now, but I don't care either way.  Everywhere
> V8_HOST_CAN_READ_UNALIGNED appears we potentially have big performance
> differences on arm. Maybe we should get rid of this difference first.

Landed.