Remove unnecessary endianness dependent logic

[buyaa-n]

Before my PR #102364 the Base64Encoder was populating uint by concatenating encoded 4 bytes (by accounting the endianness)

runtime/src/libraries/System.Private.CoreLib/src/System/Buffers/Text/Base64Encoder.cs

Lines 533 to 545 in 4a37e73

	uinti0=Unsafe.Add(refencodingMap,(IntPtr)(i>>18));
	uinti1=Unsafe.Add(refencodingMap,(IntPtr)((i>>12)&0x3F));
	uinti2=Unsafe.Add(refencodingMap,(IntPtr)((i>>6)&0x3F));
	uinti3=Unsafe.Add(refencodingMap,(IntPtr)(i&0x3F));
	if(BitConverter.IsLittleEndian)
	{
	returni0|(i1<<8)|(i2<<16)|(i3<<24);
	}
	else
	{
	return(i0<<24)|(i1<<16)|(i2<<8)|i3;
	}

and was writing that uint to the destination buffer:

runtime/src/libraries/System.Private.CoreLib/src/System/Buffers/Text/Base64Encoder.cs

Lines 95 to 96 in 4a37e73

	result=Encode(src,refencodingMap);
	Unsafe.WriteUnaligned(dest,result);

I changed that to directly assign encoded bytes to destination (instead of concatenating them into one uint and write once), where I kept the endianness logic when I should not, endianness has no effect for ASCII characters:

runtime/src/libraries/System.Private.CoreLib/src/System/Buffers/Text/Base64Helper/Base64EncoderHelper.cs

Lines 766 to 784 in 745b776

	bytei0=Unsafe.Add(refencodingMap,(IntPtr)(i>>18));
	bytei1=Unsafe.Add(refencodingMap,(IntPtr)((i>>12)&0x3F));
	bytei2=Unsafe.Add(refencodingMap,(IntPtr)((i>>6)&0x3F));
	bytei3=Unsafe.Add(refencodingMap,(IntPtr)(i&0x3F));
	if(BitConverter.IsLittleEndian)
	{
	destination[0]=i0;
	destination[1]=i1;
	destination[2]=i2;
	destination[3]=i3;
	}
	else
	{
	destination[3]=i0;
	destination[2]=i1;
	destination[1]=i2;
	destination[0]=i3;
	}

Fixes#104283

[buyaa-n]

/azp run runtime-community

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-memory
See info in area-owners.md if you want to be subscribed.

[stephentoub]

I changed that to directly assign encoded bytes to destination (instead of concatenating them into one uint and write once)

Why?

[buyaa-n]

Why?

I think I had build error for Unsafe.WriteUnaligned(dest, result); when changed the dest type to T, though that doesn't seem happen now, is this less performant? I can revert that change NO, I need to keep it

[buyaa-n]

Why?

Now I know why I did this, writing uint to dest only work for byte* dest, but will not work for ushort* dest

[buyaa-n]

/azp run runtime-community

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[stephentoub]

Why?

Now I know why I did this, writing uint to dest only work for byte* dest, but will not work for ushort* dest

But writing to a ulong would work in that case, no?

[buyaa-n]

But writing to a ulong would work in that case, no?

Did not think about that 😄. Though it looks to me more efficient, no? Compared to doing several |, << operations, I can change then

[buyaa-n]

Though it looks to me more efficient, no?

According to the local perf test, turns out the old approach is bit more performant, reverted to old approach except the case where padding is omitted and not writing 4 bytes to destination

[buyaa-n]

/azp run runtime-community

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[saitama951]

@buyaa-n The s390x community CI was timing out since last week, This has been fixed now. can you please re-run the CI?

[stephentoub]

/azp run runtime-community

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[buyaa-n]

Failures are unrelated and known

[buyaa-n]

Before my PR #102364 the Base64Encoder was populating uint by concatenating encoded 4 bytes (by accounting the endianness)

runtime/src/libraries/System.Private.CoreLib/src/System/Buffers/Text/Base64Encoder.cs

