Fix "Cleanup some string operating functions" PR

[AaronRobinsonMSFT]

Unrevert #96099

The revert of #96099 was done in #97264. Commits after the first fix troublesome locations.

See #97264 for details on what the original PR impacted.

/cc @tommcdon@hoyosjs@huoyaoyuan

[dotnet-policy-service]

Tagging subscribers to this area: @mangod9
See info in area-owners.md if you want to be subscribed.

[jkotas]

I assume that this used FString::Unicode_Utf8_Length to avoid some perf problems in WszWideCharToMultiByte. Is switching to WszWideCharToMultiByte going to introduce performance regression? (I am particularly worried about Windows.)

[AaronRobinsonMSFT]

I will check here.

Regardless, in principle I would prefer to defer to system APIs that we can/should assume are optimized. Having these narrowly defined "optimizations" is a non-trivial tax for an already covoluted space like SString.

[jkotas]

I agree that we should get rid of FString::*. We may want to replace it with a call to the minipal UTF8 methods for perf reasons like what the original change tried to do. I would expect that minipal UTF8 convertors are going to have significantly better perf than Windows OS WideCharToMultiByte.

system APIs that we can/should assume are optimized

Historically, Windows OS WideCharToMultiByte has been significantly slower for UTF8 than one would expect from a reasonably optimized implementation.

[MichalPetryka]

Would static linking simdutf to the VM for such conversions make sense here?

[AaronRobinsonMSFT]

We may want to replace it with a call to the minipal UTF8 methods for perf reasons like what the original change tried to do.

So that I can get behind. There is a small performance regression here. Let me replace this with the minipal APIs. I chose this direction to match the other API. I'd prefer symmetrical API usage in this case as it avoids confusion.

Would static linking simdutf to the VM for such conversions make sense here?

That is something we can discuss, but it not for this PR.

[AaronRobinsonMSFT]

we can push the hotpaths to managed

That seems unlikely in this case. The use of SString is litered throughout the system and there are many places where it is going to be unnatural and difficult to call into managed code. We can try jumping out in some cases, but that isn't something I am inclined to do in this PR.

[jkotas]

My bar for these types of changes is to avoid perf regressions. (Of course, perf improvements are nice - but it is better to evaluate them separately if they come with tradeoffs.)

Neither the existing FString fast path code nor the WideCharToMultiByte implementation built into Windows use any vectorization tricks. It suggests that we should not need vectorization tricks to avoid the perf regression here.

[jkotas]

The shape of the code in WideCharToMultiByte built into Windows is actually very similar to the corefx implementation and the minipal. It seems that the minipal implementation picked up some cruft alone the way that makes it quite a bit slower.

[am11]

It is interesting that we picked up minipal implementation for Windows + Unix in mono (and Unix in coreclr as before) in .NET 8 and haven't seen any report of regression. Maybe there is some low-hanging alignment issue which can be tweaked via cl switch?

[jkotas]

picked up minipal implementation for Windows + Unix in mono

Mono does not get as much perf scrutiny as CoreCLR.

low-hanging alignment issue

I do not think it is that.

From a cursory look, I see two problems:

• For smaller lengths, there is a fixed overhead. Adding a simple FString-like loop that deals with small ASCII-only strings as the first thing in the minipal_* methods should fix that.
• For longer lengths, the code of the core look does not look great (e.g. it uses more registers than necessary). For example, it may help to change

  runtime/src/native/minipal/utf8.c

  Lines 1613 to 1618 in 7b18be5

  	*pTarget= (unsigned char)ch;
  	*(pTarget+1) = (unsigned char)(ch >> 16);
  	pSrc+=4;
  	*(pTarget+2) = (unsigned char)chc;
  	*(pTarget+3) = (unsigned char)(chc >> 16);
  	pTarget+=4;

  to

 *pTarget = (unsigned char)ch;
*(pTarget + 2) = (unsigned char)(chc);
pSrc += 4;
*(pTarget + 1) = (unsigned char)(ch >> 16);
*(pTarget + 3) = (unsigned char)(chc >> 16);
pTarget += 4;

