Simplify utf8.c

[am11]

diet version 🤸

[am11]

cc @AaronRobinsonMSFT, re: #100451 (comment) - this mainly reduces the assembly code with cl.exe -O2 (before 1091 lines, now 369 for minipal_convert_utf8_to_utf16). Could you please run your benchmark to see how it compares against the MultiByteToWideChar/WideCharToMultiChar win32 APIs? Hopefully it will perform better now (at least better than before 😅).

[am11]

@lambdageek, just an FYI, I had to change this condition from

if (sourceIndex < sourceLength && (destinationIndex >= destinationLength)

for mono because this case was failing:

runtime/src/libraries/System.Runtime/tests/System.Runtime.Tests/System/AttributeTests.cs

Line 169 in 2bfd1b4

Assert.NotNull(stringArg);

IMHO, the reflection stack of mono should use the same expectation from giconv about the expected lengths as coreclr's reflection stack makes from coreclr PAL's unicode.cpp, so this standalone component doesn't need to handle more edge cases than necessary.

[AaronRobinsonMSFT]

/cc @fanyang-mono

[fanyang-mono]

The test that @am11 mentioned was testing the custom attribute value string "\uDFFF". For mono, it went through minipal_convert_utf8_to_utf16 to decode this string "\xed\xbf\xbf". It seems to me that CoreCLR went through a different mechanism to get the value of the custom attribute value.

Additionally, what Mono is doing in g_utf8_to_utf16_impl of giconv.c isn't a lot different than what is done in MultiByteToWideChar of unicode.cpp. If I understand correctly, the only difference is that in MultiByteToWideChar, it makes source length and destination length one byte longer than it is. Doing this in mono won't stop this check ((sourceIndex < sourceLength) && (destinationIndex >= destinationLength)) either.

[am11]

@fanyang-mono, coreclr ultimately uses the same implementation (couple of wrappers later), but in reflection stack (metasig.h etc.), there it compensates for those off-by-one, zero-length kind of scenarios to match the expectation.

[fanyang-mono]

@am11 Do you mind pointing me to the CoreCLR source code where they handles off-by-one, zero-length kind of scenarios?

[am11]

@fanyang-mono, good question. 😅 It is a bit tricky to discern the exact place without actually attaching a conditional debugger (or some tricky way), but I was debugging the similar tests for coreclr last year #85558 (comment) which points to

runtime/src/coreclr/md/compiler/regmeta_import.cpp

Line 705 in d8c59a4

RegMeta::GetTypeDefProps(

One thing I do remember; when all PAL tests were passing and 99% of managed tests were passingm those edge cases covered in reflection tests were still failing, which is why I had to add a similar special condition in unicode.cpp -> utf8.c conversion to balance varied expectations of mono and coreclr + reflection simultaneously.

[fanyang-mono]

It is probably fine having this a little bit longer check, because to make mono align with CoreCLR on this is non-trivial work.

[AaronRobinsonMSFT]

Thanks. I will take a look.

[jkotas]

Could you please run your benchmark to see how it compares against the MultiByteToWideChar/WideCharToMultiChar win32 APIs?

int main()
{
char* p = (char*)malloc(200);
memset(p, 'a', 200);
for (;;)
{
int start = GetTickCount();
for (int i = 0; i < 10000000; i++)
#if 0
minipal_get_length_utf8_to_utf16(p, 200, 0);
#else
MultiByteToWideChar(CP_UTF8, 0, p, 200, NULL, 0);
#endif
int end = GetTickCount();
printf("%d\n", end - start);
}
}

MultiByteToWideChar: 220ms per iteration
minipal_get_length_utf8_to_utf16: 1370ms per iteration

[am11]

Ran some google benchmarks: https://gist.github.com/am11/8d949f6c112aaab1575e85f2f350c59e

Long length: 140
Short length: 20

main:

-------------------------------------------------------------------------------------------------------------
Benchmark Time CPU Iterations UserCounters...
-------------------------------------------------------------------------------------------------------------
BM_minipal_get_length_utf16_to_utf8/ASCII_Short 46.8 ns 46.3 ns 15200142 items_per_second=388.583M/s
BM_minipal_get_length_utf16_to_utf8/NonASCII_Short 49.2 ns 48.4 ns 14081759 items_per_second=288.974M/s
BM_minipal_get_length_utf16_to_utf8/ASCII_Long 48.5 ns 47.9 ns 14615732 items_per_second=2.92203G/s
BM_minipal_get_length_utf16_to_utf8/NonASCII_Long 167 ns 164 ns 4267226 items_per_second=854.207M/s
BM_minipal_convert_utf16_to_utf8/ASCII_Short 66.7 ns 65.7 ns 10535346 items_per_second=273.86M/s
BM_minipal_convert_utf16_to_utf8/NonASCII_Short 98.3 ns 97.0 ns 7215230 items_per_second=144.395M/s
BM_minipal_convert_utf16_to_utf8/ASCII_Long 135 ns 133 ns 5226338 items_per_second=1.05422G/s
BM_minipal_convert_utf16_to_utf8/NonASCII_Long 565 ns 556 ns 1261443 items_per_second=251.616M/s
BM_minipal_get_length_utf8_to_utf16/ASCII_Short 46.5 ns 45.7 ns 15311624 items_per_second=393.657M/s
BM_minipal_get_length_utf8_to_utf16/NonASCII_Short 56.6 ns 55.8 ns 12379302 items_per_second=573.563M/s
BM_minipal_get_length_utf8_to_utf16/ASCII_Long 47.7 ns 47.2 ns 15069416 items_per_second=2.96665G/s
BM_minipal_get_length_utf8_to_utf16/NonASCII_Long 118 ns 116 ns 5989100 items_per_second=1.20323G/s
BM_minipal_convert_utf8_to_utf16/ASCII_Short 61.5 ns 60.9 ns 11373792 items_per_second=295.365M/s
BM_minipal_convert_utf8_to_utf16/NonASCII_Short 126 ns 124 ns 5599462 items_per_second=257.461M/s
BM_minipal_convert_utf8_to_utf16/ASCII_Long 109 ns 108 ns 6452981 items_per_second=1.30072G/s
BM_minipal_convert_utf8_to_utf16/NonASCII_Long 260 ns 258 ns 2722687 items_per_second=542.822M/s

PR:

-------------------------------------------------------------------------------------------------------------
Benchmark Time CPU Iterations UserCounters...
-------------------------------------------------------------------------------------------------------------
BM_minipal_get_length_utf16_to_utf8/ASCII_Short 46.3 ns 46.2 ns 15294729 items_per_second=389.687M/s
BM_minipal_get_length_utf16_to_utf8/NonASCII_Short 46.7 ns 46.7 ns 15014757 items_per_second=300.068M/s
BM_minipal_get_length_utf16_to_utf8/ASCII_Long 89.1 ns 88.2 ns 7965951 items_per_second=1.58799G/s
BM_minipal_get_length_utf16_to_utf8/NonASCII_Long 167 ns 167 ns 4209817 items_per_second=840.11M/s
BM_minipal_convert_utf16_to_utf8/ASCII_Short 57.9 ns 57.8 ns 12086261 items_per_second=311.416M/s
BM_minipal_convert_utf16_to_utf8/NonASCII_Short 80.0 ns 79.9 ns 8745736 items_per_second=175.196M/s
BM_minipal_convert_utf16_to_utf8/ASCII_Long 155 ns 154 ns 4546517 items_per_second=907.604M/s
BM_minipal_convert_utf16_to_utf8/NonASCII_Long 489 ns 488 ns 1427791 items_per_second=286.914M/s
BM_minipal_get_length_utf8_to_utf16/ASCII_Short 47.9 ns 47.1 ns 14990417 items_per_second=382.482M/s
BM_minipal_get_length_utf8_to_utf16/NonASCII_Short 65.7 ns 65.6 ns 10645254 items_per_second=487.782M/s
BM_minipal_get_length_utf8_to_utf16/ASCII_Long 131 ns 130 ns 5443066 items_per_second=1.07377G/s
BM_minipal_get_length_utf8_to_utf16/NonASCII_Long 180 ns 179 ns 3938780 items_per_second=781.547M/s
BM_minipal_convert_utf8_to_utf16/ASCII_Short 73.2 ns 72.9 ns 9594561 items_per_second=246.863M/s
BM_minipal_convert_utf8_to_utf16/NonASCII_Short 109 ns 108 ns 6488872 items_per_second=296.073M/s
BM_minipal_convert_utf8_to_utf16/ASCII_Long 282 ns 281 ns 2457149 items_per_second=497.751M/s
BM_minipal_convert_utf8_to_utf16/NonASCII_Long 298 ns 296 ns 2353052 items_per_second=472.879M/s

BM_minipal_get_length_utf16_to_utf8/ASCII_Long has gotten the worse performance regression. I tried fast tracking ASCII with:

// Use vectorized operations for ASCII characterstypedefuint16_tv4ui __attribute__ ((vector_size (8)));
for (; sourceIndex<sourceLength&&destinationIndex<destinationLength; sourceIndex+=4, destinationIndex+=4)
{
v4uidata=*(v4ui*)&source[sourceIndex];
v4uimask4= (v4ui){0x007F, 0x007F, 0x007F, 0x007F};
v4uicomparison=data <= mask4;
size_tremainingLength=sourceLength-sourceIndex;
if (remainingLength>4&&__builtin_expect(comparison[0] &comparison[1] &comparison[2] &comparison[3], 1))
{
destination[destinationIndex] = (char)data[0];
destination[destinationIndex+1] = (char)data[1];
destination[destinationIndex+2] = (char)data[2];
destination[destinationIndex+3] = (char)data[3];
continue;
}
elseif (remainingLength <= 4)
{
// Handle the remaining 4 or less elements if ASCIIif (remainingLength==4) {
if (__builtin_expect(comparison[0] &comparison[1] &comparison[2] &comparison[3], 1))
{
destination[destinationIndex++] = (char)data[0];
destination[destinationIndex++] = (char)data[1];
destination[destinationIndex++] = (char)data[2];
destination[destinationIndex++] = (char)data[3];
returndestinationIndex;
}
break;
}
v4uimask3= (v4ui){0x007F, 0x007F, 0x007F};
v4uimask2= (v4ui){0x007F, 0x007F};
comparison=data <= mask3;
if (remainingLength==3) {
if( __builtin_expect(comparison[0] &comparison[1] &comparison[2], 1)) {
destination[destinationIndex++] = (char)data[0];
destination[destinationIndex++] = (char)data[1];
destination[destinationIndex++] = (char)data[2];
returndestinationIndex;
}
break;
}
comparison=data <= mask2;
if (remainingLength==2) {
if(__builtin_expect(comparison[0] &comparison[1], 1)) {
destination[destinationIndex++] = (char)data[0];
destination[destinationIndex++] = (char)data[1];
returndestinationIndex;
}
break;
}
if (source[sourceIndex] <0x80){
destination[destinationIndex++] = (char)source[sourceIndex];
returndestinationIndex;
}
}
// Break out of the outer loop here because we know it's non-ASCIIbreak;
}
// Handle non-ASCII and mixed caseswhile (sourceIndex<sourceLength&&destinationIndex<destinationLength)
{
...

but that did not move the needle (+/- 2ns diff).

Haven't given up on fine-tuning yet, but overall I think the new implementation is simple and more readable. So it's a balancing question of readability vs. performance (I'm pursuing both 🙂).

[AaronRobinsonMSFT]

@am11 I'm moving this to draft for now.

[dotnet-policy-service]

Draft Pull Request was automatically closed for 30 days of inactivity. Please let us know if you'd like to reopen it.

[am11]

diet version 🤸

[am11]

cc @AaronRobinsonMSFT, re: #100451 (comment) - this mainly reduces the assembly code with cl.exe -O2 (before 1091 lines, now 369 for minipal_convert_utf8_to_utf16). Could you please run your benchmark to see how it compares against the MultiByteToWideChar/WideCharToMultiChar win32 APIs? Hopefully it will perform better now (at least better than before 😅).

[am11]

@lambdageek, just an FYI, I had to change this condition from

if (sourceIndex < sourceLength && (destinationIndex >= destinationLength)

for mono because this case was failing:

runtime/src/libraries/System.Runtime/tests/System.Runtime.Tests/System/AttributeTests.cs

Line 169 in 2bfd1b4

Assert.NotNull(stringArg);

IMHO, the reflection stack of mono should use the same expectation from giconv about the expected lengths as coreclr's reflection stack makes from coreclr PAL's unicode.cpp, so this standalone component doesn't need to handle more edge cases than necessary.

[AaronRobinsonMSFT]

/cc @fanyang-mono

[fanyang-mono]

The test that @am11 mentioned was testing the custom attribute value string "\uDFFF". For mono, it went through minipal_convert_utf8_to_utf16 to decode this string "\xed\xbf\xbf". It seems to me that CoreCLR went through a different mechanism to get the value of the custom attribute value.

Additionally, what Mono is doing in g_utf8_to_utf16_impl of giconv.c isn't a lot different than what is done in MultiByteToWideChar of unicode.cpp. If I understand correctly, the only difference is that in MultiByteToWideChar, it makes source length and destination length one byte longer than it is. Doing this in mono won't stop this check ((sourceIndex < sourceLength) && (destinationIndex >= destinationLength)) either.

[am11]

@fanyang-mono, coreclr ultimately uses the same implementation (couple of wrappers later), but in reflection stack (metasig.h etc.), there it compensates for those off-by-one, zero-length kind of scenarios to match the expectation.

[fanyang-mono]

@am11 Do you mind pointing me to the CoreCLR source code where they handles off-by-one, zero-length kind of scenarios?

[am11]

@fanyang-mono, good question. 😅 It is a bit tricky to discern the exact place without actually attaching a conditional debugger (or some tricky way), but I was debugging the similar tests for coreclr last year #85558 (comment) which points to

runtime/src/coreclr/md/compiler/regmeta_import.cpp

Line 705 in d8c59a4

RegMeta::GetTypeDefProps(

One thing I do remember; when all PAL tests were passing and 99% of managed tests were passingm those edge cases covered in reflection tests were still failing, which is why I had to add a similar special condition in unicode.cpp -> utf8.c conversion to balance varied expectations of mono and coreclr + reflection simultaneously.

[fanyang-mono]

It is probably fine having this a little bit longer check, because to make mono align with CoreCLR on this is non-trivial work.

[AaronRobinsonMSFT]

Thanks. I will take a look.

[jkotas]

Could you please run your benchmark to see how it compares against the MultiByteToWideChar/WideCharToMultiChar win32 APIs?

int main()
{
char* p = (char*)malloc(200);
memset(p, 'a', 200);
for (;;)
{
int start = GetTickCount();
for (int i = 0; i < 10000000; i++)
#if 0
minipal_get_length_utf8_to_utf16(p, 200, 0);
#else
MultiByteToWideChar(CP_UTF8, 0, p, 200, NULL, 0);
#endif
int end = GetTickCount();
printf("%d\n", end - start);
}
}

MultiByteToWideChar: 220ms per iteration
minipal_get_length_utf8_to_utf16: 1370ms per iteration

[am11]

Ran some google benchmarks: https://gist.github.com/am11/8d949f6c112aaab1575e85f2f350c59e

Long length: 140
Short length: 20

main:

-------------------------------------------------------------------------------------------------------------
Benchmark Time CPU Iterations UserCounters...
-------------------------------------------------------------------------------------------------------------
BM_minipal_get_length_utf16_to_utf8/ASCII_Short 46.8 ns 46.3 ns 15200142 items_per_second=388.583M/s
BM_minipal_get_length_utf16_to_utf8/NonASCII_Short 49.2 ns 48.4 ns 14081759 items_per_second=288.974M/s
BM_minipal_get_length_utf16_to_utf8/ASCII_Long 48.5 ns 47.9 ns 14615732 items_per_second=2.92203G/s
BM_minipal_get_length_utf16_to_utf8/NonASCII_Long 167 ns 164 ns 4267226 items_per_second=854.207M/s
BM_minipal_convert_utf16_to_utf8/ASCII_Short 66.7 ns 65.7 ns 10535346 items_per_second=273.86M/s
BM_minipal_convert_utf16_to_utf8/NonASCII_Short 98.3 ns 97.0 ns 7215230 items_per_second=144.395M/s
BM_minipal_convert_utf16_to_utf8/ASCII_Long 135 ns 133 ns 5226338 items_per_second=1.05422G/s
BM_minipal_convert_utf16_to_utf8/NonASCII_Long 565 ns 556 ns 1261443 items_per_second=251.616M/s
BM_minipal_get_length_utf8_to_utf16/ASCII_Short 46.5 ns 45.7 ns 15311624 items_per_second=393.657M/s
BM_minipal_get_length_utf8_to_utf16/NonASCII_Short 56.6 ns 55.8 ns 12379302 items_per_second=573.563M/s
BM_minipal_get_length_utf8_to_utf16/ASCII_Long 47.7 ns 47.2 ns 15069416 items_per_second=2.96665G/s
BM_minipal_get_length_utf8_to_utf16/NonASCII_Long 118 ns 116 ns 5989100 items_per_second=1.20323G/s
BM_minipal_convert_utf8_to_utf16/ASCII_Short 61.5 ns 60.9 ns 11373792 items_per_second=295.365M/s
BM_minipal_convert_utf8_to_utf16/NonASCII_Short 126 ns 124 ns 5599462 items_per_second=257.461M/s
BM_minipal_convert_utf8_to_utf16/ASCII_Long 109 ns 108 ns 6452981 items_per_second=1.30072G/s
BM_minipal_convert_utf8_to_utf16/NonASCII_Long 260 ns 258 ns 2722687 items_per_second=542.822M/s

PR:

-------------------------------------------------------------------------------------------------------------
Benchmark Time CPU Iterations UserCounters...
-------------------------------------------------------------------------------------------------------------
BM_minipal_get_length_utf16_to_utf8/ASCII_Short 46.3 ns 46.2 ns 15294729 items_per_second=389.687M/s
BM_minipal_get_length_utf16_to_utf8/NonASCII_Short 46.7 ns 46.7 ns 15014757 items_per_second=300.068M/s
BM_minipal_get_length_utf16_to_utf8/ASCII_Long 89.1 ns 88.2 ns 7965951 items_per_second=1.58799G/s
BM_minipal_get_length_utf16_to_utf8/NonASCII_Long 167 ns 167 ns 4209817 items_per_second=840.11M/s
BM_minipal_convert_utf16_to_utf8/ASCII_Short 57.9 ns 57.8 ns 12086261 items_per_second=311.416M/s
BM_minipal_convert_utf16_to_utf8/NonASCII_Short 80.0 ns 79.9 ns 8745736 items_per_second=175.196M/s
BM_minipal_convert_utf16_to_utf8/ASCII_Long 155 ns 154 ns 4546517 items_per_second=907.604M/s
BM_minipal_convert_utf16_to_utf8/NonASCII_Long 489 ns 488 ns 1427791 items_per_second=286.914M/s
BM_minipal_get_length_utf8_to_utf16/ASCII_Short 47.9 ns 47.1 ns 14990417 items_per_second=382.482M/s
BM_minipal_get_length_utf8_to_utf16/NonASCII_Short 65.7 ns 65.6 ns 10645254 items_per_second=487.782M/s
BM_minipal_get_length_utf8_to_utf16/ASCII_Long 131 ns 130 ns 5443066 items_per_second=1.07377G/s
BM_minipal_get_length_utf8_to_utf16/NonASCII_Long 180 ns 179 ns 3938780 items_per_second=781.547M/s
BM_minipal_convert_utf8_to_utf16/ASCII_Short 73.2 ns 72.9 ns 9594561 items_per_second=246.863M/s
BM_minipal_convert_utf8_to_utf16/NonASCII_Short 109 ns 108 ns 6488872 items_per_second=296.073M/s
BM_minipal_convert_utf8_to_utf16/ASCII_Long 282 ns 281 ns 2457149 items_per_second=497.751M/s
BM_minipal_convert_utf8_to_utf16/NonASCII_Long 298 ns 296 ns 2353052 items_per_second=472.879M/s

BM_minipal_get_length_utf16_to_utf8/ASCII_Long has gotten the worse performance regression. I tried fast tracking ASCII with:

// Use vectorized operations for ASCII characterstypedefuint16_tv4ui __attribute__ ((vector_size (8)));
for (; sourceIndex<sourceLength&&destinationIndex<destinationLength; sourceIndex+=4, destinationIndex+=4)
{
v4uidata=*(v4ui*)&source[sourceIndex];
v4uimask4= (v4ui){0x007F, 0x007F, 0x007F, 0x007F};
v4uicomparison=data <= mask4;
size_tremainingLength=sourceLength-sourceIndex;
if (remainingLength>4&&__builtin_expect(comparison[0] &comparison[1] &comparison[2] &comparison[3], 1))
{
destination[destinationIndex] = (char)data[0];
destination[destinationIndex+1] = (char)data[1];
destination[destinationIndex+2] = (char)data[2];
destination[destinationIndex+3] = (char)data[3];
continue;
}
elseif (remainingLength <= 4)
{
// Handle the remaining 4 or less elements if ASCIIif (remainingLength==4) {
if (__builtin_expect(comparison[0] &comparison[1] &comparison[2] &comparison[3], 1))
{
destination[destinationIndex++] = (char)data[0];
destination[destinationIndex++] = (char)data[1];
destination[destinationIndex++] = (char)data[2];
destination[destinationIndex++] = (char)data[3];
returndestinationIndex;
}
break;
}
v4uimask3= (v4ui){0x007F, 0x007F, 0x007F};
v4uimask2= (v4ui){0x007F, 0x007F};
comparison=data <= mask3;
if (remainingLength==3) {
if( __builtin_expect(comparison[0] &comparison[1] &comparison[2], 1)) {
destination[destinationIndex++] = (char)data[0];
destination[destinationIndex++] = (char)data[1];
destination[destinationIndex++] = (char)data[2];
returndestinationIndex;
}
break;
}
comparison=data <= mask2;
if (remainingLength==2) {
if(__builtin_expect(comparison[0] &comparison[1], 1)) {
destination[destinationIndex++] = (char)data[0];
destination[destinationIndex++] = (char)data[1];
returndestinationIndex;
}
break;
}
if (source[sourceIndex] <0x80){
destination[destinationIndex++] = (char)source[sourceIndex];
returndestinationIndex;
}
}
// Break out of the outer loop here because we know it's non-ASCIIbreak;
}
// Handle non-ASCII and mixed caseswhile (sourceIndex<sourceLength&&destinationIndex<destinationLength)
{
...

but that did not move the needle (+/- 2ns diff).

Haven't given up on fine-tuning yet, but overall I think the new implementation is simple and more readable. So it's a balancing question of readability vs. performance (I'm pursuing both 🙂).

[AaronRobinsonMSFT]

@am11 I'm moving this to draft for now.

[dotnet-policy-service]

Draft Pull Request was automatically closed for 30 days of inactivity. Please let us know if you'd like to reopen it.

[am11]

diet version 🤸

[am11]

cc @AaronRobinsonMSFT, re: #100451 (comment) - this mainly reduces the assembly code with cl.exe -O2 (before 1091 lines, now 369 for minipal_convert_utf8_to_utf16). Could you please run your benchmark to see how it compares against the MultiByteToWideChar/WideCharToMultiChar win32 APIs? Hopefully it will perform better now (at least better than before 😅).

[am11]

@lambdageek, just an FYI, I had to change this condition from

if (sourceIndex < sourceLength && (destinationIndex >= destinationLength)

for mono because this case was failing:

runtime/src/libraries/System.Runtime/tests/System.Runtime.Tests/System/AttributeTests.cs

Line 169 in 2bfd1b4

Assert.NotNull(stringArg);

IMHO, the reflection stack of mono should use the same expectation from giconv about the expected lengths as coreclr's reflection stack makes from coreclr PAL's unicode.cpp, so this standalone component doesn't need to handle more edge cases than necessary.

[AaronRobinsonMSFT]

/cc @fanyang-mono

[fanyang-mono]

The test that @am11 mentioned was testing the custom attribute value string "\uDFFF". For mono, it went through minipal_convert_utf8_to_utf16 to decode this string "\xed\xbf\xbf". It seems to me that CoreCLR went through a different mechanism to get the value of the custom attribute value.

Additionally, what Mono is doing in g_utf8_to_utf16_impl of giconv.c isn't a lot different than what is done in MultiByteToWideChar of unicode.cpp. If I understand correctly, the only difference is that in MultiByteToWideChar, it makes source length and destination length one byte longer than it is. Doing this in mono won't stop this check ((sourceIndex < sourceLength) && (destinationIndex >= destinationLength)) either.

[am11]

@fanyang-mono, coreclr ultimately uses the same implementation (couple of wrappers later), but in reflection stack (metasig.h etc.), there it compensates for those off-by-one, zero-length kind of scenarios to match the expectation.

[fanyang-mono]

@am11 Do you mind pointing me to the CoreCLR source code where they handles off-by-one, zero-length kind of scenarios?

[am11]

@fanyang-mono, good question. 😅 It is a bit tricky to discern the exact place without actually attaching a conditional debugger (or some tricky way), but I was debugging the similar tests for coreclr last year #85558 (comment) which points to

runtime/src/coreclr/md/compiler/regmeta_import.cpp

Line 705 in d8c59a4

RegMeta::GetTypeDefProps(

One thing I do remember; when all PAL tests were passing and 99% of managed tests were passingm those edge cases covered in reflection tests were still failing, which is why I had to add a similar special condition in unicode.cpp -> utf8.c conversion to balance varied expectations of mono and coreclr + reflection simultaneously.

[fanyang-mono]

It is probably fine having this a little bit longer check, because to make mono align with CoreCLR on this is non-trivial work.

[AaronRobinsonMSFT]

Thanks. I will take a look.

[jkotas]

Could you please run your benchmark to see how it compares against the MultiByteToWideChar/WideCharToMultiChar win32 APIs?

int main()
{
char* p = (char*)malloc(200);
memset(p, 'a', 200);
for (;;)
{
int start = GetTickCount();
for (int i = 0; i < 10000000; i++)
#if 0
minipal_get_length_utf8_to_utf16(p, 200, 0);
#else
MultiByteToWideChar(CP_UTF8, 0, p, 200, NULL, 0);
#endif
int end = GetTickCount();
printf("%d\n", end - start);
}
}

MultiByteToWideChar: 220ms per iteration
minipal_get_length_utf8_to_utf16: 1370ms per iteration

[am11]

Ran some google benchmarks: https://gist.github.com/am11/8d949f6c112aaab1575e85f2f350c59e

Long length: 140
Short length: 20

main:

-------------------------------------------------------------------------------------------------------------
Benchmark Time CPU Iterations UserCounters...
-------------------------------------------------------------------------------------------------------------
BM_minipal_get_length_utf16_to_utf8/ASCII_Short 46.8 ns 46.3 ns 15200142 items_per_second=388.583M/s
BM_minipal_get_length_utf16_to_utf8/NonASCII_Short 49.2 ns 48.4 ns 14081759 items_per_second=288.974M/s
BM_minipal_get_length_utf16_to_utf8/ASCII_Long 48.5 ns 47.9 ns 14615732 items_per_second=2.92203G/s
BM_minipal_get_length_utf16_to_utf8/NonASCII_Long 167 ns 164 ns 4267226 items_per_second=854.207M/s
BM_minipal_convert_utf16_to_utf8/ASCII_Short 66.7 ns 65.7 ns 10535346 items_per_second=273.86M/s
BM_minipal_convert_utf16_to_utf8/NonASCII_Short 98.3 ns 97.0 ns 7215230 items_per_second=144.395M/s
BM_minipal_convert_utf16_to_utf8/ASCII_Long 135 ns 133 ns 5226338 items_per_second=1.05422G/s
BM_minipal_convert_utf16_to_utf8/NonASCII_Long 565 ns 556 ns 1261443 items_per_second=251.616M/s
BM_minipal_get_length_utf8_to_utf16/ASCII_Short 46.5 ns 45.7 ns 15311624 items_per_second=393.657M/s
BM_minipal_get_length_utf8_to_utf16/NonASCII_Short 56.6 ns 55.8 ns 12379302 items_per_second=573.563M/s
BM_minipal_get_length_utf8_to_utf16/ASCII_Long 47.7 ns 47.2 ns 15069416 items_per_second=2.96665G/s
BM_minipal_get_length_utf8_to_utf16/NonASCII_Long 118 ns 116 ns 5989100 items_per_second=1.20323G/s
BM_minipal_convert_utf8_to_utf16/ASCII_Short 61.5 ns 60.9 ns 11373792 items_per_second=295.365M/s
BM_minipal_convert_utf8_to_utf16/NonASCII_Short 126 ns 124 ns 5599462 items_per_second=257.461M/s
BM_minipal_convert_utf8_to_utf16/ASCII_Long 109 ns 108 ns 6452981 items_per_second=1.30072G/s
BM_minipal_convert_utf8_to_utf16/NonASCII_Long 260 ns 258 ns 2722687 items_per_second=542.822M/s

PR:

-------------------------------------------------------------------------------------------------------------
Benchmark Time CPU Iterations UserCounters...
-------------------------------------------------------------------------------------------------------------
BM_minipal_get_length_utf16_to_utf8/ASCII_Short 46.3 ns 46.2 ns 15294729 items_per_second=389.687M/s
BM_minipal_get_length_utf16_to_utf8/NonASCII_Short 46.7 ns 46.7 ns 15014757 items_per_second=300.068M/s
BM_minipal_get_length_utf16_to_utf8/ASCII_Long 89.1 ns 88.2 ns 7965951 items_per_second=1.58799G/s
BM_minipal_get_length_utf16_to_utf8/NonASCII_Long 167 ns 167 ns 4209817 items_per_second=840.11M/s
BM_minipal_convert_utf16_to_utf8/ASCII_Short 57.9 ns 57.8 ns 12086261 items_per_second=311.416M/s
BM_minipal_convert_utf16_to_utf8/NonASCII_Short 80.0 ns 79.9 ns 8745736 items_per_second=175.196M/s
BM_minipal_convert_utf16_to_utf8/ASCII_Long 155 ns 154 ns 4546517 items_per_second=907.604M/s
BM_minipal_convert_utf16_to_utf8/NonASCII_Long 489 ns 488 ns 1427791 items_per_second=286.914M/s
BM_minipal_get_length_utf8_to_utf16/ASCII_Short 47.9 ns 47.1 ns 14990417 items_per_second=382.482M/s
BM_minipal_get_length_utf8_to_utf16/NonASCII_Short 65.7 ns 65.6 ns 10645254 items_per_second=487.782M/s
BM_minipal_get_length_utf8_to_utf16/ASCII_Long 131 ns 130 ns 5443066 items_per_second=1.07377G/s
BM_minipal_get_length_utf8_to_utf16/NonASCII_Long 180 ns 179 ns 3938780 items_per_second=781.547M/s
BM_minipal_convert_utf8_to_utf16/ASCII_Short 73.2 ns 72.9 ns 9594561 items_per_second=246.863M/s
BM_minipal_convert_utf8_to_utf16/NonASCII_Short 109 ns 108 ns 6488872 items_per_second=296.073M/s
BM_minipal_convert_utf8_to_utf16/ASCII_Long 282 ns 281 ns 2457149 items_per_second=497.751M/s
BM_minipal_convert_utf8_to_utf16/NonASCII_Long 298 ns 296 ns 2353052 items_per_second=472.879M/s

BM_minipal_get_length_utf16_to_utf8/ASCII_Long has gotten the worse performance regression. I tried fast tracking ASCII with:

// Use vectorized operations for ASCII characterstypedefuint16_tv4ui __attribute__ ((vector_size (8)));
for (; sourceIndex<sourceLength&&destinationIndex<destinationLength; sourceIndex+=4, destinationIndex+=4)
{
v4uidata=*(v4ui*)&source[sourceIndex];
v4uimask4= (v4ui){0x007F, 0x007F, 0x007F, 0x007F};
v4uicomparison=data <= mask4;
size_tremainingLength=sourceLength-sourceIndex;
if (remainingLength>4&&__builtin_expect(comparison[0] &comparison[1] &comparison[2] &comparison[3], 1))
{
destination[destinationIndex] = (char)data[0];
destination[destinationIndex+1] = (char)data[1];
destination[destinationIndex+2] = (char)data[2];
destination[destinationIndex+3] = (char)data[3];
continue;
}
elseif (remainingLength <= 4)
{
// Handle the remaining 4 or less elements if ASCIIif (remainingLength==4) {
if (__builtin_expect(comparison[0] &comparison[1] &comparison[2] &comparison[3], 1))
{
destination[destinationIndex++] = (char)data[0];
destination[destinationIndex++] = (char)data[1];
destination[destinationIndex++] = (char)data[2];
destination[destinationIndex++] = (char)data[3];
returndestinationIndex;
}
break;
}
v4uimask3= (v4ui){0x007F, 0x007F, 0x007F};
v4uimask2= (v4ui){0x007F, 0x007F};
comparison=data <= mask3;
if (remainingLength==3) {
if( __builtin_expect(comparison[0] &comparison[1] &comparison[2], 1)) {
destination[destinationIndex++] = (char)data[0];
destination[destinationIndex++] = (char)data[1];
destination[destinationIndex++] = (char)data[2];
returndestinationIndex;
}
break;
}
comparison=data <= mask2;
if (remainingLength==2) {
if(__builtin_expect(comparison[0] &comparison[1], 1)) {
destination[destinationIndex++] = (char)data[0];
destination[destinationIndex++] = (char)data[1];
returndestinationIndex;
}
break;
}
if (source[sourceIndex] <0x80){
destination[destinationIndex++] = (char)source[sourceIndex];
returndestinationIndex;
}
}
// Break out of the outer loop here because we know it's non-ASCIIbreak;
}
// Handle non-ASCII and mixed caseswhile (sourceIndex<sourceLength&&destinationIndex<destinationLength)
{
...

but that did not move the needle (+/- 2ns diff).

Haven't given up on fine-tuning yet, but overall I think the new implementation is simple and more readable. So it's a balancing question of readability vs. performance (I'm pursuing both 🙂).

[AaronRobinsonMSFT]

@am11 I'm moving this to draft for now.

[dotnet-policy-service]

Draft Pull Request was automatically closed for 30 days of inactivity. Please let us know if you'd like to reopen it.

[am11]

diet version 🤸

[am11]

cc @AaronRobinsonMSFT, re: #100451 (comment) - this mainly reduces the assembly code with cl.exe -O2 (before 1091 lines, now 369 for minipal_convert_utf8_to_utf16). Could you please run your benchmark to see how it compares against the MultiByteToWideChar/WideCharToMultiChar win32 APIs? Hopefully it will perform better now (at least better than before 😅).

[am11]

@lambdageek, just an FYI, I had to change this condition from

if (sourceIndex < sourceLength && (destinationIndex >= destinationLength)

for mono because this case was failing:

runtime/src/libraries/System.Runtime/tests/System.Runtime.Tests/System/AttributeTests.cs

Line 169 in 2bfd1b4

Assert.NotNull(stringArg);

IMHO, the reflection stack of mono should use the same expectation from giconv about the expected lengths as coreclr's reflection stack makes from coreclr PAL's unicode.cpp, so this standalone component doesn't need to handle more edge cases than necessary.

[AaronRobinsonMSFT]

/cc @fanyang-mono

[fanyang-mono]

The test that @am11 mentioned was testing the custom attribute value string "\uDFFF". For mono, it went through minipal_convert_utf8_to_utf16 to decode this string "\xed\xbf\xbf". It seems to me that CoreCLR went through a different mechanism to get the value of the custom attribute value.

Additionally, what Mono is doing in g_utf8_to_utf16_impl of giconv.c isn't a lot different than what is done in MultiByteToWideChar of unicode.cpp. If I understand correctly, the only difference is that in MultiByteToWideChar, it makes source length and destination length one byte longer than it is. Doing this in mono won't stop this check ((sourceIndex < sourceLength) && (destinationIndex >= destinationLength)) either.

[am11]

@fanyang-mono, coreclr ultimately uses the same implementation (couple of wrappers later), but in reflection stack (metasig.h etc.), there it compensates for those off-by-one, zero-length kind of scenarios to match the expectation.

[fanyang-mono]

@am11 Do you mind pointing me to the CoreCLR source code where they handles off-by-one, zero-length kind of scenarios?

[am11]

@fanyang-mono, good question. 😅 It is a bit tricky to discern the exact place without actually attaching a conditional debugger (or some tricky way), but I was debugging the similar tests for coreclr last year #85558 (comment) which points to

runtime/src/coreclr/md/compiler/regmeta_import.cpp

Line 705 in d8c59a4

RegMeta::GetTypeDefProps(

One thing I do remember; when all PAL tests were passing and 99% of managed tests were passingm those edge cases covered in reflection tests were still failing, which is why I had to add a similar special condition in unicode.cpp -> utf8.c conversion to balance varied expectations of mono and coreclr + reflection simultaneously.

[fanyang-mono]

It is probably fine having this a little bit longer check, because to make mono align with CoreCLR on this is non-trivial work.

[AaronRobinsonMSFT]

Thanks. I will take a look.

[jkotas]

Could you please run your benchmark to see how it compares against the MultiByteToWideChar/WideCharToMultiChar win32 APIs?

int main()
{
char* p = (char*)malloc(200);
memset(p, 'a', 200);
for (;;)
{
int start = GetTickCount();
for (int i = 0; i < 10000000; i++)
#if 0
minipal_get_length_utf8_to_utf16(p, 200, 0);
#else
MultiByteToWideChar(CP_UTF8, 0, p, 200, NULL, 0);
#endif
int end = GetTickCount();
printf("%d\n", end - start);
}
}

MultiByteToWideChar: 220ms per iteration
minipal_get_length_utf8_to_utf16: 1370ms per iteration

[am11]

Ran some google benchmarks: https://gist.github.com/am11/8d949f6c112aaab1575e85f2f350c59e

Long length: 140
Short length: 20

main:

-------------------------------------------------------------------------------------------------------------
Benchmark Time CPU Iterations UserCounters...
-------------------------------------------------------------------------------------------------------------
BM_minipal_get_length_utf16_to_utf8/ASCII_Short 46.8 ns 46.3 ns 15200142 items_per_second=388.583M/s
BM_minipal_get_length_utf16_to_utf8/NonASCII_Short 49.2 ns 48.4 ns 14081759 items_per_second=288.974M/s
BM_minipal_get_length_utf16_to_utf8/ASCII_Long 48.5 ns 47.9 ns 14615732 items_per_second=2.92203G/s
BM_minipal_get_length_utf16_to_utf8/NonASCII_Long 167 ns 164 ns 4267226 items_per_second=854.207M/s
BM_minipal_convert_utf16_to_utf8/ASCII_Short 66.7 ns 65.7 ns 10535346 items_per_second=273.86M/s
BM_minipal_convert_utf16_to_utf8/NonASCII_Short 98.3 ns 97.0 ns 7215230 items_per_second=144.395M/s
BM_minipal_convert_utf16_to_utf8/ASCII_Long 135 ns 133 ns 5226338 items_per_second=1.05422G/s
BM_minipal_convert_utf16_to_utf8/NonASCII_Long 565 ns 556 ns 1261443 items_per_second=251.616M/s
BM_minipal_get_length_utf8_to_utf16/ASCII_Short 46.5 ns 45.7 ns 15311624 items_per_second=393.657M/s
BM_minipal_get_length_utf8_to_utf16/NonASCII_Short 56.6 ns 55.8 ns 12379302 items_per_second=573.563M/s
BM_minipal_get_length_utf8_to_utf16/ASCII_Long 47.7 ns 47.2 ns 15069416 items_per_second=2.96665G/s
BM_minipal_get_length_utf8_to_utf16/NonASCII_Long 118 ns 116 ns 5989100 items_per_second=1.20323G/s
BM_minipal_convert_utf8_to_utf16/ASCII_Short 61.5 ns 60.9 ns 11373792 items_per_second=295.365M/s
BM_minipal_convert_utf8_to_utf16/NonASCII_Short 126 ns 124 ns 5599462 items_per_second=257.461M/s
BM_minipal_convert_utf8_to_utf16/ASCII_Long 109 ns 108 ns 6452981 items_per_second=1.30072G/s
BM_minipal_convert_utf8_to_utf16/NonASCII_Long 260 ns 258 ns 2722687 items_per_second=542.822M/s

PR:

-------------------------------------------------------------------------------------------------------------
Benchmark Time CPU Iterations UserCounters...
-------------------------------------------------------------------------------------------------------------
BM_minipal_get_length_utf16_to_utf8/ASCII_Short 46.3 ns 46.2 ns 15294729 items_per_second=389.687M/s
BM_minipal_get_length_utf16_to_utf8/NonASCII_Short 46.7 ns 46.7 ns 15014757 items_per_second=300.068M/s
BM_minipal_get_length_utf16_to_utf8/ASCII_Long 89.1 ns 88.2 ns 7965951 items_per_second=1.58799G/s
BM_minipal_get_length_utf16_to_utf8/NonASCII_Long 167 ns 167 ns 4209817 items_per_second=840.11M/s
BM_minipal_convert_utf16_to_utf8/ASCII_Short 57.9 ns 57.8 ns 12086261 items_per_second=311.416M/s
BM_minipal_convert_utf16_to_utf8/NonASCII_Short 80.0 ns 79.9 ns 8745736 items_per_second=175.196M/s
BM_minipal_convert_utf16_to_utf8/ASCII_Long 155 ns 154 ns 4546517 items_per_second=907.604M/s
BM_minipal_convert_utf16_to_utf8/NonASCII_Long 489 ns 488 ns 1427791 items_per_second=286.914M/s
BM_minipal_get_length_utf8_to_utf16/ASCII_Short 47.9 ns 47.1 ns 14990417 items_per_second=382.482M/s
BM_minipal_get_length_utf8_to_utf16/NonASCII_Short 65.7 ns 65.6 ns 10645254 items_per_second=487.782M/s
BM_minipal_get_length_utf8_to_utf16/ASCII_Long 131 ns 130 ns 5443066 items_per_second=1.07377G/s
BM_minipal_get_length_utf8_to_utf16/NonASCII_Long 180 ns 179 ns 3938780 items_per_second=781.547M/s
BM_minipal_convert_utf8_to_utf16/ASCII_Short 73.2 ns 72.9 ns 9594561 items_per_second=246.863M/s
BM_minipal_convert_utf8_to_utf16/NonASCII_Short 109 ns 108 ns 6488872 items_per_second=296.073M/s
BM_minipal_convert_utf8_to_utf16/ASCII_Long 282 ns 281 ns 2457149 items_per_second=497.751M/s
BM_minipal_convert_utf8_to_utf16/NonASCII_Long 298 ns 296 ns 2353052 items_per_second=472.879M/s

BM_minipal_get_length_utf16_to_utf8/ASCII_Long has gotten the worse performance regression. I tried fast tracking ASCII with:

// Use vectorized operations for ASCII characterstypedefuint16_tv4ui __attribute__ ((vector_size (8)));
for (; sourceIndex<sourceLength&&destinationIndex<destinationLength; sourceIndex+=4, destinationIndex+=4)
{
v4uidata=*(v4ui*)&source[sourceIndex];
v4uimask4= (v4ui){0x007F, 0x007F, 0x007F, 0x007F};
v4uicomparison=data <= mask4;
size_tremainingLength=sourceLength-sourceIndex;
if (remainingLength>4&&__builtin_expect(comparison[0] &comparison[1] &comparison[2] &comparison[3], 1))
{
destination[destinationIndex] = (char)data[0];
destination[destinationIndex+1] = (char)data[1];
destination[destinationIndex+2] = (char)data[2];
destination[destinationIndex+3] = (char)data[3];
continue;
}
elseif (remainingLength <= 4)
{
// Handle the remaining 4 or less elements if ASCIIif (remainingLength==4) {
if (__builtin_expect(comparison[0] &comparison[1] &comparison[2] &comparison[3], 1))
{
destination[destinationIndex++] = (char)data[0];
destination[destinationIndex++] = (char)data[1];
destination[destinationIndex++] = (char)data[2];
destination[destinationIndex++] = (char)data[3];
returndestinationIndex;
}
break;
}
v4uimask3= (v4ui){0x007F, 0x007F, 0x007F};
v4uimask2= (v4ui){0x007F, 0x007F};
comparison=data <= mask3;
if (remainingLength==3) {
if( __builtin_expect(comparison[0] &comparison[1] &comparison[2], 1)) {
destination[destinationIndex++] = (char)data[0];
destination[destinationIndex++] = (char)data[1];
destination[destinationIndex++] = (char)data[2];
returndestinationIndex;
}
break;
}
comparison=data <= mask2;
if (remainingLength==2) {
if(__builtin_expect(comparison[0] &comparison[1], 1)) {
destination[destinationIndex++] = (char)data[0];
destination[destinationIndex++] = (char)data[1];
returndestinationIndex;
}
break;
}
if (source[sourceIndex] <0x80){
destination[destinationIndex++] = (char)source[sourceIndex];
returndestinationIndex;
}
}
// Break out of the outer loop here because we know it's non-ASCIIbreak;
}
// Handle non-ASCII and mixed caseswhile (sourceIndex<sourceLength&&destinationIndex<destinationLength)
{
...

but that did not move the needle (+/- 2ns diff).

Haven't given up on fine-tuning yet, but overall I think the new implementation is simple and more readable. So it's a balancing question of readability vs. performance (I'm pursuing both 🙂).

[AaronRobinsonMSFT]

@am11 I'm moving this to draft for now.

[dotnet-policy-service]

Draft Pull Request was automatically closed for 30 days of inactivity. Please let us know if you'd like to reopen it.

[am11]

diet version 🤸

[am11]

cc @AaronRobinsonMSFT, re: #100451 (comment) - this mainly reduces the assembly code with cl.exe -O2 (before 1091 lines, now 369 for minipal_convert_utf8_to_utf16). Could you please run your benchmark to see how it compares against the MultiByteToWideChar/WideCharToMultiChar win32 APIs? Hopefully it will perform better now (at least better than before 😅).

[am11]

@lambdageek, just an FYI, I had to change this condition from

if (sourceIndex < sourceLength && (destinationIndex >= destinationLength)

for mono because this case was failing:

runtime/src/libraries/System.Runtime/tests/System.Runtime.Tests/System/AttributeTests.cs

Line 169 in 2bfd1b4

Assert.NotNull(stringArg);

IMHO, the reflection stack of mono should use the same expectation from giconv about the expected lengths as coreclr's reflection stack makes from coreclr PAL's unicode.cpp, so this standalone component doesn't need to handle more edge cases than necessary.

[AaronRobinsonMSFT]

/cc @fanyang-mono

[fanyang-mono]

The test that @am11 mentioned was testing the custom attribute value string "\uDFFF". For mono, it went through minipal_convert_utf8_to_utf16 to decode this string "\xed\xbf\xbf". It seems to me that CoreCLR went through a different mechanism to get the value of the custom attribute value.

Additionally, what Mono is doing in g_utf8_to_utf16_impl of giconv.c isn't a lot different than what is done in MultiByteToWideChar of unicode.cpp. If I understand correctly, the only difference is that in MultiByteToWideChar, it makes source length and destination length one byte longer than it is. Doing this in mono won't stop this check ((sourceIndex < sourceLength) && (destinationIndex >= destinationLength)) either.

[am11]

@fanyang-mono, coreclr ultimately uses the same implementation (couple of wrappers later), but in reflection stack (metasig.h etc.), there it compensates for those off-by-one, zero-length kind of scenarios to match the expectation.

[fanyang-mono]

@am11 Do you mind pointing me to the CoreCLR source code where they handles off-by-one, zero-length kind of scenarios?

[am11]

@fanyang-mono, good question. 😅 It is a bit tricky to discern the exact place without actually attaching a conditional debugger (or some tricky way), but I was debugging the similar tests for coreclr last year #85558 (comment) which points to

runtime/src/coreclr/md/compiler/regmeta_import.cpp

Line 705 in d8c59a4

RegMeta::GetTypeDefProps(

One thing I do remember; when all PAL tests were passing and 99% of managed tests were passingm those edge cases covered in reflection tests were still failing, which is why I had to add a similar special condition in unicode.cpp -> utf8.c conversion to balance varied expectations of mono and coreclr + reflection simultaneously.

[fanyang-mono]

It is probably fine having this a little bit longer check, because to make mono align with CoreCLR on this is non-trivial work.

[AaronRobinsonMSFT]

Thanks. I will take a look.

[jkotas]

Could you please run your benchmark to see how it compares against the MultiByteToWideChar/WideCharToMultiChar win32 APIs?

int main()
{
char* p = (char*)malloc(200);
memset(p, 'a', 200);
for (;;)
{
int start = GetTickCount();
for (int i = 0; i < 10000000; i++)
#if 0
minipal_get_length_utf8_to_utf16(p, 200, 0);
#else
MultiByteToWideChar(CP_UTF8, 0, p, 200, NULL, 0);
#endif
int end = GetTickCount();
printf("%d\n", end - start);
}
}

MultiByteToWideChar: 220ms per iteration
minipal_get_length_utf8_to_utf16: 1370ms per iteration

[am11]

Ran some google benchmarks: https://gist.github.com/am11/8d949f6c112aaab1575e85f2f350c59e

Long length: 140
Short length: 20

main:

-------------------------------------------------------------------------------------------------------------
Benchmark Time CPU Iterations UserCounters...
-------------------------------------------------------------------------------------------------------------
BM_minipal_get_length_utf16_to_utf8/ASCII_Short 46.8 ns 46.3 ns 15200142 items_per_second=388.583M/s
BM_minipal_get_length_utf16_to_utf8/NonASCII_Short 49.2 ns 48.4 ns 14081759 items_per_second=288.974M/s
BM_minipal_get_length_utf16_to_utf8/ASCII_Long 48.5 ns 47.9 ns 14615732 items_per_second=2.92203G/s
BM_minipal_get_length_utf16_to_utf8/NonASCII_Long 167 ns 164 ns 4267226 items_per_second=854.207M/s
BM_minipal_convert_utf16_to_utf8/ASCII_Short 66.7 ns 65.7 ns 10535346 items_per_second=273.86M/s
BM_minipal_convert_utf16_to_utf8/NonASCII_Short 98.3 ns 97.0 ns 7215230 items_per_second=144.395M/s
BM_minipal_convert_utf16_to_utf8/ASCII_Long 135 ns 133 ns 5226338 items_per_second=1.05422G/s
BM_minipal_convert_utf16_to_utf8/NonASCII_Long 565 ns 556 ns 1261443 items_per_second=251.616M/s
BM_minipal_get_length_utf8_to_utf16/ASCII_Short 46.5 ns 45.7 ns 15311624 items_per_second=393.657M/s
BM_minipal_get_length_utf8_to_utf16/NonASCII_Short 56.6 ns 55.8 ns 12379302 items_per_second=573.563M/s
BM_minipal_get_length_utf8_to_utf16/ASCII_Long 47.7 ns 47.2 ns 15069416 items_per_second=2.96665G/s
BM_minipal_get_length_utf8_to_utf16/NonASCII_Long 118 ns 116 ns 5989100 items_per_second=1.20323G/s
BM_minipal_convert_utf8_to_utf16/ASCII_Short 61.5 ns 60.9 ns 11373792 items_per_second=295.365M/s
BM_minipal_convert_utf8_to_utf16/NonASCII_Short 126 ns 124 ns 5599462 items_per_second=257.461M/s
BM_minipal_convert_utf8_to_utf16/ASCII_Long 109 ns 108 ns 6452981 items_per_second=1.30072G/s
BM_minipal_convert_utf8_to_utf16/NonASCII_Long 260 ns 258 ns 2722687 items_per_second=542.822M/s

PR:

-------------------------------------------------------------------------------------------------------------
Benchmark Time CPU Iterations UserCounters...
-------------------------------------------------------------------------------------------------------------
BM_minipal_get_length_utf16_to_utf8/ASCII_Short 46.3 ns 46.2 ns 15294729 items_per_second=389.687M/s
BM_minipal_get_length_utf16_to_utf8/NonASCII_Short 46.7 ns 46.7 ns 15014757 items_per_second=300.068M/s
BM_minipal_get_length_utf16_to_utf8/ASCII_Long 89.1 ns 88.2 ns 7965951 items_per_second=1.58799G/s
BM_minipal_get_length_utf16_to_utf8/NonASCII_Long 167 ns 167 ns 4209817 items_per_second=840.11M/s
BM_minipal_convert_utf16_to_utf8/ASCII_Short 57.9 ns 57.8 ns 12086261 items_per_second=311.416M/s
BM_minipal_convert_utf16_to_utf8/NonASCII_Short 80.0 ns 79.9 ns 8745736 items_per_second=175.196M/s
BM_minipal_convert_utf16_to_utf8/ASCII_Long 155 ns 154 ns 4546517 items_per_second=907.604M/s
BM_minipal_convert_utf16_to_utf8/NonASCII_Long 489 ns 488 ns 1427791 items_per_second=286.914M/s
BM_minipal_get_length_utf8_to_utf16/ASCII_Short 47.9 ns 47.1 ns 14990417 items_per_second=382.482M/s
BM_minipal_get_length_utf8_to_utf16/NonASCII_Short 65.7 ns 65.6 ns 10645254 items_per_second=487.782M/s
BM_minipal_get_length_utf8_to_utf16/ASCII_Long 131 ns 130 ns 5443066 items_per_second=1.07377G/s
BM_minipal_get_length_utf8_to_utf16/NonASCII_Long 180 ns 179 ns 3938780 items_per_second=781.547M/s
BM_minipal_convert_utf8_to_utf16/ASCII_Short 73.2 ns 72.9 ns 9594561 items_per_second=246.863M/s
BM_minipal_convert_utf8_to_utf16/NonASCII_Short 109 ns 108 ns 6488872 items_per_second=296.073M/s
BM_minipal_convert_utf8_to_utf16/ASCII_Long 282 ns 281 ns 2457149 items_per_second=497.751M/s
BM_minipal_convert_utf8_to_utf16/NonASCII_Long 298 ns 296 ns 2353052 items_per_second=472.879M/s

BM_minipal_get_length_utf16_to_utf8/ASCII_Long has gotten the worse performance regression. I tried fast tracking ASCII with:

// Use vectorized operations for ASCII characterstypedefuint16_tv4ui __attribute__ ((vector_size (8)));
for (; sourceIndex<sourceLength&&destinationIndex<destinationLength; sourceIndex+=4, destinationIndex+=4)
{
v4uidata=*(v4ui*)&source[sourceIndex];
v4uimask4= (v4ui){0x007F, 0x007F, 0x007F, 0x007F};
v4uicomparison=data <= mask4;
size_tremainingLength=sourceLength-sourceIndex;
if (remainingLength>4&&__builtin_expect(comparison[0] &comparison[1] &comparison[2] &comparison[3], 1))
{
destination[destinationIndex] = (char)data[0];
destination[destinationIndex+1] = (char)data[1];
destination[destinationIndex+2] = (char)data[2];
destination[destinationIndex+3] = (char)data[3];
continue;
}
elseif (remainingLength <= 4)
{
// Handle the remaining 4 or less elements if ASCIIif (remainingLength==4) {
if (__builtin_expect(comparison[0] &comparison[1] &comparison[2] &comparison[3], 1))
{
destination[destinationIndex++] = (char)data[0];
destination[destinationIndex++] = (char)data[1];
destination[destinationIndex++] = (char)data[2];
destination[destinationIndex++] = (char)data[3];
returndestinationIndex;
}
break;
}
v4uimask3= (v4ui){0x007F, 0x007F, 0x007F};
v4uimask2= (v4ui){0x007F, 0x007F};
comparison=data <= mask3;
if (remainingLength==3) {
if( __builtin_expect(comparison[0] &comparison[1] &comparison[2], 1)) {
destination[destinationIndex++] = (char)data[0];
destination[destinationIndex++] = (char)data[1];
destination[destinationIndex++] = (char)data[2];
returndestinationIndex;
}
break;
}
comparison=data <= mask2;
if (remainingLength==2) {
if(__builtin_expect(comparison[0] &comparison[1], 1)) {
destination[destinationIndex++] = (char)data[0];
destination[destinationIndex++] = (char)data[1];
returndestinationIndex;
}
break;
}
if (source[sourceIndex] <0x80){
destination[destinationIndex++] = (char)source[sourceIndex];
returndestinationIndex;
}
}
// Break out of the outer loop here because we know it's non-ASCIIbreak;
}
// Handle non-ASCII and mixed caseswhile (sourceIndex<sourceLength&&destinationIndex<destinationLength)
{
...

but that did not move the needle (+/- 2ns diff).

Haven't given up on fine-tuning yet, but overall I think the new implementation is simple and more readable. So it's a balancing question of readability vs. performance (I'm pursuing both 🙂).

[AaronRobinsonMSFT]

@am11 I'm moving this to draft for now.

[dotnet-policy-service]

Draft Pull Request was automatically closed for 30 days of inactivity. Please let us know if you'd like to reopen it.

[am11]

diet version 🤸

[am11]

cc @AaronRobinsonMSFT, re: #100451 (comment) - this mainly reduces the assembly code with cl.exe -O2 (before 1091 lines, now 369 for minipal_convert_utf8_to_utf16). Could you please run your benchmark to see how it compares against the MultiByteToWideChar/WideCharToMultiChar win32 APIs? Hopefully it will perform better now (at least better than before 😅).

[am11]

@lambdageek, just an FYI, I had to change this condition from

if (sourceIndex < sourceLength && (destinationIndex >= destinationLength)

for mono because this case was failing:

runtime/src/libraries/System.Runtime/tests/System.Runtime.Tests/System/AttributeTests.cs

Line 169 in 2bfd1b4

Assert.NotNull(stringArg);

IMHO, the reflection stack of mono should use the same expectation from giconv about the expected lengths as coreclr's reflection stack makes from coreclr PAL's unicode.cpp, so this standalone component doesn't need to handle more edge cases than necessary.

[AaronRobinsonMSFT]

/cc @fanyang-mono

[fanyang-mono]

The test that @am11 mentioned was testing the custom attribute value string "\uDFFF". For mono, it went through minipal_convert_utf8_to_utf16 to decode this string "\xed\xbf\xbf". It seems to me that CoreCLR went through a different mechanism to get the value of the custom attribute value.

Additionally, what Mono is doing in g_utf8_to_utf16_impl of giconv.c isn't a lot different than what is done in MultiByteToWideChar of unicode.cpp. If I understand correctly, the only difference is that in MultiByteToWideChar, it makes source length and destination length one byte longer than it is. Doing this in mono won't stop this check ((sourceIndex < sourceLength) && (destinationIndex >= destinationLength)) either.

[am11]

@fanyang-mono, coreclr ultimately uses the same implementation (couple of wrappers later), but in reflection stack (metasig.h etc.), there it compensates for those off-by-one, zero-length kind of scenarios to match the expectation.

[fanyang-mono]

@am11 Do you mind pointing me to the CoreCLR source code where they handles off-by-one, zero-length kind of scenarios?

[am11]

@fanyang-mono, good question. 😅 It is a bit tricky to discern the exact place without actually attaching a conditional debugger (or some tricky way), but I was debugging the similar tests for coreclr last year #85558 (comment) which points to

runtime/src/coreclr/md/compiler/regmeta_import.cpp

Line 705 in d8c59a4

RegMeta::GetTypeDefProps(

One thing I do remember; when all PAL tests were passing and 99% of managed tests were passingm those edge cases covered in reflection tests were still failing, which is why I had to add a similar special condition in unicode.cpp -> utf8.c conversion to balance varied expectations of mono and coreclr + reflection simultaneously.

[fanyang-mono]

It is probably fine having this a little bit longer check, because to make mono align with CoreCLR on this is non-trivial work.

[AaronRobinsonMSFT]

Thanks. I will take a look.

[jkotas]

Could you please run your benchmark to see how it compares against the MultiByteToWideChar/WideCharToMultiChar win32 APIs?

int main()
{
char* p = (char*)malloc(200);
memset(p, 'a', 200);
for (;;)
{
int start = GetTickCount();
for (int i = 0; i < 10000000; i++)
#if 0
minipal_get_length_utf8_to_utf16(p, 200, 0);
#else
MultiByteToWideChar(CP_UTF8, 0, p, 200, NULL, 0);
#endif
int end = GetTickCount();
printf("%d\n", end - start);
}
}

MultiByteToWideChar: 220ms per iteration
minipal_get_length_utf8_to_utf16: 1370ms per iteration

[am11]

Ran some google benchmarks: https://gist.github.com/am11/8d949f6c112aaab1575e85f2f350c59e

Long length: 140
Short length: 20

main:

-------------------------------------------------------------------------------------------------------------
Benchmark Time CPU Iterations UserCounters...
-------------------------------------------------------------------------------------------------------------
BM_minipal_get_length_utf16_to_utf8/ASCII_Short 46.8 ns 46.3 ns 15200142 items_per_second=388.583M/s
BM_minipal_get_length_utf16_to_utf8/NonASCII_Short 49.2 ns 48.4 ns 14081759 items_per_second=288.974M/s
BM_minipal_get_length_utf16_to_utf8/ASCII_Long 48.5 ns 47.9 ns 14615732 items_per_second=2.92203G/s
BM_minipal_get_length_utf16_to_utf8/NonASCII_Long 167 ns 164 ns 4267226 items_per_second=854.207M/s
BM_minipal_convert_utf16_to_utf8/ASCII_Short 66.7 ns 65.7 ns 10535346 items_per_second=273.86M/s
BM_minipal_convert_utf16_to_utf8/NonASCII_Short 98.3 ns 97.0 ns 7215230 items_per_second=144.395M/s
BM_minipal_convert_utf16_to_utf8/ASCII_Long 135 ns 133 ns 5226338 items_per_second=1.05422G/s
BM_minipal_convert_utf16_to_utf8/NonASCII_Long 565 ns 556 ns 1261443 items_per_second=251.616M/s
BM_minipal_get_length_utf8_to_utf16/ASCII_Short 46.5 ns 45.7 ns 15311624 items_per_second=393.657M/s
BM_minipal_get_length_utf8_to_utf16/NonASCII_Short 56.6 ns 55.8 ns 12379302 items_per_second=573.563M/s
BM_minipal_get_length_utf8_to_utf16/ASCII_Long 47.7 ns 47.2 ns 15069416 items_per_second=2.96665G/s
BM_minipal_get_length_utf8_to_utf16/NonASCII_Long 118 ns 116 ns 5989100 items_per_second=1.20323G/s
BM_minipal_convert_utf8_to_utf16/ASCII_Short 61.5 ns 60.9 ns 11373792 items_per_second=295.365M/s
BM_minipal_convert_utf8_to_utf16/NonASCII_Short 126 ns 124 ns 5599462 items_per_second=257.461M/s
BM_minipal_convert_utf8_to_utf16/ASCII_Long 109 ns 108 ns 6452981 items_per_second=1.30072G/s
BM_minipal_convert_utf8_to_utf16/NonASCII_Long 260 ns 258 ns 2722687 items_per_second=542.822M/s

PR:

-------------------------------------------------------------------------------------------------------------
Benchmark Time CPU Iterations UserCounters...
-------------------------------------------------------------------------------------------------------------
BM_minipal_get_length_utf16_to_utf8/ASCII_Short 46.3 ns 46.2 ns 15294729 items_per_second=389.687M/s
BM_minipal_get_length_utf16_to_utf8/NonASCII_Short 46.7 ns 46.7 ns 15014757 items_per_second=300.068M/s
BM_minipal_get_length_utf16_to_utf8/ASCII_Long 89.1 ns 88.2 ns 7965951 items_per_second=1.58799G/s
BM_minipal_get_length_utf16_to_utf8/NonASCII_Long 167 ns 167 ns 4209817 items_per_second=840.11M/s
BM_minipal_convert_utf16_to_utf8/ASCII_Short 57.9 ns 57.8 ns 12086261 items_per_second=311.416M/s
BM_minipal_convert_utf16_to_utf8/NonASCII_Short 80.0 ns 79.9 ns 8745736 items_per_second=175.196M/s
BM_minipal_convert_utf16_to_utf8/ASCII_Long 155 ns 154 ns 4546517 items_per_second=907.604M/s
BM_minipal_convert_utf16_to_utf8/NonASCII_Long 489 ns 488 ns 1427791 items_per_second=286.914M/s
BM_minipal_get_length_utf8_to_utf16/ASCII_Short 47.9 ns 47.1 ns 14990417 items_per_second=382.482M/s
BM_minipal_get_length_utf8_to_utf16/NonASCII_Short 65.7 ns 65.6 ns 10645254 items_per_second=487.782M/s
BM_minipal_get_length_utf8_to_utf16/ASCII_Long 131 ns 130 ns 5443066 items_per_second=1.07377G/s
BM_minipal_get_length_utf8_to_utf16/NonASCII_Long 180 ns 179 ns 3938780 items_per_second=781.547M/s
BM_minipal_convert_utf8_to_utf16/ASCII_Short 73.2 ns 72.9 ns 9594561 items_per_second=246.863M/s
BM_minipal_convert_utf8_to_utf16/NonASCII_Short 109 ns 108 ns 6488872 items_per_second=296.073M/s
BM_minipal_convert_utf8_to_utf16/ASCII_Long 282 ns 281 ns 2457149 items_per_second=497.751M/s
BM_minipal_convert_utf8_to_utf16/NonASCII_Long 298 ns 296 ns 2353052 items_per_second=472.879M/s

BM_minipal_get_length_utf16_to_utf8/ASCII_Long has gotten the worse performance regression. I tried fast tracking ASCII with:

// Use vectorized operations for ASCII characterstypedefuint16_tv4ui __attribute__ ((vector_size (8)));
for (; sourceIndex<sourceLength&&destinationIndex<destinationLength; sourceIndex+=4, destinationIndex+=4)
{
v4uidata=*(v4ui*)&source[sourceIndex];
v4uimask4= (v4ui){0x007F, 0x007F, 0x007F, 0x007F};
v4uicomparison=data <= mask4;
size_tremainingLength=sourceLength-sourceIndex;
if (remainingLength>4&&__builtin_expect(comparison[0] &comparison[1] &comparison[2] &comparison[3], 1))
{
destination[destinationIndex] = (char)data[0];
destination[destinationIndex+1] = (char)data[1];
destination[destinationIndex+2] = (char)data[2];
destination[destinationIndex+3] = (char)data[3];
continue;
}
elseif (remainingLength <= 4)
{
// Handle the remaining 4 or less elements if ASCIIif (remainingLength==4) {
if (__builtin_expect(comparison[0] &comparison[1] &comparison[2] &comparison[3], 1))
{
destination[destinationIndex++] = (char)data[0];
destination[destinationIndex++] = (char)data[1];
destination[destinationIndex++] = (char)data[2];
destination[destinationIndex++] = (char)data[3];
returndestinationIndex;
}
break;
}
v4uimask3= (v4ui){0x007F, 0x007F, 0x007F};
v4uimask2= (v4ui){0x007F, 0x007F};
comparison=data <= mask3;
if (remainingLength==3) {
if( __builtin_expect(comparison[0] &comparison[1] &comparison[2], 1)) {
destination[destinationIndex++] = (char)data[0];
destination[destinationIndex++] = (char)data[1];
destination[destinationIndex++] = (char)data[2];
returndestinationIndex;
}
break;
}
comparison=data <= mask2;
if (remainingLength==2) {
if(__builtin_expect(comparison[0] &comparison[1], 1)) {
destination[destinationIndex++] = (char)data[0];
destination[destinationIndex++] = (char)data[1];
returndestinationIndex;
}
break;
}
if (source[sourceIndex] <0x80){
destination[destinationIndex++] = (char)source[sourceIndex];
returndestinationIndex;
}
}
// Break out of the outer loop here because we know it's non-ASCIIbreak;
}
// Handle non-ASCII and mixed caseswhile (sourceIndex<sourceLength&&destinationIndex<destinationLength)
{
...

but that did not move the needle (+/- 2ns diff).

Haven't given up on fine-tuning yet, but overall I think the new implementation is simple and more readable. So it's a balancing question of readability vs. performance (I'm pursuing both 🙂).

[AaronRobinsonMSFT]

@am11 I'm moving this to draft for now.

[dotnet-policy-service]

Draft Pull Request was automatically closed for 30 days of inactivity. Please let us know if you'd like to reopen it.

[am11]

diet version 🤸

[am11]

cc @AaronRobinsonMSFT, re: #100451 (comment) - this mainly reduces the assembly code with cl.exe -O2 (before 1091 lines, now 369 for minipal_convert_utf8_to_utf16). Could you please run your benchmark to see how it compares against the MultiByteToWideChar/WideCharToMultiChar win32 APIs? Hopefully it will perform better now (at least better than before 😅).

[am11]

@lambdageek, just an FYI, I had to change this condition from

if (sourceIndex < sourceLength && (destinationIndex >= destinationLength)

for mono because this case was failing:

runtime/src/libraries/System.Runtime/tests/System.Runtime.Tests/System/AttributeTests.cs

Line 169 in 2bfd1b4

Assert.NotNull(stringArg);

IMHO, the reflection stack of mono should use the same expectation from giconv about the expected lengths as coreclr's reflection stack makes from coreclr PAL's unicode.cpp, so this standalone component doesn't need to handle more edge cases than necessary.

[AaronRobinsonMSFT]

/cc @fanyang-mono

[fanyang-mono]

The test that @am11 mentioned was testing the custom attribute value string "\uDFFF". For mono, it went through minipal_convert_utf8_to_utf16 to decode this string "\xed\xbf\xbf". It seems to me that CoreCLR went through a different mechanism to get the value of the custom attribute value.

Additionally, what Mono is doing in g_utf8_to_utf16_impl of giconv.c isn't a lot different than what is done in MultiByteToWideChar of unicode.cpp. If I understand correctly, the only difference is that in MultiByteToWideChar, it makes source length and destination length one byte longer than it is. Doing this in mono won't stop this check ((sourceIndex < sourceLength) && (destinationIndex >= destinationLength)) either.

[am11]

@fanyang-mono, coreclr ultimately uses the same implementation (couple of wrappers later), but in reflection stack (metasig.h etc.), there it compensates for those off-by-one, zero-length kind of scenarios to match the expectation.

[fanyang-mono]

@am11 Do you mind pointing me to the CoreCLR source code where they handles off-by-one, zero-length kind of scenarios?

[am11]

@fanyang-mono, good question. 😅 It is a bit tricky to discern the exact place without actually attaching a conditional debugger (or some tricky way), but I was debugging the similar tests for coreclr last year #85558 (comment) which points to

runtime/src/coreclr/md/compiler/regmeta_import.cpp

Line 705 in d8c59a4

RegMeta::GetTypeDefProps(

One thing I do remember; when all PAL tests were passing and 99% of managed tests were passingm those edge cases covered in reflection tests were still failing, which is why I had to add a similar special condition in unicode.cpp -> utf8.c conversion to balance varied expectations of mono and coreclr + reflection simultaneously.

[fanyang-mono]

It is probably fine having this a little bit longer check, because to make mono align with CoreCLR on this is non-trivial work.

[AaronRobinsonMSFT]

Thanks. I will take a look.

[jkotas]

Could you please run your benchmark to see how it compares against the MultiByteToWideChar/WideCharToMultiChar win32 APIs?

int main()
{
char* p = (char*)malloc(200);
memset(p, 'a', 200);
for (;;)
{
int start = GetTickCount();
for (int i = 0; i < 10000000; i++)
#if 0
minipal_get_length_utf8_to_utf16(p, 200, 0);
#else
MultiByteToWideChar(CP_UTF8, 0, p, 200, NULL, 0);
#endif
int end = GetTickCount();
printf("%d\n", end - start);
}
}

MultiByteToWideChar: 220ms per iteration
minipal_get_length_utf8_to_utf16: 1370ms per iteration

[am11]

Ran some google benchmarks: https://gist.github.com/am11/8d949f6c112aaab1575e85f2f350c59e

Long length: 140
Short length: 20

main:

-------------------------------------------------------------------------------------------------------------
Benchmark Time CPU Iterations UserCounters...
-------------------------------------------------------------------------------------------------------------
BM_minipal_get_length_utf16_to_utf8/ASCII_Short 46.8 ns 46.3 ns 15200142 items_per_second=388.583M/s
BM_minipal_get_length_utf16_to_utf8/NonASCII_Short 49.2 ns 48.4 ns 14081759 items_per_second=288.974M/s
BM_minipal_get_length_utf16_to_utf8/ASCII_Long 48.5 ns 47.9 ns 14615732 items_per_second=2.92203G/s
BM_minipal_get_length_utf16_to_utf8/NonASCII_Long 167 ns 164 ns 4267226 items_per_second=854.207M/s
BM_minipal_convert_utf16_to_utf8/ASCII_Short 66.7 ns 65.7 ns 10535346 items_per_second=273.86M/s
BM_minipal_convert_utf16_to_utf8/NonASCII_Short 98.3 ns 97.0 ns 7215230 items_per_second=144.395M/s
BM_minipal_convert_utf16_to_utf8/ASCII_Long 135 ns 133 ns 5226338 items_per_second=1.05422G/s
BM_minipal_convert_utf16_to_utf8/NonASCII_Long 565 ns 556 ns 1261443 items_per_second=251.616M/s
BM_minipal_get_length_utf8_to_utf16/ASCII_Short 46.5 ns 45.7 ns 15311624 items_per_second=393.657M/s
BM_minipal_get_length_utf8_to_utf16/NonASCII_Short 56.6 ns 55.8 ns 12379302 items_per_second=573.563M/s
BM_minipal_get_length_utf8_to_utf16/ASCII_Long 47.7 ns 47.2 ns 15069416 items_per_second=2.96665G/s
BM_minipal_get_length_utf8_to_utf16/NonASCII_Long 118 ns 116 ns 5989100 items_per_second=1.20323G/s
BM_minipal_convert_utf8_to_utf16/ASCII_Short 61.5 ns 60.9 ns 11373792 items_per_second=295.365M/s
BM_minipal_convert_utf8_to_utf16/NonASCII_Short 126 ns 124 ns 5599462 items_per_second=257.461M/s
BM_minipal_convert_utf8_to_utf16/ASCII_Long 109 ns 108 ns 6452981 items_per_second=1.30072G/s
BM_minipal_convert_utf8_to_utf16/NonASCII_Long 260 ns 258 ns 2722687 items_per_second=542.822M/s

PR:

-------------------------------------------------------------------------------------------------------------
Benchmark Time CPU Iterations UserCounters...
-------------------------------------------------------------------------------------------------------------
BM_minipal_get_length_utf16_to_utf8/ASCII_Short 46.3 ns 46.2 ns 15294729 items_per_second=389.687M/s
BM_minipal_get_length_utf16_to_utf8/NonASCII_Short 46.7 ns 46.7 ns 15014757 items_per_second=300.068M/s
BM_minipal_get_length_utf16_to_utf8/ASCII_Long 89.1 ns 88.2 ns 7965951 items_per_second=1.58799G/s
BM_minipal_get_length_utf16_to_utf8/NonASCII_Long 167 ns 167 ns 4209817 items_per_second=840.11M/s
BM_minipal_convert_utf16_to_utf8/ASCII_Short 57.9 ns 57.8 ns 12086261 items_per_second=311.416M/s
BM_minipal_convert_utf16_to_utf8/NonASCII_Short 80.0 ns 79.9 ns 8745736 items_per_second=175.196M/s
BM_minipal_convert_utf16_to_utf8/ASCII_Long 155 ns 154 ns 4546517 items_per_second=907.604M/s
BM_minipal_convert_utf16_to_utf8/NonASCII_Long 489 ns 488 ns 1427791 items_per_second=286.914M/s
BM_minipal_get_length_utf8_to_utf16/ASCII_Short 47.9 ns 47.1 ns 14990417 items_per_second=382.482M/s
BM_minipal_get_length_utf8_to_utf16/NonASCII_Short 65.7 ns 65.6 ns 10645254 items_per_second=487.782M/s
BM_minipal_get_length_utf8_to_utf16/ASCII_Long 131 ns 130 ns 5443066 items_per_second=1.07377G/s
BM_minipal_get_length_utf8_to_utf16/NonASCII_Long 180 ns 179 ns 3938780 items_per_second=781.547M/s
BM_minipal_convert_utf8_to_utf16/ASCII_Short 73.2 ns 72.9 ns 9594561 items_per_second=246.863M/s
BM_minipal_convert_utf8_to_utf16/NonASCII_Short 109 ns 108 ns 6488872 items_per_second=296.073M/s
BM_minipal_convert_utf8_to_utf16/ASCII_Long 282 ns 281 ns 2457149 items_per_second=497.751M/s
BM_minipal_convert_utf8_to_utf16/NonASCII_Long 298 ns 296 ns 2353052 items_per_second=472.879M/s

BM_minipal_get_length_utf16_to_utf8/ASCII_Long has gotten the worse performance regression. I tried fast tracking ASCII with:

// Use vectorized operations for ASCII characterstypedefuint16_tv4ui __attribute__ ((vector_size (8)));
for (; sourceIndex<sourceLength&&destinationIndex<destinationLength; sourceIndex+=4, destinationIndex+=4)
{
v4uidata=*(v4ui*)&source[sourceIndex];
v4uimask4= (v4ui){0x007F, 0x007F, 0x007F, 0x007F};
v4uicomparison=data <= mask4;
size_tremainingLength=sourceLength-sourceIndex;
if (remainingLength>4&&__builtin_expect(comparison[0] &comparison[1] &comparison[2] &comparison[3], 1))
{
destination[destinationIndex] = (char)data[0];
destination[destinationIndex+1] = (char)data[1];
destination[destinationIndex+2] = (char)data[2];
destination[destinationIndex+3] = (char)data[3];
continue;
}
elseif (remainingLength <= 4)
{
// Handle the remaining 4 or less elements if ASCIIif (remainingLength==4) {
if (__builtin_expect(comparison[0] &comparison[1] &comparison[2] &comparison[3], 1))
{
destination[destinationIndex++] = (char)data[0];
destination[destinationIndex++] = (char)data[1];
destination[destinationIndex++] = (char)data[2];
destination[destinationIndex++] = (char)data[3];
returndestinationIndex;
}
break;
}
v4uimask3= (v4ui){0x007F, 0x007F, 0x007F};
v4uimask2= (v4ui){0x007F, 0x007F};
comparison=data <= mask3;
if (remainingLength==3) {
if( __builtin_expect(comparison[0] &comparison[1] &comparison[2], 1)) {
destination[destinationIndex++] = (char)data[0];
destination[destinationIndex++] = (char)data[1];
destination[destinationIndex++] = (char)data[2];
returndestinationIndex;
}
break;
}
comparison=data <= mask2;
if (remainingLength==2) {
if(__builtin_expect(comparison[0] &comparison[1], 1)) {
destination[destinationIndex++] = (char)data[0];
destination[destinationIndex++] = (char)data[1];
returndestinationIndex;
}
break;
}
if (source[sourceIndex] <0x80){
destination[destinationIndex++] = (char)source[sourceIndex];
returndestinationIndex;
}
}
// Break out of the outer loop here because we know it's non-ASCIIbreak;
}
// Handle non-ASCII and mixed caseswhile (sourceIndex<sourceLength&&destinationIndex<destinationLength)
{
...

but that did not move the needle (+/- 2ns diff).

Haven't given up on fine-tuning yet, but overall I think the new implementation is simple and more readable. So it's a balancing question of readability vs. performance (I'm pursuing both 🙂).

[AaronRobinsonMSFT]

@am11 I'm moving this to draft for now.

[dotnet-policy-service]

Draft Pull Request was automatically closed for 30 days of inactivity. Please let us know if you'd like to reopen it.

[am11]

diet version 🤸

[am11]

cc @AaronRobinsonMSFT, re: #100451 (comment) - this mainly reduces the assembly code with cl.exe -O2 (before 1091 lines, now 369 for minipal_convert_utf8_to_utf16). Could you please run your benchmark to see how it compares against the MultiByteToWideChar/WideCharToMultiChar win32 APIs? Hopefully it will perform better now (at least better than before 😅).

[am11]

@lambdageek, just an FYI, I had to change this condition from

if (sourceIndex < sourceLength && (destinationIndex >= destinationLength)

for mono because this case was failing:

runtime/src/libraries/System.Runtime/tests/System.Runtime.Tests/System/AttributeTests.cs

Line 169 in 2bfd1b4

Assert.NotNull(stringArg);

IMHO, the reflection stack of mono should use the same expectation from giconv about the expected lengths as coreclr's reflection stack makes from coreclr PAL's unicode.cpp, so this standalone component doesn't need to handle more edge cases than necessary.

[AaronRobinsonMSFT]

/cc @fanyang-mono

[fanyang-mono]

The test that @am11 mentioned was testing the custom attribute value string "\uDFFF". For mono, it went through minipal_convert_utf8_to_utf16 to decode this string "\xed\xbf\xbf". It seems to me that CoreCLR went through a different mechanism to get the value of the custom attribute value.

Additionally, what Mono is doing in g_utf8_to_utf16_impl of giconv.c isn't a lot different than what is done in MultiByteToWideChar of unicode.cpp. If I understand correctly, the only difference is that in MultiByteToWideChar, it makes source length and destination length one byte longer than it is. Doing this in mono won't stop this check ((sourceIndex < sourceLength) && (destinationIndex >= destinationLength)) either.

[am11]

@fanyang-mono, coreclr ultimately uses the same implementation (couple of wrappers later), but in reflection stack (metasig.h etc.), there it compensates for those off-by-one, zero-length kind of scenarios to match the expectation.

[fanyang-mono]

@am11 Do you mind pointing me to the CoreCLR source code where they handles off-by-one, zero-length kind of scenarios?

[am11]

@fanyang-mono, good question. 😅 It is a bit tricky to discern the exact place without actually attaching a conditional debugger (or some tricky way), but I was debugging the similar tests for coreclr last year #85558 (comment) which points to

runtime/src/coreclr/md/compiler/regmeta_import.cpp

Line 705 in d8c59a4

RegMeta::GetTypeDefProps(

One thing I do remember; when all PAL tests were passing and 99% of managed tests were passingm those edge cases covered in reflection tests were still failing, which is why I had to add a similar special condition in unicode.cpp -> utf8.c conversion to balance varied expectations of mono and coreclr + reflection simultaneously.

[fanyang-mono]

It is probably fine having this a little bit longer check, because to make mono align with CoreCLR on this is non-trivial work.

[AaronRobinsonMSFT]

Thanks. I will take a look.

[jkotas]

Could you please run your benchmark to see how it compares against the MultiByteToWideChar/WideCharToMultiChar win32 APIs?

int main()
{
char* p = (char*)malloc(200);
memset(p, 'a', 200);
for (;;)
{
int start = GetTickCount();
for (int i = 0; i < 10000000; i++)
#if 0
minipal_get_length_utf8_to_utf16(p, 200, 0);
#else
MultiByteToWideChar(CP_UTF8, 0, p, 200, NULL, 0);
#endif
int end = GetTickCount();
printf("%d\n", end - start);
}
}

MultiByteToWideChar: 220ms per iteration
minipal_get_length_utf8_to_utf16: 1370ms per iteration

[am11]

Ran some google benchmarks: https://gist.github.com/am11/8d949f6c112aaab1575e85f2f350c59e

Long length: 140
Short length: 20

main:

-------------------------------------------------------------------------------------------------------------
Benchmark Time CPU Iterations UserCounters...
-------------------------------------------------------------------------------------------------------------
BM_minipal_get_length_utf16_to_utf8/ASCII_Short 46.8 ns 46.3 ns 15200142 items_per_second=388.583M/s
BM_minipal_get_length_utf16_to_utf8/NonASCII_Short 49.2 ns 48.4 ns 14081759 items_per_second=288.974M/s
BM_minipal_get_length_utf16_to_utf8/ASCII_Long 48.5 ns 47.9 ns 14615732 items_per_second=2.92203G/s
BM_minipal_get_length_utf16_to_utf8/NonASCII_Long 167 ns 164 ns 4267226 items_per_second=854.207M/s
BM_minipal_convert_utf16_to_utf8/ASCII_Short 66.7 ns 65.7 ns 10535346 items_per_second=273.86M/s
BM_minipal_convert_utf16_to_utf8/NonASCII_Short 98.3 ns 97.0 ns 7215230 items_per_second=144.395M/s
BM_minipal_convert_utf16_to_utf8/ASCII_Long 135 ns 133 ns 5226338 items_per_second=1.05422G/s
BM_minipal_convert_utf16_to_utf8/NonASCII_Long 565 ns 556 ns 1261443 items_per_second=251.616M/s
BM_minipal_get_length_utf8_to_utf16/ASCII_Short 46.5 ns 45.7 ns 15311624 items_per_second=393.657M/s
BM_minipal_get_length_utf8_to_utf16/NonASCII_Short 56.6 ns 55.8 ns 12379302 items_per_second=573.563M/s
BM_minipal_get_length_utf8_to_utf16/ASCII_Long 47.7 ns 47.2 ns 15069416 items_per_second=2.96665G/s
BM_minipal_get_length_utf8_to_utf16/NonASCII_Long 118 ns 116 ns 5989100 items_per_second=1.20323G/s
BM_minipal_convert_utf8_to_utf16/ASCII_Short 61.5 ns 60.9 ns 11373792 items_per_second=295.365M/s
BM_minipal_convert_utf8_to_utf16/NonASCII_Short 126 ns 124 ns 5599462 items_per_second=257.461M/s
BM_minipal_convert_utf8_to_utf16/ASCII_Long 109 ns 108 ns 6452981 items_per_second=1.30072G/s
BM_minipal_convert_utf8_to_utf16/NonASCII_Long 260 ns 258 ns 2722687 items_per_second=542.822M/s

PR:

-------------------------------------------------------------------------------------------------------------
Benchmark Time CPU Iterations UserCounters...
-------------------------------------------------------------------------------------------------------------
BM_minipal_get_length_utf16_to_utf8/ASCII_Short 46.3 ns 46.2 ns 15294729 items_per_second=389.687M/s
BM_minipal_get_length_utf16_to_utf8/NonASCII_Short 46.7 ns 46.7 ns 15014757 items_per_second=300.068M/s
BM_minipal_get_length_utf16_to_utf8/ASCII_Long 89.1 ns 88.2 ns 7965951 items_per_second=1.58799G/s
BM_minipal_get_length_utf16_to_utf8/NonASCII_Long 167 ns 167 ns 4209817 items_per_second=840.11M/s
BM_minipal_convert_utf16_to_utf8/ASCII_Short 57.9 ns 57.8 ns 12086261 items_per_second=311.416M/s
BM_minipal_convert_utf16_to_utf8/NonASCII_Short 80.0 ns 79.9 ns 8745736 items_per_second=175.196M/s
BM_minipal_convert_utf16_to_utf8/ASCII_Long 155 ns 154 ns 4546517 items_per_second=907.604M/s
BM_minipal_convert_utf16_to_utf8/NonASCII_Long 489 ns 488 ns 1427791 items_per_second=286.914M/s
BM_minipal_get_length_utf8_to_utf16/ASCII_Short 47.9 ns 47.1 ns 14990417 items_per_second=382.482M/s
BM_minipal_get_length_utf8_to_utf16/NonASCII_Short 65.7 ns 65.6 ns 10645254 items_per_second=487.782M/s
BM_minipal_get_length_utf8_to_utf16/ASCII_Long 131 ns 130 ns 5443066 items_per_second=1.07377G/s
BM_minipal_get_length_utf8_to_utf16/NonASCII_Long 180 ns 179 ns 3938780 items_per_second=781.547M/s
BM_minipal_convert_utf8_to_utf16/ASCII_Short 73.2 ns 72.9 ns 9594561 items_per_second=246.863M/s
BM_minipal_convert_utf8_to_utf16/NonASCII_Short 109 ns 108 ns 6488872 items_per_second=296.073M/s
BM_minipal_convert_utf8_to_utf16/ASCII_Long 282 ns 281 ns 2457149 items_per_second=497.751M/s
BM_minipal_convert_utf8_to_utf16/NonASCII_Long 298 ns 296 ns 2353052 items_per_second=472.879M/s

BM_minipal_get_length_utf16_to_utf8/ASCII_Long has gotten the worse performance regression. I tried fast tracking ASCII with:

// Use vectorized operations for ASCII characterstypedefuint16_tv4ui __attribute__ ((vector_size (8)));
for (; sourceIndex<sourceLength&&destinationIndex<destinationLength; sourceIndex+=4, destinationIndex+=4)
{
v4uidata=*(v4ui*)&source[sourceIndex];
v4uimask4= (v4ui){0x007F, 0x007F, 0x007F, 0x007F};
v4uicomparison=data <= mask4;
size_tremainingLength=sourceLength-sourceIndex;
if (remainingLength>4&&__builtin_expect(comparison[0] &comparison[1] &comparison[2] &comparison[3], 1))
{
destination[destinationIndex] = (char)data[0];
destination[destinationIndex+1] = (char)data[1];
destination[destinationIndex+2] = (char)data[2];
destination[destinationIndex+3] = (char)data[3];
continue;
}
elseif (remainingLength <= 4)
{
// Handle the remaining 4 or less elements if ASCIIif (remainingLength==4) {
if (__builtin_expect(comparison[0] &comparison[1] &comparison[2] &comparison[3], 1))
{
destination[destinationIndex++] = (char)data[0];
destination[destinationIndex++] = (char)data[1];
destination[destinationIndex++] = (char)data[2];
destination[destinationIndex++] = (char)data[3];
returndestinationIndex;
}
break;
}
v4uimask3= (v4ui){0x007F, 0x007F, 0x007F};
v4uimask2= (v4ui){0x007F, 0x007F};
comparison=data <= mask3;
if (remainingLength==3) {
if( __builtin_expect(comparison[0] &comparison[1] &comparison[2], 1)) {
destination[destinationIndex++] = (char)data[0];
destination[destinationIndex++] = (char)data[1];
destination[destinationIndex++] = (char)data[2];
returndestinationIndex;
}
break;
}
comparison=data <= mask2;
if (remainingLength==2) {
if(__builtin_expect(comparison[0] &comparison[1], 1)) {
destination[destinationIndex++] = (char)data[0];
destination[destinationIndex++] = (char)data[1];
returndestinationIndex;
}
break;
}
if (source[sourceIndex] <0x80){
destination[destinationIndex++] = (char)source[sourceIndex];
returndestinationIndex;
}
}
// Break out of the outer loop here because we know it's non-ASCIIbreak;
}
// Handle non-ASCII and mixed caseswhile (sourceIndex<sourceLength&&destinationIndex<destinationLength)
{
...

but that did not move the needle (+/- 2ns diff).

Haven't given up on fine-tuning yet, but overall I think the new implementation is simple and more readable. So it's a balancing question of readability vs. performance (I'm pursuing both 🙂).

[AaronRobinsonMSFT]

@am11 I'm moving this to draft for now.

[dotnet-policy-service]

Draft Pull Request was automatically closed for 30 days of inactivity. Please let us know if you'd like to reopen it.