Lines 533 to 545 in 4a37e73

	uinti0=Unsafe.Add(refencodingMap,(IntPtr)(i>>18));
	uinti1=Unsafe.Add(refencodingMap,(IntPtr)((i>>12)&0x3F));
	uinti2=Unsafe.Add(refencodingMap,(IntPtr)((i>>6)&0x3F));
	uinti3=Unsafe.Add(refencodingMap,(IntPtr)(i&0x3F));
	if(BitConverter.IsLittleEndian)
	{
	returni0|(i1<<8)|(i2<<16)|(i3<<24);
	}
	else
	{
	return(i0<<24)|(i1<<16)|(i2<<8)|i3;
	}

and was writing that uint to the destination buffer:

runtime/src/libraries/System.Private.CoreLib/src/System/Buffers/Text/Base64Encoder.cs

Lines 95 to 96 in 4a37e73

	result=Encode(src,refencodingMap);
	Unsafe.WriteUnaligned(dest,result);

I changed that to directly assign encoded bytes to destination (instead of concatenating them into one uint and write once), where I kept the endianness logic when I should not, endianness has no effect for ASCII characters:

runtime/src/libraries/System.Private.CoreLib/src/System/Buffers/Text/Base64Helper/Base64EncoderHelper.cs

Lines 766 to 784 in 745b776

	bytei0=Unsafe.Add(refencodingMap,(IntPtr)(i>>18));
	bytei1=Unsafe.Add(refencodingMap,(IntPtr)((i>>12)&0x3F));
	bytei2=Unsafe.Add(refencodingMap,(IntPtr)((i>>6)&0x3F));
	bytei3=Unsafe.Add(refencodingMap,(IntPtr)(i&0x3F));
	if(BitConverter.IsLittleEndian)
	{
	destination[0]=i0;
	destination[1]=i1;
	destination[2]=i2;
	destination[3]=i3;
	}
	else
	{
	destination[3]=i0;
	destination[2]=i1;
	destination[1]=i2;
	destination[0]=i3;
	}

Fixes#104283

[buyaa-n]

/azp run runtime-community

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-memory
See info in area-owners.md if you want to be subscribed.

[stephentoub]

I changed that to directly assign encoded bytes to destination (instead of concatenating them into one uint and write once)

Why?

[buyaa-n]

Why?

I think I had build error for Unsafe.WriteUnaligned(dest, result); when changed the dest type to T, though that doesn't seem happen now, is this less performant? I can revert that change NO, I need to keep it

[buyaa-n]

Why?

Now I know why I did this, writing uint to dest only work for byte* dest, but will not work for ushort* dest

[buyaa-n]

/azp run runtime-community

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[stephentoub]

Why?

Now I know why I did this, writing uint to dest only work for byte* dest, but will not work for ushort* dest

But writing to a ulong would work in that case, no?

[buyaa-n]

But writing to a ulong would work in that case, no?

Did not think about that 😄. Though it looks to me more efficient, no? Compared to doing several |, << operations, I can change then

[buyaa-n]

Though it looks to me more efficient, no?

According to the local perf test, turns out the old approach is bit more performant, reverted to old approach except the case where padding is omitted and not writing 4 bytes to destination

[buyaa-n]

/azp run runtime-community

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[saitama951]

@buyaa-n The s390x community CI was timing out since last week, This has been fixed now. can you please re-run the CI?

[stephentoub]

/azp run runtime-community

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[buyaa-n]

Failures are unrelated and known

[buyaa-n]

Before my PR #102364 the Base64Encoder was populating uint by concatenating encoded 4 bytes (by accounting the endianness)

runtime/src/libraries/System.Private.CoreLib/src/System/Buffers/Text/Base64Encoder.cs

Lines 533 to 545 in 4a37e73

	uinti0=Unsafe.Add(refencodingMap,(IntPtr)(i>>18));
	uinti1=Unsafe.Add(refencodingMap,(IntPtr)((i>>12)&0x3F));
	uinti2=Unsafe.Add(refencodingMap,(IntPtr)((i>>6)&0x3F));
	uinti3=Unsafe.Add(refencodingMap,(IntPtr)(i&0x3F));
	if(BitConverter.IsLittleEndian)
	{
	returni0|(i1<<8)|(i2<<16)|(i3<<24);
	}
	else
	{
	return(i0<<24)|(i1<<16)|(i2<<8)|i3;
	}

and was writing that uint to the destination buffer:

runtime/src/libraries/System.Private.CoreLib/src/System/Buffers/Text/Base64Encoder.cs

