Microsoft MVP성태의 닷넷 이야기
.NET Framework: 758. C# 7.2 - Span<T> [링크 복사], [링크+제목 복사]
조회: 4191
글쓴 사람
홈페이지
첨부 파일
 

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://msdn.microsoft.com/en-us/magazine/mt814808.aspx

C# 7 Series, Part 10: Span<T> and universal memory management
; https://blogs.msdn.microsoft.com/mazhou/2018/03/25/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://msdn.microsoft.com/en-us/magazine/mt814808.aspx

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를 활용해 내놓은 새 버전을 쓰는 것만으로도 성능이 올라갈 수 있습니다.




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

[연관 글]





[최초 등록일: ]
[최종 수정일: 10/7/2019 ]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer@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의 강력한 방향성입니다.

[손님]
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 맞습니다. 정정합니다. 기사내용을 아무 생각없이 믿었네요.
[손님]

... 16  17  18  19  20  21  22  23  [24]  25  26  27  28  29  30  ...
NoWriterDateCnt.TitleFile(s)
11573정성태7/2/20182086Math: 26. GeoGebra 기하 (3) - 평행선
11572정성태7/1/20181891.NET Framework: 783. C# 컴파일러가 허용하지 않는 (유효한) 코드를 컴파일해 테스트하는 방법
11571정성태7/1/20181835.NET Framework: 782. C# - JIRA에 등록된 Project의 Version 항목 추가하는 방법파일 다운로드1
11570정성태7/2/20182888Math: 25. GeoGebra 기하 (2) - 임의의 선분과 특정 점을 지나는 수직선파일 다운로드1
11569정성태7/1/20182520Math: 24. GeoGebra 기하 (1) - 수직 이등분선파일 다운로드1
11568정성태7/12/20183756Math: 23. GeoGebra 기하 - 컴퍼스와 자를 이용한 작도 프로그램 [1]
11567정성태6/28/20182265.NET Framework: 781. C# - OpenCvSharp 사용 시 포인터를 이용한 속도 향상파일 다운로드1
11566정성태6/28/20184085.NET Framework: 780. C# - JIRA REST API 사용 정리파일 다운로드1
11565정성태6/28/20182366.NET Framework: 779. C# 7.3에서 enum을 boxing 없이 int 변환하기 - 세 번째 이야기파일 다운로드1
11564정성태6/27/20182309.NET Framework: 778. (Unity가 사용하는) 모노 런타임의 __makeref 오류
11563정성태6/27/20182049개발 환경 구성: 386. .NET Framework Native compiler 프리뷰 버전 사용법
11562정성태6/26/20181904개발 환경 구성: 385. 레지스트리에 등록된 원격지 스크립트 COM 객체 실행 방법
11561정성태6/26/20183849.NET Framework: 777. UI 요소의 접근은 반드시 그 UI를 만든 스레드에서! [3]파일 다운로드1
11560정성태3/2/20191811.NET Framework: 776. C# 7.3 - 초기화 식에서 변수 사용 가능(expression variables in initializers)파일 다운로드1
11559정성태1/27/20203923개발 환경 구성: 384. 영문 설정의 Windows 10 명령행 창(cmd.exe)의 한글 지원 [3]
11558정성태6/25/20182282.NET Framework: 775. C# 7.3 - unmanaged(blittable) 제네릭 제약파일 다운로드1
11557정성태6/22/20182589.NET Framework: 774. C# - blittable 타입이란?파일 다운로드1
11556정성태6/25/20184696.NET Framework: 773. C# 7.3 - 구조체의 고정 크기를 갖는 fixed 배열 필드에 대한 직접 접근 가능 [1]파일 다운로드1
11555정성태6/25/20182174.NET Framework: 772. C# 7.3 - 사용자 정의 타입에 fixed 적용 가능(Custom fixed)파일 다운로드1
11554정성태6/25/20182310.NET Framework: 771. C# 7.3 - 자동 구현 속성에 특성 적용 가능(Attribute on backing field)
11553정성태6/25/20182559.NET Framework: 770. C# 7.3 - 개선된 메서드 선택 규칙 3가지(Improved overload candidates)파일 다운로드1
11552정성태6/25/20182487.NET Framework: 769. C# 7.3에서 개선된 문법 4개(Support == and != for tuples, Ref Reassignment, Constraints, Stackalloc initializers)파일 다운로드1
11551정성태6/14/20181683개발 환경 구성: 383. BenchmarkDotNet 사용 시 주의 사항
11550정성태6/13/20182083.NET Framework: 768. BenchmarkDotNet으로 Span<T> 성능 측정
11549정성태6/13/20181809개발 환경 구성: 382. BenchmarkDotNet에서 생성한 BuildPlots.R 파일을 실행하는 방법
11548정성태6/13/20182072오류 유형: 470. .NET Core + BenchmarkDotNet 실행 시 프레임워크를 찾지 못하는 문제
... 16  17  18  19  20  21  22  23  [24]  25  26  27  28  29  30  ...