Microsoft MVP성태의 닷넷 이야기
.NET Framework: 758. C# 7.2 - Span<T> [링크 복사], [링크+제목 복사]
조회: 20387
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 
(연관된 글이 20개 있습니다.)

C# 7.2 - Span<T>

C# 7.2 (1) - readonly 구조체
; https://www.sysnet.pe.kr/2/0/11524

C# 7.2 (2) - 메서드의 매개 변수에 in 변경자 추가
; https://www.sysnet.pe.kr/2/0/11525

C# 7.2 (3) - 메서드의 반환값 및 로컬 변수에 ref readonly 기능 추가
; https://www.sysnet.pe.kr/2/0/11526

C# 7.2 (4) - 3항 연산자에 ref 지원(conditional ref operator)
; https://www.sysnet.pe.kr/2/0/11528

C# 7.2 (5) - 스택에만 생성할 수 있는 값 타입 지원 - "ref struct"
; https://www.sysnet.pe.kr/2/0/11530

C# 7.2 (6) - Span<T>
; https://www.sysnet.pe.kr/2/0/11534

C# 7.2 (7) - private protected 접근자 추가
; https://www.sysnet.pe.kr/2/0/11543

C# 7.2 (8) - 숫자 리터럴의 선행 밑줄과 뒤에 오지 않는 명명된 인수
; https://www.sysnet.pe.kr/2/0/11544

기타 - Microsoft Build 2018 - The future of C# 동영상 내용 정리
; https://www.sysnet.pe.kr/2/0/11536




엄밀히, Span<T> 타입은 C# 7.2의 기능은 아니고 C# 7.2의 "ref struct" 구문을 이용한 하나의 사례일 뿐입니다. 심지어, Span<T> 타입은 (2018-06-05 기준 가장 최신 버전인) .NET Framework 4.7.2에도 포함되어 있지 않고 .NET Core 쪽으로만 2.1 이후부터 제공되고 있습니다.

따라서 이 글의 내용을 .NET Framework에서 실습하고 싶다면 System.Memory 어셈블리를 NuGet으로부터 받아야만 합니다. (또는, .NET Core 2.1 용 프로젝트를 생성합니다.)

System.Memory
; https://www.nuget.org/packages/System.Memory

Install-Package System.Memory -Version 4.5.0

참고로, 다음의 글을 읽어보시는 것도 좋습니다.

C# - All About Span: Exploring a New .NET Mainstay
; https://learn.microsoft.com/en-us/archive/msdn-magazine/2018/january/csharp-all-about-span-exploring-a-new-net-mainstay

C# 7 Series, Part 10: Span<T> and universal memory management
; https://learn.microsoft.com/en-us/archive/blogs/mazhou/c-7-series-part-10-spant-and-universal-memory-management




지난 글에서 설명한 "ref struct"의,

C# 7.2 - 스택에만 생성할 수 있는 값 타입 지원 - "ref struct"
; https://www.sysnet.pe.kr/2/0/11530

실제 적용 사례가 바로 Span<T> 타입입니다.

public readonly ref struct Span<T>
{
  private readonly ref T _pointer;
  private readonly int _length;
  ...
}

그로 인해 Span 타입은 반드시 스택에만 할당할 수 있으므로 ref struct가 아닌 타입의 필드로는 정의할 수 없습니다. 비록 Span 타입을 만들기 위해 ref struct가 나온 것으로 보이지만, Span은 내부에 관리 포인터를 - 그것도 제네릭 표현으로 가지고 있다는 면에서 C# 개발자들이 Span과 같은 타입을 만들 수 없다는 특별함이 있습니다. "C# - All About Span: Exploring a New .NET Mainstay" 글에서는 이에 대해 다음과 같이 언급하고 있습니다.

The concept of a ref T field may be strange at first-in fact, one can't actually declare a ref T field in C# or even in MSIL. But Span<T> is actually written to use a special internal type in the runtime that's treated as a just-in-time (JIT) intrinsic, with the JIT generating for it the equivalent of a ref T field.


따라서 Span 타입은 간단하게 "제네릭 관리 포인터를 가진 ref struct"라는 특별한 구조체입니다. 결국 관리 포인터를 포함하고 있기 때문에 힙에 할당되어서는 안 되며 이러한 요구 사항은 "ref struct"에 부합합니다. (참고로, 관리 포인터를 힙에 가질 수 있도록 참조 형의 필드로 추가하거나 어떤 식으로든 관리 힙에 전달하는 식의 코드가 있다면 JIT 컴파일 단계에서 IL Verification을 통과하지 못해 런타임 예외가 발생합니다.)