Lines 95 to 96 in 4a37e73

	result=Encode(src,refencodingMap);
	Unsafe.WriteUnaligned(dest,result);

I changed that to directly assign encoded bytes to destination (instead of concatenating them into one uint and write once), where I kept the endianness logic when I should not, endianness has no effect for ASCII characters:

runtime/src/libraries/System.Private.CoreLib/src/System/Buffers/Text/Base64Helper/Base64EncoderHelper.cs

Lines 766 to 784 in 745b776

	bytei0=Unsafe.Add(refencodingMap,(IntPtr)(i>>18));
	bytei1=Unsafe.Add(refencodingMap,(IntPtr)((i>>12)&0x3F));
	bytei2=Unsafe.Add(refencodingMap,(IntPtr)((i>>6)&0x3F));
	bytei3=Unsafe.Add(refencodingMap,(IntPtr)(i&0x3F));
	if(BitConverter.IsLittleEndian)
	{
	destination[0]=i0;
	destination[1]=i1;
	destination[2]=i2;
	destination[3]=i3;
	}
	else
	{
	destination[3]=i0;
	destination[2]=i1;
	destination[1]=i2;
	destination[0]=i3;
	}

Fixes#104283

[buyaa-n]

/azp run runtime-community

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-memory
See info in area-owners.md if you want to be subscribed.

[stephentoub]

I changed that to directly assign encoded bytes to destination (instead of concatenating them into one uint and write once)

Why?

[buyaa-n]

Why?

I think I had build error for Unsafe.WriteUnaligned(dest, result); when changed the dest type to T, though that doesn't seem happen now, is this less performant? I can revert that change NO, I need to keep it

[buyaa-n]

Why?

Now I know why I did this, writing uint to dest only work for byte* dest, but will not work for ushort* dest

[buyaa-n]

/azp run runtime-community

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[stephentoub]

Why?

Now I know why I did this, writing uint to dest only work for byte* dest, but will not work for ushort* dest

But writing to a ulong would work in that case, no?

[buyaa-n]

But writing to a ulong would work in that case, no?

Did not think about that 😄. Though it looks to me more efficient, no? Compared to doing several |, << operations, I can change then

[buyaa-n]

Though it looks to me more efficient, no?

According to the local perf test, turns out the old approach is bit more performant, reverted to old approach except the case where padding is omitted and not writing 4 bytes to destination

[buyaa-n]

/azp run runtime-community

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[saitama951]

@buyaa-n The s390x community CI was timing out since last week, This has been fixed now. can you please re-run the CI?

[stephentoub]

/azp run runtime-community

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[buyaa-n]

Failures are unrelated and known

[buyaa-n]

Before my PR #102364 the Base64Encoder was populating uint by concatenating encoded 4 bytes (by accounting the endianness)

runtime/src/libraries/System.Private.CoreLib/src/System/Buffers/Text/Base64Encoder.cs

Lines 533 to 545 in 4a37e73

	uinti0=Unsafe.Add(refencodingMap,(IntPtr)(i>>18));
	uinti1=Unsafe.Add(refencodingMap,(IntPtr)((i>>12)&0x3F));
	uinti2=Unsafe.Add(refencodingMap,(IntPtr)((i>>6)&0x3F));
	uinti3=Unsafe.Add(refencodingMap,(IntPtr)(i&0x3F));
	if(BitConverter.IsLittleEndian)
	{
	returni0|(i1<<8)|(i2<<16)|(i3<<24);
	}
	else
	{
	return(i0<<24)|(i1<<16)|(i2<<8)|i3;
	}

and was writing that uint to the destination buffer:

runtime/src/libraries/System.Private.CoreLib/src/System/Buffers/Text/Base64Encoder.cs

Lines 95 to 96 in 4a37e73

	result=Encode(src,refencodingMap);
	Unsafe.WriteUnaligned(dest,result);

I changed that to directly assign encoded bytes to destination (instead of concatenating them into one uint and write once), where I kept the endianness logic when I should not, endianness has no effect for ASCII characters:

runtime/src/libraries/System.Private.CoreLib/src/System/Buffers/Text/Base64Helper/Base64EncoderHelper.cs