[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.

[AaronRobinsonMSFT]

Unrevert #96099

The revert of #96099 was done in #97264. Commits after the first fix troublesome locations.

See #97264 for details on what the original PR impacted.

/cc @tommcdon@hoyosjs@huoyaoyuan

[dotnet-policy-service]

Tagging subscribers to this area: @mangod9
See info in area-owners.md if you want to be subscribed.

[jkotas]

I assume that this used FString::Unicode_Utf8_Length to avoid some perf problems in WszWideCharToMultiByte. Is switching to WszWideCharToMultiByte going to introduce performance regression? (I am particularly worried about Windows.)

[AaronRobinsonMSFT]

I will check here.

Regardless, in principle I would prefer to defer to system APIs that we can/should assume are optimized. Having these narrowly defined "optimizations" is a non-trivial tax for an already covoluted space like SString.

[jkotas]

I agree that we should get rid of FString::*. We may want to replace it with a call to the minipal UTF8 methods for perf reasons like what the original change tried to do. I would expect that minipal UTF8 convertors are going to have significantly better perf than Windows OS WideCharToMultiByte.

system APIs that we can/should assume are optimized

Historically, Windows OS WideCharToMultiByte has been significantly slower for UTF8 than one would expect from a reasonably optimized implementation.

[MichalPetryka]

Would static linking simdutf to the VM for such conversions make sense here?

[AaronRobinsonMSFT]

We may want to replace it with a call to the minipal UTF8 methods for perf reasons like what the original change tried to do.

So that I can get behind. There is a small performance regression here. Let me replace this with the minipal APIs. I chose this direction to match the other API. I'd prefer symmetrical API usage in this case as it avoids confusion.

Would static linking simdutf to the VM for such conversions make sense here?

That is something we can discuss, but it not for this PR.

[AaronRobinsonMSFT]

we can push the hotpaths to managed

That seems unlikely in this case. The use of SString is litered throughout the system and there are many places where it is going to be unnatural and difficult to call into managed code. We can try jumping out in some cases, but that isn't something I am inclined to do in this PR.

[jkotas]

My bar for these types of changes is to avoid perf regressions. (Of course, perf improvements are nice - but it is better to evaluate them separately if they come with tradeoffs.)

Neither the existing FString fast path code nor the WideCharToMultiByte implementation built into Windows use any vectorization tricks. It suggests that we should not need vectorization tricks to avoid the perf regression here.

[jkotas]

The shape of the code in WideCharToMultiByte built into Windows is actually very similar to the corefx implementation and the minipal. It seems that the minipal implementation picked up some cruft alone the way that makes it quite a bit slower.

[am11]

It is interesting that we picked up minipal implementation for Windows + Unix in mono (and Unix in coreclr as before) in .NET 8 and haven't seen any report of regression. Maybe there is some low-hanging alignment issue which can be tweaked via cl switch?

[jkotas]

picked up minipal implementation for Windows + Unix in mono

Mono does not get as much perf scrutiny as CoreCLR.

low-hanging alignment issue

I do not think it is that.

From a cursory look, I see two problems:

• For smaller lengths, there is a fixed overhead. Adding a simple FString-like loop that deals with small ASCII-only strings as the first thing in the minipal_* methods should fix that.
• For longer lengths, the code of the core look does not look great (e.g. it uses more registers than necessary). For example, it may help to change

  runtime/src/native/minipal/utf8.c

  Lines 1613 to 1618 in 7b18be5

  	*pTarget= (unsigned char)ch;
  	*(pTarget+1) = (unsigned char)(ch >> 16);
  	pSrc+=4;
  	*(pTarget+2) = (unsigned char)chc;
  	*(pTarget+3) = (unsigned char)(chc >> 16);
  	pTarget+=4;

  to

 *pTarget = (unsigned char)ch;
*(pTarget + 2) = (unsigned char)(chc);
pSrc += 4;
*(pTarget + 1) = (unsigned char)(ch >> 16);
*(pTarget + 3) = (unsigned char)(chc >> 16);
pTarget += 4;

[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.

[AaronRobinsonMSFT]

Unrevert #96099

The revert of #96099 was done in #97264. Commits after the first fix troublesome locations.

See #97264 for details on what the original PR impacted.

/cc @tommcdon@hoyosjs@huoyaoyuan

[dotnet-policy-service]

Tagging subscribers to this area: @mangod9
See info in area-owners.md if you want to be subscribed.

[jkotas]

I assume that this used FString::Unicode_Utf8_Length to avoid some perf problems in WszWideCharToMultiByte. Is switching to WszWideCharToMultiByte going to introduce performance regression? (I am particularly worried about Windows.)

[AaronRobinsonMSFT]

I will check here.

Regardless, in principle I would prefer to defer to system APIs that we can/should assume are optimized. Having these narrowly defined "optimizations" is a non-trivial tax for an already covoluted space like SString.

[jkotas]

I agree that we should get rid of FString::*. We may want to replace it with a call to the minipal UTF8 methods for perf reasons like what the original change tried to do. I would expect that minipal UTF8 convertors are going to have significantly better perf than Windows OS WideCharToMultiByte.

system APIs that we can/should assume are optimized

Historically, Windows OS WideCharToMultiByte has been significantly slower for UTF8 than one would expect from a reasonably optimized implementation.

[MichalPetryka]

Would static linking simdutf to the VM for such conversions make sense here?

[AaronRobinsonMSFT]

We may want to replace it with a call to the minipal UTF8 methods for perf reasons like what the original change tried to do.

So that I can get behind. There is a small performance regression here. Let me replace this with the minipal APIs. I chose this direction to match the other API. I'd prefer symmetrical API usage in this case as it avoids confusion.

Would static linking simdutf to the VM for such conversions make sense here?

That is something we can discuss, but it not for this PR.

[AaronRobinsonMSFT]

we can push the hotpaths to managed

That seems unlikely in this case. The use of SString is litered throughout the system and there are many places where it is going to be unnatural and difficult to call into managed code. We can try jumping out in some cases, but that isn't something I am inclined to do in this PR.

[jkotas]

My bar for these types of changes is to avoid perf regressions. (Of course, perf improvements are nice - but it is better to evaluate them separately if they come with tradeoffs.)

Neither the existing FString fast path code nor the WideCharToMultiByte implementation built into Windows use any vectorization tricks. It suggests that we should not need vectorization tricks to avoid the perf regression here.

[jkotas]

The shape of the code in WideCharToMultiByte built into Windows is actually very similar to the corefx implementation and the minipal. It seems that the minipal implementation picked up some cruft alone the way that makes it quite a bit slower.

[am11]

It is interesting that we picked up minipal implementation for Windows + Unix in mono (and Unix in coreclr as before) in .NET 8 and haven't seen any report of regression. Maybe there is some low-hanging alignment issue which can be tweaked via cl switch?

[jkotas]

picked up minipal implementation for Windows + Unix in mono

Mono does not get as much perf scrutiny as CoreCLR.

low-hanging alignment issue

I do not think it is that.

From a cursory look, I see two problems:

• For smaller lengths, there is a fixed overhead. Adding a simple FString-like loop that deals with small ASCII-only strings as the first thing in the minipal_* methods should fix that.
• For longer lengths, the code of the core look does not look great (e.g. it uses more registers than necessary). For example, it may help to change

  runtime/src/native/minipal/utf8.c

  Lines 1613 to 1618 in 7b18be5

  	*pTarget= (unsigned char)ch;
  	*(pTarget+1) = (unsigned char)(ch >> 16);
  	pSrc+=4;
  	*(pTarget+2) = (unsigned char)chc;
  	*(pTarget+3) = (unsigned char)(chc >> 16);
  	pTarget+=4;

  to

 *pTarget = (unsigned char)ch;
*(pTarget + 2) = (unsigned char)(chc);
pSrc += 4;
*(pTarget + 1) = (unsigned char)(ch >> 16);
*(pTarget + 3) = (unsigned char)(chc >> 16);
pTarget += 4;

[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.

[AaronRobinsonMSFT]

Unrevert #96099

The revert of #96099 was done in #97264. Commits after the first fix troublesome locations.

See #97264 for details on what the original PR impacted.

/cc @tommcdon@hoyosjs@huoyaoyuan

[dotnet-policy-service]

Tagging subscribers to this area: @mangod9
See info in area-owners.md if you want to be subscribed.

[jkotas]

I assume that this used FString::Unicode_Utf8_Length to avoid some perf problems in WszWideCharToMultiByte. Is switching to WszWideCharToMultiByte going to introduce performance regression? (I am particularly worried about Windows.)

[AaronRobinsonMSFT]

I will check here.

Regardless, in principle I would prefer to defer to system APIs that we can/should assume are optimized. Having these narrowly defined "optimizations" is a non-trivial tax for an already covoluted space like SString.

[jkotas]

I agree that we should get rid of FString::*. We may want to replace it with a call to the minipal UTF8 methods for perf reasons like what the original change tried to do. I would expect that minipal UTF8 convertors are going to have significantly better perf than Windows OS WideCharToMultiByte.

system APIs that we can/should assume are optimized

Historically, Windows OS WideCharToMultiByte has been significantly slower for UTF8 than one would expect from a reasonably optimized implementation.

[MichalPetryka]

Would static linking simdutf to the VM for such conversions make sense here?

[AaronRobinsonMSFT]

We may want to replace it with a call to the minipal UTF8 methods for perf reasons like what the original change tried to do.

So that I can get behind. There is a small performance regression here. Let me replace this with the minipal APIs. I chose this direction to match the other API. I'd prefer symmetrical API usage in this case as it avoids confusion.

Would static linking simdutf to the VM for such conversions make sense here?

That is something we can discuss, but it not for this PR.

[AaronRobinsonMSFT]

we can push the hotpaths to managed

That seems unlikely in this case. The use of SString is litered throughout the system and there are many places where it is going to be unnatural and difficult to call into managed code. We can try jumping out in some cases, but that isn't something I am inclined to do in this PR.

[jkotas]

My bar for these types of changes is to avoid perf regressions. (Of course, perf improvements are nice - but it is better to evaluate them separately if they come with tradeoffs.)

Neither the existing FString fast path code nor the WideCharToMultiByte implementation built into Windows use any vectorization tricks. It suggests that we should not need vectorization tricks to avoid the perf regression here.

[jkotas]

The shape of the code in WideCharToMultiByte built into Windows is actually very similar to the corefx implementation and the minipal. It seems that the minipal implementation picked up some cruft alone the way that makes it quite a bit slower.

[am11]

It is interesting that we picked up minipal implementation for Windows + Unix in mono (and Unix in coreclr as before) in .NET 8 and haven't seen any report of regression. Maybe there is some low-hanging alignment issue which can be tweaked via cl switch?

[jkotas]

picked up minipal implementation for Windows + Unix in mono

Mono does not get as much perf scrutiny as CoreCLR.

low-hanging alignment issue

I do not think it is that.

From a cursory look, I see two problems:

• For smaller lengths, there is a fixed overhead. Adding a simple FString-like loop that deals with small ASCII-only strings as the first thing in the minipal_* methods should fix that.
• For longer lengths, the code of the core look does not look great (e.g. it uses more registers than necessary). For example, it may help to change

  runtime/src/native/minipal/utf8.c

  Lines 1613 to 1618 in 7b18be5

  	*pTarget= (unsigned char)ch;
  	*(pTarget+1) = (unsigned char)(ch >> 16);
  	pSrc+=4;
  	*(pTarget+2) = (unsigned char)chc;
  	*(pTarget+3) = (unsigned char)(chc >> 16);
  	pTarget+=4;

  to

 *pTarget = (unsigned char)ch;
*(pTarget + 2) = (unsigned char)(chc);
pSrc += 4;
*(pTarget + 1) = (unsigned char)(ch >> 16);
*(pTarget + 3) = (unsigned char)(chc >> 16);
pTarget += 4;

[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.

[AaronRobinsonMSFT]

Unrevert #96099

The revert of #96099 was done in #97264. Commits after the first fix troublesome locations.

See #97264 for details on what the original PR impacted.

/cc @tommcdon@hoyosjs@huoyaoyuan

[dotnet-policy-service]

Tagging subscribers to this area: @mangod9
See info in area-owners.md if you want to be subscribed.

[jkotas]

I assume that this used FString::Unicode_Utf8_Length to avoid some perf problems in WszWideCharToMultiByte. Is switching to WszWideCharToMultiByte going to introduce performance regression? (I am particularly worried about Windows.)

[AaronRobinsonMSFT]

I will check here.

Regardless, in principle I would prefer to defer to system APIs that we can/should assume are optimized. Having these narrowly defined "optimizations" is a non-trivial tax for an already covoluted space like SString.

[jkotas]

I agree that we should get rid of FString::*. We may want to replace it with a call to the minipal UTF8 methods for perf reasons like what the original change tried to do. I would expect that minipal UTF8 convertors are going to have significantly better perf than Windows OS WideCharToMultiByte.

system APIs that we can/should assume are optimized

Historically, Windows OS WideCharToMultiByte has been significantly slower for UTF8 than one would expect from a reasonably optimized implementation.

[MichalPetryka]

Would static linking simdutf to the VM for such conversions make sense here?

[AaronRobinsonMSFT]

We may want to replace it with a call to the minipal UTF8 methods for perf reasons like what the original change tried to do.

So that I can get behind. There is a small performance regression here. Let me replace this with the minipal APIs. I chose this direction to match the other API. I'd prefer symmetrical API usage in this case as it avoids confusion.

Would static linking simdutf to the VM for such conversions make sense here?

That is something we can discuss, but it not for this PR.

[AaronRobinsonMSFT]

we can push the hotpaths to managed

That seems unlikely in this case. The use of SString is litered throughout the system and there are many places where it is going to be unnatural and difficult to call into managed code. We can try jumping out in some cases, but that isn't something I am inclined to do in this PR.

[jkotas]

My bar for these types of changes is to avoid perf regressions. (Of course, perf improvements are nice - but it is better to evaluate them separately if they come with tradeoffs.)

Neither the existing FString fast path code nor the WideCharToMultiByte implementation built into Windows use any vectorization tricks. It suggests that we should not need vectorization tricks to avoid the perf regression here.

[jkotas]

The shape of the code in WideCharToMultiByte built into Windows is actually very similar to the corefx implementation and the minipal. It seems that the minipal implementation picked up some cruft alone the way that makes it quite a bit slower.

[am11]

It is interesting that we picked up minipal implementation for Windows + Unix in mono (and Unix in coreclr as before) in .NET 8 and haven't seen any report of regression. Maybe there is some low-hanging alignment issue which can be tweaked via cl switch?

[jkotas]

picked up minipal implementation for Windows + Unix in mono

Mono does not get as much perf scrutiny as CoreCLR.

low-hanging alignment issue

I do not think it is that.

From a cursory look, I see two problems:

• For smaller lengths, there is a fixed overhead. Adding a simple FString-like loop that deals with small ASCII-only strings as the first thing in the minipal_* methods should fix that.
• For longer lengths, the code of the core look does not look great (e.g. it uses more registers than necessary). For example, it may help to change

  runtime/src/native/minipal/utf8.c

  Lines 1613 to 1618 in 7b18be5

  	*pTarget= (unsigned char)ch;
  	*(pTarget+1) = (unsigned char)(ch >> 16);
  	pSrc+=4;
  	*(pTarget+2) = (unsigned char)chc;
  	*(pTarget+3) = (unsigned char)(chc >> 16);
  	pTarget+=4;

  to

 *pTarget = (unsigned char)ch;
*(pTarget + 2) = (unsigned char)(chc);
pSrc += 4;
*(pTarget + 1) = (unsigned char)(ch >> 16);
*(pTarget + 3) = (unsigned char)(chc >> 16);
pTarget += 4;

[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.

[AaronRobinsonMSFT]

Unrevert #96099

The revert of #96099 was done in #97264. Commits after the first fix troublesome locations.

See #97264 for details on what the original PR impacted.

/cc @tommcdon@hoyosjs@huoyaoyuan

[dotnet-policy-service]

Tagging subscribers to this area: @mangod9
See info in area-owners.md if you want to be subscribed.

[jkotas]

I assume that this used FString::Unicode_Utf8_Length to avoid some perf problems in WszWideCharToMultiByte. Is switching to WszWideCharToMultiByte going to introduce performance regression? (I am particularly worried about Windows.)

[AaronRobinsonMSFT]

I will check here.

Regardless, in principle I would prefer to defer to system APIs that we can/should assume are optimized. Having these narrowly defined "optimizations" is a non-trivial tax for an already covoluted space like SString.

[jkotas]

I agree that we should get rid of FString::*. We may want to replace it with a call to the minipal UTF8 methods for perf reasons like what the original change tried to do. I would expect that minipal UTF8 convertors are going to have significantly better perf than Windows OS WideCharToMultiByte.

system APIs that we can/should assume are optimized

Historically, Windows OS WideCharToMultiByte has been significantly slower for UTF8 than one would expect from a reasonably optimized implementation.

[MichalPetryka]

Would static linking simdutf to the VM for such conversions make sense here?

[AaronRobinsonMSFT]

We may want to replace it with a call to the minipal UTF8 methods for perf reasons like what the original change tried to do.

So that I can get behind. There is a small performance regression here. Let me replace this with the minipal APIs. I chose this direction to match the other API. I'd prefer symmetrical API usage in this case as it avoids confusion.

Would static linking simdutf to the VM for such conversions make sense here?

That is something we can discuss, but it not for this PR.

[AaronRobinsonMSFT]

we can push the hotpaths to managed

That seems unlikely in this case. The use of SString is litered throughout the system and there are many places where it is going to be unnatural and difficult to call into managed code. We can try jumping out in some cases, but that isn't something I am inclined to do in this PR.

[jkotas]

My bar for these types of changes is to avoid perf regressions. (Of course, perf improvements are nice - but it is better to evaluate them separately if they come with tradeoffs.)

Neither the existing FString fast path code nor the WideCharToMultiByte implementation built into Windows use any vectorization tricks. It suggests that we should not need vectorization tricks to avoid the perf regression here.

[jkotas]

The shape of the code in WideCharToMultiByte built into Windows is actually very similar to the corefx implementation and the minipal. It seems that the minipal implementation picked up some cruft alone the way that makes it quite a bit slower.

[am11]

It is interesting that we picked up minipal implementation for Windows + Unix in mono (and Unix in coreclr as before) in .NET 8 and haven't seen any report of regression. Maybe there is some low-hanging alignment issue which can be tweaked via cl switch?

[jkotas]

picked up minipal implementation for Windows + Unix in mono

Mono does not get as much perf scrutiny as CoreCLR.

low-hanging alignment issue

I do not think it is that.

From a cursory look, I see two problems:

• For smaller lengths, there is a fixed overhead. Adding a simple FString-like loop that deals with small ASCII-only strings as the first thing in the minipal_* methods should fix that.
• For longer lengths, the code of the core look does not look great (e.g. it uses more registers than necessary). For example, it may help to change

  runtime/src/native/minipal/utf8.c

  Lines 1613 to 1618 in 7b18be5

  	*pTarget= (unsigned char)ch;
  	*(pTarget+1) = (unsigned char)(ch >> 16);
  	pSrc+=4;
  	*(pTarget+2) = (unsigned char)chc;
  	*(pTarget+3) = (unsigned char)(chc >> 16);
  	pTarget+=4;

  to

 *pTarget = (unsigned char)ch;
*(pTarget + 2) = (unsigned char)(chc);
pSrc += 4;
*(pTarget + 1) = (unsigned char)(ch >> 16);
*(pTarget + 3) = (unsigned char)(chc >> 16);
pTarget += 4;

[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.

[AaronRobinsonMSFT]

Unrevert #96099

The revert of #96099 was done in #97264. Commits after the first fix troublesome locations.

See #97264 for details on what the original PR impacted.

/cc @tommcdon@hoyosjs@huoyaoyuan

[dotnet-policy-service]

Tagging subscribers to this area: @mangod9
See info in area-owners.md if you want to be subscribed.

[jkotas]

I assume that this used FString::Unicode_Utf8_Length to avoid some perf problems in WszWideCharToMultiByte. Is switching to WszWideCharToMultiByte going to introduce performance regression? (I am particularly worried about Windows.)

[AaronRobinsonMSFT]

I will check here.

Regardless, in principle I would prefer to defer to system APIs that we can/should assume are optimized. Having these narrowly defined "optimizations" is a non-trivial tax for an already covoluted space like SString.

[jkotas]

I agree that we should get rid of FString::*. We may want to replace it with a call to the minipal UTF8 methods for perf reasons like what the original change tried to do. I would expect that minipal UTF8 convertors are going to have significantly better perf than Windows OS WideCharToMultiByte.

system APIs that we can/should assume are optimized

Historically, Windows OS WideCharToMultiByte has been significantly slower for UTF8 than one would expect from a reasonably optimized implementation.

[MichalPetryka]

Would static linking simdutf to the VM for such conversions make sense here?

[AaronRobinsonMSFT]

We may want to replace it with a call to the minipal UTF8 methods for perf reasons like what the original change tried to do.

So that I can get behind. There is a small performance regression here. Let me replace this with the minipal APIs. I chose this direction to match the other API. I'd prefer symmetrical API usage in this case as it avoids confusion.

Would static linking simdutf to the VM for such conversions make sense here?

That is something we can discuss, but it not for this PR.

[AaronRobinsonMSFT]

we can push the hotpaths to managed

That seems unlikely in this case. The use of SString is litered throughout the system and there are many places where it is going to be unnatural and difficult to call into managed code. We can try jumping out in some cases, but that isn't something I am inclined to do in this PR.

[jkotas]

My bar for these types of changes is to avoid perf regressions. (Of course, perf improvements are nice - but it is better to evaluate them separately if they come with tradeoffs.)

Neither the existing FString fast path code nor the WideCharToMultiByte implementation built into Windows use any vectorization tricks. It suggests that we should not need vectorization tricks to avoid the perf regression here.

[jkotas]

The shape of the code in WideCharToMultiByte built into Windows is actually very similar to the corefx implementation and the minipal. It seems that the minipal implementation picked up some cruft alone the way that makes it quite a bit slower.

[am11]

It is interesting that we picked up minipal implementation for Windows + Unix in mono (and Unix in coreclr as before) in .NET 8 and haven't seen any report of regression. Maybe there is some low-hanging alignment issue which can be tweaked via cl switch?

[jkotas]

picked up minipal implementation for Windows + Unix in mono

Mono does not get as much perf scrutiny as CoreCLR.

low-hanging alignment issue

I do not think it is that.

From a cursory look, I see two problems:

• For smaller lengths, there is a fixed overhead. Adding a simple FString-like loop that deals with small ASCII-only strings as the first thing in the minipal_* methods should fix that.
• For longer lengths, the code of the core look does not look great (e.g. it uses more registers than necessary). For example, it may help to change

  runtime/src/native/minipal/utf8.c

  Lines 1613 to 1618 in 7b18be5

  	*pTarget= (unsigned char)ch;
  	*(pTarget+1) = (unsigned char)(ch >> 16);
  	pSrc+=4;
  	*(pTarget+2) = (unsigned char)chc;
  	*(pTarget+3) = (unsigned char)(chc >> 16);
  	pTarget+=4;

  to

 *pTarget = (unsigned char)ch;
*(pTarget + 2) = (unsigned char)(chc);
pSrc += 4;
*(pTarget + 1) = (unsigned char)(ch >> 16);
*(pTarget + 3) = (unsigned char)(chc >> 16);
pTarget += 4;

[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.

[AaronRobinsonMSFT]

Unrevert #96099

The revert of #96099 was done in #97264. Commits after the first fix troublesome locations.

See #97264 for details on what the original PR impacted.

/cc @tommcdon@hoyosjs@huoyaoyuan

[dotnet-policy-service]

Tagging subscribers to this area: @mangod9
See info in area-owners.md if you want to be subscribed.

[jkotas]

I assume that this used FString::Unicode_Utf8_Length to avoid some perf problems in WszWideCharToMultiByte. Is switching to WszWideCharToMultiByte going to introduce performance regression? (I am particularly worried about Windows.)

[AaronRobinsonMSFT]

I will check here.

Regardless, in principle I would prefer to defer to system APIs that we can/should assume are optimized. Having these narrowly defined "optimizations" is a non-trivial tax for an already covoluted space like SString.

[jkotas]

I agree that we should get rid of FString::*. We may want to replace it with a call to the minipal UTF8 methods for perf reasons like what the original change tried to do. I would expect that minipal UTF8 convertors are going to have significantly better perf than Windows OS WideCharToMultiByte.

system APIs that we can/should assume are optimized

Historically, Windows OS WideCharToMultiByte has been significantly slower for UTF8 than one would expect from a reasonably optimized implementation.

[MichalPetryka]

Would static linking simdutf to the VM for such conversions make sense here?

[AaronRobinsonMSFT]

We may want to replace it with a call to the minipal UTF8 methods for perf reasons like what the original change tried to do.

So that I can get behind. There is a small performance regression here. Let me replace this with the minipal APIs. I chose this direction to match the other API. I'd prefer symmetrical API usage in this case as it avoids confusion.

Would static linking simdutf to the VM for such conversions make sense here?

That is something we can discuss, but it not for this PR.

[AaronRobinsonMSFT]

we can push the hotpaths to managed

That seems unlikely in this case. The use of SString is litered throughout the system and there are many places where it is going to be unnatural and difficult to call into managed code. We can try jumping out in some cases, but that isn't something I am inclined to do in this PR.

[jkotas]

My bar for these types of changes is to avoid perf regressions. (Of course, perf improvements are nice - but it is better to evaluate them separately if they come with tradeoffs.)

Neither the existing FString fast path code nor the WideCharToMultiByte implementation built into Windows use any vectorization tricks. It suggests that we should not need vectorization tricks to avoid the perf regression here.

[jkotas]

The shape of the code in WideCharToMultiByte built into Windows is actually very similar to the corefx implementation and the minipal. It seems that the minipal implementation picked up some cruft alone the way that makes it quite a bit slower.

[am11]

It is interesting that we picked up minipal implementation for Windows + Unix in mono (and Unix in coreclr as before) in .NET 8 and haven't seen any report of regression. Maybe there is some low-hanging alignment issue which can be tweaked via cl switch?

[jkotas]

picked up minipal implementation for Windows + Unix in mono

Mono does not get as much perf scrutiny as CoreCLR.

low-hanging alignment issue

I do not think it is that.

From a cursory look, I see two problems:

• For smaller lengths, there is a fixed overhead. Adding a simple FString-like loop that deals with small ASCII-only strings as the first thing in the minipal_* methods should fix that.
• For longer lengths, the code of the core look does not look great (e.g. it uses more registers than necessary). For example, it may help to change

  runtime/src/native/minipal/utf8.c

  Lines 1613 to 1618 in 7b18be5

  	*pTarget= (unsigned char)ch;
  	*(pTarget+1) = (unsigned char)(ch >> 16);
  	pSrc+=4;
  	*(pTarget+2) = (unsigned char)chc;
  	*(pTarget+3) = (unsigned char)(chc >> 16);
  	pTarget+=4;

  to

 *pTarget = (unsigned char)ch;
*(pTarget + 2) = (unsigned char)(chc);
pSrc += 4;
*(pTarget + 1) = (unsigned char)(ch >> 16);
*(pTarget + 3) = (unsigned char)(chc >> 16);
pTarget += 4;

[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.