기능적인 면에서 Span 타입을 설명하면, "배열에 대한 참조 View"를 제공한다고 보면 됩니다. 따라서, C#에서 만드는 모든 배열에 대해 Span으로 가리킬 수 있습니다.

// 관리 메모리에 할당된 바이트 배열
// https://learn.microsoft.com/en-us/archive/msdn-magazine/2018/january/csharp-all-about-span-exploring-a-new-net-mainstay

var arr = new byte[10];
Span<byte> bytes = arr; // Implicit cast from T[] to Span<T>

참조 View이기 때문에 Span 변수의 값을 바꾸면 원본 변수의 값도 바뀝니다.

var arr = new byte[10];
System.Span<byte> bytes = arr;

bytes[2] = 5;

OutputArrary(arr); // 출력 결과: 0,0,5,0,0,0,0,0,0,0,

private static void OutputArrary(byte[] arr)
{
    for (int i = 0; i < arr.Length; i++)
    {
        Console.Write(arr[i] + ",");
    }

    Console.WriteLine();
}

관리 힙에 있는 배열뿐만 아니라 스택에 있는 배열까지도 Span 타입으로 참조 뷰를 만들 수 있습니다.

Span<byte> bytes = stackalloc byte[2]; // Using C# 7.2 stackalloc support for spans

관리 힙의 배열과는 다르게 stackalloc 배열을 간접적으로 받는 것은 안 되지만,


{
    var arr = new byte[10];
    System.Span<byte> bytes = arr; // OK
}

{
    var arr = stackalloc byte[10];
    System.Span<byte> bytes = arr; // 컴파일 오류 - CS0029 Cannot implicitly convert type 'byte*' to 'System.Span<byte>'
}

생성자를 통해 스택 배열의 크기와 함께 전달하는 것은 가능합니다.

byte* arr = stackalloc byte[10];
Span<byte> bytes = new Span<byte>(arr, 10);
PassStackAllocBytes(bytes);

Console.WriteLine(*(arr + 5));  // 출력: 5
Console.WriteLine(bytes[5]);    // 출력: 5

private static void PassStackAllocBytes(Span<byte> bytes)
{
    bytes[5] = 5;
}

물론, 스택 배열을 메서드가 반환한 경우 스택 해제로 인한 범위를 벗어나기 때문에 그런 경우에는 반환값으로 사용할 수 없습니다.

static Span<byte> GetStackAllocBytes()
{
    Span<byte> buffer = stackalloc byte[2];
    return buffer; // 컴파일 오류 - CS8352 Cannot use local 'buffer' in this context because it may expose referenced variables outside of their declaration scope
}

관리 메모리, 스택 메모리에 이어 관리되지 않는(unmanaged) 메모리에도 참조 뷰를 생성할 수 있습니다.

unsafe void UnmanagedView()
{
    int size = 1000;
    IntPtr ptr = Marshal.AllocCoTaskMem(size);

    try
    {
        Span<byte> bytes = new Span<byte>(ptr.ToPointer(), size);
        bytes[10] = 6;

        int value = Marshal.ReadByte(ptr, 10);
        Console.WriteLine(value); // 출력: 6
    }
    finally
    {
        Marshal.FreeCoTaskMem(ptr);
    }
}

재미있는 것은, unmanaged 메모리에 대한 "관리 타입의 참조 뷰" 역할을 Span 타입이 해준다는 점입니다. 그동안 C#에서 비관리 메모리 영역을 접근할 때는 AV(Access Violation) 예외나 기타 예측할 수 없는 상황에 빠질 수 있었는데요,

int size = 1000;
IntPtr ptr = <span style='color: blue; font-weight: bold'>Marshal.AllocCoTaskMem</span>(size);

try
{
    Marshal.WriteByte(ptr, size * 1000, 25); // unpredictable
}
catch (Exception ex)
{
    // Never run
    Console.WriteLine(ex.ToString());
}

이제는 간단하게 Span의 도움을 받아 unmanaged 메모리에 대한 접근을 안전하고 성능 저하 없이 할 수 있습니다.