Lines 766 to 784 in 745b776

	bytei0=Unsafe.Add(refencodingMap,(IntPtr)(i>>18));
	bytei1=Unsafe.Add(refencodingMap,(IntPtr)((i>>12)&0x3F));
	bytei2=Unsafe.Add(refencodingMap,(IntPtr)((i>>6)&0x3F));
	bytei3=Unsafe.Add(refencodingMap,(IntPtr)(i&0x3F));
	if(BitConverter.IsLittleEndian)
	{
	destination[0]=i0;
	destination[1]=i1;
	destination[2]=i2;
	destination[3]=i3;
	}
	else
	{
	destination[3]=i0;
	destination[2]=i1;
	destination[1]=i2;
	destination[0]=i3;
	}

Fixes#104283

[buyaa-n]

/azp run runtime-community

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-memory
See info in area-owners.md if you want to be subscribed.

[stephentoub]

I changed that to directly assign encoded bytes to destination (instead of concatenating them into one uint and write once)

Why?

[buyaa-n]

Why?

I think I had build error for Unsafe.WriteUnaligned(dest, result); when changed the dest type to T, though that doesn't seem happen now, is this less performant? I can revert that change NO, I need to keep it

[buyaa-n]

Why?

Now I know why I did this, writing uint to dest only work for byte* dest, but will not work for ushort* dest

[buyaa-n]

/azp run runtime-community

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[stephentoub]

Why?

Now I know why I did this, writing uint to dest only work for byte* dest, but will not work for ushort* dest

But writing to a ulong would work in that case, no?

[buyaa-n]

But writing to a ulong would work in that case, no?

Did not think about that 😄. Though it looks to me more efficient, no? Compared to doing several |, << operations, I can change then

[buyaa-n]

Though it looks to me more efficient, no?

According to the local perf test, turns out the old approach is bit more performant, reverted to old approach except the case where padding is omitted and not writing 4 bytes to destination

[buyaa-n]

/azp run runtime-community

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[saitama951]

@buyaa-n The s390x community CI was timing out since last week, This has been fixed now. can you please re-run the CI?

[stephentoub]

/azp run runtime-community

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[buyaa-n]

Failures are unrelated and known

[buyaa-n]

Before my PR #102364 the Base64Encoder was populating uint by concatenating encoded 4 bytes (by accounting the endianness)

runtime/src/libraries/System.Private.CoreLib/src/System/Buffers/Text/Base64Encoder.cs

Lines 533 to 545 in 4a37e73

	uinti0=Unsafe.Add(refencodingMap,(IntPtr)(i>>18));
	uinti1=Unsafe.Add(refencodingMap,(IntPtr)((i>>12)&0x3F));
	uinti2=Unsafe.Add(refencodingMap,(IntPtr)((i>>6)&0x3F));
	uinti3=Unsafe.Add(refencodingMap,(IntPtr)(i&0x3F));
	if(BitConverter.IsLittleEndian)
	{
	returni0|(i1<<8)|(i2<<16)|(i3<<24);
	}
	else
	{
	return(i0<<24)|(i1<<16)|(i2<<8)|i3;
	}

and was writing that uint to the destination buffer:

runtime/src/libraries/System.Private.CoreLib/src/System/Buffers/Text/Base64Encoder.cs

Lines 95 to 96 in 4a37e73

	result=Encode(src,refencodingMap);
	Unsafe.WriteUnaligned(dest,result);

I changed that to directly assign encoded bytes to destination (instead of concatenating them into one uint and write once), where I kept the endianness logic when I should not, endianness has no effect for ASCII characters:

runtime/src/libraries/System.Private.CoreLib/src/System/Buffers/Text/Base64Helper/Base64EncoderHelper.cs

Lines 766 to 784 in 745b776

	bytei0=Unsafe.Add(refencodingMap,(IntPtr)(i>>18));
	bytei1=Unsafe.Add(refencodingMap,(IntPtr)((i>>12)&0x3F));
	bytei2=Unsafe.Add(refencodingMap,(IntPtr)((i>>6)&0x3F));
	bytei3=Unsafe.Add(refencodingMap,(IntPtr)(i&0x3F));
	if(BitConverter.IsLittleEndian)
	{
	destination[0]=i0;
	destination[1]=i1;
	destination[2]=i2;
	destination[3]=i3;
	}
	else
	{
	destination[3]=i0;
	destination[2]=i1;
	destination[1]=i2;
	destination[0]=i3;
	}

Fixes#104283

[buyaa-n]

/azp run runtime-community

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-memory
See info in area-owners.md if you want to be subscribed.

[stephentoub]

I changed that to directly assign encoded bytes to destination (instead of concatenating them into one uint and write once)

Why?

[buyaa-n]

Why?

I think I had build error for Unsafe.WriteUnaligned(dest, result); when changed the dest type to T, though that doesn't seem happen now, is this less performant? I can revert that change NO, I need to keep it

[buyaa-n]

Why?

Now I know why I did this, writing uint to dest only work for byte* dest, but will not work for ushort* dest

[buyaa-n]

/azp run runtime-community

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[stephentoub]

Why?

Now I know why I did this, writing uint to dest only work for byte* dest, but will not work for ushort* dest

But writing to a ulong would work in that case, no?

[buyaa-n]

But writing to a ulong would work in that case, no?

Did not think about that 😄. Though it looks to me more efficient, no? Compared to doing several |, << operations, I can change then

[buyaa-n]

Though it looks to me more efficient, no?

According to the local perf test, turns out the old approach is bit more performant, reverted to old approach except the case where padding is omitted and not writing 4 bytes to destination

[buyaa-n]

/azp run runtime-community

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[saitama951]

@buyaa-n The s390x community CI was timing out since last week, This has been fixed now. can you please re-run the CI?

[stephentoub]

/azp run runtime-community

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[buyaa-n]

Failures are unrelated and known

[buyaa-n]

Before my PR #102364 the Base64Encoder was populating uint by concatenating encoded 4 bytes (by accounting the endianness)

runtime/src/libraries/System.Private.CoreLib/src/System/Buffers/Text/Base64Encoder.cs

Lines 533 to 545 in 4a37e73

	uinti0=Unsafe.Add(refencodingMap,(IntPtr)(i>>18));
	uinti1=Unsafe.Add(refencodingMap,(IntPtr)((i>>12)&0x3F));
	uinti2=Unsafe.Add(refencodingMap,(IntPtr)((i>>6)&0x3F));
	uinti3=Unsafe.Add(refencodingMap,(IntPtr)(i&0x3F));
	if(BitConverter.IsLittleEndian)
	{
	returni0|(i1<<8)|(i2<<16)|(i3<<24);
	}
	else
	{
	return(i0<<24)|(i1<<16)|(i2<<8)|i3;
	}

and was writing that uint to the destination buffer:

runtime/src/libraries/System.Private.CoreLib/src/System/Buffers/Text/Base64Encoder.cs

Lines 95 to 96 in 4a37e73

	result=Encode(src,refencodingMap);
	Unsafe.WriteUnaligned(dest,result);

I changed that to directly assign encoded bytes to destination (instead of concatenating them into one uint and write once), where I kept the endianness logic when I should not, endianness has no effect for ASCII characters:

runtime/src/libraries/System.Private.CoreLib/src/System/Buffers/Text/Base64Helper/Base64EncoderHelper.cs

Lines 766 to 784 in 745b776

	bytei0=Unsafe.Add(refencodingMap,(IntPtr)(i>>18));
	bytei1=Unsafe.Add(refencodingMap,(IntPtr)((i>>12)&0x3F));
	bytei2=Unsafe.Add(refencodingMap,(IntPtr)((i>>6)&0x3F));
	bytei3=Unsafe.Add(refencodingMap,(IntPtr)(i&0x3F));
	if(BitConverter.IsLittleEndian)
	{
	destination[0]=i0;
	destination[1]=i1;
	destination[2]=i2;
	destination[3]=i3;
	}
	else
	{
	destination[3]=i0;
	destination[2]=i1;
	destination[1]=i2;
	destination[0]=i3;
	}

Fixes#104283

[buyaa-n]

/azp run runtime-community

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-memory
See info in area-owners.md if you want to be subscribed.

[stephentoub]

I changed that to directly assign encoded bytes to destination (instead of concatenating them into one uint and write once)

Why?

[buyaa-n]

Why?