int size = 1000;
IntPtr ptr = Marshal.AllocCoTaskMem(size);

Span<byte> bytes = new Span<byte>(ptr.ToPointer(), size);

try
{
    bytes[size * 1000] = 25; // 런타임 시 예외 발생 - System.IndexOutOfRangeException 
}
catch (Exception ex)
{
    Console.WriteLine("Catched: " + ex.ToString());
}

게다가 Span 타입이 제네릭이다 보니 비-관리 메모리에 대해 마치 관리 힙의 배열로 사용할 수 있도록 해줍니다.

int size = 1000;
IntPtr ptr = Marshal.AllocCoTaskMem(size * sizeof(int));

try
{
    Span<int> bytes = new Span<int>(ptr.ToPointer(), size);

    for (int i = 0; i < size; i ++)
    {
        bytes[i] = i;
    }

    OutputArrary(bytes);
}
finally
{
    Marshal.FreeCoTaskMem(ptr);
}

이렇게 Span 타입은 힙, 스택, 비-관리 메모리에 대해 공통적인 메모리 접근을 할 수 있기 때문에 "C# 7 Series, Part 10: Span<T> and universal memory management" 글의 제목에 "universal"이라는 수식어가 붙게 된 것입니다.




Span을 "참조 뷰"라고 소개했는데, "뷰"라는 관점으로 좀 더 설명해 보면 다음과 같은 기능이 있습니다.

var arr = new byte[10] { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 };
System.Span<byte> bytes = arr;

Span<byte> left = bytes.Slice(0, arr.Length / 2);
Span<byte> right = bytes.Slice(arr.Length / 2);

for (int i = 0; i < arr.Length / 2; i ++)
{
    left[i] = i * 10;
    right[i] = i * 10;
}

OutputArrary(left);
OutputArrary(right);

/*
출력 결과:

0,10,20,30,40,
0,10,20,30,40,
*/

이렇게 부분 뷰에 대한 참조를 일컬어 "interior pointer"라고 하며 Language Feature Status 문서에서 C# 7.2의 기능으로 "interior pointer/Span/ref struct"라고 소개할 때의 바로 그 단어입니다.

이를 활용하면, 특정 메모리의 영역만을 건드리도록 제약을 두고 다른 메서드에 쉽게 전달하는 것이 가능합니다. 과거에 이런 View 역할을 해주는 ArraySegment가 있었지만,

System.IO.MemoryStream, ArraySegment<T>의 효율적인 사용법
; https://www.sysnet.pe.kr/2/0/1483

이젠 Span<T>가 그 역할을 대신하게 될 것입니다. 참조 뷰를 잘 활용하면 기존 코드들의 성능을 높일 수 있는 시나리오가 제법 됩니다. "C# - All About Span: Exploring a New .NET Mainstay" 글에는 이에 대한 예제로 "123,456"과 같은 문자열로부터 숫자 데이터 2개를 구하는 기존 코드를 보여줍니다.

string input = ...;
int commaPos = input.IndexOf(',');
int first = int.Parse(input.Substring(0, commaPos)); // "123" 신규 문자열 할당
int second = int.Parse(input.Substring(commaPos + 1)); // "456" 신규 문자열 할당

위와 같은 경우, string은 불변 객체이기 때문에 2번의 input.Substring은 개별적인 메모리 할당이 됩니다. 이것을 향후 .NET Framework의 BCL에 Span을 받는 메서드를 추가하는 것으로 다음과 같이 성능을 더 높일 수 있다고 합니다.

string input = ...;
ReadOnlySpan<char> inputSpan = input.AsSpan();
int commaPos = input.IndexOf(',');
int first = int.Parse(inputSpan.Slice(0, commaPos));   // 할당 없이 "123" 영역을 가리키는 Span
int second = int.Parse(inputSpan.Slice(commaPos + 1)); // 할당 없이 "456" 영역을 가리키는 Span




Span<T>외에도 "readonly ref struct Span<T>"에 해당하는 "System.ReadOnlySpan<T>"이 있습니다. 대표적으로 string 조작을 할 때 (string이 immutable이므로) ReadOnlySpan으로 받는 것이 적당합니다.