I think I had build error for Unsafe.WriteUnaligned(dest, result); when changed the dest type to T, though that doesn't seem happen now, is this less performant? I can revert that change NO, I need to keep it

[buyaa-n]

Why?

Now I know why I did this, writing uint to dest only work for byte* dest, but will not work for ushort* dest

[buyaa-n]

/azp run runtime-community

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[stephentoub]

Why?

Now I know why I did this, writing uint to dest only work for byte* dest, but will not work for ushort* dest

But writing to a ulong would work in that case, no?

[buyaa-n]

But writing to a ulong would work in that case, no?

Did not think about that 😄. Though it looks to me more efficient, no? Compared to doing several |, << operations, I can change then

[buyaa-n]

Though it looks to me more efficient, no?

According to the local perf test, turns out the old approach is bit more performant, reverted to old approach except the case where padding is omitted and not writing 4 bytes to destination

[buyaa-n]

/azp run runtime-community

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[saitama951]

@buyaa-n The s390x community CI was timing out since last week, This has been fixed now. can you please re-run the CI?

[stephentoub]

/azp run runtime-community

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[buyaa-n]

Failures are unrelated and known

[buyaa-n]

Before my PR #102364 the Base64Encoder was populating uint by concatenating encoded 4 bytes (by accounting the endianness)

runtime/src/libraries/System.Private.CoreLib/src/System/Buffers/Text/Base64Encoder.cs

Lines 533 to 545 in 4a37e73

	uinti0=Unsafe.Add(refencodingMap,(IntPtr)(i>>18));
	uinti1=Unsafe.Add(refencodingMap,(IntPtr)((i>>12)&0x3F));
	uinti2=Unsafe.Add(refencodingMap,(IntPtr)((i>>6)&0x3F));
	uinti3=Unsafe.Add(refencodingMap,(IntPtr)(i&0x3F));
	if(BitConverter.IsLittleEndian)
	{
	returni0|(i1<<8)|(i2<<16)|(i3<<24);
	}
	else
	{
	return(i0<<24)|(i1<<16)|(i2<<8)|i3;
	}

and was writing that uint to the destination buffer:

runtime/src/libraries/System.Private.CoreLib/src/System/Buffers/Text/Base64Encoder.cs

Lines 95 to 96 in 4a37e73

	result=Encode(src,refencodingMap);
	Unsafe.WriteUnaligned(dest,result);

I changed that to directly assign encoded bytes to destination (instead of concatenating them into one uint and write once), where I kept the endianness logic when I should not, endianness has no effect for ASCII characters:

runtime/src/libraries/System.Private.CoreLib/src/System/Buffers/Text/Base64Helper/Base64EncoderHelper.cs

Lines 766 to 784 in 745b776

	bytei0=Unsafe.Add(refencodingMap,(IntPtr)(i>>18));
	bytei1=Unsafe.Add(refencodingMap,(IntPtr)((i>>12)&0x3F));
	bytei2=Unsafe.Add(refencodingMap,(IntPtr)((i>>6)&0x3F));
	bytei3=Unsafe.Add(refencodingMap,(IntPtr)(i&0x3F));
	if(BitConverter.IsLittleEndian)
	{
	destination[0]=i0;
	destination[1]=i1;
	destination[2]=i2;
	destination[3]=i3;
	}
	else
	{
	destination[3]=i0;
	destination[2]=i1;
	destination[1]=i2;
	destination[0]=i3;
	}

Fixes#104283

[buyaa-n]

/azp run runtime-community

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-memory
See info in area-owners.md if you want to be subscribed.

[stephentoub]

I changed that to directly assign encoded bytes to destination (instead of concatenating them into one uint and write once)

Why?

[buyaa-n]

Why?

I think I had build error for Unsafe.WriteUnaligned(dest, result); when changed the dest type to T, though that doesn't seem happen now, is this less performant? I can revert that change NO, I need to keep it

[buyaa-n]

Why?

Now I know why I did this, writing uint to dest only work for byte* dest, but will not work for ushort* dest

[buyaa-n]

/azp run runtime-community

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[stephentoub]

Why?

Now I know why I did this, writing uint to dest only work for byte* dest, but will not work for ushort* dest

But writing to a ulong would work in that case, no?

[buyaa-n]

But writing to a ulong would work in that case, no?

Did not think about that 😄. Though it looks to me more efficient, no? Compared to doing several |, << operations, I can change then

[buyaa-n]

Though it looks to me more efficient, no?

According to the local perf test, turns out the old approach is bit more performant, reverted to old approach except the case where padding is omitted and not writing 4 bytes to destination

[buyaa-n]

/azp run runtime-community

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[saitama951]

@buyaa-n The s390x community CI was timing out since last week, This has been fixed now. can you please re-run the CI?

[stephentoub]

/azp run runtime-community

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[buyaa-n]

Failures are unrelated and known

[buyaa-n]

Before my PR #102364 the Base64Encoder was populating uint by concatenating encoded 4 bytes (by accounting the endianness)

runtime/src/libraries/System.Private.CoreLib/src/System/Buffers/Text/Base64Encoder.cs

Lines 533 to 545 in 4a37e73

	uinti0=Unsafe.Add(refencodingMap,(IntPtr)(i>>18));
	uinti1=Unsafe.Add(refencodingMap,(IntPtr)((i>>12)&0x3F));
	uinti2=Unsafe.Add(refencodingMap,(IntPtr)((i>>6)&0x3F));
	uinti3=Unsafe.Add(refencodingMap,(IntPtr)(i&0x3F));
	if(BitConverter.IsLittleEndian)
	{
	returni0|(i1<<8)|(i2<<16)|(i3<<24);
	}
	else
	{
	return(i0<<24)|(i1<<16)|(i2<<8)|i3;
	}

and was writing that uint to the destination buffer:

runtime/src/libraries/System.Private.CoreLib/src/System/Buffers/Text/Base64Encoder.cs

Lines 95 to 96 in 4a37e73

	result=Encode(src,refencodingMap);
	Unsafe.WriteUnaligned(dest,result);

I changed that to directly assign encoded bytes to destination (instead of concatenating them into one uint and write once), where I kept the endianness logic when I should not, endianness has no effect for ASCII characters:

runtime/src/libraries/System.Private.CoreLib/src/System/Buffers/Text/Base64Helper/Base64EncoderHelper.cs

Lines 766 to 784 in 745b776

	bytei0=Unsafe.Add(refencodingMap,(IntPtr)(i>>18));
	bytei1=Unsafe.Add(refencodingMap,(IntPtr)((i>>12)&0x3F));
	bytei2=Unsafe.Add(refencodingMap,(IntPtr)((i>>6)&0x3F));
	bytei3=Unsafe.Add(refencodingMap,(IntPtr)(i&0x3F));
	if(BitConverter.IsLittleEndian)
	{
	destination[0]=i0;
	destination[1]=i1;
	destination[2]=i2;
	destination[3]=i3;
	}
	else
	{
	destination[3]=i0;
	destination[2]=i1;
	destination[1]=i2;
	destination[0]=i3;
	}

Fixes#104283

[buyaa-n]

/azp run runtime-community

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-memory
See info in area-owners.md if you want to be subscribed.

[stephentoub]

I changed that to directly assign encoded bytes to destination (instead of concatenating them into one uint and write once)

Why?

[buyaa-n]

Why?

I think I had build error for Unsafe.WriteUnaligned(dest, result); when changed the dest type to T, though that doesn't seem happen now, is this less performant? I can revert that change NO, I need to keep it

[buyaa-n]

Why?

Now I know why I did this, writing uint to dest only work for byte* dest, but will not work for ushort* dest

[buyaa-n]

/azp run runtime-community

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[stephentoub]

Why?

Now I know why I did this, writing uint to dest only work for byte* dest, but will not work for ushort* dest

But writing to a ulong would work in that case, no?

[buyaa-n]

But writing to a ulong would work in that case, no?

Did not think about that 😄. Though it looks to me more efficient, no? Compared to doing several |, << operations, I can change then

[buyaa-n]

Though it looks to me more efficient, no?

According to the local perf test, turns out the old approach is bit more performant, reverted to old approach except the case where padding is omitted and not writing 4 bytes to destination

[buyaa-n]

/azp run runtime-community

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[saitama951]

@buyaa-n The s390x community CI was timing out since last week, This has been fixed now. can you please re-run the CI?

[stephentoub]

/azp run runtime-community

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[buyaa-n]

Failures are unrelated and known