그리고 이러한 Span 타입들이 모두 "ref struct"이기 때문에 heap에 생성할 수 없어 비동기 메서드 및 열거자와 같은 몇 가지 시나리오에서 사용할 수 없는 제약이 있습니다. 그래서, Span 타입과의 연동 및 그와 유사한 역할을 하도록 "readonly struct"로 정의한 System.Memory<T>가 있으며 다시 그것의 readonly인 ReadOnlyMemory<T>가 있습니다.

아마도 이를 모두 적용한 .NET Framework 신규 버전이 나오면 BCL 자체 내에서도 Span/Memory를 이용한 코드를 적용할 것이므로 어쩌면 프레임워크 버전을 올리는 것만으로도 기존 닷넷 응용 프로그램의 성능이 높아지는 결과가 발생할 수 있습니다. 또한 응용 프로그램에서 사용 중인 (JSON.NET과 같은) 기존 라이브러리들이 Span/Memory를 활용해 내놓은 새 버전을 쓰는 것만으로도 성능이 올라갈 수 있습니다.




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]






[최초 등록일: ]
[최종 수정일: 12/5/2023]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 



2018-06-07 01시18분
[spowner] 본문과 직접적인 글은 아니지만...
.NET의 고질적인 성능 문제를 해결하는 중요한 변경이 아닌가 합니다. 제가 전반적인 개념을 잡고 있지는 못해 두리뭉실하게 표현할 수 밖에 없지만, .NET Core의 Open Source 활동을 통해 .NET 환경이 최적화 되고 있는 것은 사실이고, .NET이 고성능이 필요한 환경에 쓰여질 수 있도록 진화하는것 처럼 보입니다.
얼마전에 GitHub가 Microsoft에 피인수 되었다는 기사를 보았습니다. 75억 달라로 Microsoft의 지분 배당으로 성사되었다 하는데, 그 규모에 놀랍니다. (GitHub는 현재도 수익 구조가 없습니다)
Microsoft가 GitHub를 인수한다는 소식이 국내 안에서는 부정적으로 평가하는것 같은데, CEO인 Satya Nadella의 Open Source 생태계 안에서의 입지를 굳히는 노력은 수년동안 지속되어 왔고 현재 Microsoft의 강력한 방향성입니다.
[guest]
2018-06-07 03시00분
맞습니다. 이번 C# 7.2의 주요 변화는 GC 구동 및 데이터 복사를 최소화할 수 있는 문법이 추가돼 고성능을 요구하는 환경(예를 들어 게임 루프)에서의 요구 사항을 어느 정도는 만족시켜 줄 거라 봅니다.

그나저나 github의 수익 구조는 private repo 아닌가요? 물론 거의 수익이 없을 수 있겠지만. ^^

제 생각에는 Open Source 생태계 안에서의 입지를 굳히기 위한 노력이라기보다는 Github에 축적된 소스 코드라는 데이터를 기반으로 더 나은 개발 도구를 만들려는 노력으로 보입니다. 게다가 마이크로소프트 입장에서 azure라는 클라우드 리소스가 이미 있는 상태여서 github의 데이터를 품기에 최적인 환경을 갖추고 있으므로 향후 유지/보수 비용도 크지는 않을 듯 싶고.
정성태
2018-06-07 03시42분
[spowner] GibHub 수익구조는 Private Repo 맞습니다. 정정합니다. 기사내용을 아무 생각없이 믿었네요.
[guest]
2021-04-06 11시49분
정성태
2022-03-09 03시10분
[guest] 좋은글 잘 봤습니다. 덕분에 제가 뭘 모르는지나 어렴풋이 알게 된거같은데 참조뷰나 배열들이 어떤식으로 메모리에 할당 되는지 볼려면 어떤 것을 찾아보느게 좋나요 ? 저술하신 책에 이런 내용이 있나요 ?
[guest]
2022-03-09 11시05분
"참조 뷰"라는 것은 Span<T>가 취하는 기능에 대한 용어일 뿐 결국 "참조 뷰가 어떤 식으로 메모리에 할당되는지"는 Span<T> 타입의 멤버 필드 구성이 어떻게 되어 있느냐와 같은 문제입니다. 그리고 배열의 경우에는 관리 힙에 연속해서 할당되는 것이라 딱히 설명할 것이 없습니다.

제 책의 경우에는 요청하신 그런 부분을 자세하게 설명하지는 않지만 값 형식/참조 형식을 좀 더 자세하게 다루면서 위와 같은 식견을 가질 수 있는 바탕을 제공합니다. 그래도 책의 저자다 보니... ^^ 만약 C#을 정식으로 공부한 적이 없으시다면 책을 추천합니다. (의외로 C# 경력자들이 제 책에 대해 유익했다는 피드백이 많았습니다.)
정성태

1  [2]  3  4  5  6  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
13574정성태3/6/20241552닷넷: 2226. C# - "Docker Desktop for Windows" Container 환경에서의 IPv6 DualMode 소켓
13573정성태3/5/20241561닷넷: 2225. Windbg - dumasync로 분석하는 async/await 호출
13572정성태3/4/20241635닷넷: 2224. C# - WPF의 Dispatcher Queue로 알아보는 await 호출의 hang 현상파일 다운로드1
13571정성태3/1/20241598닷넷: 2223. C# - await 호출과 WPF의 Dispatcher Queue 동작 확인파일 다운로드1
13570정성태2/29/20241623닷넷: 2222. C# - WPF의 Dispatcher Queue 동작 확인파일 다운로드1
13569정성태2/28/20241537닷넷: 2221. C# - LoadContext, LoadFromContext 그리고 GAC파일 다운로드1
13568정성태2/27/20241602닷넷: 2220. C# - .NET Framework 프로세스의 LoaderOptimization 설정을 확인하는 방법파일 다운로드1
13567정성태2/27/20241613오류 유형: 898. .NET Framework 3.5 이하에서 mscoree.tlb 참조 시 System.BadImageFormatException파일 다운로드1
13566정성태2/27/20241626오류 유형: 897. Windows 7 SDK 설치 시 ".NET Development" 옵션이 비활성으로 선택이 안 되는 경우
13565정성태2/23/20241464닷넷: 2219. .NET CLR2 보안 모델에서의 개별 System.Security.Permissions 제어
13564정성태2/22/20241608Windows: 259. Hyper-V Generation 1 유형의 VM을 Generation 2 유형으로 바꾸는 방법
13563정성태2/21/20241625디버깅 기술: 196. windbg - async/await 비동기인 경우 메모리 덤프 분석의 어려움
13562정성태2/21/20241628오류 유형: 896. ASP.NET - .NET Framework 기본 예제에서 System.Web에 대한 System.IO.FileNotFoundException 예외 발생
13561정성태2/20/20241739닷넷: 2218. C# - (예를 들어, Socket) 비동기 I/O에 대한 await 호출 시 CancellationToken을 이용한 취소파일 다운로드1
13560정성태2/19/20241743디버깅 기술: 195. windbg 분석 사례 - Semaphore 잠금으로 인한 Hang 현상 (닷넷)
13559정성태2/19/20242620오류 유형: 895. ASP.NET - System.Security.SecurityException: 'Requested registry access is not allowed.'
13558정성태2/18/20241815닷넷: 2217. C# - 최댓값이 1인 SemaphoreSlim 보다 Mutex 또는 lock(obj)를 선택하는 것이 나은 이유
13557정성태2/18/20241569Windows: 258. Task Scheduler의 Author 속성 값을 변경하는 방법
13556정성태2/17/20241634Windows: 257. Windows - Symbolic (hard/soft) Link 및 Junction 차이점
13555정성태2/15/20241946닷넷: 2216. C# - SemaphoreSlim 사용 시 주의점
13554정성태2/15/20241706VS.NET IDE: 189. Visual Studio - 닷넷 소스코드 디컴파일 찾기가 안 될 때
13553정성태2/14/20241728닷넷: 2215. windbg - thin/fat lock 없이 동작하는 Monitor.Wait + Pulse
13552정성태2/13/20241682닷넷: 2214. windbg - Monitor.Enter의 thin lock과 fat lock
13551정성태2/12/20242011닷넷: 2213. ASP.NET/Core 웹 응용 프로그램 - 2차 스레드의 예외로 인한 비정상 종료
13550정성태2/11/20242101Windows: 256. C# - Server socket이 닫히면 Accept 시켰던 자식 소켓이 닫힐까요?
13549정성태2/3/20242473개발 환경 구성: 706. C# - 컨테이너에서 실행하기 위한 (소켓) 콘솔 프로젝트 구성
1  [2]  3  4  5  6  7  8  9  10  11  12  13  14  15  ...